Zusammenfassung

  • Gemeinsam waren bei XMODEM nur 128 Datenbytes, Blocknummer und Komplement, eine einfache Prüfsumme, die vom Empfänger gesteuerte Bestätigung sowie ein eindeutiges Ende. Verbindungsaufbau, Speicherung und Benutzerführung gehörten nicht zum Drahtprotokoll.
  • Die schmale Grenze machte unabhängige Implementierungen bezahlbar und prüfbar. Schwache Fehlererkennung, Stop-and-Wait-Verzögerung und fehlende Metadaten blieben sichtbar, sodass Nachfolger sie erweitern konnten, ohne einen zentralen Dienst zum Besitzer der Kompatibilität zu machen.

Das gemeinsame Minimum passt in eine Zeile

Ein XMODEM-Block lässt sich knapp notieren: SOH, Blocknummer, Einerkomplement der Nummer, 128 Datenbytes, Prüfsumme. Die Nummer beginnt bei eins und steigt. Ihr Komplement hilft, einen beschädigten Kopf zu erkennen. Für die Daten werden die Bytewerte addiert; ein Übertrag wird verworfen.

Auch der Ablauf bleibt klein. Der Empfänger meldet mit NAK, dass er bereit ist. Der Sender überträgt den ersten Block. Stimmt die Prüfung, antwortet der Empfänger mit ACK, andernfalls fordert NAK die Wiederholung. Sind keine Daten mehr vorhanden, sendet die Gegenseite EOT und wartet auf die letzte Bestätigung.

Diese Regeln wählen keine Telefonnummer, keinen Dateinamen und kein Zielverzeichnis. Sie kennen weder Benutzerkonto noch Abrechnung, Oberfläche oder zentrale Registrierung. Die gemeinsame Zuständigkeit beginnt erst auf der bestehenden Verbindung und endet vor dem vollständigen Produkt. Sie erfasst genau das, was beide Programme bei der Interpretation derselben Bytes gleich tun müssen.

Die 128 Bytes waren kein für alle Netze optimierter Wert. Sie entsprachen dem CP/M-Diskettensektor in Christensens Arbeitsumgebung. Eine feste Größe vereinfachte Puffer und Code auf kleinen Rechnern. Dafür musste der letzte kurze Block aufgefüllt werden, und die exakte Dateilänge kam nicht aus dem ursprünglichen Block selbst.

Die Wiederholung, die keinen Inhalt verdoppelt

Ein beschädigtes ACK erzeugt eine interessante Unsicherheit. Der Datenblock kann korrekt angekommen sein, während nur die Antwort auf dem Rückweg verloren geht. Der Sender weiß das nicht und überträgt denselben Block erneut.

Der Empfänger akzeptiert deshalb nicht nur die erwartete nächste Nummer, sondern erkennt auch die unmittelbar vorherige. In diesem Fall bestätigt er erneut, hängt die 128 Bytes jedoch nicht ein zweites Mal an die Datei. Eine Nummer außerhalb dieser beiden Möglichkeiten deutet auf einen schwereren Synchronisationsverlust und kann zum Abbruch führen.

Wenig lokaler Zustand löst damit einen eng begrenzten Streitfall. Kein zentraler Protokolldienst muss festlegen, welche Kopie gültig ist. Beide Enden kennen die gleiche Reaktion auf Nummer und vorherigen Zustand. Zuverlässigkeit bedeutet hier nicht störungsfreie Leitung, sondern vorhersagbares Verhalten bei einer bestimmten Störung.

Christensen bezeichnete die Arbeit von 1977 später als improvisierte Lösung für einen persönlichen Bedarf. Dass sie früh fertig war und sofort in die Public Domain kam, habe ihren Aufstieg zum Standard begünstigt. Diese Rückschau beschreibt seine Absicht, beweist aber keine einzelne Ursache der Verbreitung. Die Umsetzungsökonomie ist dennoch greifbar: Ein kurzes Programm ließ sich kopieren, lesen, portieren und gegen ein zweites testen, ohne einen Netzbetreiber um Aufnahme zu bitten.

Ein RFC beobachtete den De-facto-Standard

XMODEM war kein von der IETF ausgearbeiteter Standard. RFC 916 schlug 1984 ein anderes zuverlässiges Protokoll für asynchrone Verbindungen vor. MODEM/XMODEM erschien im Anhang, weil es unter Mikrocomputern bereits verbreitet war. Erst kam die Praxis vieler Implementierungen, dann ihre Dokumentation im RFC.

Der Text hielt auch die Grenzen fest. Die Nutzdaten flossen in eine Richtung, die Paketgröße war auf 128 Oktette festgelegt, und manche Konzentratoren konnten selbst mit kleineren zusammenhängenden Eingaben Schwierigkeiten haben. Das Warten auf eine Bestätigung nach jedem Block kostet bei längerer Umlaufzeit Durchsatz. Die einfache Acht-Bit-Prüfsumme erkennt nicht jedes Fehlermuster.

Kleinheit machte diese Kompromisse nicht dauerhaft richtig. Sie machte ihren Ort sichtbar. Betreiber konnten Wiederholungen, Laufzeit, unerkannte Fehler und den letzten Block untersuchen. Werden Identität, Speicherung, Auffindbarkeit und Übertragung in einem großen Dienst verborgen, ist ein Austausch der fehlerhaften Schicht wesentlich schwerer.

Erweiterungen brauchten echte Gegenstellen

Spätere Konventionen ergänzten CRC-16, optionale 1K-Blöcke und einen Block null für Angaben wie Dateiname und Größe. Öffentlich verbreitete Programme von Chuck Forsberg halfen, diese Fähigkeiten unter Bezeichnungen wie YMODEM zu etablieren. Der bekannte XMODEM-Boden erlaubte schrittweise Ergänzungen.

Christensen wollte den Kern nicht unmittelbar zu Vollduplex, mehreren unbestätigten Blöcken oder mehreren Zielen ausbauen. Das war kein Verbot anspruchsvollerer Übertragung. Er sah in der extremen Einfachheit einen Grund, weshalb das Verfahren auf so vielen Maschinen und in so vielen Programmen überlebt hatte. Eine Neuerung, die sämtliche installierten Partner auf einmal für ungültig erklärt, verändert zugleich die Macht über die gemeinsame Basis.

Freiwillige Übernahme verhinderte allerdings kein Durcheinander. Historische Referenzen warnen vor Produkten, die denselben Namen YMODEM für unterschiedliches Verhalten verwendeten. Ein Etikett bewies keine Kompatibilität. Dafür brauchte es Vorschlag, lauffähigen Code, Testdateien, begrenzten Einsatz, beobachtete Fehler, Fähigkeitskennzeichen und eine Beschreibung, die dem tatsächlichen Verhalten folgte.

CBBS war Umgebung, nicht Blockinhalt

Nach dem Schneesturm von Chicago 1978 entwickelten Christensen und Randy Suess gemeinsam CBBS. Suess stellte die Hardware, Christensen schrieb die Software. Das System nahm Anrufe an, speicherte Nachrichten und wurde zu einem sozialen Ort. Diese Geschichte erklärt die Einwahlwelt rund um XMODEM, gehört aber nicht in dessen Blockformat.

Das BBS war ein Dienst, XMODEM eine schmale Passage für eine Datei. Weil beides getrennt blieb, konnten unterschiedliche Mailboxen, Terminalprogramme und lokale Abläufe die Übertragung übernehmen, ohne Clients einer einzigen Plattform zu werden. Die Drahtvereinbarung war gemeinsam, das Produkt nicht.

Der Wert des Erbes liegt daher nicht in der Zahl 128. Entscheidend ist die Grenzziehung: Wo Interoperabilität Gleichheit verlangt, gilt eine strenge Regel; wo sie keine Gleichheit braucht, bleibt die Entscheidung lokal. Die Enden waren an Reihenfolge, Prüfung und Abschluss gebunden. Sie mussten darüber hinaus jedoch nicht gleich aussehen.

Quellen