TCP/IP Processes, Multiplexing and Client/Server

Application Roles
(Page 2 of 3)

Multiplexing and Demultiplexing

Most communication in TCP/IP takes the form of exchanges of information between a

program running on one device, and a matching program on another device. Each
instance of an application represents a copy of that application software that needs to
send and receive information. These application instances are commonly called
processes. A TCP/IP application process is any piece of networking software that sends
and receives information using the TCP/IP protocol suite. This includes both “classic”
end-user applications such as the ones described above, as well as support protocols
that behave as applications when they send messages. Examples of the latter would
include a network management protocol like SNMP, or even the routing protocol BGP
(which sends messages using TCP like an application does).

So, a typical TCP/IP host has multiple processes each needing to send and receive
datagrams. All of them, however, must be sent using the same interface to the
internetwork, using the IP layer. This means that the data from all applications (with
some possible exceptions) is “funneled down”, initially to the transport layer, where it is
handled by either TCP or UDP. From there, messages pass to the device's IP layer,
where they are packaged in IP datagrams and sent out over the internetwork to different
destinations. The technical term for this is multiplexing. This term simply means
combining, and its use here is a software analog to the way it is done with signals.

A complementary mechanism is responsible for receipt of datagrams. At the same time

that the IP layer multiplexes datagrams from many application processes to be sent out,
it receives many datagrams that are intended for different processes. The IP layer must
take this stream of unrelated datagrams, and eventually pass them to the correct
process (through the transport layer protocol above it). This is the reverse of
multiplexing: demultiplexing. You can see an illustration of the basic concept behind
TCP/IP process multiplexing and demultiplexing in Figure 197.
 Figure 197: Process Multiplexing and Demultiplexing In TCP/IP

In a typical machine running TCP/IP there are many different protocols and applications
running simultaneously. This example shows four different applications communicating
between a client and server machine. All four are multiplexed for transmission using the
same IP software and physical connection; received data is demultiplexed and passed
to the appropriate application. IP, TCP and UDP provide the means of keeping distinct
the data from each application.

Key Concept: TCP/IP is designed to allow many different applications to send and
receive data simultaneously using the same Internet Protocol software on a given
device. To accomplish this it is necessary to multiplex transmitted data from many
sources as it is passed down to the IP layer. As a stream of IP datagrams is received, it
is demultiplexed and the appropriate data passed to each application software instance
on the receiving host.
In this section we discuss the multiplexing/demultiplexing of messages by the transport layer
from/to the application layer. In order to keep the discussion concrete, we'll discuss this basic
service in the context of the Internet's transport layer. We emphasize, however, that multiplexing
and demultiplexing services are provided in almost every protocol architecture ever designed.
Moreover, multiplexing/demultiplexing are generic services, often found in several layers within
a given protocol stack.

Although the multiplexing/demultiplexing service is not among the most exciting services that
can be provided by a transport layer protocol, it is an absolutely critical one. To understand why
it so critical, consider the fact that IP delivers data between two end systems, with each end
system identified with a unique IP address. IP does not deliver data between the application
processes that run on these end systems. Extending host-to-host delivery to a process-to-process
delivery is the job of the transport layer's application multiplexing and demultiplexing service.

At the destination host, the transport layer receives segments (i.e., transport-layer PDUs) from
the network layer just below. The transport layer has the responsibility of delivering the data in
these segments to the appropriate application process running in the host. Let's take a look at an
example. Suppose you are sitting in front of your computer, and you are downloading Web pages
while running one FTP session and two Telnet sessions. You therefore have four network
application processes running -- two Telnet processes, one FTP process, and one HTTP process.
When the transport layer in your computer receives data from the network layer below, it needs
to direct the received data to one of these four processes. Let's now examine how this is done.

Each transport-layer segment has a field that contains information that is used to determine the
process to which the segment's data is to be delivered. At the receiving end, the transport layer
can then examine this field to determine the receiving process, and then direct the segment to
that process. This job of delivering the data in a transport-layer segment to the correct application
process is called demultiplexing. The job of gathering data at the source host from different
application processes, enveloping the data with header information (which will later be used in
demultiplexing) to create segments, and passing the segments to the network layer is called
multiplexing.

To illustrate the demultiplexing job, let us return to the household saga in the previous section.
Each of the kids is distinguished by his or her name. When Bob receives a batch of mail from
the mail person, he performs a demultiplexing operation by observing to whom the letters are
addressed and then hand delivering the mail to his brothers and sisters. Alice performs a
multiplexing operation when she collects letters from her brothers and sisters and gives the
collected mail to the mail person.

UDP and TCP perform the demultiplexing and multiplexing jobs by including two special fields
in the segment headers: the source port number field and the destination port number field.
These two fields are illustrated in Figure 3.2-1. When taken together, the fields uniquely identify
an application process running on the destination host. (The UDP and TCP segments have other
fields as well, and they will be addressed in the subsequent sections of this chapter.)

Figure 3.2-1: Source and destination port number fields in a transport layer segment.

The notion of port numbers was briefly introduced in Sections 2.6-2.7, in which we studied
application development and socket programming. The port number is a 16-bit number, ranging
from from 0 to 65535. The port numbers ranging from 0 - 1023 are called well-known port
numbers and are restricted, which means that they are reserved for use by well-known
application protocols such as HTTP and FTP. HTTP uses port number 80; FTP uses port number
21. The list of well-known port numbers is given in [RFC 1700]. When we develop a new
application (such as one of the applications developed in Sections 2.6-2.8), we must assign the
application a port number.

Given that each type of application running on an end system has a unique port number, then
why is it that the transport-layer segment has fields for two port numbers, a source port number
and a destination port number? The answer is simple: An end system may be running two
processes of same type at the same time, and thus the port number of an application may not
suffice to identify a specific process. For example, many Web servers spawn a new HTTP
process for every request it receives; whenever such a Web server is servicing more than one
request (which is by no means uncommon), the server is running more than one process with
port number 80. Therefore, in order to uniquely identify processes, a second port number is
needed.

How is this second port number created? Which port number goes in the source port number
field of a segment? Which goes in the destination port number field of a segment? To answer
these questions, recall from Section 2.1 that networked applications are organized around the
client-server model. Typically, the host that initiates the application is the client and the other
host is the server. Now let's look at a specific example. Suppose the application has port number
23 (the port number for Telnet). Consider a transport layer segment leaving the client (i.e., the
host that initiated the Telnet session) and destined for the server. What are the destination and
source port numbers for this segment? For the destination port number, this segment has the port
number of the application, namely, 23. For the source port number, the client uses a number that
is not being used by any of its other processes. (This is can be done automatically by the
transport-layer software running on the client and is transparent to the application developer. An
application can also explicitly request a specific port number using the bind() system call on
many Unix-like systems.) Let's say the client chooses port number x. Then each segment that this
process sends will have its source port number set to x and destination port number set to 23.
When the segment arrives at the server, the source and destination port numbers in the segment
enable the server host to pass the data of the segment to the correct application process: the
destination port number 23 identifies a Telnet process and the source port number x identifies the
specific Telnet process.

The situation is reversed for the segments flowing from the server to the client. The source port
number is now the application port number, 23. The destination port number is now x. (The same
x used for the source port number for the segments sent from client to server.) When a segment
arrives at the client, the source and destination port numbers in the segment will enable the client
host to pass the data of the segment to the correct application process, which is identified by the
port number pair. Figure 3.2-2 summarizes the discussion:

Figure 3.2-2: Use of source and destination port numbers in a client-server application

Now you may be wondering, what happens if two different clients establish a Telnet session to a
server, and each of these clients choose the same source port number x? How will the server be
able to demultiplex the segments when the two sessions have exactly the same port number pair?
The answer to this question is that server also uses the IP addresses in the IP datagrams carrying
these segments. (We will discuss IP datagrams and addressing in detail in Chapter 4.) The
situation is illustrated in Figure 3.2-3, in which host A initiates two Telnet sessions to host C, and
host A initiates one Telnet session to host C. Hosts A, B and C each have their own unique IP
address; host A has IP address A, host B has IP address B, and host C has IP address C. Host A
assigns two different source port (SP) numbers (x and y) to the two Telnet connections
emanating from host A. But because host B is choosing source port numbers independently from
A, it can also assign SP=x to its Telnet connection. Nevertheless, host C is still able to
demultiplex the two connections since the two connections have different source IP addresses. In
summary, we see that when a destination host receives data from the network layer, the triplet
[source IP address, source port number, destination port number] is used to forward the data to
the appropriate process.
 Figure 3.2-3: Two clients, using the same port numbers to communicate with the same server
application

Now that we understand how the transport layer can multiplex and demultiplex messages from/to
network applications, let's move on and discuss one of the Internet's transport protocols, UDP. In
the next section we shall see that UDP adds little more to the network layer protocol than
multiplexing/demultiplexing service.