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

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.

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 (CTRL- C). 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

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 (A- Z),  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.

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.

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.

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

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

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