Chapter 2

Application
Layer

A note on the use of these ppt slides:

Computer
We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
Networking: A
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only
Top Down
ask the following:
 If you use these slides (e.g., in a class) that you mention their source
Approach
(after all, we’d like people to use our book!) 6th edition
 If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith
from (or perhaps identical to) our slides, and note our copyright of this
material.
Ross
Addison-Wesley
Thanks and enjoy! JFK/KWR
March 2012
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved

Application Layer 2-1

Chapter 2: outline
2.1 Principles of Network
Applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail
 SMTP, POP3, IMAP
2.5 DNS
2.6 Peer-to-Peer Applications
2.7 Socket Programming with
UDP and TCP

Application Layer 2-2

Chapter 2: application
layer
our goals:
 conceptual, implementation aspects of network
application protocols
 transport-layer service models
 client-server paradigm
 peer-to-peer paradigm
 learn about protocols by examining popular
application-level protocols
 HTTP
 FTP
 SMTP / POP3 / IMAP
 DNS
 creating network applications
 socket API

Application Layer 2-3

Network Applications
 A Network application is an application running on one
host and provides a communication to another
application running on a different host.
 A network application development is writing programs
that run on different end systems and communicate
with each other over the network.
 In the Web application there are two different
programs that communicate with each other:
 Browser program running in the user's host.
 Web server program running in the Web server host.

Host Host

P2P file sharing

Web application
Network Applications - Examples
 Email
 Web
 Remote Login
 P2P File Sharing
 Multi-user Network Games
 Streaming Stored Video
(YouTube)
 Voice Over IP (Skype)
 Real-time Video Conference
 Social Networking
Creating a network app application
transport
network
data link

write programs that: physical

 run on (different) end

systems
 communicate over
network
 e.g., web server
software communicates
with browser software application
transport
network
no need to write software data link
physical
application
transport
for network-core network
data link
devices physical

 network-core devices
do not run user
applications
 applications on end
systems allows for Application Layer 2-6
Application architectures
possible structure of applications:
 client-server
 peer-to-peer (P2P)

Application Layer 2-7

 Client-server architecture
server:
 always-on host
 permanent IP address
 Large cluster of hosts- data
centers for scaling
 Eg: Web Server

clients:
 communicate with server
client/server  Its not like continuously
connected
 may have dynamic IP
addresses
 do not communicate directly
with each other
Eg: Web, FTP, Telnet, E-mail Eg. Mobiles, PCs Application Layer 2-8
P2P architecture
 no always-on server peer-peer
 Peers (end systems) directly
communicate.
 peers request service from
other peers, provide service
in return to other peers
 self scalability – new
peers bring new service
capacity, as well as new
service demands
 peers are intermittently
connected and change IP
addresses
 complex management
 Eg: BitTorrent, Skype, IPTV
Application Layer 2-9
Processes communicating
process: program running within a host
 within same host, two processes communicate
using inter-process communication (defined by OS)
 processes in different hosts communicate by
exchanging messages
 client process: process that initiates communication
 server process: process that waits to be contacted
 aside: applications with P2P architectures have
client processes & server processes
Process
Process P2
P1

Application Layer 2-10

Sockets
 A process sends messages into and receives
messages from; the network through a software
interface called a socket.
 A process is like a house and its socket is like its door.
 Sending process passes message outdoor.
 Sending process relies on transport infrastructure on other
side of door to deliver message to socket at receiving
process.
Proces
s
applicati applicati
socket on
controlled by
on
process process app developer

transpor transpor
t t controlled
network network
link
by OS
link Internet
Socket physical physical
Addressing processes
 to receive messages, process must have identifier
 host device has unique 32-bit IP address
 Q: does IP address of host on which process runs
suffice for identifying the process?
 A: no, many processes can be running on
same host
 identifier includes both IP address and port
numbers associated with process on host.
 example port numbers:
 HTTP server: 80
 mail server: 25
 to send HTTP message to [Link] web
server:
 IP address: [Link]
 port number: 80
 more shortly…
Application Layer 2-12
Transport Services to Applications
 Recall that a socket is the interface between the
application process and the transport layer protocol.
 For develop an application, choose available transport
layer protocol.
 Pick the protocol with the services that best match the
needs of your application.
 Example: Choose either Train or Airplane transport for
travel between two cities.
 Classify services with four parameters:

Reliabl
e Data Throug Securit
Timing
Transfe hput y
r
Transport Services to Applications
 Reliable Data Transfer:
 Many applications (e.g., email, file transfer, financial
applications) require 100% reliable data transfer
 Required guarantee that data sent by one end of application
is delivered correctly and completely to the other end of
application.
 This guaranteed data delivery service is called Reliable Data
Transfer.
 When it will fail to deliver reliable data transfer, it is
acceptable for loss-tolerant applications.
 Loss-tolerant Applications (e.g., audio/video) can tolerate
some loss.
Transport Services to Applications
Throughput
 Some apps (e.g., multimedia) require at least amount of
throughput to be “effective”
 Bandwidth sensitive application, specific throughput required.
 Elastic application (eg. Email, file transfer, Web transfer) can
use of as much, or as little, throughput as happens to be
available.
Timing
 some apps (e.g., Internet telephony, teleconferencing,
multiplayer games) require tight timing constraints on data
delivery in order to be effective.
 For non-real-time applications, lower delay is always
preferable to higher delay, but no tight constraint is placed on
the end-to-end delays.
Security
 In the sending host, encrypt all data transmitted by the
sending process.
 In the receiving host, decrypt the data before delivering the
Transport service requirements: common
apps

application data loss throughput time sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time loss-tolerant audio: 5kbps-1Mbps yes, 100s msec
audio/video video:10kbps-5Mbps
Streaming stored loss-tolerant same as above yes, few secs
audio/video
interactive games loss-tolerant few kbps-10kbps yes, 100s msec
text messaging no loss elastic yes and no

Application Layer 2-16

 Internet transport protocols
services
 TCP Service:  UDP Services:
 Connection-Oriented: A  Connectionless: No
setup required between connection before two
client and server processes processes start to
 Reliable data transfer communicate.
between sending and  Unreliable data transfer
receiving process without between sending and
error and proper order receiving process
 Congestion control: To  It does not provide
control sender when network congestion control.
overloaded  It does not provide.
 It does not provide, Timing, Reliability, flow control,
at least throughput throughput guarantee,
guarantee (not preferred in security.
real-time application)

Application Layer 2-17

Securing TCP

TCP & UDP SSL is at app layer

 no encryption  Apps use SSL
 Clear text libraries, which
passwords sent “talk” to TCP
into socket SSL socket API
traverse Internet  Clear text
in clear text passwords sent
SSL into socket
 provides traverse Internet
encrypted TCP encrypted
connection  See Chapter 7
 data integrity
 end-point Application Layer 2-18
Internet apps: application, transport
protocols
application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP

Internet telephony SIP, RTP [RFC 1889],

proprietary(e.g., Skype) TCP or UDP

Application Layer 2-19

App-layer protocol defines
 types of messages exchanged,
 e.g., request, response
 message syntax:

 what fields in messages & how fields are

delineated
 message semantics

 meaning of information in fields

 rules for when and how processes send & respond
to messages
open protocols:
 defined in RFCs
 allows for interoperability
 e.g., HTTP, SMTP

proprietary protocols:
 e.g., Skype Application Layer 2-20
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-21

Web
 Early 1990, Internet was used only by researchers,
academics, and university students.
 New application WWW arrived in 1994 by Tim Berners-Lee.
 World Wide Web - is an information where documents and
other web resources are identified by URL, interlinked by
hypertext links, and can be accessed via the Internet.
 On demand available, What they want, When they want it.
 Unlike TV and Radio.
 Navigate through Websites.
Web and HTTP
 Web page consists of objects.
 Object can be HTML file, JPEG image, Java applet,
audio file etc.…
 Web page consists of base HTML-file which includes
several referenced objects.
Web Page (e.g Total five objects)

 Each object is addressable by a Uniform Resource

Locator (URL), like;

[Link]/someDept/[Link]

host name path name

 HTTP overview
HTTP: hypertext
transfer protocol HT
 Web’s application layer TP
req
protocol PC running HT
ues
t
Firefox browser TPr
 client/server model esp
ons
 client: browser that e
requests, receives, t
(using HTTP u es
req server
protocol) and HT
T P
po
nse
running
“displays” Web P res
Apache Web
objects HT
T
server
 server: Web server
sends (using HTTP iphone running
protocol) objects in Safari browser
response to
requests
Application Layer 2-24
HTTP overview (continued)
uses TCP: HTTP is
 client initiates TCP “stateless”
connection (creates  server maintains
socket) to server, no information
port 80 about past client
requests
 server accepts TCP aside
connection from client protocols that maintain
 HTTP messages “state” are complex!
(application-layer
 past history (state) must
be maintained
protocol messages)  if server/client crashes,
exchanged between their views of “state”
browser (HTTP client) may be inconsistent,
and Web server (HTTP must be reconciled
server)
 TCP connection closed
Application Layer 2-25
Non-persistent & Persistent Connection
 In Client-Server communication, Client making a series
of requests to server, Server responding to each of the
requests.
 Series of requests may be made back-to-back or
periodically at regular time interval.
 So, Application developer need to make an important
decision;
 Should each request/response pair be sent over a separate
TCP connection.
 OR should all the requests and corresponding responses be
sent over same TCP connection?
HTTP connections
non-persistent HTTP persistent HTTP
 at most one object sent
 multiple
over TCP
objects
connection can be sent over
single TCP
 connection then closed
connection
 downloading multiple objects required
multiple connections between client,
server

Application Layer 2-27

Non-persistent HTTP
 A non-persistent connection is closed after the server
sends the requested object to the client.
 The connection is used exactly for one request and one
response.
 For downloading multiple objects, it required multiple
connections.
 Non-persistent connections are the default mode for
HTTP/1.0.
 Example:
 Transferring a webpage from server to client, webpage
consists of a base HTML file and 10 JPEG images.
 Total 11 object are residing on server.
 Non-persistent HTTP
suppose user enters URL: (contains text,
[Link]/someDepartment/[Link] references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
[Link] on [Link]
port 80 waiting for TCP
connection at port 80.
2. HTTP client sends HTTP “accepts” connection,
request message notifying client
(containing URL) into TCP 3. HTTP server receives
connection socket. request message, forms
Message indicates that response message
client wants object containing requested
someDepartment/home.i object, and sends
time ndex message into its socket
Application Layer 2-29
 Non-persistent HTTP (cont.)
4. HTTP server closes TCP
connection.
5. HTTP client receives
response message
containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
time
6. Steps 1-5 repeated for
each of 10 jpeg objects

Application Layer 2-30

Non-persistent HTTP: response
time
RTT (Round Trip Time): time
for a small packet to
travel from client to
server and back
initiate TCP
HTTP response time: connection
 one RTT to initiate TCP RTT
connection request
 one RTT for HTTP request file
time to
and first few bytes of RTT transmit
HTTP response to return file
file
 file transmission time received
 non-persistent HTTP
response time = time time
2RTT+ file
transmission time
Application Layer 2-31
 Persistent HTTP
non-persistent HTTP issues:
 requires 2 RTTs per object
 OS overhead for each TCP connection
 browsers often open parallel TCP connections to fetch referenced
objects
persistent HTTP:
 server leaves connection open after sending response
 subsequent HTTP messages between same
client/server sent over open connection
 The server closes the connection only when it is not
used for a certain configurable amount of time.
 It requires as little as one round-trip time (RTT) for all
the referenced objects.
 Persistent connections are the default mode for
HTTP/1.1.

Application Layer 2-32

 HTTP request message
 two types of HTTP messages: request,
response
 HTTP request message:
 ASCII (human-readable format) carriage return character
line-feed character
request line
(GET, POST, GET /[Link] HTTP/1.1\r\n
HEAD commands) Host: [Link]\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
headerAccept-Language: en-us,en;q=0.5\r\n
linesAccept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
Application Layer 2-33
HTTP Request Message -
Format
 The request line has three fields: Method field, URL
field, and HTTP version field.
 The method field can take on several different values,
including GET, POST, HEAD, PUT, and DELETE.
 In above message, browser is requesting the object
/somedir/[Link] ([Link]) and version is self-
explanatory; browser implements version HTTP/1.1.
 The header line Host: [Link] specifies
the host on which the object resides.
 User agent indicate browser name and version.
HTTP request message: general
format
method sp URL sp version cr lf request
line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

Application Layer 2-35

Uploading form input
POST method:
 web page often
includes form input
 input is uploaded to
server in entity body

URL method:
 uses GET method
 input is uploaded in
URL field of request
line:
[Link]/animalsearch?monkeys&banana

Application Layer 2-36

Method types
HTTP/1.0: HTTP/1.1:
 GET  GET, POST, HEAD
 POST  PUT
 HEAD  uploads file in
 asks server to entity body to
leave requested path specified in
object out of URL field
response  DELETE
 deletes file
specified in the
URL field

Application Layer 2-37

 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 [Link] GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 [Link]
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\
r\n
\r\n
data, e.g., data data data data data ...
requested
HTML file
Application Layer 2-38
HTTP Response Message -
Format
 The status line has three fields: protocol version field,
status code and corresponding status message.
 In below example, the status line indicates that the
server is using HTTP/1.1 and that everything is OK.
HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 [Link] GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007
[Link] GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-
8859-1\r\n \r\n
data data data data data ...
Date: header
Content-Type:
Server:
Last-Modified:
Content-Length:
header line indicates
header
line
header the indicates
indicates
line
lineline time
indicates
indicates and
that that
the
datenumber
when
message
time
the object the
and wasinofHTTP
date the response
generated
bytes
when
entity
in thebody was
byobject
object created
anisApache
HTML
being
was
and sent
Web
created
sent.
text. by last
server.
or the server.
modified.
HTTP response status codes
 status code appears in 1st line in server-to-
client response message.
 some sample codes:
200 OK
 request succeeded, requested object is sent in this msg
301 Moved Permanently
 requested object moved, new location (URL) specified
later in this msg (Location:)
400 Bad Request
 request msg not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported

Application Layer 2-40

 User-server state: cookies
 A small text file that is stored in the user's computer either
temporarily for that session only or permanently on the hard
disk.
 Cookies provide a way for the Web site to recognize you and
keep track of your preferences.
many Web sites use cookies
four components:
1) cookie header line in the HTTP response message
2) cookie header line in the HTTP request message
3) cookie file kept on user’s end system, managed by user’s
browser
4) back-end database at the Web site
example:
 Susan always access Internet from PC
 visits specific e-commerce site for first time
 when initial HTTP requests arrives at site, site creates:
 unique ID
Application Layer 2-41
 entry in backend database for ID
 Cookies: keeping “state” (cont.)
client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer 2-42
Cookies (continued)
what cookies can asid
be used for: cookies and privacy:
e
 authorization  cookies permit sites
 shopping carts to learn a lot about
 recommendations you
 user session state  you may supply
(Web e-mail) name and e-mail to
sites

Application Layer 2-43

 Web caches (proxy server)
goal: satisfy client request without involving
origin server
The Web cache has its own disk storage and keeps copies of
recently requested objects in this storage.

HT proxy
TP
server q uest
req re
HT ues P
client TP t H TT
p o nse
res res origin
pon TP
se HT server
t
ues
P req se
T o n
HT res
p
TP
HT

client origin
server

Application Layer 2-44

Web Caches (Proxy Server) –
Cont...
 A user’s browser can be configured so, user’s HTTP requests
are first directed to the Web Cache.
 A browser sends all HTTP requests to cache.
 As an example, suppose a browser is requesting the object
[Link]
 Object in cache returns to client browser.
 Otherwise cache requests object from origin server, then
returns object to client browser.
 cache acts as both client and server
 server for original requesting client
 client to origin server
 typically cache is installed by ISP (university, company,
residential
ISP)
 why Web caching?
 Reduce response time for client request.
 Reduce traffic on an institution’s access link.
 Internet dense with caches: Insufficiency for content providers
to effectively deliver content.
Caching example:
assumptions:
 avg object size: 1Mbits origin
 avg request rate from
servers
browsers to origin servers:15 public
request/sec Internet
 RTT from institutional router
to any origin server: 2 sec
 access link rate: 15 Mbps
15 Mbps
consequences: problem! access link
 LAN utilization: 15%
 access link utilization =
100 Mbps LAN
100%
 total delay = Internet delay
+ access delay + LAN delay
= 2 sec + minutes + usecs institutional
network

Application Layer 2-46

 Caching example: install local
cache
Calculating access link
utilization, delay with
cache: origin
 suppose cache hit rate is 0.4 servers
 40% requests satisfied at cache, public
Internet
60% requests
 access satisfied at origin
link utilization:
 60% of requests use access link

 total 15 Mbps
delay access link
 = 0.6 * (delay from origin
servers) +0.4 * (delay when
satisfied at cache)
 = 0.6 (2.01) + 0.4 (~msecs) 100 Mbps LAN
 = ~ 1.2 secs
 less than with 100 Mbps link
(and cheaper too!)
institutional
network
Conditional GET
client server
 Goal: don’t send
object if cache has
up-to-date cached HTTP request msg
object
If-modified-since: <date>
version not
 no object modified
transmission delay HTTP response
before
HTTP/1.0
 lower link utilization <date>
304 Not Modified
 cache: specify date
of cached copy in
HTTP request
If-modified-since: HTTP request msg
<date> If-modified-since: <date> object
 server: response modified
after
contains no object if HTTP response
HTTP/1.0 200 OK <date>
cached copy is up-
<data>
to-date:
HTTP/1.0 304 Not Application Layer 2-48
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-49

FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

 transfer file to/from remote host

 client/server model
 client: side that initiates transfer (either to/from
remote)
 server: remote host
 ftp: RFC 959
 ftp server: port 21
Application Layer 2-50
FTP: separate control, data
connections TCP control connection,
server port 21

TCP data connection,

FTP server port 20 FTP
client server
 FTP client contacts FTP server at port 21, using TCP
 FTP uses two parallel TCP connections to transfer a file,
 client authorized over control connection
 client browses remote directory, sends commands over control
connection
 when server receives file transfer command, server opens 2nd
TCP data connection (for file) to client
 after transferring one file, server closes data connection
 server opens another TCP data connection to transfer another
file
 control connection: “out of band”
 FTP server maintains “state”: current directory, earlier
authentication
Application Layer 2-51
FTP commands, responses
sample commands: sample return codes
sent as ASCII text over status code and phrase
control channel (as in HTTP)
 USER username  331 Username OK,
 PASS password password required
 LIST return list of file  125 data connection

in current directory already open;

 RETR filename
transfer starting
 425 Can’t open data
retrieves (gets) file connection
 STOR filename  452 Error writing
stores (puts) file onto file
remote host

Application Layer 2-52

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-53

 Electronic mail outgoing
message queue
user mailbox
 e-mail is an asynchronous user
communication medium- agent
people send and read mail user
messages when it is server agent
convenient for them,
without having to SMTP mail user
coordinate with other server agent
people’s schedules. SMTP
Three major SMTP user
components: mail
agent
server
 user agents user
 mail servers agent
 simple mail transfer user
protocol: SMTP agent

Application Layer 2-54

 Electronic mail outgoing
message queue
user mailbox
User Agent user
agent
 “mail reader”
mail
 composing, editing, server
user
agent
reading mail messages
 e.g., Microsoft Outlook, SMTP mail user
Apple Mail, Thunderbird server agent
 outgoing, incoming SMTP
messages stored on user
server SMTP agent
mail
server
user
agent
user
agent

Application Layer 2-55

Electronic mail: mail servers
mail servers: user
agent
 mailbox contains
incoming messages for mail user
server
user agent
 message queue of SMTP mail user
outgoing (to be sent) server agent
mail messages SMTP
SMTP user
agent
mail
server
user
agent
user
agent

Application Layer 2-56

Alice
User agent
Reattempts are often done
If Alice’s server every 30 minutes or so; if
cannot deliver mail to there is no success after
Bob’s server, Alice’s several days, the server
SMTP
server holds the removes the message and
message in a notifies the sender (Alice)
message queue and with an e-mail message.
attempts to transfer
the message later.

Bob
User agent

Application Layer 2-57

Electronic mail: SMTP
SMTP protocol between user
agent
mail servers to send
email messages mail user
 client: sending to server agent
mail server SMTP
 server: receiving mail user
server agent
from mail server
SMTP
SMTP user
agent
mail
server
user
agent
user
agent

Application Layer 2-58

 Electronic Mail: SMTP [RFC
2821]
 uses TCP to reliably transfer email message from
client to server, port 25
 direct transfer:
 sending server to receiving server
 SMTP does not use intermediate mail servers for sending
mail.
 If receiving end mail server is down, the message remains
in sending end mail server and waits for a new attempt.
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction (like HTTP, FTP)
 commands: ASCII text
 response: status code and phrase
 messages must be in 7-bit ASCII Application Layer 2-59
Scenario: Alice sends message to Bob

1. Alice uses user agent to

4. SMTP client sends
compose message to Alice’s message over
2) Alice’s user agent sends
3)4)Alice
1) Client
SMTP
computer@[Link] side
client
uses of sends
userSMTP
agentAlice’s
opens
thetoTCP connection.
message
5)6)Bob’s to herserver
Bob invokes
mail mail server;
his user
places agent
the
TCPagent
2. Alice’s user connection
message
compose over
withthe
message
sends Bob’s
TCPmail mail server
to
5. Bob’s
message
message placed
to read in message
in Bob’s
message
mailbox
places the message
message to her connection
server
computer@[Link]
mail server;
queue. in Bob’s mailbox.
message placed in message 6. Bob invokes his user
queue. agent to read
3. Client side of SMTP opens message.
TCP connection with Bob’s
 Sample SMTP interaction
closure Transfer of messages Handshaking

S: 220 [Link]
C: HELO [Link]
S: 250 Hello [Link], pleased to meet you
C: MAIL FROM: <alice@[Link]>
S: 250 alice@[Link]... Sender ok
C: RCPT TO: <bob@[Link]>
S: 250 bob@[Link] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 [Link] closing connection

Application Layer 2-61

SMTP: final words
 SMTP uses persistent comparison with
connections HTTP:
 SMTP requires  HTTP: pull
message (header &
body) to be in 7-bit
 SMTP: push
ASCII  both have ASCII
 SMTP server uses command/response
[Link] to interaction, status
determine end of codes
message
 HTTP: each object
encapsulated in its
own response msg
 SMTP: multiple
objects sent in one
msg Application Layer 2-62
Mail message format
SMTP: protocol for
exchanging email header
msgs blank
line
RFC 822: standard for
text message
format:
 header lines, e.g.,
body
 To:
 From:
 Subject:
different from SMTP
MAIL FROM, RCPT
TO: commands!
 Body: the “message”
 ASCII characters only
Application Layer 2-63
Mail access protocols
user
mail user
SMTP SMTP access
agent agent
protocol
(e.g., POP,
IMAP)

sender’s mail receiver’s mail

server server

 SMTP: delivery/storage to receiver’s server

 mail access protocol: retrieval from server
 POP: Post Office Protocol [RFC 1939]: (port
110) authorization, download
• used to transfer mail from the recipient’s mail
server to the recipient’s user agent.
 IMAP: Internet Mail Access Protocol [RFC
1730]: more features, including manipulation
of stored msgs on server
 HTTP: gmail, Hotmail, Yahoo! Mail, etc.
Application Layer 2-64
POP3 protocol
With the TCP connection established, POP3 S: +OK POP3 server ready
progresses through three phases: C: user bob
authorization, transaction and S: +OK
update.
C: pass hungry
authorization phase S: +OK user successfully logged on
 the user agent sends a username
and a password to authenticate the C: list
user. S: 1 498
transaction phase, S: 2 912
the user agent retrieves messages, S: .
mark C: retr 1
messages for deletion, remove deletion S: <message 1 contents>
S: .
marks and obtain mail statistics.
C: dele 1
client: C: retr 2
 list: list message numbers S: <message 1 contents>
 retr: retrieve message by number S: .
 dele: delete C: dele 2
 Quit C: quit
S: +OK POP3 server signing off
Update phase,
In update, after the quit command by Application Layer 2-65
POP3 (more) and IMAP
more about POP3 IMAP
 previous example  keeps all messages
uses POP3 in one place: at
“download and server
delete” mode  allows user to
 Bob cannot re- organize messages
read e-mail if he in folders
changes client  keeps user state
 POP3 “download- across sessions:
and-keep”: copies of  names of folders
messages on and mappings
different clients between message
IDs and folder
name

Application Layer 2-66

IMAP (Internet Mail Access
Protocol)
 keeps all messages in one place: at server
 The recipient can then move and organize the
message into a new, user-created folder, read the
message, delete the message, move messages from
one folder to another and so on.
 To allow users to search remote folders for messages
matching specific criteria.
 Also permit a user agent to obtain components of
messages, When low-bandwidth connection between
the user agent and its mail server.
 In this case, user not to download all the messages
in its mailbox, particularly avoiding long messages
like an audio or video clip.

Application Layer 2-67

Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-68

DNS: domain name system
people: many identifiers:
 Aadhar no, name, passport #
Internet hosts, routers:
 IP address (32 bit) - used for addressing
datagrams
 “name”, e.g., [Link] - used by
humans

Q: how to map between IP address and

name, and vice versa ?

Application Layer 2-69

DNS: domain name system

IP
Address
Alphabetic name
remember by human
 It is an internet service that translates domain names
into IP addresses.
 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.
 In DNS system, If one DNS server doesn't know how to
translate a particular domain name, it asks another
one, and so on, until the correct IP address is returned.
Application Layer 2-70
DNS: Domain Name
System
 The DNS servers are often UNIX
machines running the Berkeley Internet
Name Domain (BIND) software
 The DNS protocol runs over UDP and
uses port 53.

Application Layer 2-71

 DNS: services, structure
DNS services
 Main service to translate the host name into the corresponding IP
address.
 host aliasing: A host with a complicated hostname can have
one or more alias names.
 For eg.: a hostname such as [Link]-
[Link] (canonical hostname) could have,
say, two aliases such as
• [Link] and
• [Link]
 mail server aliasing:
 the email ids are
like blog@[Link] , blog@[Link] etc.
 However, the hostname of the gmail or outlook servers are
more complicated and are less convenient to
remember(something like `[Link]` and
`[Link]`).
 So in this case DNS server can be invoked by mail
application to obtain the canonical
hostname(`[Link]`) for the alias hostname
Application Layer 2-72
([Link]) as well as IP address.
 DNS: services, structure
why not centralize DNS?
 single point of failure
 traffic volume
 distant centralized database
 maintenance

A: doesn’t scale!

Application Layer 2-73

DNS: a distributed, hierarchical
database
Root DNS Servers
… …

com DNS servers org DNS servers edu DNS servers

[Link] [Link] [Link]

[Link] [Link]
DNS servers DNS serversDNS servers
DNS servers DNS servers
client wants IP for [Link]; 1st approx:
 DNS client wants to determine the IP address for the
hostname [Link]
 The client first contacts one of the root servers, which
returns IP addresses for TLD servers - top-level
domain .com.
 Then contacts TLD servers, which returns the IP address of
an authoritative server for [Link]
 Finally, contacts one of the authoritative servers for
[Link], which returns the IP address for the
Application Layer 2-74
hostname [Link].
DNS: root DNS servers
 There are over 400 root name servers scattered all
over the world.
 These root name servers are managed by 13
different organizations. (Root Server 2016)
 Root name servers provide the IP addresses of the
TLD servers.

Application Layer 2-75

TLD servers
Top-Level Domain (TLD) servers:
 For each of the top-level domains — top-level
domains such as
 com, org, net, edu, and gov, and all of the
country top-level domains such as uk, fr, ca,
and jp — there is TLD server (or server
cluster).
 The company Verisign Global Registry Services
maintains the TLD servers for the com top-
level domain
 The company Educause maintains the TLD
servers for the edu top-level domain.
 TLD servers provide the IP addresses for
authoritative DNS servers.

Application Layer 2-76

Authoritative servers
authoritative DNS servers:
 Every organization with publicly accessible
hosts (such as Web servers and mail servers)
on the Internet must provide publicly
accessible DNS records that map the names of
those hosts to IP addresses.
 Either organization’s own DNS server(s), to
hold these records
 Or can be maintained by organization or
service provider

Application Layer 2-77

Local DNS name server
 does not strictly belong to hierarchy
 each ISP (residential ISP, company,
university) has one
 also called “default name server”
 when host makes DNS query, query is
sent to its local DNS server
 has local cache of recent name-to-address
translation pairs (but may be out of date!)
 acts as proxy, forwards query into hierarchy

Application Layer 2-78

DNS name
resolution root DNS server

example 2
 host at [Link] 3
TLD
wants IP address List ofDNS server of
IP addresses
4
for TLD server responsible
[Link] 5forIPedu
address of
authoritative DNS
local DNS server
iterated query: [Link] server for
 contacted server 7
[Link]
6
1 8
replies with name
of server to
authoritative DNS server
contact [Link]
 “I don’t know this requesting host
name, but ask this [Link]
server”
[Link]

Application Layer 2-79

DNS name
resolution root DNS server

example 2 3
7
recursive query: 6
 puts burden of TLD DNS
server
name resolution
on contacted local DNS server
name server [Link] 5 4

1 8

authoritative DNS server

[Link]
requesting host
[Link]

[Link]

Application Layer 2-80

DNS: caching, updating
records
 once (any) name server learns mapping,
it caches mapping
 cache entries timeout (disappear) after some
time (TTL- Time To Live)
 TLD servers typically cached in local name
servers
• thus root name servers not often visited
 cached entries may be out-of-date (best
effort name-to-address translation!)
 if name host changes IP address, may not be
known Internet-wide until all TTLs expire

Application Layer 2-81

 DNS records
DNS: distributed db storing resource records
(RR) RR format: (Name, Value, Type, TTL)

Where TTL is Time to live of the resource record.

The meaning of name and value depends on type:
type=A type=CNAME
 name is hostname  name is alias name for some
“canonical” (the real) name
 value is IP address
 [Link] is really
 ([Link],[Link]
, A) [Link]
type=NS  value is canonical name
 name is domain (e.g.,
[Link]) type=MX
 value is hostname of  value is canonical name of
authoritative DNS
server for this domain mail server associated
 ([Link],[Link], with alias hostname name
Application Layer 2-82
 DNS protocol, messages
 query and reply messages, both with
same message format 2 bytes 2 bytes
msg header
identification flags
 identification: 16 bit # for

Header
query, reply to query uses # questions # answer RRs
same #
# authority RRs # additional RRs
 flags:
 1 bit query or reply questions (variable # of questions)
 1bit reply is authoritative
server answers (variable # of RRs)
 1 bit recursion desired : is
set when a client (host or DNS authority (variable # of RRs)
server) desires that the DNS
server perform recursion when additional info (variable # of RRs)
it doesn’t have the record.
 1 bit recursion available: Application Layer 2-83
 DNS protocol, messages

2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

Name that is being queried, questions (variable # of questions)

type fields for a query
RRs in
response answers (variable # of RRs)
to query
records for authority (variable # of RRs)
authoritative servers
additional “helpful” additional info (variable # of RRs)
info that may be used
Application Layer 2-84
Inserting records into DNS
 example: new startup “Network Utopia”
 register name [Link] at DNS
registrar (e.g., Network Solutions)
 provide names, IP addresses of authoritative
DNS server (primary and secondary)
 Suppose the name & IP addresses of primary &
secondary authoritative DNS are
[Link]-- [Link] &
[Link]-- [Link]
 registrar inserts two RRs into .com TLD server:
([Link], [Link], NS)
([Link], [Link], A)
 create authoritative server type A record for
[Link]; type MX record
for mail server [Link]
Application Layer 2-85
Chapter 2: outline
2.1 principles of 2.6 P2P applications
network 2.7 socket
applications programming
 app architectures with UDP and TCP
 app requirements
2.2 Web and HTTP
2.3 FTP
2.4 electronic mail
 SMTP, POP3,
IMAP
2.5 DNS

Application Layer 2-86

Socket programming
goal: learn how to build client/server
applications that communicate using
sockets
socket: door between application process
and end-end-transport protocol
application application
socket controlled by
process process app developer

transport transport
network network controlled
link
by OS
link Internet
physical physical

Application Layer 2-87

 Socket programming
Two socket types for two transport
services:
 UDP: unreliable datagram
 TCP: reliable, byte stream-oriented
Application Example:
1. Client reads a line of characters (data)
from its keyboard and sends the data to
the server.
2. The server receives the data and
converts characters to uppercase.
3. The server sends the modified data to
the client.
4. The client receives the modified data
Application Layer 2-88
Socket programming with
UDP
UDP: no “connection” between client &
server
 no handshaking before sending data
 sender explicitly attaches IP destination
address and port # to each packet
 rcvr extracts sender IP address and port#
from received packet
UDP: transmitted data may be lost or
received out-of-order
Application viewpoint:
 UDP provides unreliable transfer of groups
of bytes (“datagrams”) between client and
server
Application Layer 2-89
Client/server socket interaction:
UDP
server (running on serverIP) client
create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket

write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket

Application 2-90
 Example app: UDP client
Python UDPClient
include Python’s socket
library from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for clientSocket = socket(AF_INET, SOCK_DGRAM)
server
get user keyboard
input
message = raw_input(’Input lowercase sentence:’)
Attach server name, port to
message; send into socket [Link]([Link](),
(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
[Link](2048)
print out received string print ([Link]())
and close socket
[Link]()
Application Layer 2-91
 Example app: UDP server
Python UDPServer
from socket import *
serverPort = 12000
create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM)
bind socket to local port
number 12000
[Link](('', serverPort))
print “The server is ready to receive”
loop forever while True:
Read from UDP socket into message, clientAddress = [Link](2048)
message, getting client’s
address (client IP and port) modifiedMessage = [Link]()
send upper case string [Link]([Link](),
back to this client clientAddress)

Application Layer 2-92

Socket programming with
TCP
client must contact  when contacted by
server client, server TCP
 server process must creates new socket for
first be running server process to
 server must have communicate with that
created socket (door) particular client
that welcomes client’s  allows server to talk
contact with multiple clients
 source port numbers
client contacts server used to distinguish
by: clients (more in Chap
 Creating TCP socket, application
3) viewpoint:
specifying IP address, TCP provides reliable, in-order
port number of server byte-stream transfer (“pipe”)
process between client and server
 when client creates
socket: client TCP
establishes connection Application Layer 2-93
Client/server socket interaction:
TCP
server (running on hostid) client
create socket,
port=x, for incoming
request:
serverSocket = socket()

wait for incoming create socket,

connection request
TCP
connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
[Link]()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket

Application Layer 2-94

 Example app: TCP client
Python TCPClient
from socket import *
serverName = ’servername’
create TCP socket for serverPort = 12000
server, remote port 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
[Link]((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
No need to attach server [Link](sentence)
name, port
modifiedSentence = [Link](1024)
print ‘From Server:’, modifiedSentence
[Link]()

Application Layer 2-95

 Example app: TCP server
Python TCPServer
from socket import *
create TCP welcoming
serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
[Link]((‘’,serverPort))
server begins listening for
incoming TCP requests
[Link](1)
print ‘The server is ready to receive’
loop forever while 1:
server waits on accept() connectionSocket, addr = [Link]()
for incoming requests, new
socket created on return
sentence = [Link](1024)
read bytes from socket (but
not address as in UDP) capitalizedSentence = [Link]()
close connection to this
[Link](capitalizedSentence)
client (but not welcoming [Link]()
socket)
Application Layer 2-96
Chapter 2:
summary
our study of network apps now
complete!
 application architectures  specific protocols:
 client-server  HTTP
 P2P  FTP
 application service  SMTP, POP, IMAP
requirements:
 reliability, bandwidth,  DNS
delay  P2P: BitTorrent,
 Internet transport DHT
service model  socket programming:
 connection-oriented,
TCP, UDP sockets
reliable: TCP
 unreliable,
datagrams: UDP
Application Layer 2-97
Chapter 2:
summary
most importantly: learned about
protocols!
 typical request/reply
important themes:
message exchange:
 client requests
 control vs. data msgs
info or service  in-band, out-of-band
 server responds  centralized vs.
with data, status decentralized
code  stateless vs. stateful
 message formats:
 headers: fields  reliable vs. unreliable
giving info about msg transfer
data  “complexity at
 data: info being network edge”
communicated
Application Layer 2-98