Connection-Oriented Transport - TCP

Connection-Oriented Transport - TCP

We have studied the underlying principles of reliable data transfer, let's examine TCP - the Internet's transport-layer, connection-oriented, reliable transport protocol. In this section, we'll see that in order to provide reliable data transfer, TCP relies on many of the underlying principles explained in the previous section, including error detection, retransmissions, cumulative acknowledgments, timers, and header fields for sequence and acknowledgment numbers.

The TCP Connection

TCP is considered connection-oriented because before one application process can begin to send data to another, the two processes must first "handshake" with each other - that is, they must send some preliminary segments to each other to establish the parameters of the ensuing data transfer. As part of TCP connection establishment, both sides of the connection will initialize many TCP state variables (many of which will be explained in this section and in "TCP Congestion Control") associated with the TCP connection.

The TCP "connection" is not an end-to-end TDM or FDM circuit as in a circuit-switched network. Nor is it a virtual circuit (see "Computer Networks and the Internet"), as the connection state resides entirely in the two end systems. Because the TCP protocol runs only in the end systems and not in the intermediate network elements (routers and link-layer switches), the intermediate network elements do not maintain TCP connection state,

VINTON CERF, ROBERT KAHN

In reality, the intermediate routers are completely oblivious to TCP connections; they see datagrams, not connections.

A TCP connection provides a full-duplex service: If there is a TCP connection between Process A on one host and Process B on another host, then application-layer data can flow from Process A to Process B at the same time as application-layer data flows from Process B to Process A. A TCP connection is also always point-to-point, that is, between a single sender and a single receiver. So-called "multicasting" - the transfer of data from one sender to many receivers in a single send operation - is not possible with TCP. With TCP, two hosts are company and three are a crowd.

Let's now take a look at how a TCP connection is established. Suppose a process running in one host wants to initiate a connection with another process in another host. Recall that the process that is initiating the connection is called the client process, while the other process is called the server process. The client application process first informs the client transport layer that it wants to establish a connection to a process in the server. Recall from "Socket Programming with TCP", a Java client program does this by issuing the command



where hostname is the name of the server and portNumber identifies the process on the server. The transport layer in the client then proceeds to establish a TCP connection with the TCP in the server. At the end of this section we discuss in some detail the connection-establishment procedure. For now it suffices to know that the client first sends a special TCP segment; the server responds with a second special TCP segment; and finally the client responds again with a third special segment. The first two segments carry no payload, that is, no application-layer data; the third of these segments may carry a payload. Because three segments are sent between the two hosts, this connection-establishment procedure is often referred to as a three-way handshake.

Once a TCP connection is established. the two application processes can send data to each other. Let's look at the sending of data from the client process to the server process. The client process passes a stream of data through the socket (the door of the process), as described in "Socket Programming with TCP". Once the data passes through the door, the data is now in the hands of TCP running in the client. As shown in Figure 1, TCP directs this data to the connection's send buffer, which is one of the buffers that is set aside during the initial three-way handshake. From time to time, TCP will grab chunks of data from the send buffer. Interestingly, the TCP specification is very laid  back about specifying when TCP should actually send buffered data, stating that TCP should "send that data in segments at its own convenience". The maximum amount of data that can be grabbed and placed in a segment is limited by the maximum segment size (MSS). The MSS is typically set by first determining the length of the largest link-layer frame that can be sent by the



Iocal sending host (the so-called maximum transmission unit, MTU), and then setting the MSS to ensure that a TCP segment (when encapsulated in an IP datagram) will fit into a single link-layer frame. Common values for the MTU are 1,460 bytes, 536 bytes, and 512 bytes. Approaches have also been proposed for discovering the path MTU - the largest link-layer frame that can be sent on all links from source to destination - and setting the MSS based on the path MTU value. Note that the MSS is the maximum amount of application-layer data in the segment, not the maximum size of the TCP segment including headers. (This terminology is confusing, but we have to live with it, as it is well entrenched).

TCP pairs each chunk of client data with a TCP header, thereby forming TCP segments. The segments are passed down to the network layer, where they are separately encapsulated within network-layer IP datagrams. The IP datagrams are then sent into the network. When TCP receives a segment at the other end. the segment's data is placed in the TCP connection's receive buffer, as shown in Figure 1. The application reads the stream of data from this buffer. Each side of the connection has its own send buffer and its own receive buffer.

We see from this discussion that a TCP connection consists of buffers, variables, and a socket connection to a process in one host, and another set of buffers, variables, and a socket connection to a process in another host. As mentioned earlier, no buffers or variables are assigned to the connection in the network elements (routers, switches, and repeaters) between the hosts.


Tags

data transfer, virtual circuit, end systems, routers, datagrams, client process, server process

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.