Free riding on BitTorrent

15 06 2009

I will, in this post, describe the loopholes in the BitTorrent protocol and how they are exploited by the rogue clients.

Loopholes in the BitTorrent protocol

  • Peer list during startup
    During start-up phase a new peer connects with tracker and requests for a list of peers (seeders and leechers) having the pieces of the file. The tracker generally responds with 50 peer addresses per announcement. This parameter can be increased to at most 200 in the announce request. Tracker announcements are repeated at an interval received in the first announce response, usually in the order of once every 1800 seconds. However downloaders may rerequest on nonscheduled times if an event happens or they need more peers.
  • No upload to seeders
    Peers that provide a complete file are called seeders, and the peer providing the initial copy is called the initial seeder. So the peer having connection with seed does not have to upload any data to the seed. Seeders upload to all peers in the round-robin fashion.
  • Optimistic Unchoke
    The purpose of optimistic unchoking policy is to allow newly joined peers without any pieces of torrent to bootstrap to the swarm. Which peer is optimistically unchoked rotates every 30 seconds. Newly connected peers are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation. This gives them a decent chance of getting a complete piece to upload.

How rogue clients work?

BitTorrent Protocol vs Rogue Clients

  • Downloading only from seeds
    A selfish client, upon connecting, repeatedly asks for new lists. Since most trackers perform some form of load balancing, after a short period of time, such a client has the information for most of the seeds in the torrent. The selfish client then only connects and downloads pieces from the seeds and ignores the leechers. Since seeds are typically high-bandwidth clients, the selfish client are able to sustain high download rates without any uploads.
  • BitThief
    BitThief re-announces itself frequently during the startup period to the tracker in order to get as many remote peer addresses as quickly as possible. BitThief also sends an empty list of available pieces during connection setup and it does not inform the remote peer about any new pieces it acquires. So the BitThief client has a big list of different seeders and leechers for the torrent. The default BitTorrent client has 4 open connections (i.e. it is connected with at most 4 peers at a time). However the BitThief opens a large number of connections.

    Having more connections increases the number of seeders in the swarm, so the client benefits from their round robin unchoking periods. BitThief never uploads to the leechers and is regularly snubbed by them. The leechers in the swarm would also include BitThief in their periodical optimistic unchoke slot.

  • Pretending to upload
    Since, many times, torrent files are of pure quality or are fake, a lot of sharing communities have emerged. Sharing communities require their users to upload at least as much data as they download, i.e., to keep their sharing ratio above 1. The community sites make use of the tracker announcements which every client performs regularly. In these announcements the client reports the current amount of data downloaded and uploaded. However, the client can announce bogus information and fake peers so that the tracker’s peer list fills up with dozens of clients which do not exist.
  • Advertising false pieces
    A selfish peer when asked for a sub-piece can send garbage data. The receiving leecher is able to verify the SHA1 hash only after receiving all sub-pieces of a piece.

    When selecting which piece to start downloading next, peers generally download pieces which the fewest of their own peers have, referred to as rarest first. A client can announce it has rare pieces, so more peers try to connect with it, they get garbage values while the rogue client will have a piece of the file.

Next post will list the enhancements used by some clients to overcome the free-riding behavior and propose a method to limit the peer list a client has.

Advertisement

Actions

Information

2 responses

16 06 2009
Making selfish BitTorrent clients history « Experiences with CompSci

[...] selfish BitTorrent clients history 16 06 2009 It is evident from the study of different exploits that we need to keep a check on the number of peers that we send to a newly connected [...]

6 02 2010
Abhishek

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s




Follow

Get every new post delivered to your Inbox.