o Unix uucps address this by being very "shy" about sending NAKs,
mostly just letting the sender time out.
This works but hurts throughput.
o DECUS uucp keeps track of the number of received error packets
and sends the NAK only if the number modulo the window size =
1. Thus we send the first NAK right away, but no more until at
least a window-size worth of packets have been received.
^L
UUCP "G" PROTOCOL Page 12
UN047, Tuesday, 4-5 pm
4.2.5 Duplicate Packets
If a packet is received with a number that's already been received and
ACKd it's either
o a duplicate of one we got earlier; our ACKs got lost, so the
sender timed out and is resending its window
o a future packet, and the intervening seven packets were bad
(but this can't happen, since max window size is seven, not
eight)
Since packets must always be acked in sequence, the only correct thing
is to send a NAK indicating the last good (in sequence) received packet.
4.2.6 Miscellaneous
4.2.6.1 Control Packet Priority
The control packet types denote the priority of the packets. That is,
if several control packets are to be sent, the lower-numbered ones are
sent first. (CLOSE before anything else, for example.) Control packets
in turn have priority over data packets.
4.2.6.2 Varying Physical Packet Lengths
Although the protocol allows for data packets with different K values
(physical lengths) to be sent in a session, in practice, both ends
always use the value negotiated at the start of the session.
4.2.6.3 Interpacket Noise
The DLE that begins a packet should follow right on the heels of the
previous packet. Berkeley 4.3 uucp has a bug that causes it to send two
null bytes between packets. A robust implementation will _^Hn_^Ho_^Ht report
errors when it encounters two null bytes while looking for a DLE.
4.2.6.4 Common Parameters
Almost all implementations seem to use a window size of 3 and a data
packet physical length of 64 bytes (Kbyte = 2). Some implementations
will agree to use a larger window size or packet length, but do not do
so correctly.
^L
UUCP "G" PROTOCOL Page 13
UN047, Tuesday, 4-5 pm
4.2.6.5 Checksum Details
The checksum that is placed in the packet header for data packets has
the value
MAGIC - (chksum(buf,len) ^ (0xFF & cbyte))
For control packets, the checksum value is simply
MAGIC - (0xFF & cbyte)
where
buf is the data segment
len is its (physical) length
chksum() is shown below
cbyte is the value of the control byte
MAGIC is 0125252 (octal) (i.e. alternating bits set)
If a data packet is resent, the checksum must be recalculated, as the
checksum includes the control byte and the Y field (last good received
packet number) of the control byte might change between transmissions of
the same data packet.
/*
* the checksum routine, copied from G. L. Chesson's article,
* modified by John Gilmore to reflect actual behavior
* (see References)
*/
int
chksum(s,n)
register unsigned char *s;
register n;
{
register short sum;
register unsigned short t;
register short x;
sum = -1;
x = 0;
do {
if (sum < 0) {
sum <<= 1;
sum++;
}
else
sum <<= 1;
t = sum;
sum += *s++ & 0377;
x += sum ^ n;
if ((unsigned short)sum <= t)
sum ^= x;
} while (--n > 0);
return(sum);
}
^L
UUCP "G" PROTOCOL Page 14
UN047, Tuesday, 4-5 pm
5 FILE TRANSFER "MESSAGES" ("APPLICATION LAYER")
The data packets and acknowledgements form a _^Hr_^He_^Hl_^Hi_^Ha_^Hb_^Hl_^He _^Hd_^Ha_^Ht_^Ha _^Hl_^Hi_^Hn_^Hk which
the two uucico programs use to exchange _^Hm_^He_^Hs_^Hs_^Ha_^Hg_^He_^Hs and _^Hf_^Hi_^Hl_^He_^Hs.
At the start of a uucp session the caller is in _^Hm_^Ha_^Hs_^Ht_^He_^Hr _^Hm_^Ho_^Hd_^He and the
answerer is in _^Hs_^Hl_^Ha_^Hv_^He. The caller searches its uucp spool directory for
work (queued requests to send or receive files). Each such "work
request" results in an "S" (request to send), "R" (request to receive),
or "X" (remote request for uucp) message being sent to the slave:
S _^Hs_^Hr_^Hc_^Hf_^Hi_^Hl_^He_^H__^Ho_^Hn_^H__^Hm_^Ha_^Hs_^Ht_^He_^Hr _^Ht_^Ha_^Hr_^Hg_^He_^Ht_^Hf_^Hi_^Hl_^He_^H__^Ho_^Hn_^H__^Hs_^Hl_^Ha_^Hv_^He ...
R _^Hs_^Hr_^Hc_^Hf_^Hi_^Hl_^He_^H__^Ho_^Hn_^H__^Hs_^Hl_^Ha_^Hv_^He _^Ht_^Ha_^Hr_^Hg_^He_^Ht_^Hf_^Hi_^Hl_^He_^H__^Ho_^Hn_^H__^Hm_^Ha_^Hs_^Ht_^He_^Hr ...
X _^Hs_^Hr_^Hc_^Hf_^Hi_^Hl_^He _^Hu_^Hu_^Hc_^Hp_^Hh_^Ho_^Hs_^Ht_^H!_^Ht_^Ha_^Hr_^Hg_^He_^Ht_^Hf_^Hi_^Hl_^He ... (not covered here)
The slave will respond with one of:
(for send requests)
SY ok
SN2 not permitted
SN4 can't create temporary file
(for receive requests)
RY<mode> ok (gives protection mode of file)
RN2 not permitted
If the master receives any of the reject messages it simply looks for
its next queued work request.
If the master receives an "ok", the master (for file send requests) or
the slave (for file receive requests) sends the file to the other side.
The receiver of the file then sends one of the following messages:
CN5 couldn't move temp file into place
CY file received ok
to the sender.
^L
UUCP "G" PROTOCOL Page 15
UN047, Tuesday, 4-5 pm
6 ROLE EXCHANGE
When the master has no more queued work requests it asks the slave if it
wants to hang up. The slave then looks for work and, if any is found,
the two systems exchange master and slave roles.
Example: Slave has no work, hangup is agreed upon:
