This framework has been designed to enable practical experiments and obtaining hands-on experience with implementation of transport layer protocols for reliable data transfer (RDT). The naming scheme used for the packages and the classes follows the naming scheme of the RDT1-4 protocols in the networking book.
To undertake the following exercises it is assumed that you have read section 3.4 in the networking book. You may also want to review the lecture notes from the transport layer lectures, in particular the parts that cover the RDT implementation framework.
Start by cloning and importing the RDT framework project into your IDE:
https://github.com/lmkr/dat110-rdt
and make sure that the classes and the tests compile.
The dat110-rdt
project is organised into the following packages
-
no.hvl.dat110.application
implements an application-level sender process that sends messages to a receiver application-level process using the underlying transport protocol implementation. -
no.hvl.dat110.common
contains some common classes for console-logging used in the implementation of the framework. It also contains theStopable.java
class which implements a stopable thread-abstraction which is central to the implementation of threads used in the transport protocol entities. -
no.hvl.dat110.network
implements a simulated network layer that can connect a sender and a receiver transport entity by means of two channels (one in each direction). By changing the type of the channels (the network model), we can simulate reliable and unreliable networks and undertake some controlled experiments with different transport protocol implementations. -
no.hvl.dat110.network.models
contains classes implementing various network/channel models, including a fully reliable channel, a channel in which DATA segments may be corrupted due to bit errors, a channel in which both DATA and ACK/NAK segments may get corrupted, a lossy channel, and a channel in which overtaking of segments is possible. -
no.hvl.dat110.transport
contains the base classes for implementing transport protocols for reliable data transfer of segments and defines the basic primitives ofrdt_send
,deliver_data
,udt_send
, andrdt_recv
. See figure 3.8 in the networking book. -
no.hvl.dat110.rdt1
contains classes implementing the RDT1 protocol. -
no.hvl.dat110.rdt2
contains classes implementing the RDT2 protocol. -
no.hvl.dat110.rdt21
contains classes implementing the RDT21 protocol. -
no.hvl.dat110.rdt3
contains classes implementing the RDT3 protocol. -
no.hvl.dat110.rdt4
contains classes that can serve as a basis for implementing the RDT4 protocol.
The test part of the project contains a package no.hvl.dat110.transport.tests
that implements unit-tests for running and testing the transport protocols. The basic correctness criteria is that the receiver must receive all data sent from the sender and in correct order.
Perform the following experiments
-
Run the main-method in
Main.java
where a sender process sends three messages to the receiver. Try to understand and interpret the output generated in the console and where it is generated from. -
Run the
TestRDT1.java
which tests the rdt1.0 transport protocol over a perfect channel. -
Run the
TestRDT2ReliableChannel.java
which tests the rdt2.0 transport protocol over a perfect channel. -
Run the
TestRDT2DataBitErrors.java
which test the rdt2.0 transport protocol over a channel with bit-errors on DATA segments.
The RDT2DataBitErrors.java
class implements a network model that at random negates the checksum in the transmitted segment thereby simulating a transmission errors. It tests whether the segment being processed by the network is a DATA segment, and only in that case may a negation of the checksum take place.
This in turn cause the doWaiting()
method in TransportReceiverRDT2.java
to detect that the received segment has a checksum errors and therefore send a NAK segment back to the sender.
Methods for calculating and checking checksums can be found in the SegmentRDT2.java
class.
Modify the implementation of the network model in RDT2DataBitErrors.java
such that also ACK/NAK may be corrupted, i.e., be exposed to transmission errors.
Augment the implementation of the sender side in the rdt2.0 transport protocol in TransportSenderRDT2.java
such that the sender checks for any transmission errors on ACK and NAK segments.
What could/should the sender do in case a corrupt ACK / NAK segment is received?
Implement your proposed solution and use the TestRDT2DataAckNakBitErrors.java
to test your solution. You can modify the probability of transmission errors by adjusting the value CORRUPTPB
in the RDT2DataAckNakBitErrors.java
network model.
To run the test you will also have to change the cast from SegmentRDT21
to SegmentRDT2
in RDT2DataAckNakBitErrors.java
since otherwise a cast-exception will be raised.
The no.hvl.dat110.transport.rdt21
package implements the RDT 2.1 transport protocol for reliable data transfer over a channel with bit errors as described on pages 237-239 in the networking book. The implementation of the sender and receiver are in the classes TransportSenderRDT21.java
and TransportReceiverRDT21.java
.
The transport receiver of RDT2.1 uses a NAK (negative acknowledgement) to signal to the sender that a corrupt data segment has been received. As described on page 242 in the networking book, then it is also possible to replace the use of NAKs with the use of an ACK (acknowledgement) in combination with a sequence number.
Modify the RDT 2.1 implementation (i.e., the classes TransportSenderRDT21.java
and TransportReceiverRDT21.java
) to become an RDT2.2 implementation as described on page 242 in the networking book.
The test TestRDT21DataAckNakBitErrors.java
can be used as a basis to test your protocol implementation.
The no.hvl.dat110.transport.rdt3
package implements the RDT 3.0 transport protocol for reliable data transfer over a channel with bit errors and loss of segments as described on pages 242-245 in the networking book.
The implementation of the sender in TransportSenderRDT3.java
uses a timer to implement timeouts, and thereby recover from possible loss of data and acknowledgements. The implementation of the timer constructs can be found in the RetransmissionTimer.java
class.
Study the implementation of the transport sender and transport receiver in order to understand how it implements retransmission and the state machines shown in Figures 3.15 and 3.16.
The test in TestRDT3LossyBitErrors.java
can be used to run and test the implementation.
The RDT3.0 protocol cannot recover from overtaking of segments, i.e., that segments may arrive in a different order from which they were sent.
The no.hvl.dat110.transport.rdt4
package contains templates for implementing a RDT 4.0 protocol that can recover from overtaking of segments. The protocol is to replace the alternating bit sequence number of RDT3.0 with an increasing sequence number and operates as follows:
-
The sender keeps sending the same data segment (having the same sequence number) until an acknowledgement with a sequence number which is one higher is received. This should include retransmission similar to RDT 3.0. This means that the sender interprets a sequence number received in an acknowledge which is one higher that its current sequence number as indication that the receiver has received the data segment with the current sequence number.
-
The receiver keeps an internal sequence number indicating the data segment expected next. If a data segment with the expected sequence number is received, then the internal sequence number is incremented and a corresponding acknowledgement segment is sent back to the sender. If the receiver receives a data segment with the wrong (non-expected) sequence number, then the receiver replies with an acknowledgement segment containing the sequence number of the data segment expected next.
The test in TestRDT4DelayLossyBitErrors.java
can be used to test and run the protocol implementation.
Modify the implementation of the receiver side of the RDT4.0 protocol in Exercise 5.2 such that an acknowledgement is only sent if the data segment with the expected sequence number is received. Is the protocol still correct?
Make an implementation of the Go-Back-N protocol in section 3.4.3 of the networking book. As part of this, you may want to augment SenderProcess.java
such that additional data is being sent from the sender-side.
Make an implementation of the Go-Back-N protocol in section 3.4.4 of the networking book.