Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!styx!ames!ucbcad!ucbvax!CC5.BBN.COM!jr From: jr@CC5.BBN.COM (John Robinson) Newsgroups: comp.emacs Subject: Re: What's wrong with flow control? Message-ID: <8612011729.AA28159@ucbvax.Berkeley.EDU> Date: Mon, 1-Dec-86 12:17:23 EST Article-I.D.: ucbvax.8612011729.AA28159 Posted: Mon Dec 1 12:17:23 1986 Date-Received: Mon, 1-Dec-86 20:36:35 EST References: <2660@osu-eddie.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 71 Karl Kleinpaste writes: >> That's what CTS & RTS (clear-to-send and request-to-send) are for: >> hardware handshaking. And if UNIX tty drivers and related hardware >> were set up to do it properly, that would be the way to go. >> Otherwise, the solutions are either to make a terminal for which >> padding can be sufficiently easily specified, so that you basically >> trust the terminal not to get behind and screw up; or just make a >> terminal whose firmware is faster than its fastest data rate. (Don't >> laugh, it's not that difficult. It's a poor commentary on DEC et al >> that they can't do so themselves.) True enough. We made this work in BBN's Unix machines. It was neat to run a terminal at 19200 with no padding in RAW mode and have it drop nothing, even though the terminal was fairly fancy and unable to keep up with XOF/XON. (The Unix machine of course could :-). The question of what to consider "control" characters has no clear answer, as the other postings on this topic have pointed out. ASCII does single out the control characters (\000 through \037) and RUBOUT (\177) for special treatment, but it also allows for "transparent" operation, where no characters are special. RMS clearly prefers the latter, and for some applications, such as binary file transfer with trustworthy lines, it is a big win over other techniques that avoid the control characters. The trouble with RTS/CTS (or other modem control signal use) is that it is hard to pass them through modems, especially in full-duplex operation, and you can't use them with any network that provides "transparent" terminal connections. "Network" here must be general enough to include such things as fancy rate-adaptive modems like Microcoms or (I think) Trailblazers. So what to do? One approach, advocated in this list, is to accept the non-transparency of XOF/XON and get by with other characters or sequences (ie, ^\ or ESC-S), using the unused control characters. While this risks the possibility that some other terminal/modem/network will preempt another control character someday, this is probably unlikely to happen now that so much async ASCII stuff is out there. (I once was exposed to a terminal that displayed only upper case and used the lower case characters for terminal control. Ouch!) The other approach is to define more elaborate framing rules, which is what synchronous protocols do (like X.25, Binary Synchronous or HDLC). Although these tend to be associated with synchronous transmission, in fact binary synchronous and other protocols (eg DDCMP) are perfectly happy to run over async lines. The "frame" of async ASCII is the (typically 8) data bits between the "start" and "stop" framing bits. To get more elaborate, you have to put more bits in. The typical way to do this is to build multi-character frames using some of the ASCII characters as delimiters, and then devise ways to send the framing characters when they appear in the data stream. Now the bits within the frame can have uses other than data, like sequence numbering, acknowledgment, checksum, etc. and you can build up a pretty sophisticated protocol if you wish. In particular, positive-acknowledgment protocols, advocated in another message on this topic, are possible, with windowed flow control, multiple logical channels, and so forth. The US ANSI committee X3S3.4, of which I am a member, has proposed an addition to the ISO HDLC standard that would add just such a framing technique for sending HDLC-family protocols over asynchronous hardware. This would permit software on PCs, for example, to use HDLC, X.25, or SDLC protocols with only asynch hardware and modems. It has been introduced to ISO; we'll see where it goes. /jr ps. posted only to unix-emacs/comp.emacs. If someone would like to cross-post to the other list mentioned, please feel free.