Simulation of TCP RDT 3.0 stop protocol (failed! )

< H2 > description < / H2 >

this is an assignment about the university computer network. The assignment requirement is to realize a reliable transmission simulation program according to the rdt 3.0protocol. The program is given by the teacher. Of course, this program is incomplete and needs to be modified and perfected. The code file that needs to be changed is altbit.c,. All other files are correct

. The

program will have four tests to check whether the program is completed. I have passed three tests, one of which failed, and I was puzzled. I hope the passing god will take a look at it and give me a report in the afterlife.

the amount of information is a little large.

the details are as follows (the original text is in English, but my translation is not good):

< H2 > background < / H2 >
You"ve been hired by "Net Source", a company specialising in networking software. Their programmer, Mue, who was working on an implementation of the Alternating Bit protocol has caught the flu and the implementation must absolutely be finished in the next week. Most of the implementation is complete and Mue left comments for parts still to be completed. As the code isn"t finished, Mue hasn"t completed testing yet.
Mue is an experienced C programmer and there is nothing wrong with the C syntax or structure of the code that Mue has written. So you don"t have to correct any C syntax errors, your job is to finish the code, correct any protocol errors and test it. Your boss realises you"re not a C expert, but at least you"ve programmed in some language with C like syntax (e.g. Java, CPP) before so you"re the closest they have as an expert. Mue has written a C hints for programmers of C like languages programmers sheet which explains what you need to know about C that is different than Java. She"s confident that if you stick to the sheet, anything else you need to add or change would be the same if you wrote it in Java.

you have been hired by a company that specializes in web software. Their programmer, Mue, is working to implement a bit interchange protocol that has contracted the flu and must be done next week. Most of the implementation is complete, and Mue leaves some parts that need to be done. Mue has not finished testing because the code is not yet complete. Mue is an experienced C language programmer, and the code he has written does not have any syntax or structural errors. So you don"t need to fix any C syntax errors, your job is to complete the code, correct some protocol errors and complete the test. Your boss realizes that you are not an experienced C language expert, but at least you have used a language similar to C syntax (such as java,cPP) before, so you are their closest expert. Mue has written a "C hints for programmers of C like languages programmers" article explaining that you need to know something about the difference between C and Java. He believes that when you write java, if you follow the instructions in the manual / documentation, whether you add or modify the code, it is a similar situation

.

[I will not put up the "C hints for programmers of C like languages programmers" mentioned here. I think the c language should be mastered.

< H2 > The testing system Test system < / H2 >
To help isolate and demonstrate the behaviour of the sender and receiver, you have a simulation system at your disposal. The overall structure of the environment is shown below:

to help isolate and demonstrate the behavior of the sender and receiver, you can use a simulation system. The overall structure of the environment is as follows

There are two hosts (A and B). An application on host A is sending messages to an application on host B.
The application messages (layer 5) on host A are sent to layer 4 (transport) on host A, which implements Alternating Bit for reliable delivery. Layer 4 creates packets and sends them to the network (layer 3). The network transfers (unreliably) these packets to host B where they are handed to the transport layer (Alternating Bit receiver) and if not corrupt or out of order, the message is extracted and delivered to the receiving application (layer 5) on host B.

ABABA5A44()()B(),,B(5)

Mue has supplied the code for the Alternating Bit sender procedures A_output(), A_init(), A_input(), and A_timerinterrupt(). She has also written the code for the Alternating Bit receiver procedures B_input() and B_init(). At this stage, only unidirectional transfer of data (from A to B) is required, so B does not need to implement B_timerinterrupt or B_output. Of course, B will have to send ACK packets to A to acknowledge receipt of data.

MueA_outputA_initA_inputA_timerinterruptB_inputB_initABB B_timerinterruptB_outputBAACK

The routines are detailed below. Such procedures in real-life would be part of the operating system, and would be called by other procedures in the operating system. In the simulator the simulator will call and be called by procedures that emulate the network environment and operating system.

A_output(message), where message is a structure of type struct msg, containing data to be sent to B. This routine will be called whenever the upper layer application at the sending side (A) has a message to send. It is the job of the Alternating Bit protocol to insure that the data in such a message is delivered in-order, and correctly, to the receiving side upper layer.

A_output(message), struct msgBA

A_input(packet), where packet is a structure of type struct pkt . This routine will be called whenever a packet sent from B (i.e., as a result of a tolayer3() being called by a B procedure) arrives at A. packet is the (possibly corrupted) packet sent from B.

A_input(packet),struct pktBtolayer3BAB

A_timerinterrupt() This routine will be called when A"s timer expires (thus generating a timer interrupt). This routine controls the retransmission of packets. See starttimer() and stoptimer() below for how the timer is started and stopped.

A_timerinterruptAstarttimerstoptimer

A_init() This routine will be called once, before any other A-side routines are called. It is used to do any required initialization.
A_init()a

B_input(packet), where packet is a structure of type struct pkt . This routine will be called whenever a packet sent from A (i.e., as a result of a tolayer3() being called by a A-side procedure) arrives at B. The packet is the (possibly corrupted) packet sent from A.

B_input(packet),struct pktA:tolayer3AB.A

B_init() This routine will be called once, before any other B-side routines are called. It is used to do any required initialization.

B_init()b

The unit of data passed between the application layer and the Alternating Bit (transport layer) protocol is a message, which is declared as:

:


That is, data is stored in a msg structure which contains an array of 20 chars. A char is one byte. The sending entity will thus receive data in 20-byte chunks from the sending application; and the receiving entity should deliver 20-byte chunks to the receiving application.

msg20char20;20
The unit of data passed between Alternating Bit (transport layer) and the network layer is the packet, which is declared as:
:


The A_output routine fills in the payload field from the message data passed down from the Application layer. The other packet fields are used by the Alternating Bit protocol to insure reliable delivery, as we"ve seen in class.

A_outputpayload

These functions implement what the sender and receiver should do when packets arrive.

Software Interfaces

The procedures described above implement the Alternating Bit tranport layer protocol. The following emulator procedures are called by the Alternating Bit procedures. They are explained here so you know how they fit in. They are not part of the Alternating Bit implementation and these routines work correctly. Do not modify them:

:

starttimer(calling_entity,increment), where calling_entity is either A (for starting the A-side timer) or B (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. You are free to experiment with different timeout values; but when handing in for mark submission linking, the timeout value must be set to 15.0

calling_entityAA-sideBBAAb:5;mark15.0

Note that starttimer() is not restarttimer(). If a timer is already running it must be stopped before it is started. Calling starttimer when the timer is already running, or calling stoptimer when the timer is not running, indicates an error in the protocol behaviour and will result in an error message.

starttimerrestarttimerstarttimerstoptimer

The starttimer() call should occur immediately after the tolayer3() call to send the packet being timed.

starttimertolayer3

stoptimer(calling_entity), where calling_entity is either A (for stopping the A-side timer) or B (for stopping the B side timer).

stoptimercalling_entitycalling_entity AABB

tolayer3(calling_entity,packet), where calling_entity is either A (for the A-side send) or B (for the B side send), and packet is a structure of type struct pkt. Calling this routine will cause the packet to be sent into the network, destined for the other entity.

tolayer3calling_entitypacketcalling_entityAABBpacketstruct pkt

tolayer5(calling_entity,message), where calling_entity is either A (for A-side delivery to layer 5) or B (for B-side delivery to layer 5), and message is a structure of type msg. With unidirectional data transfer, you would only be calling this with calling_entity equal to B (delivery to the B-side). Calling this routine will cause data to be passed up to layer 5.

calling_entityA5BB5msgcallingentityBB5

The emulator code is in the file emulator.c

emulator emulator.c

The incorrect implementation of Alternating Bit is in the file altbit.c

Alternating Bit()altbit.c

There are also two header files emulator.h and altbit.h

emulator.h altbit.h

which define the procedures and shared variables used in the program.
You should download the 4 files and examine the code in altbit.c with the description above and your knowledge of Alternating Bit and make sure you understand how the program fits together. You do not need to understand emulator.c; but if you want to know how the emulator works, you are welcome to look at the code.
To build the program use the command:

4altbitemulator.c;
:


The executable program will be called a.out. To run the program, type:

a.out:


The simulated network environment

The medium is capable of corrupting and losing packets. It will not reorder packets. When you compile and run the resulting program, you will be asked to specify values regarding the simulated network environment:

:

Number of messages to simulate.The emulator will stop generating messages as soon as this number of messages have been passed down from layer 5.

5

Loss. You are asked to specify a packet loss probability. A value of 0.1 would mean that one in ten packets (on average) are lost.
0.1101

Corruption. You are asked to specify a packet corruption probability. A value of 0.2 would mean that one in five packets (on average) are corrupted. Note that the contents of payload, sequence or ack field can be corrupted.

0.25ack

Tracing. Setting a tracing value of 1 or 2 will print out useful information about what is going on inside the emulation (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 messages that detail what is happening inside the emulation code as well. 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 underlying networks that provide such nice information about what is going to happen to their packets!

12022

Average time between messages from sender"s layer5. You can set this value to any non-zero, positive value. Note that the smaller the value you choose, the faster packets will be generated.

layer5

Take a moment to experiment with the simulated environment and look at the events that occur. Try sending a few packets with no loss or corruption. Does the protocol work properly? Try with just loss. Try with just corruption. Some of the errors with the Alternating Bit implementation should be apparent.

What to do

The implementation of Alternating Bit should be identical to that described in your book (page 244/245, Extended FSM description of Alternating Bit sender and receiver are shown).

244/245FSM

There may be errors in the protocol. You will need to test it. The errors are only in the altbit.c file. The other three files are correct and do not need to be modified. None of the mistakes are with the programming language or the data structures, they are all errors in the protocol behaviour. The program will compile and run as written; but the sender and receiver do not follow the Alternating Bit protocol.

altbit.c;

This part has 4 tests which test that you have correctly finished the code. Since mark submission link will show you what should have happened if you submit an incorrect solution,there is a 1 mark penalty for each submission you make after the first. You should test and correct any errors before submission. If you rely on mark submission link to do your testing, then your mark will reflect this. However, if you are really stuck, realise that this is a small percentage of the marks for each test, and the output should help clarify any misconception. We have provided an Oracle (see details below in the Handing In section) which will tell you if you pass the tests or not; but will give you no other information. There is no mark penalty to use the Oracle.

4mark1markOracle;Oracle

I suggest the following strategy for this practical. In each step I"d recommend focussing on getting the receiver behaving correctly first and then turn your attention to the sender (the receiver behaviour is simpler and therefore easier to get right and test). :

:

1.Compile the code and do a simple test sending just one packet with no corruption or loss. Does both the sender and receiver behave properly in this scenario? If not fix any problems. At this stage you should be able to pass test 1 (you can check with Oracle). If not, look at what your sender and receiver do in your test. (10 marks)

1OracleOracle(10)

2.Fill in the code items numbered 1. Now run some small tests with loss. Does your sender follow the protocol properly when a packet is lost? If not, fix the behaviour. You should now be able to pass test 2.(10 marks)

12(10)

3.Fill in the code items number 2 (check if ACK is a duplicate ACK) and 3 (B receives wrong sequence number or corrupt packet). When you have this correct you should be able to pass test 3. (20 marks)
2ACKACK3B3(20)

4.Fill in the code item numbered 4. Now run a small test with corruption. Do your sender and receiver detect corruption when it occurs and do they react correctly when a corrupted packet or ACK is received? You should now be able to pass test 4. (10 marks)

4ACK4(10)

altbit.h


altbit.c


emulator.h


emulator.c


oracletest124test3:

C
Mar.03,2021

answer your own questions:
at the suggestion of others, I put the judgment in the A_input function in
code altbit.c

.
if (packet.acknum!= A_nextseqnum)
Change

to

if (packet.acknum!= A_nextseqnum && windowcount>=WINDOWSIZE)

passed the test, but I don't know why
wants passers-by to know about
and I continue to think

.
Menu