This documentation should be read by people responsible for
maintaining the network (and the systems it runs on).
It is divided into the following sections:
Besides the commands described in the net introduction,
there are a number of network-internal commands and
See if the network daemons are running with the command
If not running, see below.
Check the network queue to see how long commands have been waiting to
To restart the network daemons, try
See if they are running, as above.
If so, there should be two net daemon processes per machine connection\(em
``kill \-9'' the child named ``netdaemon'' and the parent ``netstart'' will start
If there are no ``netstart's'' or ``netdaemon's'', executing
will start up all the daemons on your machine.
To have two ``netdaemons'' pointing to the same machine is to invite disaster.
What happens is that a few small requests get through,
and then the error rate goes up by a factor of a hundred.
The first thing to do when you see this is to check the
(All this must be done as super-user).
There are files /usr/net/plogfile? with a log for each
directly-connected machine.
% tail /usr/net/plogfiley
will tell you in a cryptic form what the network
has done on the Cory machine.
This is a good file to inspect to see if transmissions
It is readable only by ``schmidt'' and ``root'' (and ``staff'' on Cory).
Basically, ``sends'' begin ``^S'' and end ``^T''.
If a send fails for some reason, ``^F'' is printed instead of ``^T''.
``^R'' is printed when a receive begins.
``RCV'' is entered when the command is received and executed.
``^P'' indicates a pass through.
The file /usr/net/netstat?, one per directly-connected machine,
have various statistics about the usage of the network, and
The overloading on various machines is causing high error rates.
If these rates persist, the network can overload to the point
where the queues are immense and nothing gets through.
The only thing that can be done at this point is to remove the files (using
as super-user) and adjust the delay times in the `initfile'.
If free space is a scarce commodity, truncate logfile and plogfile?,
and check /usr/net/send? and /usr/net/rcv.
If there are any files there which are quite old,
use your judgement to remove them.
Net news should be provided periodically
(usually in `/usr/help' or `/usr/news').
For another machine to join the network, there must be some hardware link,
such as tty lines, special character-oriented
hardware, or DMA lines between the two machines.
The software does not require the link to be reliable or fast.
The best way to start is with slow-speed TTY lines
(say 1200 baud) which demonstrate the network's usefulness at low cost.
The highest transfer speed on a TTY link is about
one-half the link speed (at best),
because of processing time, the 3 \(-> 4 character
expansion from 8 bits to 6, and the responses.
There is a subdirectory ``src/net''
with all the network source files and a ``makefile''.
The file ``READ_ME'' has information about
the different conditional compilation
option available, and table entries which must be made in the `.c' files.
Assuming the options have been specified in the makefile, the command
will make all the necessary files.
will install the user commands and service programs.
The directories are specified as options in the makefile.
removes all the `.o' and executable files.
There are also other little-used programs, made by ``make othernet''.
Included are programs to send and receive packets and files, and a program
to simulate TTY lines using pipes.
It should not be necessary to run these.
The central directory is `/usr/net',
which has subdirectories `bin', `rcv', and `send?', where
the `?' represents the one-letter codes of the directly-connected machines.
For various reasons, the support programs
(netdaemon, netstart, mmail, mwrite,
The user programs may be anywhere but the pathnames in "Paths.h"
The logfiles are `logfile' and `plogfile?',
one for each directly-connected machine.
If not present in `/usr/net', they are not created.
The file `bin/start' should start up all the net daemons on the current machine.
This file is normally executed by `/etc/rc'.
The file `initfile' has a format similar to `.netrc'
but is read by the net daemons when they are started.
It has the network device names, speed and various tuning parameters.
The complete list is in the source file `sub.c'.
It is generally possible to change almost anything about the network
through the `initfile' and restarting the daemon.
The program `bin/netstart' is a simple program to
start up a net daemon, and if it should abort for any reason, restart it.
There must be an account `network', which executes
all responses and the free commands.
Its login directory should be `/usr/net/network' and
login shell should be `nsh' in that directory.
The list of free commands can be changed in `nsh.c'.
The `cat' command must be in `/bin' (used by
At Berkeley, we follow the convention that the TTY
special files are named `/dev/net-X', where `X'
is the remote machine name.
mail program should be modified to recognize
remote names and to fork a ``sendmail'' command.
If possible, a `\-r' option should be added (see `mmail.c').
It is important to understand the scope of this network;
what it is and what it is not.
Since it is ``batched'', there are a lot of things it cannot do.
Our experience is that remote file copying, mailing and printing between
machines are adequate for our immediate needs.
In the future, we will concentrate on improving
the hardware and speeding up the network, rather than major user-interface
This is a list of the things that have been planned for the future
Use Bill Joy's retrofit library to simulate the version 7 system calls.
This would reduce the dependence on conditional compilation for V6 code.
The file length restriction is a major inconvenience.
One way to allow large files would be to
send large files (over 100,000 chars) only when there are no smaller ones.
This would be non-preemptive, but might be workable.
Another way would be to have two hardware links,
and two sets of daemons, one for large files and one for small ones.
Bob Fabry has suggested generalizing the machine name to
be user-definable as a login/machine pair, to
make it easier for people with multiple accounts on multiple machines.
It is possible to share binaries between all
the similar machine configurations (e.g. the Comp. Center machines).
This involves ``patching'' the local machine in the binary.
Ed Gould suggested that the notion of ``default'' machine
that an appropriate default for, say, ``netlpr'' was a
nearby machine with a quality printer, whereas the default for ``net''
should be the logical most useful machine.
I have just recently bullet-proofed the network
so `root' commands are very restricted.
However, the presence of passwords in the `.netrc' files
poses a hazard to other machines when one machine is broken into.
As long as the root password is not in a file, the root is safe.
I am fairly convinced there is no way using encryption
to handle the `.netrc' files.
The introductory documentation is very explicit about
the threat these passwords pose.
Certain other more exotic requests are unlikely
to get done until things change:
Having the same user-id's across machines.
Adding an option to ``net'' to wait until a response has been received.
There should be a net status command which would
give things like load averages, the number of users, etc.
The notion of a local queue is not general enough\(em
should print out relevant queues on other machines.
Files on intermediate machines can't be \fInetrm\fP'ed.
queue files is a problem.
No easy solution to this problem is known at this time.
There are hooks in for the B, INGRES, and Q
machines, and I would love to have them added to the network.
I'd like to see the following things happen:
A driver for the network links to avoid character
processing, which would make 9600-baud practical.
On the Computer Center machines, this could be accomplished
using a high speed link through the Bussiplexor.
It has also been suggested that all the mail programs
look at a file to see if they should forward
this message to an account on another machine.
This would allow people to get all their mail on one machine.
Extra files beginning with `df...' are created in the `send?'
directories, with no control files (`cf...').
They should be removed periodically.
creates files with filenames as login names.
They will never be sent and subsequent requests
Their net queue files should be removed.
In general, some requests can block the queue until removed.
Shorter requests will get through, and longer ones will not.
Again, their net queue files should be removed.