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.
[Previous Lecture]
[Lecture Index]
[Next Lecture]
Copyright © 2001 by
Philip Scott,
La Trobe University.