Datenflusssteuerung

Zweck und Einordnung

Datenflusssteuerung (englisch data flow control) umfasst Verfahren, die die Übertragung zwischen nicht synchron arbeitenden Endgeräten so regeln, dass Daten möglichst kontinuierlich und ohne Verluste übertragen werden. Sie ist nötig, wenn ein schneller Sender auf einen langsameren Empfänger trifft: Der Sender muss dann zeitweise angehalten werden, damit der Empfänger nicht mehr Daten erhält, als er verarbeiten kann.

Es gibt Flusssteuerung auf Protokollebene, Hardwareverfahren und Softwareverfahren. Hardwareverfahren übertragen Steuerinformationen über zusätzliche Schnittstellenleitungen; Softwareverfahren fügen Steuerinformationen in den Datenstrom ein und benötigen deshalb keine zusätzlichen Leitungen. Meist arbeiten mehrere Verfahren gleichzeitig. Bei einem PC mit Internetzugang über ein Modem kann etwa das Hardware-Handshaking zwischen PC und Modem die dortige Geschwindigkeit regeln, während die Internetprotokollfamilie auf höheren Ebenen weitere Mechanismen zur Geschwindigkeitsanpassung nutzt.

Dies ist erforderlich, weil nicht nur Sender und Empfänger unterschiedliche Datenraten haben können: Auch jeder Abschnitt des Übertragungswegs und die Komponenten eines Netzes arbeiten mit eigenen Geschwindigkeiten. Hardwareverfahren gehören im OSI-Modell zur Bitübertragungsschicht; Softwareverfahren können auch auf höheren Schichten eingesetzt werden.

Flusssteuerung in Netzwerkprotokollen

Auf Protokollebene ist die Flusssteuerung Bestandteil eines Netzwerkprotokolls. Sie liegt meist im Protokollstapel zwischen zwei OSI-Schichten oder zwischen gleichberechtigten Schichten auf Sender- und Empfängerseite, beispielsweise bei einem ARQ-Protokoll.

Die Verfahren nutzen Rückmeldungen: Der Empfänger quittiert Daten und signalisiert damit, ob der Sender weiter übertragen darf. TCP verwendet ein Sliding-Window-Protokoll. Ein „Window“ ist ein ganzes Fenster empfangener Daten, das gemeinsam quittiert wird. „Sliding“ bedeutet, dass die Fenstergröße im Steuerungsdialog vergrößert oder verkleinert werden kann. Der Empfänger gibt dabei an, wie viele Bytes er noch empfangen kann. Eine TCP-Verbindung kann ihren Datenfluss dadurch automatisch und dynamisch anpassen.

Andere Verfahren übertragen stets nur ein Paket und vergeben zusammen mit dessen Bestätigung die Erlaubnis für das nächste Paket. Dies sind Stop-and-Wait-Protokolle. HDLC verwendet zur Flusssteuerung die Blocktypen RR (Receive Ready) und RNR (Receive Not Ready).

Hardwaresteuerung bei Peripheriegeräten

Peripheriegeräte sind hier etwa Drucker, Modems und Terminals. Bei der Hardware-Flusssteuerung zeigen Signalpegel auf zugehörigen Schnittstellenleitungen an, ob Daten gesendet oder angenommen werden dürfen.

Bei der parallelen Centronics-Schnittstelle von Druckern dienen drei Leitungen der Flusssteuerung:

• Strobe meldet dem Empfänger, dass gültige Daten anliegen; es arbeitet mit positiver Logik, wie ACK.
• ACK (Acknowledge) bestätigt, dass der Drucker die Daten übernommen hat.
• Busy zeigt an, ob der Drucker bereit ist, Daten zu übernehmen; diese Leitung arbeitet mit negativer Logik.

Ein Drucker ist deutlich langsamer als die steuernde Endeinrichtung. Durch Deaktivieren von Busy wird das Senden weiterer Daten untersagt; die Übertragung hält kurzfristig an.

Serielle Schnittstellen und Leitungen

Für serielle Datenübertragung beschreiben die ITU-T-Empfehlung V.24, DIN 66020 und RS232 die notwendigen Schnittstellenleitungen. Sie beziehen sich auf eine lokale Endeinrichtung, beispielsweise einen PC, ein lokales Übertragungsgerät wie ein Modem, ein entferntes Übertragungsgerät und eine entfernte Endeinrichtung, etwa einen Internet-Server. Je nach Norm heißen die Leitungen unterschiedlich; verwendet werden die umgangssprachlichen Namen.

Ohne Flusssteuerung aktiviert die lokale Endeinrichtung zunächst DTR (Data terminal ready, Datenendgerät bereit) zum lokalen Modem und wartet auf DSR (Data set ready, Datenübertragungsgerät bereit). Damit besteht lokale Betriebsbereitschaft, während der Sender noch nicht aktiv ist. Soll die Endeinrichtung senden, setzt sie RTS (Request to send, Aufforderung zum Senden) und wartet auf CTS (Clear to send, Erlaubnis zum Senden erteilt). Schaltet das Modem seinen Sender ein, erkennt das entfernte Modem das Empfangssignal und meldet dies seiner Endeinrichtung über CD (Data channel received line signal detector), umgangssprachlich Carrier detected. In einem Nullmodem-Kabel sind diese logischen Abläufe fest verdrahtet; ein Nullmodem verbindet zwei Endeinrichtungen gleicher Übertragungsgeschwindigkeit.

Daneben gibt es RFR (Ready for receiving, Bereit zum Empfang). Wegen Platzmangels beim 25-poligen Stecker teilen sich RFR und RTS Pin 4, beim 9-poligen Stecker Pin 7. Entweder wird damit der Sender gesteuert oder bei konstantem Trägersignal der Empfänger. Halbduplex-Modems können deshalb nicht mit RFR gesteuert werden, weil dort der Sender gesteuert werden muss. Obwohl RTS und RFR oft gleichgesetzt werden, warnt die ITU-T in V.43 ausdrücklich davor. Die ITU-T-Empfehlung V.43 Data flow control (02/98), entsprechend dem ISO/IEC-Report 15294, sowie DIN 12900-1 von August 1998 unterscheiden beide Leitungen korrekt.

Bei RFR/CTS-Flusssteuerung schaltet das Übertragungsgerät CTS aus, sobald es keine weiteren Daten von der Endeinrichtung aufnehmen kann, und wieder ein, sobald dies möglich ist. Da die Endeinrichtung verzögert reagieren und noch Bytes senden kann, soll CTS vor dem vollständigen Füllen des Puffers deaktiviert werden; V.43 empfiehlt mindestens 2000 Bytes. Daten aus dem Puffer kann das Übertragungsgerät über TxD (Transmitted Data) weiterhin zum entfernten Gerät senden. Umgekehrt deaktiviert die Endeinrichtung RFR, wenn sie vorübergehend nicht empfangsbereit ist. Das Übertragungsgerät gibt Daten über RxD (Received Data) erst bei wieder aktivem RFR weiter. Hier empfiehlt V.43 nur einen kleinen Puffer, weil eine schnelle Reaktion des Übertragungsgeräts erwartet wird. Neuere Normen ersetzen bei Duplex-Modems RTS seit 1995 durch RFR, auch wenn Handbücher einfacher Modems häufig weiterhin RTS/CTS nennen.

DTR/DSR kann denselben Ablauf mit anderen Leitungen umsetzen. Dieser besonders bei Modems gebräuchliche Mechanismus ist nicht genormt. Selten werden außerdem die Übertragungsgeschwindigkeit über Schnittstelle 111 beziehungsweise 112 zeitweise halbiert oder die Taktung abgeschaltet.

Software-Flusssteuerung mit X-ON/X-OFF

Software-Flusssteuerung verwendet Zeichen, die in die Datenübertragung eingefügt werden. Ihr Hauptvorteil ist, dass keine zusätzliche Schnittstellenleitung nötig ist. Im ASCII-Zeichensatz nach ITU-T-Empfehlung T.50 sind die ersten 32 Zeichen für Steuerungsaufgaben reserviert. DC1 bis DC4 sind Gerätesteuerzeichen; für die Flusssteuerung sollen insbesondere DC1 und DC3 verwendet werden.

• DC1 heißt oft X-ON (Transmission ON), hat die Codierung 11_hex beziehungsweise 17_dez und entspricht auf der PC-Tastatur Strg-Q.
• DC3 heißt oft X-OFF (Transmission OFF), hat die Codierung 13_hex beziehungsweise 19_dez und entspricht Strg-S.

Beide Zeichen sind in beide Richtungen zwischen Endeinrichtung und Übertragungsgerät nutzbar und können bei Modems oft konfiguriert werden. Da sie frühzeitig an Puffern vorbei eingefügt und ausgewertet werden müssen, sind sie Out-Of-Band-Daten.

Ist der Sendespeicher eines lokalen Modems fast voll, fügt das Modem X-OFF in die Empfangsdaten für seine eigene Endeinrichtung ein. Nachdem die Daten zur Gegenstelle übertragen sind und der Speicher wieder frei ist, folgt X-ON. Die Endeinrichtung darf dann wieder senden; die Leitung wird so gegen Datenverluste gesichert.

Grenzen bei Binärdaten

Bei bidirektionaler Übertragung von Binärdaten dürfen X-ON und X-OFF nicht als normale Datenwerte vorkommen, weil sie sonst die Übertragung ungewollt anhalten oder freigeben würden. Sie müssen daher maskiert werden. Eine Möglichkeit ist eine Umcodierung der gesamten Übertragung in ASCII-Werte der hexadezimalen Zahlen, etwa im früher oft verwendeten Intel-Hex-Record. Dadurch verdoppelt sich jedoch das zu übertragende Datenvolumen.

Auch nach einer Umcodierung kann das Problem auftreten, wenn ein Protokoll jedes mögliche Datenbyte verwendet. X-Modem enthält beispielsweise einen fortlaufenden Blockzähler von 00_hex bis FF_hex; dadurch tritt unabhängig vom Dateiinhalt jedes Datenbyte auf. Während X-Modem läuft, muss XON/XOFF deshalb vorübergehend deaktiviert sein. Der Empfänger benötigt genügend Puffer für einen Block, und ein ACK/NAK-Protokoll ersetzt das XON/XOFF-Protokoll.

Software-Flusssteuerung soll nur eingesetzt werden, wenn keine Alternative besteht. Bei unidirektionalem Binärdatentransfer ist XON/XOFF hingegen problemlos möglich, weil die Steuerzeichen nur im jeweiligen Rückkanal vorkommen. Der Empfänger der Binärdaten darf XON/XOFF dann nicht aus seinem Empfangsdatenstrom herausfiltern.