Universal Naming Scheme



next up previous
Next: Indexing and Searching Up: Areas Needing Development Previous: Areas Needing Development

Universal Naming Scheme

 

Currently location-dependent filenames are used to name objects. Multiple copies of objects often exist, but outside of the distributed Netlib Repository, different sites may have different filenames for the same object. To complicate matters further, the same filename is often used for different objects or for different versions of the same object.

Current search facilities return the locations of objects, usually in the form of URLs. As a result, multiple hits may be returned for the same object. Another disadvantage is that the searchable indices have to be updated every time a copy of an object is moved, and such relocation is likely to happen much more often than changes to the object or to its description.

Naming objects by their locations presents a problem for caching, because it is difficult to tell whether a desired object is in the cache. Looking up whether the URL is cached does not suffice, because the contents of the location may have changed. Hence, clients or cache servers are forced to try to determine if the contents of the location have changed since the last access. Caching by location also wastes the opportunity to take advantage of multiple copies of objects. The Xnetlib client demonstrates a way of doing local caching by putting local copies of index and data files on the user's local file system, and these cached copies may be shared on a site-wide basis. To do such caching outside of Netlib, however, will require universal names.

Although it uses consistent filenames across different Netlib sites, Netlib still has the problem that an object's name is tied to its location. If an object is moved to a new location on the file system, it gets a new name, and the old name becomes stale. Furthermore, Netlib files may be updated in place, and although such updates are automatically propagated to all mirroring sites, the user cannot tell from the name, or from any other readily accessible information, that the object has changed.

Hence, there is a need for a name that remains constant for the lifetime of an object, regardless of its location. The Uniform Resource Name (URN) has been proposed by the IETF Uniform Resource Identifier (URI) Working Group [10]. The Netlib Development Group has begun implementing a specialized type of universal name called a Location Independent Filename (LIFN) as part of the Bulk File Distribution (BFD) project. A LIFN is assigned to a particular sequence of bytes, and once the assignment has been made, the same LIFN cannot subsequently be used to name any other sequence of bytes. The space of LIFNs is subdivided among several publishers, or naming authorities, who are responsible for ensuring the uniqueness of LIFNs within their portions of the LIFN-space. Resolving a LIFN involves finding an appropriate LIFN-to-location server and then contacting that server to obtain a list of locations for the LIFN. The prototype BFD implementation includes LIFN-to-location server code, as well as a WWW client library for resolving LIFNs. LIFNs are currently being assigned to Netlib files and are being integrated into the Netlib search interfaces. Use of LIFNs will allow Netlib to automatically mirror files from author-maintained sites, rather than handling updates from these sites manually. Future plans include include integration of authenticity and integrity checking into server-to-server and client-to-server protocols. Such checking will allow a network of trusted LIFN servers and file servers to be set up for a naming authority and will allow a client to authenticate such servers. More information about BFD is available at http://www.netlib.org/nse/bfd.



next up previous
Next: Indexing and Searching Up: Areas Needing Development Previous: Areas Needing Development



Jack Dongarra
Sun Dec 18 14:22:28 EST 1994