Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!coherent!dplatt
From: dplatt@coherent.com (Dave Platt)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <36136@coherent.coherent.com>
Date: 9 Oct 89 18:06:19 GMT
References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com> <1032@faatcrl.UUCP> <1989Oct9.003603.3693@esegue.segue.boston.ma.us>
Reply-To: dplatt@coherent.com (Dave Platt)
Organization: Coherent Thought Inc., Palo Alto CA
Lines: 52

In article <1989Oct9.003603.3693@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
> Zmodem is undoubtedly a better protocol than 'g' for a full-duplex
> transparent connection such as that provided by 2400 bps modems, 9600 bps
> V.32 modems, or by packet switch networks.  PEP, though, is really a
> half-duplex protocol, and fakes full-duplex by turning the line around.  That
> means that the zmodem ACK packets cause a performance hit and spoofing would
> still be a win.

In its normal, streaming mode, the ZMODEM protocol does not send ACKs
during data transmission... only at the end of the file.  NAKs are sent
whenever data transmission errors occur.

The only time I've found it necessary to switch ZMODEM over into a
windowed mode of operation is if the transmitting system is sending data
faster than the receiver can gobble the data, and the transmitter
doesn't support flow control.  In this situation, ZMODEM does use
periodic ACKs, and these could (as you suggest) slow down a PEP transfer
if they caused more-frequent line turnarounds.

I believe that a ZMODEM streaming transmission through a TrailBlazer
would not require any more line-turnarounds than the spoofed UUCP
protocol through the same modems.

> If someone who actually understands the details of how Telebit's spoofing
> works, and what sort of protocol they really use, that would be great.  PEP
> uses a large number of very slow channels, and I don't know whether spoof
> mode means that they use a few of the channels for the ACKs and the rest
> for the data, or if they use bigger blocks and still turn the line around.

The latter (bigger blocks, with occasional line turnarounds).  You can
hear this quite easily if you configure the modem to leave its speaker
turned on during a session.  To my ear, a spoofed reception of a big
file sounds like "chuffa-chuffa-chuffa-chuffa (pause) CHUF (pause)
chuffa-chiffa....".  A _long_ block arrives (1-2 seconds worth), the
line is turned around, the local modem sends back an ack/nak packet, the
line turns around again, and the remote modem sends the next block of
data (with, if necessary, any packets from the prior block that required
retransmission).

I believe that a streamed ZMODEM transmission would sound, and behave,
in very much the same manner.

The UUCP-spoofing used by the modem has the effect of converting the
uucp protocol from a sliding-window, remote-acknowledge protocol into
something very similar to a streaming protocol with modem-based flow
control.

-- 
Dave Platt                                             VOICE: (415) 493-8805
  UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: dplatt@coherent.com
  INTERNET:       coherent!dplatt@ames.arpa,  ...@uunet.uu.net 
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303