代做COMS3200 – Semester 1, 2025 Assignment 1调试Python程序

COMS3200 – Semester 1, 2025

Assignment 1 (Version 1.3)

Marks: 100

Weighting: 35%

Due: 3:00pm, Friday, 9th May, 2025

Introduction

This assignment is divided into Part A and Part B. Part A is a set of questions that examine your ability to use Wireshark. The question set can be found on the course Blackboard site. Part B contains programming tasks to demonstrate your understanding of socket programming, networking and multi-threaded programming. You have to create a server program and a client program so that multiple clients can chat in multiple channels under the management of the server program. In Part B of this assignment, you can use either C or Python as your coding language (you cannot use any other languages). Python 3.11 is the required version if you use Python for this assignment. This is the version available on moss.labs.eait.uq.edu.au.

Student Conduct

This is an individual assignment. You should feel free to discuss general aspects of C programming, Python programming and the assignment specification with fellow students, including on the discussion forum. In general, questions like “How should the program behave if ⟨this happens⟩?” would be safe, if they are seeking clarification on the specification.

You must not actively help (or seek help from) other students or other people with the actual design, structure and/or coding of your assignment solution. It is cheating to look at another person’s assignment code and it is cheating to allow your code to be seen or shared in printed or electronic form. by others. All submitted code will be subject to automated checks for plagiarism and collusion. If we detect plagiarism or collusion, formal misconduct actions will be initiated against you, and those you cheated with. That’s right, if you share your code with a friend, even inadvertently, then both of you are in trouble. Do not post your code to a public place such as the course discussion forum or a public code repository. (Code in private posts to the discussion forum is permitted.) You must assume that some students in the course may have very long extensions so do not post your code to any public repository until at least three months after the result release date for the course (or check with the course coordinator if you wish to post it sooner). Do not allow others to access your computer – you must keep your code secure. Never leave your work unattended.

You must follow the following code usage and referencing rules:

Uploading or otherwise providing the assignment specification or part of it to a third party including online tutorial and contract cheating websites is considered misconduct. The university is aware of many of these sites and many cooperate with us in misconduct investigations. You are permitted to post small extracts of this document to the course Ed Discussion forum for the purposes of seeking or providing clarification on this specification.

In short – Don’t risk it! If you’re having trouble, seek help early from a member of the teaching staff. Don’t be tempted to copy another student’s code or to use an online cheating service. Don’t help another COMS3200 student with their code no matter how desperate they may be and no matter how close your relationship. You should read and understand the statements on student misconduct in the course profile and on the school website: https://eecs.uq.edu.au/current-students/guidelines-and-policies-students/student-conduct.

Part A

This part of the assignment is a Wireshark quiz which is worth 20% of this assignment. Remember to submit your quiz before the due date. The quiz is under the Assessment section on the Blackboard site. There is no time limit to submit these answers, and only one submission is allowed. Please make sure to complete your submission. Incomplete submissions will not be marked, and the mark for that part will be zero.

Part B

This part of the assignment is about TCP socket programming, which is worth 80% of this assignment. TCP must be used for all socket connections and communication. You will write two programs: chatclient and chatserver. chatserver hosts a channel or channels that support multiple chatclient processes (in the same channel) to chat with each other. Both chatserver and chatclient can execute specific commands, some of the commands require communication between the chatserver and chatclient. You will need to determine the communication protocol used between the client and the server and what state information is kept in each.

Specification - chatclient

The chatclient program provides a command line interface to chat with other client or clients (in the same channel) through a server (chatserver). Your client will need to listen for incoming message(s) on both stdin and the network connection.

Command Line Arguments

Your chatclient program is to accept command line arguments as follows:

./chatclient port_number client_username (if using C) or

python3 chatclient.py port_number client_username (if using Python)

Italics indicate a placeholder for user-supplied arguments. Arguments must always be in the given order.

Some examples of how the program might be run include the following:

./chatclient 1234 Bob

./chatclient 3456 Alice

The meaning of the arguments is as follows:

• port_number – this mandatory argument specifies which localhost port the server is listening on. The range of port_number is between 1024 and 65535 (inclusive). The server may be listening on multiple ports – each port corresponds to a channel that will have a specific name.

• client_username – this mandatory argument specifies the name of this client. This username will be sent to the server and will be used to identify the client during the chat. Thus, the username must be unique within the channel.

Before doing anything else, your program must check the command line arguments for validity. If the program receives an invalid command line then it must print the (single line) message:

Usage: chatclient port_number client_username

to standard error (with a following newline), and exit with an exit status of 3. (This will be the message whether you implement the client with Python or C.)

Invalid command lines include (but may not be limited to) any of the following:

• No arguments are present (i.e., there is no port_number argument).

• An unexpected argument is present (i.e., too many arguments).

• Any argument is an empty string.

• The client_username argument contains spaces.

Checking whether the port_number is a valid port is not part of the usage checking (other than checking that the value is not empty). The validity of the port is checked after command line validity as described next.

Client Port Checking

If the port_number argument is not an integer or chatclient is unable to create a socket and connect to the server on the specified port of host localhost, it shall print the following message (terminated by a newline) to stderr and exit with exit status 7:

Error: Unable to connect to port N.

where N should be replaced by the port number argument given on the command line.

Client Username Checking

If chatclient wishes to connect to a channel but there already exists a client with the same client_username in that channel or the queue for that channel, chatclient will be notified by the server and chatclient will print the following message (terminated by a newline) to stdout and exit with exit status 2:

[Server Message] Channel "channel_name " already has user client_username.

where channel_name should be replaced by the name of the channel that chatclient wishes to join, and client_username should be replaced by the client username given on the command line. The double quotes must be present.

Client Runtime Behaviour

Assuming that the checks above are passed and your chatclient can successfully connect to the channel, then your chatclient must print and flush the following message (terminated by a newline) to stdout:

Welcome to chatclient, client_username.

where client_username should be replaced by the username argument given on the command line.

If the channel has capacity for the client, then the client should be notified by chatserver and print the following message to stdout (terminated by a newline):

[Server Message] You have joined the channel "channel_name ".

where channel_name is replaced by the name of the channel that the client has connected to. The double quotes must be present.

If the channel does not have capacity, then the client should be notified by chatserver and print the following message to stdout (terminated by a newline):

[Server Message] You are in the waiting queue and there are X user(s) ahead of you.

where X should be replaced by the number of users (clients) waiting in the queue ahead of this client.

The client must read lines of input from the user (via stdin) and respond to them as described below (e.g. usually by sending a message to the server), and will simultaneously read lines received from the server (via the connected socket) and respond to them as described below. Communication is asynchronous – either party can send a message at any time – so your client must be implemented to support this. You can do this by using two threads (one reading from stdin and one reading from the connected network socket).

Client – Handling Standard Input

If the client has connected to a channel, then the client can broadcast messages in this channel by entering messages in stdin. Messages are to be terminated by a single newline. These messages are to be sent to the server, and the server will send them to all other clients currently in the same channel. For example, if a client named Bob enters

Hello COMS3200 students!

into stdin, the below message (terminated by a newline) should be printed to the stdout of both the server and all clients (including the sender) within the channel (not the queue):

[Bob] Hello COMS3200 students!

The client can also enter the following commands on stdin. Commands should be started with / and terminated by a single newline. No leading or trailing spaces are to be accepted but multiple spaces may appear between arguments. If an invalid command is entered (other than those that result in an error message printed to the user as described below), then the server will treat it as a broadcast message.

If the command has an invalid number of arguments, then chatclient should print a usage message (ter-minated by a newline) to chatclient’s stdout to show the correct usage of this command. For example, if chatclient reads a line like this from stdin:

/send Bob

which is missing the file_path argument, then chatclient must print the following usage message (terminated by a newline) to its stdout:

[Server Message] Usage: /send target_client_username file_path

The content of this usage message depends on the command keyword. Valid commands (which define the messages to be printed) are listed below. In most cases, the use of a command will result in a message or messages being sent to the server. If the client is in a queue to join a channel then only the /quit, /list and /switch commands are valid. All other commands will be ignored.

• /send target_client_username file_path

This command indicates that the client wishes to send a file to another client within the same channel. file_path may include the path and basename of the file. If the target_client_username is the sender’s own username then the following message will be printed to the sender’s stdout (terminated by a newline):

[Server Message] Cannot send file to yourself.

If the target client is not within the same channel as the sending client, the file will not be sent, and the below message (terminated by a newline) will be printed to the sender’s stdout:

[Server Message] target_client_username is not in the channel.

where target_client_username should be replaced by the target client username given in the /send command.

If the file does not exist or can not be opened for reading, then only this message (terminated by a newline) is printed to the sender’s stdout:

[Server Message] "file_path " does not exist.

where file_path should be replaced by the path of the file to send given in the /send command. The double quotes must be present.

If both the file does not exist and the target client is not within the channel, then both error messages should be displayed. The check of the target_client_username ’s existence shall be the first.

If the file was sent successfully, it should be saved in the current working directory of the target’s client. The following message (terminated by a newline) will then be printed to the sender’s stdout:

[Server Message] Sent "file_path " to target_client_username.

where file_path should be replaced by the path of the file you wish to send given in the /send command, and target_client_username should be replaced by the target client username given in the /send command. The double quotes must be present.

If the file was sent successfully (i.e. the receiving client successfully saved the file), the following message (terminated by a newline) will be printed to chatserver ’s stdout and the receiving client’s stdout (terminated by a newline):

[Server Message] sender_client_username sent "file_path " to target_client_username.

where sender_client_username should be replaced by the sender client’s username given in the /send command, file_path should be replaced by the basename of the file sent, and target_client_username should be replaced by the target client username given in the /send command. The double quotes must be present.

File sizes up to 232 − 1 = 4294967295 bytes are to be supported. File names may not contain spaces. Existing files are to be overwritten.

If the receiving client was unable to successfully save the file, then the following message (terminated by a newline) will be printed to the sender’s stdout:

[Server Message] Failed to send "file_path " to target_client_username

where file_path should be replaced by the path of the file the sender wished to send as given in the /send command, and target_client_username should be replaced by the sender client’s username.

• /quit

This command indicates that the client exits the channel and closes the connection to the server. The below message is printed (terminated by a newline) to the stdout of both the chatserver and all remaining users in the channel:

[Server Message] client_username has left the channel.

where client_username should be replaced by the username of the client quitting.

The client can use this command when in a waiting queue or a channel. If a client in the queue uses this command, then only the server should print the above message. The client who wishes to quit should not print any message and exit with exit status 0.

EOF on the client’s stdin, should be treated the same as if the /quit command was entered. Termination by signal will be treated similarly (other than the client exit status – there is no need for the client to catch SIGINT, SIGQUIT, etc.).

• /list

This command indicates that the client wishes to receive a list of all channels that the chatserver is hosting. This list will be in the order of server’s config_file and it will be printed to the client’s stdout. Each channel is listed in a separate line according to the following format:

[Channel] channel_name channel_port Capacity: current /channel_capacity, Queue:

in_queue

where channel_name should be replaced by the name of the channel, channel_port should be replaced by the port where the channel listens on, current should be replaced by the current number of clients in this channel, channel_capacity should be replaced by the maximum number of clients this channel could host, and in_queue should be replaced by the current number of clients waiting in the queue of this channel.

• /whisper receiver_client_username chat_message

This command sends a chat message to a specific client in the channel. If the receiver is not in the channel, the whisperer (the client who sends out the message) will print this message (terminated by a newline) to its stdout:

[Server Message] client_username is not in the channel.

where client_username should be replaced by the name of the receiving client.

The receiver client will print this command (terminated by a newline) to its stdout:

[sender_client_username whispers to you] chat_message

where sender_client_username should be replaced by the sender’s client username, and chat_message should be replaced by the content of the message (all characters after the space(s) that follow the client_- username in the /whisper command line).

When one client successfully whispers to another client, a message (terminated by a newline) will be printed to the chatserver’s and sender client’s stdout:

[sender_client_username whispers to receiver_client_username ] chat_message where receiver_client_username should be replaced by the receiver’s client username, and sender_- client_username and chat_message are replaced as above.

It is permissible for a client to /whisper to itself.

• /switch channel_name

This command indicates that the client wishes to switch to a channel based on the given channel name. If there does not exist a channel matching the given channel_name , the client that initiates the switch move will stay in the current channel and print the following message (terminated by a newline) to its stdout:

[Server Message] Channel "channel_name " does not exist.

where channel_name should be replaced by the channel name provided in the /switch command line.

The double quotes must be present.

If a client in the target channel has the same username as the client initiating the switch, the client that initiates the switch will stay in the current channel and the below message (terminated by a newline) will be printed to its stdout:

[Server Message] Channel "channel_name " already has user client_username.

where channel_name should be replaced by the channel name provided in the /switch command line and client_username should be replaced by the username of the client that initiates the switch command.

The double quotes must be present.

If the specified channel exists and no user in that channel has the same name, then the client who initiated the switch operation will first leave the original channel (i.e. disconnect from the server). If the client wasn’t in the queue, then the remaining client(s) in the original channel (excluding those in the queue) will be notified and print the following message (terminated by a newline) to stdout:

[Server Message] client_username has left the channel.

The server will also print this message to its stdout – including if the departing client was in a queue. Then the client will attempt to join the specified channel. The new channel and all client(s) in the new channel will treat this client as a new client trying to join the channel and print messages accordingly.

If the target channel is at maximum capacity, then the client will be placed into the queue of the target channel. In this case, the client will follow the expected behaviour when dealing with the queue of a channel.

Client – Handling Messages from Server

The client may receive messages from the server at any time – see the description of the server behaviour below. The client must print the messages specified as part of the server behaviour below. It is up to you whether the text of these messages form. part of the communication protocol between the server and the client or whether the client constructs the messages from information received from the server. All messages must be flushed to stdout upon receipt.

Other Client Requirements

• If your client detects that the connection to the server has been closed then it should print the following message (terminated by a newline) to stderr:

Error: server connection closed.

and exit with status 8. This relates to unexpected disconnections (e.g. server crashes).

• There is no requirement that chatclient free all memory before exiting.

• Your client must not exit abnormally due to SIGPIPE. A SIGPIPE when writing to the server will be treated as the connection to the server being closed – see line 249.

• For any aspects of behaviour not described in this specification, your program must behave in the same manner as demo-chatclient on moss. If you’re unsure about some aspect, then you can run the demo program to check the expected behaviour.