Replica Registration Service - Functional Interface Specification1.0 Page: 4 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.
The following text was automatically extracted from the image on this page using optical character recognition software:
example, for the file above the SRM may return the PFN on another machine,
cs.berkeley.edu, by using the URL gridftp://cs.berkeley.edu/home/temp/foo. Note that a
PFN is a special case of an SURL, where the transfer service specified by the protocol is
the site endpoint. Therefore, we only use SURL in the remainder of this document.
LFN namespace structure
LFNs are commonly organized into directory structures, similar to any file system (such
as the Unix file system). Some file systems consider directory names as LFNs as well
and assign GUIDs to them (this can be automatically assigned by the catalog). The
value of treating directories as LFNs is that one can refer to a directory path in a similar
way as a reference to a file. In this specification we allow the creation and removal of
directories and references to them, so that systems that support this feature will be
accessible through the RRS. This is shown schematically in the box referring to LFNs in
Figure 1 by having the directory icon in it.
A common use case for using multiple LFNs is that a file is first registered with a
particular LFN, and then additional LFNs are allowed to refer to the same file. The
original registration is sometimes referred to as the "primary LFN" directory structure,
and subsequent references to it are referred to as "secondary LFNs" or as "LFN-aliases".
We do not find this distinction generalizable, useful, or necessary. Therefore we refer to
all LFNs in the same way regardless of when they were defined. Thus, the RRS interface
does not permit references to "primary LFNs" - only to LFNs.
Finally, the power of symbolic links as provided with common file systems is also
considered useful. We make symbolic links visible through the RRS interface, by
allowing definitions of links as well as including them in LFNs path names. Note that
symbolic links are not assigned GUIDs since they point to other GUID objects. This is
shown schematically in figure 1 by an arrow pointing from the LFN box to itself.
Symbolic links are simply directed pointers from an existing LFN to another.
In this specification we assume that there is a way to distinguish between GUIDs, LFNs,
and SURLs from their format structure. The easiest way to do that is to use a URI
structure and the corresponding protocol labels. Thus, for GUIDs and LFNs the URI
format will have a protocol label "guid" and "lfn" respectively. For example:
lfn://star/runl2/filel7.raw (this is an LFN of a file)
lfn://star/runl2 (this is an LFN for a directory)
guid://123456 (the GUID value can be any string)
All other protocol labels will be considered SURLs. Examples of such protocols are:
gridftp, ftp, http, srm (for files managed by SRMs). For example:
gridftp://cs.bnl.gov:4004/tmp/run12/file17.raw (this is an SURL for a file)
srm://cs.bnl.gov:4004/tmp/run12/file17.raw (this is also an SURL for a file)
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
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
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/4/: accessed April 20, 2019), University of North Texas Libraries, Digital Library, https://digital.library.unt.edu; crediting UNT Libraries Government Documents Department.