Zusammenfassung

  • RFC 913 schlug für ein einfaches Dateiübertragungsprotokoll ASCII, Binary und Continuous vor. Eine TOPS-20-Seite mit 512 Wörtern zu je 36 Bit ergibt in den Beispielen 2560, 2048 und 2304 übertragene Acht-Bit-Bytes.
  • Binary nimmt vier Bytes je Wort und lässt dessen letzte vier Bit weg. Continuous verpackt sämtliche Bits über Wortgrenzen hinweg. Der Erfolg der Übertragung sagt deshalb zunächst etwas über den gewählten Datenstrom, nicht automatisch über das vollständige Quellobjekt.

Der Rechner meldet Erfolg. Die Datei liegt auf dem Zielsystem. Was dort liegt, entscheidet ein kleines Wort, das der Benutzer vor dem Senden wählen konnte. Mark Lottors RFC 913 beschrieb im September 1984 ein Simple File Transfer Protocol auf TCP-Port 115. Dieses alte SFTP teilte nur die Abkürzung mit dem späteren SSH-Dateidienst. Es sollte mehr können als TFTP, weniger Aufwand verlangen als FTP und mit einer TCP-Verbindung auskommen. Der interessante Streit begann bei TYPE A, TYPE B und TYPE C: Nicht jede Maschine verstand unter einer Datei dieselbe Folge von Einheiten.

Das Beispiel im Papier verwendet TOPS-20. Ein Wort besitzt dort 36 Bit, eine Diskseite 512 Wörter. Insgesamt sind das 18.432 Bit. ASCII-Modus liest aus jedem Wort fünf Zeichen mit je sieben Bit. Das macht 35 Bit; das letzte bleibt außerhalb der Textdarstellung. Die Zeichen gehen in Acht-Bit-Einheiten mit freiem obersten Bit über die Leitung; lokale Zeilenenden werden nach NETASCII zu CRLF. So entstehen 2560 übertragene Bytes. Wer Text austauschen will, kann genau diese Umformung brauchen. Wer die komplette Bitfolge sichern will, braucht einen anderen Vertrag.

Binary klingt nach dem sicheren Vertrag. In der RFC holt der Modus allerdings vier Acht-Bit-Bytes aus jedem 36-Bit-Wort. Bit 32 bis 35 bleiben zu Hause. Aus 512 Wörtern werden 2048 Bytes. Bei einer Datei, deren entscheidende Inhalte bereits in vier Acht-Bit-Einheiten liegen, mag das passend sein. Bei anderer Belegung kann Information in den ausgelassenen vier Bit stecken. Das Wort „binär“ beschreibt hier die Einheiten des Transports; es gibt keine Zusage, dass jeder Speicherbit des Ursprungs mitfährt. Ein Name für die Kiste ist noch keine Inventarliste.

Continuous schiebt Wortgrenzen beiseite. Nach vier ganzen Bytes aus dem ersten Wort werden dessen restliche vier Bit mit den ersten vier Bit des nächsten Wortes verbunden. So gehen alle 18.432 Bit als 2304 Acht-Bit-Bytes auf Reisen. Für Maschinen mit Wortbreiten, die ohnehin durch acht teilbar sind, sollen Binary und Continuous laut RFC dasselbe leisten. TOPS-20 machte den Unterschied nötig. Der eine Modus behandelt jedes Wort als Behälter für vier Bytes; der andere behandelt die ganze Seite als durchgehendes Band. Am Ziel muss eine Anwendung immer noch wissen, wie das Band zu deuten ist.

Die vorgeschlagene Bedienung machte diese Wahl fast beiläufig. Befehle bestanden aus vier ASCII-Buchstaben plus NUL; ohne ausdrückliche Wahl galt Binary. Vor Dateioperationen konnten Kennung, Konto und Passwort verlangt werden. Der Dienst bot Verzeichnislisten, Wechsel des Verzeichnisses, Umbenennen, Löschen, Lesen und Schreiben. Ein sauber quittierter Transfer konnte also exakt die festgelegten 2048 Bytes liefern und dennoch an einer anderen Vorstellung vom ursprünglichen 36-Bit-Objekt vorbeigehen. Verbindungstreue und Dateitreue haben unterschiedliche Prüffragen.

Der RFC-Editor-Eintrag führt den Vorschlag heute als historisch. Seine Zahlen sind durchgerechnete Beispiele; sie dokumentieren keinen konkret beschädigten Nutzerbestand. Trotzdem sitzt der Befund: Dieselbe Seite kann im Protokoll 2560, 2048 oder 2304 Bytes groß sein. Der Transfer meldet guten Vollzug, während vier Bit je Wort je nach Modus nie in den Zug gestiegen sind. Wer die Datei zurückhaben will, muss vor der Abfahrt klären, welche Fahrkarte ihre Bits besitzen.