Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!apple!motcsd!mcdcup!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: How efficient/fast is uucp?
Message-ID: <1990Aug28.212355.2806@chinet.chi.il.us>
Date: 28 Aug 90 21:23:55 GMT
References: <1556.26d282ea@dcs.simpact.com> <1990Aug24.152938.7413@chinet.chi.il.us> <1990Aug25.144323.10811@DSI.COM>
Organization: Chinet - Chicago Public Access UNIX
Lines: 35

In article <1990Aug25.144323.10811@DSI.COM> syd@DSI.COM writes:
>
>>>Technically:  There is a "protocol negotiation" sequence in the uucp startup, 
>A new protocol will only handle the actual sending of a single request
>itself.

If you just drop a new protocol into the existing routines, that would
be true, but it would also be possible after the protocol negotiation
to drop into an entirely new mode.

>If you are a mail site, and sending lots of small messages for mail,
>then you can improve your throughput by switching to a different
>mail protocol, such as BSMTP, still sent via uucp, instead of rmail.

But only if you are willing to delay mail while your mailer attempts
to bundle requests.  A single message sent BSMTP will still cause
2 files to be sent via uucp.

>If its a packet link, then just a protocol with a larger window and
>selective reject would be needed.  Again, its only the transfer of
>a single file that can be improved by changing the 'protocol' module
>within uucico.  You would need a whole different concept as a file
>transfer device to improve more than that, and then it wouldn't 
>be uucico.

No, it would still be uucico as long as it can negotiate and use 'g'
protocol.  It would be much more complicated to stream files, though
since you would need to delay deleting the request from the sender's
queue until the ack comes back, which might cause a job to be resent
later accidentally if the connection is broken at the wrong moment.
Saving status between calls with a startup negotiation that includes
"last packet received" could avoid that problem, though.

Les Mikesell
  les@chinet.chi.il.us