Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
|
|
|
|
TCP Segment Retransmission Timers and the Retransmission Queue
(Page 1 of 3)
TCP's basic data transfer and acknowledgment
mechanism uses a set of variables maintained by each device to implement
the sliding
window acknowledgement system. These pointers
keep track of the bytes of data sent and received by each device, as
well as differentiating between acknowledged and unacknowledged transmissions.
In the preceding section I
described this mechanism, and gave a simplified example showing how
a client and server uses them for basic data transfer.
One of the reasons why that example
is simplified is that every segment that was transmitted by the server
was received by the client, and vice-versa. It would be nice if we could
always count on this happening, but as we know, in an Internet environment
this is not realistic. Due to any number of conditions, such as hardware
failure, corruption of an IP datagram or router congestion, a TCP segment
may be sent but never received. To qualify as a reliable transport protocol,
TCP must be able detect lost segments and retransmit them.
Managing Retransmissions Using the Retransmission Queue
The method for detecting lost segments
and retransmitting them is conceptually simple. Each time we send a
segment, we start a retransmission timer. This timer starts at
a predetermined value and counts down over time. If the timer expires
before an acknowledgment is received for the segment, we retransmit
the segment.
TCP uses this basic technique but
implements it in a slightly different way. The reason for this is the
need to efficiently deal with many segments that may be unacknowledged
at once, to ensure that they are each retransmitted at the appropriate
time if needed. The TCP system works according to the following specific
sequence:
- Placement On Retransmission Queue, Timer Start:
As soon as a segment containing data is transmitted, a copy of the segment
is placed in a data structure called the retransmission queue.
A retransmission timer is started for the segment when it is placed
on the queue. Thus, every segment is at some point placed
in this queue. The queue is kept sorted by the time remaining in the
retransmission timer, so the TCP software can keep track of which timers
have the least time remaining before they expire.
- Acknowledgment Processing: If an acknowledgment
is received for a segment before its timer expires, the segment is removed
from the retransmission queue.
- Retransmission Timeout: If an acknowledgment
is not received before the timer for a segment expires,
a retransmission timeout occurs, and the segment is automatically
retransmitted.
Of course, we have no more guarantee
that a retransmitted segment will be received than we had for the original
segment. For this reason, after retransmitting a segment, it remains
on the retransmission queue. The retransmission timer is reset, and
the countdown begins again. Hopefully an acknowledgment will be received
for the retransmission, but if not, the segment will be retransmitted
again and the process repeated.
Certain conditions may cause even
repeated retransmissions of a segment to fail. We don't want TCP to
just keep retransmitting forever, so TCP will only retransmit a lost
segment a certain number of times before concluding that there is a
problem and terminating the connection.
Key Concept: To provide basic reliability for sent data, each devices TCP implementation uses a retransmission queue. Each sent segment is placed on the queue and a retransmission timer started for it. When an acknowledgment is received for the data in the segment, it is removed from the retransmission queue. If the timer goes off before an acknowledgment is received the segment is retransmitted and the timer restarted. |
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |
|
|
Home -
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.
|