The University of Western Australia
Computer Science and Software Engineering

Department of Computer Science and Software Engineering

CITS3002 Computer Networks

Labsheet 5 - for the week commencing 30th March 2020

  1. [15 minutes]
    [file required: ]

    Create a new directory for this labsheet, and take a copy of and expand the ZIP archive file.
    Before examining any source code files, read the file 1st.README.

    Compare the 3 flooding protocols by running the provided shellscript, and modifying (uncommenting) its constants named YAXIS and METRIC. Observe the delivery improvements made by each successive protocol.

  2. [15 minutes]
    All 3 flooding implementations share a number of source code files - notably code to implement a basic Data Link Layer and code to implement a simple Network Layer routing table. Each cnet topology file indicates which source files are to be compiled to build one of the 3 flooding implementations.

    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.

  3. [1 hour]
    In Lecture-6 we saw that the Distance Vector Routing protocol provides a simple mechansim for routing messages. Periodically, say every 30 seconds, nodes exchange information with their direct neighbours about how 'far away' are other nodes in the network. Providing nodes and links don't crash, and the number of nodes in the network is fixed, the Distance Vector Routing protocol enables convergence of routing information, but can also adapt to varying per-node and per-link conditions.

    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:

    cnet -N -C "distancevector.c anyotherfiles.c..." -r 20

    A good approach (all in one C file) -

    1. design a simple data-structure to hold your routing table and the updates that each node will send to neighbours;
    2. write your reboot_node() handler to allocate any memory and declare other event handlers;
    3. write an event handler to periodically send an update vector to all neighbours;
    4. write an event handler to receive update vectors from neighbours and merge their contents with the routing table;
    5. write an event handler to display the current routing table when a debug button is pressed.

  4. 🌶 [1 hour]
    Returning to the flooding examples, replace the implementation of dll_basic.c with a stopandwait protocol, as seen in earlier labsheets. Making such a change to a single file should then provide more realistic implementations of all 3 flooding protocols. Note, that each node will require an instance of the stopandwait protocol to execute on each of its links.

    Before making extensive changes to the provided code, carefully consider what changes you may need to make to support the stopandwait protocol.

  5. 🌶 🌶 [1-2 hours]
    All 3 flooding protocols limit the maximum distance travelled by any single message, through the use of the constant MAXHOPS. This is set to 4 for AUSTRALIA.MAP, but for a larger map, such a limitation will actually prevent distant nodes from communicating at all.

    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.

This Page

Written by: [email protected]