1604 lines
71 KiB
Plaintext
1604 lines
71 KiB
Plaintext
Path: bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian
|
|
From: ian@airs.com (Ian Lance Taylor)
|
|
Newsgroups: comp.mail.uucp,comp.answers,news.answers
|
|
Subject: UUCP Internals Frequently Asked Questions
|
|
Keywords: UUCP, protocol, FAQ
|
|
Message-ID: <uucp-internals_787915801@airs.com>
|
|
Date: 20 Dec 94 09:30:02 GMT
|
|
Expires: 31 Jan 95 09:30:01 GMT
|
|
Reply-To: ian@airs.com (Ian Lance Taylor)
|
|
Followup-To: comp.mail.uucp
|
|
Organization: Infinity Development, Waltham, MA
|
|
Lines: 1587
|
|
Approved: news-answers-request@MIT.Edu
|
|
Supersedes: <uucp-internals_785496601@airs.com>
|
|
Xref: bloom-beacon.mit.edu comp.mail.uucp:5270 comp.answers:9043 news.answers:31575
|
|
|
|
Archive-name: uucp-internals
|
|
Version: $Revision: 1.26 $
|
|
Last-modified: $Date: 1994/10/26 02:39:07 $
|
|
|
|
This article was written by Ian Lance Taylor <ian@airs.com> and I may
|
|
even update it periodically. Please send me mail about suggestions
|
|
or inaccuracies.
|
|
|
|
This article describes how the various UUCP protocols work, and
|
|
discusses some other internal UUCP issues. It does not describe how
|
|
to configure UUCP, nor how to solve UUCP connection problems, nor how
|
|
to deal with UUCP mail. I do not know of any FAQ postings on these
|
|
topics. There are some documents on the net describing UUCP
|
|
configuration, but I can not keep an up to date list here; try using
|
|
archie.
|
|
|
|
If you haven't read the news.announce.newusers articles, read them.
|
|
|
|
This article is in digest format. Some newsreaders will be able to
|
|
break it apart into separate articles. Please don't ask me how to do
|
|
this, though.
|
|
|
|
This article answers the following questions. If one of these
|
|
questions is posted to comp.mail.uucp, please send mail to the poster
|
|
referring her or him to this FAQ. There is no reason to post a
|
|
followup, as most of us know the answer already.
|
|
|
|
Sources
|
|
What does "alarm" mean in debugging output?
|
|
What are UUCP grades?
|
|
What is the format of a UUCP lock file?
|
|
What is the format of a UUCP X.* file?
|
|
What is the UUCP protocol?
|
|
What is the 'g' protocol?
|
|
What is the 'f' protocol?
|
|
What is the 't' protocol?
|
|
What is the 'e' protocol?
|
|
What is the 'G' protocol?
|
|
What is the 'i' protocol?
|
|
What is the 'j' protocol?
|
|
What is the 'x' protocol?
|
|
What is the 'y' protocol?
|
|
What is the 'd' protocol?
|
|
What is the 'h' protocol?
|
|
What is the 'v' protocol?
|
|
Thanks
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
From: Sources
|
|
Subject: Sources
|
|
|
|
"Unix-to-Unix Copy Program," said PDP-1. "You will never find a more
|
|
wretched hive of bugs and flamers. We must be cautious."
|
|
--DECWars
|
|
|
|
I took a lot of the information from Jamie E. Hanrahan's paper in the
|
|
Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
|
|
O'Reilly and Grace Todino (with contributions by several other
|
|
people). The latter includes most of the former, and is published by
|
|
O'Reilly & Associates, Inc.
|
|
103 Morris Street, Suite A
|
|
Sebastopol, CA 95472
|
|
It is currently in its tenth edition. The ISBN number is
|
|
0-937175-93-5.
|
|
|
|
Some information is originally due to a Usenet article by Chuck
|
|
Wegrzyn. The information on execution files comes partially from
|
|
Peter Honeyman. The information on the 'g' protocol comes partially
|
|
from a paper by G.L. Chesson of Bell Laboratories, partially from
|
|
Jamie E. Hanrahan's paper, and partially from source code by John
|
|
Gilmore. The information on the 'f' protocol comes from the source
|
|
code by Piet Berteema. The information on the 't' protocol comes from
|
|
the source code by Rick Adams. The information on the 'e' protocol
|
|
comes from a Usenet article by Matthias Urlichs. The information on
|
|
the 'd' protocol comes from Jonathan Clark, who also supplied
|
|
information about QFT. The FSUUCP information comes straight from
|
|
Christopher J. Ambler; it applies to version 1.4 and up.
|
|
|
|
Although there are few books about UUCP, there are many about networks
|
|
and protocols in general. I recommend two non-technical books which
|
|
describe the sorts of things that are available on the network: ``The
|
|
Whole Internet,'' by Ed Krol, and ``Zen and the Art of the Internet,''
|
|
by Brendan P. Kehoe. Good technical discussions of networking issues
|
|
can be found in ``Internetworking with TCP/IP,'' by Douglas E. Comer
|
|
and David L. Stevens and in ``Design and Validation of Computer
|
|
Protocols'' by Gerard J. Holzmann.
|
|
|
|
------------------------------
|
|
|
|
From: alarm
|
|
Subject: What does "alarm" mean in debugging output?
|
|
|
|
The debugging output of many versions of UUCP (but not Taylor UUCP)
|
|
will include messages like
|
|
alarm 1
|
|
or
|
|
pkcget: alarm 1
|
|
|
|
This message means that the UUCP package has timed out while waiting
|
|
for some sort of response from the remote system. This normally
|
|
indicates some sort of connection problem. For example, the modems
|
|
might have lost their connection, or perhaps one of the modems will
|
|
not transmit the XON and XOFF characters, or perhaps one side or the
|
|
other is dropping characters. It can also mean that the packages
|
|
disagree about some aspect of the UUCP protocol, although this is less
|
|
common.
|
|
|
|
Using the information in the rest of this posting, you should be able
|
|
to figure out what type of data your UUCP was expecting to receive.
|
|
This may give some indication as to exactly what the problem is. It
|
|
is difficult to be more specific, since there are many possiblities.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-grades
|
|
Subject: What are UUCP grades?
|
|
|
|
Modern UUCP packages support grades for each command. The grades
|
|
generally range from 'A' (the highest) to 'Z' followed by 'a' to 'z'.
|
|
Some UUCP packages also support '0' to '9' before 'A'. Some UUCP
|
|
packages may permit any ASCII character as a grade.
|
|
|
|
On Unix, these grades are encoded in the name of the command file. A
|
|
command file name generally has the form
|
|
C.nnnngssss
|
|
where nnnn is the remote system name for which the command is queued,
|
|
g is a single character grade, and ssss is a four character sequence
|
|
number. For example, a command file created for the system ``airs''
|
|
at grade 'Z' might be named
|
|
C.airsZ2551
|
|
|
|
The remote system name will be truncated to seven characters, to
|
|
ensure that the command file name will fit in the 14 character file
|
|
name limit of the traditional Unix file system. UUCP packages which
|
|
have no other means of distinguishing which command files are intended
|
|
for which systems thus require all systems they connect to to have
|
|
names that are unique in the first seven characters. Some UUCP
|
|
packages use a variant of this format which truncates the system name
|
|
to six characters. HDB and Taylor UUCP use a different spool
|
|
directory format, which allows up to fourteen characters to be used
|
|
for each system name.
|
|
|
|
The sequence number in the command file name may be a decimal integer,
|
|
or it may be a hexadecimal integer, or it may contain any alphanumeric
|
|
character. Different UUCP packages are different.
|
|
|
|
FSUUCP (a DOS based UUCP and news package) uses up to 8 characters for
|
|
file names in the spool (this is a DOS file name limitation; actually,
|
|
with the extension, 11 characters are available, but FSUUCP reserves
|
|
that for future use). FSUUCP defaults mail to grade D, and news to
|
|
grade N, except that when the grade of incoming mail can be
|
|
determined, that grade is preserved if the mail is forwarded to
|
|
another system. Mail and news are currently the only 2 types of
|
|
transfers supported. The default grades may be changed by editing
|
|
the MAIL.RC file for mail, or the FSUUCP.CFG file for news.
|
|
|
|
UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade 'C',
|
|
news at grade 'd', and file transfers at grade 'n'. The UUPC/extended
|
|
UUCP and RMAIL commands accept grades to override the default, the
|
|
others do not.
|
|
|
|
I do not know how command grades are handled in other non-Unix UUCP
|
|
packages.
|
|
|
|
Modern UUCP packages allow you to restrict file transfer by grade
|
|
depending on the time of day. Typically this is done with a line in
|
|
the Systems (or L.sys) file like this:
|
|
airs Any/Z,Any2305-0855 ...
|
|
This allows grades 'Z' and above to be transferred at any time. Lower
|
|
grades may only be transferred at night. I believe that this grade
|
|
restriction applies to local commands as well as to remote commands,
|
|
but I am not sure. It may only apply if the UUCP package places the
|
|
call, not if it is called by the remote system.
|
|
|
|
Taylor UUCP can use the ``timegrade'' and ``call-timegrade'' commands
|
|
to achieve the same effect (and supports the above format when reading
|
|
Systems or L.sys).
|
|
|
|
UUPC/extended provides the symmetricgrades option to announce the
|
|
current grade in effect when calling the remote system.
|
|
|
|
This sort of grade restriction is most useful if you know what grades
|
|
are being used at the remote site. The default grades used depend on
|
|
the UUCP package. Generally uucp and uux have different defaults. A
|
|
particular grade can be specified with the -g option to uucp or uux.
|
|
For example, to request execution of rnews on airs with grade 'd', you
|
|
might use something like
|
|
uux -gd - airs!rnews <article
|
|
|
|
Uunet queues up mail at grade 'C', but increases the grade based on
|
|
the size. News is queued at grade 'd', and file transfers at grade
|
|
'n'. The example above would allow mail (below some large size) to be
|
|
received at any time, but would only permit news to be transferred at
|
|
night.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-lock-file
|
|
Subject: What is the format of a UUCP lock file?
|
|
|
|
This discussion applies only to Unix. I have no idea how UUCP locks
|
|
ports on other systems.
|
|
|
|
UUCP creates files to lock serial ports and systems. On most if not
|
|
all systems these same lock files are also used by cu to coordinate
|
|
access to serial ports. On some systems getty also uses these lock
|
|
files, often under the name uugetty.
|
|
|
|
The lock file normally contains the process ID of the locking process.
|
|
This makes it easy to determine whether a lock is still valid. The
|
|
algorithm is to create a temporary file and then link it to the name
|
|
that must be locked. If the link fails because a file with that name
|
|
already exists, the existing file is read to get the process ID. If
|
|
the process still exists, the lock attempt fails. Otherwise the lock
|
|
file is deleted and the locking algorithm is retried.
|
|
|
|
Older UUCP packages put the lock files in the main UUCP spool
|
|
directory, /usr/spool/uucp. HDB UUCP generally puts the lock files in
|
|
a directory of their own, usually /usr/spool/locks or /etc/locks.
|
|
|
|
The original UUCP lock file format encodes the process ID as a four
|
|
byte binary number. The order of the bytes is host-dependent. HDB
|
|
UUCP stores the process ID as a ten byte ASCII decimal number, with a
|
|
trailing newline. For example, if process 1570 holds a lock file, it
|
|
would contain the eleven characters space, space, space, space, space,
|
|
space, one, five, seven, zero, newline. Some versions of UUCP add a
|
|
second line indicating which program created the lock (uucp, cu, or
|
|
getty/uugetty). I have also seen a third type of UUCP lock file which
|
|
does not contain the process ID at all.
|
|
|
|
The name of the lock file is traditionally "LCK.." followed by the
|
|
base name of the device. For example, to lock /dev/ttyd0 the file
|
|
LCK..ttyd0 would be created. On SCO Unix, the lock file name is
|
|
always forced to lower case even if the device name has upper case
|
|
letters.
|
|
|
|
System V Release 4 UUCP names the lock file using the major and minor
|
|
device numbers rather than the device name. The file is named
|
|
LK.XXX.YYY.ZZZ, where XXX, YYY and ZZZ are all three digit decimal
|
|
numbers. XXX is the major device number of the device holding the
|
|
directory holding the device file (e.g., /dev). YYY is the major
|
|
device number of the device file itself. ZZZ is the minor device
|
|
number of the device file itself. If s holds the result of passing
|
|
the device to the stat system call (e.g., stat ("/dev/ttyd0", &s)),
|
|
the following line of C code will print out the corresponding lock
|
|
file name:
|
|
printf ("LK.%03d.%03d.%03d", major (s.st_dev),
|
|
major (s.st_rdev), minor (s.st_rdev));
|
|
The advantage of this system is that even if there are several links
|
|
to the same device, they will all use the same lock file name.
|
|
|
|
------------------------------
|
|
|
|
From: X-file
|
|
Subject: What is the format of a UUCP X.* file?
|
|
|
|
UUCP X.* files control program execution. They are created by uux.
|
|
They are transferred between computers just like any other file. The
|
|
uuxqt daemon reads them to figure out how to execute the job requested
|
|
by uux.
|
|
|
|
An X.* file is simply a text file. The first character of each line
|
|
is a command, and the remainder of the line supplies arguments. The
|
|
following commands are defined:
|
|
C command
|
|
This gives the command to execute, including the program and
|
|
all arguments. For example,
|
|
C rmail ian@airs.com
|
|
U user system
|
|
This names the user who requested the command, and the system
|
|
from which the request came.
|
|
I standard-input
|
|
This names the file from which standard input is taken. If no
|
|
standard input file is given, the standard input will probably
|
|
be attached to /dev/null. If the standard input file is not
|
|
from the system on which the execution is to occur, it will
|
|
also appear in an F command.
|
|
O standard-output [ system ]
|
|
This names the standard output file. The optional second
|
|
argument names the system to which the file should be sent.
|
|
If there is no second argument, the file should be created on
|
|
the executing system.
|
|
F required-file [ filename-to-use ]
|
|
The F command can appear multiple times. Each F command names
|
|
a file which must exist before the execution can proceed.
|
|
This will usually be a file which is transferred from the
|
|
system on which uux was executed, but it can also be a file
|
|
from the local system or some other system. If the file is
|
|
not from the local system, then the command will usually name
|
|
a file in the spool directory. If the optional second
|
|
argument appears, then the file should be copied to the
|
|
execution directory under that name. This is necessary for
|
|
any file other than the standard input file. If the standard
|
|
input file is not from the local system, it will appear in
|
|
both an F command and an I command.
|
|
R requestor-address
|
|
This is the address to which mail about the job should be
|
|
sent. It is relative to the system named in the U command.
|
|
If the R command does not appear, then mail is sent to the
|
|
user named in the U command.
|
|
Z
|
|
This command takes no arguments. It means that a mail message
|
|
should be sent if the command failed. This is the default
|
|
behaviour for most modern UUCP packages, and for them the Z
|
|
command does not actually do anything.
|
|
N
|
|
This command takes no arguments. It means that no mail
|
|
message should be sent, even if the command failed.
|
|
n
|
|
This command takes no arguments. It means that a mail message
|
|
should be sent if the command succeeded. Normally a message
|
|
is sent only if the command failed.
|
|
B
|
|
This command takes no arguments. It means that the standard
|
|
input should be returned with any error message. This can be
|
|
useful in cases where the input would otherwise be lost.
|
|
e
|
|
This command takes no arguments. It means that the command
|
|
should be processed with /bin/sh. For some packages this is
|
|
the default anyhow. Most packages will refuse to execute
|
|
complex commands or commands containing wildcards, because of
|
|
the security holes this opens.
|
|
E
|
|
This command takes no arguments. It means that the command
|
|
should be processed with the execve system call. For some
|
|
packages this is the default anyhow.
|
|
M status-file
|
|
This command means that instead of mailing a message, the
|
|
message should be copied to the named file on the system named
|
|
by the U command.
|
|
# comment
|
|
This command is ignored, as is any other unrecognized command.
|
|
|
|
Here is an example. Given the following command executed on system
|
|
test1
|
|
uux - test2!cat - test2!~ian/bar !qux '>~/gorp'
|
|
(this is only an example, as most UUCP systems will not permit the cat
|
|
command to be executed) Taylor UUCP will produce the following X.
|
|
file:
|
|
U ian test1
|
|
F D.test1N003r qux
|
|
O /usr/spool/uucppublic test1
|
|
F D.test1N003s
|
|
I D.test1N003s
|
|
C cat - ~ian/bar qux
|
|
The standard input will be read into a file and then transferred to
|
|
the file D.test1N003s on system test2, and the file qux will be
|
|
transferred to D.test1N003r on system test2. When the command is
|
|
executed, the latter file will be copied to the execution directory
|
|
under the name qux. Note that since the file ~ian/bar is already on
|
|
the execution system, no action need be taken for it. The standard
|
|
output will be collected in a file, then copied to the directory
|
|
/usr/spool/uucppublic on the system test1.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-protocol
|
|
Subject: What is the UUCP protocol?
|
|
|
|
The UUCP protocol is a conversation between two UUCP packages. A UUCP
|
|
conversation consists of three parts: an initial handshake, a series
|
|
of file transfer requests, and a final handshake.
|
|
|
|
Before the initial handshake, the caller will usually have logged in
|
|
the called machine and somehow started the UUCP package there. On
|
|
Unix this is normally done by setting the shell of the login name used
|
|
to /usr/lib/uucp/uucico.
|
|
|
|
All messages in the initial handshake begin with a ^P (a byte with the
|
|
octal value \020) and end with a null byte (\000). A few systems end
|
|
these messages with a line feed character (\012) instead of a null
|
|
byte; the examples below assume a null byte is being used.
|
|
|
|
Some options below are supported by QFT, which stands for Queued File
|
|
Transfer, and is (or was) an internal Bell Labs version of UUCP.
|
|
|
|
Taylor UUCP size negotiation was introduced by Taylor UUCP, and is
|
|
also supported by DOS based FSUUCP and Amiga based wUUCP and
|
|
UUCP-1.17.
|
|
|
|
The initial handshake goes as follows. It is begun by the called
|
|
machine.
|
|
|
|
called: \020Shere=hostname\000
|
|
The hostname is the UUCP name of the called machine. Older UUCP
|
|
packages do not output it, and simply send \020Shere\000.
|
|
|
|
caller: \020Shostname options\000
|
|
The hostname is the UUCP name of the calling machine. The
|
|
following options may appear (or there may be none):
|
|
-QSEQ
|
|
Report sequence number for this conversation. The
|
|
sequence number is stored at both sites, and incremented
|
|
after each call. If there is a sequence number mismatch,
|
|
something has gone wrong (somebody may have broken
|
|
security by pretending to be one of the machines) and the
|
|
call is denied. If the sequence number changes on one of
|
|
the machines, perhaps because of an attempted breakin or
|
|
because a disk backup was restored, the sequence numbers
|
|
on the two machines must be reconciled manually. This is
|
|
not supported by FSUUCP.
|
|
-xLEVEL
|
|
Requests the called system to set its debugging level to
|
|
the specified value. This is not supported by all
|
|
systems.
|
|
-pGRADE
|
|
-vgrade=GRADE
|
|
Requests the called system to only transfer files of the
|
|
specified grade or higher. This is not supported by all
|
|
systems. Some systems support -p, some support -vgrade=.
|
|
-R
|
|
Indicates that the calling UUCP understands how to restart
|
|
failed file transmissions. Supported only by System V
|
|
Release 4 UUCP and QFT.
|
|
-ULIMIT
|
|
Reports the ulimit value of the calling UUCP. The limit
|
|
is specified as a base 16 number in C notation (e.g.,
|
|
-U0x1000000). This number is the number of 512 byte
|
|
blocks in the largest file which the calling UUCP can
|
|
create. The called UUCP may not transfer a file larger
|
|
than this. Supported only by System V Release 4 UUCP, QFT
|
|
and FSUUCP. FSUUCP reports the lesser of the
|
|
available disk space on the spool directory drive and the
|
|
ulimit variable in FSUUCP.CFG.
|
|
-N
|
|
Indicates that the calling UUCP understands the Taylor
|
|
UUCP size negotiation extension. Not supported by
|
|
traditional UUCP packages.
|
|
|
|
called: \020ROK\000
|
|
There are actually several possible responses.
|
|
ROK
|
|
The calling UUCP is acceptable, and the handshake proceeds
|
|
to the protocol negotiation. Some options may also
|
|
appear; see below.
|
|
ROKN
|
|
The calling UUCP is acceptable, it specified -N, and the
|
|
called UUCP also understands the Taylor UUCP size limiting
|
|
extensions.
|
|
RLCK
|
|
The called UUCP already has a lock for the calling UUCP,
|
|
which normally indicates the two machines are already
|
|
communicating.
|
|
RCB
|
|
The called UUCP will call back. This may be used to avoid
|
|
impostors (but only one machine out of each pair should
|
|
call back, or no conversation will ever begin).
|
|
RBADSEQ
|
|
The call sequence number is wrong (see the -Q discussion
|
|
above).
|
|
RLOGIN
|
|
The calling UUCP is using the wrong login name.
|
|
RYou are unknown to me
|
|
The calling UUCP is not known to the called UUCP, and the
|
|
called UUCP does not permit connections from unknown
|
|
systems. Some versions of UUCP just drop the line rather
|
|
than sending this message.
|
|
|
|
If the response is ROK, the following options are supported by
|
|
System V Release 4 UUCP and QFT.
|
|
-R
|
|
The called UUCP knows how to restart failed file
|
|
transmissions.
|
|
-ULIMIT
|
|
Reports the ulimit value of the called UUCP. The limit is
|
|
specified as a base 16 number in C notation. This number
|
|
is the number of 512 byte blocks in the largest file which
|
|
the called UUCP can create. The calling UUCP may not send
|
|
a file larger than this. Also supported by FSUUCP.
|
|
-xLEVEL
|
|
I'm not sure just what this means. It may request the
|
|
calling UUCP to set its debugging level to the specified
|
|
value.
|
|
If the response is not ROK (or ROKN) both sides hang up the phone,
|
|
abandoning the call.
|
|
|
|
called: \020Pprotocols\000
|
|
Note that the called UUCP outputs two strings in a row. The
|
|
protocols string is a list of UUCP protocols supported by the
|
|
caller. Each UUCP protocol has a single character name. These
|
|
protocols are discussed in more detail later in this document.
|
|
For example, the called UUCP might send \020Pgf\000.
|
|
|
|
caller: \020Uprotocol\000
|
|
The calling UUCP selects which protocol to use out of the
|
|
protocols offered by the called UUCP. If there are no mutually
|
|
supported protocols, the calling UUCP sends \020UN\000 and both
|
|
sides hang up the phone. Otherwise the calling UUCP sends
|
|
something like \020Ug\000.
|
|
|
|
Most UUCP packages will consider each locally supported protocol in
|
|
turn and select the first one supported by the called UUCP. With some
|
|
versions of HDB UUCP, this can be modified by giving a list of
|
|
protocols after the device name in the Devices file or the Systems
|
|
file. For example, to select the 'e' protocol in Systems,
|
|
airs Any ACU,e ...
|
|
or in Devices,
|
|
ACU,e ttyXX ...
|
|
Taylor UUCP provides the ``protocol'' command which may be used either
|
|
for a system or a port.
|
|
|
|
After the protocol has been selected and the initial handshake has been
|
|
completed, both sides turn on the selected protocol. For some
|
|
protocols (notably 'g') a further handshake is done at this point.
|
|
|
|
Each protocol supports a method for sending a command to the remote
|
|
system. This method is used to transmit a series of commands between
|
|
the two UUCP packages. At all times, one package is the master and
|
|
the other is the slave. Initially, the calling UUCP is the master.
|
|
|
|
If a protocol error occurs during the exchange of commands, both sides
|
|
move immediately to the final handshake.
|
|
|
|
The master will send one of four commands: S, R, X or H.
|
|
|
|
Any file name referred to below is either an absolute pathname
|
|
beginning with "/", a public directory pathname beginning with "~/", a
|
|
pathname relative to a user's home directory beginning with "~USER/",
|
|
or a spool directory file name. File names in the spool directory are
|
|
not pathnames, but instead are converted to pathnames within the spool
|
|
directory by UUCP. They always begin with "C." (for a command file
|
|
created by uucp or uux), "D." (for a data file created by uucp, uux or
|
|
by an execution, or received from another system for an execution), or
|
|
"X." (for an execution file created by uux or received from another
|
|
system).
|
|
|
|
master: S FROM TO USER -OPTIONS TEMP MODE NOTIFY SIZE
|
|
The S and the - are literal characters. This is a request by the
|
|
master to send a file to the slave.
|
|
FROM
|
|
The name of the file to send. If the C option does not
|
|
appear in OPTIONS, the master will actually open and send
|
|
this file. Otherwise the file has been copied to the
|
|
spool directory, where it is named TEMP. The slave
|
|
ignores this field unless TO is a directory, in which case
|
|
the basename of FROM will be used as the file name. If
|
|
FROM is a spool directory filename, it must be a data file
|
|
created for or by an execution, and must begin with "D.".
|
|
TO
|
|
The name to give the file on the slave. If this field
|
|
names a directory the file is placed within that directory
|
|
with the basename of FROM. A name ending in `/' is taken
|
|
to be a directory even if one does not already exist with
|
|
that name. If TO begins with `X.', an execution file will
|
|
be created on the slave. Otherwise, if TO begins with
|
|
`D.' it names a data file to be used by some execution
|
|
file. Otherwise, TO should not be in the spool directory.
|
|
USER
|
|
The name of the user who requested the transfer.
|
|
OPTIONS
|
|
A list of options to control the transfer. The following
|
|
options are defined (all options are single characters):
|
|
C
|
|
The file has been copied to the spool directory
|
|
(the master should use TEMP rather than FROM).
|
|
c
|
|
The file has not been copied to the spool
|
|
directory (this is the default).
|
|
d
|
|
The slave should create directories as necessary
|
|
(this is the default).
|
|
f
|
|
The slave should not create directories if
|
|
necessary, but should fail the transfer instead.
|
|
m
|
|
The master should send mail to USER when the
|
|
transfer is complete (not supported by FSUUCP).
|
|
n
|
|
The slave should send mail to NOTIFY when the
|
|
transfer is complete (not supported by FSUUCP).
|
|
TEMP
|
|
If the C option appears in OPTIONS, this names the file to
|
|
be sent. Otherwise if FROM is in the spool directory,
|
|
TEMP is the same as FROM. Otherwise TEMP may be a dummy
|
|
string, such as "D.0". After the transfer has been
|
|
succesfully completed, the master will delete the file
|
|
TEMP.
|
|
MODE
|
|
This is an octal number giving the mode of the file on
|
|
MASTER. If the file is not in the spool directory, the
|
|
slave will always create it with mode 0666, except that if
|
|
(MODE & 0111) is not zero (the file is executable), the
|
|
slave will create the file with mode 0777. If the file is
|
|
in the spool directory, some UUCP packages will use the
|
|
algorithm above and some will always create the file with
|
|
mode 0600. This field is not used by FSUUCP, since it is
|
|
meaningless on DOS.
|
|
NOTIFY
|
|
This field may not be present, and in any case is only
|
|
meaningful if the n option appears in OPTIONS. If the n
|
|
option appears, then when the transfer is successfully
|
|
completed, the slave will send mail to NOTIFY, which must
|
|
be a legal mailing address on the slave. If a SIZE field
|
|
will appear but the n option does not appear, NOTIFY will
|
|
always be present, typically as the string "dummy" or
|
|
simply a pair of double quotes.
|
|
SIZE
|
|
This field is only present when doing Taylor UUCP or SVR4
|
|
UUCP size negotiation, It is the size of the file in
|
|
bytes. Taylor UUCP version 1.03 sends the size as a
|
|
decimal integer, while versions 1.04 and up, and all other
|
|
UUCP packages that support size negotiation, send the size
|
|
in base 16 with a leading 0x.
|
|
|
|
The slave then responds with an S command response.
|
|
SY START
|
|
The slave is willing to accept the file, and file transfer
|
|
begins. The START field will only be present when using
|
|
file restart. It specifies the byte offset into the file
|
|
at which to start sending. If this is a new file, START
|
|
will be 0x0.
|
|
SN2
|
|
The slave denies permission to transfer the file. This
|
|
can mean that the destination directory may not be
|
|
accessed, or that no requests are permitted. It implies
|
|
that the file transfer will never succeed.
|
|
SN4
|
|
The slave is unable to create the necessary temporary
|
|
file. This implies that the file transfer might succeed
|
|
later.
|
|
SN6
|
|
This is only used by Taylor UUCP size negotiation. It
|
|
means that the slave considers the file too large to
|
|
transfer at the moment, but it may be possible to transfer
|
|
it at some other time.
|
|
SN7
|
|
This is only used by Taylor UUCP size negotiation. It
|
|
means that the slave considers the file too large to ever
|
|
transfer.
|
|
SN8
|
|
This is only used by Taylor UUCP. It means that the file
|
|
was already received in a previous conversation. This can
|
|
happen if the receive acknowledgement was lost after it
|
|
was sent by the receiver but before it was received by the
|
|
sender.
|
|
SN9
|
|
This is only used by Taylor UUCP (versions 1.05 and up)
|
|
and FSUUCP (versions 1.5 and up). It means that the
|
|
remote system was unable to open another channel (see the
|
|
discussion of the 'i' protocol for more information about
|
|
channels). This implies that the file transfer might
|
|
succeed later.
|
|
SN10
|
|
This is reportedly used by SVR4 UUCP to mean that the file
|
|
size is too large.
|
|
|
|
If the slave responds with SY, a file transfer begins. When the
|
|
file transfer is complete, the slave sends a C command response.
|
|
CY
|
|
The file transfer was successful.
|
|
CYM
|
|
The file transfer was successful, and the slave wishes to
|
|
become the master; the master should send an H command,
|
|
described below.
|
|
CN5
|
|
The temporary file could not be moved into the final
|
|
location. This implies that the file transfer will never
|
|
succeed.
|
|
|
|
After the C command response has been received (in the SY case) or
|
|
immediately (in an SN case) the master will send another command.
|
|
|
|
master: R FROM TO USER -OPTIONS SIZE
|
|
The R and the - are literal characters. This is a request by the
|
|
master to receive a file from the slave. I do not know how SVR4
|
|
UUCP or QFT implement file transfer restart in this case.
|
|
FROM
|
|
This is the name of the file on the slave which the master
|
|
wishes to receive. It must not be in the spool directory,
|
|
and it may not contain any wildcards.
|
|
TO
|
|
This is the name of the file to create on the master. I
|
|
do not believe that it can be a directory. It may only be
|
|
in the spool directory if this file is being requested to
|
|
support an execution either on the master or on some
|
|
system other than the slave.
|
|
USER
|
|
The name of the user who requested the transfer.
|
|
OPTIONS
|
|
A list of options to control the transfer. The following
|
|
options are defined (all options are single characters):
|
|
d
|
|
The master should create directories as necessary
|
|
(this is the default).
|
|
f
|
|
The master should not create directories if
|
|
necessary, but should fail the transfer instead.
|
|
m
|
|
The master should send mail to USER when the
|
|
transfer is complete.
|
|
SIZE
|
|
This only appears if Taylor UUCP size negotiation is being
|
|
used. It specifies the largest file which the master is
|
|
prepared to accept (when using SVR4 UUCP or QFT, this was
|
|
specified in the -U option during the initial handshake).
|
|
|
|
The slave then responds with an R command response. FSUUCP does
|
|
not support R requests, and always responds with RN2.
|
|
RY MODE [ SIZE ]
|
|
The slave is willing to send the file, and file transfer
|
|
begins. MODE is the octal mode of the file on the slave.
|
|
The master treats this just as the slave does the MODE
|
|
argument in the send command, q.v. I am told that SVR4
|
|
UUCP sends a trailing SIZE argument. For some versions of
|
|
BSD UUCP, the MODE argument may have a trailing M
|
|
character (e.g., RY 0666M). This means that the slave
|
|
wishes to become the master.
|
|
RN2
|
|
The slave is not willing to send the file, either because
|
|
it is not permitted or because the file does not exist.
|
|
This implies that the file request will never succeed.
|
|
RN6
|
|
This is only used by Taylor UUCP size negotiation. It
|
|
means that the file is too large to send, either because
|
|
of the size limit specifies by the master or because the
|
|
slave considers it too large. The file transfer might
|
|
succeed later, or it might not (this will be cleared up in
|
|
a later release of Taylor UUCP).
|
|
RN9
|
|
This is only used by Taylor UUCP (versions 1.05 and up)
|
|
and FSUUCP (versions 1.5 and up). It means that the
|
|
remote system was unable to open another channel (see the
|
|
discussion of the 'i' protocol for more information about
|
|
channels). This implies that the file transfer might
|
|
succeed later.
|
|
|
|
If the slave responds with RY, a file transfer begins. When the
|
|
file transfer is complete, the master sends a C command. The
|
|
slave pretty much ignores this, although it may log it.
|
|
CY
|
|
The file transfer was successful.
|
|
CN5
|
|
The temporary file could not be moved into the final
|
|
location.
|
|
|
|
After the C command response has been sent (in the RY case) or
|
|
immediately (in an RN case) the master will send another command.
|
|
|
|
master: X FROM TO USER -OPTIONS
|
|
The X and the - are literal characters. This is a request by the
|
|
master to, in essence, execute uucp on the slave. The slave
|
|
should execute "uucp FROM TO".
|
|
FROM
|
|
This is the name of the file or files on the slave which
|
|
the master wishes to transfer. Any wildcards are expanded
|
|
on the slave. If the master is requesting that the files
|
|
be transferred to itself, the request would normally
|
|
contain wildcard characters, since otherwise an `R'
|
|
command would suffice. The master can also use this
|
|
command to request that the slave transfer files to a
|
|
third system.
|
|
TO
|
|
This is the name of the file or directory to which the
|
|
files should be transferred. This will normally use a
|
|
UUCP name. For example, if the master wishes to receive
|
|
the files itself, it would use "master!path".
|
|
USER
|
|
The name of the user who requested the transfer.
|
|
OPTIONS
|
|
A list of options to control the transfer. It is not
|
|
clear which, if any, options are supported by most UUCP
|
|
packages.
|
|
|
|
The slave then responds with an X command response. FSUUCP does
|
|
not support X requests, and always responds with XN.
|
|
XY
|
|
The request was accepted, and the appropriate file
|
|
transfer commands have been queued up for later
|
|
processing.
|
|
XN
|
|
The request was denied. No particular reason is given.
|
|
|
|
In either case, the master will then send another command.
|
|
|
|
master: H
|
|
This is used by the master to hang up the connection. The slave
|
|
will respond with an H command response.
|
|
HY
|
|
The slave agrees to hang up the connection. In this case
|
|
the master sends another HY command. In some UUCP
|
|
packages the slave will then send a third HY command. At
|
|
this point the protocol is shut down, and the final
|
|
handshake is begun.
|
|
HN
|
|
The slave does not agree to hang up. In this case the
|
|
master and the slave exchange roles. The next command
|
|
will be sent by the former slave, which is the new master.
|
|
The roles may be reversed several times during a single
|
|
connection.
|
|
|
|
After the protocol has been shut down, the final handshake is
|
|
performed. This handshake has no real purpose, and some UUCP packages
|
|
simply drop the connection rather than do it (in fact, some will drop
|
|
the connection immediately after both sides agree to hangup, without
|
|
even closing down the protocol).
|
|
|
|
caller: \020OOOOOO\000
|
|
called: \020OOOOOOO\000
|
|
|
|
That is, the calling UUCP sends six O's and the called UUCP replies
|
|
with seven O's. Some UUCP packages always send six O's.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-g
|
|
Subject: What is the 'g' protocol?
|
|
|
|
The 'g' protocol is a packet based flow controlled error correcting
|
|
protocol that requires an eight bit clear connection. It is the
|
|
original UUCP protocol, and is supported by all UUCP implementations.
|
|
Many implementations of it are only able to support small window and
|
|
packet sizes, specifically a window size of 3 and a packet size of 64
|
|
bytes, but the protocol itself can support up to a window size of 7
|
|
and a packet size of 4096 bytes. Complaints about the inefficiency of
|
|
the 'g' protocol generally refer to specific implementations, rather
|
|
than to the correctly implemented protocol.
|
|
|
|
The 'g' protocol was originally designed for general packet drivers,
|
|
and thus contains some features that are not used by UUCP, including
|
|
an alternate data channel and the ability to renegotiate packet and
|
|
window sizes during the communication session.
|
|
|
|
The 'g' protocol is spoofed by many Telebit modems. When spoofing is
|
|
in effect, each Telebit modem uses the 'g' protocol to communicate
|
|
with the attached computer, but the data between the modems is sent
|
|
using a Telebit proprietary error correcting protocol. This allows
|
|
for very high throughput over the Telebit connection, which, because
|
|
it is half-duplex, would not normally be able to handle the 'g'
|
|
protocol very well at all. When a Telebit is spoofing the 'g'
|
|
protocol, it forces the packet size to be 64 bytes and the window size
|
|
to be 3.
|
|
|
|
This discussion of the 'g' protocol explains how it works, but does
|
|
not discuss useful error handling techniques. Some discussion of this
|
|
can be found in Jamie E. Hanrahan's paper, cited above.
|
|
|
|
All 'g' protocol communication is done with packets. Each packet
|
|
begins with a six byte header. Control packets consist only of the
|
|
header. Data packets contain additional data.
|
|
|
|
The header is as follows:
|
|
|
|
\020
|
|
Every packet begins with a ^P.
|
|
k (1 <= k <= 9)
|
|
The k value is always 9 for a control packet. For a data
|
|
packet, the k value indicates how much data follows the six
|
|
byte header. The amount of data is 2 ** (k + 4), where **
|
|
indicates exponentiation. Thus a k value of 1 means 32 data
|
|
bytes and a k value of 8 means 4096 data bytes. The k value
|
|
for a data packet must be between 1 and 8 inclusive.
|
|
checksum low byte
|
|
checksum high byte
|
|
The checksum value is described below.
|
|
control byte
|
|
The control byte indicates the type of packet, and is
|
|
described below.
|
|
xor byte
|
|
This byte is the xor of k, the checksum low byte, the checksum
|
|
high byte and the control byte (i.e., the second, third,
|
|
fourth and fifth header bytes). It is used to ensure that the
|
|
header data is valid.
|
|
|
|
The control byte in the header is composed of three bit fields,
|
|
referred to here as TT (two bits), XXX (three bits) and YYY (three
|
|
bits). The control is TTXXXYYY, or (TT << 6) + (XXX << 3) + YYY.
|
|
|
|
The TT field takes on the following values:
|
|
0
|
|
This is a control packet. In this case the k byte in the
|
|
header must be 9. The XXX field indicates the type of control
|
|
packet; these types are described below.
|
|
1
|
|
This is an alternate data channel packet. This is not used by
|
|
UUCP.
|
|
2
|
|
This is a data packet, and the entire contents of the attached
|
|
data field (whose length is given by the k byte in the header)
|
|
are valid. The XXX and YYY fields are described below.
|
|
3
|
|
This is a short data packet. Let the length of the data field
|
|
(as given by the k byte in the header) be L. Let the first
|
|
byte in the data field be B1. If B1 is less than 128 (if the
|
|
most significant bit of B1 is 0), then there are L - B1 valid
|
|
bytes of data in the data field, beginning with the second
|
|
byte. If B1 >= 128, let B2 be the second byte in the data
|
|
field. Then there are L - ((B1 & 0x7f) + (B2 << 7)) valid
|
|
bytes of data in the data field, beginning with the third
|
|
byte. In all cases L bytes of data are sent (and all data
|
|
bytes participate in the checksum calculation) but some of the
|
|
trailing bytes may be dropped by the receiver. The XXX and
|
|
YYY fields are described below.
|
|
|
|
In a data packet (short or not) the XXX field gives the sequence
|
|
number of the packet. Thus sequence numbers can range from 0 to 7,
|
|
inclusive. The YYY field gives the sequence number of the last
|
|
correctly received packet.
|
|
|
|
Each communication direction uses a window which indicates how many
|
|
unacknowledged packets may be transmitted before waiting for an
|
|
acknowledgement. The window may range from 1 to 7, and may be
|
|
different in each direction. For example, if the window is 3 and the
|
|
last packet acknowledged was packet number 6, packet numbers 7, 0 and
|
|
1 may be sent but the sender must wait for an acknowledgement before
|
|
sending packet number 2. This acknowledgement could come as the YYY
|
|
field of a data packet or as the YYY field of a RJ or RR control
|
|
packet (described below).
|
|
|
|
Each packet must be transmitted in order (the sender may not skip
|
|
sequence numbers). Each packet must be acknowledged, and each packet
|
|
must be acknowledged in order.
|
|
|
|
In a control packet, the XXX field takes on the following values:
|
|
1 CLOSE
|
|
The connection should be closed immediately. This is
|
|
typically sent when one side has seen too many errors and
|
|
wants to give up. It is also sent when shutting down the
|
|
protocol. If an unexpected CLOSE packet is received, a CLOSE
|
|
packet should be sent in reply and the 'g' protocol should
|
|
halt, causing UUCP to enter the final handshake.
|
|
2 RJ or NAK
|
|
The last packet was not received correctly. The YYY field
|
|
contains the sequence number of the last correctly received
|
|
packet.
|
|
3 SRJ
|
|
Selective reject. The YYY field contains the sequence number
|
|
of a packet that was not received correctly, and should be
|
|
retransmitted. This is not used by UUCP, and most
|
|
implementations will not recognize it.
|
|
4 RR or ACK
|
|
Packet acknowledgement. The YYY field contains the sequence
|
|
number of the last correctly received packet.
|
|
5 INITC
|
|
Third initialization packet. The YYY field contains the
|
|
maximum window size to use.
|
|
6 INITB
|
|
Second initialization packet. The YYY field contains the
|
|
packet size to use. It requests a size of 2 ** (YYY + 5).
|
|
Note that this is not the same coding used for the k byte in
|
|
the packet header (it is 1 less). Most UUCP implementations
|
|
that request a packet size larger than 64 bytes can handle any
|
|
packet size up to that specified.
|
|
7 INITA
|
|
First initialization packet. The YYY field contains the
|
|
maximum window size to use.
|
|
|
|
The checksum of a control packet is simply 0xaaaa - the control byte.
|
|
|
|
The checksum of a data packet is 0xaaaa - (CHECK ^ the control byte),
|
|
where ^ denotes exclusive or, and CHECK is the result of the following
|
|
routine as run on the contents of the data field (every byte in the
|
|
data field participates in the checksum, even for a short data
|
|
packet). Below is the routine used by Taylor UUCP; it is a slightly
|
|
modified version of a routine which John Gilmore patched from G.L.
|
|
Chesson's original paper. The z argument points to the data and the c
|
|
argument indicates how much data there is.
|
|
|
|
int
|
|
igchecksum (z, c)
|
|
register const char *z;
|
|
register int c;
|
|
{
|
|
register unsigned int ichk1, ichk2;
|
|
|
|
ichk1 = 0xffff;
|
|
ichk2 = 0;
|
|
|
|
do
|
|
{
|
|
register unsigned int b;
|
|
|
|
/* Rotate ichk1 left. */
|
|
if ((ichk1 & 0x8000) == 0)
|
|
ichk1 <<= 1;
|
|
else
|
|
{
|
|
ichk1 <<= 1;
|
|
++ichk1;
|
|
}
|
|
|
|
/* Add the next character to ichk1. */
|
|
b = *z++ & 0xff;
|
|
ichk1 += b;
|
|
|
|
/* Add ichk1 xor the character position in the buffer counting from
|
|
the back to ichk2. */
|
|
ichk2 += ichk1 ^ c;
|
|
|
|
/* If the character was zero, or adding it to ichk1 caused an
|
|
overflow, xor ichk2 to ichk1. */
|
|
if (b == 0 || (ichk1 & 0xffff) < b)
|
|
ichk1 ^= ichk2;
|
|
}
|
|
while (--c > 0);
|
|
|
|
return ichk1 & 0xffff;
|
|
}
|
|
|
|
When the 'g' protocol is started, the calling UUCP sends an INITA
|
|
control packet with the window size it wishes the called UUCP to use.
|
|
The called UUCP responds with an INITA packet with the window size it
|
|
wishes the calling UUCP to use. Pairs of INITB and INITC packets are
|
|
then similarly exchanged. When these exchanges are completed, the
|
|
protocol is considered to have been started.
|
|
|
|
Note that the window and packet sizes are not a negotiation. Each
|
|
system announces the window and packet size which the other system
|
|
should use. It is possible that different window and packet sizes
|
|
will be used in each direction. The protocol works this way on the
|
|
theory that each system knows how much data it can accept without
|
|
getting overrun. Therefore, each system tells the other how much data
|
|
to send before waiting for an acknowledgement.
|
|
|
|
When a UUCP package transmits a command, it sends one or more data
|
|
packets. All the data packets will normally be complete, although
|
|
some UUCP packages may send the last one as a short packet. The
|
|
command string is sent with a trailing null byte, to let the receiving
|
|
package know when the command is finished. Some UUCP packages require
|
|
the last byte of the last packet sent to be null, even if the command
|
|
ends earlier in the packet. Some packages may require all the
|
|
trailing bytes in the last packet to be null, but I have not confirmed
|
|
this.
|
|
|
|
When a UUCP package sends a file, it will send a sequence of data
|
|
packets. The end of the file is signalled by a short data packet
|
|
containing zero valid bytes (it will normally be preceeded by a short
|
|
data packet containing the last few bytes in the file).
|
|
|
|
Note that the sequence numbers cover the entire communication session,
|
|
including both command and file data.
|
|
|
|
When the protocol is shut down, each UUCP package sends a CLOSE
|
|
control packet.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-f
|
|
Subject: What is the 'f' protocol?
|
|
|
|
The 'f' protocol is a seven bit protocol which checksums an entire
|
|
file at a time. It only uses the characters between \040 and \176
|
|
(ASCII space and ~) inclusive as well as the carriage return
|
|
character. It can be very efficient for transferring text only data,
|
|
but it is very inefficient at transferring eight bit data (such as
|
|
compressed news). It is not flow controlled, and the checksum is
|
|
fairly insecure over large files, so using it over a serial connection
|
|
requires handshaking (XON/XOFF can be used) and error correcting
|
|
modems. Some people think it should not be used even under those
|
|
circumstances.
|
|
|
|
I believe the 'f' protocol originated in BSD versions of UUCP. It was
|
|
originally intended for transmission over X.25 PAD links.
|
|
|
|
The 'f' protocol has no startup or finish protocol. However, both
|
|
sides typically sleep for a couple of seconds before starting up,
|
|
because they switch the terminal into XON/XOFF mode and want to allow
|
|
the changes to settle before beginning transmission.
|
|
|
|
When a UUCP package transmits a command, it simply sends a string
|
|
terminated by a carriage return.
|
|
|
|
When a UUCP package transmits a file, each byte b of the file is
|
|
translated according to the following table:
|
|
|
|
0 <= b <= 037: 0172, b + 0100 (0100 to 0137)
|
|
040 <= b <= 0171: b ( 040 to 0171)
|
|
0172 <= b <= 0177: 0173, b - 0100 ( 072 to 077)
|
|
0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
|
|
0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
|
|
0372 <= b <= 0377: 0176, b - 0300 ( 072 to 077)
|
|
|
|
That is, a byte between \040 and \171 inclusive is transmitted as is,
|
|
and all other bytes are prefixed and modified as shown.
|
|
|
|
When all the file data is sent, a seven byte sequence is sent: two
|
|
bytes of \176 followed by four ASCII bytes of the checksum as printed
|
|
in base 16 followed by a carriage return. For example, if the
|
|
checksum was 0x1234, this would be sent: "\176\1761234\r".
|
|
|
|
The checksum is initialized to 0xffff. For each byte that is sent 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;
|
|
|
|
When the receiving UUCP sees the checksum, it compares it against its
|
|
own calculated checksum and replies with a single character followed
|
|
by a carriage return.
|
|
G
|
|
The file was received correctly.
|
|
R
|
|
The checksum did not match, and the file should be resent from
|
|
the beginning.
|
|
Q
|
|
The checksum did not match, but too many retries have occurred
|
|
and the communication session should be abandoned.
|
|
|
|
The sending UUCP checks the returned character and acts accordingly.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-t
|
|
Subject: What is the 't' protocol?
|
|
|
|
The 't' protocol is intended for use on links which provide reliable
|
|
end-to-end connections, such as TCP. It does no error checking or
|
|
flow control, and requires an eight bit clear channel.
|
|
|
|
I believe the 't' protocol originated in BSD versions of UUCP.
|
|
|
|
When a UUCP package transmits a command, it first gets the length of
|
|
the command string, C. It then sends ((C / 512) + 1) * 512 bytes (the
|
|
smallest multiple of 512 which can hold C bytes plus a null byte)
|
|
consisting of the command string itself followed by trailing null
|
|
bytes.
|
|
|
|
When a UUCP package sends a file, it sends it in blocks. Each block
|
|
contains at most 1024 bytes of data. Each block consists of four
|
|
bytes containing the amount of data in binary (most significant byte
|
|
first, the same format as used by the Unix function htonl) followed by
|
|
that amount of data. The end of the file is signalled by a block
|
|
containing zero bytes of data.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-e
|
|
Subject: What is the 'e' protocol?
|
|
|
|
The 'e' protocol is similar to the 't' protocol. It does no flow
|
|
control or error checking and is intended for use over networks
|
|
providing reliable end-to-end connections, such as TCP.
|
|
|
|
The 'e' protocol originated in versions of HDB UUCP.
|
|
|
|
When a UUCP package transmits a command, it simply sends the command
|
|
as an ASCII string terminated by a null byte.
|
|
|
|
When a UUCP package transmits a file, it sends the complete size of
|
|
the file as an ASCII decimal number. The ASCII string is padded out
|
|
to 20 bytes with null bytes (i.e. if the file is 1000 bytes long, it
|
|
sends "1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"). It then sends the
|
|
entire file.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-G
|
|
Subject: What is the 'G' protocol?
|
|
|
|
The 'G' protocol is used by SVR4 UUCP. It is identical to the 'g'
|
|
protocol, except that it is possible to modify the window and packet
|
|
sizes. The SVR4 implementation of the 'g' protocol reportedly is
|
|
fixed at a packet size of 64 and a window size of 7. Supposedly SVR4
|
|
chose to implement a new protocol using a new letter to avoid any
|
|
potential incompatibilities when using different packet or window
|
|
sizes.
|
|
|
|
Most implementations of the 'g' protocol that accept packets larger
|
|
than 64 bytes will also accept packets smaller than whatever they
|
|
requested in the INITB packet. The SVR4 'G' implementation is an
|
|
exception; it will only accept packets of precisely the size it
|
|
requests in the INITB packet.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-i
|
|
Subject: What is the 'i' protocol?
|
|
|
|
The 'i' protocol was written by Ian Lance Taylor (who also wrote this
|
|
FAQ). It is 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.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-j
|
|
Subject: What is the 'j' protocol?
|
|
|
|
The 'j' protocol is a variant of the 'i' protocol. It was also
|
|
written by Ian Lance Taylor, and first appeared in Taylor UUCP version
|
|
1.04.
|
|
|
|
The 'j' protocol is a version of the 'i' protocol designed for
|
|
communication links which intercept a few characters, such as XON or
|
|
XOFF. It is not efficient to use it on a link which intercepts many
|
|
characters, such as a seven bit link. The 'j' protocol performs no
|
|
error correction or detection; that is presumed to be the
|
|
responsibility of the 'i' protocol.
|
|
|
|
When the 'j' protocol starts up, each system sends a printable ASCII
|
|
string indicating which characters it wants to avoid using. The
|
|
string begins with the ASCII character '^' (octal 136) and ends with
|
|
the ASCII character '~' (octal 176). After sending this string, each
|
|
system looks for the corresponding string from the remote system. The
|
|
strings are composed of escape sequences: \ooo, where o is an octal
|
|
digit. For example, sending the string ^\021\023~ means that the
|
|
ASCII XON and XOFF characters should be avoided. The union of the
|
|
characters described in both strings (the string which is sent and the
|
|
string which is received) is the set of characters which must be
|
|
avoided in this conversation. Avoiding a printable ASCII character
|
|
(octal 040 to octal 176, inclusive) is not permitted.
|
|
|
|
After the exchange of characters to avoid, the normal 'i' protocol
|
|
start up is done, and the rest of the conversation uses the normal 'i'
|
|
protocol. However, each 'i' protocol packet is wrapped to become a
|
|
'j' protocol packet.
|
|
|
|
Each 'j' protocol packet consists of a seven byte header, followed by
|
|
data bytes, followed by index bytes, followed by a one byte trailer.
|
|
The packet header looks like this:
|
|
|
|
^
|
|
Every packet begins with the ASCII character '^', octal 136.
|
|
HIGH
|
|
LOW
|
|
These two characters give the total number of bytes in the
|
|
packet. Both HIGH and LOW are printable ASCII characters.
|
|
The length of the packet is (HIGH - 040) * 0100 + (LOW - 040),
|
|
where 040 <= HIGH < 0177 and 040 <= LOW < 0140. This permits
|
|
a length of 6079 bytes, but there is a further restriction on
|
|
packet size described below.
|
|
=
|
|
The ASCII character '=', octal 075.
|
|
DATA-HIGH
|
|
DATA-LOW
|
|
These two characters give the total number of data bytes in
|
|
the packet. The encoding is as described for HIGH and LOW.
|
|
The number of data bytes is the size of the 'i' protocol
|
|
packet wrapped inside this 'j' protocol packet.
|
|
@
|
|
The ASCII character '@', octal 100.
|
|
|
|
The header is followed by the number of data bytes given in DATA-HIGH
|
|
and DATA-LOW. These data bytes are the 'i' protocol packet which is
|
|
being wrapped in the 'j' protocol packet. However, each character in
|
|
the 'i' protocol packet which the 'j' protocol must avoid is
|
|
transformed into a printable ASCII character (recall that avoiding a
|
|
printable ASCII character is not permitted). Two index bytes are used
|
|
for each character which must be transformed.
|
|
|
|
The index bytes immediately follow the data bytes. The index bytes
|
|
are created in pairs. Each pair of index bytes encodes the location
|
|
of a character in the 'i' protocol packet which was transformed to
|
|
become a printable ASCII character. Each pair of index bytes also
|
|
encodes the precise transformation which was performed.
|
|
|
|
When the sender finds a character which must be avoided, it will
|
|
transform it using one or two operations. If the character is 0200 or
|
|
greater, it will subtract 0200. If the resulting character is less
|
|
than 020, or is equal to 0177, it will xor by 020. The result is
|
|
a printable ASCII character.
|
|
|
|
The zero based byte index of the character within the 'i' protocol
|
|
packet is determined. This index is turned into a two byte printable
|
|
ASCII index, INDEX-HIGH and INDEX-LOW, such that the index is
|
|
(INDEX-HIGH - 040) * 040 + (INDEX-LOW - 040). INDEX-LOW is restricted
|
|
such that 040 <= INDEX-LOW < 0100. INDEX-HIGH is not permitted to be
|
|
0176, so 040 <= INDEX-HIGH < 0176. INDEX-LOW is then modified to
|
|
encode the transformation:
|
|
|
|
If the character transformation only had to subtract 0200, then
|
|
INDEX-LOW is used as is.
|
|
|
|
If the character transformation only had to xor by 020, then 040
|
|
is added to INDEX-LOW.
|
|
|
|
If both operations had to be performed, then 0100 is added to
|
|
INDEX-LOW. However, if the value of INDEX-LOW were initially 077,
|
|
then adding 0100 would result in 0177, which is not a printable
|
|
ASCII character. For that special case, INDEX-HIGH is set to
|
|
0176, and INDEX-LOW is set to the original value of INDEX-HIGH.
|
|
|
|
The receiver decodes the index bytes as follows (this is the reverse
|
|
of the operations performed by the sender, presented here for
|
|
additional clarity):
|
|
|
|
The first byte in the index is INDEX-HIGH, and the second is
|
|
INDEX-LOW.
|
|
|
|
If 040 <= INDEX-HIGH < 0176, the index refers to the data byte at
|
|
position (INDEX-HIGH - 040) * 040 + INDEX-LOW % 040.
|
|
|
|
If 040 <= INDEX-LOW < 0100, then 0200 must be added to indexed
|
|
byte.
|
|
|
|
If 0100 <= INDEX-LOW < 0140, then 020 must be xor'ed to the
|
|
indexed byte.
|
|
|
|
If 0140 <= INDEX-LOW < 0177, then 0200 must be added to the
|
|
indexed byte, and 020 must be xor'ed to the indexed byte.
|
|
|
|
If INDEX-HIGH == 0176, the index refers to the data byte at
|
|
position (INDEX-LOW - 040) * 040 + 037. 0200 must be added to the
|
|
indexed byte, and 020 must be xor'ed to the indexed byte.
|
|
|
|
This means the largest 'i' protocol packet which may be wrapped inside
|
|
a 'j' protocol packet is (0175 - 040) * 040 + (077 - 040) == 3007
|
|
bytes.
|
|
|
|
The final character in a 'j' protocol packet, following the index
|
|
bytes, is the ASCII character '~' (octal 176).
|
|
|
|
The motivation behind using an indexing scheme, rather than escape
|
|
characters, is to avoid data movement. The sender may simply add a
|
|
header and a trailer to the 'i' protocol packet. Once the receiver
|
|
has loaded the 'j' protocol packet, it may scan the index bytes,
|
|
transforming the data bytes, and then pass the data bytes directly on
|
|
to the 'i' protocol routine.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-x
|
|
Subject: What is the 'x' protocol?
|
|
|
|
The 'x' protocol is used in Europe (and probably elsewhere) with
|
|
machines that contain an builtin X.25 card and can send eight bit data
|
|
transparently across X.25 circuits, without interference from the X.28
|
|
or X.29 layers. The protocol sends packets of 512 bytes, and relies
|
|
on a write of zero bytes being read as zero bytes without stopping
|
|
communication. It first appeared in the original System V UUCP
|
|
implementation.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-y
|
|
Subject: What is the '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 is a streaming protocol,
|
|
like the 'f' protocol. It requires an eight bit clean connection. It
|
|
performs error detection, but not error correction; when an error is
|
|
detected, the line is dropped. I do not know the implementation
|
|
details.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-d
|
|
Subject: What is the 'd' protocol?
|
|
|
|
This is apparently used for DataKit muxhost (not RS-232) connections.
|
|
No file size is sent. When a file has been completely transferred, a
|
|
write of zero bytes is done; this must be read as zero bytes on the
|
|
other end.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-h
|
|
Subject: What is the 'h' protocol?
|
|
|
|
This is apparently used in some places with HST modems. It does no
|
|
error checking, and is not that different from the 't' protocol. I
|
|
don't know the details.
|
|
|
|
------------------------------
|
|
|
|
From: UUCP-v
|
|
Subject: What is the 'v' protocol?
|
|
|
|
The 'v' protocol is used by UUPC/extended, a PC UUCP program. It is
|
|
simply a version of the 'g' protocol which supports packets of any
|
|
size, and also supports sending packets of different sizes during the
|
|
same conversation. There are many 'g' protocol implementations which
|
|
support both, but there are also many which do not. Using 'v' ensures
|
|
that everything is supported.
|
|
|
|
------------------------------
|
|
|
|
From: Thanks
|
|
Subject: Thanks
|
|
|
|
Besides the papers and information acknowledged at the top of this
|
|
article, the following people have contributed help, advice,
|
|
suggestions and information:
|
|
Earle Ake 513-429-6500 <ake@Dayton.SAIC.COM>
|
|
cambler@nike.calpoly.edu (Christopher J. Ambler)
|
|
jhc@iscp.bellcore.com (Jonathan Clark)
|
|
jorge@laser.satlink.net (Jorge Cwik)
|
|
celit!billd@UCSD.EDU (Bill Davidson)
|
|
"Drew Derbyshire" <ahd@kew.com>
|
|
erik@pdnfido.fidonet.org
|
|
Matthew Farwell <dylan@ibmpcug.co.uk>
|
|
dgilbert@gamiga.guelphnet.dweomer.org (David Gilbert)
|
|
kherron@ms.uky.edu (Kenneth Herron)
|
|
Mike Ipatow <mip@fido.itc.e-burg.su>
|
|
Romain Kang <romain@pyramid.com>
|
|
"Jonathan I. Kamens" <jik@GZA.COM>
|
|
"David J. MacKenzie" <djm@eng.umd.edu>
|
|
jum@helios.de (Jens-Uwe Mager)
|
|
peter@xpoint.ruessel.sub.org (Peter Mandrella)
|
|
david nugent <david@csource.oz.au>
|
|
Stephen.Page@prg.oxford.ac.uk
|
|
joey@tessi.UUCP (Joey Pruett)
|
|
James Revell <revell@uunet.uu.net>
|
|
Larry Rosenman <ler@lerami.lerctr.org>
|
|
Rich Salz <rsalz@bbn.com>
|
|
evesg@etlrips.etl.go.jp (Gjoen Stein)
|
|
kls@ditka.Chicago.COM (Karl Swartz)
|
|
Dima Volodin <dvv@hq.demos.su>
|
|
jon@console.ais.org (Jon Zeeff)
|
|
Eric Ziegast <ziegast@uunet.uu.net>
|
|
|
|
------------------------------
|
|
|
|
End of UUCP Internals Frequently Asked Questions
|
|
******************************
|
|
--
|
|
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
|
|
``You don't have to sleep. That's just something *they* tell you to keep
|
|
*control* over you. Nobody has to sleep; you're *taught* to sleep when
|
|
you're a kid. If you're really determined, you can get over it.''
|