fbpx
Wikipedia

Mit Datenflusssteuerung (engl. data flow control) 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 Protokolle der Internetprotokollfamilie auf höherer Ebene haben jedoch 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.

Inhaltsverzeichnis

Diese Flusssteuerung 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 dieser 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, wie viele Bytes er bereit ist zu empfangen. Somit kann eine TCP-Verbindung automatisch und dynamisch den Datenfluss regeln.

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

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

Hardware-Flusssteuerung, Hardware-Handshake oder Hardware-Protokoll

Eine Hardware-Flusssteuerung wird durch entsprechende Signalpegel auf zugehörigen Schnittstellenleitungen realisiert.

Parallele Datenübertragung (Druckertechnik)

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

  • Strobe – zeigt dem Empfänger an, dass gültige Daten anliegen (positive Logik, wieACK)
  • 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. Sie beziehen sich auf eine lokale Endeinrichtung (z. B. PC), die über ein lokales Übertragungsgerät (z. B. Modem) mit einem entfernten Übertragungsgerät (z. B. Modem beim Provider) und der entfernten Endeinrichtung (z. B. Internet-Server) kommuniziert. Die Leitungen werden je nach Norm unterschiedlich bezeichnet. Hier werden die umgangssprachlichen Bezeichnungen genutzt.

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

  • Die lokale Endeinrichtung aktiviert die Schnittstelle DTR (Data terminal ready = Datenendgerät bereit) in Richtung seines Modems und wartet auf dessen Rückmeldung durch DSR (Data set ready = Datenübertragungsgerät bereit). 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 = Aufforderung zum Senden) und wartet auf die Sendebereitschaft CTS (Clear to send = Erlaubnis zum Senden erteilt) 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 = Erkennung des Datenkanal-Empfangsleitungssignals, umgangssprachlich Carrier detected = Träger erkannt).

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 = Bereit zum Empfang). Durch Platzprobleme auf dem 25-poligen Stecker wurde eine Doppelbelegung mit RTS (Request to send = Aufforderung zum Senden) 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 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.

Normen mit Beschreibung einer seriellen Datenflusssteuerung

Folgende Dokumente unterscheiden korrekt zwischen RTS und RFR:

  • Die ITU-T-Empfehlung V.43 Data flow control (02/98) beschreibt verschiedene Möglichkeiten einer Datenflusssteuerung. Diese Empfehlung entspricht dem ISO/IEC-Report 15294.
  • DIN 12900-1 Labordatenkommunikation Punkt-zu-Punkt-Verbindung mit RS232 (August 1998).
Datenflusssteuerung durch RFR/CTS (oft fälschlich als RTS/CTS bezeichnet)
  • Wenn das Übertragungsgerät keine Daten von dem Endeinrichtungsgerät mehr empfangen kann, schaltet es die Leitung CTS (Clear To Send = Sendebereitschaft) aus. Erst wenn es wieder Daten aufnehmen kann wird CTS eingeschaltet.
  • Es kann sein, dass die Endeinrichtung erst verzögert auf das Ausschalten von CTS reagiert, und weitere Bytes sendet, bevor es die Übertragung unterbricht. Daher sollte das Übertragungsgerät CTS bereits ausschalten, bevor sein Puffer ganz gefüllt ist. V.43 empfiehlt mindestens 2000 Bytes.
  • Auch wenn CTS ausgeschaltet ist und von der Endeinrichtung keine weiteren Daten kommen, fährt das Übertragungsgerät mit der Übertragung der Daten über TxD (Transmitted Data = Übertragene Daten) an das entfernte Gerät fort, solange sein Puffer noch Daten enthält.
  • In umgekehrter Richtung schaltet die Endeinrichtung RFR (Ready For Receiving = Empfangsbereitschaft) aus, wenn sie zum Datenempfang momentan nicht bereit ist.
  • Auch hier kann es sein, dass das Übertragungsgerät erst verzögert reagiert. Anders als bei der umgekehrten Richtung empfiehlt V.43 in diesem Fall aber nur einen kleinen Puffer, da von einer schnellen Reaktion des Übertragungsgeräts ausgegangen werden kann.
  • Das Übertragungsgerät gibt die Empfangsdaten des entfernten Gerätes auf RxD (Received Data = Empfangsdaten) erst dann an die Endeinrichtung weiter, wenn RFR wieder aktiv ist.

Hinweis: Obwohl seit 1995 wichtige Normen bei einer Datenflusssteuerung 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.

Datenflusssteuerung durch DTR/DSR

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

Datenflusssteuerung 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-Flusssteuerung, Software-Handshake, Software-Protokoll oder X-ON/X-OFF

Eine Software-Flusssteuerung wird durch in die Datenübertragung eingefügte Zeichen gesteuert. Der Hauptvorteil liegt darin, keine gesonderte (zusätzliche) Schnittstellenleitung zu erfordern.

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-Flusssteuerung sollte davon die folgenden Zeichen benutzen:

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

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

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

Da das Einfügen und Auswerten dieser Zeichen frühzeitig an Puffern vorbei erfolgen muss, handelt es sich dabei um Out-Of-Band-Daten.

Anwendung

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 effizientere Protokoll X-Modem beinhaltet zum Beispiel einen fortlaufenden Blockzähler von 00hex bis FFhex, so dass unabhängig von den zu übertragenen Daten jedes Datenbyte auftritt. Während X-Modem läuft, muss diese Software-Flusssteuerung vorübergehend deaktiviert werden, und der Empfänger muss genügend Pufferspeicher für einen Block bereitstellen: Das XON/XOFF-Protokoll wird durch ein ACK/NAK-Protokoll ersetzt.

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

  1. List of definitions for interchange circuits between data terminal equipment (DTE) and data circuit-terminating equipment (DCE)
  2. ITU-T V.43, Abschnitt 4.2.1.1 a: 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.
  3. ITU-T V.43, Abschnitt 4.1.1.1 a
  4. ITU-T V.43, Abschnitt 4.2.2.1 a
  5. Circuit 133 (Memento vom 30. Juli 2012 im Internet Archive). 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. (PDF-Datei; 344 kB)
  6. Plug and Play External COM Device Specification Version 1.00 February 28, 1995. 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.
Normdaten (Sachbegriff): GND:4194071-4(OGND, AKS) | LCCN:sh2005007524

Datenflusssteuerung Begriff aus der Informatik Sprache Beobachten Bearbeiten Weitergeleitet von XON XOFF Mit Datenflusssteuerung engl data flow control werden unterschiedliche Verfahren bezeichnet mit denen die Datenubertragung von Endgeraten an einem Datennetz die nicht synchron arbeiten so gesteuert wird dass eine moglichst kontinuierliche Datenubermittlung ohne Verluste erfolgen kann Wenn ein schneller Sender mit einem langsamen Empfanger zusammenarbeitet muss die Datenubertragung zeitweise unterbrochen werden Der Empfanger wurde sonst mit Daten uberlastet werden die er nicht verarbeiten konnte Die Steuerung dieser Unterbrechungen ist die Aufgabe der Datenflusssteuerung Um den Datenfluss zu steuern gibt es verschiedene Verfahren Hardwareverfahren ubertragen Steuerinformationen uber Leitungen die zusatzlich zu den Datenleitungen auf den Steckverbinder gefuhrt sind Softwareverfahren fugen Steuerinformationen in den Datenstrom ein so dass keine zusatzlichen Leitungen gebraucht werden Gewohnlich arbeitet bei einer Datenubertragung nicht nur ein Verfahren zur Datenflusssteuerung sondern mehrere gleichzeitig Wenn beispielsweise ein PC einen Internetzugang uber ein Modem hat arbeitet an der Schnittstelle vom Modem zum PC ein Hardware Verfahren Handshaking uber Steuerleitungen mit dem die Ubertragungsgeschwindigkeit zwischen ihnen geregelt wird Die Protokolle der Internetprotokollfamilie auf hoherer Ebene haben jedoch weitere Mechanismen zur Geschwindigkeitsadaption Dass meistens mehrere Verfahren gleichzeitig arbeiten liegt daran dass nicht nur die Datenubertragungsrate zwischen Sender und Empfanger an einem Datennetz geregelt werden muss sondern in jedem Abschnitt auf dem gesamten Ubertragungsweg im Netz Auch das Datennetz und seine Komponenten arbeiten mit einer bestimmten Geschwindigkeit die von der Geschwindigkeit von Sender und Empfanger abweichen kann Die Hardwareverfahren fur die Datenflusssteuerung sind im OSI Modell der Bitubertragungsschicht zuzuordnen Softwareverfahren gibt es ausserdem auch auf den nachsthoheren Schichten Inhaltsverzeichnis 1 Datenflusssteuerung auf Protokollebene 2 Datenflusssteuerung von Peripheriegeraten 2 1 Hardware Flusssteuerung Hardware Handshake oder Hardware Protokoll 2 1 1 Parallele Datenubertragung Druckertechnik 2 1 2 Serielle Datenubertragung 2 1 2 1 Allgemein 2 1 2 2 Normen mit Beschreibung einer seriellen Datenflusssteuerung 2 1 2 3 Datenflusssteuerung durch RFR CTS oft falschlich als RTS CTS bezeichnet 2 1 2 4 Datenflusssteuerung durch DTR DSR 2 1 2 5 Datenflusssteuerung durch andere Schnittstellenleitungen 2 2 Software Flusssteuerung Software Handshake Software Protokoll oder X ON X OFF 2 2 1 Anwendung 2 2 2 Probleme 3 Einzelnachweise 4 WeblinksDatenflusssteuerung auf Protokollebene BearbeitenDiese Flusssteuerung ist eine Funktion in einem Netzwerkprotokoll Sie ist gewohnlich in einem Protokollstapel zwischen zwei Schichten angesiedelt OSI Modell oder aber zwischen zwei gleichberechtigten Schichten Peer Entities auf Empfanger und Senderseite Diese Algorithmen benutzen eine Art von Feedback der Empfanger signalisiert dem Sender mit einer Quittung ob dieser 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 Fenstergrosse mittels des Steuerungsdialoges nach oben oder unten geregelt werden kann Der Empfanger gibt immer mit an wie viele Bytes er bereit ist zu empfangen Somit kann eine TCP Verbindung automatisch und dynamisch den Datenfluss regeln Andere Verfahren versenden immer nur ein Paket und versenden mit der Bestatigung eine Sendeberechtigung Stop and Wait Protokolle HDLC verwendet die Blocktypen RR Receive Ready und RNR Receive Not Ready zur Flusssteuerung Datenflusssteuerung von Peripheriegeraten BearbeitenAls Peripherie werden hier Drucker Modems Terminals oder ahnliche Gerate bezeichnet Hardware Flusssteuerung Hardware Handshake oder Hardware Protokoll Bearbeiten Eine Hardware Flusssteuerung wird durch entsprechende Signalpegel auf zugehorigen Schnittstellenleitungen realisiert Parallele Datenubertragung Druckertechnik Bearbeiten Die oft an Druckern verwendete Centronics Schnittstelle benutzt drei Leitungen zur Flusssteuerung Strobe zeigt dem Empfanger an dass gultige Daten anliegen positive Logik wie ACK ACK Acknowledge Bestatigung der Datenubernahme durch den Drucker Busy zeigt die Bereitschaft des Druckers zur Datenubernahme an negative Logik Ein Drucker ist viel langsamer als die steuernde Endeinrichtung Durch Deaktivierung der Schnittstellenleitung Busy durfen keine weiteren Daten gesendet werden die Datenubertragung stoppt kurzfristig Serielle Datenubertragung Bearbeiten Allgemein Bearbeiten Die zur Datenubertragung notwendigen Schnittstellenleitungen sind in der ITU T Empfehlung V 24 1 der DIN 66020 oder RS232 beschrieben Sie beziehen sich auf eine lokale Endeinrichtung z B PC die uber ein lokales Ubertragungsgerat z B Modem mit einem entfernten Ubertragungsgerat z B Modem beim Provider und der entfernten Endeinrichtung z B Internet Server kommuniziert Die Leitungen werden je nach Norm unterschiedlich bezeichnet Hier werden die umgangssprachlichen Bezeichnungen genutzt Der normale Ablauf einer Datenubertragung ohne Flusssteuerung verlauft folgenderweise Die lokale Endeinrichtung aktiviert die Schnittstelle DTR Data terminal ready Datenendgerat bereit in Richtung seines Modems und wartet auf dessen Ruckmeldung durch DSR Data set ready Datenubertragungsgerat bereit Damit besteht lokale Betriebsbereitschaft ohne Aktivierung des Senders der Empfanger wartet Wenn die Endeinrichtung senden mochte setzt es die Schnittstelle RTS Request to send Aufforderung zum Senden und wartet auf die Sendebereitschaft CTS Clear to send Erlaubnis zum Senden erteilt 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 Erkennung des Datenkanal Empfangsleitungssignals umgangssprachlich Carrier detected Trager erkannt Diese logischen Ablaufe sind in einem Nullmodem Kabel fest verdrahtet Ein Nullmodem verbindet zwei Endeinrichtungen mit gleicher Ubertragungsgeschwindigkeit Es gibt eine weitere definierte Schnittstelle RFR Ready for receiving Bereit zum Empfang Durch Platzprobleme auf dem 25 poligen Stecker wurde eine Doppelbelegung mit RTS Request to send Aufforderung zum Senden auf Pin 4 9 polig Pin 7 notwendig Entweder kann man den Sender steuern oder der Sender arbeitet mit konstantem Tragersignal und der Empfanger wird gesteuert Modems in der Betriebsart Halbduplex konnen deshalb mit RFR nicht gesteuert werden da dort 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 ausdrucklich davor 2 Normen mit Beschreibung einer seriellen Datenflusssteuerung Bearbeiten Folgende Dokumente unterscheiden korrekt zwischen RTS und RFR Die ITU T Empfehlung V 43 Data flow control 02 98 beschreibt verschiedene Moglichkeiten einer Datenflusssteuerung Diese Empfehlung entspricht dem ISO IEC Report 15294 DIN 12900 1 Labordatenkommunikation Punkt zu Punkt Verbindung mit RS232 August 1998 Datenflusssteuerung durch RFR CTS oft falschlich als RTS CTS bezeichnet Bearbeiten Wenn das Ubertragungsgerat keine Daten von dem Endeinrichtungsgerat mehr empfangen kann schaltet es die Leitung CTS Clear To Send Sendebereitschaft aus Erst wenn es wieder Daten aufnehmen kann wird CTS eingeschaltet Es kann sein dass die Endeinrichtung erst verzogert auf das Ausschalten von CTS reagiert und weitere Bytes sendet bevor es die Ubertragung unterbricht Daher sollte das Ubertragungsgerat CTS bereits ausschalten bevor sein Puffer ganz gefullt ist V 43 empfiehlt mindestens 2000 Bytes 3 Auch wenn CTS ausgeschaltet ist und von der Endeinrichtung keine weiteren Daten kommen fahrt das Ubertragungsgerat mit der Ubertragung der Daten uber TxD Transmitted Data Ubertragene Daten an das entfernte Gerat fort solange sein Puffer noch Daten enthalt In umgekehrter Richtung schaltet die Endeinrichtung RFR Ready For Receiving Empfangsbereitschaft aus wenn sie zum Datenempfang momentan nicht bereit ist Auch hier kann es sein dass das Ubertragungsgerat erst verzogert reagiert Anders als bei der umgekehrten Richtung empfiehlt V 43 in diesem Fall aber nur einen kleinen Puffer da von einer schnellen Reaktion des Ubertragungsgerats ausgegangen werden kann 4 Das Ubertragungsgerat gibt die Empfangsdaten des entfernten Gerates auf RxD Received Data Empfangsdaten erst dann an die Endeinrichtung weiter wenn RFR wieder aktiv ist Hinweis Obwohl seit 1995 wichtige Normen bei einer Datenflusssteuerung die Leitung RTS im Zusammenhang mit neueren Duplex Modems gegen RFR austauschen 5 6 wird in Handbuchern von einfachen Modems immer noch RTS CTS beschrieben Fur die Benutzer dieser Modems andert sich nichts da die richtige Funktion vorhanden ist Datenflusssteuerung durch DTR DSR Bearbeiten Dieser Ablauf ist identisch mit dem vorherigen es werden nur andere Schnittstellenleitungen benutzt Besonders bei Modems kann dieser Mechanismus verwendet werden Er ist zwar nicht genormt aber gebrauchlich Datenflusssteuerung durch andere Schnittstellenleitungen Bearbeiten Eher selten genutzte Moglichkeiten sind die zeitweise Halbierung der Ubertragungsgeschwindigkeit durch die Schnittstelle 111 bzw 112 oder das Abschalten der Taktung Software Flusssteuerung Software Handshake Software Protokoll oder X ON X OFF Bearbeiten Eine Software Flusssteuerung wird durch in die Datenubertragung eingefugte Zeichen gesteuert Der Hauptvorteil liegt darin keine gesonderte zusatzliche Schnittstellenleitung zu erfordern Im ASCII Zeichensatz ITU T Empfehlung T 50 sind die ersten 32 Zeichen fur Steuerungsaufgaben reserviert Vier davon DC1 bis DC4 Device Control sind Geratesteuerzeichen Die Software Flusssteuerung sollte davon die folgenden Zeichen benutzen DC1 oft als X ON bezeichnet engl fur Transmission ON Zeichencodierung 11hex bzw 17dez PC Tastatur Strg Q und DC3 oft als X OFF bezeichnet engl fur Transmission OFF Zeichencodierung 13hex bzw 19dez PC Tastatur Strg S Diese Zeichen sind sowohl in Richtung Endeinrichtung zum Ubertragungsgerat als auch umgedreht nutzbar In der Datenubertragung mit Modems gibt es oft die Moglichkeit diese Zeichen durch Konfiguration umzustellen Da das Einfugen und Auswerten dieser Zeichen fruhzeitig an Puffern vorbei erfolgen muss handelt es sich dabei um Out Of Band Daten Anwendung Bearbeiten Ist der Sendespeicher des lokalen Modems fast gefullt wird das X OFF Steuerzeichen in die Empfangsdaten zur eigenen Endeinrichtung eingefugt Sobald dieser Speicher zur Gegenstelle gesendet wurde und damit wieder leer ist wird das X ON Steuerzeichen eingefugt und damit die Blockierung der Endeinrichtung aufgehoben Die Ubertragungsleitung ist hierdurch vor Datenverlusten gesichert Probleme Bearbeiten Beim Versand von Binardaten durfen die beiden Steuerzeichen nicht in den Daten auftauchen da sonst die Datenubertragung unterbrochen wird Die Zeichen mussen maskiert werden z B dadurch dass die ganze Datenubertragung 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 ubertragene Datenvolumen aber verdoppelt Obwohl durch die Umkodierung innerhalb der zu ubertragenen Dateien die X ON X OFF Steuerzeichen nicht mehr vorkommen war eine Ubertragung oft nicht moglich Das effizientere Protokoll X Modem beinhaltet zum Beispiel einen fortlaufenden Blockzahler von 00hex bis FFhex so dass unabhangig von den zu ubertragenen Daten jedes Datenbyte auftritt Wahrend X Modem lauft muss diese Software Flusssteuerung vorubergehend deaktiviert werden und der Empfanger muss genugend Pufferspeicher fur einen Block bereitstellen Das XON XOFF Protokoll wird durch ein ACK NAK Protokoll ersetzt Die Software Flusssteuerung sollte nur genutzt werden wenn es keine Alternative gibt Einzelnachweise Bearbeiten List of definitions for interchange circuits between data terminal equipment DTE and data circuit terminating equipment DCE ITU T V 43 Abschnitt 4 2 1 1 a 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 ITU T V 43 Abschnitt 4 1 1 1 a ITU T V 43 Abschnitt 4 2 2 1 a Circuit 133 Memento vom 30 Juli 2012 im Internet Archive 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 PDF Datei 344 kB Plug and Play External COM Device Specification Version 1 00 February 28 1995 Microsoft nennt in diesem Dokument fur Entwickler ausdrucklich RTS und RFR fur den Anwender wird auch heute noch in der Hilfe nur RTS beschrieben Weblinks BearbeitenITU T Empfehlung V 43 Data flow control 02 98 Normdaten Sachbegriff GND 4194071 4 OGND AKS LCCN sh2005007524 Abgerufen von https de wikipedia org w index php title Datenflusssteuerung amp oldid 214515166 Software Flusssteuerung Software Handshake Software Protokoll oder X ON X OFF, wikipedia, wiki, deutsches, deutschland,

buch

, bücher, bibliothek,

artikel

, lesen, herunterladen, kostenlos, kostenloser herunterladen, MP3, Video, MP4, 3GP, JPG, JPEG, GIF, PNG, Bild, Musik, Lied, Film, Buch, Spiel, Spiele