info-terms (06/24/82)
>From KLH@MIT-AI Thu Jun 24 03:19:33 1982
KLH@MIT-AI 06/24/82 06:07:54 Re: Flow control
To: info-terms at MIT-MC
Thought this would be a useful item to get into the info-terms archives.
--KLH
Mail-from: ARPANET site MIT-XX rcvd at 21-Jun-82 2258-PDT
Date: Monday, 21 June 1982 22:57-EDT
From: DPR at MIT-XX
To: Frankston at MIT-MULTICS, POURNE at MIT-MC,
editor-people at SU-SCORE, Goldberg at RUTGERS
Subject: ^S/^Q but not DTR
Remailed-date: 23 Jun 1982 1513-PDT
Remailed-from: J.Q. Johnson <Admin.JQJ at SU-SCORE>
Remailed-to: Editor People: ;
[ Editor's note: The following very complete message on flow control is, I
hope, the last that will appear in Editor-People (unless someone has
novel comments that specifically address the relation of flow control
and editing). Let's move the discussion to Human-Nets. /jq ]
Although I'm not a regular contributor to "editor-people", Bob Frankston
forwarded some comments that Pournelle made about the appropriate flow
control mechanisms for terminals.
As one of the long-time people in the business (not as long as Frankston,
who has been programming since 1963 -- I've been coding since '67), I am
amazed that the "movers and shakers" Jerry refers to know so little about
why the computing world is the way it is, and why we have gone past the
limits of the old technologies that led to the old design choices. In
particular, the use of the control key as an extra shift key goes back to
the widespread use of model 33 TTY's in the 60's which had an extra set of
non-printing chars that could be used when such terminals were hardwired
to computers (the 33 and old systems rarely utilized those chars).
Although modern keyboards are capable of generating all manner of
interesting code sequences, we still see the remnants of those poor
excuses for terminals in today's video editors!!! Surely this is a case
of unnecessary and bass-ackward backward compatibility.
The issues are not that complex, but are deeper than just the concern that
^S steals a useful keyboard character out of the character set. If you
will bear with a detailed explanation, I hope you will see that there is a
technical issue involved in doing it right that needs some fixing by the
terminal manufacturers, and some standardization in the industry to make
it fly. Unfortunately, more chaos (such as the suggestion that DTR be
used in a way that most computer manufacturers and most terminal
manufacturers sensibly don't support) is not helpful to anyone.
Both DTR and XON/XOFF (^S/^Q) flow control approaches are flwed in a
fundamental way -- they don't work well if the source of data is remote
and has significant delay. As communications speeds migrate from the 75
bits/sec that these mechanisms were designed for towards higher speeds and
with networks or front-ends that buffer characters on their way to the
receiver, these ideas are obsolescent or obsolete.
The basic problem is simple: both are based on negative-acknowledgment
("stop now! I can't take it any more") interactions, rather than
positive-acknowledgment interactions ("give me 20 more characters ...
thanks, now I'm ready for the next batch"). In general, positive
acknowledgment approaches are more robust than ones based on negative
acks, since the delay on receiver-to-sender messages does not affect
reliability.
The ideal flow control protocol for terminals is thus one that has the
receiver signalling when it is ready for more chars to be sent. To
enhance performance by keeping those bits flowing, the receiver shoudl
"double-buffer"-- that is, he should divide his buffer space in half, and
send "give me N more characters," where N is the half-buffer size,
whenever the receiver reaches the state where N of the buffer elements are
free. Unless the response latency on the path from rcvr-sndr-rcvr exceeds
the transmission time for N chars, there will be no pauses due to the flow
control (of course if the rcvr is slower than the sender, the sender will
pause.
Now for the buggy flow-control mechanisms:
DTR ON/OFF - is a gross violation of the protocol standard for RS-232C.
DTR off requires the modem to hang up. A better choice would be Request
to Send (RTS), which when off causes the sender to shut up eventually, and
seems to have been intended for this approximate purpose. The problem
here is that RTS or DTR are not defined to have any particular effect on
the sending PROGRAM. Most computers ignore these signals.
XON/XOFF - these at least sort of work over the communications links
between sender and receiver, and fit with the current ascii standards.
Note: ascii reserves the CONTROL characters for CONTROL functions on the
communications line. Terminals should use escape sequences, or
shift-out/shift-in (SO/SI) to get character set additions. I have no
objection to adding a shift key (call it CODE or even CONTROL) that
transmits a sequence like SO-typedchar-SI or ESC-|-typedchar when a char
is hit with the shift key set. The old terminets did that sort of (ESC
worked as a shift key), unfortunately the use of ESC as a raw char in
these editors makes the terminet choice inappropriate.
Both of the flow controls above don't work over long-distance lines too
well, since the round trip delay can be large fractions (1/4) of a second
when Bell starts using satellite links routinely (as she has threatened to
do in the near future). Nor do they work well over many networks.
Consider, for example, a pet project of mine, to get 4800 bps over dialup
lines by using a 4800 bps modem in half-duplex, fast turnaround mode. The
turnaround on these modems is about 50 msec (or about 25 chars), and would
cause 50-100 chars to be lost at the sender when trying to shut him up.
But with a positive ack flow control, all is copasetic, since the sender
will stop occasionally to wait for the positive ack.
By the way, the Xerox 1700 hardcopy printer does flow control in the way I
describe.
Peace --
Prof. David P. Reed