Protocols

Because an understanding of some of the protocol details is important to understand how well RCDS achieves it goals, this section outlines important aspects of the protocols used by the current prototype.

RCDS currently uses a lightweight query-response protocol based on Sun's Open Network Computing Remote Procedure Call technology. Either UDP datagrams or TCP streams may be used. Unlike normal RPC applications which use a separate binding protocol to associate an RPC function to a TCP or UDP port, RCDS requests are sent to a ``well-known port'' on the server machine, cutting the network overhead in half.

There are currently five function calls:

1. update_name adds zero or more assertions and/or certificates to the catalog record for a URN or URL.
2. update_lifn adds a resource location (URL) to the list of locations associated with a LIFN.
3. query_name allows a client to obtain the catalog record (or portions thereof) associated with a URN or URL.
4. query_lifn allows a client to obtain the current list of resource locations for a particular LIFN.
5. create_uri allows a client to request that the server allocate a unique URN or LIFN in a particular domain. This is used by publication tools.

Although the catalog records and the locations are maintained separately, the server optimizes for the common case where a catalog record contains a LIFN whose locations are kept on the same server. In this case, the URLs associated with that LIFN are returned in the same response that contains the catalog record, space permitting.

For the update calls, authentication is accomplished by the use of a secret shared by client and server. The request, along with the shared secret and a timestamp, is used to calculate a 128-bit digest using a variant of the ``keyed MD5'' algorithm. This digest is transmitted by the client along with the request and the timestamp, but omitting the shared secret. The server computes the same digest using its copy of the shared secret, and compares the result it obtained with the digest included in the request. Only if the result matches is the client considered to be authenticated. The client must still have appropriate permissions to perform the request.

Replay attacks are thwarted (while allowing for duplicated UDP datagrams) as follows: the server keeps a copy of the last request id and the last result of any update call from a particular client. If the last request was repeated, the server repeats the response obtained from the previous call (which consists of a single integer indicating success or failure), without modifying the database. The client must increase the request id on each call; if the request id from a particular client is less than the previous request id, the request is considered to be a delayed duplicate and ignored.

Catalog records used by the update_name and query_name functions are composed of assertions and certificates. An assertion is essentially of the form ``A states that, as of time , the attribute named N of the resource named U had value V, and that this value is expected to be valid until time .'' A certificate is essentially of them form ``C warrants that, as of time , assertions '' are valid. A certificate also contains C's cryptographic signature, computed over and the contents of assertions .

Location records associated with a LIFN (and used by the update_lifn and query_lifn functions) consist of a URL, a cache retention time-to-live , and an expiration date . The cache retention time-to-live is a contract by the file server that supplied the binding, that it will notify the server at least seconds before making that file inaccessible to clients. Clients and caches should not use that LIFN to URL binding after has expired. The expiration date is an indication that