Zusammenfassung

  • RFC 1080 erlaubte einem Telnet-Prozess, beim anderen Software-Flusssteuerung ein- oder auszuschalten, aber erst nach einer begrenzten DO/WILL-Vereinbarung.
  • Die Option betraf den lokalen Ausgabepfad vom Benutzer-Telnet zum angeschlossenen Terminal. Sie pausierte weder TCP noch die entfernte Anwendung und bestätigte keinen angewandten Treiberzustand.
  • Die Vereinbarung erzwang einen bekannten aktivierten Anfangszustand; nach dem Widerruf konnten keine Befehle mehr folgen und eine implementierungseigene Voreinstellung zurückkehren.

Ein Zeichen konnte Steuerung oder Eingabe sein

Die NVT-Tastatur aus RFC 854 konnte alle 128 US-ASCII-Codes erzeugen. Ein entfernter Editor durfte Control-S oder Control-Q daher als gewöhnliche, bedeutungsvolle Eingabe behandeln.

Software-Flusssteuerung fing dieselben Werte lokal ab. XOFF, meist Control-S, stoppte die Ausgabe; XON, meist Control-Q, setzte sie fort. Der Terminaltreiber verbrauchte das Zeichen, bevor es das Serverprogramm erreichte.

Bei einem vollen Puffer oder zu schneller Anzeige war das nützlich. Für einen Editorbefehl war es Datenverlust. Nicht der Bytewert allein, sondern Ort und Zustand der Interpretation entschieden.

RFC 1080 veröffentlichte im November 1988 Option 33, TOGGLE-FLOW-CONTROL. Sie übertrug keine Terminalhoheit, sondern eröffnete einen engen Kanal für Zustandswünsche.

Ohne Einwilligung gab es keinen Modusbefehl

RFC 855 teilte komplexe Optionen in Zustimmung und anschließende Subnegotiation. Typischerweise sandte der Host DO, das am Terminal sitzende Benutzer-Telnet antwortete WILL.

DO erklärte die Bereitschaft, Ein- und Ausschaltwünsche zu senden. WILL nahm die Rolle an, sie lokal umzusetzen. DONT und WONT lehnten diese Rollen ab, meldeten aber keinen aktuellen Zustand. Ein Client konnte Fernsteuerung verweigern und trotzdem nach eigener Vorgabe XON/XOFF verwenden.

Vor dem vollständigen Austausch waren ON und OFF unzulässig. Nach einem Widerruf ebenfalls. Ein eintreffender Befehl konnte seine eigene Berechtigung nicht gleich mit erzeugen.

Die Option war zwar in beiden Richtungen möglich, normalerweise aber asymmetrisch. Die entfernte Anwendung kannte ihren Bedarf an wörtlichen Zeichen; der lokale Client beherrschte den Weg zum Terminal.

Zustimmung setzte einen bekannten Ausgangspunkt

Nach DO/WILL durfte der DO-Sender ON oder OFF anfordern. Gemeint war die Behandlung der Ausgabe zwischen Benutzer-Telnet und Terminal, nicht das TCP-Empfangsfenster, ein Router oder die entfernte Programmausführung.

RFC 1080 verlangte unmittelbar nach der Vereinbarung aktivierte Flusssteuerung beim WILL-Sender. Die Option begann daher nicht in einem unbekannten Zustand; die Zustimmung selbst definierte den Start.

Für spätere Wünsche gab es jedoch keine Zustandsbestätigung. Ein Mitschnitt beweist, dass ein gültiges OFF gesendet wurde. Er beweist weder die Anwendung im Treiber noch das Anhalten der Anzeige oder die Zustellung des Zeichens.

Unbekannte Subcodes wurden ignoriert. Das schützte ältere Implementierungen, machte Schweigen aber ungeeignet als Fähigkeitsnachweis.

Widerruf bedeutete Rückkehr lokaler Politik

Beide Seiten konnten mit DONT oder WONT die Option beenden. Bis zu einer neuen Vereinbarung waren weitere Subnegotiationen verboten.

Der letzte Wunsch musste nicht bestehen bleiben. Der Zustand durfte auf eine implementierungsdefinierte Voreinstellung zurückfallen. Ein Register, das nur den zuletzt gesehenen Schalter speichert, irrt daher nach Widerruf, Neuverbindung oder Neustart.

Die entfernte Befugnis war an eine aktive Sitzungsvereinbarung gebunden. Ihr Ende schrieb den letzten Wunsch nicht dauerhaft in das fremde System, sondern gab die Entscheidung an den lokalen Besitzer zurück.

Bildschirmfluss war kein TCP-Fluss

RFC 1080 umfasste nur Ausgabe vom Benutzer-Telnet zum angeschlossenen Terminal. Die Eingaberichtung konnte anders arbeiten. Hardware-Flusssteuerung nutzte eigene Signale und musste keine Zeichen reservieren.

Auch Staukontrolle war nicht gemeint. Der Server konnte weiter rechnen, TCP weiter Daten aufnehmen, Puffer weiter wachsen. Ein stehender Bildschirm ist keine stehende Netzverbindung.

Jede Aussage braucht deshalb Richtung und Messpunkt. Tastendruck, im Treiber verbrauchtes XOFF, übertragenes OFF und sichtbare Pause sind vier getrennte Tatsachen.

Linemode ordnete benachbarte lokale Arbeit

RFC 1184 verlegte Zeilenbearbeitung und Signalverarbeitung zum Client. Auf Pfaden mit hoher Latenz konnte der Benutzer lokal tippen und erst eine fertige Zeile senden.

Obwohl Flusssteuerung nahe lag, beließ RFC 1184 sie in der separaten Option. Eine neue Modemaske sollte den bestehenden Automaten nicht stillschweigend umdeuten.

Für Beweise bleiben Tastatur, Treiber, Telnet-Client und Serveranwendung getrennt. An jeder Grenze kann das Zeichen verschwinden oder seine Form ändern.

RFC 1372 ergänzte einen nicht bestätigbaren Wunsch

RFC 1372 ersetzte RFC 1080 im Jahr 1992 und ergänzte RESTART-XON sowie RESTART-ANY. Entweder durfte nur XON oder jedes Zeichen außer einem weiteren XOFF die Ausgabe fortsetzen.

Der aktivierte Fluss blieb nach der Zustimmung bekannt. Die Wiederanlaufregel begann dagegen systemabhängig, weshalb der Server seine Präferenz senden sollte.

Ein Client ohne beide Fähigkeiten durfte den Wunsch ignorieren. Das Protokoll bot keine Nachricht, die den Server darüber informierte. Gesendete Absicht und lokale Fähigkeit blieben auseinander.

Viele Treiber verschluckten XON und XOFF. Bei Wiederanlauf durch beliebige Zeichen konnte ein normales Zeichen die Ausgabe öffnen und anschließend zur Anwendung weiterlaufen. Fortsetzung und Zustellung waren verschiedene Ergebnisse.

Serielle Schnittstelle und Sitzung waren andere Flächen

RFC 2217 definierte später serielle Flussmodi und FLOWCONTROL-SUSPEND/RESUME für Daten und Befehle einer Telnet-Sitzung.

Geräteeinstellung, Sitzungssperre und lokale XON/XOFF-Auswertung betreffen unterschiedliche Gegenstände. Ihr gemeinsamer Name ersetzt keine Beweiskette.

Die IANA-Liste der Telnet-Optionen führt Nummer 33 weiterhin als Remote Flow Control mit RFC 1372. Das ist Koordinationskontinuität, kein heutiger Einsatznachweis.

Fünf Belege statt eines Modusfeldes

Zu trennen sind Sitzungszustimmung, gesendeter Wunsch, lokal angewandter Zustand, Behandlung eines konkreten Zeichens und die beobachtete Wirkung auf Anzeige und Anwendung.

RFC 1080 standardisierte die ersten beiden Ebenen und den Anfangszustand. Die übrigen brauchen lokale oder Ende-zu-Ende-Beobachtung.

Der historische Wert liegt in der begrenzten, widerrufbaren Delegation. Control-S war nur so lange Befehl, wie Vereinbarung und lokaler Mechanismus diese Bedeutung gemeinsam trugen.

Quellen und Grenzen

RFC 854 liefert den NVT-Rahmen, RFC 855 die Zustimmung, RFC 1080 die Ursprungsoption, RFC 1184 Linemode, RFC 1372 den Wiederanlauf, RFC 2217 serielle und Sitzungssteuerung, IANA den Registereintrag. Sie belegen keine heutige Verbreitung, Identität, allgemeine Autorisierung, angewandte Treiberlage, reale Störung oder Nutzerwirkung.