Jay Thom Sifat Ibne Mushfique CPE 701 Semester Project README/Manual

Introduction The following is a README for the CPE 701 semester project completed by Jay Thom and Sifat Ibne Mushfique. The project, completed in the Python programming language, is a simulation of the protocols used in the 5 layers of the Internet Protocol Stack, plus a simulated distance-vector algorithm to support message forwarding in a multi-node environment.

To run the program, navigate to the /CPE_701/Application/Application.py folder and enter “python Application.py ” where the node ID is the NID of the particular instance being started, and the itc file name is the name of the initial topology file being use (i.e. itc.txt). At this point you will be presented with a very clear user interface that will demonstrate all of the options available, along with prompts for the required parameters. While the program will run if all instances of nodes are created from one file, ideally separate directories would be set up for each instance so that the sending of files from one node to another is sensible and easy to track.

Physical Layer – Sifat Ibne Mushfique The Physical Layer of this application is basically used to create the whole network topology and set up the attributes of a particular node / instance. It has a class named as Node, which has the attributes stored for the current node / instance from which the application is being run, and a function named InitializeTopology, which sets up the attributes for this node / instance.

When the application is run from the Application Layer, then the function InitializeTopology from the Physical Layer instantly sets up the attributes of the current node / instance by parsing the itc file given in the command line argument. It also creates link table for the network by using the information given in the itc file. The attributes for the current node / instance can be viewed by using the “print status” menu in the Application Layer which calls the PrintStatus function inside the Physical Layer.

Link Layer – Jay Thom The Link Layer is built around a class called MyUDPHandler that acts as a server to receive incoming messages on a UDP socket with the port number assigned to the node by the initial topology file. The UDP handler utilizes a listener that is started on a separate thread and runs in a continuous loop to capture any incoming traffic. When the listener receives a message it is handed up to the handler for processing. The listener parses the beginning of the message and looks for a string of the type ‘hhhhh’ indicating that the received packet is a keepalive message from one of its two links. These messages are generated by a timer function and a hello function that generate outgoing hello messages on a timed interval to check on the status of the nodes two neighbors. When a hello is received, it triggers a change in one of the two UpFlag fields in the Node class, found in the Physical Layer. These flag states are queried by the routing algorithm in the Routing protocol, and help determine next hop information. If the received packet does not begin with this distinct string, the packet is forwarded to the Network Layer for further processing.

The Physical Layer also hosts the garbler function, which is set from the Application Layer. The garbler is given a probability between 1 and 100 for one of two functions; to determine packet loss, and to determine the corruption of packets. If packet loss is called for, the UDP packet is simply dropped (not sent) to simulate loss in the network. If corruption is called for, the frame is opened, and a string is appended to the payload. This is then repackaged, and sent as normal. If the program is functioning properly, this will cause a discrepancy in the checksum field, and the packet will be marked as corrupted and will be dropped in the Transport Layer.

The Link Layer is meant to simulate the implementation of the Internet’s link layer, providing for connection from one node (router) to another.

While there are no mechanisms for checking the status of the Link Layer directly, by choosing option 12 in the main menu one can view the status of the links to a given node’s neighbors, which is generated in the Link Layer.

Network Layer – Jay Thom The network layer is built around a dictionary data structure that simulates a network datagram. Messages are received from the Transport layer, the headers read, and the payload inserted into a datagram that is then passed to the Link Layer. The Network Layer sets a time to live (ttl) that is then decremented each time it returns to this function in another instance, dropping the packets if the ttl reaches zero. There are also fields where sequence number and MTU are set, but these are not used, as this functionality was not completed. When datagrams are received from the Link Layer, the header is inspected to see if the destination address is the same as the current node’s NID, and if so, the layer 4 frame is extracted and passed up to the Transport Layer. If the datagram is not intended for this node, the ttl is decremented, and it is returned to the Link Layer for transport to the next node.

Ideally, MTU would have been checked in this layer, and datagrams fragmented to accommodate heterogeneous MTU’s, but this functionality was not comleted.

Routing Protocol – Sifat Ibne Mushfique The Routing Protocol of this application has two main functionalities – printing the routing table managed by each node, and determining the next hop that is needed to be taken in order to follow the shortest path towards the destination. Two functions are written for these purposes – route_table and next_hop.

route_table takes the NID of the current node as it’s argument. Inside the function, the link table generated by the Physical Layer is traversed in order to calculate the shortest path to reach all other node except the current node. Since there are only two possible ways to reach to any destination node (as there will be no more than two connection for any node in the network), so the route which infers the minimum cost to reach these nodes are calculated – and in the process, the next hop to follow this route is also determined. This minimum cost along with the next hop that is needed to be chosen to take this minimum cost route is printed when the function is called.

next_hop also works in similar manner like route_table, except from the fact that it will take a particular NID as an added argument along with the NID of the current node – that is the NID of the destination node when something is needed to be sent across the network. This function will not print anything – instead it will return the NID of the next hop to take the minimum cost route to reach the destination – which is calculated in the similar way as in the function route_table. This function is used by the other layers for forwarding packets across the network.

Transport Layer – Jay Thom/Sifat Ibne Mushfique The Transport Layer consists mainly of two functions; one to receive traffic from the Application Layer and forward it to the Network Layer, and one to receive traffic from the Network Layer and forward it to the Application Layer. The layer is based on a dictionary data structure simulating a layer 4 frame. When traffic is received from Layer 5, a header is constructed and the payload is placed in the frame. A checksum is calculated and is also included in the payload so that the integrity of the frame can be checked when received again from layer 3.

Functionality to support segmentation of data, acknowledgement of packet receipt, sliding window functionality, and out-of-order packets were not completed for this project.

Application Layer – Jay Thom/Sifat Ibne Mushfique The Application Layer acts as the main driver for the entire program. This file includes the ‘main’ function, and initiates the other layers of the simulation. The Application Layer is menu driven, and starts a number of threads for various functions, and serves as the landing point for transferred files. The following functionality is offered to a user:

Start New Service – a request to start new service initiates a prompt for how many connections the service point will accept. A random 3-digit number is generated for the SID, and it is stored in a dictionary data structure for later reference.

Stop Service – a request to stop service initiates a prompt for the service that should be stopped, and this SID along with its associated connections are removed from the dictionary.

List Service Points – this function will list all existing service points so that the user can view what SID’s and CID’s are available.

Connect – a request to connect will initiate a prompt for a NID (node identification) and an SID to connect to. This forwards a message to the indicated node, where a check is made for that SID. If the SID exists and there is room for an additional connection, a CID is added to the responding node’s SID list, and a 4-digit number is generated and returned to the requesting node for future use.

Close Connection – a request to close a connection will initiate a prompt for a CID, and this CID is removed from the connection list.

Download – a request to download a file will initiate a prompt for a filename and an NID. A message is forwarded to the indicated node requesting the file. If the file exists, it will be returned to the requesting node, if it doesn’t exist, a message indicating this is returned.

Set Garbler – a request to set the garbler will initiate a prompt for values between 1 and 100 indicating the probability of packet loss or packet corruption. These values are then set in the Link Layer. After each sending of a packet, the values are reset to a 0 probability.

Display Routing Data – this function will print the current routing data to the screen.

Down Link – a request to down a link will initiate a prompt for a node with which a link should be downed. A message indicating success or failure is returned.

Up Link – a request to up a link will initiate a prompt for a node with which a link should be upped. A message indicating success or failure is returned.

Send Text Message – a request to send a text message will initiate a request for a node to which the message should be sent, and a request for a message. The message will be forwarded to that node in the fashion of an instant message. This is mainly for testing purposes.

Status – this function will query the Physical Layer, and will print to screen the basic topology information for the current node, along with the status of its links to neighboring nodes.

Division of Tasks Among Team Members: Task ‘A’ – Physical Layer: Sifat Ibne Mushfique Task ‘B’ – Link Layer: Jay Thom Task ‘C’ – Network Layer: Jay Thom Task ‘D’ – Routing Protocol: Sifat Ibne Mushfique Task ‘E’ – Transport Layer: Jay Thom/Sifat Ibne Mushfique Task ‘F’ – Application Layer: Jay Thom/Sifat Ibne Mushfique

Comparison to tentative rubric dated Friday February 26, 2016 -30 points no submission of source files - Complete -10 points no readme/manual - Complete -10 points no distributed execution - Complete -5 points link layer cannot handle heterogeneous MTU’s (Task B) - Incomplete -5 points no error detection - Complete -5 points node failures cannot be handled (Task A) - Complete -5 points the non-blocking/simul. downloads do not work properly - Complete -5 points can only download text files - Complete -5 points out of order is not handled - Incomplete -5 points no sliding window - Incomplete -5 points closing connection does not work - Complete -5 points Task F is missing - Complete