V10/doc/uucp.a
!<arch>
fig3 328475341 26 1 100664 1223 `
.LP
.ds LA \v'-.1n'<\v'.1n'\h'-2.20n'\f2\\l'.52i\-'\f1
.ds RA \f2\\l'|2.75i\-'\f1\h'-1.25n'\v'-.1n'>\v'.1n'
.ds RD \f2\\l'|2.75i\&='\h'-1.15n'\f1\v'-.1n'>\v'.1n'
.ds LD \v'-0n'<\v'0n'\h'-1.00n'\f2\l'.55i\&='\f1
.ds SD \f2\l'.42i\&='\f1
.nf
.mk
.B1
CALLING
SYSTEM
.B2
.nf
.rt
.ta 1.75iC
MESSAGES
& DATA
.rt
.ta .5i 1.25i 2.0i 3.0i 2.75i
.po +2.5i
.B1
CALLED
SYSTEM
.B2
.po
.nf
.vs 20p
.ps 12
.cs I 25
555-6789 \*(RA [ Dialup ]
\*(LA \f3login:\f1
userid, password \*(RA [ Identification ]
\*(LA \f3S\f1 [ Handshake and
\f3S\f1 36 myname \*(RA sequence check ]
\*(LA \f3P\f1 a, b, c [ Offer protocols ]
\f3U\f1 b \*(RA [ Choose protocol ]
\f3S\f1 /abc/def/ghi \*(RA [ Send file ]
\*(LA \f3SY\f1 [OK to send]
\h'.10i'\*(SD D\s-2ATA\s0 \*(RD
\f3R\f1 /abc/def/jkl [ Get file ]
\*(LA \f3RY\f1 [OK to receive]
\*(LD D\s-2ATA\s0 \*(SD
\f3H\f1 \*(RA [ Offer to stop ]
\*(LA \f3HN\f1 [ Refused ]
\*(LA \f3S\f1 /abc/mno/prs [ Called system sends ]
\f3SY\f1 \*(RA [OK to send]
\*(LD D\s-2ATA\s0 \*(SD
\*(LA \f3H\f1 [ Offer to stop ]
\f3HY\f1 \*(RA [ Accepted ]
\*(LA \f3(OO)\f1 [Close]
\f3(OO)\f1 \*(RA
Hangup
.sp .5
.ll 4.5i
.lt 4.5i
.ce
FIGURE 3
.ce
SAMPLE CONVERSATION
fig3a 297021364 26 1 100664 981 `
.bp
.LP
.ds LA \(<-\h'-.4n'\f2\\l'.5i\-'\f1
.ds RA \f2\\l'|3.00i\-'\f1\h'-.2n'\(->
.ds RD \f2\\l'|3.00i\&='\h'-1.00n'\f1>
.ds LD <\h'-1.75n'\f2\\l'.55i\&='\f1
.ds SD \f2\l'.3i\&='\f1
.nf
.ta 1i 1.75i 2.5i 3.25i 4.25i
.mk
.B1
CALLING
SYSTEM
.B2
.nf
.rt
.po +3.25i
.B1
CALLED
SYSTEM
.B2
.po
.nf
.vs 20p
.ps 12
.cs I 25
555-6789 \*(RA [ Dialup ]
\*(LA \f3login:\f1
userid, password \*(RA [ Identification ]
\*(LA \f3S\f1 36 [ Handshake and
\f3S\f1 36 myname \*(RA sequence check ]
\*(LA \f3P\f1 abc [ Offer protocol ]
\f3U\f1 b \*(RA [ Choose protocol ]
\f3S\f1 /abc/def/ghi \*(RA [ Send file ]
\h'.25i'\*(SD Data \*(RD
\f3R\f1 /abc/def/jkl [ Get file ]
\*(LD Data \*(SD
\f3H\f1 \*(RA [ Offer to stop ]
\*(LA \f3HN\f1 [ Refused ]
\*(LA \f3S\f1 /abc/def/mno [ Called system sends file ]
\*(LD Data \*(SD
\*(LA \f3H\f1 [ Offer to stop ]
\f3HY\f1 \*(RA [ Accepted ]
\*(LA \f3(OO)\f1 \*(RA
Hangup
.sp 2
.ce
Figure 3
.ce
Sample conversation
fig3b 297021378 26 1 100664 969 `
.bp
.LP
.ds LA <\h'-1.75n'\f2\\l'.5i\-'\f1
.ds RA \f2\\l'|3.00i\-'\f1\h'-1n'>
.ds RD \f2\\l'|3.00i\&='\h'-1.00n'\f1>
.ds LD <\h'-1.75n'\f2\\l'.55i\&='\f1
.ds SD \f2\l'.3i\&='\f1
.nf
.ta 1i 1.75i 2.5i 3.25i 4.25i
.mk
.B1
CALLING
SYSTEM
.B2
.nf
.rt
.po +3.25i
.B1
CALLED
SYSTEM
.B2
.po
.nf
.vs 20p
.cs I 25
555-6789 \*(RA [ Dialup ]
\*(LA \f3login:\f1
userid, password \*(RA [ Identification ]
\*(LA \f3S\f1 36 [ Handshake and
\f3S\f1 36 myname \*(RA sequence check ]
\*(LA \f3P\f1 abc [ Offer protocol ]
\f3U\f1 b \*(RA [ Choose protocol ]
\f3S\f1 /abc/def/ghi \*(RA [ Send file ]
\h'.25i'\*(SD Data \*(RD
\f3R\f1 /abc/def/jkl [ Get file ]
\*(LD Data \*(SD
\f3H\f1 \*(RA [ Offer to stop ]
\*(LA \f3HN\f1 [ Refused ]
\*(LA \f3S\f1 /abc/def/mno [ Called system sends file ]
\*(LD Data \*(SD
\*(LA \f3H\f1 [ Offer to stop ]
\f3HY\f1 \*(RA [ Accepted ]
\*(LA \f3(OO)\f1 \*(RA
Hangup
.sp 2
.ce
Figure 3
.ce
Sample conversation
greg.pk 278184815 26 1 100664 9518 `
.if \n(nl>0 .bp
.if n .ls 2
.vs 20p
.nr VS 20
.ds RH Nowitz
.SH
.ce 2
Appendix 1 - Pk Protocol
.ft I
G. L. Chesson
.SH
General
.PP
Information flow between a pair of machines
may be regulated by
first
discretizing the data streams
into 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
in the current version of the PK
protocol.
.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.
.nf
.sp
.in 1i
.vs 12p
bit 7 6 5 4 3 2 1 0
t t x x x y y y
.vs 20p
.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
.vs 12p
.I
tt interpretation
.sp
.R
00 control packet
10 data packet
11 `short' data packet
01 alternate channel
.vs 20p
.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 one 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 experimental in nature
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
.vs 12p
.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 -1i
.vs 20p
.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.
.SH
Message Exchanges
.SH
Initialization
.PP
Messages are exchanged between four cooperating
entities: two senders and two receivers.
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.
.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 are not required to arrive in order;
however, 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 or SRJ
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.
.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.
One technique will be outlined.
.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
<SYN><k><c0><c1><C><x>
.in -1i
The <SYN> symbol denotes the ASCII sync 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 efficiently because of the
constant-sized framing envelopes and data segments.
implement 315889111 221 1 100666 41058 `
.ds :? UUCP Implementation
.hy 14
.de PT
.lt \\n(LLu
.pc %
.nr PN \\n%
.if \\n%-1 .if o .tl '\s9\f2\*(:?\fP''\\n(PN\s0'
.if \\n%-1 .if e .tl '\s9\\n(PN''\f2\*(:?\^\fP\s0'
.lt \\n(.lu
..
.TL
Uucp Implementation Description
.AU
D. A. Nowitz
.AI
.MH
.AB
.PP
Uucp is a series of programs designed to permit communication
between
.UX
systems using either dial-up or hardwired communication
lines.
This document gives a detailed implementation
description of the current
implementation of uucp.
Is is designed
for use by an administrator/installer of the system.
It is not meant as a user's guide.
.AE
.CS 12 5 15
.SH
Introduction
.LP
Uucp is a series of programs designed to permit communication between
.UX
systems using either dial-up or
hardwired communication lines.
It can be used for file transfers and remote command execution.
The first version of the system was designed and implemented
by M. E. Lesk.\s-2\u1\d\s+2\
.FS
1. M. E. Lesk and A. S. Cohen,
.UX
.I "Software Distribution by Communication Link,"
.ie \n(TN>0 TM-77-1274-3, TM-77-8234-5.
.el private communication.
.FE
This paper describes the current (second) implementation
of the system.
.LP
Uucp is a batch operation.
Files are created in a spool directory for processing
by the uucp demons.
There are three types of files used for the execution
of work.
.I Data\ files
contain data for transfer to remote systems.
.I Work\ files
contain directions for file transfers between systems.
.I Execute\ files
are scripts for
.UX
commands that
involve the resources of one or more systems.
.LP
There are four primary programs:
.RS
.IP uucp 10
builds
.I "work files"
and gathers
.I "data files"
in the spool directory
for data transmission.
.IP uux
creates
.I "work files" ,
.I "execute files" ,
and gathers
.I "data files"
for the remote execution of
.UX
commands.
.IP uucico
executes the work files for data transmission.
.IP uuxqt
executes the scripts for
.UX
command execution.
.RE
.LP
There are a couple of administrative programs:
.RS
.IP uulog 10
gathers temporary log files that may occur due to lockout of
the uucp log file
and reports some information such as copy requests and completion status.
.IP uuclean
removes old files from the spool directory.
.LP
.RE
The remainder of this paper will describe the operation
of each program, the installation of the system,
the security aspects of the system,
the files required for execution,
and the administration of the system.
.NH
Uucp\-UNIX to UNIX File Copy
.LP
The
.I uucp
command is the user's primary interface with the system.
The command is designed to look like
.I cp
to the user.
The syntax is
.IP
.I uucp\ \
.B [
option
.B ]
\ .\|.\|.\ \ \ source\ .\|.\|.\ \ \ destination
.LP
where the source and destination
may contain the prefix
.I system-name\^!\| ,
which indicates the system where the file
or files reside
or where they will be copied.
.LP
.I Uucp
has several options:
.RS
.IP \-d 10
Make directories when necessary for copying the file.
.IP \-c
Don't copy source files to the spool directory,
but use the specified source when the actual
transfer takes place.
.IP \-e\fIsys\fR
Send this job to system
.I sys
to execute.
(Note that this will only work when the system
.I sys
allows
.I uuxqt
to execute a
.I uucp
command.
See the ``Uuxqt'' and ``Security'' sections.)
.IP \-g\fIletter\fR
Put
.I letter
in as the grade in the name of the work file.
(This can be used to change the order of work for a particular
machine.)
.IP \-m
Send mail to the requester on completion of the work.
.IP \-n\fIuser\fR
Notify
.I user
on the remote machine that a file has been sent.
.LP
There are several options available for debugging:
.IP \-r 10
Queue the job but do not start
.I uucico
program.
.IP \-x\fInum\fR
.I Num
is a level number between 1 and 9;
higher numbers give more debugging output.
.RE
.LP
The destination may be a directory name,
in which case the file name is taken from the last part of the
source's name.
If the directory exists, it must be writable by everybody.
(Note that if the destination is a directory name and the ``\-d'' option
is specified to create the directory, the directory name must be followed
by ``/''.)
The source
name may contain special shell characters
such as ``?*[]''.
These will be expanded on the appropriate system.
.LP
The command
.IP "" 12
uucp\ \ \ *\s+4.\s-4c\ \ \ usg\^!\^/usr/dan
.LP
will set up the transfer of all files whose names end with ``\s+4.\s-4c''
to the ``/usr/dan'' directory on the``usg'' machine.
.LP
The source and/or destination names may also contain a
.I ~user
prefix.
This translates to the login directory of
.I user
on the specified system.
File names beginning with ``~/'' translate into the public directory
(usually /usr/spool/uucppublic)
on the remote system.
For names with partial path-names,
the current directory is prepended to the file name.
File names with
\&\s+4..\s-4/
are not permitted
for security reasons.
.LP
The command
.IP "" 12
uucp\ \ \ usg\^!\^~dan/*\s+4.\s-4h\ \ \ ~dan
.LP
will set up the transfer of files whose names end with ``\s+4.\s-4h''
in dan's login
directory on system ``usg'' to dan's local
login directory.
.LP
For each source file,
the program will check the source and destination
file-names,
the system-part of each argument,
and the options
to classify the work into several types:
.RS
.IP [1]
Copy source to destination on local system.
.IP [2]
Receive files from other systems.
.IP [3]
Send files to a remote system.
.IP [4]
Send files from remote systems
to another remote system.
.IP [5]
Receive files from remote systems when the source
contains special shell characters as
mentioned above.
.IP [6]
Request that the
.I uucp
command be executed by a remote system.
.RE
.LP
After the work has been set up in the spool directory,
the
.I uucico
program is started to try to contact the other
machine and execute the work (unless the \-r option
was specified).
.SH
Type 1 - local copy
.LP
The copy is done locally.
The
.I \-m
and
.I \-n
options are not honored in this case.
.SH
Type 2 - receive files
.LP
A
.I "work file"
is created or appended with a one line entry for each request.
The upper limit to the number of files per
.I "work file"
is set in
.I uucp.h.
(The default setting is 20.)
After the limit has been reached, a new
.I "work file"
is created.
(All
.I "work files"
and
.I "execute files"
use a blank as the field separator.)
The fields for these entries are given below.
.RS
.IP [1]
R
.IP [2]
The full path-name of the source or a ~something/path-name.
The
.I ~something
part will be expanded on the remote system.
.IP [3]
The full path-name of the destination file.
If the
.I ~something
notation is used, it will be immediately
expanded.
.IP [4]
The user's login name.
.IP [5]
A ``\-'' followed by an option list.
The options \-m and \-d may appear.
.RE
.KS
.SH
Type 3 - send files
.LP
Each source file
is copied into a
.I "data file"
in the spool directory.
(A ``\-c'' option on the
.I uucp
command will prevent the
.I "data file"
from being made.
In this case, the file will be transmitted from
the indicated source.)
The fields for these entries are given below.
.RS
.IP [1]
S
.IP [2]
The full-path name of the source file.
.IP [3]
The full-path name of the destination or
~something/file-name.
.IP [4]
The user's login name.
.IP [5]
A ``\-'' followed by an option list.
The options \-d, \-m, and \-n may appear.
.IP [6]
The name of the
.I "data file"
in the spool directory.
A dummy name, ``D.0'' is used when the \-c option is specified.
.IP [7]
The file mode bits of the source file
in octal print format
(e.g., 0666).
.IP [8]
The user on the remote system to be notified upon completion of the
file copy when the ``\-n'' option is specified.
.RE
.KE
.SH
Type 4 and Type 5 - remote uucp required
.LP
.I Uucp
generates a
.I uucp
command and sends it to the remote machine;
the remote
.I uucico
executes the
.I uucp
command.
.SH
Type 6 - remote execution
.LP
This occurs when the ``\-e'' option is used.
In this case, the
.I uux
facility is used to create and send the request.
This requires that the remote
.I uuxqt
program allows the
.I uucp
command.
.NH
Uux\-UNIX To UNIX Execution
.LP
The
.I uux
command is used to set up the execution of a
.UX
command
where the execution machine and/or some of the
files are remote.
The syntax of the uux command is
.IP
.I uux\ \
.B [
\-
.B "] ["
option
.B ]
\ .\|.\|.\ \ command-string
.LP
where the command-string is made up of one or more arguments.
All special shell characters such as ``<>\(bv^'' must be quoted
either by quoting the entire command-string
or quoting the character as a separate argument.
Within the command-string, the command and file names may
contain a
.I system-name\^!\|
prefix.
All arguments that do not contain a ``!'' will not
be treated as files.
(They will not be copied to the execution machine.)
An argument that contains a ``!'' but is not to be treated as a file
at the present time,
can be escaped by using ``()'' around
the argument.
(Note that the ``()'' symbols must usually be escaped with a ``\\'' symbol.)
The ``\-'' is used to indicate that the standard input
for
.I command-string
should be inherited from the standard input
of the
.I uux
command.
The following options are available for debugging:
.RS
.IP \-r 10
Don't start
.I uucico
or
.I uuxqt
after queuing the job.
.IP \-x\fInum\fR
.I Num
is a level number between 1 and 9;
higher numbers give more debugging output.
.RE
.LP
The command
.IP "" 12
pr\ \ abc\ \ \(bv\ \ uux\ \ \-\ \ usg\^!\^lpr
.LP
will set up the output of ``pr abc''
as standard input to an lpr command
to be executed on system ``usg''.
.LP
.I Uux
generates an
.I "execute file"
that contains the
names of the files required
for execution (including standard input),
the user's login name, the destination
of the standard output, and the command to be executed.
This file is either put in the spool directory
for local execution or sent to the remote system using
a send command (type 3 above).
.LP
For required files that are not on the execution machine,
.I uux
will generate receive command files (type 2 above).
These command-files will be put on the execution machine
for execution by the
.I uucico
program.
.LP
The
.I "execute file"
contains a script that
will be processed
by the
.I uuxqt
program.
It is made up of several lines,
each of which contains an identification character
and one or more arguments.
The lines are described below.
.RS
.SH
User Line
.IP
U\ \ user\ \ system
.LP
where the
.I user
and
.I system
are the requester's login name and system.
.SH
Required File Line
.IP
F\ \ file-name\ \ real-name
.LP
where the
.I file-name
is a unique name used for file transmission
and
.I real-name
is the last part of the actual file name (contains no
path information).
Zero or more of these lines may be present.
The
.I uuxqt
program will check for the existence of all these
files before the command is executed.
.SH
Standard Input Line
.IP
I\ \ file-name
.LP
The standard input is either specified by a ``<'' in the
command-string or inherited from the standard input of the
.I uux
command if the ``\-'' option is used.
If a standard input is not specified,
``/dev/null'' is used.
(Note that if there is a standard input specified, it will also
appear in an ``F'' line.)
.SH
Standard Output Line
.IP
O\ \ file-name\ \ system-name
.LP
The standard output is specified by a ``>'' within the
command-string.
If a standard output is not specified,
``/dev/null'' is used.
(Note that the use of ``>>'' is not implemented.)
.SH
Command Line
.IP
C\ \ command\ \
.B [
arguments
.B ]
\ .\|.\|.
.LP
The arguments are those specified in the command-string.
The standard input and standard output will not appear on this
line.
All
.I "required files"
will be moved to the execution directory
(usually /usr/lib/uucp/.XQTDIR)
and the
.UX
command is executed using the shell specified in the
.I uucp\s+4.\s-4h
header file.
In addition, a shell ``PATH'' statement is prepended
to the command line as specified in the
.I uuxqt
program.
(Note that a check is made to see that the command
is allowed as specified in the
.I uuxqt
program.)
After execution, the standard output is copied or sent to the proper place.
.RE
.NH
Uucico\-Copy In, Copy Out
.LP
The
.I uucico
program will perform several major functions:
.RS
.IP \- 3
Scan the spool directory for work.
.IP \-
Place a call to a remote system.
.IP \-
Negotiate a line protocol to be used.
.IP \-
Execute all requests from both systems.
.IP \-
Log work requests and work completions.
.RE
.LP
.I Uucico
may be started in several ways:
.RS
.IP a) 5
by a system demon specified in a crontab entry,
.IP b)
by one of the
.I
uucp, uux, uuxqt
.R
or
.I uucico
programs,
.IP c)
directly by the user (this is usually for testing),
.IP d)
by a remote system.
(The uucico program should be specified as the ``shell''
field in the ``/etc/passwd'' file for the
logins used by remote systems to access uucp.)
.RE
.LP
When started by method a, b or c, the program is considered to
be in
.I MASTER
mode.
In this mode, a connection will be made to a remote system.
If started by a remote system (method d),
the program is considered to be in
.I SLAVE
mode.
.LP
The
.I MASTER
mode will operate in one of two ways.
If no system name is specified
(\-s option not specified)
the program will scan the spool directory for
systems to call.
If a system name is specified, that system will be called,
and work will only be done for that system.
.LP
.I Uucico
is generally started by another program.
There are several options used for execution:
.RS
.IP \-r1 10
Start the program in
.I MASTER
mode.
This is used when
.I uucico
is started by a program or ``cron'' shell.
.IP \-s\fIsys\fR
Do work only for system
.I sys.
If
.I \-s
is specified,
a call to the specified system
will be made even if there is no work for system
.I sys
in the spool directory.
This is useful for polling systems that do not have
the hardware to initiate a connection.
.LP
The following options are used primarily for debugging:
.IP \-d\fIdir\fR
Use directory
.I dir
for the spool directory.
.IP \-x\fInum\fR
.I Num
is a level number between 1 and 9;
higher numbers give more debugging output.
.RE
.LP
The next part of this section will describe the major steps within
the
.I uucico
program.
.SH
Scan For Work
.LP
The names of the work related files in the spool directory have format
.IP
type \s+4.\s-4 system-name grade number
.LP
where
.IP
.I type
is an upper case letter
(
.I C
\-\ copy command file,
.I D
\-\ data file,
.I X
\-\ execute file),
.IP
.I system-name
is the remote system,
.IP
.I grade
is a character,
.IP
.I number
is a four digit, zero padded sequence number.
.LP
The file
.IP "" 12
C\s+4.\s-4res45n0031
.LP
would be a
.I "work file"
for a file transfer between the local
machine and the ``res45'' machine.
.LP
The scan for work is done by looking through the
spool directory for
.I "work files"
(files with prefix ``C\s+4.\s-4'').
A list is made of all systems to be called.
.I Uucico
will then call each system and process all
.I "work files" .
.SH
Call Remote System
.LP
The call is made using information from several
files that reside in the uucp program directory
(usually /usr/lib/uucp).
At the start of the call process, a lock is
set to forbid multiple conversations
between the same two systems.
.LP
The
.I L\^\s+4.\s-4sys
file contains information required to make the remote connection:
.RS
.IP [1]
system name,
.IP [2]
times to call the system
(days-of-week and times-of-day)
and the minimum time delay before retry,
.IP [3]
device or device type to be used for call,
.IP [4]
line class (this is the line speed on almost all systems),
.IP [5]
phone number if field [3] is
.I ACU
or the device
if not
.I ACU ,
.IP [6]
login information (zero or more fields),
.RE
.LP
The time field is checked against the present time to see
if the call should be made.
The
.I "phone number"
may contain abbreviations (e.g., mh, py, boston) that get translated into dial
sequences using the
.I L-dialcodes
file.
.LP
The
.I L-devices
file is scanned using fields [3] and [4] from the
.I L\^\s+4.\s-4sys
file to find an available device for the call.
The program will try each devices that satisfy
[3] and [4] until a call is made, or no more
devices can be tried.
If a device is successfully opened, a lock file
is created.
If the call is completed, the
.I
login information
.R
(field [6] of
.I L\^\s+4.\s-4sys )
is used to login.
.LP
The conversation between the two
.I uucico
programs begins with a handshake started by the called,
.I SLAVE ,
system.
The
.I SLAVE
sends a message to let the
.I MASTER
know it is ready to receive the system
identification and conversation sequence number.
The response from the
.I MASTER
is
verified by the
.I SLAVE
and if acceptable, protocol selection begins.
The
.I SLAVE
can also reply with a ``call-back required''
message in which case, the current conversation
is terminated.
.SH
Line Protocol Selection
.LP
The remote system sends a message
.IP "" 12
P\fIproto-list\fR
.LP
where
.I proto-list
is a string of characters, each
representing a line protocol.
.LP
The calling program checks
.I proto-list
for a letter corresponding to an available line
protocol and returns a
.I use-protocol
message.
The
.I use-protocol
message is
.IP "" 12
U\fIcode\fR
.LP
where
.I code
is either a one character
protocol letter or
``N'',
which means there is no common protocol.
.SH
Work Processing
.LP
The
.I MASTER
program does a work search similar to the
one used in the ``Scan For Work'' section.
(The
.I MASTER
has been specified by the ``\-r1'' uucico option.)
Each message used during the
work processing is specified by the first
character of the message:
.RS
.IP S 3
send a file,
.IP R
receive a file,
.IP C
copy complete,
.IP X
execute a
.I uucp
command,
.IP H
hangup.
.RE
.LP
The
.I MASTER
will send
.I R ,
.I S
or
.I X
messages until all work for the remote system is complete,
at which point an
.I H
message will be sent.
The
.I SLAVE
will reply with
.I SY ,
.I SN ,
.I RY ,
.I RN ,
.I HY ,
.I HN ,
.I XY ,
or
.I XN ,
corresponding to
.I yes
or
.I no
for each request.
.LP
The send and receive replies are
based on permission to access the
requested file/directory using the
.I USERFILE
and read/write permissions of the file/directory.
After each file is copied into the spool directory
of the receiving system,
a copy-complete message is sent by the receiver of the file.
The message
.I CY
will be sent if the
file has successfully been moved from the
spool directory to the destination.
Otherwise, a
.I CN
message is sent.
(In this case,
the file is put in the public directory, usually /usr/spool/uucppublic,
and the requester is notified by mail.)
The requests and results are logged on both systems.
.LP
The hangup response is determined by a
work scan of the
.I SLAVE 's
spool directory.
If work for the remote system exists
an
.I HN
message is sent and the programs switch roles.
If no work exists, an
.I HY
response is sent.
.SH
Conversation Termination
.LP
When a
.I HY
message is received by the
.I MASTER
it is echoed back to the
.I SLAVE
and the protocols are turned off.
Each program sends a final ``OO'' message to the
other.
The original
.I SLAVE
program will clean up and terminate.
The
.I MASTER
will proceed to call other systems
unless a ``\-s'' option was specified.
.LP
.NH
Uuxqt\-Uucp Command Execution
.LP
The
.I uuxqt
program is used to execute
scripts
generated by
.I uux.
The
.I uuxqt
program may be started by either the
.I uucico
or
.I uux
programs or a demon specified by a
.I crontab
entry.
The program scans the spool directory for
.I
execute files
.R
(prefix ``X\s+4.\s-4'').
Each one is checked to see if all the required files are available and
if so, the command line is verified and executed.
.LP
The
.I
execute file
.R
is described in the ``Uux''
section above.
.LP
The execution is accomplished by executing a
``sh \-c''
of the command line after appropriate
standard input and standard output have been opened.
If a standard output is specified, the program
will create a send command or copy the output
file as appropriate.
.NH
Uulog\-Uucp Log Inquiry
.LP
When a
.I uucp
program can not make a log entry directly into the
.I LOGFILE
an individual log file is created:
a file with prefix
.I LOG .
This will sometimes occur when more than one uucp process is running.
Periodically,
.I uulog
may be executed to append these files to the
.I LOGFILE .
.LP
The
.I uulog
program may also be used to request the output of
.I LOGFILE
entries.
The request is specified by the use of the
options:
.RS
.IP \-s\fIsys\fR 9
Print entries where
.I sys
is the remote system name,
.IP \-u\fIuser\fR
Print entries for user
.I user.
.RE
.LP
The intersection of lines satisfying the two options is output.
A null
.I sys
or
.I user
means all system names or users respectively.
.NH
Uuclean\-Uucp Spool Directory Cleanup
.LP
This program is typically started by the uucp daily demon.
Its function is to remove files from the spool directory that
are more than 3 days old.
These are usually files for work that can not be completed.
The requester of this work is notified that the files have been deleted.
.LP
There are several options:
.RS
.IP \-d\fIdir\fR 10
The directory to be scanned is
.I dir .
.IP \-m
Send mail to the owner of each file being removed.
(Note that most files put into the spool directory
will be owned by the owner of the
uucp programs since the setuid bit will be set on these
programs.
This mail is sometimes useful for administration.)
.IP \-n\fIhours\fR
Change the aging time from 72 hours to
.I hours
hours.
.IP \-p\fIpre\fR
Examine files with prefix
.I pre
for deletion.
(Up to 10 of these options may be specified.)
.IP \-x\fInum\fR
This is the level of debugging output desired.
.RE
.NH
Security
.LP
.in +\w'\ \(rh\ \ 'u
.ti -\w'\ \(rh\ \ 'u
.I
\ \(rh\ \ The uucp system, left unrestricted,
will let any outside user execute any commands
and copy out/in any file that is readable/writable
by a uucp login user.
It is up to the individual sites to be aware of this and
apply the protections that they feel are necessary.
.R
.in -\w'\ \(rh\ \ 'u
.LP
There are several security features available aside from the
normal file mode protections.
These must be set up by the administrator of the
.I uucp
system.
.IP \- 3
The login for uucp does not get a standard shell.
Instead, the
.I uucico
program is started
so that all work is done through
.I uucico .
.IP \-
The owner of the uucp programs should be an administrative login.
It should not be one of the logins used for remote system access to
uucp.
.IP \-
A path check is done on file names that are to be sent
or received.
The
.I USERFILE
supplies the information for these checks.
The
.I USERFILE
can also be set up to require call-back
for certain login-ids.
(See the ``Files Required For Execution'' section
for the file description.)
.IP \-
A conversation sequence count can be set up so
that the called system
can be more confident of the caller's identity.
.IP \-
The
.I uuxqt
program comes with a list of commands that it
will execute.
A ``PATH'' shell statement is prepended to the command
line as specified in the
.I uuxqt
program.
The installer may modify the list or remove the
restrictions as desired.
.IP \-
The
.I L\^\s+4.\s-4sys
file should be owned by the uucp administrative login and have mode 0400
to protect the phone numbers and login information
for remote sites.
.IP \-
The programs
.I uucp ,
.I uucico ,
.I uux ,
.I uuxqt ,
.I uulog ,
and
.I uuclean
should be
owned by the uucp administrative login, have the setuid bit set,
and have only execute permissions.
.NH
Uucp Installation
.LP
It is assumed that the
.I "login name"
used by a remote computer to call into a local computer
is not the same as the login name of a normal user
or the uucp administrative login.
However, several remote computers may use the same
login name.
.LP
Each computer should be given a unique
.I "system name"
that is transmitted at the start of each call.
This name identifies the calling machine to the called machine.
The
.I login/system
names are used for security as described later in the
.I USERFILE
section.
.LP
There are several source modifications that may be required
before the system programs are compiled.
These relate to the directories, local system name,
and attributes of the local environment.
.LP
There are several directories used by the uucp system:
.RS
.IP lib 12
(/usr/src/cmd/uucp) \-
This directory contains the uucp system source files.
.IP program
(/usr/lib/uucp) \-
This is the directory used for some of the executable system programs and
the system files.
Some of the programs reside in ``/usr/bin''.
.IP spool
(/usr/spool/uucp) \-
This is the uucp system spool directory.
.IP xqtdir
(/usr/lib/uucp/.XQTDIR) \-
This directory is used during execution of
the
.I uux
scripts.
.RE
.LP
The names in parentheses above are the default values
for the directories.
The italicized names
.I
lib, program, xqtdir,
.R
and
.I spool
will be used in the following text to represent the
appropriate directory names.
.LP
There are two files that may require modification,
the
.I makefile
file and the
.I uucp\s+4.\s-4h
file.
(On some systems, the makefile is named
.I uucp.mk .)
In addition, the ``uuxqt.c'' program may be modified as indicated in
the ``Security'' section above.
The following paragraphs describe the modifications.
.SH
uucp\s+4.\s-4h modification
.LP
Several manifests in ``uucp.h'' may need modification for the local
system environment:
.RS
.IP UNAME 12
should be defined if the ``uname'' function is available.
.IP MYNAME
should be modified to the name of the local system if
UNAME is
.I not defined.
.IP ACULAST
is the character required by the ACU as the last character.
For most systems, it is a ``\-''.
.IP DATAKIT
should be defined if the system is on a datakit network.
.IP DIALOUT
should be defined if the ``C'' library routine ``dialout''
is available.
.RE
.SH
makefile modification
.LP
There are several
.I make
variable definitions that may need modification:
.RS
.IP INSDIR 10
is the
.I program
directory
(e.g., INSDIR=/usr/lib/uucp).
This parameter is used if ``make cp'' or
``make install'' is used.
.IP IOCTL
is required to be set if the ``ioctl'' routine is
.I not
available in the standard
``C'' library;
the statement
``IOCTL=ioctl\s+4.\s-4o'' is required in this case.
.IP PUBDIR
is a public directory for remote access.
This is also the login directory for remote uucp users.
It should be the same as that defined in ``uucp.h''.
.IP SPOOL
is the uucp spool directory.
This should be the same as that defined in ``uucp.h''.
.IP XQTDIR
is the directory for uuxqt to use for command execution.
It is also defined in ``uucp.h''.
.IP OWNER
is the administrative login for uucp.
.RE
.SH
Compile the system
.LP
The command
.IP "" 12
make install
.LP
will make the required directories,
compile all programs,
set the proper file modes,
and copy the programs to the proper directories.
This command should be run as
.I root .
The command
.IP "" 12
make
.LP
will compile the entire system.
.LP
The programs
.I uucp ,
.I uux ,
and
.I uulog
should be put in ``/usr/bin''.
The programs
.I uuxqt ,
.I uucico ,
and
.I uuclean
should be put in the
.I program
directory.
.SH
Files Required For Execution
.LP
There are four files that are required for execution.
They should reside in the
.I program
directory.
The field separator for all files is a space.
.SH
L-devices
.LP
This file contains call-unit device and hardwired connection information.
The special device files are assumed to be in the
.I /dev
directory.
The format for each entry is
.IP "" 12
type\ \ line\ \ call-unit\ \ speed
.LP
where
.RS
.IP type 12
is a device type such as ACU or DIR.
The field can also be used to specify particular ACUs for some
calls by using a suffix on the ACU field, e.g., ACU3.
This names should be used in
.I L\^\s+4.\s-4sys .
.IP line
is the device for the line (e.g., cul0).
.IP call-unit
is the automatic call unit associated with
.I line
(e.g., cua0).
Hardwired lines have a number ``0'' in this field.
.IP speed
is the line speed.
.RE
.LP
The line
.IP "" 12
ACU\ \ cul0\ \ cua0\ \ 300
.LP
would be set up for a system that
has device ``/dev/cul0'' wired to a call-unit ``/dev/cua0''
for use at 300 baud.
.SH
L-dialcodes
.LP
This file contains the dialcode abbreviations used
in the
.I L\^\s+4.\s-4sys
file (e.g., py, mh, boston).
The entry format is
.IP "" 12
abb\ \ dial-seq
.LP
where
.RS
.IP abb 12
is the abbreviation,
.IP dial-seq
is the dial sequence to call that location.
.RE
.LP
The line
.IP "" 12
py\ \ 165\-
.LP
would be set up so that entry py7777 would
send 165\-7777 to the dial-unit.
.SH
USERFILE
.LP
This file contains user accessibility information.
It specifies four types of constraint:
.RS
.IP [1]
which files can be accessed by a normal user of the local machine,
.IP [2]
which files can be accessed from a remote computer,
.IP [3]
which login name is used by a particular remote computer,
.IP [4]
whether a remote computer should be called back in order to confirm
its identity.
.RE
.LP
Each line in the file has the format
.IP "" 6
login,sys\ \
.B [
c
.B ]
\ \ path-name\ \
.B [
path-name
.B ]
\ .\|.\|.
.LP
where
.RS
.IP login 12
is the login name for a user or the remote computer,
.IP sys
is the system name for a remote computer,
.IP c
is the optional
.I
call-back required
.R
flag,
.IP path-name
is a path-name prefix that is acceptable for
.I sys .
.LP
.RE
.LP
The constraints are implemented as follows.
.RS
.IP [1]
When the program is obeying a command stored on the local machine,
.I MASTER
mode,
the path-names allowed are those given on the first line in the
.I USERFILE
that has the login name of the user
who entered the command.
If no such line is found, the first line with a
.I null
login name is used.
.IP [2]
When the program is responding to a command from a remote machine,
.I SLAVE
mode, the path-names allowed are those given on the first line
in the file that has the system name that matches
the remote machine.
If no such line is found, the first one with a
.I null
system name is used.
.IP [3]
When a remote computer logs in, the login name that
it uses
.I must
appear in the
.I USERFILE .
There may be several lines with the same login name but one of them must
either have the name of the remote system or must contain a
.I null
system name.
.IP [4]
If the line matched in ([3]) contains a ``c'',
the remote machine is called back before any transactions take place.
.RE
.LP
The line
.IP "" 12
u,m /usr/xyz
.LP
allows machine
.I m
to login with name
.I u
and request the transfer of files whose names start with
``/usr/xyz''.
.LP
The line
.IP "" 12
dan, /usr/dan
.LP
allows the ordinary user
.I dan
to issue commands for files whose name starts with
``/usr/dan''.
(Note that this type restriction is seldom used.)
.LP
The lines
.IP "" 12
u,m /usr/xyz /usr/spool
.br
u, /usr/spool
.LP
allows any remote machine to login with name
.I u .
If its system name is not
.I m ,
it can only ask to transfer files whose names start with
``/usr/spool''.
If it is system
.I m ,
it can send files from paths ``/usr/xyz'' as well as ``/usr/spool''.
.LP
The lines
.IP "" 12
root, /
.br
, /usr
.LP
allow any user to transfer files beginning with ``/usr''
but the user with login
.I root
can transfer any file.
(Note that any file that is to be transferred must be readable by anybody.)
.SH
L\s+4.\s-4sys
.LP
Each entry in this file represents one system
that can be called by the local uucp programs.
More than one line may be present for a particular system.
In this case, the additional lines represent alternative
communication paths that will be tried in sequential order.
The fields are described below.
.RS
.SH
system name
.LP
The name of the remote system.
.SH
time
.LP
This is a string that indicates the days-of-week
and times-of-day when the system should
be called
(e.g., MoTuTh0800\-1730).
.LP
The day portion may be a list containing
some of
.IP
.I
Su Mo Tu We Th Fr Sa
.R
.LP
or it may be
.I Wk
for any week-day or
.I Any
for any day.
.LP
The time should be a range of times (e.g., 0800\-1230).
If no time portion is specified, any time
of day is assumed to be okay for the call.
Note that a time range that spans 0000 is permitted, for example,
0800-0600 means all times are ok other than times between 6 and 8 am.
.LP
An optional subfield is available to indicate the minimum time (minutes)
before a retry following a failed attempt.
The subfield separator is a ``,''.
(e.g., Any,9 means call any time but wait at least 9 minutes after a failure
has occurred.)
.SH
device
.LP
This is either
.I ACU
or the hardwired device to be used for the call.
For the hardwired case, the last part of the
special file name is used (e.g., tty0).
.SH
class
.LP
This is usually the line speed for the call (e.g., 300).
The exception is when the ``C'' library routine ``dialout'' is
available in which case this is the dialout class.
.SH
phone
.LP
The phone number is made up of an optional
alphabetic abbreviation and a numeric part.
The abbreviation should be one that appears in the
.I L-dialcodes
file (e.g., mh5900, boston995\-9980).
For the hardwired devices, this field contains
the same string as used for the
.I device
field.
.SH
login
.LP
The login information is given as a series of
fields and subfields in the format
.IP
.B [
expect\ \ send
.B ]
\ .\|.\|.
.LP
where
.I expect
is the string expected to be read and
.I send
is the string to be sent when the
.I expect
string is received.
.LP
The expect field may be made up of subfields
of the form
.IP
expect\fB[\fR\-send\-expect\fB]\fR .\|.\|.
.LP
where the
.I send
is sent if the prior
.I expect
is
.I not
successfully read
and the
.I expect
following the
.I send
is the next expected string.
(e.g., login--login will expect
.I login ;
if it gets it, the program will go on to the next field;
if it does not get
.I login ,
it will send
.I null
followed by a new line,
then expect
.I login
again.)
.LP
There are two special names available to be sent
during the login sequence.
The string
.I EOT
will send an EOT character and the string
.I BREAK
will try to send a BREAK character.
(The
.I BREAK
character is simulated using line speed changes
and null characters and may not work on all
devices and/or systems.)
A number from 1 to 9 may follow the
.I BREAK
for example,
.I BREAK1
will send 1 null character instead of the default of
3.
Note that
.I BREAK1
usually works best for 300/1200 baud lines.
.RE
.LP
A typical entry in the L\s+4.\s-4sys file would be
.IP "" 6
sys\ \ Any\ \ ACU\ \ 300\ \ mh7654\ \ login\ \ uucp\ \ ssword:\ \ word
.LP
The expect algorithm match all or part of the input
string as illustrated in the password field above.
.RE
.NH
Administration
.LP
This section indicates some events and files that must be
administered for the
uucp system.
Some administration can be accomplished by
.I "shell files"
initiated by
.I crontab
entries.
Others will require manual intervention.
Some sample
.I "shell files"
are given toward the end of this section.
.SH
SQFILE \- sequence check file
.LP
This file is set up in the
.I program
directory and contains an entry for each remote
system with which you agree to perform conversation
sequence checks.
The initial entry is just the system name of
the remote system.
The first conversation will add
the conversation count and the date/time of the most
resent conversation.
These items will be updated with each conversation.
If a sequence check fails, the entry will have to
be adjusted manually.
.SH
TM \- temporary data files
.LP
These files are created in the
.I spool
directory while a file is being copied
from a remote machine.
Their names have the form
.IP "" 12
\fBTM.\^\fRpid\s+4.\s-4ddd
.LP
where
.I pid
is a process-id and
.I ddd
is a sequential three digit number starting at zero.
After the entire file is received, the
.I TM
file is moved/copied to the requested destination.
If processing is abnormally terminated
the file will remain in the
spool directory.
The leftover files should be periodically removed;
the
.I uuclean
program is useful in this regard.
The command
.IP "" 12
.I program /uuclean\ \ \-pTM
.LP
will remove all
.I TM
files older than three days.
.SH
LOG \- log entry files
.LP
During execution, log information is appended to the
.I LOGFILE .
If this file is locked by another process, the log
information is placed in individual log files which will have prefix
.I LOG .
These files should be combined into the
.I LOGFILE
by using the
.I uulog
program.
This program will append the
.I LOGFILE
with the individual log files.
The command
.IP "" 12
uulog
.LP
will accomplish the merge.
Options are available to print some or all the
log entries after the files are merged.
The
.I LOGFILE
should be removed periodically.
.LP
The
.I LOG .
files are created initially with mode 0222.
If the program that creates the file terminates normally,
it changes the
mode to 0666.
Aborted runs may leave the files with mode
0222 and the
.I uulog
program will not read or remove them.
To remove them, either use
.I rm ,
.I uuclean ,
or change the mode to 0666 and let
.I uulog
merge them into the
.I LOGFILE .
.SH
STST \- system status files
.LP
These files are created in the spool directory by the
.I uucico
program.
They contain information such as login, dialup or
sequence check failures or will contain a
.I TALKING
status when two machines are conversing.
The form of the file name is
.IP
\fBSTST.\^\fRsys
.LP
where
.I sys
is the remote system name.
.LP
For ordinary failures, such as dialup or login, the file will
prevent repeated tries for about 55 minutes.
This is the default time;
it can be changed on an individual system basis by a subfield of the time
field in the
.I L\^\s+4.\s-4sys
file.
For sequence check failures, the file must be removed before
any future attempts to converse with that remote system.
.SH
LCK \- lock files
.LP
Lock files are created for each device in use (e.g., automatic calling
unit) and each system conversing.
This prevents duplicate conversations and multiple attempts to use the
same device.
The form of the lock file name is
.IP "" 12
\fBLCK..\^\fRstr
.LP
where
.I str
is either a device or system name.
The files may be left in the spool directory if runs abort
(usually only on system crashes).
They will be ignored (reused) after 1.5 hours.
When runs abort and calls are desired before the time limit,
the lock files should be removed.
.SH
Shell Files
.LP
The
.I uucp
program will spool work and attempt to start the
.I uucico
program, but
.I uucico
will not always be able to execute the request immediately.
Therefore, the
.I uucico
program should be periodically started.
The command to start
.I uucico
can be put in a ``shell'' file with a command to merge
.I LOG .
files and started by a crontab entry on an hourly basis.
The file could contain the commands
.IP
/usr/bin/uulog
.br
.I program /uucico
\ \ \-r1\ \ \-sinter
.br
.I program /uucico
\ \ \-r1
.LP
The ``\-r1'' option is required to start the
.I uucico
program in
.I MASTER
mode.
The ``\-s'' option can be used for polling as illustrated in the
second line where machine
.I inter
is being polled.
The third line will process all other spooled work.
.LP
Another shell file may be set up on a daily basis to remove
.I TM ,
.I ST
and
.I LCK
files
and
.I C.
or
.I D.
files for work that can not be accomplished for
reasons like bad phone number, login changes etc.
A shell file containing commands like
.IP
.I program /uuclean
\ \ \-pTM \-pC\s+4.\s-4 \-pD\s+4.\s-4
.br
.I program /uuclean
\ \ \-pST \-pLCK \-n12
.LP
can be used.
Note that the ``\-n12'' option causes the
.I ST
and
.I LCK
files older than 12 hours to be deleted.
The absence of the ``\-n'' option will use a three day time
limit.
.LP
A daily or weekly shell should also be created
to remove or save old
.I LOGFILE s.
A shell like
.IP
cp
.I spool /LOGFILE
\ \
.I spool /o\s+4.\s-4LOGFILE
.br
rm
.I spool /LOGFILE
.LP
can be used.
.SH
Login Entry
.LP
Two or more logins should be set up for
.I uucp .
One should be an administrative login:
the owner of all the uucp programs, directories and files.
All others are used by remote systems to access the uucp system.
Each of the ``/etc/passwd'' entries for the
.I access
logins should have
``\fIprogram\fR/uucico''
as the shell to be executed.
The login directory should be the public directory (usually
/usr/spool/uucppublic).
The various
.I access
login names are used in the
.I USERFILE
to restrict file access.
.SH
File Modes
.LP
The programs
.I uucp ,
.I uux ,
.I uucico ,
.I uulog ,
.I uuclean
and
.I uuxqt
should be owned by the
.I uucp
administrative login with the ``setuid'' bit set and only execute
permissions (e.g., mode 04111).
The
.I L\^\s+4.\s-4sys ,
.I SQFILE
and the
.I USERFILE ,
which are put in the
.I program
directory should be owned by
the
.I uucp
administrative login and set with mode 0400.
The mode of
.I spool
should be ``0755''.
The mode of
.I xqtdir
should be ``0777''.
The
.I L-dialcodes
and the
.I L-devices
files should have mode 0444.
.sp
.I "November 1979"
network 327347538 221 1 100666 22270 `
' refer -e network | tbl | troff -ms
' .TM "79-3782-2, 79-1274-7" "39199" "39199-11"
.RP
.if n .ls 2
.ND "August 18, 1978"
.ND April 30, 1979
.ND "June 1, 1979"
.ND "March 15, 1980"
.TL
A Dial-Up Network of
UNIX\s6\uTM\d\s0
Systems
.AU "MH 2D-234" 7386
D. A. Nowitz
.AU "MH 2C-572" 6377
M. E. Lesk
.AI
.MH
.AB
.if n .ls 2
A network of over one hundred
.UX
computer systems has been established using the
telephone system as its primary communication medium.
The network was designed to meet the growing demands for
software distribution and exchange.
There are several features that helped make it
a successful system:
.RS
.IP - 3
The startup cost is low.
A system needs only a dial-up port,
but systems with automatic calling units have much more
flexibility.
.IP -
No operating system changes are required to install or use the system.
.IP -
The communication is basically over dial-up lines,
but hardwired communication lines can be used
to increase speed.
.IP -
The command for sending/receiving files is simple to use.
.IP -
A general remote execution facility is part of the system;
remote mail is one use of this feature.
.IP -
Adequate security facilities are available,
so the site administrators feel comfortable about
being on the network.
.RE
.sp
...Keywords: networks, communications, software distribution, software maintenance
.AE
.CS 8 0 11 3 0 7
.if n .ls 2
.if t .nr PD 0.3v
.if n .nr PD 1v
.de Un
\s-1\fB\\$1\fP\s0\\$2
..
.SH
Introduction
.PP
The
.UX
operating system
.[
%T The U\s-2NIX\s0 Time-Sharing System
%K unix bstj
%A D. M. Ritchie
%A K. Thompson
%J Bell Sys. Tech. J.
%V 57
%N 6
%P 1905-1929
%D 1978
.]
is a time-sharing system that
runs on small to large minicomputers.
A typical user gets access to the system through
the telephone network.
Since each computer is connected to the telephone
network, they are potentially connected together;
all that is needed to connect the machines is
an automatic dialer and
a program
that can emulate a terminal.
(Figure 1)
.PP
Many
.UX
systems are used within the
Bell System.
Although there are some differences between them,
a large set of common software modules exist:
compilers, text editors, assemblers, linking loaders,
debuggers, phototypesetting programs, and so on.
An informal network emerged out of the need to
exchange, deliver and
maintain software.
The telephone network provides the transmission
path and the computer
programs described in this paper implement the
necessary protocols.
.PP
Over the past year, the network has grown to over one hundred machines through out the
country.
There are several major uses of the network:
.RS
.IP - 3
distribution of software
.nr PD 0
.IP -
distribution of documentation
.IP -
personal communication (mail)
.IP -
data transfer between closely sited machines
.IP -
transmission of debugging dumps and data exposing bugs
.IP -
production of hardcopy output on remote printers.
.RE
.SH
Design
.PP
In keeping with the style of
.UX
commands, the user interface is quite simple.
To copy a file from the local system to a remote
system, the user would execute the command
.IP "" 12
.B
uucp\ \ file1\ \ sysx!file2
.R
.sp
.LP
where
.I file1
and
.I file2
are file names and
.I sysx
is the remote system name.
All details of the connection
(e.g., device(s) to use for the connection,
phone number,
times the remote machine is available,
login sequence and password for the remote system,
retry for unavailable device or busy phone)
are hidden from the user.
The actual file transfer takes place when the connection
can be made.
.PP
We had to adapt to a community of systems that are independently
operated and resistant to suggestions that they should all
buy particular hardware or install particular operating system
modifications.
Therefore, we make minimal demands on the local sites
in the network.
Our implementation requires no operating system changes;
in fact, the transfer programs look like any other user
entering the system through the normal dial-up login ports,
obeying all local protection rules.
.PP
We distinguish between ``active'' and ``passive'' systems
on the network.
Active systems have an automatic calling unit
or a hardwired line to another system:
they can initiate a connection.
Passive systems do not have the hardware
to initiate a connection.
However, an
active system can be assigned the job of calling passive
systems and executing work found there:
this makes a passive system the functional equivalent of
an active system except for an additional delay while it waits to be polled.
.PP
Several groups, both inside and outside Bell Laboratories,
have constructed networks using hardwired connections exclusively.
.[
%T U\s-2NIX\s0 Time-Sharing System: The Programmer's Workbench
%A T. A. Dolotta
%A R. C. Haight
%A J. R. Mashey
%J Bell Sys. Tech. J.
%V 57
%N 6
%P 2177-2200
%D 1978
.]
.[
%T The Network U\s-2NIX\s0 System
%K unix
%A G. L. Chesson
%J Operating Systems Review
%V 9
%N 5
%P 60-66
%D 1975
%O Also in \f2Proc. 5th Symp. on Operating Systems Principles,\f1 1975.
.]
Our network, however,
uses both dial-up and hardwired connections
so that service can be provided to as many sites as possible and so the
slower dial-up paths can be
automatically used if
a hardwired link is out of service.
Dial-up connections are made at either 300 or 1200 baud;
hardwired connections are asynchronous up to 9600 baud
and might run even faster on special-purpose communications
hardware.
.[
%T A Virtual Channel Network
%A A. G. Fraser
%J Datamation
%P 51-56
%D February 1975
.]
.[
%T Spider \(em An Experimental Data Communications System
%Z ctr127
%A A. G. Fraser
%J Proc. IEEE Conf. on Communications
%P 21F
%O IEEE Cat. No. 74CH0859-9-CSCB.
%D June 1974
.]
Thus, systems typically join our network first as
passive systems.
When they find the service important, acquire
automatic calling units and become active
systems; eventually, they may install high-speed
links to particular machines with which they
handle a great deal of traffic.
At no time, however, must users change their
programs or procedures.
.PP
The basic operation of the network is simple.
Each participating system has a spool directory
in which work
(files to be moved or commands to be executed remotely)
is placed.
The
.Un UUCICO
program performs all transfers.
This program is started periodically to perform the
file transfers;
it selects devices,
establishes the connection to the remote machine,
performs the required login sequence,
performs file security checks,
transfers data files,
logs results,
and notifies specified users of transfer completions.
.PP
After the calling program completes all the work
for the
called system,
the called machine sends any files that have been queued for the calling system.
In this way, all services are available from all sites; passive sites,
however, must wait until called.
A variety of line protocols may be used;
this gives users some flexability and provides
a mechanism for distributing other protocols
in the future.*
.FS
* There is only one known system that has implemented
an additional protocal.
The protocol is used for high speed transfers using
a shared disk.
.FE
As long as the caller and called programs have a protocol in common,
they can communicate.
Furthermore, each caller knows the hours when each destination system
should be called.
If a destination is unavailable, the data intended for it
remains in the spool directory until the destination machine can be reached.
.PP
In addition to the
.Un UUCP
command, the user has
the
.Un UUX
command
which allows execution of programs that
require resources of
remote machines.
A common use of this facility is to format
a printout on the local machine
and send the result to a remote
machine which has a hard
copy output device.
Remote mail is implemented using the
.Un UUX
command but its execution is embedded in the
standard
.I mail
command.
.SH
Processing
.PP
The user has two commands that set up communications,
.Un UUCP
to set up file copying,
and
.Un UUX
to set up command execution where some of the required
resources (system and/or files)
are not on the local machine.
Each of these commands will put work and data files
into the spool directory for execution by the
.Un UUCICO
program.
Figure 2 shows the major blocks of the file transfer process.
.PP
The file names in the spool directory are constructed to allow the
.Un UUCICO
program
to identify the work and data files,
the remote machines that should be called,
and the order that the files for a
particular system should be processed.
.PP
The call is made using information from several
files.
A single conversation between a pair of systems is
ensured by the use of a
lock file.
A ``systems''
file contains information for making a connection
to a remote machine:
.IP
.RS
.IP [1]
system name,
.IP [2]
system access time
(days-of-week and times-of-day),
.IP [3]
device or device type to be used for the call,
.IP [4]
line speed,
.IP [5]
phone number,
.IP [6]
login information (multiple fields).
.RE
.PP
The
.I
phone number
.R
may contain abbreviations (e.g. ``nyc'', ``boston'') that get translated into dial
sequences using a
``dial-codes'' file.
This permits the same
.I "phone number"
to be stored at every site, despite
local variations in telephone services and dialing conventions.
.PP
A ``devices''
file is scanned using fields [3] and [4] from the
``systems''
file to find an available device for the connection.
If the connection fails after two attempts,
an alternate path can be
tried.
(The presence of more than one entry for a system
in the ``systems'' file
indicates alternate paths.)
If the connection is complete, the
.I
login information
.R
is used to log into the remote system.
The conversation between the two
.Un UUCICO
programs begins with a handshake started by the called (or
.I SLAVE )
system.
The
.I SLAVE
sends a message to let the
.I MASTER
know that it is ready to receive the system
identification and conversation sequence number.
The response from the
.I MASTER
is
verified by the
.I SLAVE
and if acceptable, protocol selection begins.
.PP
The remote system sends a message
.IP "" 12
P\fIproto-list\fR
.LP
where
.I proto-list
is a string of characters, each
representing a line protocol.
The calling program checks the proto-list
for a letter corresponding to an available line
protocol and returns a
.I use-protocol
message.
The
.I use-protocol
message is
.IP "" 12
U\fIcode\fR
.LP
where
.I code
is either a one character
protocol letter or a
\fIN\fR,
which means there is no common protocol.
.PP
During the processing, one program is the
.I MASTER
and the other is the
.I SLAVE .
Initially, the calling program is the
.I MASTER.
These roles may switch one or more times during
the conversation.
.PP
There are five messages used during the
work processing, each specified by the first
character of the message.
They are
.KS
.TS
center;
c l.
S send a file,
R receive a file,
X get files whose names are
determined on the remote system.
C copy complete,
H hangup,
.TE
.KE
.LP
The
.I MASTER
uses the first three to request file transfers.
The
.I SLAVE
responds to each with a
.I yes
or
.I no.
.PP
The send, receive and execute replies are
based on permission to access the
requested file/directory.
After each file is copied
to the receiving system,
a copy-complete message is sent by the receiver of the file.
The requests and results are logged on both systems,
and, if requested, mail is sent to the user reporting completion.
A failure message is sent by mail to the requestor.
.PP
The
.I MASTER
executes all the work for the remote followed by a
.I H
message.
The
.I SLAVE
checks for work in its spool directory.
If work for the remote system exists, an
.I HN
message is sent and the programs switch roles;
otherwise an
.I HY
response is sent.
When an
.I HY
message is received by the
.I MASTER
it is echoed back to the
.I SLAVE
and the protocols are turned off.
Each program sends a final
.I OO
(close) message to the
other.
A sample conversation is shown in Figure 3.
.SH
Security
.PP
The implementation of this
network
between independent sites, many of which
store proprietary programs and data,
illustrates the pervasive need for security
and administrative controls over file access.
A number of security features evolved during the development
of the system:
.RS
.IP - 3
file directory access restrictions,
.IP -
file monitoring,
.IP -
callback,
.IP -
call sequence checking,
.IP -
limited commands for
the
.Un UUCP
logins,
.IP -
restricted commands available to the
.Un UUX
command,
.IP -
limited access to remote login information.
.RE
.PP
Each site, when configuring its programs and system files,
limits and monitors transmissions.
The administrator can give some remote systems limited file access
while others have the same access privileges as the local users.
Each system establishes a public directory for
the
.Un UUCP
program.
A degree of file security can be achieved if the administrator allows
the remote
.Un UUCP
programs to access only this
public directory.
This requires a local user for remote
sites to get or send files.
Records are kept identifying all files
that are moved into and out of the local system,
and also of how the requestor of such accesses identified
themselves.
.PP
A site can arrange
to permit users
to call up
and request that work be done;
the calling users are then called back
before the work is actually performed.
This makes it possible to verify
that the requestor is legitimate.
Masquerading is difficult
even if the necessary password is known.
.PP
Each machine can optionally maintain a sequence count for
conversations with other machines and require a verification of the
count at the start of each conversation.
A would-be impersonator must steal not only the correct phone number,
user name, and password, but also the sequence count, and must call in
promptly before the next legitimate request from either side.
Even a successful masquerade will be detected on the next correct
conversation.
.PP
The ``systems'' file, which is described in the Processing Section,
contains information to allow the
.Un UUCICO
program to login to the remote machines.
This information would usually permit almost complete
access to the system.
The normal file system protections are used to restrict
access of the ``systems'' file to the
.Un UUCP
programs and the administrator.
This gives some security,
but it depends on the remote system administrator.
To minimize this problem, we set up the system so that the
only program that can be executed with the
.Un UUCP
login is the
.Un UUCICO
program.
The system administrator can use the directory access restrictions to protect the local system
without depending on a remote system to protect the login information.
.PP
The
.Un UUX
command allows users to execute commands on remote systems.
To protect a system, the administrator has to specify a list of commands that the
.Un UUCP
system can execute.
All commands received are checked against the list.
.SH
Present Uses
.PP
One application of this software is remote mail.
Normally, a
.UX
system user
writes ``mail dan'' to send mail to
user ``dan''.
By writing ``mail pwba!dan''
the mail is sent to user
``dan''
on system ``pwba''.
.PP
The primary uses of our network to date have been in software maintenance.
New programs (or new program versions)
are sent to users, and potential bugs are returned to authors.
A ``stockroom'' has been established at two
sites.
This allows remote users to call in and request software without
bothering the author.
A ``stock list'' of available programs, new bug
fixes, and utilities is updated regularly.
.PP
Test cases are retrieved from other systems
to determine whether errors on remote systems are caused
by local misconfigurations or old versions of software,
or whether they are bugs that must be fixed at the home site.
This helps identify errors rapidly.*
.FS
* For one set of test programs maintained by us,
over 70% of the bugs reported from remote sites
were due to old software and were fixed
merely by distributing the current version.
.FE
.PP
The
.Un UUX
command has
been useful for providing remote output.
There are some machines that do not have hard-copy
devices, but that are connected over 9600 baud
communication lines to machines with printers.
The
.Un UUX
command allows the formatting of a
printout on a local machine and printing on a
remote machine using standard
.UX
commands.
.br
.SH
Performance
.PP
Throughput, of course, is primarily dependent on transmission speed.
The table below shows the real throughput of characters
on communication links of different speeds.
These numbers represent actual data transferred;
they do not include bytes used by the line protocol for
data validation such as checksums and messages.
At the higher speeds, contention for the processors on both
ends prevents the network from driving the line at full speed.
The range of speeds represents the difference between light and
heavy loads on the two systems.
If desired, operating system modifications can
be installed
that permit full use of fast links.
.KS
.TS
center;
c c
n n.
Nominal speed Characters/sec.
300 baud 27
1200 baud 100-110
9600 baud 200-850
.TE
.KE
In addition to the transfer time, there is some overhead
for making the connection and logging in, ranging from
a few seconds to 1 minute.
Even at 300 baud, however, a typical 5,000 byte source program
can be transferred in
four minutes instead of the 2 days that might be required
to mail a tape.
.PP
Traffic between systems is variable.
During a typical week for a group a three co-located systems,
30 users made about 300 requests resulting in the
transfer of about 3 million bytes.
(These transfers took place over 9600 baud hardwired lines.)\
On a system that distributes and maintains standard
system software,
a typical week consists of transferring
about 1500 files (10 million bytes):
this includes the
dial-up network at 300 or 1200 baud
and hardwired local lines.
.PP
Presently, the total number of sites in the network is about 120.
This includes most of the Bell Laboratories
full-size machines
that run the
.UX
operating system,
many operating telephone companies,
some Western Electric sites,
and several universities.
Geographically, the machines range from Andover, Massachusetts to
Berkeley, California.
.SH
Further Goals
.PP
Eventually, we would like to develop a full system of remote software
maintenance.
Conventional maintenance (a support group that mails tapes)
has many well-known disadvantages.
.[
%A F. P. Brooks, Jr.
%T The Mythical Man-Month
%I Addison-Wesley
%C Reading, Mass.
%D 1975
.]
There are distribution errors and delays, resulting in old software
running at remote sites and old bugs continually reappearing.
These difficulties are aggravated when
there are 100 different small systems, instead of a few large ones.
.PP
The availability of file transfer on a network of compatible operating
systems
makes it possible to send programs directly to the end user who wants them.
This avoids the bottleneck of negotiation and packaging in the central support
group.
The ``stockroom'' provides this function for new utilities
and fixes to old utilities.
However, it is still likely that distributions will not be sent
and installed as often as needed.
Users are justifiably suspicious of the ``latest version'' that has just
arrived; all too often it features the ``latest bug.''\
What is needed is to address both problems simultaneously:
.RS
.IP 1.
send distributions whenever programs change.
.IP 2.
have sufficient quality control so that users will install them.
.RE
.LP
To do this, we recommend systematic regression testing both on the
distributing and receiving systems.
Acceptance testing on the receiving systems can be automated
permitting the local system to ensure that its essential work can continue
despite the constant installation of changes sent from elsewhere.
The work of writing the test sequences should be recovered by lower
counseling and distribution costs.
.PP
Some slow-speed network services have been implemented.
We now have inter-system
.I mail
plus the many implied commands represented by
.Un UUX .
However, we still need inter-system
.I write
(real-time inter-user
communication) and
.I who
(list of people logged in
on different systems).
A slow-speed network of this sort may be very useful
for speeding up counseling and education, even
if not fast enough for the distributed data base
applications that attract many users to networks.
Effective use of remote execution over slow-speed lines, however,
must await the general installation of multiplexed channels so
that long file transfers do not lock out short inquiries.
.SH
Lessons
.PP
What follows is a summary of the lessons we learned in
building this system.
.IP 1.
By starting the network in a way that requires no hardware or operating system
changes, one can get going quickly.
.IP 2.
Support will follow use.
Since the network existed and was being used, system maintainers
were easily persuaded to help keep it operating, including purchasing
additional hardware to speed traffic.
.IP 3.
Make the network commands look like local commands.
Our users have a resistance to learning anything new;
all the inter-system commands look similar to
standard
.UX
system
commands so that little training cost
is involved.
.IP 4.
In the first version, we made the mistake of using dial-up
communications exclusively.
The second implementation of the system
permits the use of different connecting fabric,
such as hardwired asyncronous lines:
this adds flexibility to the network.
.IP 5.
Security presented a bigger problem than we anticipated.
We had to give the administrators features that
enabled them to protect their systems.
These features, however, made it difficult to do useful work.
The creation of a public directory on each system alleviated some of the problem, but the casual users of
.Un UUCP
are often
unpleasantly surprised when their
requests are rejected by remote systems.
.SH
Acknowledgements
.PP
We thank G. L. Chesson for his design and implementation
of the packet driver line protocol, and A. S. Cohen, A. G. Fraser, J. Lions,
and P. F. Long for their suggestions and assistance.
.SG MH-3782/1274-DAN/MOH
.[
$LIST$
.]
o.fig3 323378325 221 1 100664 1090 `
.LP
.ds LA \v'-.1n'<\v'.1n'\h'-2.20n'\f2\\l'.52i\-'\f1
.ds RA \f2\\l'|3.25i\-'\f1\h'-1.25n'\v'-.1n'>\v'.1n'
.ds RD \f2\\l'|3.25i\&='\h'-1.15n'\f1\v'-.1n'>\v'.1n'
.ds LD \v'-.1n'<\v'.1n'\h'-2.40n'\f2\\l'.55i\&='\f1
.ds SD \f2\l'.42i\&='\f1
.nf
.mk
.B1
CALLING
SYSTEM
.B2
.nf
.rt
.ta 2.0iC
MESSAGES
& DATA
.rt
.ta 1i 1.75i 2.5i 3.5i 4.25i
.po +3.4i
.B1
CALLED
SYSTEM
.B2
.po
.nf
.vs 20p
.ps 12
.cs I 25
555-6789 \*(RA [ Dialup ]
\*(LA \f3login:\f1
userid, password \*(RA [ Identification ]
\*(LA \f3S\f1 [ Handshake and
\f3S\f1 36 myname \*(RA sequence check ]
\*(LA \f3P\f1 a, b, c [ Offer protocols ]
\f3U\f1 b \*(RA [ Choose protocol ]
\f3S\f1 /abc/def/ghi \*(RA [ Send file ]
\h'.10i'\*(SD D\s-2ATA\s0 \*(RD
\f3R\f1 /abc/def/jkl [ Get file ]
\*(LD D\s-2ATA\s0 \*(SD
\f3H\f1 \*(RA [ Offer to stop ]
\*(LA \f3HN\f1 [ Refused ]
\*(LA \f3S\f1 /abc/mno/prs [ Called system sends file ]
\*(LD D\s-2ATA\s0 \*(SD
\*(LA \f3H\f1 [ Offer to stop ]
\f3HY\f1 \*(RA [ Accepted ]
\*(LA \f3(OO)\f1 \*(RA
Hangup
.sp 2
.ce
FIGURE 3
.ce
SAMPLE CONVERSATION
run.network 280424690 221 1 100775 52 `
refer -e /usr/doc/uucp/network | tbl | troff -ms $*