Cached

1. Programming Assignment #2: Implementing a Reliable Transport Protocol (Go-Back-N) is for extra credit and is not required). Network properties: (although some can be lost). /. 4 (students' code). It contains the data (characters) to be delivered./. /. to layer 5 via the students transport level protocol entities.
2. Learn how to implement protocol (in this case Alternating Bit Protocol) using Socket. Learn how to write a socket program that implements a protocol entity, in our case the sender. Learn how to use select and set up timeout for retransmission when packets are lost.
3. The Alternating Bit Protocol Bartlett, 69 is an example used widely to illustrate the application of formal methods to protocols. It is assumed that the reader has some familiarity with this protocol so we will go directly to our particular model of it. The version being used is that described in Bochmann, 77.

The second example is the alternating bit protocol, a basic communica-tion protocol underlying many more advanced protocols. Because of simplicity of the framework of Kahn networks our implementation of this protocol turns out to be relatively lightweight. Our treatment is very much in uenced by 4. ABP: Alternating Bit Protocol Slide 15 CS3234 — Logic and Formal Systems — Lecture 07 — 07/10/04 The Alternating Bit Protocol ABP is a protocol for correctly trans-mitting data on faulty channels which may lose or duplicate data; ABP uses two faulty channels between a sender and a receiver.

Overview

In this programming assignment, you will be writing the sendingand receiving transport-level code for implementing a simple reliable datatransfer protocol. The basic assignment will be to implement the AlternatingBit Protocol; the extra credit assignment will be to implement a Go-Back-Nprotocol. This should be FUN since your implementation will differvery little from what would be required in a real-world situation.

Since we do not 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., thecode that would call your entities from above (i.e., from layer 5) andfrom below (i.e., from layer 3)) is very close to what is done in an actualUNIX environment. (Indeed, the software interfaces described in this programmingassignment are much more realistic that the infinite loop senders and receiversthat the text describes). Stopping/starting of timers are also simulated,and timer interrupts will cause your timer handling routine to be activated.

The desciption of the routines below is givenin C. See text at end regarding the Java version of this assignment.Note that you do not need a network connection to run this assignment,so you can do it pretty much on any machine you would like.

The routines you will write The procedures you will write arefor the sending entity (A) and the receiving entity (B). Only unidirectionaltransfer of data (from A to B) is required. Of course, the B side willhave to send packets to A to acknowledge (positively or negatively) receiptof data. Your routines are to be implemented in the form of the proceduresdescribed below. These procedures will be called by (and will call) proceduresthat I have written which emulate a network environment. The overall structureof the environment is shown in Figure 1:

The unit of data passed between the upper layers and your protocolsis a message, which is declared as:

See Full List On Cs.xu.edu

The unit of data passed between your routines and the network layeris the packet, which is declared as:

The routines you will write are detailed below. As noted above, suchprocedures in real-life would be part of the operating system, and wouldbe called by other procedures in the operating system.

A_output(message),

where message is a structure of type msg, containingdata to be sent to the B-side.

This routine will be called whenever the upper layer at the sendingside (A) has a message to send. It is the job of your protocol to insurethat the data in such a message is delivered in-order, and correctly, tothe receiving side upper layer.

A_input(packet),

where packet is a structure of type pkt.

This routine will be called whenever a packet sent from the B-side(i.e., as a result of a tolayer3() being done by a B-side procedure)arrives at the A-side. packet is the (possibly corrupted) packetsent from the B-side.

A_timerinterrupt()

This routine will be called when A's timer expires (thus generating a timerinterrupt). You'll probably want to use this routine to control the retransmissionof packets. See starttimer() and stoptimer() below forhow the timer is started and stopped.

A_init()

This routine will be called once, before any of your other A-side routinesare called. It can be used to do any required initialization.

B_input(packet),

where packet is a structure of type pkt.

This routine will be called whenever a packet sent from the A-side(i.e., as a result of a tolayer3() being done by a A-side procedure)arrives at the B-side. packet is the (possibly corrupted) packetsent from the A-side.

B_init()

This routine will be called once, before any of your other B-side routinesare called. It can be used to do any required initialization.

Software Interfaces

The procedures described above are the ones that you will write. I havewritten 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 floatvalue 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 similarlyfor the B-side timer.

To give you an idea of the appropriate increment value to use: a packetsent into the network takes an average of 5 time units to arrive at theother 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 (forthe 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,message),

where calling_entity is either 0 (for A-side delivery to layer5) or 1 (for B-side delivery to layer 5), and message is a structureof type msg. With unidirectional data transfer, you would onlybe calling this with calling_entity equal to 1 (delivery to theB-side).

Calling this routine will cause data to be passed up to layer 5.

A call to procedure tolayer3() sends packets into the medium(i.e., into the network layer). Your procedures A_input() andB_input()are called when a packet is to be delivered from the medium to your protocollayer.

The medium is capable of corrupting and losing packets. It will notreorder packets. When you compile your procedures and my procedures togetherand run the resulting program, you will be asked to specify values regardingthe simulated network environment:

• Number of messages to simulate. My emulator (and your routines)will stop as soon as this number of messages have been passed down fromlayer 5, regardless of whether or not all of the messages have been correctlydelivered. Thus, you need not worry about undelivered or unACK'edmessages still in your sender when the emulator stops.

Note that if you set this value to 1, your program will terminate immediately,before the message is delivered to the other side. Thus, this value shouldalways be greater than 1.
• Loss. You are asked to specify a packet loss probability. A valueof 0.1 would mean that one in ten packets (on average) are lost.
• Corruption. You are asked to specify a packet loss probability.A value of 0.2 would mean that one in five packets (on average) are corrupted.

Note that the contents of payload, sequence, ack, or checksum fieldscan be corrupted. Your checksum should thus include the data, sequence,and ack fields.
• Tracing. Setting a tracing value of 1 or 2 will print out usefulinformation about what is going on inside the emulation (e.g., what's happeningto packets and timers). A tracing value of 0 will turn this off. A tracingvalue greater than 2 will display all sorts of odd messages that are formy own emulator-debugging purposes.

A tracing value of 2 may be helpful to you in debugging your code.You should keep in mind that real implementors do not have underlyingnetworks that provide such nice information about what is going to happento their packets!
• Average time between messages from sender's layer5. You can setthis value to any non-zero, positive value. Note that the smaller the valueyou choose, the faster packets will be be arriving to your sender.

You are to write the procedures,A_output(),A_input(),A_timerinterrupt(),A_init(),B_input(),and B_init() which together will implement a stop-and-wait (i.e.,the alternating bit protocol, which we referred to as rdt3.0 on page 6-13of the class notes) unidirectional transfer of data from the A-side tothe B-side.Your protocol should use both ACK and NACK messages..

You should choose a very large value for the average time between messagesfrom sender's layer5, so that your sender is never called while it stillhas an outstanding, unacknowledged message it is trying to send to thereceiver. I'd suggest you choose a value of 1000. You should also performa check in your sender to make sure that when A_output() is called,there is no message currently in transit. If there is, you can simply ignore(drop) the data being passed to the A_output() routine.

You should put your procedures in a file called prog2.c. You will need the initial version of this file, containing my emulation routines, and the stubs for your procedures. Students should copy the version of prog2.c from the class web site.

This assignment can be completed on any machine supporting C. Itmakes no use of UNIX features. (You can simply grab the file from theclass sites and copy the file to whatever machine and OS you choose).

As always, you should hand in a code listing, a design document (asdescribed in the handout accompanying the first programming assignment),and sample output.

For your sample output, your procedures should print out a message wheneveran event occurs at your sender or receiver (a message/packet arrival, ora timer interrupt) as well as any action taken in response. You shouldhand in output for a run up to the point (approximately) when 10 messageshave been ACK'ed correctly at the receiver, a loss probability of 0.1,and a corruption probability of 0.3, and a trace level of 2. You shouldannotate your printout with a colored pen showing how your protocol correctlyrecovered from packet loss and corruption.

Make sure you read the ``helpful hints' for this assignment followingthe description of the extra credit assignment.

Extra Credit Assignment

You are to write the procedures,A_output(),A_input(),A_timerinterrupt(),A_init(),B_input(),and B_init() which together will implement a Go-Back-N unidirectionaltransfer of data from the A-side to the B-side, with a window size of 8.Your protocol should use both ACK and NACK messages. Consult the basicassignment above for information about how to obtain the network emulator.

Alternating Bit Protocol C Code

I would STRONGLY recommend that you first implement the basicassignment (Alternating Bit) and then extend your code to implement theextra-credit assignment (Go-Back-N). Believe me - it will not betime wasted! However, some new considerations for your Go-Back-N code (whichdo not apply to the Alternating Bit protocol) are:

Rather than have you worry about buffering an arbitrary number of messages,it will be OK for you to have some finite, maximum number of buffers availableat your sender (say for 50 messages) and have your sender simply abort(give up and exit) should all 50 buffers be in use at one point (Note:using the values I have given you below, this should never happen!) Inthe ``real-world,' of course, one would have to come up with a more elegantsolution to the finite buffer problem!

Simulation Of TCP RDT 3.0 Stop Protocol (Failed! ! ! ) – DDCODE

Consult the basic assignment above for a general description ofwhat to hand in. You should hand in output for a run that was long enoughso that at least 20 messages were successfully transfered from sender toreceiver (i.e., the sender receives ACK for these messages) transfers,a loss probability of 0.2, and a corruption probability of 0.2, and a tracelevel of 2, and a mean time between arrivals of 10. You should annotateparts of your printout with a colored pen showing how your protocol correctlyrecovered from packet loss and corruption.

Helpful Hints and the like

• Checksumming. You can use whatever approach for checksumming youwant. Remember that the sequence number and ack field can also be corrupted.I would suggest a TCP-like checksum, which consists of the sum of the (integer)sequence and ack field values, added to a character-by-character sum ofthe payload field of the packet (i.e., treat each character as if it werean 8 bit integer and just add them together).
• Note that any shared ``state' among your routines needs to be in the formof global variables. Note also that any information that your proceduresneed to save from one invocation to the next must also be a global (orstatic) variable. For example, your routines will need to keep a copy ofa packet for possible retransmission. It would probably be a good ideafor 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, thatvariable should NOT be accessed by the receiving side entity, sincein real life, communicating entities connected only by a communicationchannel can not share global variables.
• There is a float global variable called time that you can accessfrom within your code to help you out with your diagnostics msgs.
• START SIMPLE. Set the probabilities of loss and corruption to zeroand test out your routines. Better yet, design and implement your proceduresfor 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, andthen finally both being non-zero.
• Debugging. I'd recommend that you set the tracing level to 2 andput LOTS of printf's in your code while your debugging your procedures.
• Random Numbers.

The emulator generates packet loss and errors using a random numbergenerator. My past experience is that random number generators can varywidely from one machine to another. Some of you may need to modify therandom number generation code in my emulator. My emulation routines havea test to see if the random number generator on your machine will workwith my code. If you get an error message:

It is likely that random number generation on your machineis different from what this emulator expects. Please take a look at theroutine jimsrand() in the emulator code. Sorry.

then you'll know you'll need to look at how random numbers are generatedin the routine jimsrand(); see the comments in that routine.

• NetworkSimulator is an abstract class that is the bulk of the simulator.StudentNetworkSimulatoris the only class that you will have to modify.
• Packet, Message, Event, and EventListImpl are support classes. EventList is an interface. Project is the 'driver' for thewhole thing.
• You only need the .class files, and StudentNetworkSimulator.java. The other sources are there in case you are interested.
• StudentNetworkSimulator.java contains inline comments documentingthe interfaces of the other classes that you will need. These classfiles will need to be in the CLASSPATH (which will happen automaticallyif you edit and compile StudentNetworkSimulator.java in the same directoryas the other class files).

Reliable Data Transfer Protocol implementation in C++ using modified ALTERNATING BIT AND GO-BACK-N NETWORK EMULATORFROM VERSION 1.1 of J.F.Kurose as an assignment of Computer Networking Lab in Level-3, Term-2 of BUET.

Lab #7 – Programming: Reliable Transport - Alternating Bit

In this assignment sender and receiver implemented for two versions of RDT3.0 are implemented for only simplex data transfer:

• Alternating-bit protocol (ABP)
• Go-Back-N (GBN) with finite sequence numbers [0,7].

Alternating Bit Protocol C Programming

Additional Implementation:

• separate timers used for each packet in sender's window.
• another modified version of go-back-n is implemented which sends cumulative ack after certain timeout unlike normal gbn.

Detailed specifications can be found at 'offline_specification.pdf' in folder 'Assignment-Specifications'.

Simulation:

• compile and run rdt_abp.cpp to simulate Alternating-bit protocol.
• compile and run rdt_gbn.cpp to simulate Go-Back-N protocol.
• compile and run rdt_gbn_cumulative_ack.cpp to simulate Go-Back-N protocol with modified receiver.

This repo has been worked in CLion project and that's why CMakeLists.txt exists here.