rts/cts - a tutorial on flow control

[Brian Kantor]

Phil Ngai suggests that hardware flow control is gross, and that
XON/XOFF is the proper way to go.  As this attitude is widespread among
those who don't really understand why hardware flow control exists:


XON/XOFF could be considered an example of what is called 
``inband signalling'', where a communications channel carries both data
and control signals in the data stream.  

When such a scheme is used, there has to be some way to separate the 
control signals from the data.  There can be some special sequence of
characters, or reserved characters, or timing, or a combination of
these.  There are a lot of disadvantages to this.

Hayes modems, for example, use timing and a sequence of characters.  To
disconnect an open data connection, you stop all outgoing data for 3
seconds, send +++, and pause for another 3 seconds.  If you are already
connected and discover that you have to send exactly that pattern for
some reason, you are out of luck - the modem is going to disconnect and
you can't do anything about it (oh, you could have changed the control
characters BEFORE you connected, but once you have connected, too bad.
You could also have disabled the feature, but then you have to have some
other method of disconnecting the modem).

XON-XOFF (aka DC1/DC3) are examples of reserved characters.  When they
occur in the data stream, they are interpreted.  If its desired that
they be treated as data (for example, as a command key for EMACS, or as
binary data), it is necessary to ``escape'' them - to send another
reserved character that signifies that the character following it is NOT
to be interpreted.  So its then necessary to have software watching the
data stream and handling the escape character too. (To send the escape
character itself as data, you would then send it twice.)

Hardware flow control has none of these complications.  It is
``out-of-band'' signalling, i.e., it performs its control functions
without giving any special significance to or altering the data stream
in any way.  This means that you can transmit anything over the data
stream without worrying about what funny noises it might generate along
the way.

But, I hear you saying, ``This is normal typing at a terminal.  We're
not going to send funny characters!''.  Well, maybe YOU aren't, but the
equipment you're using might.

The original question was regarding terminals and such connected through
a Local Area Network (LAN).  Because a LAN typically has contention for
its bandwidth, it is sometimes necessary to stop the data flow into the
network for a brief period of time until congestion is alleviated. With
the XON/XOFF protocol, that means that the Network Attachment Device (NAD) 
(sort of like a modem) has to send an XOFF to the terminal or
computer until its buffers empty out a bit, and then send XON to resume
data flow.

Consider the following scenario:  You are reading the USENET news, and
you decide to pause the screen for a moment.  You type a control-S
(XOFF) and the NAD stops sending you data.  But the computer is still
sending, and does so until the other NAD (at the computer end) fills up,
and sends an XOFF to the computer.  You begin reading again (send an XON
to restart output), and not until the computer NAD empties out again do
things start to flow out of the computer (the computer NAD sends XON to
restart output there).

This all works well, and is reasonably invisible to the user. (The NAD
also has to know when to throw away buffered data, like when you kill a
process or something, or else you get a couple of screens of unwanted
characters after you thought you'd killed the job).  Of course, you
can't change your flow control characters or method, as that would
require reprogramming the NADs at both ends.

But consider.  Now you have two Un*x systems talking to each other with
UUCP, and the network gets congested.  UUCP needs an eight-bit
transparent path, so it doesn't really handle XON-XOFF.  How is the
network to tell the sending computer that it should stop?  Perhaps you
could reserve special high-priority network connections for uucp, but
that doesn't solve the problem of a user who is perhaps doing file
transfers to his microcomputer from a normal terminal line, or something
similar.  And how about a Diablo terminal, that wants ETX/ACK instead of
XON/XOFF?

And consider a network that is carrying encrypted data.  Is the NAD
supposed to be smart enough to encrypt/decrypt the XON/XOFF?

Point is, hardware flow control is a good answer when transparency is
required in the data stream, as it frequently is.  XON/XOFF worked ok
when its only function was to turn on and off the paper tape reader in a
teletype machine, but the world has moved past that era.  There are
simply too many applications where you don't want to tamper with the
data stream to do flow control.

	Brian Kantor	UC San Diego

	decvax\ 	brian at ucsd.arpa
	akgua  >---  sdcsvax  --- brian
	ucbvax/		Kantor at Nosc