File distribution: BitTorrent
q  P2P file distribution
tracker: tracks peers
participating in torrent
obtain list
of peers
trading
chunks
torrent: group of
peers exchanging
chunks of a file
Seed: peer that
has the
whole file
peer
Matta @ BUCS - Applications
1-61
BitTorrent (1)
q  file divided into 256KB
chunks
q  peer joining torrent:
❍  has
no chunks, but will accumulate them over time
with tracker to get list of peers,
connects to subset of peers (“neighbors”)
q  while downloading, peer uploads chunks to other
peers
q  peers may come and go
q  once peer has entire file, it may (selfishly) leave or
(altruistically) remain
❍  registers
Matta @ BUCS - Applications
BitTorrent (2)
Pulling Chunks
q  at any given time,
different peers have
different subsets of
file chunks
q  periodically, a peer
(Alice) asks each
neighbor for list of
chunks that they have
q  Alice sends requests
for her missing chunks
❍  rarest first
1-62
Sending Chunks: tit-for-tat
q  Alice sends chunks to four
neighbors currently
sending her chunks at the
highest rate
❍  re-evaluate top 4 every
10 secs
q  every 30 secs: randomly
select another peer,
starts sending chunks
❍  newly chosen peer may
join top 4
❍  “optimistically
unchoke”
Matta @ BUCS - Applications
1-63
1
BitTorrent: Tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
With higher upload rate,
can find better trading
partners & get file faster!
Matta @ BUCS - Applications
1-64
Distributed Hash Table (DHT)
q  DHT: distributed P2P database
q  database has (key, value) pairs;
❍  key: ss number; value: human name
❍  key: content type; value: IP address
q  peers query DB with key
❍  DB returns values that match the key
q  peers can also insert (key, value) pairs
Application 2-65
DHT Identifiers
q  assign integer identifier to each peer in range
[0,2n-1].
❍  Each
identifier can be represented by n bits.
q  require each key to be an integer in same range.
q  to get integer keys, hash original key.
❍  e.g., key = h(“Led Zeppelin IV”)
❍  this is why they call it a distributed “hash” table
Application 2-66
2
How to assign keys to peers?
q  central issue:
❍  assigning (key, value) pairs to peers.
q  rule: assign key to the peer that has the
closest ID.
q  assume convention is: closest is the
immediate successor of the key.
q  e.g.,: n=4; peers: 1,3,4,5,8,10,12,15;
❍  key = 13, then immediate successor peer = 14
❍  key = 15, then immediate successor peer = 1
Application 2-67
Circular DHT (1)
1
3
15
4
12
5
10
8
only aware of immediate successor
and predecessor.
q  “overlay network”
q  each peer
Application 2-68
Circular DHT (2)
O(N) messages
on avg to resolve
query, when there
are N peers
0001
I am
Who’s resp
for key 1110 ?
0011
1111
1110
0100
1110
1110
1100
1110
Define closest
as closest
successor
1110
0101
1110
1010
1000
Application 2-69
3
Circular DHT with Shortcuts
1
3
Who’s resp
for key 1110?
15
4
12
5
10
8
q  each peer keeps track of IP addresses of predecessor,
successor, short cuts.
q  reduced from 6 to 2 messages.
q  possible to design shortcuts so O(log N) neighbors, O(log
N) messages in query
Application 2-70
Peer Churn
1
v 
3
15
v 
4
12
To handle peer churn, require
each peer to know the IP
address of its two successors.
Each peer periodically pings its
two successors to see if they
are still alive.
5
10
8
q  peer 5 abruptly leaves
q  Peer 4 detects; makes 8 its immediate successor;
asks 8 who its immediate successor is; makes 8’s
immediate successor its second successor.
q  What if peer 13 wants to join?
Application 2-71
P2P Case study: Skype
Skype clients (SC)
q  proprietary
application-layer
protocol (inferred via
reverse engineering)
q  hierarchical overlay of
SNs
q  Index maps usernames
to IP addresses;
distributed over SNs
Supernode
(SN)
Matta @ BUCS - Applications
1-72
4
Peers as relays
q  Problem when both
Alice and Bob are
behind “NATs”
❍ 
NAT prevents an outside
peer from initiating a call
to insider peer
q  Solution:
❍  Using Alice’s and Bob’s
SNs, (non-NATed) Relay
is chosen
❍  Each peer initiates
session with relay
❍  Peers can now
communicate through
NATs via relay
Matta @ BUCS - Applications
1-73
Chapter 2: Summary
our study of network apps now complete!
q  application architectures
❍  client-server
❍  P2P
❍  hybrid
q  application service
requirements:
❍ 
reliability, throughput,
delay
q  socket programming
q  specific protocols:
❍  HTTP
❍  SMTP, POP, IMAP
❍  DNS
❍  P2P: BitTorrent, Skype,
…
q  Internet transport
service model
❍ 
❍ 
connection-oriented,
reliable: TCP
unreliable, datagrams: UDP
Matta @ BUCS - Applications
1-74
Chapter 2: Summary
Most importantly: learned about protocols
Important themes:
q  persistent vs. non-persistent
message exchange:
transport connections
❍  client requests info or
q  stateless vs. stateful
service
q  caching
❍  server responds with
data, status code
q  reliable vs. unreliable msg
q  message formats:
transfer
❍  headers: fields giving
q  centralized vs. distributed
info about data
q  Overlay vs. underlay
❍  data: info being
q  typical request/reply
communicated
Matta @ BUCS - Applications
1-75
5