o problema
Servir um arquivo por HTTP joga todo o custo de upload na máquina que hospeda. Quanto mais gente quer o arquivo, mais caro fica para quem publicou — popularidade vira punição. A saída óbvia é fazer quem baixa também enviar, redistribuindo o custo para uma ponta onde a banda de upload frequentemente nem é medida. A ideia não era nova em 2003; o que faltava era uma implantação que funcionasse em escala.
Cohen lista três razões para isso. Primeira, o problema logístico: descobrir quem tem qual parte do arquivo e para onde mandar cada parte, sem gastar em coordenação mais do que se economiza em banda. Segunda, o churn: peers raramente ficam conectados mais que algumas horas, e muitas vezes ficam só alguns minutos. Terceira, e a mais dura, a fairness. O download total de todos os participantes é, por necessidade matemática, igual ao upload total. A alocação que deixa as pessoas satisfeitas é aquela em que a taxa de download de cada um é proporcional ao seu upload — mas na prática é difícil até impedir que a taxa de alguém caia a zero por acaso, quanto mais correlacionar as duas.
a ideia
O BitTorrent não faz alocação central de recurso nenhuma. Cada peer tenta maximizar o próprio download, e o protocolo é desenhado para que essa ganância produza o resultado coletivo desejado. O instrumento é uma versão mais elaborada do tit-for-tat do dilema do prisioneiro: você envia para quem está enviando para você, e recusa envio (“choke”) para o resto.
A justificativa é eficiência de Pareto. Se dois peers estão sendo mal reciprocados pelo upload que oferecem, eles podem começar a enviar um para o outro e ambos saem ganhando. Buscar Pareto é otimização local — pares de contrapartes verificando se melhoram juntos — e esse tipo de algoritmo tende a convergir para um ótimo global. Não há moeda, reputação persistente nem contabilidade global; só a taxa medida agora, nesta conexão.
como funciona
Publicar é pôr um arquivo estático .torrent num servidor web comum, com nome, tamanho, hashes e a url de um tracker. O tracker fala um protocolo simples sobre HTTP e devolve uma lista aleatória de peers. Ele é o único ponto de coordenação, e sua responsabilidade termina aí — as taxas que os peers reportam servem só para estatística. Alguém precisa rodar um seed, que envia ao menos uma cópia completa.
O arquivo é cortado em peças de tamanho fixo, tipicamente um quarto de megabyte, com o SHA1 de cada uma no .torrent. Um peer só anuncia que tem a peça depois de conferir o hash. Sobre o fio, as peças viram sub-peças de uns 16 kilobytes, com cerca de cinco requisições sempre em pipeline, para o TCP não ficar ocioso entre respostas.
A escolha de peças tem quatro regras. Strict priority: começou uma peça, termina as sub-peças dela antes de abrir outra. Rarest first: baixe primeiro o que menos peers seus têm. Random first piece: no início, quando não há nada a oferecer, sorteie, porque peça rara chega devagar e o que importa é ter algo para trocar. Endgame mode: no fim, peça as sub-peças que faltam a todo mundo e mande cancel conforme elas chegam.
O choking é o motor econômico. Cada peer mantém quatro slots abertos, recalcula a cada dez segundos quem ocupa esses slots — tempo suficiente para o TCP subir até a capacidade — e ordena por taxa de download atual, medida numa média móvel de 20 segundos. Um slot extra é o optimistic unchoke, rotacionado a cada três períodos, ou 30 segundos, que envia para alguém independentemente de retorno. Se um minuto passa sem receber nada de um peer, o cliente se considera snubbed e para de enviar para ele, exceto como optimistic unchoke. Terminado o download, o sinal acaba e o cliente passa a preferir os peers para quem consegue enviar mais rápido.
o que isso custou
O próprio texto pede só que o algoritmo seja “razoavelmente resistente” a quem baixa sem enviar — não imune. O tit-for-tat também não tem o que oferecer a um seed: quem já tem o arquivo não recebe nada em troca, e Cohen registra que os downloaders frequentemente param de enviar assim que terminam, e que a implementação padrão continua enviando até a janela ser fechada, o que costuma significar até o usuário voltar para a máquina. Isso é etiqueta, não protocolo.
O algoritmo de choking não faz parte do wire protocol: é política de implementação, necessária para desempenho mas trocável por qualquer cliente. Medir a taxa atual de forma útil é descrito como surpreendentemente difícil, e as constantes de dez, 20 e 30 segundos são calibragem empírica, não resultado derivado. O endgame desperdiça alguma banda em envios redundantes.
Sobra o tracker, único jeito de peers se encontrarem e gargalo declarado de escala — na época consumindo cerca de um milésimo da banda total, com estimativa de cair para um décimo de milésimo. E a evidência é operacional, não experimental: arquivos de centenas de megabytes, mais de mil downloaders simultâneos num deployment de 400 megabytes. Nada aqui demonstra comportamento algumas ordens de grandeza acima disso.
onde isso aparece hoje
Três anos depois, Rarest First and Choke Algorithms Are Enough mediu enxames reais e concluiu que essas duas heurísticas, sozinhas, dão conta — uma confirmação incomum para um paper que era, na origem, descrição de um sistema já rodando. O próprio Cohen cita Kademlia como fonte para os números de churn, e a DHT que o BitTorrent adotou depois, para dispensar o tracker, é baseada nela: o único ponto centralizado do desenho foi o primeiro a cair.
O IPFS reaproveita a mesma família de decisões — conteúdo endereçado por hash, blocos trocados entre peers, troca condicionada a reciprocidade. E o argumento estrutural, de que um sistema aberto só é robusto se o comportamento egoísta de cada participante levar ao resultado global desejado, é exatamente a forma do raciocínio que aparece cinco anos depois no Bitcoin.