Connection Termination:

• Any of the two parties involved in exchanging data (client or server) can close the connection, although it is usually initiated by the client.

• Most implementations today allow two options for connection termination: three-way handshaking and four-way handshaking with a half-close option.

-86- 3-1 Three-Way Handshaking:

• Step 1: In a normal situation, the client TCP, after receiving a close command from the client process, sends the first segment, a FIN segment in which the FIN flag is set.

• Note that a FIN segment can include the last chunk of data sent by the client, or it can be just a control segment. If it is only a control segment, it consumes only one sequence number.

• Step 2: The server TCP, after receiving the FIN segment, informs its process of the situation and sends the second segment, a FIN +ACK segment, to confirm the receipt of the FIN segment from the client and at the same time to announce the closing of the connection in the other direction.

This segment can also contain the last chunk of data from the server. If it does not carry data, it consumes only one sequence number.

• Step 3: The client TCP sends the last segment, an ACK segment, to confirm the receipt of the FIN segment from the TCP server. This segment contains the acknowledgment number, which is 1 plus the sequence number received in the FIN segment from the server. This segment cannot carry data and consumes no sequence numbers.

3-2 Half-Close :

• In TCP, one end can stop sending data while still receiving data. This is called a half-close.

Although either end can issue a half-close, it is normally initiated by the client. It can occur when the server needs all the data before processing can begin.

• A good example is sorting. When the client sends data to the server to be sorted, the server needs to receive all the data before sorting can start. This means the client, after sending all the data, can close the connection in the outbound direction. However, the inbound direction must remain open to receive the sorted data.

• The server, after receiving the data, still needs time for sorting; its outbound direction must remain open.

-87-

• Step 1: The client half-closes the connection by sending a FIN segment.

• Step2: The server accepts the half-close by sending the ACK segment.

• Step 3: The data transfer from the client to the server stops. The server, however, can still send data. When the server has sent all the processed data, it sends a FIN segment, which is acknowledged (Step 4) by an ACK from the client.

• After half-closing of the connection, data can travel from the server to the client and acknowledgments can travel from the client to the server. The client cannot send any more data to the server.

• Note the sequence numbers we have used. The second segment (ACK) consumes no sequence number. Although the client has received sequence number y - 1 and is expecting y, the server sequence number is still y - 1.

• When the connection finally closes, the sequence number of the last ACK segment is still x, because no sequence numbers are consumed during transmission in that direction.

-88- 3- Flow Control

• TCP uses a sliding window to handle flow control.

• The sliding window protocol used by TCP, however, is something between the Go-Back-N and Selective Repeat sliding window.

• The sliding window protocol in TCP looks like the Go-Back-N protocol because it does not use NAKs.

• It looks like Selective Repeat because the receiver holds the out-of-order segments until the missing ones arrive.

• There are two big differences between this sliding window and the one we used at the data link layer. First, the sliding window of TCP is byte-oriented; the one we discussed in the data link layer is frame-oriented. Second, the TCP's sliding window is of variable size; the one we discussed in the data link layer was of fixed size.

• The sender window is always less than or equal to the receiver window.

• The window spans a portion of the buffer containing bytes received from the process. The bytes inside the window are the bytes that can be in transit; they can be sent without worrying about acknowledgment.

211 210 209 208 207 206 205 204 203 At the sender:

Next byte to be sent Size = receiver window

211 210 209 208 207 206 205 204 203 Bytes not

sent yet

Bytes ready to be immediately

sent

Bytes already sent but not acknowledged

Bytes sent and acknowledged At the sender:

-89- 3-1 Deciding the receiver window:

• The receiver window is variable. It depends on two factors: the size of the buffer and the processed bytes:

• Receiver window size = buffer size – unprocessed data.

• Example: What is the value of the receiver window (rwnd) for host A if the receiver, host B, has a buffer size of 5000 bytes and 1000 bytes of received and unprocessed data?

• Solution: The value of rwnd =5000 - 1000 = 4000. Host B can receive only 4000 bytes of data before overflowing its buffer. Host B advertises this value in its next segment to A.

3-2 Deciding the sender window:

• We know that the sender's window is always lesser than the receiver window. Yet, another factor must be taken in consideration: congestion. The sender can get information about congestion in the network and decide its window size.

• Sender window size = minimum (receiver window size, congestion window size).

3-3 Sliding the sender window:

• Once the receiver verifies the integrity of the received bytes, it sends an acknowledgement (could be piggybacked) to the sender with the number of the expected byte.

3-4 Expanding the sender window:

• If the receiver process consumes data faster than it receives, the size of the receiver window expands.

• In this case, the receiver updates the window size field in the TCP header with the new size and sends it to the sender in the next TCP segment.

211 210 209 208 207 206 205 At the sender:

Next byte to be sent 212

211 210 209 208 207 206 205 At the sender:

Next byte to be sent After receiving ACK expecting byte 205

-90- 3-5 Shrinking the sender window:

• If the receiver process consumes data slower than it receives, the size of the receiver window shrinks.

• In this case, the receiver updates the window size field in the TCP header with the new size and sends it to the sender in the next TCP segment.

• Shrinking is not recommended since some bytes can be revoked from being acknowledged:

3-2 Closing the sender window:

• If the buffer of the receiver is full, it sets the window size to be zero and informs the sender. In this case the sender recess sending bytes until receiving a non-zero window size.

4- Error Control:

• TCP is reliable: it handles error control using timers, acknowledgements and retransmissions.

• TCP has no negative acknowledgement.

• There are three cases

4-1 Lost or corrupted segment and lost acknowledgment:

• Once the receiver checks the integrity of a segment and finds it corrupted, it simply discards it.

• The sender sets a timer for each segment. If an acknowledgement is received for this segment or for any of its successors than the timer is destroyed and the segment is considered safe.

• If the timer goes off before receiving an acknowledgement, the sender consider that the segment was lost or corrupted. In this case, it retransmits the segment and sets its timer.

• On the other hand, if an acknowledgement is lost, then the sender's timer goes off and the corresponding segment is retransmitted.

4-2 Duplicate segment and acknowledgement:

• If an acknowledgement for a segment is delayed and arrived after retransmitting the segment, the sender consider it as the real acknowledgment, and ignore any other duplicates.

• In this case, the receiver also might receive a duplicate segment of bytes. Then, by checking the sequence number of the segment, it knows that it has been already acknowledged, so it simply discards it.

211 210 209 208 207 206 205 At the sender:

Next byte to be sent 212

This byte is revoked

-91- 4-3 Out-of-order segments:

• TCP used an unreliable IP service that guarantees no order of the transmitted datagrams.

• TCP handles this problem by delaying the acknowledgement of a segment until receiving its predecessors.

-92-