1. Programming Project Design Report (CS 6390.001)
Group Members- Abhishek Datta (axd151630), Raj Gupta(rxg164730)
Implementation at network-level:
a> Functionality of a Fog Topology/distributed system including a bunch of nodes, interacting with each other to
provide relevant cloud services (like computation, networking and storage to IoT devices at lower level) thereby
considerably reducing the response-time delay incurred in IoT device-requests processed by the cloud.
Operation of fog-node roughly includes 2 specific tasks –
1> Receive request packets from IoT devices at UDP port, and either processing or forwarding to neighbouring
nodes on TCP connections based on max response-time limit;
2> Periodic exchange of current queuing-time information with 1-hop neighbours so that each node can decide
its best neighbour to forward the packet.
b> Simulation of the cloud-node functionality in the form of an independent thread implementation having a
considerably long enough queue, that can process any request that is forwarded towards it. Request packets can
be forwarded by any fog-node (in case maximum forward-limit of a packet reached) over TCP connections
established between individual fog-nodes and the cloud.
c> For debugging and testing purposes, the response packet received by the IoT device from the fog/cloud
should have the complete information of its own path traced across several fog-nodes before being accepted
and processed by any node. On receipt of any packet, the IoT device should be able to print (in plain text) from
the message body, a consolidated information of all the fog nodes visited and activity performed at each node on
the request packet until it is processed.
Assumptions considered during implementation:
1. A working model of IoT node implementation should be available beforehand, that continuously generates
request packets in specified format and randomly forwards to the fog-nodes.
The request-packet message body should follow the pre-decided format below: -
Packet sequence-number
Request-type
Forward Limit
IP-address of the request generator
UDP port-number of request generator
2. The IoT device request-generator should have prior knowledge on the IP-address/UDP port information for
each of the fog-nodes that it receives as input in the beginning.
3. The connection between IoT node and each fog-node should run on UDP (connectionless) socket
implementation. On the other hand, all fog-nodes should interact among themselves and with the cloud-node
over TCP sockets.
4. It can be inferred from the description that, a Request-type of x (should be a numerical value included in the
message body of any packet) should be implied as the processing time of x units (in secs). No further calculation is
needed to derive processing delay of any new packet.
5. The Maximum Response-time for any fog-node exceeding which a node must forward packets to the next best
neighbour/cloud, should be entered as an input parameter while running a fog-node on terminal with below
command: FogNode Max_Response_Time t MY_IP MY_UDP MY_TCP N1 TCP1 N2 TCP2...
6. The forward limit for each request packet obtained from the message body of the corresponding packet,
should be the decided max hop-limit after which an unprocessed request should be forwarded to the cloud.

2. Code-level implementation:
Implementation of fog-node/cloud functionality will be done in C/Java programming language at all levels.
TCP/UDP listener sockets (for receiving packets) and worker sockets (for processing per request-packet in a fog-
node) will be implemented as multiple threads in Java.
Another higher level of multi-threading will be implemented while designing active fog-nodes that can parallelly
process request-messages randomly posted by the IoT request generator. The active threads (representing fog-
nodes) will be maintained in a thread pool (i.e. the fog topology) which can act on any number of request-packets
periodically generated by the IoT devices.
Generic Approach and Understanding:
Packet forwarded over TCP connection to cloud-node in case Forward limit reached at R1 or R2 or R3 etc
UDP
UDP packet 2 UDP packet 4
UDP packet 1 UDP packet 3
1> All fog-nodes in the topology, run on the terminal with below command:
FogNode Max_Response_Time t MY_IP MY_UDP MY_TCP N1 TCP1 N2 TCP2...
2> IoT request generator receives input IP/UDP port information from the fog-nodes (declared in the
terminal), and runs below command in terminal:
IoTreqGen interval IP1 UDP1 IP2 UDP2...
3> Fog-nodes begin exchanging periodic updates on current queueing time delay with its 1-hop neighbours (as
specified in the terminal command run for each node i.e. N1, N2 etc) after every t secs (passed as an input
argument in the terminal command).
Fog-nodes interact over TCP sockets establishing connections among nodes, where one in a pair acts as a ser
-ver socket and listens on the TCP port identified in terminal command and the other acts as a client socket,
sending update. Initially queueing time for each node calculates as 0
4> Each fog-node listens for incoming request messages on its UDP port (as identified in terminal command).
Cloud node
Periodic TCP
updates (t secs)
Periodic TCP
updates (t secs)

3. On receipt of any new message Rnew from IoT request generator, the listener socket calculates its response
time (Queueing delay of all currently queued messages + Processing time for Rnew, as derived from request-
type) and compares with Max response-time (passed as an argument in terminal command of the node).
Timer function is called and checked for t seconds since last periodic update; in such case repeat step 3 again.
5> In case of response-time for Rnew < Max Response-time, it adds the new request to end of the processing
queue.
Otherwise, the request packet is forwarded to next best neighbour with least queueing time (based on
last periodic queueing-time update exchanged between 1-hop neighbours) thereby decrementing the
Forward Limit field in the message body. Care should be taken, not to re-forward to the best neighbour from
which the packet has been received, in which case it should be forwarded to the 2nd
best neighbour in the list.
Timer function is called and checked for t seconds since last periodic update; in such case repeat step 3 again.
6> In case Forward-Limit equals 0 while decrementing, it forwards the request packet towards the cloud-node
over TCP connection to the fixed-IP address/ TCP port defined for the cloud.
Also in step 5 if there is no best neighbour left in the periodic update list of the fog-node, it directly sends the
packet towards the cloud-node. Therefore, cloud is always the last priority in the periodic update list for any
fog-node.
Timer function is called and checked for t seconds since last periodic update; in such case repeat step 3 again.
7> In case the fog-node is unable to process the request-packet due to exceeding Max response-time of that
node, it appends a short information text at the end of the text-string within the message body and
propagates towards the next best neighbour. Continuing the process at each hop until the packet is processed,
a complete overview of the visited fog-nodes and activities performed by each node is printed when the
response packet arrives back at the IoT device.
For debugging reasons, below information per fog-node is enough to track the packet flow:
FogNode ID, Response-time calculated, Next Best neighbour, Neighbour’s queue-time update
Handing the looping problem:
Let suppose, the periodic TCP queueing update messages among the fog-node R2’s 1-hop neighbours creates a
best-neighbour decision table in below format:
Fog-node IP Fog-node TCP port Neighbour IP Neighbour Port Queueing time(secs)
R2 (192.x.x.x) 1000 R1 (192.y.y.y) 2000 25
R2(192.x.x.x) 1000 R3 (192.y.y.z) 3000 20
R2(192.x.x.x) 1000 R4 (192.y.y.x) 4000 15
R2(192.x.x.x) 1000 Cloud (10.0.0.1) 8080 Infinity
Case 1:
According to the above table, R2 should decide its best-hop neighbour as R4 as queueing delay is least (15 secs)
for R4 fog-node. In such cases, when the request packet has arrived from a fog-node to R2 which is later decided
as the best 1-hop neighbour, R2 should offload the packet to the 2nd
best neighbour R3 (with next best queueing
time 20 secs) to avoid looping problem among R2 and R4.
Queueing delay = 25 Max response-time reached Queueing delay = 20
Request packet forwarded by 4
Queueing delay = 15
1 2 3
4

4. Case 2 (leaf node):
According to the above table, R2 should decide its best-hop neighbour as R4 as queueing delay is least (15 secs)
for R4 fog-node. In this case, when the request packet has arrived from a fog-node (R4) to R2 which is later
calculated as the best 1-hop neighbour for R2, it should offload the packet to the 2nd
best neighbour R2 (with next
best queueing time 20 secs) to avoid looping problem among R2 and R4.
If R1 also has its max response-time exceeded, it has no other neighbour to forward to since R2 has already
offloaded the packet towards R1. In such cases, it should directly send the packet to cloud-node Ip address/port
number defined.
Cloud
Packet forwarded by 2
Queueing delay = 20 Max response-time reached Queueing delay = 25
Request packet forwarded by 4
Queueing delay = 15
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 2 3
4