@Part( voverview, root "text" )
@Section(V-System Overview)

The V-System is a distributed operating system designed to run
on a collection of personal workstations and server machines
connected by a high-speed local-area network.
It currently runs on SUN workstations@Cite(BECH82)
connected by 3 or 10 Mbit Ethernet.
The basic structure of V is similar to that of a number of contemporary
distributed systems.
The distributed V
kernel provides uniform local and network interprocess communication
by messages.
Most system services are implemented by dedicated server processes
that provide their services through message communication.
Application programs are written using a procedural interface
to system services provided by a collection of @i[stub] routines
that are part of the standard run-time library.
These routines hide the message interface from applications that
do not explicitly use interprocess communication.

The V kernel provides an ideal base for a distributed system
because it allows software above the kernel level to be designed
and implemented in the same way,
independently of whether the clients it serves and
the services it uses are local or distributed.
For instance, we are using diskless personal workstations
with all file access and program loading via IPC messages to
network file servers.
Adding a disk and local file server process to a workstation
requires no changes to the workstation software other than
adding a disk driver to the kernel.

@subsection(V-System IPC Model)
The following briefly describes the IPC model provided,
the basic IPC protocol, and its performance.
For further details, the interested reader is referred to a separate
in-depth study@Cite(CHER83).

The V interprocess communication design is derived from Thoth@Cite(CHERI82)
with several extensions for distributed operation.
Basic interprocess communication is in terms of three primitives_@p[Send],
@p[Receive], and @p[Reply]_that implement a message transaction
or request-response pair of messages, as shown in Figure 1.

@comment[Figure moved to fix up page layout]

The @i[sender] sends a message to the @i[receiver]
and is blocked until the message
is received and replied to.
The time for a @p[Send-Receive-Reply] sequence using 32-byte messages
between two processes on separate 10 MHz SUN workstations connected
by a 3 Mbit Ethernet is 2.56 milliseconds.
A message may be @i[forwarded] by the receiver to a third process,
in which case it appears as though the sender originally sent to the
third process, which is then expected to receive the message
and reply to the sending process.

Large data transfers are handled by separate primitives,
@p[MoveTo] and @p[MoveFrom],
which move an arbitrary number of bytes between the sender and
the receiver of a message while the sender is still awaiting the reply
message.
Basically, the recipient of a message can use @p[MoveFrom] and @p[MoveTo]
to read and write the memory space of the message sender up to
the point that the reply message is sent.
Using @p[MoveTo] for program loading from a network file server into
a diskless SUN workstation (assuming the program text is already
in the file server's memory buffers),
a 64 kilobyte program can be loaded in 338 milliseconds on the
3 megabit Ethernet.
This performance is within 13 percent of the maximum speed at which a SUN
workstation can write packets out to the network when there is no protocol
overhead.

@PressPicture( file="send.fig", height="2.09 inches")
@Center(@b(Figure 1:) Send-Receive-Reply Message Transaction)

Streams can be implemented efficiently using the V IPC primitives.
For instance,
with a disk delivering a 512 byte page every 15 milliseconds,
a file can be read sequentially averaging 17.13 milliseconds per page.
This is comparable to the performance of highly tuned special-purpose
file access protocols@Cite(POPE81).
With this performance,
the V IPC facility is also entirely adequate as a transport level
for remote terminal access and file transfer.

@subsection(Message Standards)

One of the key aspects of building a cohesive system on top of the
V kernel is adopting standards on the use of messages so that
different applications and servers can be interconnected
flexibly with minimal difficulty.

Messages specifying operations, called request messages, follow a system
standard message format in containing the request code specifying
the operation in the first field (16-bit word) of the message.
The operation code acts as a tag field in the request message,
similar to tag fields in Pascal variant records,
specifying the format of the rest of the message,
i.e., the number and type of parameters to the operation.

Reply messages sent by servers in response to request messages
have their format specified by the requested operation as well,
relying on the tight coupling of reply messages to request messages
in the V message primitives.  A reply code (usually one of
a set of standard system replies) appears
at the beginning of each reply message, indicating whether
the request succeeded or failed, and in the latter case,
the reason for failure.

Another V-System standard is the V I/O protocol@Cite(CHERI81),
which provides uniform
connection of program input and output to a variety of data sources
and sinks, including disk files, terminals, pipes, network connections,
graphics pointing devices, and memory arrays.
The I/O protocol uses the IPC provided by the kernel as a transport
layer.
It is a presentation protocol in specifying conventions
on the format of messages
and a session protocol in specifying the legal sequence of operations
for opening a file, reading and writing the file and closing the file.
Basically, it provides a data transfer protocol between any two processes,
useful when the data can be viewed as a file and communication between
processes can be structured with one process, the server, implementing the
file and the other process, the client, reading and writing the file.

The use of the I/O protocol by all servers that support file-like objects
has been of utmost importance in the cohesiveness of V.
Building on the experience with the I/O protocol over the past 3 years,
we have designed and implemented a name-handling protocol that
provides uniform client-server interaction for handling names
while allowing flexible distributed name-handling by a variety
of different servers.