Compare the 3 flooding protocols by running the provided shellscript plot-flooding-to-html.sh, and modifying (uncommenting) its constants named YAXIS and METRIC. Observe the delivery improvements made by each successive protocol.
Examine the implementation of dll_basic.c, which provides a minimal reliable Data Link layer. It avoids any frame loss and corruption at the Physical layer (it cheats!) by calling CNET_write_physical_reliable() instead of CNET_write_physical(). Because "nothing can go wrong", we don't need to manage any sequence numbers or buffers of frames in this layer, and our DLL_FRAME structure can consist of just its payload (the NL's packets). Of course, this is rather unrealistic.
Implement the Distance Vector Routing protocol in cnet, using the number of hops as a routing metric. Initially, do not generate or deliver any messages (no node should call CNET_enable_application()). Instead, just focus on generating, transmitting, receiving, and merging the routing update packets. As seen in the stopandwait.c file, use an EV_DEBUG event handler to display each node's known routing table. Over time, the detail in the table should 'grow' until it stabilizes to reflect all connection information in the simulation.
Normally, in cnet protocols, we don't (need to) know the number of nodes in the whole simulation, as the goal is usually to develop adaptive protocols that learn about their (close) neighbourhood. However, invoking cnet with its -N command-line option will 'reveal' the number of nodes in the whole simulation in the C global variable NNODES. This integer value may be used to allocate sufficient space for each node's routing table, and we use each node's unique value of nodeinfo.nodenumber as an index into that table.
Construct a topology file of 5 or 6 nodes to test your ideas, or use the Australian topology from the flooding examples. When confident that your Distance Vector Routing protocol is discovering all nodes in your network, generate a random topology of 20, 50, 100 nodes with:
A good approach (all in one C file) -
Before making extensive changes to the provided code, carefully consider what changes you may need to make to support the stopandwait protocol.
Take a copy of AUSTRALIA.MAP, add a few more nodes and links to make the distance from, say, Perth to HongKong, 6 hops. Now observe how the flooding3 protocol will fail to deliver messages.
Can you devise a modification to the flooding3 protocol to support topologies with lengthy paths?
Chris McDonald March 2020.