There are many ways to categorize the methods or manners of communication.
In other blog posts, we talked about Connection-Oriented and Connectionless Communication. Another way to categorize the various methods of communication is to divide these methods into the following groups.
- Reliable Communication, and
- Unreliable Communication.
Now, if we choose reliable or unreliable communication, I presume that most of us would select reliable communication.
However, if we truly understand the differences between these two forms of communication, then our choice may not be so obvious.
In other words, there is a role for both reliable and unreliable communication. There are applications in which it is actually better to use unreliable communication.
In this blog post, I will discuss reliable communication. I will discuss unreliable communication in another post.
What is Reliable Communication?
Let’s consider two Terminals (Terminal A and Terminal B) that are connected to each other.
Figure 1, Illustration of Terminal A and Terminal B Connected to Each Other.
In a Reliable Communication system, a Terminal will transmit a block of data (say, a packet or a frame) to the other Terminal.
Figure 2, Illustration of Terminal A sending Data Frame # 1 to Terminal B.
The Receiving Terminal (Terminal B in this case) will receive this frame and perform some error checking on this frame.
Figure 3, Illustration of the Receiving Terminal (Terminal B) processing and performing Error Checking on this frame that it has received from Terminal A.
Terminal A (the Sending Terminal) may also be halted for some time after sending this frame to Terminal B.
Figure 4, Illustration of Terminal A being “halted” after sending the Data Frame to Terminal B.
If the Receiving Terminal Detects No Errors within the Data Frame…
If Terminal B properly receives the Data Frame (with no errors or other problems), then it will send an Acknowledgment frame back out to Terminal A.
Figure 5, Illustration of Terminal B sending an Acknowledgment frame back out to Terminal A.
Once Terminal A (the Sending Terminal) receives this Acknowledgment Frame from Terminal B (the Receiving Terminal), it is no longer “halted” and can now send more frames.
Figure 6, Illustration of Terminal A being allowed to Send More Frames to Terminal B.
And this is the Essence of Reliable Communication.
The Essence of Reliable Communication
When everything works well, a Reliable Communication system will execute the following steps.
- The Sending Terminal sends a Data Frame.
- The Sending Terminal then HALTS and does not send any more frames (it is waiting for Acknowledgment frames from the Receiving Terminal).
- The Receiving Terminal processes this data frame (e.g., checks for Errors, Proper Sequence Numbers, etc.)
- If the Receiving Terminal determines that this frame is “GOOD,” it returns an acknowledgment frame to the Sending Terminal.
- The Sending Terminal is no longer HALTED and can now send more frames to the Receiving Terminal.
We discussed Reliable Communication when everything is working fine. Let’s talk about Reliable Communication when things are not so good.
Reliable Communication in the Presence of Frame Errors
Once again, Terminal A sends a Frame to Terminal B. I should also mention that Terminal A will start a timer (within its circuitry). I will explain why we have this timer as we work through this scenario.
NOTE: These Terminals will always start a timer whenever they send a data frame to the remote Terminal.
This is true, even during the Good Conditions that I described above. I’m mentioning the timer now because it will be important in our discussion shortly.
Figure 6, Illustration of Terminal A sending a Data Frame to Terminal B.
Once Terminal A sends this frame to Terminal B, as before, it will be halted until it gets an “Acknowledgement frame” from Terminal B.
However, in this case, Terminal B detects an error within the frame.
Figure 7, Terminal B detects an error within the frame.
Now, there are a variety of protocols that the Receiving Terminal can use to respond to this error.
Receiving Terminal Does not Send an Acknowledgement Frame during Error Conditions.
However, we assume that Terminal B does nothing in this case. In other words, it does not send an Acknowledgment frame back out to Terminal A.
In figure 8, Terminal B (after receiving an Errored Frame) does not return an Acknowledgment frame to Terminal A.
In this case, Terminal A is halted, but only for a limited amount of time. The timer (that we just introduced) will eventually expire.
When this timer expires, Terminal A will resend the Data Frame (that it already sent). In this case, Terminal A correctly assumes that Terminal B did not properly receive the data frame (from Terminal A). So, Terminal A resends this frame to ensure that Terminal B ultimately receives this frame.
Figure 9, Illustration of Terminal A resending Data Frame # 1 to Terminal B.
Once Terminal B receives this retransmission of Data Frame # 1, it checks this frame again.
Figure 10, Illustration of Terminal B checking the Retransmission of Data Frame # 1.
If Terminal B determines that the Retransmission of Data Frame # 1 contained no errors, then it will send an Acknowledgment back to Terminal A.
Figure 11, Illustration of Terminal B sending an Acknowledgement Frame back to Terminal A.
At this point, Terminal A is now “unhalted” and can proceed to transmit data frames (to Terminal B) again.
More Information about the Timer
I mentioned earlier that each Terminal contains a timer. I want to spend some time talking about this timer.
When a Terminal sends a Data Frame to the remote Terminal, in a reliable communication, the Terminal also starts a timer.
The timer will run until the Sending Terminal receives an acknowledgment frame from the remote Terminal.
If the remote Terminal does not send the Acknowledgment frame, the timer will eventually expire and command the Sending Terminal to retransmit the same Data Frame.
On the other hand, if the Sending Terminal does receive an Acknowledgment frame (from the remote Terminal) before the timer expires, it will stop the timer.
The Sending Terminal will only restart the timer whenever it sends another data frame to the remote Terminal.
Let’s Once Again Review the Essence of Reliable Communication
- The Sending Terminal sends a Frame to the remote Terminal.
- The remote (or Receiving Terminal) checks the Frame.
- If the Receiving Terminal determines that the Data Frame is OK, it will send an Acknowledgment frame back out to the Sending Terminal.
- If the Receiving Terminal determines that the Data Frame is NOT OK, it will NOT send an Acknowledgement frame back out to the Sending Terminal.
- If the Sending Terminal receives an Acknowledgment frame from the Receiving Terminal, it it no longer halted and can send more frames to the Receiving Terminal.
- On the other hand, if the Sending Terminal does not receive an Acknowledgment frame (from the Receiving Terminal) and the timer (within the Sending Terminal’s circuitry) expires, the Sending Terminal will retransmit the Data Frame that it was trying to send.
Applications Using Reliable Communication
- File Transfer Protocol
- Any service that transmits/receives a large amount of data (files)
- Data Storage Applications and Servers
We will discuss unreliable communication in another post.
