fgz@lakart.UUCP (Zerbi) (09/14/88)
I am looking for uucp specs, as I would like to implement a standalone uucp for my mac that would be standalone and could run under finder (including interface to read and send mail and read and send news. The interface I already have, I need to have the machine talk to other machines though). The sort of things I need are a list of commands that a master or server would use to request mail, what format the mail is expected to come in, and what protocols are used for transferring it, how calls are actually handled etc...... I would also like to have similar information regarding how the news is exchanged. If anybody could send me info or point me to a place where I could find any of this out, I would greatly appreciate it. ------------------------------------------------------------------------------- Federico Genoese-Zerbi | Esto agnus | etsi insignibus leo. ----->cca!fgz@lakart.UUCP | Fulget sides ------>cfisun!fgz@lakart.UUCP | et habet occasum. ------->mirror!fgz@lakart.UUCP | Mors sit semper praesens | et vives. --------------------------------------------------------------------------------
tissot@nicmad.UUCP (Kevin Tissot) (09/16/88)
I am also interested in UUCP specs, especially the "g" protocol
definition. Thanks in advance.
--
===============================================================================
Kevin Tissot {ucbvax,harvard,rutgers}!uwvax!nicmad!tissot
---------------------> {att,decvax,rolls}!nicmad!tissot
===============================================================================bdb@becker.UUCP (Bruce Becker) (09/20/88)
In article <3183@nicmad.UUCP> tissot@nicmad.UUCP (Kevin Tissot) writes: > > I am also interested in UUCP specs, especially the "g" protocol >definition. Thanks in advance. > >-- >=============================================================================== >Kevin Tissot {ucbvax,harvard,rutgers}!uwvax!nicmad!tissot >---------------------> {att,decvax,rolls}!nicmad!tissot >=============================================================================== I also would like this information. Thanks, Bruce Becker Toronto, Ont. Vox: 1 416 699 1868 Internet: bdb@becker.UUCP, becker@humvax.UUCP, becker@ziebmef.UUCP BitNet: BECKER@HUMBER.BITNET "Once we got the sun going, the planets were a cinch" -pwzygphphp
deanr@lakesys.UUCP (Dean Roth) (09/22/88)
This book can be purchased from some bookstores or directly from
O'Reilly & Associates, Inc.:
"Managing UUCP and USENET"
Telephone # 1-800-338-NUTS (it's a Nutshell Handbook)
UUCP: uunet!ora!nuts
(In MA, 617-527-1392.)
My copy just arrived. I haven't done more than give it a quick
glance, but it looks promising. (Last revision - May 1988.)
===================opinions by: Dean A. Roth=======================
{rutgers, uwvax} uwmcsd1!lakesys!deanr deanr@lakesys.UUCP
P.O. Box 11095
Milwaukee, WI 53211
===================representing Dean A. Roth=======================pfales@ttrde.UUCP (Peter Fales) (09/22/88)
> In article <3183@nicmad.UUCP> tissot@nicmad.UUCP (Kevin Tissot) writes: > > > > I am also interested in UUCP specs, especially the "g" protocol > >definition. Thanks in advance. > > > >-- > >=============================================================================== > >Kevin Tissot {ucbvax,harvard,rutgers}!uwvax!nicmad!tissot Well, I am far from the expert on this subject, but there seems to be enough interest in this to warrant posting. All of this has been posted before (that's where I got it), but it is not real long. The follow shell archive is my collection of documents on the uucp protocols. It includes thes following files: packet.new.ms Source (needs ms macros) for a document describing the g protocol uucp.prot A description of the call setup and initial handshake phases. (Somewhat incomplete and possibly inaccurate). uucp.handshake A discussion (from the net) of this handshake. uucp.docs A list (also from the net) of additional uucp documentation. Peter Fales UUCP: ...att!ttrde!pfales work: (312) 416-5357 AT&T, Room 2F-217 200 Park Plaza Naperville, IL 60566 #!/bin/sh # shar: Shell Archiver # Run the following text with /bin/sh to create: # packet.new.ms # uucp.prot # uucp.handshake # uucp.docs sed 's/^X//' << 'SHAR_EOF' > packet.new.ms X.\" @(#) packet.driver.ms Version hoptoad-1.4 88/03/24 X.\" X.\" format this with [nt]roff -ms. X.\" X.\" From: greg@sgi.uucp (Greg Chesson) X.\" Newsgroups: mod.std.unix X.\" Volume-Number: Volume 9, Number 55 X.\" Subject: Packet Driver Protocol X.\" Message-ID: <7136@ut-sally.UUCP> X.\" Date: 11 Feb 87 23:44:09 GMT X.\" X.\" This message contains a copy of ``Packet Driver Protocol,'' X.\" written by G. L. Chesson while he was at Bell Laboratories. X.\" He remarks that it was approved for public distribution, and that X.\" X.\" The version of the note that you probably have omits the X.\" detail that the transmitted checksum is really 0125252 X.\" - the block checksum function. X.\" X.\" [Note that 0125252 is 0xAAAA, which is easier to remember. X.\" I have folded this update into the document. -- hoptoad!gnu] X.\" X.\" [I have also updated the checksum routine to include one that X.\" works regardless of the size of a "short" or an "int". -- hoptoad!gnu] X.ce X.B XPacket Driver Protocol X.R X.sp 1 X.ce XG. L. Chesson X.br X.ce XBell Laboratories X.SH XAbstract X.in +.5i X.PP XThese notes describe the packet driver link Xprotocol that was supplied Xwith the XSeventh Edition of X.UX Xand is used by the UUCP program. X.in -.5i X.SH XGeneral X.PP XInformation flow between a pair of machines Xmay be regulated by Xfirst Xrepresenting the data Xas sequence-numbered X.I Xpackets X.R Xof data Xand then establishing conventions that Xgovern the use of sequence numbers. XThe X.I XPK, X.R Xor X.I Xpacket driver, X.R Xprotocol Xis a particular instance of this type of Xflow-control discipline. XThe technique depends on the notion of a transmission X.I Xwindow X.R Xto determine upper and lower bounds for valid Xsequence numbers. XThe transmitter is allowed to retransmit packets Xhaving sequence numbers Xwithin the window until the receiver indicates that Xpackets have been correctly received. XPositive acknowledgement from the receiver moves the Xwindow; Xnegative acknowledgement or no acknowledgement Xcauses retransmission. XThe receiver must ignore duplicate transmission, detect Xthe various errors that may occur, Xand inform the transmitter when packets are Xcorrectly or incorrectly received. X.PP XThe following paragraphs describe the packet formats, Xmessage exchanges, Xand framing Xused by the protocol as coded Xin the UUCP program and the X.UX Xkernel. XAlthough no attempt will be made here to present Xinternal details of the algorithms that were used, Xthe checksum routine is supplied Xfor the benefit of other implementors. X.SH XPacket Formats X.PP XThe protocol is defined in terms of message Xtransmissions of 8-bit bytes. XEach message includes one X.I Xcontrol X.R Xbyte plus a X.I Xdata segment X.R Xof zero or more information bytes. XThe allowed data segment sizes range Xbetween 32 and 4096 as determined by the formula X32(2\uk\d) where Xk is a 3-bit number. XThe packet sequence numbers are likewise constrained Xto 3-bits; i.e. counting proceeds modulo-8. X.PP XThe control byte is partitioned into three fields as Xdepicted below. X.bp X.nf X.sp X.in 1i X.ls 1 Xbit 7 6 5 4 3 2 1 0 X t t x x x y y y X.ls 1 X.in -1i X.fi X.sp XThe X.I Xt X.R Xbits indicate a packet type and Xdetermine the interpretation to be placed on Xthe X.I Xxxx X.R Xand X.I Xyyy X.R Xfields. XThe various interpretations are as follows: X.in +1i X.sp X.nf X.ls 1 X.I Xtt interpretation X.sp X.R X00 control packet X10 data packet X11 `short' data packet X01 alternate channel X.ls 1 X.fi X.sp X.in -1i XA data segment accompanies all non-control packets. XEach transmitter is constrained to observe the maximum Xdata segment size Xestablished during initial synchronization by the Xreceiver that it sends to. XType 10 packets have maximal size data segments. XType 11, or `short', packets have zero or more data Xbytes but less than the maximum. XThe first one or two bytes of the data segment of a Xshort packet are `count' bytes that Xindicate the difference between the Xmaximum size and the number of bytes in the short Xsegment. XIf the difference is less than 127, one count Xbyte is used. XIf the difference exceeds 127, Xthen the low-order seven bits of the difference Xare put in the first data byte and the high-order Xbit is set as an indicator that the remaining Xbits of the difference are in the second byte. XType 01 packets are never used by UUCP Xand need not be discussed in detail here. X.PP XThe sequence number of a non-control packet is Xgiven by the X.I Xxxx X.R Xfield. XControl packets are not sequenced. XThe newest sequence number, Xexcluding duplicate transmissions, Xaccepted by a receiver is placed in the X.I Xyyy X.R Xfield of non-control packets sent to the X`other' receiver. X.PP XThere are no data bytes associated with a control packet, Xthe X.I Xxxx X.R Xfield is interpreted as a control message, Xand the X.I Xyyy X.R Xfield is a value accompanying the control message. XThe control messages are listed below in decreasing priority. XThat is, if several control messages are to be sent, Xthe lower-numbered ones are sent first. X.in +1i X.nf X.ls 1 X.sp X.I Xxxx name yyy X.R X X1 CLOSE n/a X2 RJ last correctly received sequence number X3 SRJ sequence number to retransmit X4 RR last correctly received sequence number X5 INITC window size X6 INITB data segment size X7 INITA window size X.in -i X.ls 1 X.fi X.sp X.PP XThe CLOSE message indicates that the communications channel Xis to be shut down. XThe RJ, or X.I Xreject, X.R Xmessage indicates that the receiver has detected an error Xand the sender should retransmit after using the X.I Xyyy X.R Xfield to update the window. XThis mode of retransmission is usually Xreferred to as a X`go-back-N' procedure. XThe SRJ, or X.I Xselective reject, X.R Xmessage carries with it the sequence number of Xa particular packet to be retransmitted. XThe RR, or X.I Xreceiver ready, X.R Xmessage indicates that the receiver has detected Xno errors; the X.I Xyyy X.R Xfield updates the sender's window. XThe INITA/B/C messages are used Xto set window and data segment sizes. XSegment sizes are calculated by the formula X32(2\uyyy\d) Xas mentioned above, Xand window sizes may range between 1 and 7. X.PP XMeasurements of the protocol running on communication Xlinks at rates up to 9600 baud showed that Xa window size of 2 is optimal Xgiven a packet size greater than 32 bytes. XThis means that the link bandwidth can be fully utilized Xby the software. XFor this reason the SRJ message is not as important as it Xmight otherwise be. XTherefore the X.UX Ximplementations no longer generate or respond to SRJ Xmessages. XIt is mentioned here for historical accuracy only, Xand one may assume that SRJ is no longer part of the protocol. X.SH XMessage Exchanges X.SH X Initialization X.PP XMessages are exchanged between four cooperating Xentities: two senders and two receivers. XThis means that the communication channel is thought of Xas two independent half-duplex data paths. XFor example the window and segment sizes need not Xbe the same in each direction. X.PP XInitial synchronization is accomplished Xwith two 3-way handshakes: two each of XINITA/INITB/INITC. XEach sender transmits INITA messages repeatedly. XWhen an INITA message is received, INITB is Xsent in return. XWhen an INITB message is received X.I Xand X.R Xan INITB message has been sent, Xan INITC message is sent. XThe INITA and INITB messages carry Xwith them the packet and window size that Xeach receiver wants to use, Xand the senders are supposed to comply. XWhen a receiver has seen all three XINIT messages, the channel is Xconsidered to be open. X.PP XIt is possible to design a protocol that starts up using Xfewer messages than the interlocked handshakes described above. XThe advantage of the more complicated design lies in its use as Xa research vehicle: Xthe initial handshake sequence is completely symmetric, Xa handshake Xcan be initiated by one side of the link while the Xconnection is in use, and the software to do this can Xutilize code that would ordinarily be used only once Xat connection setup time. XThese properties were used in experiments with dynamically Xadjusted parameters. XThat is attempts were made to adapt the window and segment Xsizes to changes observed in traffic while a link was in use. XOther experiments used the initial Xhandshake in a different way Xfor restarting the protocol without data loss Xafter machine crashes. XThese experiments never worked well in the packet driver and Xbasically provided the impetus for other protocol designs. XThe result Xas far as UUCP is concerned is that initial synchronization Xuses the two 3-way handshakes, and the INIT Xmessages are ignored elsewhere. X.SH X Data Transport X.PP XAfter initial synchronization each receiver Xsets a modulo-8 incrementing counter R to 0; Xeach sender sets a similar counter S to 1. XThe value of R is always the number of the most recent Xcorrectly received packet. XThe value of S is always the first sequence number in Xthe output window. XLet W denote window size. XNote that the value of W may be different for each sender. X.PP XA sender may transmit packets with sequence numbers Xin the range S to (S+W-1)\ mod-8. XAt any particular time a receiver expects Xarriving packets to have numbers in the range X(R+1)\ mod-8 to (R+W)\ mod-8. XPackets must arrive in sequence number order Xare are only acknowledged in order. XThat is, Xthe `next' packet a receiver Xwill acknowledge must have Xsequence number (R+1)\ mod-8. X.PP XA receiver acknowledges receipt of data packets Xby arranging for the value of its R counter to be Xsent across the channel Xwhere it will be used to update an S counter. XThis is done in two ways. XIf data is flowing in both directions across a Xchannel then each receiver's current R value is Xcarried in the X.I Xyyy X.R Xfield of non-control packets. XOtherwise when there is no bidirectional Xdata flow, Xeach receiver's R value is transmitted across the link Xas the X.I Xyyy X.R Xfield of an RR control packet. X.PP XError handling is up to the discretion Xof the receiver. XIt can ignore all errors in which case Xtransmitter timeouts must provide for Xretransmission. XThe receiver may also generate RJ Xerror control packets. XThe X.I Xyyy X.R Xfield of an incoming RJ message replaces Xthe S value of the local sender and Xconstitutes a request for retransmission to start Xat that sequence number. XThe X.I Xyyy X.R Xfield of an incoming SRJ message selects a particular Xpacket for retransmission. X.PP XThe resemblance between the flow control procedure in the Xpacket driver and that defined for X.25 is no accident. XThe packet driver protocol began life as an attempt at Xcleaning up X.25. XThat is why, for example, Xcontrol information is uniform in length (one byte), Xthere is no RNR message (not needed), Xand there is but one timeout defined Xin the sender. X.SH X Termination X.PP XThe CLOSE message is used to terminate communications. XSoftware on either or both ends of the communication Xchannel may initiate termination. XIn any case when one end wants to terminate it sends XCLOSE messages until one is received from the other end Xor until a programmable limit on the number of CLOSE Xmessages is reached. XReceipt of a CLOSE message causes a CLOSE message to be sent. XIn the X.UX Xenvironment Xit also causes the SIGPIPE or X`broken pipe' signal to be sent to Xthe local process using the communication channel. X.SH X Framing X.PP XThe term X.I Xframing X.R Xis used to denote the technique by which the Xbeginning and end of a message is detected Xin a byte stream; X.I Xerror control X.R Xdenotes the method by which transmission Xerrors are detected. XStrategies for framing and error control depend Xupon Xadditional information being transmitted along Xwith the control byte and data segment, Xand the choice of a particular strategy usually Xdepends on characteristics of input/output Xdevices and transmission media. X.PP XSeveral framing techniques are in used in support Xof PK protocol implementations, Xnot all of which can be described in detail here. XThe technique used on asynchronous serial lines Xwill be described. X.PP XA six byte Xframing X.I Xenvelope X.R Xis constructed using the control byte XC of a packet and five other bytes as Xdepicted below. X.in +1i X<DLE><k><c0><c1><C><x> X.in -1i XThe <DLE> symbol denotes the ASCII ctrl/P character. XIf the envelope is to be followed by a data segment, X<k> has the value Xlog\d2\u(size)-4; Xi.e. 1 \(<= k \(<= 8. XIf k is 9, then the envelope represents a control packet. XThe <c0> and <c1> bytes are the low-order and high-order Xbytes respectively of 0xAAAA minus a 16-bit checksum. XFor control packets, this 16-bit checksum is the same Xas the control byte C. XFor data packets, the checksum is calculated by the Xprogram below. XThe <x> byte is the exclusive-or of <k><c0><c1><C>. XError control is accomplished by checking Xa received framing envelope for compliance with the definition, Xand comparing a checksum function of the data segment Xwith <c0><c1>. X.PP XThis particular framing strategy assumes data segments Xare constant-sized: Xthe `unused' bytes in a short packet are actually Xtransmitted. XThis creates a certain amount of overhead which Xcan be eliminated by a more complicated framing technique. XThe advantage of this strategy is that i/o Xdevices can be programmed to take advantage of the Xconstant-sized framing envelopes and data segments. X.bp X.PP XThe checksum calculation is displayed below as a C function. XNote that the code is not truly portable because Xthe definitions of X.I short Xand X.I char Xare not necessarily uniform across all machines Xthat might support this language. XThis code assumes that X.I short Xand X.I char Xare 16 and 8-bits respectively. X.PP X.in +.5i X.nf X.ft CW X.ls 1 X/* [Original document's version corrected to actual version] */ Xchksum(s,n) Xregister char *s; Xregister n; X{ X register short sum; X register unsigned short t; X register short x; X X sum = -1; X x = 0; X X do { X if (sum<0) { X sum <<= 1; X sum++; X } else X sum <<= 1; X t = sum; X sum += (unsigned)*s++ & 0377; X x += sum^n; X if ((unsigned short)sum <= t) { X sum ^= x; X } X } while (--n > 0); X X return(sum); X} X X.fi X.in -.5i X.ft XThe checksum routine used in gnuucp has been updated to avoid depending Xon the particular sizes of X.I char Xand X.I short Xvariables. As long as a X.I char Xholds 8 bits or more, and a X.I short Xholds 16 bits or more, the code will work. XTo test it, uncomment the ``#define short long'' below. XA good compiler produces the same code from this function as from Xthe less portable version. X.PP X.in +.5i X.nf X.ft CW X.ls 1 X#define HIGHBIT16 0x8000 X#define JUST16BITS 0xFFFF X#define JUST8BITS 0x00FF X#define MAGIC 0125252 /* checksum is subtracted from this */ X Xint Xpktchksum(msg, bytes) X unsigned char *msg; X int bytes; X{ X return (JUST16BITS & X (MAGIC - (chksum(&msg[6], bytes) ^ (JUST8BITS & msg[4])))); X X} X X Xint Xchksum(s,n) Xregister unsigned char *s; Xregister n; X{ X/* #define short long /* To make sure it works with shorts > 16 bits */ X register short sum; X register unsigned short t; X register short x; X X sum = (-1) & JUST16BITS; X x = 0; X do { X /* Rotate "sum" left by 1 bit, in a 16-bit barrel */ X if (sum & HIGHBIT16) X { X sum = (1 + (sum << 1)) & JUST16BITS; X } X else X sum <<= 1; X t = sum; X sum = (sum + (*s++ & JUST8BITS)) & JUST16BITS; X x += sum ^ n; X if ((unsigned short)sum <= t) X sum = (sum ^ x) & JUST16BITS; X } while (--n > 0); X X return(sum); X#undef short /* End of debugging check */ X} X.fi X.in -.5i X.ft X XVolume-Number: Volume 14, Number 13 X X SHAR_EOF sed 's/^X//' << 'SHAR_EOF' > uucp.prot XThis is the second issue; the information below is the start of Xwhat has been collected here. It is expected that more information Xwill be collected in the next few weeks, and that information will Xbe forwarded when/if it becomes available. X X ===================================================== X -- part 1 X ===================================================== XThis information came via several people, most of whom snet this Xexact message (probably from their news archives from before we Xjoined the net): X X I am posting this over the network because I believe that X others are interested in knowing the protocols of UUCP. X Below is listed all the information that I have acquired X to date. This includes the initial handshaking phase, though X not the login phase. It also doesn't include information X about the data transfer protocol for non-packet networks X (the -G option left off the uucico command line). But, just X hold on - I am working on that stuff. X X For a point of information : the slave is the UUCP site being X dialed, and the master is the one doing the calling up. The X protocols listed in the handshaking and termination phase are X independent of any UUCP site : it is universal. The stuff in X the work phase depends on the specific protocol chosen. The X concepts in the work phase are independent of protocol, ie. the X sequences are the same. It is just the lower level stuff that X changes from protocol to protocol. I have access only to level X g and will document it as I begin to understand it. X X Most of the stuff you see here is gotten from the debug phase X of the current BSD UUCP system. X X I hope this is useful. Maybe this will get some of the real X 'brains' in UUCP to get off their duffs and provide some real X detail. In any case, if you have any questions please feel X free to contact me. I will post any questions and answers over X the network. X X X Chuck Wegrzyn X {allegra,decvax,ihnp4}!encore!wegrzyn X X (617) 237-1022 X X X X UUCP Handshake Phase X ==================== X XMaster Slave X------ ----- X X <----- \020Shere\0 (1) X X X(2) \020S<mastername> <switches>\0 -----> X X X <----- \020RLCK\0 (3) X \020RCB\0 X \020ROK\0 X \020RBADSEQ\0 X X <----- \020P<protos>\0 (4) X X X(5) \020U<proto>\0 -----> X \020UN\0 X X X(6) ... X X X(0) This communication happens outside of the packet communication that X is supported. If the -G flag is sent on the uucico line, all X communications will occur without the use of the packet X simulation software. The communication at this level is just X the characters listed above. X X(1) The slave sends the sequence indicated, while the master waits for X the message. X X(2) The slave waits for the master to send a response message. The message X is composed of the master's name and some optional switches. X The switch field can include the following X X -g (set by the -G switch on the X master's uucico command line. X Indicates that communication X occurs over a packet switch net.) X -xN (set by the -x switch on the X master's uucico command line. X The number N is the debug level X desired.) X -QM (M is really a sequence number X for the communication.) X X Each switch is separated from the others by a 'blank' character. X X(3) The slave will send one of the many responses. The meanings appear to X be : X X RLCK X X This message implies that a 'lock' failure occurred: X a file called LCK..mastername couldn't be created since X one already exists. This seems to imply that the master X is already in communication with the slave. X X RCB X X This message will be sent out if the slave requires a X call back to the master - the slave will not accept a X call from the master but will call the master instead. X X ROK X X This message will be returned if the sequence number that X was sent in the message, attached to the -Q switch, from X the master is the same as that computed on the slave. X X RBADSEQ X X Happens if the sequence numbers do not match. X X (Notes on the sequence number - if a machine does not keep X sequence numbers, the value is set to 0. If no -Q switch X is given in the master's line, the sequence number is X defaulted to 0. X X The sequence file, SQFILE, has the format X X <remotename> <number> <month>/<day>-<hour>:<min> X X where <remotename> is the name of a master and <number> X is the previous sequence number. If the <number> field X is not present, or if it is greater than 9998, it is X set to 0. The <number> field is an ascii representation X of the number. The stuff after the <number> is the time X the sequence number was last changed, this information X doesn't seem important.) X X(4) The slave sends a message that identifies all the protocols that X it supports. It seems that BSD supports 'g' as the normal case. X Some sites, such as Allegra, support 'e' and 'g', and a few X sites support 'f' as well. I have no information about these X protocols. The exact message sent might look like X X \020Pefg\0 X X where efg indicates that this slave supports the e,f and g X protocols. X X(5) The slave waits for a response from the master with the chosen X protocol. If the master has a protocol that is in common the X master will send the message X X \020U<proto>\0 X X where <proto> is the protocol (letter) chosen. If no protocol X is in common, the master will send the message X X \020UN\0 X X(6) At this point both the slave and master agree to use the designated X protocol. The first thing that now happens is that the master X checks for work. X X+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ X X UUCP Work Phase X =============== X X XMaster Slave X------ ----- X X(a) Master has UUCP Work X X (1) X file1 file2 -----> X X <----- XN (2) X XY X X When the master wants the slave to do a 'uux' command X it sends the X message. If the slave can't or won't X do it, the slave will send an XN message. Otherwise X it will send an XY message. X X(b) Master wants to send a file X X (1) S file1 file2 user options -----> X X <----- SN2 (2) X SN4 X SY X X <---- <data exchanged>----> (3) X X X <----- CY (4) X CN5 X X If the master wishes to send a file to the slave, it will X send a S message to the slave. If the slave can or will do X the transfer, it sends a SY message. If the slave has a X problem creating work files, it sends a SN4 message. If X the target file can't be created (because of priv's etc) X it sends a SN2 message. X X The file1 argument is the source file, and file2 is the X (almost) target filename. If file2 is a directory, then X the target filename is composed of file2 concatenated X with the "last" part of the file1 argument. Note, if the X file2 argument begins with X, the request is targeted to X UUX and not the normal send. X X The user argument indicates who, if anyone, is to be notified X if the file has been copied. This user must be on the slave X system. X X I am not sure what the options argument does. X X After the data has been exchanged the slave will send one of X two messages to the master. A CY message indicates that every- X thing is ok. The message CN5 indicates that the slave had X some problem moving the file to it's permanent location. This X is not the same as a problem during the exchange of data : this X causes the slave to terminate operation. X X(c) Master wishes to receive a file. X X (1) R file1 file2 user -----> X X <----- RN2 (2) X RY mode X X (3) <---- <data exchanged> ----> X X (4) CY -----> X CN5 X X If the master wishes the slave to send a file, the master sends X a R message. If the slave has the file and can send it, the X slave will respond with the RY message. If the slave can't find X the file, or won't send it the RN2 message is sent. It doesn't X appear that the 'mode' field of the RY message is used. X X The argument file1 is the file to transfer, unless it is a X directory. In this case the file to be transferred is built X of a concatenation of file1 with the "last" part of the file2 X argument. X X If anything goes wrong with the data transfer, it results in X both the slave and the master terminating. X X After the data has been transferred, the master will send an X acknowledgement to the slave. If the transfer and copy to the X destination file has been successful, the master will send the X CY message. Otherwise it will send the CN5 message. X X(d) Master has no work, or no more work. X X (1) H -----> X X <----- HY (2) X HN X X (3) HY -----> X X <---- HY (4) X X (5) ... X X The transfer of control is initiated with the master sending X a H message. This message tells the slave that the master has X no work, and the slave should look for work. X X If the slave has no work it will respond with the HY message. X This will tell the master to send an HY message, and turn off X the selected protocol. When the HY message is received by the X slave, it turns off the selected protocol as well. Both the X master and slave enter the UUCP termination phase. X X If the slave does have work, it sends the HN message to the X master. At this point, the slave becomes the master. After X the master receives the HN message, it becomes the slave. X The whole sequence of sending work starts over again. Note, X the transmission of HN doesn't force the master to send any X other H messages : it waits for stuff from the new master. X X++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ X X X UUCP Termination Sequence X ========================= X X Master Slave X ------ ----- X X (1) \020OOOOOO\0 -----> X X <----- \020OOOOOOO\0 (2) X X X X At this point all conversation has completed normally. X X X+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ X X UUCP Data Transfers X =================== X X After the initial handshake the systems send messages in one X of two styles : packet and not packet. A Packet protocol is X just raw data transfers : there is no protocol or acknowledgements; X this appears to assume that the lower level is a packet network X of some type. If the style is not Packet, then extra work is X done. I am still working on this stuff. X X ===================================================== X -- part 2 X ===================================================== X ** summary of UUCP packets ** X(this is much like part 1, but shortened and compared against a Xlive UUCP ~uucp_adm/uucico) X Xnote that all transmissions end with a null, not shown here X X X(master) (slave) X X ... dials up ... <DLE>Shere says "hello" X X<DLE>S<sysname> <opts> says who he is X X | <DLE>ROK says ok to talk X | <DLE>RLCK says locked out X | <DLE>RCB says will call back X | <DLE>RBADSEQ says bad seq num X X <DLE>P<protos> what protocols he has X X<DLE>U<proto> | which to use X<DLE>UN | use none, hang up X X Xpacket driver is turned on at this time, if not told otherwise X X -- if master has work -- X Xto sned file to slave... XS <mfilenm> <sfilenm> <user> <opts> request to sned file X X | SY ok -- i'll take it X | SN2 not permitted X | SN4 can't make workfile X X<data> the file is transmitted X X | CY finished OK X | CN5 can't move into place X X Xto recv file from slave... XR <sfilenm> <mfilenm> <user> request to recv file X X | RY<mode> ok -- here is prot mode X | RN2 not permitted X X <data> file is transmitted X XCY | worked XCN5 | can't move into place X X Xto do UUX on slave... XX <file1> <file2> request to exec file X X | XY ok -- will do X | XN nopers X Xto indicate that he has no more work... XH no more work X X | HN reverse roles X | HY no work here either X Xto accept slave's claim of no more work... X XHY agrees to hang up X Xthe rest of the hang-up is done OUTSIDE of packet driver X<DLE>OOOOOO signs off (6*'O') X X <DLE>OOOOOOO signs off (7*'O') X X XIf the slave has work, then the roles are reversed, and the Xsession proceeds from the label 'loop1' above. The system Xwhich was the slave is now the master, and the old master is Xjust the slave. X XThe <opts> which follow the system name for the start-up sequence Xinclude: X -g don't use packet driver (command line -G) X -xN debug level (command line -Xn) X -QN seq number (if systems use this) X XThe filenames for <mfilenm> should be complete filenames with Xpath information; otherwise they are assumed to be in /usr/spool/uucp. XThe filenames for <sfilenm> should be either complete filenames Xor directory names. If directory names are used, then the final Xcomponant of <mfilenm> is appended to form the complete filename. X XThe 'X' command to do UUX on a slave is more than a little unclear. XIt doesn't seem to work here, but that may be a microsoft "feature". X X XProtocol "g", which seems to be the one most commonly used, is supposed Xto be a slightly munged version of level 2 of X.25; an article was just Xposted in net.unix-wizards (which you probably have already seen) to Xthis effect. The article didn't provide any details on the protocol, Xbut merely mentioned the modifications. X XThe "packet" mode, with no protocol, does not work under microsoft Ximplementations, and may have *lots* of trouble working anywhere Xelse as well. It evidently requires that zero-length reads happen Xevery so often to delimit things, such as files being transferred. XThis of course can't happen without the packet driver, which was long Xgone by the time sys-3 or sys-5 or <your current version> came along. X X********************************** X** end of issue #2 X********************************** X SHAR_EOF sed 's/^X//' << 'SHAR_EOF' > uucp.handshake X X Once you have gotten thru the handshake, the INIT messages are Xasynchronous, so it possible for both master and slave to send the Xfirst INIT message at the same time. It just that both have to wait Xfor the INITA message before they can send the INITB and so on. XThe following are the messages I get when talking to a ATT 3B2 system. X Xwho message control byte values Xsend $10 $09 $71 $aa $39 $eb 0,7,1 Xget $10 $09 $6f $2a $3b $77 0,7,3 Xget $10 $09 $79 $aa $31 $6b 0,6,1 Xsend $10 $09 $79 $2a $31 $eb 0,6,1 Xget $10 $09 $7f $2a $2b $77 0,5,3 Xsend $10 $09 $81 $aa $29 $0b 0,5,1 X X The message format is X byte 0 - synch byte always $10 X byte 1 - buffer size, with protocol g, its either 2 or 9 (control) X bytes 2 and 3 - are checksum X byte 4 - control byte X byte 5 - xor of bytes 1,2,3,4 X X The format of the control byte is X bits 0 and 1 - packet type, 0 - CTRL, 2 - LNGDAT, 3 - SHTDAT X bits 2, 3 and 4 - for CTRL packets, the type of CTRL packet X 1 - CLOSE X 2 - RJ X 3 - SRJ X 4 - RR X 5 - INITC X 6 - INITB X 7 - INITA X bits 5, 6 and 7 - for INIT type, size of INIT, for RJ, SRJ and X RR, seqnum of message. X X So, the message you are getting is right (but not the checksums). It is Xa CTRL packet with a INITA, value of 3 (remember that the value is the last Xthree bits, not four). X XCarl Fosler XIntermetrics, Inc. XBethesda, MD. 301-657-3775. X Xfosler@inmet.inmet.com X X SHAR_EOF sed 's/^X//' << 'SHAR_EOF' > uucp.docs XFrom ihnp4!ptsfa!ames!ll-xn!adelie!ora!tim Sun Jul 26 20:27:34 1987 XPath: ihlpe!ihnp4!ptsfa!ames!ll-xn!adelie!ora!tim XFrom: tim@ora.UUCP (Tim O'Reilly) XNewsgroups: comp.mail.uucp,comp.unix.questions XSubject: Re: UUCP Documentation Wanted XKeywords: UUCP for beginners XMessage-ID: <641@ora.UUCP> XDate: 27 Jul 87 01:27:34 GMT XReferences: <2098@sphinx.uchicago.edu> <876@dasys1.UUCP> XOrganization: O'Reilly & Associates, Inc., Newton, MA XLines: 21 X XIn article <876@dasys1.UUCP>, eravin@dasys1.UUCP (Ed Ravin) writes: X> Check out "Managing UUCP and Usenet", by Grace Todino and Tim O'Reilly, X> They also have a companion volume, called "Using UUCP and Usenet", X> which I haven't looked at yet but it too is probably worthwhile. X> X> ...The publisher was a little slow shipping us our copy: you might want to ask X> them when they expect to ship your order. X XMy apologies for the delayed shipment. We were in the Xprocess of revising the books, and the edition about which you Xhad so many nice things to say was delayed for a while. We Xare now shipping books within no more than two days from the Xdate of the order. X XIncidentally, we now take MasterCard and Visa, and have an X800 number (1-800-338-NUTS). X-- XTim O'Reilly (617) 527-4210 XO'Reilly & Associates, Inc., Publishers of Nutshell Handbooks X981 Chestnut Street, Newton, MA 02164 XUUCP: seismo!uunet!ora!tim ARPA: tim@ora.uu.net X X XFrom ihnp4!gargoyle!sphinx!kat2 Mon Jul 27 10:41:53 1987 XPath: ihlpe!ihnp4!gargoyle!sphinx!kat2 XFrom: kat2@sphinx.uchicago.edu (Robby Kates) XNewsgroups: comp.mail.uucp,comp.unix.questions XSubject: UUCP Documentation References XKeywords: Thanks! XMessage-ID: <2118@sphinx.uchicago.edu> XDate: 27 Jul 87 15:41:53 GMT XReply-To: kat2@sphinx.uchicago.edu (Robby Kates) XDistribution: world XOrganization: University of Chicago Computer Science XLines: 58 XFollowup-To: X X X Thanks to everyone who sent recommendations! I have not been able to get Xresponses through to many of you due to problems in UUCP (how ironic). XAnyways... here is a listing of the recommendations: X XOverall the best (most recommended) : X XNutshell Handbooks on "Setting Up UUCP...." and "Managing UUCP...." from XO'Reilly and Associates. X XO'Reilly & Associates X981 Chesnut St. XNewton, MA 02164 X617-527-4210. X X"Uucp Implementation Description" by D.A. Nowitz. This paper may be found in Xthe UNIX Programmer's Manual, Vol 2, 7th Edition published by Holt, Rinehart Xand Winston. X X"Bringing Up Unix Systems Communications - A Case Study" by Dr. Rebecca Thomas. XUNIX/World June & July 1986 X XAT&T Bell Laboratories Computing Science Technical Report # 111, "Another Try Xat Uucp", Robert T. Morris. (201) 582-4905 X X"Experimental Implementation of UUCP - Security Aspects", D.A. Nowitz, XP. Honeyman and B.E. Redman, January 1984 UniForm Conference Proceedings, XWashington D.C., pages 245-250. X X"HoneyDanBer UUCP - Bringing UNIX Systems into the Information Age" by Bill XRieken and Jim Webb. Part 1 May/June, 1986 issue of ;login. XPart 2 July/August, 1986 issue of ;login. X X"UNIX System V Basic Networking Utilities" select code 307-165 Xfrom AT&T X X"UNIX System Security" Patrick H. Wood & Stphen G. Kochan, Hayden Books XISBN 0-8104-6267-2 (although it doesn't have the ISBN prefix, the Xnumbering looks correct) X XFiedler and Hunter, "UNIX System Administration", Hayden Books, 1986 X XGeneral reference and advice: X XJim Joyce's UNIX Bookstore X47 Potomac St XSF, CA 94117 X415/626-7581 X X XAgain, XThanks to everyone for their help! X-Robby X-- X X-Robby Kates X...ihnp4!gargoyle!sphinx!kat2 Xkat2@sphinx.uchicago.edu X X SHAR_EOF exit -- Peter Fales UUCP: ...att!ttrde!pfales work: (312) 416-5357 AT&T, Room 2F-217 200 Park Plaza Naperville, IL 60566
wcf@psuhcx.psu.edu (Bill Fenner) (09/24/88)
Anyone who wants a description of the UUCP g protocol, contact me. If there is
enough response, I will (re) post.
Bill
--
Bitnet: wcf@psuhcx.bitnet Bill Fenner | "Ain't got no cash,
Internet: wcf@hcx.psu.edu | Ain't got no style
UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | Ain't got no girls
Fido: Sysop at 263/42 (814/238 9633) \hogbbs!wcf| To make me smile"honey@umix.cc.umich.edu (Peter Honeyman) (09/24/88)
here's another one -- X. file JCL cards (known to me). unrecognizable
cards are ignored.
peter
C command to be executed
I file to be used as input for the command
O file to be used as output for the command
F file required to be present before running command; optional second
argument gives name for the file at command execution
R name of user that issued request (relative to the machine named on
the U line)
U second arg is name of site that passed this X. file to me; first arg is
a (random) user name on that site
Z requests status notification if command failed
N requests no status notification if command failed
n requests status notification if command succeeded
B requests that stdin be returned on error
M file (on the requesting host) in which status info should be stored
# comment line