Forwarded message 1
I'm sorry I haven't been able to respond sooner. Here's a quick
summary of my work related to software distribution.
RCDS is a scalable system for replicating content across several
(possibly geographically dispersed) servers, propagating changes to
the content, keeping track of where the replicas are, maintaining
metadata about resources, and providing integrity guarantees for the
resources and metadata.
RCDS is not limited to software distribution, but was designed with
software distribution in mind -- including distribution of source
code, object libraries, and executables. This is why RCDS goes to
great lengths to provide identical results at different service
locations, even while resources are being updated, as well as strong
authenticity and integrity checking.
RCDS can serve as a resolution system to obtain locations and metadata
for resources named by Uniform Resource Names (URNs) or alternate
locations and metadata for resources named by URLs.
Along with a SONAR protocol server, an RCDS-aware client (say, a web
browser or http proxy) can identify several locations of an identical
resource, pick one which is nearby (on the Internet), and download the
resource from that location. If an attempt to download the resource
from one location fails, the client can fail over to other locations,
even in mid-transfer.
A LIFN is a stable resource name -- once assigned to a resource, the
resource it points it can never be changed, nor can the name be
reassigned to point to a different resource.
LIFNs (Location Independent File Names) are used internally to RCDS as
sort of a file handle. They appear in metadata about a resource. If
a resource is updated, a new LIFN is created for the new version of
the resource and the metadata for that resource is updated to reflect
the new LIFN. The metadata may also contain digital signatures on the
resource, along with arbitrary subsets of the metadata, and these are
also updated when the resource LIFN is changed.
A client wishing to access the resource first obtains the metadata,
and then obtains URLs for the resource that correspond to the LIFN.
In this way, the resource obtained is guaranteed to be consistent with
the metadata, including the digital signatures. (a URL once
associated with a particular LIFN cannot be reused)
Work on RCDS continues: it's currently being used as a naming and
metadata infrastructure for a scalable distributed programming
environment called SNIPE (scalable network information processing
environment)
There is a tech report about RCDS, and a "slideshow" in
http://www.netlib.org/utk/projects/rcds/
The slideshow is a better first-time presentation. I must apologize
for the tech report. As I recall, it's not put together very well (I
made the mistake of trusting a departing grad student to do the job),
and I haven't yet had time to revise it.
The SONAR protocol is documented at:
http://www.netlib.org/utk/projects/sonar/
An abstract of a paper describing the SNIPE project is at:
http://www.cs.utk.edu/~moore/snipe/sc97-abstract.html
We're in the process of setting up a web page for it.
Keith Moore