Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!netnews.upenn.edu!dsinc!ub!boulder!ncar!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: What should a new UUCP protocol do?
Message-ID: <1990Nov16.060148.2194@chinet.chi.il.us>
Date: 16 Nov 90 06:01:48 GMT
References: <1990Nov07.155516.17815@ism.isc.com> <1990Nov09.230452.6549@chinet.chi.il.us> <8290@gollum.twg.com>
Distribution: usa
Organization: Chinet - Public Access UNIX
Lines: 94

In article <8290@gollum.twg.com> david@twg.com (David S. Herron) writes:
>>(it's not really necessary to ACK every packet, but it may be desirable
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yeeaaaahh.. that makes
>me shudder.. how do you tell the difference between a lost NAK & an ACK
>which you ACK'd without ACKing? 

Easy - you just send the packet number of the last received packet back
in the ACK packet.

>Now.. if your protocol did a "mass ACK"
>by, for instance, saying "this ACK is for packets 1,3-5,7,8-12" then the
>cost of ACKing is greatly reduced.  Is this what you mean?

Almost, but all you have to do is assume that any ACK ack's all previous
packets.  First, this means that lost ACK's within the transmit window
can simply be ignored, but more importantly the speed of error recovery
is tied to packet size and skipping some of the ACK's intentionally will
be more efficient where there is a high-turnaround time or packet charge
on the reverse direction without increasing the time it takes to NAK
a bad packet.  Ideally, you would ACK slightly before the transmit window
is filled (i.e. soon enough for the ACK to get back before transmision
stops), but on links that are generally error-free the transmit window
could be huge.

>
>erm.. why would it be good for the communications protocol to pick out
>the compression scheme?  The protocol doesn't know a bit about what
>kind of data it's transmitting &so can only use some generic scheme.

I meant that it should try to apply one or more generic schemes and each
packet would carry a compression-type code.  If none of the schemes work
to actually compress the data, it could be passed through uncompressed
on a packet-by-packet basis and thus never cause an expansion of more
than the type code in the packet header (unlike the normal compress
program when used in a pipe). 

>Instead I feel that it'd be best for the compression to be done outside
>the protocol -- like it's done now with Usenet news.

Do you enjoy providing the disk space for both compressed and uncompressed
copies?

>using compress v4 ...  Note that for CPU load it (probably) doesn't
>matter whether the compression is done in uucico or in a seperate program,
>it's still CPU time on the local system.  Finally -- adding compression
>into a protocol module will make it larger, make it take longer to write,
>and longer to debug.

Like the CPU time, it's all the same one way or the other.  It's going to
take the same amount of work on the compression module whether it is
linked into the communication code or not.  If it's not, it will always
require intermediate disk space to use, and will be more difficult to
arrange to happen on remote requests.  There will be situations where
the link is cheaper than the CPU at one or both ends, something in the
link already does compression, or the data is always pre-compressed, so
there is still the need to disable it, in which case the type code can
be omitted from the packet header.

>Note that mail isn't currently compressed.  It would be pretty simple to
>write an rmail which recognized that the input was compressed, after all
>that's why compress-v4 has it's own magic number, and decompress it before
>doing anything else.  But I *gaurantee* that it'd be a looooong time before
>that was supported very widely..

Do you really want to write a high-level front end for everything that
involves communications?  Do you want it to know which links need
compression and which ones don't? If you want things compressed specifically
because they are going across a slow and/or expensive link, then the
thing to do is to tie the compression specifically to the transport
across that link.  The other problem with mail is that it usually
consists of lots of little files which don't compress well unless you
batch them, and you can't batch them easily unless you impose an arbitrary
delay on delivery.  The cleanest solution is to do the compression
on the fly and allow multiple files to be outstanding in the transmit
window, even though this will introduce some new problems to deal with.

>>The one other thing that might be considered is a way to escape certain
>>control characters within the protocol.

>The PhoneNet protocol (available in the MMDF sources but it's history
>starts in a different place than MMDF) does exactly that. 

Unfortunately it would be impossible to negotiate the 2nd most likely
situation and remain compatible with existing uucico's.  This
is the case where you are connected over something that looks like an
X.25 PAD and the DLE character is used to get the PAD's attention instead
of being passed through.  Uucico uses DLE as a start-of-packet character
even during the initial negotiations before the protocol is selected.
You could, of course, give the program a different name and recognize
a new start-up mode when that name is used, but then it becomes more
difficult to install and maintain.

Les Mikesell
  les@chinet.chi.il.us