@Part(csnaming, root "text") @Section(Character String Naming) @label(CSnaming) V-System standards for character string naming are specified by the @i[V-System Name Handling Protocol]. The protocol specifies a number of conventions for request messages that use character string names to identify objects. The protocol includes: @itemize{ A method for specifying the context in which a name is to be interpreted, using a numeric identifier. Specification of several common fields for all messages that contain character string names. A standard procedure for mapping names, which may involved forwarding partially interpreted names from one server to another. A mechanism for determining the objects named in a given context, including general query and modification operations on such objects. Several other operations that must be implemented by all servers participating in the protocol, and some that are optional. } We first define some terms, then discuss the protocol itself. The section concludes with a discussion of context prefix servers. @subsection(Character String Names) A V-System character string name (or @i[CSname]) is a sequence of zero or more bytes, of a specified length or else terminated by a null byte. Although CSnames may contain arbitrary bytes, they are usually meaningful human-readable ASCII strings. The term @i[character string name handling server (CSNH server)] refers to any server that performs character string name mapping as specified by the name-handling protocol, regardless of what else it does. We use the term @i[CSname request] to refer to any request that contains a character string name that must be mapped to an object as part of the requested operation. @Subsection(Contexts) In general, the interpretation of a character string name depends on the @i[context] in which the name is used. Formally, a context is a set of (name, object)-tuples. A context can have an arbitrary set of members in theory. Multiple contexts on a single server can arise from servers implementing more than one type of object. For example, a file server may implement both files and user accounts. Multiple contexts are also used to modify the interpretation of names within a structured name space such as a hierarchical file system. One can regard the directories in a conventional file system as defining multiple contexts. For example, the filename ``naming.mss'' could refer to a file named ``/ng/@|mann/@|naming.mss,'' ``/ng/@|cheriton/@|naming.mss,'' or perhaps other files, depending upon which fileserver the name was mapped by and which directory was current at the time, i.e., upon which context it was interpreted in. In the V-System, a context is specified by the pair @i[(server-pid, context-identifier)]. The @i[server pid] is a process identifier, specifying the process which is to interpret the name. The @i[context identifier] is a numeric identifier, specifying a particular context or name space implemented by the server. Ordinary context identifiers are server-assigned and valid only so long as the server process continues to exist. We have also found it convenient to define several @i[well-known] context identifiers with fixed values. These are used to specify generic name spaces such as ``home directory'' and ``standard program directory.'' Also, when a server implements only one context, the context identifier has little meaning and uses a standard default value of 0. Thus, a @i[fully-qualified] CSname includes a server pid, a context identifier, and the byte string. Given such a specification, the interpretation of the name is fully specified independent of the operation requested. @subsection(Message Format) Each CSname request specifies the name, length of name, index into the name at which interpretation is to begin (or continue), and a context identifier specifying the context in which to interpret it. The server-pid portion of the context is implictly specified by sending the message directly to the server in question. This standard format serves as a skeleton for any request message type that contains a CSname. The standard fields are a fixed part of the message structure, always appearing in the same place, while the rest of the message is a variant part whose format depends on the request's operation code. Thus, a CSNH server can perform some processing on any CSname request, even if it does not understand the operation code. The importance of this is indicated below. @subsection(Name Mapping Procedure) A CSNH server follows the following algorithm in handling a request containing a CSname. If the server does not provide pointers to contexts in other servers as part of its name space, it may interpret the name in any way it chooses. Otherwise, the server begins by looking at the name itself, not the operation code. Since this request may have been directed to another server (to which it will eventually be forwarded by this algorithm), the operation code is irrelevant at this point. Names are ordinarily interpreted left-to-right, if the server implements hierarchical naming, though this is not required. The server initializes the variable @t[CurrentContext] to the context id specified in the request. As each component of the name is parsed, it is looked up in the current context. If the name specifies a context, the variable @t[CurrentContext] is updated. If the new context is implemented by some other server, the name index field in the request message is updated to point to the first character of the name not yet parsed, the context id field is set to the value of @t[CurrentContext], and the request is forwarded to the server that implements the context. @Subsection(Object Descriptions) One important operation provided on objects is a query operation to get a description of the object, where the description is a list of properties or attributes of the object. Since the type of the object need not be specified by its name or known to the client, a query operation returns a description record with the first field being a tag field specifying the format of the record, similar to the technique used with request messages. The tag field also allows the application to check that the object is of the type it might be expecting. An example description is shown in Figure 3. @PressPicture( file="example.fig", height="2.6 inches" ) @Center(@b[Figure 3:] Typical Object Description Record) Some of the fields of a description record are typically names of other system objects, such as name of the owner. Thus, a user-level description of an object can entail query operations not only on this object but also on objects mentioned in the description record for the original object. It is also important in many cases to be able to modify some fields of an object's description, for example, the access control bits associated with a file. The protocol provides a uniform modification operation, which takes a description record of the proper type, and ``overwrites'' the original description. Servers are free to ignore changes to any fields which it makes no sense to change in this way. The query and modification operations manipulate descriptions of individual objects. We introduce the concept of context directories for accessing descriptions of some or all of the objects in a context. @Subsection(Context Directories) A @i[context directory] is logically a file consisting of a sequence of description records, one for each object in the associated context. A client process can open and read a context directory in the same way it opens a file. The description records returned are identical to those returned if the client had instead invoked a query on each object in the context. Writing a description record has the same semantics as invoking the modification operation on the corresponding object. The directory allows the client to access each object description without knowing the name of each object in the context. It also provides efficient access for the client and the server when the context contains many objects of interest to the client. A server need not store information about objects in the same format as it is presented to the client in the context directories. Instead, server data structures should be organized to maximize server performance on critical operations with context directory entries dynamically fabricated on demand. For example, a file server may store file names separate from their descriptions with an association maintained by internal indices, such as the ``i-node numbers'' in Unix, but return both the name and the description in response to a query operation or context directory read. Of course, the cost of dynamically fabricating these records must be considered as part of designing the server. An alternative to this approach would be to provide an operation that enumerates (or lists) the names of objects in a context. The client would use the list of names in conjunction with the object query operation to simulate the reading of a context directory. We argue that our approach is preferable because with an increasing diversity of objects in our distributed system, even the listing of names of objects in a context requires some indication of the type of each object. Thus, a straight enumeration of names is rarely sufficient and requires an additional operation for each object at considerable cost over the context directory approach. We also view our approach as more consistent with the underlying model in which names are attributes in object descriptions. The cost of our approach is the collation and transmission of information that may not be required in all cases. @comment[Do we want to say the following at all? Should perhaps be under future work. --TPM] Consequently, we have been considering extensions to context directories such as pattern matching, which would cause the server to only include objects that match the given pattern in the returned context directory. @subsection(Standard Request Types) Besides the description query and modify operations just mentioned, three standard operations and two optional ones are specified as part of the name-handling protocol. As explained above, there is no limit to the number of request message types that may contain CSnames. There is a standard operation to map a CSname that specifies a context into a @i[(server-pid, context-id)] pair, which is returned in the reply message. There are also standard operations to perform an inverse mapping from a @i[(server-pid, context-id)] pair to a CSname, or from a @i[(server-pid, object-instance-id)] pair to a CSname. There are also operations to add and delete names for an existing context from another existing context. These are optional, and are ordinarily implemented only in context prefix servers (described below). @Subsection(Context Prefixes for CSnames) Many servers (particularly file servers) implement a hierarchically structured space of names. Some others may implement arbitrary directed graphs, but we will speak in terms of trees here. A flat name space may be considered as a degenerate tree in which all nodes are sons of the root. Thus, we may view the V-System name space as a forest, where each tree is associated with a server, as illustrated in Figure 4. The forwarding conventions in the naming protocol allow any server to include a pointer to a context on another server as part of its name space (curved arrow in the figure), but in practice, we do not expect enough such pointers to exist at any one time to unify the forest into a single graph. Therefore, V makes available standard @i[context prefix servers], which provide each user with locally defined character string names for contexts on servers of interest. The context prefix server is a CSNH server that allows users to add and delete names for contexts in other servers, using the optional operation codes mentioned above. A context prefix is simply the part of the CSname that is parsed by the context server to determine where to forward the request. The syntax is: any CSname starting with `@t([)', with the prefix terminated by a closing `@t(])'. @PressPicture(file="smalltree.fig", height = "3.2 inches" ) @Center(@b[Figure 4:] The V Naming Forest) The standard V run-time routines check for such prefixes and route any CSname request containing one to the context server in its default context. This procedure is described more fully in the next section.