Data flow control

from Wikipedia, the free encyclopedia

With Flow Control (engl. Dataflow control ) different methods with which the data transmission from terminal devices to a data network, which are not referred to, in synchronization work is controlled so that a continuous transmission of data as possible can be carried out without loss.

If a fast transmitter works with a slow receiver, the data transmission must be temporarily interrupted. Otherwise the receiver would be overloaded with data that it could not process. The control of these interruptions is the task of the data flow control.

There are various methods of controlling the data flow.

  • Hardware processes transmit control information via lines that are routed to the connector in addition to the data lines .
  • Software processes add control information to the data stream so that no additional lines are needed.

Usually, not only one method for data flow control works in a data transmission, but several at the same time. If, for example, a PC has Internet access via a modem , a hardware process (handshaking via control lines) works at the interface from the modem to the PC, with which the transmission speed between them is regulated. However, the higher-level protocols of the Internet protocol family have additional mechanisms for speed adaptation.

The fact that several processes usually work at the same time is due to the fact that not only the data transmission rate between the transmitter and receiver in a data network has to be regulated, but also in every section along the entire transmission path in the network. The data network and its components also work at a certain speed, which can differ from the speed of the transmitter and receiver.

The hardware procedures for data flow control are assigned to the physical layer in the OSI model . There are also software processes on the next higher layers.

Data flow control at the protocol level

This flow control is a function in a network protocol . It is usually located in a protocol stack between two layers ( OSI model ), or between two layers with equal rights (peer entities) on the receiver and sender side.

These algorithms use a type of feedback: the receiver signals the sender with an acknowledgment whether it should continue to send. A sliding window protocol is used with TCP . "Window" here means that a whole "window" is always acknowledged with received data, "sliding" means that the window size can be adjusted up or down using the control dialog. The receiver always indicates how many bytes it is ready to receive. Thus, a TCP connection can regulate the data flow automatically and dynamically.

Other methods always send only one package and send a send authorization with the confirmation (stop-and-wait protocol). HDLC uses the block types RR (Receive Ready) and RNR (Receive Not Ready) for flow control.

Data flow control of peripheral devices

Printers, modems, terminals or similar devices are referred to here as peripherals.

Hardware flow control, hardware handshake or hardware protocol

Hardware flow control is implemented through appropriate signal levels on the associated interface lines.

Parallel data transfer (printer technology)

The Centronics interface, which is often used on printers, uses three lines for flow control:

  • Strobe - indicates to the receiver that valid data is present ( positive logic , such as ACK )
  • ACK - Acknowledge, confirmation of data transfer by the printer
  • Busy - indicates that the printer is ready to accept data ( negative logic )

A printer is much slower than the controlling terminal . By deactivating the Busy interface line , no further data may be sent; the data transmission stops briefly.

Serial data transfer

General

The interface lines required for data transmission are described in ITU-T recommendation V.24 , DIN 66020 or RS232 . They refer to a local terminal device (e.g. PC) that communicates via a local transmission device (e.g. modem) with a remote transmission device (e.g. modem at the provider) and the remote terminal device (e.g. Internet Server) communicates. The cables are designated differently depending on the standard. The colloquial terms are used here.

The normal sequence of data transmission without flow control is as follows:

  • The local terminal activates the DTR (data terminal ready) interface in the direction of its modem and waits for its response from DSR (data set ready). This means that there is local operational readiness without activating the transmitter, the receiver waits.
  • When the terminal device wants to send, it sets the RTS (request to send) interface and waits for the local modem to be ready to send CTS (clear to send) . By switching on the transmitter detects the distant modem receive signal level and reports it to his terminal by CD (Data channel received line signal detector = detection of the data channel received line signal, commonly known carriers detected = carrier detected).

These logical processes are hard-wired in a null modem cable . A null modem connects two terminal devices with the same transmission speed.

There is another defined interface: RFR (Ready for receiving). Due to space problems on the 25-pin connector, a double assignment with RTS (request to send) on pin 4 (9-pin: pin 7) became necessary: ​​Either you can control the transmitter, or the transmitter works with a constant carrier signal, and the receiver is controlled. Modems in the half-duplex operating mode cannot therefore be controlled with RFR, since the transmitter must be controlled there.

Since both interfaces work from the direction of the terminal equipment, they are often equated. The ITU-T expressly warns against this in Recommendation V.43.

Standards describing a serial data flow control

The following documents correctly differentiate between RTS and RFR:

  • The ITU-T recommendation V.43 Data flow control (02/98) describes various options for data flow control . This recommendation corresponds to ISO / IEC report 15294.
  • DIN 12900-1 laboratory data communication point-to-point connection with RS232 (August 1998).
Data flow control through RFR / CTS (often incorrectly referred to as RTS / CTS)
  • If the transmission device can no longer receive data from the terminal, it switches off the CTS (Clear To Send) line. Only when it can accept data again is CTS switched on.
  • It may be that the terminal device only reacts with a delay to switching off CTS and sends further bytes before it interrupts the transmission. The transmission device should therefore switch off the CTS before its buffer is completely full. V.43 recommends at least 2000 bytes.
  • Even if CTS is switched off and no further data comes from the terminal, the transmission device continues to transmit the data to the remote device via TxD (Transmitted Data) as long as its buffer still contains data.
  • In the opposite direction, the terminal device switches off RFR (Ready For Receiving) if it is currently not ready to receive data.
  • Here, too, the transmission device may react with a delay. In contrast to the reverse direction, V.43 only recommends a small buffer in this case, since a quick response from the transmission device can be assumed.
  • The transmission device only forwards the received data from the remote device on RxD (Received Data) to the terminal device when RFR is active again.

Note: Although important standards for data flow control have been replacing the RTS line with RFR in connection with newer duplex modems since 1995, RTS / CTS is still described in the manuals for simple modems. Nothing changes for the users of these modems as the correct function is in place.

Data flow control through DTR / DSR

This process is identical to the previous one, only different interface lines are used. This mechanism can be used especially with modems. Although it is not standardized, it is common.

Data flow control through other interface lines

Seldom used options are the temporary halving of the transmission speed by the interface 111 or 112 or switching off the clock.

Software flow control, software handshake, software protocol or X-ON / X-OFF

Software flow control is controlled by characters inserted in the data transmission. The main advantage is that no separate (additional) interface line is required.

In the ASCII character set (ITU-T recommendation T.50 ) the first 32 characters are reserved for control tasks . Four of them, DC1 to DC4 (Device Control), are device control characters.

The software flow control should use the following characters:

  • DC1 (often called X-ON referred, English for. Transmission ON , character encoding 11 hex or 17 dec , PC - keyboard : Ctrl-Q) and
  • DC3 (often referred to as X-OFF , English for Transmission OFF , character coding 13 hex or 19 dec , PC keyboard: Ctrl-S).

These characters can be used both in the direction of the end device to the transmission device and vice versa.

When transmitting data with modems, there is often the option of changing these characters through configuration.

Since the insertion and evaluation of these characters must be done in good time by buffers, this is out-of-band data.

application

If the transmission memory of the local modem is almost full , the X-OFF control character is inserted into the received data for the own terminal. As soon as this memory has been sent to the remote station and is thus empty again, the X-ON control character is inserted and the terminal device is blocked. This protects the transmission line from data loss.

Problems

When sending binary data , the two control characters must not appear in the data, otherwise the data transmission will be interrupted. The characters must be masked, e.g. B. in that the entire data transmission is recoded in such a way that the data is sent as ASCII values ​​of the hexadecimal numbers. A format that was often used years ago was the Intel hex record . This doubled the data volume to be transferred. Although the X-ON / X-OFF control characters no longer occur due to the recoding within the files to be transferred , transfer was often not possible. The more efficient X-Modem protocol includes, for example, a continuous block counter from 00 hex to FF hex , so that every data byte occurs regardless of the data to be transmitted. While the X-Modem is running, this software flow control must be temporarily deactivated and the receiver must provide enough buffer memory for one block: The XON / XOFF protocol is replaced by an ACK / NAK protocol.

Software flow control should only be used if there is no alternative.

Individual evidence

  1. ↑ List of definitions for interchange circuits between data terminal equipment (DTE) and data circuit-terminating equipment (DCE)
  2. ↑ ITU-T V.43, Section 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, Section 4.1.1.1 a
  4. ↑ ITU-T V.43, Section 4.2.2.1 a
  5. ↑ Circuit 133 ( Memento of July 30, 2012 in the Internet Archive ). The TIA officially uses 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 file; 344 kB)
  6. ↑ Plug and Play External COM Device Specification Version 1.00 February 28, 1995 . Microsoft specifically mentions RTS and RFR for developers in this document; for the user, even today only RTS is described in the help.

Web links