Zusammenfassung

  • Das SO-Flag in RFC 916 erklärte die Nutzlast zu genau einem Oktett. Das dadurch überflüssige LENGTH-Feld trug das Zeichen selbst; die Header-Prüfsumme schützte es, und ein eigener Datenteil entfiel.
  • Dieselbe physische Position war in SYN die Maximum Data Length des Empfängers, in einem gewöhnlichen Paket die Datenlänge und bei SO das Datum selbst. Gültige Flags und Verbindungszustand erteilten die Auslegungserlaubnis.
  • Je ein Bit für Sequenz und Bestätigung reichte nur unter der Regel, dass pro Richtung höchstens ein antwortpflichtiges Paket ausstand. Der kleine Zustand war zugleich eine Durchsatzgrenze.

RFC 916 veröffentlichte im Oktober 1984 den Vorschlag für das Reliable Asynchronous Transfer Protocol, RATP. Es sollte über eine vollduplexe Punkt-zu-Punkt-Verbindung laufen, meist über asynchrones RS-232 zwischen kleinen Rechnern, Modems oder Geräten, die Befehle annahmen. Der heutige Eintrag des RFC Editors führt das Dokument als Historic. Dieser Archivstatus sagt nicht, wie viele Implementierungen einst liefen.

Die Entwurfsreihenfolge war ausdrücklich: zuerst Zuverlässigkeit, dann einfache Implementierung. Dynamische Fenster und mehrere gleichzeitig ausstehende Pakete wurden weggelassen. Schloss die Gegenseite, wurden noch nicht gesendete Warteschlangendaten verworfen; dadurch entfielen laut Dokument zwei Zustände. RATP war kein verkleinertes TCP mit denselben Ansprüchen. Der engere Auftrag erlaubte einen engeren Automaten.

Das einzelne ausstehende Paket kam vor dem einzelnen Bit

Die Felder SN und AN waren jeweils ein Bit breit. Der Empfänger erwartete den nächsten Wert modulo zwei. Kam stattdessen der andere, konnte er das Paket als Wiederholung eines bereits angenommenen Pakets erkennen — vermutlich erneut gesendet, weil die vorherige Bestätigung verloren gegangen war. Die doppelten Daten wurden verworfen, die passende Bestätigung konnte wiederholt werden.

Der Sender las aus AN, dass sein einziges antwortpflichtiges Paket angekommen war, entfernte es aus der Wiederholungswarteschlange und kippte das Bit. Es gab kein zweites unbestätigtes Paket, das dieselbe kurze Nummer tragen und die Entscheidung zweideutig machen konnte.

Beide Richtungen arbeiteten trotzdem unabhängig. War das letzte relevante Paket von A bestätigt, durfte A wieder senden, ohne auf Nutzdaten von B zu warten. Musste A zugleich B bestätigen, konnten Bestätigung und eigene Daten in einem Paket zusammenfallen. Eine reine Bestätigung verlangte keine weitere Bestätigung, sonst hätte der Austausch der Quittungen kein Ende.

Die Vereinfachung enthielt ihre Leistungsgrenze. Während einer Umlaufzeit konnte der Sender nicht mehrere Pakete auf den Weg bringen. Auf einer langsamen interaktiven Leitung mit knappem Speicher sparte das Puffer, Zustände und komplizierte Duplikatlogik. Auf einem Pfad mit großem Bandbreiten-Laufzeit-Produkt begrenzte es die Auslastung. Das Ein-Bit-Feld kann nicht von der Ein-Paket-Regel getrennt bewertet werden.

Sieben Oktette um ein Zeichen

Ein normaler RATP-Header bestand aus vier Oktetten: dem hexadezimalen Synchronisationsführer 01, einem Steueroktett, einem Datenlängenoktett und einer Header-Prüfsumme. Gewöhnliche Daten folgten und endeten mit einer 16-Bit-Datenprüfsumme.

Bei interaktiver Eingabe wäre das Sammeln mehrerer Zeichen zwar effizienter, hätte aber die Reaktion verzögert. Ein sofort gesendetes Zeichen kostete im normalen Format sieben Oktette: vier Header, ein Datum und zwei Datenprüfsumme.

Das SO-Flag, Single Octet, definierte genau diesen Sonderfall. War SO gesetzt und waren SYN, RST sowie FIN nicht gesetzt, stand die Länge eins bereits fest. Eine eins im Längenfeld wäre Wiederholung gewesen. RFC 916 legte deshalb das Zeichen in die Position LENGTH, ließ Datenteil und Datenprüfsumme fort und bezog das Zeichen in die Header-Prüfsumme ein. Das Dokument bezeichnete die Verringerung von sieben auf vier Oktette als Effizienzgewinn von 40 Prozent.

Das war keine allgemeine Kompression. Die Flag-Information ersetzte die Länge, die freie Position trug das Datum, und die Header-Prüfsumme übernahm dessen begrenzte Fehlererkennung. Für zwei Zeichen galt die Abkürzung nicht. Auch Bestätigung und Verbindungszustand blieben notwendig.

Derselbe Platz hatte drei Verträge

In einem SYN enthielt die dritte Headerposition die Maximum Data Length, MDL. Der Absender des SYN teilte mit, wie viele Datenoktette er in einem einzelnen eingehenden Paket höchstens verarbeiten wollte. Im Drei-Wege-Verbindungsaufbau erklärte jede Seite ihre eigene Grenze.

Nach dem Aufbau, ohne SYN, RST und FIN, hieß die Position LENGTH. Ohne SO zählte sie die nachfolgenden Daten von null bis zur MDL des Peers. Mit SO war sie keine Zahl, sondern das eine Datenoktett.

Ein isolierter Wert konnte seine Bedeutung nicht mitteilen. Erst musste der Empfänger die Synchronisation finden, Steuerung, Position und Header-Prüfsumme validieren und die Flagkombination im aktuellen Zustand annehmen. Dann konnte aus demselben Oktett Kapazität, Länge oder Inhalt werden. Eine Aufzeichnung ohne Verbindungsepoche behält unter Umständen die Bytes und verliert deren Grammatik.

Die MDL war zudem durchsetzbar. Deklarierte ein prüfsummenrichtiger gewöhnlicher Header mehr Daten als die lokale Grenze, wertete RFC 916 das als Protokollverletzung oder als unwahrscheinlichen unentdeckten Längenfehler. Der Empfänger setzte die Verbindung zurück. Die Grenze war keine Empfehlung, sondern lokale Zulassung mit gemeinsam definiertem Ergebnis.

Eine Seite durfte MDL null ankündigen, wenn sie keine Daten empfangen wollte; das ließ Einwegverkehr zu. Sollten Daten fließen, konnten nicht beide Seiten null wählen. Das Protokoll bestimmte Darstellung und Verstoß. Die konkrete Kapazität blieb bei der Maschine, die sie bereitstellen musste.

Die Größe war endlich und vom Empfänger gewählt

Die MDL war auf 255 begrenzt. Das größte gewöhnliche Paket umfasste daher 261 Oktette: Synchronisation, restlichen Header, zwei Oktette Datenprüfsumme und 255 Datenoktette. Aus dieser Grenze leitete die Spezifikation ab, dass ein Empfänger für ein einzelnes Paket nie mehr Speicher reservieren musste.

Der praktische Wert durfte niedriger sein. Betriebssystem, Treiber, Speicher, Baudrate und auf dem Weg eingefügte Flusssteuerzeichen konnten die Wahl beeinflussen. Erwartete eine Implementierung, dass lange Bursts externe Flusssteuerung auslösen, sollte sie eine kleinere Grenze wählen, damit wenigstens manche Pakete ohne Eingriff ankamen.

Die gemeinsame Schicht regelte damit nur, was gemeinsam sein musste: Darstellung der Grenze und Verhalten bei Überschreitung. Sie bestimmte weder Speicherausbau noch Anwendung. Jeder Teilnehmer entschied lokal und gab dem Peer eine prüfbare Zahl.

Paketende und Satzende blieben getrennt

RATP benutzte ein Startmuster, aber kein entsprechendes Endzeichen. Beliebige Muster durften in den Daten vorkommen. Nach gültigem Header berechnete die interpretierte Länge, wo das Paket endete.

Eine Einheit der höheren Schicht konnte größer als die MDL sein und fragmentiert werden. Das Flag EOR meldete, dass in diesem Paket ein höherer Datensatz endete. Die höhere Schicht war für das Setzen verantwortlich. Ein vollständig empfangenes und bestätigtes Paket konnte also nur ein Fragment eines noch unvollständigen Objekts sein.

Die Beweiskette darf keine Ebene überspringen. Die Header-Prüfsumme stützt eine begrenzte Aussage über den Header. Eine Bestätigung belegt die Annahme im RATP-Zustand. EOR hilft beim Zusammensetzen. Nichts davon authentifiziert einen Benutzer, berechtigt einen Befehl, verschlüsselt das Zeichen oder beweist den Anwendungserfolg.

Rauschen erforderte eine eigene Rückkehrregel

RS-232 rahmte einzelne Oktette, nicht komplette RATP-Pakete. Der Empfänger suchte 01, las die nächsten drei Oktette und prüfte sie. Schlug die Header-Prüfung fehl, wurden diese drei wieder als neue Eingabe der Synchronisationssuche behandelt. Ein falscher Beginn erlaubte nicht, eine unbekannte Menge zu überspringen.

Später dokumentierte RFC 1055 den anderen Zuschnitt von SLIP: Begrenzungs- und Escapezeichen für IP-Datagramme, aber kein Typfeld, kein vom Grundtext definierter Maximalwert und keine Fehlerkorrektur auf der seriellen Schicht. RFC 1661 und RFC 1662 beschrieben danach PPP mit Protokollmultiplex, LCP, verhandelbaren Grenzen, Flag-Rahmung, Transparenz und FCS. Das sind Vergleiche, kein belegter Stammbaum.

Die zeitgenössische Referenz, die RFC 916 beim Verzicht auf dynamische Fenster selbst nennt, ist TCP in RFC 793. TCP regelte einen breiteren zuverlässigen Strom über verbundene Netze. RATP vereinte Paket- und zuverlässige Verbindungsfunktionen auf einem Punkt-zu-Punkt-Link. Ähnliche Begriffe verleihen nicht dieselben Garantien.

Diese Primärquellen zählen keine RATP-Installationen und sagen nichts über heutige Produkte. Eine Prüfsumme ist weder Signatur noch Verschlüsselung. Der historische Befund ist schmal und überprüfbar: Vier Oktette genügten, weil beide Enden strenge gemeinsame Zustände über Empfangsgrenze, Folge und das einzige noch offene Paket führten.