Sim, na verdade, esse é o comportamento padrão da maioria dos clientes bittorrent. O termo mais usado para esse comportamento é "justiça", a maioria dos clientes não permite que você o ligue e desligue.
Eu não estou muito familiarizado com o BitTorrent em um nível de protocolo / tecnológico.
É possível para os clientes preferirem a propagação (dar mais largura de banda, ou apenas conectar-se a todos) aos leechers que estão também semeando as partes que baixaram? (Por exemplo, como uma maneira de recompensar ou fornecer apenas àqueles que também estão compartilhando, não apenas fazendo o leeching.) Ou o protocolo torna impossível conhecer a atividade de semeadura de outro usuário (um leecher).
Eu pergunto porque às vezes parece que eu recebo taxas de download muito mais rápidas quando eu removo meu limite de upload e distribuo liberalmente - existe uma explicação alternativa para o fenômeno? - Estou imaginando coisas?
Estou aceitando a resposta de @ScottChamberlain ao procurar o termo "justiça" que me levou a outro conjunto de termos, "asfixia" e "descontrole", o que me levou a uma resposta definitiva em a Especificação do Protocolo BitTorrent (Cohen, Bram. 20 de outubro de 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.
Como os novos leechers podem baixar, já que não têm partes para upload? Desarqueamento otimizado:
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.
Eu encontrei outro documento intitulado Protocolo BitTorrent versão 1.0 (Fonseca, J Reza, B. e Fjeldsted, L. April 2005.) que descreve esse aspecto do protocolo (embora baseado em uma versão mais antiga do protocolo) em maior detalhe.
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.
Este documento sugere strongmente que versões anteriores do protocolo não especificam explicitamente esquemas de "equidade" - apenas "diretrizes" (referidas acima como "Seção 6.1"), que incluem:
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.
Até onde eu sei, não é possível para uma semente saber quem está compartilhando o que baixou, então as sementes normalmente são enviadas para leechers aleatórios.
No entanto, quando escolhem para quem enviar as partes que já possuem, outros leechers dão preferência àqueles que lhes deram mais, por isso, remover seu limite de upload provavelmente o classificará mais alto na lista de prioridades de outros leechers, aumentando sua velocidade de download .