Xref: utzoo comp.mail.uucp:5434 comp.dcom.modems:7277
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp,comp.dcom.modems
Subject: Re: What should a new UUCP protocol do?
Message-ID: <1990Nov09.230452.6549@chinet.chi.il.us>
Date: 9 Nov 90 23:04:52 GMT
References: <1990Nov07.155516.17815@ism.isc.com>
Distribution: usa
Organization: Chinet - Public Access UNIX
Lines: 55

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?  Obviously, this works best with ASCII files
>in bulk like Batch SMTP.

How much work do you want to do?  I'd start by making the packet and
window sizes negotiable, as well as the frequency of ACKs desired
(it's not really necessary to ACK every packet, but it may be desirable
to use small packets so you can request a resend of a small piece when
necessary).  Then I would allow a configuration file setting for the
initial values and minimum and maximum limits for each of these variables
for each entry in Systems, Devices, and Dialers (actually the equivalents
as per Sysfiles), plus an entry for inbound devices.  When this new protocol
is agreed upon, each machine would take the smallest of the values from the
relevant entries and pass to the other machine, and the smaller of
the two values for each variable would be used for the session.  This
would allow the best values for the most limiting factor, whether it is
the destination machine (Systems), the modem setup (Dialers), or the
communications link - modem/PAD/satellite (Devices).  The session would
start out with the pre-set initial values and increase the values to the
maximums after a few error-free packets - any errors would drop the values
to the mimimum and several error-free packets would be required before
working upwards again.  A log of the errors would make it possible to
optimize for any type of link.

Compression would be another possibility at this level but it should also
be controlled by the config files so it could be disabled where something
in the link compresses for you or one of the machines doesn't want the
CPU overhead.  It should also be done on a per-packet basis (though not
necessarily alligned with the communications protocol packets) so that
already-compressed data will never expand by more than the packet headers.

The next thing to tackle would be windowing the per-file ACKs.  That is,
do not wait for permission to start sending a file on start-up (but let
the receiver discard and cancel) and do not wait for the final ACK after
each file before sending the next.  Doing this correctly will require some
state information to be saved between sessions to detect cases where
a file is transferred correctly but the ACK does not get back to the
sender (this happens now, but with a maximum of one file per session and
uux jobs typically take at least two files for the receiver to be able
to execute anything). This part is likely to be the hardest to work
into the existing scheme, but it is the most significant if you transfer
a lot of small mail messages and don't want to impose the arbitrary
delays to apply some other form of batching.

The one other thing that might be considered is a way to escape certain
control characters within the protocol.  I'm thinking specifically of
links that need (or work best with) xon/xoff flow control and/or have
a data-link escape character that normally doesn't pass through, but
it would be nice to generalize this into something that could be specified
in the config files.

Les Mikesell
  les@chinet.chi.il.us