This is a Seminar Report on a BitTorrent Topic,In this report working,early history and architecture of bittorrent explain with simple examples.

1. 1. INTRODUCTION
BitTorrent[1] is a peer-to-peer file sharing protocol used to distribute large amounts of
data. BitTorrent is one of the most common protocols for transferring large files. Its main usage
is for the transfer of large sized files. It makes transfer of such files easier by implementing a
different approach. A user can obtain multiple files simultaneously without any considerable loss
of the transfer rate. It is said to be a lot better than the conventional file transfer methods because
of a different principle that is followed by this protocol. It also evens out the way a file is shared
by allowing a user not just to obtain it but also to share it with others. This is what has made a
big difference between this and the conventional file transfer methods. It makes a user to share
the file he is obtaining so that the other users who are trying to obtain the same file would find it
easier and also in turn making these users to involve themselves in the file sharing process. Thus
the larger the number of users the more is the demand and more easily a file can be transferred
between them.
BitTorrent protocol[2] has been built on a technology which makes it possible to distribute
large amounts of data without the need of a high capacity server, and expensive bandwidth. This
is the most striking feature of this file transfer protocol. The transferring of files will never
depend on a single source which is supposed the original copy of the file but instead the load will
be distributed across a number of such sources. Here not just the sources are responsible for file
transfer but also the clients or users who want to obtain the file are involved in this process. This
makes the load get distributed evenly across the users and thus making the main source partially
free from this process which will reduce the network traffic imposed on it. Because of this,
BitTorrent has become one of the most popular file transfer mechanisms in today’s world.
Though the mechanism itself is not as simple as an ordinary file transfer protocol, it has gained
its popularity because of the sharing policy that it imposes on its users. This fact is quite obvious,
since the recent surveys made by various organizations show that 35% of the overall internet
traffic is because of BitTorrent. This shows that the amount of files that are being transferred and
shared by users through BitTorrent is very huge.

2. 1.1 History
BitTorrent was created by a programmer named Bram Cohen. After inventing this new
technology he said, "I decided I finally wanted to work on a project that people would actually
use, would actually work and would actually be fun". Before this was invented, there were other
techniques for file sharing but they were not utilizing the bandwidth effectively. The bandwidth
had become a bottleneck in such methods. Even other peer to peer file sharing systems like
Napster and Kazaa had the capability of sharing files by making the users involve in the sharing
process, but they required only a subset of users to share the files not all. This meant that most of
the users can simply download the files without being needed to upload. So this again put a lot of
network load on the original sources and on small number of users. This led to inefficient usage
of bandwidth of the remaining users. This was the main intention behind Cohen’s invention, i.e.,
to make the maximum utilization of all the users’ bandwidth who are involved in the sharing of
files. By doing so, every person who wants to download a file had to contribute towards the
uploading process also. This new and novel concept of Cohen gave birth to a new peer to peer
file sharing protocol called BitTorrent. Cohen invented this protocol in April 2001. The first
usable version of BitTorrent appeared in October 2002, but the system needed a lot of finetuning. BitTorrent really started to take off in early 2003 when it was used to distribute a new
version of Linux and fans of Japanese anime started relying on it to share cartoons. The most
important part of this protocol that matters a lot about this is that it makes it possible for people
with limited bandwidth to supply very popular files. This means that if you are a small software
developer you can put up a package, and if it turns out that millions of people want it, they can
get it from each other in an automated way. Thus the bandwidth which used to be a bottleneck in
previous systems no longer poses a problem.
2

3. 2. LITRATURE SURVEY
2.1 The History of File Sharing
Last century filesharing was a fringe hobby, only for geeks who were lucky enough to
own a computer that could dial into the World Wide Web. How different is that today, where
filesharing has become daily routine for hundreds of millions of people worldwide. In just a few
years swapping files has become mainstream. Time to take a step back and see how it all came
about. Digital file sharing has come a long way since the early days of the floppy disk, starting
with a 79.7 kB storage capacity in the early 1970s. Two decades ago 3.5kb disks were the most
sought after medium to distribute files. At the time, their massive 1.4 MB file size was more than
enough to distribute files. But things got really interesting when people started to swap files on
the Internet.
In just 2 score years, filesharing has evolved into an amazingly efficient process which
has enhanced lives everywhere. It has brought great exposure to underexposed types of media
and democratized distribution, making it possible for individuals to share files with the rest of the
world at virtually no cost.
The most common method by which files are transferred on the Internet is the clientserver model. A central server sends the entire file to each client that requests it, this is how
both http and ftp work. The clients only speak to the server, and never to each other. The main
advantages of this method are that it's simple to set up, and the files are usually always available
since the servers tend to be dedicated to the task of serving, and are always on and connected to
the Internet. However, this model has a significant problem with files that are large or very
popular, or both. Namely, it takes a great deal of bandwidth and server resources to distribute
such a file, since the server must transmit the entire file to each client. Perhaps you may have
tried to download a demo of a new game just released, or CD images of a new Linux
distribution, and found that all the servers report "too many users," or there is a long queue that
you have to wait through. The concept of mirrors partially addresses this shortcoming by
distributing the load across multiple servers. But it requires a lot of coordination and effort to set
up an efficient network of mirrors, and it's usually only feasible for the busiest of sites.
3

4. Some new method of transferring files has become popular recently: the peer-to-peer
network, systems such as Kazaa, eDonkey, Gnutella, Direct Connect, etc[7]. In most of these
networks, ordinary Internet users trade files by directly connecting one-to-one. The advantage
here is that files can be shared without having access to a proper server, and because of this there
is little accountability for the contents of the files. Hence, these networks tend to be very popular
for illicit files such as music, movies, pirated software, etc. Typically, a downloader receives a
file from a single source, however the newest version of some clients allow downloading a single
file from multiple sources for higher speeds. The problem discussed above of popular downloads
is somewhat mitigated, because there's a greater chance that a popular file will be offered by a
number of peers. The breadth of files available tends to be fairly good, though download speeds
for obscure files tend to be low. Another common problem sometimes associated with these
systems is the significant protocol overhead for passing search queries amongst the peers, and
the number of peers that one can reach is often limited as a result. Partially downloaded files are
usually not available to other peers, although some newer clients may offer this functionality.
Availability is generally dependent on the goodwill of the users, to the extent that some of these
networks have tried to enforce rules or restrictions regarding send/receive ratios.
2.2 Typical HTTP File Transfer
The most common type of file transfer is through a HTTP server. In this method, a HTTP
server listens to the client’s requests and serves them. Here the client can only depend on the
lone server that is providing the file. The overall download scheme will be limited to the
limitations of that server. Also this kind of transfer of file is subjected to single point of failure,
where if the server crashes then the whole download process will seize.
4

5. Fig 2.1: Typical HTTP File Transfer
2.3 The DAP Method
Download Accelerator Plus (DAP) is the world's most popular download accelerator.
DAP's key features include the ability to accelerate downloading of files in FTP and HTTP
protocols, to pause and resume downloads, and to recover from dropped internet connections.
On the Internet the same file is often hosted on numerous mirror sites, such as at
universities and on ISP servers. DAP immediately senses when a user begins downloading a file
and identifies available mirror sites that host the requested file. As soon as it is
triggered, DAP's client side optimization begins to determine - in real time - which mirror sites
offer the fastest response for the specific user's location. The file is downloaded in several
segments simultaneously through multiple connections from the most responsive server(s) and
reassembled at the user's PC. This results in better utilization of the user's available bandwidth.
2.4 DC++ and i2hub
DC++ and i2hub were popular methods of sharing files in closed-networks. Both were
highly used within the university and college scene where students would share hub/server
addresses with each other in order to share files at very high speeds within the local college
5

6. networks. The advantage provided within these was that outside agencies and other various third
parties could not access the content found within these networks.
2.5 File Lockers
In recent years Megaupload, Rapidshare, Hotfile[8] and other file lockers became quite
popular. These file lockers provided the simplest means of filesharing when compared to all of
their predecessors. Files are simply uploaded to the file locker, and a URL is provided to the file
which is downloading through HTTP/HTTPS.
2.6 The Bittorrent Approach
In BitTorrent, the data to be shared is divided into many equal-sized portions called
pieces. Each piece is further sub-divided into equal-sized sub-pieces called blocks. All clients
interested in sharing this data are grouped into a swarm, each of which is managed by a central
entity called the tracker. BitTorrent has revolutionized[5] the way files are shared between people.
It does not require a user to download a file completely from a single server. Instead a file can be
downloaded from many such users who are indeed downloading the same file. A user who has
the complete file, called the seed will initiate the download by transferring pieces of file to the
users. Once a user has some considerable number of such pieces of a file then even he can start
sharing them with other users who are yet to receive those pieces. This concept enables a client
not to depend on a server completely and also it reduces overall load on the server.
Early versions of BitTorrent required centralized trackers to operate, but have later
become able to utilize trackerless “torrents.”[3]
Fig 2.2 BitTorrent File Transfer
6

7. 3. WORKING OF BITTORRENT
As previously explained, BitTorrent’s design makes it extremely efficient[5] in the sharing
of large data files among interested peers. Looking under the hood, BitTorrent is a protocol with
some complexity where modeling is useful to gain a better understanding of its performance.
BitTorrent scales well and is a superior method for transferring and disseminating files between
interested peers while limiting free riding (peers who download but do not upload) between those
same peers. BitTorrent’s is based on a “tit for tat” reciprocity agreement between users that
ultimately results in pareto efficiency. Pareto efficiency is an important economic concept that
maximizes resource allocation among peers to their mutual advantage. Pareto efficiency is the
crown jewel of BitTorrent and is the driving force behind the protocol’s popularity and success.
Cohen’s vision of peers simultaneously helping each other by uploading and downloading has
been realized by the BitTorrent system.
Fig 3.1: A Typical BitTorrent System
The protocol[2] shares data through what are known as torrents. For a torrent to be alive or
active it must have several key components to function. These components include a tracker
server, a .torrent file, a web server where the .torrent file is stored and a complete copy of the file
being exchanged. Each of these components is described in the following paragraphs.
7

8. The file being exchanged is the essence of the torrent and a complete copy is referred to
as a seed. A seed is a peer in the BitTorrent network willing to share a file with other peers in the
network. Why seed owners choose to share their files is debatable, as the BitTorrent protocol
does not reward seed behavior. In fact, some researchers believe the protocol lacks any incentive
mechanism for encouraging seeds to remain in torrents. Some argue that the lack of incentive in
the protocol is a fundamental design flaw that leads to the punishment of seeds.
Peers lacking the file and seeking it from seeds are called leechers. While seeds only
upload to leechers, leechers may both download from seeds and upload to other leechers.
BitTorrent’s protocol is designed so leeching peers seek each other out for data transfer in a
process known as “optimistic unchoking”. Together seeds and leechers engaged in file transfer
are referred to as a swarm. A swarm is coordinated by a tracker server serving the particular
torrent and interested peers find the tracker via metadata known as a .torrent file. Since
BitTorrent has no built in search functionality, .torrent files are usually located via HTTP
through search engines or trackers.
The first step in the BitTorrent exchange occurs when a peer downloads a .torrent file
from a server. The role of .torrent files is to provide the metadata that allows the protocol to
function; .torrent files can be viewed as surrogates for the files being shared. These .torrent files
contain key pieces of data to function correctly including file length, assigned name, hashing
information about the file and the URL of the tracker coordinating the torrent activity. Torrent
files can be created using a program such as MakeTorrent, another open source tool available
under the free software model.
When a .torrent file is opened by the peer’s client software, the peer then connects to the
tracker server responsible for coordinating activity for that specific torrent. The tracker and client
communicate by a protocol layered on top of HTTP and the tracker’s key role is to coordinate
peers seeking the same file for Cohen envisioned “The tracker’s responsibilities are strictly
limited to helping peers find each other”. In reality the tracker’s role is a bit more complex as
many trackers collect data about peers engaged in a swarm. Additionally, some of the newer
tracker software being released has integrated the functions of the tracker and .torrent server.
Leechers and seeds are coordinated by the tracker server and the peers periodically
update the tracker on their status allowing the tracker to have a global view of the system.
8

9. The data monitored by the tracker can include peer IP addresses, amount of data
uploaded/downloaded for specific peers, data transfer rates among peers, the percentage of the
total file downloaded, length of time connected to the tracker, and the ratio of sharing among
peers[6]. Usually a tracker coordinates multiple torrents and the most popular trackers are busy
coordinating thousands of swarms simultaneously.
It should be noted that .torrent files are not the actual file being shared; rather .torrent files are
the metadata information which allow which trackers and peers to coordinate their activities. As
previously mentioned, the complete file is actually stored on peer seed nodes and not the tracker
server. Since .torrent files are small and require little space to store, one server can easily host
thousands of .torrent files without prohibitive server or bandwidth requirements. There is some
issue with bandwidth usage to host a tracker, however, especially if the tracker becomes popular
and begins to see heavy usage. Regardless, the tracker’s bandwidth requirements are much less
than hosting the complete files in a traditional client-server model such as one would encounter
with an FTP site.
While trackers and .torrent files serve as mechanisms to assist the BitTorrent protocol,
the process of actually transferring data is handled by the peers engaged in the swarm. Cohen’s
vision of “tit for tat” is the sole incentive measure he saw necessary for the protocol’s success.
Peers seek tit for tat behavior from others and discourage free riding by a “choke/unchoke”
policy. This choke policy uses a process known as “optimistic unchoking” to constantly seek
other swarm peers who may have more beneficial connections to offer an interested peer.
There has been some research of the tit for tat algorithm by modeling rational users
whose behavior is then studied. This work defined rational users as those peer nodes
manipulating their client software beyond default settings. The fact that many newer BitTorrent
clients allow for custom tweaking of specific upload or download speed indicates that perhaps
the original tit for tat coding was too good, and thus detrimental to other peer node functions
such as normal HTTP traffic. Some BitTorrent FAQs recommend limiting uploads to
approximately 80% of known capacity and personal tests indicate this strategy does benefit
download speeds.
The final important aspect of the BitTorrent protocol’s architecture is its use of a “rarest
piece first” algorithm when a peer begins a file download. The rarest first algorithm has as its
goal the uniform distribution of data across peers, also known as the “endgame mode”. A rarest
9

10. first policy requires a seed to upload new file chunks (those not yet uploaded to a swarm) to the
newest peer connecting to a torrent. This policy encourages distribution of the file further across
peer nodes.. The rarest first algorithm is an interesting aspect of BitTorrent that when combined
with optimistic unchoking may explain why the protocol has achieved such success.
3.1 Terminology
These are the common terms that one would come across while making a typical
BitTorrent file transfer.

Torrent:The .torrent file is not the entire file. It is extremely small and it just
contains the information that points to the actual file and the people who are
sharing it. It is like a map which is used by the BitTorrent client to assemble all
the pieces together.

BitTorrent client: A Bit Torrent client is one of the most important parts of the
torrent process. It is a piece of software which takes the .torrent file, reads the
information in it and starts the download.

Peer: A peer is any computer participating in the download and upload of a
torrent file

Leeches:A leech (or a leecher) is the person who does not have the complete file
yet but has joined the network to download it. A leecher becomes a seeder when
he downloads the entire file and then shares it across the network.

Seed: A computer that has a complete copy of a certain torrent. Once a client
downloads a file completely, he can continue to upload the file which is called as
seeding. This is a good practice in the BitTorrent world since it allows other users
to have the file easily.

Share Ratio: The ratio is the amount of data a user has uploaded divided by the
amount of data they have downloaded for a particular torrent (UL÷DL). A share
ratio of 1+ has a positive effect on the user’s reputation because it means that the
user has sent more data to other users than he has received. Conversely, share
ratios under 1 have a negative effect.

Reseed: When there are zero seeds for a given torrent, then eventually all the
peers will get stuck with an incomplete file, since no one in the swarm has the
10

11. missing pieces. When this happens, a seed must connect to the swarm so that
those missing pieces can be transferred. This is called reseeding.

Swarm:The swarm is the sum total of all the leechers and seeders (i.e. all the
computers) participating in the torrent process.

Tracker:The tracker is a server which has the information of who has what files
and who needs which ones, thus acting as a bridge between seeders and leechers.
Some trackers are private requiring a registration where most are public..

Distributed Copies: Sometimes the peers in a swarm will collectively have a
complete file. Such copies are called distributed copies.

Interested: This is the state of a downloader which suggests that the other end has
some pieces that the downloader wants. Then the downloader is said to be
interested in the other end.

Index: An index is, as the name implies, a searchable list of .torrent files, hosted
on a website.
3.2 Architecture of BitTorrent
The BitTorrent protocol can be split into the following five main components:

Metainfo File - a file which contains all details necessary for the protocol to operate.

Tracker - A server which helps manage the BitTorrent protocol.

Peers - Users exchanging data via the BitTorrent protocol.

Data - The files being transferred across the protocol.

Client - The program which sits on a peers computer and implements the protocol.
Peers use TCP (Transport Control Protocol) to communicate and send data. This protocol
is preferable over other protocols such as UDP (User Datagram Protocol) because TCP
guarantees reliable and in-order delivery of data from sender to receiver. UDP cannot give such
guarantees, and data can become scrambled, or lost all together. The tracker allows peers to
query which peers have what data, and allows them to begin communication. Peers communicate
with the tracker via the plain text via HTTP (Hypertext Transfer Protocol) The following
diagram illustrates how peers interact with each other, and also communicate with a central
tracker.
11

12. Fig 3.2 :Architecture of a BitTorrent System
3.2.1 Metainfo File
When someone wants to publish data using the BitTorrent protocol, they must create a
metainfo file. This file is specific to the data they are publishing, and contains all the information
about a torrent, such as the data to be included, and IP address of the tracker to connect to. A
tracker is a server which 'manages' a torrent, and is discussed in the next section. The file is
given a '.torrent' extension, and the data is extracted from the file by a BitTorrent client. This is a
program which runs on the user computer, and implements the bittorrent protocol. Every
metainfo file must contain the following information, (or 'keys'):

info: A dictionary which describes the file(s) of the torrent. Either for the single file, or
the directory structure for more files. Hashes for every data piece, in SHA 1 format are
stored here.

announce: The announce URL of the tracker as a string
The following are optional keys which can also be used:

announce-list: Used to list backup trackers

creation date: The creation time of the torrent by way of UNIX time stamp (integer
seconds since 1-Jan-1970 00:00:00 UTC)

comment: Any comments by the author
12

13. 
created by: Name and Version of program used to create the metainfo file
These keys are structured in the metainfo file as follows:
{'info': {'piece length': 131072, 'length': 38190848L, 'name':
'Cory_Doctorow_Microsoft_Research_DRM_talk.mp3', 'pieces':
'xcbxfazrx9bxe1x9axe1x83x91~xed@.....', } 'announce':
'http://tracker.var.cc:6969/announce', 'creation date': 1089749086L }
Instead of transmitting the keys in plain text format, the keys contained in the metainfo
file are encoded before they are sent. Encoding is done using bittorrent specific method known as
'bencoding'.
3.2.2 Bencoding :
Bencoding is used by bittorrent to send loosely structured data between the BitTorrent
client and a tracker. Bencoding supports byte strings, integers, lists and dictionaries. Bencoding
uses the beginning delimiters 'i' / 'l' / 'd' for integers, lists and dictionaries respectively. Ending
delimiters are always 'e'. Delimiters are not used for byte strings.
Bencoding Structure:

Byte Strings : <string length in base ten ASCII> : <string data>

Integers: i<base ten ASCII>e

Lists: l<bencoded values>e

Dictionaries: d<bencoded string><bencoded element>e
Minus integers are allowed, but prefixing the number with a zero is not permitted. However '0' is
allowed.
Examples of bencoding:
4:spam // represents the string "spam"
i3e // represents the integer "3"
l4:spam4:eggse // represents the list of two strings: ["spam","eggs"]
d4:spaml1:a1:bee // represents the dictionary {"spam" => ["a" , "b"] }
3.2.3Metainfo File Distribution:
13

14. Because all information which is needed for the torrent is included in a single file, this file can
easily be distributed via other protocols, and as the file is replicated, the number of peers can
increase very quickly. The most popular method of distribution is using a public indexing site
which hosts the metainfo files. A seed will upload the file, and then others can download a copy
of the file over the HTTP protocol and participate in the torrent.
3.3 Tracker
A tracker is used to manage users participating in a torrent (known as peers). It stored
statistics about the torrent, but its main role is allowing peers to 'find each other' and start
communication, i.e. to find peers with the data they require. Peers know nothing of each other
until a response is received from the tracker. Whenever a peer contacts the tracker, it reports
which pieces of a file they have. That way, when another peer queries the tracker, it can provide
a random list of peers who are participating in the torrent, and have the required piece.
14

15. Fig 3.3: Tracker
A tracker is a HTTP/HTTPS service and typically works on port 6969. The address of the
tracker managing a torrent is specified in the metainfo file, a single tracker can manage multiple
torrents. Multiple trackers can also be specified, as backups, which are handled by the BitTorrent
client running on the user’s computer. BitTorrent clients communicate with the tracker using
HTTP GET requests, which is a standard CGI method. This consists of appending a "?" to the
URL, and separating parameters with a "&".
The parameters accepted by the tracker are:

info hash: 20-byte SHA1 hash of the info key from the metainfo file.

peer_id: 20-byte string used as a unique ID for the client.

port: The port number the client is listed on.
15

16. 
uploaded: The total amount uploaded since the client sent the 'started' event to the
tracker in base ten ASCII.

downloaded: The total amount downloaded since the client sent the 'started' event to the
tracker in base ten ASCII.

left: The number of bytes the client till has to download, in base ten ASCII.

compact: Indicates that the client accepts compacted responses. The peer list can then be
replaced by a 6 bytes per peer. The first 4 bytes are the host, and the last 2 bytes are port.

event: If specified, must be one of the following: started, stopped, completed.

ip: (optional) The IP address of the client machine, in dotted format.

numwant: (optional) The number of peers the client wishes to receive from the tracker.

key: (optional) Allows a client to identify itself if their IP address changes.

trackerid: (optional) If previous announce contained a tracker id, it should be set here.
The tracker then responds with a "text/plain" document with the following keys:

failure message: If present, then no other keys are included. The value is a human
readable error message as to why the request failed.

warning message: Similar to failure message, but response still gets processed.

interval: The number of seconds a client should wait between sending regular requests to
the tracker.

min interval: Minimum announce interval.

tracker id: A string that the client should send back with its next announce.

complete: Number of peers with the complete file.

incomplete: number of non-seeding peers (leechers)

peers: A list of dictionaries including: peer id, IP and ports of all the peers.
3.3.1 Scraping
Scraping is the process of querying the state of a given torrent (or all torrents) that the
tracker is managing. The result is known as a "scrape page". To get the scrape, you must start
with the announce URL, find the last '/' and if the text immediately following the '/' is 'announce',
then this can be substituted for 'scrape' to find the scrape page.
Examples:
16

17. Announce URL
Scrape URL
http://example.com/annnounce

http://example.com/scrape
http://example.com/a/annnounce

http://example.com/a/scrape
http://example.com/announce.php

http://example.com/scrape.php
The tracker then responds with a "text/plain" document with the following bencoded keys:

files: A dictionary containing one key pair for each torrent. Each key is made up of a 20byte binary hash value. The value of that key is then a nested dictionary with the
following keys:

complete: number of peers with the entire file (seeds)

downloaded: total number of times the entire file has been downloaded.

incomplete: the number of active downloaders (lechers)

name: (optional) the torrent name
3.4 Peers
Peers are other users participating in a torrent, and have the partial file, or the complete
file (known as a seed). Pieces are requested from peers, but are not guaranteed to be sent,
depending on the status of the peer. BitTorrent uses TCP (Transmission Control Protocol) ports
6881-6889 to send messages and data between peers, and unlike other protocols, does not use
UDP (User Datagram Protocol)
3.4.1 Piece Selection
Peers continuously queue up the pieces for download which they require. Therefore the
tracker is constantly replying to the peer with a list of peers who have the requested pieces.
17

18. Which piece is requested depends upon the BitTorrent client. There are three stages of piece
selection, which change depending on which stage of completion a peer is at.
3.4.2 Random First Piece
When downloading first begins, as the peer has nothing to upload, a piece is selected at
random to get the download started. Random pieces are then chosen until the first piece is
completed and checked. Once this happens, the 'rarest first' strategy begins.
3.4.3 Rarest First
When a peer selects which piece to download next, the rarest piece will be chosen from
the current swarm, i.e. the piece held by the lowest number of peers. This means that the most
common pieces are left until later, and focus goes to replication of rarer pieces.
At the beginning of a torrent, there will be only one seed with the complete file. There
would be a possible bottle neck if multiple downloaders were trying to access the same piece.
rarest first avoids this because different peers have different pieces. As more peers connect,
rarest first will the some load off of the tracker, as peers begin to download from one another.
Eventually the original seed will disappear from a torrent. This could be because of cost
reasons, or most commonly because of bandwidth issues. Losing a seed runs the risk of pieces
being lost if no current downloaders have them. Rarest first works to prevent the loss of pieces
by replicating the pieces most at risk as quickly as possible. If the original seed goes before at
least one other peer has the complete file, then no one will reach completion, unless a seed reconnects.
3.4.4 Endgame Mode
When a download nears completion, and waiting for a piece from a peer with slow
transfer rates, completion may be delayed. To prevent this, the remaining sub-pieces are request
from all peers in the current swarm.
3.4.5 Peer Distribution
18

19. The role of the tracker ends once peers have 'found each other'. From then on,
communication is done directly between peers, and the tracker is not involved. The set of peers a
BitTorrent client is in communication with is known as a swarm.
To maintain the integrity of the data which has been downloaded, a peer does not report
that they have a piece until they have performed a hash check with the one contained in the
metainfo file.
Peers will continue to download data from all available peers that they can, i.e. peers that
possess the required pieces. Peers can block others from downloading data if necessary. This is
known as choking.
3.4.6 Choking
When a peer receives a request for a piece from another peer, it can opt to refuse to
transmit that piece. If this happens, the peer is said to be choked. This can be done for different
reasons, but the most common is that by default, a client will only maintain a default number of
simultaneous uploads (max_uploads) All further requests to the client will be marked as choked.
Usually the default for max_uploads is 4.
Fig 3.4 :Choking by a peer
The peer will then remain choked until an unchoke message is sent. Another example of
when a peer is choked would be when downloading from a seed, and the seed requires no pieces.
19

20. To ensure fairness between peers, there is a system in place which rotates which peers are
downloading. This is known as optimistic unchoking.
3.4.7 Optimistic Unchoking
To ensure that connections with the best data transfer rates are not favored, each peer has
a reserved 'optimistic unchoke' which is left unchoked regardless of the current transfer rate. The
peer which is assigned to this is rotated every 30 seconds. This is enough time for the upload /
downloads rates to reach maximum capacity.
The peers then cooperate using the tit for tat strategy, where the downloader responds in
one period with the same action the uploader used in the last period.
3.4.8 Communication Between Peers
Peers which are exchanging data are in constant communication. Connections are
symmetrical, and therefore messages can be exchanged in both directions. These messages are
made up of a handshake, followed by a never-ending stream of length-prefixed messages.
3.4.9 Handshaking
Handshaking is performed as follows:

The handshake starts with character 19 (base 10) followed by the string 'BitTorrent
Protocol'.

A 20 byte SHA1 hash of the bencoded info value from the metainfo is then sent. If this
does not match between peers the connection is closed.

A 20 byte peer id is sent which is then used in tracker requests and included in peer
requests. If the peer id does not match the one expected, the connection is closed.
3.5 Data
BitTorrent is very versatile, and can be used to transfer a single file, of multiple files of
any type, contained within any number of directories. File sizes can vary hugely, from kilobytes
to hundreds of gigabytes.
20

21. 3.5.1 Piece Size
Data is split into smaller pieces which sent between peers using the bittorrent protocol.
These pieces are of a fixed size, which enables the tracker to keep tabs on who has which pieces
of data. This also breaks the file into verifiable pieces, each piece can then be assigned a hash
code, which can be checked by the downloader for data integrity. These hashes are stored as part
of the 'metinfo file' which is discussed in the next section.
The size of the pieces remains constant throughout all files in the torrent except for the
final piece which is irregular. The piece size a torrent is allocated depends on the amount of data.
Piece sizes which are too large will cause inefficiency when downloading (larger risk of data
corruption in larger pieces due to fewer integrity checks), whereas if the piece sizes are too
small, more hash checks will need to be run.
As the number of pieces increase, more hash codes need to be stored in the metainfo file.
Therefore, as a rule of thumb, pieces should be selected so that the metainfo file is no larger than
50 - 75kb. The main reason for this is to limit the amount of hosting storage and bandwidth
needed by indexing servers. The most common piece sizes are 256kb, 512kb and 1mb. The
number of pieces is therefore: total length / piece size. Pieces may overlap file boundaries.
For example, a 1.4Mb file could be split into the following pieces. This shows 5 * 256kb pieces,
and a final piece of 120kb.
Fig 3.5 : Pieces of a file
3.6 BitTorrent Clients
A BitTorrent client is an executable program which implements the BitTorrent protocol.
It runs together with the operating system on a user’s machine, and handles interactions with the
tracker and peers. The client is sits on the operating system and is responsible for controlling the
reading / writing of files, opening sockets etc.
21

22. A metainfo file must be opened by the client to start partaking in a torrent. Once the file
is read, the necessary data is extracted, and a socket must be opened to contact the tracker.
BitTorrent clients use TCP ports 6881-6999. To find an available port, the client will start at the
lowest port, and work upwards until it finds one it can use. This means the client will only use
one port, and opening another BitTorrent client will use another port. A client can handle
multiple torrents running concurrently.
Clients come in many flavors, and can range from basic applications with few features to
very advanced, customizable ones. For example, some advanced features are metainfo file
wizards and inbuilt trackers. These additional features mean different clients behave very
differently, and may use multiple ports, depending on the number of processes it is running. As
all applications implement the same protocol, there is no incompatibility issue, however because
of various tweaks and improvements between clients, a peer may experience better performance
from peers running the same client.
3.7 Sub Protocols
BitTorrent can be described in terms of two sub-protocols: one which describes
interactions between the tracker and all clients, and one which describes all client-to-client
interactions.
3.7.1 THP: Tracker HTTP Protocol
The tracker protocol is implemented on top of HTTP/HTTPS. This means that the
machine running the tracker runs a HTPP or HTTPS server, and has the behavior described
below:

The client sends a GET request to the tracker URL, with certain CGI variables andvalues
added to the URL. This is done in the standard way, i.e., if the base URL
is“http://some.url.com/announce”,
the
full
URL
would
be
of
this
form:“http://some.url.com/announce?var1=value1&var2=value2&var3=value3”.

The tracker responds with a “text/plain” document, containing a bencoded dictionary.
This dictionary has all the information required for the client.

The client then sends re-requests, either on regular intervals, or when an event occurs,and
the tracker responds.
22

23. The CGI variables and values added to the base URL by the client sending a GET request are:

info_hash: The 20 byte SHA1 hash calculated from whatever value the info key maps
to in the metainfo file.

peer_id: A 20 character long id of the downloading client, random generated at startof
every download. There is no formal definition on how to generate this id, but someclient
applications have adapted some semiformal standards on how to generate thisid.

ip: This is an optional variable, giving the IP address of the client. This can usually
beextracted from the TCP connection, but this field is useful if the client and tracker
areon the same machine, or behind the same NAT gateway. In both cases, the trackerthen
might publish an unroutable IP address to the client.

port: The port number that the client is listening on. This is usually in the range 68816889.

uploaded: The amount of data uploaded so far by the client. There is no official
definition on the unit, but generally bytes are used

left: How much the user has left for the download to be complete, in bytes.

event: An optional variable, corresponding to one of four possibilities:

started: Sent when the client starts the download

stopped: Sent when the client stops downloading

completed: Sent when the download is complete. If the download is completeat start up,
this message should not be sent.

empty: Has the same effect as if the event key is nonexistent. In either case, the message
in question is one of the messages sent with regular intervals.
There are some optional variables that can be sent along with the GET request that are not
specified in the official description of the protocol, but are implemented by some tracker servers:

numwant: The number of peers the client wants in the response.

key: An identification key that is not published to other peers. peer_id is public, and is
thus useless as authorization. key is used if the peer changes IP number to prove
it’sidentity to the tracker.

Trackerid: If a tracker previously gave its trackerid, this should be given here.
As mentioned earlier, the response is a “text/plain” response with a bencoded dictionary. This
dictionary contains the following keys:
23

24. 
failure reason: If this key is present, no other keys are included. The value mapped tothis
key is a human readable string with the reason to why the connection failed.

interval: The number of seconds that the client should wait between regularrarequests.

peers: Maps to a list of dictionaries, that each represent a peer, where each dictionaryhas
the keys:

peer_id: The id of the peer in question. The tracker obtained this by the peer_id variable
in the GET request sent to the tracker.

ip: The address of the peer, either the IP address or the DNS domain name.

port: The port number that the peer listens on.
These are the keys required by the official protocol specification, but here as well there are
optional extensions:

min interval: If present, the client must do requests more often than this.

warning message: Has the same information as failure reason, but the other keys in the
dictionary are present.

tracker id: A string identification the tracker. A client should resend it in thetrackerid
variable to the tracker.

complete: This is the number of peers that have the complete file available for upload.

incomplete: The number of peers that not have the complete file yet.
3.7.2 PWP: Peer Wire Protocol
The peer wire (peer to peer) protocol runs over TCP. Message passing is symmetric, i.e.
messages are the same sent in both directions. When a client wants to initiate a connection, it sets
up the TCP connection and sends a handshake message to the other peer. If the message is
acceptable, the receiving side sends a handshake message back. If the initiator accepts this
handshake, message passing can initiate, and continues indefinitely. All integers are encoded as
four byte big-endian, except the first length prefix in the handshake.
3.8 Handshake message
The handshake message consists of five parts:
24

25. 
A single byte, containing the decimal value 19. This is the length of the characterstring
following this byte.

A character string “BitTorrent protocol”, which describes the protocol. Newerprotocols
should follow this convention to facilitate easy identification of protocols.

Eight reserved bytes for further extension of the protocol. All bytes are zero in
currentimplementations.

A 20 byte SHA1 hash of the value mapping to the info key in the torrent file. This isthe
same hash sent to the tracker in the info_hash variable.

The 20 byte character string representing the peer id. This is the same value sent to the
tracker.
If a peer is the first recipient to a handshake, and the info_hash doesn’t match any torrent
it is serving, it should break the connection. If the initiator of the connection receives a
handshake where the peer id doesn’t match with the id received from the tracker, the connection
should be dropped. Each peer needs to keep the state of each connection. The state consists of
two values, interested and choking. A peer can be either interested or not in another peer, and
either choke or not choke the other peer. Choking means that no requests will be answered, and
interested means that the peer is interested in downloading pieces of the file from the other peer.
This means that each peer needs four Boolean values for each connection to keep track of
the state.

am_interested

am_choking

peer_interested

peer_choking
All connections start out as not interested and choking for both peers. Clients should keep
the am_interested value updated continuously, and report changes to the other peer. The
messages sent after the handshaking are structured as: [message length as an integer] [single
byte describing message type] [payload] Keep alive messages are sent with regular intervals, and
they are simply a message with length 0, and no type or payload.
Type 0, 1, 2, 3 are choke, unchoke, interested and not interested respectively. All of them
have length 1 and no payload. These messages simply describe changes in state.
25

26. Type 4 is a have. This message has length = 5, and a payload that is a single integer,
giving the integer index of which piece of the file the peer has successfully downloaded and
verified.
Type 5 is bit field. This message is only sent directly after handshake. It contains a bit
field representation of which pieces the peer has. The payload is of variable length, and consists
of a bitmap, where byte 0 corresponds to piece 0-7, byte 1 to piece 8-15 etc. A bit set to 1
represents having the piece. Peers that have no pieces can neglect to send this message.
Type 6 is a request. The payload consists of three integers, piece index, begin and length.
The piece index decides within which piece the client wants to download, begin gives the byte
offset within the piece, and length gives the number of bytes the client wants to download.
Length is usually a power of two.
Type 7 is a block. This message follows a request. The payload contains piece index,
length and the data itself that was requested. Type 8 is cancel. This message has the same
payload as request messages, and it is used to cancel requests made. Peers should continuously
update their interested status to neighbors, so that clients know which peers will begin
downloading when unchoked.
26

27. 4. Conclusion
BitTorrent pioneered mesh-based file distribution that effectively utilizes all the uplinks
of participating nodes. Most followon research used similar distributed and randomized
algorithms for peer and piece selection, but with different emphasis or twists. This work takes a
different approach to the mesh-based file distribution problem by considering it as a scheduling
problem, and strives to derive an optimal schedule that could minimize the total elapsed time. By
comparing the total elapsed time of BitTorrent and CSFD in a wide variety of scenarios, we are
able to determine how close BitTorrent is to the theoretical optimum. In addition, the study of
applicability of BitTorrent to real-time media streaming applications, shows that with minor
modifications, BitTorrent can serve as an effective media streaming tool as well.
BitTorrent’s application in this information sharing age is almost priceless. However,it is
still not perfected as it is still prone to malicious attacks and acts of misuse. Moreover, the
lifespan of each torrent is still not satisfactory, which means that the length of file distribution
can only survive for a limited period of time. Thus, further analysis and a more thorough study in
the protocol will enable one to discover more ways to improve it.
27

28. 5. References
[1]
BitTorrent Inc. (2006) http://www.bittorrent.com
[2]
BitTorrent.Org (2006) http://www.bittorrent.org/protocol.htm
[3]
Cohen, Bram (2003)
Incentives Build Robustness in BitTorrent, May 22 2003
http://www.bitconjurer.org/BitTorrent/bittorrentecon.pdf
[4]
Information on BitTorrent Protocol http://en.wikipedia.org/wiki/BitTorrent_(protocol)
[5]
BitTorrentFAQ:http://btfaq.com
[6]
BitTorrent Specifications http://wiki.theory.org/BitTorrentSpecification
[7]
Other Informationhttp://www.dessent.net/btfaq/#compare
[8]
The History Of File Sharing http://torrentfreak.com/the-history-of-filesharing-120422/
28