HW5 - Threaded TCP Chat Server
Due Date: April 29th by 11:59PMNew Date
Late Policy
IMPORTANT: This counts as two homeworks!
- Chat Server
The objectives of this assignment are:
- Basic Sockets programming (TCP).
- Threads programming
You are to write a threaded TCP based chat server. Your server must support the application level protocol described below. Your server must use threads to support multiple clients, you can limit your server to handling 10 clients at a time.
Service Overview
Each client will use a TCP connection to communication with the server, all chat messages are sent to the server, which then send messages on to any appropriate clients. The server supports two different kinds of chat messages:
- broadcast messages that are sent to all active clients
- private messages that are sent to (at most) a single client
In addition to forwarding chat messages, the server also manages usernames (makes sure that there are never two users with the same username), can supply status information to clients (a list of who is currently logged in), and help information (a list of the commands supported by the server).
Application Protocol
All communication takes place over TCP connections, the server is available via a "well-known" address (the clients must know the server IP address and port number). Clients send individual commands to the server, and the server responds to commands with a response line. The server can also send messages any time it want (not as a response to a comand received from the client), this is how actual chat messages are sent from the server to the client. Clients do not ask for incoming messages, they can arrive at any time. Both the commands (client->server communication) and responses (server->client communication) are single lines of ASCII text terminated by a single '\n' character. The format of commands and responses is shown below.
Commands (sent from client to server)
There are two different types of commands that can be sent by the client, distinguished by the first character of the line containing the command. If the first character is '/', the rest of line contains a special command that asks the server to take some specific action. If the first character is not '/', the line is assumed to contain a chat messages that should be sent to all active clients (a chat broadcast).
Special Commands:
/login username : client is attempting to login to the system using the specified username. The username cannot contain any whitespace, the server should ignore anything additional on the line (only the second token on the line should be used as the username).
/priv destuser message ... : client is requesting that the server forward the message to a single users (a private message). The destuser must be logged on for this to work, the server is not expected to queue private messages. Everything after the destuser is the actual message to be forwarded.
/help: client would like a list of all supported commands.
/who: client would like a list of all current users (a list of usernames).
/quit: client is terminating the connection (this is a polite quit).
Server->Client communications (Responses and messages)
There are two different responses that the server can send to the client, these are distinguised by the first token on the response line. This first token should always be in uppercase and must be the first text on the line (no whitespace before the response type). The response types are shown below:
ERR error message text ...: Server is indicating some kind of error condition. There are no established set of possible error messages, and clients are not expected to do anything with an ERR other than alert the users that the server has sent an error response.
OK some message ...: Server is responding to the previous command, indicating that everything seemed to work ok. Clients are free to ignore OK messages, or to show them to the user.
The server can also send chat messages at any time. Each chat message has the following format:
MSG some message ...: Server is sending a chat message to the client. The server is free to format the message any way it wants, for example it can include information about who sent the message, whether it was private or not, etc. Servers will generate MSG responses asynchronously (whenever they want - not as a respond to any command from the client).
Servers forward chat messages as MSG lines, and also respond to some commands (for example the /help and /who commands) with MSG lines.
Sample Conversation
The following is one possible conversation that takes place over a TCP connection. The client-to-server communication is shown in blue, the server-to-client communication is shown in red.
/who ERR You must login first! /login fred OK welcome fred /help MSG Commands supported: MSG /help MSG /login username MSG /who MSG /priv username message... MSG broadcast message... /who MSG Current Users: joe fred sam sally Hello folks! MSG fred says: Hello folks MSG joe says: Go away fred MSG sam says: yeah - fred take a hike MSG sally says: Don't listen to them fred, stick around /priv sally thanks, I'll stick around. OK private message to sally sent MSG joe has logged out. MSG private message from sally: no problemo. MSG sam says: Never mind, I'm outtahere... MSG sam has logged out. MSG sally has logged out. Hello? MSG fred says: Hello? /who MSG Current Users: fred /quit OK goodbye. |
Protocol Rules
In general, application protocols have lots of rules that specifiy what kind of messages can be sent by whom and at what place in a conversation. For example, some protocols require that the server sends some kind of status messages after every request received. We've tried to provide a protocol with no rules (to make the project simpler), but there is one rule that your server must enforce:
The user must login before any other command will work
Other than the login rule, there is are no requirements in terms of what the server should send back to the client in response to each type of command received. Use common sense, if the command is not recognized by the server - send back some kind of error message, etc.
Testing your server
The telnet program allows you to establish a TCP
connection to any TCP server you want (you need to give telnet a
hostname and port number on the command line).
There is a sample client that may be a little nicer to use than
telnet (separates incoming messages from what you are
typing). The code is here.
Be aware that the client program has some restrictions - you can't
resize the terminal window while the program is running, and it is
kinda stupid in terms of how it handles various messages. Basically
the client forwards everything it reads from the user without
modification, and displays all ERR and MSG messages received from the
server (OK messages are ignored).
- Project Requirements
The following are the requirements for the project:
Your program must compile and run on the CS department FreeBSD machines (
freebsd.remote.cs.rpi.edu). You can use C or C++, if you want to use something else ask Dave first.Your server must support the protocol described above.
Your server must support at least 10 clients at once.
Your server must use threads! The general idea is to have a thread for each client (waiting for incoming messages from a client). When a client sends a chat message, it's thread can send messages to all appropriate clients. In this scenerio all threads will need to share some global data structures and make sure that only one thread at a time is using/updating the data structures.
Your server can support more than the simple chat protocol mentioned above. Feel free to ask Dave for permission if you want to extend the service in ways that are not compatible with the above protocol.
Your submission must include instructions on how to build and run your server. A Makefile must be included.
Your submission must include a file named README that includes the following information:
- Your name
- A 1 line description of each file you are submitting
- A description of any problems you had, known bugs or deficiencies.
- Anything else you want us to know.
Grading: Your code will be graded according to the formula below. Note that to get full credit we must be able to understand your code (it must be commented!)
| 50% | Basic chat functionality (handles multiple clients, processes chat protocol properly). |
|---|---|
| 40% | Threads. It's actually easier to use threads than to try to do this any other way (you could also use I/O multiplexing using select() or poll(), but this would require some recordkeeping not necessary when using threads). |
| 10% | Code quality (comments, organization, how hard is it to understand ?). |
You can get partial credit for any part.
If you code does not compile and run under FreeBSD, you will lose at least 1/2 the relevant points ( partial credit will be awarded based on visual inspection of the code).
- How to Submit
Log in to WebCT at webct.rpi.edu using your RCS id and password. Once you get to MyWebCT click on "Operating Systems", and from there go to the homework drop boxes. Submit your files (individually, zipped or tarred) to the drop box labeled HW5.
-Resources