Replica Registration Service - Functional Interface Specification1.0 Page: 3 of 25
This report is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to Digital Library by the UNT Libraries Government Documents Department.
Referring to files
GUIDs, LFNs, and PFNs
There are several ways to refer to a file. If the location of the file is known, one can
specify its Physical File Name (PFN). However, since a file may have multiple replicas,
it is convenient to refer to the file by using Logical File Names (LFN). Some
communities of users prefer to support a unique immutable LFN for each file, and
provide a mapping between the LFN and one or more Physical File Names (PFNs).
In many cases, LFNs are designed to be structured names. This is a desired property,
since the file name conveys a meaning, such as the date, purpose, or conditions that were
used at the time the file was generated. However, having such structured names makes it
difficult to guarantee global uniqueness of the name. Furthermore, there may be a need
to change file names over time, or even have multiple aliases for a file name. For this
reason, some communities use a "globally unique identifier", referred to as GUID, to
identify a file, in addition to an LFN. Given that a GUID is used for a file, that file can
now have multiple LFNs that are treated as name-aliases for the GUID.
Since we wish to have this specification applicable to all communities, we adopt the more
general case of having a GUID for a file. In addition, we permit multiple LFNs per
GUID. For communities that only use a single LFN and no GUID, we consider that LFN
to be equivalent to a GUID.
The one-to-many relationships between a-GUID to-PFNs and a GUID-to-LFNs are
shown schematically in Figure 1.
PFNs and SURLs
The most straightforward way to specify a file is by a Physical File Name (PFN). A PFN
can be specified as a physical URL made of the format:
protocol://machine:port/directory-path/file-name. For example:
gridftp://cs.berkeley.edu/home/temp/foo. Note that the protocol specified in this case is
the transfer protocol.
Some storage systems support multiple physical devices and multiple directories, and
may want to have the freedom of changing the physical location of a file without
changing the reference to it by Grid clients. An example of a software layer that permits
this functionality is a Storage Resource Manager (SRM). The SRM is a single endpoint
for accessing a file regardless of its physical location on a particular site. The site is a
virtual entity referring to the collection of resources under the administrative control of
the site manager. The concept of a site permits a single filename to be assigned to a
physical file regardless of it physical storage location.
The reference for a file on a site is called a "Site URL" (SURL). For example:
srm://data.berkeley.edu:4004/dir/foo is the name of a file managed by an SRM residing
on the machine data.berkeley.edu, on port 4004. When requesting the file from the SRM
using the SURL, the SRM returns the "transfer URL" which is the actual PFN. For
Here’s what’s next.
This report can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
Citing and Sharing
Reference the current page of this Report.
Shoshani, Arie; Sim, Alex & Stockinger, Kurt. Replica Registration Service - Functional Interface Specification1.0, report, February 28, 2005; Berkeley, California. (https://digital.library.unt.edu/ark:/67531/metadc899452/m1/3/: accessed April 21, 2019), University of North Texas Libraries, Digital Library, https://digital.library.unt.edu; crediting UNT Libraries Government Documents Department.