From: utzoo!decvax!ucbvax!info-terms Newsgroups: fa.info-terms Title: Flow control Article-I.D.: ucbvax.7757 Posted: Thu Jun 24 03:19:26 1982 Received: Sun Jun 27 23:03:13 1982 >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. JohnsonRemailed-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