Click slide for next, or goto previous, first, last slides or back to thumbnail layout.
Interested parties...these can be file servers that might want to replicate the resource, full-text search services such as Lycos or AltaVista who might want to index it, cataloging services who want to add cataloging and/or rating information, or any other party that the publisher wants to be informed.
LIFN consistency model... RCDS doesn't try to maintain consistent copies of a collection of files, between servers which may be geographically distant and connected by unreliable links. Instead, it issues a unique name to every new version of a file, which refers only to identical copies of that file. The location database keeps track of locations of files on a per-LIFNbasis. When a client wants a particular file, it asks the location database where it can find copies of the file with that LIFN.
Any location of the file will do. Ideally, there will be several locations of the file and the client can pick one that is nearby. But because the client does not need to know about all locations of the file, the various copies of the list of locations for that file (the location database is replicated, after all) need not be in synch. This makes it easy to propagate updates of the location database. A similar technique (slightly hairier)is used to keep replicas of the resource description ("catalog info") in sync.
RCDS provides a reasonable consistency model (basically, the user sees the same data no matter which server his files are coming from) while avoiding multi-phase commits between servers. This allows for less overhead and better fan-out when distributing updates, which increases the scalability of the system.
Resource descriptions allow for screening... The client normally sees a description of a resource before getting the actual resource, since the description contains the binding from the resource name used by the client (more on that later) to the LIFN which describes a particular version of that resource. The resource description can also contain descriptive information (Is it in English? Is it in a format I can read? How much does it cost to look at it? Is it appropriate for kids under 18?) which can be used to filter out unwanted resources before fetching them. It can also contain descriptions of multiple formats of the resource (English/French/German, plain text/PostScript/PDF, etc.), along with the LIFNfor each. This allows the user (or his web browser) to choose the version of the resource that best suits his needs.
Easy transition to new protocols... A resource description can be attached to any URL, and that resource description contains one or more LIFNs. The LIFN can be used to look up multiple locations of the resource. These locations are expressed as URLs, which need not use the same transfer protocol as the original URL. For instance, the original URL could specify http, but the location database could also return (if the client requests them) WebNFS URLs. In this way, a client can use the most efficient transfer protocol available for a particular resource.
Click slide for next, or goto previous, or back to thumbnail layout.