Making selfish BitTorrent clients history

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 client.

The tracker has a list of all the peers for the torrent. A new field for timestamp is to be added for each peer. The following steps should be followed when a client connects (with its unique IP and port address) to the tracker:

• check if it is in the connected peers list
• if not or if the time when it last contacted the tracker exceeds 1800 seconds (1800 is selected since it is the average time of scheduled exchange of messages between tracker and the peer), then send it the list of peers
• add/update to the list of peers in the trackers, the timestamp describing when it established the connection with the tracker

The client can then only contact the tracker after a specified time of 1800 seconds to give information about its status and a new list of peers. This will help in removing peers which have moved out of the network. But genuine clients might have to restart the download or the peers in their list might have died.

When a client connects again within the 1800 seconds period:

• the clients will have to provide the original list of peers given to them
• tracker will verify the list and give a new set of replacement only for the peers in the list which have died out

So the repeated query for a list of peer sets will not yield new peers. Hence the methods which are dependent on having large peer set will be useless. There would not be any significant overhead in the network as even if the client sends the list of peers it has, it will only get a small set of peers which have died out in return. Otherwise it would have got a new random list of all the peers.

The tracker has to do some additional work in checking the timestamps and died out peers in the list sent by newly connected clients. However at present the capabilities of the tracker are underutilized, so a small overhead should not be a problem.

Different BitTorrent Clients

Some other clients also apply enhancements to overcome the free-riding behavior as described below:

• Azureus client stores the information from which it has received the subpieces and immediately bans the IP address once the hash verification fails. Only a recent subset of history is necessary to determine the trustworthiness of a given peer.
• The trackers of the sharing communities should verify the upload numbers sent by the peers. For instance, the sum of all reported download and upload amounts could be analyzed over different torrents and time periods, in order to detect and ban dishonest peers.
• Many clients now implement super-seeding. Rather than claiming to have every piece from the outset, the seeder claims to have no pieces. As peers connect, the seed will inform a peer that it has received a new piece, one that has not yet been sent to any other peers. Thus allowing nodes to hide their properties does not allow selfish peers to detect the seeds.

The BitTorrent protocol is based on the obedience of clients. This appears unrealistic as more users will employ free riding clients because of their reluctance to upload. The users should realize that they need to contribute their resources in order to improve the download rates. On the other hand, in many countries, it is illegal to upload but okay to download, maybe these rogue clients can come to their rescue.

Free riding on BitTorrent

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?

• 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.