Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: hardware handshaking through a modem
Message-ID: <14043@smoke.BRL.MIL>
Date: 7 Oct 90 07:59:47 GMT
References: <2092@unsvax.NEVADA.EDU>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 28

In article <2092@unsvax.NEVADA.EDU> alfter@uns-helios.nevada.edu (SCOTT ALFTER) writes:
>XON/XOFF handshaking is fine for an interactive session, but what about file
>transfers?  You need all 256 possible byte values available for most file
>transfer protocols ...

This isn't true.  There are two general classes of file transfer protocols;
one of them sends limited-size packets, where the initial connection
negotiation establishes how big a packet can be without the receiver
getting overrun.  In such a protocol, generally a subsequent packet is
not sent until the receiver acknowledges the previous one, which it does
only after it has made room for one more incoming packet.

The other style of serial-line transfer protocol utilizes only a subset
of the available (usually 7-bit) data bit patterns, specifically to avoid
sending a control character by mistake.  There are several obvious ways to
map from generic 8-bit byte contents into less-than-7 bit patterns.  UUCP
typically contains "uuencode"/"uudecode" to handle such a mapping, for
example.

DTR should not be toggled to flow-control a modem, because in many cases
one or more characters have already been sent and disabling DTR will not
stop them from arriving, and at worst will cause that data to be lost.
Similarly, RTS/CTS handshaking generally doesn't work for flow control
either.  Even with DC3/DC1 (XOFF/XON) in-band flow control, you still
need to be prepared to handle a few characters that arrive after you have
requested that no more be sent.  This is simply inherent in asynchronous
full-duplex communication.  Positive-acknowledgement packetizing schemes
avoid this particular problem.