Lab will require you to create a client and a server that communicate over either message queues, sockets, or a well known fifo. The data passed will be a simple request/response in string format. Each of the 3 methods will need to answer the problem of rendezvous in their own way. Suggested algorithms:
Server will listen specifically to a single key and respond to clients based on a key that was passed in the message to the server.
Well Known FIFOs -
Since Well Known FIFOs are "file" based and will require a name (hence the "well known" part), you should create a common header that defines the server read / client write FIFO as a const string for both. The server will respond to the client based on data passed through the Well Known FIFO to the server.
Every socket requires a tuple on both sides. Tuple being the IP address / Port / Protocol. Since sockets require "root" access for ports less than 1024, choose a port greater than 1024 for the server. Just like the well known fifo, you should create a common header file with a const integer for the server port number. Unlike the other IPC methods, the client and server in a socket dynamically exchange the path back to the client, so there is no need to "pass" that data to the server. Once you have chosen your method of communication, then define a simple dataset that can be used in a request / response loop. Examples could be that you have an array of phone numbers, and when the phone number is sent to the server it will respond with the person's name associated with that phone number. Any simple dataset with at least a name=value pair will work as long as you can look up the value based on the name. Simple structures with a simple searching algorithm up to using hash maps or search tree libraries are all ok. This assignment is more about the IPC and the semaphore than the dataset. So even something as simple as the process environment is fine (doesn't get any easier than that...) Your server will listen to incoming requests and then respond according to the client connection algorithm. You will also be required to add 3 server threads that will all block and wait to receive the client request based on a semaphore. Although the 3 methods of IPC all are based on queues, we will be adding a semaphore to only allow 1 thread to pull/pop a request from the queue, and once the request is taken by one of the 3 server threads, then it will release the semaphore allowing the other threads to take the next request from the queue. Here is an example of how the semaphore will work... You see 3 server threads T1, T2, and T3. Only one can be receiving from the Server FIFO Queue at a time, so the semaphore will lock out the other 2. When the T2 thread takes the request off the Server queue, it will immediately unlock the semaphore so the other threads can block for the next request on the queue. Right after the T2 thread unlocks the semaphore it will then process the request and send the response back to the client via the Client FIFO queue and then go back to request the semaphore and block until it gets the unlock from the semaphore and then blocks for the next request from the Server FIFO QUEUE.
Pseudo code for the server would be the following
requestSemaphore(); //Block until you get the green light
readFromQueue(); // Another blocking call (maybe no clients yet)
Keep in mind that it is important to lock critical regions more often and in the smallest block of code otherwise you would diminish the value of threading and concurrency. This lab will help you understand synchronization through message passing as well as a form of preballocation where the server already has 3 "worker" threads ready to accept client connections without the cost of creating a thread or fork/exec. You will also understand the use of blocking vs. nonbblocking I/O due to the way servers and clients need to manage their reads and writes in a way that will not create a deadlock. Please zip/tar your source code, script output file and design doc into a single file for submitting.