For example, the /etc/services file on UNIX systems
lists which servers are permanently attached to
which ports, including the fact that the mail server
is found on TCP port 25.
While stable TSAP addresses work for a small
number of key services that never change (e.g., the
Web server), user processes, in general, often want
to talk to other user processes that do not have
TSAP addresses that are known in advance, or that
may exist for only a short time.
To handle this situation, an alternative scheme can
be used. In this scheme, there exists a special
process called a portmapper.
To find the TSAP address corresponding to a given
service name, such as ‘‘BitTorrent,’’ a user sets up a
connection to the portmapper (which listens to a well-
known TSAP).
The user then sends a message specifying the service
name, and the portmapper sends back the TSAP
address.
Then the user releases the connection with the
portmapper and establishes a new one with the
desired service.
The function of the portmapper is analogous to that of
a directory assistance operator in the telephone
system—it provides a mapping of names onto
numbers. Just as in the telephone system, it is
essential that the address of the well-known
In Fig. in a simplified form which is known as the
initial connection protocol. Instead of every
conceivable server listening at a well-known TSAP,
each machine that wishes to offer services to
remote users has a special process server that acts
as a proxy for less heavily used servers.
This server is called inetd on UNIX systems. It
listens to a set of ports at the same time, waiting for
a connection request.
Potential users of a service begin by doing a
CONNECT request, specifying the TSAP address of
the service they want. If no server is waiting for
them, they get a connection to the process server,
as shown in Fig. (a).
After it gets the incoming request, the process
server spawns the requested server, allowing it to
inherit the existing connection with the user.
The new server does the requested work, while the
process server goes back to listening for new
requests, as shown in Fig. (b).
This method is only applicable when servers can be
created on demand.
Establishing a connection sounds easy, but it is
actually surprisingly tricky.
At first glance, it would seem sufficient for one
transport entity to just send a CONNECTION
REQUEST segment to the destination and wait for a
CONNECTION ACCEPTED reply.
The problem occurs when the network can lose,
delay, corrupt, and duplicate packets.
A network that is so congested that
acknowledgements hardly ever get back in time
and each packet times out and is retransmitted two
or three times.
The network uses datagrams inside and that every
packet follows a different route.
Some of the packets might get stuck in a traffic jam
inside the network and take a long time to arrive. That is,
they may be delayed in the network and pop out much
later, when the sender thought that they had been lost.
The problem can be attacked in various ways, none of
them very satisfactory. One way is to use throwaway
transport addresses. In this approach, each time a
transport address is needed, a new one is generated.
When a connection is released, the address is discarded
and never used again. Delayed duplicate packets then
never find their way to a transport process and can do no
damage.
Another possibility is to give each connection a
unique identifier (i.e., a sequence number
incremented for each connection established)
chosen by the initiating party and put in each
segment, including the one requesting the
connection.
After each connection is released, each transport
entity can update a table listing obsolete
connections as (peer transport entity, connection
identifier) pairs.
Whenever a connection request comes in, it can be
checked against the table to see if it belongs to a
previously released connection.
This scheme has a basic flaw: it requires each
transport entity to maintain a certain amount of
history information indefinitely.
This history must persist at both the source and
destination machines. Otherwise, if a machine
crashes and loses its memory, it will no longer know
which connection identifiers have already been used
by its peers.
Solution is Rather than allowing packets to live
forever within the network, we devise a mechanism
to kill off aged packets that are still hobbling about.
With this restriction, the problem becomes
somewhat more manageable.
Packet lifetime can be restricted to a known
maximum using one (or more) of
the following techniques:
1. Restricted network design.
2. Putting a hop counter in each packet.
3. Timestamping each packet.
The first technique includes any method that
prevents packets from looping, combined with some
way of bounding delay including congestion over
the (now known) longest possible path.
It is difficult, given that internets may range from a
single city to international in scope.
The second method consists of having the hop
count initialized to some appropriate value and
decremented each time the packet is forwarded.
The network protocol simply discards any packet
whose hop counter becomes zero.
The third method requires each packet to bear the
time it was created, with the routers agreeing to
discard any packet older than some agreed-upon
time.
This latter method requires the router clocks to be
synchronized, which itself is a nontrivial task, and in
practice a hop counter is a close enough
approximation to age.
It is one of the method of establishing the
connection. This establishment protocol involves one
peer checking with the other that the connection
request is indeed current.
The normal setup procedure when host 1 initiates is
shown in Fig. (a). Host 1 chooses a sequence
number, x, and sends a CONNECTION REQUEST
segment containing it to host 2.
Host 2 replies with an ACK segment acknowledging
x and announcing its own initial sequence number, y.
Finally, host 1 acknowledges host 2’s choice of an
initial sequence number in the first data segment that
it sends.
in the presence of delayed duplicate control segments.
In Fig. (b), the first segment is a delayed duplicate
CONNECTION REQUEST from an old connection.
This segment arrives at host 2 without host 1’s
knowledge. Host 2 reacts to this segment by sending
host 1 an ACK segment, in effect asking for verification
that host 1 was indeed trying to set up a new
connection.
When host 1 rejects host 2’s attempt to establish a
connection, host 2 realizes that it was tricked by a
delayed duplicate and abandons the connection.
In this way, a delayed duplicate does no damage.
The worst case is when both a delayed CONNECTION
REQUEST and an ACK are floating around in the subnet.
This case is shown in Fig. (c).
As in the previous example, host 2 gets a delayed
CONNECTION REQUEST and replies to it. At this point, it
is crucial to realize that host 2 has proposed using y as
the initial sequence number for host 2 to host 1 traffic,
knowing full well that no segments containing sequence
number y or acknowledgements to y are still in
existence.
When the second delayed segment arrives at host 2, the
fact that z has been acknowledged rather than y tells
host 2 that this, too, is an old duplicate.
Releasing a connection is easier than establishing
one. There are two styles of terminating a connection:
asymmetric release and symmetric release.
Asymmetric release is the way the telephone system
works: when one party hangs up, the connection is
broken.
Symmetric release treats the connection as two
separate unidirectional connections and requires each
one to be released separately.
Asymmetric release is abrupt and may result in data
loss.
In Fig. After the connection is established, host 1
sends a segment that arrives properly at host 2. Then
host 1 sends another segment. Unfortunately, host 2
issues a DISCONNECT before the second segment
arrives. The result is that the connection is released
and data are lost.
A more sophisticated release protocol is needed to
avoid data loss. One way is to use symmetric
release, in which each direction is released
independently of the other one.
Symmetric release does the job when each process
has a fixed amount of data to send and clearly
knows when it has sent it.
In Fig. (a), we see the normal case in which one of the
users sends a DR (DISCONNECTION REQUEST)
segment to initiate the connection release.
When it arrives, the recipient sends back a DR
segment and starts a timer, just in case its DR is lost.
When this DR arrives, the original sender sends back
an ACK segment and releases the connection.
Finally, when the ACK segment arrives, the receiver
also releases the connection. Releasing a connection
means that the transport entity removes the
information about the connection from its table of
currently open connections and signals the
connection’s owner (the transport user.
If the final ACK segment is lost, as shown in Fig.
(b), the situation is saved by the timer.
When the timer expires, the connection is released
anyway.
Now consider the case of the second DR being lost.
The user initiating the disconnection will not
receive the expected response, will time out, and
will start all over again.
In Fig.(c), we see how this works, assuming that the
second time no segments are lost and all segments
are delivered correctly and on time.
Our last scenario, Fig. (d), is the same as Fig. (c)
except that now we assume all the repeated
attempts to retransmit the DR also fail due to lost
segments.
After N retries, the sender just gives up and
releases the connection. Meanwhile, the receiver
times out and also exits.
The key issues are error control and flow control.
Error control is ensuring that the data is delivered
with the desired level of reliability, usually that all
of the data is delivered without any errors.
Flow control is keeping a fast transmitter from
overrunning a slow receiver.
The solutions that are used at the transport layer
are the same mechanisms as in data link layer.
1. A frame carries an error-detecting code (e.g., a
CRC or checksum) that is used to check if the
information was correctly received.
2. A frame carries a sequence number to identify itself
and is retransmitted by the sender until it receives an
acknowledgement of successful receipt from the
receiver. This is called ARQ .
3. There is a maximum number of frames that the
sender will allow to be outstanding at any time,
pausing if the receiver is not acknowledging frames
quickly enough.
If this maximum is one packet the protocol is called
stop-and-wait. Larger windows enable pipelining and
improve performance on long, fast links.
4. The sliding window protocol combines these
features and is also used to support bidirectional data
transfer.
For a difference in function, consider error
detection. The link layer checksum protects a frame
while it crosses a single link. The transport layer
checksum protects a segment while it crosses an
entire network path.
It is an end-to-end check, which is not the same as
having a check on every link describe a situation in
which packets were corrupted inside a router.
The link layer checksums protected the packets only
while they traveled across a link, not while they were
inside the router. Thus, packets were delivered
incorrectly even though they were correct according
to the checks on every link.
Multiplexing, or sharing several conversations over
connections, virtual circuits, and physical links plays
a role in several layers of the network architecture.
In the transport layer, the need for multiplexing can
arise in a number of ways.
For example, if only one network address is available
on a host, all transport connections on that machine
have to use it. When a segment comes in, some way
is needed to tell which process to give it to. This
situation, called multiplexing,
If hosts and routers are subject to crashes or
connections are long-lived (e.g., large software or
media downloads), recovery from these crashes
becomes an issue.
If the transport entity is entirely within the hosts,
recovery from network and router crashes is
straightforward.
The transport entities expect lost segments all the
time and know how to cope with them by using
retransmissions.
If the transport entities on many machines send too
many packets into the network too quickly, the network
will become congested, with performance degraded as
packets are delayed and lost.
Controlling congestion to avoid this problem is the
combined responsibility of the network and transport
layers.
Congestion occurs at routers, so it is detected at the
network layer. However, congestion is ultimately
caused by traffic sent into the network by the transport
layer.
The only effective way to control congestion is for the
transport protocols to send packets into the network
more slowly
The data link layer is responsible for delivery of frames
between two neighboring nodes over a link. This is
called node-to-node delivery. The network layer is
responsible for delivery of datagrams between two
hosts. This is called host-to-host delivery.
Communication on the Internet is not defined as the
exchange of data between two nodes or between two
hosts. Real communication takes place between two
processes (application programs).
We need process-to-process delivery. However, at any
moment, several processes may be running on the
source host and several on the destination host.
To complete the delivery, we need a mechanism to
deliver data from one of these processes running on the
source host to the corresponding process running on
the destination host.
The transport layer is responsible for process-to-
process delivery-the delivery of a packet, part of a
message, from one process to another.
Two processes communicate in a client/server
relationship, as we will see later. Figure shows these
three types of deliveries and their domains.
Client/Server Paradigm
Although there are several ways to achieve process-to-
process communication, the most common one is
through the client/server paradigm.
A process on the local host, called a client, needs
services from a process usually on the remote host,
called a server.
Both processes (client and server) have the same name..
Operating systems today support both multiuser and
multiprogramming environments.
A remote computer can run several server programs at
the same time, just as local computers can run one or
more client programs at the same time. For
communication, we must define the following:
1. Local host
2. Local process
3. Remote host
4. Remote process
Addressing
Whenever we need to deliver something to one specific
destination among many, we need an address. At the
data link layer, we need a MAC address to choose one
node among several nodes if the connection is not
point-to-point.
A frame in the data link layer needs a destination MAC
address for delivery and a source address for the next
node's reply.
At the network layer, we need an IP address to choose
one host among millions. A datagram in the network
layer needs a destination IP address for delivery and a
source IP address for the destination's reply.
At the transport layer, we need a transport layer
address, called a port number, to choose among
multiple processes running on the destination host. The
destination port number is needed for delivery; the
source port number is needed for the reply.
