Configuration(F)

Configuration -- protocol configuration table for the UUCP system

Format

SYSTEM hostname
PROTOCOL STRING proto
USE PROTOCOL protocol
WITH parameter = value
[ WITH parameter = value ] ... DEVICE devicetype
PROTOCOL STRING proto
USE PROTOCOL protocol
WITH parameter= value
[ WITH parameter = value ] ...

Description

The Configuration file (/usr/lib/uucp/Configuration) contains configuration information for protocols used by the uucico command. When uucico calls or is called by a host listed in /usr/lib/uucp/Systems, it checks Configuration. When originating or receiving a call, if Configuration contains a SYSTEM entry that matches the hostname being contacted, the protocol specified in the USE PROTOCOL statement is used. When making an outgoing call, uucico also checks the /usr/lib/uucp/Devices file, and if the device used to contact the destination system has a DEVICE entry in Configuration, the specified protocol is used.

The SYSTEM hostname or DEVICE devicetype entry called OTHER (if it exists) is applied by default if the host or device being used does not have an entry of its own.

For each entry, a protocol string proto lists the protocols that uucico can use to talk to the remote system. The protocols are listed in order of preference from left to right. If no protocols are specified, the uucico daemons at each end of the session compare the protocols they support and use the first that they have in common.

The following protocols are supported by this implementation of UUCP:

d: Used for DataKit muxhost connections (non RS232).
e: Used for links that provide reliable connections (such as TCP). This protocol does no error checking or flow control, and requires an 8-bit clear channel. When sending a command using this protocol, UUCP sends the command as a null-terminated ASCII string. When sending a file, UUCP sends the filesize (as an ASCII decimal number padded to 20 bytes with nulls), then sends the entire file. (Originated in the HoneyDanBer implementation of UUCP.)
f: A 7-bit protocol that checksums an entire file. There is no flow control and the file-level checksum means that it is unreliable over serial connections unless handshaking (typically XON/XOFF) and error correcting modems are used. The `f' protocol is most efficient for transferring text-only data in small files, and is least efficient when transferring large compressed or 8-bit files.
g: A packet-based error-correcting flow-controlled protocol that requires an 8-bit clear connection. This is the original UUCP protocol and is supported by all implementations. Data is transferred in packets prefixed by a 6-byte header. Packets that fail a checksum may be retransmitted. The `g' protocol is user configurable; see below for a discussion.
G: A variant on the `g' protocol, available to SVR4-based UNIX systems. The `G' protocol is user configurable; see below for a discussion.
t: Used for links that provide reliable corrections (such as TCP). Does no error checking or flow control, requires an 8-bit clear channel. Commands and files are sent in blocks: data blocks consist of at most 1024 bytes of data, while command blocks consist of the smallest multiple of 512 bytes that can hold the command string plus a trailing null byte. (Originated in the BSD implementation of UUCP.)
x: Used for links across X.25 circuits (without interference from the X.28 or X.29 layers). Requires an 8-bit clean connection. Data and commands are send in 512-byte packets.

If a protocol is specified in proto and is configurable, any of its configurable parameters may be adjusted using the format:

USE PROTOCOL protocol
WITH parameter = value

(Multiple WITH lines may be associated with a single protocol.)

In the case of the `g' and `G' protocols, the window size (window_size) and packet size (packet_size) may be adjusted. The `g' protocol may also be configured to use variable length packets (variable_packet), and the packet timeout delay (pktime) may be adjusted.

Protocol configuration

The `G' and `g' protocols transmit data in packets, each of which has a fixed length header containing checksum and sequence information. The window size window_size is the number of packets that may be sent before a packet is acknowledged. During a session, the receiving uucico daemon calculates the checksums of the incoming packets. If the checksum of an incoming packet does not match the checksum specified in its header, the receiver daemon sends a packet that tells the transmitting uucico daemon to resend the corrupted packet.

Changing the following parameters can affect the efficiency of a UUCP session:

packet_size: As packet_size increases, the protocol overhead is reduced. However, if a single error occurs in a packet, the entire packet must be retransmitted. When small packets are in use, the overhead for resending a packet is small; but if a large packet fails, it ties up the session for longer while it is retransmitted. Furthermore, larger packets are more vulnerable to line noise. As the error rate rises towards one error per packet_size bytes, the session performance will degrade. Therefore, smaller settings of packet_size may result in slightly slower transmission, but are more reliable over noisy lines. Default packet_size is 64 bytes.
window_size: If window_size is large, the uucico processes can exchange more packets before having to acknowledge the transfers. However, the `g' and `G' protocols operate on a ``go back n'' principle; if a given packet is dropped, all packets from the dropped one to the end of the window must be resent. On a poor line this means that large windows may result in a very high number of resends being required. Default window_size is 3.
variable_packets: If the `g' protocol is in use and variable_packets is set to 1, uucico may send or receive variable length packets. For example, if packet_size = 4096 and variable_packets = 1, then if we only need to send 13 bytes of data it will be sent in a 32 byte packet (the smallest permitted size). Note that the uucico at both ends must support this feature. By default, variable_packets is set to 0 (disabled).
pktime: If the `g' protocol is in use the pktime parameter may be configured. pktime is the number of seconds uucico should wait before giving up and re-transmitting the packet being sent. This interval may be as long as 35 seconds, which can be costly with overseas phone connections.

Protocol selection

Selecting the correct protocol can affect the efficiency of a UUCP session. The following points should be noted:

Over networks that provide their own reliable connections (such as TCP/IP) the `e' or `t' protocols are preferred. The precise protocol to use should be decided on the basis of the protocols supported by the non-SCO OpenServer systems on the network.
Over networks connected by error-correcting modems, the `f' protocol may be used for mail transfers that consist of numerous small ASCII-only files.
Over general-purpose serial connections, where there is a risk of line noise, or where non-ASCII files may be transferred, the `g' or `G' protocols are preferred.

The version of the `g' protocol implemented in SCO System V/386 Release 3.2 Version 4 (and earlier releases) used a fixed packet size of 64 bytes, and a fixed window size of 3, even though the specification for the `g' protocol allows different packet and window lengths to be selected. When communicating with such a `g' protocol host, the remote uucico may die if the correct packet and window sizes are not used in the modern uucico. (This limitation is common to many implementations of the UUCP `g' protocol under UNIX System V Release 3.2).

The `G' protocol was introduced in UNIX System V Release 4.0. It is identical to the `g' protocol implementation noted above, except that it allows the packet and window sizes to be configured. The `G' protocol does not permit the packet length to be changed during a session. (If long packets are used to transmit short files, this may result in nearly empty packets being sent.)

The version of the `g' protocol implemented in this product is fully configurable and can adaptively send and receive packets less than packet_size bytes long, when communicating with a system that implements the `g' protocol correctly. To permit variable length packets, variable_packets should be set to 1 in the protocol configuration.

Under the properly implemented `g' protocol, packets may be from 32 to 4096 bytes long (increasing in powers of two). The window size may be in the range 1 to 7 packets.

Examples

Here is an example Configuration file:

SYSTEM scolon


	PROTOCOL STRING  Ggxt


	USE PROTOCOL G


			WITH window_size = 7


			WITH packet_size = 512


	USE PROTOCOL g


			WITH window_size = 7




DEVICE TCP


	PROTOCOL STRING  tfgGxe


		USE PROTOCOL G


			WITH window_size = 7


			WITH packet_size = 1024


		USE PROTOCOL g


			WITH window_size = 7

The entry for system scolon, specifies that the protocols `G', `g', `x', `t', and `i' are recognized. Two protocol specifications follow. The USE PROTOCOL G WITH ... statement specifies that a window size of 7 packets and a packet size of 512 bytes should be used with the `G' protocol. The USE PROTOCOL g WITH ... statement specifies a window size of 7 packets when using the `g' protocol, and leaves uucico to negotiate the packet size.

The DEVICE TCP entry specifies protocols that can be used when UUCP is communicating over the TCP device. Valid devices are ACU, for modems, and TCP, for networks. All systems that are connected to using the TCP entry in Devices use this entry. (A longer packet size is used over TCP/IP than over an ACU connection because networks are generally less prone to noise than modem connections.)

Limitations

When using the `g' protocol to contact older SVR3 implementations of UUCP, be aware that the session may fail unless Configuration specifies the window and packet size expected by the older system. (Older systems are particularly vulnerable to different values of packet_size.)

Files

/usr/lib/uucp/Configuration

Standards conformance

Configuration is not part of any currently supported standard; it is an extension of AT&T System/V provided by The Santa Cruz Operation, Inc.