Spring 2021 CSE30264 Programming Assignment 3 - Online Chat Room

Background

Type of Messages

Online Chat Room

1. Server opens a port, creates the TCP/UDP socket, goes into "wait for connection" state, and actively listens for socket connections. Hint: please read the Technical Instruction section for details.
2. Client logs in to the system by connecting to the server on the appropriate port.
3. Client sends the username.
4. 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).
5. Server generates a public key and sends it to the client.
6. Client encrypts its password using server's public key, and sends the encrypted password to server.
7. Server receives the password and decrypts it. Then, server either registers a new user or checks to see if the password matches. Server also sends the acknowledgment to the client.
8. Client generates a public key and sends it to the server. Note: multiple clients should be able to register at the same time.
9. Server continues to wait for operation command from a client or a new client connection.
10. Client goes into "prompt user for operation" state and prompts user for operation.
11. Client passes operation (BM: Broadcast Messaging, PM: Private Messaging, EX: Exit) to server.
12. Operation is executed as follows:
    1. BM:
       1. Client sends operation (BM) to broadcast a message to all active clients (i.e., clients who successfully log in to the system but have not exited yet).
       2. Server sends the acknowledgment back to the client to prompt for the message to be sent.
       3. Client sends the broadcast message to the server.
       4. Server receives the message and sends that broadcast 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.
       5. Server sends the confirmation that the message was sent. Note: you can decide the content/format of the confirmation.
       6. Client receives the confirmation.
       7. Client and server return to "prompt user for operation" and "wait for operation from client" state, respectively.
    2. PM:
       1. Client sends operation (PM) to leave a message to a specific client.
       2. 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 (EX).
       3. Client receives the list of online users from the server.
       4. Client prompts the user for the username (of the target user) to send a message to.
       5. Client sends the username to the server, and the server replies with the user's public key.
       6. Client then prompts for, encrypts, and sends the message to be sent.
       7. Server receives the above information and checks to make sure the target user exists/online.
       8. If the target user exists/online, the server forwards the message to the user, which decrypts and displays the message. The server should do this by sending the message to the corresponding socket descriptor of the target user.
       9. Server sends the confirmation that the message was sent or that the user did not exist. Note: you can decide the content/format of the confirmation.
       10. Client receives the confirmation from the server.
       11. Client and server return to "prompt user for operation" and "wait for operation from client" state, respectively.
    3. EX:
       1. Client sends operation (EX) to close its connection with the server and end the program.
       2. Server receives the operation and closes the socket descriptor for the client.
       3. Server updates its tracking record on the socket descriptors of active clients and usernames of online users.
       4. Client should close the socket and exit.

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 (EX) command to exit, 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 /escnfs/courses/sp21-cse-30264.01/public/program3/C/pg3lib.h) to simplify the implementation of cryptography for passwords and private 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 BM command). Then send a private 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 broadcast messaging, private messaging and multithreading in this scenario.

General Notes

• Your code may be written in C or C++. You should create two separate directories in your submission, 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 int) value for transmission. Use htonl/ntohl for 32-bit (long int) values.
• 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

Client Side Design

Demo:

Submission

• Working client code in a client subdirectory
  • Makefile for the client.
  • Source file for the client.
  • Appropriate comments and each member's name.
• Working server code in a server subdirectory
  • Makefile for the server.
  • Source file for the server
  • Appropriate comments and each member's name.
• User file
  • Listing of the registered usernames and corresponding passwords. Note: You should read this file in on the server side to handle registered users.
• README file
  • Listing of the included file names and example commands to run your code in the archive.

Grading Rubric

• Client code(45 pts total)
  • [5 pts] Included Makefile and code compiles without errors.
  • [5 pts] Code performs the login operation and encrypts the password correctly.
  • [5 pts] Code performs the broadcast messaging operation correctly.
  • [5 pts] Code performs the private messaging operation correctly.
  • [6 pts] Code accepts incoming broadcast and private messages correctly.
  • [5 pts] Code performs exit operation correctly.
  • [5 pts] Code provides reasonable error checking.
  • [5 pts] Reasonable code performance (runs without errors).
  • [4 pts] Code is commented with appropriate header information.
• Server code (45 pts total)
  • [5 pts] Included Makefile and code compiles without errors.
  • [5 pts] Code handles multiple client connections correctly.
  • [5 pts] Code performs the login operation and decrypts the password correctly.
  • [5 pts] Code performs the broadcast messaging operation correctly.
  • [6 pts] Code performs the private messaging operation correctly.
  • [5 pts] Code performs exit operation correctly.
  • [5 pts] Code provides reasonable error checking.
  • [5 pts] Reasonable code performance (runs without errors).
  • [4 pts] Code is commented with appropriate header information.
• Overall (10 pts total)
  • [3 pts] Code is submitted in the requested form.
  • [3 pts] Code follows argument convention.
  • [4 pts] User information is stored in file.

Appendix