COMS3200 代做、代写 Python/C++语言程序

日期：2024-09-01 07:38

COMS3200 Assignment 1 2023S1

100 total marks, 25% overall course mark

Due: 15:00 19 April 2023

1 Preface

1.1 Notes

This document is subject to change for the purposes of clarification. Changes made since the

original release will be highlighted in red.

Please post any questions on the course Ed stem page.

It is strongly recommended that all programming tasks are done in Python 3.6.8 or C.

1.2 Revision History

20 March, 2023: Version 1.0 Released.

24March, 2023: Version 1.1 Clarifications to startup behaviour, malformed commands and python

version.

29 March, 2023: Version 1.2 Clarifications to commands and queue behaviour.

31 March, 2023: Version 1.3 Clarifications to commands

2 Part A: Problem Solving Questions

This section is worth 25% of the assignment.

The scope of this section is chapters 1-3.

Show full working for all questions. Marks may be withheld if working is not provided.

The question set is located on Blackboard under Assessment =? Assignment 1 =? Part A: Problem

solving questions.

There is no time limit to submit these answers and multiple resubmissions are permitted. Only the

last submitted attempt will be marked.

3 Part B: Wireshark Questions

This section is worth 20% of the assignment.

This section covers ICMP, HTTP, DNS and DHCP.

The question set is located on Blackboard under Assessment =? Assignment 1 =? Part B:Wireshark

questions and the capture file is located under Assessment =? Assignment 1 =? Part B: Packet

capture File.

There is no time limit to submit these answers and multiple resubmissions are permitted. Only the

last submitted attempt will be marked.

4 Part C: Socket Programming

This section is worth 55% of the assignment.

4.1 Goals

You will implement a multi-channel chat application using socket programming in Python 3 or C.

You will create two programs; a chat client and a chat server.

4.2 Programs

You must use socket and multithreading libraries. The use of any other third-party libraries is not

allowed. You must implement all chat logic yourself.

If you choose to use Python then you must name your programs chatclient.py and chatserver.py.

If you choose to use C then you must name your programs chatclient and chatserver.

4.3 Report

You must also submit a plaintext README file named readme.txt. This file must contain:

A brief and high-level abstract detailing your overall approach.

A list of functions you implemented with their respective descriptions.

An overview to how you tested your code.

IEEE references to any code you used and was not written by you. This includes generative AI.

4.4 Requirements

4.4.1 High-level Requirements

You must implement a server program which can support concurrent communication between multiple

clients across multiple channels.

The server must be able to maintain at least three distinct chat channels simultaneously, each of which

may contain at least five simultaneous connections. The exact operation of the server’s channels will

be specified in an external config file.

As clients connect to a channel within the server, they are to be placed in a waiting queue until there

is room available for them to join the channel.

Once in a channel, clients are able to send messages to other clients within that same channel.

Clients are able to specify the username which will be used to identify them within the channel. Your

client and server programs must rely on socket and multithreading libraries in either Python or C.

If you wish to use another programming language, you must get written permission from the course

coordinator.

You may use any transport layer protocol but it is highly recommended you use TCP.

2

4.4.2 Functional Requirements

The server must be able to be started by one of the two below commands:

$ ./ chatserver configfile

$ python3 chatserver.py configfile

where configfile is the path to the server configuration file. The client must be able to be started by

one of the two below commands:

$ ./ chatclient port username

$ python3 chatclient.py port username

where port is the port of the desired channel and username is the name which should be used to identify

the client in the chat channel.

All lines in the server configuration file must follow the below format:

channel

where is the name of the channel, is the port that channel should use

and is the maximum number of users who can be active at once within a channel.

The below requirements must be met:

Each channel must operate on independent sockets.

No two channels can have the same name or port.

No channel should use the ephemeral port.

Channel names cannot begin with a number.

There must be at least three channels in the config file.

Each channel’s capacity must be at least five.

If the configuration file is missing, invalid or not specified, then the server process should exit im-

mediately with status code 1. Similarly, if the client cannot connect to the server due to malformed

arguments or an invalid port number, then the client process should also exit immediately with status

code 1.

Once the server is running, it will accept incoming client connections. Before clients are permitted to

enter their requested channel, they will be entered into a first-in-first-out waiting queue specific to that

channel. Once there is a free position in the channel, the longest-waiting client may be removed from

the waiting queue and entered into the channel.

Upon entering the waiting queue, the below should be displayed on the client’s stdout:

[Server message ()] Welcome to the channel , .

Where is the server’s current time in 24 hour time and in hh:mm:ss format, is

the name of the channel the client is waiting to join and is the name of the client.

3

When the client joins the waiting queue, and whenever a client leaves the queue, the below should be

displayed on the client’s stdout:

[Server message ()] You are in the waiting queue and there are user(s) ahead of

you.

where is the number of users in the waiting queue who joined before this client.

When the client is finally able to join the channel, or if the queue is empty and there is already available

space in the channel, the above message is not displayed. Instead, the below message is displayed to

the stdout of every client in the channel:

[Server message ()] has joined the channel.

and the below is displayed to the server’s stdout:

[Server message ()] has joined the channel.

Clients are able to send messages by typing in stdin. These messages are then sent to all other clients

currently in the same channel. For example, if the client named Dan types Hello COMS3200 students!

into his stdin, the below message should be displayed to the stdout of both the server and all clients

within the channel:

[Dan ()] Hello COMS3200 students!

4.4.3 Clientside Commands

Besides just broadcasting messages to each other, clients are also able to enter special commands into

stdin:

? /whisper

Only the client named receives the message. It will be displayed as:

[ whispers to you: ()]

Where is the username of the client which typed the whisper command. If

is not in the channel, the whisperer will receive this message to stdout:

[Server message ()] is not here.

Regardless of whether or not the target client is present in the channel, the below message will

be displayed to the server’s stdout:

[Dan whispers to : ()]

? /quit

The client who uses this command exits the channel and closes their connection to the server. The

below message is displayed to the stdout of both the server and all remaining users:

[Server message ()] has left the channel.

This command should be usable while the client is still within a waiting queue as well as within a

channel. If a client in the queue uses this command then only the server should receive the above

message.

/list

The list of all channels is displayed to the client’s stdout in the order in which they are listed

in the server configuration file. Each channel is listed on a separate line according to the below

format:

[Channel] //.

where is the name of the channel, is the current number of clients

currently in the channel, is the total capacity of the channel and is

the number of clients currently in the queue.

4

/switch

The client leaves their current channel or waiting queue and joins the waiting queue for the spec-

ified channel. If the specified channel exists, then the below message is displayed to the stdout of

both the server and every client remaining in the channel:

[Server message ()] has left the channel.

The client who issued the switch command should receive the waiting queue messages (pg 3) for

that channel. If the channel does not exist then the client will stay in the channel and the below

message will be displayed to their stdout:

[Server message ()] does not exist.

No two clients with the same username should be in the same channel at the same time. If a

client attempts to switch into a channel where there is already a client with the same username

(or in its respective waiting queue), the below should be displayed to that client’s stdout:

[Server message ()] Cannot switch to the channel.

The client should not leave the channel and no messages will be sent to any other clients or the

server. This command should be usable within both channels and waiting queues.

? /send

The file on the sender’s machine located at will be sent to the client named .

The below message will be displayed to the sender’s stdout:

[Server message ()] You sent to .

and the below message will be displayed to the server’s stdout:

[Server message ()] sent to .

If the target client is not within the same channel as the sending client, then neither of the above

two messages are displayed and the file will not be sent. Instead, the below message will be

displayed to the sender’s stdout only:

[Server message ()] is not here.

If the file specified by does not exist, then only the below is displayed to the sender’s

stdout:

[Server message ()] does not exist.

If the file can be sent, it should be saved to the same directory as the target’s chatclient exe-

cutable.

If both the file does not exist and the target client is not within the same channel as the sender,

then both error messages should be displayed. The invalid client message should be displayed

first.

N.B. For testing purposes, we will always be starting the server process from its directory.

Anything starting with /which is not one of these commands should be treated as a chat message.

5

4.4.4 Serverside Commands

The server is also able to use these below commands by typing them into stdin:

/kick :

If there is a client named , in the channel named , they will be removed

and their connection to the server will be closed. The below message is displayed to the stdout all

remaining users within that channel:

[Server message ()] has left the channel.

and the below message is displayed to the stdout of the server:

[Server message ()] Kicked .

If there is no such client in the specified channel then nothing is displayed to the clients’ stdout

and the below is displayed on the server’s stdout:

[Server message ()] is not in .

If the specified channel does not exist then nothing is displayed to the clients’ stdout and the

below should be displayed to the server’s stdout:

[Server message ()] does not exist.

/mute :

Prevents the client named in the channel named from sending any

messages for seconds.

If this client exists then the below will be displayed to the server’s stdout:

[Server message ()] Muted for seconds.

The below is displayed to the muted client’s stdout:

[Server message ()] You have been muted for seconds.

and the below is displayed to every other client’s stdout:

[Server message ()] has been muted for seconds.

If a client tries to send messages or use /whisper while muted, the below will be displayed to their

stdout:

[Server message ()] You are still muted for seconds.

Where is the number of seconds remaining before the client is unmuted. The message they

attempted to send will not be sent to any other users.

If the target client is not in the specified channel or the channel does not exist, the below will be

displayed to the server’s stdout:

[Server message ()] is not here.

must be a positive integer. If anything other than a positive integer is specified, then the

below message should be displayed to the server’s stdout:

[Server message ()] Invalid mute time.

All commands except /whisper should still be usable while muted.

6

/empty

Every client in the channel named will have their connection closed. The below

will be displayed to the server’s stdout:

[Server message ()] has been emptied.

If the specified channel does not exist, then the below will be displayed to the server’s stdout

instead:

[Server message ()] does not exist.

No clients in the emptied channel should receive any messages.

/shutdown

The entire server will shut down. Connections to every client in every channel and waiting queue

will be closed and the server process will exit. No clients should receive any messages.

Anything entered into the server’s stdin which is not one of these commands should be ignored.

4.4.5 Miscellaneous Requirements

If you choose to use C, then you must also submit a makefile. Both your client and server program

must be able to be compiled with the $ make command.

If your code does not compile, you might not receive any marks.

Both client and server processes should be runnable on Moss.

The use of fork() and select() in C and Python are expressly forbidden - This includes the

Python’s select library functions such as devpoll, epoll, kqueue, poll, kevent and select.

Only one server process should run at any time.

When a client’s connection with the server ends, the client process should exit.

No two clients with the same name should be within the same channel at the same time. If client

attempts to join a channel already containing another client of the same name when first starting

from the command line, the below message should be displayed to the client’s stdout:

[Server message ()] Cannot connect to the channel.

and the client process should immediately exit.

If a client in a channel does not send any message or use any command for 100 seconds, then it

should be removed from the channel and their connection should be closed. The below message

should be displayed to the stdout of both the server and all remaining clients in the channel:

[Server message ()] went AFK.

If a client is muted by the server, the timeout counter should freeze until the client becomes

unmuted. If a client attempts to chat or issues a command while muted, their timeout counter

should not reset.

Everything taken from stdin should have whitespace stripped from both sides before being eval-

uated as a chat message or a command.

Commands may have multiple spaces between arguments.

7

4.5 Marking Breakdown

Marks will be awarded according to the following breakdown:

Client and server processes start correctly or exit on invalid startup parameters - 1 mark

Chat messages and announcements can be sent/received in at least one channel - 4 marks

Chat messages and announcements can be sent/received in at least three channels. Chat mes-

sages and announcements sent to one channel do not appear in other any other channels - 5 marks

Clients are held in the waiting queue until space in the correct channel is available - 5 marks

Clients are correctly removed from chat after timing out - 5 marks

/whisper and /quit work - 5 marks

/kick and /empty work - 5 marks

/shutdown works - 5 marks

/list and /switch work - 5 marks

/mute works - 5 marks

/send works - 10 marks

Total: 55 marks.

N.B.: Although the README itself is not assigned marks, it is still mandatory for integrity purposes.

Failure to include the README file will result in a ≥50% penalty.

5 Miscellaneous Notes

"Clients within a channel" refer only to those in the channel and not those in the related waiting

queue.

Your code will not be tested for memory leaks but having large memory leaks may render your

code untestable. If you make any critical programming mistakes which impact our ability to test

your code, your marks may be severely limited.

For marking purposes, you should ignore commands which have too many or too few arguments.

6 Integrity

All code submissions will be checked for similarity and plagiarism. All code in your submission which

was not written by you (or was written by you for a previous assignment) must be correctly referenced in

IEEE format in both in your code and your README file. This includes code written by generative AI.

7 Submission

You must submit all source code files and your README file together in a zip file. This zip file must

be named A1_sxxxxxxx.zip, where the sxxxxxxx is your student ID. This zip file must be submitted to

the course Blackboard page under Assessment =? Assignment 1 =? Part C: Code Submission.