Table of Contents
In this project, we will design a server and client program for a chat application using Python.
The clients will be limited to 2 per simultaneous chat session.
Code will explicitly create sockets, send data and receive data from the sockets.
A client needs to connect first to the server. Connection to the server is initiated when a user logs on.
- When the user at client A logs on, client A sends a HELLO (Client-ID-A) message to the server, using UDP transport.
- The server verifies that Client-ID-A is an ID on the list of subscribers. If so, the server retrieves the client’s secret key and sends a CHALLENGE (rand) message to the client, using UDP.
- The client responds with a RESPONSE (Res) to authenticate itself. If authentication is not successful, the server sends an AUTH_FAIL message to the client. Else the server generates an encryption key CK-A, then sends an AUTH_SUCCESS(rand_cookie, port_number) message to the client. The message is encrypted by CK-A.
- The client generates the same CK-A key, and decrypts the message. From this point on, all data exchanged between client A and the server is encrypted using CK-A.
- Client A establishes a TCP connection to the port at port_number and sends a CONNECT (rand_cookie) to the server. From this point on, until the TCP connection is closed, all data (signaling messages and chat) is exchanged over the TCP connection.
- The server sends CONNECTED to the client. The client is connected.
- The client tears down the TCP connection when the user types “Log off” or when the activity timer expires.
This scenario will go through the following steps. Client A must have already gone through the connection phase and be connected to the server.
- To start a chat with client B, the end user types “Chat Client-ID-B”, and client A sends a CHAT_REQUEST (Client-ID-B). If the server determines client-B is connected and not already engaged in another chat session, the server sends CHAT_STARTED(session-ID, Client-ID-B) to client A, and CHAT_STARTED(session-ID, Client-ID-A) to client B. Client A and Client B are now engaged in a chat session and can send chat messages with each other, through the server. The clients display “Chat started” to the end user at A and B. If client B is not available, the server sends UNREACHABLE (Client-ID-B) to client A.
- When the end user at A or B wants to terminate the session, the end user types “End Chat”, and the associated Client sends END_REQUEST (session-ID) to the server.
- The server sends an END_NOTIF(session-ID) to the other client. The Clients display “Chat ended” to their respective end users.
The server is assumed secure, and only the client needs to be authenticated. Authentication is based on the challenge/response mechanism, used in cellular networks. Upon receiving HELLO (Client-ID-A), the server looks up Client A’s secret key K_A. Then it generates a random number rand. Rand and K_A are input into an authentication algorithm A3. The output, XRES, is stored by the server. Then the server sends rand in the CHALLENGE (rand). Client A is expected to run the same algorithm A3 with the same inputs rand and K_A, and produce RES, which is sent to the server in the RESPONSE (Res) message. If RES matches XRES, the server has authenticated the client. For this assignment, use a hash function for algorithm A3: RES = hash1(rand + K_A), where + denotes concatenation. Examples are MD5, SHA1, SHA256 etc.
Concurrently with the above authentication process, the server and client run an A8 algorithm, which takes as input rand and K_A, to generate a ciphering key CK_A. For this assignment, use a hash function for A8: CK_A = hash2(rand + K_A).
For simplicity, integrity protection is not implemented.
In addition, the server will maintain chat history of each client. At any time in the connected state, client A can see the history of past chat messages with client B by sending the HISTORY (Client-ID-B) message to the server. In response the server sends all the past chat messages exchanged between client A and client B. Client A should display all the chat messages in the history in the following format <session_id> <from: sending client> <chat message>
The significant fields of the messages along with their semantics are defined below. As part of the project assignment, you have to define the precise syntax and format of the messages.
- HELLO (Client-ID-A): Initiates the process for Client A to be authenticated and registered with the server.
- CHALLENGE (rand): Sent by the server to challenge the client to authenticate itself. rand is a random number generated by the server. A new rand is generated at every CHALLENGE.
- RESPONSE (client-ID, Res): Response to the challenge, sent by the client to authenticate itself.
- AUTH_SUCCESS(rand_cookie, port_number): Sent by the server to notify the client authentication is successful. rand_cookie is a random number generated by the server, and port_number is a TCP port number assigned by the server for subsequent connection by the client.
- AUTH_FAIL: Sent by the server to notify the client authentication has failed
- CONNECT (rand_cookie): Sent by the client to the server. rand_cookie is the cookie previously sent by the server.
- CONNECTED: Sent by the server to notify the client it has been connected
- CHAT_REQUEST (Client-ID-B): Sent by client A to the server to request a chat session with Client B
- CHAT_STARTED (session-ID, Client-ID-B): Sent by the server to notify client A that a chat session with client B has started. Session-ID is an ID assigned to the session
- UNREACHABLE (Client-ID-B): Sent by the server to client A to notify client B is not available for chat.
- END_REQUEST (session-ID): Sent by any of the clients involved in the chat session to request a termination of the session
- END_NOTIF (session-ID): Sent by the server to notify a client involved in the session that the session has been terminated by another client.
- CHAT (session-ID, chat message): Exchanged between the clients, relayed by the server. Carries the actual chat message
- HISTORY_REQ (Client-ID-B): Sent by client A to request the history of past chat messages with client B.
- HISTORY_RESP (Sending Client-ID, chat message): Sent by the server to the client who requested the history. Sending Client-ID is the ID of the client who sent the chat message, and chat message is the chat message in the history. There is one HISTORY_RESP message for each chat message in the history.
We will be validating the code based on the following scenarios.
| Step | Action | Expected behavior |
|---|---|---|
| 0 | Start from the state where clients A and B are off line | |
| 1 | Client A’s user types “Log on” | Client A and server should go through the connection phase and exchange the messages shown in “Connection Phase” Client A should display “Connected” |
| 2 | Client B’s user types “Log on” | Client B and server should go through the connection phase and exchange the messages shown in “Connection Phase” Client B should display “Connected” |
| 3 | Client A’s user types “Chat Client-ID-B” | Client A should send CHAT_REQUEST, server should send CHAT_STARTED to client B and client A. “Chat started” should be displayed at both clients |
| 4 | Client A and client B exchange chat messages | What client A’s user types should be displayed at client B, and vice versa |
| 5 | Client A’s user types “End chat” | Client A should send END_REQUEST to server and display “Chat ended Client B should receive END_NOTIF from server and display “Chat ended” |
| 6 | Client A’s user types “Log off" | Client A should close the TCP connection |
####Basic chat initiated by A and closed by B
| Step | Action | Expected Behavior |
|---|---|---|
| 0 | Go through steps 0 to 4 of “Basic chat initiated and closed by A” | |
| 1 | Client B’s user types “End chat” | Client B should send END_REQUEST to server an display “Chat ended” Client A should receive END_NOTIF from server and display “Chat ended” |
| 2 | Client A’s user types “Log off" | Client should close the TCP connection |
| Step | Action | Expected behavior |
|---|---|---|
| 0 | Go through steps 0 to 1 of “Basic chat initiated and closed by A” | |
| 1 | Client A’s user types “Chat Client-ID-B” | Client A should send CHAT_REQUEST, server should reply with UNREACHABLE, client A should display “Correspondent unreachable” |
| 2 | Client B’s user types “Log on” | Client B and server should go through the connection phase and exchange the messages shown in “Connection Phase” Client B should display “Connected” |
| 3 | Client A’s user types “Chat Client-ID-B” | Client A should send CHAT_REQUEST, server should send CHAT_STARTED to client B and client A. “Chat started” should be displayed at both clients |
| 4 | Client A and client B exchange chat messages | What client A’s user types should be displayed at client B, and vice versa |
| 5 | Client B’s user types “End chat” | Client B should send END_REQUEST to server and display “Chat ended” Client A should receive END_NOTIF from server and display “Chat ended” |
| 6 | Client A’s user types “Logoff" | Client A should close the TCP connection |
| Step | Action | Expected behavior |
|---|---|---|
| 0 | Go through steps 0 to 4 of “Basic chat initiated and closed by A” | |
| 1 | Client C’s user types “Log on” | Client C and server should go through the connection phase and exchange the messages shown in “Connection Phase” Client C should display “Connected” |
| 2 | Client C’s user types “Chat Client-ID-B” | Client C should send CHAT_REQUEST, server should reply with UNREACHABLE, client C should display “Correspondent unreachable” |
| Step | Action | Expected behavior |
|---|---|---|
| 0 | Go through the steps of “Basic chat initiated and closed by A” | |
| 1 | Client B’s user types “Log on" | Client B and server should go through the connection phase and exchange the messages shown in “Connection Phase” Client B should display “Connected” |
| 2 | Client A’s user types “History Client-ID-B” | Client A should send HISTORY_REQ and should receive all the chat messages of the last chat session with B, sent in one or more HISTORY_RESP messages |
Verify you can establish 5 simultaneous chat sessions between 5 pairs of clients.
- A proposed action plan by the due date specified in “ProjectTimeline” in “Projects Overview”.
- A team report by by the due date specified in “ProjectTimeline” in “Projects Overview”. a) Containing source codes related to client and server. Include a README file that describes how to compile/run the program. b) Providing a background summary of challenge/response authentication scheme c) Describing your hardware setup and configuration d) Including the design document of your code (e.g. Protocol State Diagrams, Sequence Diagram or any other info that helps to understand what has been done) e) Providing screenshots of chat sessions f) Describing what issues, if any, the team encountered during the project, how the team overcame the issues and what the team learned from the project. You can also provide suggestions on how the projects in Computer Networks could be improved in the future. g) Including a video clip to demo the code running
- Individual reports, one for each team member by the due date specified in “ProjectTimeline in “Projects Overview””. The individual report is confidential and not shared with the other team members. a) If you, as an individual team member, have anything specific to add to 1.f) in the team report, please do it in your individual report. Describe what issues, if any, you, as an individual team member, encountered during the project, how you overcame the issues and what you learned from the project (this is not necessarily just about the topic, could be related to teamwork, etc.). You can also provide suggestions on how the projects in Computer Networks could be improved in the future. This complements the team report with any individual viewpoint not included in the team report. b) Describing what each team member (including yourself) did and contributed to the project, and assign a numerical score from 1 to 10 to each team member, including yourself. 1 is the poorest, and 10 is the best. Note: There will be a separate session (taking place outside of lecture hours) for you to demo your code is running and answer questions about your code and design. The code demo sessions will take place towards the end of the semester
Note: There will be a separate session (taking place outside of lecture hours) for you to demo your code is running and answer questions about your code and design. The code demo sessions will take place towards the end of the semester.
Must use Python 3.10
Use this space to show useful examples of how to use the application.
- Additional screenshots
- Code examples
- Demos
- Links to more resources.
 |
 |
 |
|
|---|---|---|---|
| @Kantancoder | @ThanosWasTaken | [@Timothy_Choi] | @Adrian |
| rogonzalez214@gmail.com | surya.modern.work@gmail.com | timothychoi14@gmail.com | adriansanchez68.as@gmail.com |
 |
|
|
|
General Note: The following are criteria used to come up with a team grade. Your final individual project score is not necessarily the team grade, it may be flexed up or down, depending on your individual contribution to the team and the quality of your individual report.
Source code of your well-structured and well-documented program. Include comments on your codes for clarification. In addition, your project has to meet the validation scenarios. Generally, “connection phase” weigh 25% and “chat phase” weigh 35%. You should be able to demonstrate good understanding of the code and be able to answer specific questions on the code and design.
Group Report (40%): The group report will be evaluated not only on its content, but also the professionalism of its appearance.