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 Sliding Window Acknowledgment System For Data Transport, Reliability and Flow Control
(Page 5 of 9)
TCP's Stream-Oriented Sliding Window Acknowledgment System
So, does TCP use this variation on
PAR? Of course not! That would be too simple. Well, actually, the TCP
sliding window system is very similar to this method,
conceptually, which is why it is important for us to understand. However,
it requires some adjustment. The main reason has to do with the way
TCP handles data: the matter of stream orientation compared to
message orientation discussed
in the previous topic. The technique we
have outlined involves explicit acknowledgments and (if
necessary) retransmissions for messages. Thus, it would work well for
a protocol that exchanged reasonably large messages on a fairly infrequent
basis.
TCP, on the other hand, deals with
individual bytes of data as a stream. Transmitting each byte one at
a time and acknowledging each one at a time would quite obviously be
absurd. It would require too much work, and even with overlapped transmissions
(not waiting for an acknowledgment before sending the next piece of
data) the result would be horribly slow.
Of course, this is why TCP doesn't
send bytes individually, it divides them into segments. All of
the bytes in a segment are sent together and received together, and
thus acknowledged together. TCP uses a variation on the method we described
above, where the identification of data sent and acknowledged is done
using the
sequence numbers we discussed in the previous topic.
Instead of acknowledging using something like a message ID field,
we acknowledge data using the sequence number of the last byte of data
in the segment. Thus, we are dealing with a range of bytes
in each case, the range representing the sequence numbers of all the
bytes in the segment.
Conceptual Division of the TCP Transmission Stream Into Categories
Imagine a newly-established TCP connection
between Device A and Device B. Device A has a long
stream of bytes to be transmitted, but Device B can't accept
them all at once. So it limits Device A to sending a particular
number of bytes at once in segments, until the bytes in the segments
already sent have been acknowledged. Then Device A is allowed
to send more bytes. Each device keeps track of which bytes have been
sent and which not, and which have been acknowledged.
At any point in time we can take
a snapshot of the process. If we do, we can conceptually
divide the bytes that the sending TCP has in its buffer into four categories,
viewed as a timeline (Figure 206):
- Bytes Sent And Acknowledged:
The earliest bytes in the stream will have been sent and acknowledged.
These are basically accomplished from the standpoint of
the device sending data. For example, let's suppose that 31 bytes of
data have already been send and acknowledged. These would fall into
Category #1.
- Bytes Sent But Not Yet Acknowledged:
These are the bytes that the device has sent but for which it has not
yet received an acknowledgment. The sender cannot consider these accomplished
until they are acknowledged. Let's say there are 14 bytes here, in Category
#2.
- Bytes Not Yet Sent For Which Recipient
Is Ready: These are bytes that have not yet been sent, but which
the recipient has room for based on its most recent communication to
the sender of how many bytes it is willing to handle at once. The sender
will try to send these immediately (subject to certain algorithmic restrictions
we'll explore later). Suppose there are 6 bytes in Category #3.
- Bytes Not Yet Sent For Which Recipient
Is Not Ready: These are the bytes further down the stream
which the sender is not yet allowed to send because the receiver is
not ready. There are 44 bytes in Category #4.
Figure 206: Conceptual Division of TCP Transmission Stream Into Categories
|
Note: I am using very small numbers here to keep the example simple (and to make the diagrams a bit easier to construct!) TCP doesn't normally send tiny numbers of bytes around for efficiency reasons. |
The receiving device uses a similar
system to differentiate between data received and acknowledged, not
yet received but ready to receive, and not yet received and not yet
ready to receive. In fact, both devices maintain a separate set of variables
to keep track of the categories into which bytes fall in the stream
they are sending as well as the one they are receiving. This is explored
in the
topic describing the detailed sliding window data transfer procedure
(yes, theres even more on this subject!)
Key Concept: The TCP sliding window system is a variation on the enhanced PAR system, with changes made to support TCPs stream orientation. Each device keeps track of the status of the byte stream it needs to transmit by dividing them into four conceptual categories: bytes sent and acknowledged, bytes sent but not yet acknowledged, bytes not yet sent but that can be sent immediately, and bytes not yet sent that cannot be sent until the recipient signals that it is ready for them. |
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.
|