Processes and IPC

A process in the context of a general-purpose computing system is generally defined as[1]: 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:

[1] The definition becomes a little blurred in some multi-threaded environments: a thread is kind-of like 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.

[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.


Format of a TCP Segment

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


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:

TCP Connection Establishment

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.


This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #02.
[Previous Lecture] [Lecture Index] [Next Lecture]
Phil Scott