Zusammenfassung

  • RDP wollte alle Nachrichten zuverlässig zustellen, verlangte aber keine stets geordnete Übergabe an die Anwendung; der Modus wurde beim Open für die Verbindung festgelegt.
  • Das kumulative ACK markierte die geschlossene Folge, EACK nannte korrekt empfangene spätere Segmente und begrenzte die Wiederholung auf die Lücke.
  • Transportannahme, Übergabe in den Nutzerpuffer und Anwendungswirkung blieben getrennte Beweise; RST, NUL und IANA-Protokollnummer 27 änderten daran nichts.

Die linke Kante blieb ehrlich

Nach den Segmenten 100, 101, 102 und 103 geht 101 verloren. 102 und 103 kommen mit gültiger Prüfsumme an. Die kumulative Empfangskante darf nicht über 100 hinausgehen. Würde sie 103 melden, verschwände die Lücke nur in der Buchführung.

RFC 908 ergänzte deshalb EACK. Das normale ACK bezeichnete das letzte korrekt und in Reihenfolge empfangene Segment. EACK führte die Nummern korrekt empfangener, aber vorgezogener Segmente auf. Der Sender konnte 101 erneut senden, ohne 102 und 103 ebenfalls zu wiederholen.

Diese Selektivität löste die Flussgrenze nicht auf. Die linke Fensterkante blieb am fehlenden Segment. Weitere bestätigte Inseln näherten sich der rechten Kante; dort musste neuer Versand warten, bis die Lücke geschlossen war. EACK sparte Bandbreite und Arbeit, ohne aus Teilbesitz einen vollständigen Verlauf zu machen.

Zwei Anwendungen, zwei Ordnungsbedürfnisse

RDP zielte auf Remote Loading, Speicherauszüge und Debugging. Eine Speicherabbildung darf keinen dauerhaften Block verlieren. Sequenznummer, Prüfsumme, positive Bestätigung und erneute Übertragung waren deshalb gemeinsame Mindestfunktionen.

Die Sichtreihenfolge war nicht in jedem Fall gemeinsam. Ein Block mit eigener Zieladresse kann sofort abgelegt werden. Ein Debug-Befehl kann dagegen vom vorherigen Befehl abhängen. „Breakpoint setzen“ und „fortsetzen“ dürfen ihre Reihenfolge nicht tauschen.

RDP ließ die Anwendung diese Grenze beim Open angeben. Im nicht sequenzierten Modus durfte der Empfänger ein vorgezogenes Segment nach gültiger Annahme in den Nutzerpuffer kopieren. Im sequenzierten Modus konnte er dasselbe Segment per EACK bestätigen, hielt es aber bis zum Schließen der Lücke zurück.

Damit wurden Bestätigung und Übergabe unabhängig. EACK sagt, was der Transport besitzt. Der beim Aufbau gewählte Modus sagt, wann die Anwendung es sehen darf.

Der SYN schuf einen Deutungszeitraum

Der Zustellmodus blieb über die gesamte Verbindung konstant. Im SYN standen außerdem anfängliche Sequenznummer, maximale Zahl ausstehender Segmente, maximale Segmentgröße und die Optionsbits einschließlich sequenzierter Zustellung.

Wer nur die Mitte einer Verbindung mitschneidet, kennt daher nicht die volle Bedeutung eines EACK. Ohne den SYN ist unklar, ob ein vorgezogenes Segment bereits an die Anwendung ging oder intern wartete. Der Verbindungsaufbau ist Teil des Beweises, nicht nur dessen Vorbereitung.

Die Puffergrenzen kamen von den Endpunkten selbst. Jeder Empfänger nannte seine Kapazität, der gemeinsame Mechanismus machte ihre Einhaltung überprüfbar. Er erhob keine einzelne Fenstergröße zur universellen Leistungspolitik. Lokal blieb, was nur der Betreiber der jeweiligen Ressource beurteilen konnte.

Ein lebender Transport ist keine lebende Anwendung

RDP unterschied CLOSED, LISTEN, SYN-SENT, SYN-RCVD, OPEN und CLOSE-WAIT. Auch gleichzeitig gesendete SYNs konnten eine Verbindung bilden, ohne die anfänglichen Sequenzidentitäten zu verlieren.

Ein NUL-Segment half bei manchen halb offenen Zuständen. Es verbrauchte die nächste Sequenznummer; ein ACK zeigte, dass das entfernte RDP die Verbindung noch erkannte. Es zeigte nicht, dass der Loader arbeitsfähig war oder ein Debug-Auftrag Wirkung hatte.

Beim Schließen sendete RDP RST, wartete in CLOSE-WAIT und verwarf schließlich den Verbindungsdatensatz. RFC 908 verlangte vom Nutzer, vor dem Close festzustellen, dass die benötigten Daten zuverlässig zugestellt waren. Der Transport erzeugte aus seinem Ende keinen Abschlussbeleg der Anwendung.

Auch die Prüfsumme bleibt eng. Sie stützt eine Aussage über einen empfangenen Abschnitt unter dem festgelegten Algorithmus. Sie authentisiert weder den Partner noch seine Absicht.

Version 2 war eine Antwort auf Messung

RFC 1151 berichtete 1990 über Probleme aus Versuchen von 1986 und 1987. Die nichtlineare 32-Bit-Prüfsumme der ersten Version hing überraschend stark von der Datendarstellung des Hosts ab. Optimierte Implementierungen auf vergleichbarer Hardware unterschieden sich im Aufwand um den Faktor fünf. Version 2 wechselte zur 16-Bit-TCP-Prüfsumme.

Die internen Ports wuchsen von acht auf sechzehn Bit. Wegen der geänderten Headerfelder stieg die Versionsnummer. Außerdem korrigierte RFC 1151 SND.UNA: Nach der Bestätigung von SEG.ACK musste der älteste unbestätigte Wert SEG.ACK + 1 sein.

Die Veröffentlichung beweist keine flächendeckende Umstellung. Das Dokument selbst nennt begrenzte Implementierungsnachfrage als Grund gegen eine vollständige Neufassung. Es belegt, dass Experimente die Spezifikation veränderten, nicht welche Systeme die Änderung ausführten.

Im IANA-Register der Protokollnummern steht RDP weiterhin bei 27. Der Eintrag bewahrt eine eindeutige Zuordnung. Er beweist weder Verkehr noch Version, Implementierung, EACK-Unterstützung oder Produktkonformität.

Zuverlässigkeit braucht einen Nachsatz

RDP fragt: Sind alle Nachrichten schließlich vorhanden? Welche späteren Segmente sind schon da? Wann darf die Anwendung sie sehen? Hat die Anwendung ihr Ziel erreicht? Erst diese Trennung macht „zuverlässig“ prüfbar.

Die Reihenfolge wird nicht geringgeschätzt. Sie wird dort entschieden, wo ihre semantische Wirkung bekannt ist.

Quellen