COMP3331/9331 Computer Networks and Applications Assignment for Term 2, 2022

1. Change Log

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:

1.   Detailed understanding of how client-server and client-client interactions work.

2.   Expertise in socket programming.

3.   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.

Non-CSE Student: The rationale for this option is that students enrolled in a program that does not include a computer science component have had very limited exposure to programming and in particular working on complex programming assignments. A Non-CSE Student is a student who is not enrolled in a CSE program (single or double degree). Examples would include students enrolled exclusively in a single degree program such as Mechatronics or Aerospace or Actuarial Studies or Law. Students enrolled in dual degree programs that include a CSE program as one of the degrees do

not qualify. Any student who meets this criterion and wishes to avail of this option MUST email [email protected]to seek approval before 5 pm, 1 July (Friday, Week 5). We will assume by default that all students are attempting the CSE version of the assignment unless they have sought explicit permission. No exceptions.

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

For CSE Students: After a user log in successfully, the client should next send the UDP port number that it is listening to the server. The server should record a timestamp of the user logging in the event, the username, the IP address, and port number that the client listens to in the active user log file (userlog.txt):

Active user sequence number; timestamp; username; client IP address; client UDP server port number

1; 1 Jun 2022 21:30:04; Yoda; 129.64.1.11; 6666

For simplicity, a user will log in once at any given time, e.g., multiple logins concurrently are not allowed, and we won’t test this case.

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 ofactive 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 ofthe 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.

There are 6 commands for Non-CSE Students and 7 commands for CSE Students respectively, which users can execute. The execution of each command is described below.

BCM: Broadcast Message

BCM message

The message body should be included as the argument. Note that, the message may contain white spaces (e.g., “Hi Wei, how are you”). The client should send the command (i.e., BCM), the message, and the username to the server. In our tests, we will only use short messages (a few words long). The server should append the message, the username, and a timestamp at the end of the message log file (file (messagelog.txt, you should make sure that write permissions are enabled for messagelog.txt) in the format, along with the number of the messages (messages are numbered starting at 1):

messageNumber; timestamp; username; message

1; 1 Jun 2022 21:39:04; yoda; do or do not, there is no try

After the message is successfully received at a server, a confirmation message with message type (i.e., broadcast message), message number, and the timestamp should be sent from the server to the client and displayed to the user. If there is no argument after the BCM command. The client should display an error message before prompting the user to select one of the available commands.

ATU: Download Active Users

ATU

There should be no arguments for this command. The server should check if there are any other active users apart from the client that sends the ATU command. If so, the server should send the usernames, and timestamp since the users are active, (and their IP addresses and Port Numbers, CSE Students only) in the active user log file to the client (the server should exclude the information of the client, who sends ATU command to the server.). The client should display all the information of all received users at the terminal to the user. If there is no other active user exists, a notification message of “no other active user” should be sent to the client and displayed at the prompt to the user. The client should next prompt the user to select one of the available commands.

SRS: Separate Room Service

This function is composed of two commands: SRB: Separate room building and SRM: Separate room message. See below details for SRB and SRM.

SRB username1 username2 …

The client needs to practice the SRB command to request the server to build a separate chat room. Arguments are usernames that the current client wants to include in the separate chat room. If there is no argument after the SRB command, the client should display an error message before prompting the user with one of the available commands. The server is expected to check if the provided usernames exist or not, and the server also should check if the corresponding users are active or not. If any username does not exist or the corresponding user is offline, the server should not create a separate room and reply to the client which username does not exist, or user is offline. If all the

provided usernames exist and all the corresponding users are online, the server should create a separate room for them, and the server is expected to generate a separate room ID which should be represented by integers e.g., 1, 2, 3. The server also needs to create a corresponding log file (e.g., SR_ID_messagelog.txt) to record the messages in a separate chat room.  Finally, the server should reply to the client to confirm that the separate room has been successfully created, for example, “Separate chat room has been created, room ID: 1, users in this room: username1, username2 …” . Noted that, if a separate room already created for this group of users no matter which user in the group created, the server should not create another separate room, instead the server should inform the client with a message of “a separate room (ID: 1) already created for these users” .  In addition, a user cannot build a separate room with himself/herself.

SRM roomID message

The separate room ID and message body should be included in the argument. The room ID as the first argument indicates which separate room the client wants to send a message (assume the client may be in multiple separate chat rooms).  The server should first check if the room with provided room ID exists. If the room with that room ID does not exist, the server should reply to the client with a message of “The separate room does not exist” . And the server also needs to check if the client (the client sends the SRM commands) is a member of the separate room, if the client is not in this separate room the server should reply to the client with a message of “You are not in this separate room chat” . If everything is good, the server should append the message, the username, and a timestamp at the end ofthe message log file (file (SR_ID_messageLog.txt, you should make sure that write permissions are enabled for SR_ID_messageLog.txt) in the format, along with the number of the messages (messages are numbered starting at 1 for each new created separate room chat):

messageNumber; timestamp; username; message

1; 1 Jun 2022 21:39:04; Yoda; do or do not, there is no try

After the message is successfully received at a server, a confirmation message with message type (i.e., separate room message), message number, and the timestamp should be sent from the server to the client and displayed to the user. If there is no argument after the SRM command.  The client should display an error message before prompting the user to select one of the available commands.

RDM: Read Messages

RDM messageType timestamp

The messagType, which groups the messages to be read. On the server side, there are broadcast messages and separate room messages. The lower letters b and s are used to represent broadcast messages and separate room messages, respectively. The timestamp, after which the messages are to be read, should be included as an argument. The client should send the command (RDM), message type (i.e., b or s), and a timestamp to the server. The server should check ifthere are any new messages (i.e., the timestamps of the messages that are larger/later than the timestamp specified in the RDM message) in the message log files. If so, the server should send these new messages to the client. The client should display all received messages at the terminal to the user. Noted that, if the message group is specified as “s” and the client is in multiple separate rooms, the server should check all separate rooms’ message log files and send new messages in these separate rooms to the client.  If there is no new message exists, a notification message of “no new message” should be sent to the client and displayed at the prompt to the user. The client should next prompt the user to select one of the available commands.

OUT: Log out

OUT

There should be no arguments for this command. The client should close the TCP connection, (UDP peer-peer, CSE Students only) and exit with a goodbye message displayed at the terminal to the user. The server should update its state information about currently logged-on users and the active user log file. Namely, based on the message (with the username information) from the client, the server should delete the user, which entails deleting the line containing this user in the active user log file (all subsequent users in the file should be moved up by one line and their active user sequence numbers should be updated appropriately) and confirmation should be sent to the client and displayed at the prompt to the user. Note that any messages uploaded by the user must not be deleted. For simplicity, we won’t test the cases where a user forgets to log out or log out is unsuccessful.

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. Ifthe 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.

TESTING NOTES: 1) When you are testing your assignment, you may run the server and multiple clients on the same machine on separate terminals. In this case, use 127.0.0.1 (local host) as the destination (e.g., Obi-wan’s in our example above) IP address. 2) For simplicity, we will run different clients at different directories, and won’t test the scenario that a file is received when a user is typing/issuing a command.

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: this is the IP address of the machine on which the server is running.

•   server_port: this is the port number being used by the server. This argument should be the 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

For CSE Students:

If you use Java:

java Client server_IP server_port client_udp_server_port

If you use C:

./client server_IP server_port client_udp_server_port

If you use Python:

python client.py server_IP server_port client_udp_server_port

Note: 1) The additional argument of client_udp_server_port for CSE Students for the P2P UDP communication is described in Section 3.4. In UDP P2P communication, one client program (i.e., Audience) acts as UDP server and the other client program (i.e., Presenter) acts as UDP client.  2) When you are testing your assignment, you can run the server and multiple clients on the same

machine on separate terminals. In this case, use 127.0.0.1 (local host) as the server IP address.

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.

For CSE Students, the client program also involves P2P communication using UDP. Similar to the above, the user should be prompted to enter the available P2P communication command: UPD. This function should be implemented using a new thread since the user may want to interact with the client program when the file is uploading. The thread will end when the upload finishes.  Similarly, the client UDP server should be implemented with another thread. However, this thread should be run until the client logs off since it is a UDP server thread. 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.

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.

4. Additional Notes

•   This is NOT a group assignment. You are expected to work on this individually.

• Tips on getting started: The best way to tackle a complex implementation task is to do it in stages. A good place to start would be to implement the functionality to allow a single user to log in with the server. Next, add the blocking functionality for several unsuccessful attempts. Then extend this to handle multiple clients. Once your server can support multiple clients,

implement the functions for broadcasting message, reading message, and separate room service. Finally, implement the features of downloading active users and logging off. Note that, this may require changing the  implementation  of some  of the  functionalities  that  you  have  already implemented. Once the communication with the server is working perfectly, you can move on to peer-to-peer communication (CSE Students only). It is imperative that you rigorously test your code to ensure that all possible (and logical) interactions can be correctly executed. Test, test, and test.

• Application Layer Protocol: Remember that you are implementing an application layer protocol for videoconferencing software. We are only considered the end result, i.e., the functionalities outlined above. You may wish to revisit some of the application layer protocols that we have studied (HTTP, SMTP, etc.) to see examples of the message format, actions are taken, etc.

• Transport Layer Protocol: You should use TCP for the communication between each client and server, (and UDP for P2P communication between two clients CSE Students only). The TCP connection should be set up by the client during the login phase and should remain active until the user logs off, while there is no such requirement for UDP. The server port of the server is specified as  a  command-line  argument.  (Similarly, the  server port number of UDP  is  specified  as  a command parameter of the client CSE Students only). The client ports for both TCP and UDP do not need to be specified. Your client program should let the OS pick up random available TCP or UDP ports.

• Backup and Versioning: We strongly recommend you back up your programs frequently. CSE backups all user accounts nightly. If you are developing code on your personal machine, it is strongly recommended that you undertake daily backups. We also recommend using a good versioning system such as Github or bitbucket so that you can roll back and recover from any inadvertent changes. There are many services available for which are easy to use. We will NOT entertain any requests for special consideration due to issues related to computer failure, lost files, etc.

• Language and Platform: You are free to use C, JAVA, or Python to implement this assignment. Please choose a language that you are comfortable with. The programs will be tested on CSE Linux machines. So please make sure that your entire application runs correctly on these machines (i.e., CSE lab computers) or using VLAB. This is especially important if you plan to develop and test the programs on your personal computers (which may possibly use a different OS or version or IDE). Note that CSE machines support the following: gcc version 8.2, Java 11, Python 2.7 or 3.7. If you are using Python, please clearly mention in your report which version of Python we should use to test your code. You may only use the basic socket programming APIs provided in your programming language of choice. You may not use any special ready-to-use libraries or APIs that implement certain functions of the spec for you.

•   There is no requirement that you must use the same text for the various messages displayed to the user on the terminal as illustrated in the examples in Section 8. However, please make sure that the text is unambiguous.

•   You are encouraged to use the forums on ED to ask questions and to discuss different approaches to solve the problem. However, you should not post your solution or any code fragments on the forums.

•   We will arrange for additional consultation hours in Weeks 7 - 10 to assist you with assignment- related questions if needed.

5. Submission

Please ensure that you use the mandated file name. You may of course have additional header files  and/or helper files. If you are using C, then you MUST submit a makefile/script along with your code