Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umn-cs.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxl!houxm!ihnp4!stolaf!umn-cs!smith
From: smith@umn-cs.UUCP
Newsgroups: net.dcom
Subject: Re: XON/XOFF as flow control? - (nf)
Message-ID: <356@umn-cs.UUCP>
Date: Thu, 10-Nov-83 21:01:17 EST
Article-I.D.: umn-cs.356
Posted: Thu Nov 10 21:01:17 1983
Date-Received: Sat, 12-Nov-83 12:09:08 EST
Sender: notes@umn-cs.UUCP
Organization: Computer Science Dept., U of Minn, Mpls, MN
Lines: 24

#R:umcp-cs:-363600:umn-cs:1600004:000:971
umn-cs!smith    Nov 10 09:53:00 1983

   The problem about network processing of Xon/Xoff exists primarily in
poorly designed network frontends.  A proper design (i.e. the Arpa TIP's
handling of Xon/Xoff) intercepts Xon/Xoff locally and converts them into
network level flow control actions.  It is wrong to let the host's
application software or 'terminal emulator' handle that kind of flow 
control.

   If we COULD change the Xon/Xoff characters to something else then we
could change it from a troublesome 'stop/go' protocol into a more effective
(and easier to handle) 'go ahead' protocol as laura pointed out.  But I
wouldn't hold my breath -- as recently as last year I was using a 'state
of the art' timesharing system supported by a 'major manufacturer' which
had NO terminal flow control support at all.  

   As an Emacs afficinado I can only cringe at the ^S problem since it
routinely afflicts me with two mutually exclusive 'standards'.

Rick.
[smith.umn-cs@Rand-Relay]
 [...ihnp4!umn-cs!smith]