The University of Queensland
School of Electrical Engineering and Computer Science (EECS)
Semester One, 2024
COMS3200
Computer Networks I Assignment 2
Due: 3:00 pm 24th May 2024
Marks: 100
Weight: 25% of your final grade.
Version: 1.2
*Updates are marked as red
COMS3200 Assignment 2 2024
100 total marks, 25% overall course mark
Due: 15:00 24 May 2024
1. Preface
1.1. Notes
• This document is subject to change for the purpose of clarification. Changes made since the
original release will be highlighted in red.
• Please post any questions on the course Ed stem page.
• It is strongly recommended that all programming tasks are done in Python 3.9
1.2. Revision History
• Version 1.1: remove readme files, clarification on invalid commands.
2. Part A: Wireshark Questions (20 marks total)
This part is worth 20% of the assignment. This part covers Wireshark questions related to the Network
and Link Layer Protocols. Submit your answers to the quiz for Assignment 2 under the Assessment on
the Blackboard. You need to show your workings for all the questions in a report (e.g., the place where
you find the related information for a question). Marks may be withheld if the report with explanation
is not provided. There is no time limit to submit these answers and multiple resubmissions are
permitted. Note that only the last submitted attempt will be marked.
3. Part B: Programming (80 marks total)
This assignment involves building a multi-threaded chat system in Python3 using sockets and other
libraries (e.g., threading libraries). The problem is divided into two scenarios as follows:
1. Scenario 1: A server with one channel and multiple users.
2. Scenario 2: A server with multiple channels and multiple users.
Scenario 2 is an extension of scenario 1, hence, we will be repurposing some of the functions developed
for scenario 1 in the scenario 2. Along with some common requirements, each scenario will have some
scenario specific requirements. We will be using the same server and client python file for both the
scenarios. However, the config files will be different.
The recommended version is Python 3.9. We will provide you with code templates on the course
blackboard, and you are not allowed to use any other third-party library which is not included in the
code templates. Fulfill the requirements from the descriptions in function documentations.
3.1. Multi-thread chat Scenario 1: One channel, multiple users (40
marks).
You must implement a server program that can support concurrent communication between multiple
clients within a single channel. The specifics of channel such as channel name, channel capacity, and
channel port will be specified in an external config file.
Once in a channel, a client can send messages to other clients in the channel. A client will be identified
by his/her unique username. Your client and server programs must rely on socket and multithreading
libraries in Python. You may use any transport layer protocol, but it is highly recommended you use
TCP.
3.1.1. Functional Requirements
The server must be able to run by the following command:
where is the configuration file name (e.g., config1.txt) for the scenario 1.
The server configuration file must follow the following format: channel < channel_name > < channel_port>
Where is the name of the channel, is the port that the channel should
use, and is the maximum number of users who can be active at once within the
channel, respectively; for example, channel uqcyber 44444 5.
The client must be able to run by the below command:
where is the port of the channel and is the name which should be used to identify
the client in the channel (Note: should be unique in the channel). It’s not very common in
the real world for the clients to know the channel’s port. For simplicity, we assume that the client knows
the channel’s port.
The below requirements must be met:
• The channel must operate on a socket (it should not use ephemeral port).
• Channel names cannot contain a number or any special characters.
• Each channel’s capacity must be at most five.
If the configuration file is missing, invalid or not specified, then the server process should exit
immediately with status code 1 (Note: specifying the channel capacity more than five also renders the
config file invalid). Similarly, if the client cannot connect to the server due to malformed arguments or
an invalid port number, then the client process should also exit immediately with status code 1 (This
includes non-unique usernames).
Once the server is running, it will accept incoming client connections. If there’s space in the channel
(the number of clients is less than the channel capacity), the client gets accepted in the channel and
below message is displayed to the stdout of every client in the channel:
And the below is displayed to the server’s stdout:
Where is the server’s current time in 24 hour time and in hh:mm:ss format,
is the name of the channel, and is the name of the client.
Clients can send messages by typing in stdin. These messages are then sent to all other clients currently
on the same channel. For example, if the client named Bob types, “Hello COMS3200 students!” into
his stdin, the below message should be displayed to the stdout of both the server and all clients within
the channel:
If the channel is operating at a maximum capacity (the number of clients is equal to the capacity), they
$ python3 mchatserver.py
$ python3 mch atcl ient .py < u s e r n a m e >
[ Server message ()] has joined the channel.
[ Server message ()] has joined the < channel_name > channel.
[ Bob ()] Hello COMS3200 students!
will enter a first-in-first-out waiting queue specific to that channel. Once there is a free position in the
channel, the longest-waiting client will be removed from the waiting queue and entered the channel.
Upon entering the waiting queue, the below should be displayed on the client’s stdout: [ Server message ()] Welcome to the < channel_name > waiting room, .
When a client joins the waiting queue, and whenever another client leaves the queue, the below
should be displayed on the client’s stdout:
where is the number of users in the waiting queue who joined before this client.
3.1.2. Client-side Commands
Besides just broadcasting messages to each other, clients are also able to enter special commands
into
stdin:
• /send
The file on the sender’s machine located at will be sent to the client
named . The below message will be displayed to the sender’s stdout: [ Server message ()] You sent to .
and the below message will be displayed to the server’s stdout: [ Server message ()] sent to .
Where is the sender’s username.
If the client is not within the same channel as the sending client, then
neither of the above two messages are displayed and the file will not be sent.
Instead, the below message will be displayed to the sender’s stdout only: [ Server message ()] is not here.
If the file specified by does not exist, then only the below is displayed to the
sender’s stdout: [ Server message ()] does not exist.
If the file can be sent, it should be saved to the same directory as the target’s
chat-client executable.
If both the files do not exist and the target client is not within the same channel
as the sender, then both error messages should be displayed. The invalid client
message should be displayed first.
N.B. For testing purposes, we will always start the server process from its directory.
• /quit
The client who uses this command exits the channel and closes their connection to
the server. The below message is displayed to the stdout of both the server and
all remaining users: [ Server message ()] has left the channel.
This command should be usable while the client is still within a waiting queue as
well as within a channel. If a client in the queue uses this command, then only the
server should receive the above message.
[ Server message ()] You are in the waiting queue and there are user(s) ahead of you.
3.1.3. Server-side Commands
The server is also able to use these below commands by typing them into stdin:
• /kick
If there is a client named , in the channel named , they
will be removed and their connection to the server will be closed. The below message
is displayed to the stdout of the other user in the channel:
and the below message is displayed to the stdout of the server:
If there is no such client in the channel, then nothing is displayed to the clients’ stdout and
the below is displayed on the server’s stdout:
If the specified channel does not exist, then nothing is displayed to the clients’
stdout and the below should be displayed to the server’s stdout:
• /shutdown
The entire server will shut down. Connections to every client on every channel
and waiting queue will be closed and the server process will exit. No clients
should receive any messages.
• Anything entered in the server’s stdin which is not one of these commands should be
ignored.
3.2. Multi-thread chat Scenario 2: Multiple channels, multiple users. (40
marks)
You must extend the server program from scenario 1 such that it can support concurrent communication
between multiple clients across multiple channels. There are some additional requirements in this
scenario in addition to the prior requirements. The specifics of channel such as channel name, channel
capacity, and channel port will be specified in an external config file.
The server must be able to maintain at least three distinct channels simultaneously, each of them may
contain at most five simultaneous connections.
3.2.1. Functional Requirements
The server must be able to start by the following command:
where is the configuration file name for the scenario 2.
The server configuration file must follow the following format: channel < channel_name > < channel_port>
Each row in the configuration file denotes a channel; where is the name of the
channel, is the port that the channel should use, and is the
maximum number of users who can be active at once within the channel.
$ python3 mchatserver.py
[ Server message ()] has left the channel.
[ Server message ()] Kicked .
[ Server message ()] is not in < channel_name >.
[ Server message ()] < channel_name > does not exist.
The client must be able to be started by the below command:
where is the port of the channel and is the name which should be used to identify
the client in the channel (Note: should be unique in the channel).
In addition to the requirements from scenario 1, below requirements must be met:
• Each channel must operate on independent sockets.
• No two channels can have the same name or port.
• No channels should use ephemeral ports.
• There must be at least three channels in the config file.
• Channel names cannot contain a number or any special characters.
• Each channel’s capacity must be at most five.
All other functional requirements remain the same!
3.2.2. Client-side Commands
Besides just broadcasting messages to each other, clients are also able to enter special commands
into
stdin:
• /list
It displays the list of all channels on client’s stdout in the order in which they
are listed in the server configuration file. Each channel is listed on a separate line
according to the below format: [ Channel] < channel_name > Capacity: / < capacity >, Queue: < in_queue>.
Where is the name of the channel, is the port of the
corresponding channel, is the current number of clients currently in the channel,
is the total capacity of the channel, and is the number of clients
currently in the queue.
• /whisper
Only the client named receives the message. It will be displayed as: [< sender > whispers to you: ()]
Where is the username of the client who typed the whisper command.
The below message will be displayed to the server’s stdout: [ whispers to : ()]
If is not in the channel, the whisperer() will receive this message in
the stdout: [ Server message ()] is not here.
• /switch
The client leaves its current channel and joins the specified channel,
. If is full, it gets added to the
respective channel queue. If the specified channel exists, then the below
message is displayed to the stdout of both the server and every client remaining
in the channel. If the client uses it while in the queue, the following message
should display only to the stdout of the server and no other clients: [ Server message ()] has left the channel.
$ python3 mch atcl ient .py < u s e r n a m e >
The client who issued the switch command should be treated as a new client in
the new channel. The client should go through all the steps a new user goes
through while joining a new channel and receive respective messages.
If there exist a client in the new channel with same username as the current client,
, the client will stay in the current channel and the below message
would be displayed in its stdout: [ Server message ()] < channel_name > already has a user with username .
If the channel does not exist, then the client will stay in the current channel and
the below message will be displayed in its stdout: [ Server message ()] < channel_name > does not exist.
• Anything starting with “/” which is not one of these commands should be treated as a
chat message.
3.2.3. Server-side Commands
The server is also able to use these below commands by typing them into stdin:
• /mute
Prevents the client named in the channel named
from sending any messages for seconds.
If this client exists, then the below will be displayed to the server’s stdout:
The below is displayed to the muted client’s stdout:
and the below is displayed to every other client’s stdout:
If a client tries to send messages or use /whisper while muted, the below will be displayed to
the client’s stdout:
Where is the number of seconds remaining before the client is unmuted.
The message they attempted to send will not be sent to any other client.
If the client to be muted is not in the specified channel or the channel does not
exist, the below will be displayed to the server’s stdout:
must be a positive integer. If anything, other than a positive integer is
specified, then the below message should be displayed to the server’s stdout:
If both username and time are invalid, print both the error message should be displayed in
the respective order as shown.
All commands except /whisper should still be usable while muted.
• /empty
Every client in the channel named will have their connection
closed. The below will be displayed to the server’s stdout:
[ Server message ()] Muted for seconds.
[ Server message ()] You have been muted for seconds.
[ Server message ()] has been muted for seconds.
[ Server message ()] You are still muted for seconds.
[ Server message ()] is not here.
[ Server message ()] Invalid mute time.
[ Server message ()] < channel_name > has been emptied.
If the specified channel does not exist, then the below will be displayed to the server’s
stdout instead: [ Server message ()] < channel_name > does not exist.
No messages would be shown to any clients. Their connections would simply be
terminated.
3.2.4. Miscellaneous Requirements
• The use of select () Python are expressly forbidden - This includes the
Python’s select library functions such as devpoll, epoll, kqueue, poll, kevent
and select.
• Only one server process should run at any time.
• When a client’s connection with the server ends, the client process should exit.
• If a client in a channel does not send any message or use any command for 100
seconds, then it should be removed from the channel and their connection should
be closed. The below message should be displayed to the stdout of both the
server and all remaining clients in the channel: [ Server message ()] went AFK.
If a client is muted by the server, the timeout counter should freeze until the
client becomes unmuted. If a client attempts to chat or issues a command while
muted, their timeout counter should not reset.
• Everything taken from stdin should have whitespace stripped from both sides
before being evaluated as a chat message or a command.
• Commands may have multiple spaces between arguments.
• There’s a full stop in all the sentences, make sure to put it.
• If any command starts with the command code but has something wrong with it
including the spelling, number of arguments, or the structure of the argument, the
server should output to the stdout of the client using the command: [ Server message ()] Usage .
e.g., [Server message ()] Usage /switch .
• Server should NOT output anything to its stdout for the wrong usage of server
commands.
3.2.5 Marking Breakdown
Marks will be awarded according to the following breakdown:
1. Functionality common in Scenario 1 and 2
a. Client and server processes start correctly/ exit on invalid startup parameters: 5
marks.
b. Clients are held in the waiting queue until space available: 5 marks.
c. Clients are correctly removed after timing out: 5 marks.
2. Scenario 1 functionality:
a. Chat messages and announcements can be sent/received in one channel: 5 marks.
b. /send: 8 marks.
c. /quit: 5 marks.
d. /kick: 5 marks
e. /shutdown: 2 marks.
3. Scenario 2 functionality:
a. Chat messages and announcements can be sent/received in at least three channels. Chat
messages and announcements sent to one channel do not appear in others: 5 marks.
b. /list: 3 marks.
c. /whisper: 5 marks.
d. /switch: 5 marks
e. /mute: 5 marks.
f. /empty: 2 marks.
3.3 Miscellaneous Notes
• "Clients within a channel" refer only to those in the channel and not those in the related
waiting queue.
• Your code will not be tested for memory leaks but having large memory leaks may render your
code untestable. If you make any critical programming mistakes which impact our ability to
test your code, your marks may be severely limited.
• For marking purposes, you should ignore commands which have too many or too few
arguments.
3.4 Integrity
All code submissions will be checked for similarity and plagiarism. All code in your submission
which was not written by you (or was written by you for a previous assignment) must be correctly
referenced in IEEE format in your code. This includes code written by generative AI. Note that the
course coordinator and casual academic may interview some students if there is any suspicious
behavior.
3.5 Submission
You must submit all source code files and the report for part A together in a zip file in a format
specified in the Blackboard. This zip file must be submitted to the course Blackboard page under
Assessment ⇒ Assignment 2 ⇒ compressed file submission.
3.6 Resources
These resources may be of use to you:
• Joyce, P. (2022). Sockets. In: C and Python Applications. Apress, Berkeley,
CA. https://doi- org.ezproxy.library.uq.edu.au/10.1007/978-1-4842-7774-4_6
• Socket Programming HOWTO, available at: https://docs.python.org/3/howto/sockets.html.
• Socket Programming with Multi-threading in Python, https://www.tutorialspoint.com/socket-
programming- with-multi-threading-in-python
• The Linux Manual Page