程序代写 COMP3331/9331 Computer Networks and Applications

Microsoft Word – Assignment.docx

COMP3331/9331 Computer Networks and Applications

Copyright By PowCoder代写 加微信 powcoder

Assignment for Term 3, 2022

Release Date: XXX

Due: 11:59 am (noon) Friday, 11 November 2022

Designing and Implementing an IoT Data Collection and Sharing Network

1. Change Log & Author

Version 1.0 is released on 30/09/2022,

2. Goal and learning objectives

The Internet of Things, or IoT, refers to the billions of physical devices around the world that are now

connected to the Internet, all collecting and sharing data for improving people’s quality of life. For

example, the smartwatches which are very popular nowadays, can collect data from the wearer and

share data with its central sever for monitoring the health of the wearer. In this assignment, you will

have the opportunity to implement your own version of a data collection and sharing network based

on the idea of IoT. Your application is based on the client-server architecture consisting of one server

and multiple clients (i.e., the edge IoT devices) communicating concurrently as well as peer-to-peer

networks. Your application will support a range of functions that are typically found from the existing

edge networks including authentication (between edge devices and the central server), data generation

at the side of edge devices, and data sharing between edge devices and the central server, and between

one edge device and another edge device. You will be designing custom communication protocols

for the edge network based on TCP and UDP.

2.1 Learning Objectives

On completing this assignment, you will gain expertise in the following skills:

1. Detailed understanding of how client-server and client-client (peer-to-peer) interactions work.

2. Expertise in socket programming.

3. Insights into designing and implementing a communication protocol.

• This is an individual assignment (group submission not allowed).

• Updates to the assignment, including any corrections and clarifications, will be announced
on the course WebCMS.

• Late submissions will attract a penaly of 5% per day late beyond the deadline (12 noon to 12
noon will be counted as one day). No submissions will be accepted after 5 days beyond the
deadline (no submissions after 12 noon 16 November).

3. Assignment Specification

The assignment is worth 20 marks. The specification is structured in two parts. The first part, which is

covered in Sections 3.2 – 3.3, involves the basic interactions between the edge device (i.e., the client)

and the central server and includes functionality for edge devices to communicate with the central

server via TCP. The second part, covered in Section 3.4, asks you to implement additional functionality

whereby two edge devices can exchange video files with one another directly in a peer-to-peer fashion

CSE students are expected to implement both functionalities. Non-CSE students are only required to

implement the first part (i.e., no peer-to-peer data exchange between two edge devices over UDP). The

marking guidelines are thus different for the two groups and are indicated in Section 7.

The assignment includes 2 major modules, the server program and the client program. The server

program will be run first followed by multiple instances of the client program (each instance supports

one client). They will be run from the terminals on the same and/or different hosts.

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 criterion and wishes to avail of this option MUST email

to seek approval before 5 pm, 7 October (Friday, Week 4). 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.1. Assignment Specification

In this programming assignment, you will implement the client (Note that we will use client and edge

device interchangeably) and server programs of an edge network, similar in many ways to the existing

edge networks. Your application will support a range of operations including authenticating an edge

device and let the edge device join the network, generating data at the edge devices, uploading the data

from edge devices to the central server, interacting with the central sever for acquiring computation

services, deleting the data from the central server, reading active edge devices’ information, and

exchanging data files from one edge device to another edge device (CSE Students only). You will design

and implement a communication protocol for the edge network to achieve these functions. The server

will listen on a port specified as a 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

client will initiate the authentication process. The client program will interact with users through the

command-line interface. Following successful authentication, the client will initiate one of the

available commands. All commands require a simple request-response interaction between the client

and server or two clients (CSE Students only). The client 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.

3.2 Authentication

When a client requests a connection to the server, e.g., for joining an edge network, the server should

prompt the client to input the edge device name and password and authenticate the edge device. The

valid edge device name and password combinations will be stored in a file called credentials.txt which

will be in the same directory as the server program. An example credentials.txt file is provided on the

assignment page. Edge device names and passwords are case-sensitive, and you can assume that

the edge device name is unique for the context of this assignment. We may use a different file for

testing so DO NOT hardcode this information in your program. You may assume that each edge

device name and password will be on a separate line and that there will be one white space between

the two. Device names and passwords will not contain any white space. If the credentials are correct,

the edge device is considered to be successfully authenticated and joined the edge network and a

welcome message is displayed.

On entering invalid credentials, the client is prompted to retry. After several consecutive failed

attempts, this edge device is blocked for 10 seconds (the number is an integer command-line argument

supplied to the server and the valid value of the number should be between 1 and 5) and cannot join the

network during this 10-second duration (even from another IP address). If an invalid number value

(e.g., a floating-point value, 0 or 6) is supplied to the server, the server prints out a message such as

“Invalid number of allowed failed consecutive attempts: number. The valid value of argument number

is an integer between 1 and 5”.

For non-CSE Students: After an edge device has joined the network successfully, i.e, the server

authenticates the edge device successfully, the server should record a timestamp of the edge device

joining and the device name in the active edge device log file (edge-device-log.txt, you should make

sure that write permissions are enabled for edge-device-log.txt). Active edge devices are numbered

starting at 1:

Active edge device sequence number; timestamp; edge device name

1; 30 September 2022 10:31:13; supersmartwatch

For CSE Students: After an edge device has joined the network successfully, the edge device (i.e.,

the client) should next send the server the UDP port number on which it will listen for P2P connections.

The server should record a timestamp of the edge device joining, the edge device name, its IP address,

and its UDP port number, in the active edge device log file (edge-device-log.txt):

Active edge device sequence number; timestamp; edge device name; edge

device IP address; edge device UDP server port number

1; 30 September 2022 10:31:13; supersmartwatch; 129.64.31.13; 5432

For simplicity, an edge device will join the network once at any given time, e.g., multiple joins

concurrently are not allowed, and we won’t test this case.

3.3. Commands

After the edge device has successfully joined the edge network, the client needs to display a message

informing all available commands and prompting it to select one command. In the context of this

assignment, the following commands are available: EDG: Edge Data Generation which means the

client side helps to generate data to simulate the data collection function in the real edge device, UED:

Upload Edge Data, it allows the edge device to upload a particular edge data file to the central server,

SCS: Server Computation Service, the edge device can practice this command to request the server to

do some basic computations on a particular data file, DTE: Delete the data file (server side), AED:

Active Edge Devices, request and display the active edge devices, OUT: exit this edge network, and

UVF: Peer-to-peer Uploading Video Files (for CSE Students only). All available commands should

be displayed in the first instance after the edge device has joined the network. Subsequent prompts for

actions should include this same message. If an invalid command is selected, an appropriate error

message should be displayed, and they should be prompted to select one of the available commands.

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 (EDG,

UED, 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 and timestamps that have a fixed format of dd mm

yyyy hh:mm:ss such as 30 September 2022 10:31:13). You may assume that the

communication data files only contain numbers (i.e., integers).

There are 6 commands for Non-CSE Students and 7 commands for CSE Students respectively, which

users can execute. The execution of each command is described below.

EDG: Edge Data Generation

EDG fileID dataAmount

The fileID and dataAmount should be included as arguments, the fileID is an integer which is used

to uniquely identify the file which will be utilised to store the generated data, the name of the file

should be edge device name-fileID and the file type should be txt (e.g., supersmartwatch-1.txt). The

dataAmount argument is used to indicate the number the data samples to be generated. You can

randomly generate the data samples, there is no strict requirements for the data generation, for

example, if dataAmount is specified as 10, then you can generate any 10 integers (e.g., from 1 to 10,

from 20 to 30, or any other 10 integers) and store them into the data file. In addition, when you store

the data samples into the file, you should follow the rule of “one line one number”, an example

(supersmartwatch-1.txt) is provided. Note that, if the file already exists in the subsequent EDG

command calls, you should directly overwrite the existing data samples with the new generated data

samples. If the fileID or dataAmount argument are missing from the EDG command, you should

prompt a proper error message, for example, “EDG command requires fileID and dataAmount as

arguments.”, and if the provided fileID and dataAmount parameters are not integers, you should

prompt a proper error message, for example, “the fileID or dataAmount are not integers, you need to

specify the parameter as integers”.

After the edge device successfully generates the data samples and stores them into the file, you should

prompt a proper message (e.g., “data generation done”) to indicate this command has been

successfully processed by the edge device.

UED: Upload Edge Data

UED fileID

The fileID of the particular file the edge device is going to upload is included as the argument. Upon
receiving this command the edge device (i.e., the client) is expected to read the data samples from the

corresponding file and transfer the data samples to the central server using TCP. The client needs to
check if the fileID argument is provided or not, you should prompt a message for example “fileID is

needed to upload the data” if the fileID is missed. The client also needs to check if the corresponding

file exists or not, you should prompt a message e.g., “the file to be uploaded does not exist” if the file
does not exist at the edge device side. After the central server successfully receives the file, the server

should send a message to the edge device to inform that the server has successfully received the file,
and the client also should prompt a proper message to indicate that the file uploading is done

successfully. In addition, the central sever should maintain an uploading log file named as upload-
log.txt. If everything is good, the server should append an uploading log message in the following

edgeDeviceName; timestamp; fileID; dataAmount

supersmartwatch; 30 September 2022 10:31:13; 1; 10

SCS: Server Computation Service

SCS fileID computationOperation

This command is designed to request the powerful central server to do various computations, because

in reality the edge devices normally have very limited computation resources. The fileID and

computationOperation are included as two arguments. The fileID is used to indicate the

corresponding data file used for the computation purpose. If the fileID is not provided or the fileID

is not an integer the client should prompt a proper error message e.g., “fileID is missing or fileID

should be an integer”. The server also needs to check if the corresponding file exists or not, if the file

does not exist the server should respond to the client with a message informing the client that the file

does not exist, and the client should prompt a proper message indicating the file does not exist at the

server side. For simplicity, we define a total of four computation operations for this assignment: SUM,

AVERAGE, MAX, MIN. SUM – calculate the sum of the data samples in the corresponding file,

AVERAGE – get the average of the data samples in the corresponding file, MAX – get the maximum

value among the data samples, and MIN – get the minimum value among the data samples. If the

provided computation operation argument is not one of these four, the client should display a proper

error message. If everything is good, the server should send the computation result to the edge device

(i.e., the client) and it should display the result properly at the terminal.

DTE: Delete the data file

DTE fileID

The fileID of the particular file the edge device is going to delete at the central server side is included

as the argument, upon receiving this command the edge device (i.e., the client) is expected to send a
message to the central server to request the server to delete the corresponding file with that fileID

provided in the argument. The server needs to first check if the file exists or not, if the file does not
exist the server should make a response to inform the client the file to be deleted does not exist and

the client should display a proper error message at the terminal, for example, “the file does not exist
at the server side”. If everything is good, the server should remove the file from its folder completely.

In addition, the central sever should maintain a log file named as deletion-log.txt. If everything is
good, the server should append a delete operation log message in the following format:

edgeDeviceName; timestamp; fileID; dataAmount

supersmartwatch; 30 September 2022 10:33:13; 1; 10

After that, the central server should respond to the client with a message to inform the client the file

has been successfully deleted and the client should display a successful message (e.g., “file with ID of

fileID has been successfully removed from the central server”).

AED: Active Edge Devices

There should be no arguments for this command. The central server should check if there are any

other active edge devices apart from the edge device that sends the AED command. If so, the server

should send the edge device names, and timestamps since the edge devices joined, (and their IP

addresses and Port Numbers, CSE Students only) from the active edge device log file to the client

(the server should exclude the information of the client, who sends the AED command to the server).

The client should display all the information of all received edge devices at the terminal. If there are

no other active edge devices, a notification message of “no other active edge devices” should be sent

to the client and displayed. The client should next prompt to select one of the available commands.

OUT: Exit edge network

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. The server should update its state information

about currently active edge devices and the active edge device log file. Namely, based on the message

(with the edge device name information) from the client, the server should delete this edge device,

which entails deleting the line containing this edge device in the active edge device log file (all

subsequent active edge devices in the file should be moved up by one line and their active edge device

sequence numbers should be updated appropriately) and confirmation should be sent to the client and

displayed at the terminal. Note that all the data files and messages uploaded by this edge device must

NOT be deleted. For simplicity, we won’t test the cases where an edge device forgets to exit or exit

is unsuccessful.

3.4 Peer to Peer Communication (Video file upload, CSE Students only)

The P2P part of the assignment enables one edge device to upload video files to another edge device

using UDP (A good example for this scenario would be the video camera uploading its video files to

the smartphone). Each edge device is in one of two states, Presenter or Audience. The Presenter edge

device sends video files to the Audience edge device. Here, the presenter edge device is the UDP

client, while the Audience edge device is the UDP server. After receiving the video files, the Audience

edge device saves the files and the device name of the Presenter. Note that an edge device can behave

in either Presenter or Audience state.

To implement this functionality your client program should support the following command, and two

example video files are provided to help implement and test this command.

UVF: Upload Video File

UVF deviceName filenam

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com