|
|
Labsheet 3 - sample solutions and discussion
-
....
For this task, using the cnet network simulator:
- Add piggybacking to the standard stop-and-wait protocol.
- Modify the topology file,
changing the attributes of message delivery, bandwidth,
frame corruption and loss,
to determine under which conditions piggybacking offers an advantage....
-
....
To perform a valid scientific experiment
(which, after all, is what we're doing),
we need to hold all conditions/arrtibutes constant and vary just one over time,
perform the same experiment for both the stop-and-wait and
piggybacking protocols.
As in Labsheet 2,
develop a plot to help you to visually compare the results of your experiment....
The coded solution in
stopandwait-vs-piggyback.zip
show that,
under identical conditions of frame corruption and loss,
piggybacking
transmits more (but a similar number of) frames,
delivers more (but a similar number of) messages,
and
provides a lower average delivery time per message:
Why?
- ....
The simplest variant of a sliding-window protocol is termed
the go-back-N protocol,
in which the receiver simply discards (ignores) all frames after a bad one.
This corresponds to a receiver window size of 1.
After it learns of a lost (or corrupted frame),
the sender retransmits all unacknowledged frames -
it "goes back N frames" and starts again.
Notice that in the presence of significant errors that
bandwidth is wasted because the receiver only 'buffers' a single frame.
Following the same experimental approach as in the first task,
use cnet to implement the go-back-N protocol,
and determine under which conditions it is an improvement over the
stop-and-wait protocol.
The coded solution in
stopandwait-vs-gobackn.zip
show that,
under identical conditions of frame corruption and loss,
the go-back-N sliding-window protocol
transmits (significantly) more frames,
delivers (significantly) more messages,
but
provides a higher average delivery time per message:
Why?
Chris McDonald
March 2024.
|
