uucp over terminal server

[Romain Kang]

If you're going to have a BIG uucp site, it is even cleverer to use
the terminal server to connect to directly to the uucp TCP port (if
the server allows it).  This works quite well if your uucp supports
incoming TCP connections, since it bypasses the
	tty + (rlogind or telnetd) + context switch
overhead entirely.  If you want to see the performance hit from the
latter two terms, see John LoVerso's article (7705 at xenna.Xylogics.COM).

In some variants of uucp, you'll need to list the incoming connections
with the IP address of your terminal server to satisfy some weak
authentication requirements.  In 4.3, you would say something like:
	pyrnj Never TCP uucp server03.pyramid.com
Incoming uucp will still want to run 'g' protocol, since that's still
the most reliable way to move data over dialups.  'f' is the only other
reasonable alternative, but there are other weak links in a terminal
server scheme which make flow control dicey.  Naturally, you can't
gracefully dial out without RS-232 (i.e., tty) control...

The potential disadvantage that I see is that the pkcget() stall code
in 4.3 uucp or the VMIN termio setting in HDB aren't applicable to
non-tty descriptors like sockets, which may make the kernel schedule
uucico more frequently than optimal.  In other words, uucico could
spin on reads that only return a few characters at a time, rather
than pulling in (nearly) complete 'g' packets on each read.

However, direct connection to the uucp TCP port is a clear winner
on fast dialups.  I don't have the figures around anymore, but when
rutgers made "/stream" mode available on their Cisco, pyrnj saw
instantaneous character rates (as reported by sar) rise from about
1100 to 1900 bytes/second.  Now, if rutgers could only keep both of
their TrailBlazers healthy...
--
"Eggheads unite!  You have nothing to lose but your yolks!"  -Adlai Stevenson