DNS and P2P File Sharing

Stan Kurkovsky

Computer Networks

DNS and

P2P File Sharing

Based on Computer Networking, 4th_{Edition by Kurose and Ross}

DNS: Domain Name System

People:many identifiers: • SSN, name, passport # Internet hosts, routers:

• IP address (32 bit) - used for addressing datagrams • “name”, e.g., www.yahoo.com - used by humans Q:map between IP addresses and name ?

Domain Name System:

• distributed databaseimplemented in hierarchy of many name servers

• application-layer protocolhost, routers, name servers to communicate to

resolvenames (address/name translation)

• note: core Internet function, implemented as application-layer protocol

Stan Kurkovsky

DNS

DNS services

• Hostname to IP address translation • Host aliasing

• Canonical and alias names • Mail server aliasing

• Load distribution

• Replicated Web servers: set of IP addresses for one canonical name Why not centralize DNS?

• single point of failure • traffic volume

• distant centralized database • maintenance

doesn’t scale!

Distributed, Hierarchical Database

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

Root DNS Servers

com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers

Stan Kurkovsky

DNS: Root name servers

• contacted by local name server that can not resolve name • root name server:

• contacts authoritative name server if name mapping not known • gets mapping

• returns mapping to local name server

b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. PaloAlto, CA (and 17 other locations)

i Autonomica, Stockholm (plus 3 other locations) k RIPE London (also Amsterdam, Frankfurt)

m WIDE Tokyo a Verisign, Dulles, VA

c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations)

13 root name servers worldwide

TLD and Authoritative Servers

• Top-level domain (TLD) servers

• Responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.

• Network Solutions maintains servers for com TLD • Educause for edu TLD

• Authoritative DNS servers

• Organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web and mail).

Stan Kurkovsky

Local Name Server

• Does not strictly belong to hierarchy • Each ISP (residential ISP, company,

university) has one.

• Also called “default name server” • When a host makes a DNS query,

query is sent to its local DNS server • Acts as a proxy,

forwards query into hierarchy • Example

• Host at cis.poly.edu wants IP address for gaia.cs.umass.edu

requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server Recursive queries recursive query:

• puts burden of name resolution on contacted name server

• heavy load? iterated query:

• contacted server replies with name of server to contact

• “I don’t know this name, but ask this server” requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server 3

Stan Kurkovsky

DNS: caching and updating records

• once (any) name server learns mapping, it cachesmapping • 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

DNS records

DNS:distributed db storing resource records (RR)

• Type=A

• name is hostname • value is IP address • Type=NS

• name is domain (e.g. foo.com)

• value is hostname of authoritative name server for this domain • Type=CNAME

• name is alias name for some “canonical” (the real) name www.ibm.com is really

servereast.backup2.ibm.com • value is canonical name • Type=MX

• value is name of mailserver associated with name

RR format:

Stan Kurkovsky

DNS protocol, messages

DNS protocol:queryand reply messages, both with same message format msg header

• identification:16 bit # for query, reply to query uses same # • flags:

• query or reply • recursion desired • recursion available • reply is authoritative

Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used

Inserting records into DNS

• Example: just created startup “Network Utopia”

• Register name networkuptopia.com at a registrar (e.g., Network Solutions)

• Need to provide registrar with names and IP addresses of your authoritative name server (primary and secondary)

• Registrar inserts two RRs into the com TLD server:

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

• Put in authoritative server Type A record for www.networkuptopia.com and Type MX record for networkutopia.com

Stan Kurkovsky

P2P file sharing

Example

• Alice runs P2P client application on her notebook computer • Intermittently connects to Internet; gets new IP address for each

connection

• Asks for “Hey Jude”

• Application displays other peers that have copy of Hey Jude. • Alice chooses one of the peers, Bob.

• File is copied from Bob’s PC to Alice’s notebook: HTTP • While Alice downloads, other users uploading from Alice. • Alice’s peer is both a Web client and a transient Web server.

All peers are servers = highly scalable!

P2P: centralized directory

original “Napster” design

1) when peer connects, it informs central server: • IP address

• content

2) Alice queries for “Hey Jude” 3) Alice requests file from Bob Problems

• Single point of failure • Performance bottleneck • Copyright infringement:

“target” of lawsuit is obvious

file transfer is decentralized,

but locating content is highly centralized

centralized directory server peers Alice Bob 1 1 1 1 2 3

Stan Kurkovsky

Query flooding: Gnutella

• fully distributed • no central server • public domain protocol

• many Gnutella clients implementing protocol overlay network: graph

• edge between peer X and Y if there’s a TCP connection • all active peers and edges is overlay net

• Edge is not a physical link

• Given peer will typically be connected with < 10 overlay neighbors

Gnutella: protocol

• Query message sent over existing TCP connections • peers forward query message

• QueryHit sent over reverse path • Scalability:

limited scope flooding

Query QueryHit Query QueryHit File transfer: HTTP

Stan Kurkovsky

Gnutella: Peer joining

1. 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 connection 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

Hierarchical Overlay

• between centralized index, query flooding approaches • each peer is either a

group leaderor

assigned to a group leader. • TCP connection between

peer and its group leader. • TCP connections between

some pairs of group leaders. • group leader tracks content

in its children

ordinary peer group-leader peer neighoring relationships

Stan Kurkovsky

Comparing Client-server, P2P architectures

Question: How much time distribute file initially at one server to N other computers? us u₂ d₁ d₂ u₁ uN d_N Server Network (with abundant bandwidth) File, size F us:server upload bandwidth ui:client/peer i upload bandwidth di:client/peer i download bandwidth

Client-server: file distribution time

us u2 d1 _d 2 u1 uN d_N Server Network (with abundant bandwidth) F

• server sequentially sends N copies of a file of size F:

• NF/ustime

• client i takes F/ditime to

download

increases linearly in N

(for large N)

= d

= max

{

NF/u

, F/min(d

)

}

Time to distribute F

to N clients using

client/server approach

Stan Kurkovsky

P2P: file distribution time

u_s u2 d1 _d 2 u1 u_N dN Server Network (with abundant bandwidth) F

• server must send one copy: F/u_stime

• client i takes F/d_itime to download

• NF bits must be downloaded (aggregate)

• fastest possible upload rate (assuming all nodes sending file chunks to same peer):

us+ ui

i=1,N

d

= max

{

F/u

, F/min(d

)

, NF/(u

+ u

}

Comparing Client-server, P2P architectures

0 0.5 1 1.5 2 2.5 3 3.5 0 5 10 15 20 25 30 35 N M in im u m D is tri b u tio n T im e P2P Client-Server

Stan Kurkovsky

P2P Case Study: BitTorrent

tracker:tracks peers participating in torrent torrent:group of peers exchanging chunks of a file obtain list of peers peer • 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

P2P Case Study: BitTorrent

Pulling Chunks

• at any given time, different peers have different subsets of file chunks

• periodically, a peer (Alice) asks each neighbor for list of chunks that they have.

• Alice issues requests for her missing chunks

• rarest first

Sending Chunks: tit-for-tat • Alice sends chunks to four

neighbors currently sending her chunks at the highest rate

• re-evaluate top 4 every 10 secs

• every 30 secs: randomly select another peer, starts sending chunks

• newly chosen peer may join top 4

Stan Kurkovsky

P2P Case study: Skype

• P2P (pc-to-pc, pc-to-phone, phone-to-pc) Voice-Over-IP (VoIP) application

• also IM

• proprietary application-layer protocol (inferred via reverse engineering) • hierarchical overlay

• Making a call • User starts Skype • SC registers with SN

• list of bootstrap SNs • SC logs in (authenticate)

• Call: SC contacts SN will callee ID

• SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC

• SC directly contacts callee, overTCP

Skype clients (SC)

Supernode (SN) Skype