wynkoop@esquire.UUCP (Brett Wynkoop) (04/10/88)
Greetings-
My frustration level is very high at the moment. I have been trying
with very little luck to get uucp running on my level 2 os9 system (512k
coco3). I have the 68000 FLEX source in C, but I am not a C or OS9 wizard,
and as a result have not gotten very far. Will someone out there pick up
the chalange and try porting this code to the coco. I know it can not be
that hard for someone with experence in C (something I do not have I am
the hardware man for my site).
If anyone is interested in picking up the challange send me email or
reply with a posting and I will get the source to you either over the net or
mailing a disk or whatever.
Someone please help! I think uucp is the only thing I need to make my
little COCO a very happy machine. If someone does do the port I will
donate my system mail program to the effort! How is that for a cheap net
node under $500!!
-Brett
---------------------------------------------------------------------------
uucp................!rutgers!cmcl2!esquire!wynkoop
voice................212-266-0741
OS9 seven steps ahead!
---------------------------------------------------------------------------rms@frog.UUCP (Bob Santy) (04/12/88)
In article <382@esquire.UUCP>, wynkoop@esquire.UUCP (Brett Wynkoop) writes: > > Greetings- > My frustration level is very high at the moment. I have been trying > with very little luck to get uucp running on my level 2 os9 system (512k > coco3). I have the 68000 FLEX source in C, but I am not a C or OS9 wizard, Brett: I'll give it a try. I've had some experience porting C programs of considerable size to my COCO-III. Sounds like a good challenge. Bob Santy 5 Johnson Avenue Medford, MA 02155 (617)-488-3515
pete@wlbr.EATON.COM (Pete Lyall) (04/15/88)
In article <2170@frog.UUCP> rms@frog.UUCP (Bob Santy) writes: >In article <382@esquire.UUCP>, wynkoop@esquire.UUCP (Brett Wynkoop) writes: >> >> Greetings- >> My frustration level is very high at the moment. I have been trying >> with very little luck to get uucp running on my level 2 os9 system (512k >> coco3). I have the 68000 FLEX source in C, but I am not a C or OS9 wizard, > >Brett: >I'll give it a try. I've had some experience porting C programs of >considerable size to my COCO-III. Sounds like a good challenge. Bob, Brett, and others... There have been UUCP derivatives floating about in comp.sources.[unix|misc] for quite some time. A few that come to mind are UUSLAVE, UUPC, and DCP. UUSLAVE was alleged to be somewhat limited, and unreliable, although I don't recall the specifics. UUPC was supposed to be primarily set up for the IBM-PC family - I haven't any knowledge of what it would take to port it. The last (DCP) was brought to my attention when Steve Sampson (frequents the NET and Compuserve) ported DCP to Uniflex (a unix clone running on 6809/680x0 hardware). He has sent me his updated sources for the DCP package. I have looked them over, and feel that porting would not be an exceptionally difficult task. Biggest areas of concern will be the IOCTL stuff, the lack of an 'alarm()' function in MW C, and some #defined string literals which are over 16 characters in length (some function names are fairly long as well). As an aside, I believe I have a kludgey but portable solution to the 'alarm()' problem. I too have hacked some substantially large C code over to OS9/LII from unix, and concur that this could be fun (and rewarding!). Conceivably, your os9 system could become a UUCP node if you have a local (and friendly) unix site. Read your UUCP mail over your (early) morning coffee! I have long been using a C-Kermit script to effect my automated transfers, and would really like the additional functionality that having a UUCP-like tool would provide. Bob - count me in - I'll play. Pete -- Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693 Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Internet: pete@wlbr.eaton.com UUCP: {ihnp4,scgvax,jplgodo,voder}!wlbr!pete
ssmith@uxe.cso.uiuc.edu (04/15/88)
I love it!! I am very interested in such a port myself. I cant say that I have the time to do it, but I would be more than happy to make one of our machines a UUCP 'host' if needed. Please mail the source (at your convenience) to my address, and I will take a look at setting it up here. Amazing little machines arent't they? Steven Smith University of Illinois Microbiology. "I don't know what the language of the future will look like, but it will be called FORTRAN" .
ssmith@uxe.cso.uiuc.edu (04/15/88)
>I love it!! I am very interested in such a port myself. I cant say >that I have the time to do it, but I would be more than happy to make >one of our machines a UUCP 'host' if needed. Please mail the source >(at your convenience) to my address, and I will take a look at setting >it up here. Amazing little machines arent't they? > >Steven Smith >University of Illinois Microbiology. > >"I don't know what the language of the future will look like, but it will be >called FORTRAN" >. oops, forgot my address: smith@phylum.life.uiuc.edu (217) 333-2938
megabyte@chinet.UUCP (Dr. Megabyte) (04/15/88)
In article <10624@wlbr.EATON.COM> pete@wlbr.UUCP (0000-Pete Lyall) writes: >your os9 system could become a UUCP node if you have a local (and .... >Bob - count me in - I'll play. Even better, make your OS9 system into a public USENET acess site and promte OS9 to the public that way!!! Having set up UUCP on several Unix systems, and knowing some "friendly" unix systems I volunteer to help on this all I can... as soon as my CoCo3 is back from the shop :-( The thoought of reading comp.sys.m6809 on my CoCo3 instead of frm my Coco3 boggles the mind. Pete, Bob, How do we want to organise ourselves? -- "I Don't Charge Tax, I Collect It" Mark E. Sunderlin UUCP: ihnp4!chinet!megabyte aka Dr. Megabyte CIS: 74026,3235 (304) 267-2911 X544 Mail: IRS National Computer Center P.O. Box 1208 Martinsburg, WV 25401
wynkoop@esquire.UUCP (Brett Wynkoop) (04/17/88)
Greeting-
I have not answered any one on this subject because our machine has
been off the net for a while due to software upgrades. could someone
please repost Bobs article or mail it to me at
....rutgers!cmcl2!esquire!wynkoop
Thanks in advance.
The C source I have is the Flex 68k source from CIS. I have tried to
compile it, but the COCO does not have some of the include files specified
in the header, and I do not have any idea what should be in them or how to
go about constructing them. Would you guys like to get the source from me?
I could send it uucp, or if you give me warning you could dial my coco.
I need the warning so that I can mount the sources as I only have 1 360k
drive and 1 720k drive. This means that not everything is online at once.
Some day a hard drive.
Pete which kermit do you use as I downloaded the compiled version from
CIS and could not get it to work.
I am glad there are so many folks interested in this project. Don't
know how helpful I can be but of course since I have been puzzeling over
this for a while I do want to help if I can.
-Brett
uucp......!rutgers!cmcl2!esquire!wynkoop
voice.....212-266-0741 0900-1700 eastern m-f
OS9.......212-942-0846 8n1 3/12/24 mnp5 login as guest & send mail to wynkooppete@wlbr.EATON.COM (Pete Lyall) (04/19/88)
Here are the two doc files that belong with the other UUCP/DCP
sources:
=========================== CUT HERE ================================
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# uucp1.doc
# uucp2.doc
# This archive created: Mon Apr 18 11:12:34 1988
export PATH; PATH=/bin:$PATH
if test -f 'uucp1.doc'
then
echo shar: will not over-write existing file "'uucp1.doc'"
else
cat << \SHAR_EOF > 'uucp1.doc'
.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
.I
yyy
.R
field of non-control packets.
Otherwise when there is no bidirectional
data flow,
each receiver's R value is transmitted across the link
as the
.I
yyy
.R
field of an RR control packet.
.PP
Error handling is up to the discretion
of the receiver.
It can ignore all errors in which case
transmitter timeouts must provide for
retransmission.
The receiver may also generate RJ
error control packets.
The
.I
yyy
.R
field of an incoming RJ message replaces
the S value of the local sender and
constitutes a request for retransmission to start
at that sequence number.
The
.I
yyy
.R
field of an incoming SRJ message selects a particular
packet for retransmission.
.PP
The resemblance between the flow control procedure in the
packet driver and that defined for X.25 is no accident.
The packet driver protocol began life as an attempt at
cleaning up X.25.
That is why, for example,
control information is uniform in length (one byte),
there is no RNR message (not needed),
and there is but one timeout defined
in the sender.
.SH
Termination
.PP
The CLOSE message is used to terminate communications.
Software on either or both ends of the communication
channel may initiate termination.
In any case when one end wants to terminate it sends
CLOSE messages until one is received from the other end
or until a programmable limit on the number of CLOSE
messages is reached.
Receipt of a CLOSE message causes a CLOSE message to be sent.
In the
.UX
environment
it also causes the SIGPIPE or
`broken pipe' signal to be sent to
the local process using the communication channel.
.SH
Framing
.PP
The term
.I
framing
.R
is used to denote the technique by which the
beginning and end of a message is detected
in a byte stream;
.I
error control
.R
denotes the method by which transmission
errors are detected.
Strategies for framing and error control depend
upon
additional information being transmitted along
with the control byte and data segment,
and the choice of a particular strategy usually
depends on characteristics of input/output
devices and transmission media.
.PP
Several framing techniques are in used in support
of PK protocol implementations,
not all of which can be described in detail here.
The technique used on asynchronous serial lines
will be described.
.PP
A six byte
framing
.I
envelope
.R
is constructed using the control byte
C of a packet and five other bytes as
depicted below.
.in +1i
<DLE><k><c0><c1><C><x>
.in -1i
The <DLE> symbol denotes the ASCII ctrl/P character.
If the envelope is to be followed by a data segment,
<k> has the value
log\d2\u(size)-4;
i.e. 1 \(<= k \(<= 8.
If k is 9, then the envelope represents a control packet.
The <c0> and <c1> bytes are the low-order and high-order
bytes respectively of a 16-bit checksum of the data segment,
if there is one.
For control packets <c1> is zero and <c0> is the same
as the control byte C.
The <x> byte is the exclusive-or of <k><c0><c1><C>.
Error control is accomplished by checking
a received framing envelope for compliance with the definition,
and comparing a checksum function of the data segment
with <c0><c1>.
.PP
This particular framing strategy assumes data segments
are constant-sized:
the `unused' bytes in a short packet are actually
transmitted.
This creates a certain amount of overhead which
can be eliminated by a more complicated framing technique.
The advantage of this strategy is that i/o
devices can be programmed to take advantage of the
constant-sized framing envelopes and data segments.
.bp
.PP
The checksum calculation is displayed below as a C function.
Note that the code is not truly portable because
the definitions of
.I short
and
.I char
are not necessarily uniform across all machines
that might support this language.
This code assumes that
.I short
and
.I char
are 16 and 8-bits respectively.
.PP
.in +.5i
.nf
.ft CW
.ls 1
/* [Original document's version corrected to actual version] */
chksum(s,n)
register char *s;
register n;
{
register short sum;
register unsigned short t;
register short x;
sum = -1;
x = 0;
do {
if (sum<0) {
sum <<= 1;
sum++;
} else
sum <<= 1;
t = sum;
sum += (unsigned)*s++ & 0377;
x += sum^n;
if ((unsigned short)sum <= t) {
sum ^= x;
}
} while (--n > 0);
return(sum);
}
.fi
.in -.5i
.ft R
SHAR_EOF
fi # end of overwriting check
if test -f 'uucp2.doc'
then
echo shar: will not over-write existing file "'uucp2.doc'"
else
cat << \SHAR_EOF > 'uucp2.doc'
I am posting this over the network because I believe that others are interested
in knowing the protocols of UUCP. Below is listed all the information that I
have acquired to date. This includes the initial handshaking phase, though not
the login phase. It also doesn't include information about the data transfer
protocol for non-packet networks (the -G option left off the uucico command
line). But, just hold on - I am working on that stuff.
For a point of information : the slave is the UUCP site being dialed, and the
master is the one doing the calling up. The protocols listed in the
handshaking and termination phase are independent of any UUCP site : it is
universal. The stuff in the work phase depends on the specific protocol
chosen. The concepts in the work phase are independent of protocol, ie. the
sequences are the same. It is just the lower level stuff that changes from
protocol to protocol. I have access only to level g and will document it as I
begin to understand it. Most of the stuff you see here is gotten from the
debug phase of the current BSD UUCP system.
I hope this is useful. Maybe this will get some of the real 'brains' in UUCP
to get off their duffs and provide some real detail. In any case, if you have
any questions please feel free to contact me. I will post any questions and
answers over the network.
Chuck Wegrzyn
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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 **
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 send file to slave...
S <mfilenm> <sfilenm> <user> <opts> request to send 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; an article was just
posted in net.unix-wizards (which you probably have already seen) to
this effect. The article didn't provide any details on the protocol,
but merely mentioned the modifications.
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.
New Info:
I got the answer that version 7 and its descendants use only Shere
while SVR2 uses Shere=xxx (or is it the other way around). Anyway,
the correct change would be to check if there is a '=' then verify
the remote name.
/* EOF */
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
--
Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
Internet: pete@wlbr.eaton.com UUCP: {ihnp4,scgvax,jplgodo,voder}!wlbr!pete jejones@mcrware.UUCP (James Jones) (04/19/88)
Perhaps the first thing to figure out is--which version of UUPC should one start from? I'm not sure which version of UUPC Steve Sampson posted/uploaded (save, of course, that it's for UniFLEX). A fellow who keeps archives of comp.sources.misc was nice enough to mail me the whole megillah (ST, Amiga, and International BM versions)--I uploaded the whole mess (I believe the .AR file came to 130+K!) to CIS, and I wouldn't mind sending a floppy to someone working on a port to OS-9. (Maybe I should wait on that offer until the logistics are settled.) I have various freely-copyable things that are sitting around that I don't have time to port and probably won't (sigh)--UUPC is one, Phil Karn's TCP/IP is another. I may just drag them all on floppy to RAINBOWFest Chicago. [This posting is treated with lemon-freshened DISCLAIMO! It reflects no opinions of anyone or any organization save a certain obscure collection of cells, which goes by the name of "James Jones."]
pete@wlbr.EATON.COM (Pete Lyall) (04/22/88)
In article <693@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes: >Perhaps the first thing to figure out is--which version of UUPC should one >start from? I'm not sure which version of UUPC Steve Sampson posted/uploaded >(save, of course, that it's for UniFLEX). JJ (and others) The code we started with was Sampson's UNIFlex version of DCP. Bob Santy has it compiling under os9/Lii now, and we just discussed a workaround for the 'alarm()' problem a few hours ago on the phone. Also, we believe we have a nice method of keeping the various directories to be used in a reconfigurable fashion (merged data module, with extra space left in for modification purposes). I'd expect to see a beta version within the next two weeks. -- Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693 Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Internet: pete@wlbr.eaton.com UUCP: {ihnp4,scgvax,jplgodo,voder}!wlbr!pete
donp@bucket.UUCP (Don Park) (04/22/88)
In article <49400002@uxe.cso.uiuc.edu> ssmith@uxe.cso.uiuc.edu writes: >>I love it!! I am very interested in such a port myself. I cant say >>that I have the time to do it, but I would be more than happy to make >>one of our machines a UUCP 'host' if needed. Please mail the source >>(at your convenience) to my address, and I will take a look at setting >>it up here. Amazing little machines arent't they? I would like to look at the source as well!! My Address is ....!tektronix!teksce!bucket!donp Thanks All. Don Park -- /.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.\ | Don Park - Bark Technologies - Bryan Bybee : 246-0025 (voice) 256-2154 (bbs)| | 512K Color Computer III - RGB - Os-9 Lvl. II - DTerm vr 3.2 - Hardware | \.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-./
peter@sugar.UUCP (Peter da Silva) (04/30/88)
I would recommend NOT starting with a UUPC version. UUPC is a mite kludgy. The UniFLEX version seemed a bit better deigned from a brief perusal. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.