@Section(Implementation)
@label(Implementation)
The model described in the previous section has been implemented and
in use in the V-System for several months.
In this section, we describe some details of interest regarding the
implementation and discuss our experience to date.

Our current configuration consists of several diskless SUN workstations
(about 30 counting those using V, but not necessarily part of our project)
connected by 3 and 10 megabit Ethernet.
There are 7 @c[Vax/Unix]@foot(@c[Vax] is a trademark of Digital Equipment
Corporation; @c[Unix] is a trademark of Bell Laboratories.)
systems running our file server software, providing
program loading and file access for the workstations.
We are in the process of bringing up a V kernel-based file server on a SUN.
There is also a V kernel-based laser printer server, and a Internet server
that runs a V kernel-based implementation of IP/TCP.
Each workstation also runs one or more simple local server processes,
including a virtual graphics terminal server@Cite(thirdgen),
exception server, program manager, and context prefix server.

All of the servers that deal with CSnames implement the
name-handling protocol described in the previous section.
In particular, the file server software maps context identifiers onto
directories that act as starting points for interpreting relative pathnames,
similar to the current working directory in Unix@Cite(RICH74).
A pathname is interpreted as a context prefix specifying the directory
with the final file name component being interpreted in the context
defined by the directory.

The context prefix server on each workstation defines context
prefixes for the contexts being used by the user of the workstation.
Normally these include some standard context prefixes and
some corresponding to the file servers being used, plus some special
contexts within the file servers, such as home directory, etc.
It is common procedure for a workstation user to be accessing several
file servers simultaneously, with several context prefixes defined for
each server.
Because each user has his own context prefix server,
the top-level context prefixes can be user-specified and different for
each user, although in practice considerable use is made of standard
prefixes.

The context prefix
server allows names to be defined for both ordinary @i[(process-id,
context-id)] pairs, and also @i[(logical-pid, well-known-context-id)] pairs.
For the latter type of name, the server performs a @p[GetPid] operation each
time the name is used.
It has proven useful to be able to give character string names to generic
services in this way, and
several of the standard, predefined prefixes are of
this type.

The system run-time routines provide several types of support for the
system naming conventions.
When a new program is executed, it is passed a process identifier and
context identifier specifying its @i[current context].
It may change this during the course of execution using a function
that is analogous to the ``change directory'' function in Unix.
When the program executes an @p[Open] call to access a file-like object,
the @p[Open] routine checks whether the name specified starts with the
standard context prefix character, `@t([)'.
If so, it sends an @p[Open] request message to the workstation context
prefix server which parses the context prefix, modifies the message
to indicate the context corresponding to the prefix, and forwards
the message to the server implementing this context.
If not, @p[Open] specifies the current context identifier in the message
and sends to the request directly to the server implementing the
current context.
All other CSname-handling routines operate similarly,
including routines for removing, renaming, querying, and changing the
current context.
(The code that checks for the `@t([)' character is localized in a single
common routine.)

The time for an @p[Open] (including creating the message, sending to the
server, and receiving and processing
the reply, but excluding the server-specific
actions on @p[Open]) is 1.21 milliseconds in the current context with the
server local and 3.70 milliseconds in the current context with the
server remote.
When a context prefix is specified and the @p[Open] request thus goes
through the context prefix server,
the time increases to 5.14 milliseconds with the server local,
and 7.69 milliseconds with the server remote.  The
difference is identical within the limits of experimental error
in both cases (3.94 vs. 3.99 milliseconds),
because it reflects the processing time in the context prefix server,
which is always local, even though the server performing
the @p[Open] may be local or remote.

The context prefix server is 4.5 kilobytes of code
plus 2.6 kilobytes of data (mostly space reserved
for its context directory) when compiled for
the Motorola 68000.
This space cost is not significant on SUN workstations, which typically
have one or two megabytes of main memory.

Each CSNH server also implements one or more context directories.
The initial type tag in each entry specifies
one of several standard entry formats.
A single ``list directory'' command lists the objects in any one of
several different contexts, including programs in execution,
disk files, virtual terminals, TCP connections, and context
prefixes.
This program and the typed representations it relies on appear to
extend well to the new contexts we are currently implementing.

Requests are provided in the servers for determining the name of
a context from its context identifier as well as the name of,
for example, a file from its instance identifier.
This provides the required support for a program to determine
the CSname of its current context as well as the ``absolute''
name of, for example, an open file.
Unfortunately, this is the inverse mapping of a many-to-one function
so the CSname may not be the one that was in fact used.
In fact, there is no guarantee that there is an inverse mapping,
given that, for example, the context prefix may no longer be defined.
The difficulty of inverting the name mapping to determine the
CSname for an object is made worse by the possibility that
a name request was forwarded from one server to another during
the course of name interpretation.
For example, a component of the name in one file server may
be logically linked to a directory on another file server.
It is difficult, if not impossible, to determine which server forwarded
the request when working backward from the object.

In general, this reverse mapping to extract a name appears quite
important and quite difficult.
The pathological cases of strange or non-existent reverse mappings
occur very rarely
and thus are difficult to motivate fixing.
Still, they occasionally cause confusion for users.