Programming Project Design Report (CS 6390.001)

Group Members- Raj Gupta(rxg164730), Abhishek Datta (axd151630) 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.

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)

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

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