The naming architecture is being implemented as part of the Bulk File Distribution (BFD) package. BFD is part of the implementation of the National Software Exchange (NSE), which is being developed by the Center for Research in Parallel Computing (CRPC), a consortium of universities and national laboratories formed to make high performance and parallel computing accessible to engineers and scientists. BFD LIFN and file servers will run at all the CRPC participating sites, as well as at other major NSE sites, such as Oak Ridge National Laboratory.
A BFD client is a WWW browser that, in addition to having the capability to retrieve a file given its URL, also has the capability to retrieve a file given its LIFN or URN. A version of NCSA Mosaic 2.4 for X Windows that has been modified to support BFD is available at http://www.netlib.org/nse/bfd/. A BFD client library that can be incorporated into other Web browsers will be available soon.
The prototype implementation of BFD uses LIFN query and update protocols based on Sun's Remote Procedure Call (RPC) mechanism over UDP. RPC was chosen because it is very lightweight (one packet for request, and one for reply), widely supported on UNIX platforms, and easy to implement on other platforms (at least for the portions of RPC needed by BFD). The BFD RPC requests are sent to a server at a fixed port number, rather than using the RPC portmapper, to avoid the overhead of an extra RPC call.
To locate a LIFN server, BFD uses an ordinary DNS lookup for IP address records. LIFN.NETLIB.ORG is the implicit root of the LIFN name tree. For example, to find a LIFN server for the naming authority foo, a client looks up the IP addresses for foo.LIFN.NETLIB.ORG. IP addresses were used instead of new DNS records types because experiments showed that many DNS servers would not accept unknown record types. Several IP addresses may be listed for any one naming authority.
The BFD LIFN database is a simple key/data database in which the unique keys are LIFNs. Sending a BFD LIFN server a query containing a LIFN causes a list of URLs to be returned, possibly along with other information. Sending a BFD LIFN server an update containing a LIFN/URL pair (and possibly additional location-specific descriptive information) causes that pair to be added to the database.
The URN database and protocols have been implemented in an analogous manner.
LIFNs have been assigned to a number of software components in Netlib. Each of these LIFNs is of the form
lifn:netlib:<signature>where <signature> is the MD5 signature of the file. The URLs listed for Netlib LIFNs are of the form
<protocol>://<hostname>/<path>/<lifn>When a client program requests this URL from the file server, the file server either returns a file that it guarantees is correct for the given LIFN, or it returns an error indicating that a file corresponding to that LIFN is not available. Thus, BFD file servers guarantee that the LIFN-to-URL mapping is correct, and no integrity checking is required on the part of the BFD client. Several CRPC sites are or will soon be mirroring portions of the Netlib collection and running such BFD file servers.
Because the client program has not yet been modified to handle them yet, composite LIFNs, such as the set of files containing an LAPACK routine and its dependent routines, are handled by resolving a composite LIFN to a URL for an HTML file that contains a list of the component LIFNs. With the current client, the user must retrieve and save each of these files separately.
Descriptions of the Netlib software components have been exported to a Harvest Broker which eliminates duplicate files on the basis of LIFNs and which returns search results in the form of a list of LIFNs together with short (one to two-line) descriptions. From this list, the user may either retrieve the entire description record for a particular LIFN or resolve the LIFN to retrieve the file itself from one of its locations.
We have not yet made extensive use of URNs because most search
services, such as Harvest, describe resources at the file level
only. We expect the use of URNs to increase as more of the
issues involved with referring to non-specific or incompletely
defined resources are worked out.