Question

Objective: Create programs that are run independently and can use simple IPC using FIFOs/named pipes to pass information back and forth in a client/server fashion. The information/request from the client will look like simple semaphore system calls and will include information for the server to be able to identify which client requested it and what request it is and its associated parameters.

This assignment requires the analysis, implementation, testing and documentation of two C program that use C on the Linux server sapphire or your own Linux box or virtual machine. A server program and a client program that will be run concurrently.

Server program:

The server program will implement ONE semaphore that multiple clients can issue request to lock and unlock.

Server program will be an iterative server which can receive requests from multiple clients, although it process the requests in a serial fashion, one at a time, i.e., request from client one, request from client three, request from client two etc. So,

• Server will need to create a well-known FIFOs where it will read its inputs from the clients and open it in READ mode (will block of course until a client opens the fifo in write mode). After the first client connects, the server should also open the well known fifo in write mode, to prevent the server from quitting when there are no clients connected.
• Server will then go into a loop to read from the pipe to receive requests from clients that will consist of the following types of request:
  1. Requests from a new clients asking to “connect” to the server, this requests should include the client ID/number and the name of that client-specific FIFO (used by the client to receive replies from the server). Server should open that FIFO in WRITE mode, save the file descriptor and the client ID/number into a CONNECTED CLIENTS table for use when replies need to be sent to THAT client.

2. 1-System call-like Request from a connected client requesting to “lock the semaphore” – a wait request. If the semaphore is free (unlocked) a reply should be sent immediately to the client indicating the semaphore has been locked the reply would allow the client to continue. If the semaphore is not free (locked by another client), the request (client) should be put in a wait queue and NO reply should be sent to the client (which will effectively block the client from continuing at this point.

3. 2-System call-like Request from a connected client requesting to “unlock the semaphore” – a signal request. At this point, if no other client is waiting for the semaphore, the semaphore should be unlocked and a simple ack reply should be sent to the client. If at least one client is waiting for the semaphore, in addition to the ack sent to the client doing the signal request, one of the clients waiting for the semaphore should be removed from the wait queue and a reply should be sent to THAT client indicating that it now owns the semaphore and effectively unblocking it and allowing it to continue.
4. Client request to disconnect from the server. In this case, the server should reply with an OK message to that client and then close THAT client’s fifo and remove the client’s entry from the CONNECTED CLIENTS table.

5. There should be a “special request-STOP” that can be sent by a client to indicate to the server that it should close all fifos and terminate (this is not normally part of a standard server code which should run indefinitely, but will give you a way to gracefully shutdown the server. This should ONLY be processed if the client requesting it is the last connected client.

After each of these five types of requests, the server should print to the screen enough information to show which client is requesting and what the request was (client ID/number, type of requests, and associates parameters if any). It should also print the reply being sent.

Client Program:

The client program will “connect” to the server through the well-known FIFO and send requests through it to the server, more specifically, the client program should:

• Acquire from the user (through the command line or reading from the keyboard) what the client number this instance of the program will be (i.e., client 1, client 2, etc.)
• Open the well-known server’s fifo in write mode to communicate with the server (which will unblock the server from its fifo open call)
• Create the client-specific FIFO using an appropriate name (e.g., ClientNfifo, where N is the client number) and send the initial “connect request” to the server including Client number AND name of the client-specific FIFO.
• Open the client-specific FIFO in READ mode to be able to read replies from the server. This will block the client until the server opens the fifo in write mode.
• After this, the client should go into a loop that will run for a predetermined number of times (say 30-50 times) after the loops (described below) is run the client will ask the user what to do next? providing three choices:
  • 1 – Run the loop again

• 2 – EXIT - indicates THIS client does not want to issue more requests to the server, it should close its pipes and exit.

• 3 – STOP - indicates THIS client does not want to issue more requests to the server, and it should also send a STOP request to the server (so that it can gracefully terminate) before closing its pipes and exiting. No more clients can connect to the server after this.

Description of the loop:

The body of the loop will consist of:

{

          // NON – CRITICAL SECTION

An inner loop that will also run 20-30 times where the client will continually print a message (maybe every second or so) to the screen indicating that it is processing in its NON-CRITICAL SECTION

After the NON-CRITICAL SECTION LOOP the client should print a message:

          WAITING TO GET INTO THE CRITICAL SECTION

          *Send a wait request to the server (locking the semaphore) and wait for a reply

          // CRITICAL SECTION

An inner loop that will also run 20-30 times where the client will continually print a message (maybe every second or so) to the screen indicating that it is processing in its CRITICAL SECTION

          After the CRITICAL SECTION LOOP the client should print a message:

          LEAVING THE CRITICAL SECTION

          *Send a signal request to the server (freeing the semaphore) and wait for a reply

}

** You should implement a Wait and Signal function that are called from inside the loop when appropriate. The Wait function should send a wait request to the server and expect a reply before returning. The Signal function should send a signal request to the server and expect a reply before returning.

Answer 1