Zusammenfassung

  • Kermit entstand 1981 an der Columbia University, weil Studierende und Beschäftigte Dateien zwischen Großrechnern und den aufkommenden Mikrocomputern austauschen mussten.
  • Sein Kern aus kleinen bestätigten Paketen lief über serielle Leitungen; Zeichen-, Datensatz- und ausgehandelte Funktionsregeln überbrückten Unterschiede, die die Leitung selbst nicht lösen konnte.

Beim ersten Kermit-Transfer tauschten zwei Kermit-20-Programme eine Datei über ein Nullmodemkabel zwischen den seriellen Anschlüssen desselben DECSYSTEM-20 aus. Das Kermit Project bezeichnete dies später als Machbarkeitsnachweis: Eine Datei auf demselben Rechner zu kopieren, war einfacher. Der entscheidende Versuch folgte einige Wochen danach. Auf der einen Seite stand ein DEC-20 mit TOPS-20, auf der anderen ein Intertec Superbrain mit CP/M-80. Prozessor, Betriebssystem und Dateidarstellung unterschieden sich. Bytes zu senden war nur der sichtbare Teil der Aufgabe.

An der Columbia University änderte sich, wer die Rechner nutzte. Mikrocomputer hielten Einzug in Labore, Fachbereiche, Wohnungen und Wohnheime; benötigte Dateien und Dienste lagen weiterhin auf zentralen Timesharing-Systemen. In einem 1983 vorbereiteten Beitrag beschrieben Frank da Cruz und Bill Catchings studentische Kennungen, die je Kurs oder Semester vergeben wurden und keinen dauerhaften Plattenspeicher garantierten. Ein Mikrocomputer mit Diskette konnte Arbeit lokal sichern, sofern sie zuverlässig zwischen kleinem Rechner und Großrechner übertragen werden konnte.

Das dokumentiert den Bedarf einer Institution, nicht die Verhältnisse aller Universitäten.

Die serielle Leitung erschwerte den Austausch. Gewöhnliche asynchrone Verbindungen boten wenig Schutz vor Störungen, verlorenen Zeichen, überfüllten Puffern oder zeitweiligem Trägerverlust. Kermit zerlegte eine Übertragung daher in Pakete und machte jedes Paket zu einem Teil eines Dialogs. Der Sender begann mit einem Send-Init-Paket, das Parameter ankündigte. Der Empfänger antwortete mit seinen. Ein Dateikopf nannte den Dateinamen, Datenpakete trugen die Abschnitte, weitere Pakete markierten Datei- und Übertragungsende. Eine Bestätigung erlaubte den nächsten Schritt; eine negative Bestätigung oder ein Zeitablauf führte zur Wiederholung.

Der Grundmechanismus blieb bewusst klein. Die Paketnummer lief modulo 64, sodass beide Programme erkennen konnten, welche Einheit bestätigt worden war, und in der laufenden Sitzung fehlende oder doppelte Schritte bemerkten. Eine vorgeschriebene einstellige arithmetische Prüfsumme half, veränderte Pakete zu erkennen. Sie war weder ein modernes kryptografisches Prüfverfahren noch eine Identitätsprüfung der Person am anderen Ende. Sie half den Programmen, manche Übertragungsfehler festzustellen und erneut zu senden. Zuverlässigkeit entstand durch das Zusammenspiel der Endpunkte, nicht durch eine plötzlich vertrauenswürdige Leitung.

Kermits größeres Interoperabilitätsproblem lag oberhalb der Leitung. Zwei Rechner konnten ASCII austauschen und Dateien trotzdem verschieden interpretieren. DEC-20 und CP/M hatten andere Betriebsumgebungen; IBM-Großrechner brachten weitere Einschränkungen mit. Dateien konnten aus Datensätzen statt aus einem unstrukturierten Byte-Strom bestehen, Textkodierungen variierten, und ein Host-Terminal konnte Eingaben spiegeln, Zeilen umbrechen, Groß- und Kleinschreibung ändern oder Steuerzeichen verarbeiten. Wurde die Verbindung als transparente Röhre behandelt, konnte sich der Inhalt vor dem Schreiben auf den Zieldatenträger verändern.

Kermit definierte eine gemeinsame Übertragungsdarstellung und explizite Umwandlungen an beiden Enden. Das Grundformat der Pakete verwendete druckbare Zeichen; Steuerzeichen in den Daten konnten als druckbare Folgen codiert werden. Jedes Programm übersetzte den Austausch anschließend in die lokale Dateikonvention. Das Handbuch benennt die gemeinsame Voraussetzung eng: ASCII über eine gewöhnliche asynchrone serielle Leitung. Es machte die Rechner nicht gleich. Es gab ihnen eine begrenzte Sprache für den Dateiaustausch trotz unterschiedlicher Speicherung, Kodierung und Terminalverarbeitung.

Auch Programme mit unterschiedlichen Fähigkeiten mussten zusammenarbeiten. Das Handbuch vom November 1983 erklärt, dass die Entwicklung verteilt und nicht zentral organisiert war; deshalb ließ sich den Implementierern keine feste Protokollversion vorschreiben. Es beschrieb Grundfunktionen und optionale Erweiterungen. Im anfänglichen Austausch konnten die Seiten ihre Fähigkeiten mitteilen. Das erklärte Ziel war, dass eine einfache Implementierung mit einer fortgeschritteneren arbeiten könne. Das ist ein Gestaltungsziel im Handbuch, kein Beleg für Kompatibilität jedes Programmpaars.

Der kleine Kern fror das Protokoll nicht ein. Spätere Fassungen ergänzten längere Pakete, stärkere Blockprüfungen und Vollduplex-Schiebefenster. Das Handbuch schreibt die Entwicklung der Fensterfunktion für 1985–86 einer Gruppe bei The Source Telecomputing zu. Sie adressierte ein anderes Leistungsproblem: Auf einem Weg mit merklicher Laufzeit konnte das Warten auf jede einzelne Bestätigung Zeit verschwenden. Die Funktion musste ausgehandelt werden; ein nicht unterstützender Empfänger konnte beim Grundverfahren bleiben. Diese spätere Erweiterung ist nicht auf den ersten Transfer von 1981 zurückzuprojizieren.

Die Projektchronik verzeichnet 1984 eine Kermit-FTP-Site und die Info-Kermit-Mailingliste auf dem ARPANET. Das Netz erleichterte Verteilung und Diskussion, doch der ursprüngliche Bedarf blieb konkret: Eine Person wollte eine Datei von einer Rechnerart zu einer anderen bringen. Kermit war kein Internetstandard und ersetzte keine Netzwerkprotokolle. Es erledigte eine andere Aufgabe: Dateitransfer zwischen Systemen, die über eine serielle Leitung und später auch über Netzdienste verbunden waren.

Die Geschichte zeigt, dass Verbindung und Interoperabilität nicht dasselbe sind. Ein Trägersignal verbindet Terminals, macht ihre Dateien aber nicht kompatibel; eine Paketprüfung erkennt manche Fehler, authentifiziert jedoch nicht den Sender; eine gemeinsame Spezifikation ermöglicht Austausch, garantiert aber nicht die Übernahme jeder Option. Kermit machte diese Übergänge zu einem ausdrücklichen, implementierbaren Dialog.

Quellen