Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!ucbcad!ucbvax!LF-SERVER-2.BBN.COM!jr From: jr@LF-SERVER-2.BBN.COM.UUCP Newsgroups: comp.emacs Subject: Re: 9600 baud problems (was Re: when using termcap, get it right!) Message-ID: <8707071528.AA02320@ucbvax.Berkeley.EDU> Date: Tue, 7-Jul-87 11:28:51 EDT Article-I.D.: ucbvax.8707071528.AA02320 Posted: Tue Jul 7 11:28:51 1987 Date-Received: Thu, 9-Jul-87 05:46:39 EDT References: <14358@teknowledge-vaxc.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 >> 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. Oh I know that. But terminals that do hardware flow-control at all have to use some signals (and avoid modems!). I think my message indicated that this is all no help over modems since they only interpret the control signals locally. >> 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. This is all well and good, but now you have to worry about the delay imposed by the modem link. It may use a satellite hop or a slow microwave repeater. The "out-of-band" signal may have a very low baud rate. Most terminals only have a few characters of buffer left when they say stop. >> I really doubt that this set of extensions will occur. Agreed. Better to use a real communications protocol based on packets, like say X.25. Or even Kermit. Not likely to appear in a termial near you soon, but at least PCs generally can all do this sort of thing now. /jr