diff options
Diffstat (limited to 'share/FAQ/Text/UUCP_Internals.FAQ')
| -rw-r--r-- | share/FAQ/Text/UUCP_Internals.FAQ | 1603 |
1 files changed, 1603 insertions, 0 deletions
diff --git a/share/FAQ/Text/UUCP_Internals.FAQ b/share/FAQ/Text/UUCP_Internals.FAQ new file mode 100644 index 0000000..5a0702b --- /dev/null +++ b/share/FAQ/Text/UUCP_Internals.FAQ @@ -0,0 +1,1603 @@ +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.1 $ +Last-modified: $Date: 1995/01/04 01:53:38 $ + + 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.'' |
