chris@mimsy.UUCP (06/18/87)
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
drw@cullvax.UUCP (Dale Worley) (06/18/87)
(Note: RLK, your messages start with: From: rlk@.COM (Robert Krawitz), which is probably wrong.) Well, it's all well and good to talk about buffering as a way to reduce flow control, but I can't see any way to get the guaranteed-no-flow-control rate any better than the slowest operation the terminal supports. For example, if it takes 18ms to scroll, and the computer sends 10^6 ^J's, if you permit them to be sent much faster than one character per 18ms, you're going to have to buffer 1 MB of data. Ugh! Can you imagine how long it will take to get ^C to stop output? Now, if you can load-shed, say by performing a several-line scroll in the same time as a one-line scroll (bit-map displays are like this), then you can effectively just keep an up-to-date screen image in memory and update the real screen as time permits. Ultimately, ^S/^Q flow control is a quite reasonable concept if (1) the host software is assumed to not understand screen sizes, and so when you 'cat foo', you want to be able to stop the output and examine it (VT100 'smooth scroll' is a variant of this), and (2) there is no reliable 'extra' data path available. It's only recently when people have started using Emacs as a total user environment that (1) has been avoided in a significant fraction of common usage. No one uses a glass tty at 9600 baud! Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw "President Nixon has just lowered the speed of light to 55 mph. At what speed can 2 colliding VW's of mass m = (number) produce a 3rd VW?"