Hardware-Handshake

Mit Datenflusskontrolle (engl. data flow control) oder Datenflusssteuerung werden unterschiedliche Verfahren bezeichnet, mit denen die Datenübertragung von Endgeräten an einem Datennetz, die nicht synchron arbeiten, so gesteuert wird, dass eine möglichst kontinuierliche Datenübermittlung ohne Verluste erfolgen kann.

Wenn ein schneller Sender mit einem langsamen Empfänger zusammenarbeitet, muss die Datenübertragung zeitweise unterbrochen werden. Der Empfänger würde sonst mit Daten überlastet werden, die er nicht verarbeiten könnte. Die Steuerung dieser Unterbrechungen ist die Aufgabe der Datenflusssteuerung.

Um den Datenfluss zu steuern, gibt es verschiedene Verfahren.

• Hardwareverfahren übertragen Steuerinformationen über Leitungen, die zusätzlich zu den Datenleitungen auf den Steckverbinder geführt sind.
• Softwareverfahren fügen Steuerinformationen in den Datenstrom ein, so dass keine zusätzlichen Leitungen gebraucht werden.

Gewöhnlich arbeitet bei einer Datenübertragung nicht nur ein Verfahren zur Datenflusssteuerung, sondern mehrere gleichzeitig. Wenn beispielsweise ein PC einen Internetzugang über ein Modem hat, arbeitet an der Schnittstelle vom Modem zum PC ein Hardware-Verfahren (Handshaking über Steuerleitungen), mit dem die Übertragungsgeschwindigkeit zwischen ihnen geregelt wird. Die TCP/IP-Verbindung ihrerseits hat weitere Mechanismen zur Geschwindigkeitsadaption.

Dass meistens mehrere Verfahren gleichzeitig arbeiten liegt daran, dass nicht nur die Datenübertragungsrate zwischen Sender und Empfänger an einem Datennetz geregelt werden muss, sondern in jedem Abschnitt auf dem gesamten Übertragungsweg im Netz. Auch das Datennetz und seine Komponenten arbeiten mit einer bestimmten Geschwindigkeit, die von der Geschwindigkeit von Sender und Empfänger abweichen kann.

Die Hardwareverfahren für die Datenflusssteuerung sind im OSI-Modell der Bitübertragungsschicht zuzuordnen. Softwareverfahren gibt es außerdem auch auf den nächsthöheren Schichten.

Datenflusskontrolle auf Protokollebene

Diese Flusskontrolle ist eine Funktion in einem Netzwerkprotokoll. Sie ist gewöhnlich in einem Protokollstapel zwischen zwei Schichten angesiedelt (OSI-Modell), oder aber zwischen zwei gleichberechtigten Schichten (Peer-Entities) auf Empfänger- und Senderseite.

Diese Algorithmen benutzen eine Art von Feedback: der Empfänger signalisiert dem Sender mit einer Quittung, ob der weiter senden soll. Bei TCP kommt dabei ein Sliding-Window-Protokoll zum Einsatz. „Window” bedeutet hier, dass immer ein ganzes „Fenster” mit empfangenen Daten quittiert wird, „sliding” bedeutet, dass die Fenstergröße mittels des Steuerungsdialoges nach oben oder unten geregelt werden kann. Der Empfänger gibt immer mit an, wieviele Bytes er bereit ist zu empfangen. Somit kann eine TCP-Verbindung automatisch und dynamisch die Flusskontrolle regeln.

Andere Verfahren versenden immer nur ein Paket und verschicken mit der Bestätigung eine Sendeberechtigung (Stop-and-Wait-Protokolle). HDLC verwendet die Blocktypen RR (Receive Ready) und RNR (Receive Not Ready) zur Flusskontrolle.

Datenflusskontrolle von Peripheriegeräten

Als Peripherie werden hier Drucker, Modems, Terminals oder ähnliche Geräte bezeichnet.

Hardware-Flusskontrolle, Hardware-Handshake oder Hardware-Protokoll

Eine Hardware-Flusskontrolle wird durch Schnittstellenleitungen gesteuert.

Parallele Datenübertragung (Druckertechnik)

Die oft an Druckern verwendete Centronics-Schnittstelle benutzt drei Leitungen zur Flusskontrolle:

• Strobe – zeigt dem Empfänger an, dass gültige Daten anliegen (positive Logik, wie ACK)
• ACK – Acknowledge, Bestätigung der Datenübernahme durch den Drucker
• Busy – zeigt die Bereitschaft des Druckers zur Datenübernahme an (negative Logik)

Ein Drucker ist viel langsamer als die steuernde Endeinrichtung. Durch Deaktivierung der Schnittstellenleitung Busy dürfen keine weiteren Daten gesendet werden, die Datenübertragung stoppt kurzfristig.

Serielle Datenübertragung

Allgemein

Die zur Datenübertragung notwendigen Schnittstellenleitungen sind in der ITU-T-Empfehlung V.24, der DIN 66020 oder RS232 beschrieben. Die Leitungen werden je nach Norm unterschiedlich bezeichnet. Hier werden die umgangssprachlichen Bezeichnungen genutzt.

Der normale Ablauf einer Datenübertragung ohne Flusskontrolle verläuft folgenderweise:

• Die lokale Endeinrichtung aktiviert die Schnittstelle DTR (Data terminal ready) in Richtung seines Modems und wartet auf dessen Rückmeldung durch DSR (Data set ready). Damit besteht lokale Betriebsbereitschaft ohne Aktivierung des Senders, der Empfänger wartet.
• Wenn die Endeinrichtung senden möchte, setzt es die Schnittstelle RTS (Request to send) und wartet auf die Sendebereitschaft CTS (Clear to send) des lokalen Modems. Durch Einschalten des Senders erkennt das entfernte Modem Empfangssignalpegel und meldet es seiner Endeinrichtung durch CD (Data channel received line signal detector, umgangssprachlich Carrier detected).

Diese logischen Abläufe sind in einem Nullmodem-Kabel fest verdrahtet. Ein Nullmodem verbindet zwei Endeinrichtungen mit gleicher Übertragungsgeschwindigkeit.

Es gibt eine weitere definierte Schnittstelle: RFR (Ready for receiving). Durch Platzprobleme auf dem 25-poligen Stecker wurde eine Doppelbelegung mit RTS auf Pin 4 (9-polig: Pin 7) notwendig: Entweder kann man den Sender steuern oder der Sender arbeitet mit konstantem Trägersignal und der Empfänger wird gesteuert. Modems in der Betriebsart Halbduplex können deshalb mit RFR nicht gesteuert werden, da dort zwingend der Sender gesteuert werden muss.

Da beide Schnittstellen aus Richtung der Endeinrichtung arbeiten, werden sie oft gleichgesetzt. Die ITU-T warnt in der Empfehlung V.43 aber ausdrücklich davor: In many publications, circuit 133 (Ready for receiving) is, incorrectly, referred to as circuit 105 (Request to send). These two interchange circuits are significantly different in their respective definitions and functions.

Normen mit Beschreibung einer seriellen Datenflusskontrolle

Folgende Dokumente unterscheiden korrekt zwischen RTS und RFR:

• Die ITU-T-Empfehlung V.43 Data flow control (02/98) beschreibt verschiedene Möglichkeiten einer Datenflusskontrolle.
  Diese Empfehlung entspricht dem ISO/IEC-Report 15294.
• DIN 12900-1 Labordatenkommunikation Punkt-zu-Punkt-Verbindung mit RS232 (August 1998).
• Weitere Hinweise über die offizielle Bezeichnung siehe Weblinks

Datenflusskontrolle durch RFR/CTS (oft fälschlich als RTS/CTS bezeichnet)

• Das Übertragungsgerät muss einen Sendespeicher von mindestens 2000 Byte haben. Ist dieser Speicher zur Hälfte gefüllt, soll es Leitung CTS ausschalten. Die Endeinrichtung sollte daraufhin so schnell wie möglich das Senden von Daten unterbrechen, bis CTS wieder eingeschaltet wird.
• Die Endeinrichtung schaltet RFR aus, wenn sie zum Datenempfang momentan nicht bereit ist. Das Übertragungsgerät gibt die Empfangsdaten des entfernten Gerätes auf RXD erst weiter, wenn RFR wieder aktiv ist.

Hinweis: Obwohl seit mindestens zehn Jahren wichtige Normen bei einer Datenflusskontrolle die Leitung RTS im Zusammenhang mit neueren Duplex-Modems gegen RFR austauschen, wird in Handbüchern von einfachen Modems immer noch RTS/CTS beschrieben. Für die Benutzer dieser Modems ändert sich nichts, da die richtige Funktion vorhanden ist.

Datenflusskontrolle durch DTR/DSR

Dieser Ablauf ist identisch zum vorherigen, es werden nur andere Schnittstellenleitungen benutzt. Besonders bei Modems kann dieser Mechanismus verwendet werden. Er ist zwar nicht genormt, aber gebräuchlich.

Datenflusskontrolle durch andere Schnittstellenleitungen

Eher selten genutzte Möglichkeiten sind die zeitweise Halbierung der Übertragungsgeschwindigkeit durch die Schnittstelle 111 bzw. 112 oder das Abschalten der Taktung.

Software-Flusskontrolle, Software-Handshake, Software-Protokoll oder X-ON/X-OFF

Eine Software-Flusskontrolle wird durch in die Datenübertragung eingefügte Zeichen gesteuert.

Im ASCII-Zeichensatz (ITU-T-Empfehlung T.50) sind die ersten 32 Zeichen für Steuerungsaufgaben reserviert. Vier davon, DC1 bis DC4 (Device Control), sind Gerätesteuerzeichen.

Die Software-Flusskontrolle sollte davon die folgenden Zeichen benutzen:

• DC1 (oft als X-ON bezeichnet, engl. für Transmission ON, Zeichencodierung 11_hex bzw. 17_dez, PC-Tastatur: Strg-Q) und
• DC3 (oft als X-OFF bezeichnet, engl. für Transmission OFF, Zeichencodierung 13_hex bzw. 19_dez,PC-Tastatur: Strg-S).

Diese Zeichen sind sowohl in Richtung Endeinrichtung zum Übertragungsgerät als auch umgedreht nutzbar.

Anwendung

In der Datenübertragung mit Modems gibt es oft die Möglichkeit, diese Zeichen durch Konfiguration umzustellen.

Ist der Sendespeicher des lokalen Modems fast gefüllt, wird das X-OFF-Steuerzeichen in die Empfangsdaten zur eigenen Endeinrichtung eingefügt. Sobald dieser Speicher zur Gegenstelle gesendet wurde und damit wieder leer ist, wird das X-ON-Steuerzeichen eingefügt und damit die Blockierung der Endeinrichtung aufgehoben. Die Übertragungsleitung ist hierdurch vor Datenverlusten gesichert.

Probleme

Beim Versand von Binärdaten dürfen die beiden Steuerzeichen nicht in den Daten auftauchen, da sonst die Datenübertragung unterbrochen wird. Die Zeichen müssen maskiert werden, z. B. dadurch, dass die ganze Datenübertragung so umkodiert wird, dass die Daten als ASCII-Werte der hexadezimalen Zahlen gesendet werden. Ein vor Jahren oft genutztes Format war der Hex-Record von Intel. Dadurch wurde das zu übertragene Datenvolumen aber verdoppelt. Obwohl durch die Umkodierung innerhalb der zu übertragenen Dateien die X-ON/X-OFF-Steuerzeichen nicht mehr vorkommen, war eine Übertragung oft nicht möglich. Das Protokoll X-Modem beinhaltet zum Beispiel einen fortlaufenden Blockzähler von 00_hex bis FF_hex, so dass unabhängig von den zu übertragenen Daten jedes Datenbyte auftritt.

Die Software-Flusskontrolle sollte nur genutzt werden, wenn es keine Alternative gibt.

Weblinks

• [1] Beschreibung des Intel HEX-record Formates (englisch, PDF)
• [2] Das INTEL Hex-Format Kurzüberblick
• [3] Plug and Play External COM Device Specification Version 1.00 February 28, 1995
• [4] Auch die TIA benutzt offiziell RFR: Circuit 133, RFR (Ready for Receiving) is commonly assigned to the connector pin that is alternatively used for circuit 105, RTS. It is sometimes referred to by that name.

  Microsoft nennt in diesem Dokument für Entwickler ausdrücklich RTS und RFR; für den Anwender wird auch heute noch in der Hilfe nur RTS beschrieben.

• [5] GENERAL: INTEL HEX FILE FORMAT (Auch für 32-bit-Adressierung)