\section{Implementation of {\kfdirectory}}
\label{sec-kfdirectory}

{\kfdirectory} is implemented by a set of HTTP servers acting as
directory servers, and a single HTML file at each server containing a
table of directory entries and (as will be described below) a
JavaScript program.  While every HTML file contains the same
JavaScript program, their directory entries may differ.  A directory
entry is a tuple containing a string (session name), a URL address
(initiator of the session), and optional fields for category,
password, and comments.  The category field is used to distinguish
between entries representing sessions and other directory servers.
Adding and removing an entry is performed by processes sending HTTP
Post messages to HTTP servers resulting in execution of appropriate
CGI scripts.

A {\em lookup operation} consists of loading an initial HTML page and
executing the embedded JavaScript program with the request as a
parameter.  This program analyzes the entries in its own page.  If no
match is found, a new URL is constructed and the browser is instructed
to load the new address.  The new URL contains the address of another
directory server augmented with state information containing a list of
hosts visited so far, and a list of hosts to visit next which is
included in the tag part of the new URL.  This state information
allows the implementation of different search strategies, e.g.,
breadth-first search to find sessions on nearby hosts first.  Our
implementation allows the search to be performed by a JavaScript
program without breaking the security restrictions imposed by Web
browsers.  Under the {\em tainting}~\cite{flan97} security model, a
JavaScript program is not allowed to inspect pages coming from another
site than itself.  Once the JavaScript program finds an entry matching
the request, the browser is instructed to follow the corresponding
link.  In our case, this will download an HTML page with an embedded
applet which constitutes a partner of a distributed computation.

Note that this is not a search engine: unlike centralized search
engines, the {\kfdirectory} is truly decentralized. The only services
required from the HTTP server are sending the HTML file and running
the CGI scripts to add and remove entries.  The actual search  takes
place in users' browsers.


\subsection{{\kfdirectory{}} and Java RMI}
\label{ssec-rmi}

While {\kfdirectory} was initially designed to work within browsers,
in this section we will consider an example how its services can be
used in other contexts.  In particular, we will look at the
client/server architecture of Java Remote Method Invocation (RMI).
 
In Java RMI terminology, a {\em registry} is a remote object which
provides basic name server functionality.  The {\tt rmiregistry}
provided in JDK~1.1 is a shell script which invokes {\tt RegistryImpl},
an implementation of such a registry.  Two methods provided by the
registry are of special interest to us: {\tt bind()} and {\tt
lookup()} for registering and locating a server object, respectively.
The existing RMI registry successfully binds a server object {\em only
if it is local to its machine}.  In the absence of a network-wide
directory service, this means either that client applications must
have {\apriori} knowledge of the host running each server they might
contact, or that all servers must run on a single well-known host.

\kf{} overcomes this restriction by providing a directory service to 
RMI registries.  We are in the process of implementing a wrapper class
around {\tt RegistryImpl}.  In addition of passing {\tt bind}
operations to the RMI registry, our wrapper class makes a
corresponding entry in a \kfdirectory{} under a specified service
name.  Our {\tt lookup} operation uses {\kfdirectory} to first search
the network for the host running an RMI registry with the appropriate
entry and then contacts that registry for a server's remote reference.
Thus, with the help of {\kfdirectory}, RMI servers can run and execute
anywhere on the network, and clients can transparently get servers'
remote references without knowing which hosts to search.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "paper"
%%% End: 
