Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

UUCP Internals Frequently Asked Questions
Section - UUCP `y' Protocol

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Property taxes ]


Top Document: UUCP Internals Frequently Asked Questions
Previous Document: UUCP `x' Protocol
Next Document: UUCP `d' Protocol
See reader questions & answers on this topic! - Help others by sharing your knowledge
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.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: UUCP Internals Frequently Asked Questions
Previous Document: UUCP `x' Protocol
Next Document: UUCP `d' Protocol

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
ian@airs.com (Ian Lance Taylor)





Last Update March 27 2014 @ 02:12 PM