Xref: utzoo comp.mail.uucp:5433 comp.dcom.modems:7271
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.mail.uucp,comp.dcom.modems
Subject: Re: What should a new UUCP protocol do?
Message-ID: <15780@cbmvax.commodore.com>
Date: 10 Nov 90 03:48:16 GMT
References: <1990Nov07.155516.17815@ism.isc.com> <1889.2739aa0d@dcs.simpact.com>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Distribution: usa
Organization: Commodore, West Chester, PA
Lines: 33

In article <1889.2739aa0d@dcs.simpact.com> jeh@dcs.simpact.com writes:
> In article <1990Nov07.155516.17815@ism.isc.com>, johnan@ism.isc.com 
> (John Antypas) writes:
> > [...]
> > [...]
> > I've been looking at a modified 'g' protocol using 2K blocks window size 7.
> > Am I completely off track?  
> 
> This is a fine idea, but it isn't really a modified 'g' at all.  'g' supports
> up to 4K packets and a transmit window size of 7.  Some *implementations* are
> restricted to 64 byte packets and a tx window of 3, but there is provision in
> the startup sequence for learning what the other end wants and restricting 
> yourself to that.  So a 'g' that handles 4Kx7 can still talk to one that 
> only does 64x3.  

Note that this isn't precisely true.  Due to an incomplete implemenation of
the negotiation/startup code, most versions of uucp will "negotiate" the
larger packet sizes, but blow off when they scribble past the end of the "big"
buffers.

This requires that either the user be able to specify window/packet sizes
(not a bad idea) or the use of a new protocol designator to indicate a working
"g" protocol.  I believe "G" has been suggested.
 
The problem exists in the versions of uucp that serve as the  base for the
pre-HDB AT&T uucp and the 4.2/3 BSD uucp.  This represents a very large
percentage of the traditional uucp installed base.  I don't recall right off
if HDB does it right, if so then a growing segment of the uucp base could play.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)