USENIX Board Studies UUCP

[Gregory G. Woodbury]

In article <36700 at apple.Apple.COM> fair at Apple.COM (Erik E. Fair) writes:
>
>UUCP in its present form is is perfect for telephone based
>interactions; prepare files, place the call, blast the files over the
>phone as fast as you can, hang up, and process what you got in from the
>remote.  You spend minimum time actually on the phone (and therefore,
>you minimize your communication costs).
	Call this point 1
>
>Netnews batching is about as optimal as you can get right now. The only
>way to make it cheaper is to try and figure out what the other guy has
>(i.e. what you don't need to send him) before you call him. Netnews
>already does this to the extent that it has the information (it never
>sends to a site already in the Path: header), but beyond that we need
>information we can't get without making the phone call we're trying to
>avoid in the first place. NNTP cheats, because it can ask before it
>sends and it's not a killer to wait for the answer.
	Call this point 2
>
>UUCP Email, on the other hand, needs work - moving all those little
>files is costly. BSMTP from BITNET land is one obvious alternative,
>particularly since you should be able to compress the batched SMTP
>transactions, and it will eliminate a whole raft of problems related to
>passing Email addresses through the shell on the way to the rmail
>command.
	And this is point 3.

Point 1 and point 2 are (relatively) self-evident.  Uucp does send batches
quite well (up to a point!) and NetNews batching is quite efficient.
However, point 3 does not seem to follow from point 1 - to me it seems that
you contradict yourself (calling uucp efficient in point 1 and inefficient
in point 3).

	The unfortunate truth is that the de-facto 'g' protocol is very
inadequate in certain situations -- just watch the dead time on the line
when pushing 'g' uucp through a 9600 line without a telebit to buffer and
spoof the protocol!  This is especially true when one or both of the machines
have other processes running that make either end miss the window for the
ack.  Waiting for an alarm kills the throughput.

	The other point made by the original message was how to provide
a universal protocol for as many machines as possible!  My binary-only
System V machines have a fair amount of trouble talking to a vanilla
BSD uucp - it takes a lot of fiddling to make it work.  Additionally,
as a binary-only site, I can't add (easily) a new protocol to the uucp
stack.
	A full implementation of a PD or Freely Redistributable uucp-like
exchange system would make a lot of sense - borrow what is good from both
the socket and streams worlds, and provide it as a service.  Allow for
changing the window or packet length, or even other base protocols (like
xmodem or even kermit ;-) and it would be a wonder.  I would possibly
rip uucp out of (some) of my systems and install that!

-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw at cds.duke.edu  ggw at ac.duke.edu  ggw%wolves at ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>