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.

The Book is Here... and Now On Sale!

The whole site in one document for easy reference!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)
      9  TCP/IP Transport Layer Protocols
           9  Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
                9  TCP/IP Transmission Control Protocol (TCP)
                     9  TCP Fundamentals and General Operation

Previous Topic/Section
TCP Data Handling and Processing: Streams, Segments and Sequence Numbers
Previous Page
Pages in Current Topic/Section
1234
5
6789
Next Page
TCP Ports, Connections and Connection Identification
Next Topic/Section

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):

  1. 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.

  2. 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.

  3. 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.

  4. 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, there’s 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 TCP’s 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.



Previous Topic/Section
TCP Data Handling and Processing: Streams, Segments and Sequence Numbers
Previous Page
Pages in Current Topic/Section
1234
5
6789
Next Page
TCP Ports, Connections and Connection Identification
Next Topic/Section

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!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.