Fall 2018 CSE30264 Programming Assignment 3 - Online Chat Room
Total Points: 100 points
Goal: Program a Prototype of an Online Chat Room
Assigned: Oct. 3, 2018
Due: Oct. 31 , 2018 by the beginning of class Grouping: Completed by a group
Background
In this programming assignment, you will implement the client and server sides of an "online chat room" application. You can choose to use either TCP or UDP in your implementation. In this application, the client determines the operation to be performed: public messaging and direct messaging. Even though only one port is being used, the server should be able to accept multiple simultaneous client connections. The server should respond appropriately to the specific command send by the client. The specifics of the protocol are detailed in this handout. You are free to reuse part of your programs in the programming assignments 1 and 2 to finish this programming assignment. Note: please refer to appendix A for the port number assigned to you (the same as PG1).
Type of Messages
In this assignment, we define two types of message frames: 1) data message and 2) command message. A data message is the message exchanged between clients (i.e., the Public and Direct messages described in the following online chat room protocol). A command message is the message exchanged between the client and server (e.g., operation, acknowledgment, confirmation messages described below). In your implementation, you can define your own message format to encode the message type. For example, you can use the first character of the message to distinguish between the two types of messages (e.g., "C" for command message and "D" for data message).
Note:
In your implementation, the sender is responsible for encoding the type information into the message frame and the receiver is responsible for extracting the type information from the message and performs accordingly. (Refer to Technical Instruction section for more details.)
Online Chat Room
Server opens a port, creates the TCP/UDP socket, and goes into "wait for connection" state, and actively listens for socket connections. Hint: Please read the Technical Instruction Section below for details
Client logs into the system by connecting to the server on the appropriate port.
Client sends the username.
Server checks to see if it is a new user or existing user and requests a password. Note: Store users and their passwords in a file rather than in memory (otherwise the credentials will get lost once the server program is terminated).
Client sends the password.
Server either registers a new user or checks to see if the password matches. Server then sends the acknowledgment to the client.
Client generates a public key and sends it to the server. Note: multiple clients should be able to register at the same time.
Server continues to wait for operation command from a client or a new client connection.
Client goes into "prompt user for operation" state and prompts user for operation.
Client passes operation (P: Public Message, D: Direct Messaging, Q: Quit) to server.
Operation is executed as follows:
P:
Client sends operation (P) to broadcast a public message to all active clients (i.e., the clients who successfully log into the system but has not exited yet).
Server sends the acknowledgment back to the client to prompt for the message to be sent.
Client sends the broadcast message to the server.
Server receives the message and sends that message to all other client connections. Note: The server should keep track of the socket descriptors it has created for each client since the program began running. You can decide how to implement this tracking function.
Server sends confirmation that the message was sent. Note: You can decide the content/format of the confirmation.
Client receives the confirmation.
Client and server return to "prompt user for operation" and "wait for operation from client" state respectively.
D:
Client sends operation (D) to leave a message to a specific client.
Server sends the list of current online users. Note: The server should keep track of the usernames of all online users (i.e., users associated with active clients) since the program began running. You can decide how to implement this tracking function. We assume that any client can go offline by using operation (Q).
Client receives the list of online users from the server.
Client prompts the user for and sends the username (of the target user) to send a message to.
Client sends the username to the server, and the server replies with the user's public key
Client then prompts for, encrypts, and sends the message to be sent.
Server receives the above information and checks to make sure the target user exists/online.
If the target user exists/online, the server forwards the message to the user, which decrypts it and displays the message. The server should do this by sending the message to the corresponding socket descriptor of the target user.
Server sends confirmation that the message was sent or that the user did not exist. Note: You can decide the content/format of the confirmation.
Client receives the confirmation from the server.
Client and server return to "prompt user for operation" and "wait for operation from client" state respectively.
Q:
Client sends operation (Q) to close its connection with the server and end the program.
Server receives the operation and closes the socket descriptor for the client.
Server updates its tracking record on the socket descriptors of active clients and usernames of online users.
Client should close the socket and return.
Note: If it is not explicitly specified, the client and server will return to "prompt user for operation" and "wait for operation from client" state respectively after a successful operation and wait for the next operation.
Technical Instructions
Multithread Server: The server must be able to monitor and handle messages from multiple clients simultaneously. This can be done using multithreading. We encourage you to use pthread library.
Basically, you will need a main thread to listen to all new connections. This can be done using the socket accept function within a while loop. This main thread is just your main program. For each connected client, you will need to create a new thread using pthread_create() method. You can set a threshold (e.g., maxThreadNumber=10) for the total number of threads.
A multithreaded server implementation example can be found here.
Multithread Client: The client must also be able to handle concurrent messages from multiple origins (e.g., command messages from the server and data messages from other clients). This should be done using multithreading as well. In particular, each client should have one thread (e.g., thread1) to collect all messages from the socket and another thread (e.g., thread2) to parse and react to those messages. Note that the main program itself is a thread so you only need to create one extra thread. The client will also need to identify the type of the messages it received and perform appropriately based on the application protocol (e.g., if a data message is received, the client simply prints out the message; if a command message is received, the client should continue the interaction with server based on the command message).
Note: When using the (Q) command to quit, make sure all threads are properly terminated. Specifically, you should terminate the main thread after the extra thread has finished its job. This can be done by using the pthread_join() method.
Use the library pg3lib.h (available at /afs/nd.edu/coursefa.18/cse/cse30264.01/files/program3/pg3lib.h) to simplify the implementation of cryptography for direct messages. The library contains the following methods::
/* Generate and return an encryption key
* (won't generate a new one if one exists already)
* return: this host's encryption key
*/
char* getPubKey();
/* Encrypt a message with peer's encryption key
* char *message: plaintext message to encrypt
* char *pubkey: peer's encryption key (formatted as output to getPubKey())
* return: base64 encoded ciphertext
*/
char* encrypt(char *message, char *pubkey);
/* Decrypt a message with this host's private key
* char *cipher: base64 encoded ciphertext
* return: decrypted plaintext message
*/
char* decrypt(char *cipher);
To ensure multithreading is working correctly on both client and server, you can perform the following simple tests:
Try logging/registering with multiple clients with the server at the same time. One client's login process should not block any other clients.
Reach a state where a server is prompting client 1 to type in some message (e.g., after client 1 sends a (P) command). Then send a direct message to client 1 from client 2. Client 1 should first print out the message from client 2 and then return to the prompt state.
Note: A simple test scenario of your implementation: three clients and one server. You can run three clients on three different student machines and run the server on any of the three machines where you run the client or on a fourth student machine. You can then easily test public messaging, direct messaging and multithreading in this scenario.
General Notes
Your code may be written in C or C++. You should create two separate directories under the
dropbox/program3 directory, a server directory for the server code and a client directory for the
client code.
Each directory should contain a Makefile for building your code appropriately.
Don't forget that the Endian-ness matters. Use htons / ntohs in order to encode a 16 bit (short) value for transmission. Use htonl / ntohl for 32 bit (int) values.
To determine the size of files, you may want to use the fseek (or equivalent ifstream operation) function and/or the peek operation. For efficiency reasons you probably should not "roll your own".
When in doubt, add in extra printf or cout statements to assist with debugging. Make sure to add in a carriage return or do a flush on the I/O buffer to ensure that debug information is displayed before program crashes occur. Make sure to disable your debugging output before handing in the assignment.
You can connect back to localhost (127.0.0.1), which will allow you to test your code on the same machine where you have the server running. Create a separate ssh terminal session back to the server and then run your client code by connecting to localhost.
When compiling your code, remember to link the libraries -lcrypto -lpthread
Server Side Design
The server is responsible for handling the connection request from multiple clients, processing the request,
then looping back to handle further requests from any client.
The server binary should be named chatserver.
The server should listen on the specified port number [refer to Appendix for the port number for
your group] that is given by command line argument. Your server should bind to the port and then listen
for incoming client connections. You may decide if you would like to allow timeouts for better
responsiveness but any sort of a timeout is purely optional. You may want to allow for port reuse for
quicker recovery after a crash.
Once a new client request arrives, your server should use the accept function to create a new client socket.
Your server should be invoked as follows: ./chatserver Port
Client Side Design
The client is responsible for initiating a connection to a server. Once connected, the client code should
prompt the user for an operation (B, P, E), and should transmit the operation to the
server. Your client executable should be named chatclient. Your client should be invoked as follows: ./chatclient Server_Name Port Username
The first argument is the hostname of the server to connect to (this will depend on what machine you start
your server code on). The second argument is the port number. The third argument is the username for login.
Demo:
(You can ignore the debug messages on the server. The top-left terminal is the online chat server and the rest are clients.)
Note: Please set the quality of the video to be 720p by clicking the gear in the lower right of the video.