Friday, February 17, 2012

d h c p

Dynamic Host Configuration Protocol

From Wikipedia, the free encyclopedia
A DHCP Server settings tab
The Dynamic Host Configuration Protocol (DHCP) is a network configuration protocol for hosts on Internet Protocol (IP) networks. Computers that are connected to IP networks must be configured before they can communicate with other hosts. The most essential information needed is an IP address, and a default route and routing prefix. DHCP eliminates the manual task by a network administrator. It also provides a central database of devices that are connected to the network and eliminates duplicate resource assignments.
In addition to IP addresses, DHCP also provides other configuration information, particularly the IP addresses of local Domain Name Server (DNS), network boot servers, or other service hosts.
DHCP is used for IPv4 as well as IPv6. While both versions serve much the same purpose, the details of the protocol for IPv4 and IPv6 are sufficiently different that they may be considered separate protocols.[1]
Hosts that do not use DHCP for address configuration may still use it to obtain other configuration information. Alternatively, IPv6 hosts may use stateless address autoconfiguration. IPv4 hosts may use link-local addressing to achieve limited local connectivity.

Contents

 [hide

[edit] History

DHCP was first defined as a standards track protocol in RFC 1531 in October 1993, as an extension to the Bootstrap Protocol (BOOTP). The motivation for extending BOOTP was that BOOTP required manual intervention to add configuration information for each client, and did not provide a mechanism for reclaiming disused IP addresses.
Many worked to clarify the protocol as it gained popularity, and in 1997 RFC 2131 was released, and remains as of 2011 the standard for IPv4 networks. DHCPv6 is documented in RFC 3315. RFC 3633 added a DHCPv6 mechanism for prefix delegation. DHCPv6 was further extended to provide configuration information to clients configured using stateless address autoconfiguration in RFC 3736.
The BOOTP protocol itself was first defined in RFC 951 as a replacement for the Reverse Address Resolution Protocol RARP. The primary motivation for replacing RARP with BOOTP was that RARP was a data link layer protocol. This made implementation difficult on many server platforms, and required that a server be present on each individual network link. BOOTP introduced the innovation of a relay agent, which allowed the forwarding of BOOTP packets off the local network using standard IP routing, thus one central BOOTP server could serve hosts on many IP subnets.[2]

[edit] Technical overview

Dynamic Host Configuration Protocol automates network-parameter assignment to network devices from one or more DHCP servers. Even in small networks, DHCP is useful because it makes it easy to add new machines to the network.
When a DHCP-configured client (a computer or any other network-aware device) connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, other servers such as time servers, and so forth. On receiving a valid request, the server assigns the computer an IP address, a lease (length of time the allocation is valid), and other IP configuration parameters, such as the subnet mask and the default gateway. The query is typically initiated immediately after booting, and must complete before the client can initiate IP-based communication with other hosts.
Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:
  • dynamic allocation: A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
  • automatic allocation: The DHCP server permanently assigns a free IP address to a requesting client from the range defined by the administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
  • static allocation: The DHCP server allocates an IP address based on a table with MAC address/IP address pairs, which are manually filled in (perhaps by a network administrator). Only requesting clients with a MAC address listed in this table will be allocated an IP address. This feature (which is not supported by all DHCP servers) is variously called Static DHCP Assignment (by DD-WRT), fixed-address (by the dhcpd documentation), Address Reservation (by Netgear), DHCP reservation or Static DHCP (by Cisco/Linksys), and IP reservation or MAC/IP binding (by various other router manufacturers).

[edit] Technical details

DHCP uses the same two ports assigned by IANA for BOOTP: destination UDP port 67 for sending data to the server, and UDP port 68 for data to the client. DHCP communications are connectionless in nature.
DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease acknowledgement.
DHCP clients and servers on the same subnet communicate via UDP broadcasts, initially. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point.

[edit] DHCP discovery

The client broadcasts messages on the physical subnet to discover available DHCP servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server from a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet with the broadcast destination of 255.255.255.255 or the specific subnet broadcast address.
A DHCP client can also request its last-known IP address (in the example below, 192.168.1.100). If the client remains connected to a network for which this IP is valid, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP address immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address.
DHCPDISCOVER
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0x00000000
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s, or overflow space for additional options. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Discover
DHCP option 50: 192.168.1.100 requested
DHCP option 55: Parameter Request List: Request Subnet Mask (1), Router (3), Domain Name (15),
Domain Name Server (6)

[edit] DHCP offer

When a DHCP server receives an IP lease request from a client, it reserves an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration based on the client's hardware address as specified in the CHADDR (Client Hardware Address) field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR (Your IP Address) field.
DHCPOFFER
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Offer
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18

[edit] DHCP request

In response to the offer Client requests the server. The client replies DHCPRequest, unicast to the server, requesting the offered address A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on the Transaction ID field in the request, servers are informed whose offer the client has accepted. When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses. In some cases DHCP request message is broadcast, instead of being unicast to a particular DHCP server, because the DHCP client has still not received an IP address. Also, this way one message can let all other DHCP servers know that another server will be supplying the IP address without missing any of the servers with a series of unicast messages.
Read more: http://wiki.answers.com/Q/What_is_Dora_process_in_DHCP_and_how_it_works#ixzz1ljWKjqeA

DHCPREQUEST
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Request
DHCP option 50: 192.168.1.100 requested
DHCP option 54: 192.168.1.1 DHCP server.

[edit] DHCP acknowledgement

When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed.
The protocol expects the DHCP client to configure its network interface with the negotiated parameters.
DHCPACK
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address switched by relay)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP ACK
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18
After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to prevent IP conflicts caused by overlapping address pools of DHCP servers.

[edit] DHCP information

A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.

[edit] DHCP releasing

The client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.

[edit] Client configuration parameters in DHCP

A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS.
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[3]

[edit] Options

An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method that a DHCP client can utilize to communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value that this option is set to give the DHCP server a hint about any required extra information that this client needs in a DHCP response.

[edit] DHCP Relaying

In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it doesn't have a routable IP address, nor does it know the IP address of a router. In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR address, again using unicast. The relay agent then retransmits the response on the local network.

[edit] Reliability

The DHCP protocol provides reliability in several ways: periodic renewal, rebinding, and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired. They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, the DHCPREQUEST will be repeated by the client from time to time,[specify] so when the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it, and renew its lease.
If the DHCP server is unreachable for an extended period of time,[specify] the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.
In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A standard for implementing fault-tolerant DHCP servers was developed at the Internet Engineering Task Force.[4][note 1]
If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease. At that time, it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address, presumably from a different DHCP server, it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.

[edit] Security

The base DHCP protocol does not include any mechanism for authentication.[5] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
  • Unauthorized DHCP servers providing false information to clients.[6]
  • Unauthorized clients gaining access to resources.[6]
  • Resource exhaustion attacks from malicious DHCP clients.[6]
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers can be operated on networks, providing incorrect information to DHCP clients. This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity[citation needed], or as a man-in-the-middle attack. Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[6] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[7] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[7]
Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[citation needed] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[citation needed]
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[5]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[8]

Saturday, February 11, 2012

about torrent


BitTorrent (protocol)

BitTorrent is a peer-to-peer file sharing protocol used for distributing large amounts of data over the Internet. BitTorrent is one of the most common protocols for transferring large files, and it has been estimated that it accounted for roughly 43% to 70% of all Internet traffic (depending on geographical location) as of February 2009.[1]
Programmer Bram Cohen designed the protocol in April 2001 and released a first implementation on July 2, 2001.[2] It is now maintained by Cohen's company BitTorrent, Inc. There are numerous BitTorrent clients available for a variety of computing platforms.
As of January 2012 BitTorrent has 150 million active users according to BitTorrent Inc.. Based on this the total number of monthly BitTorrent users can be estimated at more than a quarter billion.[3] At any given instant of time BitTorrent has, on average, more active users than YouTube and Facebook combined. (This refers to the number of active users at any instant and not to the total number of unique users.)[4][5][dubious ]

Contents

 [hide

[edit] Description

The BitTorrent protocol can be used to reduce the server and network impact of distributing large files. Rather than downloading a file from a single source server, the BitTorrent protocol allows users to join a "swarm" of hosts to download and upload from each other simultaneously. The protocol is an alternative to the older single source, multiple mirror sources technique for distributing data, and can work over networks with lower bandwidth so many small computers, like mobile phones, are able to efficiently distribute files to many recipients.
A user who wants to upload a file first creates a small torrent descriptor file that they distribute by conventional means (web, email, etc.). They then make the file itself available through a BitTorrent node acting as a seed. Those with the torrent descriptor file can give it to their own BitTorrent nodes which, acting as peers or leechers, download it by connecting to the seed and/or other peers.
The file being distributed is divided into segments called pieces. As each peer receives a new piece of the file it becomes a source (of that piece) for other peers, relieving the original seed from having to send that piece to every computer or user wishing a copy. With BitTorrent, the task of distributing the file is shared by those who want it; it is entirely possible for the seed to send only a single copy of the file itself and eventually distribute to an unlimited number of peers.
Each piece is protected by a cryptographic hash contained in the torrent descriptor.[6] This ensures that any modification of the piece can be reliably detected, and thus prevents both accidental and malicious modifications of any of the pieces received at other nodes. If a node starts with an authentic copy of the torrent descriptor, it can verify the authenticity of the entire file it receives.
Pieces are typically downloaded non-sequentially and are rearranged into the correct order by the BitTorrent Client, which monitors which pieces it has, can upload to other peers and which it needs. Pieces are of the same size throughout a single download (for example a 10MB file may be transmitted as ten 1MB Pieces or as forty 256kB Pieces). Due to the nature of this approach, the download of any file can be halted at any time and be resumed at a later date, without the loss of previously downloaded information, which in turn makes BitTorrent particularly useful in the transfer of larger files. This also enables the client to seek out readily available pieces and download them immediately, rather than halting the download and waiting for the next (and possibly unavailable) piece in line, which typically reduces the overall length of the download.
When a peer completely downloads a file, it becomes an additional seed. This eventual shift from peers to seeders determines the overall "health" of the file (as determined by the number of times a file is available in its complete form).
The distributed nature of BitTorrent leads to a flood like spreading of a file throughout many peer computer nodes. As more peers join the swarm, the likelihood of a complete successful download by any particular node increases. Relative to traditional Internet distribution schemes, this permits a significant reduction in the original distributor's hardware and bandwidth resource costs. It also provides redundancy against system problems, reduces dependence on the original distributor[7] and provides sources for the file which are generally transient and therefore harder to trace by those who would block distribution compared to the situation provided by limiting availability of the file to a fixed host machine (or even several).

[edit] Operation

Animation showing 7 remote computers exchanging data with an 8th (local) computer over a network.
In this animation, the colored bars beneath all of the 7 clients in the animation above represent the file, with each color representing an individual piece of the file. After the initial pieces transfer from the seed (large system at the bottom), the pieces are individually transferred from client to client. The original seeder only needs to send out one copy of the file for all the clients to receive a copy.
A BitTorrent client is any program that implements the BitTorrent protocol. Each client is capable of preparing, requesting, and transmitting any type of computer file over a network, using the protocol. A peer is any computer running an instance of a client.
To share a file or group of files, a peer first creates a small file called a "torrent" (e.g. MyFile.torrent). This file contains metadata about the files to be shared and about the tracker, the computer that coordinates the file distribution. Peers that want to download the file must first obtain a torrent file for it and connect to the specified tracker, which tells them from which other peers to download the pieces of the file.
Though both ultimately transfer files over a network, a BitTorrent download differs from a classic download (as is typical with an HTTP or FTP request, for example) in several fundamental ways:
  • BitTorrent makes many small data requests over different TCP connections to different machines, while classic downloading is typically made via a single TCP connection to a single machine.
  • BitTorrent downloads in a random or in a "rarest-first"[8] approach that ensures high availability, while classic downloads are sequential.
Taken together, these differences allow BitTorrent to achieve much lower cost to the content provider, much higher redundancy, and much greater resistance to abuse or to "flash crowds" than regular server software. However, this protection, theoretically, comes at a cost: downloads can take time to rise to full speed because it may take time for enough peer connections to be established, and it may take time for a node to receive sufficient data to become an effective uploader. This contrasts with regular downloads (such as from an HTTP server, for example) that, while more vulnerable to overload and abuse, rise to full speed very quickly and maintain this speed throughout.
In general, BitTorrent's non-contiguous download methods have prevented it from supporting "progressive downloads" or "streaming playback". However, comments made by Bram Cohen in January 2007 suggest that streaming torrent downloads will soon be commonplace and ad supported streaming appears to be the result of those comments. In January 2011 Cohen demonstrated an early version of BitTorrent streaming, saying the feature will be available by summer 2011.[8]

[edit] Creating and publishing torrents

The peer distributing a data file treats the file as a number of identically sized pieces, usually with byte sizes of a power of 2, and typically between 32 kB and 16 MB each. The peer creates a hash for each piece, using the SHA-1 hash function, and records it in the torrent file. Pieces with sizes greater than 512 kB will reduce the size of a torrent file for a very large payload, but is claimed to reduce the efficiency of the protocol.[9] When another peer later receives a particular piece, the hash of the piece is compared to the recorded hash to test that the piece is error-free.[10] Peers that provide a complete file are called seeders, and the peer providing the initial copy is called the initial seeder.
The exact information contained in the torrent file depends on the version of the BitTorrent protocol. By convention, the name of a torrent file has the suffix .torrent. Torrent files have an "announce" section, which specifies the URL of the tracker, and an "info" section, containing (suggested) names for the files, their lengths, the piece length used, and a SHA-1 hash code for each piece, all of which are used by clients to verify the integrity of the data they receive.
Torrent files are typically published on websites or elsewhere, and registered with at least one tracker. The tracker maintains lists of the clients currently participating in the torrent.[10] Alternatively, in a trackerless system (decentralized tracking) every peer acts as a tracker. Azureus was the first[citation needed] BitTorrent client to implement such a system through the distributed hash table (DHT) method. An alternative and incompatible DHT system, known as Mainline DHT, was later developed and adopted by the BitTorrent (Mainline), µTorrent, Transmission, rTorrent, KTorrent, BitComet, and Deluge clients.
After the DHT was adopted, a "private" flag — analogous to the broadcast flag — was unofficially introduced, telling clients to restrict the use of decentralized tracking regardless of the user's desires.[11] The flag is intentionally placed in the info section of the torrent so that it cannot be disabled or removed without changing the identity of the torrent. The purpose of the flag is to prevent torrents from being shared with clients that do not have access to the tracker. The flag was requested for inclusion in the official specification in August, 2008, but has not been accepted.[12] Clients that have ignored the private flag were banned by many trackers, discouraging the practice.[13]

[edit] Downloading torrents and sharing files

Users find a torrent of interest, by browsing the web or by other means, download it, and open it with a BitTorrent client. The client connects to the tracker(s) specified in the torrent file, from which it receives a list of peers currently transferring pieces of the file(s) specified in the torrent. The client connects to those peers to obtain the various pieces. If the swarm contains only the initial seeder, the client connects directly to it and begins to request pieces.
Clients incorporate mechanisms to optimize their download and upload rates; for example they download pieces in a random order to increase the opportunity to exchange data, which is only possible if two peers have different pieces of the file.
The effectiveness of this data exchange depends largely on the policies that clients use to determine to whom to send data. Clients may prefer to send data to peers that send data back to them (a tit for tat scheme), which encourages fair trading. But strict policies often result in suboptimal situations, such as when newly joined peers are unable to receive any data because they don't have any pieces yet to trade themselves or when two peers with a good connection between them do not exchange data simply because neither of them takes the initiative. To counter these effects, the official BitTorrent client program uses a mechanism called "optimistic unchoking", whereby the client reserves a portion of its available bandwidth for sending pieces to random peers (not necessarily known good partners, so called preferred peers) in hopes of discovering even better partners and to ensure that newcomers get a chance to join the swarm.[14]
Although swarming scales well to tolerate flash crowds for popular content, it is less useful for unpopular content. Peers arriving after the initial rush might find the content unavailable and need to wait for the arrival of a seed in order to complete their downloads. The seed arrival, in turn, may take long to happen (this is termed the seeder promotion problem). Since maintaining seeds for unpopular content entails high bandwidth and administrative costs, this runs counter to the goals of publishers that value BitTorrent as a cheap alternative to a client-server approach. This occurs on a huge scale; measurements have shown that 38% of all new torrents become unavailable within the first month.[15] A strategy adopted by many publishers which significantly increases availability of unpopular content consists of bundling multiple files in a single swarm.[16] More sophisticated solutions have also been proposed; generally, these use cross-torrent mechanisms through which multiple torrents can cooperate to better share content.[17]
BitTorrent does not offer its users anonymity. It is possible to obtain the IP addresses of all current and possibly previous participants in a swarm from the tracker. This may expose users with insecure systems to attacks.[14] It may also expose users to the risk of being sued, if they are distributing files without permission from the copyright holder(s). However, there are ways to promote anonymity; for example, the OneSwarm project layers privacy-preserving sharing mechanisms on top of the original BitTorrent protocol.

[edit] Adoption

A growing number of individuals and organizations are using BitTorrent to distribute their own or licensed material. Independent adopters report that without using BitTorrent technology and its dramatically reduced demands on their private networking hardware and bandwidth, they could not afford to distribute their files.[18]

[edit] Film, video and music

  • BitTorrent Inc. has obtained a number of licenses from Hollywood studios for distributing popular content from their websites.
  • Sub Pop Records releases tracks and videos via BitTorrent Inc.[19] to distribute its 1000+ albums. Babyshambles and The Libertines (both bands associated with Pete Doherty) have extensively used torrents to distribute hundreds of demos and live videos. US industrial rock band Nine Inch Nails frequently distributes albums via BitTorrent.
  • Podcasting software is starting to integrate BitTorrent to help podcasters deal with the download demands of their MP3 "radio" programs. Specifically, Juice and Miro (formerly known as Democracy Player) support automatic processing of .torrent files from RSS feeds. Similarly, some BitTorrent clients, such as µTorrent, are able to process web feeds and automatically download content found within them.
  • DGM Live! purchases are provided via BitTorrent.[20]

[edit] Broadcasters

  • In 2008, the CBC became the first public broadcaster in North America to make a full show (Canada's Next Great Prime Minister) available for download using BitTorrent.[21]
  • The Norwegian Broadcasting Corporation (NRK) has since March 2008 experimented with bittorrent distribution, available online.[22] Only selected material in which NRK owns all royalties are published. Responses have been very positive, and NRK is planning to offer more content.
  • The Dutch VPRO broadcasting organization released three documentaries under a Creative Commons license using the content distribution feature of the Mininova tracker.

[edit] Personal material

  • The Amazon S3 "Simple Storage Service" is a scalable Internet-based storage service with a simple web service interface, equipped with built-in BitTorrent support.
  • Blog Torrent offers a simplified BitTorrent tracker to enable bloggers and non-technical users to host a tracker on their site. Blog Torrent also allows visitors to download a "stub" loader, which acts as a BitTorrent client to download the desired file, allowing users without BitTorrent software to use the protocol.[23] This is similar to the concept of a self-extracting archive.

[edit] Software

  • Blizzard Entertainment uses BitTorrent (via a proprietary client called the "Blizzard Downloader") to distribute content and patches for Diablo III, StarCraft II and World of Warcraft, including the games themselves.[24]
  • Many software games, especially those whose large size makes them difficult to host due to bandwidth limits, extremely frequent downloads, and unpredictable changes in network traffic, will distribute instead a specialized, stripped down bittorrent client with enough functionality to download the game from the other running clients and the primary server (which is maintained in case not enough peers are available).
  • Many major open source and free software projects encourage BitTorrent as well as conventional downloads of their products (via HTTP, FTP etc.) to increase availability and to reduce load on their own servers, especially when dealing with larger files.[25]

[edit] Government

  • The UK government used BitTorrent to distribute details about how the tax money of UK citizens was spent.[26][27]

[edit] Others

  • Facebook uses BitTorrent to distribute updates to Facebook servers.[28]
  • Twitter uses BitTorrent to distribute updates to Twitter servers.[29][30]
As of 2011 BitTorrent has 100 million users and a greater share of network bandwidth than Netflix and Hulu combined.[31][32][dubious ]
At any given instant of time BitTorrent has, on average, more active users than YouTube and Facebook combined. (This refers to the number of active users at any instant and not to the total number of registered users.) [33][34][dubious ]
CableLabs, the research organization of the North American cable industry, estimates that BitTorrent represents 18% of all broadband traffic.[35][dated info] In 2004, CacheLogic put that number at roughly 35% of all traffic on the Internet.[36][dated info] The discrepancies in these numbers are caused by differences in the method used to measure P2P traffic on the Internet.[37]
Routers that use network address translation (NAT) must maintain tables of source and destination IP addresses and ports. Typical home routers are limited to about 2000 table entries[citation needed] while some more expensive routers have larger table capacities. BitTorrent frequently contacts 20–30 servers per second, rapidly filling the NAT tables. This is a common cause of home routers locking up.[38]

[edit] Indexing

The BitTorrent protocol provides no way to index torrent files. As a result, a comparatively small number of websites have hosted a large majority of torrents, many linking to copyrighted material without the authorization of copyright holders, rendering those sites especially vulnerable to lawsuits.[39] Several types of websites support the discovery and distribution of data on the BitTorrent network.
Public torrent hosting sites such as The Pirate Bay allow users to search and download from their collection of torrent files. Users can typically also upload torrent files for content they wish to distribute. Often, these sites also run BitTorrent trackers for their hosted torrent files, but these two functions are not mutually dependent: a torrent file could be hosted on one site and tracked by another, unrelated site.
Private host/tracker sites operate like public ones except that they restrict access to registered users and keep track of the amount of data each user uploads and downloads, in an attempt to reduce leeching.
Search engines allow the discovery of torrent files that are hosted and tracked on other sites; examples include Mininova, BTDigg, BTJunkie, Torrentz, The Pirate Bay, Eztorrent and isoHunt. These sites allow the user to ask for content meeting specific criteria (such as containing a given word or phrase) and retrieve a list of links to torrent files matching those criteria. This list can often be sorted with respect to several criteria, relevance (seeders-leechers ratio) being one of the most popular and useful (due to the way the protocol behaves, the download bandwidth achievable is very sensitive to this value). Bram Cohen launched a BitTorrent search engine on http://www.bittorrent.com/search that co-mingles licensed content with search results.[40] Metasearch engines allow one to search several BitTorrent indices and search engines at once. DHT search engines monitors the DHT network and indexes torrents via metadata exchange from peers.

[edit] Technologies built on BitTorrent

The BitTorrent protocol is still under development and therefore may still acquire new features and other enhancements such as improved efficiency.

[edit] Distributed trackers

On May 2, 2005, Azureus 2.3.0.0 (now known as Vuze) was released,[41] introducing support for "trackerless" torrents through a system called the "distributed database." This system is a DHT implementation which allows the client to use torrents that do not have a working BitTorrent tracker. The following month, BitTorrent, Inc. released version 4.2.0 of the Mainline BitTorrent client, which supported an alternative DHT implementation (popularly known as "Mainline DHT") that is incompatible with that of Azureus. Current versions of the official BitTorrent client, µTorrent, BitComet, Transmission and BitSpirit all share compatibility with Mainline DHT. Both DHT implementations are based on Kademlia.[42] As of version 3.0.5.0, Azureus also supports Mainline DHT in addition to its own distributed database through use of an optional application plugin.[43] This potentially allows the Azureus client to reach a bigger swarm.
Another idea that has surfaced in Vuze is that of virtual torrents. This idea is based on the distributed tracker approach and is used to describe some web resource. Currently, it is used for instant messaging. It is implemented using a special messaging protocol and requires an appropriate plugin. Anatomic P2P is another approach, which uses a decentralized network of nodes that route traffic to dynamic trackers.
Most BitTorrent clients also use Peer exchange (PEX) to gather peers in addition to trackers and DHT. Peer exchange checks with known peers to see if they know of any other peers. With the 3.0.5.0 release of Vuze, all major BitTorrent clients now have compatible peer exchange.

[edit] Web seeding

Web seeding was implemented in 2006 as the ability of BitTorrent clients to download torrent pieces from an HTTP source in addition to the swarm. The advantage of this feature is that a website may distribute a torrent for a particular file or batch of files and make those files available for download from that same web server; this can simplify long-term seeding and load balancing through the use of existing, cheap, web hosting setups. In theory, this would make using BitTorrent almost as easy for a web publisher as creating a direct HTTP download. In addition, it would allow the "web seed" to be disabled if the swarm becomes too popular while still allowing the file to be readily available.
This feature has two distinct and incompatible specifications.
The first was created by John "TheSHAD0W" Hoffman, who created BitTornado.[44] From version 5.0 onward, the Mainline BitTorrent client also supports web seeds, and the BitTorrent web site had[45] a simple publishing tool that creates web seeded torrents.[46] µTorrent added support for web seeds in version 1.7. BitComet added support for web seeds in version 1.14. This first specification requires running a web service that serves content by info-hash and piece number, rather than filename.
The other specification is created by GetRight authors and can rely on a basic HTTP download space (using byte serving).[47]
In September 2010, a new service named Burnbit was launched which generates a torrent from any URL using webseeding. [48]
There exist server-side solutions that provide initial seeding of the file from the webserver via standard Bittorrent protocol and when the number of external seeders reach a limit, they stop serving the file from the original source. [49]

[edit] RSS feeds

A technique called broadcatching combines RSS with the BitTorrent protocol to create a content delivery system, further simplifying and automating content distribution. Steve Gillmor explained the concept in a column for Ziff-Davis in December, 2003.[50] The discussion spread quickly among bloggers (Ernest Miller,[51] Chris Pirillo, etc.). In an article entitled Broadcatching with BitTorrent, Scott Raymond explained:
I want RSS feeds of BitTorrent files. A script would periodically check the feed for new items, and use them to start the download. Then, I could find a trusted publisher of an Alias RSS feed, and "subscribe" to all new episodes of the show, which would then start downloading automatically — like the "season pass" feature of the TiVo.
—Scott Raymond,  scottraymond.net[52]
The RSS feed will track the content, while BitTorrent ensures content integrity with cryptographic hashing of all data, so feed subscribers will receive uncorrupted content.
One of the first and popular software clients (free and open source) for broadcatching is Miro. Other free software clients such as PenguinTV and KatchTV are also now supporting broadcatching.
The BitTorrent web-service MoveDigital had the ability to make torrents available to any web application capable of parsing XML through its standard REST-based interface,[53] although this has since been discontinued. Additionally, Torrenthut is developing a similar torrent API that will provide the same features, as well as further intuition to help bring the torrent community to Web 2.0 standards. Alongside this release is a first PHP application built using the API called PEP, which will parse any Really Simple Syndication (RSS 2.0) feed and automatically create and seed a torrent for each enclosure found in that feed.[54]

[edit] Throttling and encryption

Since BitTorrent makes up a large proportion of total traffic, some ISPs have chosen to throttle (slow down) BitTorrent transfers to ensure network capacity remains available for other uses. For this reason, methods have been developed to disguise BitTorrent traffic in an attempt to thwart these efforts.[55]
Protocol header encrypt (PHE) and Message stream encryption/Protocol encryption (MSE/PE) are features of some BitTorrent clients that attempt to make BitTorrent hard to detect and throttle. At the moment Vuze, Bitcomet, KTorrent, Transmission, Deluge, µTorrent, MooPolice, Halite, rTorrent and the latest official BitTorrent client (v6) support MSE/PE encryption.
In September 2006 it was reported that some software could detect and throttle BitTorrent traffic masquerading as HTTP traffic.[56]
Reports in August 2007 indicated that Comcast was preventing BitTorrent seeding by monitoring and interfering with the communication between peers. Protection against these efforts is provided by proxying the client-tracker traffic via an encrypted tunnel to a point outside of the Comcast network.[57] Comcast has more recently called a "truce" with BitTorrent, Inc. with the intention of shaping traffic in a protocol-agnostic manner.[58] Questions about the ethics and legality of Comcast's behavior have led to renewed debate about net neutrality in the United States.[59]
In general, although encryption can make it difficult to determine what is being shared, BitTorrent is vulnerable to traffic analysis. Thus even with MSE/PE, it may be possible for an ISP to recognize BitTorrent and also to determine that a system is no longer downloading but only uploading data, and terminate its connection by injecting TCP RST (reset flag) packets.

[edit] Multitracker

Another unofficial feature is an extension to the BitTorrent metadata format proposed by John Hoffman[60] and implemented by several indexing websites. It allows the use of multiple trackers per file, so if one tracker fails, others can continue to support file transfer. It is implemented in several clients, such as BitComet, BitTornado, BitTorrent, KTorrent, Transmission, Deluge, µTorrent, rtorrent, Vuze, Frostwire. Trackers are placed in groups, or tiers, with a tracker randomly chosen from the top tier and tried, moving to the next tier if all the trackers in the top tier fail.
Torrents with multiple trackers[61] can decrease the time it takes to download a file, but also has a few consequences:
  • Poorly implemented[62] clients may contact multiple trackers, leading to more overhead-traffic.
  • Torrents from closed trackers suddenly become downloadable by non-members, as they can connect to a seed via an open tracker.

[edit] Decentralized keyword search

Even with distributed trackers, a third party is still required to find a specific torrent. This is usually done in the form of a hyperlink from the website of the content owner or through indexing websites like isoHunt, Torrentz, BTDigg or The Pirate Bay.
The Tribler BitTorrent client is the first to incorporate decentralized search capabilities. With Tribler, users can find .torrent files that are hosted among other peers, instead of on a centralized index sites. It adds such an ability to the BitTorrent protocol using a gossip protocol, somewhat similar to the eXeem network which was shut down in 2005. The software includes the ability to recommend content as well. After a dozen downloads the Tribler software can roughly estimate the download taste of the user and recommend additional content.[63]
In May 2007 Cornell University published a paper proposing a new approach to searching a peer-to-peer network for inexact strings,[64] which could replace the functionality of a central indexing site. A year later, the same team implemented the system as a plugin for Vuze called Cubit[65] and published a follow-up paper reporting its success.[66]
A somewhat similar facility but with a slightly different approach is provided by the BitComet client through its "Torrent Exchange"[67] feature. Whenever two peers using BitComet (with Torrent Exchange enabled) connect to each other they exchange lists of all the torrents (name and info-hash) they have in the Torrent Share storage (torrent files which were previously downloaded and for which the user chose to enable sharing by Torrent Exchange).
Thus each client builds up a list of all the torrents shared by the peers it connected to in the current session (or it can even maintain the list between sessions if instructed). At any time the user can search into that Torrent Collection list for a certain torrent and sort the list by categories. When the user chooses to download a torrent from that list, the .torrent file is automatically searched for (by info-hash value) in the DHT Network and when found it is downloaded by the querying client which can after that create and initiate a downloading task.

[edit] Implementations

The BitTorrent specification is free to use and many clients are open source, so BitTorrent clients have been created for all common operating systems using a variety of programming languages. The official BitTorrent client, µTorrent, Xunlei, Vuze and BitComet are some of the most popular clients.[68]
Some BitTorrent implementations such as MLDonkey and Torrentflux are designed to run as servers. For example, this can be used to centralize file sharing on a single dedicated server which users share access to on the network.[69] Server-oriented BitTorrent implementations can also be hosted by hosting providers at co-located facilities with high bandwidth Internet connectivity (e.g., a datacenter) which can provide dramatic speed benefits over using BitTorrent from a regular home broadband connection.
Services such as ImageShack can download files on BitTorrent for the user, allowing them to download the entire file by HTTP once it is finished.
The Opera web browser supports BitTorrent,[70] as does Wyzo. BitLet allows users to download Torrents directly from their browser using a Java applet. An increasing number of hardware devices are being made to support BitTorrent. These include routers and NAS devices containing BitTorrent-capable firmware like OpenWrt.
Proprietary versions of the protocol which implement DRM, encryption, and authentication are found within managed clients such as Pando.

[edit] Development

An unimplemented (as of February 2008) unofficial feature is Similarity Enhanced Transfer (SET), a technique for improving the speed at which peer-to-peer file sharing and content distribution systems can share data. SET, proposed by researchers Pucha, Andersen, and Kaminsky, works by spotting chunks of identical data in files that are an exact or near match to the one needed and transferring these data to the client if the "exact" data are not present. Their experiments suggested that SET will help greatly with less popular files, but not as much for popular data, where many peers are already downloading it.[71] Andersen believes that this technique could be immediately used by developers with the BitTorrent file sharing system.[72]
As of December 2008, BitTorrent, Inc. is working with Oversi on new Policy Discover Protocols that query the ISP for capabilities and network architecture information. Oversi's ISP hosted NetEnhancer box is designed to "improve peer selection" by helping peers find local nodes, improving download speeds while reducing the loads into and out of the ISP's network.[73]

[edit] Legal issues

There has been much controversy over the use of BitTorrent trackers. BitTorrent metafiles themselves do not store file contents. Whether the publishers of BitTorrent metafiles violate copyrights by linking to copyrighted material without the authorization of copyright holders is controversial.
Various jurisdictions have pursued legal action against websites that host BitTorrent trackers. High-profile examples include the closing of Suprnova.org, Torrentspy, LokiTorrent, BTJunkie, Mininova and OiNK.cd. The Pirate Bay torrent website, formed by a Swedish group, is noted for the "legal" section of its website in which letters and replies on the subject of alleged copyright infringements are publicly displayed. On 31 May 2006, The Pirate Bay's servers in Sweden were raided by Swedish police on allegations by the MPAA of copyright infringement;[74] however, the tracker was up and running again three days later.

[edit] BitTorrent and malware

Several studies on BitTorrent have indicated that a large portion of files available for download via BitTorrent contain malware. In particular, one small sample[75] indicated that 18% of all executable programs available for download contained malware. Another study [76] claims that as much as 14.5% of BitTorrent downloads contain zero-day malware, and that BitTorrent was used as the distribution mechanism for 47% of all zero-day malware they have found.

[edit] See also

[edit] References

  1. ^ Schulze, Hendrik; Klaus Mochalski (2009). "Internet Study 2008/2009". Leipzig, Germany: ipoque. Retrieved 3 Oct 2011. "Peer-to-peer file sharing (P2P) still generates by far the most traffic in all monitored regions – ranging from 43 percent in Northern Africa to 70 percent in Eastern Europe."
  2. ^ Cohen, Bram (2001-07-02). "BitTorrent — a new P2P app". Yahoo eGroups. Retrieved 2007-04-15.
  3. ^ BitTorrent and µTorrent Software Surpass 150 Million User Milestone
  4. ^ fastcompany.com
  5. ^ comscore.com
  6. ^ Bram Cohen (10-Jan-2008). "The BitTorrent Protocol Specification". BitTorrent.org. Retrieved 20 November 2010.
  7. ^ Estimating Self-Sustainability in Peer-to-Peer Swarming Systems by D. Menasche, A. Rocha, E. de Souza e Silva, R. M. Leao, D. Towsley, A. Venkataramani
  8. ^ a b Urvoy-Keller (December 2006). "Rarest First and Choke Algorithms Are Enough" (PDF). imconf.net. Retrieved 2007-11-10.
  9. ^ Theory.org
  10. ^ a b Cohen, Bram (October 2002). "BitTorrent Protocol 1.0". BitTorrent.org. Retrieved 2008-10-27.
  11. ^ "Unofficial BitTorrent Protocol Specification v1.0". Retrieved 2009-10-04.
  12. ^ "Private Torrents". Bittorrent.org. Retrieved 2009-10-04.
  13. ^ "BitComet Banned From Growing Number of Private Trackers". Retrieved 2009-10-04.
  14. ^ a b Tamilmani, Karthik (2003-10-25). "Studying and enhancing the BitTorrent protocol" (DOC). Stony Brook University. Archived from the original on 2004-11-19. Retrieved 2006-05-06.
  15. ^ Unraveling BitTorrent's File Unavailability:Measurements and Analysis by Sebastian Kaune, Ruben Cuevas Rumin, Gareth Tyson, Andreas Mauthe, Ralf Steinmetz
  16. ^ Content Availability and Bundling in Swarming Systems by D. Menasche, A. Rocha, B. Li, D. Towsley, A. Venkataramani
  17. ^ The Seeder Promotion Problem: Measurements, Analysis and Solution Space by Sebastian Kaune, Gareth Tyson, Konstantin Pussep, Andreas Mauthe, Aleksandra Kovacevic and Ralf Steinmetz
  18. ^ See, for example, Why Bit Torrent at http://tasvideos.org tasvideos.org.
  19. ^ "Sub Pop page on BitTorrent.com". Retrieved 2006-12-13.
  20. ^ DGMlive.com
  21. ^ "CBC to BitTorrent Canada's Next Great Prime Minister:". CBC News. 19 March 2008. Retrieved 2008-03-19.
  22. ^ Bittorrent
  23. ^ Rustad, Roger E. (26 August 2004). "Blog Torrent and Participatory Culture". Grep Law. Retrieved 2006-05-09.
  24. ^ "Blizzard Downloader". Curse Inc.. 4 November 2010. Retrieved 2010-11-04.
  25. ^ "Complete Download Options List – BitTorrent". Retrieved 2009-05-07.
  26. ^ Combined Online Information System | data.gov.uk
  27. ^ "UK Government Uses BitTorrent to Share Public Spending Data".
  28. ^ "Facebook Uses Bittorrent And They Love It".
  29. ^ "Twitter Uses BitTorrent for Server Deployment".
  30. ^ "BitTorrent Makes Twitters Server Deployment 75 Faster".
  31. ^ fastcompany.com
  32. ^ financialpost.com
  33. ^ fastcompany.com
  34. ^ comscore.com
  35. ^ Ellis, Leslie (8 May 2006). "BitTorrent's Swarms Have a Deadly Bite On Broadband Nets". Multichannel News. Retrieved 2006-05-08.
  36. ^ Pasick, Adam (4 November 2004). "LiveWire — File-sharing network thrives beneath the radar". Yahoo! News. Retrieved 2006-05-09.
  37. ^ Sevcik, Peter (1 November 2005). "Peer-to-Peer Traffic: Another Internet Myth Is Born". Business Communication Review. Archived from the original on 2006-04-10. Retrieved 2006-05-09.
  38. ^ "uTorrent's FAQ page".
  39. ^ "PublicBT Tracker Set To Patch BitTorrent' Achilles' Heel". 12 July 2009. Retrieved 14 July 2009.
  40. ^ Worthington, David; Nate Mook (25 May 2015). "BitTorrent Creator Opens Online Search". BetaNews. Retrieved 2006-05-09.
  41. ^ "Vuze Changelog". Azureus.sourceforge.net.
  42. ^ Khashmir.Sourceforge.net
  43. ^ Azureus.sourceforge.net
  44. ^ "HTTP-Based Seeding Specification" (TXT). Retrieved 2006-05-09.
  45. ^ "The Torrent Entertainment Network has closed".
  46. ^ "Publish – BitTorrent". Archived from the original on 2007-05-26. (archived page from May 26, 2007, web.archive.org)
  47. ^ "HTTP/FTP Seeding for BitTorrent". Retrieved 2010-03-18.
  48. ^ [1]
  49. ^ [2]
  50. ^ Gillmore, Steve. BitTorrent and RSS Create Disruptive Revolution EWeek.com, 13 December 2003. Retrieved on 22 April 2007.
  51. ^ Corante.com[dead link]
  52. ^ Raymond, Scott: Broadcatching with BitTorrent. scottraymond.net: 16 December 2003.
  53. ^ "Move Digital REST API". Move Digital. Retrieved 2006-05-09. Documentation.
  54. ^ "Prodigem Enclosure Puller(pep.txt)" (TXT). Prodigem.com. Archived from the original on 2006-05-26. Retrieved 2006-05-09. via Internet Wayback Machine
  55. ^ "Encrypting Bittorrent to take out traffic shapers". Torrentfreak.com. 2006-02-05. Retrieved 2006-05-09.
  56. ^ Sales, Ben (September 2006). "ResTech solves network issues". studlife.com.
  57. ^ Comcast Throttles BitTorrent Traffic, Seeding Impossible, TorrentFreak, 17 August 2007
  58. ^ Comcast and Bittorrent Agree to Collaborate
  59. ^ Is Comcast's BitTorrent filtering violating the law?
  60. ^ "Multitracker Metadata Entry Specification" (TXT). Bittornado.com. Retrieved 2006-05-09.
  61. ^ Called MultiTorrents by indexing website myBittorrent.com
  62. ^ "P2P:Protocol:Specifications:Multitracker". wiki.depthstrike.com. Retrieved 2009-11-13.
  63. ^ DecentralizedRecommendation – tribler.org
  64. ^ "Hyperspaces for Object Clustering and Approximate Matching in Peer-to-Peer Overlays" (PDF). Cornell University. Retrieved 2008-05-26.
  65. ^ "Cubit: Approximate Matching for Peer-to-Peer Overlays". Cornell University. Retrieved 2008-05-26.
  66. ^ "Approximate Matching for Peer-to-Peer Overlays with Cubit" (PDF). Cornell University. Retrieved 2008-05-26.
  67. ^ Torrent Exchange. The torrent sharing feature of BitComet. Retrieved 2010-01-31.
  68. ^ Van Der Sar, Ernesto. "Thunder Blasts uTorrent’s Market Share Away". TorrentFreak. Archived from the original on 2011-09-15. Retrieved 2011-09-15.
  69. ^ Torrent Server combines a file server with P2P file sharing
  70. ^ Anderson, Nate (1 February 2007). "Does network neutrality mean an end to BitTorrent throttling?". Ars Technica, LLC. Retrieved 2007-02-09.
  71. ^ Himabindu Pucha, David G. Andersen, Michael Kaminsky (April 2007). "Exploiting Similarity for Multi-Source Downloads Using File Handprints". Purdue University, Carnegie Mellon University, Intel Research Pittsburgh. Retrieved 2007-04-15.
  72. ^ "Speed boost plan for file-sharing". BBC News. 12 April 2007. Retrieved 2007-04-21.
  73. ^ Arstechnica.com
  74. ^ "The Piratebay is Down: Raided by the Swedish Police". TorrentFreak. 31.05.2006. Retrieved 2007-05-20.
  75. ^ "Searching for Malware in Bit Torrent".
  76. ^ Håvard Vegge, Finn Michael Halvorsen and Rune Walsø Nergård (2009), Where Only Fools Dare to Tread: An Empirical Study on the Prevalence of Zero-day Malware, 2009 Fourth International Conference on Internet Monitoring and Protection

[edit] Further reading

[edit] External links


View page ratings
Rate this page
Trustworthy
Objective
Complete
Well-written