Spring 2022 IS496 Programming Assignment 3 - Online Chat Room

Total Points: 100 points
Goal: Program a Prototype of an Online Chat Room
Assigned: Mar 21, 2022
Due: April 18, 2022 April 20, 2022 by the end of day (11:59 pm CST).
Grouping: To be completed by a group.
Note: This instruction is based on Python. The C/C++ version is available at here.


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: broadcast messaging and private 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 sent by the client. The specifics of the protocol are detailed in this handout. You are free to reuse part of your programs in PG1 and PG2 to finish this assignment. Please refer to Appendix for the port number assigned to you (same as PG1).

Type of Messages

In this assignment, we define two types of message frames: data message and command message. A data message is the message exchanged between clients (i.e., the broadcast and private 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 performing accordingly. (Refer to "Technical Instruction" section for more details.)

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. Client sends the password to the server.
  6. Server receives the password and either registers a new user or checks to see if the password matches. Server also sends the acknowledgment to the client.
  7. Server continues to wait for operation command from a client or a new client connection.
  8. Client goes into "prompt user for operation" state and prompts user for operation.
  9. Client passes operation (BM: Broadcast Messaging, PM: Private Messaging, EX: Exit) to server.
  10. 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, and the message to be sent.
      5. Client sends the username and the message to the server.
      6. Server receives the above information and checks to make sure the target user exists/online.
      7. If the target user exists/online, the server forwards the message to the user, which displays the message. The server should do this by sending the message to the corresponding socket descriptor of the target user.
      8. 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.
      9. Client receives the confirmation from the server.
      10. 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.
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

General Notes

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 should listen on the specified port number (refer to Appendix for the port number) that is given by the 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.

The server executable should be named chatserver.py and be invoked as follows:

[netid@is-student00 ~] $ python3 chatserver.py [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 (BM, PM, EX), and should transmit the operation to the server.

The client executable should be named chatclient.py and be invoked as follows:

[netid@is-student02 ~] $ python3 chatclient.py [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.



Submit a gzipped tar file of your entire assignment package to the corresponding assignment on Canvas. One submission per group is sufficient. The archive must include the following:

Grading Rubric

Extra Credits

  1. Chat History (CH) Command:
    1. Client sends operation (CH) to view the chat history.
    2. The chat history should be stored in a file on the server that keeps track of all previous chat messages received and sent by the client. The file is stored on the server rather than on the client so that the user cannot modify or delete the chat history. The file should be created upon user registration. For example, when user Alice registers, the server will create a file "Alice.chat" to store her chat history.
    3. Each chat history entry should include [Timestamp] [Type of Chat (BM or PM)] [Sender and Receiver] and [Message Content]. The timestamp is the moment when a client sends or receives a message. (You may use the corresponding timestamp on the server to record the chat history.)
    4. When receiving the (CH) command, the server sends the chat history to the client.
    5. The client receives and then displays the chat history on the screen. For long chat history that exceeds the buffer size, the client will need to enter a loop to receive the chat history.
    6. Client and server return to "prompt user for operation" and "wait for operation from client" state, respectively.
  2. Password and Private Message Encryption:
    • Password Encryption
      1. After the server receives the username from the client, the server generates a public key and sends it to the client.
      2. Client encrypts its password using server's public key, and sends the encrypted password to server.
      3. Server receives the encrypted password and decrypts it. Server continues the login process as shown in the main instruction.
    • Private Message Encryption
      1. After the client has successfully logged in to the chat room, the client generates a public key and sends it to the server.
      2. Server stores the public key of the client.
      3. When a client wants to send a private message, the client first sends the username to the server, and the server replies with the user's public key.
      4. Client receives the user's public key and then prompts for, encrypts, and sends the message to be sent.
      5. The server forwards the encrypted message to the target user, which will receive the encrypted message, and decrypt and display the message.
    Note: The encryption/decryption functions are provided in the file pg3lib.py that can be downloaded here.

Extra Credit Rubric (20 pts)


Use the port number corresponding to your name in the appendix below.

Table 1. Port Assignments
Port to UseName
41001 Canty, Angel
41002 Guo, Jerry
41003 Lee, Ivy
41004 Shamim, Iman
41005 Shi, Tiancheng
41006 Shuaibi, Alaa
41007 Torres, Michael
41008 Xiao, Justin
41009 Cui, Cilia
41010 Donelson, Curt
41011 Fang, Hongli
41012 He, Richard
41013 He, Xiang
41014 Huang, Chung-An
41015 Huang, Houshuo
41016 Jia, Bo
41017 Jia, Hao
41018 Jiang, Yuxuan
41019 Li, Chang
41020 Li, Ziheng
41021 Liu, Amelia
41022 Liu, River
41023 Wang, Jingwei
41024 Wang, Weiyu
41025 Wang, Xiuyuan
41026 Wang, Zeyu
41027 Xia, Yilin
41028 Xu, Yuting
41029 Xu, Zhizhou
41030 Yang, Qinwen
41031 Zhang, Boyu
41032 Zhang, Jingfang
41033 Zhang, Yunjia
41034 Zhang, Zheng
41035 Zheng, Shaojun