A TCP connection has two endpoints, one at the source and one at the destination. Each endpoint is a socket, with a port number and IP address. Each TCP connection has a unique pair of sockets, but a single socket on a computer can have multiple connections, each to a different socket. For example, a computer’s port 80 can have connections to a number of remote computers at the same time. A pair of computers can have multiple connections to each other at the same time, as long as no two pairs of sockets are identical. To establish a connection, two computers must complete a 3-way handshake. Each communication in the handshake contains a TCP header. The computer that requests the connection is sometimes referred to as the TCP client, while the computer that receives the connection request is the TCP server. Once the connection has been established, either computer can transmit to the other at any time, although an application protocol may limit when the computers may transmit. Network article 5-3 shows typical communications in a handshake between two processes, the client and server, using the following communications: 1. The client initiates the handshake by sending a segment containing an initial sequence number. In the example, the sequence number is 100. The acknowledgment number is zero, the SYN bit is 1, and the ACK and FIN bits are zero. 2. The server waits to receive a connection request. On receiving the segment from the client, the server responds by sending a segment containing its own initial sequence number and an acknowledgment number equal to the received sequence number + 1. In the example, the segment’s sequence number is 500. The acknowledgment number is 101 (the received sequence number + 1). The SYN and ACK bits are 1, and the FIN bit is zero. 3. The client responds by sending a segment whose sequence number is 101, the received acknowledgment number.

Sending and Receiving Data

The client sends a segment with a sequence number of 101, an acknowledgment number of 501, an ACK bit of 1, a SYN bit of zero, and eight bytes of data in the data portion of the segment. The ACK and SYN bits don’t change for the remainder of the connection. The server acknowledges receiving the 8 bytes of data by sending a segment with a sequence number of 501 and an acknowledgment number of 109. The data portion of this segment may also contain new data to be sent to the client, which the client acknowledges in another segment. The segments sent when establishing a connection can include data as well. When this occurs, the destination must hold the received data until the connection is established.

A successful handshake tells the source computer that the data arrived at the destination computer’s TCP layer. There is still room for error, however, because the handshake can’t guarantee that the designated process at the destination computer received the data from the TCP layer. So to be absolutely sure that the destination’s application received the data, you need a protocol at the application layer to provide the acknowledgment.

Closing a Connection

Closing a connection also requires handshaking. To close a connection completely, each computer sends a segment with the FIN control bit set to 1 to indicate that the computer has no more data to send. Each destination must acknowledge receiving the FIN. Network article 5-5 shows an example:

1. The client sends a segment with the FIN control bit set to 1. This indicates that the client will send no more data over this connection. The client may continue to receive from the server.

2. The server sends a segment acknowledging the received FIN. If the server has no more data to send, it sets its FIN bit to 1. Otherwise, the server continues to send data and sets the FIN bit to 1 when all of the data has been sent.

3. The client sends a segment acknowledging the received FIN. The connection is now closed.

Of course, it’s possible that one of the computers will crash or be removed from the network before the closing handshake completes. In this case, the other computer may decide after a time to consider the connection closed and free the resources allocated to the connection.

Flow Control

A sending process may have multiple segments ready to send to a destination. Before sending each segment, the sending process could wait for an acknowledgment for the previous segment. But this isn’t the most efficient way to transfer data if the destination has room to store the data in more than one segment.

For more efficient transfers, the sending process can use a received header’s Window field to help determine how much data to send without waiting for an acknowledgment. The destination can adjust the size according to its current state by changing the contents of the Window field as needed in the headers it sends. A received acknowledgment number tells the sender that the destination received all of the data with segment numbers up to one less than the acknowledgment number. If the sender receives no acknowledgment, it can resend the data. Typically, on sending a segment, the source temporarily stores the segment’s data in a retransmission queue and starts a timer. On receiving an acknowledgment, the source deletes the data from the retransmission queue. If the source doesn’t receive an acknowledgment by the time the timer times out, the source assumes that the destination didn’t receive the segment and resends it, using the data in the retransmission queue. The amount of time to wait before resending can vary with the network. Hosts often use the average round-trip time for a transmission in determining a timeout value.

Enhancing Performance

Over time, several methods have come into popular use to help make TCP data transfers more efficient. The methods limit how much data a sender can send in some situations, and may also eliminate the need to wait for a timeout before retransmitting. The methods are Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC2581: TCP Congestion Control documents the methods. The methods all have to do with specifying the number of segments a source can transmit before receiving an acknowledgment. If a source waits for acknowledgment of the previous segment before sending the next segment, the source complies with the requirements of the approved and proposed standards. An embedded system that transfers data infrequently can use this simpler, if less efficient, approach.

Supporting TCP in Embedded Systems

Supporting TCP in an embedded system is more complicated than supporting UDP. In addition to adding and removing headers and supporting IP, the computer must perform the 3-way handshake to connect to a remote host, maintain sequence and acknowledgment numbers when exchanging data, handshake when closing a connection, and respond to detected errors. To send a message using TCP, a computer in an Ethernet network must do the following:

• Establish a connection using the 3-way handshake.

• Use the received Window size to determine how much data the remote computer can accept.

• Place the source and destination port numbers, sequence number, acknowledgment number, header length, source window size, and checksum in the appropriate locations in the TCP header. Computing the checksum requires knowing the source and destination IP addresses.

• Place the data to send in the data portion of the segment.

• Place the TCP segment in the data portion of an IP datagram. The IP datagram requires source and destination IP addresses and computing a checksum on the header.

• Pass the IP datagram to the Ethernet controller’s driver for sending on the network and start a timeout timer.

• Wait to receive an acknowledgment number that indicates that the remote computer received the data. If the acknowledgment doesn’t arrive before a timeout, resend the segment. To receive a datagram using TCP, a computer in an Ethernet network must do the following:

• Establish a connection using the 3-way handshake.

• Receive an IP datagram from the Ethernet controller’s driver.

• Strip the IP header from the datagram. Calculate the checksum and compare with the received value.

• If the checksums match, strip the header from the TCP segment. Calculate the checksum and compare it to the received value.

• Examine the received acknowledgment number to find out if the segment is acknowledging receipt of previously sent data and if so, delete the acknowledged data from the retransmission queue.

• Compare the received sequence number to the expected value. If the numbers match, set the acknowledgment number to return to the sender in a TCP segment.

• Use the destination port number to decide where to pass the data. In addition, at any time, either computer may request to close or reset the connection and the other computer should acknowledge the request and may request to close or reset the connection from the other end if appropriate.

As the examples at the beginning of the networking tutorial showed, if you’re using a module with TCP support, the details of creating the segments and dealing with the checksums and sequence and acknowledgment numbers are handled for you.