The `i' protocol was written by Ian Lance Taylor (who also wrote this manual). It was first used by Taylor UUCP version 1.04.
It is a sliding window packet protocol, like the `g' protocol, but
it supports bidirectional transfers (i.e., file transfers in both
directions simultaneously). It requires an eight bit clear connection.
Several ideas for the protocol were taken from the paper A
High-Throughput Message Transport System by P. Lauder. I don't know
where the paper was published, but the author's e-mail address is
piers@cs.su.oz.au
. The `i' protocol does not adopt his
main idea, which is to dispense with windows entirely. This is because
some links still do require flow control and, more importantly, because
using windows sets a limit to the amount of data which the protocol must
be able to resend upon request. To reduce the costs of window
acknowledgements, the protocol uses a large window and only requires an
ack at the halfway point.
Each packet starts with a six byte header, optionally followed by data bytes with a four byte checksum. There are currently five defined packet types (`DATA', `SYNC', `ACK', `NAK', `SPOS', `CLOSE') which are described below. Although any packet type may include data, any data provided with an `ACK', `NAK' or `CLOSE' packet is ignored.
Every `DATA', `SPOS' and `CLOSE' packet has a sequence number. The sequence numbers are independent for each side. The first packet sent by each side is always number 1. Each packet is numbered one greater than the previous packet, modulo 32.
Every packet has a local channel number and a remote channel number. For all packets at least one channel number is zero. When a UUCP command is sent to the remote system, it is assigned a non-zero local channel number. All packets associated with that UUCP command sent by the local system are given the selected local channel number. All associated packets sent by the remote system are given the selected number as the remote channel number. This permits each UUCP command to be uniquely identified by the channel number on the originating system, and therefore each UUCP package can associate all file data and UUCP command responses with the appropriate command. This is a requirement for bidirectional UUCP transfers.
The protocol maintains a single global file position, which starts at 0. For each incoming packet, any associated data is considered to occur at the current file position, and the file position is incremented by the amount of data contained. The exception is a packet of type `SPOS', which is used to change the file position. The reason for keeping track of the file position is described below.
The header is as follows:
(packet << 3) + locchan
(ack << 3) + remchan
(type << 5) + (caller << 4) + len1
If the data length is non-zero, the packet is immediately followed by the specified number of data bytes. The data bytes are followed by a four byte CRC 32 checksum, with the most significant byte first. The CRC is calculated over the contents of the data field.
The defined packet types are as follows:
When the protocol starts up, both systems send a `SYNC' packet. The `SYNC' packet includes at least three bytes of data. The first two bytes are the maximum packet size the remote system should send, most significant byte first. The third byte is the window size the remote system should use. The remote system may send packets of any size up to the maximum. If there is a fourth byte, it is the number of channels the remote system may use (this must be between 1 and 7, inclusive). Additional data bytes may be defined in the future.
The window size is the number of packets that may be sent before a packet is acknowledged. There is no requirement that every packet be acknowledged; any acknowledgement is considered to acknowledge all packets through the number given. In the current implementation, if one side has no data to send, it sends an `ACK' when half the window is received.
Note that the `NAK' packet corresponds to the unused `g' protocol `SRJ' packet type, rather than to the `RJ' packet type. When a `NAK' is received, only the named packet should be resent, not any subsequent packets.
Note that if both sides have data to send, but a packet is lost, it is perfectly reasonable for one side to continue sending packets, all of which will acknowledge the last packet correctly received, while the system whose packet was lost will be unable to send a new packet because the send window will be full. In this circumstance, neither side will time out and one side of the communication will be effectively shut down for a while. Therefore, any system with outstanding unacknowledged packets should arrange to time out and resend a packet even if data is being received.
Commands are sent as a sequence of data packets with a non-zero local channel number. The last data packet for a command includes a trailing null byte (normally a command will fit in a single data packet). Files are sent as a sequence of data packets ending with one of length zero.
The channel numbers permit a more efficient implementation of the UUCP file send command. Rather than send the command and then wait for the `SY' response before sending the file, the file data is sent beginning immediately after the `S' command is sent. If an `SN' response is received, the file send is aborted, and a final data packet of length zero is sent to indicate that the channel number may be reused. If an `SY' reponse with a file position indicator is received, the file send adjusts to the file position; this is why the protocol maintains a global file position.
Note that the use of channel numbers means that each UUCP system may send commands and file data simultaneously. Moreover, each UUCP system may send multiple files at the same time, using the channel number to disambiguate the data. Sending a file before receiving an acknowledgement for the previous file helps to eliminate the round trip delays inherent in other UUCP protocols.
Go to the first, previous, next, last section, table of contents.