Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: New UUCP Protocol (was: Re: Zmodem added to UUCP)
Message-ID: <9769@chinet.chi.il.us>
Date: 8 Oct 89 22:28:43 GMT
References: <1024@faatcrl.UUCP> <710@lakart.UUCP> <1029@faatcrl.UUCP> <688.252e37c2@simpact.com>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 20

In article <688.252e37c2@simpact.com> jeh@simpact.com writes:

>Allowing 512-byte packets increases the theoretical max from 219.4 char/sec
>to 237.2, a whopping 8% increase.  Not a big deal.  And, as someone else 
>said, increasing the packetsize increases the expense of error recovery.  

>How would ZMODEM be a big improvement???

The problem with 'g' is that the maximum window of unack'ed data is
7 * 64 char packets, and most hosts won't allow more than 3 packets.
When you try to use this protocol over a connection that has a long
turn-around time (satellite links, busy packet nets, modems that
fake full-duplex by turning the line around, etc.), the sender ends
up waiting for ack's instead of driving the link at full speed.
Increasing the packet size is a quick and dirty fix, but what we
really need is an intelligent handshake between hosts that describes
the best way to handle the connection, along with reasonable fall-back
if the error rate is excessive at a large block/window size.

Les Mikesell