next up previous
Next: Related Work Up: Resource Cataloging and Distribution Previous: Scalability

Current Implementation

We have implemented the catalog and location server in a single piece of software called rc_server. The server replicates its database using a simple replica updating scheme based on journal files. A more sophisticated replication scheme is needed. The catalog servers currently use shared secrets for symmetric authentication of udpates; public key authentication would be better.

We have modified the popular ftp-mirror replication tool to update a RCDS location server when a file is mirrored. We are developing a high-performance bulk file transfer tool called blitzfer which uses multiplexing and compression and supports checkpoint and restart.

We have written a publication tool that extracts a resource description from the results of filling out an HTML form, signs the description with RSA, and uploads the resource files to a designated file server.

We have implemented an HTTP proxy server that acts as a RCDS client. We have modified an older version of Mosaic to understand RCDS. We will modify the new redesigned Mosaic to be an RCDS client as soon as it becomes available. We are also looking at the possibility of an Active X plug-in for use with Microsoft Explorer.

Our initial implementation of SONAR sends ICMP echo requests to each of the addresses for which a proximity measure is desired, and uses the time between when the request is sent, and when an ICMP echo reply is received, as its metric for evaluating relative proximity. Round-trip-time estimates obtained using ICMP are cached for a certain amount of time (currently several hours) so that subsequent SONAR queries within that time do not result in generation of additional ICMP requests. Any ICMP ``unreachable'' replies are also noted, though these are cached for a smaller amount of time. We are investigating alternative algorithms for measuring proximity that place less load on the network.

A testbed for RCDS has been established at five geographically dispersed US sites (University of Tennessee, Syracuse, Rice, CalTech, and Argonne). This testbed serves as a platform to stress-test RCDS implementations and to provide a demonstration of RCDS technology. The RCDS testbed servers are being used to keep track of widely-mirrored network resources, including the Linux operating system and related software, the Internet RFC and Internet-Drafts repositories, the netlib software repository, and others. This provides a means to test the use of RCDS with resources that have large numbers of replicas.


next up previous
Next: Related Work Up: Resource Cataloging and Distribution Previous: Scalability

Keith Moore
Fri Feb 7 11:53:58 EST 1997