Difference between revisions of "Flow control"

From Computer History Wiki
Jump to: navigation, search
(A good start)
 
m (Serial lines: typo)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Flow control''' refers to the need, with two [[application]] instances communicating over a [[byte stream]], to prevent the sender from sending data faster than the receiver can consume it.
+
'''Flow control''' refers to the need to prevent a sender of data from sending it so fast the receiver cannot take it all in.
 +
 
 +
==Serial lines==
 +
 
 +
In [[asynchronous serial line]]s, a variety of techniques are used.
 +
 
 +
With [[EIA RS-232 serial line interface|RS-232 interfaces]], there are a pair of control lines dedicated to doing flow control in [[hardware]] - Request To Send, and Clear To Send. The sender activates RTS when it has data ready; the receiver puts up Clear To Send as long as it's OK for the sender to send.
 +
 
 +
More commonly, serial lines also use [[software]] flow control, using in-band transmission of XOFF and XON [[character]]s: usually, but not nessarily, CTRL-S and CTRL-Q. (The formal [[ASCII]] specification does not reserve XON/XOFF characters.)
 +
 
 +
==Inter-application==
 +
 
 +
In computers, flow control is often needed when there are two [[application]] instances communicating over a [[byte stream]].
  
 
When the two instances are on a single machine (e.g. using a [[pipe]] to communicate), flow control is fairly simple to peform; the [[operating system]] monitors the amount of data in the stream, and blocks the sender when the backlog gets too large.
 
When the two instances are on a single machine (e.g. using a [[pipe]] to communicate), flow control is fairly simple to peform; the [[operating system]] monitors the amount of data in the stream, and blocks the sender when the backlog gets too large.
Line 5: Line 17:
 
Over a network, the problem is a little more complicated; the [[protocol]] has to have a mechanism to allow the destination to inform the source how much [[buffer]]ing is available for incoming data, or to tell the source that the destination cannot accept any more data at this time.
 
Over a network, the problem is a little more complicated; the [[protocol]] has to have a mechanism to allow the destination to inform the source how much [[buffer]]ing is available for incoming data, or to tell the source that the destination cannot accept any more data at this time.
  
In the [[reliable byte stream]] [[Transmission Control Protocol|TCP]] protocol of the [[TCP/IP]] [[protocol family]], a '''window''' at the sender is maintained for this purpose; the receiver on each side periodically updates the window stored at the other end.
+
In the [[Transmission Control Protocol|TCP]] [[reliable byte stream]] protocol of the [[TCP/IP]] [[protocol family]], a '''window''' at the sender is maintained for this purpose; the receiver on each side periodically updates the window stored at the other end.
 +
 
 +
[[Category: Basics]]

Latest revision as of 14:47, 18 October 2021

Flow control refers to the need to prevent a sender of data from sending it so fast the receiver cannot take it all in.

Serial lines

In asynchronous serial lines, a variety of techniques are used.

With RS-232 interfaces, there are a pair of control lines dedicated to doing flow control in hardware - Request To Send, and Clear To Send. The sender activates RTS when it has data ready; the receiver puts up Clear To Send as long as it's OK for the sender to send.

More commonly, serial lines also use software flow control, using in-band transmission of XOFF and XON characters: usually, but not nessarily, CTRL-S and CTRL-Q. (The formal ASCII specification does not reserve XON/XOFF characters.)

Inter-application

In computers, flow control is often needed when there are two application instances communicating over a byte stream.

When the two instances are on a single machine (e.g. using a pipe to communicate), flow control is fairly simple to peform; the operating system monitors the amount of data in the stream, and blocks the sender when the backlog gets too large.

Over a network, the problem is a little more complicated; the protocol has to have a mechanism to allow the destination to inform the source how much buffering is available for incoming data, or to tell the source that the destination cannot accept any more data at this time.

In the TCP reliable byte stream protocol of the TCP/IP protocol family, a window at the sender is maintained for this purpose; the receiver on each side periodically updates the window stored at the other end.