Labsheet 2 - for the week commencing 9th March 2020
REDUCE YOUR FRUSTRATION - UNDERTAKE THIS LABSHEET WITH A FRIEND.
The purpose of this week's labsheet is to introduce you to
implementation of Data Link Layer protocols,
and to use some simple plotting software
to present measurements of your protocols.
There is a lot of documentation at
which will provide most of the help that you need,
Frequently Asked Questions/
You may also install cnet
to your own Linux or Apple MacOS computer.
You will need to download cnet
's source code and any other necessary
libraries, and then compile and link them.
Full instructions appear on
Downloading and installing cnet
If installing on your own machine, ensure you have at least version 3.3.4.
NOTE: cnet is already installed on CSSE lab machines;
you do not need to install it yourself.
Within CSSE, the cnet
program is installed in the location
To save yourself having to type this pathname each time,
set yourself a shell alias.
Depending on which shell you use (type echo $SHELL to find out),
an alias may be set in one of two ways:
for sh, bash, ksh, or zsh:
for csh, or tcsh:
alias cnet "/cslinux/bin/cnet"
- [15 minutes]
Examine the cnet topology file TICKTOCK
and its corresponding "protocol" file ticktock.c.
Together they define a simple topology of two nodes connected by a single
The program 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" file ticktock.c
first includes the cnet header file,
with which you should become very familiar.
Take a copy of the files TICKTOCK
into a new directory and from the command-line type:
prompt> cnet TICKTOCK
The C protocol file will be automatically compiled
(with the 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.
- [1 hour]
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
The topology file STOPANDWAIT2 introduces frame corruption
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.
- [15 minutes]
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
to generate a plot that we can view using a standard web-browser.
The provided shellscript produces a plot basic for some "fixed" simulation
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.
- [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.
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
The use of an additional negative-acknowledgement frame will reduce this
Modify a copy of the provided stop-and-wait protocol to also use
Have the receiver reply with a negative-acknowledgement when a corrupt
You may like to use gnuplot,
or any other 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.]