CITS3002 Computer Networks - Labsheet 2  
 

Unit home

help3002

Lecture recordings
via LMS

Schedule

Unit outline

Resources

Textbooks

Extra reading



Look after yourself!

Labsheet 2 - for the week commencing 11th March 2024

REDUCE YOUR FRUSTRATION - UNDERTAKE THIS LABSHEET WITH A FRIEND.

The purpose of this week's labsheet is to introduce you to the cnet network simulator, implementation of Data Link Layer protocols (introduced in Lecture 3), and to use some simple plotting software to present measurements of your protocols. There is a lot of documentation, which should provide most of the help that you need, including a Frequently Asked Questions page.

cnet has been tested and is supported on the following platforms:

  • Apple M-series 'Silicon' processor (built on macOS Sonoma 14.3)
  • Apple with 64-bit Intel processor (built on macOS Sonoma 14.3)
  • Linux on 64-bit Intel processor (built on Ubuntu 23.04 LTS)

cnet is not installed on laboratory computers in CSSE or the UniApps Virtual Lab System. However, you may install it on your own laptop or desktop computer. In particular, cnet does not run natively on Windows, but you should have success using Windows Subsystem for Linux (WSL-2) on Windows-11.

To download and install a pre-built cnet binary and its resources, follow these instructions.



And then to work....
  1. [15 minutes] [files required: TICKTOCK, ticktock.c ]
    Examine the cnet topology file TICKTOCK and its corresponding "protocol" in file ticktock.c. Together they define a simple topology of two nodes connected by a single bidirectional link. The code in ticktock.c demonstrates the use of timer events in cnet which you will later use to provide timeouts in your protocols. Notice that the "protocol" in file ticktock.c first includes the cnet.h header file (in /usr/local/lib/cnet/cnet.h ) which all cnet protocols (code) must include.

    Take a copy of the files TICKTOCK and ticktock.c into a new directory and, at the command-line, type:

    shell>  cnet TICKTOCK

    The C file will be automatically compiled (with your local C compiler) and a simple graphical representation of the two node network will be displayed. Selecting either of the nodes (Perth or Melbourne) with the left mouse button will open a new window for that node on which you see the node's timer function timeouts() ticking away.

    Although this is a rather trivial exercise, make sure that you understand what is happening.

  2. [5 minutes] [files required: CLICK, click.c ]
    Another simple example demonstrating how buttons on cnet's GUI may invoke event handlers in your protocols.

    Take a copy of the required files and, at the command-line, type:

    shell>  cnet CLICK

  3. [1 hour] [files required: STOPANDWAIT1, STOPANDWAIT2, STOPANDWAIT3, stopandwait.c ]
    These files provide an implementation of the stop-and-wait protocol introduced in lectures. You will not need to modify these files, but you should execute the protocol with each of the topology files.

    The topology file STOPANDWAIT1 defines the basic topology consisting of just 2 nodes and 1 link - the minimum we require for a Data-Link Layer protocol. The topology file STOPANDWAIT2 introduces frame corruption and the topology file STOPANDWAIT3 introduces frame loss.

    For each of the topology files, follow the path that each frame will take "through the source code" when there's no Physical Layer problems, then frame corruption, and then frame loss.

    Gather some basic statistics from cnet that show how the probabilities of frame corruption and loss affect the number of frames delivered in a fixed length of time.

  4. [15 minutes] [file required: plot-to-html.sh ]
    We will finally investigate the performance of our stop-and-wait protocol - how it performs under varying characteristics of (random) frame corruption and loss. We will need to run a number of simulations, varying just one attribute while holding all others constant.

    Execute the provided plot-to-html.sh shellscript (with  ./plot-to-html.sh ) to both run your simulations and to generate an HTML file that uses Google charts to generate a plot that we can view using a standard web-browser.

    The provided shellscript produces a plot basic for some "fixed" simulation attributes; can edit the first few lines of the shellscript to run different simulations, and to focus on different metrics.

    Note that you may wish to print additional or different statistics. In support of this, experiment with the EV_SHUTDOWN event, and the -f and -s command line options.

    NOTE: you do not have to specifically use this shellscript - if you have a preferred method of plotting 2D data, perhaps with Excel or Matlab, then feel free to use that.

  5. [1-2 hours, HARDER] 🌶 🌶
    Q2 presented a complete stop-and-wait protocol which used acknowledgements to report the successful arrival of data frames. If a corrupted frame arrived, the receiver would simply ignore it and the sender's timeout mechanism would cause retransmission of the data frame.

    This protocol, although robust, introduces some inefficiency because the sender is not directly (or quickly) informed about a corrupt data frame arriving at the receiver. The sender actually only infers the data frame corruption after a timeout occurs. The use of an additional negative-acknowledgement frame will reduce this inefficiency.

    Modify a copy of the provided stop-and-wait protocol to also use negative-acknowledgements. Have the receiver reply with a negative-acknowledgement when a corrupt frame arrives.

    You may like to use your favourite plotting software to show that your addition of negative-acknowledgements improves the standard protocol.

    [This is an interesting problem - don't panic about the apparent need for lots of tricky code. Think about the problem - it requires a bit of logic and only about 8 lines of code.]


Chris McDonald

March 2024.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Presented by [email protected]