Zusammenfassung

  • URG eröffnet keinen Nebenkanal. Es macht einen Offset im normalen Sequenzraum gültig und meldet einen Zustand bis zu dieser Grenze.
  • Telnet verband die Meldung mit einem DATA MARK im Strom; FTP nutzte dieselbe Folge für ABOR. Aufmerksamkeit kam von TCP, Bedeutung von der Anwendung.
  • Die LAST-Korrektur setzte sich im verbreiteten Code nicht durch. RFC 6093 übernahm dessen LAST+1-Konvention, untersagte aber neue architektonische Abhängigkeit.

Dringend, aber nicht schneller

Nach RFC 793 wird das 16-Bit-Feld nur bei gesetztem URG interpretiert. Zusammen mit der Segmentsequenz ergibt es den Urgent Pointer. Solange dieser vor dem Verbrauchsstand liegt, meldet TCP der Anwendung den Urgent-Modus.

Die Bytes bleiben geordnet. Verschiebt sich die Grenze im laufenden Modus, muss kein neues sichtbares Ereignis entstehen. Eine Meldung ist daher weder eigener Datensatz noch sicherer Zähler.

Telnet hielt den Beweis im Strom

RFC 854 koppelte die TCP-Meldung an DATA MARK. Das Ereignis weckte die Sonderbehandlung; die im Strom gelesene Marke beendete sie. Mehrere Synch-Signale konnten zusammenfallen.

RFC 959 schlug für FTP während einer Übertragung Interrupt Process, Synch und danach ABOR oder STAT vor. TCP entschied nicht über den Abbruch. Es half dem Interpreter, den folgenden Befehl zu beachten.

Zwei Enden in einem Standard

Die Headerbeschreibung von RFC 793 zeigt auf das Byte nach den dringenden Daten, während SEND SND.NXT-1 verwendet. RFC 1011 erklärte die erste Aussage für falsch. RFC 1122 verlangte LAST statt LAST+1 und beliebig lange dringende Folgen.

Die veröffentlichte Reparatur bewegte jedoch nicht die Grenze in bereits ausgelieferten Kerneln.

Das ausgelagerte Einzelbyte

RFC 6093 fand bei fast allen getesteten verbreiteten Implementierungen die ursprüngliche Byte-danach-Deutung. Viele Socket-APIs nahmen standardmäßig das letzte dringende Byte aus normalen Leseaufrufen und lieferten es über MSG_OOB.

So wirkte ein In-Band-Zustand wie Out-of-Band-Daten. Der Ein-Byte-Speicher konnte durch die nächste Meldung überschrieben werden. SO_OOBINLINE änderte die lokale Übergabe, nicht den gesamten Pfad.

Ein Gerät konnte das Klingeln abschalten

Einige Middleboxes löschten URG und setzten den Zeiger auf null. Die Daten blieben inline, die erwartete Benachrichtigung verschwand. Endpunkt und Inspektor konnten dadurch verschiedene Anwendungsströme rekonstruieren.

RFC 6093 stellte die implementierte Konvention wieder her, verpflichtete TCP zur Altunterstützung und riet neuen Anwendungen vom Mechanismus ab. Verbleibende Nutzer sollten inline lesen und ohne URG korrekt bleiben. RFC 9293 hält diese Trennung aufrecht.

Quellen und Beweisgrenzen

Die RFCs belegen Entwurf, Textkonflikt, Anwendungsfälle und untersuchte Praxis. Sie belegen keine weltweite Einheitlichkeit. URG schafft weder Netzpriorität noch Authentisierung oder eine garantierte Nebenleitung.

Kompatibilität blieb; die Befugnis, neue Korrektheit zu tragen, ging verloren.