Xref: utzoo comp.mail.uucp:5436 comp.dcom.modems:7280
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!usc!ucsd!nosc!crash!simpact!jeh
From: jeh@dcs.simpact.com
Newsgroups: comp.mail.uucp,comp.dcom.modems
Subject: Re: What should a new UUCP protocol do?
Message-ID: <1898.273bd977@dcs.simpact.com>
Date: 10 Nov 90 18:41:59 GMT
References: <1990Nov07.155516.17815@ism.isc.com> <1889.2739aa0d@dcs.simpact.com> <+2m8g2.lb1@smurf.sub.org>
Organization: Simpact Associates, San Diego CA
Lines: 52

In article <+2m8g2.lb1@smurf.sub.org>, urlichs@smurf.sub.org 
(Matthias Urlichs) writes:
> In comp.dcom.modems, article <1889.2739aa0d@dcs.simpact.com>,
>   jeh@dcs.simpact.com writes:
> < [uucp g negotiates packet and window size]
> < yourself to that.  So a 'g' that handles 4Kx7 can still talk to one that 
> < only does 64x3.  
>
> Sorry, but no.
> 
> Lots of g's _think_ they can do 4K packets, but internally they use some
> stupid small buffers anyway because the support for big blocks hasn't been
> tested in the last ten years or so.

Hmmmmm.  Well, if one still wanted to stay with "g", this would be fixable with
an option in the systems file entry(ies) for those hosts.  "When talking to
this host, restrict packet size to n, and window size to m."  

> You'll also run into trouble if you try to talk to a Telebit with UUCP
> spoofing enabled, and want to use bigger blocks.

THis I have not seen -- I have tested a 7x4k g through a TB+ and it works fine,
though it only runs 3x64.  Ad I don't know why there should be trouble.  The 
packet and window size negotiation is not really "negotiation", it is each
receiver telling the sender "this is the biggest number I can handle", and
the sender is expected to comply.  If the telebit tells me that it won't take
more than 3x64, that's all I'll send.  And if I tell the telebit that I can take
7x4K, but it only chooses to send me 3x64, that works fine too.  And that is 
exactly what happened in my tests, confirmed both by debug output and by line
analyzer.  

> Actually, it might be sufficient to NAK packets if there's an error but to
> keep quiet otherwise. Using UUCP, this is OK because you're transmitting a
> file and the sender can always back up as far as the receiver wants it to.

Sounds like zmodem.  Which is not intended as a pejorative statement -- just an
observation.  

> One problem that you're not going to cure with this is that if you have a
> full duplex  link, about  half the bandwidth is wasted. Fixing this would
> probably require major mods to the uucico's involved.
> 
> Hmmmm ... Thinking some about this ... you could possibly fake it by ...

Someone actually hacked this together a year or so ago.  As I recall he never
did get it working perfectly but I am sure this was just an implementation bug
and not a real flaw in the design; the design looked fine. 

	--- Jamie Hanrahan, Simpact Associates, San Diego CA
Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG 
Internet:  jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!jeh