Next Previous Contents

15. UUCP `y' Protocol

UUCP `y' Protocol

The `y' protocol was developed by Jorge Cwik for use in FX UUCICO, a PC uucico program. It is designed for communication lines which handle error correction and flow control. It requires an eight bit clean connection. It performs error detection, but not error correction: when an error is detected, the line is dropped. It is a streaming protocol, like the `f' protocol; there are no packet acknowledgements, so the protocol is efficient over a half-duplex communication line such as PEP.

Every packet contains a six byte header:

sequence low byte sequence high byte A two byte sequence number, in little endian order. The first sequence number is 0. Since the first packet is always a sync packet (described below) the sequence number of the first data packet is always 1. Each system counts sequence numbers independently.

length low byte length high byte A two byte data length, in little endian order. If the high bit of the sixteen bit field is clear, this is the number of data bytes which follow the six byte header. If the high bit is set, there is no data, and the length field is a type of control packet.

checksum low byte checksum high byte A two byte checksum, in little endian order. The checksum is computed over the data bytes. The checksum algorithm is described below. If there are no data bytes, the checksum is sent as 0.

When the protocol starts up, each side must send a sync packet. This is a packet with a normal six byte header followed by data. The sequence number of the sync packet should be 0. Currently at least four bytes of data must be sent with the sync packet. Additional bytes should be ignored. They are defined as follows:

version The version number of the protocol. Currently this must be 1. Larger numbers should be ignored; it is the responsibility of the newer version to accommodate the older one.

packet size The maximum data length to use divided by 256. This is sent as a single byte. The maximum data length permitted is 32768, which would be sent as 128. Customarily both systems will use the same maximum data length, the lower of the two requested.

flags low byte flags high byte Two bytes of flags. None are currently defined. These bytes should be sent as 0, and ignored by the receiver.

A length field with the high bit set is a control packet. The following control packet types are defined:

0xfffe `YPKT_ACK' Acknowledges correct receipt of a file.

0xfffd `YPKT_ERR' Indicates an incorrect checksum.

0xfffc `YPKT_BAD' Indicates a bad sequence number, an invalid length, or some other error.

If a control packet other than `YPKT_ACK' is received, the connection is dropped. If a checksum error is detected for a received packet, a `YPKT_ERR' control packet is sent, and the connection is dropped. If a packet is received out of sequence, a `YPKT_BAD' control packet is sent, and the connection is dropped.

The checksum is initialized to 0xffff. For each data byte in a packet it is modified as follows (where B is the byte before it has been transformed as described above):

/* Rotate the checksum left. */ if ((ichk & 0x8000) == 0) ichk <<= 1; else { ichk <<= 1; ++ichk; }

/* Add the next byte into the checksum. */ ichk += B;

This is the same algorithm as that used by the `f' protocol.

A command is sent as a sequence of data packets followed by a null byte. In the normal case, a command will fit into a single packet. The packet should be exactly the length of the command plus a null byte. If the command is too long, more packets are sent as required.

A file is sent as a sequence of data packets, ending with a zero length packet. The data packets may be of any length greater than zero and less than or equal to the maximum permitted packet size specified in the initial sync packet.

After the zero length packet ending a file transfer has been received, the receiving system sends a `YPKT_ACK' control packet. The sending system waits for the `YPKT_ACK' control packet before continuing; this wait should be done with a large timeout, since there may be a considerable amount of data buffered on the communication path.


Next Previous Contents