Client-server architecture Pure P2P architecture

server: ❒ no always-on server

❍ always-on host ❒ arbitrary end systems
❍ permanent IP address directly communicate
❍ server farms for ❒ peers are intermittently peer-peer
scaling connected and change IP
clients: addresses
❍ communicate with server ❒ Three topics:
client/server ❍ may be intermittently ❍ File sharing
connected ❍ File distribution
❍ may have dynamic IP ❍ Searching for information
addresses ❍ Case Studies: Bittorrent
❍ do not communicate and Skype
directly with each other
P2P slides copyright 1996-2009 J.F
Kurose and K.W. Ross, and W.
Stallings. All Rights Reserved. TDDD36: Lecture 5, P2P networks and streaming 1 TDDD36: Lecture 5, P2P networks and streaming 2

Hybrid of client-server and P2P P2P file sharing

❒ Alice chooses one of
Skype Example the peers, Bob.
❍ voice-over-IP P2P application ❒ file is copied from
❒ Alice runs P2P client
❍ centralized server: finding address of remote Bob’s PC to Alice’s
party: application on her
notebook computer notebook: HTTP
❍ client-client connection: direct (not through
server) ❒ intermittently ❒ while Alice downloads,
Instant messaging connects to Internet; other users uploading
❍ chatting between two users is P2P gets new IP address from Alice.
❍ centralized service: client presence for each connection ❒ Alice’s peer is both a
detection/location Web client and a
❒ asks for “Hey Jude”
• user registers its IP address with central transient Web server.
server when it comes online ❒ application displays
other peers that have All peers are servers =
• user contacts central server to find IP
addresses of buddies copy of Hey Jude. highly scalable!

TDDD36: Lecture 5, P2P networks and streaming TDDD36: Lecture 5, P2P networks and streaming 4
3

P2P: centralized directory P2P: problems with centralized directory

Bob
original “Napster” design centralized
❒ single point of failure file transfer is
1) when peer connects, it directory server
1 ❒ performance bottleneck decentralized, but
informs central server: peers
❒ copyright infringement:
locating content is
❍ IP address 1
“target” of lawsuit is highly centralized
❍ content obvious
1 3
2) Alice queries for “Hey
2 1
Jude”
3) Alice requests file from
Bob
Alice

TDDD36: Lecture 5, P2P networks and streaming TDDD36: Lecture 5, P2P networks and streaming 6
5

1
 Gnutella: protocol
Query flooding: Gnutella ❒ Query message
File transfer:
HTTP
sent over existing TCP
connections
❒ fully distributed overlay network: graph ❒ peers forward
❍ no central server Query message Query
❒ edge between peer X ❒ QueryHit QueryHit
❒ public domain protocol and Y if there’s a TCP sent over
❒ many Gnutella clients connection reverse
implementing protocol path
❒ all active peers and
edges form overlay net
Query
❒ edge: virtual (not
QueryHit
physical) link
❒ given peer typically Scalability:
connected with < 10 limited scope
flooding
overlay neighbors

TDDD36: Lecture 5, P2P networks and streaming 7

TDDD36: Lecture 5, P2P networks and streaming 8

Gnutella: Peer joining Hierarchical Overlay

1. joining peer Alice must find another peer in ❒ between centralized
Gnutella network: use list of candidate peers index, query flooding
2. Alice sequentially attempts TCP connections with approaches
candidate peers until connection setup with Bob ❒ each peer is either a
3. Flooding: Alice sends Ping message to Bob; Bob group leader or assigned
forwards Ping message to his overlay neighbors to a group leader.
(who then forward to their neighbors….)
❍ TCP connection between
❒ peers receiving Ping message respond to Alice peer and its group leader.
with Pong message ❍ TCP connections between
4. Alice receives many Pong messages, and can then some pairs of group leaders. ordinary peer

setup additional TCP connections ❒ group leader tracks group-leader peer

Peer leaving: see homework problem! content in its children neighoring relationships
in overlay network

TDDD36: Lecture 5, P2P networks and streaming 9 TDDD36: Lecture 5, P2P networks and streaming 10

File distribution time: server-client

File Distribution: Server-Client vs P2P
Server
Question : How much time to distribute file
❒ server sequentially
from one server to N peers? F u1 d1 u2 d
sends N copies: us 2

us: server upload ❍ NF/us time Network (with

dN
bandwidth abundant bandwidth)
Server
ui: peer i upload
❒ client i takes F/di uN

u1 d1 u2 bandwidth time to download

us d2
di: peer i download
File, size F bandwidth
Time to distribute F
dN to N clients using
client/server approach = dcs = max { NF/us, F/min(di) }
Network (with
uN abundant bandwidth) i

increases linearly in N
(for large N)
TDDD36: Lecture 5, P2P networks and streaming 11 TDDD36: Lecture 5, P2P networks and streaming 12

2
File distribution time: P2P Server-client vs. P2P: example
Server Client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
❒ server must send one
F u1 d1 u2
copy: F/us time us d2 3.5
P2P
❒ client i takes F/di time

Minimum Distribution Time

3
dN Network (with Client-Server
to download abundant bandwidth) 2.5
uN
❒ NF bits must be 2
downloaded (aggregate)
1.5
❒ fastest possible upload rate: us + Σu i
1

0.5

dP2P = max { F/us, F/min(di) , NF/(us + Σu ) }

i
0 5 10 15 20 25 30 35
i N
TDDD36: Lecture 5, P2P networks and streaming 13 TDDD36: Lecture 5, P2P networks and streaming 14

File distribution: BitTorrent

❒ P2P file distribution
tracker: tracks peers torrent: group of
BitTorrent (1)
participating in torrent peers exchanging
chunks of a file
❒ file divided into 256KB chunks.
❒ peer joining torrent:
❍ has no chunks, but will accumulate them over time
obtain list
of peers
❍ registers with tracker to get list of peers,
trading
connects to subset of peers (“neighbors”)
chunks ❒ while downloading, peer uploads chunks to other
peers.
❒ peers may come and go
peer
❒ once peer has entire file, it may (selfishly) leave or
(altruistically) remain
TDDD36: Lecture 5, P2P networks and streaming 15 TDDD36: Lecture 5, P2P networks and streaming 16

BitTorrent (2) BitTorrent: Tit-for-tat

Sending Chunks: tit-for-tat
❒ Alice sends chunks to four (1) Alice “optimistically unchokes” Bob
Pulling Chunks neighbors currently sending her (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
chunks at the highest rate (3) Bob becomes one of Alice’s top-four providers
❒ at any given time,
re-evaluate top 4 every 10 secs

different peers have ❒ every 30 secs: randomly select

another peer, starts sending
different subsets of chunks
file chunks
newly chosen peer may join top
4
❒ periodically, a peer
“optimistically unchoke”
(Alice) asks each
neighbor for list of
chunks that they have.
❒ Alice sends requests
With higher upload rate,
for her missing chunks
can find better trading
❍ rarest first partners & get file faster!
TDDD36: Lecture 5, P2P networks and streaming 17
TDDD36: Lecture 5, P2P networks and streaming 18

3
 Distributed Hash Table (DHT) DHT Identifiers
❒ DHT = distributed P2P database ❒ Assign integer identifier to each peer in range
❒ Database has (key, value) pairs; [0,2n-1].
❍ key: ss number; value: human name ❍ Each identifier can be represented by n bits.
❍ key: content type; value: IP address ❒ Require each key to be an integer in same range.
❒ Peers query DB with key ❒ To get integer keys, hash original key.
❍ DB returns values that match the key ❍ eg, key = h(“Led Zeppelin IV”)
❒ Peers can also insert (key, value) peers ❍ This is why they call it a distributed “hash” table

TDDD36: Lecture 5, P2P networks and streaming 19 TDDD36: Lecture 5, P2P networks and streaming 20

How to assign keys to peers? Circular DHT (1)

1

❒ Central issue:
3
❍ Assigning (key, value) pairs to peers. 15

❒ Rule: assign key to the peer that has the

4
closest ID.
12
❒ Convention in lecture: closest is the 5
immediate successor of the key. 10
8
❒ Ex: n=4; peers: 1,3,4,5,8,10,12,14;
❍ key = 13, then successor peer = 14 ❒ Each peer only aware of immediate successor
❍ key = 15, then successor peer = 1 and predecessor.
❒ “Overlay network”
TDDD36: Lecture 5, P2P networks and streaming 21 TDDD36: Lecture 5, P2P networks and streaming 22

Circle DHT (2) Circular DHT with Shortcuts

1 Who’s
responsible
3 for key 1110?
O(N) messages 0001 Who’s
responsible 15
on avg to resolve
for key 1110 ?
query, when there I am
0011 4
are N peers
1111
12
1110 5

1110 0100 10
8
1110
1100 ❒ Each peer keeps track of IP addresses of predecessor,
1110 0101 successor, short cuts.
1110
❒ Reduced from 6 to 2 messages.
Define closest 1110
❒ Possible to design shortcuts so O(log N) neighbors,
as closest 1010
1000 O(log N) messages in query
successor
TDDD36: Lecture 5, P2P networks and streaming 23 TDDD36: Lecture 5, P2P networks and streaming 24

4
Peer Churn P2P Case study: Skype
1

•To handle peer churn, require Skype clients (SC)

3 each peer to know the IP address ❒ inherently P2P: pairs
15
of its two successors. of users communicate.
• Each peer periodically pings its
4 two successors to see if they ❒ proprietary Skype
are still alive. application-layer login server Supernode
12 (SN)
5 protocol (inferred via
reverse engineering)
10
8 ❒ hierarchical overlay
❒ Peer 5 abruptly leaves with Supernodes
❒ Peer 4 detects; makes 8 its immediate successor; (SNs)
asks 8 who its immediate successor is; makes 8’s ❒ Index maps usernames
immediate successor its second successor. to IP addresses;
❒ What if peer 13 wants to join? distributed over SNs
TDDD36: Lecture 5, P2P networks and streaming 25 TDDD36: Lecture 5, P2P networks and streaming 26

Peers as relays
❒ Problem when both
Alice and Bob are
behind “NATs”.
❍ NAT prevents an outside
peer from initiating a call
to insider peer
❒ Solution:
❍ Using Alice’s and Bob’s
SNs, Relay is chosen
❍ Each peer initiates
session with relay.
❍ Peers can now
communicate through
NATs via relay

TDDD36: Lecture 5, P2P networks and streaming 27