COMP3331/9331 Computer Networks and Applications - Assignment for Term 2, 2022 - An online video conferencing and messaging application
COMP3331/9331 Computer Networks and Applications Assignment for Term 2, 2022
Version 1.0
11:59 am (noon) Friday, 5 August 2022 (Week 10)
Updates to the assignment, including any corrections and clarifications, will be posted on the subject website. Please make sure that you check the subject website regularly for updates.
Version 1.0 is released on 21/06/2022.
2. Goal and learning objectives
Zoom and Microsoft Teams are widely used as a method for large groups of people to hold online virtual meetings. A good example is the online Zoom lectures used for various courses at UNSW. In this assignment, you will have the opportunity to implement your own version of an online video conferencing and messaging application. Your application is based on a client-server model consisting of one server and multiple clients communicating concurrently. The text messages should be communicated using TCP for the reason of reliability, while the video (you will use video files instead of capturing the live video streams from cameras and microphones) should be communicated using UDP for the reason of low latency. Your application will support a range of functions that are typically found on videoconferencing including authentication, broadcasting text messages to all participants, building a separate room for part of the participants, and uploading video streams (i.e., files in this assignment). You will be designing custom application protocols based on TCP and UDP.
2.1 Learning Objectives
On completing this assignment, you will gain sufficient expertise in the following skills:
- Detailed understanding of how client-server and client-client interactions work.
- Expertise in socket programming.
- Insights into designing and implementing an application layer protocol.
3. Assignment Specification
The base specification of the assignment is worth 20 marks. The specification is structured in two parts. The first part covers the basic interactions between the clients and server and includes functionality for clients to communicate with the server. The second part asks you to implement additional functionality whereby two clients can upload/download video files to each other directly in a peer-to-peer fashion via UDP. This first part is self-contained (Sections 3.2 – 3.3) and is worth
15 marks. Implementing video file uploading/downloading over UDP (Section 3.4) is worth 5 marks. CSE students are expected to implement both functionalities. Non-CSE students are only required to implement the first part (i.e., no video file uploading/downloading over UDP). The marking guidelines are thus different for the two groups and are indicated in Section 7.
The assignment includes 2 major modules, the server program and the client program. The server program will be run first followed by multiple instances of the client program (Each instance supports one client). They will be run from the terminals on the same and/or different hosts.
3.1. Assignment Specification
In this programming assignment, you will implement the client and server programs of a video conference application, similar in many ways to the Zoom application that we use for this course. The difference is that your application won’t capture and display live videos; instead, it will transmit and receive video files. The text messages must communicate over TCP to the server, while the clients communicate video files in UDP themselves. Your application will support a range of operations including authenticating a user, posting a message to the server, sending a private message to another particular participant, reading messages from the server, reading active users’ information, and uploading video files from one user to another user (CSE Students only). You will implement the application protocol to implement these functions. The server will listen on a port specified as the command line argument and will wait for a client to connect. The client program will initiate a TCP connection with the server. Upon connection establishment, the user will initiate the authentication process. The client will interact with the user through the command-line interface. Following successful authentication, the user will initiate one of the available commands. All commands require a simple request-response interaction between the client and server or two clients (CSE Students only). The user may execute a series of commands (one after the other) and eventually quit. Both the client and server MUST print meaningful messages at the command prompt that capture the specific interactions taking place. You are free to choose the precise text that is displayed. Examples of client- server interactions are given in Section 8.
3.2 Authentication
When a client requests a connection to the server, e.g., for attending a video conference, the server should prompt the user to input the username and password and authenticate the user. The valid username and password combinations will be stored in a file called credentials.txt which will be in the same directory as the server program. An example credentials.txt file is provided on the assignment page. Usernames and passwords are case-sensitive. We may use a different file for testing so DO NOT hardcode this information in your program. You may assume that each username and password will be on a separate line and that there will be one white space between the two. If the credentials are correct, the client is considered to be logged in and a welcome message is displayed. You should make sure that write permissions are enabled for the credentials.txt file (type “chmod +w credentials.txt” at a terminal in the current working directory of the server).
On entering invalid credentials, the user is prompted to retry. After several consecutive failed attempts, the user is blocked for 10 seconds (the number is an integer command-line argument supplied to the server and the valid value of the number should be between 1 and 5) and cannot login during this 10-second duration (even from another IP address). If an invalid number value (e.g., a floating-point value, 0 or 6) is supplied to the server, the server prints out a message such as “Invalid number of allowed failed consecutive attempt: number. The valid value of argument number is an integer between 1 and 5”.
For non-CSE Students: After a user log in successfully, the server should record a timestamp of the user logging in the event and the username in the active user log file (userlog.txt, you should make sure that write permissions are enabled for userlog.txt). Active users are numbered starting at 1:
Active user sequence number; timestamp; username
1; 1 Jun 2022 21:30:04; Yoda
3.3. Text message commands
Following a successful login, the client displays a message to the user informing them of all available commands and prompting it to select one command. The following commands are available: BCM: Broadcast messages to all the active users i.e., public messages, ATU: Display active users, SRS: Separate chat room service, in which users can build a separate room for part of active users and send messages in the separate room, RDM: Read messages, OUT: Log out, and UPD: Upload file (for CSE Students only). All available commands should be shown to the user in the first instance after successful login. Subsequent prompts for actions should include this same message.
If an invalid command is selected, an error message should be shown to the user, and they should be prompted to select one of the available actions.
In the following, the implementation of each command is explained in detail. The expected usage of each command (i.e., syntax) is included. Note that, all commands should be upper-case (BCM, RDM, etc.). All arguments (if any) are separated by a single white space and will be one word long (except messages which can contain white spaces and timestamps that have a fixed format of dd mm yyyy hh:mm:ss such as 1 Jun 2022 16:01:20). You may assume that the message text may contain uppercase characters (A-Z), lowercase characters (a-z) and digits (0-9) and the following limited set of special characters (!@#$%.?,). If the user does not follow the expected usage of any of the operations listed below, i.e., missing (e.g., not specifying the body of a message when posting the message) or incorrect number of arguments (e.g., the inclusion of additional or fewer arguments than required), an error message should be shown to the user and they should be prompted to select one of the available commands. Section 8 illustrates sample interactions between the client and server.
3.4 Peer to Peer Communication (Video file upload, CSE Students only)
The P2P part of the assignment enables one client to upload video files to another client using UDP. Each client is in one of two states, Presenter or Audience. The Presenter client sends video files to the Audience client. Here, the presenter client is the UDP client, while the Audience client is the UDP server. After receiving the video files, the Audience client saves the files and the username of the Presenter. Note that a client can behave in either Presenter or Audience state.
To implement this functionality your client should support the following command.
UPD: Upload file
UPD username filename
The Audience user and the name of the file should be included as arguments. You may assume that the file included in the argument will be available in the current working directory of the client with the correct access permissions set (read). You should not assume that the file will be in a particular format, i.e., just assume that it is a binary file. The Presenter client (e.g., Yoda) should check if the Audience user (indicated by the username argument, e.g., Obi-wan) is active (e.g., by issuing command ATU). If Obi-wan is not active, the Presenter client should display an appropriate error message (e.g., Obi-wan is offline) at the prompt to Yoda. If Obi-wan is active, Yoda should obtain the Obi-wan’s address and UDP server port number (e.g., by issuing command ATU) before transferring the contents of the file to Obi-wan via UDP. Here, Yoda is the UDP client and Obi-Wan is the UDP server. The file should be stored in the current working directory of Obi-wan with the file name presenterusername_filename (DO NOT add an extension to the name. If the filename has an extension mp4, e.g., test.mp4 should be stored as yoda_test.mp4 in our example). File names are case sensitive and one word long. After the file transmission, the terminal of Yoda should next prompt the user to select one of the available commands. The terminal of Obi-wan should display an appropriate message, e.g., a file (test.mp4) has been received from Yoda, before prompting the user to select one of the available commands. Two example video files are available in Webcms.
3.5 File Names & Execution
The main code for the server and client should be contained in the following files: server.c, or Server.java or server.py, and client.c or Client.java or client.py. You are free to create additional files such as header files or other class files and name them as you wish.
The server should accept the following two arguments:
• server_port: this is the port number that the server will use to communicate with the clients. Recall that a TCP socket is NOT uniquely identified by the server port number. So, it is possible for multiple TCP connections to use the same server-side port number.
• number_of_consecutive_failed_attempts: this is the number of consecutive unsuccessful authentication attempts before a user should be blocked for 10 seconds. It should be an integer between 1 and 5.
The server should be executed before any of the clients. It should be initiated as follows: If you use Java:
java Server server_port number_of_consecutive_failed_attempts
If you use C:
./server server_port number_of_consecutive_failed_attempts
If you use Python:
python server.py server_port number_of_consecutive_failed_attempts
The client should accept the following three arguments:
- server_IP:thisistheIPaddressofthemachineonwhichtheserverisrunning.
- server_port:thisistheportnumberbeingusedbytheserver.Thisargumentshouldbethe same as the first argument of the server.
- client_udp_port: this is the port number which the client will listen to/wait for the UDP traffic from the other clients.
Note that, you do not have to specify the TCP port to be used by the client. You should allow the OS to pick a random available port. Similarly, you should allow the OS to pick a randomly available UDP source port for the UDP client. Each client should be initiated in a separate terminal as follows:
For non-CSE Students:
If you use Java:
java Client server_IP server_port
If you use C:
./client server_IP server_port
If you use Python:
python client.py server_IP server_port
3.6 Program Design Considerations Client Design
The client program should be fairly straightforward. The client needs to interact with the user through the command-line interface and print meaningful messages. Section 8 provides some examples. You do not have to use the exact same text as shown in the samples. Upon initiation, the client should establish a TCP connection with the server and execute the user authentication process. Following authentication, the user should be prompted to enter one of the available commands. Almost all commands require simple request/response interactions between the client with the server. Note that, the client does not need to maintain any state about the videoconferencing.
Server Design
When the server starts up, the videoconference is empty – i.e., there exist no users. The server should wait for a client to connect, perform authentication, and service each command issued by the client sequentially. Note that, you will need to define several data structures for managing the current state of the videoconference (e.g., active users and posts) and the server must be able to interact with multiple clients simultaneously. A robust way to achieve this is to use multithreading. In this approach, you will need the main thread to listen for new connections. This can be done using the socket accept function within a while loop. This main thread is your main program. For each connected client, you will need to create a new thread. When interacting with one particular client, the server should receive a request for a particular operation, take necessary action and respond accordingly to the client and wait for the next request. You may assume that each interaction with a client is atomic. Consider that client A initiates an interaction (i.e., a command) with the server. While the server is processing this interaction, it cannot be interrupted by a command from another client B. Client B’s command will be acted upon after the command from client A is processed. Once a client exits, the corresponding thread should also be terminated. You should be particularly careful about how multiple threads will interact with the various data structures. Code snippets for multi-threading in all supported languages are available on the course webpage.
