CIS307: Homework 5: Communicating through Sockets and using Threads

Given April 8, due April 21 by 5pm.

It is a continuation of homeworks 2, 3, and 4. Now communication between clients and server is not taking place in a single computer using pipes or accessing a shared memory. It is taking place across networks using sockets. We require that we will have at least three client processes.

The STORE_MANAGER is a server program running on a computer, say Snowhite.cis.temple.edu.
It is started from the Unix shell and it is called without command line parameters.
It obtains a port from the system and prints out its id.
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 a single other thread is currently active. If more are active, it will wait on an appropriate condition variable until the desired condition becomes true. [This means that we have at most two threads simultaneously active. Reminds me of counting semaphores..] 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 that same socket. The thread then terminates. Since a number of threads (two in our case) 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 waits for and services the next message which it handles in a similar way. [Implement the STORE_MANAGER first without using threads, mutexes, and condition variable, i.e. as a program that handles requests sequentially. Only after it works re-implement it using threads and mutexes. Only after that worry about the use of the condition variable.]

Client programs RAND_PROC are started from the Unix shell on the same or on different computers. Each RAND_PROC is given two command line parameters:

Each client program, RAND_PROC, will use its own process id as seed for the random number generator. RAND_PROC will use a datagram socket to communicate with the server. RAND_PROC will send messages to the server (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.

Both the client and the server will use timeouts when waiting for messages. At the timeout they print a warning message and then they go back to waiting.

The RAND_PROC program has the same structure as in Homework 4, only now the store operations instead of being implemented by creating/accessing shared memory, are implemented by communicating with the server through a socket.

RAND_PROC and STORE_MANAGER will log to their private log files all the messages that they send or receive.
The programs should keep operating correctly even if you launch a number of copies of RAND_PROC, perhaps on different computers.

STORE_MANAGER will terminate when we send to it from the unix shell the appropriate kill signal. The RAND_PROC processes are terminate by the users when they make the appropriate menu selection.

ingargiola@cis.temple.edu