UUCP `i' Protocol
=================

The `i' protocol was written by Ian Lance Taylor (who also wrote this
FAQ).  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:

`\007'
     Every packet begins with `^G'.

`(PACKET << 3) + LOCCHAN'
     The five bit packet number combined with the three bit local
     channel number.  `DATA', `SPOS' and `CLOSE' packets use the packet
     sequence number for the PACKET field.  `NAK' packet types use the
     PACKET field for the sequence number to be resent.  `ACK' and
     `SYNC' do not use the PACKET field, and generally leave it set to
     0.  Packets which are not associated with a UUCP command from the
     local system use a local channel number of 0.

`(ACK << 3) + REMCHAN'
     The five bit packet acknowledgement combined with the three bit
     remote channel number.  The packet acknowledgement is the number
     of the last packet successfully received; it is used by all packet
     types.  Packets which are not sent in response to a UUCP command
     from the remote system use a remote channel number of 0.

`(TYPE << 5) + (CALLER << 4) + LEN1'
     The three bit packet type combined with the one bit packet
     direction combined with the upper four bits of the data length.
     The packet direction bit is always 1 for packets sent by the
     calling UUCP, and 0 for packets sent by the called UUCP.  This
     prevents confusion caused by echoed packets.

LEN2
     The lower eight bits of the data length.  The twelve bits of data
     length permit packets ranging in size from 0 to 4095 bytes.

CHECK
     The exclusive or of the second through fifth bytes of the header.
     This provides an additional check that the header is valid.

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:

0 `DATA'
     This is a plain data packet.

1 `SYNC'
     `SYNC' packets are exchanged when the protocol is initialized, and
     are described further below.  `SYNC' packets do not carry sequence
     numbers (that is, the PACKET field is ignored).

2 `ACK'
     This is an acknowledgement packet.  Since `DATA' packets also carry
     packet acknowledgements, `ACK' packets are only used when one side
     has no data to send.  `ACK' packets do not carry sequence numbers.

3 `NAK'
     This is a negative acknowledgement.  This is sent when a packet is
     received incorrectly, and means that the packet number appearing
     in the PACKET field must be resent.  `NAK' packets do not carry
     sequence numbers (the PACKET field is already used).

4 `SPOS'
     This packet changes the file position.  The packet contains four
     bytes of data holding the file position, most significant byte
     first.  The next packet received will be considered to be at the
     named file position.

5 `CLOSE'
     When the protocol is shut down, each side sends a `CLOSE' packet.
     This packet does have a sequence number, which could be used to
     ensure that all packets were correctly received (this is not
     needed by UUCP, however, which uses the higher level `H' command
     with an `HY' response).

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.