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:
g
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.
i
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.
t
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.
e
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.
f
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.
G
This is the System V Release 4 version of the g protocol.
It is also understood by some other versions of UUCP.
a
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.
