In this assignment you will be implementing the BLAST protocol. Information on the BLAST protocol can be found in previous editions of Peterson & Davie, and in BLAST (pdf)
. You will implement BLAST on top of UDP. You will further consider where and how to test your implementation, specifically, how to drop packets so that the BLAST packet recovery is exercised.This lab is based on the BLAST protocol as defined by Peterson & Davie.
You are to submit your code, and a test plan including files for evaluating your Blast implementation. You will also demo your Blast implementation. You may discuss the material with whomever you wish. You may obtain help from anyone you wish, but you should clearly document that help.
To prepare for this assignment, read
the
BLAST
You may complete this assignment on any workstation.
See below for further implementation instructions.
The BLAST header has the following format:
1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 3 | 3 | ||||||||||
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 |
ProtNum | |||||||||||||||||||||||||||||||
MID | |||||||||||||||||||||||||||||||
Length | |||||||||||||||||||||||||||||||
NumFrags | Type | ||||||||||||||||||||||||||||||
FragMask |
What follows is an outline of subtasks. You should implement the sender and receiver in tandem so that you can test both of them as you go along.
Use a large text string, one that will require several fragments, as the data for the client (sender) to send to the server (receiver). Your fragments do not need to be as large as the length field implies they can be; choose a size that is useful for testing. A typical Ethernet maximum frame size is 1 KB, and your fragments could be much smaller.
In order to make sure your sender is robust, you should modify your receiver to "lie" to the sender in order to simulate network conditions which are not present in the lab (specifically, packet loss, delay, and reordering).
The receiver definitely must drop some packets in order to stress the protocol. When your receiver starts, it should accept a parameter that indicates how often to drop a packet, e.g., every 3rd packet. I know this is not random, but it is easy to understand in testing.
ProtNum
and
MID
fields in subsequent packets match the values from the first
packet received, and
that the packets are DATA
packets.
After verifying that a packet is valid, the receiver should
convert
the FragMask
to a packet number (ith
bit set
converts to the number i) and print the contents,
something like
this:
0, 2 of 15: tion, conceived in liberty and committed to the proposition that all me
Implement the LAST_FRAG counter on the receiver to help determine when a SRR should be sent. You may choose any reasonable value for the timer length. When the timer expires, print a status message.
When the last message arrives, or the LAST_FRAG timer expires, the receiver sends a SRR message back to the sender indicating which messages it has already received. You will need to modify the BLAST processing function to record which messages have been received as they come in.
Add a RETRY timer (set whenever an SRR message is sent), in the receiver. The length of this timer is also up to you. When the timer expires the first and second times, the receiver should resend the SRR and reset the RETRY timer. If the timer expires a third time, the receiver should give up on the BLAST session.
You should now have a BLAST receiver that receives the entire message and prints each part as it comes in. The receiver must now save these messages in a buffer and put them back together in the proper order.
Use script to capture a sender and receiver interaction that demonstrates your BLAST implementation in action. This interaction must include "lost" packets and may include delayed or reordered packets.
Be sure to