Of protocols and paper bags,
of packetings and pings.

UUCP is a general-purpose, computer-to-computer file copying system, on
top of which quite a number of different sorts of applications can be
built.  You can think of UUCP as a three-layer cake, with each layer
handling a different aspect of the file transfer:

-  What files should be transferred?
-  How should they be transferred over a communications link?
-  What should be done with them when they arrive?

It's possible to have two or more ways of implementing each of these
layers, and to "mix and match" various combinations of these
implementations to suit a particular need.

The first layer... deciding which files should be transferred...
is common to all implementations of UUCP.  There is an agreed-upon
process for saying things like:

"I want to send you file 'foo', on behalf of a user 'joe' on this
 machine.  OK?"
"Yes, go ahead."
"Here it is........"
"OK, I got it."
"Fine.  User 'sam' on this machine wants you to send me a copy of
 file 'bar', OK?"
"OK, here it is....."
"Got it, thanks.  I'm done."
"I don't have anything to ask you to do at this point."
"Fine.  Goodbye."
"Goodbye."

The last layer... deciding what should be done with a file once it
has been transmitted... is also fairly well standardized.  Crudely
speaking, the UUCP system transmits three kinds of files:

-  Those which describe a command to be executed by the other
   system... for example, "rmail bob" means "receive mail from somebody
   here, and send it to bob, please".
   
-  Those which describe data which is to be fed into a program
   being run on the other system... for example, a file would be sent
   which contained the message which was to be delivered to "bob".

-  Those which contain data being transferred for some other
   purpose... for example, source-file archives which are being
   transferred from a file-server system to a client.

Most UUCP transfers involve the first two sorts of files... electronic
mail messages, network-news articles, and the command-files which cause
these messages and articles to be fed to the proper program for delivery
or other processing.

As you might guess, there are some real security issues here.  You
(as a system administrator) don't want to permit other people to
execute arbitrary commands on your system, or to transfer files
to or from your system's disks without your permission.  Most
implementations of UUCP place severe restrictions on which programs
can be run via the file-transfer mechanism, and the directories into
which files can be written (or read from).

The lowest layer in the "cake"... that of actually transmitting the
data over a communications line... is also fairly standardized.  It has
to be... if two UUCP systems don't speak a common communications protocol,
they can't exchange any data... in fact, they cannot even tell each other
which files they want to send!

There are a number of different communication protocols available within
the UUCP universe.  The 'g' protocol is by far the commonest, and it's
the one you'll most often encounter.  uupc 3.0 also supports the 'f'
protocol, and you may wish to use it under certain conditions.  Other
implementations of UUCP support the 't', 'e', and 'x' protocols,
which uupc 3.0 does not understand and cannot use.

The 'g' protocol
----------------

The 'g' protocol is an answer to the following question:

  "How can we transmit data, consisting of arbitrary 8-bit characters,
   over a telecommunications link which is capable of sending 8-bit
   data, but which is subject to noise and cannot be relied upon to
   deliver all of the characters correctly?"

The 'g' protocol is most commonly used over normal dial-up modems.
It can also be used with dedicated (leased-line) modems, or over
direct machine-to-machine connections.

'g' is a "packet-oriented" protocol. The data being transmitted is broken
up into packets, or chunks, of an agreed-upon size. The sender transmits
one or more packets, and then waits for the receiver to acknowledge that
the packets have been received correctly. Packets are numbered (so the
receiver can tell if they have arrived in the proper order, or if a packet
has been lost in transit) and contain a checksum and a CRC code (so the
receiver can determine if any of the contents have been corrupted by noise
on the phone line). The receiver sends back a series of short packets, to
ACKnowledge the successful reception of a packet, or to Negatively
AcKnowedge a packet which has been lost or damaged. If the sender receives
a NAK, it "backs up" and retransmits packets starting with the first one
which was lost or damaged.

Most implementations of the 'g' protocol use a "sliding window".  The
sender transmits a burst of packets... typically 3 of them... and
then waits for the receiver to ACK packet #1.  Once packet #1 has been
ACKed, the sender transmits packet #4 and waits for an ACK from packet
#2, then sends #5 and waits for an ACK from #3, and so forth.  The
sender will almost always have a "window" of one or more packets
which have been sent, and not yet acknowledged.

The use of a multi-packet window improves the 'g' protocol's performance.
If the window is only 1 packet wide, the sender must stop and wait
for an ACK after each packet... and, because it will take the receiver
some amount of time to check the packet's correctness and send back
an ACK, the transmission will "stall" and the line will sit idle
between packets..  If the window is two or more packets wide, then the sender
can be transmitting a packet while the receiver is checking the
previous one and sending back an ACK... and, with a bit of luck and
a fair wind, the sender will always receive the ACKs in time to allow
it to send another packet as soon as it's ready.

By default, almost all UUCP implementations use the 'g' protocol with
a 3-packet window, unless instructed otherwise.  It gives good performance,
and permits rapid recovery if a packet is damaged in transit.

Under some conditions, it may be useful to increase the size of the 'g'
protocol's window.  This will increase the amount of unacknowledged data
which can be "in transit" at any particular moment, and can reduce the
impact of a "sluggish" receiving system (one which doesn't always
acknowledge packets instantly) or of a telephone connection which delays
transmissions significantly (for example, an overseas call via a
geostationary satellite).

You should not assume that a larger 'g' window will always increase
performance, though.  If your phone line is noisy, and packets are
damaged in transmission at all frequently, then a larger window won't
help much, and can actually hurt... most errors require the retransmission
of an entire window's worth of data, and a larger window thus requires
more retransmission.

Also... there are cases in which some UUCP implementations say that they
can handle a larger window, but in fact cannot do so gracefully.  These
implementations can "drop packets on the floor" if the packets arrive
in large numbers at high speeds... this usually leads to protocol
timeouts, retransmissions, and long delays.

You can also increase the size of the packets used by the 'g' protocol.
In theory, the 'g' protocol can use packets of sizes from 32 to 4096
bytes (the packet size is always a power of two).  In practice, most
uucp implementations use a hard-coded packet size of 64 bytes.  Some
can send packets of a few other sizes, if you ask them to;  very few can
accept packets of any size other than 64 without becoming acutely ill.

Increasing the packet size can increase performance, because more data
is transmitted per packet (each packet having a fixed amount of overhead)
and because the total size of bytes in the window is increased.  It can
hurt performance over noisy phone lines, because more data must be
retransmitted after an error.  Furthermore, many uucp implementations
behave very impolitely if one even attempts to negotiate a packet size of
other than 64 bytes... some implementations send invalid packets, and some
dump core or disconnect abruptly.

Due to its sliding-window characteristic, the 'g' protocol is normally 
self-pacing - it will not send data faster than its peer can accept it.  
For this reason, it is usually unnecessary to use Mac-to-modem flow 
control with the 'g' protocol.  You can, if you wish, enable hardware 
flow control with the 'g' protocl (see the "Modems and cables" document 
for instructions).  You must NOT attempt to use software (XON/XOFF) flow 
control with the 'g' protocol - it won't work and will very probably 
cause your protocol to malfunction.

The 'f' protocol
----------------

The 'f' protocol is an answer to the following question:

  "How can we transmit data, consisting of arbitrary 8-bit characters,
   over a telecommunications link which cannot send characters with
   their 8th bit turned on, or send certain control characters... but
   can be relied upon to deliver data reliably in almost all cases,
   and can be trusted to perform flow control at all stages of the
   link?

The 'f' protocol was originally developed to send data over X.25
packet-switched networks (PSNs), via direct connections between
a computer and a packet assembler/disassembler (PAD).  It has also
shown itself to be useful when sending data over a dial-up phone
connection between computers whose modems support either MNP (the
Microcom Network Protocol) or V.42.

The 'f' protocol is a "streaming" protocol.  Data is transmitted as
a sequence of bytes, without packet headers or trailers.  Data is
sent continuously, except when the data link (modem or PAD) uses
a flow-control mechanism to report that the link is becoming
backlogged... at which point the transmission ceases until the
link is once again free.  The only characters transmitted over
the link are printable 7-bit ASCII characters... any other (high-bit
or control) characters in the original data are converted into
two-character "escape sequences" by the sender, and are converted
back into their correct form by the receiver.

The receiver does not send back periodic ACK/NAK indications, as is done in
the 'g' protocol. Instead, it calculates a checksum of the file, as the
file is received. At the end of the file, the sender transmits the checksum
that it has calculated, and the receiver checks this value against its own
version. If the checksums match, the receiver says (in effect) "Got it!" If
the checksums do not match, the receiver sends a "Beg pardon, how's that
again?" and the sender retransmits the _entire_ file.

As you can infer, the 'f' protocol is extremely sensitive to data
errors... a single one-byte error anywhere in the file will cause the
entire file to be retransmitted.  For this reason, the 'f' protocol
should _not_ be used over dial-up modem lines, unless the modems
support MNP or V.42 error control and have been configured to use it.
Similarly, the 'f' protocol should _not_ be used if you are running
LocalTalk via your printer port... when LocalTalk packets arrive, the
LocalTalk driver turns off interrupts for a few milliseconds, and this
can cause your modem port to overrun its FIFO and lose a character or
two.

The 'f' protocol usually requires flow control to avoid overrunning 
buffers in your modem or network.  Software (XON/XOFF) flow control is 
most commonly used at the Macintosh end;  hardware handshaking can be 
used as well, if you have a suitable cable and modem (see the "Modems and 
cables" document for details).