【COMP3331/9331】Assignment

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 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 promptsfor 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 operationslisted 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 argumentsthan 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 wordslong) . 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 issuccessfully 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 theprovided 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.