rts/cts - a tutorial on flow control

[Henry Spencer]

The ultimate problem here is two slightly-different definitions of what
"data" is.  Narrowly speaking, the ASCII control characters are just that --
*control* characters, not data -- and hence they *are* out-of-band as far
as transmission of ASCII text goes.  The difficulties arise because of a
combination of (a) not enough keys on the keyboard for things like fancy
editors, and (b) the ability to send control characters from the keyboard.
Programs like uucp that want to send arbitrary bit patterns make it worse.
The result of this is predictable:  there is now a strong preference for
classing *all* ASCII characters as "data", which implies that out-of-band
flow control has to use some other mechanism.

CTS/RTS is workable at short range, but since those wires were never meant
for flow control, much hardware (modems, local networks, dumb terminal
multiplexors) won't handle it.  (What *were* CTS and RTS meant for, you
ask?  For turning around half-duplex modems.)

In any case, neither XON/XOFF nor CTS/RTS is really ideal, because both
are negative ("stop, I can't take any more!") flow control methods.  This
means that they fall down badly when propagation delays are long (e.g.
long-haul networks or satellite channels), because the other end doesn't
get the word quickly enough.  What is really wanted is a standard method
of *positive* flow control ("I'm OK for another 347 characters now").
I don't see much hope for getting one established, though.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry