Hardware flow control Vs. Software flow contorl

데이터 통신의 흐름을 제어하는 방법의 하나로, 통상의 신호선(線)과는 달리 별도의 흐름 제어전용 신호선을 가지는 방식. 이와는 반대로, 통상의 신호선에 송수신하는 데이터열 속에 제어 데이터를 넣어 놓는 방식을 소프트 흐름 제어라고 한다.

하드웨어 흐름 제어는 제어전용의 신호선이 필요하기 때문에 설계는 복잡하지만 송수신하는 데이터에 제어 데이터를 넣지않고 전송을 완료하기 때문에 데이터 효율이 좋다. 원격지와 공중회선으로 통신하는 경우 등, 통신회로의 특성상 어떻게해도 소프트웨어 제어를 이용해서는 안되는 경우를 빼고, 현재는 거의 모든 경우에 소프트웨어 흐름제어가 이용된다.

RS-232C에는, 하드웨어 흐름 제어를 위한 'CS(Clear to Send)'와 'RS(Request to Send)'의 제어신호를 가지고 있다. 이 때문에, RS-232C에 있어서 흐름 제어는, CTS/RTS 흐름 제어 방식으로 불리운다.

================================================================================================================

Software flow control is a method of flow control used in computer data links, especially RS-232 serial. It uses special codes, transmitted in-band, over the primary communications channel. These codes are generally called XOFF and XON (from "transmit off" and "transmit on", respectively). Thus, "software flow control" is sometimes called "XON/XOFF flow control". This is in contrast to flow control via dedicated out-of-band signals — "hardware flow control" — such as RTS/CTS.

RTS/CTS (Request to Send / Clear to Send)  is the optional mechanism used by the 802.11 wireless networking protocol to reduce frame collisions introduced by the hidden terminal problem. Originally the protocol fixed the exposed terminal problem as well, but modern RTS/CTS includes ACKs and does not solve the exposed terminal problem. A node wishing to send data initiates the process by sending a Request to Send frame (RTS). The destination node replies with a Clear To Send frame (CTS). Any other node receiving the RTS or CTS frame should refrain from sending data for a given time (solving the hidden node problem). The amount of time the node should wait before trying to get access to the medium is included in both the RTS and the CTS frame. This protocol was designed under the assumption that all nodes have the same transmission range. RTS/CTS is an additional method to implement virtual carrier sensing in Carrier sense multiple access with collision avoidance (CSMA/CA). By default, 802.11 relies on physical carrier sensing only which is known to suffer from the hidden node problem. RTS/CTS packet size threshold is 0-2347 octets. Typically, sending RTS frames is turned off by default (threshold ≥ 2347). If the packet size the node wants to transmit is larger than the threshold, the RTS/CTS handshake gets triggered. If the packet size is equal to or less than threshold the data frame gets sent immediately.

Representation

For systems using the ASCII character code, XOFF is generally represented using a character or byte with value 19; XON with value 17.

The ASCII standard does not reserve any control characters for use as XON/XOFF specifically. However, it does provide four generic "device control" characters (DC1 through DC4). The seminal ASR-33 Teletype adopted two of these, DC3 and DC1, for use as XOFF and XON, respectively. This usage was copied by others, and is now a de facto standard. The keyboard equivalents of CTRL+S for XOFF, and CTRL+Q for XON, also derive from this usage.

XOFF/XON representations in ASCII

Code	Meaning	ASCII	Dec	Hex	Keyboard
XOFF	Pause transmission	DC3	19	0x13	CTRL+S
XON	Resume transmission	DC1	17	0x11	CTRL+Q

Mechanism

When one end of a data link is unable to accept any more data (or approaching that point), it sends XOFF to the other end. The other end receives the XOFF code, and suspends transmission. Once the first end is ready to accept data again, it sends XON, and the other end resumes transmission.

For example, imagine a computer connected to a slow printer. The computer starts sending data to the printer. Since the computer is faster than the printer, the printer falls behind, and starts to be overwhelmed by the data. The printer thus sends XOFF to the computer. The software on the computer "sees" the XOFF, and temporarily stops sending data. Once the printer has "caught up", it sends XON to the computer. The computer sees XON, and starts sending data again.

XOFF/XON can be employed in both directions -- for example, two teleprinters connected to each other.

Comparison with hardware flow control

The principal advantage of software flow control is the reduction in the number of electrical conductors between sender and receiver. Given a common ground, only two signals are needed, one to send and the other to receive. Hardware flow control requires additional wires between the two devices. It also requires specific hardware implementation, which had more significant costs in earlier days of computing (i.e., 1960s and 70s).

However, software flow control is not without its problems. Sending XOFF requires at least one character time to transmit, and may be queued behind already-transmitted data still in buffers. Hardware signals may be asserted almost instantaneously, and out-of-order.

As the name "software flow control" implies, flow control using this method is usually implemented in software (or at least a higher level of firmware), which can cause further delays in XOFF response. Hardware flow control is typically under the direct control of the transmitting UART, which is able to cease transmission immediately, without the intervention of higher levels.

Finally, since the XOFF/XON codes are sent in-band, they cannot appear in the data being transmitted without being mistaken for flow control commands. Any data containing the XOFF/XON codes thus must be encoded in some manner for proper transmission, with corresponding overhead. This is frequently done with some kind of escape sequence.

Applications

Software flow control is used extensively by low-speed devices, especially older printers and dumb terminals, to indicate they are temporarily unable to accept more data. Typically, this is due to a combination of limited output rate and any buffers being full. Some terminal control packages, such as termcap, employ "padding" to allow such equipment sufficient time to perform the requested actions without the need to assert XOFF.

XOFF/XON are still sometimes used manually by computer operators, to pause and restart output which otherwise would scroll off the display too quickly.

Terminal emulator software generally implements XOFF/XON support as a basic function. This generally includes the system console on modern Unix and Linux machines, as well as GUI emulators such as xterm and the Win32 console.

References

• How to control the flow of data: The XON/XOFF protocol. In: Configuring Systems for Terminals, Printers, and Other Serial Devices: HP 3000 MPE/iX Computer Systems. Hewlett-Packard Company.

출처 : http://en.wikipedia.org/wiki/Software_flow_control#Comparison_with_hardware_flow_control