| 
 | 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 KozierokAuthor 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 Data Transfer and Acknowledgement Mechanics
 (Page 6 of 6)
 
 Real-World Complications of the Sliding Window Mechanism I'm sure this seems rather complicated, 
but in fact, the example is highly simplified, to show 
you how the basic data transfer mechanism works without too much going 
on. Scary, isnt it? J 
A real world connection would include several complications:  
Overlapping Transmissions: I intentionally 
showed only one request from the client and the response from the server. 
In reality, the client and server could be pumping many requests and 
responses at each other in rapid-fire succession; the client would be 
acknowledging segments received from the server with segments that themselves 
contained new requests, and so on. 
 
Acknowledgment of Multiple Segments: I 
also didn't show a case where two segments are received by a device 
and acknowledged with a single acknowledgment, though this can certainly 
happen. Suppose that in the example above, the two parts of the 280-byte 
file were sent at once and received by the client at the same time. 
The client would acknowledge both by sending a single segment with an 
Acknowledgment Number of 601. Remember, this field is a cumulative 
acknowledgment of all segments containing data through the number preceding 
it, so this would acknowledge all data up to byte 600.
 
Fluctuating Window Sizes For Flow Control: 
The window sizes in the example above remained constant, but in a real 
connection this will not always be the case. A very busy server may 
not be able to process and remove data from its buffer as fast as it 
acknowledges it. It may need to reduce its receive window to reduce 
the amount of data the client sends it, and then increase the window 
when more space becomes available. This 
is how TCP implements flow control.
 
Lost Transmissions: In a real connection, 
some transmitted segments will be lost and need to be retransmitted. 
This is handled by TCP's 
retransmission scheme.
 
Avoiding Small Window Problems: I hinted 
in the table above that we don't necessarily always want to send data 
as fast as we can, when it means we have to send a very small segment. 
The reason is that this can lead to performance degradation, including 
a phenomenon called silly 
window syndrome. This too will be explored 
in the section that follows, where we will see how handling it requires 
that we change 
the simple sliding windows scheme we have 
seen until the point.
 
Congestion Handling and Avoidance: The 
basic sliding window mechanism has been changed over the years to avoid 
having TCP connections cause internetwork congestion and to have them 
handle congestion when it is detected. Congestion issues are discussed, 
you guessed it, in 
the next 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! |  
|  | 
 | 
 
 
 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.
 |