CIS307: Homework 5: Communicating through Sockets and using RPC

Given November 18, due December 8 by 8pm.

It is a continuation of homework 3. Now there will be two separate store managers. One is STORE_MANAGER_S and communicates with clients using sockets. The other is STORE_MANAGER_RPC and communicates with clients using Remote Procedure Calls (RPCs). Apart from that, the two servers are identical. The servers are started from the Unix shell and are called without command line parameters.

Each client, RAND_PROC, will contain three threads: one to interact with the user [the user can ask for statistics (number of reads/updates started and completed with each server), or it can terminate the client], one to interact with STORE_MANAGER_S, and one to interact with STORE_MANAGER_RPC. Each client is created at the command prompt and receives for STORE_MANAGER_S server the IP name of its computer and its port and for STORE_MANAGER_RPC it receives the IP name of its computer [so we have, in addition to the name of the client program, three parameters] . Each client will use a datagram socket to communicate with STORE_MANAGER_S and it will send messages to it (as identified by the IP and by the port specified in the command line) through this socket and will retrieve messages from this same socket. Each client will interact with STORE_MANAGER_RPC using remote procedure calls [see class notes and the hints for this homework]. You will run at least four clients.

STORE_MANAGER_S is called from the Unix interface without any parameter. It obtains a port from the system and prints out the id of this port. It creates a datagram socket, and it binds it to this port. Then it waits to receive messages from the clients. When it receives a message from a client, it creates a thread and gives the request to it together with information on the requestor (the thread needs this information in order to send information back to the requesting client). The thread will take care of this request, the Store Manager will not worry about it any longer. The thread makes sure that at most three threads are currently active. If more are active, it will wait on an appropriate condition variable until the desired condition becomes true. The thread then carries out the request (starting the operation, sleeping a bit since the read and update operations are assumed to be slow, and then completing the operation) and sends back a reply on the requestor's socket. The thread then terminates. Since a number of threads will be executing concurrently and sharing the table, you will need mutexes to enforce the appropriate mutual exclusions on a per table-entry basis. In the meanwhile STORE_MANAGER_S waits for and services the next message which it handles in a similar way. The user can terminate this server with an appropriate kill command from the command line.

STORE_MANAGER_RPC is just like STORE_MANAGER_S, only now it interacts with the user by responding to its RPC calls. Again the user can terminate this server with a kill command.

Both the clients and the servers will use timeouts when waiting for messages. At the timeout they print a warning message and then they go back to waiting. Clients and servers will log to their private log files all the messages that they send or receive.

ingargiola@cis.temple.edu