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.