Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!sun-barr!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.220121.3532@chinet.chi.il.us>
Date: 28 Aug 90 22:01:21 GMT
References: <1556.26d282ea@dcs.simpact.com> <1990Aug24.152938.7413@chinet.chi.il.us> <1565.26d6609c@dcs.simpact.com>
Organization: Chinet - Chicago Public Access UNIX
Lines: 65

In article <1565.26d6609c@dcs.simpact.com> jeh@dcs.simpact.com writes:

>These links provide an error-free path, no?  There is already the "f" protocol
>which is intended for use through mostly-error-free, flow-controlled links.  It
>sends a single checksum at the end of the entire file, relying on the network
>to get the data through and relying on the fact that while the RS232 (or
>whatever) connection to your local modem may not be perfect it is quite close. 

I believe that "f" protocol is for 7-bit links and thus adds a lot of
overhead, and not everyone has it.  "e" protocol works if the link is,
in fact, error free (i.e. a network with end to end error control), but
again, not everyone has it.

>> The big hangup here is that you need a source license to begin with, and
>> then you can't distribute copies.  Does anyone have a HDB compatible
>> uucico that can be freely distributed? 

>well, how "compatible" does it have to be?  DECUS uucp uses old-style spool
>file names and a single spool directory but talks to HDB systems just fine.  It
>also has the best login and dialer scripting capability of any uucp arround
>(not just my opinion). 

I had in mind just dropping a new uucico into a standard HDB program set.
Uucp, uux, uuxqt all work just fine.  The only thing lacking in the
dialer scripts (since \M,\m was added) is the ability to adjust speeds
to match up with a modem that sync's with the answering end, and perhaps
a "reset" script.

> .... so I have declared it to be in the public domain. 

How can I get a copy? 

>We are going to go to neighbor-system-specific spool directories for the next
>release.  (Right, Mark? :-)  HDB-style permissions files are so bizarre that
>we'll be doing something different.  

Hmm, nothing wrong with HDB permissions here except that a syntax error
in the file will make uucico silently fail.  Perhaps under VMS you
can do something better than the LOGNAME/MACHINE setup that is needed
under unix.

>> I'd like to see a protocol where you could specify a minimum and
>> maximum packet and window size per host, device and dialer.  

>we support this in 'g' via an options field in the entries in the systems file.

You need it for the devices file also, since you may have many
choices for connections to the same host.  The differences in dialers
could be accomodated by multiple entries for the same device.

>Unfortunately, in order to use this with TrailBlazer modems, we'd have to
>abandon their fabled 'g' protocol spoofing.  a TB in g-spoof mode  not only
>"knows about" the data link level, it looks for and interprets the "messages"
>(S, SY, CY, etc.) that mark the beginning and end of a file transfer.  It has
>to, because it has to know to flush its buffers and prepare for line turnaround
>when the sending system sends the last packet of a file. 

Or you could just spoof the spoofing.  Pretend you were sending one big file
with the normal 'g' protocol (perhaps making it look like a cpio archive
of all the files you want to send) and let the other end extract them back
out.  This presents the problems of refusing transmissions (who cares?) and
restarting after an interruption (possible, but perhaps not worth the trouble).

Les Mikesell
  les@chinet.chi.il.us