Name Servicies

13.4 Case study: The Global Name Service

 Global Name Service (GNS)
A Global Name Service (GNS) was designed and implemented by Lampson and
colleagues at the DEC Systems Research Center [Lampson 1986] to provide facilities for
resource location, mail addressing and authentication. The design goals of the GNS have
already been listed at the end of Section 13.1; they reflect the fact that a name service
for use in an internetwork must support a naming database that may extend to include
the names of millions of computers and (eventually) email addresses for billions of users.
The designers of the GNS also recognized that the naming database is likely
to have a long lifetime and that it must continue to operate effectively while
it grows from small to large scale and while the network on which it is based
evolves. The structure of the name space may change during that time to
reflect changes in organizational structures. The service should
accommodate changes in the names of the individuals, organizations and
groups that it holds, and changes in the naming structure such as those that
occur when one company is taken over by another. In this description,
we focus on those features of the design that enable it to accommodate
such changes.
The GNS manages a naming database that is composed of a tree of
directories holding names and values. Directories are named by multi-part
pathnames referred to a root, or relative to a working directory, much like
file names in a UNIX file system. Each directory is also assigned an integer,
which serves as a unique directory identifier (DI). In this section, we use
names in italics when referring to the DI of a directory, so that EC is the
identifier of the EC directory. A directory contains a list of names and
references. The values stored at the leaves of the directory tree are
organized into value trees, so that the attributes associated with names can
be structured values.
Names in the GNS have two parts: <directory name, value name>. The first
part identifies a directory; the second refers to a value tree, or some portion
of a value tree. For example, see Figure 13.7, in which the DIs are illustrated
as small integers (although they are actually chosen from a range of integers
to ensure uniqueness). The attributes of a user Peter.Smith in the directory
QMUL would be stored in the value tree named <EC/UK/AC/QMUL,
Peter.Smith>. The value tree includes a password, which can be referenced
as <EC/UK/AC/QMUL, Peter.Smith/password>, and several mail addresses,
each of which would be listed in the value tree as a single node with the
name <EC/UK/AC/QMUL, Peter.Smith/mailboxes>.
• The directory tree is partitioned and stored in many servers, with
each partition replicated in several servers. The consistency of the
tree is maintained in the face of two or more concurrent updates –
for example, two users may simultaneously attempt to create entries
with the same name, and only one should succeed. Replicated
directories present a second consistency problem; this is addressed
by an asynchronous update distribution algorithm that ensures
eventual consistency, but with no guarantee that all copies are always
current.
GNS directory tree and value tree for user
Peter. Smith
Accommodating change
We now turn to the aspects of the design that are concerned with
accommodating growth and change in the structure of the naming database.
At the level of clients and administrators, growth is accommodated through
extension of the directory tree in the usual manner. But we may wish to
integrate the naming trees of two previously separate GNS services. For
example, how could we integrate the database rooted at the EC directory
shown in Figure 13.7 with another database for NORTH AMERICA? shows a
new root, WORLD, introduced above the existing roots of the two trees to be
merged. This is a straightforward technique, but how does it affect clients
that continue to use names that are referred to what was ‘the root’ before
integration took place? For example, </UK/AC/QMUL, Peter.Smith> is a name
used by clients before integration. It is an absolute name (since it begins with
the symbol for the root, ‘/’), but the root it refers to is EC, not WORLD. EC
and NORTH AMERICA are working roots – initial contexts against which
names beginning with the root ‘/’ are to be looked up.
 Restructuring the directory
• The existence of unique directory identifiers can be used to solve this problem.
The working root for each program must be identified as part of its execution
environment (much as is done for a program’s working directory). When a
client in the European Community uses a name of the form </UK/AC/QMUL,
Peter.Smith>, its local user agent, which is aware of the working root, prefixes
the directory identifier EC (#599), thus producing the name
<#599/UK/AC/QMUL, Peter.Smith>. The user agent passes this derived name in
the lookup request to a GNS server. The user agent may deal similarly with
relative names referred to working directories. Clients that are aware of the
new configuration may also supply absolute names to the GNS server, which
are referred to the conceptual super-root directory containing all directory
identifiers – for example, <WORLD/EC/UK/AC/QMUL, Peter.Smith> – but the
design cannot assume that all clients will be updated to take account of such a
change.
The technique described above solves the logical problem, allowing users and client
programs to continue to use names that are defined relative to an old root even
when a new real root is inserted, but it leaves an implementation problem: in a
distributed naming database that may contain millions of directories, how can the
GNS service locate a directory given only its identifier, such as #599? The solution
adopted by the GNS is to list those directories that are used as working roots, such
as EC, in a table of ‘well-known directories’ held in the current real root directory of
the naming database. Whenever the real root of the naming database changes, as
it does in Figure 13.8, all GNS servers are informed of the new location of the real
root. They can then interpret names of the form WORLD/EC/UK/AC/QMUL
(referred to the real root) in the usual way, and they can interpret names of the
form #599/UK/AC/QMUL by using the table of ‘well-known directories’ to translate
them to full pathnames beginning at the real root.
• The GNS also supports the restructuring of the database to
accommodate organizational change. Suppose that the United States
becomes part of the European Community . shows the new directory
tree. But if the US subtree is simply moved to the EC directory, names
beginning WORLD/NORTH AMERICA/US will no longer work. The
solution adopted by the GNS is to insert a ‘symbolic link’ in place of
the original US entry (shown in bold in Figure 13.9). The GNS
directory lookup procedure interprets the link as a redirection to the
US directory in its new location.
Discussion of the GNS
The GNS is descended from Grapevine [Birrell et al. 1982] and
Clearinghouse [Oppen and Dalal 1983], two successful naming systems
developed primarily for the purposes of mail delivery by the Xerox
Corporation. The GNS successfully addresses needs for scalability and
reconfigurability, but the solution adopted for merging and moving
directory trees results in a requirement for a database (the table of
well-known directories) that must be replicated at every node. In a
largescale network, reconfigurations may occur at any level, and this
table could grow to a large size, conflicting with the scalability goal.