mention-ltflependent Naming for Virtual <3R>Distributed Sofiwar...
`
`httpn‘twww nctlib orgtulldpaperstlifistmiain html
`
`
`Next: Introduction
`
`_L‘ocation-Independent- Naming for Virtual
`Distributed Software Repositories
`
`Shirley Brown-l, Jack Dongarra, Stan Green, Keith Moore
`Theresa Pepin, Tom Batman, and Reed Wade
`University of Tennessee
`'
`Eric Grosse
`
`ATE; Bell'Lalroratories
`
`November 11, 1994
`
`Abstract:
`
`A location-independent naming architecture for network resources has been designed tofaciiitate
`organization and description of software components access ibte through a virtual distributed
`repository. This naming scheme enables easy and efiicient searching and retrieval, and it addresses
`. many ofthe consistency, authenticity, and integrity issues invoived with distributed soflware
`repositories by providing mechanisms for grouping resources and for authenticity and integrity
`checking This paper details the design of the naming scheme. decribes a prototype implementation of
`some ofthe capabilities, and describes how the scheme fits into the development of’the i'fi’ationotI
`Soflware Exchange. 0 virtual software repository that has the goal ofproviding access to reusable
`software components for high=performance computing
`
`I Introduction
`
`I Publishing and Name Assign_ment
`.
`I Name Resolution and File Mhlosing
`I Authenticity, Integg'tg,- and COnsistenc}; 'of Resources
`I Pmtogmg Implementation
`'
`I - Conclusions and Fauna Work
`
`'
`
`I Glossy}: ofTerms
`I References
`-
`
`I About this doournent
`
`Jack Dongarra
`
`on
`
`'
`
`'
`
`EMCVMW 1006
`EMCVMW 1006
`0322229006 10:22 AM
`
`1
`
`1
`
`

`

`.acatiun-lfliependcm Naming for Virtual <BR>Distributed Sofiwar
`v
`
`htthMww ncllitimglutldpapnsllifn/main html
`
`‘ Mon Jan 30 10'42'57 BT19”
`
`of 2
`
`-
`
`'
`
`omzrzooe I02 2 AM
`
`2
`
`2
`
`

`

`ntroductifi
`
`http'waww netllborg/utidpapersllilnfnodc l' html
`
`
`Next: Publishing and Name Up: Location-independent Naming for Virtual_____Previous:
`. Location-Independent Naming for Virtual
`....._-....‘
`...
`......__._——-‘..-.
`
`Introduction
`
`Well—maintained software repositories are central to software-reuse because they make hi gh—quality
`software widely available and .easily accessible. One such repository is Netlib, a collection of
`high-quality publicly available mathematical software. Netlib, in operation since 1985-, currently
`processes over 300,000 requests a day Netlib is serving as a prototype for development of the
`National Software Exchange (NSE), which has the goal of encompassing all High Performance
`Computing Consortium (HPCC) software repositories and of promoting reuse bf software components
`developed by Grand Challenge and other scientific computing researchers.
`-
`
`Many repositories, previously maintained centrally, have evolved into virtual repositories that serve as
`directories to distributed collections. For example, the GAMS Software Repository, once a central
`repository Ll_1, is now a virtual repository that'catalogs software maintained by other repositories L2].
`Another distributed repository, the NASNGSFCIESS Software and Information Exchange (accessible
`at m: tp : {(faraide .gafc . naea .gov/BSSI), stores some of the catalogued sofiware packages locally,
`but for packages at remote sites stores just descriptions with pointers. Growth in the popularity of the
`Internet and the World Wide Web, as well as the wide availability of‘WWW client and server
`software, has accelerated the shift from centrally maintained software repositories to virtual,
`distributed repositories. A provider site (either the maintainer or a mirror site) need only make the file -
`available liom an FIR—Gopher, or HTTP server for it to be accessible from a WWW client
`-
`
`The main advantage ofdistributing a repository is to allow the software to be maintained by those in
`the best position to keep it up-to-date. Also, copies ofpopular software packages may be mirrored by a
`number of sites to increase availability (e.g. if one site is unreachable, the sofiware may be retrieved
`from a different site) and to prevent bottlenecks
`
`' A distributed, virtual repository should appear as a Centralized, well-organized repository. An effective
`search interface for a distributed software repository allows a user to search for sofiware without
`knowing at what site the software is located. A mirrored file should appear once in a list of such
`results, rather than once for each mirrored copy Yet a searcher should still enjoy the reliability and
`performance benefits of'mirroring - i e , be able' to try alternative locations to retrieve a search hit or
`retrieve the closest copy of the file
`
`'
`Distributed maintenance and mirroring of software introduces challenges as well as benefits.
`_ Maintaining the quality of sofiware and of indexing information and presenting a uniform searching
`and browsing interface become much more difl'rcult Location-independent naming facilitates the
`organization, finding, and retrieval of software'in a distributed repository, and can be used to provide
`consistency, authenticity, and integrity guarantees.
`
`ht"?
`
`'
`
`031232006 10:22 AM
`
`3
`
`3
`
`

`

`ntroductidlt
`
`_
`
`.
`
`hapwwww netlib oryuwpapersn tarmac I html
`
`The WWW mechanism of specifying a file by its Uniform Resource Locator (URL) poses several
`difficulties for a virtual software repositOry. URLs are inadequate for ensuring the consistency and
`' currency of'mir'rored copies. A URL for an independently mirrored cOpy of a software package may
`point to an out-of-date copy and give no indication that it is not up-to-date Consistency between a set
`of't'rles that are meant to be used together may also become a problem. For example, the Netlib
`Software Repository pretrides dependency checking that allost the user to retrieve a rep-level routine
`plus all routines in its dependency tree (i-e ., those routines that are called directly or indirectly by the
`top-level routine). Another example is a graphical parallel programming environment that relies on an
`underlying parallel communications support package. the problem becomes more complex when
`different pieces might be retrieved from different physical repositories. Ideally, the user should be able
`to have a consistent set retrieved automatically without having to scan documentation to verify that
`compatible piecos have been retrieved.
`'
`
`Distributing the repository also poses challenges for searching. A centrally maintained repository can
`easily run an indexing and search engine that provides a search interface to the repository contents
`With the current WWW setup, however, the user has a choice of searching the variOus distributed
`repository sites individually or of using a general purpose WWW search engine such as WebCrawler,
`Lycos, or the World Wide Web Worm
`
`'
`
`Most of'the above problems can be alleviated by implementing a location-independent naming
`architecture that includes mechanisms for authenticity and integrity checking. We have designed a
`naming scheme in which the binding between a name and tile contents is unchangeable and verifiable
`A name may be resolved to multiple, mirrored copies ln'the case where it represents a set of files, a
`name may be resolved to a list of other names. The record for a resource that includes the name as well
`as other descriptive information may be signed by the publisher so that users may verify the
`authenticity of a retrieved resource This paper describes the design of our naming architecture. We
`also describe our implementation of a protoype name—to-location service and of a modified WWW
`client that does name r'esolutiOn. A glossary of terms used in this paper is included as an appendix.
`.
`. v...p_. ,. ..
`...........
`.
`.....
`
`
`
`Next: Publishing and Name Up: Location-Index ndent Naming for Virtual Previous:
`Location—Indegndent Naming for Virtual
`
`Jack Danger? :1
`Mon Jan 30 10. 4'2 57 EST 199.5
`
`W 7
`
`'
`
`.
`
`.
`
`Dimmers m : 22 AM
`
`4
`
`4
`
`

`

`?ublishinfind Name Assignment
`
`,
`
`.
`
`httpzflwwwnetlib orglutldpspersflifirfnodfl .htrnl
`
`
`
`;,
`
`Next: Name Resolution and Up: Location-independent Naming for Virtual Previous: Introduction
`
`Publishing and Name Assignment
`
`A user who contributes a resource (e .g , a software package or a document) by making it available via
`our virtual software repository is said to have published the resource Two types of
`location-independent names may be assigned by the publisher to the resource. Fora resource that is
`made available as a file or a set offiles, a Location Independent File Name (LIFN) may be assigned. A
`LIFN refers to the particular sequence of bytes making up that file, or in the case of a set offiles, to the
`set of'LIFNs for those files. Once a LIFN has been assigned to a particular sequence of bytes, that
`binding may not be changed. Various ways of enforcing this requirement are discussed in Section 5
`
`The otherpossible type of'na'rne is the Uniform Resource Name (URN), which is a long-lasting name
`that may be used by humans to refer to some network-accessible resource, be it a Web page or a telnet
`interface The exact contents of the resource named by a URN can change. For example, accessing a
`URN for “the current version of LAPACK" would give a different result following a new release of
`the LAPACK package.
`
`_
`The LlPN'and URN name spaces are subdivided among several publishers, also called naming
`authorities, who are responsible for ensuring the uniqueness ofnames assigned within their portions of
`the name spaces
`
`' A name is formed by concatenating the registered naming authority identifier and the unique string
`assigned by the naming authority. For the Netlib naming authority, whose identifier is me t1 in, the
`unique string for a LlFN consists of the MDS fingerprint [fl ofthe file. This fingerprint is a 128-bit
`quantity resulting from applying the MDS function to the contents of the file The function'is designed
`to make it computationally infeasible to find a- different sequence of bytes that produces the same
`fingerprint. The unique string used for a URN is the unique name by which the resource isknown in
`the Netlib RepOsitory - for example, lapaclr for the current version of the LAPACK package. The
`LIFN and URN are formatted as '
`
`LIENr-rpubliahex idmstring
`URN: epubl inner ids-:31: ing
`
`The publisher may provide a description for each name it assigns. The description may include
`information such as title, author, abstract, etc .- Suggested attributes for software resOurces include
`programming language and system requirements, and for mathematical software, the GAMS
`classification [1_1. A description may also include a supersedes field if the file supersedes a previous
`one (e 3., a new version of a software package). The description for a LIFN should include an MDS or
`similar fingerprint, ifthat fingerprint is not part of'the LIFN itself. To enable authentication, the entiie
`description may be cryptographically signed, as discussed in Section 3. Portions of'the description may
`
`of").
`
`'
`
`‘
`
`osnzrzooe 10:23 AM
`
`5
`
`5
`
`

`

`’ublishinfimd Name Assignment
`
`httptiiwwwnertib orghrtlrlpaperso’lifiii'nodfl2 hflml
`
`be exported to resource discovery servers, which provide search services based on resource
`descriptions A search service may also accept value—added descriptions submitted by users other than
`the publisher (e3, critical reviews). Multiple descriptionsmay becombined into a union record,whi_1e
`preserving the source ofeach description, as in [31 The URN or LIFN exported to the search service
`provides a unique long-lived key, so that descriptions may be unambiguously associated with a
`resource, and so that a resource turns up at most once in a list of search hits.
`
`For a name tobe useful there must be some means of resolving a name to a location from which the
`resource can be retrieved oraccessed. Thus, the publisher, as well as any other parties that mirror the
`resource. must register such lecation with the appropriatename—to-location Iookup services Such
`name-to—location services are discussed111 Section 3
`
`limit, publishing a resource involves the following steps:
`
`mthH
`
`. creating the resource'5 description
`. signing the description with the publisher'3 private key,
`. making the resource available on one or more file sewers,
`.
`listing the resource locations'in the name-”tolocation database, and
`. exporting the resource's description to search services.
`
`Steps 1 and 5 have been discussed above Steps 213 discussed'in Section 4, and Steps 3 arid 4 are
`discussed1n Section -_3
`
`Next:IName Resolution and Up: Location-Independent Naming for Virtual Previous: Introduction
`
`Jack Dongarra-
`Mon Jan 30 10 42 5755'? 1995
`
`Inf 2
`
`.
`
`'
`
`'
`
`‘
`
`0312mm 10:23 AM
`
`6
`
`6
`
`

`

`dame Resalution and File Mirroring
`
`httpflwww netlibnrgfutk/papersllifiiinodeil him]
`
`
`
`n
`
`-.
`
`
`
`
`
`Authenticitylntegg'ty, and Up: Location-Indegndent Naming for Virtual Previous: Publishing
`Next:
`. and Name
`
`Name Resolution and File Mirroring
`
`' Resources available fi'om the virtual repository will be named by URNs and/or LIFNs, rather than by
`URLs. Thus, WWW clients will need a means of resolving a URN or LIFN to one or more locations,
`expressed in the form of a URL, to be able to access the resource. Access to files is provided by
`conventional file servers, using protocols such as HTTP, Gopher, and FTP Name resolution - that is,
`accessing a resource given its name - requires the following two steps:
`
`1. finding a'name-to-location mapping service that knows locations for the name in question, and
`2. querying that service to obtain a list (if locations
`
`For a non-file resource, such as a database service, a list of locations may be associated directly with
`the URN for that resource. For a file resource, such as a file containing a piece of sofiwar e, we
`recommend that the list of locations be associated directly with the DIN for the file, rather than with
`any URN assigned to the resource- If the publisher wishes to also assign a URN to the resource, then a
`LIFN should be associated with that URN.
`.
`
`The-LII: N-to-location mapping-ser vice is to be provided by a network ot'LlFN servers, collectively
`called the LIFN database. These servers process queries for locations of'LlFNs. They also accept
`updates from file servers containing new locations for LIPNs, as well as requests to delete old
`LIFN-to-location mappings. A naming authority may run its own LIFN servers, or it may find another
`organization willing to provide the service on its behalf.
`
`The URN service is similar to the [JPN service, eacept that it maps a name either to a list of locations
`or to a LIFN. For fault tolerance and availability, the URN service is also provided by a network of
`SCIVCIS-
`
`Mappings from naming authority identifiers to URN and LIFN servers are stored in the the Domain
`Name system (DNS) name space, so that a client program cari determine which LlFN (URN) server to
`query fora particular LIFN (URN) Our current client uses an ordinary DNS lookup for [P address
`records. The publisher identifier is prepended to the string .LIFN.NETLIB ORG (for a LlFN) or
`URN .uisrLrn one (fora URN). The resulting string is treated as if it were the name of an Internet
`host, and DNS is queried to find the IP addresses of that host For example, to find a LIFN server for
`the naming authority foo, the client would look up the IP addresses for foo ram .NETLIB .036.
`Several IP addresses may be listed for any one naming authority. Our client attempts to query each [P
`address until it finds one that can satisfy the LIFN or URN lookup request.
`
`A file server can mirror a file by acquiring a copy of it and posting an update to a LIFN server for the
`
`"‘7
`
`\
`
`7-
`
`OJQMDOE 10:24 AM
`
`7
`
`7
`
`

`

`flame Resfiution and File Mirroring
`
`.
`
`httrrm'mrumr nerlib orglutkfpapersflifnlnodfl .htrnl
`
`
`
`file's naming authority Ifa file server moves or deletes a file, then it would post that information 'as
`well It is not necesSary to keep all LII‘N servers for a particular naming authority perfectly
`synchronized. Such synchronization would entail too much overhead. Instead, location updates will be
`posted to a single LIFN server and propagated to other peer servers using a batch update protocol-
`
`Under normal conditions, all LIFN servers will be reasonably up—to-date, but ifthe list of locations
`provided by one server is unsufficient', the client is free to consult other LIFN servers foradditional,
`locations [fa listed location turns out to be incorrect - i.e , it points to a location that does not actually
`contain the file (how such an error condition maybe detected by the client is discussed in Section 3) -
`the client may look for a file at the file's other listed looations.
`
`Similar techniques are to be used for propagating updates betWeen peer URN server 5. In the cam: of
`URNs‘, however, the consistency issues are more vague, because of the less precise definition ofURN
`compared to LIFN. Consistency guarantees to be provided for URNs are the subject of future work.
`
`
`
`and Name
`
`Jack Dongana
`Mon Jan 3010 4'2 57 ES? 1995
`
`inf?
`
`'
`
`‘
`
`0332212006 10:24 AM
`
`8
`
`8
`
`

`

`Authenticg, Integrity, and Consistency of’Resor'rrces
`
`_
`
`httpzflww netlib or york/paper sllifnfnodefi htrnl
`
`
`I Next: Protom Implementation Up: Location-Inde ndent Narnia for Virtual Previous: Name
`
`
`
`
`
`Resolution and
`
`Authenticity, Integrity,- and Consistency of
`Resources
`
`Authentication of a resource verifies that the resource was published by its purported publisher.
`Verifying the integrity ofa file ensures that the file has not been modified Provisions for authenticity
`and integrity checking are necessary for a software repository because there have been multiple
`instances of Software packages stored on a public repository that were modified by intruders to
`introduce security holes which were then spread to other systems. Our" authentication and integrity
`mechanisms are similar to those described in [g].
`
`Recall from Section 2 that a publisher cryptographically signs the description for a resource In the
`case of‘a file resource, this description includes the file's'LIFN and MDS fingerprint. Any client in
`possession of'the publisher's public key can verify the authenticity of the resource description
`Publishers are expected to widely advertise their public keys to make it difficult for an attacker to
`substitute rogue keys In addition, publishers may have their keys certified by trusted third parties to
`fiuther establish their authenticity, as in [El
`
`Assuming that the association between a LIFN and a file signature (e g., the MDS fingerprint)i‘s
`known to be correct (either because the signature is part of the LIFN or because of the description
`authentication described'in the preceding paragraph), a client may perform an integrity check on a
`retrieved file by computing the signature for the file and comparing it with the one known to be
`associated with the file's purported LIFN. Recall from Section }_ that a LIFN server returns a list of
`locations for a given LIFN but does not guarantee the correctness of those locations. A location may
`be incorrect if it no longer exists or if'the contents of that location are vvrong.'ln the former case, no
`file will be-returned from that location The latter condition may be detected by the client performing
`an integrity check.
`
`'
`
`To avoid the overhead ofthe client having to perform authenticity and integrity checks for every file
`accessed, however, we plan to use an authentication system for LIFN and URN servers and for-file
`servers. A client program will be able to cache naming-authority to LlPN(URN)vserver-lP-address
`mappings and authenticate these mapping by contacting the LlFN (URN) servers. Furthermore, the
`LIFN servers for a particular naming authority will allow only authorized trusted file servers to register
`locations for that naming authority‘s files. Update requests fiom file servers to LlFN servers, as well as .
`the batch update protocol between LIFN (URN) servers, will require authentication, so that only
`- author rzed servers can store locationsin the naming authoritys LlIFN and URN databases Such
`authentication may be based on public keys, shared secrets network addresses, or some combination
`
`of 2
`
`_
`
`arm/zoos Io:24 AM
`
`9
`
`9
`
`

`

`Authenticifpflntegrity. and Consistency of Resources
`
`httpzflmvwnetlib org/mklpapersilifiilnodfi hurt]
`
`of these.
`
`_
`
`Io spare clients fiorn performing an integrity check on every retrieved'file, a trusted file server must
`be able to guarantee, that a file it returns for a particular LlFN is correct. The guarantee can be provided
`in at least two ways. One-way is for the file server to maintain a LlFN-to—filename mapping-for the
`files _it_'serves, to guarantee that this mapping is correct, and to accept file requests in the form of
`LIFNs'A LIFN server would still return one or more URLs for the LIFN, but the LIFN would be
`substituted for or added onto the pathnam'e portion of'the URL. Such a file server could be
`implemented with current HI IP servers by means of a 061 program A file server could also
`guarantee correctness of the file returned for a LIFN by never reusing filenames, even for updates to a
`file This restriction would require changing from the present-day practice ofusing a filename as a
`stable reference to the current version of a file
`
`File servers will be expected to inform the loCation database in advance of deleting a file to-minimize
`the likelihood of "stale" file locations. locations for which the corresponding files have been deleted.
`A file server will supply a location-time~to-live value when it posts a location for a file Specifying a
`location-time—to-live value ofN constitutes an agreement that the file server will not delete the file
`without informing a location server N seconds in advance of doing so The location server can then
`adjust that value by subtracting an estimated upper bound on the time to propagate updates between
`LlFN servers, and LIFN servers can then include a location-time-to-live value in responses to location
`queries for use by clients or proxy servers in maintaining a cache ofLIFN-to-locati on mappings.
`
`To ensure consistency within a group of related‘files (e .g .5 a software routine plus all the routines in its
`call tree) we allow a LIPN to represent a list of component LIFNs. A query to the LIFN database may
`therefore return a list of component LIFNs instead of a list of locations IheLIFN server might
`optionally also returna location list for eachof the component LIFNs in the same response. Current
`WWW clients, such as Mosaic, are not capable of’retrieving a group of files in one action, so we are
`developing a WWW client that will have this capability. Our client will then download a consistent set
`offiles to a specified location on the user's disk
`
`
`
`Next: Protogpe Implementation Up: Location-Independent Naming for Virtual Previous: Name
`Resolution and
`-
`
`Jack Dongana
`Mon Jan 30 10. 42 .57EST1995
`
`:nl‘2
`
`'
`
`1 O
`
`'
`
`‘
`
`alumnus 10:24 AM
`
`10
`
`10
`
`

`

`?rototype1nirlementation
`
`'
`
`hrtp:ffwww nellib org/ufldpapersmfrunodefi hn-nl
`
`
`Next: Conclusions and Future Up: Location-Independent Naming far Virtual Previous:
`Authenticitylntegrity, and
`-
`
`Prototype Implementation
`
`The naming architecture is being implemented as part of the Bulk File Distribution (BFD) package
`BFD is part ofthe implementation of the National Software Exchange (NSE), which is being
`developed by the Center for Research in Parallel Computing (CRPC), a consortium of univer sities 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 Laboratmy.
`
`A BFD client is a WWW bIOWSer that, in addition to having the capability to retrieve a file given its
`URL, also has the capability to retrieve a file given its LIPN or URN. A version of NCSA Mosaic 2 .4
`f0: X Windows that has been modified to support BFD'rs available at
`http- Hm. netlib. org/nee/bsd; A BPD 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 (RFC) 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 RFC needed by BED). The BFD RPC requests are sent to a
`server at a fixed port number, rather than using the RFC portmapper, to avoid the overhead of an extra
`RPC call.
`
`To locate a LIFN server, BED uses an ordinary DNS lookup for 1? address records ernarua . one
`is the implicit root of'the LIFN name tree. For example, to find a LIFN server for the naming authority
`£00, a client looks up the IP addresses for £00 1.11711 some .0120. lP-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 siniple 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 :1 BED LLFN server an update containing a LIFNIURL 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 havebeen assigned to a number ofsoftware components in Netlib Each of these LIFNs'1s of
`the form
`
`1 of").
`
`'
`
`.
`
`.
`
`'
`
`1 1
`
`03R21'2006 10:2 4 AM
`-
`
`11
`
`11
`
`

`

`'rototype lfilemenmion
`
`httpdfwrvw netlib orglufldpapersflifirtnodcs htr'nl
`
`——————‘
`
`lifn :netiib: caignature:
`
`where esignature> is the MDS. signature of'the file The URLs listed for Netlib LIPNs are of the form
`
`eprotocob : H<hostnamesf epfltl‘»! elifn> '
`
`When a client program requests this URL hour 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 LlFN 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 LIPNs. With the
`current client, the user must retrieve and save each of these files separately.
`'
`
`Descriptions of the Netiib 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 tw0--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 ot'URNs beeause most search services, such as Harvest, describe
`resources at the tile level only. We expect the use ofURNs to increase as more of the issues involved
`with referring to n0n~specific or incompletely defined resources are worked out
`
`
`Next: Conclusionsand Future Up: LocatiOn-lndependent Naming for Virtual Previous:
`
`AuthentithyIntegity, and
`
`-
`
`.r.-
`
`Jack Derrgarra
`Mon Jan 30 I042 '57 EST1995
`
`fln‘fi
`
`12
`
`0302/2006 IO:24 AM
`
`12
`
`12
`
`

`

`Ionelusiorprrd Future Work
`
`.
`
`httprww netlib org/ufldpapcrsflifirrnodcfi htrnl
`
` :4: g :I-
`Next: Glossary of' Terms Up: Location~lndependent Naming for Virtual Previous: Prototype
`Implementation
`
`Conclusions and Future Work
`
`We have designed a naming scheme that makes an immutable association between a
`location-independent filenanre, called a LIFN, and a specific byte stream. A higher-level
`location-independent name, called a URN, may be associated with a resource that is not tied to a
`specific byte stream. We 'haVe assigned such names to some of the software components in Netlib, and
`we have exported descriptions of these components to a Harvest search server. We have deployed
`LLFN and URN servers that provide LIFN and URN lockup services, and we have made available a
`modified version ofMosaic that can retrieve files named by LIFNs or URNs
`
`We have described mechaniSms, based on a public key encryption system, for verifying the
`authenticity of'LIFN and URN servers, oftrusted file servers, and of resource descriptions. Although
`we have not yet implemented such mechanisms, we plan to do so soon
`
`Our naming scheme will help provide a uniform central interface to a virtual distributed software
`repository, such as the National Software Exchange, while preserving the advantages of distributed
`maintenance of contributed software and of file mirroring Our consistency, authenticity, and integrity
`mechanisms will provide assurances that software components retrieved from independent sources are
`consistent with their verifiable descriptions. Use of LIFNs will allow value-added descriptions, such as
`critical revieWs, to be unambiguously associated with the exact file or set of files that was reviewed
`Referring to a LIFN also allows a researcher to unambiguously specify the exact piece of software
`used to produce and report experimental results
`
`As part ofthe BED package, we plan to implement a replication daemon that acquires new files from
`remote servers, deletes files that are no longer wanted, and informs LIFN servers of the changes. These
`functions are similar to those provided by several existing mirror programs, such as the Netlib
`repository mirroring scheme described in E], but with the addition of interacting with the LIFN '
`database. The BFD replication daemon will be designed to perform its tasks very efficiently. Planned .
`features include on-the-wire compression, checkpointfrestart, multiple file multiplexing (to allow for
`gradual transfer of very large files), integrity checking, and a protocol that works well over high
`bandwi dth-delay links.
`
`A collection manager program will also be part of the BFD package. A collection manager will decide
`which files to acquire and which ones to keep or throw away, based on access statistics and
`site-specific criteria. The results of such decisions will then be fed to one or more replication daemons
`
`. 4—...
`
`.
`
`.
`
`.
`
`.... ....
`
`. ...._...
`
`r are:
`
`I
`
`13
`
`03020006 10:24 AM
`
`13
`
`13
`
`

`

`ZonclusiOIflim‘d Future Work
`
`httpwwmv netliborglutkfpapers/lifivnodeG .html
`
` - . m .3
`
`
`.44-
`5
`[Iii-J
`I‘L.‘
`J.
`
`Nexf: Glossary of Terms Up: Location-Indchndcnt Naming ‘for Virtual Previous: Protogggc
`ImplementatiOn
`
`Jack Dangan a
`Mon Jan 30 )0 42 57 EST1995
`
`1m
`
`14
`
`I OSQIQOM [0:2 4 AM
`
`14
`
`14
`
`

`

`Eiossery 01 5t ms
`
`http:lfwwwlnetlib orglutk/papers/lifrflnodc'? html -
`
`
`
`'
`
`15.
`
`
`
`t A135
`"ext: References Up: Location-Indegendent Naming for Virtual Previous: ConclusiOns and Future
`
`Glossary of Terms
`
`BFD
`
`CGI
`
`CRPC
`
`Bulk Pile Distribution
`
`Common Gateway Interface
`
`Center for Research in Parallel Computing
`
`DNS
`
`F TP
`
`Domain Name System
`
`File Transfer Protocol
`GAMS
`
`Guide to Available Mathematical Software
`Harvest
`
`An information discovery and access system
`HPCC
`
`High Performance Computing Consortium
`
`HTTP
`
`'
`
`IETF
`
`[P
`
`Hyper Text Transfer Protocol
`
`Internet Engineering Task Force
`
`Internet Protocol
`
`.
`LAPACK
`A linear algebra sofiWare package
`
`Ll'FN
`
`Lycos
`
`MDS
`
`Location Independent File Name
`
`A World Wide Web search engine
`
`A message digest algorithm
`Mosaic
`
`A World Wide Web browser
`NC SA
`
`National Center for Supercomputing Applications
`
`Netlib
`
`A mathematical software repository
`
`ot'2
`
`15
`
`OJRZRDDG 10:24 AM
`
`15
`
`15
`
`

`

`3Iossa1y 01 6mm
`
`httpu'lww nerlib org/quapersllifiVnodeTV html -
`
`.
`
`National Software Exchange
`'-
`Prelty Good Plivacy, a public key encryption package
`'
`'
`Remote Plocedme Call
`
`Uniform Resounce Citation
`
`Uniform Resource Locator
`
`NSE
`
`PGP
`
`RPC
`
`URC
`
`URL
`
`URN
`
`Uniform Resomce Name
`
`WebCIawlei
`
`A World Wide Web search engine
`WWW
`
`Woxld Wide Web
`
`WWW
`
`Woxld Wide Web Worm, a Woild Wide Web search engine
`
`Jack Dongan'a
`Mon Jan 30 I0 42.57 EST 1995
`
`. of 2
`
`'
`
`'
`
`'
`
`_
`
`1 6
`
`'
`
`031220006 10:24 AM
`
`16
`
`16
`
`

`

`Referenced] 7
`
`.
`
`http:/twww netlib org/utkfpap‘ersflifrie‘nodfl him]
`
`
`
`‘ {gs. .5351]
`
`Next: About this docurnent Up: Location-Independent Naming for Virtual Previous: Glossary of
`
`Terms
`'
`-..»......
`..
`..
`-_.......
`......_...-.
`
`References
`
`l
`
`2
`
`3
`
`4
`
`5
`
`6
`
`R. F Boisvert, S. E. Howe, and D K