Module–5

• Application Layer
 Principles of Network Applications
Listing examples of popular network applications:
• Electronic mail
• The web
• P2P file sharing
• Multi-user networked games
• Streaming stored video clips
• Internet phone
• Real-time video conferencing
 Principles of Network Applications
• Writing programs - run on different end systems and
communicate with each other over the network.
• For example, there are two distinct programs that communicate
with each other:
-The Browser program running in the user’s host (desktop,
laptop, tablet, smartphone, and so on).
-The Web server program running in the Web server host.
• As another example, in a P2P file-sharing system there is a
program in each host that participates in the file-sharing
community.
• Write software that will run on multiple end systems.
• This software could be written, for example, in C, Java, or
Python.
• Do not need to write software that runs on network core devices,
such as routers or link-layer switches.
 Network Application Architectures
• The network architecture is fixed and provides
a specific set of services to applications.
• The application architecture, is designed by
the application developer.
In choosing the application architecture, an
application developer will likely draw on one of
the predominant architectural paradigms used in
modern network applications:
• The client-server architecture
• The peer-to-peer (P2P) architecture
 Client-Server Architecture
• In a client-server architecture, there is an
always-on host, called the server, which
services requests from many other hosts,
called clients.
• The client hosts can be either sometimes-on or
always-on.
• A classic example is the Web application for
which an always-on Web server services
requests from browsers running on client
hosts.
• Clients do not directly communicate with each
other. For example, in the Web application, two
browsers do not directly communicate.
• The server has a fixed, well-known address, called
an IP address.
• Because the server has a fixed, well-known
address, and because the server is always on, a
client can always contact the server by sending a
packet to the server’s IP address.
• Some of the better-known applications with a
client-server architecture include the Web, FTP,
Telnet, remote login and e-mail.
• In a client-server application, a single-server
host is incapable of keeping up with all the
requests from clients. For this reason, a data
center, housing a large number of hosts, is
often used to create a powerful virtual server.
• The most popular Internet services—such as
search engines (e.g., Google and Bing),
Internet commerce (e.g., Amazon and e-Bay),
Web-based email (e.g., Gmail and Yahoo
Mail), social networking (e.g., Facebook and
Twitter)— employ one or more data centers.
 Peer-to-Peer Architecture
• The application exploits direct communication
between pairs of intermittently connected hosts,
called peers.
• The peers are not owned by the service
provider, but are instead desktops and laptops
controlled by users, with most of the peers
residing in homes, universities, and offices.
• Because the peers communicate without
passing through a dedicated server, the
architecture is called peer-to-peer.
• None of the participating hosts is required to be
always on, in addition, a participating host may
change its IP address each time it comes on.
• Example for pure P2P architecture is Gnutella- an
open-source P2P file-sharing application.
• In Gnutella- any host can request files, send files,
query to find where a file is located, respond to
queries and forward queries.
• Many of today’s most popular and traffic-
intensive applications are based on P2P
architectures. These applications include file
sharing (e.g., BitTorrent), Internet Telephony
(e.g., Skype).
• Features:
• Self-scalability:
• For example, in a P2P file-sharing application,
although each peer generates workload by
requesting files, each peer also adds service
capacity to the system by distributing files to
other peers.
• Cost effective:
• P2P architectures are also cost effective, since
they normally don’t require significant server
infrastructure and server bandwidth
• Future P2P applications face three major challenges:
1. ISP Friendly. Most residential ISPs have been dimensioned for
“asymmetrical” bandwidth usage, that is, for much more
downstream than upstream traffic. But P2P video streaming and
file distribution applications shift upstream traffic from servers
to residential ISPs, thereby putting significant stress on the
ISPs. Future P2P applications need to be designed so that they
are friendly to ISPs .

2. Security. Because of their highly distributed and open nature,

P2P applications can be a challenge to secure .

3. Incentives. The success of future P2P applications also depends

on convincing users to volunteer bandwidth, storage, and
computation resources to the applications, which is the challenge of
incentive design.
 Processes Communication
• In the jargon of operating systems, it is not actually
programs but processes that communicate.
• A process can be thought of as a program that is running
within an end system.
• When processes are running on the same end system, they
can communicate with each other with interprocess
communication.
• Processes on two different end systems communicate with
each other by exchanging messages across the computer
network.
• A sending process creates and sends messages into the
network; a receiving process receives these messages and
possibly responds by sending messages back.
 Client and Server Processes
• A network application consists of pairs of processes that send
messages to each other over a network.
• The Web application a client browser process exchanges
messages with a Web server process.
• With the Web, a browser is a client process and a Web server
is a server process.
• In the context of a communication session between a pair of
processes, the process that initiates the communication is
labeled as the client. The process that waits to be contacted
to begin the session is the server.
• In the Web, a browser process initializes contact with a Web
server process; hence the browser process is the client and
the Web server process is the server.
The Interface Between the Process and the Computer
Network
• Any message sent from one process to another must go through
the underlying network.
• A process sends messages into, and receives messages from, the
network through a software interface called a socket.
• When a process wants to send a message to another process on
another host, it shoves the message out its door (socket).
• Once the message arrives at the destination host, the message
passes through the receiving process’s door (socket), and the
receiving process then acts on the message.
• Figure 5.3 illustrates socket communication between two
processes that communicate over the Internet.
• It is also referred to as the Application Programming Interface
(API) between the application and the network, since the socket is
the programming interface with which network applications are
built.
• The only control that the application developer has on the transport-
layer side is (1) the choice of transport protocol and (2) perhaps the
ability to fix a few transport-layer parameters such as maximum
buffer and maximum segment sizes.
• In order for a process running on one host to send packets to a
process running on another host, the receiving process needs to
have an address.
• Once the application developer chooses a transport protocol (if a
choice is available), the application is built using the transport-layer
services provided by that protocol.
• Two pieces of information need to be specified: (1) the address of
the host and (2) an identifier that specifies the receiving process in
the destination host.
• This information is needed because in general a host could be
running many network applications.
• A destination port number serves this purpose.
• Popular applications have been assigned specific port numbers.
 Transport Services Available to Applications

• Many networks, including the Internet, provide

more than one transport-layer protocol.
• When you develop an application, you must
choose one of the available transport-layer
protocols.
• How do you make this choice?
• Most likely, you would study the services
provided by the available transport-layer
protocols, and then pick the protocol with the
services that best match your application’s needs.
We can broadly classify the possible services
along four dimensions:

• Reliable data transfer

• Throughput
• Timing
• Security
Reliable Data Transfer
• Packets can get lost within a computer
network.
• For example, a packet can overflow a buffer in
a router, or can be discarded by a host or router
after having some of its bits corrupted.
• For many applications data loss can have
devastating consequences.
• If a protocol provides a guaranteed data
delivery service, it is said to provide reliable
data transfer.
Throughput
• In the context of a communication session between two
processes along a network path, is the rate at which the
sending process can deliver bits to the receiving process.
• Applications that have throughput requirements are said to be
bandwidth-sensitive applications. Many current multimedia
applications are bandwidth sensitive.

• While bandwidth-sensitive applications have specific

throughput requirements, elastic applications can make use
of as much, or as little, throughput as happens to be available.

• For example, Electronic mail, file transfer, and Web transfers

are all elastic applications.
Timing
• A transport-layer protocol can also provide
timing guarantees.
• An example guarantee might be that every bit
that the sender pumps into the socket arrives at
the receiver’s socket no more than 100 msec later.
• Interactive real-time applications, such as Internet
telephony, virtual environments,
teleconferencing, and multiplayer games, all of
which require tight timing constraints on data
delivery in order to be effective.
Security
• Finally, a transport protocol can provide an
application with one or more security services.
• Provide confidentiality between the two
processes.
• A transport protocol can also provide other
security services in addition to confidentiality,
including data integrity and end-point
authentication.
 Transport Services Provided by the
Internet
• The Internet makes two transport protocols available
to applications, UDP and TCP.
• When you create a new network application for the
Internet, one of the first decisions you have to make
is whether to use UDP or TCP.
• Each of these protocols offers a different set of
services to the invoking applications.
TCP Services
• The TCP service model includes:
- connection-oriented service and
- reliable data transfer service.
 Connection-oriented service
• TCP has the client and server exchange transport layer
control information with each other before the
application-level messages begin to flow.
• This so-called handshaking procedure alerts the client
and server, allowing them to prepare for an onslaught of
packets.
• After the handshaking phase, a TCP connection is said
to exist between the sockets of the two processes.
• The connection is a full-duplex connection in that the
two processes can send messages to each other over the
connection at the same time.
• When the application finishes sending messages, it must
tear down the connection.
 Reliable data transfer service
• The communicating processes can rely on TCP
to deliver all data sent without error and in the
proper order.

• When one side of the application passes a

stream of bytes into a socket, it can count on
TCP to deliver the same stream of bytes to the
receiving socket, with no missing or duplicate
bytes.
 UDP Services
• UDP is connectionless, so there is no
handshaking before the two processes start to
communicate.
• UDP provides an unreliable data transfer
service—that is, when a process sends a
message into a UDP socket, UDP provides no
guarantee that the message will ever reach the
receiving process.
• Furthermore, messages that do arrive at the
receiving process may arrive out of order.
• Application-Layer Protocols
• An application-layer protocol defines how an application’s
processes, running on different end systems, pass messages to each
other .
• In particular, an application-layer protocol defines:
• The types of messages exchanged, for example, request messages
and response messages
• The syntax of the various message types.
• The semantics of the fields.
• Some application-layer protocols are specified in RFCs and are
therefore in the public domain.
• Many other application-layer protocols are proprietary and
intentionally not available in the public domain. For example, Skype
uses proprietary application-layer protocols.
• Protocols that define how messages are passed between servers, and
mail clients, and how the contents of message headers are to be
interpreted.
The Web and HTTP

• In the early 1990s, a major new application arrived on the

scene—the World Wide Web.
• The Web was the first Internet application.
• It dramatically changed, and continues to change, how people
interact inside and outside their work environments.
• Perhaps what appeals the most to users is that the Web operates
on demand. Users receive what they want, when they want it.
• Hyperlinks and search engines help us navigate through an
ocean of Web sites.
• The Web serves as a platform for many killer applications
emerging after 2003, including YouTube, Gmail, and Facebook.
 Overview of HTTP
• The HyperText Transfer Protocol (HTTP),
the Web’s application-layer protocol, is at the
heart of the Web.
• HTTP is implemented in two programs: a client
program and a server program.
• The client program and server program,
executing on different end systems, talk to each
other by exchanging HTTP messages.
• HTTP defines the structure of these messages
and how the client and server exchange the
messages.
• A Web page (also called a document) consists of objects.

• An object is simply a file—such as an HTML file, a JPEG image,

a Java applet, or a video clip—that is addressable by a single
URL.

• Most Web pages consist of a base HTML file and several

referenced objects.
• The base HTML file references the other objects in the page with
the objects’ URLs.

• Each URL has two components: the hostname of the server that
houses the object and the object’s path name.

• For example, the URL

http://www.someSchool.edu/someDepartment/picture.gif
• A Web browser is a user agent for the web, it displays the
requested web page to the user and provides numerous
navigational and configuration features.

• Web browsers also implement the client side of HTTP.

• Popular web browsers include Netscape Communicator and

Microsoft Internet Explorer.
• A Web server houses Web objects, each addressable by a
URL.

• Web servers also implement the server side of HTTP.

• Popular Web servers include Apache and Microsoft Internet

Information Server.
• HTTP defines how Web clients request Web
pages from Web servers and how servers
transfer Web pages to clients.
• When a user requests a Web page (for
example, clicks on a hyperlink), the browser
sends HTTP request messages for the objects
in the page to the server.
• The server receives the requests and responds
with HTTP response messages that contain the
objects.
HTTP request-response behavior
• HTTP uses TCP as its underlying transport protocol.

• The HTTP client first initiates a TCP connection with the

server.

• Once the connection is established, the browser and the

server processes access TCP through their socket interfaces.
• It is important to note that the server sends requested files to
clients without storing any state information about the client.

• If a particular client asks for the same object twice in a period

of a few seconds, the server resends the object.

• Because an HTTP server maintains no information about the

clients, HTTP is said to be a stateless protocol.
 Non-Persistent and Persistent
Connections
• HTTP, which can use both non-persistent
connections and persistent connections.
• Although HTTP uses persistent connections in
its default mode.
• HTTP clients and servers can be configured to
use non-persistent connections instead.
 HTTP with Non-Persistent Connections
• The steps of transferring a Web page from
server to client for the case of non-persistent
connections.
• Suppose the page consists of a base HTML file
and 10 JPEG images, and that all 11 of these
objects reside on the same server.
• Suppose the URL for the base HTML file is:
http://www.someSchool.edu/someDepartment/
home.index
1. The HTTP client process initiates a TCP connection to the
server www.someSchool.edu on port number 80, which is
the default port number for HTTP.

2. The HTTP client sends an HTTP request message to the

server via its socket. The request message includes the
path name /someDepartment/home.index.
3. The HTTP server process receives the request message via
its socket, retrieves the object
/someDepartment/home.index from its storage,
encapsulates the object in an HTTP response message, and
sends the response message to the client via its socket.

4. The HTTP server process tells TCP to close the TCP

connection.
5. The HTTP client receives the response
message. The TCP connection terminates. The
message indicates that the encapsulated object is
an HTML file. The client extracts the file from
the response message, examines the HTML file,
and finds references to the 10 JPEG objects.

6. The first four steps are then repeated for each

of the referenced JPEG objects.
• Each TCP connection is closed after the server
sends the object—the connection does not
persist for other objects.

• Note that each TCP connection transports

exactly one request message and one response
message.

• Thus, in this example, when a user requests the

Web page, 11 TCP connections are generated.
 Round-Trip Time
• The round-trip time (RTT), which is the time it
takes for a small packet to travel from client to
server and then back to the client.

• The RTT includes packet-propagation delays,

packet-queuing delays in intermediate routers
and switches, and packet-processing delays.
HTTP with Persistent Connections
• With persistent connections, the server leaves
the TCP connection open after sending a
response.
• Subsequent requests and responses between
the same client and server can be sent over the
same connection.
• In particular, an entire Web page can be sent
over a single persistent TCP connection.
• The HTTP server closes a connection when it
isn’t used for a certain time.
• There are two versions of persistent
connections: without pipelining and with
pipelining.
• Without pipelining- the client issues a new
request only when the previous response has
been received.
• With pipelining- client issues a request as soon
as it encounters a reference. It can make a new
request before receiving a response to a
previous request.
 HTTP Message Format
• The HTTP specifications include the
definitions of the HTTP message formats.

• There are two types of HTTP messages,

request messages and response messages.
 HTTP Request Message
A typical HTTP request message:

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
• The first line of an HTTP request message is
called the request line; the subsequent lines
are called the header lines.

• The request line has three fields: the method

field, the URL field, and the HTTP version
field.

• The method field can take on several different

values, including GET, POST, HEAD, PUT,
and DELETE.
• The great majority of HTTP request messages
use the GET method.

• The GET method is used when the browser

requests an object, with the requested object
identified in the URL field.

• In this example, the browser is requesting the

object /somedir/page.html. The version is
self-explanatory; in this example, the browser
implements version HTTP/1.1.
• The header line Host: www.someschool.edu
specifies the host on which the object resides.

• By including the Connection: close header

line, the browser is telling the server that it
doesn’t want to bother with persistent
connections; it wants the server to close the
connection after sending the requested object.
• The User-agent: header line specifies the user
agent, that is, the browser type that is making
the request to the server.
• Here the user agent is Mozilla/5.0, a Firefox
browser.
• Finally, the Accept-language: header indicates
that the user prefers to receive a French
version of the object, if such an object exists
on the server; otherwise, the server should
send its default version.
Fig:HTTP Request Message
 HTTP Response Message

• A typical HTTP response message is:

HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(data data data data data ...)

• It has three sections: an initial status line, six
header lines, and then the entity body.

• The entity body contains the requested object

itself (represented by data data data data
data ...).

• The status line has three fields: the protocol

version field, a status code, and a
corresponding status message.
• In this example, the status line indicates that
the server is using HTTP/1.1 and that
everything is OK.
• The server uses the Connection: close header
line to tell the client that it is going to close the
TCP connection after sending the message.
• The Date: header line indicates the time and
date when the HTTP response was created and
sent by the server.
• The Server: header line indicates that the
message was generated by an Apache Web
server; it is analogous to the User-agent:
header line in the HTTP request message.

• The Last-Modified: header line indicates the

time and date when the object was created or
last modified.
• The Content-Length: header line indicates the
number of bytes in the object being sent.

• The Content-Type: header line indicates that

the object in the entity body is HTML text.
• The status code and associated phrase indicate
the result of the request.
• Some common status codes and associated
phrases include:
-200 OK: Request succeeded and the
information is returned in the response.

-301 Moved Permanently: Requested

object has been permanently moved.
 -400 Bad Request: This is a generic error
code indicating that the request could not be
understood by the server.

-404 Not Found: The requested document

does not exist on this server.

-505 HTTP Version Not Supported: The

requested HTTP protocol version is not
supported by the server.
 User-Server Interaction: Cookies
• Cookies, allow sites to keep track of users.
• Most major commercial Web sites use cookies
today.
• Cookie technology has four components:
(1) a cookie header line in the HTTP response
message;
(2) a cookie header line in the HTTP request
message;
(3) a cookie file kept on the user’s end system and
managed by the user’s browser; and
(4) a back-end database at the Web site.
special cookie file
• Ex: Suppose a user, who always accesses the Web using Internet Explorer from
her home PC, contacts Amazon.com for the first time. Let us suppose that in the
past he has already visited the eBay site. When the request comes into the
Amazon Web server, the server creates a unique identification number and
creates an entry in its back-end database that is indexed by the identification
number. The Amazon Web server then responds to Susan’s browser, including in
the HTTP response a Set-cookie: header, which contains the identification
number.
• For example, the header line might be:
• Set-cookie: 1678
• When users browser receives the HTTP response message, it sees the Set-cookie:
header. The browser then appends a line to the special cookie file that it
manages. This line includes the hostname of the server and the identification
number in the Set-cookie: header.
• As user continues to browse the Amazon site, each time he requests a Web page,
his browser consults his cookie file, extracts his identification number for this
site, and puts a cookie header line that includes the identification number in the
HTTP request. Specifically, each of his HTTP requests to the Amazon server
includes the header line:
• Cookie: 1678
 Web Caching
• A Web cache also called a proxy server—is a
network entity that satisfies HTTP requests on
the behalf of an origin Web server.
• The Web cache has its own disk storage and
keeps copies of recently requested objects in
this storage.
• A user’s browser can be configured so that all
of the user’s HTTP requests are first directed
to the Web cache.
Clients requesting objects through a Web cache
• As an example, suppose a browser is
requesting the object
http://www.someschool.edu/campus.gif.
• Here is what happens:
1. The browser establishes a TCP
connection to the Web cache and sends an HTTP
request for the object to the Web cache.
2. The Web cache checks to see if it has a
copy of the object stored locally. If it does, the
Web cache returns the object within an HTTP
response message to the client browser.
 3. If the Web cache does not have the object, the Web
cache opens a TCP connection to the origin server, that is,
to www.someschool.edu.

The Web cache then sends an HTTP request for the

object into the cache-to-server TCP connection.
After receiving this request, the origin server sends the
object within an HTTP response to the Web cache.
4. When the Web cache receives the object, it stores a
copy in its local storage and sends a copy, within an HTTP
response message, to the client browser (over the existing
TCP connection between the client browser and the Web
cache).
 The Conditional GET
• The copy of an object residing in the cache may
be stale.
• The object housed in the Web server may have
been modified since the copy was cached at the
client.
• HTTP has a mechanism that allows a cache to
verify that its objects are up to date. This
mechanism is called the conditional GET.
• An HTTP request message is a so-called conditional
GET message if
(1) the request message uses the GET method
and
(2) the request message includes an If-Modified-
Since: header line.

• First, on the behalf of a requesting browser, a proxy

cache sends a request message to a Web server:

GET /fruit/kiwi.gif HTTP/1.1

Host: www.exotiquecuisine.com
• Second, the Web server sends a response
message with the requested object to the
cache:

HTTP/1.1 200 OK
Date: Sat, 8 Oct 2011 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 7 Sep 2011 09:23:24
Content-Type: image/gif

(data data data data data ...)

• Third, one week later, another browser requests
the same object via the cache, and the object is
still in the cache.
• Since this object may have been modified at the
Web server in the past week, the cache performs
an up-to-date check by issuing a conditional GET.
• Specifically, the cache sends:
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 7 Sep 2011 09:23:24
• This conditional GET is telling the server to
send the object only if the object has been
modified since the specified date.
• Suppose the object has not been modified
since 7 Sep 2011 09:23:24.
• Then, fourth, the Web server sends a response
message to the cache:
HTTP/1.1 304 Not Modified
Date: Sat, 15 Oct 2011 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)
 File Transfer: FTP

FTP moves files between local and remote file systems

 File Transfer: FTP
• The user interacts with FTP through an FTP user agent.

• The user first provides the hostname of the remote host,

causing the FTP client process in the local host to establish
a TCP connection with the FTP server process in the
remote host.
• The user then provides the user identification and
password, which are sent over the TCP connection as part
of FTP commands.

• Once the server has authorized the user, the user copies one
or more files stored in the local file system into the remote
file system (or vice versa).
• HTTP and FTP are both file transfer protocol and have
many common characteristics . Ex Both runs on top of
TCP.
• The two application-layer protocols have some important
differences.
• The most striking difference is that FTP uses two parallel
TCP connections to transfer a file, a control connection
and a data connection.
• The control connection is used for sending control
information between the two hosts—information such as
user identification, password, commands to change
remote directory, and commands to “put” and “get” files.
• The data connection is used to actually send a file.
Control and data connections
 FTP Commands and Replies

• The commands, from client to server, and

replies, from server to client, are sent across
the control connection in 7-bit ASCII format.
• FTP commands are readable by people.
• Each command consists of four uppercase
ASCII characters, some with optional
arguments.
Some of the more common commands are given
below:
• USER username: Used to send the user
identification to the server.
• PASS password: Used to send the user password
to the server.
• LIST: Used to ask the server to send back a list of
all the files in the current remote directory.
• RETR filename: Used to retrieve (that is, get) a file
from the current directory of the remote host.
• STOR filename: Used to store (that is, put) a file into
the current directory of the remote host.
• Each command is followed by a reply, sent
from server to client.
• The replies are three-digit numbers, with an
optional message following the number.
• Some typical replies, along with their possible
messages, are as follows:
- 331 Username OK, password required
- 125 Data connection already open; transfer
starting
- 425 Can’t open data connection
- 452 Error writing file
 Electronic Mail in the Internet
• E-mail is an asynchronous communication
medium—people send and read messages
when it is convenient for them, without having
to coordinate with other people’s schedules.
• Electronic mail is fast, easy to distribute, and
inexpensive.
• Modern e-mail has many powerful features,
including messages with attachments,
hyperlinks, HTML-formatted text, and
embedded photos.
• It has three major components: user agents,
mail servers, and the Simple Mail Transfer
Protocol (SMTP).

• User agents allow users to read, reply to,

forward, save, and compose messages.

• Microsoft Outlook and Apple Mail are

examples of user agents for e-mail.
• When Alice is finished composing her
message, her user agent sends the message to
her mail server, where the message is placed in
the mail server’s outgoing message queue.

• When Bob wants to read a message, his user

agent retrieves the message from his mailbox
in his mail server.
• Each recipient has a mailbox located in one of
the mail servers.
• Mailbox manages and maintains the messages
that have been sent to him.
• A typical message starts its journey in the
sender’s user agent, travels to the sender’s
mail server, and travels to the recipient’s mail
server, where it is deposited in the recipient’s
mailbox.
• SMTP is the principal application-layer
protocol for Internet electronic mail.

• It uses the reliable data transfer service of TCP

to transfer mail from the sender’s mail server
to the recipient’s mail server.

• SMTP has two sides: a client side and a server

side.
 SMTP
• SMTP is at the heart of Internet electronic
mail.
• SMTP transfers messages from senders’ mail
servers to the recipients’ mail servers.
• SMTP is much older than HTTP.
• It restricts the body of all mail messages to
simple 7-bit ASCII.
Alice sends a message to Bob
1. Alice invokes her user agent for e-mail, provides Bob’s e-
mail address (for example, [email protected]), composes a
message, and instructs the user agent to send the message.
2. Alice’s user agent sends the message to her mail server,
where it is placed in a message queue.
3. The client side of SMTP, running on Alice’s mail server,
sees the message in the message queue. It opens a TCP
connection to an SMTP server, running on Bob’s mail server.
4. After some initial SMTP handshaking, the SMTP client
sends Alice’s message into the TCP connection.
5. At Bob’s mail server, the server side of SMTP receives the
message. Bob’s mail server then places the message in Bob’s
mailbox.
6. Bob invokes his user agent to read the message at his
convenience.
 Comparison with HTTP
• Both protocols are used to transfer files from one host
to another.
• When transferring the files, both persistent HTTP and
SMTP use persistent connections.
• Thus, the two protocols have common characteristics.
• First difference is, HTTP is mainly a pull protocol—
someone loads information on a Web server and users
use HTTP to pull the information from the server at
their convenience.
• SMTP is primarily a push protocol—the sending mail
server pushes the file to the receiving mail server.
• A second difference, is that SMTP requires
each message, including the body of each
message, to be in 7-bit ASCII format.
• HTTP data does not impose this restriction.
• A third important difference concerns how a
document consisting of text and images is
handled.
• HTTP encapsulates each object in its own
HTTP response message.
• Internet mail places all of the message’s
objects into one message.
 Mail Message Formats
• When an e-mail message is sent from one
person to another, a header containing
peripheral information precedes the body of
the message itself.
• This peripheral information is contained in a
series of header lines.
• The header lines and the body of the message
are separated by a blank line.
• As with HTTP, each header line contains readable text,
consisting of a keyword followed by a colon followed
by a value.
• Every header must have a From: header line and a To:
header line;
• A header may include a Subject: header line as well as
other optional header lines.
• A typical message header looks like this:

From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.
 Mail Access Protocols
• Introducing a special mail access protocol that
transfers messages from recipient’s mail server
to his local PC.
• There are currently a number of popular mail
access protocols, including
-Post Office Protocol—Version 3 (POP3).
-Internet Mail Access Protocol (IMAP).
-HTTP.
E-mail protocols and their communicating entities
 POP3
• POP3 is short and quite readable.

• POP3 begins when the user agent (the client)

opens a TCP connection to the mail server.

• With the TCP connection established, POP3

progresses through three phases:
authorization, transaction, and update.
• During the first phase, authorization, the user
agent sends a username and a password to
authenticate the user.
• During the second phase, transaction, the user
agent retrieves messages; also during this
phase, the user agent can mark messages for
deletion, remove deletion marks, and obtain
mail statistics.
• The third phase, update, occurs after the client
has issued the quit command, ending the POP3
session; at this time, the mail server deletes the
messages that were marked for deletion.
 IMAP
• An IMAP server will associate each message with
a folder; when a message first arrives at the server,
it is associated with the recipient’s INBOX folder.
• The recipient can then move the message into a
new, user-created folder, read the message, delete
the message, and so on.
• The IMAP protocol provides commands to allow
users to create folders and move messages from
one folder to another.
• IMAP also provides commands that allow users to
search remote folders for messages matching
specific criteria.
 Web-Based E-Mail
• In this, the user agent is an ordinary Web browser,
and the user communicates with its remote
mailbox via HTTP.
• When a recipient, such as Bob, wants to access a
message in his mailbox, the e-mail message is sent
from Bob’s mail server to Bob’s browser using the
HTTP protocol rather than the POP3 or IMAP
protocol.
• When a sender, such as Alice, wants to send an e-
mail message, the e-mail message is sent from her
browser to her mail server over HTTP rather than
over SMTP.
 DNS—The Internet’s Directory Service
• One identifier for a host is its hostname.

• Hostnames—such as cnn.com, www.yahoo. com, gaia.cs.umass.edu,

and cis.poly.edu

• Hostnames provide little, if any, information about the location within

the Internet of the host.
• Hosts are also identified by so-called IP addresses.

• An IP address consists of four bytes and has a rigid hierarchical

structure.

• An IP address looks like 121.7.106.83, where each period separates

one of the bytes expressed in decimal notation from 0 to 255.
 Services Provided by DNS
• We need a directory service that translates hostnames to IP
addresses.
• This is the main task of the Internet’s domain name
system (DNS).
• The DNS is
(1) a distributed database implemented in a hierarchy of
DNS servers, and
(2) an application-layer protocol that allows hosts to
query the distributed database.
• The DNS protocol runs over UDP and uses port 53.
• DNS is commonly employed by other application-layer
protocols—including HTTP, SMTP, and FTP—to translate
user-supplied hostnames to IP addresses.
 Overview of How DNS Works
• A simple design for DNS would have one
DNS server that contains all the mappings.

• In this centralized design, clients simply direct

all queries to the single DNS server, and the
DNS server responds directly to the querying
clients.

• A centralized database in a single DNS server

simply doesn’t scale.
The problems with a centralized design include:
• A single point of failure: if the DNS server
crashes, so does the entire Internet.
• Traffic volume: a single DNS server would
have to handle all DNS queries.
• Distant centralized database: a single DNS
server cannot be “close to” all the querying
clients.
• Maintenance: The single DNS server would
have to keep records for all Internet hosts.
 A Distributed, Hierarchical Database

• In order to deal with the issue of scale, the

DNS uses a large number of servers, organized
in a hierarchical fashion and distributed
around the world.
• No single DNS server has all of the mappings
for all of the hosts in the Internet.
• Instead, the mappings are distributed across
the DNS servers.
• To a first approximation, there are three
classes of DNS servers—
- Root DNS servers
- Top-level domain (TLD) DNS servers
- Authoritative DNS servers
Portion of the hierarchy of DNS servers
Interaction of Servers/DNS Caching
 DNS Caching
• DNS caching is a critically important feature
of the DNS system.

• DNS extensively exploits DNS caching in

order to improve the delay performance and to
reduce the number of DNS messages
ricocheting around the Internet.
 DNS Records and Messages
• The DNS servers that together implement the
DNS distributed database store resource
records (RRs), including RRs that provide
hostname-to-IP address mappings.
• Each DNS reply message carries one or more
resource records.
• A resource record is a four-tuple that contains
the following fields:
(Name, Value, Type, TTL)
• TTL is the time to live of the resource record;
it determines when a resource should be
removed from a cache.
• The meaning of Name and Value depend on
Type:
• If Type=A, then Name is a hostname and
Value is the IP address for the hostname.
• If Type=NS, then Name is a domain and Value
is the hostname of an authoritative DNS
server.
• If Type=CNAME, then Value is a canonical
hostname for the alias hostname Name.

• If Type=MX, then Value is the canonical name

of a mail server that has an alias hostname
Name.
DNS Messages

DNS message format

• The first 12 bytes is the header section, which
has a number of fields.
• The first field is a 16-bit number that identifies
the query.
• There are a number of flags in the flag field.
• In the header, there are also four number-of
fields.
• These fields indicate the number of
occurrences of the four types of data sections
that follow the header.
• The question section contains information
about the query that is being made.
• This section includes :
(1) a name field that contains the name that
is being queried.
(2) a type field that indicates the type of
question being asked about the name.
• In a reply from a DNS server, the answer section
contains the resource records for the name that was
originally queried.

• The authority section contains records of other

authoritative servers.