Program 5

TCP Card Dealer - child processes

For this program, you'll be doing something significantly different with your card dealer server. By now, you should have all the kinks ironed out in handling the cards (shuffling and dealing in a random order). Your server will still be using TCP to communicate with clients, but you will address the issue of how to deal with multiple client connections in a different way. Instead of trying to handle all of the clients from the main program, you will use Unix's ability to create new processes.

The main server process should spawn a child process each time it gets a connection request from a client. The child process is responsible only for handling the connection to the client, while the main server process is responsible for handling new connection requests and dealing the cards. For information on how to use fork to create a child process, see the section on Multi-client Servers in the Unix Network Programming Manual. I also have some more information about fork() from Unix Network Programming (both the first and second editions) by W. Richard Stevens.

Since the child is not doing any management of the cards, it will need to communicate with the main server process (its parent process) each time it receives a request. To do this, you will use pipes. For more information on pipes, see me for a section from from Unix Network Programming, 1st Ed. by W. Richard Stevens. The main program will now have to deal with its normal server socket (the one on which it calls accept()), plus multiple pipes to communicate with its children. Notice that the pipes are represented using integer descriptors; these descriptors can be used with select(), just like file descriptors or socket handles.

As an alternative to using pipes, the program can use stream pipes, which are similar but a little more convenient. I have some info from the second edition of the Stevens book about creating stream pipes. You are free to choose either IPC (interprocess communication) mechanism for your program.

The requirements for this program are thus the following:

Provide the same TCP interface to the client that the previous card dealer programs did
Provide the normal accept() loop in the main process
For each connection accepted, create a pair of pipes (or one stream pipe) and a child process
Handle the client connection in the child process and pass any requests from the client on to the main process using one of the pipes. Read the response from the main process on the other pipe and pass it back to the client
The main process must monitor its set of pipes and process requests from them just as previous versions did for a child connection
The main process must call wait3() each time through its main loop to make sure child processes can terminate
The child processes must handle the closing of the client connection - they should close the socket, and they must call exit() to terminate cleanly

Since the main server process needs to deal with its normal server socket, plus all the pipes that its children use to communication with it, you might suspect that this is not really saving that process any work. This is a true observation - for this particular application, the implementation using one process and the select() call is more efficient. However, this multi-processing approach has advantages when the work that must be done for each child request is more significant. Suppose for instance that each request requires a database query plus some length computations to generate the response. The use of multiple processes means that while some of them are blocked waiting on database query responses, others can be performing computations.

Design

There is not a lot of design work to be done here, but you should plan how you will control the child connections;will you use pipes or stream pipes? If you use pipes, which one is the parent to child pipe and which goes the other direction? Make sure you are comfortable with how fork works, and figure out how control will flow through the program after the fork to make sure that one path runs the child code and one runs the parent code. Do this before you start hacking on code.

Adding onto Your Code Library

You should continue to refine the library of socket functions - add routines to the server code that allow you to use select to manage a set of sockets on the server side. Clean up any code that might need it for both the server and client.

Assignment Submission

NO hard copy, please. Everything should be submitted via email by the due date - mail everything to Anthony. Follow Anthony's specifications for assignment submissions. You need to include the design, your source for the main application, your source for your library, and the output from your server for two different test runs. (You don't need to include any source for the client, since it should be the same as last time.) For the first test run, start the server with one deck and choose one of the ports designated for the lab (40000-40007). If your server can't open a socket on that port, try another one; you should succeed before you exhaust all eight possibilities. Start a client in another window and request twenty cards, shuffle, then request five more cards. For the second run, start the server with four decks, choosing the port as in the previous run, then start two different clients and request twenty cards from each. (These are the same test runs as you did for the last program.)

You should include the following:

Anything that you thought was particularly interesting or problematic in getting the program running and tested
The program design
The output of a run of the server with 1 deck
The output of a run of the server with 4 decks
The source for your server
The source for your library

The first item should just be in the body of the email - attach the design, source, and output as separate files.