Is it possible for a BitTorrent client to give seeding preferences only to leechers who are also seeding?

I'm accepting @ScottChamberlain's answer as searching the term "fairness" led me to another set of terms, "choking" and "unchoking," which in turn led me to a definitive answer in the BitTorrent Protocol Specification (Cohen, Bram. October 20, 2012.)

Choking is done for several reasons. TCP congestion control behaves very poorly when sending over many connections at once. Also, choking lets each peer use a tit-for-tat-ish algorithm to ensure that they get a consistent download rate.

The choking algorithm described below is the currently deployed one. [...]

The currently deployed choking algorithm avoids fibrillation by only changing who's choked once every ten seconds. It does reciprocation and number of uploads capping by unchoking the four peers which it has the best download rates from and are interested. Peers which have a better upload rate but aren't interested get unchoked and if they become interested the worst uploader gets choked. If a downloader has a complete file, it uses its upload rate rather than its download rate to decide who to unchoke.

How do new leechers get to download, then, since they have no pieces to upload? Optimistic unchoking:

For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of its upload rate (if interested, it counts as one of the four allowed downloaders.) Which peer is optimistically unchoked rotates every 30 seconds. To give them a decent chance of getting a complete piece to upload, new connections are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation.

I found another document titled BitTorrent Protocol version 1.0 (Fonseca, J., Reza, B., and Fjeldsted, L. April 2005.) that describes this aspect of the protocol (though based on an older version of the protocol) in greater detail.

This section describes the choking algorithm recommended for selecting neighboring peers with whom to exchange pieces. Implementations are free to implement any strategy as long as the guidelines in Section 6.1 are observed.

[...]

All connections are periodically rated in terms of their ability to provide the client with a better download rate. The rating may take into account factors such as the remote peers willingness to maintain an unchoked connection with the client over a certain period of time, the remote peers upload rate to the client and other implementation defined criteria.

[...]

The only lacking element from the above algorithm is the capability to ensure that new peers can have a fair chance of downloading a piece, even though they would evaluate poorly in the above schema. A simple method is to make sure that a random peer is selected periodically regardless of how it evaluates. Since this process is repeated in a round robin manner, it ensures that ultimately even new peers will have a chance of being unchoked.

This document strongly suggests that earlier versions of the protocol did not explicitly specify "fairness" schemes—only "guidelines" (referred to above as "Section 6.1"), which include:

The algorithm should not be constructed with the goal in mind to reduce the amount of data uploaded compared to downloaded. At the very least a peer should upload the same amount that it has downloaded.

The algorithm should not use a strict tit-for-tat schema when dealing with remote peers that have just joined the swarm and thus have no pieces to offer.


As far as I know, it's not possible for a seeder to know who is sharing, what they have downloaded, so seeds normally upload to random leechers.

However, when choosing who to upload, what parts they already have, other leechers give preference to those who have given them the most, so removing your upload cap will probably rank you higher in other leechers' priority list, thus increasing your download speed.


Yes, in fact that is the default behavior most bittorrent clients. The term that is most often used for this behavior is "fairness", most clients don't let you turn it on and off.