Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.dcom
Subject: Re: XON/XOFF as flow control?
Message-ID: <981@utah-gr.UUCP>
Date: Sat, 12-Nov-83 01:47:39 EST
Article-I.D.: utah-gr.981
Posted: Sat Nov 12 01:47:39 1983
Date-Received: Mon, 14-Nov-83 02:28:26 EST
References: watcgl.1063
Lines: 24

Just as a counter-example to the "do xon/xoff locally, use out of band
flow control over the network" scheme, I present the DEC-20.  Assume:
	1. You have a device such as LocalNet which allows you to do
	   Xon/Xoff flow control at the terminal end, and out-of-band
	   flow control at the other end.
	2. You have a DH or equivalent (e.g. Able's) which supports
	   o-o-b flow control on your DEC-20.

Now, you are "fooling" the DEC-20 into thinking that it is never flow
controlled since the flow control is happening in the DH (the right
place).  However, the DEC-20 has built into its terminal handler a
"reasonableness" check on how long it takes to output a string.  If it
takes "too long" (twice as long seems to be ok, at least), the CPU
assumes something is wrong and the front-end crashes.  Oops.

(on the other hand, when you send the ^S through the net to the DEC-20,
it takes another line or so to stop, usually.)

Oh, in response to the person who wondered how you do delays if you
throw away nulls - I think you misunderstood the original statement. 
The nulls are thrown away by the TERMINAL as they are received, not by
the CPU.  Therefore they still perform their padding function.

=Spencer