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.