Académique Documents
Professionnel Documents
Culture Documents
Introduction
1. Overview
1
Bit Torrent Protocol
Seminar Report 2011
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.
1.1 History
2
Bit Torrent Protocol
Seminar Report 2011
The first usable version of BitTorrent appeared in October 2002, but the system
needed a lot of fine-tuning. 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.
3
Bit Torrent Protocol
Seminar Report 2011
The most common method by which files are transferred on the Internet
is the client-server 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.
Another method of transferring files has become popular recently: the
peer-to-peer network, systems such as Kazaa, eDonkey, Gnutella, Direct
Connect, etc. In most of these networks, ordinary Internet users trade files by
4
Bit Torrent Protocol
Seminar Report 2011
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.
Use of the Usenet binary newsgroups is yet another method of file
distribution, one that is substantially different from the other methods. Files
transferred over Usenet are often subject to miniscule windows of opportunity.
Typical retention time of binary news servers are often as low as 24 hours, and
having a posted file available for a week is considered a long time. However,
the Usenet model is relatively efficient, in that the messages are passed around
a large web of peers from one news server to another, and finally fanned out to
the end user from there. Often the end user connects to a server provided by his
or her ISP, resulting in further bandwidth savings. Usenet is also one of the
more anonymous forms of file sharing, and it too is often used for illicit files of
almost any nature. Due to the nature of NNTP, a file's popularity has little to do
5
Bit Torrent Protocol
Seminar Report 2011
with its availability and hence downloads from Usenet tend to be quite fast
regardless of content. The downsides of this method include a set of rules and
procedures, and requires a certain amount of effort and understanding from the
user. Patience is often required to get a complete file due to the nature of
splitting big files into a huge number of smaller posts. Finally, access to Usenet
often must be purchased due to the extremely high volume of messages in the
binary groups.
BitTorrent is closest to Usenet. It is best suited to newer files, of which a
number of people have interest in. Obscure or older files tend to not be
available. Perhaps as the software matures a more suitable means of keeping
torrents seeded will emerge, but currently the client is quite resource-intensive,
making it cumbersome to share a number of files. BitTorrent also deals well
with files that are in high demand, especially compared to the other methods.
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. A single server can handle
many such clients and serve the requested file simultaneously to all the clients.
The file being served will be available as one single piece, which means that if
the download process stops abruptly in the middle the whole file has to be
downloaded again. BitTorrent protocol has overcome all these shortcomings
seen in this type and thus it is more robust due to which it is chosen by many
people over this traditional method of file transfer.
6
Bit Torrent Protocol
Seminar Report 2011
7
Bit Torrent Protocol
Seminar Report 2011
Web, and reduces download times for users while allowing them to receive
maximum benefit from their available bandwidth. DAP's Resume functionality
and the ability to continue downloading even when one of the participating
connections has dropped also provides users with a more reliable download
experience.
8
Bit Torrent Protocol
Seminar Report 2011
9
Bit Torrent Protocol
Seminar Report 2011
since the whole process is not depending on servers alone. The load is
distributed across the network between peers and servers. This makes
BitTorrent far better than its competing peers like DAP and others.
3. Working of BitTorrent
10
Bit Torrent Protocol
Seminar Report 2011
11
Bit Torrent Protocol
Seminar Report 2011
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.
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. Usually a tracker coordinates
12
Bit Torrent Protocol
Seminar Report 2011
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
13
Bit Torrent Protocol
Seminar Report 2011
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 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.
4. Terminology
These are the common terms that one would come across while making
a typical BitTorrent file transfer.
Torrent : this refers to the small metadata file you receive from
the web server (the one that ends in .torrent.) Metadata here
means that the file contains information about the data you want
to download, not the data itself.
14
Bit Torrent Protocol
Seminar Report 2011
to and transfer data. Generally a peer does not have the complete
file.
Leeches : They are similar to peers in that they won’t have the
complete file. But the main difference between the two is that a
leech will not upload once the file is downloaded.
Seed : A computer that has a complete copy of a certain torrent.
15
Bit Torrent Protocol
Seminar Report 2011
the other end has some pieces that the downloader wants. Then
the downloader is said to be interested in the other end.
Snubbed : If the client has not received anything after a certain
5. 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.
16
Bit Torrent Protocol
Seminar Report 2011
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.
17
Bit Torrent Protocol
Seminar Report 2011
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
• created by: Name and Version of programme used to create the
metainfo file
These keys are structured in the metainfo file as follows:
18
Bit Torrent Protocol
Seminar Report 2011
Instead of transmitting the keys in plan 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'.
5.1.1 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:
19
Bit Torrent Protocol
Seminar Report 2011
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.
5.2 Tracker
A tracker is used to manage users participating in a torrent (know as
peers). It stored statistics about the torrent, but its main role is allow 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.
20
Bit Torrent Protocol
Seminar Report 2011
21
Bit Torrent Protocol
Seminar Report 2011
5.2.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:
22
Bit Torrent Protocol
Seminar Report 2011
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 20-byte 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
5.3 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)
23
Bit Torrent Protocol
Seminar Report 2011
24
Bit Torrent Protocol
Seminar Report 2011
25
Bit Torrent Protocol
Seminar Report 2011
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. To ensure fairness between peers, there is
a system in place which rotates which peers are downloading. This is know as
optimistic unchoking.
5.3.7 Optimistic Unchoking
To ensure that connections with the best data transfer rates are not
favoured, 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 / download 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.
5.3.8 Communication Between Peers
Peers which are exchanging data are in constant communication.
Connections are symmetrical, and therefore messages can be exchanged in both
26
Bit Torrent Protocol
Seminar Report 2011
5.3.9 Handshaking
Handshaking is performed as follows:
1. The handshake starts with character 19 (base 10) followed by the string
'BitTorrent Protocol'.
2. 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.
3. 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.
Prefi Additional
Message Structure
x Information
Fixed length,
no payload.
This enables
0 choke <len=0001><id=0> a peer to
block another
peers request
for data.
27
Bit Torrent Protocol
Seminar Report 2011
Fixed length,
no payload.
Unblock
peer, and if
1 unchoke <len=0001><id=1> they are still
interested in
the data,
upload will
begin.
Fixed length,
no payload.
A user is
2 interested <len=0001><id=2> interested if a
peer has the
data they
require.
Fixed length,
no payload.
The peer
not
3 <len=0001><id=3> does not
interested
have any
data
required.
Fixed length.
Payload is
the zero-
based index
4 have <len=0005><id=4><piece index> of the piece.
Details the
pieces that
peer
currently has.
28
Bit Torrent Protocol
Seminar Report 2011
Sent
immediately
after
handshaking.
Optional, and
only sent if
client has
pieces.
Variable
5 bitfield <len=0001+X><id=5><bitfield>
length, X is
the length of
bitfield.
Payload
represents
pieces that
have been
successfully
downloaded.
Fixed length,
used to
request a
block of
pieces. The
payload
contains
6 request <len=0013><id=6><index><begin><length>
integer
values
specifying
the index,
begin
location and
length.
29
Bit Torrent Protocol
Seminar Report 2011
messages.
Fixed length,
X is the
length of the
block. The
payload
contains
integer
values
specifying
the index,
begin
location and
length.
Fixed length,
used to
cancel block
requests.
payload is
8 cancel <len=13><id=8><index><begin><length> the same as
‘request’.
Typically
used during
‘end game’
mode.
A peer will be 'interested' in data if there is a peer which has the required
pieces. If the peer which has this data is not choked, then data will be
transferred. After handshaking, by default, connections start out as choked, and
not interested.
5.4 Data
30
Bit Torrent Protocol
Seminar Report 2011
31
Bit Torrent Protocol
Seminar Report 2011
32
Bit Torrent Protocol
Seminar Report 2011
1. The client sends a GET request to the tracker URL, with certain CGI
variables and
values 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”.
2. The tracker responds with a “text/plain” document, containing a bencoded
dictionary.
This dictionary has all the information required for the client.
3. The client then sends re-requests, either on regular intervals, or when an
event occurs,
and the tracker responds.
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
33
Bit Torrent Protocol
Seminar Report 2011
generated at start
of every download. There is no formal definition on how to generate this
id, but some
client applications have adapted some semiformal standards on how to
generate this
id.
ip: This is an optional variable, giving the IP address of the client. This
can usually be
extracted from the TCP connection, but this field is useful if the client
and tracker are
on the same machine, or behind the same NAT gateway. In both cases,
the tracker
then might publish an unroutable IP address to the client.
port: The port number that the client is listening on. This is usually in
bytes.
event: An optional variable, corresponding to one of four possibilities:
34
Bit Torrent Protocol
Seminar Report 2011
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.
public, and
is thus useless as authorization. key is used if the peer changes IP
number to prove it’s
identity to the tracker.
trackerid: If a tracker previously gave its trackerid, this should be given
here.
value mapped to
this 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
regular
rerequests.
35
Bit Torrent Protocol
Seminar Report 2011
each dictionary
has 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 rereqests 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 identificating the tracker. A client should resend it in
the
trackerid variable to the tracker.
complete: This is the number of peers that have the complete file
incomplete: The number of peers that not have the complete file yet.
36
Bit Torrent Protocol
Seminar Report 2011
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.
Handshake message
The handshake message consists of five parts:
A single byte, containing the decimal value 19. This is the length of the
character
string following this byte.
A character string “BitTorrent protocol”, which describes the protocol.
Newer
protocols should follow this convention to facilitate easy identification
of protocols.
Eight reserved bytes for further extension of the protocol. All bytes are
zero in current
implementations.
A 20 byte SHA1 hash of the value mapping to the info key in the torrent
file. This is
the same hash sent to the tracker in the info_hash variable.
The 20 byte character string representing the peer id. This is the same
37
Bit Torrent Protocol
Seminar Report 2011
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.
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 bitfield. This message is only sent directly after handshake. It
contains a bitfield 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.
38
Bit Torrent Protocol
Seminar Report 2011
6. Vulnerabilities of BitTorrent
39
Bit Torrent Protocol
Seminar Report 2011
5. Attacker requests all chunks from swarm and wastes their upload
bandwidth.
Pollution attacks have become increasingly popular and have been used
by
anti-piracy groups. In 2005 HBO used pollution attacks to prevent people from
downloading their show Rome.
40
Bit Torrent Protocol
Seminar Report 2011
Many ISPs don’t encourage the use of BitTorrent from their users. This
is because BitTorrent is usually used to transfer large sized files due to
which the traffic over the ISPs increase to a large extent. To avoid such
exploding traffic on their servers many ISPs have started to avoid the
traffic caused by BitTorrent. This can be done by sniffing the packets
that pass through and detecting whether they oblige BitTorrent protocol.
ISPs make use of filters to find out such packets and block them from
passing their servers. This has resulted in many file transfer breakdowns
across the world.
6.2 Solutions
Many of the attacks that BitTorrent suffers have been dealt with and some
measures have been taken to avoid such attacks. Here are a few solutions to the
attacks that were discussed above.
41
Bit Torrent Protocol
Seminar Report 2011
Another fix would be for web sites hosting torrents to check and report whether
all trackers are active, or even remove the on-responding trackers from the
tracker list in the torrent. Another measure could be to restrict the size of the
tracker list to reduce the effectiveness of such an attack.
7. Conclusion
42
Bit Torrent Protocol
Seminar Report 2011
8. References
May 22 2003
http://www.bitconjurer.org/BitTorrent/bittorrentecon.pdf
4. Cachelogic, BitTorrent bandwidth usage
http://www.cachelogic.com/research/2005_slide06.php
5. Information on BitTorrent Protocol
en.wikipedia.org/wiki/BitTorrent_(protocol)
6. BitTorrent FAQ: http://btfaq.com
43
Bit Torrent Protocol
Seminar Report 2011
7. BitTorrent Specifications
http://wiki.theory.org/BitTorrentSpecification
8. Other Information http://www.dessent.net/btfaq/#compare
44