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!

Enjoy The TCP/IP Guide? Get the complete PDF!
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 Message Formatting and Data Transfer

Previous Topic/Section
TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size
Previous Page
Pages in Current Topic/Section
1234
5
6
Next Page
TCP Immediate Data Transfer: "Push" Function
Next Topic/Section

TCP Sliding Window Data Transfer and Acknowledgement Mechanics
(Page 5 of 6)

Example Illustration of TCP Sliding Window Mechanics

To see how all of this works, let's consider the example of a client and server using a mythical file retrieval protocol. This protocol specifies that the client sends a request and receives an immediate response from the server. The server then sends the file requested when it is ready.

The two devices will of course first establish a connection and synchronize sequence numbers. For simplicity, let's say the client uses an initial sequence number (ISN) of 0, and the server an ISN of 240. The server will send the client an ACK with an Acknowledgement Number of 1, indicating it is the sequence number it expects to receive next. Let's say the server's receive window size is set to 350, so this is the client's send window size. The client will send its ACK with an Acknowledgment Number of 241. Let's say its receive window size is 200 (and the server's client window size is thus 200). Let's assume that both devices maintain the same window size throughout the transaction. This won't normally happen, especially if the devices are busy, but the example is complicated enough. Let's also say the maximum segment size is 536 bytes in both directions. This means that the MSS won’t affect the size of actual segments in this example (since the MSS is larger than the send window sizes for both devices.)

With the background for our example established, we can now follow a sample transaction to show in detail how the send and receive pointers are created and changed as messages are exchanged between client and server. Table 159 describes the process in detail, showing for each step what the send and receive pointers are for both devices. It is rather large, so beware. J The transaction is also graphically illustrated in two figures: Figure 221 and Figure 222. Both illustrate the same exchange of messages, using the step numbers of Table 159, but each from the perspective of one of the devices. Figure 221 shows the server’s send pointers and client’s receive pointers; Figure 222 shows the client’s send pointers and server’s receive pointers. (I would have put them all in one diagram but it wouldn’t fit!)


Table 159: TCP Transaction Example With Send and Receive Pointers

Client

 

Server

Process Step

SND.UNA

SND.NXT

SND.WND

RCV.NXT

RCV.WND

 

Process Step

SND.UNA

SND.NXT

SND.WND

RCV.NXT

RCV.WND

Description

 

Description

(setup)

1

1

360

241

200

 

(setup)

241

241

200

1

360

During connection establishment, the client sets up its pointers based on the parameters exchanged during setup. Notice that the SND.UNA and SND.NXT values are the same — no data has been sent yet so nothing is unacknowledged. RCV.NXT is the value of the first byte of data expected from the server.

The server sets up its pointers just as the client does. Notice how its values are the complement of the client's.

1. Send Request

1

141

360

241

200

 

(wait)

241

241

200

1

360

The client transmits a request to the server. Let's say the request is 140 bytes in length. It will form a segment with a data field of this length and transmit it with the Sequence Number set to 1, the sequence number of the first byte. Once this data has been sent, the client's SND.NXT pointer will be incremented to the value 141 to indicate this is the next data to be sent to the server.

The server does nothing, waiting for a request.

(wait)

1

141

360

241

200

 

2. Receive Request, Send Ack & Reply

241

321

200

141

360

At this point the client hasn't received an acknowledgment for its request. At present, SND.UNA+SND.WND is 361, while SND.NXT is 141. This means the current usable window is 220 bytes. The the client could send up to 220 more bytes of data before getting back an acknowledgment. For now, let's say it has nothing more to transmit.

The server receives the 140-byte request from the client. The server sends back an 80-byte response that also acknowledges the client's TCP segment. The Sequence Number field will be 241, the first sequence number of the server's 80 bytes of data. The Acknowledgment Number will be 141, telling the client that is the next sequence number the server expects to hear, and thereby implicitly acknowledging receipt of bytes 1 through 140.

The server increases its RCV.NXT pointer to 141 to reflect the 140 bytes of data received. It increases its SND.NXT pointer by 80.

3. Receive Ack & Reply, Send Ack

141

141

360

321

200

 

4. Send Part 1 of File

241

441

200

141

360

The client receives the server's response. It sees the Acknowledgment Number of 141 and knows bytes 1 to 140 were successfully received. It increases its SND.UNA to 141, effectively “sliding the send window” by 140.

The client also accepts the 80 bytes of data the server sent, increasing its RCV.NXT pointer by 80. Assuming it has no more data to sent, it sends back a TCP segment that is a pure acknowledgment of the server's response. This segment has no data, and an Acknowledgment Number value of 321.

While the client was receiving its response, the server's TCP was supplied with a 280 byte file to be sent to the client. It cannot send this all in one segment however. The current value of SND.UNA+SND.WND is 441, while SND.NXT is 321. Thus, the server's usable window contains 120 bytes of data. It creates a TCP segment with this much data and a Sequence Number of 321. It increases the SND.NXT pointer to 441. The server has now filled the send window.

Note that the server does not have to wait for an acknowledgement to the reply it sent in step #2. This is a key factor in TCP’s ability to ensure high throughput.

5. Receive Part 1 of File, Send Ack

141

141

360

441

200

 

6. Receive Ack for Reply

321

441

200

141

360

The client receives the first 120-byte part of the file the server was sending. It increases the RCV.NXT pointer to 441 and sends an acknowledgment back with an Acknowledgment Number of 441. Again, if it had another request to make of the server it could include it here, but we'll assume it does not.

The server receives the client's acknowledgment of its earlier 80-byte response (sent in step #2). It increases its SND.UNA to 321. Since it just received acknowledgment of 80 bytes (and the client's window didn't change), the server's usable window is now 80 bytes. However, as we will see in the section on TCP performance, sending small segments like this can lead to performance issues. Let's say the server has been programmed to not send segments under 100 bytes when it has a lot of data to transmit. It decides to wait.

(wait)

141

141

360

441

200

 

7. Receive Ack for Part 1 of File

441

441

200

141

360

The client waits for the rest of the file.

The server receives the acknowledgment for the first part of the file. It increases SND.UNA to 441. This now restores the full 200 byte window.

(still waiting J)

141

141

360

441

200

 

8. Send Part 2 of File

441

601

200

141

360

The client continues to wait for the rest of the file.

The server sends the remaining 160 bytes of data in the file in one segment. It increases SND.NXT by 160, and sends the data with a Sequence Number value of 441.

9. Receive Part 2 of File, Send Ack

141

141

360

601

200

 

(wait)

441

601

200

141

360

The client receives the rest of the file and acknowledges it. It increases RCV.NXT to 601 and sends back a segment with an Acknowledgment Number of 601.

The server is done for now; it waits for the acknowledgment of the second part of the file.

(done)

141

141

360

601

200

 

10. Receive Ack for Part 2 of File

601

601

200

141

360

The client is done with this exchange.

The server receives the second acknowledgment and slides its send window forward by 160 bytes. The transaction is now completed.



Figure 221: TCP Transaction Example Showing Server’s Send Pointers

The transaction of Table 159 from the perspective of the server. See Figure 222 for the client’s pointers.

 



Figure 222: TCP Transaction Example Showing Client’s Send Pointers

The transaction of Table 159 from the perspective of the client. See Figure 221 for the server’s pointers.

 


Previous Topic/Section
TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size
Previous Page
Pages in Current Topic/Section
1234
5
6
Next Page
TCP Immediate Data Transfer: "Push" Function
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.