Subjects -> Computer Networks -> Lectures -> Lecture #03

Lecture 3: The TCP Protocol

Processes and IPC

A process in the context of a general-purpose computing system is generally defined as^[1]:

A program which is currently in execution (ie, running), including:
- the instantaneous value of all of its variables (in memory and registers)
- the "current" value of its program counter , etc

Note that we also sometimes use the term application instead of process -- and even application process is sometimes used. They're basically all equivalent to one another.

Inter-Process Communications (IPC) occurs when a process "talks to" another process. Apart from TCP-based IPC, there have historically been many other flavours of IPC:

Shared files (only useful where two process share a common filesystem)
Unix pipes (only useful between process which have a common "parent process")
Others: shared memory, named pipes, message passing, remote procedure call, etc.

^[1] The definition becomes a little blurred in some multi-threaded environments (eg, Java): a thread is kind-of a "light weight" process. We ignore threads for the moment.

The Transmission Control Protocol (TCP)

In the Internet, Inter-Process Communications is implemented using the TCP "transport-layer" protocol. TCP provides an "end-to-end" (or point-to-point) IPC service which is:

reliable: all data is delivered correctly, without errors, even though the underlying delivery service may be unreliable -- see later.
connection-oriented: the protocol provides procedures for establishing and concluding interprocess connections.
byte stream: ie, no visible packetisation so far as the application processes are concerned
full duplex: data can flow in either direction over an established connection, without restriction.

TCP is widely regarded as the best transport protocol ever developed, and has no serious competitors.

TCP Operation

In order to provide reliable, connection oriented service, TCP breaks the incoming application byte stream into segments. The maximum size of a segment is called the MSS.

A segment consists of a header, and some data. The last data byte in each segment is identified with a 32-bit byte count field in the segment header.

When a segment is received correct and intact, a special acknowledgement segment is returned to the sending TCP containing the byte count of the last byte correctly received.
The network service can fail to deliver a segment. If the sending TCP waits for too long^[2] for an acknowledgment, it times out and resends the segment, on the assumption that the datagram has been lost.
The network can potentially deliver duplicated segments, and can deliver segments out of order. TCP buffers or discards out of order or duplicated segments appropriately, using the byte count for identification.

^[2] The TCP timeout algorithm uses observed round trip times, and measures of their variability, to calculate a continuously updated best estimate of when to resend. See the tutorial for a discussion on this.

Format of a TCP Segment

A segment consists of a 20-byte header and (optionally) some data, thus:

Note:

Port numbers define the process from which this segment was sent, and the destination process -- see later.
Sequence Numbers identify last byte of data sent and received.

Reliable Transmission

We can visualise the successful transmission of a TCP segment as follows:

If a segment is lost in the network, the sender times out and re-transmits, thus:

TCP Port Numbers

TCP provides an interprocess delivery system, so it needs to identify processes in the two "end systems" which it connects.

To do this, it defines an abstract address called a port number. Two processes can communicate by agreeing on the port numbers they will use for communications. Port numbers are the addresses of the TCP protocol -- each segment contains port numbers for each of the sending and receiving processes.

In order to set up a TCP connection, a process notifies the TCP software that it is waiting for connections "at" a certain port number. By definition, such a process is called a server. A client process which needs to connect to the server asks its local TCP software to allocate an unused port number and establish the connection. Once the connection is established, the two processes can communicate.

In order to manage TCP connections, a group of port numbers (0 to 1023) have been defined to be used by processes providing well known services. Most Unix systems provide server processes corresponding to all the well-known services.

TCP Servers and Clients

Initially:

Note that the port number is used to name processes. Because the client establishes communication, it does not need a well-known port number, and so an unused one (> 1023) is randomly allocated by the TCP software, eg:

Optional Topic: TCP Connections

The connection phase in TCP uses a 3-way handshake of control segments:

The 3-way handshake is necessary because TCP is layered on the unreliable datagram service provided by IP, so that these control segments can be lost, duplicated or delivered out of order.

This could lead to trouble if original or retransmitted segments arrive while the connection is being established - the handshake used overcomes this problem.

A TCP connection is closed using another (modified) 3-way handshake sequence involving the use of FIN control segments. An interesting consequence of the full-duplex nature of TCP, and the concept of graceful close is that a TCP connection can be half-open if one side closes the connection and the other does not.

The tutorial for this lecture is Tutorial #03.
La Trobe Uni Logo

[Previous Lecture] [Lecture Index] [Next Lecture]