Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcsstat.UUCP
Path: utzoo!utcsstat!laura
From: laura@utcsstat.UUCP (Laura Creighton)
Newsgroups: net.dcom
Subject: Re: In defense of XOFF/XON flow control
Message-ID: <1388@utcsstat.UUCP>
Date: Sun, 6-Nov-83 22:24:41 EST
Article-I.D.: utcsstat.1388
Posted: Sun Nov  6 22:24:41 1983
Date-Received: Mon, 7-Nov-83 09:55:40 EST
References: <257@decvax.UUCP>
Organization: U. of Toronto, Canada
Lines: 41

Arrrgh, Martin, We *know* that XON/XOFF works in all sorts of environments!
But it is a *bad thing*. I print a binary file by mistake and this terminal
which thinks it is in VT100 emulation mode gets too many ^s/^qs for its
little microprocessor to handle. It goes into infinite reset-screeching-
there-is-something-terribly-broken mode. This leads to terminal wars.
Who can send all the other users packing first by writing obnoxious files
all over their terminal. Stage two -- who can find the shortest file
that will do the same. Stage three (either only played by super-users, or
on people with writable .profiles) -- who can insert 'cat obnoxious' onto
the end of everyone's .profile...

There are an endless variety of these. 

Then there are hardware manufacturers who think that 3 chars is plenty of
time for one to stop when it sends a ^s. Stick one of those off a 9600 baud
line, and watch yourself lose *whole* *paragraphs* of text. Exactly what
you want on a hard copy printer.

Now you get other terminals that treat ^s unconditionally as magic. I write
a communications package that runs in raw mode. To watch and see if the
handshaking is going okay, I have what is going on echoed onto my terminal.
Whoops, there is a ^s in the input. The terminal, which handles other
control characters just fine, goes into amnesia mode and has to be
powered off before it will stop beeping at me. And i have to find a
new way to debug it which involves the LINEPRINTER. Yuck.

^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!

Negative acknowledgement is a *bad idea*. You don't really want your
devices screaming STOP STOP at you -- what you want is for them to
say "go ahead" if they are going to have trouble with arbitrary amounts
of data. Perhaps this was not obvious when the protocol was developed,
or perhaps there was no way to do it. But this is no reason to perpetuate
a mistake.


Laura Creighton
utzoo!utcsstat!laura