Peer-to-peer (P2P) architecture

• Arbitrary end systems directly communicate each other.
• Peers request service from other peers, peers provide service in return to other peers.
• Used for file sharing (BitTorrent), VoIP (Skype), etc.

Self scalability - new peers bring new service capacity, and new service demands!

File distribution time

How much time does it take to distribute file (size F) from one server to N peers?

• $u_s$: server upload capacity
• $d_i$: peer i download capacity
• $u_i$: peer i upload capacity

Client-server approach

• Server must sequentially send N file copies: $N\frac{F}{u_s}$
• Each client must download file copy: $\frac{F}{d_{min}}$

$$\therefore D_{c-s} \geq \max(N\frac{F}{u_s}, \frac{F}{d_{min}})$$

P2P approach

• Server must upload at least 1 copy: $\frac{F}{u_s}$
• Each client must download file copy: $\frac{F}{d_{min}}$
• Client can upload too! Server and client upload N file copies: $N\frac{F}{u_s + \sum u_i}$

$$\therefore D_{P2P} \geq \max(\frac{F}{u_s}, \frac{F}{d_{min}}, N\frac{F}{u_s + \sum u_i})$$

When P2P was common, client was usually readers, so $u_i >d_i$.
Theoretically, P2P is faster than client-server when $N$ is large!

BitTorrent

P2P file distribution!

• Each file is divided into 256KB of chunks, and peers in torrent send/receive file chunks.
• Tracker server tracks peers participating in torrent!

Tit-for-tat in BitTorrent

Problem: once peer has entire file, it may selfishly leave.
Solution: use tit-fot-tat strategy!

When requesting chunks, client periodically ask each peer for list of chunks that they have.
Then client requests missing chunks from peers, rarest first.

When sending chunks, client send chunks to those four peers currently sending her chunks at highest rate.
Other peers are choked by client - they do not receive chunks.
Every 10 secs, client reevaluate top four peers.
Every 30 secs, client optimistically unchoke peer - it randomly select another peer and start sending chunks.