Zusammenfassung

  • TCP lieferte einen zuverlässigen geordneten Bytestrom, aber keine Grenzen für CALL und REPLY; ONC RPC legte jede Nachricht in einen Datensatz aus einem oder mehreren Fragmenten.
  • Vor jedem Fragment stand ein vier Byte großer Big-Endian-Marker: Die unteren 31 Bits nannten die Fragmentlänge, das oberste Bit schloss den Datensatz nach diesen Daten.
  • Ein vollständiger Datensatz bewies Framing, nicht Wahrheit: XDR, XID, Authentisierung, Autorisierung, Ergebnis und dauerhafte Wirkung blieben getrennte Prüfungen.

Der Empfänger musste unvollständige Gewissheit aushalten

Eine Socket-Lesung liefert drei Byte. Der Parser darf daraus weder einen beschädigten Marker noch eine kurze Nachricht machen. Er besitzt lediglich drei Viertel eines möglichen Vier-Byte-Headers und wartet auf den Rest. Die nächste Lesung kann danach mehrere vollständige Datensätze bringen.

RFC 793 definierte TCP als geordneten Oktettstrom und erklärte, dass PUSH keine Datensatzgrenze bereitstellt. RFC 9293 beschreibt weiterhin einen zuverlässigen, geordneten Bytestrom. Segment- und API-Grenzen sind lokale Verpackung, keine RPC-Syntax.

Für den entfernten Prozeduraufruf musste trotzdem feststehen, wo ein kodierter CALL oder eine REPLY endet. Diese Bedeutung lag oberhalb des Transports und brauchte eine eigene überprüfbare Regel.

Der höchste Platz entschied, die übrigen zählten

RFC 1050 veröffentlichte record marking im April 1988. Eine RPC-Nachricht passte in einen RM-Datensatz, der aus einem oder mehreren Fragmenten bestand. RFC 1057 ersetzte den Text im Juni mit unverändertem Format.

Jedes Fragment beginnt mit einem vorzeichenlosen Vier-Byte-Wort in höchstwertiger Byte-Reihenfolge. Die unteren 31 Bits geben null bis 2^31 - 1 folgende Datenbytes an. Das oberste Bit ist boolesch: Eins bezeichnet das letzte Fragment des Datensatzes, Null kündigt ein weiteres Fragment desselben Datensatzes an.

Das Endbit wirkt erst hinter dem angegebenen Körper. Ein Parser, der bei Eins sofort schließt, verwechselt Header und Ende. Umgekehrt beendet die erfüllte Länge bei Null nur das Fragment; das nächste Vier-Byte-Wort gehört noch zum laufenden Datensatz.

Zustand rekonstruierte, was Pakete nicht bewahrten

Der Empfänger sammelt zuerst vier Markerbytes, trennt Bit und Länge und verbraucht anschließend genau die angegebene Datenmenge. Dabei dürfen beliebig viele TCP-Lesungen beteiligt sein. Die Daten bleiben im Kontext des aktuellen Datensatzes.

Bei Null beginnt die Markerphase erneut. Bei Eins bilden die angesammelten Fragmente eine vollständige RPC-Nachricht; verbleibende Bytes beginnen den nächsten Datensatz. Derselbe Automat verarbeitet einen geteilten Marker ebenso wie mehrere Nachrichten in einem Buffer.

Auch ein Fragment der Länge null liegt im definierten Bereich. Sein Bit kann fortsetzen oder schließen. Bricht die Verbindung jedoch mitten im deklarierten Körper ab, ist das Fragment unvollständig. Daraus folgt nichts darüber, ob eine entfernte Prozedur bereits eine Wirkung erzeugte.

Ein RM-Fragment war kein Netzfragment

RM fragment, IP fragment und TCP segment bezeichnen verschiedene Schichten. Das RM-Fragment stimmt auch nicht zwingend mit einem Anwendungs-Write oder einem XDR-Feld überein. Es kann mehrere TCP-Segmente überspannen; ein Segment kann mehrere Marker, Fragmente oder Datensätze enthalten.

Das oberste Bit ist folglich weder FIN noch PSH, Dateiende, Commit oder Erfolg. CALL und REPLY sind eigenständige RPC-Nachrichten mit eigenen Datensätzen. Ein formal geschlossener Datensatz kann ein unbekanntes Programm, ungültige Argumente oder abgewiesene Zugangsdaten enthalten.

PUSH und RM besitzen getrennte Ämter. PUSH kann das zügige Weiterschieben verfügbarer Bytes anstoßen. RM nennt die Zahl der Bytes in der aktuellen Einheit und sagt, ob danach die RPC-Nachricht abgeschlossen ist. Zeitplanung ist keine Grammatik.

Der Rahmen blieb absichtlich außerhalb von XDR

Innerhalb des Datensatzes verwendet RPC External Data Representation. RFC 4506 vereinheitlicht Zahlen, Längen, Padding und Typen für unterschiedliche Rechnerarchitekturen.

Die RPC-Dokumente erklären den Vier-Byte-Marker dennoch ausdrücklich zur Nicht-XDR-Standardform. Die Byte-Reihenfolge ähnelt einem XDR-Integer, doch der Parser braucht den Rahmen, bevor er die vollständige RPC-Struktur decodiert. Sonst müsste er den Inhalt verstehen, um dessen äußeres Ende zu finden.

Damit bleiben zwei Fehler sichtbar. Ein untragbarer Framing-Anspruch kann vor der Prozedurverarbeitung scheitern. Ein perfekt begrenzter Datensatz kann später wegen XDR oder RPC scheitern. Grenze und Gültigkeit sind nicht austauschbar.

31 Bits waren keine Kapazitätszusage

Die Länge gilt für ein Fragment, nicht für den gesamten Datensatz. Mehrere Fragmente können folgen; das Grundformat nennt keine einheitliche kumulative Obergrenze. Der theoretische Zahlenraum ist auch keine Aufforderung zur sofortigen Speicherreservierung. Eine solche Lesart gäbe dem Sender Kontrolle über lokale Ressourcen.

Empfänger benötigen eigene Budgets für kumulative Bytes, Fragmentzahl, gleichzeitigen Speicher und Zeit. Das ist eine betriebliche Folgerung zur sicheren Umsetzung, kein neuer RFC-Grenzwert. Messwerte und angewandtes Limit müssen getrennt dokumentiert werden.

Die Spezifikationen sagen, dass Abgrenzung Protokollfehler erkennen und möglicherweise beheben hilft. Sie definieren aber keine Suche nach dem nächsten plausiblen Marker im Payload. Jedes Vier-Byte-Muster kann Nutzdaten sein. Nach verlorener Ausrichtung ist ein Verbindungsabbruch oft ehrlicher als eine falsche Neuordnung.

Das Format blieb, bis ein anderer Transport es ersetzte

RFC 1831 übernahm das Format 1995. RFC 5531 löste ihn 2009 ohne Änderung auf dem Draht ab. Die Regel blieb stabil, weil sie nur die fehlende TCP-Grenze ergänzte.

RFC 8166 zeigt ihre Transportbindung. RPC-over-RDMA besitzt einen Transport- und einen Payload-Strom und ersetzt jedes andere RPC-Framing, einschließlich TCP record marking, selbst wenn RDMA über TCP arbeitet. Ein dynamischer Wechsel darf nur zwischen getrennten RPC-Nachrichten und gemeinsam mit dem Transport erfolgen.

RM war somit keine ewige Eigenschaft einer Prozedur, sondern der Adapter zwischen RPC-Nachrichten und einem Bytestrom.

Quellen und Reichweite

Der geschlossene Bestand umfasst RFC 793, RFC 1050, RFC 1057, RFC 1831, RFC 4506, RFC 5531, RFC 8166 und RFC 9293. Er belegt Format, Entwicklung und Schichtgrenzen, nicht heutige Verbreitung, Bibliothekskonformität, Identität, Berechtigung oder Ergebnis eines realen Aufrufs.

Das Endbit war verlässlich, weil es seine Behauptung begrenzte. Es gab beiden Seiten dieselbe Nachrichtengrenze, ohne die Arbeit darin für abgeschlossen zu erklären.