Free Riding in Bittorrent Is Cheap

Free Riding in BitTorrent is Cheap Thomas Locher1, Patrick Moor2, Stefan Schmid1, Roger Wattenhofer1 1 Computer Engineering and Networks Laboratory (TIK), ETH Zurich, 8092 Zurich, Switzerland {lochert, schmiste, wattenhofer}@tik.ee.ethz.ch 2 Google Inc., Mountain View, CA 94043, USA [email protected] ABSTRACT while seeders (“altruistic peers”) clearly offer the oppor- tunity to freeload, we are even able to download content While it is well-known that BitTorrent is vulnerable to self- quickly if we ignore seeders and download solely from ish behavior, this paper demonstrates that even entire files other peers that do not possess all pieces of the desired can be downloaded without reciprocating at all in BitTor- content (leechers). This implies that the basic piece ex- rent. To this end, we present BitThief, a free riding client change mechanism does not effectively restrain peers from that never contributes any real data. First, we show that freeloading. simple tricks suffice in order to achieve high download Sharing communities are also investigated in this paper. rates, even in the absence of seeders. We also illustrate By banning users with constantly low sharing ratios or by how peers in a swarm react to various sophisticated at- denying them access to the newest torrents available, such tacks. Moreover, our analysis reveals that sharing com- communities encourage users to upload more than they munities—communities originally intended to offer down- download, i.e., to keep their sharing ratio above 1. We will loads of good quality and to promote cooperation among show that sharing communities are particularly appealing peers—provide many incentives to cheat. for free riders, and that cheating is easy. We believe that the possibility to freeload which does 1 INTRODUCTION not come at the cost of a considerably reduced quality of service (e.g., download rate) is attractive for users: Not As pure peer-to-peer (p2p) systems are completely decen- only because wasting more expensive upload bandwidth is tralized and resources are shared directly between partic- avoided, but also because—in contrast to downloading— free ipating peers, all p2p systems potentially suffer from merely the distribution of copyrighted media content such riders , i.e. peers that eagerly consume resources without as music or video shared in p2p networks is unlawful in reciprocating in any way. Not only do free riders diminish certain countries. the quality of service for other peers, but they also threaten However, as more and more users decide to free ride, the existence of the entire system. the usefulness of a p2p system will naturally decline. Thus, For that reason, it is crucial for any system without cen- spreading such freeloading clients might prove to be an tralized control to incorporate a rigorous incentive mecha- effective attack for corporations fighting the uncontrolled nism that renders freeloading evidently unattractive to self- distribution of their copyrighted material. ish peers. Unfortunately, however, many solutions so far ei- ther could easily be fooled or were unrealistically complex. 2 BITTORRENT Bram Cohen’s BitTorrent protocol heralded a paradigm shift as it demonstrated that cooperation can be fostered The main mechanisms applied by BitTorrent are described among peers interested in the same file, and that concen- in [4]; for additional resources including a detailed tech- trating on one file is often enough in practice. The fair shar- nical protocol, the reader is referred to www.bittorrent.org. ing mechanism of BitTorrent is widely believed to strongly Basically, BitTorrent is a p2p application for sharing files or discourage freeloading behavior. collections of files. In order to participate in a torrent download, a peer has to obtain a torrent metafile which con- Contrary to such belief, we show that BitTorrent in fact tains information about the content of the torrent, e.g. file does not provide sufficient incentives to rule out free rid- names, size, tracker addresses, etc. A tracker is a central- ing. The large degree of cooperation observed in BitTorrent ized entity that keeps track of all the peers (TCP endpoints) swarms is mainly due to the widespread use of obedient 2 clients which willingly serve all requests from other peers. that are downloading in a specific torrent swarm. Peers obtain contact information of other participating peers by We have developed our own BitTorrent client BitThief 1 that announcing themselves to the tracker on a regular basis. never serves any content to other peers. With the aid of this The data to be shared is divided into pieces whose size client, we demonstrate that a peer can download content is specified in the metafile (usually a couple of thousand fast without uploading any data. Surprisingly, BitThief al- pieces per torrent). A hash of each piece is also stored in the ways achieves a high download rate, and in some experi- metafile, so that the downloaded data can be verified piece ments has even outperformed the official client. Moreover, 2Recently, a distributed tracker protocol has been proposed. It is im- 1Available at http://dcg.ethz.ch/projects/bitthief/. plemented by most modern clients. 1 HotNetsV Session 5: Anti/Social 85 600 by piece. Peers participating in a torrent download are sub- BitThief divided into seeders which have already downloaded the Official Client whole file and which (altruistically) provide other peers 500 with any piece they request, and leechers which are still 400 in progress of downloading the torrent. While seeders upload to all peers (in a round robin fashion), leechers upload 300 only to those peers from which they also get some pieces in Connections return. The peer selection for uploading is done by unchok- 200 ing a fixed number of peers every ten seconds and thus en- abling them to send requests. If a peer does not contribute 100 for a while it is choked again and another peer is unchoked 0 instead. 0 2 4 6 8 10 12 14 16 18 The purpose of this mechanism is to enforce contribu- Time (minutes) tions of all peers. However, each leecher periodically un- Figure 1: Number of open connections over time. In comparison to the chokes a neighboring leecher, transferring some data to official client, BitThief opens connections much faster. this neighboring peer for free (called optimistic unchoking in BitTorrent lingo). This is done in order to allow newly Having a large number of open connections improves joined peers without any pieces of the torrent to bootstrap. the download rate twofold: First, connecting to more seed- Clearly, this unchoking mechanism is one weakness that ers allows our client to benefit more often from their round can be exploited by BitThief. robin unchoking periods. Second, there will be more leechers in our neighborhood that include BitThief in their peri- 3 BITTHIEF:AFREE RIDING CLIENT odical optimistic unchoke slot. Opening more connections increases download speed linearly, as remote peers act in- In this section we provide evidence that, with some simple dependently of the number of our open connections. How- tricks, uploading can be avoided in BitTorrent while main- ever, note that opening two connections to the same peer taining a high download rate. In particular, our own client does not help, as the official client, Azureus, and presum- BitThief is described and evaluated. BitThief is written in 3 ably all other clients as well immediately close a second Java and is based on the official implementation (writ- connection originating from the same IP address. ten in Python, also referred to as official client or main- 4 Our experiments with BitThief demonstrate that the line client), and the Azureus implementation. We kept the common belief that the performance will degrade if a large implementation as simple as possible and added a lot of in- number of TCP connections is maintained simultaneously strumentational code to analyze our client’s performance. is unfounded. On the contrary, more connections always BitThief does not perform any chokes or unchokes of re- help to increase the download rate when using BitThief. mote peers, and it never announces any pieces. In other The reason why the total number of TCP connections is words, a remote peer always assumes that it interacts with kept small in BitTorrent might be that a moderate number a newly arrived peer that has just started downloading. of connections suffice to saturate the average user’s band- Compared to the official client, BitThief is more aggres- width when following the real protocol, and no further gain sive during the startup period, as it re-announces itself to could be achieved by connecting to more peers. the tracker in order to get many remote peer addresses as In contrast to other BitTorrent clients, BitThief does not quickly as possible. The tracker typically responds with 50 apply the so-called rarest-first policy, but uses a simpler peer addresses per announcement. This parameter can be piece selection algorithm instead: We fetch whatever we increased to at most 200 in the announce request, but most can get. If our client is unchoked by a remote peer, it picks a trackers will trim the list to a limit of 50. Tracker announce- random missing piece. Our algorithm ensures that we never ments are repeated at an interval received in the first an- leave an unchoke period unused. Furthermore, just like all nounce response, usually in the order of once every 1800 other BitTorrent clients, we strive to complete the pieces seconds. Our client ignores this number and queries the we downloaded partially as soon as possible in order to tracker more frequently, starting with a configurable inter- check them against the hash from the metafile and write val and then exponentially backing off to once every half an them to the harddisk immediately.

Load more