COMP3331/9331 Computer Networks and Applications
Assignment for Term 1, 2022
Version 1.0
Due: 11:59am (noon) Friday, 22 April 2022 (Week 10)
1. Change Log
Version 1.0 released on 7th March 2022.
2. Goal and learning objectives
Online discussion forums are widely used as a means for large groups of people to hold
conversations on topics of mutual interest. A good example is the online forum used for this
course. In this assignment, you will have the opportunity to implement your own version of an
online discussion forum application. Your application is based on a client server model
consisting of one server and multiple clients communicating either sequentially (i.e., one at a
time) or concurrently. The client and server should communicate using both UDP and TCP. Your
application will support a range of functions that are typically found on discussion forums
including authentication, creation and deletion of threads and messages, reading threads,
uploading and downloading files. However, unlike typical online forums that are accessed
through HTTP, you will be designing a custom application protocol. Most functions should be
implemented over UDP except for uploading and downloading of files, which should use TCP.
2.1 Learning Objectives
On completing this assignment, you will gain sufficient expertise in the following skills:
1. Detailed understanding of how online discussion forums work.
2. Expertise in socket programming.
3. Insights into designing an application layer protocol and a fully functioning networked
application.
The assignment is worth 20 marks. We will test it in two distinct configurations. In the first
instance, we will test the interaction between the server and a SINGLE active client. All outlined
functionality will be tested. Multiple clients will connect to the server but sequentially – one
client connects, interacts, exits, the second client connects, interacts, exits and so on. The first
configuration is worth 14 marks (70% of the total mark). In the second instance, we will test
the interaction of the server with multiple concurrent clients. All outlined functionality will be
tested. The second configuration is worth 6 marks. Submissions from CSE students will be
tested in both configurations. Submissions from non-CSE students will only be tested in the first
configuration. The marking guidelines are thus different for the two groups and are indicated in
Section 7.
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
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.
2
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 cs3331@cse.unsw.edu to seek approval before 5pm, 18th March
(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. Assignment Specification
In this programming assignment, you will implement the client and server programs of a
discussion forum application, similar in many ways to the discussion forum we use for this
course. The difference being that your application is not web-based (i.e. non-HTTP) but uses a
custom application layer protocol which you will design. The client and server must
communicate using both UDP and TCP as described in the rest of the specification. Your
application will support a range of operations including creating a new user account, creating
and deleting a new thread, posting a message on a thread, editing or deleting messages, uploading
and downloading files to/from a thread, reading a thread, and listing all threads. You will
implement the application protocol to implement these functions. Most of the communication
between the client and server will take place over UDP, except for file uploads and downloads
which must use TCP. The server will listen on a port specified as the command line argument
and will wait for a message from the client. When a user executes a client, the authentication
process will be initiated. 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. 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. All communication between the
client and server must happen over UDP. The only exception is uploading and downloading files
to/from a thread, where the file transfer process must use TCP. The implementation of these
operations will require your client to initiate a TCP connection with the server. The server would
first need to open a TCP port using the port number specified as the command line argument and
listen for connection requests. Note that, UDP and TCP port numbers are distinct (e.g., UDP port
53 is distinct from TCP port 53). Thus, your server can concurrently open a UDP and TCP port
with the specified port number (as the command line argument). Once the TCP connection is
established, the file upload or download should be initiated. The TCP connection should be
immediately closed after the file transfer is completed.
The assignment will be tested in two configurations. In the first configuration, the server will
interact with a single client at any given time. The interaction will involve authentication
followed by the execution of several commands, one after the other. Multiple clients can connect
with the server in a serial fashion, i.e., one client is initiated, the client authenticates and executes
several commands one after the other and quits, a second client is initiated, authenticates,
executes several commands, and quits, and so on. The server design is significantly simplified
(i.e., you won’t need to deal with concurrency) if you only wish to implement this portion of the
assignment. A correct implementation of this first part is worth 70% of the assignment marks
(14 marks, see Section 7). In the second configuration, the server must interact with multiple
clients concurrently. The client design should not require any changes to meet this requirement.
3
The server design, however, would require a significant change, in that, the server would need
to send and receive messages to and from multiple clients concurrently. We strongly recommend
using multi-threading to achieve this. The interaction with a single client, would however be
similar as in the first configuration. Note that, a correctly implemented multi-threaded server
should also be able to interact correctly with a single client at any given time. So, if you design
your client and server to achieve all functionality expected for the second configuration, it should
work as expected in the first configuration.
The server program will be run first followed by one or more instances of the client program
(each instance supports one client in the second configuration). They will be run from different
terminals on the same machine (so you can use localhost, i.e., 127.0.0.1 as the IP address for
the server and client in your program). All interaction with the clients will be through a command
line interface.
3.1 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. Submission instructions are in Section 5.
The server should accept one argument:
• server_port: this is the port number which the server will use to communicate with
the clients. Since TCP and UDP ports are distinct, the server can open a UDP and TCP
port with the same port number. Recall that UDP is connectionless, so the server should
be able to communicate with multiple clients (in the second configuration) through a
single server-side UDP socket. Also, a TCP socket is NOT uniquely identified by the
server port number. It should thus be possible for multiple TCP connections to use the
same server-side port number (when multiple clients are simultaneously
uploading/downloading files to/from the server in the second configuration).
The server should be executed before the clients. You may assume that the server will remain
executing forever. While marking, we will not abruptly kill the server or client processes (CTRLC).
The server is not expected to maintain state from previous executions. When it is executed,
it is assumed that no users are logged on and that the discussion forum is empty, i.e., there are
no threads or messages. The spec indicates that we will test your code in two configurations. We
The server will remain executing for the entire duration that encompasses all tests. In other
words, the server will not be restarted after concluding the tests for the first configuration.
It should be initiated as follows:
If you use Java:
java Server server_port
If you use C:
./server server_port
If you use Python:
python server.py server_port OR
python3 server.py server_port
4
The client should accept one argument:
• 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.
Note that, you do not have to specify the port to be used by the client. You should allow the OS
to pick a random available port (for both UDP and TCP). Each client should be initiated in a
separate terminal as follows:
If you use Java:
java Client server_port
If you use C:
./client server_port
If you use Python:
python client.py server_port OR
python3 client.py server_port
3.2 Authentication
You may assume that a credentials file called credentials.txt will be available in the current
working directory of the server with the correct access permissions set (read and write). This file
will contain username and passwords of authorised users. They contain uppercase characters (AZ),
lowercase characters (a-z) and digits (0-9) and special characters (~!@#$%^&*_-
+=`|\(){}[]:;"'<>,.?/). Username and passwords are case-sensitive, so Yoda and yoda are
distinct usernames. An example credentials.txt file is provided on the assignment page. 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. Neither the username nor password will contain white spaces.
There will only be one password per username. The credentials.txt file will terminate with a ‘\n’
(newline character). There will be no other empty lines in this file.
Upon execution, a client should prompt the user to enter a username. The username should be
sent to the server. The server should check the credentials file (credentials.txt) for a match. If the
username exists, the server sends a confirmation message to the client. The client prompts the
user to enter a password. The password is sent to the server, which checks for a match with the
stored password for this user. The server sends a confirmation if the password matches or an
error message in the event of a mismatch. An appropriate message (welcome or error) is
displayed to the user. In case of a mismatch, the client prompts the user to enter a username and
the process explained above is repeated. You may assume that there is no limit to the number of
login attempts that a user may try if they keep entering a wrong password. If the username does
not exist, it is assumed that the user is creating a new account and the server sends an appropriate
message to the client. The client prompts the user to enter a new password. You may assume the
password format is as explained above (no need to check). The password is sent to the server.
The server creates a new username and password entry in the credentials file (appending it as the
last entry in the file). A confirmation is sent to the client. The client displays an appropriate
message to the user. 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). After successful authentication, the client is assumed to be
logged in. All messages exchanged for implementing authentication should use UDP.
5
When your assignment is tested with multiple concurrent clients, the server should also check
that a new client that is authenticating with the server does not attempt to login with a username
that is already being used by another active client (i.e., the same username cannot be used
concurrently by two clients). The server should keep track of all users that are currently logged
on and check that the username provided by an authenticating client does not match with those
in this list. If a match is found, then a message to this effect should be sent to the server and
displayed at the prompt for the user and they should be prompted to enter a username.
3.3 Discussion Forum Operations
Following successful login, the client displays a message to the user informing them of all
available commands and prompting to select one command. The following commands are
available: CRT: Create Thread, LST: List Threads, MSG: Post Message, DLT: Delete Message,
RDT: Read Thread, EDT: Edit Message, UPD: Upload File, DWN: Download File, RMV:
Remove Thread, XIT: Exit. All available commands should be shown to the user in the first
instance after successful login. Subsequent prompts for action should include this same message.
If an invalid command is entered, 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
(CRT, MSG, 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). You may assume that all
arguments including thread names, file names and the message text may contain uppercase
characters (A-Z), lowercase characters (a-z), digits (0-9) and the ‘.’ special character. The
message text can additionally contain white spaces. You are not required to check if the names
or message text adhere to this format.
If the user does not follow the expected usage of any of the operations listed below, i.e., missing
(e.g., not specifying the title of the thread when creating a thread) or additional arguments, 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.
The error checking described above can be readily implemented in the client program.
The application can support 10 different commands. 8 of these (excluding file upload and
download) should use UDP for communication. Note that UDP segments can be occasionally
lost, so you should implement some simple mechanisms such as a retransmission timer to deal
with the possibility of packet loss. We will leave the specifics for you to decide. We have
discussed several mechanisms for implementing reliable data transfer in the lectures. The file
upload and download commands (UPD and DWN) should use TCP for transferring the file. The
server should first open a TCP socket on the port number specified in the command line argument
(UDP and TCP ports are distinct, so the server can simultaneously use UDP port X and TCP port
X). The client should initiate the establishment of the TCP connection. Once the TCP connection
is established, the file transfer should be initiated from the client (UPD) or the server (DWN).
The TCP connection should be closed immediately after the file transfer concludes. Since the
file transfer takes place over TCP, you do not have to worry about reliable transfer of the file.
The execution of each individual command is described in detail below.
6
CRT: Create Thread
CRT threadtitle
The title of the new thread (threadtitle) should be included as an argument with this command.
Thread titles are one word long and case sensitive. The client should send the command (CRT),
the title of the thread and the username to the server. Each thread is represented as a text file in
the current working directory of the server with the same file name as the thread title (threadtitle,
DO NOT add “.txt” extension to the name). The first line of the file should contain the username
who created the thread. Each subsequent line should be a message, added in the chronological
sequence in which they were posted. The server should first check if a thread with this title exists.
If so, an error message should be conveyed to the client and displayed at the prompt to the user.
If the thread does not exist, a new file with the provided title should be created as per the
convention noted above (the first line of this file should be the username of the creator). You
may assume that the server program will have permission to create a file in the current working
directory. A confirmation message should be sent to the server and displayed at the prompt to
the user. The client should next prompt the user to select one of the available commands.
MSG: Post Message
MSG threadtitle message
The title of the thread that the message should be posted to and the message should be included
as arguments. Note that, the message may contain white spaces (e.g. “hello how are you”). The
client should send the command (MSG), the title of the thread, the message and the username to
the server. In our tests, we will only use short messages (a few words long). The server should
first check if a thread with this title exists. If so, the message and the username should be
appended at the end of the file in the format, along with the number of the message (messages
within each thread are numbered starting at 1):
messagenumber username: message
An example:
1 yoda: do or do not, there is no try
A confirmation message should be sent to the server and displayed to the user. If the thread with
this title does not exist, an error 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.
DLT: Delete Message
DLT threadtitle messagenumber
The title of the thread from which the message is to be deleted and the message number within
that thread to be deleted should be included as arguments. A message can only be deleted by
the user who originally posted that message. The client sends the command (DLT), the title
of the thread, the message number and the username to the server. The server should check if a
thread with this title exists and if the corresponding message number is valid and finally if this
user had originally posted this message. In the event that any of these checks are unsuccessful,
an appropriate error message should be sent to the client and displayed at the prompt to the user.
7
If all checks pass, then the server should delete the message, which entails deleting the line
containing this message in the corresponding thread file (all subsequent messages and
information about uploaded files in the thread file should be moved up by one line and the
message numbers should be updated appropriately) and a confirmation 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.
EDT: Edit Message
EDT threadtitle messagenumber message
The title of the thread from which the message is to be edited, the message number within that
thread to be edited and the new message should be included as arguments. A message can only
be edited by the user who originally posted that message. The client should send the command
(EDT), the title of the thread, the message number, the new message and the username to the
server. The server should check if a thread with this title exists and if the corresponding message
number is valid and finally if the username had posted this message. In the event that any of
these checks are unsuccessful, an appropriate error message should be sent to the client and
displayed at the prompt to the user. If all checks pass, then the server should replace the original
message in the corresponding thread file with the new message (the rest of the details associated
with this message, i.e. message number and username should remain unchanged) and a
confirmation 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 commands.
LST: List Threads
LST
There should be no arguments for this command. The client sends the command (LST) to the
server. The server replies back with a listing of all the thread titles. Only the thread titles should
be listed, not the messages. The client should print the list on the terminal (one thread per line).
If there are no active threads, then a message to that effect should be displayed at the prompt to
the user. The client should next prompt the user to select one of the available commands.
RDT: Read Thread
RDT threadtitle
The title of the thread to be read should be included as an argument. The client should send the
command (RDT) and the title of the thread to be read to the server. The server should check if a
thread with this title exists. If so, the server should send the contents of the file corresponding to
this thread (excluding the first line which contains the username of the creator of the thread) to
the client. The client should display all contents of the file including messages and information
about uploaded files (see next action) at the terminal to the user. If the thread with this title does
not exist, an error 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.
UPD: Upload file
UPD threadtitle filename
8
The title of the thread to which the file is being uploaded to and the name of the file should be
included as arguments. Thread titles and file names are case sensitive. 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 (e.g., text file), i.e., assume that it is a binary file. Be careful to not use
functions for file access (reading, writing, etc.) that assume the file to be in text format. The
client should send the command (UPD), the title of the thread, the username, and the name of
the file being uploaded to the server. The server should check if a thread with this title exists. If
it does not, then an appropriate error message should be sent to the client and displayed at the
prompt to the user. The server should also check if a file with the provided file name already
exists. If it does, an appropriate error message should be conveyed to the client and displayed at
the prompt to the user (Note that the same file can be uploaded to different threads). If the thread
exists and the file has not already been uploaded to the thread, then a confirmation message
should be sent to the client. Following this, the client should transfer the contents of the file to
the server. All communication between the client and server described so far should happen over
UDP. TCP should only be used for transferring the contents of the file. The TCP connection
should be immediately closed after completion of the file transfer. The file should be stored in
the current working directory of the server with the file name threadtitle-filename (DO NOT add
an extension to the name. If the filename has an extension in the name, retain it, e.g., test.exe
should be stored as threadtitle-test.exe). File names are case sensitive and one word long. You
may assume that the server program will have permission to create a file in its current working
directory. A record of the file should be noted on the thread, i.e., an entry should be added at the
end of the file corresponding to the thread title indicating that this user has uploaded a file with
the specified name. The format should be as follows (note the lack of a message number which
differentiates it from a message):
Username uploaded filename
The entries for file uploads cannot be edited using the EDT command or deleted using the DLT
command. They should however be included when a thread is read using the RDT command.
Finally, the server should send a confirmation message to the client and a message to this effect
should be displayed at the prompt to the user. The client should next prompt the user to select
one of the available commands.
DWN: Download file
DWN threadtitle filename
The title of the thread from which the file is being downloaded and the name of the file should
be included as arguments. The client should send the title of the thread and the name of the file
to the server. The server should check if a thread with this title exists and if so whether a file
with this name was previously uploaded to the thread. If either check does not match, then an
appropriate error message should be sent to the client and displayed at the prompt to the user. If
a match is found, then the server should transfer the contents of the file to the client. As with the
UPD command, all communication between the client and server described so far should happen
over UDP. TCP should only be used for transferring the contents of the file. The TCP connection
should be immediately closed after completion of the file transfer. The client should write the
contents to a local file in the current working directory of the client with the same name
(filename, DO NOT include threadtitle in the file name). You may assume that the client program
will have permission to create a file in the current working directory. You may also assume that
a file with this same name does not exist in the current working directory of the client. Once the
9
file transfer is complete, a confirmation message should be displayed at the prompt to the user.
The client should next prompt the user to select one of the available commands. Note that, the
file should NOT be deleted at the server end. The client is simply downloading a copy of the file.
TESTING NOTES: (1) When you test the operation of the UDP and DWN command, you will
likely first upload a test file from the client to the server using the UPD and then try to download
the same file from the server using the DWN command. You should make sure that you remove
this file from the current working directory of the client between these two commands (to be
consistent with the assumption stated in the description above). You can do this by opening a
separate terminal and deleting this file from the client’s working directory. (2) For similar
reasons, when testing your program under the second configuration, make sure that the multiple
clients are executed in different working directories.
RMV: Remove Thread
RMV threadtitle
The title of the thread to be removed should be included as an argument with this action. A
thread can only be removed by the user who originally created that thread. The client should
send the operation (RMV), the title of the thread and the username to the server. The server
should first check if a thread with this title exists and if so, whether the user who created the
thread matches with the provided username. If either check doesn’t match, then an error message
should be sent to the client and displayed at the terminal to the user. Else, the thread is deleted
including the file storing information about the thread, any files uploaded to the thread and any
state maintained about the thread at the server. A confirmation message should be sent to the
client which is displayed at the prompt to the user. The client should next prompt the user to
select one of the available actions.
XIT: Exit
XIT
There should be no arguments for this command. The client should inform the server that the
user is logging off 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. Note that, any
messages and files uploaded by the user must not be deleted.
3.3 Program Design Considerations
Transport Layer
You MUST use UDP for communicating between the client and server to implement the
authentication process and 8 of the 10 commands, i.e., excluding UPD and DWN. TCP should
only be used for transferring the contents of the file. All other message exchanges required to
implement UDP and DWN should use UDP. Remember that UDP is connectionless and that
your client and server programs must explicitly create UDP segments containing your
application messages and send these segments to the other endpoint. The client has the socket
information about the server (127.0.0.1 and server_port). The server program should extract
the client-side socket information from the UDP segment sent by the client. The responses sent
by the server to the client should be addressed to this socket. Note that a maximum size of UDP
segment is 65,535 bytes. The loopback interface (127.0.0.1) on the machine you are executing
10
the program on may have a smaller MSS value. Either way, it is unlikely that you would need to
send very large UDP segments, so this should not be an issue.
Since, UDP segments can be occasionally lost, you must implement some simple mechanisms
to recover from it. We have discussed several mechanisms for implementing reliable data
transfer in the lectures. You are free to use one or more of those in your implementation. We do
not specifically mandate the mechanisms to be used.
The file transfer process associated with the UPD and DWN commands should use TCP.
The server port is specified as a command line argument (server_port). Note that TCP and
UDP ports are distinct, so the server can open a TCP port at server_port and a UDP port at
server_port. The client port does not need to be specified. Your client program should let the
OS pick a random available port.
If you no not adhere to the choice of the transport layer as noted in the specification, then a
significant penalty will be assessed.
Client Design
The client program should be relatively straightforward. The client needs to interact with