Bittorrent não é completamente "hubless" - não para a transferência de dados, mas para a descoberta de pares. Inicialmente, os torrents só poderiam depender de um hub central chamado tracker - mais uma vez, não para trocar partes do arquivo, mas para descobrir quem mais está no swarm. (Acredito que você pode especificar vários rastreadores em um protocolo para redundância.) Com a introdução do DHT, um par Bittorrent pode usar o DHT para procurar outros pares, além disso, ou em vez de usar um rastreador. O próprio DHT depende da presciência de alguns "nós" de DHT bem conhecidos (inseguro quanto à terminologia exata) para "fazer bootstrap" de um par que não tenha consultado via DHT, nem por um tempo.
Um cliente é livre para fazer uma conexão com cada par que ele conhece, simultaneamente, e geralmente faz - com a exceção de considerar qualquer configuração de "limite de conexão" que o programa suporta.
De a especificação oficial do Bittorrent :
Connections contain two bits of state on either end: choked or not, and interested or not. Choking is a notification that no data will be sent until unchoking happens. The reasoning and common techniques behind choking are explained later in this document.
Data transfer takes place whenever one side is interested and the other side is not choking. Interest state must be kept up to date at all times - whenever a downloader doesn't have something they currently would ask a peer for in unchoked, they must express lack of interest, despite being choked. Implementing this properly is tricky, but makes it possible for downloaders to know which peers will start downloading immediately if unchoked.
Connections start out choked and not interested.
When data is being transferred, downloaders should keep several piece requests queued up at once in order to get good TCP performance (this is called 'pipelining'.) On the other side, requests which can't be written out to the TCP buffer immediately should be queued up in memory rather than kept in an application-level network buffer, so they can all be thrown out when a choke happens.
Então, para você obter dados de um par, o par deve estar "interessado" e você deve estar "sem ser bloqueado" - de acordo com o protocolo. Mais adiante:
Assim, a maioria dos pares de Bittorrent implementam algoritmos de "sufocação" que garantem que as coisas funcionem de forma justa, mas dão a novas conexões tratamento preferencial para dar a elas uma chance de serem uma boa parte do enxame. Um par poderia tentar ter um algoritmo diferente que é mais injusto, mas sem a cooperação imediata de todos os outros pares, o par "ruim" seria "sufocado" até não receber dados de ninguém.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. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one.
There are several criteria a good choking algorithm should meet. It should cap the number of simultaneous uploads for good TCP performance. It should avoid choking and unchoking quickly, known as 'fibrillation'. It should reciprocate to peers who let it download. Finally, it should try out unused connections once in a while to find out if they might be better than the currently used ones, known as optimistic unchoking.
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.
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.
Mais pares = mais velocidade e pares mais rápidos são preferidos. A capacidade de upload de um par, qualquer limite de download que você tenha definido e sua capacidade de upload / download de link físico também afetam a velocidade.
Eu (e outros) detalhamos mais detalhadamente como o Bittorrent funciona nesta questão .