The BitTorrent protocol

A peer-to-peer file sharing protocol.

History & Other facts

BitTorrent is a peer-to-peer file sharing protocol used for

distributing large amounts of data over the Internet. Programmer Bram Cohen designed the protocol in April 2001 and released a first implementation on July 2, 2001.It is now maintained by Cohen's company BitTorrent, Inc. There are numerous BitTorrent clients available for a variety of computing platforms.

Common Scenario
Millions want to download the same popular huge

files (for free)

ISOs Media (the real example!)

Client-server model fails

Single server fails Cant afford to deploy enough servers

Why Torrent ?

Client-Server

Client-Server
Overloaded!

Basic terms :
Tracker

Web Server
.torrent file Seeder Piece

The Tracker
IP address, port, peer id
State information (Completed Returns a random list of peers

or Downloading)

The .torrent file

The URL of the tracker

Pieces <hash1, hash 2,, hash n>

Piece length Name of the file Length of the file

Overall Architecture
Web Server Tracker

C A Peer Peer [Leech] Downloader US B Peer [Leech] [Seed]

Overall Architecture
Web Server Tracker

C A Peer Peer [Leech] Downloader US B Peer [Leech] [Seed]

Overall Architecture
Web Server Tracker

C A Peer Peer [Leech] Downloader US B Peer [Leech] [Seed]

Overall Architecture
Web Server Tracker

C A Peer Peer [Leech] Downloader US B Peer [Leech] [Seed]

Overall Architecture
Web Server Tracker

C A Peer Peer [Leech] Downloader US B Peer [Leech] [Seed]

Overall Architecture
Web Server Tracker

C A Peer Peer [Leech] Downloader US B Peer [Leech] [Seed]

Piece Selection
The order in which pieces are selected by

different peers is critical for good performance If an inefficient policy is used, then peers may end up in a situation where each has all identical set of easily available pieces, and none of the missing ones. If the original seed is prematurely taken down, then the file cannot be completely downloaded! What are good policies?

Peer-peer transactions: Choosing pieces to request

Rarest-first: Look at all pieces at all peers, and

request piece thats owned by fewest peers

Increases diversity in the pieces downloaded avoids case where a node and each of its peers have exactly the same pieces; increases throughput Increases likelihood all pieces still available even if

original seed leaves before any one node has downloaded entire file

Choosing pieces to request

Random Piece:
When peer starts to download, request random

piece.
So as to assemble first complete piece quickly Then participate in uploads

When first complete piece assembled, switch to

rarest-first

Choosing pieces to request

End-game mode:
When requests sent for all sub-pieces, (re)send

requests to all peers. To speed up completion of download Cancel request for downloaded sub-pieces

One more example

peer C peer A

peer D peer B

peer E

One more example

peer C peer A
C3,C4

peer D

peer B

peer E

One more example

peer C peer A
C5

peer D peer B

peer E

One more example

peer C peer A

peer D peer B

peer E

Pros and cons of BitTorrent

Pros
Proficient in utilizing partially downloaded files Discourages freeloading By rewarding fastest uploaders Encourages diversity through rarest-first Extends lifetime of swarm

Works well for hot content

Pros and cons of BitTorrent

Cons
Assumes all interested peers active at same time;

performance deteriorates if swarm cools off Even worse: no trackers for obscure content

Pros and cons of BitTorrent

Dependence on centralized tracker: pro/con?
Single point of failure: New nodes cant enter

swarm if tracker goes down Lack of a search feature

Prevents pollution attacks

Users need to resort to out-of-band search: well known

torrent-hosting sites / plain old web-search

Thank you !!!!!