Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!lll-lcc!pyramid!ncc!lyndon
From: lyndon@ncc.UUCP
Newsgroups: comp.os.minix
Subject: How uucp handles incoming files
Message-ID: <1382@ncc.UUCP>
Date: Sat, 4-Apr-87 04:12:39 EST
Article-I.D.: ncc.1382
Posted: Sat Apr  4 04:12:39 1987
Date-Received: Sun, 5-Apr-87 09:43:16 EST
References: <480@gouldsd.UUCP> <43183@beno.seismo.CSS.GOV> <7326@boring.mcvax.cwi.nl>
Distribution: comp
Organization: Nexus Computing Corp.,  Edmonton, AB
Lines: 54

In article <7326@boring.mcvax.cwi.nl>, jack@mcvax.cwi.nl (Jack Jansen) writes:
> [...]
> If you only count the time uucp takes to transfer bytes, this is true.
> However, if you add the time taken to deposit files in the appropriate
> places, *which kermit does during conversation*, things get far worse.
> 
> I'm not sure how fancy uucp's like honey-danber handle this, but one of
> the gross misfeatures of most uucp's is that they deliver files while
> they're still eating phone time. This, combined with the fact that, for small
> files, the overhead is enourmous (two files transmitted for each tiny
> mail message) makes me dislike uucp.

Not quite true! When uucp is *receiving* a file, it goes into the spool
directory with a name like TM.process_id.sequence. Once the *entire*
file is received (correctly we presume), *then* it is renamed to
[DX].site_grade_sequence. This involves only a rename of the file
(not a copy) which is generally quite efficient under Unix. It also
prevents partially sent or corrupted files from showing up as
being complete and accurate (think of 'f' protocol which sends only
a checksum at the *end* of the file).

The overhead of sending the control files is also quite small. A quick
scan of our spool directory shows and average byte count of 58 for the
D.nccX* files. Remeber that the C.* files are not transferred - they
tell the local uucico what files to send where.

About the only time "delivering" files becomes a problem is when
someone dumps across a large file, and specifies a destination
path not in the same file system as your UUCP spool directory. In
this case, an explicit copy and delete must take place.

After spending quite a bit of time babysitting UUCP and a bunch of
news feeds, the big gripe I have with uucico is the time it spends
searching the spool directory for work files. In the early days of
Bnews 2.11 our main newsfeed had a problem with the HIDDENET code
in rnews that caused our system to think that all of the 2 Megs
of news we received the previous night had not come through them.
Therefore, rnews obediently queued *every* *article* for retransmission
back to them. And, no we wern't batching the feed back due to the low
return traffic volume. Needless to say, I was quite impressed to see 20+
'cico jobs running the next morning (we only have two phone lines :-)
and was less impressed trying to delete the several THOUSAND files
sitting in the spool directory :-(  Some of the jobs had spent over
10 hours scanning for work files, and none had even reached the point
of calling the remote system!

Anyways, I find UUCP throughput to be quite good. We maintain a throughput
of 109 cps on all of our 1200 baud links (+- about 2 cps over the last
year). I would be interested in seeing some comparitive stat's on
Kermit and [XYZ]MODEM.

--
Lyndon Nerenberg   UUCP: {mnetor!seismo, ihnp4, ubc-vision}!alberta!ncc
			 {pyramid,winfree,bellcore}!ncc!lyndon