



	   ################################################
	   #                                              #
	   # ##   ## ###### ####### ##    ## ## ##     ## #
	   # ##   ## ##  ## ##      ###   ## ##  ##   ##  #
	   # ##   ## ##     ##      ####  ## ##   ## ##   #
	   # ##   ## ###### ######  ## ## ## ##    ###    #
	   # ##   ##     ## ##      ##  #### ##   ## ##   #
	   # ##   ## ##  ## ##      ##   ### ##  ##   ##  #
	   # ####### ###### ####### ##    ## ## ##     ## #
	   #                                              #
	   ################################################






 
 
 
	 The following paper was originally presented at the

		     Third Annual Tcl/Tk Workshop
		 Toronto, Ontario, Canada, July 1995

	   sponsored by Unisys, Inc. and USENIX Association



	    It was published by USENIX Association in the
		  1995 Tcl/Tk Workshop Proceedings.
 
 
 
 
        For more information about USENIX Association contact:
 
                   1. Phone:    510 528-8649
                   2. FAX:      510 548-5738
                   3. Email:    office@usenix.org
                   4. WWW URL:  http://www.usenix.org
 
 
 
 
 
^L
Tcl-DP Name Server

Peter T. Liu
Brian Smith
Lawrence Rowe
Computer Science Division - EECS
University of California
Berkeley, CA 94720-1776
(pliu@CS.Berkeley.EDU)

Abstract

This paper describes a general purpose name server for Tcl-DP. This name 
server 
maintains host addresses and port numbers of services running in a distributed 
en-
vironment and allows clients to query about them. It starts services on demand 
so 
services are guaranteed to be available, and it provides a simple 
authentication 
protocol for better security. The Tcl-DP name server is also designed to be 
fault-
tolerant. Multiple backup servers can be started on different hosts, and a 
failover 
occurs when the main server goes down. In addition, the name server provides 
mechanisms to interface with external modules for extending its functionality.

1.  Introduction

Tcl-DP [Smith93] is a distributed programming extension to Tcl [Ousterhout94]. 
It provides TCP and IP connection management, blocking and nonblocking re-
mote procedure call (RPC), and a simple distributed object system. It is a 
high-
level scripting language for building distributed client-server applications 
such as 
the Berkeley Continuous Media Toolkit (CMT) [Rowe94] and the Berkeley Dis-
tributed Video-On-Demand System (BVODS) [Federighi94, Rowe95].

Despite its convenience, Tcl-DP has several shortcomings. First, the system 
does 
not provide service management to client-server applications. Tcl-DP clients 
must 
use explicit host addresses and port numbers to locate services available to 
them, 
unless a customized service registry is implemented. This approach leads to 
sys-
tem management and reliability problems in a large and rapidly changing 
distrib-
uted system. Second, Tcl-DP does not provide automatic failure recovery in the 
event of a server crash or a broken network connection. Services offered by a 
server process will be unavailable if the process crashes. Therefore, there is 
no 
guarantee of service availability in Tcl-DP applications. Finally, Tcl-DP 
provides 
limited security. The current release (Tcl-DP v3.2) allows applications to 
restrict 
commands that can be called remotely and limit connections to clients running 
on 
specific hosts. However, it does not prevent malicious programs from taking 
over 
as legitimate services nor does it support finer granularity access control. 
An au-
thentication protocol is needed to provide better security.

The Tcl-DP name server described in this paper is designed to address these 
prob-
lems. It solves the explicit host address and port number and availability 
issues, 
and it provides a simple authentication protocol for applications to increase 
secu-
rity. In addition, it is fault tolerant and provides mechanisms for extending 
its 
functionality. The remainder of this paper is organized as follow. Section 2 
de-
scribes the functionality of the Tcl-DP name server and other name services in 
ex-
istence. Section 3 presents an overview of the name server design and 
describes 
how it fits in a real application. Section 4 discusses the implementation of 
the sys-
tem. And, section 5 describes the current status of the system, the 
experiences with 
the current implementation and possible future extensions.

2.  Name Server Functionality

This section describes the functionality of the Tcl-DP name server. First, the 
name 
server must maintain information about services and respond to client queries 
about them. Second, it must start services on demand so they are guaranteed to 
be 
available at all times. Third, an authentication protocol is needed to protect 
the 
system from malicious users. Fourth, the name server itself must be 
fault-tolerant 
which means it must recover successfully if the name server itself or the host 
it 
runs on crashes. Finally, the name server should provide mechanisms to 
interface 
with external modules without interfering with its normal operations. These 
issues 
are discussed in this section followed by descriptions of other name servers. 

The name server must maintain information about available services running on 
the system, such as the service names and the host addresses and port numbers 
needed to access them. It should provide an interface to query such 
information 
using unique name associated with each service. Consequently, the name server 
must enforce a naming convention on services. The Tcl-DP name server uses a hi-
erarchical namespace, similar to other name servers and the structure of a 
UNIX 
file system [Ritchie74]. Section 3 will discuss the naming convention in more 
de-
tail. Every server that offers a service under the name server's management 
must 
inform the name server of its existence at start-up time and its demise when 
it ter-
minates. When a client needs to connect to a service, it queries the name 
server for 
the host and port number on which the service is running using the service 
name 
as the key. The only information the client needs to know in advance is the 
host 
address and port number of the name server plus the names of the services to 
which it wants to connect. As new services are added to a distributed system, 
only 
the service names need to be advertised to the clients. Also, services can be 
freely 
moved around on the local network without affecting the clients. 

In a distributed environment, services must be highly available because the 
liveli-
hood of the clients may depend on them. In certain cases, services must run 24 
hours a day and 7 days a week. The name server can provide the illusion of 
24-by-
7 service by restarting the service after it fails. In essence, the name 
server acts as 
a service launcher. It assumes that services are either stateless or can 
recover from 
disk. If a server process is detected by a client to have crashed, the client 
can ask 
the name server to restart the server process. If the server cannot be 
restarted on a 
particular machine because that machine has crashed, the client can request 
con-
nection to the same service running on a different machine. This assumes that 
mul-
tiple processes offering the same service are distributed across the local 
network. 
With this capability, failure recovery in case of server crash or a stale 
network con-
nection is simple. Therefore, unless the network is partitioned or the name 
server 
goes down, services are guaranteed to be available at all times. We call this 
feature 
auto-starting.

As a dual feature to the auto-starting capability, the name server can also 
terminate 
services on demand. One can think of situations in which this capability is re-
quired. For example, a service can get into a bad state in which it must be 
killed 
before it can be restarted. The name server is the perfect agent to carry out 
this task 
because it maintains information such as the process identifier and location 
of the 
server that provides the service. 

Since the name server is capable of launching and terminating services, it 
should 
also have the ability to authenticate such requests to prevent malicious 
programs 
from taking over as legitimate services. Therefore, an authentication protocol 
is 
needed between the name server and the services it manages. A similar protocol 
is needed between clients and servers in case they do not trust one another. 
Effec-
tively, the name server is acting as a security checkpoint in the distributed 
system. 
A client can request the name server to check the server on its behalf. The 
name 
server can also set things up between the client and server so they can 
authenticate 
each other. However, it is still the responsibility of the application to 
restrict com-
mands and connections to clients.

The Tcl-DP name server uses a ticket-based scheme for authentication. When a 
service is auto-started, the name server issues a random ticket to the server 
pro-
cess. The server process must present this ticket when it reports to the name 
server. 
Servers and clients can also authenticate one another using tickets issued by 
the 
name server. This approach is similar to the one used by Kerberos [Steiner88].

To implement the functions mentioned in the preceding paragraphs, the name 
server must itself be highly available and fault-tolerant. One way to 
implement a 
fault-tolerant name server is to use multiple servers that fail independently. 
The 
state of a service provided by the name server is replicated and distributed 
among 
these servers, and updates are coordinated so that when a subset of the 
servers fail, 
the service remains available. There are generally two approaches to this 
fault-tol-
erant architecture. One approach is to replicate the service state in all 
servers and 
to present client requests, in the same order, to all servers. This approach 
is com-
monly called active replication or the state-machine approach [Schneider90]. 
The 
other approach is to designate one server as the primary and all other servers 
as 
backups. This approach is called the primary-backup or primary-copy approach 
[Alsberg76]. Clients send requests only to the primary. If the primary fails, 
a 
failover occurs and one of the backups takes over as the new primary. The 
state-
machine approach is more costly because it requires all client requests to be 
pre-
sented to each server, and each server must process the requests in the same 
rela-
tive order. The advantage is that no requests are lost when a subset of the 
servers 
fail. The primary-backup approach, on the other hand, is simpler and less 
costly 
but suffers from lost requests when failure occurs. The Tcl-DP name server em-
ploys the second approach because it is simple and we assume that most applica-
tions can tolerate occasional lost requests.

The name server should also provide mechanisms for dynamically interfacing 
with external modules without interrupting its own operations. The idea is to 
have 
the name server auto-load these modules into its address space at run time and 
al-
low them direct access to its data. For example, a directory service for a 
confer-
encing application can be used to keep track of the users currently logged 
onto the 
different conferencing servers running on the network. A user can lookup a 
person 
from the directory service and ask for the location of his/her conferencing 
server. 
Without the external-module interface, the user will have to first query the 
name 
server for the location of the directory service and then ask the directory 
service 
for the location of the person he/she wants to talk to. The directory service 
will in 
turn ask the name server for the location of the desired conferencing server. 
With 
the external-module interface, since the directory service runs as part of the 
name 
server and has direct access to its data, the user only has to contact the 
name server 
to get the desired information, thus eliminating two levels of indirection. 
There-
fore, the interface mechanism can significantly reduce the response time of 
certain 
applications. The purpose of these external modules should be to extend the 
name 
server functionality or provide higher-level abstractions on top of the one 
pro-
vided by the name server. 

Considerable interest exists to develop an international standard for name 
services 
or directory services due to the diverse requirements raised by the 
developments 
in future communication networks. The requirements include integration of new 
services and sharing of network resources by various communication services. 
Possible applications of the directory service can be found in Open System 
Inter-
connection (OSI), internetworking, broadband networks and mobile communica-
tion. For example, in future broadband networks, name services will be used to 
manage addressing information of all communication entities such as telephones 
and computer terminals, and Help-Desk information such as information about 
hotels, hospitals, and airlines. In future mobile networks, the need for a 
name ser-
vice is even more pronounced because the current location of all subscribers 
as 
well as information about networks and terminals have to be maintained. In the 
following paragraphs, several well-known name services including the Domain 
Name System (DNS), DCE Directory Service, Grapevine and others, will be de-
scribed, followed by an overview of the CCITT X.500 Directory System standard.

The most widely used name servers are the ones that comprise the Domain Name 
System's (DNS) client-server mechanism [Albitz92]. DNS is a distributed data-
base that holds the name-to-address mapping for every host connected to the In-
ternet. It is organized in a tree structure similar to a file directory as 
shown in 
Figure 1. The DNS namespace is partitioned into domains and subdomains. In 
DNS, the name of the root is the null label (""). A typical name in the DNS 
data-
base is cs.berkeley.edu. Figure 1 shows how this name can be stored in the DNS 
database. A DNS name server contains information about a segment of the data-
base. A client that accesses the name server, called a resolver, issues 
queries by 
calling a library routine. Given a query about any domain name, the root name 
servers can provide the names and addresses for the top-level domain in which 
the 
name is located. Top-level domain name servers can provide the list of name 
serv-
ers responsible for the second-level domain. The process continues until the 
entire 
query is resolved. For example, to resolve the name cs.berkeley.edu, the 
resolver 
first sends a query to the root server for the location of the edu server. The 
edu 
server will then be used to retrieve information about the location of the 
berkeley 
server. The process continues until the actual location is found. In this 
case, the 
resolver will be given the IP address of the CS Division machine which is 
128.32.34.35. To speed up the process, name servers usually maintain more than 
one level of information, and they cache complete or partial results of 
queries. 
Also, name servers can be replicated to increase availability and throughput. 
Two 
types of name servers are used: primary masters and secondary masters. A pri-
mary master loads data from files on the host on which it runs. A secondary 
master 
loads data by periodically querying a primary master.

Another well-known name server is the DCE Directory Service which is com-
prised of three components: 1) Cell Directory Service (CDS), 2) Global 
Directory 
Service (GDS) and 3) Global Directory Agent (GDA) [OSF92]. CDS is a local di-
rectory service that stores names and attributes of resources located in a DCE 
cell. 
It is optimized for local access and replicated for reliability. GDS is a 
distributed, 
replicated directory service based on the CCITT X.500 international standard 
dis-
cussed below. It is used when looking up a name outside of the local DCE cell. 
GDS and DNS together can act as the high-level connectors that allows indepen-
dent cells to interact with one another. GDS also works with other X.500 imple-
mentation which means it can participate in the worldwide X.500 directory 
service. GDA is the intermediary between a cell's CDS and the rest of the 
world. 
It takes a name that cannot be found in its local cell and queries foreign 
cells to 
find it using GDS or DNS, depending on where the foreign cell is registered. 
Fig-
ure 2 shows the relationship between the different components of the DCE direc-
tory system. The DCE namespace is also hierarchical. It supports names used by 
DNS and typed names using the X.500 syntax discussed below.

Grapevine is a distributed database running at Xerox Palo Alto Research Center 
that has been used to provide name service lookup for the Xerox Remote Proce-
dure Call (RPC) package [Birrell82, Birrell84]. It is highly reliable and can 
be 
configured to replicate data on different servers. There are two types of 
entries in 
Grapevine: individuals and groups. As far as the RPC package is concerned, for 
each individual entry there is a connect-site, which is a network address, and 
for 
each group there is a member-list which is a list of individual and group 
entries. 
Using these two types of entries, one can create complex hierarchies of 
services 
similar to the domain hierarchy in DNS. To avoid long delays during client re-
quests, each client operation is performed at a single site and the result is 
later 
propagated to other name servers in the background. The disadvantage of this 
tac-
tic is that inconsistency may occasionally occur. A more recent system design, 
such as Global Name Service (GNS), restricts this nondeterminism by periodi-
cally sweeping all replicas to ensure all updates are properly propagated 
[Lamp-
son86].

Other name servers are provided by distributed programming systems (e.g. ISIS, 
ASN.1, etc.). The Distributed Resource Manager provided by ISIS manages the 
execution of remote jobs on a local network [ISIS92]. It includes "recycling" 
idle 
workstations for remote use and managing a pool of "compute servers." It can 
also 
be used to manage a reliable replicated service by ensuring that some desired 
num-
ber of copies of the service are always running, despite machine failures. The 
Re-
source Manager supports a subroutine interface for looking up the address of a 
server and auto-starting server if necessary.

The CCITT X.500 Directory System provides a framework for the development 
of a worldwide standard for directory services [Sykas91]. The information con-
tained in the Directory System is called the Directory Information Base (DIB). 
It 
is organized in a tree, the Directory Information Tree (DIT), similar to the 
DNS 
database. The information about each entity is contained in an entry. Each 
entry 
consists of a set of attributes. Examples of attributes are country name, 
street ad-
dress, title, postal address, telephone number, ISDN address and OSI address. 
Each entry is identified by its unique Distinguished Name (DN). An example of 
a 
DN is "/.../C=US/O=Berkeley". The prefix "/..." is the name of the global 
root. C 
stands for country, and O stands for Organization. Aliases can also be created 
to 
reference other entries. The user interacts with a Directory User Agent (DUA) 
which is served by a Directory System Agent. Figure 3 depicts the Directory 
Sys-
tem as a whole. The Directory may also be composed of a centralized DSA rather 
than distributed ones as shown in Figure 3. Each DSA holds a fragment of the 
DIB 
which comprises one or more naming contexts. A naming context is a partial sub-
tree of the DIT. A DSA may use information stored in its local database or 
interact 
with other DSAs to carry out requests. Three modes of DSA interaction are de-
fined: chaining, multicasting and referral. A mixture of the three is also 
possible. 
Chaining allows one DSA to pass on a remote operation to another DSA when the 
former has specific knowledge about naming contexts held by the latter. Multi-
casting allows a DSA to pass on an identical remote operation in parallel or 
se-
quentially to one or more DSAs. Referral allows a reference to another DSA to 
be 
returned to the DUA or DSA. 

The Tcl-DP name server discussed in this paper is designed to be a local name 
ser-
vice with backups similar to the CDS in DCE. It is not designed to be a global 
di-
rectory service like DNS and DCE. It only maintains information about 
processes 
running on machines distributed in a local domain. However, certain ideas used 
in 
the design of the name server are similar to other directory services (i.e. 
the nam-
ing convention). Also, the Tcl-DP name server can be extended using the 
external-
module interface to support higher level abstractions found in directory 
services.

3.  Name Server Design

This section describes the naming scheme used by the Tcl-DP name server and 
how it can be used in a distributed application such as the Berkeley 
Distributed 
Video-On-Demand System (BVODS) [Rowe95]. 

The Tcl-DP name server is designed to be general-purpose and flexible. We want 
different applications to share the name server and use it for all types of 
services 
they provide. We also want new services to be easy to add without affecting 
other 
applications. The Tcl-DP name server achieves this flexibility and generality 
by 
allowing applications to organize their services in a hierarchical manner as 
if they 
are files in a directory. In addition, aliases can be created for services 
shared by 
different applications.

Before we discuss the advantages of the naming scheme, an example of how the 
name server can be used in a real distributed system is given. Figure 4 shows 
an 
example of using the name server to manage BVODS. Boxes represent machines, 
ovals represent processes, and edges represent communication paths. The labels 
in the process ovals are service names. The labels next to the process ovals 
are the 
service names registered with the name server. As can be seen from the figure, 
all 
service names have the prefix "/BVODS/" indicating that they are BVODS ser-
vices. Also, communication to the name server is initiated through client 
library 
routines that are wrappers around the actual RPC calls. 

BVODS is a distributed video-on-demand system that is suitable for large video 
libraries. Users search for videos through a video browser. The browser 
queries 
information about a video by connecting to a remote query server (QS) which is-
sues commands to a POSTGRES database that contains indexes to the video li-
brary [Stonebraker91]. The browser locates the QS by first issuing a lookup 
query 
to the name server using "/BVODS/QS" as the key. If the QS is running, the 
name 
server will return the host address and the port number of the server which 
the 
browser can use to connect to the QS. If the QS is not running, the name 
server 
will start the QS server on behalf of the browser. The authentication ticket, 
which 
is a random number generated by the name server, is passed on to the service. 
Once the QS is up and running, it will register its existence with the name 
server 
using the authentication ticket as a proof of legitimacy. When the user 
identifies a 
movie he or she wants to view, the browser locates the BVODS Manager (VMGR) 
using the service name  "/BVODS/VMGR" and connects to it. It then asks the 
VMGR to determine if the movie is available on one of the local video file 
servers. 
If so, the browser asks the VMGR for the machine and path names for all compo-
nents of the video and launches the CMPlayer to play them. The CMPlayer pro-
cess opens a video window and contacts the CMSource processes, on each of the 
machines participating in the playback [Rowe92]. The CMSources can be located 
through the name server using the name "/BVODS/VFS1/CMS" and "/BVODS/
VFS2/CMS" which, in reality, are aliases for the services "/CMS/Host1" and "/
CMS/Host2". 

Also notice that all processes communicate with the name server running on the 
Primary machine. If the primary name server goes down, the name server running 
on the Backup machine will take over. Subsequent queries will be directed to 
the 
backup server. This example illustrates the backup capability of the Tcl-DP 
name 
server. The connection maintained between the two servers is used for crash de-
tection and update propagation.

As seen from the BVODS example, the main advantage of using this naming 
scheme is that it avoids naming conflicts. As long as an application can 
specify a 
unique name, such as BVODS, services provided by the application can be as-
signed globally unique names.

Another advantage of using this service naming scheme is that a client can 
easily 
find available services under BVODS by having the name server do a glob-style 
expansion on the pattern "/BVODS/*". One can think of situations in which this 
feature can be very useful. For example, we can have services named for the ma-
chines on which they run (i.e., "/Service/roger-rabbit", "/Service/zonker", 
etc.) A 
client first queries for the name of all services running on different 
machines by 
issuing a list services command on the pattern "/Service/*", and picking the 
one 
to which it wants to connect. If a particular service is overloaded, it can 
pick an-
other one from the list and switch to it. This capability allows a simple 
client ap-
proach to load-balancing. One can also think of a situation in which this 
capability 
can be used as a backup scheme. If a service crashes on a machine and cannot 
be 
restarted, a client can pick a server running on a different machine. In 
addition, 
new services can be easily added without having to make major changes. 

Having the Tcl-DP name server launch servers has two advantages. First, the 
ser-
vice is guaranteed to be available as long as the machines are up. Second, the 
name 
server can issue authentication tickets to authenticate servers.

In summary, the Tcl-DP name server uses a hierarchical naming scheme that can 
be used to organize and manage their services as well as providing 
fault-tolerance 
and simple load-balancing. The fault-tolerant design of the name server makes 
it 
highly reliable.

4.  Name Server Implementation

This section describes the implementation of the Tcl-DP name server. The name 
server is written in Tcl using the DP extension for all interprocess 
communication. 
Several new Tcl commands have also been added to the dpsh to support running 
the name server as a daemon and generating random authentication tickets. The 
Tk windowing toolkit for building Motif-style user interfaces is used to 
implement 
the name server monitor, shown in Figure 5, which displays the current status 
of 
registered services. Users can restrict the services displayed by specifying a 
glob 
pattern, such as "/vods/*" in the Service entry box. The monitor also allows 
users 
to add, alias, edit, delete, launch, and reset services. 

The Tcl-DP name server is composed of a small set of commands that clients in-
voke through the RPC facility of Tcl-DP. The client library package provides a 
wrapper around the actually RPCs which hides the remote nature of the name 
server. The commands are grouped into four categories shown in Table 1. The 
first 
category includes the client routines. These routines include commands for 
listing, 
locating and launching services, plus routines for inquiring and resetting 
service 
status. By intermixing the different commands, a client can implement 
different 
behaviors. For example, a client can first list all services and pick the ones 
to 
which it wishes to connect. It can then get the host address and port number 
on 
which the service is running and connect to it. If the service crashes, the 
client can 
ask the name server to reset the server and launch it again. The following 
code seg-
ment illustrates this case:



set srvc [lindex [ns_ListServices *] 0]								# get a list of all the 
services and pick the first one

set hp [ns_FindServices $srvc]								# get the host port

if [catch "dp_MakeRPCClient $hp"] {								# if the service has 
crashed

	ns_LaunchServices $srvc							# ask the name 
server to launch it again

	# wait for the service to come up

}

The second category is composed of routines for the service interface to the 
name 
server which are used by a server to advertise services. For example, the 
following 
Tcl code has to be executed by a server when it starts up:

ns_AdvertiseService /cms/bugs-bunny bugs-bunny 1234 $ticket

"/cms/bugs-bunny" is the service name. Bugs-bunny is the host address of the 
ser-
vice, and 1234 is the port number. $ticket is the authentication ticket issued 
by the 
name server. 

The third category is composed of routines used to administer the name server 
in-
cluding routines to add, delete, alias and edit services. These commands are 
used 
to implement the name server monitor. 

Lastly, there is a set of commands for authentication between the name server 
and 
its servers, and between a server and its clients. The following code segment 
illus-
trates its usage by a client application:

set ticketPair [ns_AuthenticateService /cms/bugs-bunny] 

set myTicket [lindex $ticketPair 0]	 							# get client's ticket

set srvc	Ticket [lindex $ticketPair 1]							# get service's ticket



if {$srvcTicket!= [dp_RPC $srvc_fd ns_Authenticate $myTicket]} {

	error "Service authentication failed!"

}

The remainder of this section describes the implementation of the following 
func-
tions: 1) auto-starting services, 2) using authentication, 3) configuring a 
reliable 
name server, and 4) extending name server functionality. When an application 
needs to connect to a service, it will ask the name server for the host 
address and 
port number of the server. If a server is not currently running for an 
auto-start ser-
vice, the client can request the server to be started either using rsh or 
inetd.

Using rsh to launch a server has the disadvantage that when the name server 
crashes, the server may go down as well because rsh maintains a connection be-
tween the process and the process it starts. Inetd avoids this problem by not 
maintaining a connection. A server is launched using inetd as follow (see 
Figure 
6): 

1.	Client process requests the name server to launch a service.

2.	The name server connects to the inet daemon (inetd) running on the host on 
which the server is to be started.

3.	Inetd executes the launch daemon (launchd) which opens a connection 
with the name server for launchd, and exits.

4.	The name server requests launchd to start the server. Launchd is a Tcl 
script that executes the server on behalf of the name server. It also checks 
whether a server is legal so a malicious user cannot request a dangerous pro-
gram such as rm. The success or failure of the launching procedure is 
reported back to the name server.

5.	Once the service is started, launchd exits which closes the connection with 
the name server. 

6.	The new server process connects to the name server process and register its 
host name and port number to the name server. Note that the server process 
gets the name from its command line used to start it. The service name is 
appended to the command line when the name server starts up the server. 

7.	The client gets the host address and port number of the server process from 
the name server

8.	The client connects to the server process.

Launching servers using rsh is similar except that inetd and launchd are by-
passed. 

Every auto-started servers shares a pair of random tickets with the name 
server. 
The server can retrieve these tickets from stdin which is written by the name 
server. The tickets are used to authenticate the server to the name server and 
vice 
versa. For example, when a server registers itself to the name server, it will 
send 
its half of the ticket pair to the name server. The name server then verifies 
the ticket 
with its internally maintained table of tickets. If the ticket is not valid, 
the name 
server will ignore the server

A client application can also ask the name server to authenticate a particular 
server 
by using the technique described above. If a server is authentic, the name 
server 
will generate a new pair of tickets to be shared between the application and 
the 
server. The server and the application can then use the tickets to 
authenticate each 
other. Figure 7 is a diagram that depicts the name server security scheme:

1.	The client requests the name server to authenticate a server.

2.	The name server and the service server exchanges tickets [Tn,Ts]. If the 
server has the right ticket, a new pair of tickets are generated by the name 
server [T1,T2].

3.	The name server sends the new ticket pair to the server and the client.

4.	The server and the client can then use the tickets to authenticate each 
other.

Currently, tickets are generated by the system clock, and they are not 
encrypted. 
This authentication strategy is similar to the one employed by Kerberos 
[Steiner88]. An authentication is done at the name server level because it is 
easy 
to implement and does not require changes to Tcl-DP. However, if Tcl-DP were 
modified to run on Kerberos, this feature would become obsolete.

The Tcl-DP name server can be configured to run in either stand-alone or 
backup 
mode. In stand-alone mode, the name server is a single point of failure that 
can 
bring down the entire system. In backup mode, a system administrator can 
specify 
a list of machines on which the name server should run. One machine is picked 
as 
the primary server, and the rest are backup servers. Also, each server has an 
im-
plicit server identification number (SID) that is inferred from the machine 
list. 
Each backup server maintains a private connection with the primary, forming a 
star configuration as shown in Figure 8. When the primary goes down, each 
backup server will detect it by noticing the bad connection. The backup server 
with the SID one greater that the primary's SID will then designate itself as 
the 
new primary and the others will re-form the star configuration around the new 
pri-
mary. In Figure 8, backup server one (B1) takes over as the primary server. 
Once 
the new primary takes over, it will try to restart the dead server. The 
bad-connec-
tion detection is implemented by setting the keepAlive flag using dp_socke-
tOption which requests the system to send periodic messages on a tcp socket. 
Should the connected party fail to respond to these messages, the connection 
is 
considered broken and will be closed automatically. The dp_atclose com-
mand, which allows a list of commands to be executed when connections are 
closed, is called to re-form the start configuration.

In backup mode, the primary server maintains consistency among the backup 
servers. Figure 9 shows the simple primary-backup protocol used by the Tcl-DP 
name server. The dotted arrows are the keepAlive messages mentioned above. The 
client sends an update command to the primary name server. The name server pro-
cesses the request and updates its state. It then sends an update-state 
request to the 
backup server. Without waiting for acknowledgment from the backup, the primary 
sends its response to the client. Each server also writes its state onto a 
local disk. 
The justification for writing to local disk is to avoid writing onto an 
NFS-mounted 
file system which can hang the server when it goes down. This scheme makes 
crash recovery almost instantaneous because the major source of delay is 
detect-
ing the bad connection. 

The external-module interface is currently implemented using the auto-loading 
feature of Tcl and the RPC command checking feature of DP. The routines from 
an external module must all have the same unique prefix that is known to the 
name 
server. When an RPC request is sent to the name server, the command check pro-
cedure will match the routine prefix with the ones known to the name server. 
If it 
matches and the routine does not exist, the name server will automatically 
source 
the module containing the routine. This approach prevents naming conflicts 
among different modules. However, it does not prevent a module from renaming 
procedures and corrupting data. A better approach is to create a separate Tcl 
inter-
preter for each external module with read-only access to name server data. 
Again, 
each module is identified by its unique prefix and the correct interpreter 
will be 
selected to interpret a RPC. We plan to modify the implementation of name 
server 
extension using this technique in a future release.

5.  Discussion

A prototype of the Tcl-DP name server has been implemented. The Berkeley Pla-
teau Multimedia Project has used it in the implementation of CMT and BVODS 
systems. The name server has been included in Tcl-DP release 3.3. 

The name server package is composed of approximately 3500 lines of Tcl code: 

(1)		1000 lines in the name server

(2)	700 lines in the client library 

(3)	1800 lines in the name server monitor and installation inter-
face. 

The most difficult part of the implementation was debugging the backup servers 
because each backup server runs as a daemon and there is no Tcl debugger that 
allows you to attach to a process and debug it. Testing the auto-start feature 
also 
turns out to be difficult because servers can fail to start and tools to 
monitor remote 
process do not exist. Despite the implementation difficulties, the experience 
with 
the name server so far has been positive. Its advantage is particular obvious 
in a 
demonstration environment in which things are unstable. 

Currently, we are considering whether to extend the name server to handle 
service 
load-balancing. As mentioned before, a client can query the name server for a 
list 
of servers that support particular service. However, it is up to the client to 
pick the 
server to which it wants to connect. It would be very useful for the client to 
have 
access to data such as the load of each service so it can make more 
intelligent de-
cisions. One way to implement this feature is to have each server periodically 
re-
port its load average to the name server in a format that clients can 
understand. Or, 
the name server can periodically monitor the load average of the machine on 
which the server is running. It remains to be investigated which approach is 
better. 
Another extension being considered is to use the backup servers as replicated 
serv-
ers giving the name server as a whole higher throughput. The idea is to direct 
all 
read-only requests to the backup servers and all updates to the primary 
server. The 
issues involved are how to distribute the requests evenly among the backup 
serv-
ers and what happens when a backup server crashes.

6.  References

[Smith93] B.C. Smith, L.A. Rowe, and S. Yen, "Tcl Distributed Programming," 
Proc. 1993 Tcl/Tk Workshop, Berkeley, CA, June 1993.

[Ousterhout94] J.K. Ousterhout, "Tcl and the Tk Toolkit," Addison-Wesley Pro-
fessional Computing Series, April 1994.

[Rowe94] L.A. Rowe, "Continuous Media Applications," Computer Science Di-
vision - EECS, University of California at Berkeley, November 
1992. Also available as ftp://mm-ftp.cs.berkeley.edu/pub/multime-
dia/papers/CMApps94.ps.Z. 

[Federighi94] C. Federighi and L.A. Rowe, "The Design and Implementation of 
the UCB Distributed Video On Demand System," Proc. of IS&T/
SPIE 1994 Int'l Symp. on Elec. Imaging: Science and Technology, 
San Jose, CA, February 1994. Also available as ftp://mm-ftp.cs.ber-
keley.edu/pub/multimedia/papers/VodsArch-SPIE94.ps.Z

[Rowe95] L.A. Rowe, et. al., "The Berkeley Distributed VOD System," Proc. 6th 
NEC Research Symposium on Multimedia Computing, Tokyo, Ja-
pan, June 1995.

[Ritchie74] D.M. Ritchie, and K. Thompson, "The UNIX Time-Sharing System," 
Communications of the ACM 17:7, July 1974.

[Stiner88] J.G. Steiner, C. Neuman, and J. I. Schiller, "Kerberos: An 
Authentica-
tion Service for Open Network Systems," USENIX Winter Confer-
ence, February 9-12 1988, Dallas, Texas.

[Schneider90] F.B. Schneider, "Implementing Fault-tolerant Services using the 
State Machine Approach: A Tutorial," ACM Computing Surveys 22, 
December 1990.

[Alsberg76] P.A. Alsberg, and J.D. Day, "A Principle for Resilient Sharing of 
Dis-
tributed Resources," Proceedings of the Second International Con-
ference on Software Engineering, 1990, San Francisco, CA, 562-
570.

[Albitz92] P. Albitz and C. Liu, "DNS and BIND," O'Reilly & Associate, Inc., 
Oc-
tober 1994.

[OSF92] Open Software Foundation, "Introduction to OSF DCE," Prentice Hall, 
Inc., 1994. 

[Birrell82] A.D. Birrell, R. Levin, R.M.Needham and M.D. Schroeder, "Grape-
vine: An Exercise in Distributed Computing," Communications of 
the ACM 25, pp 260-274.

[Birrell84] A.D. Birrell, and B.J. Nelson, "Implementing Remote Procedure 
Calls," Communications of the ACM Transaction on Compute Sys-
tems, Vol. 2, No.1, pp 39-59, February 1984.

[Lampson86] B.W. Lampson, "Designing a Global Name Service," Proc. 5th 
ACM Annual Symposium on Principles of Distributed Computing, 
Calgary, Canada.

[ISIS92] "The ISIS Distributed Toolkit Version 3.0 User Reference Manual," 
ISIS 
Distributed Systems, Inc. 1992.

[Sykas91] E.D. Sykas, and G.L. Lyberopoulos, "Overview of the CCITT X.500 
Recommendations series," Computer Communications Review, No-
vember 1991.

[Stonebraker91] M. Stonebraker and G. Kemnitz, "The POSTGRES Next-Gener-
ation Database Management System," Comm. of the ACM, Vol. 34, 
No. 10, October, 1991, pp.78-92.

[Rowe92] L.A. Rowe, and B.C. Smith, "A Continuous Media Play," Proc. 3rd Int. 
Workshop on Network and OS Support for Digital Audio and Video, 
San Diego CA, November 1992. Also available as ftp://mm-ftp.cs.-
berkeley.edu/pub/multimedia/papers/CMPlayer.ps.Z.


