UUCP was a protocol commonly used on non-networked UNIX machines in the past. Similar to what Fidonet was for DOS-based BBSes, UUCP enabled UNIX machines to regularly dial up and connect to each other to form an ad-hoc network. For years this was widely used both for mail and for USENET, as well as just for transferring files from one machine to another. The Internet basically eradicated UUCP.

If you look through old code and documentation, you will see e-mail addresses given in the old bang path UUCP-style, where the names of connected machines are successively named, culminating with the name of the user on the last machine, i.e. darkstar!walrus!bayport!gertrude would send a message to gertrude on the machine bayport, first through darkstar, then to walrus, and lastly to its destination. In those times, it is easy to see how it might take days for a message to get from one end of the loose-knit network to the other depending on how often the nodes synced.

Where UUCP is used at all today, it is generally used as a gateway from a non-networked system to an Internet networked system.

UUCP, which stands for "Unix-to-Unix CoPy", is a system to copy files between hosts, and execute commands on remote hosts, in a batched and asynchronous manner. There are many implementations of UUCP for various operating systems, as well as various systems which will cooperate with UUCP. UUCP is also a protocol used in UUCP communications. The highlights will be covered here. Furthermore, 'uucp' is a command which is part of the UUCP suite. Special care should be taken to get the case right when discussing UUCP or uucp.

CHARACTERISTICS

UUCP, when it is remembered at all, is often remembered for its long and cumbersome addresses. For example, in my signature I used ...scruz.ucsc.edu!deeptht!inkpot!drink as my address. Later, when deeptht became an internet node, it became possible for me to use inkpot!drink@deeptht.armory.com. As the ! is known as a "bang" in Unix, these email addresses became known as bang paths. But there's more to remember than that; Without UUCP, there would be no USENET. It was the way to carry email from one system to another, and at one time, the only way which worked across all (or nearly all) the hosts of the internetwork. Imagine what the early development of the internet would have been like without newsgroups, which are still very much in use today in spite of the web.

UUCP is somewhat unique in that it is the only package designed to send and retrieve mail and news for multiple users over an impermanent connection. This helps explain why it is still in use (though the number of users is probably decreasing) after more than twenty years. A result of this type of design, though significantly more than a side effect, is that communications can be scheduled for times when rates are low. This is uncommon since the advent of the third millennium A.D., as most phone networks now charge a flat rate, but in the time of Ma Bell this was a big deal. email and news articles were once carried at night from system to system, utilizing ordinary POTS lines and modems.

While configuring various versions of UUCP is beyond the scope of this writeup, they tended to have certain things in common. One writes chat scripts to connect to remote hosts. The chat script includes the usernames and passwords used to connect to those hosts in plaintext, so care is required to maintain security. Modem initialization was sometimes done in the connect chat script, and sometimes done in a separate script. Generally speaking however, if your modem was used only for UUCP or if you used the right protocols, you were best off saving settings in the modem itself. Each system is identified by a unique name of not more than seven characters. One of the pieces of information stored is a range of times to call that system, as many systems shared a phone line used for voice communications (or normal interactive dialup use) and access was only available during restricted hours.

HISTORY

UUCP began in 1976 at AT&T/Bell Labs, when it was written by Mike Lesk, and subsequently distributed with AT&T Unix SVR2, paving the way for the birth of USENET in 1979. This became Version 2 UUCP, with further work from David A. Novitz and Greg Chesson. UUCP was rewritten in 1983 in the form of HoneyDanBer UUCP, or HDB for short. It came to be known as BNU (Basic Networking Utilities), and was developed for SVR3. The name HoneyDanBer is derived from the authors' names, P. Honeyman, D. A. Novitz, and B. E. Redman. Ian Lance Taylor released the first version of Taylor UUCP in 1993, which has since become something of a standard, though various odd flavors of UUCP abound. SCO in particular had their own (quite compliant) version of UUCP. SGI used what appeared to be a standard UUCP, but they also used its configuration files to manage PPP connections, at least in IRIX 5.2.

PROGRAMS

UUCP is made up primarily of a handful of core programs.

  • uucp is the highest-profile command in the uucp package. Its purpose is to copy files between systems. Aside from options, uucp takes two arguments, the source and destination. If both the source and destination are local, then uucp will act like cp and simply copy a file. If one or more of the files specified are remote paths, then uucp will queue your copy for the next time a connection is made between systems.
  • uux executes commands on remote systems, acting much like a non-interactive version of rsh.
  • uustat displays uucp status information, and can be used to cancel jobs.
  • uuname is intended for use in shell scripts, and it will print out the name of the local system, or the names of connected systems.
  • uulog displays the UUCP logfile.
  • uuto and uupick are insecure programs for users to send and receive files. uuto sends the file to a remote system, and uupick is used to take the file from the queue.
  • cu, or "call unix", makes connections to remote systems. For a long time, cu was the accepted way to dial up to a remote Unix system running a getty in order to start an interactive session. cu can optionally use a chat script when connecting to the remote system, or can simply be used to talk to the tty directly. (Relatively) newer versions of cu support simple file transfers without error correction.
  • uucico is a daemon which processes the queued requests from uucp and uux, including dialing up remote hosts and making batched transfers. When it terminates, it calls uuxqt to execute any requests from uux. uucico is responsible for retrying failed connections to remote systems.
  • uuxqt executes job requests queued by uux on local or remote systems.
  • uuchk checks the UUCP config files for errors.
  • uuconv is a tool from Taylor UUCP to convert between configuration file formats. It supports 'taylor', 'v2', and 'hdb' (HoneyDanBer/BNU UUCP) formats.
  • uusched forces a call for all systems for which there are batched jobs.

MAPS

The UUCP Mapping Project (Part of the UUCP Project) produced UUCP Maps in order to aid in the delivery of mail. Remember that UUCP is intended to be used on systems which do not have an internet link, so we cannot use DNS to look up MX hosts for the typical site. In addition, SLIP links (PPP didn't exist at all until quite late in the UUCP game) were hard to come by at the time, hence the need for UUCP to handle modem communications. The mapping project terminated in November 2000 as mail is rarely carried solely via UUCP in cases where there is more than one hop involved.

A map entry took the following format:


#N	UUCP name of site
#S	manufacturer machine model; operating system & version
#O	organization name
#C	contact person's name
#E	contact person's electronic mail address
#T	contact person's telephone number
#P	organization's address
#L	latitude / longitude
#R	remarks
#U	netnews neighbors
#W	who last edited the entry ; date edited
#
sitename	.domain
sitename	remote1(FREQUENCY), remote2(FREQUENCY),
		remote3(FREQUENCY)

A completed map entry might look like the following:


#N	academ,academ.houston.tx.us,academ.com
#S	Victor 486/50; BSDOS 1.1
#O	Academ Consulting Services
#C	Stan Barber
#E	sob@academ.com
#T	+1 713 793 0222
#P	P.O. Box 300481, Houston, Texas USA 77230-0481
#L	29 42 N / 95 23 W city
#U	news.sesqui.net cs.utexas.edu news.usis.com bcm
#W	academ!sob (Stan Barber); Fri May 12 19:26:27 CDT 1995
#R	academ is the primary uucp gateway for Academ Consulting Services

academ=academ.houston.tx.us
academ  .academ.com(LOCAL)
academ  nuchat(DIRECT),uhnix1(DIRECT),cyberlaw(POLLED)

A program called uuhosts was used to make use (and sense) of the UUCP maps. It is still available from the ISC.

SPOOLING

Various versions and releases of UUCP have different spooling behavior. In general, there is a spool directory which contains files with descriptive names. These files are sent to remote systems (via uucico) and things are done to them once they arrive. There are command files, which indicate what commands are to be executed, and data files, which have the information needed for the commands.

Taylor UUCP names its command files in the format C.ssssssgqqqq, where ssssss is the name of the system to transfer to or from, g is the grade, and qqqq is the sequence number. Data files are named D.ssssssgqqqq (same conventions). The system name may be "LOCAL", for locally queued jobs. A sequence file named "SEQF" is kept in each system's spool directory.

PROTOCOLS

The first protocol notable in the UUCP system is the UUCP Protocol. Each UUCP conversation consists of an initial handshake, some number of UUCP Protocol commands, and a final handshake. Each command in the initial handshake begins with a ^P (octal \020) and end with a null (octal \000), though some (non-conformant) packages may end them with a line feed (octal \012). First the remote system announces its hostname, and then the calling system responds with its own hostname, and zero or more options such as sequence number, debug level, ulimit, and so on. The called system then announces which communication protocols it supports, and the calling system responds with which of them it would like to use.

We are now ready to do some work in the form of UUCP Protocol commands. There are five commands: S, R, X, E, and H.

  • S: This is a request from the 'master' to send a file to the 'slave'. The slave then responds with an S command response, which can instruct the master to send the file, or to inform it as to why it will not accept it. If the file is accepted, the slave sends a C command response to do one of the following:
    • CY informs the master that the transfer was successful, and business goes on as before.
    • CYM is like CY, but it includes a request from the slave to become the master, which the master responds to with an H command (more on this later).
    • CN5 indicates a failure to copy the temp file to its final destination.
    Once the master receives the C command response, it will send its next command.
  • R: This is a request by the master to get (recieve) a file from the slave. It works essentially the same as the S command.
  • X: This is a request to the slave to queue a file for transfer, which constitutes running uucp.
  • E: This is a command in Taylor UUCP 1.04 and up, used to request execution of a command without a job file, only used when the command to be executed requires a single input file which is passed to it on stdin. It is otherwise similar to an S command.
  • H: A hangup request. It can be responded to in one of two ways:
    • HY is an agreement to hang up. If the slave responds to H with HY, then the master is intended to send HY in response, and we enter the final handshake.
    • If the slave should respond with HN instead, then the master and slave swap roles.

At this point we are ready for the final handshake. Some UUCP implementations simply drop the connection rather than going through this step, which looks like this:

caller: \020OOOOOO\000
called: \020OOOOOOO\000

At which point the modem is hung up.

The communcation in between the handshakes (or at least following the first handshake) is handled by various communications protocols. The original is the g protocol, which requires an eight bit clear connection. Other protocols include G (note capital letter) which is identical to the g protocol except that it supports modifiable window and packet sizes; f, a seven bit protocol with file checksums (which cannot be used to transmit 8 bit data such as compressed news); t which requires an 8 bit channel and has no flow control or error checking (used for TCP connections); the i and j protocols which perform bidirectional transfers; and the x protocol, used for X.25. There are others, but they are largely irrelevant. There is little reason to use any protocol other than g, G, f, t, i, j, or x.

IMPLEMENTATIONS

UUCP implementations exist for many operating systems. The primary UUCP used on Unix today is Taylor UUCP, sometimes called GNU UUCP, written by Ian Lance Taylor. Prior to its existence, the most common were BNU UUCP and the version of UUCP which came with BSD 4.3 version 2. On DOS, there are UUPC and the Waffle BBS software, among others. Mac users also have access to a port of UUPC to MacOS. A gateway called GIGO also provides UUCP services for a variety of systems, including OS/2.


References:

  1. Website: Ian Lance Taylor, Taylor UUCP 1.06.1. 2002. (http://www.airs.com/ian/uucp.html)
  2. Website: Eric Ziegast and Stan Barber, The UUCP Project. June 19, 2000. (http://www.uucp.org/)
  3. Webpage: Andrew Anderson, History. March 7, 1996. (http://www.tldp.org/LDP/nag/node147.html)
  4. C Source File: Ian Lance Taylor, unix/spool.c. Taylor UUCP 1.06.1, 1993. (GPL)

Supporting Documentation (for more info):

  1. David H. Crocker, RFC 822 Standard for the Format of ARPA Internet Text Messages. University of Delaware, August 13, 1982.
  2. Mark R. Horton, RFC 976 UUCP Mail Interchange Format Standard. Bell Laboratories, February 1986.

Log in or register to write something here or to contact authors.