UNIVERSITY OF NEBRASKA AT OMAHA Computer Science 3550 Section 002 Communication Networks Spring 2018 Programming Assignment 3 Introduction Having created a TCP client in programming assignment 2, it s only natural to create a server in programming assignment 3. And that s what we ll do! The goal of the server is to provide a simple chat facility. Although it will only support a simple chat client, you should be able to see how it could be expanded to provide expanded functionality. The server you will create will handle chats among a somewhat arbitrary number of clients. We ll assume at most 5 clients can be used, but that s just an arbitrary number. It should be easy to redefine the maximum number of clients. There will be a unique TCP port number specified for the server (on the command line); the host IP address of the server will naturally be the local IP address associated with the system on which it is running. You will be provided with a complete client chat program that can use the server you create. As a result, you should be able to develop and test your server on any system to which you have access, including (for example) a laptop assuming it has the appropriate software to develop applications in the language you choose. Once the chat server is running, it will continually loop, waiting for one of three events to occur: a connection request from a client, a termination indication from a client, or the arrival of data from a client. Let s consider what s done for each of those events. A connection request will be accepted and recorded if the maximum number of active clients hasn t yet been reached. Since we re allowing 5 clients at the same time, the data structures you use can easily be statically allocated for that many clients. Several obvious data items that will be needed for each client will be the client status (connected or not connected), the socket used to communicate with the client (if the client is connected), an any partial part of a line that might have been received so far. When a complete line has been received from the client (that is, we read an end of line character from the socket), we will send that line to each of the other currently-connected clients. A disconnection request is accepted and processed as you might expect: the server closes the socket used for its connection with the client, and all record of the client is cleared. That is, the data structures used for the terminating client are made available for another client. The only other event the server deals with are the arrival of data from a client. When one or more bytes of data arrive, they are copied to a per-client buffer (as mentioned above). Eventually we expect a client will have sent a complete input line (which we ll assume is at most 100 characters long, including the end of line character). When that happens, that line of input will be sent to each of the other currently-connected client programs. If a client disconnects before sending a complete line, any partial input line that is in the buffer will be discarded.
The Sample Server (Instructor s Solution) The instructor s executable solution for the assignment is provided for your use in the class directory on loki. It will accept the s and v options. The s option will cause input lines to be sent to all the other connected clients and the client that sent the input line. The v option is used to display verbose output. These options need not be implemented in your server. Additional details on how to start and stop the server are described later in the assignment. Server Actions The server will perform the following steps in the order specified: 1. [GET PORT NUMBER] Get a port number between 1024 and 65535 (inclusive). This is the port number to which clients will direct their connection requests. We ll call it the SERVER PORT, and the associated socket will be called the SERVER SOCKET. If the selected port number you choose is already being used, you ll get an error when you attempt to bind it to a socket; in that case, just run the server again with a different port number. 2. [CREATE THE SERVER SOCKET] Create a socket for use with TCP and associate it with the port number obtained in step 1. (This is where an error will occur if the port is already in use.) You can see how to do this in C by looking at the server code on page 505 of the text or the passivesock function in the library provided in the class directory on loki. 3. [INITIALIZE STATE] Initialize the state of all possible clients (you should allow at least 5). Initially, no clients will be active (that is, connected to the server). 4. [WAIT FOR AN EVENT] Wait for a new connection request from a client, a connection termination, or for some data to become available to read on one of the active connections. Depending on which event was detected, go to step 5, step 6, or step 7. The details of identifying an event will be discussed in more detail below. 5. [HANDLE A NEW CONNECTION REQUEST] If a new connection is being requested, accept the connection, record the identifity of the connected socket on which data will be read or written (returned by the accept system call in UNIX/Linux) in the appropriate data structure associated with the client, clear the buffer to be used for incoming lines of text from the connection (set its length to zero), and return to step 4. (If the maximum number of active connections permitted by the server has already been reached, then just accept the connection, immediately close it, and return to step 4.) 6. [HANDLE A CONNECTION TERMINATION] When a previously-active connection is terminated (because the client closed its socket), close the corresponding connected socket, then mark that connection as inactive and return to step 4. 7. [HANDLE ANY INPUT DATA] Otherwise (that is, if it s not a new or terminated connection event), read a byte of data from the appropriate socket (which is associated with the connection that has data ready to be read) and add it to the end of the appropriate buffer (associated with the connection). If the byte just added contained an end of line character, then send the line to each of the other active connections and clear the line (that is, set its length back to zero). Optionally you could send the line back to the client that produced it; that s what the -s option requests in the instructor s solution. Return to step 4. Note that there is no event associated with server termination. Indeed, there is no specification of how the server should be terminated. Ideally there should be some means for terminating the server other
than pressing control-c in the terminal window associated with the server process. However that isn t required, and no specific mechanism is specified in this assignment statement for that task. Details There are a few additional points that you ll need to consider in your implementation. The most complicated point to deal with is determining what event caused the wait in step 4 to terminate. As noted there, there are three possible events that must be handled by the server: (a) a new connection is being requested, (b) an existing connection is terminated (because the client closed its socket), and (c) incoming data is available to be read from the socket. How do you know which of these three will occur next? If you assume a connection request will arrive and do an accept on the server socket, then you won t be able to process any incoming data (from an already-connected client) until a connection request does arrive. Similarly, if you assume data will arrive next and do a read on a connected socket, you won t be able to process any new connection requests until some data arrives. It almost appears that you have to be clairvoyant to write the appropriate code to handle these cases. But the situation isn t quite that grim. There are several ways we can proceed. MULTIPLE THREADS One way to handle this problem is to create a separate thread for each connected client (at the time it connects). The main thread, after performing appropriate initialization tasks, continually waits on connection requests. Each time one arrives, it is accepted and a new thread to handle communication with the client is created. This is very similar to what happens in a web server, except that the threads are usually created in advance of their use, and are just waiting to be assigned some work. The thread for a connected client can safely block when it tries to read data from the connected socket, since even if that thread blocks, the other threads in the program will be able to continue execution. DETECTING CLOSED CONNECTIONS As with the second assignment, it may be most appropriate to read data from the connected socket one byte at a time (although this isn t required), and note the number of bytes actually read. Any attempt to read data that indicates 0 bytes were read is an indication that the connection has been closed (in C and C++ code using the read or recv system calls); in Java, the read method applied to a socket returns 1 if the socket was closed by the client. In this case, the server s end of the connection should also be closed, and the state of the corresponding connection should be updated. If a separate thread is used to handle each connected client, the thread should terminate after the corresponding connection has been closed. SINGLE THREAD WITH SELECT Another approach to dealing with the multiple cases is to use the select system call (if you re using C or C++), or perhaps using a Selector object in Java. Since the UNIX select system call is more frequently used, we ll consider it here. Simply stated, the select system call causes the executing thread to wait until an event of interest occurs on one of the file descriptors specified in a set. Since sockets are also effectively file descriptors, we can use the select system call to wait until one of the events in which we re interested has occurred. Here s some simple pseudocode to illustrate the approach. 1. Create a set containing the server socket s file descriptor and the file descriptor associated with each active connection. 2. Use the select system call to wait for an event of interest on any of the file descriptors in the set. When the select call returns, we know that at least one file descriptor is ready for processing (or an error occurred, which we ll ignore in this pseudocode), and the set (created in step 1) has been modified to contain just those file descriptors of interest.
3. If the server socket s file descriptor is in the set that was produced by step 2, we know a new connection request has been made. That new request is handled (as specified above in Server Actions, step 5), then we continue at step 1. 4. If we reach this point, we know that at least one of the sockets connected to a client has data to be read. It can be read here and added to a buffer for the connection. If the incoming character was an end of line, then we can also write that line to each of the other active connections. In any case, we continue with step 1. Another issue that may arise if you write your own client is similar to that just discussed for the server: when do you read the keyboard and when do you read the socket? These can be handled in the same way in a client (using threads to separate the work, or using the select system call to identify the next event). But in the client we want to avoid writing an incoming line (from the server) to the terminal until there is no partial user input line in progress. For example, suppose you want to send a line containing Hello, world to the other clients. But after you type the comma, a complete input line arrives from the socket. The client should avoid writing that line in the middle of the echo of the keyboard input. This isn t a server issue, however. Finally, the thread-based solutions will in a robust solution require some method for synchronizing access (from the threads) to the shared data structures. It is unlikely that you ll run into difficulty in testing if you don t provide the synchronization. And since things like semaphores and mutexes and other synchronization facilities are more properly the domain of an operating system class, we ll ignore them here. Notes and Restrictions Your solution may be written in the C, C++, Java, or Python3 programming language. It must accept a single command line argument indicating the port number to be associated with the server socket. One of the instructor s executable solutions has been provided on loki.ist.unomaha.edu in the directory /home/stanw/csci3550/prog3. A C-based client is provided in source code for your use, but it works with servers written in any of the allowable languages. It is called client3 and expects two command-line arguments: the hostname (in symbolic or dotted numeric form) on which the server is running, and the port number associated with the server socket. The file /home/stanw/csci3550/serv3temp.java contains a simple template for a thread-based solution to the problem. Show below is the output (on loki) when the C server and two clients were executed. Note that the C server has been designed to terminate gracefully when it receives a SIGHUP signal (which is signal 1). The Java server must be interrupted with a SIGINT signal (which is what happens when you press control-c in the window where the server is running). Note that three separate terminal windows were used; the content of each window is bracketed by horizontal lines. stanw@loki:~/csci3550/prog3$./serv3 50000 Server for assignment 3, CSCI 3550, Spring 2018 Accepting at most 5 connections on port 50000 Server process ID is 27189 stanw@loki:~/csci3550/prog3$ stanw@loki:~/csci3550/prog3$./client3 localhost 50000 Hello over there! I am a client for programming assignment 3. Well so am I! Will you get my message?
I did! I did! It appears everything is working fine. I concur. But this is boring, and I'm going to quit soon. Okay. So long. I'm going to press control-d now. And so will I. Of course, since the only other client has terminated, no one will see this input. stanw@loki:~/csci3550/prog3$ # We'll kill the server now stanw@loki:~/csci3550/prog3$ kill -1 27189 stanw@loki:~/csci3550/prog3$ stanw@loki:~/csci3550/prog3$./client3 localhost 50000 Hello over there! I am a client for programming assignment 3. Well so am I! Will you get my message? I did! I did! It appears everything is working fine. I concur. But this is boring, and I'm going to quit soon. Okay. So long. I'm going to press control-d now. stanw@loki:~/csci3550/prog3$ Evaluation Submissions will be evaluated as follows. 1. Extraneous files in the submission directory will be deleted. For each one deleted, the overall score for the assignment will be reduced by one. A group effort with multiple submission directories will lose 10 points for the duplication. 2. The program will be compiled and linked as necessary. If this fails, and it looks like there is some reasonable effort to produce a solution, a grade of 50 percent will be recorded. 3. The server program will be started. If that fails, a grade of 60 percent will be recorded. 4. In a second terminal window, a client will be started and several lines of arbitrary text will be entered. Failure here will result in a grade of 65 percent. 5. In a third terminal window, another client will be started. As before, several lines of arbitrary text will be entered. These should appear in the second terminal window (that is, sent to the first client). Failure here will result in a grade of 75 percent. 6. Input text for the various clients will be entered and the behavior of the server will be assessed. Thins like limits on the number of clients (5) and the input line lengths will be examined. Depending on the results, a grade between 80 and 100 percent will be reported. Requirements You must write and test a program that functions as a server for up to five chat clients at a time. Your solution may be written in C, C++, Java or Python3. You may use the library of functions provided on loki in your solution. The solution must be submitted by Tuesday, May 1, 2018. You may work in groups of two on this assignment if you wish. If you do, it is absolutely essential that you (a) make certain both of your names appear in all of the source code files you submit (likely as comments), and (b) you only create one submission directory into which you put your joing submission. The same evaluation will be given to each member of a group effort. The source code file (or files) for your solution should be placed in a directory named csci3550-181-prog3 immediately below your home directory. For example, if your username was brenfro,
your home directory would probably be /home/brenfro and your solution s source code would be placed in the directory /home/brenfro/csci3550-181-prog3. There should be nothing but source code files (and perhaps a Makefile and/or a readme file, as needed) in your submission directory. DO NOT CREATE THE SUBMISSION DIRECTORY UNTIL YOU ARE READY TO SUBMIT YOUR WORK. GROUP EFFORTS SHOULD HAVE ONLY A SINGLE SUBMISSION DIRECTORY FOR BOTH MEMBERS. As always, please contact the instructor if you have questions, and periodically check the class web site for any additions or corrections to this assignment.