Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!ginosko!uunet!omen!caf
From: caf@omen.UUCP (Chuck Forsberg)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <839@omen.UUCP>
Date: 11 Oct 89 10:49:23 GMT
References: <672.2530C0D4@mudos.ann-arbor.mi.us> <690.25315ee6@simpact.com>
Reply-To: caf@omen.UUCP (Chuck Forsberg)
Organization: Omen Technology Inc, Portland Oregon
Lines: 21

In article <690.25315ee6@simpact.com> jeh@simpact.com writes:
:PEP/uucp spoofing mode.  The uucp acks and naks do NOT get sent end-to-end;
:the modems do their own ACKs, NAKs, and retransmission; a few of the PEP 
:channels are reserved for "supervisory data" in both directions, and so line
:turnaround is not required. 

Perhaps this has changed in newer models, but the TrailBlazers I have
turn the line around when spoofing UUCP.

To answer a previous question about ZMODEM framing overhead I must give
some basics of ZMODEM.  When ZMODEM is in full streaming operation, the
data in a file is sent as a ZDATA header followed by 0 or more data
subpackets whose lengths are 0-1024 bytes.  So in a 16K file with no
errors we could have one ZDATA header (about 11 bytes if CRC-32 is used)
and 16 data subpackets.  Each data subpacket is terminated by two bytes
and CRC.  In a long file sent with CRC-32, the framing overhead approaches
6/1024, or about 0.6 per cent.

To support network operations, ZMODEM protects XON, XOFF, and DLE in both
parities.  This adds just under 3 per cent overhead on typical compressed
files.