To negotiate session control and file transfers with the remote end, uucico uses a set of standardized messages. This is often referred to as the high-level protocol. During the initialization phase and the hangup phase these are simply sent across as strings. However, during the real transfer phase, an additional low-level protocol that is mostly transparent to the higher levels is employed. This protocol offers some added benefits, such as allowing error checks on data sent over unreliable links.
UUCP is used over different types of connections, such as serial lines, TCP, or sometimes even X.25; it is advantageous to transport UUCP within protocols designed specifically for the underlying network protocol. In addition, several implementations of UUCP have introduced different protocols that do roughly the same thing.
Protocols can be divided into two categories: streaming and packet protocols. Protocols of the streaming variety transfer a file as a whole, possibly computing a checksum over it. This is nearly free of overhead, but requires a reliable connection because any error will cause the whole file to be retransmitted. These protocols are commonly used over TCP connections but are not suitable for use over telephone lines. Although modern modems do quite a good job at error correction, they are not perfect, nor is there any error detection between your computer and the modem.
On the other hand, packet-oriented protocols split up the file into several chunks of equal size. Each packet is sent and received separately, a checksum is computed, and an acknowledgment is returned to the sender. To make this more efficient, sliding-window protocols have been invented, which allow for a limited number (a window) of outstanding acknowledgments at any time. This greatly reduces the amount of time uucico has to wait during a transmission. Still, the relatively large overhead compared to a streaming protocol makes packet protocols inefficient for TCP use, but ideal for telephone lines.
The width of the data path also makes a difference. Sometimes sending 8-bit characters over a serial connection is impossible; for instance, the connection could go through a stupid terminal server that strips off the eighth bit. When you transmit 8-bit characters over a 7-bit connection, they have to be quoted on transmission. In the worst-case scenerio, quoting doubles the amount of data to be transmitted, although compression done by the hardware may compensate. Lines that can transmit arbitrary 8-bit characters are usually called 8-bit clean. This is the case for all TCP connections, as well as for most modem connections.
Taylor UUCP 1.06 supports a wide variety of UUCP protocols. The most common of these are:
This is the most common protocol and should be understood by virtually all uucicos. It does thorough error checking and is therefore well suited for noisy telephone links. g requires an 8-bit clean connection. It is a packet-oriented protocol that uses a sliding-window technique.
This is a bidirectional packet protocol, which can send and receive files at the same time. It requires a full-duplex connection and an 8-bit clean data path. It is currently understood by Taylor UUCP only.
This protocol is intended for use over a TCP connection or other truly error-free networks. It uses packets of 1,024 bytes and requires an 8-bit clean connection.
This should basically do the same as t. The main difference is that e is a streaming protocol and is thus suited only to reliable network connections.
This is intended for use with reliable X.25 connections. It is a streaming protocol and expects a 7-bit data path. 8-bit characters are quoted, which can make it very inefficient.
This is the System V Release 4 version of the g protocol. It is also understood by some other versions of UUCP.
This protocol is similiar to ZMODEM. It requires an 8-bit connection, but quotes certain control characters like XON and XOFF.
All protocols allow for some variation in packet sizes, timeouts, etc. Usually, the defaults work well under standard circumstances, but may not be optimal for your situation. The g protocol, for instance, uses window sizes from 1 to 7, and packet sizes in powers of 2 ranging from 64 through 4096. If your telephone line is usually so noisy that it drops more than 5 percent of all packets, you should probably lower the packet size and shrink the window. On the other hand, on very good telephone lines the protocol overhead of sending acknowledgments for every 128 bytes may prove wasteful, so you might increase the packet size to 512 or even 1,024. Most binaries included in Linux distributions default to a window size of 7 and 128-byte packets.
Taylor UUCP lets you tune parameters with the protocol-parameter command in the sys file. For instance, to set the g protocol's packet size to 512 when talking to pablo, you have to add:
system pablo ... protocol-parameter g packet-size 512 |
The tunable parameters and their names vary from protocol to protocol. For a complete list of them, refer to the documentation enclosed in the Taylor UUCP source.
Not every implementation of uucico speaks and understands each protocol, so during the initial handshake phase, both processes have to agree on a common one. The master uucico offers the slave a list of supported protocols by sending Pprotlist, from which the slave may pick one.
Based on the type of port used (modem, TCP, or direct), uucico will compose a default list of protocols. For modem and direct connections, this list usually comprises i, a, g, G, and j. For TCP connections, the list is t, e, i, a, g, G, j, and f. You can override this default list with the protocols command, which may be specified in a system entry as well as a port entry. For instance, you might edit the port file entry for your modem port like this:
port serial1 ... protocols igG |
This will require any incoming or outgoing connection through this port to use i, g, or G. If the remote system does not support any of these, the conversation will fail.