Download Handout for assignment2 and more Summaries Network Analysis in PDF only on Docsity!
CSE 489/
Programming Assignment 2
Reliable Transport Protocols
1. Objectives
In a given simulator, implement three reliable data transport protocols: Alternating-Bit (ABT), Go-Back-N (GBN), and Selective-Repeat (SR).
2. Getting Started
2.1 Reading
Alternating-Bit Protocol (rdt3.0) 8th Edition Textbook: Page 241 – Page 245 Go-Back-N Protocol 8th Edition Textbook: Page 245 – Page 250 Selective-Repeat Protocol 8th Edition Textbook: Page 250 – Page 256
2.2 Play with the GBN and SR applet
https://www2.tkn.tu-berlin.de/teaching/rn/animations/gbn_sr/
2.3 Install the PA2 template
Read the document at CSE 4/589: PA2 Template in full and install the template. It is mandatory to use this template.
2.4 Report
Under NO circumstances may students rely on the work of their peers, including but not limited to GitHub repositories or code submissions from previous academic terms. You need to write a report for this assignment. See more details in section 6 and follow the instructions in the PA2 Report Template. Your submission will NOT be graded without submitting the reports.
3. Implementation
3.1 Programming environment
You will write C (or C++) code that compiles under the GCC (GNU Compiler Collection) environment. Furthermore, you should ensure that your code compiles and operates correctly on the host assigned to you in section 3.2. You can develop or test your code on your local Linux machine. However, for the analysis experiments in Section 6, you should NOT use any machine other than the CSE host servers to run those experiments, which means that the analysis results should come from the CSE host server. Your code should successfully compile using the version of gcc (for C code) or g++ (for C++ code) found on the host assigned to you and should function correctly when executed. Further, your implementation should NOT involve any disk I/O unless explicitly mentioned in the PA description.
3.2 Dedicated host
For the purpose of this assignment, you should only use (for development and/or testing) the directory created for you on one of the following hosts. stones.cse.buffalo.edu euston.cse.buffalo.edu embankment.cse.buffalo.edu underground.cse.buffalo.edu highgate.cse.buffalo.edu You can log in to those five hosts using your UBITName and password. For example: $ ssh yourubit@stones.cse.buffalo.edu For each host, your directory is located at: /local/Fall_2023/<Your-UBIT-Name>/ The access permission to this directory has already been changed so that only you are allowed to access the contents of the directory. This is to prevent others from getting access to your code.
3.3 Overview
In this programming assignment, you will be writing the sending and receiving transport-layer code for implementing a simple reliable data transfer protocol. There are 3 versions of this assignment, the Alternating-Bit Protocol version, the Go-Back-N version, and the Selective-Repeat version. Since we don't have standalone machines (with an OS that you can modify), your code will have to execute in a simulated hardware/software environment. However, the programming interface provided to your routines, i.e., the code that would call your entities from above and from below is very close to what is done in an actual UNIX environment. Stopping/starting of timers is also simulated, and timer interrupts will cause your timer handling routine to be activated.
message to send. It is the job of your protocol to ensure that the data in such a message is delivered in order, and correctly, to the receiving side upper layer.
A_input(packet)
Where the packet is a structure of type pkt. This routine will be called whenever a
packet sent from the B-side (as a result of a tolayer3() (see section 3.5) being called by
a B-side procedure) arrives at the A-side. packet is the (possibly corrupted) packet sent
from the B-side.
A_timerinterrupt()
This routine will be called when A's timer expires (thus generating a timer interrupt). You'll probably want to use this routine to control the retransmission of packets. See
starttimer() and stoptimer() below for how the timer is started and stopped.
A_init()
This routine will be called once, before any of your other A-side routines are called. It can be used to do any required initialization.
B_input(packet)
Where the packet is a structure of type pkt. This routine will be called whenever a
packet sent from the A-side (as a result of a tolayer3() (see section 3.5) being called by
a A-side procedure) arrives at the B-side. packet is the (possibly corrupted) packet sent
from the A-side.
B_init()
This routine will be called once, before any of your other B-side routines are called. It can be used to do any required initialization. These six routines are where you can implement your protocols. You are not allowed to modify any other routines.
3.5 Software Interfaces
The procedures described above are the ones that you will write. We have written the following routines which can be called by your routines:
starttimer(calling_entity, increment)
where calling_entity is either 0 (for starting the A-side timer) or 1 (for starting the B side
timer), and increment is a float value indicating the amount of time that will pass before
the timer interrupts. A's timer should only be started (or stopped) by A-side routines, and similarly for the B-side timer. To give you an idea of the appropriate increment value to use: a packet sent into the network takes an average of 5 time units to arrive at the other side when there are no other messages in the medium.
stoptimer(calling_entity)
where calling_entity is either 0 (for stopping the A-side timer) or 1 (for stopping the B
side timer).
tolayer3(calling_entity, packet)
where calling_entity is either 0 (for the A-side send) or 1 (for the B side send), and
packet is a structure of type pkt. Calling this routine will cause the packet to be sent into
the network, destined for the other entity.
tolayer5(calling_entity, data)
where calling_entity is either 0 (for A-side delivery to layer 5) or 1 (for B-side delivery to
layer 5), and data is a char array of size 20. With unidirectional data transfer, you would
only be calling this with calling_entity equal to 1 (delivery to the B-side). Calling this routine will cause data to be passed up to layer 5.
getwinsize()
returns the window size value passed as parameter to -w (see section 3.6).
get_sim_time()
returns the current simulation time.
3.6 The simulated network environment
A call to procedure tolayer3() sends packets into the medium (i.e., into the network layer).
Your procedures A_input() and B_input() are called when a packet is to be delivered from
the medium to your transport protocol layer. The medium is capable of corrupting and losing packets. However, it will not reorder packets. When you compile your procedures and our procedures together and run the resulting program, you will be asked to specify certain values regarding the simulated network environment as command-line arguments. We describe them below:
Seed (-s)
The simulator uses some random numbers to reproduce random behavior that a real network usually exhibits. The seed value (a non-zero positive integer) initializes the random number generator. Different seed values will make the simulator behave slightly differently and result in different output values.
Window size (-w)
This only applies to Go-back-N and Selective-Repeat binaries. Both these protocols use a finite-sized window to function. You need to tell the simulator beforehand what window size you want to use. In fact, your code will internally use this value for implementing the protocols.
Number of messages to simulate (-m)
The simulator (and your routines) will stop as soon as this number of messages has been passed down from Layer 5, regardless of whether or not all of the messages have been correctly delivered. Thus, you need not worry about undelivered or unACK'ed messages still in your sender when the simulator stops. This value should always be greater than 1. If you set this value to 1, your program will terminate immediately, before the message is delivered to the other side.
Loss (-l)
Specify a packet loss probability [0.0,1.0]. A value of 0.1, for example, would mean that one in ten packets (on average) are lost.
Corruption (-c)
You are asked to specify a packet corruption probability [0.0,1.0]. A value of 0.2, for example, would mean that one in five packets (on average) are corrupted. Note that the contents of payload, sequence, ack, or checksum fields can be corrupted. Your checksum should thus include the data, sequence, and ack fields.
Average time between messages from sender's layer5 (-t)
You can set this value to any non-zero, positive value. Note that the smaller the value you choose, the faster packets will be arriving at your sender.
Tracing (-v)
Setting a tracing value of 1 or 2 will print out useful information about what is going on inside the simulation (e.g., what's happening to packets and timers). A tracing value of 0 will turn this off. A tracing value greater than 2 will display all sorts of odd messages that are for our own simulator-debugging purposes. A tracing value of 2 may be helpful to you in debugging your code. You should keep in mind that, in reality, you would not have
A_timerinterrupt()
will be called when A's timer expires (thus generating a timer interrupt). Even though the protocol uses multiple logical timers, remember that you've only got one hardware timer , and may have many outstanding, unacknowledged packets in the medium. You will have to think about how to use this single timer to implement multiple logical timers. Note that an implementation that simply sets a timer every T time units and retransmits all the packets that should have expired within those time units is NOT acceptable. Your implementation has to ensure that each packet is retransmitted at the exact time at which it would be retransmitted if you had multiple timers.
5. Testing We will test your implementation of the three protocols with the settings/parameters described below. We will begin with the most basic tests and then move on to more involved tests (in the order mentioned below).
5.1 SANITY Tests
Here we perform two types of checks. (i) Check for duplicate and/or out-of-order packets at B. For each of the three protocols: Environment Settings Number of messages to simulate (-m): 1000 Average time between messages from sender's layer5 (-t): 50 Window size (-w): 10 Test Cases Loss (-l): 0.1, 0.2, 0.4, 0.6, 0.8, Corruption (-c): 0. Loss (-l): 0.0, Corruption (-c): 0.1, 0.2, 0.4, 0.6, 0. (ii) Confirm that the behavior of your protocols is the expected one under some very simple tests (e.g. no packets are delivered under 100% loss). For each of the three protocols: Environment Settings Number of messages to simulate (-m): 20 Average time between messages from sender's layer5 (-t): 1000 (ABT); 50 (GBN,SR) Window size (-w): 50 Test Cases Loss (-l): 0.0, Corruption (-c): 0. Loss (-l): 1.0, Corruption (-c): 0. Loss (-l): 0.0, Corruption (-c): 1.
5.2 BASIC Tests
For each of the three protocols:
Environment Settings Number of messages to simulate (-m): 20 Average time between messages from sender's layer5 (-t): 1000 (ABT); 50 (GBN,SR) Window size (-w): 50 Test Cases Loss (-l): {0.1, 0.4, 0.8}, Corruption (-c): 0. Loss (-l): 0.0, Corruption (-c): {0.1, 0.4, 0.8}
5.3 ADVANCED Tests
For each of the three protocols: Environment Settings Number of messages to simulate (-m): 1000 Average time between messages from sender's layer5 (-t): 50 Window size (-w): 10 Test Cases Loss (-l): {0.1, 0.2, 0.4, 0.6, 0.8}, Corruption (-c): 0. Loss (-l): 0.0, Corruption (-c): {0.1, 0.2, 0.4, 0.6, 0.8}
6. Analysis and Report For the analysis part, we provide you with a set of experiments (see section 6.1) to compare your implementation of the three different protocols’ performance, consisting of various loss probabilities, corruption probabilities, and window sizes. You need to present your results in a report as a file named groupnumber_assignment2.pdf. Please use the PA2 Report Template and share it with your teammates. The report should have the following statement right at the top:
I have read and understood the course’s academic integrity policy.
Your submission will NOT be graded without this statement. Even if you decide not to attempt the analysis part (section 6.1) of the assignment, you need to have a report file (with the name given above) with the following items: Academic integrity declaration mentioned above. Brief description of the timeout scheme you used in your protocol implementation and why you chose that scheme. Brief description (including references to the corresponding variables and data structures in your code) of how you implemented multiple software timers in SR using a single hardware timer. Screenshots of the results (the output of the grader) as required in section
5. You can just provide the overall result for each test. We expect you to use graphs to show your results for each of the experiments in 6.1 and then write down your observations. Further, your report, at the very least, should answer questions like: What variations did you expect for throughput by changing those parameters and why? Do you agree with your measurements; if not then why?
For example, your routines will need to keep a copy of a packet for possible retransmission. It would probably be a good idea for such a data structure to be a global variable in your code. Note, however, that if one of your global variables is used by your sender side, that variable should NOT be accessed by the receiving side entity, since, in real life, communicating entities connected only by a communication channel cannot share global variables. There is a float global variable called time that you can access from within your code to help you out with your diagnostics msgs. Start Simple Set the probabilities of loss and corruption to zero and test out your routines. Better yet, design and implement your procedures for the case of no loss and no corruption, and get them working first. Then handle the case of one of these probabilities being non-zero, and then finally both being non-zero. Debugging We'd recommend that you set the tracing level to 2 and put LOTS of printf() statements in your code while you are debugging your procedures. Random Numbers The simulator generates packet loss and errors using a random number generator. Our past experience is that random number generators can vary widely from one machine to another. You may need to modify the random number generation code in the simulator we have supplied you. Our simulation routines have a test to see if the random number generator on your machine will work with our code. If you get an error message: It is likely that random number generation on your machine is different from what this simulator expects. Please take a look at the routine jimsrand() in the simulator code. Sorry. then you'll know you'll need to look at how random numbers are generated in the routine jimsrand(); see the comments in that routine. However, to avoid inconsistency, we recommend you directly develop and test your code on the host in this case. Q&A from Kurose-Ross
1. My timer doesn't work. Sometimes it times out immediately after I set it (without waiting), other times, it does not time out at the right time. What's up? The timer code is OK (hundreds of students have used it). The most common timer problem I've seen is that students call the timer routine and pass it an integer time value (wrong), instead of a float (as specified). 2. You say that we can access your time variable for diagnostics, but it seems that accessing it in managing our timer interrupt list would also be useful. Can we use time for this purpose? Yes. 3. How concerned does our code need to be with synchronizing the sequence numbers between A and B sides? Does our B side code assume that Connection Establishment (three-way handshake) has already taken place, establishing the first packet sequence number? In other words, can we just assume that the first packet should always have a certain sequence number? Can we pick that number arbitrarily? You can assume that the three-way handshake has already taken place. You can hard-code an initial sequence number into your sender and receiver. 4. When I submitted my assignment I could not get a proper output because the program core dumped…. I could not figure out why I was getting a segmentation fault so …. Offhand I'm not sure whether this applies to your code, but it seems most of the problems with seg. faults in this assignment stemmed from programs that printed out char *'s without ensuring those pointed to null-terminated strings. (For example, the
messages -- packet payloads -- supplied by the network simulator were not null-terminated). This is a classic difficulty that trips up many programmers who've recently moved to C from a safer language.
8. Grading and Submission The grading will be done using a combination of automated tests (described in section 5) and a manual evaluation of your analysis report. For a detailed breakup of points associated with each command/function, see PA2 Template. For packaging and submission, see the section Packaging and Submission at CSE 4/589: PA2 Template.
