terminal servers and (their) flow control

[Andy Freeman]

Barry Shein, Boston University writes -

	As the world becomes more networked login paths are becoming less
	transparent. Many switches and terminal servers reserve a few chars,
	typically (like our Ungermann/Bass) ^S/^Q for flow control, some sort
	of disconnect character or at least a 'wakeup', and quite possibly a
	DLE (eg. ^P for literally quote next character, this is the ASCII DLE.)
	What happens is that the switch, being overloaded, wants to send a
	^S to the system to stop flow for a while.

	I *strongly* suggest people start fixing software universally to
	accomodate this rather than fighting it.  All EMACS' that I know
	of allow re-definition at the user level of ^S/^Q to some other keys.
	[other suggestions on how to effect the above in 4.2]

Argh!  Networks are supposed to solve problems, not gratuitously add
new ones.  Separating data from control is good; just because current
implementations of traditional human i/o devices (eg ordinary
terminals) don't do a very good job of it is no reason to let other
devices screw up and add to the problem.

Switches, terminal servers, intermediate hosts, etc. are all
computers.  If they've got something to say to each other, they should
and CAN do it out-of-band.  Anything else is like requiring users to
prefix every input with routing info.  (Besides, there are scads of
things for them to talk about, like time-of-day, breath-of-life,
are-you-there, what's-your-sign.  If the separation isn't made, then
soon there won't be any room for what I wanted to "say" or "hear" in
the first place.)  They already have to do some out-of-band
communication, why shouldn't flow control and everything else
mentioned above go in that category?

Yes, there are defective terminals which don't work at the speeds they
are used at.  RS-232 has control lines to help them, but they don't
work over (private) modems, and many computers would ignore them even
if the terminal used them.  There are also no good solutions for
people who overrun the input buffer on the poor machine they're typing
at.  Both of these situations are errors.  (And both can be fixed by
putting the local terminal server in your terminal with an out-of-band
way to talk to you.)

I'm typing this through a (barely) adequate terminal server.  It
manages my multiple connections and does whatever flow control, etc.
it needs (as opposed to what I need) without taking characters away
from my use.  The OS' on my hosts, some of whom are 4.2, think of the
server as another computer and none of the programs I use know what's
going on.

Since it is an ordinary terminal, I have to use an in-band command
sequence to talk to the server, but that's a hardware deficiency.  (It
can do my flow control locally, but it isn't as flexible/programmable
as that provided by the hosts I use.)  I can see asking it to pad my
deficient terminal and even provide some of the sub-functions of a
screen handling package, but I'd rather have a smarter terminal with a
simple integrated server for that and the other obvious features
anyway.

Sorry this got so long.  Dan Ingalls' paper in the first IEEE Software
(last January) covers issues like this much more clearly.

-andy
-------