Chapter 2: Application layer

r 2.1 Principles of network r 2.6 P2P file sharing

applications r 2.7 Socket programming
r 2.2 Web and HTTP with TCP
r 2.3 FTP r 2.8 Socket programming
r 2.4 Electronic Mail with UDP
v SMTP, POP3, IMAP r 2.9 Building a Web server
r 2.5 DNS

2: Application Layer 65
DNS: Domain Name System

r Imagine a world without DNS

r You would have to remember the IP addresses of

v Every website you want to visit
v Your bookmarks will be a list of IP addresses

v You will speak like

“I went to 167.33.24.10, and there was an awesome
link to 153.11.35.81… “

2: Application Layer 66
DNS: Domain Name System

People: many identifiers: Domain Name System:

v SSN, name, passport # r distributed database implemented in
hierarchy of many name servers

Internet hosts, routers: r application-layer protocol host,

routers, name servers to communicate
v IP address (32 bit) - used
to resolve names (address/name
for addressing datagrams translation)
v “name”, e.g., v note: core Internet function,
ww.yahoo.com - used by implemented as application-layer
humans protocol
v complexity at network’s “edge”

Q: map between IP addresses

and name ?
2: Application Layer 67
 DNS , e.

DNS services Why not centralize DNS?

r Hostname to IP address r single point of failure
translation r traffic volume
r distant centralized database
r Host aliasing
v Canonical and alias names doesn’t scale!
tokyo.ibm.com ibm.com
r Load distribution
v Replicated Web servers: set
of IP addresses for one
canonical name

2: Application Layer 68
 Distributed, Hierarchical Database servers
Root → 13 such root DNS
→
Root DNS Servers

TLD →
com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

Auth → yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

Client wants IP for www.amazon.com; 1st approx:

r Client queries a root server to find .com DNS server
r Client queries com DNS server to get amazon.com DNS server
r Client queries amazon.com DNS server to get IP address for
www.amazon.com web server

client queries same amazon.com DNS server

☐ 2: Application Layer 69
to get IP address of mail.amazon.com mail server .
h¥④
a.am
-

(
☒

Illinois Univ ¥" amazon.com

I ☒* ☒
:É ←☒
 DNS: Root name servers boss :
ask the

→ Hoot of
r contacted by local name server that can not resolve name
the tree
r root name server:
v contacts authoritative name server if name mapping not known
v gets mapping
v returns mapping to local name server
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD k RIPE London (also Amsterdam,
g US DoD Vienna, VA Frankfurt)
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3
j Verisign, ( 11 locations) other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)

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

2: Application Layer 70
TLD and Authoritative Servers
r Top-level domain (TLD) servers:
v responsible for com, org, net, edu, etc.
v all top-level country domains uk, fr, ca, jp.
v Network solutions maintains servers for com TLD
v Educause for edu TLD

r Authoritative DNS servers:

v An organization’s DNS servers,
• providing authoritative hostname to IP mappings for
organization’s servers (e.g., Web and mail).
v Can be maintained by organization or service provider

2: Application Layer 71
Local Name Server
r Does not strictly belong to hierarchy

r Each ISP (residential, company, univ) has one.

v Also called “default name server”

r When a host makes a DNS query

v query is sent to its local DNS server
v Acts as a proxy, forwards query into hierarchy.

2: Application Layer 72
 root DNS server
Example
2 .edu
r Iterative Querying 3
TLD DNS server
Host at cis.poly.edu 4
wants IP address for
5
gaia.cs.umass.edu
local DNS server illinois .edu ault
dns.poly.edu
7 6
1 8

authoritative DNS server

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

gaia.cs.umass.edu

2: Application Layer 73
 "

Recursive queries root DNS server

recursive query: Unique

2 3
r puts burden of name
resolution on contacted 7 6
name server TLD DNS server
r heavy load?

iterated query: local DNS server

dns.poly.edu 5 4
r contacted server replies
with name of server to 1 8
contact
r “I don’t know this name, authoritative DNS server
dns.cs.umass.edu
but ask this server” requesting host
cis.poly.edu

gaia.cs.umass.edu
Which is a better design choice? 2: Application Layer 74
DNS: caching and updating
records

r Once (any) name server learns mapping, it caches mapping

v cache entries timeout (disappear) after some time
v TLD servers typically cached in local name servers
• Thus root name servers not often visited

r Update/notify mechanisms under design by IETF

L
v RFC 2136
v http://www.ietf.org/html.charters/dnsind-charter.html

2: Application Layer 75
 Auth →
( cnn.com
,
166.34-33.11 ,
A ,
10
)
TLD ( cnn.com 166.34-23.18
→ , NS 10
)
DNS records
, ,

4categories.tt
DNS: distributed db storing resource records (RR)
RR format: (name,
-
value, type, ttl)
NS
CNAME
MX

r Type=A r Type=CNAME time to live

v name is hostname v name is alias name for some
v value is IP address “canonical” (the real) name
www.ibm.com is really
r Type=NS alias ←
servereast.backup2.ibm.com
v name is domain (e.g.
value is canonical name
foo.com)
v
cannonical
v value is hostname of r Type=MX
authoritative name server for
v value is name of mailserver
this domain
associated with name

2: Application Layer 76
 ☐ Local

→
Everest . ibm

D
com
local

(ibm.com ,
servereast.ibm.com C. NAME
)
10

÷imwm?
, ,

""
"'
"

(servereast ,
I 13.63.11.12 , A ,
)
10
?⃝
DNS protocol, messages
DNS protocol : query and reply messages, both with same
message format

msg header
r identification: 16 bit # for
query, reply to query uses
same #
r flags:
v query or reply
v recursion desired
v recursion available
v reply is authoritative

2: Application Layer 77
DNS protocol, messages

Name, type fields

for a query

RRs in response
to query

records for
authoritative servers

additional “helpful”
info that may be used

2: Application Layer 78
 ←i
Inserting records into DNS
r Example: just created startup “Network Utopia”
←
☒
I Pw
r Register name networkuptopia.com at a registrar (e.g.,
Network Solutions)
v Need to provide registrar with names and IP addresses of your
authoritative name server (primary and secondary)
v Registrar inserts two RRs into the com TLD server:
server
name

=
→
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
.

( networkuto.com ,
212 .
212.212.1 , A)
r Also, in the startup’s Auth server, put Type A record for
www.networkuptopia.com and Type MX record for
networkutopia.com
r How do people get the IP address of your Web site?
2: Application Layer 79
Questions ?

2: Application Layer 80
Chapter 2: Application layer
r 2.1 Principles of network r 2.6 P2P file sharing [ Napster ,
Gnrxtella, a)
kaza

applications r 2.7 Socket programming

v app architectures with TCP
v app requirements
r 2.8 Socket programming
r 2.2 Web and HTTP with UDP
r 2.4 Electronic Mail r 2.9 Building a Web server
v SMTP, POP3, IMAP
r 2.5 DNS

2: Application Layer 81
P2P file sharing
r Alice chooses one of the
Example peers, Bob.
r Alice runs P2P client r File is copied from Bob’s
application on her notebook PC to Alice’s notebook:
computer HTTP
r Intermittently connects to
Internet; gets new IP address r While Alice downloads,
for each connection other users uploading
r Asks for “Hey-Jude.mp3” from Alice.
r Application displays other peers r Alice’s peer is both a Web
that have copy of Hey Jude. client and a transient Web
server.
All peers are servers = highly
scalable!
2: Application Layer 82
P2P: centralized directory
Bob
original “Napster” design centralized
directory server
1) when peer connects, it 1
informs central server: peers

v IP address 1

v content
1 3
2) Alice queries for “Hey
has it 2
Jude” Server informs that Bob
•
.
1

3) Alice requests file from Bob

Alice

2: Application Layer 83
P2P: problems with centralized directory

r Single point of failure file transfer is

r Performance bottleneck decentralized, but
r Copyright infringement
locating content is highly
centralized

2: Application Layer 84
Query flooding: Gnutella
r fully distributed overlay network: graph
v no central server r edge between peer X and
r public domain protocol Y if there’s a TCP
r many Gnutella clients connection
implementing protocol r all active peers and edges
is overlay net
r Edge is not a physical link
r Given peer will typically
be connected with < 10
overlay neighbors

2: Application Layer 85
Gnutella: protocol
File transfer:
r Query message HTTP
sent over existing TCP
connections
Query
r peers forward
QueryHit
Query message
ry Qu
r QueryHit e ery
Qu H it
sent over ery
Qu
reverse
Query
path
QueryHit

Scalability: Qu
er
y
limited scope
flooding
2: Application Layer 86
 A

Gnutella: Peer joining i *¥17T

ernet
1. Joining peer X must find some other peer in Gnutella
network: use list of candidate peers

¥ ÷¥
X sequentially attempts to make TCP with peers on list

0
2.
until connection setup with Y
3. X sends Ping message to Y; Y forwards Ping message.
4. All peers receiving Ping message respond with Pong
message
5. X receives many Pong messages. It can then setup
additional TCP connections

What happens when peer leaves: find out as an exercise!

2: Application Layer 87
Exploiting heterogeneity: KaZaA

r Each peer is either a group *

leader or assigned to a

¥
group leader.
v TCP connection between peer
and its group leader.
v TCP connections between
some pairs of group leaders.
r Group leader tracks the
content in all its children.
Hotdai .

2: Application Layer 88
KaZaA: Querying
r Each file has a hash and a descriptor
r Client sends keyword query to its group leader
r Group leader responds with matches:
v For each match: metadata, hash, IP address

r If group leader forwards query to other group

leaders, they respond with matches
r Client then selects files for downloading
v HTTP requests using hash as identifier sent to peers
holding desired file

2: Application Layer 89
KaZaA tricks
r Limitations on simultaneous uploads
r Request queuing
r Incentive priorities
r Parallel downloading

For more info:

r J. Liang, R. Kumar, K. Ross, “Understanding KaZaA,”
(available via cis.poly.edu/~ross)

2: Application Layer 90
Chapter 2: Application layer
r 2.1 Principles of network r 2.6 P2P file sharing
applications r 2.7 Socket programming
r 2.2 Web and HTTP with TCP
r 2.3 FTP r 2.8 Socket programming
r 2.4 Electronic Mail with UDP
v SMTP, POP3, IMAP r 2.9 Building a Web server
r 2.5 DNS

2: Application Layer 91