Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!samsung!uakari.primate.wisc.edu!xanth!mcnc!ecsvax.uncecs.edu!dukeac!wolves!ggw From: ggw@wolves.uucp (Gregory G. Woodbury) Newsgroups: comp.org.usenix Subject: Re: USENIX Board Studies UUCP Message-ID: <1989Nov24.042806.23926@wolves.uucp> Date: 24 Nov 89 04:28:06 GMT References: <287@usenix.UUCP> <1989Nov19.032449.7940@world.std.com> <2167@prune.bbn.com> <7067@ficc.uu.net> <36700@apple.Apple.COM> Reply-To: ggw@wolves.UUCP (Gregory G. Woodbury) Followup-To: comp.org.usenix Distribution: usa Organization: Wolves Den UNIX BBS Lines: 60 In article <36700@apple.Apple.COM> fair@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@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ]