Chapter 2

Application Layer
Adapted by Andreas Pitsillides for class
EPL324, Computer Science department,
University of Cyprus, from Kurose and Ross
slides: see below Computer
Networking: A Top
A note on the use of these ppt slides: Down Approach ,
We’re making these slides freely available to all (faculty,
students, readers). They’re in PowerPoint form so you can add, 7th edition.
modify, and delete slides (including this one) and slide content to Jim Kurose, Keith Ross
suit your needs. They obviously represent a lot of work on our
part. In return for use, we only ask the following: Addison-Wesley.
 If you use these slides (e.g., in a class) in substantially
unaltered form, that you mention their source (after all, we’d
like people to use our book!) A translation in Greek
 If you post any slides in substantially unaltered form on a exists (4th edition).
www site, that you note that they are adapted from (or http://www.papasotiriou.gr/
perhaps identical to) our slides, and note our copyright of this product.gbook.asp?
material. pfid=1875791&prid=1130023

Thanks and enjoy! JFK/KWR

All material copyright 1996-2009 2: Application Layer 1

J.F Kurose and K.W. Ross, All Rights Reserved
Chapter 2: Application layer
 2.1 Principles of network
 2.6
applications
P2P applications
and
application layer protocols
 2.7 Socket
 2.2 Web and HTTP programming with TCP
 2.3 FTP  2.8 Socket
 2.4 Electronic Mail programming with
 SMTP, POP3, IMAP UDP
 2.5 DNS
 New directions

2: Application Layer 2
Chapter 2: Application Layer
 learn about protocols by
Our goals:
 conceptual, examining popular
implementation application-level
aspects of network protocols
 HTTP for web
application
 FTP for file transfer
protocols  SMTP / POP3 / IMAP for
 service models
email
offered to  DNS for IP<-
application layer >mnemonic
by transport-  Peer-to-peer (P2P) for
layer direct comm between
 client-server peers

paradigm  creating network

 peer-to-peer applications
2: Application Layer 3
Some network apps
 and more…
 e-mail
 Web  Facebook
 instant messaging  Whatsup
 remote login  Real-time video
 P2P file sharing  Internet of Things (IoT)
 multi-user network games  Web of Things
 Grid computing
 real-time video conferencing
  Cloud computing
streaming stored video clips (Utube, Netflix, …)
 Zoom…
 MS Teams …

2: Application Layer 4
Creating a network app applicatio
n
transport

write programs that network

data link
physical
 run on (different) end
systems
 communicate over the
network
 e.g., web server software
communicates with browser
software applicatio
n
transport
network
applicatio
data link
IMPORTANT: No need to physical
n
transport

write software for network- network

data link
physical
core devices
 Network-core devices do not
run user applications
 applications on end systems
allows for rapid app 2: Application Layer 5
Protocol layering in Internet

2: Application Layer 6
Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
and
application layer protocols
 2.7 Socket
 2.2 Web and HTTP programming with TCP
 2.3 FTP  2.8 Socket
 2.4 Electronic Mail programming with
 SMTP, POP3, IMAP UDP
 2.5 DNS  2.9 Building a Web
server

2: Application Layer 7
Applications and application-layer
protocols
application
applicatio
n
transport
network

Application: data link

physical

communicating,
distributed processes
 e.g., e-mail, Web, P2P file
sharing, instant messaging
 running in end systems
(hosts)
 exchange messages to applicatio
applicatio
n
implement application n
transport
transport
network
network data link
data link physical
 Via the internet ‘layers’, physical

through an application application

layer protocol (e.g. HTTP)

2: Application Layer 8
 Applications and application-layer
protocols e.g.firefox
Application-layer protocols applicatio
n
 abstraction layer (επίπεδο applicatio
Applicati
on layer
αφαιρετικότητας) that specifies the n
transport protocol
shared communications network
protocols and interface data link
physical
methods used by hosts in a
communications network
 one “piece” of an app
 define messages exchanged
by apps and actions taken
 uses communication services
provided by lower layer
protocols (TCP, UDP) e.g.chrome applicatio
e.g.MS Edge
application applicatio application
n
n transport
Applicati
 Same application layer on layer transport
network
network Applicati
data link on layer
protocol used by different
protocol data link physical protocol
physical
application
implementations
 written once
(standardised) for the
same type of application , 2: Application Layer 9
e.g. for web (http), email
App-layer protocol defines
(everything)
 Types of messages
Public-domain exchanged, e.g., request &
protocols:
 response messages
defined in RFCs
 Syntax of message types: what fields in messages
 allows for interoperability
& how fields are delineated
 eg, HTTP, SMTP
 Semantics of the fields, i.e., meaning of
information in fields
Proprietary
 protocols:
Rules for when and how processes send & respond
 to
eg,messages
Skype, torrent, …

2: Application Layer 10
Application architectures
 Client-server
 Peer-to-peer (P2P)
 Hybrid of client-server and P2P

2: Application Layer 11
 Client-server architecture
server:
 always-on host
 permanent IP
address
 server farms for
scaling
clients:
client/server
 communicate with
server
 may be intermittently
connected
 may have dynamic IP
addresses
 do not communicate
2: Application Layer 12
directly with each other
Pure P2P architecture
peer-peer
 no always-on server
 arbitrary 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 can be intermittently
connected and change IP
addresses
2: Application Layer 13
Hybrid of client-server and
P2P
Skype
 voice-over-IP P2P application
 centralized server: finding address of
remote party:
 client-client connection: direct (not through
server)
Instant messaging
 chatting between two users is P2P
 centralized service: client presence
detection/location
• user registers its IP address with central
server when it comes online
• user contacts central server to find IP
addresses of buddies

2: Application Layer 14
Processes communicating
Process: program running Client process:
within a host. process that
 within same host, two initiates
processes communicate communication
using inter-process Server process:
communication (defined by process that waits
OS). to be contacted

 Note: applications with

P2P architectures have
client processes & server
 processes in processes

different hosts
communicate by 2: Application Layer 15
 Sockets (OS ‘jargon’, ‘API’)
 process sends/receives messages to/from its socket
(interface with transport layer)
 socket analogous to door
 sending process ‘pushes’ message out of the door
 sending process relies on transport infrastructure on other
side of door which brings message to socket at receiving
process
application application
socket process
controlled by
process app developer
transport transport controlled
network network by OS
link Internet link
physical physical

 API offers: (1) choice of transport protocol; (2)

ability to fix a few parameters (more on this later)
2: Application Layer 16
How do we identify processes:
Addressing
 For a networked  Identifier includes both
process to receive the IP address and port
messages, it must numbers associated with
have an identifier the process on the host
 In the internet a host  Example port numbers:
has a unique 32-bit IP  HTTP server: 80
address  Mail server: 25
 Q: does the IP address  to send HTTP message to

of the host on which gaia.cs.umass.edu web

the process runs server:
suffice for identifying
 IP address:
128.119.245.12
the process?  Port number: 80
 Answer: No, as there
 more later…
may be many 2: Application Layer 17
processes running on
 Q. What transport service does an
app need?
Note: diverse application requirements exist:
Data integrity/loss Throughput
 some apps require 100%  some apps (e.g.,
reliable data transfer multimedia) require
(e.g., file transfer, telnet)
minimum or fixed amount
 some other apps can
of throughput to be
tolerate some loss (e.g.,
audio, video) “effective” (e.g.
video@2Mbps
peak/average/minimum, …)
Timing
 other apps (“elastic
 some require low delay
to be “effective” apps apps”) make use of
(e.g., Internet telephony, whatever throughput they
interactive games, video) get (e.g. file transfer)
 others not necessarily,
Security
e.g. transfer a file
 Encryption, data integrity,
2: Application Layer 18
 What do
Please read aloud you see
 Aoccdrnig to a rscheearch at an Elingsh
uinervtisy, it deosn't mttaer in
waht oredr the ltteers in a wrod are, the
olny iprmoetnt tihng is taht
frist and lsat ltteer is at the rghit pclae.
The rset can be a toatl mses and
you can sitll raed it wouthit porbelm.
Tihs is bcuseae we do not raed ervey
lteter by it slef but the wrod as a wlohe.

Human brain can still interpret missing and ‘noisy’

information, i.e. depending on the application it can
tolerate a certain amount of loss (and delay)
2: Application Layer 19
Please read aloud
 Πμανιπσητετο τυο Κμτρπιαιζ
 Σνφμύωα με μαι έυρενα σοτ
Πμανιπσητετο τυο Κμτρπιαιζ, δνε πεαιζι
ρλόο με τι σριεά ενίαι τοθοπεμετενα τα
γταμαμρά μσέα σε μαί λξηέ, αεκρί το
πώτρο κια το ταελείτυο γάμρμα να ενιαί
σητ στωσή θσέη.
Τα υλοπιόπα μροπούν να ενίαι σε τχίυεας
θιέεσς κια να μροπετίε να τςι δαβαιάεστε
χρωίς πλβημόρα.
 Ατυό γνίταει, γαιτί ο απρώνθονις
εκέγλφοας δνε δαεβζιάι γάμρμα γάμρμα
κθάε λξηέ αλλά τνη λξηέ σνα σνύλοο.
Ατίπτσυεο ε;
2: Application Layer 20
Picture quality: how is it measured/defined?

Q. Is the quality
of this picture
acceptable?

A. It depends ...

Message: in
certain cases we
can accept some
deterioration of the
message we
receive, e.g. due to
lost packets or
delay2: Application Layer 21
 Application requirements
examples
applications have
diverse capacity
(bandwidth)
demands

+ applications also
have diverse
demands in terms
of loss, delay, and
delay variation
(among others)

2: Application Layer 23
Effect of propagation delay
(RTT-Round Trip Time) 10,000km link

 simplistic example: request and send 1MB

down a 1Gb/s link, with 200ms RTT. Reque
st
 What’s the throughput?
 Transfer size = 1MB == 8 Mbit
file
 What’s the transfer time? distance
time

 Throughput = Transfer file size / Transfer time

 Transfer time = RTT + transfer file size / Bandwidth
 = 0.2 s + 8 Mbit/1 Gbps = 0.208 s
 Thus throughput = 8Mbit/0.208 s= 38.5 Mbps !!!!!!!!
 OUT OF A 1 Gbps LINE ONLY 38.5 Mbps are
transferred!!!! (3.85%!!!!!! WHAT A WASTE OF
RESOURCES-MONEY!!)
 Adding bandwidth will not help!!! Reducing distance? Is
this practical? Can better protocol design help, and Layer
2: Application 24
Protocol design affects
performance
 Protocols which require many RTTs don’t
work well in the high speed wide area (esp.
long distance) network.
 Example: Opening a network folder in
Windows
• About 80 request/response pairs on average
• 200ms RTT (e.g. London-Redmond)
• more than 16 seconds delay !!!

 Upgrading your network will not help!

 Design a better protocol? More later on
http… 2: Application Layer 25
Recall: Internet protocol
stack
 application: supporting network
applications, with application application
protocols, such as
 HTTP, FTP, SMTP
transport
 transport: host-host data transfer
network
 Offers services to higher layer
• What type of services? What should
they offer?
link
• One? More?
 ‘Prepares package’ at transport layer physical
to be sent to the network (via the
network layer)

2: Application Layer 26
 Internet transport protocols services
services offered by transport layer to app layer
TCP service: UDP service:
 reliable transport between  unreliable data transfer
sending and receiving between sending and
process receiving process
 connection-oriented: setup  does not provide:
required between client connection setup,
and server processes reliability, flow control,
 flow control: sender won’t congestion control,
overwhelm receiver timing, or bandwidth
 congestion control: throttle guarantee
sender when network
overloaded Q: why bother? Why is
 does not provide: timing or there a UDP?
minimum bandwidth
guarantees
we need any more services to be designed? 2: Application Layer 28
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 (eg Youtube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) typically UDP

2: Application Layer 29
Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
 app architectures  2.7 Socket
 app requirements
programming with TCP
 2.2 Web and HTTP 2.8 Socket
 2.4 Electronic Mail programming with
 SMTP, POP3, IMAP UDP
 2.5 DNS

2: Application Layer 30
Aside: The Web-some history
 Hypertext'91 Conference decides that the
WWW is only worth a Poster!!!!!
World Wide Web
(WWW) was
introduced for
public use as a
service in
August 1991

A public graphic
browser,
Mosaic, was
introduced in
1993

We all know its value today. 2: Application Layer 31

 Web and HTTP

First some jargon

 Web page consists of objects
 Object can be HTML file, JPEG image, Java
url of this
applet, audio file,… picture
object
 Web page consists of base HTML-file which
includes several referenced objects
 Each object is addressable by a URL
 Example URL:
www.someschool.edu/someDept/pic.gif

host name path name

2: Application Layer 32
HTTP overview
HTTP: hypertext
transfer protocol HT
TP
 Web’s application req
ues
PC running HT t
layer protocol Firefox browser TPr
esp
ons
e
 client/server model
t
u es
 client: browser that req server
T P nse
requests, receives, HT s po running
re Apache Web
(using the HTTP T P
HT server
protocol) “displays”
Web objects
iPhone running
 server: Web server Safari browser
sends (using the HTTP
protocol) objects in
response to requests 2: Application Layer 33
 HTTP overview (continued)
Uses TCP: Distance, d

 client initiates TCP initiate TCP

connection (creates connection
socket) to server, port RTT
80 request
file
 server accepts TCP
time to
RTT
connection from client transmit
File (Length
(TCP connection open) file R/link speed)
 HTTP messages received
(application-layer
protocol messages) close TCP
exchanged between connection
1.5 RTT
browser (HTTP client)
and Web server (HTTP time time
server)
 TCP connection closed 2: Application Layer 34
HTTP overview (continued)
HTTP is “stateless”
Distance, d
 server maintains no
initiate TCP
connection information about
RTT past client requests
request
file aside
RTT
time to Protocols that maintain
transmit “state” are complex!
File (Length
file R/link speed)  past history (state) must
received
be maintained
 if server/client crashes,
close TCP
connection their views of “state”
1.5 RTT may be inconsistent,
must be reconciled
time time

2: Application Layer 35
 A typical
web page

HTTP connections
with many
objects

Nonpersistent HTTP Persistent HTTP

(v1.0) (v1.1)
 At most one object is  Multiple objects can
sent over a TCP be sent over single
connection (connection TCP connection
cycle requires for each
object: open TCP, transfer between client and
object, close TCP). server.
 Two version:
 Is this a good design  with pipelining
choice? Why?  without pipelining
 Any other choice(s)? HTTP 1.1: RFC 2068
and RFC2616
 HTTP 1.0: RFC 1945
2: Application Layer 36
 Nonpersistent HTTP (v1.0) 10,000km link

(contains base HTML-

Suppose user enters URL file text + references to
www.someSchool.edu/someDepartment/home.index 10 jpeg images)

1a. HTTP client initiates TCP

connection to HTTP server
(process) at
1b. HTTP server at host
www.someSchool.edu waiting
www.someSchool.edu on port 80
for TCP connection at port
80. “accepts” connection,
notifying client
2. HTTP client sends HTTP
request message
(containing URL) into TCP 3. HTTP server receives
connection socket. Message request message, forms
indicates that client wants response message
object containing requested object,
someDepartment/home.index and sends message into its
socket
time
distance 2: Application Layer 37
 Nonpersistent HTTP (cont.) 10,000km link

4. HTTP server closes TCP

connection.
5. HTTP client receives
response message
containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
time objects
6. Steps 1-5 repeated for
each of 10 jpeg objects
(i.e. a new TCP
connection is opened for
each object request and
closed when sent by
server)
What effect does step 6 have on the
time? Can we improve and how?
2: Application Layer 38
 Non-Persistent HTTP: Response
time
Definition of RTT: time for a small
packet to travel from client to
server and back.
distance
Response time (up to step 5): initiate TCP
 one RTT to initiate TCP connection
connection RTT
 one RTT for HTTP request + request
file
first few bytes of HTTP time to
response to return RTT
transmit
 file transmission time file
file
 close connection

...
received
total = 2.5 RTT (to open and
close connection)+ 1RTT + time time
transmit time for each object
Step 6: for each referenced object we need 1 RTT (open
connection) + 1 RTT +Transmit Time to request and send object+
Time to close connection (1.5 RTT) 2: Application Layer 39
 example
RTT increases with
distance: time to
Distance, propagate (‘travel’)
initiate TCP d signal a distance d;
connection

RTT
if speed of channel
request is s, then RTT = 2d/s
file
time to
RTT transmit e.g.
File
(Tix=File
d=1000km/2x108m/
time File received Length/R s
Close RTT link
connection0.5 RTT speed)
=5x10-3 sec.

time time RTT=

total = 2 x 5ms
2*10ms+ Tix + 1.5*10
2: Application Layer 40
NonPersistent and Persistent HTTP

Nonpersistent (v1.0) Persistent (v1.1) HTTP

HTTP issues:  server leaves
 requires 2.5 extra connection open
RTTs per object and after sending
OS overhead for each response
TCP connection  subsequent HTTP
messages between
 [Note 1: for v1.0 often same client/server
browsers open parallel are sent over open
TCP connections to fetch
referenced objects (not
connection
intended with ‘original’  Note 2: Two
TCP).] versions: with and
without pipelining
How can we improve?
2: Application Layer 41
Persistent (v.1.1) with and
without pipelining
 Persistent without  Persistent with
pipelining: pipelining:
 client issues new  default in HTTP/1.1
request only  client sends requests
when previous as soon as it
response has encounters a
been received referenced object
 one RTT for each  as little as one RTT
referenced object for all the referenced
+ the each objects + all object’s
object’s transmit transmit time
2: Application Layer 42
time
 example  What type of http is
used/preferred?
 A typical http Persistent (v1.1) or
non-persistent(v1.0)?
session
 How long to fetch
the web page
RTT consisting of 3 small
RTT objects, one .html
Total
time main file, one .jpg
RTT
image, and
RTT/2
one .mp3. The
… transmission time for
RTT=5
each one is Τ1=1,
Also see applet: Τ2=5, and Τ3=20
http://media.pearsoncmg.com/aw/aw_kurose_network_2/applets/http/http.html 2: Application Layer 43
msec. RTT=5 msec.
Non-persistent (v.0) vs persistent
(v1.1) RTT= 5 msec beginning SYN

RTT
SYNACK

REQUE
ST HT
Total time =
ML
RTT
main fi
le 5.5. RTT +
T1=1 mse
c T1+T2+T3
=53.5 msec
REQU
EST JP
G
RTT (note solution is
se c
T2=5 m without
REQUE pipelining)
ST mp3 How would
T2
RTT total times
sec
between the 2
T3 = 2 0 m solutions be
affected if
FIN number of
RTT objects is about
IN
T3 ACK & F
20 with mean
ACK
0.5 RTT
transfer time 5
end msec?
Total time = What if it is
10.5. RTT + T1+T2+T3 with pipelining?
=78.5 msec 2: Application Layer 44
Persistent without vs with
pipelining
RTT= 5 msec beginning beginning SYN
SYN

RTT RTT
SYNACK
SYNACK
REQUE
REQUE ST HT
ST HT ML ma
ML main fi in file
RTT le RTT
c
c T1=1 mse
T1=1 mse se c
T2=5 m
REQU
EST JP se c
RTT
G T3 = 2 0 m
Total time = se c
T2=5 m
5.5. RTT + FIN
REQUE
T1+T2+T3 ST mp3 RTT
IN
=53.5 msec RTT ACK & F
ACK
sec
(without T3 = 2 0 m 0.5 RTT
end
pipelining)
FIN
RTT Total time =
ACK & F
IN ??? RTT +
ACK T1+T2+T3
0.5 RTT =???? msec
end (with pipelining)
What if number of objects
is 30 (for simplicity assume
2: Application Layer 45 10msec each)?
 HTTP V1.0 and V1.1 beginning S YN
beginning S YN
RTT= 5 msec
RTT
RTT SYNACK
SYNACK
RTT RE QU E
RE QU E
ST HT
ST HT ML main fi
M L ma le
RTT
in file RTT
c
c T1=1 mse
T1=1 mse ms ec
T2= 5
RE QU
EST JP sec
G T 3= 20 m
RTT
sec
T2= 5 m
FIN
R E QU E
ST mp3 RTT
IN
T2 RTT ACK & F
ACK
sec
T 3= 20 m 0.5 RTT
end
FIN
RTT
IN (v1.1 with
ACK & F
T3
ACK pipelining)
RTT
0.5 RTT
0.5 RTT end
V1.1
(without
Total time = pipelining)

2.5. RTT (open (set up) and close (tear 46

2: Application Layer
down) TCP connection)+Delays in box
 HTTP request message
 two types of HTTP messages: request,
response

 HTTP request message:

 ASCII (human-readable format)
request line
(GET, POST, GET /somedir/page.html HTTP/1.1
HEAD commands) Host: www.someschool.edu
User-agent: Mozilla/4.0
header Connection: close
lines Accept-language:fr

Carriage return,
(extra carriage return, line feed)
line feed
indicates end
of message
2: Application Layer 47
HTTP request message: general
format

2: Application Layer 48
Method types
HTTP/1.1
HTTP/1.0
 GET,
GET POST, HEAD
 PUT
POST
 HEAD
 uploads file in entity body to path specified in URL

field
asks server to leave requested object out of
 DELETE
response
 deletes file specified in the URL field

2: Application Layer 49
Uploading form input
Post method:
 Web page often includes form input
URLin
 Input is uploaded to server method:
entity body
 Uses GET method
 Input is uploaded in
URL field of request
line:

www.somesite.com/animalsearch?monkeys&banana

2: Application Layer 50
HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK
status phrase) Connection close
Date: Thu, 06 Aug 1998 12:00:15 GMT
header Server: Apache/1.3.0 (Unix)
lines Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html

data, e.g., data data data data data ...

requested
HTML file

2: Application Layer 51
HTTP response status codes
In first line in server->client response message.
A few sample codes:
200 OK
 request succeeded, requested object later in this
message
301 Moved Permanently
 requested object moved, new location specified later
in this message (Location:)
400 Bad Request
 request message not understood by server
404 Not Found
 requested document not found on this server
505 HTTP Version Not Supported
2: Application Layer 52
 Trying out HTTP (client side) for
yourself
1. Telnet to your favorite Web server:
telnet gaia.cs.umass.edu 80 opens TCP connection to port 80
(default HTTP server port)
at gaia.cs.umass. edu.
anything typed in will be sent
to port 80 at gaia.cs.umass.edu

2. type in a GET HTTP request:

GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu by typing this in (hit carriage
return twice), you send
this minimal (but complete)
GET request to HTTP server

3. look at response message sent by HTTP server!

or use Wireshark to look at captured HTTP request/response)
Application Layer 2-53
User-server state: cookies
Example:
Many major Web sites use cookies. Why?
 Susan always
accesses Internet from
Four components:
1) cookie header line in HTTP PC
request message
 visits
2) cookie header line in HTTP specific
response e-
message
commerce
3) cookie file kept on user’s host, managedsite for first
by user’s
browser time
4) back-end database at Web site
 when initial HTTP
requests arrives at
site, site creates:
 Unique cookie ID
 entry in backend
database for ID
2: Application Layer 54
 Cookies: keep “state” (cont.)
Amazon
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-
55
Cookies (continued)
aside
What cookies can Cookies and privacy:
bring:  cookies permit sites
 authorization to learn a lot about
 shopping carts you
 recommendations  you may supply
 user session state private info, e.g.
(Web e-mail) name and e-mail to
How to keep “state”: sites
 protocol endpoints: maintain
state at sender/receiver over
multiple transactions
 cookies: http messages which
carry state
2: Application Layer 56
 Web caches (proxy server)
Goal: satisfy client request without involving origin
server
 user sets browser:
Web accesses via
cache (proxy server) HT proxy
TP
server q uest
req re
 browser sends all HT
client TP
ues
t TT P
nse
res H p o origin
pon res
HTTP requests to se HT
TP server
t
cache ues
req e s
 if object in cache: TTP pon
H res
cache returns object TP
HT
 else cache requests
object from origin client origin
server, then returns server
object to client and
keeps a copy
2: Application Layer 57
More about Web caching
 cache acts as both why Web caching?
 reduce response time
client and server
 server for original for client request
requesting client  reduce traffic on an
 client to origin server
institution’s access link
 Internet dense with
 typically cache is
caches: enables “poor”
installed by ISP
content providers to
(university,
effectively deliver
company, residential
content (so too does
ISP)
P2P file sharing)

Application Layer 2-
58
Caching example:
assumptions:
 avg object size: 100K bits
origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router
to any origin server: 2 sec 1.54 Mbps
 access link rate: 1.54Mbps access link

problem! institutional
consequences: network
 LAN utilization: 15% 1 Gbps LAN
 access link utilization = 99%
 total delay = Internet delay
+ access delay + LAN delay
= 2 sec + minutes + msecs
Application Layer 2-59
 Caching example: fatter
access link
assumptions:
 avg object size: 100K bits
origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router
to any origin server: 2154
sec 1.54 Mbps
154 Mbps
 access link rate: 1.54 Mbps access link
Mbps
institutional
consequences: network
 LAN utilization: 15%9.9% 1 Gbps LAN
 access link utilization = 99%
 total delay = Internet delay +
access delay + LAN delay
= 2 sec + msecs
minutes + msecs

Cost: increased access link speed (not cheap!) Application Layer 2-60
 Caching example: install
local cache
assumptions:
 avg object size: 100K bits
origin
 avg request rate from servers
browsers to origin public
servers:15/sec Internet
 avg data rate to browsers:
1.50 Mbps
 RTT from institutional router
to any origin server: 2 sec 1.54 Mbps
 access link rate: 1.54 Mbps access link
institutional
consequences: network
 ?
LAN utilization: 15% 1 Gbps LAN
 ?
access link utilization = 100% local web
 Howdelay
total to compute
= Internetlink
delay + cache
utilization,
access delay + LANdelay?
delay
= 2 sec + minutes + usecs
Cost: web cache (cheap!)
Application Layer 2-61
Caching example: install local
cache
Calculating access link
utilization, delay with
origin
cache: servers
 suppose cache hit rate is public
0.4 Internet
• 40% requests satisfied at
 access link utilization:
cache, 60% requests
 60% of requests use access link
satisfied at origin
 data rate to browsers over 1.54 Mbps
access link
access link
= 0.6*1.50 Mbps = .9 Mbps institutional
 utilization = 0.9/1.54 = .58 network
1 Gbps LAN
 total delay
 = 0.6 * (delay from origin local web
servers) +0.4 * (delay when cache
satisfied at cache)
 = 0.6 (2.01) + 0.4 (~msecs) =
~ 1.2 secs
 less than with 154 Mbps link
Application Layer 2-62
(and cheaper too!)
BUT is caching without any
problems? is the cached data always current?
Conditional GET cache server
 Goal: don’t send
object if cache has HTTP request msg
object
up-to-date cached If-modified-since: <date>
not
version modified
• no object HTTP response
before
transmission delay HTTP/1.0
304 Not Modified <date>
• lower link utilization
 cache: specify date
of cached copy in
HTTP request HTTP request msg
If-modified-since: If-modified-since: <date> object
<date> modified
 server: response HTTP response after
contains no object if HTTP/1.0 200 OK <date>
cached copy is up- <data>
to-date: DOES THIS SOLVE THE PROBLEM?Application Layer 2-63
Whats coming
 HTTPv3 is the upcoming third major version of the
Hypertext Transfer Protocol used to exchange information
on the World Wide Web, alongside HTTPv1.1 and HTTPv2
 HTTP semantics are consistent across versions:
 the same request methods, status codes, and message fields are
typically applicable to all versions. The differences are in the
mapping of these semantics to underlying transports. Both
HTTPv1.1 and HTTPv2 use TCP as their transport.
 HTTPv3 uses QUIC, a transport layer network protocol
developed initially by Google where user space
congestion control is used over the User Datagram
Protocol (UDP).
 The switch to QUIC aims to fix a major problem of HTTP/2
called "head-of-line blocking": because of the parallel
nature of default. Safari 14 will ship with HTTPv3 enabled by default.
https://en.wikipedia.org/wiki/HTTP/3
2: Application Layer 64
HTTPv2
Key goal: decreased delay in multi-object
HTTP requests

HTTPv1.1: introduced multiple, pipelined GETs

over single TCP connection
 server responds in-order (FCFS: first-come-first-served
scheduling) to GET requests
 with FCFS, small object may have to wait for
transmission (head-of-line (HOL) blocking) behind
large object(s)
 loss recovery (retransmitting lost TCP segments) stalls
object transmission Application Layer: 2-65
HTTPv2
Key goal: decreased delay in multi-object
HTTP requests
HTTPv2: [RFC 7540, 2015] increased flexibility at server
in sending objects to client:
• methods, status codes, most header fields unchanged
from HTTP v1.1
• transmission order of requested objects based on
client-specified object priority (not necessarily FCFS)
• push unrequested objects to client
• divide objects into frames, schedule frames to mitigate
HOL blocking
Application Layer: 2-66
HTTPv2: mitigating HOL blocking
HTTP v1.1: client requests 1 large object (e.g., video file,
and 3 smaller objects)
server
GET GET GET GET
O4 O3 O2 object data
client O1
requested

O1

O2
O
O O3
1
2
O
O
O4
3
4

objects delivered in order requested: O2, O3, O4 wait

behind O1
Application Layer: 2
HTTPv2: mitigating HOL blocking
HTTPv2: objects divided into frames, frame transmission
interleaved
server

GET
object data
GET GET
O4 O3 O2
GET requested
client O1

O
2 O

4 O O1
3

O2
O3
O O4
1

O2, O3, O4 delivered quickly, O1 slightly

Application Layer: 2-68
delayed
HTTPv2 to HTTPv3
Key goal: decreased delay in multi-object
HTTP requests
HTTPv2 over single TCP connection means:
• recovery from packet loss still stalls all object
transmissions
• as in HTTP v1.1, browsers have incentive to open multiple
parallel TCP connections to reduce stalling, increase overall
throughput
 no security over vanilla TCP connection
 HTTPv3: adds security , per object error- and
congestion-control (more pipelining) over UDP
As of August 2021, the HTTPv3 protocol is still officially
an Internet Draft, but is already supported by 73% of running
web browsers and, according to W3Techs, 21% of the top 10 Application Layer: 2-69
million websites.
Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
 2.2 Web and HTTP  2.7 Socket
 2.3 FTP programming with TCP
 2.4 Electronic Mail  2.8 Socket
 SMTP, POP3, IMAP programming with
 2.5 DNS UDP
 2.9 Building a Web
server

2: Application Layer 70
FTP: the file transfer protocol

FTP file transfer

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

2: Application Layer 71
FTP: separate control, data
connections
TCP control
 FTP client contacts FTP connection
port 21
server at port 21, TCP is
transport protocol TCP data connection
 client authorized over control FTP port 20 FTP
connection client server
 client browses remote  server opens another TCP
directory by sending
data connection to transfer
commands over control
another file.
connection.
 control connection: “out of
 when server receives file
band”
transfer command, server
 FTP server maintains
opens 2nd TCP connection,
port 20 (for file) to client “state”: current directory,
 earlier authentication
after transferring one file,
server closes data
2: Application Layer 72
connection.
Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
 2.2 Web and HTTP  2.7 Socket
 2.3 FTP programming with TCP
 2.4 Electronic Mail  2.8 Socket
 SMTP, POP3, IMAP programming with
 2.5 DNS UDP

2: Application Layer 74
Electronic Mail user
outgoing
message queue
agent user mailbox

Three major
components: mail
server user
 user agents agent
 mail servers SMTP mail user
 simple mail transfer server agent
protocol: SMTP SMTP
User Agent SMTP user
 a.k.a. “mail reader” mail agent
 composing, editing, server

reading mail messages

 e.g. Outlook, Mozilla
Thunderbird, iphone mail client
user user
 outgoing, incoming agent
agent
messages stored on
server 2: Application Layer 75
Electronic Mail: mail servers
user
agent
Mail Servers
 mailbox contains mail user
incoming messages for server agent
user
SMTP mail user
 message queue of
server agent
outgoing (to be sent) mail
messages SMTP
 SMTP protocol between user
SMTP agent
mail servers to send email mail
messages server
 client: sending mail
server user
 “server”: receiving user agent
agent
mail server
2: Application Layer 76
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
 three phases of transfer
 handshaking (greeting)
 transfer of messages
 closure
 command/response interaction
 commands: ASCII text
 response: status code and phrase

 messages must be in 7-bit ASCII

2: Application Layer 77
Scenario: Alice sends message to
Bob
1) Alice uses User Agent 4) SMTP client sends Alice’s
(UA) to compose message over the TCP
message to connection
[email protected] 5) Bob’s mail server places
2) Alice’s UA sends the message in Bob’s
message to her mail mailbox
server; message placed 6) Bob invokes his user
in message queue agent to read message
3) Client side of SMTP opens
TCP connection with
Bob’s mail server
1 mail
mail
server user
user server
2 agent
agent 3 6
4 5

2: Application Layer 78
Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... 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 hamburger.edu closing connection

2: Application Layer 79
Try SMTP interaction for yourself:

 telnet servername 25
 see 220 reply from server
 enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands
above lets you send email without using email
client (reader)

2: Application Layer 80
Mail message format

SMTP: application layer protocol for exchanging email

msgs header
blank
RFC 822: standard for text message format:
line
 header lines, e.g.,
 To:
 From:
 Subject:
body
different from SMTP commands!
 body
 the “message”, ASCII characters only

2: Application Layer 82
 Mail access protocols
SMTP SMTP access user
user
agent protocol agent

sender’s mail receiver’s mail

server server
 Mail access protocol: retrieval from
 SMTP:
server
delivery/storage  POP: Post Office Protocol [RFC 1939]
to receiver’s
• authorization (agent <-->server)
server
and download
 IMAP: Internet Mail Access Protocol
[RFC 1730]
• more features (more complex)
• manipulation of stored msgs on
server
2: Application Layer 83
 HTTP: gmail, Hotmail, Yahoo! Mail,
POP3 protocol S: +OK POP3 server ready
C: user bob
authorization phase S: +OK
C: pass hungry
 client commands:
S: +OK user successfully logged on
 user: declare
C: list
username
S: 1 498
 pass: password
S: 2 912
 server responses S: .
 +OK C: retr 1
S: <message 1 contents>
 -ERR
S: .
transaction phase, client: C: dele 1
 list: list message C: retr 2
S: <message 1 contents>
numbers S: .
 retr: retrieve message C: dele 2
by number C: quit
 dele: delete S: +OK POP3 server signing off
 quit 2: Application Layer 84
POP3 (more) and IMAP
More about POP3 IMAP
 Previous example  Keep all messages in
uses “download and one place: the server
delete” mode.  Allows user to
 Bob cannot re-read organize messages
e-mail if he changes in folders
client  IMAP keeps user
 “Download-and- state across
keep”: copies of sessions:
messages on  names of folders and
different clients mappings between
 POP3 is stateless message IDs and
folder name
across sessions
2: Application Layer 85
Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
 2.2 Web and HTTP  2.7 Socket
 2.3 FTP programming with TCP
 2.4 Electronic Mail  2.8 Socket
 SMTP, POP3, IMAP programming with
 2.5 DNS UDP
 2.9 Building a Web
server

2: Application Layer 86
DNS: Domain Name System

People: many identifiers: Domain Name System:

 ID, Social Security Name,name,
distributed
passport
database
#
Internet devices: hosts, routers:implemented in hierarchy of
many name servers
 IP address (32 bit) - used by internet devices for
 application-layer protocol
addressing datagrams, e.g. 1001 …11
allows host, routers, name
 “name”, e.g., www.yahoo.com - used by humans
servers to communicate to
Q: map between IP addresses resolveand
namesname ?
(address/name translation)
 note: core Internet
function, implemented
as application-layer
protocol
 complexity at network’s
“edge”
2: Application Layer 87
DNS services

Main function:
 hostname to IP address Why not centralize
translation (e.g. www.yahoo.com to 1001 DNS?
…11)
 single point of failure
Plus:  traffic volume
 host aliasing  distant centralized
 Canonical, alias database
(pseudonym) names
 maintenance
 mail server aliasing
 load distribution
doesn’t scale!
 replicated Web servers: set
of IP addresses for one
canonical name (e.g.
amazon.com)
2: Application Layer 88
Distributed, Hierarchical
Database

Root DNS Servers

TLD servers
org DNS servers edu DNS servers
com DNS servers …
pbs.org poly.edu umass.edu
yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers
Authoritative
servers

2: Application Layer 89
 DNS: Root name servers
 contacted by local name server that cannot resolve name
 root name server:
 contacts authoritative name server if name mapping not
known
 gets mapping
 returns mapping to local name server
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD k RIPE London (also 16 other locations)
g US DoD Vienna, VA
h ARL Aberdeen, MD i Autonomica, Stockholm (plus
j Verisign, ( 21 locations) 28 other locations)
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
f Internet Software C. Palo Alto, Paris, SF)
CA (and 36 other locations)

13 root name
servers
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA worldwide

2: Application Layer 91
TLD and Authoritative
Servers
 Top-level domain (TLD) servers:
 responsible for com, org, net, edu, etc, and all
top-level country domains, e.g. uk, fr, ca, jp,
cy.
• Network Solutions maintains servers for com TLD
• Educause for edu TLD
• UCY for .cy

 Authoritative DNS servers:

 organization’s DNS servers, providing
authoritative hostname to IP mappings for
organization’s servers (e.g., Web, mail).
 can be maintained by organization or service
provider
2: Application Layer 92
Local 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
 acts as proxy, forwards query into
hierarchy

2: Application Layer 93
 Distributed, Hierarchical
Database
Root DNS Servers

TLD servers

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers
Authoritative
servers
Client wants IP for www.amazon.com; 1st approx:
 client queries a root server to find .com DNS
server
 client queries .com DNS server to get
amazon.com DNS server
 client queries amazon.com DNS server to get IP
address for www.amazon.com 2: Application Layer 94
DNS name root DNS server

resolution example
2
 Host at cis.poly.edu 3
TLD DNS server
wants IP address 4
for 5
gaia.cs.umass.edu
a) iterated query: local DNS server
dns.poly.edu
 contacted server
7 6
replies with name of 1 8
server to contact
 “I don’t know this authoritative DNS server
dns.cs.umass.edu
name, but ask this requesting host
server” cis.poly.edu

gaia.cs.umass.edu

2: Application Layer 95
DNS name
resolution example root DNS server

b) recursive query: 2 3
 puts burden of
7 6
name resolution on
TLD DNS server
contacted name
server
 heavy load on root local DNS server
dns.poly.edu 5 4
DNS server?
1 8

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

2: Application Layer 96
DNS: caching and updating
records
 once (any) name server learns mapping, it
caches mapping
 cache entries timeout (disappear) after
some time
 TLD servers typically cached in local name
servers
• Thus root name servers not often visited
 update/notify mechanisms under design by
IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html

2: Application Layer 97
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type,
ttl)

 Type=A  Type=CNAME
 name is hostname  name is alias name for some
 value is IP address “canonical” (the real) name
 Type=NS www.ibm.com is really
servereast.backup2.ibm.com
 name is domain (e.g.
 value is canonical name
foo.com)
 value is hostname of
 Type=MX
authoritative name  value is name of
server for this domain
mailserver associated with
name
2: Application Layer 98
Inserting records into DNS
 example: new startup “Network Utopia”

 register name networkuptopia.com at DNS

registrar (e.g., Network Solutions)
 provide names, IP addresses of authoritative name
server (primary and secondary)
 registrar inserts two RRs into .com TLD server:
hostname of authoritative name
server for this domain Type
domain
(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)
hostname IP address

2: Application Layer 99
Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
 app architectures  2.7 Socket
 app requirements
programming with TCP
 2.2 Web and HTTP 2.8 Socket
 2.4 Electronic Mail programming with
 SMTP, POP3, IMAP UDP
 2.5 DNS

2: Application Layer 102

Pure P2P architecture
 no always-on server
 arbitrary end systems
directly communicatepeer-peer
 peers can be
intermittently
connected and change
IP addresses

 Three topics:
 File distribution
 Searching for
information
 Case Study: Skype
2: Application Layer 103
P2P file sharing Bob

peers
 Alice chooses one of
Example the peers, Bob.
Alice
 Alice runs P2P client  file is copied
application on her from
notebook computer Bob’s PC to Alice’s
 intermittently connects tonotebook:
Internet;HTTP
gets new IP
 while Alice
address for each connection
 asks for “Hey Jude” downloads, other
users uploading from
 application displays other peers that have
Alice.
copy of Hey Jude.
 Alice’s peer is both a
Web client and a
transient Web server.
All peers are servers =
highly scalable!
2: Application Layer 104
P2P: centralized directory
Bob
original “Napster” centralized
design directory server
1
1) when peer connects, peers

it informs central 1

server:
1 3
 IP address
 content 2 1

2) Alice queries for “Hey

Jude”
Server provides
address of Bob Alice

4) Alice requests file

from Bob directly 2: Application Layer 105
P2P: problems with centralized
directory
 single point of failure file transfer is
 performance decentralized, but
bottleneck locating content is
 copyright highly centralized
infringement: “target”
of lawsuit is obvious

2: Application Layer 106

Query flooding: Gnutella
 fully distributed
overlay network: graph
 no central server
 edge between peer X and Y if there’s a TCP
 public domain protocol
connection
 many Gnutella clients implementing protocol
 all active peers and edges form overlay net
 edge: virtual (not physical) link
 given peer typically connected with < 10
overlay neighbors

2: Application Layer 107

Gnutella: protocol
File transfer:
 Query
HTTP
message
sent over Bob
Query
existing TCP
QueryHit
connections
 peers forward ery Qu
ery
Qu Hit
Query message ery
 QueryHit Qu
Query
sent over
QueryHit
reverse Jude
path Scalability:
Qu
File Transfer er
y limited scope
directly from flooding
Bob to Jude
2: Application Layer 108
Gnutella: Peer joining
1. A joining peer, Alice, must find another peer
in Gnutella network: use list of candidate
peers
2. Alice sequentially attempts TCP connections
with candidate peers until a connection is
setup with Bob
3. Flooding: Alice sends Ping message to Bob;
Bob forwards Ping message to his overlay
neighbors (who then forward to their
neighbors….)
 peers receiving Ping message respond to
Alice with Pong message
4. Alice receives many Pong messages, and can
then setup additional TCP connections
2: Application Layer 109
File Distribution: Server-Client vs
P2P
Question : How much time to distribute file
(size F) from one server to N peers?
What is the bottleneck?
us: server upload
capacity
di: peer i download
file, size F u1 d1 bandwidth
us u2 d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
bandwidth
peer upload/download
capacity is limited resource 2: Application Layer 111
File distribution time: client-server
 server transmission:
F
must sequentially send us
(upload) N file copies: di
 time to send one copy: network
ui
F/us
 time to send N copies:
NF/us
 client: each client must
download file copy
• dmin = min client
download rate
• min client download time:
F/dtime
min to distribute F
to N clients using
Dc-s > max{NF/us,,F/dmin}
client-server approach

Application Layer
increases linearly in N 112
File Distribution: Server-Client vs
P2P
 Since 10 Mbps shared equally among N (10) users,
then effective download speed of 1 Mbps,
 Is this less than the upload bandwidth of each
user? YES
 Then total time is equal to 4 Mbits / 1Mbps = 4
seconds to download file (by all users)

 What happens if N=100?

 then 40 seconds to download file (by all users)

 What happens if N=10, and 1 user upload speed

reduces to 100 kbps?
 then 40 seconds to download file (dictated by
the slowest user) 2: Application Layer 113
File distribution time: P2P
 server transmission:
must upload at least F
us
one copy
di
 client:to
 time sendclient
each one copy:
must network
F/us
download file copy ui
• min client download time:
F/dmin
 clients: as aggregate must download NF
bits
• max upload rate (limiting max download
timerate)
to distribute Sui
is us + F
DP2P > max{F/us,,F/dmin,,NF/(us +
to N clients using Sui)}
P2P approach

increases linearly in N …
… but so does this, as each peer brings service capacity
Application Layer 114
 Server-client vs. P2P: example
ient upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us

3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

N
2: Application Layer 115
 P2P file distribution: BitTorrent
 file divided into 256Kb chunks
 peers in torrent send/receive file chunks

tracker: tracks peers torrent: group of

participating in torrent peers exchanging
chunks of a file

Alice arrives …
… obtains list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

Application Layer 116

P2P file distribution:
BitTorrent
 peer joining torrent:
 has no chunks, but will
accumulate them over
time from other peers
 registers with tracker
to get list of peers,
connects to subset of
peers (“neighbors”)

 while downloading, peer uploads chunks to other

peers
 peer may change peers with whom it exchanges
chunks
 churn: peers may come and go
 once peer has entire file, it may (selfishly) leave
Application Layer 117
BitTorrent: requesting, sending file
chunks
requesting chunks: sending chunks: tit-for-
 at any given time, tat
different peers have  Alice sends chunks to
different subsets of file those four peers currently
sending her chunks at
chunks highest rate
 periodically, Alice asks • other peers are choked by
each peer for list of Alice (do not receive chunks
from her)
chunks that they have • re-evaluate top 4 every10
 Alice requests missing secs
chunks from peers,  every 30 secs: randomly
rarest first select another peer,
starts sending chunks
• “optimistically unchoke” this
peer Application Layer 2-
• newly chosen peer may join 11
BitTorrent (1)
 file divided into 256KB chunks.
 peer joining torrent:
 has no chunks, but will accumulate them over
time
 registers with tracker to get list of peers,
connects to subset of peers (“neighbors”)
 while downloading, peer uploads chunks to
other peers.
 peers may come and go
 once peer has entire file, it may (selfishly) leave
or (altruistically) remain
2: Application Layer 119
BitTorrent mechanism(2)
Sending Chunks: tit-for-
Pulling Chunks tat
 at any given time,  Alice sends chunks to
different peers have four neighbors currently
different subsets of sending her chunks at
file chunks the highest rate
 periodically, a peer  re-evaluate top 4
(Alice) asks each every 10 secs
neighbor for list of  every 30 secs: randomly
chunks that they
select another peer,
have.
starts sending chunks
 Alice sends requests
 newly chosen peer
for her missing
may join top 4
chunks
 “optimistically
2: Application Layer 120
 rarest first
 BitTorrent: tit-for-tat
1) Alice “optimistically unchokes” Bob
Alice becomes one of Bob’s top-four providers; Bob reciproca
) Bob becomes one of Alice’s top-four providers

higher upload rate: find

better trading partners,
get file faster !
Application Layer 2-
12
 P2P Case study: Skype
Skype clients (SC)
 inherently P2P:
pairs of users
communicate. Skype
 proprietary login server Supernode
application-layer (SN)
protocol (inferred via
reverse engineering)
 hierarchical overlay
with Supernodes
(SNs)
 Index maps
usernames to IP
addresses; 2: Application Layer 122
 Skype: making a call
Skype
Client
 User (SC) starts Skype (SC)

 SC registers with SN
 list of bootstrap SNs Skype
login server
 SC logs in
(authenticate)
 Call: SC contacts SN with
Supernode
callee ID (SN)

 SN contacts other SNs

(unknown protocol, maybe
flooding) to find addr of
callee; returns addr to SC
 SC directly contacts callee, overTCP

2: Application Layer 124

Chapter 2: Application layer
 2.1 Principles of network
 applications
2.6 P2P applications
 2.2 Web and HTTP  2.7 Socket
 2.3 FTP programming with TCP
 2.4 Electronic Mail  2.8 Socket
 SMTP, POP3, IMAP programming with
 2.5 DNS UDP

2: Application Layer 125

Socket programming
Goal: learn how to build client/server
application that communicate using
sockets
Socket API socket
 introduced in BSD4.1 UNIX,
a host-local,
1981 application-created,
 explicitly created, used,
OS-controlled interface
released by apps (a “door”) into which
 client/server paradigm application process can
 two types of transport both send and
service via socket API: receive messages
 unreliable datagram to/from another
(UTP) application process
 reliable, byte stream-
oriented (TCP)
2: Application Layer 126
Socket-programming using TCP
Socket: a door between application process and
end-end-transport protocol (UDP or TCP)
TCP service: reliable transfer of bytes from one
process to another

controlled by
controlled by process application
application process
developer
developer socket socket
controlled by TCP with TCP with controlled by
buffers, operating
operating buffers, internet system
system variables variables

host or host or
server server

2: Application Layer 127

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

TCP create socket,

wait for incoming
connection request connection setup connect to hostid, port=x
connectionSocket = clientSocket =
welcomeSocket.accept() Socket()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket
2: Application Layer 129
Chapter 2: Summary
our study of network apps now
complete!
 application  specific protocols:
architectures  HTTP
 client-server
 FTP
 P2P
 SMTP, POP, IMAP
 hybrid
 DNS
 application service
 P2P: BitTorrent, Skype
 others …
requirements:
 reliability, bandwidth,
delay  socket programming
 Internet transport
service model
 connection-oriented,
reliable: TCP
 unreliable, datagrams: 2: Application Layer 144
 Chapter 2: Summary
Most importantly: learned about
application layer protocols
 e.g. typical Important themes:
request/reply message  centralized vs.
exchange: decentralized
 client requests info or  stateless vs. stateful
service  reliable vs. unreliable
 server responds with
data, status code
msg transfer
 “complexity at
 message formats:
 headers: fields giving info network edge”
about data  client server vs peer-
 data: info being to-peer
communicated 2: Application Layer 145