Peer-to-peer file distribution
Peer-to-Peer (P2P) systems allow users' devices (peers) to communicate directly with each other with little or no central server involvement.
Scalability of P2P architectures
Solutions for distributing large files:
- client-server distribution:
- the server sends a separate copy of the file to every peer
- this places all upload bandwidth requirements on the server, creating a scalability bottleneck
- P2P distribution:
- each peer can redistribute any portion of the file it has received to any other peers
- this reduces the burden on the server and improves scalability
Model
| Model component | Description |
|---|---|
| \( F \) | Size of the file to be distributed (in bits) |
| \( N \) | Number of peers that want to obtain a copy of the file |
| \( D \) | Distribution time: the time it takes to get a copy of the file to all \( N \) peers |
| \( u_s \) | Upload rate of the server's access link |
| \( u_i \) | Upload rate of the \( i \)th peer's access link: \( u_1 \), \( u_2 \), etc. |
| \( d_i \) | Download rate of the \( i \)th peer's access link: \( d_1 \), \( d_2 \), etc. |
| \[ d_{min} = min\{d_1, d_2, … ,d_N\} \] | Lowest download rate among peers |
Client-server architecture
| Explanation | Formula |
|---|---|
| The server sends one copy of the file to each peer | \[ N \times F \ bits \] |
| Minimum time for the server to upload all copies | \[ \frac{NF}{u_s} \] |
| Minimum time required by the slowest peer to download the file | \[ \frac{F}{d_{min}} \] |
| Minimum distribution time for the client-server architecture | \[ D_{cs} = max\{ \frac{NF}{u_s}, \frac{F}{d_{min}} \} \] |
The minimum distribution time is determined by whichever process takes longer:
- the time required for the server to upload all copies of the file
- the time required for the slowest peer to download the file
P2P architecture
In P2P systems, distribution time is harder to compute because peers also help share the file.
| Explanation | Formula |
|---|---|
| Minimum time for the server to upload the first complete copy of the file (initially only the server has the file) | \[ \frac{F}{u_{s}} \] |
| Minimum time required by the slowest peer to download the file | \[ \frac{F}{d_{min}} \] |
| Total upload capacity = upload rate of the server + upload rates of all peers | \[ u_{s} + \sum\limits_{i=1}^N u_i \] |
| Minimum time to upload all copies to all peers (all \( NF \) bits must be uploaded, the server plus all peers share this work) | \[ \frac{NF}{u_{s} + \sum\limits_{i=1}^N u_i } \] |
| Minimum distribution time is determined by the largest bottleneck | \[ D_{p2p} = max\{ \frac{F}{u_s}, \frac{F}{d_{min}}, \frac{NF}{u_{s} + \sum\limits_{i=1}^N u_i } \} \] |
The minimum distribution time is determined by whichever limitation takes the longest:
- the server must upload at least one complete copy of the file
- the slowest peer must finish downloading the file
- the time to upload all copies to all peers
Comparison
Assumptions:
- a peer can transmit the entire file in one hour
- the peer download rates are assumed to be high enough that they are not the limiting factor (or bottleneck)
- the server transmission rate is 10× faster than a peer (it can initially upload in less than one hour)
Time from the start of the distribution until every peer has a complete copy of the file:
- client–server:
- only the server uploads, so the distribution time grows linearly and without bound with the number of peers
- P2P:
- the distribution time is always less than the distribution time of the client-server architecture
- the distribution time is less than one hour for any number of peers because adding more peers makes the network faster
A P2P system can become self-scaling because each new peer increases demand but also contributes additional upload capacity to the network.
BitTorrent
The most popular P2P file distribution protocol is BitTorrent (originally developed by Bram Cohen).
Many BitTorrent clients follow the BitTorrent protocol.
In BitTorrent:
- a particular file is distributed
- a torrent refers to two things:
- a
.torrentfile - the shared download activity itself
- a
- peers do two things:
- download equal-size chunks of the file from each other (commonly 256 KB–4 MB depending on torrent size)
- upload chunks to other peers
- once a peer has the entire file:
- it may (selfishly) leave the torrent
- or (altruistically) stay in the torrent and continue uploading chunks to other peers
- any peer may leave the torrent at any time with only some chunks, and later rejoin the torrent
BitTorrent is a complex protocol and system.
Most important mechanisms:
- each torrent has an infrastructure node called a tracker
- the tracker keeps track of the peers participating in the torrent
- when a peer joins a torrent:
- it registers with the tracker
- and periodically tells the tracker it is still in the torrent
- when a new peer (Alice) joins the torrent:
- the tracker randomly selects a subset of peers (for example, 50)
- sends the IP addresses of these 50 peers to Alice
- Alice tries to establish concurrent TCP connections with all peers on the list
- all peers with which Alice successfully establishes a TCP connection are neighboring peers
- a peer's neighboring peers change over time
- at any time, each peer has a subset of the file's chunks
- different peers have different subsets
- periodically, Alice asks each neighboring peer for a list of the chunks they have
- if Alice has \( L \) different neighbors, she receives \( L \) chunk lists
- Alice can then request chunks she does not currently have
- but Alice has two decisions to make:
- which chunks should she request first?
- Alice uses a technique called rarest first
- she determines which chunks she does not have are rarest among her neighbors
- the rarest chunks are redistributed more quickly, helping to (roughly) equalize the number of copies of each chunk in the torrent
- to which neighbors should she send requested chunks?
- BitTorrent uses a clever trading algorithm
- Alice prioritizes neighbors currently supplying her data at the highest rate
- for each neighbor, Alice continuously measures the rate at which she receives bits and identifies the four peers sending her bits at the highest rate
- she then reciprocates by sending chunks to those same four peers
- every 10 seconds, she recalculates the rates and may change the set of four peers
- these four peers are called unchoked
- every 30 seconds, Alice randomly chooses a new trading partner and starts trading with that partner
- this is called optimistically unchoked
- if both peers are satisfied with the trading, they place each other in their top four lists
- and continue trading until one peer finds a better partner
- peers able to upload at compatible rates tend to find each other
- which chunks should she request first?
The trading incentive mechanism described above is often called tit-for-tat.
BitTorrent has a number of other interesting mechanisms:
- pieces (mini-chunks)
- pipelining
- random first selection
- endgame mode
- anti-snubbing