Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.emacs,comp.terminals
Subject: Flow control
Message-ID: <7109@mimsy.UUCP>
Date: Thu, 18-Jun-87 00:28:50 EDT
Article-I.D.: mimsy.7109
Posted: Thu Jun 18 00:28:50 1987
Date-Received: Sat, 20-Jun-87 00:47:35 EDT
References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM> <6828@mimsy.UUCP> <5988@brl-smoke.ARPA>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 42
Keywords: termcap, curses
Xref: utgpu comp.emacs:1042 comp.terminals:289

In article <5988@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>Railing against the use of DC3 and DC1 for flow control by some terminals
>is pointless -- they need to throttle incoming data, especially at high
>bit rates and when performing complex actions such as line insertion....

They do indeed, but this is not all.  I find it amusing, and somewhat
sad, that all of this could have been avoided quite simply.

There are four independent flow control actions: stop because the
terminal's input buffer is full; restart because the terminal's
input buffer is empty; stop because the user requested it; restart
because the user requested it.  Too few terminals distinguish
between their own stops and user-requested stops.  (Ann Arbor
Ambassadors get this right.  This is not an exhaustive list: that
there are others I do not doubt.)

These actions translate into two terminal-to-host requests: stop,
and continue.  These requests should be distinguishable from all
input events.  Alas, they are not.  Perhaps what we, as users of
terminals, should do is to adopt a new standard that may be
implemented as an option in new terminal firmware.  It would then
be a Small Matter Of Programming to fix host terminal software also
to implement this standard, and terminals that conform to the
standard would have no trouble with flow control.  (I believe such
standards exist, but are not being used because they are, well,
not *standard* enough.  This is a political problem and one I
cannot solve.)

The immediate problem is to distinguish between user input and flow
control sequences.  In the simplest case this can be done with a
form of byte stuffing: one character is defined as an `escape',
and control-S can be represented as escape-s, control-Q as escape-q,
and escape as escape-e.  (Any three value suffice, but if we admit
the possibility of transmission errors, some triples seem better
than others.)  More complex solutions include positive flow control
and perhaps error detection and correction.  In the end, we may
wind up with something like TCP/IP built into the terminals
themselves.  For now, though, I shall muddle along with half-
solutions and a sad smile.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris