Re: The Path URN Specification

michael rabinovich writes:

 > 	From: mshapiro@ncsa.uiuc.edu (Michael Shapiro)
 > 	But you point out a real problem. With the path scheme, if you can move
 > 	part of the hierarchy to a new server and put the info into DNS, scheme
 > 	you have to contact the original server that used to serve the document
 > 	and it tells you to contact another (ie returns forwarding info).  Plus
 > 	if the ability of a server to serve even the forwarding info degrades -
 > 	were stuck.
 > 
 > 	I think this may be a fundamental flaw with hierarchical names.
 > 
 > No, I think this is only a problem if you make server hierarchy part of the
 > name hierarchy. 

In the path scheme, the server hierarchy is adjustable.  If a server
administrator wants to give up serving just part of its name space,
provided that part is already subdivided by the name space (is this
what you mean Misha?), then the server can (and must) forward requests
for that part to another server.  But if the server administrator
wants to give up serving all together, its parent resolver can find
someone who will take over, or it can take over itself.

So things tend to get pushed up to higher levels of the hierarchy as
time goes on - as the original motivation evaporates to serve names at
lower levels.  The motivation to serve an increasing number of
unrelated names seems to be lower as we move higher in the hierarchy.
If we imagine that everything gets pushed up to the top level, this is
essentially a flat namespace.  How is a flat namespace to be funded
long-term?

 > 	However, flat namespaces have their problems.

 [... description of handle system ...]

 > 	Clients figure out which server to contact by forming a hash on the URN
 > 	and looking up a server in a list of servers (that it downloads from
 > 	somewhere - a detail).
 ...
 > 	However, this means that clients may have to contact servers that are
 > 	very remote - or that (a hierarchy of?) caches that replicate the
 > 	namespace would have to be introduced.
 > 
 > If there is no caching or replication, clients will have to contact remote
 > URN/URL resolution servers anyway, be it a flat or hierarchical namespace.
 > So, I do not see this to be a problem particular to the flat namespace.

With a hierarchy of servers, a client can cache the locations of
servers, so even if the cache does not contain the full name of a
document, the client can find a most-specific known server.  In a flat
name space, there is no possibility for taking advantage of coherence
from one name to the next, so there is no way to cache the location of
an appropriate server.  

In the handle system, you might consider the hash table as the cache
of all servers.  But all servers have to have a correct hash table to
map names to the right servers.  It is difficult to imagine that all
clients can also have the correct hash table, but the handle protocol
allows them to be wrong.  Servers could be wrong too, I suppose, if
they eventually bounce you to a correct server.

So we are thinking of a hybrid between hierarchical and flat name spaces.

 > This handles system seems rather close to our own approach, except we
 > deal with name server overloading differently, and we also do dynamic 
 > replication of end documents.

I'd be interested in seeing more details of your system.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Friday, 24 March 1995 10:04:46 UTC