Introduction to Computer Networks

3rd Assignment
1. Discuss Flow and Error Control in Transport Layer with Sliding window in circular
format and linear format.

Flow Control at Transport Layer

In communication at the transport layer, we are dealing with four entities: sender process,
sender transport layer, receiver transport layer, and receiver process. The sending
process at the application layer is only a producer. It produces message chunks
and pushes them to the transport layer. The sending transport layer has a double role:
it is both a consumer and a producer. It consumes the messages pushed by the producer.

It encapsulates the messages in packets and pushes them to the receiving transport
layer. The receiving transport layer also has a double role: it is the consumer for
the packets received from the sender and the producer that decapsulates the messages
and delivers them to the application layer. The last delivery, however, is normally a
pulling delivery; the transport layer waits until the application-layer process asks for
messages.

Figure 23.10 shows that we need at least two cases of flow control: from the sending
transport layer to the sending application layer and from the receiving transport
layer to the sending transport layer.

Error Control
In the Internet, since the underlying network layer (IP) is unreliable, we need to make
the transport layer reliable if the application requires reliability. Reliability can be
achieved to add error control services to the transport layer. Error control at the transport
layer is responsible for
1. Detecting and discarding corrupted packets.
2. Keeping track of lost and discarded packets and resending them.
3. Recognizing duplicate packets and discarding them.
4. Buffering out-of-order packets until the missing packets arrive.
Error control, unlike flow control, involves only the sending and receiving transport
layers. We are assuming that the message chunks exchanged between the application
and transport layers are error free. Figure 23.11 shows the error control between the
sending and receiving transport layers. As with the case of flow control, the receiving
transport layer manages error control, most of the time, by informing the sending transport
layer about the problems.

Sliding Window
Since the sequence numbers use modulo 2m, a circle can represent the sequence numbers
from 0 to 2m 1 (Figure 23.12). The buffer is represented as a set of slices, called the
sliding window, that occupies part of the circle at any time. At the sender site, when a
packet is sent, the corresponding slice is marked. When all the slices are marked, it means
that the buffer is full and no further messages can be accepted from the application layer.
When an acknowledgment arrives, the corresponding slice is unmarked. If some consecutive
slices from the beginning of the window are unmarked, the window slides over
the range of the corresponding sequence numbers to allow more free slices at the end of the
window. Figure 23.12 shows the sliding window at the sender. The sequence numbers are
in modulo 16 (m = 4) and the size of the window is 7. Note that the sliding window is just
an abstraction: the actual situation uses computer variables to hold the sequence numbers
of the next packet to be sent and the last packet sent.
Most protocols show the sliding window using linear representation. The idea is
the same, but it normally takes less space on paper. Figure 23.13 shows this representation.
Both representations tell us the same thing. If we take both sides of each diagram
in Figure 23.13 and bend them up, we can make the same diagram as in Figure 23.12.

2. Explain with neat diagram Stop-and-Wait Protocol with FSM in Transport Layer.

Stop-and-Wait Protocol
Our second protocol is a connection-oriented protocol called the Stop-and-Wait
protocol, which uses both flow and error control. Both the sender and the receiver use a
sliding window of size 1. The sender sends one packet at a time and waits for an
acknowledgment before sending the next one. To detect corrupted packets, we need to
add a checksum to each data packet. When a packet arrives at the receiver site, it is
checked. If its checksum is incorrect, the packet is corrupted and silently discarded.

The silence of the receiver is a signal for the sender that a packet was either corrupted
or lost. Every time the sender sends a packet, it starts a timer. If an acknowledgment
arrives before the timer expires, the timer is stopped and the sender sends the next
packet (if it has one to send). If the timer expires, the sender resends the previous
packet, assuming that the packet was either lost or corrupted. This means that the
sender needs to keep a copy of the packet until its acknowledgment arrives. Figure 23.20
shows the outline for the Stop-and-Wait protocol. Note that only one packet and one
acknowledgment can be in the channels at any time.
The Stop-and-Wait protocol is a connection-oriented protocol that provides flow
and error control.

3. Explain with neat diagram Goback-N protocol with FSM in Transport Layer.

FSMs
Figure 23.27 shows the FSMs for the GBN protocol.
Sender
The sender starts in the ready state, but thereafter it can be in one of the two states:
ready or blocking. The two variables are normally initialized to 0 (Sf = Sn = 0).
❑ Ready state. Four events may occur when the sender is in ready state.
a. If a request comes from the application layer, the sender creates a packet with
the sequence number set to Sn. A copy of the packet is stored, and the packet is
sent. The sender also starts the only timer if it is not running. The value of Sn is
now incremented, (Sn = Sn + 1) modulo 2m. If the window is full, Sn = (Sf +
Ssize) modulo 2m, the sender goes to the blocking state.
b. If an error-free ACK arrives with ackNo related to one of the outstanding packets,
the sender slides the window (set Sf = ackNo), and if all outstanding packets
are acknowledged (ackNo = Sn), then the timer is stopped. If all outstanding
packets are not acknowledged, the timer is restarted.
c. If a corrupted ACK or an error-free ACK with ackNo not related to the outstanding
packet arrives, it is discarded.
d. If a time-out occurs, the sender resends all outstanding packets and restarts the
timer.
❑ Blocking state. Three events may occur in this case:
a. If an error-free ACK arrives with ackNo related to one of the outstanding packets,
the sender slides the window (set Sf = ackNo) and if all outstanding packets
are acknowledged (ackNo = Sn), then the timer is stopped. If all outstanding
packets are not acknowledged, the timer is restarted. The sender then moves to
the ready state.
b. If a corrupted ACK or an error-free ACK with the ackNo not related to the outstanding
packets arrives, the ACK is discarded.
c. If a time-out occurs, the sender sends all outstanding packets and restarts the timer.
Receiver
The receiver is always in the ready state. The only variable, Rn, is initialized to 0. Three
events may occur:
a. If an error-free packet with seqNo = Rn arrives, the message in the packet is delivered
to the application layer. The window then slides, Rn = (Rn + 1) modulo 2m.
Finally an ACK is sent with ackNo = Rn.
b. If an error-free packet with seqNo outside the window arrives, the packet is discarded,
but an ACK with ackNo = Rn is sent.
c. If a corrupted packet arrives, it is discarded.

4. Describe connection oriented and connectionless services provided by transport layer.

Connectionless and Connection-Oriented Protocols

A transport-layer protocol, like a network-layer protocol, can provide two types of

services: connectionless and connection-oriented. The nature of these services at the
transport layer, however, is different from the ones at the network layer. At the network
layer, a connectionless service may mean different paths for different datagrams
belonging to the same message. At the transport layer, we are not concerned about the
physical paths of packets (we assume a logical connection between two transport layers).
Connectionless service at the transport layer means independency between packets;
connection-oriented means dependency. Let us elaborate on these two services.

Connectionless Service
In a connectionless service, the source process (application program) needs to divide its
message into chunks of data of the size acceptable by the transport layer and deliver
them to the transport layer one by one. The transport layer treats each chunk as a single
unit without any relation between the chunks. When a chunk arrives from the application
layer, the transport layer encapsulates it in a packet and sends it. To show the independency
of packets, assume that a client process has three chunks of messages to send
to a server process. The chunks are handed over to the connectionless transport protocol
in order. However, since there is no dependency between the packets at the transport
layer, the packets may arrive out of order at the destination and will be delivered out of
order to the server process (Figure 23.14).

In Figure 23.14, we have shown the movement of packets using a time line, but we
have assumed that the delivery of the process to the transport layer and vice versa are
instantaneous. The figure shows that at the client site, the three chunks of messages are
delivered to the client transport layer in order (0, 1, and 2). Because of the extra delay
in transportation of the second packet, the delivery of messages at the server is not in
order (0, 2, 1). If these three chunks of data belong to the same message, the server process
may have received a strange message.
The situation would be worse if one of the packets were lost. Since there is no
numbering on the packets, the receiving transport layer has no idea that one of the messages
has been lost. It just delivers two chunks of data to the server process.
The above two problems arise from the fact that the two transport layers do not
coordinate with each other. The receiving transport layer does not know when the first
packet will come nor when all of the packets have arrived.
We can say that no flow control, error control, or congestion control can be effectively
implemented in a connectionless service.

Connection-Oriented Service
In a connection-oriented service, the client and the server first need to establish a
logical connection between themselves. The data exchange can only happen after the
connection establishment. After data exchange, the connection needs to be torn down
(Figure 23.15).
As we mentioned before, the connection-oriented service at the transport layer is
different from the same service at the network layer. In the network layer, connection oriented
service means a coordination between the two end hosts and all the routers in
between. At the transport layer, connection-oriented service involves only the two
hosts; the service is end to end. This means that we should be able to make a
connection-oriented protocol at the transport layer over either a connectionless or
connection-oriented protocol at the network layer. Figure 23.15 shows the connection establishment,
data-transfer, and tear-down phases in a connection-oriented service at
the transport layer.
We can implement flow control, error control, and congestion control in a connection oriented
protocol.
 5. Explain different field in user datagram(UDP) format with a neat diagram .

USER DATAGRAM PROTOCOL

The User Datagram Protocol (UDP) is a connectionless, unreliable transport protocol.

It does not add anything to the services of IP except for providing process-to-process
communication instead of host-to-host communication. If UDP is so powerless, why
would a process want to use it? With the disadvantages come some advantages. UDP is a
very simple protocol using a minimum of overhead. If a process wants to send a small
message and does not care much about reliability, it can use UDP. Sending a small message
using UDP takes much less interaction between the sender and receiver than using
TCP. We discuss some applications of UDP at the end of this section.

User Datagram
UDP packets, called user datagrams, have a fixed-size header of 8 bytes made of four
fields, each of 2 bytes (16 bits). Figure 24.2 shows the format of a user datagram. The
first two fields define the source and destination port numbers. The third field defines
the total length of the user datagram, header plus data. The 16 bits can define a total
length of 0 to 65,535 bytes. However, the total length needs to be less because a UDP
user datagram is stored in an IP datagram with the total length of 65,535 bytes. The last
field can carry the optional checksum (explained later).
Example 24.1:
The following is the content of a UDP header in hexadecimal format.
CB84000D001C001C
a. What is the source port number?
b. What is the destination port number?
c. What is the total length of the user datagram?
d. What is the length of the data?
e. Is the packet directed from a client to a server or vice versa?
f. What is the client process?
Solution
a. The source port number is the first four hexadecimal digits (CB84)16, which means that
the source port number is 52100.
b. The destination port number is the second four hexadecimal digits (000D)16, which
means that the destination port number is 13.
c. The third four hexadecimal digits (001C)16 define the length of the whole UDP packet as
28 bytes.
d. The length of the data is the length of the whole packet minus the length of the header, or
28 8 = 20 bytes.
e. Since the destination port number is 13 (well-known port), the packet is from the client
to the server.
f. The client process is the Daytime (see Table 24.1).

6. With a neat diagram explain connection establishment, data transfer and connection
termination in TCP.
Connection Establishment
TCP transmits data in full-duplex mode. When two TCPs in two machines are connected,
they are able to send segments to each other simultaneously. This implies that
each party must initialize communication and get approval from the other party before
any data are transferred.
Three-Way Handshaking
The connection establishment in TCP is called three-way handshaking. In our example,
an application program, called the client, wants to make a connection with another
application program, called the server, using TCP as the transport-layer protocol.
The process starts with the server. The server program tells its TCP that it is ready
to accept a connection. This request is called a passive open. Although the server TCP
is ready to accept a connection from any machine in the world, it cannot make the connection
itself.
The client program issues a request for an active open. A client that wishes to connect
to an open server tells its TCP to connect to a particular server. TCP can now start
the three-way handshaking process, as shown in Figure 24.10.

The three steps in this phase are as follows:

1. A SYN segment cannot carry data, but it consumes one sequence number.
2. A SYN + ACK segment cannot carry data, but it does consume one sequence number.
3. An ACK segment, if carrying no data, consumes no sequence number.

Connection Termination
Either of the two parties involved in exchanging data (client or server) can close the
connection, although it is usually initiated by the client. Most implementations today
allow two options for connection termination: three-way handshaking and four-way
handshaking with a half-close option.
Three-Way Handshaking
Most implementations today allow three-way handshaking for connection termination,
as shown in Figure 24.12.
1. In this situation, the client TCP, after receiving a close command from the client
process, sends the first segment, a FIN segment in which the FIN flag is set. Note
that a FIN segment can include the last chunk of data sent by the client or it can be
just a control segment as shown in the figure. If it is only a control segment, it consumes
only one sequence number because it needs to be acknowledged.

The FIN segment consumes one sequence number if it does not carry data.

2. The server TCP, after receiving the FIN segment, informs its process of the situation
and sends the second segment, a FIN + ACK segment, to confirm the receipt of the
FIN segment from the client and at the same time to announce the closing of the connection
in the other direction. This segment can also contain the last chunk of data
from the server. If it does not carry data, it consumes only one sequence number
because it needs to be acknowledged.
3. The client TCP sends the last segment, an ACK segment, to confirm the receipt of
the FIN segment from the TCP server. This segment contains the acknowledgment
number, which is one plus the sequence number received in the FIN segment from
the server. This segment cannot carry data and consumes no sequence numbers.

Data Transfer
After connection is established, bidirectional data transfer can take place. The client
and server can send data and acknowledgments in both directions. We will study the
rules of acknowledgment later in the chapter; for the moment, it is enough to know
that data traveling in the same direction as an acknowledgment are carried on the
same segment. The acknowledgment is piggybacked with the data. Figure 24.11
shows an example.
In this example, after a connection is established, the client sends 2,000 bytes of
data in two segments. The server then sends 2,000 bytes in one segment. The client
sends one more segment. The first three segments carry both data and acknowledgment,
but the last segment carries only an acknowledgment because there is no more
data to be sent. Note the values of the sequence and acknowledgment numbers. The
data segments sent by the client have the PSH (push) flag set so that the server TCP
knows to deliver data to the server process as soon as they are received. We discuss the
use of this flag in more detail later. The segment from the server, on the other hand,
does not set the push flag. Most TCP implementations have the option to set or not to
set this flag.
TCP can handle such a situation. The application program at the sender can
request a push operation. This means that the sending TCP must not wait for the window
to be filled. It must create a segment and send it immediately. The sending TCP
must also set the push bit (PSH) to let the receiving TCP know that the segment
includes data that must be delivered to the receiving application program as soon as
possible and not to wait for more data to come. This means to change the byte oriented
TCP to a chunk-oriented TCP, but TCP can choose whether or not to use this
feature.

7. Suppose a TCP connection is transferring a file of 5000 bytes. The first byte is numbered
10001. What are the sequence numbers for each segment if data are sent in five segments?
Each carrying 1000 bytes. (Example 24.7 in Text book)

When a segment carries a combination of data and control information (piggybacking),

it uses a sequence number. If a segment does not carry user data, it does not
logically define a sequence number. The field is there, but the value is not valid. However,
some segments, when carrying only control information, need a sequence number
to allow an acknowledgment from the receiver. These segments are used for connection
establishment, termination, or abortion. Each of these segments consume one sequence
number as though it carries one byte, but there are no actual data. We will elaborate on
this issue when we discuss connections.

8. Briefly explain a) client-server paradigm b) peer-to-peer paradigm in Application layer.

Application-Layer Paradigms
It should be clear that to use the Internet we need two application programs to interact
with each other: one running on a computer somewhere in the world, the other running
on another computer somewhere else in the world. The two programs need to send
messages to each other through the Internet infrastructure. However, we have not discussed
what the relationship should be between these programs. Should both application
programs be able to request services and provide services, or should the
application programs just do one or the other? Two paradigms have been developed
during the lifetime of the Internet to answer this question: the client-server paradigm
and the peer-to-peer paradigm.

Client-Server
The traditional paradigm is called the client-server paradigm. It was the most popular
paradigm until a few years ago. In this paradigm, the service provider is an application
program, called the server process; it runs continuously, waiting for another application
program, called the client process, to make a connection through the Internet and ask
for service. There are normally some server processes that can provide a specific type
of service, but there are many clients that request service from any of these server processes.
The server process must be running all the time; the client process is started
when the client needs to receive service.

The client-server paradigm is similar to some available services out of the territory
of the Internet. For example, a telephone directory center in any area can be thought of
as a server; a subscriber that calls and asks for a specific telephone number can be
thought of as a client. The directory center must be ready and available all the time; the
subscriber can call the center for a short period when the service is needed.

Although the communication in the client-server paradigm is between two application

programs, the role of each program is totally different. In other words, we cannot run a client program as a
server program or vice versa. Later in this chapter, when we
talk about client-server programming in this paradigm, we show that we always need to
write two application programs for each type of service. Figure 25.2 shows an example
of a client-server communication in which three clients communicate with one server
to receive the services provided by this server.

One problem with this paradigm is that the concentration of the communication
load is on the shoulder of the server, which means the server should be a powerful computer.
Even a powerful computer may become overwhelmed if a large number of clients
try to connect to the server at the same time. Another problem is that there should be
a service provider willing to accept the cost and create a powerful server for a specific
service, which means the service must always return some type of income for the server
in order to encourage such an arrangement.
Several traditional services are still using this paradigm, including the World Wide
Web (WWW) and its vehicle Hyper Text Transfer Protocol (HTTP), file transfer protocol
(FTP), secure shell (SSH), e-mail, and so on. We discuss some of these protocols and applications later in the
chapter.

Peer-to-Peer
A new paradigm, called the peer-to-peer paradigm (often abbreviated P2P paradigm)
has emerged to respond to the needs of some new applications. In this paradigm, there
is no need for a server process to be running all the time and waiting for the client
processes to connect. The responsibility is shared between peers. A computer connected
to the Internet can provide service at one time and receive service at another
time. A computer can even provide and receive services at the same time. Figure 25.3
shows an example of communication in this paradigm.

One of the areas that really fits in this paradigm is the Internet telephony. Communication
by phone is indeed a peer-to-peer activity; no party needs to be running forever
waiting for the other party to call. Another area in which the peer-to-peer paradigm
can be used is when some computers connected to the Internet have something to share
with each other. For example, if an Internet user has a file available to share with other
Internet users, there is no need for the file holder to become a server and run a server process
all the time waiting for other users to connect and retrieve the file.

Although the peer-to-peer paradigm has been proved to be easily scalable and
cost-effective in eliminating the need for expensive servers to be running and maintained
all the time, there are also some challenges. The main challenge has been
security; it is more difficult to create secure communication between distributed
services than between those controlled by some dedicated servers. The other challenge
is applicability; it appears that not all applications can use this new paradigm. For
example, not many Internet users are ready to become involved, if one day the Web can
be implemented as a peer-to-peer service.

There are some new applications, such as BitTorrent, Skype, IPTV, and Internet
telephony, that use this paradigm.

9. Write a note on WWW (World Wide Web).

World Wide Web

The idea of the Web was first proposed by Tim Berners-Lee in 1989 at CERN†, the
European Organization for Nuclear Research, to allow several researchers at different
locations throughout Europe to access each others’ researches. The commercial Web
started in the early 1990s.
The Web today is a repository of information in which the documents, called web
pages, are distributed all over the world and related documents are linked together. The
popularity and growth of the Web can be related to two terms in the above statement:
distributed and linked. Distribution allows the growth of the Web. Each web server in
the world can add a new web page to the repository and announce it to all Internet users
without overloading a few servers. Linking allows one web page to refer to another web
page stored in another server somewhere else in the world. The linking of web pages
was achieved using a concept called hypertext, which was introduced many years
before the advent of the Internet. The idea was to use a machine that automatically
retrieved another document stored in the system when a link to it appeared in the document.
The Web implemented this idea electronically to allow the linked document to be
retrieved when the link was clicked by the user. Today, the term hypertext, coined to
mean linked text documents, has been changed to hypermedia, to show that a web page
can be a text document, an image, an audio file, or a video file.

The purpose of the Web has gone beyond the simple retrieving of linked documents.
Today, the Web is used to provide electronic shopping and gaming. One can use
the Web to listen to radio programs or view television programs whenever one desires
without being forced to listen to or view these programs when they are broadcast.

Architecture
The WWW today is a distributed client-server service, in which a client using a
browser can access a service using a server. However, the service provided is distributed
over many locations called sites. Each site holds one or more web pages. Each
web page, however, can contain some links to other web pages in the same or other
sites. In other words, a web page can be simple or composite. A simple web page has
no links to other web pages; a composite web page has one or more links to other web
pages. Each web page is a file with a name and address.

10. Explain control connection & data connection in FTP.

Control Connection
For control communication, FTP uses the same approach as TELNET (discussed later).
It uses the NVT ASCII character set as used by TELNET. Communication is achieved
through commands and responses. This simple method is adequate for the control connection
because we send one command (or response) at a time. Each line is terminated
with a two-character (carriage return and line feed) end-of-line token.

During this control connection, commands are sent from the client to the server and
responses are sent from the server to the client. Commands, which are sent from the FTP
client control process, are in the form of ASCII uppercase, which may or may not be followed
by an argument. Some of the most common commands are shown in Table 26.4.
Every FTP command generates at least one response. A response has two parts: a
three-digit number followed by text. The numeric part defines the code; the text part
defines needed parameters or further explanations. The first digit defines the status of
the command. The second digit defines the area in which the status applies. The third
digit provides additional information. Table 26.5 shows some common responses.

Data Connection
The data connection uses the well-known port 20 at the server site. However, the creation
of a data connection is different from the control connection. The following
shows the steps:
1. The client, not the server, issues a passive open using an ephemeral port. This must be
done by the client because it is the client that issues the commands for transferring files.
2. Using the PORT command the client sends this port number to the server.
3. The server receives the port number and issues an active open using the wellknown
port 20 and the received ephemeral port number.
Communication over Data Connection
The purpose and implementation of the data connection are different from those of the control
connection. We want to transfer files through the data connection. The client must
define the type of file to be transferred, the structure of the data, and the transmission mode.
Before sending the file through the data connection, we prepare for transmission through
the control connection. The heterogeneity problem is resolved by defining three attributes
of communication: file type, data structure, and transmission mode.
File Type
FTP can transfer one of the following file types across the data connection: ASCII file,
EBCDIC file, or image file.
Data Structure
FTP can transfer a file across the data connection using one of the following interpretations
of the structure of the data: file structure, record structure, or page structure. The
file structure format (used by default) has no structure. It is a continuous stream of
bytes. In the record structure, the file is divided into records. This can be used only with
text files. In the page structure, the file is divided into pages, with each page having a
page number and a page header. The pages can be stored and accessed randomly or
sequentially.

Transmission Mode
FTP can transfer a file across the data connection using one of the following three
transmission modes: stream mode, block mode, or compressed mode. The stream mode
is the default mode; data are delivered from FTP to TCP as a continuous stream of
bytes. In the block mode, data can be delivered from FTP to TCP in blocks. In this case,
each block is preceded by a 3-byte header. The first byte is called the block descriptor;
the next two bytes define the size of the block in bytes.
File Transfer
File transfer occurs over the data connection under the control of the commands sent
over the control connection. However, we should remember that file transfer in FTP
means one of three things: retrieving a file (server to client), storing a file (client to
server), and directory listing (server to client).

11. Explain Architecture of E-mail.

Architecture
To explain the architecture of e-mail, we give a common scenario, as shown in Figure
26.12. Another possibility is the case in which Alice or Bob is directly connected to
the corresponding mail server, in which LAN or WAN connection is not required, but this
variation in the scenario does not affect our discussion.
In the common scenario, the sender and the receiver of the e-mail, Alice and Bob
respectively, are connected via a LAN or a WAN to two mail servers. The administrator
has created one mailbox for each user where the received messages are stored. A mailbox
is part of a server hard drive, a special file with permission restrictions. Only the
owner of the mailbox has access to it. The administrator has also created a queue
(spool) to store messages waiting to be sent.

A simple e-mail from Alice to Bob takes nine different steps, as shown in the figure.
Alice and Bob use three different agents: a user agent (UA), a message transfer agent
(MTA), and a message access agent (MAA). When Alice needs to send a message to Bob, she runs a UA
program to prepare the message and send it to her mail server. The mail server at her site uses a queue (spool)
to store messages waiting to be sent. The message, however, needs to be sent through the Internet from
Alice’s site to Bob’s site using
an MTA. Here two message transfer agents are needed: one client and one server. Like
most client-server programs on the Internet, the server needs to run all the time because it
does not know when a client will ask for a connection. The client, on the other hand, can
be triggered by the system when there is a message in the queue to be sent. The user agent
at the Bob site allows Bob to read the received message. Bob later uses an MAA client to
retrieve the message from an MAA server running on the second server.

There are two important points we need to emphasize here. First, Bob cannot
bypass the mail server and use the MTA server directly. To use the MTA server
directly, Bob would need to run the MTA server all the time because he does not
know when a message will arrive. This implies that Bob must keep his computer on
all the time if he is connected to his system through a LAN. If he is connected
through a WAN, he must keep the connection up all the time. Neither of these situations
is feasible today.

Second, note that Bob needs another pair of client-server programs: message
access programs. This is because an MTA client-server program is a push program: the
client pushes the message to the server. Bob needs a pull program. The client needs to
pull the message from the server. We discuss more about MAAs shortly.

The electronic mail system needs two UAs, two pairs of MTAs
(client and server), and a pair of MAAs (client and server).
 12. Explain HTTP for Non-persistence & Persistence connection

The HyperText Transfer Protocol (HTTP) is used to define how the client-server
programs can be written to retrieve web pages from the Web. An HTTP client sends a
request; an HTTP server returns a response. The server uses the port number 80; the client
uses a temporary port number. HTTP uses the services of TCP, which, as discussed
before, is a connection-oriented and reliable protocol. This means that, before any
transaction between the client and the server can take place, a connection needs to be
established between them. After the transaction, the connection should be terminated.
The client and server, however, do not need to worry about errors in messages
exchanged or loss of any message, because the TCP is reliable and will take care of this
matter, as we saw in Chapter 24.

Nonpersistent versus Persistent Connections

As we discussed in the previous section, the hypertext concept embedded in web page
documents may require several requests and responses. If the web pages, objects to be
retrieved, are located on different servers, we do not have any other choice than to create
a new TCP connection for retrieving each object. However, if some of the objects
are located on the same server, we have two choices: to retrieve each object using a new
TCP connection or to make a TCP connection and retrieve them all. The first method is
referred to as a nonpersistent connection, the second as a persistent connection. HTTP,
prior to version 1.1, specified nonpersistent connections, while persistent connections
are the default in version 1.1, but it can be changed by the user.
Nonpersistent Connections

In a nonpersistent connection, one TCP connection is made for each request/response.

The following lists the steps in this strategy:
1. The client opens a TCP connection and sends a request.
2. The server sends the response and closes the connection.
3. The client reads the data until it encounters an end-of-file marker; it then closes the
connection.
In this strategy, if a file contains links to N different pictures in different files (all
located on the same server), the connection must be opened and closed N + 1 times.
The nonpersistent strategy imposes high overhead on the server because the server
needs N + 1 different buffers each time a connection is opened.

Figure 26.3 shows an example of a nonpersistent connection. The client needs to access a file that
contains one link to an image. The text file and image are located on the same server. Here we
need two connections. For each connection, TCP requires at least three handshake messages to establish the
connection, but the request can be sent with the third one. After the connection is
established, the object can be transferred. After receiving an object, another three handshake
messages are needed to terminate the connection, as we saw in Chapter 24.

Persistent Connections
HTTP version 1.1 specifies a persistent connection by default. In a persistent connection,
the server leaves the connection open for more requests after sending a response.
The server can close the connection at the request of a client or if a time-out has been
reached. The sender usually sends the length of the data with each response. However,
there are some occasions when the sender does not know the length of the data. This is
the case when a document is created dynamically or actively. In these cases, the server
informs the client that the length is not known and closes the connection after sending
the data so the client knows that the end of the data has been reached. Time and
resources are saved using persistent connections. Only one set of buffers and variables
needs to be set for the connection at each site. The round trip time for connection establishment
and connection termination is saved.

Figure 26.4 shows the same scenario as in Example 26.3, but using a persistent connection.
Only one connection establishment and connection termination is used, but the request for the
image is sent separately.

13. Write a note on DNS .

DOMAIN NAME SYSTEM (DNS)

The last client-server application program we discuss has been designed to help other
application programs. To identify an entity, TCP/IP protocols use the IP address, which
uniquely identifies the connection of a host to the Internet. However, people prefer to
use names instead of numeric addresses. Therefore, the Internet needs to have a directory
system that can map a name to an address. This is analogous to the telephone network.
A telephone network is designed to use telephone numbers, not names. People
can either keep a private file to map a name to the corresponding telephone number or
can call the telephone directory to do so. We discuss how this directory system in the
Internet can map names to IP addresses.

Since the Internet is so huge today, a central directory system cannot hold all the
mapping. In addition, if the central computer fails, the whole communication network
will collapse. A better solution is to distribute the information among many computers
in the world. In this method, the host that needs mapping can contact the closest computer
holding the needed information. This method is used by the Domain Name
System (DNS). We first discuss the concepts and ideas behind the DNS. We then
describe the DNS protocol itself.

Figure 26.28 shows how TCP/IP uses a DNS client and a DNS server to map a
name to an address. A user wants to use a file transfer client to access the corresponding
file transfer server running on a remote host. The user knows only the file transfer server name, such as
afilesource.com. However, the TCP/IP suite needs the IP address
of the file transfer server to make the connection. The following six steps map the host
name to an IP address:
1. The user passes the host name to the file transfer client.
2. The file transfer client passes the host name to the DNS client.
3. Each computer, after being booted, knows the address of one DNS server. The
DNS client sends a message to a DNS server with a query that gives the file transfer
server name using the known IP address of the DNS server.
4. The DNS server responds with the IP address of the desired file transfer server.
5. The DNS server passes the IP address to the file transfer client.
6. The file transfer client now uses the received IP address to access the file transfer
server.

Note that the purpose of accessing the Internet is to make a connection between the file
transfer client and server, but before this can happen, another connection needs to be
made between the DNS client and DNS server. In other words, we need at least two
connections in this case. The first is for mapping the name to an IP address; the second
is for transferring files. We will see later that the mapping may need more than one
connection.