In this assignment, we will develop a simple proxy for IoT devices that will allow them to communicate with each other within the LAN and other devices at WAN.
The code that you develop in this part will serve as a basis for the following programming assignments. You must create a pair of programs (client and server). The server (a PC) will act as a central repository where clients (a Raspberry PI) will post and access messages. All communications happen through the server. Clients establish a TCP session with the server when they become online and open a UDP port to be able to communicate with other devices. Clients also notify the server when they terminate.
The server code should be started with a parameter of
port-number. Similarly, client code should be started with parameters of
server-port (all separated with spaces).
For this part of the assignment you need to implement multi threaded communication with devices and the server. Each client will register with the server and be able to communicate with each other simultaneously. Server will also be able to serve multiple clients simultaneously. You will need to use synchronization among threads and rely on mutexes to work with shared resources.
As measurement, we will run ping and traceroute from each client to a website and exchange the results with other clients. That is, once ping/traceroute is completed, it will be sent to other peers using UDP and all devices will record all data in a file.
Following are the application level messages sent from/to the server using TCP sockets:
REGISTER device-ID MAC IP port
This command is used to register a device with device-ID and MAC address in the server. The IP address and port number are for the UDP communication with other devices. The server will build a database/table of all registered devices and allow devices to search for others using device-ID or MAC. If the client does not get a
ACK reply to a
REGISTER message after 10 sec than it should retry two more times and if all fail assume the server is unavailable and record the event in
ACK code parameter(s)
This command acknowledges a successfully request.
code indicates what is being acknowledged and parameters include any useful information. For instance, after a
REGISTER request, if there is no conflict, a reply of
ACK 1 device-ID is sent to indicate successful registration. If the user is already registered, a reply of
ACK 1 device-ID count time is sent to indicate previous registration for this device-ID along with a count of any messages waiting for the device.
NACK code parameter(s)
This command notifies the other party that the previous request did not succeed.
code indicates what is being notified and parameters include any useful information. For instance, after a
REGISTER request, if there is a conflict, a reply of
NACK 1 device-ID MAC is sent to indicate the MAC address is registered with another device-ID or device-ID is registered by another MAC address. Similarly, a reply of
NACK 2 MAC to indicate the actual MAC of received packet does not match the indicated MAC address in
REGISTER message. If any received message is malformed a message of
NACK 0 is sent.
DEREGISTER device-ID MAC
This command is used to remove a registration from the proxy server. If successful, server should reply with a
ACK 3 device-ID to indicate device is successfully removed from the list or
ACK 3 device-ID to indicate the MAC or device-ID was not registered anyway. Otherwise, it should notify the client with a
NACK 3 MAC device-ID message to indicate it was registered to another
MSG from-ID to-ID message [time]
This packet carries a message from
to-ID. Server keeps a copy of all such messages in a mailbox until they are successfully delivered to the recipient. The same message format is used to deliver a message in mailbox to the recipient device along with the
time of original receipt. After successful delivery of the message, the server keeps a log of delivery time in
Activity.log file. The server acknowledges reception of a
ACK 5 device-ID time reply. If the
to-ID does not exist in the system, it will send a
NACK 5 device-ID.
QUERY code parameter(s)
This command queries the server for another device or waiting messages. When
code=1 , the query is for a device-ID to lookup up device's IP address and port number to establish UDP connection. When
code=2 , the query is for checking the mailbox.
This command indicates the device-ID is leaving the system (sent from device to server). The server should assure the source-IP of the packet matches the device-ID before logging off the device.
Following are the application level messages sent between IoT devices using UDP sockets:
DATA source-ID trace/ping results
This command sends data to other device where
source-ID indicates the device-ID of sender,
trace indicates this is a traceroute data, and
ping indicates it is ping data. If an
ACK is not received in 30 seconds, it is recorded in
Error.log and retried for up to 3 times.
This command acknowledges the receipt of data.
Report all major actions as the program communicates with other server/users in a file named
We assume device-IDs to be at most 32 characters without any white space characters.
When a malformed message is received report it in a log file named
You may utilize localhost (127.0.0.1 or actual IP address) to test your program by running multiple users on the same machine but within different folders (with different port numbers).
If testing on multiple machines, be sure that the machines are not behind a NAT (or within the same subnet).
You might get TCP messages in multiple segments even one byte at a time. Hence, you must check whether you have read all the message when parsing them (TCP streams).
You must submit all the source code in Python with sufficient comments to help understand the code.
You must include in your submission a file named
Readme.txt that includes your name and a brief description of your submission, including the name of each file submitted along with a one line description of what is in the file.
If your code is not complete, tell us what works and what doesn't in
Readme.txt file. If you are submitting code that does not compile, please tell us that as well. If you borrow code from someone else, you are required to tell us about it (this must also be documented in the code itself).
Finally, feel free to include a description of any problems you had or anything else you think might be helpful to us.
You should work individually.
Your project will be tested to make sure it works properly.
Your grade will depend on the functionality and the code quality. Hence, please pay careful attention to clean, modular and extensible design as you implement the project.
There will be bonus grades for extra functionality (such as a well designed GUI) not required by the project (optional and at the discretion of the instructor).
There will be bonus for students that point to major issues or add to program structure.
This document will evolve as we discuss the project and determine communication protocols and messaging formats.
Don't wait till the last minute to start this phase!
Last updated on Mar 6, 2017