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