The TCP/IP Guide - TCP Sliding Window Data Transfer and Acknowledgement 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.

Please Whitelist This Site?