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