COMP3331/9331 Computer Networks and Applications Assignment for Term 3, 2020
Version 1.3
Due: 11:59am (noon) Friday, 20 November 2020 (Week 10)
1. Change Log
Version 1.0 released on 5th Oct 2020.
Version 1.1 released on 8th Oct 2020: minor update to naming convention for thread/file names. Version 1.2 released on 19th Oct 2020: fixed some minor inconsistencies.
Version 1.3 released on 4th Nov 2020: fixed some errors in the sample interaction for 2 clients.
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 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.
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.
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.
1
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 criteria and wishes to avail of this option MUST email cs3331@cse.unsw.edu to seek approval before 5pm, 16th October (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 over TCP. Your application will support a range of operations including create a new user account, create or delete a new thread, post a message on a thread, edit or delete messages, upload and download attachments to/from a thread, read a thread, list all threads and shutting down the server. 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. 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.
The assignment will be tested in two configurations. In the first configuration, the server will interact with a single client at any given time. Multiple clients can connect with the server in a serial fashion, i.e., one client connects, interacts and quits, the second client connects, interacts and quits, and so on. The server design is significantly simplified (i.e. you won’t need to use multi-threading) 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 will only require minimal 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.
3.1 File Names & Execution
The main code for the server and client should be contained in the following files: server.c, 2
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 the following arguments:
• server_port: this is the port number which the server will use to communicate with the clients. Recall that 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 (in Part 2).
• admin_passwd:thisistheadminpasswordfortheserver.Itisrequiredtoshutdownthe server (see operation SHT later).
The server should be executed before any of the clients. It should be initiated as follows: If you use Java:
java Server server_port admin_passwd
If you use C:
./server server_port admin_passwd
If you use Python:
python server.py server_port admin_passwd OR python3 server.py server_port admin_passwd
The client should accept the following two 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.
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. Each client should be initiated in a separate terminal as follows:
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 OR python3 client.py server_IP server_port
Note: When you are testing your assignment, you should run the server and one or more clients on the same machine in separate terminals. In this case, use 127.0.0.1 (local host) as the server IP address.
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-
3
Z), lowercase characters (a-z) and digits (0-9) and special characters (~!@#$%^&*_- +=`|\(){}[]:;”‘<>,.?/). 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. There will only be one password per username. A sample credentials file is provided on the assignment page. We may use a different file while testing.
Upon execution, a client should first attempt to setup a TCP connection with the server. Assuming the connection is successful, the 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 is displayed to the user. In case, of a mismatch, the client prompts the user to enter a username. If the username does not exist, the sever sends an appropriate message to the client. The client prompts the user to enter a new password. 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).
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. a username cannot be used concurrently by two clients). The server should keep track of all active users 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:
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 (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) and digits (0-9) and the following limited set of special characters (!@#$%.?,).
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, SHT: Shutdown Server. 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.
4
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 incorrect number of arguments (e.g., 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 11 commands that users can execute. The execution of each individual command is described 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. 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 as the title of the thread (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.
5
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 in the file should be moved up by one line and their 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
6
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. 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 client should send the command (UPD) and the title of the thread 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. If the thread exists, then a confirmation message should be sent to the client. The client should next send the username and file name to the server. Following this, the client should transfer the contents of the file to the server. 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. You may assume that the file name will be unique for each thread (i.e., if a file with a particular name has been uploaded to a thread, then no other user will upload a file with that same name to that thread). However, a file with the same name could be uploaded to a different thread. 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 the 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. 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
7
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 this command, you will likely first upload a test file from the client to the server using the previous command 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 close the TCP connection 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.
SHT: Shutdown
SHT admin_password
The admin password should be provided as the argument. The client should send the command (SHT) and the admin password to the server. Note that, the admin password is provided to the server as the second command line argument during execution. It is NOT included in the credentials file. The server should check the provided password against the admin password. If the passwords do not match, then 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 actions. If the passwords match, then the server should initiate shutdown process. This includes
8
sending a shutdown message to all active clients (in the case when we are testing with multiple concurrent clients). Each client will display an appropriate message at the terminal to the user indicating that the discussion forum is shutting down and close the socket. The server should delete all files that were (only) created by the server program in the current working directory including files for all active threads and any files uploaded to the threads and the credentials file. The client need not delete any files in the current working directory. All sockets should be closed.
3.3 Program Design Considerations
Transport Layer
You MUST use TCP for this assignment. This ensures that your client and server programs do not have to worry about reliable delivery of messages to each other. The use of UDP is likely to attract a heavy penalty.
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 the 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 discussion forum.
Only one minor change would be needed in the client design as you progress the implementation from the first configuration to the second configuration. This has to do with the shutdown process. In the first configuration, only the client currently connected to the server can initiated the shutdown process. However, in the second configuration, any one of the concurrently connected clients could initiate the shutdown process. This would mean a client instance may receive a message from the server at any time indicating that it is shutting down (due to the issuance of the SHT command by one of the other clients). This is the only difference with the first configuration on the client end. A client program that correctly implements functionality for the second configuration should be able to correctly accomplish all interactions expected in the first configuration.
Server Design
The server code will be fairly involved compared to the client as the server is responsible for maintaining the message forum. However, the server design to implement functionality for the first configuration of testing should be relatively straightforward as the server needs to only interact with one client at a time. When the server starts up, the forum is empty – i.e., there exist no threads, no messages, no uploaded files. The server should wait for a client to connect, perform authentication and service each command issued by the client sequentially. After the client exits, the server should wait for a new client to connect. Note that, you will need to define a number of data structures for managing the current state of the forum (threads, posts, files). Implementing functionality for the second configuration will require a significant change as the server must interact with multiple clients simultaneously. A robust way to achieve this to use multithreading. In this approach, you will need a 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
9
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. This process is exactly similar to what you would have implemented to meet the functionality of the first configuration. 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. A server program that correctly implements functionality for the second configuration should be able to correctly accomplish all interactions expected in the first configuration.
4. Additional Notes
• This is NOT 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. We recommend that you first implement the functionality for the first configuration, i.e., the server interacts with a single active client at any time. A good place to start would be to implement the functionality to allow a single user to login with the server. Next, add functionality to implement one command. Ensure you thoroughly test the operation of each command, including typical error conditions, and then progress to the next. We recommend that you start with the simpler commands such as CRT, MSG, LST before progressing to more complex commands such as UPD and DWN. Once you have thoroughly tested your code for the first configuration, proceed to the second configuration. 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 realising a fully functional discussion forum. You will have to design the format (both syntax and semantics) of the messages exchanged between the client and server and the actions taken by each entity on receiving these messages. We do not mandate any specific requirements with regards the design of your application layer protocol. We are only considered with the end result, i.e. the functionality outlined above. You may wish to revisit some of the application layer protocols that we have studied (HTTP, SMTP, etc.) to see examples of message format, actions taken, etc.
• Transport Layer Protocol: You should use TCP for transferring messages between each client and server. The TCP connection should be setup by the client on initiation and should remain active until the user exits or one of the other concurrently connected users initiates shutdown (only in the second configuration). The server port is specified as a command line argument. The client port does not need to be specified. Your client program should let the OS pick a random available port.
• Backup and Versioning: We strongly recommend you to 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 so that you can roll back and recover from any inadvertent changes. There are many services available for both which are easy to use. We will NOT entertain any requests for special consideration due to issues related to computer failure, lost files, etc.
10
• Language and Platform: Y ou are free to use C, JA V A 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. your 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 and 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 providing 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 clear and unambiguous.
• You are strongly encouraged to use the course forum on WebCMS 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 consultations in Weeks 7-10 to assist you with assignment related questions. Information about the consults will be announced via the website.
5. Submission
Please ensure that you use the mandated file names (see Section 3.1). 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 (not necessary with Java or Python). This is because we need to know how to resolve the dependencies among all the files that you have provided. After running your makefile we should have the following executable files: server and client. In addition, you should submit a small report, report.pdf (no more than 3 pages) describing the program design, the application layer message format and a brief description of how your system works. Also discuss any design trade-offs considered and made. Describe possible improvements and extensions to your program and indicate how you could realise them. If your program does not work under any particular circumstances, please report this here. If you have not implemented functionality for handling multiple concurrent clients, then you should indicate this in the report. Also indicate any code segments that were borrowed from the Web or other sources.
You are required to submit your source code and report.pdf. You can submit your assignment using the give command through VLAB. Make sure you are in the same directory as your code and report, and then do the following:
1. Type tar -cvf assign.tar filenames
e.g. tar -cvf assign.tar *.java report.pdf
2. When you are ready to submit, at the bash prompt type 3331
3. Next, type: give cs3331 Assign assign.tar (You should receive a message
stating the result of your submission). The same command should be used for 3331 and 9331. Alternately, you can also submit the tar file via the WebCMS3 interface on the assignment page.
11
Important Notes
• The system will only accept assign.tar submission name. All other names will be rejected.
• Ensure that your program/s are tested in the VLAB environment before submission. In the past, there were cases where tutors were unable to compile and run students’ programs while marking. To avoid any disruption, please ensure that you test your program in the VLAB environment before submitting the assignment. Note that, we will be unable to award any significant marks if the submitted code does not run during marking.
• You may submit as many times before the deadline. A later submission will override the earlier submission, so make sure you submit the correct file. Do not leave until the last moment to submit, as there may be technical, or network errors and you will not have time to rectify it.
Late Submission Penalty: Late penalty will be applied as follows:
• 1 day after deadline: 10% reduction
• 2 days after deadline: 20% reduction
• 3 days after deadline: 30% reduction
• 4 days after deadline: 40% reduction
• 5 or more days late: NOT accepted
NOTE: The above penalty is applied to your final total. For example, if you submit your assignment 1 day late and your score on the assignment is 10, then your final mark will be 10 – 1 (10% penalty) = 9.
6. Plagiarism
You are to write all of the code for this assignment yourself. All source codes are subject to strict checks for plagiarism, via highly sophisticated plagiarism detection software. These checks may include comparison with available code from Internet sites and assignments from previous semesters. In addition, each submission will be checked against all other submissions of the current semester. Do not post this assignment on forums where you can pay programmers to write code for you. We will be monitoring such forums. Please note that we take this matter quite seriously. The LIC will decide on appropriate penalty for detected cases of plagiarism. The most likely penalty would be to reduce the assignment mark to ZERO. We are aware that a lot of learning takes place in student conversations, and don’t wish to discourage those. However, it is important, for both those helping others and those being helped, not to provide/accept any programming language code in writing, as this is apt to be used exactly as is, and lead to plagiarism penalties for both the supplier and the copier of the codes. Write something on a piece of paper, by all means, but tear it up/take it away when the discussion is over. It is OK to borrow bits and pieces of code from sample socket code out on the Web and in books. You MUST however acknowledge the source of any borrowed code. This means providing a reference to a book or a URL when the code appears (as comments). Also indicate in your report the portions of your code that were borrowed. Explain any modifications you have made (if any) to the borrowed code.
12
7. Marking Policy
The following table outlines the marking rubric for both CSE and non-CSE students. For CSE students, 14 marks are attributed towards testing the interaction between the server and one active client (multiple clients will connect sequentially one after the other as in the sample interaction provided). 6 marks are attributed towards testing the interaction between the server and multiple concurrent clients. You should test your program rigorously before submission. All submissions will be manually marked by your tutors and NOT auto marked. Some helper scripts may be used to assist with the marking. Your submissions will be marked using the following criteria:
Functionality
Marks (CSE)
Marks (Non- CSE)
Successful authentication for an existing and new user including all error handling
1
1.5
Successful creation of a new thread (CRT command) including all error handling
1
1.5
Successful creation of a new message (MSG command) including all error handling
1
1.5
Successful listing of active threads (LST command) including all error handling
0.5
0.75
Successful reading of an active thread (RDT command) including all error handling
1
1.5
Successful editing of an existing message (EDT command) including all error handling
1
1.5
Successful deletion of an existing message (DLT command) including all error handling
1
1.5
Successful deletion of an active thread (RMV command) including all error handling
1
1.5
Successful uploading of a file to a thread (UPD command) including all error handling
1.5
2.25
Successful download of a file from a thread (DWN command) including all error handling
1.5
2.25
Successful log off for a logged in user (XIT command) including all error handling
0.5
0.75
Successful shutdown of the server (SHT command) including all error handling
1
1.5
Properly documented report
1
1
Code quality and comments
1
1
Successful authentication of multiple concurrent existing and new users including all error handing
0.5
N/A
Successful execution of all 11 commands and associated error handling (11 x 0.5 marks each)
5.5
N/A
NOTE: While marking, we will be testing for typical usage scenarios for the above functionality and some straightforward error conditions. A typical marking session will last for about 15-20 minutes. When testing with multiple concurrent clients, we will spawn a maximum of 3 concurrent clients. However, please do not hard code any specific limits in your programs. We won’t be testing your code under very complex scenarios and extreme edge cases.
13
8. Sample Interaction
In the following we provide examples of sample interactions for both configurations to be tested. Your server and client code should display similar meaningful messages at the terminal. You do not have to use the same text as shown below. Note that, this is not an exhaustive summary of all possible interactions. Our tests will not necessarily follow this exact interaction shown.
First Configuration
In this configuration, the server interacts with a single client at any given time. It is recommended to execute the client and server in different working directories. Ensure that write permissions are enabled on the credentials file. In the following, two clients with usernames Yoda and Obi- wan connect and interact with the server sequentially in that order. The inputs from the user are shown as underlined in the client terminal. Extra spacing is inserted in the server terminal to align the output with corresponding user interaction at the client end.
Client Terminal
Server Terminal
>java Client 127.0.0.1 5000 Enter username: Yoda
Enter password: sdrfdfs12 Invalid password
Enter username: Yoda
Enter password: jedi*knight Welcome to the forum
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: LST
No threads to list
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: HELLO
Invalid command
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: CRT 3331
Thread 3331 created
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: CRT 3331
Thread 3331 exists
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: CRT 9331
Thread 9331 created
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV,
>java Server 5000 destroyforum Waiting for clients
Client connected
Incorrect password
Yoda successful login
Yoda issued LST command
Yoda issued CRT command Thread 3331 created
Yoda issued CRT command Thread 3331 exists
Yoda issued CRT command Thread 9331 created
14
XIT, SHT: LST 3331
Incorrect syntax for LST
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: LST
The list of active threads: 3331
9331
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: MSG 3331 Networks is awesome
Message posted to 3331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT
Incorrect syntax for RDT
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 9331
Thread 9331 is empty
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 3331
1 Yoda: Networks is awesome
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: UPD 3331 test.exe
test.exe uploaded to 3331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 3331
1 Yoda: Networks is awesome
Yoda uploaded test.exe
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RMV 9331
Thread 9331 removed
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: XIT
Goodbye
>java Client 127.0.0.1 5000
Enter username: Obi-wan
Enter new password for Obi-wan: r2d2 Enter one of the following commands: CRT,
Yoda issued LST command
Yoda issued MSG command Message posted to 3331 thread
Yoda issued RDT command Thread 9331 read
Yoda issued RDT command Thread 3331 read
Yoda issued UPD command
Yoda uploaded file test.exe to 3331 thread
Yoda issued RDT command Thread 3331 read
Yoda issued RMV command Thread 9331 removed
Yoda exited
Waiting for clients
Client connected
New user
Obi-wan successfully logged in
15
MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: CRT 9331
Thread 9331 created
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: MSG 9331 Networks exam PWNED me
Message posted to 9331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: MSG 3331 Networks exam PWNED me
Message posted to 3331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: LST
The list of active threads: 3331
9331
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 331
Thread 331 does not exist
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 3331
1 Yoda: Networks is awesome
Yoda uploaded test.exe
2 Obi-wan: Networks exam PWNED me
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: DWN 9331 test.exe
File does not exist in Thread 9331
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: DWN 3331 test.exe
test.exe successfully downloaded
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: EDT 3331 1 I PWNED Networks exam
The message belongs to another user and cannot be edited
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: EDT 3331 2 I PWNED Networks exam
The message has been edited
Enter one of the following commands: CRT,
Obi-wan issued CRT command Thread 9331 created
Obi-wan issued MSG command Obi-wan posted to 9331 thread
Obi-wan issued MSG command Obi-wan posted to 3331 thread
Obi-wan issued LST command
Obi-wan issued RDT command Incorrect thread specified
Obi-wan issued RDT command Thread 3331 read
Obi-wan issued DWN command
test.exe does not exist in Thread 9331
Obi-wan issued DWN command
test.exe downloaded from Thread 3331
Obi-wan issued EDT commend Message cannot be edited
Obi-wan issued EDT commend Message has been edited
16
MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 3331
1 Yoda: Networks is awesome Yoda uploaded test.exe
2 Obi-wan: I PWNED Networks exam
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RMV 3331
The thread was created by another user and cannot be removed
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RMV 9331
The thread has been removed
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: LST
The list of active threads:
3331
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: SHT
Incorrect syntax for RDT
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: SHT monkey
Incorrect password
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: SHT destroyforum
Goodbye. Server shutting down >
Obi-wan issued RDT command Thread 3331 read
Obi-wan issued RMV command Thread 3331 cannot be removed
Obi-wan issued RMV command Thread 9331 removed
Obi-wan issued LST
command
Obi-wan issued SHT
Incorrect password
command
Obi-wan issued SHT
Server shutting down
>
command
Second Configuration
In this configuration, the server interacts concurrently with multiple clients. In the following, two clients with usernames Yoda and R2D2 connect and interact with the server concurrently. The inputs from the user are shown as underlined. It is strongly recommended to execute the sever and each individual client in a separate working directory. Ensure that write permissions are enabled on the credentials file.
Note that, extra space is added in the two client terminals to simulate some delay before the users enter commands when prompted to do so. This is simply done to improve readability of the output below. You should not make such assumptions in your implementation.
17
Client 1 Terminal
Client 2 Terminal
Server Terminal
>java Client 127.0.0.1 6000 Enter username: Yoda
Enter password: jedi*knight Welcome to the forum
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
LST
No threads to list
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
CRT 3331
Thread 3331 exists
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: CRT 9331
Thread 9331 created
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: MSG 3331 Networks Rocks!
Message posted to 3331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
>java Client 127.0.0.1 6000
Enter username: Yoda
Yoda has already logged in
Enter username: R2D2
Enter password: c3p0sucks
Welcome to the forum
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
CRT 3331
Thread 3331 created
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
MSG 3331 Yes it does
Message posted to 3331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT,
>java Server 6000 destroyforum
Waiting for clients Client connected Yoda successful login
Client connected
Yoda has already logged in
R2D2 successful login
Yoda issued LST command
R2D2 issued CRT command
Thread 3331 created
Yoda issued CRT command
Thread 3331 exists
Yoda issued CRT command
Thread 9331 created
Yoda issued MSG command
Message posted to 3331 thread
R2D2 issued MSG command
Message posted to 3331 thread
18
UPD 9331 test1.exe
test1.exe uploaded to 9331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
RDT 9331
Yoda uploaded test1.exe R2D2 uploaded test2.exe
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
EDT 3331 2 This assignment rocks
The message belongs to another user and cannot be edited
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: MSG 3331 This assignment rocks
Message posted to 3331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
LST, RDT, UPD, DWN, RMV, XIT, SHT: RDT 3331
1 Yoda: Networks Rocks!
2 R2D2: Yes it does
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
UPD 9331 test2.exe
test2.exe uploaded to 9331 thread
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
DWN 9331 test1.exe
test1.exe successfully downloaded
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
RDT 3331
1 Yoda: Networks
Rocks!
R2D2 issued RDT command
Thread 3331 read
Yoda issued UPD command
Yoda uploaded file test1.exe to 9331 thread
R2D2 issued UPD command
R2D2 uploaded file test2.exe to 9331 thread
Yoda issued RDT command
Thread 9331 read
R2D2 issued DWN command
test1.exe downloaded from Thread 9331
Yoda command
Message
edited
Yoda command
issued EDT cannot be
issued MSG
Message posted to 3331 thread
R2D2 issued RDT command
19
(extra space added before user’s response)
DLT 3331 2
The message belongs to another user and cannot be edited
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: DLT 3331 1
The message has been deleted
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
SHT destroyforum
Goodbye. Server shutting down
>
2 R2D2: Yes it does
3 Yoda: This
assignment rocks
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
(extra space added before user’s response)
RDT 3331
1 R2D2: Yes it does
2 Yoda: This
assignment rocks
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RMV 9331
Thread cannot be removed
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT: RMV 3331
Thread removed
Enter one of the following commands: CRT, MSG, DLT, EDT, LST, RDT, UPD, DWN, RMV, XIT, SHT:
Goodbye. Server shutting down
>
Thread 3331 read
Yoda command
Message
deleted
Yoda command
Message
deleted
R2D2 issued RMV command
Thread 9331 cannot be removed
R2D2 issued RMV command
Thread 3331 removed
Obi-wan issued SHT command
Server shutting down
>
issued DLT cannot be
issued DLT has been
issued RDT Thread 3331 read
R2D2 command
20