Project 3 - Distributed Resource Sharing

Client-Server Interfaces, Spring 2003

Due Date
Background
The Project
Comments

Due Date

This assignment is due on May, 6 May, no later than 2:00 p.m.

See the assignment turn-in page (last modified on 25 February 2003) for instructions on turning in your assignment.

Napster-like resource-sharing (NLRS) systems implement a quasi-distributed approach to making files available over the Internet, in contrast to, for example, FTP, which provides a centralized approach.

NLRS systems comprise two different client-server subsystems, called the the Directory and Supplier subsystems. A Supplier subsystem is responsible for providing files to clients; the Directory subsystem is responsible for keeping track of the available Supplier subsystems. A complete NLRS system comprises one Directory and zero or more Suppliers (a system with zero Suppliers won't be able to do much, but it's still a valid configuration).

Client interaction with a NLRS system is has three phases, of which the middle one is optional. Suppose client program C is looking for a particular resource (a file, say) and wants to use a NLRS system N to find the file. C performs the following:

Send a search request to N's Directory and receive a reply listing, for each resource R requested, the Suppliers (if any) that can provide R.
Send a ping request to each Supplier S to determine if resource R is available from S. The reply from S not only indicates R's availability, but also some indication of the load on S at the time it handled the ping request.
Based on the ping replies, client C selects one or more of the Suppliers that can provide resource R and sends a resource request to the selected Suppliers.

For example, the event diagram

shows a client C searching for some resource and receiving from D the reply that Suppliers S1 and S2 have the resource. C pings both suppliers and decides that S2 is faster, and makes its resource request to S2.

The Directory D and Suppliers in a NLRS system N also interact:

As each Supplier S starts, it sends a registration request to D. The registration request contains the resources that S can provide to N's clients , and gives S's IP address and port number. The reply from D indicates whether or not D as accepted S into N. Reasons for rejecting a registration request include incorrect Supplier address or resource limitations at D.
D occasionally makes ping requests to each of its registered Suppliers. If the request fails, D unregisters that Supplier. This ping request can be similar to the ping request made by clients, although it need not be because the only thing D is interested in is whether or not the Supplier is still running.

The Project

Implement an NLRS system using RPC. All communication between clients, the Directory and the Suppliers (that is, all inter-process communication) should be provided by the sRPC system you implemented for the second project.

Notice that only clients are pure RPC clients; they only make requests and receive replies. Both the Directory and the Suppliers act like RPC servers and clients. For example, the Directory replies to clients' search requests and make ping requests to registered Suppliers.

Comments

Your NLFS system may serve arbitrary resources, but files are probably the easiest to deal with.
Search requests should allow the possibility of returning more than one resource reference to satisfy the search. For example, when serving files, the Directory should be able to perform command-line-style pattern matching using ? to match any single character and * to match zero or more characters.
Assume an NLFS system uses at most nine Suppliers at once, although you may support any number of Suppliers if you want.
You should submit both your NLRS system and your sRPC system.
You may modify your sRPC implementation to include two new input parameters on the server-side initialization call-spec:
```
call initialize
in  int             argc
in  array of string argv
out string          emsg
```
Your server-side main can then construct the new in parameters from its own argc and argv and pass them along in the call to initialize().
This change may be useful to, for example, pass in the directory's host and port number to a supplier so it knows where to register.

This page last modified on 28 April 2003.

Project 3 - Distributed Resource Sharing

Client-Server Interfaces, Spring 2003

Table of Contents

Due Date

Background

The Project

Comments