Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site cbosgd.UUCP
Path: utzoo!linus!decvax!harpo!floyd!vax135!ariel!houti!hogpc!houxm!ihnp4!cbosgd!mark
From: mark@cbosgd.UUCP
Newsgroups: net.dcom
Subject: Re: In defense of XOFF/XON flow control
Message-ID: <570@cbosgd.UUCP>
Date: Thu, 10-Nov-83 01:12:58 EST
Article-I.D.: cbosgd.570
Posted: Thu Nov 10 01:12:58 1983
Date-Received: Sat, 12-Nov-83 00:00:46 EST
References: <257@decvax.UUCP> <1388@utcsstat.UUCP>, <1377@rlgvax.UUCP>
Organization: AT&T Bell Laboratories, Columbus
Lines: 49


	^s and ^q are just characters. Making them magic was an awful kludge.
	The way hardware manufacturers implemented it was worse than a kludge,
	in many cases it was gross incompetence. Let's put this one to rest,
	now, huh? Surely we can come up with a better way to do handshaking!
Sorry, but this is false.  There is no such character as control-S or
control-Q.  Look in your ANSI standard.  There ARE characters DC3 and DC1,
which happen to have the binary representation we are all thinking of.
In the interests of being able to generate all characters from all
keyboards, terminal manufacturers have arranged that the keystroke
control-S produces DC3, and control-Q produces DC1.  This does not
alter the fact that characters 00-1F are specifically set aside for
control functions.  The fact that many systems do not make use of all
of these "control characters" has allowed people to write software that
uses them as "just characters".  (EMACS is an example.)  This does not
mean that someone who implements XON/XOFF handshaking (the defined
semantics of DC3/DC1, or at least one of them) are wrong, it means
the people who used the control characters for their editors are the
ones who violated the standard.  (vi is guilty too, although to a
lesser extent: it uses, for example, control-G as a command.  It does
not use ^S or ^Q.)

The MIT point of view (very vocally defended by RMS, the author of
the original EMACS) is that delays should be done with padding, or
with packet switched networks.  Ideally, terminals should be used
that do not require padding (there are a few out there) even at 9600
baud.  Otherwise, you pad or do something transparent.  But they very
strongly feel that xon/xoff should not be used by terminals.  They do
have some valid points - xon/xoff does not always work well over a
network, and it does break EMACS, which has ^S and ^Q commands.

However, the other side of the coin is that many terminals run much
better using xon/xoff than with padding, since the padding has to be
worst-case, and if the terminal has a buffer it can often do a lot
better than worst case.  While one might claim that, since some
terminals do not need any padding, all terminals should be designed
to not need padding, the facts remain that (a) there are a LOT of
terminals out there that do need some padding, although usually very
little (the HP 2621 and Ann Arbor Ambassador are two good examples),
and of course there are lots of vt100's; (b) there are some features
that require flow control to implement, e.g. smooth scrolling ("ooze
mode", as we call it), and (c) some kinds of terminals cannot be
implemented without flow control - in particular, bitmapped terminals
scroll slowly and so need flow control.

In the ideal world, all terminals will support a packet switched network
which does flow control in a totally transparent way.  I'm not holding
my breath.

	Mark