| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP Window Size Adjustment and Flow Control (Page 4 of 4) Closing the Send Window The process of window adjustment can continue, and of course, can be done by both deviceswe are just only considering the client-sends-to-server side of the equation here. If the server continues to receive data from the client faster than it can pump it out to the application, it will continue to reduce the size of its receive window. To continue our example above, suppose that after the send window is reduced to 80, the client sends a third request, this one 80 bytes in length, but the server is still busy. The server then reduces its window all the way down to 0, which is called closing the window. This tells the client the server is very overloaded, and it should stop routine sending of data entirely, as shown in the bottom third of Figure 226. Later on, when the server is less loaded down, it can increase the window size for this connection back up again, permitting more data to be transferred. While conceptually simple, flow control using window size adjustment can be very tricky. If we aren't careful about how we make changes to window size, we can introduce serious problems in the operation of TCP. There are also special situations that can occur, especially in cases where the window size is made small in response to a device becoming busy. The next two topics explore window management issues, as well as changes that need to be made to the basic sliding windows system to address them.
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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||