UUCP (Unix-to-Unix Copy) is a suite of computer programs and protocols allowing remote execution of commands and transfer of files, email and netnews between computers.
A command named is one of the programs in the suite; it provides a user interface for requesting file copy operations. The UUCP suite also includes (user interface for remote command execution), (the communication program that performs the file transfers), (reports statistics on recent activity), (execute commands sent from remote machines), and (reports the UUCP name of the local system). Some versions of the suite include / (convert 8-bit binary files to 7-bit text format and vice versa).
Although UUCP was originally developed on Unix in the 1970s and 1980s, and is most closely associated with Unix-like systems, UUCP implementations exist for several non-Unix-like operating systems, including DOS, OS/2, OpenVMS (for VAX hardware only), AmigaOS, classic Mac OS, and even CP/M.
History UUCP was originally written at AT&T Bell Laboratories by Mike Lesk. By 1978, it was in use on 82 UNIX machines inside the Bell system, primarily for software distribution. It was released in 1979 as part of Version 7 Unix.
The first UUCP emails from the U.S. arrived in the United Kingdom in 1979 and email between the UK, the Netherlands and Denmark started in 1980, becoming a regular service via EUnet in 1982.
The original UUCP was rewritten by AT&T researchers Peter Honeyman, David A. Nowitz, and Brian E. Redman around 1983. The rewrite is referred to as HDB or HoneyDanBer uucp, which was later enhanced, bug fixed, and repackaged as BNU UUCP ("Basic Network Utilities").
Each of these versions was distributed as proprietary software, which inspired Ian Lance Taylor to write a new free software version from scratch in 1991. Taylor UUCP was released under the GNU General Public License. Taylor UUCP addressed security holes which allowed some of the original network worms to remotely execute unexpected shell commands. Taylor UUCP also incorporated features of all previous versions of UUCP, allowing it to communicate with any other version and even use similar config file formats from other versions.
UUCP was also implemented for non-UNIX operating systems, most-notably DOS systems. Packages such as UUSLAVE/GNUUCP (John Gilmore, Garry Paxinos, Tim Pozar), UUPC/extended (Drew Derbyshire of Kendra Electronic Wonderworks) and FSUUCP (Christopher Ambler of IODesign), brought early Internet connectivity to personal computers, expanding the network beyond the interconnected university systems. FSUUCP formed the basis for many bulletin board system (BBS) packages such as Galacticomm's Major BBS and Mustang Software's Wildcat! BBS to connect to the UUCP network and exchange email and Usenet traffic. As an example, UFGATE (John Galvin, Garry Paxinos, Tim Pozar) was a package that provided a gateway between networks running FidoNet and UUCP protocols.
FSUUCP was the only other implementation of Taylor's enhanced 'i' protocol, a significant improvement over the standard 'g' protocol used by most UUCP implementations.
Technology Before the widespread availability of Internet access, computers were only connected by smaller local area networks within a company or organization. They were also often equipped with modems so they could be used remotely from character-mode terminals via dial-up telephone lines. UUCP used the computers' modems to dial out to other computers, establishing temporary, point-to-point links between them. Each system in a UUCP network has a list of neighbor systems, with phone numbers, login names and passwords, etc. When work (file transfer or command execution requests) is queued for a neighbor system, the program typically calls that system to process the work. The program can also poll its neighbors periodically to check for work queued on their side; this permits neighbors without dial-out capability to participate.
Over time, dial-up links were replaced by Internet connections, and UUCP added a number of new link layer protocols. These newer connections also reduced the need for UUCP at all, as newer application protocols developed to take advantage of the new networks. Today, UUCP is rarely used over dial-up links but is occasionally used over TCP/IP. The number of systems involved, as of early 2006, ran between 1500 and 2000 sites across 60 enterprises. UUCP's longevity can be attributed to its low cost, extensive logging, native failover to dialup, and persistent queue management.
Sessions UUCP is normally started by having a user log into the target system and then running the UUCP program. In most cases, this is automated by logging into a known user account used for transfers, whose account's shell has been set to . Thus, for automated transfers, another machine simply has to open a modem connection to the called machine and log into the known account.
When uucico runs, it will expect to receive commands from another UUCP program on the caller's machine and begin a session. The session has three distinct stages:
Initial handshake File request(s) Final handshake
Initial handshake On starting, uucico will respond by sending an identification string, \20Shere=hostname\0, where \20 (octal, decimal 16) is the control-P character, and \0 is a trailing null. The caller's UUCP responds with \20Scallername options\0, where options is a string containing zero or more Unix-like option switches. These can include packet and window sizes, the maximum supported file size, debugging options, and others.
Depending on the setup of the two systems, the call may end here. For instance, when the caller responds with their system name, the called system may optionally hang up if it does not recognize the caller, sending the RYou are unknown to me\0 response string and then disconnecting.
File requests If the two systems successfully handshake, the caller will now begin to send a series of file requests. There are four types:
S causes a file to be Sent from the caller to the called system (upload). The from and to names are provided, allowing the filename to be changed on the receiver. When the S command is received on the called system, it responds with SY if it succeeded and it is ready to accept the file, or SNx if it failed, where x is a failure code. If an SY is received by the caller, it begins uploading the file using the protocol selected during the initial handshake (see below). When the transfer is complete, the called system responds with CY if it successfully received the file, or CN5 if it failed. R is a Request for the called system to send a file to the caller (download). It is otherwise similar to S, using RY and RN to indicate the command was accepted and it will begin to send data or had a problem, and expecting a CY and CN5 from the caller at the end of the transfer. X uploads commands to be eXecuted on the called system. This can be used to make that system call another and deliver files to it. The called system responds with XY if it succeeded, or XN if it failed. H, for Hangup, indicates the caller is done. The called system responds with HY if it succeeded, or HN if it failed.
Final handshake After sending an H command, the calling system sends a final packet (control-P, six ohs, null-terminator) and the called system responds with (control-P, seven ohs, null-terminator). Some systems will simply hang up on the successful reception of the H command and not bother with the final handshake.
g-protocol Within the suite of protocols in UUCP, the underlying g-protocol is responsible for transferring information in an error-free form. The protocol originated as a general-purpose system for packet delivery, and thus offers a number of features that are not used by the UUCP package as a whole. These include a secondary channel that can send command data interspersed with a file transfer, and the ability to renegotiate the packet and window sizes during transmission. These extra features may not be available in some implementations of the UUCP stack.
The packet format consisted of a 6-byte header and then between zero and 4096 bytes in the payload. The packet starts with a single \020 (control-P). This is followed by a single byte, known as "K", containing a value of 1 to 8 indicating a packet size from 32 to 4096 bytes, or a 9 indicating a control packet. Many systems only supported K=2, meaning 64 bytes. The next two bytes were a 16-bit checksum of the payload, not including the header. The next byte is the data type and finally, the last byte is the XOR of the header, allowing it to be checked separately from the payload.
The control byte consists of three bit-fields in the format TTXXXYYY. TT is the packet type, 0 for control packets (which also requires K=9 to be valid), 1 for alternate data (not used in UUCP), 2 for data, and 3 indicates a short packet that re-defines the meaning of K. In a data packet, XXX is the packet number for this packet from 0 to 7, and YYY is the last that was received correctly. This provides up to 8 packets in a window. In a control packet, XXX indicates the command and YYY is used for various parameters. For instance, transfers are started by sending a short control packet with TT=0 (control), XXX=7 and YYY the number of packets in a window, then sending another packet with XXX=6 and YYY as the packet length (encoded as it would be in K) and then a third packet that is identical to the first but XXX=5.
g-protocol uses a simple sliding window system to deal with potentially long latencies between endpoints. The protocol allows packets to size from 32 to 4096 8-bit bytes, and windows that include 1 to 7 packets. In theory, a system using 4k packets and 7 packet windows (4096×7) would offer performance matching or beating the best file-transfer protocols like ZMODEM. In practice, many early implementations only supported a single setting of 64x3. As a result, the g-protocol has an undeserved reputation for poor performance. Confusion over the packet and window sizes led to the G-protocol, differing only in that it always used 4096x3. Taylor UUCP did not support G, but did support any valid requested window or packet size, so remote systems starting G would work fine with Taylor's g, while two Taylor systems could negotiate even faster connections.
Telebit modems used protocol spoofing to improve the performance of g-protocol transfers by noticing end-of-packet markers being sent to the remote system and immediately sending an back to the local host, pretending that the remote system had already received the packet and decoded it correctly. This triggered the software stack on the local computer to send the next packet, so rapidly that the transfer became almost continuous. The data between the two modems was error-corrected using a proprietary protocol based on MNP that ran over Telebit's half-duplex connections much better than g-protocol would normally, because in the common 64x3 case the remote system would be sending a constant stream of s that would overflow the low-speed return channel. Combined with the modem's naturally higher data rates, up to 23 kbps, they greatly improved overall throughput and generally performed about seven times the speed of a 2400 bit/s modem. They were widely used on UUCP hosts as they could quickly pay for themselves in reduced long-distance charges.
Other protocols UUCP implementations also include other transfer protocols for use over certain links.
f-protocol is designed to run over 7-bit error-corrected links. This was originally intended for use on X.25 links, which were popular for a time in the 1980s. It does not packetize data; instead, the entire file is sent as a single long string followed by a whole-file checksum. The similar x-protocol appears to have seen little or no use. d-protocol was similar to x, but intended for use on Datakit networks that connected many of Bell Labs offices.