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