Flow control in computer networks is defined as the process of managing the rate of data transmission between two systems(nodes), this mechanism ensures that the rate of data (transmitted by the sender) is within the receiving capacity of the receiver node.
In the above diagram, we can see that there are two protocols, Stop & Wait and a sliding window. The basic difference between them is that, in stop & wait the sender node sends one frame and then waits for the feedback from the receiver node. On the other hand, in the sliding window protocol, the sender node keeps on sending frames to the receiver node without waiting for any feedback and it re-sends the frame which is/are damaged or suspected.
Talking about efficiency, the efficiency of the stop &wait protocol is less, while the efficiency of the sliding window protocol is more than the stop & wait protocol. And, in stop & wait protocol sorting is not necessary, but in sliding window protocol, sorting may or may not be necessary. The stop & wait protocol is half-duplex whereas the sliding window protocol is full-duplex.
Stop & Wait Protocol
The Stop and Wait protocol is a simple flow control mechanism used in computer networks. In this protocol, the sender transmits a single data frame and waits for an acknowledgment from the receiver before sending the next frame. The receiver acknowledges the receipt of each frame, allowing for reliable and sequential data transmission. This protocol ensures that data is delivered successfully, but it can be inefficient for high-latency networks as it introduces delays during the waiting period.
How Stop & Wait Works
The sender node sends a data packet to the receiver node.
Then, waits for the feedback of the transmitted packet.
As soon as the receiver node receives a data packet it starts processing it.
Then, the receiver node sends the feedback to the sender node (about the received data packet).
After receiving the feedback, if the feedback is positive then the sender node sends the next data packet otherwise resends the damaged packet.
Stop & Wait Protocol performs better for LANs than WANs because the efficiency of the protocol is inversely proportional to the distance between the sender & receiver node and as we all know that the distance is less in LANs as compared to WANs.
But this protocol has some issues, one such issue is the probability of occurrence of deadlock, which is very high due to loss in a data packet or loss in feedback which can lead to infinite waiting, where the sender will keep on sending the data packet if the feedback is lost.
Stop & Wait ARQ
Stop & Wait ARQ is a sliding window protocol for flow control and it overcomes the limitations of Stop & Wait, we can say that it is the improved or modified version of the Stop & Wait protocol.
Stop & Wait ARQ assumes that the communication channel is noisy (previously Stop & Wait assumed that the communication channel is not noisy). Stop & Wait ARQ also assumes that errors may occur in the data while transmission.
Working of Stop & Wait for ARQ
Working of Stop & Wait ARQ is almost like Stop & Wait protocol, the only difference is that it includes some additional components, which are:
Time out timer
Sequence numbers for data packets
Sequence numbers for feedback
Note: If any sliding window protocol must work properly then, the available sequence numbers must be greater than or equal to the sum of the sender window size and receiver window size.
[available sequence numbers >= sender window size + receiver window size]
Stop & Wait ARQ is a 1-bit sliding window protocol where the size of the sender window as well as the receiver window is 1. Thus, in Stop & Wait ARQ technique, the minimum number of sequence numbers required is equal to the sum of the sender window size & receiver window size
[minimum number of sequence numbers required = sender window size + receiver window size]
Thus, the minimum number of sequence numbers required in Stop & Wait ARQ is 2, which are 0 and 1.
Stop & Wait ARQ overcoming the problem of a lost data packet
For solving this problem, we use a time-out timer, after transmitting the data packet to the receiver through the communication channel, the sender starts the time-out timer. Now if the data packet's feedback is received by the sender before the timer expires, then the sender stops the timer and transmits the next data packet.
And if the time-out timer expires and the feedback is not received by the sender then, the sender retransmits the data packet. This prevents the occurrence of deadlock in the network.
An illustration of the process is shown in the image below.
The problem of lost Feedback
The problem of delayed/lost feedback(which used to happen in the Stop & Wait protocol) is solved by putting sequence numbers on data packets.
Assume that the feedback given by the receiver is lost, then the sender resends the same data packet after its timer expires. This prevents the occurrence of deadlock. The sequence number on the data packets helps the receiver to identify the duplicate data packet, then the receiver discards the duplicate data packet & resends the same feedback.
We can see the process in the image below
Now in the case of feedback delay, we can see in the image below
The problem of a damaged data packet
When it comes to data transmission in computer networks, one of the common challenges is the possibility of encountering damaged or corrupted data packets. This issue becomes particularly relevant when discussing flow control protocols like STOP & WAIT and STOP & WAIT ARQ (Automatic Repeat Request).
Imagine a scenario where a sender is transmitting a series of data packets to a receiver using the STOP & WAIT protocol. Each packet contains valuable information that needs to be accurately delivered. However, during transmission, a data packet becomes damaged due to noise, interference, or other factors present in the network.
In the basic STOP & WAIT protocol, without any error detection or retransmission mechanism, the receiver would be unaware of the damaged packet. The receiver would provide an acknowledgment to the sender, assuming the data was received correctly. As a result, the damaged packet remains undetected, leading to potential errors or inaccuracies in the received data.
This is where the enhanced STOP & WAIT ARQ protocol comes into play. Incorporating an acknowledgment mechanism and error detection capabilities, it allows the receiver to identify the damaged packet and request the sender to retransmit it. The sender, upon receiving this request, resends the packet, ensuring that the receiver obtains the correct data.
The inclusion of error detection and retransmission mechanisms in the STOP & WAIT ARQ protocol addresses the problem of damaged data packets. It provides a more robust and reliable approach to data transmission, as it actively detects and corrects errors, ensuring the accuracy and integrity of the received data.
Difference Between Stop & Wait and Stop & Wait ARQ
Here's a table comparing the Stop & Wait protocol and the Stop & Wait ARQ (Automatic Repeat Request) protocol:
| Stop & Wait Protocol | Stop & Wait ARQ Protocol | |
|---|---|---|
| Error Detection | No error detection mechanism | Incorporates error detection mechanism |
| Retransmission | No retransmission of lost or corrupted frames | Retransmits lost or corrupted frames |
| Efficiency | Less efficient due to waiting periods | More efficient due to error recovery capabilities |
| Data Integrity | No assurance of data integrity | Ensures data integrity through error detection |
| Latency | Can introduce significant delays | Can minimize delays through error recovery |
| Suitable for | Simple networks with low error rates | Networks with potential packet loss or errors |
| Reliability | Basic reliability for data transmission | Improved reliability through error recovery |
0 Comments