Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!teknowledge-vaxc!dplatt From: dplatt@teknowledge-vaxc.ARPA (Dave Platt) Newsgroups: comp.emacs Subject: Re: 9600 baud problems (was Re: when using termcap, get it right!) Message-ID: <14358@teknowledge-vaxc.ARPA> Date: Mon, 6-Jul-87 13:59:59 EDT Article-I.D.: teknowle.14358 Posted: Mon Jul 6 13:59:59 1987 Date-Received: Tue, 7-Jul-87 06:07:00 EDT References: <1373@bobkat.UUCP> <8707061522.AA07395@ucbvax.Berkeley.EDU> Distribution: world Organization: Teknowledge, Inc., Palo Alto CA Lines: 45 In-reply-to: jr@LF-SERVER-2.BBN.COM's message of 6 Jul 87 15:22:59 GMT Posting-Front-End: GNU Emacs 18.41.3 of Tue Apr 7 1987 on teknowledge-vaxc (berkeley-unix) In article ucbvax.8707061522.AA07395, John Robinson wrote: > Hardware flow-control can be based > loosely on this model (Await CTS when you want to send; don't assert > DTR [or else RTS] when you don't want to receive). Urrch! It's probably not a good idea to use DTR for flow-control purposes. Most terminals assert DTR to indicate "I'm powered up and alive"; similarly, most modems look at DTR to see whether the terminal is alive. The standard option-set (or jumper strapping) installed in most asynchronous modems on the market today will cause a modem to drop its transmit carrier and go on-hook (hang up) if DTR is deasserted for more than a very short amount of time (milliseconds, in some cases). Similarly, terminals connected to a host over a hardwired line often wire the DTR signal through to the host as a "terminal is alive" feature (it's connected to the host's Carrier Detect input pin), so that if a terminal is switched off or unplugged the connection will be "hung up". This is an excellent security feature, as it ensures that a timesharing/TP session will be terminated if its controlling terminal is powered off. It's unfortunate, but the standard asynchronous version of RS-232, and the 103/212/V.22 asynchronous modem protocols don't provide a standard end-to-end out-of-band flow control mechanism. The existing send/don't-send mechanism (RTS/CTS) operates only between a DTE (terminal) and its corresponding DCE (modem); there's no way for the equipment at the other end of the conversation to control it. I have seen some systems that have extended (or subverted) the RS-232 interface to provide additional flow-control capability, typically by using one of the optional RS-232 pins (e.g. external clock input / handshake) for a different purpose. These extensions work only on hardwired terminal-to-host connections; if you introduce a full-duplex modem protocol between the host and the terminal, the additional signals aren't carried through. A real solution to this problem would probably require a slight extension to RS-232. It would probably require two additional pin assignments: one output pin to say "please stop sending", and one input pin to receive the "stop sending" signal from the person at the other end of the wire. Extensions to the modem protocols would also be required... perhaps a pair of frequencies at the lower end of the voiceband could be assigned (in the 103/113/212 families). I really doubt that this set of extensions will occur.