Xref: utzoo comp.mail.uucp:5427 comp.dcom.modems:7266
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.mail.uucp,comp.dcom.modems
Subject: Re: What should a new UUCP protocol do?
Message-ID: <+2m8g2.lb1@smurf.sub.org>
Date: 9 Nov 90 20:10:47 GMT
References: <1990Nov07.155516.17815@ism.isc.com> <1889.2739aa0d@dcs.simpact.com>
Organization: University of Karlsruhe, FRG
Lines: 54

In comp.dcom.modems, 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.  
< 
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.
You'll also run into trouble if you try to talk to a Telebit with UUCP
spoofing enabled, and want to use bigger blocks.

< If the modems do NOT give you a reliable data link, you are back to acking
< each packet.

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.

< [...]  Also note that, for a
< scheme where packets are numbered modulo 'n', the maximum transmit window
< size for a retransmit-entire-window protocol like 'g' is n-1, but for a 
< selective reject protocol it is (n/2)-1.  
< 
It might be a better idea to just use the offset into the file you're
transmitting. That way you wouldn't need to worry about windowing and the
machines involved could agree on these things on a dynamic basis.
(On the other hand, you'd also need a start character, and some size
 information, and a CRC checksum, and that might incur too much overhead. :-( )

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 talking
to  a sending and a receiving uucico across two pty ports, and multiplexing
the resulting full duplex data stream yourself. Hmmm --- that way you
wouldn't even have to modify your uucico. If I had enough time I would do
this -- the idea certainly looks like it would work.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/