Blast
Content
Lab 10 (CSC 364, 2012S)
This week
Schedule
Mechanics
Contact
CSC 364, 2012S » Schedule » Lab 10
Search
Implementing the BLAST Protocol
Due date
Monday, April 23
Introduction
In this assignment you will be implementing the BLAST protocol. Information on the BLAST protocol can be found in previous editions of Peterson & Davie. 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.
Acknowledgments
This lab is based on the BLAST protocol as defined by Peterson & Davie. It was written by Mike Erlinger at Harvey Mudd College.
Goals
To To To To implement a transport-layer protocol. understand how to implement a protocol to a specification. encounter protocol implementation issues. experiment with testing and evaluating a new protocol.
Logistics
Students should pair up to complete this assignment. Link to your work in BOTH lab notebooks. You may discuss the material with whomever you wish. You may obtain help from anyone you wish, but you should clearly document that help. You have two weeks to complete this assignment.
1 of 6
Lab 10 (CSC 364, 2012S)
Preparation
To prepare for this assignment, read section 4.3.1 (pp. 408 - 413) in Peterson & Davie, 3rd edition, on the BLAST bulk transfer protocol. Because this material no longer appears in the current edition of the textbook, I will hand out photocopies in class on Monday. You may complete this assignment on any MathLAN workstation. See below for further implemenation instructions.
Assignment
The BLAST header
The BLAST header has the following format (bit numbers across the top): 1111111111222222222233 01234567890123456789012345678901 ProtNum MID Length NumFrags FragMask ProtNum Normally used to demultiplex BLAST messages. Since your client will not have any explicit protocols riding on top of BLAST, you should set this field to first four characters of your last name. The server will use whatever value you use in your messages. MID Message ID: Used to differentiate multiple BLAST streams. Your client will only be dealing with a single stream, but you should code basic support for multiple streams, e.g., set up a running counter to handle new streams. The server will use whatever value the client sends to it in the initial message. Length Length (in bytes) of the data which follows the header. NumFrags Total number of fragments in this BLAST message. This is used to determine Type
2 of 6
Lab 10 (CSC 364, 2012S)
which message is the last one in the sequence. Type 1 DATA 2 SRR FragMask Bitmask indicating packet number. DATA packets from the server should have only one of these bits set to indicate which packet this is. SRR packets should have bits set for every message that has been received so far and zeros for all missing messages. You'll find the C functions for manipulatng bit fields to be useful here: & (bitwise and), | (bitwise or), << (shift left), and >> (shift right).
Task 1 - Implement BLAST Sender and Receiver on the MathLAN
What follows below 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. You will need to design a struct to represent the BLAST header. This data structure should be shared between the sender and receiver via a C header file. As the data for the client (sender) to send to the server (receiver), use a large text string, one that will require several fragments. 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 1500 bytes, and your fragments could be much smaller. It's okay to hard code this data for testing purposes, but it might be more fun to read data from STDIN. 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's easy to understand. Step 1 The sender will initiate a BLAST connection by simply sending the first BLAST data packet via a UDP socket. Then it will send the remaining packets.
3 of 6
Lab 10 (CSC 364, 2012S)
The receiver should ensure that the 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. If the protocol number is "LINC", the message id is 0, and packet 2 of 15 has just been received, then the output should look something like this: LINC
0, 2 of 15: tion, conceived in liberty and committed to the proposition that all me
Step 2 Implement the LAST_FRAG timer on the receiver to help determine when a SRR should be sent. You may choose any resonable value for the timer length. When the timer expires, print a status message. Also implement the DONE timer in the sender. The sender should print a message and exit when the DONE timer fires. Here is an example of implementing a timer using the timeout.c. (It's also a fun game.) Step 3 When the last fragment arrives, or the LAST_FRAG timer expires, the receiver sends a SRR message back to the sender indicating which fragments it has already received. You will need to modify the receiver's BLAST processing function to record which fragments have been received as they come in. The sender will need to accept a SRR message and retransmit the appropriate fragments. Step 4 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 may want to temporarily disable retransmission in the sender to test this feature.) Step 5
select
syscall: select-
4 of 6
Lab 10 (CSC 364, 2012S)
You should now have a BLAST receiver that receives all of the fragments and prints each fragment as it arrives. The receiver must now save these fragments 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.
Task 2
Move your BLAST implementation to your Emulab network. Disable your built-in packet loss and experiment with the delay and loss characteristics of the links. (Emulab's simulated packet loss, unlike yours, is fairly random.)
Assessment
To earn a B, complete Task 1 along with the discussion questions. To earn an A, also complete Task 2.
Advice
Make sure you have read and understand the book's description of BLAST before you begin. If you have questions, write them down and ask me during our lab meetings or office hours. The htons function is your friend. You should already know how to use UDP sockets from the lab on sockets. Recall that recvfrom() allows you to receive the IP address of the sender along with the contents of the UDP datagram.
Discussion Questions
1. How much does performance depend on the settings of the various timers used to implement BLAST? 2. What guarantees does BLAST give you concerning message delivery? 3. What does BLAST not guarantee? Why not? 4. When would one choose TCP instead of BLAST as a transport layer protocol, or vice versa? 5. How long did you spend on this assignment?
Lab Notebook
Be sure to
5 of 6
Lab 10 (CSC 364, 2012S)
include any relevant program source, document your code, and include your answers to the discussion questions. Janet Davis ([email protected]) Created March 31, 2009 Last revised April 11, 2012
6 of 6
This week
Schedule
Mechanics
Contact
CSC 364, 2012S » Schedule » Lab 10
Search
Implementing the BLAST Protocol
Due date
Monday, April 23
Introduction
In this assignment you will be implementing the BLAST protocol. Information on the BLAST protocol can be found in previous editions of Peterson & Davie. 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.
Acknowledgments
This lab is based on the BLAST protocol as defined by Peterson & Davie. It was written by Mike Erlinger at Harvey Mudd College.
Goals
To To To To implement a transport-layer protocol. understand how to implement a protocol to a specification. encounter protocol implementation issues. experiment with testing and evaluating a new protocol.
Logistics
Students should pair up to complete this assignment. Link to your work in BOTH lab notebooks. You may discuss the material with whomever you wish. You may obtain help from anyone you wish, but you should clearly document that help. You have two weeks to complete this assignment.
1 of 6
Lab 10 (CSC 364, 2012S)
Preparation
To prepare for this assignment, read section 4.3.1 (pp. 408 - 413) in Peterson & Davie, 3rd edition, on the BLAST bulk transfer protocol. Because this material no longer appears in the current edition of the textbook, I will hand out photocopies in class on Monday. You may complete this assignment on any MathLAN workstation. See below for further implemenation instructions.
Assignment
The BLAST header
The BLAST header has the following format (bit numbers across the top): 1111111111222222222233 01234567890123456789012345678901 ProtNum MID Length NumFrags FragMask ProtNum Normally used to demultiplex BLAST messages. Since your client will not have any explicit protocols riding on top of BLAST, you should set this field to first four characters of your last name. The server will use whatever value you use in your messages. MID Message ID: Used to differentiate multiple BLAST streams. Your client will only be dealing with a single stream, but you should code basic support for multiple streams, e.g., set up a running counter to handle new streams. The server will use whatever value the client sends to it in the initial message. Length Length (in bytes) of the data which follows the header. NumFrags Total number of fragments in this BLAST message. This is used to determine Type
2 of 6
Lab 10 (CSC 364, 2012S)
which message is the last one in the sequence. Type 1 DATA 2 SRR FragMask Bitmask indicating packet number. DATA packets from the server should have only one of these bits set to indicate which packet this is. SRR packets should have bits set for every message that has been received so far and zeros for all missing messages. You'll find the C functions for manipulatng bit fields to be useful here: & (bitwise and), | (bitwise or), << (shift left), and >> (shift right).
Task 1 - Implement BLAST Sender and Receiver on the MathLAN
What follows below 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. You will need to design a struct to represent the BLAST header. This data structure should be shared between the sender and receiver via a C header file. As the data for the client (sender) to send to the server (receiver), use a large text string, one that will require several fragments. 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 1500 bytes, and your fragments could be much smaller. It's okay to hard code this data for testing purposes, but it might be more fun to read data from STDIN. 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's easy to understand. Step 1 The sender will initiate a BLAST connection by simply sending the first BLAST data packet via a UDP socket. Then it will send the remaining packets.
3 of 6
Lab 10 (CSC 364, 2012S)
The receiver should ensure that the 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. If the protocol number is "LINC", the message id is 0, and packet 2 of 15 has just been received, then the output should look something like this: LINC
0, 2 of 15: tion, conceived in liberty and committed to the proposition that all me
Step 2 Implement the LAST_FRAG timer on the receiver to help determine when a SRR should be sent. You may choose any resonable value for the timer length. When the timer expires, print a status message. Also implement the DONE timer in the sender. The sender should print a message and exit when the DONE timer fires. Here is an example of implementing a timer using the timeout.c. (It's also a fun game.) Step 3 When the last fragment arrives, or the LAST_FRAG timer expires, the receiver sends a SRR message back to the sender indicating which fragments it has already received. You will need to modify the receiver's BLAST processing function to record which fragments have been received as they come in. The sender will need to accept a SRR message and retransmit the appropriate fragments. Step 4 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 may want to temporarily disable retransmission in the sender to test this feature.) Step 5
select
syscall: select-
4 of 6
Lab 10 (CSC 364, 2012S)
You should now have a BLAST receiver that receives all of the fragments and prints each fragment as it arrives. The receiver must now save these fragments 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.
Task 2
Move your BLAST implementation to your Emulab network. Disable your built-in packet loss and experiment with the delay and loss characteristics of the links. (Emulab's simulated packet loss, unlike yours, is fairly random.)
Assessment
To earn a B, complete Task 1 along with the discussion questions. To earn an A, also complete Task 2.
Advice
Make sure you have read and understand the book's description of BLAST before you begin. If you have questions, write them down and ask me during our lab meetings or office hours. The htons function is your friend. You should already know how to use UDP sockets from the lab on sockets. Recall that recvfrom() allows you to receive the IP address of the sender along with the contents of the UDP datagram.
Discussion Questions
1. How much does performance depend on the settings of the various timers used to implement BLAST? 2. What guarantees does BLAST give you concerning message delivery? 3. What does BLAST not guarantee? Why not? 4. When would one choose TCP instead of BLAST as a transport layer protocol, or vice versa? 5. How long did you spend on this assignment?
Lab Notebook
Be sure to
5 of 6
Lab 10 (CSC 364, 2012S)
include any relevant program source, document your code, and include your answers to the discussion questions. Janet Davis ([email protected]) Created March 31, 2009 Last revised April 11, 2012
6 of 6
