Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Is there such a thing as a uucp daemon?
Message-ID: <8295@auspex.auspex.com>
Date: 11 Jun 91 00:11:41 GMT
References: <1991Jun6.185715.16350@versyss.uucp> <139@gordius.gordian.com>
Organization: Auspex Systems, Santa Clara
Lines: 43

>Uucp doesn't need a daemon. uucico is started by /bin/login when the
>calling system logs into the target machine.

Well, that's *one* way "uucico" can get started; however, it's not the
*only* way.  The 4.xBSD UUCP-over-TCP mechanism doesn't involve a normal
login from the calling system to the target machine; instead, the
calling "uucico" makes a TCP connection to some particular TCP port on
the remote machine (normally port 540), which connects it to the UUCP
daemon on the target machine.

The UUCP daemon prompts for a login name, reads that, prompts for a
password, reads that, and does the same checks that "login" does (it
originally didn't do so; that was added later), and then directly runs
"uucico".  The two UUCPs then communicate using a protocol such as the
"t" protocol, running on top of TCP, rather than the "g" protocol used
over asynchronous serial lines (although you can run UUCP-over-TCP on a
connection that passes over an asynchronous serial line using SLIP or
PPP, of course...).

Now, as the person who asked the original question is running SVR3.2,
the above doesn't necessarily apply.  S5R3.2's UUCP has its *own* way of
doing UUCP over various transport layers; it uses TLI, which achieves
its goal of transport independence, in part, by not supporting any form
of host-name-to-address translation, and requires you, from what I've
seen, to put long strings of hex digits representing a transport-level
address into the Systems file.  (S5R4, with the aid of run-time dynamic
linking, actually admits host+service-to-address translation into the
Wonderful World of TLI; whether its UUCP makes use of that, or still
requires hex digits in the Systems file, I don't know.)

That address is the address of the "listener" process on the remote
machine, which is a somewhat bizarre sort of network daemon that
requires those who want to connect to it to send an identifier for the
service to which they want to connect as *data* over the connection,
rather than letting you simply say "this transport address belongs to
this service" - or, at least, it did so in the S5R3's I've seen; perhaps
they've replaced it with something rational (or, at least, capable of
supporting normal Internet-style services) in S5R3.2.

The "listener" would occupy the same niche in that scheme of
UUCP-over-TCP as "uucpd" does in a BSDish scheme.  There may well be
documentation somewhere in the S5R3.2 documentation set on how to set
that up, unpleasant long strings of hex digits and all....