|
(for the week commencing 24th March 2008)
The purpose of this week's labsheet is to introduce you to the cnet
network simulation software.
cnet will be used for the practical work in our unit this year,
so familiarity with cnet can only be a good idea.
There is a lot of WWW-based documentation for cnet
(at
http://www.csse.uwa.edu.au/cnet3/ )
which will provide most of the help that you need.
The cnet program is installed in the location
/cslinux/bin/cnet.
To save yourself having to type this pathname each time,
why not set yourself a shell alias?
Depending on which Linux 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:
alias cnet="/cslinux/bin/cnet"
- for csh:
alias cnet "/cslinux/bin/cnet"
All files referred to in this labsheet are, of course, in
/cslinux/examples/CITS3230/Lab2.
- 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
bidirectional link.
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,
/cslinux/cnetlib3/cnet.h,
with which you should become very familiar.
Take a copy of the files TICKTOCK
and ticktock.c
into a new directory and from the command-line type:
cnet TICKTOCK
The C protocol file will be automatically compiled (with gcc)
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 "pop up" a new window for that node on which you see the
node's timer function timeouts() ticking away.
Similarly,
copy and examine the cnet topology files CLICK
and KEYBOARD and their corresponding "protocol" files
click.c and keyboard.c.
Although these are rather trivial exercises,
make sure that you understand what is happening.
- The protocol source file protocol.c
(and its topology file TOPOLOGY.2a)
enables each node's Application Layer to generate messages for delivery
(to the other node).
Each node will run its own copy of the same protocol
and access its own copy of any variables.
Experiment with each node's buttons to change the size of messages to be
generated and their rate.
Again, make sure that you understand what is happening.
- Copy protocol.c into a new file,
stopandwait.c,
and (surprisingly) implement a simple stop-and-wait protocol.
Initially, do not modify the topology file
to introduce any errors into the Physical Layer.
- Using TOPOLOGY.2b,
which introduces frame corruption (only) into the Physical Layer,
extend your stop-and-wait protocol to detect and handle the
frame corruption (using one of the supplied checksum functions).
The probframecorrupt = 3 attribute
will corrupt a frame with a "one in eight" chance.
- Slightly harder: Using TOPOLOGY.2c,
which now introduces frame loss into the Physical Layer,
extend your stop-and-wait protocol to detect and handle frame
loss (using a suitable timeout scheme).
NOTE: If you do not have file-system permissions to read or execute
certain files in the directory,
it is because they have have not yet been "released" to you.
Chris McDonald
March 2008.
|