network

unix v7是最后一个广泛发布的研究型UNIX版本

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.
.SH
Line Protocol Selection
.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 code is either a one character
protocol letter or a
.I N
which means there is no common protocol.
.PP
Greg Chesson designed and implemented the standard
line protocol used by the uucp transmission program.
Other protocols may be added by individual installations.
.SH
Work Processing
.PP
During processing, one program is the
.I MASTER
and the other is
.I SLAVE .
Initially, the calling program is the
.I MASTER.
These roles may switch one or more times during
the conversation.
.PP
There are four 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,
C	copy complete,
H	hangup.
.TE
.KE
.LP
The
.I MASTER
will send
.I R
or
.I S
messages until all work from the spool directory is
complete, at which point an
.I H
message will be sent.
The
.I SLAVE
will reply with
\fISY\fR, \fISN\fR, \fIRY\fR, \fIRN\fR, \fIHY\fR, \fIHN\fR,
corresponding to
.I yes
or
.I no
for each request.
.PP
The send and receive replies are
based on permission to access the
requested 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
.UX
.I cp
command, used to copy from the spool directory, is successful.
Otherwise, a
.I CN
message is sent.
The requests and results are logged on both systems,
and, if requested, mail is sent to the user reporting completion
(or the user can request status information from the log program at any time).
.PP
The hangup response is determined by the
.I SLAVE
program by a work scan of the spool directory.
If work for the remote system exists in the
.I SLAVE's
spool directory, a
.I HN
message is sent and the programs switch roles.
If no work exists, an
.I HY
response is sent.
.PP
A sample conversation is shown in Figure 2.
.SH
Conversation Termination
.PP
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.
.NH
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 usg!dan''
the mail is sent to user 
``dan''
on system ``usg''.
.PP
The primary uses of our network to date have been in software maintenance.
Relatively few of the bytes passed between systems are intended for
people to read.
Instead, new programs (or new versions of programs)
are sent to users, and potential bugs are returned to authors.
Aaron Cohen has implemented a
``stockroom'' which allows remote users to call in and request software.
He keeps a ``stock list'' of available programs, and new bug
fixes and utilities are added regularly.
In this way, users can always obtain the latest version of anything
without bothering the authors of the programs.
Although the stock list is maintained on a particular system,
the items in the stockroom may be warehoused in many places;
typically each program is distributed from the home site of
its author.
Where necessary, uucp does remote-to-remote copies.
.PP
We also routinely retrieve test cases 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.
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.
.PP
Another application of the network for software maintenance
is to compare files on two different machines.
A very useful utility on one machine has been
Doug McIlroy's ``diff'' program
which compares two text files and indicates the differences,
line by line, between them.
.[
hunt mcilroy file
.]
Only lines which are
not identical are printed.
Similarly,
the program ``uudiff''
compares files (or directories) on two machines.
One of these directories may be on a passive system.
The
``uudiff'' program
is set up to work similarly to the inter-system mail, but it is slightly
more complicated.
.PP
To avoid moving large numbers of usually identical
files,  
.I uudiff
computes file checksums
on each side, and only moves files that are different
for detailed comparison.
For large files, this process can be iterated; checksums can be computed
for each line, and only those lines that are different
actually moved.
.PP
The ``uux'' command has
been useful for providing remote output.
There are some machines which do not have hard-copy
devices, but which are connected over 9600 baud
communication lines to machines with printers.
The
.I uux
command allows the formatting of the
printout on the local machine and printing on the
remote machine using standard
.UX
command programs.
.br
.NH
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 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 even very 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
15 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.  Between two
closely related systems,
we observed
20 files moved and 5 remote commands executed in a typical day.
A more normal traffic out of a single system would be around
a dozen files per day.
.PP
The total number of sites at present
in the main network is
82, which includes most of the Bell Laboratories
full-size machines
which run the
.UX
operating system.
Geographically, the machines range from Andover, Massachusetts to
Denver, Colorado.
.PP
Uucp has also
been used to set up another network
which connects a group of
systems in operational sites with the home site.
The two networks touch at one
Bell Labs computer.
.NH
Further Goals
.PP
Eventually, we would like to develop a full system of remote software
maintenance.
Conventional maintenance (a support group which mails tapes)
has many well-known disadvantages.
.[
brooks mythical man month 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 just 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'' serves 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:
.IP 1.
Send distributions whenever programs change.
.IP 2.
Have sufficient quality control so that users will install them.
.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 and
permits 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 in lower
counseling and distribution costs.
.PP
Some slow-speed network services are also being implemented.
We now have inter-system ``mail'' and ``diff,''
plus the many implied commands represented by ``uux.''
However, we still need inter-system ``write'' (real-time inter-user
communication) and ``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 multiplexable channels so
that long file transfers do not lock out short inquiries.
.NH
Lessons
.PP
The following is a summary of the lessons we learned in
building these programs.
.IP 1.
By starting your network in a way that requires no hardware or major operating system
changes, you 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 very similar to
standard
.UX
system
commands so that little training cost
is involved.
.IP 4.
An initial error was not coordinating enough
with existing communications projects: thus, the first
version of this network was restricted to dial-up, since
it did not support the various hardware links between systems.
This has been fixed in the current system.
.SH
Acknowledgements
.PP
We thank G. L. Chesson for his design and implementation
of the packet driver and protocol, and A. S. Cohen, J. Lions,
and P. F. Long for their suggestions and assistance.
.[
$LIST$
.]