ayp@mentor.cc.purdue.edu (Don Ault) (09/19/89)
I would like to find a description of the UUCP "g" protocol. If someone could mail that my direction I would be very greatful! Don Ault -- -------------------------------------------------------------------------------- Don P. Ault Jr. | PUCC General Consultant Purdue University Computing Center | UNIX Group Volunteer West Lafayette, Indiana 47906 | ayp@mentor.cc.purdue.edu
larry@nstar.UUCP (Larry Snyder) (09/26/89)
In article <4102@mentor.cc.purdue.edu>, ayp@mentor.cc.purdue.edu (Don Ault) writes: > I would like to find a description of the UUCP "g" protocol. If someone > could mail that my direction I would be very greatful! > > Don Ault UUCP Handshake Phase ==================== Master Slave ------ ----- <----- \020Shere\0 (1) (2) \020S<mastername> <switches>\0 -----> <----- \020RLCK\0 (3) \020RCB\0 \020ROK\0 \020RBADSEQ\0 <----- \020P<protos>\0 (4) (5) \020U<proto>\0 -----> \020UN\0 (6) ... (0) This communication happens outside of the packet communication that is supported. If the -G flag is sent on the uucico line, all communications will occur without the use of the packet simulation software. The communication at this level is just the characters listed above. (1) The slave sends the sequence indicated, while the master waits for the message. (2) The slave waits for the master to send a response message. The message is composed of the master's name and some optional switches. The switch field can include the following -g (set by the -G switch on the master's uucico command line. Indicates that communication occurs over a packet switch net.) -xN (set by the -x switch on the master's uucico command line. The number N is the debug level desired.) -QM (M is really a sequence number for the communication.) Each switch is separated from the others by a 'blank' character. (3) The slave will send one of the many responses. The meanings appear to be : RLCK This message implies that a 'lock' failure occurred: a file called LCK..mastername couldn't be created since one already exists. This seems to imply that the master is already in communication with the slave. RCB This message will be sent out if the slave requires a call back to the master - the slave will not accept a call from the master but will call the master instead. ROK This message will be returned if the sequence number that was sent in the message, attached to the -Q switch, from the master is the same as that computed on the slave. RBADSEQ Happens if the sequence numbers do not match. (Notes on the sequence number - if a machine does not keep sequence numbers, the value is set to 0. If no -Q switch is given in the master's line, the sequence number is defaulted to 0. The sequence file, SQFILE, has the format <remotename> <number> <month>/<day>-<hour>:<min> where <remotename> is the name of a master and <number> is the previous sequence number. If the <number> field is not present, or if it is greater than 9998, it is set to 0. The <number> field is an ascii representation of the number. The stuff after the <number> is the time the sequence number was last changed, this information doesn't seem important.) (4) The slave sends a message that identifies all the protocols that it supports. It seems that BSD supports 'g' as the normal case. Some sites, such as Allegra, support 'e' and 'g', and a few sites support 'f' as well. I have no information about these protocols. The exact message sent might look like \020Pefg\0 where efg indicates that this slave supports the e,f and g protocols. (5) The slave waits for a response from the master with the chosen protocol. If the master has a protocol that is in common the master will send the message \020U<proto>\0 where <proto> is the protocol (letter) chosen. If no protocol is in common, the master will send the message \020UN\0 (6) At this point both the slave and master agree to use the designated protocol. The first thing that now happens is that the master checks for work. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ UUCP Work Phase =============== Master Slave ------ ----- (a) Master has UUCP Work (1) X file1 file2 -----> <----- XN (2) XY When the master wants the slave to do a 'uux' command it sends the X message. If the slave can't or won't do it, the slave will send an XN message. Otherwise it will send an XY message. (b) Master wants to send a file (1) S file1 file2 user options -----> <----- SN2 (2) SN4 SY <---- <data exchanged>----> (3) <----- CY (4) CN5 If the master wishes to send a file to the slave, it will send a S message to the slave. If the slave can or will do the transfer, it sends a SY message. If the slave has a problem creating work files, it sends a SN4 message. If the target file can't be created (because of priv's etc) it sends a SN2 message. The file1 argument is the source file, and file2 is the (almost) target filename. If file2 is a directory, then the target filename is composed of file2 concatenated with the "last" part of the file1 argument. Note, if the file2 argument begins with X, the request is targeted to UUX and not the normal send. The user argument indicates who, if anyone, is to be notified if the file has been copied. This user must be on the slave system. I am not sure what the options argument does. After the data has been exchanged the slave will send one of two messages to the master. A CY message indicates that every- thing is ok. The message CN5 indicates that the slave had some problem moving the file to it's permanent location. This is not the same as a problem during the exchange of data : this causes the slave to terminate operation. (c) Master wishes to receive a file. (1) R file1 file2 user -----> <----- RN2 (2) RY mode (3) <---- <data exchanged> ----> (4) CY -----> CN5 If the master wishes the slave to send a file, the master sends a R message. If the slave has the file and can send it, the slave will respond with the RY message. If the slave can't find the file, or won't send it the RN2 message is sent. It doesn't appear that the 'mode' field of the RY message is used. The argument file1 is the file to transfer, unless it is a directory. In this case the file to be transferred is built of a concatenation of file1 with the "last" part of the file2 argument. If anything goes wrong with the data transfer, it results in both the slave and the master terminating. After the data has been transferred, the master will send an acknowledgement to the slave. If the transfer and copy to the destination file has been successful, the master will send the CY message. Otherwise it will send the CN5 message. (d) Master has no work, or no more work. (1) H -----> <----- HY (2) HN (3) HY -----> <---- HY (4) (5) ... The transfer of control is initiated with the master sending a H message. This message tells the slave that the master has no work, and the slave should look for work. If the slave has no work it will respond with the HY message. This will tell the master to send an HY message, and turn off the selected protocol. When the HY message is received by the slave, it turns off the selected protocol as well. Both the master and slave enter the UUCP termination phase. If the slave does have work, it sends the HN message to the master. At this point, the slave becomes the master. After the master receives the HN message, it becomes the slave. The whole sequence of sending work starts over again. Note, the transmission of HN doesn't force the master to send any other H messages : it waits for stuff from the new master. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ UUCP Termination Sequence ========================= Master Slave ------ ----- (1) \020OOOOOO\0 -----> <----- \020OOOOOOO\0 (2) At this point all conversation has completed normally. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ UUCP Data Transfers =================== After the initial handshake the systems send messages in one of two styles : packet and not packet. A Packet protocol is just raw data transfers : there is no protocol or acknowledgements; this appears to assume that the lower level is a packet network of some type. If the style is not Packet, then extra work is done. I am still working on this stuff. ****************************************************************************** ** summary of UUCP packets ** (this is much like part 1, but shortened and compared against a live UUCP ~uucp_adm/uucico) note that all transmissions end with a null, not shown here (master) (slave) ... dials up ... <DLE>Shere says "hello" <DLE>S<sysname> <opts> says who he is | <DLE>ROK says ok to talk | <DLE>RLCK says locked out | <DLE>RCB says will call back | <DLE>RBADSEQ says bad seq num <DLE>P<protos> what protocols he has <DLE>U<proto> | which to use <DLE>UN | use none, hang up packet driver is turned on at this time, if not told otherwise -- if master has work -- to sned file to slave... S <mfilenm> <sfilenm> <user> <opts> request to sned file | SY ok -- i'll take it | SN2 not permitted | SN4 can't make workfile <data> the file is transmitted | CY finished OK | CN5 can't move into place to recv file from slave... R <sfilenm> <mfilenm> <user> request to recv file | RY<mode> ok -- here is prot mode | RN2 not permitted <data> file is transmitted CY | worked CN5 | can't move into place to do UUX on slave... X <file1> <file2> request to exec file | XY ok -- will do | XN nopers to indicate that he has no more work... H no more work | HN reverse roles | HY no work here either to accept slave's claim of no more work... HY agrees to hang up the rest of the hang-up is done OUTSIDE of packet driver <DLE>OOOOOO signs off (6*'O') <DLE>OOOOOOO signs off (7*'O') If the slave has work, then the roles are reversed, and the session proceeds from the label 'loop1' above. The system which was the slave is now the master, and the old master is just the slave. The <opts> which follow the system name for the start-up sequence include: -g don't use packet driver (command line -G) -xN debug level (command line -Xn) -QN seq number (if systems use this) The filenames for <mfilenm> should be complete filenames with path information; otherwise they are assumed to be in /usr/spool/uucp. The filenames for <sfilenm> should be either complete filenames or directory names. If directory names are used, then the final componant of <mfilenm> is appended to form the complete filename. The 'X' command to do UUX on a slave is more than a little unclear. It doesn't seem to work here, but that may be a microsoft "feature". Protocol "g", which seems to be the one most commonly used, is supposed to be a slightly munged version of level 2 of X.25. The "packet" mode, with no protocol, does not work under microsoft implementations, and may have *lots* of trouble working anywhere else as well. It evidently requires that zero-length reads happen every so often to delimit things, such as files being transferred. This of course can't happen without the packet driver, which was long gone by the time sys-3 or sys-5 or <your current version> came along. ****************************************************************************** .ce .B Packet Driver Protocol .R .sp 1 .ce G. L. Chesson .br .ce Bell Laboratories .SH Abstract .in +.5i .PP These notes describe the packet driver link protocol that was supplied with the Seventh Edition of .UX and is used by the UUCP program. .in -.5i .SH General .PP Information flow between a pair of machines may be regulated by first representing the data as sequence-numbered .I packets .R of data and then establishing conventions that govern the use of sequence numbers. The .I PK, .R or .I packet driver, .R protocol is a particular instance of this type of flow-control discipline. The technique depends on the notion of a transmission .I window .R to determine upper and lower bounds for valid sequence numbers. The transmitter is allowed to retransmit packets having sequence numbers within the window until the receiver indicates that packets have been correctly received. Positive acknowledgement from the receiver moves the window; negative acknowledgement or no acknowledgement causes retransmission. The receiver must ignore duplicate transmission, detect the various errors that may occur, and inform the transmitter when packets are correctly or incorrectly received. .PP The following paragraphs describe the packet formats, message exchanges, and framing used by the protocol as coded in the UUCP program and the .UX kernel. Although no attempt will be made here to present internal details of the algorithms that were used, the checksum routine is supplied for the benefit of other implementors. .SH Packet Formats .PP The protocol is defined in terms of message transmissions of 8-bit bytes. Each message includes one .I control .R byte plus a .I data segment .R of zero or more information bytes. The allowed data segment sizes range between 32 and 4096 as determined by the formula 32(2\uk\d) where k is a 3-bit number. The packet sequence numbers are likewise constrained to 3-bits; i.e. counting proceeds modulo-8. .PP The control byte is partitioned into three fields as depicted below. .bp .nf .sp .in 1i .ls 1 bit 7 6 5 4 3 2 1 0 t t x x x y y y .ls 1 .in -1i .fi .sp The .I t .R bits indicate a packet type and determine the interpretation to be placed on the .I xxx .R and .I yyy .R fields. The various interpretations are as follows: .in +1i .sp .nf .ls 1 .I tt interpretation .sp .R 00 control packet 10 data packet 11 `short' data packet 01 alternate channel .ls 1 .fi .sp .in -1i A data segment accompanies all non-control packets. Each transmitter is constrained to observe the maximum data segment size established during initial synchronization by the receiver that it sends to. Type 10 packets have maximal size data segments. Type 11, or `short', packets have zero or more data bytes but less than the maximum. The first one or two bytes of the data segment of a short packet are `count' bytes that indicate the difference between the maximum size and the number of bytes in the short segment. If the difference is less than 127, one count byte is used. If the difference exceeds 127, then the low-order seven bits of the difference are put in the first data byte and the high-order bit is set as an indicator that the remaining bits of the difference are in the second byte. Type 01 packets are never used by UUCP and need not be discussed in detail here. .PP The sequence number of a non-control packet is given by the .I xxx .R field. Control packets are not sequenced. The newest sequence number, excluding duplicate transmissions, accepted by a receiver is placed in the .I yyy .R field of non-control packets sent to the `other' receiver. .PP There are no data bytes associated with a control packet, the .I xxx .R field is interpreted as a control message, and the .I yyy .R field is a value accompanying the control message. The control messages are listed below in decreasing priority. That is, if several control messages are to be sent, the lower-numbered ones are sent first. .in +1i .nf .ls 1 .sp .I xxx name yyy .R 1 CLOSE n/a 2 RJ last correctly received sequence number 3 SRJ sequence number to retransmit 4 RR last correctly received sequence number 5 INITC window size 6 INITB data segment size 7 INITA window size .in -i .ls 1 .fi .sp .PP The CLOSE message indicates that the communications channel is to be shut down. The RJ, or .I reject, .R message indicates that the receiver has detected an error and the sender should retransmit after using the .I yyy .R field to update the window. This mode of retransmission is usually referred to as a `go-back-N' procedure. The SRJ, or .I selective reject, .R message carries with it the sequence number of a particular packet to be retransmitted. The RR, or .I receiver ready, .R message indicates that the receiver has detected no errors; the .I yyy .R field updates the sender's window. The INITA/B/C messages are used to set window and data segment sizes. Segment sizes are calculated by the formula 32(2\uyyy\d) as mentioned above, and window sizes may range between 1 and 7. .PP Measurements of the protocol running on communication links at rates up to 9600 baud showed that a window size of 2 is optimal given a packet size greater than 32 bytes. This means that the link bandwidth can be fully utilized by the software. For this reason the SRJ message is not as important as it might otherwise be. Therefore the .UX implementations no longer generate or respond to SRJ messages. It is mentioned here for historical accuracy only, and one may assume that SRJ is no longer part of the protocol. .SH Message Exchanges .SH Initialization .PP Messages are exchanged between four cooperating entities: two senders and two receivers. This means that the communication channel is thought of as two independent half-duplex data paths. For example the window and segment sizes need not be the same in each direction. .PP Initial synchronization is accomplished with two 3-way handshakes: two each of INITA/INITB/INITC. Each sender transmits INITA messages repeatedly. When an INITA message is received, INITB is sent in return. When an INITB message is received .I and .R an INITB message has been sent, an INITC message is sent. The INITA and INITB messages carry with them the packet and window size that each receiver wants to use, and the senders are supposed to comply. When a receiver has seen all three INIT messages, the channel is considered to be open. .PP It is possible to design a protocol that starts up using fewer messages than the interlocked handshakes described above. The advantage of the more complicated design lies in its use as a research vehicle: the initial handshake sequence is completely symmetric, a handshake can be initiated by one side of the link while the connection is in use, and the software to do this can utilize code that would ordinarily be used only once at connection setup time. These properties were used in experiments with dynamically adjusted parameters. That is attempts were made to adapt the window and segment sizes to changes observed in traffic while a link was in use. Other experiments used the initial handshake in a different way for restarting the protocol without data loss after machine crashes. These experiments never worked well in the packet driver and basically provided the impetus for other protocol designs. The result as far as UUCP is concerned is that initial synchronization uses the two 3-way handshakes, and the INIT messages are ignored elsewhere. .SH Data Transport .PP After initial synchronization each receiver sets a modulo-8 incrementing counter R to 0; each sender sets a similar counter S to 1. The value of R is always the number of the most recent correctly received packet. The value of S is always the first sequence number in the output window. Let W denote window size. Note that the value of W may be different for each sender. .PP A sender may transmit packets with sequence numbers in the range S to (S+W-1)\ mod-8. At any particular time a receiver expects arriving packets to have numbers in the range (R+1)\ mod-8 to (R+W)\ mod-8. Packets must arrive in sequence number order are are only acknowledged in order. That is, the `next' packet a receiver will acknowledge must have sequence number (R+1)\ mod-8. .PP A receiver acknowledges receipt of data packets by arranging for the value of its R counter to be sent across the channel where it will be used to update an S counter. This is done in two ways. If data is flowing in both directions across a channel then each receiver's current R value is carried in the . -- Larry Snyder uucp: iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site Notre Dame, Indiana USA