[GTER] Cache de BitTorrent

Provedor Bogus provedorbogus at gmail.com
Fri Jul 10 02:21:33 -03 2009


> É, imaginei que haveria o overhead por conta de criptografia e um ASIC com
> certeza ajudaria muito. :)


Sem ASIC, sem chance. :-(
A sorte é que esse hardware não é nada intangível e o preço só tende a cair
com o
passar do tempo.


> Interessante. Fica mais rápido porque diminui o overhead, ou porque uma vez
> que a criptografia está ligada, só é permitido fazer a conexão com outros
> peers
> que também tenham a criptografia ligada?


Fica mais rápido porque conseguimos identificar o tráfego e cacheá-lo. :-D
Normalmente os clients de Torrent permitem selecionar se exigirão
criptografia ou se
tolerarão conexões sem ela. Por padrão, o client mais popular (uTorrent) vem
com ela
desabilitada e poucos usuários se tocam em tentar habilitá-la.


> Desculpe a ignorância, mas não entendi o que você quer dizer com "mesmo
> arquivo,
> mas como torrents diferentes". A priori, se os arquivos são iguais,
> isto é, apresentam
> o mesmo hash MD5/SHA1/SHA256 eles seriam coincidentes e assim você poderia
> passar o segmento requisitado por um ou pelo outro a partir do mesmo
> arquivo
> armazenado no cache. Mas note que os arquivos tem que ser *idênticos*. Se
> mudar
> UM bit, já não são mais idênticos.


Aí é que mora o perigo. O infohash é do Torrent e não por arquivo.
Se você pegar um filme e criar um .torrent ele já terá outro infohash
diferente, mesmo tendo
sido gerado com o mesmo conteúdo do Torrent de origem.

Assim, o infohash de um Torrent do Demonoid será diferente de outro do
PirateBay,
prejudicando o hit ratio. Mas os arquivos lá dentro são iguais.


> Às vezes o defeito não é tão óbvio assim. Ou tão simples... ;)


Concordo. O problema é que observando o tráfego e o comportamento da rede,
nota-se que o
cache está funcionando perfeitamente, mas, o conteúdo é que é mesmo bem
diverso.
Um erro de código nesse caso seria muito fácil de ser encontrado.
Fora que esse problema foi exaustivamente acompanhado.



>
> > Cada torrent possui um infohash e esse é o índice usado.
>
> Este infohash, seria um hash do arquivo, como MD5/SHA1/SHA256? Se sim,
> então os arquivos são diferentes e querer buscar o segmento de um a partir
> do outro é um problema. :/


Conforme expliquei acima, sim.

Interessante saber como o perfil do consumidor e novas tecnologias
> acabam mudando
> o tráfego internet. :)


É ... e o provedor que se dane pra dar conta disso ... :-)



> Desculpe, mas este seu argumento é falho. É a mesma coisa de fazer
> pré-fetching
> do arquivo a ser cacheado: você faz o pré-fetching com o intuito de
> acelerar o
> download do arquivo, e o usuário também não sabe que seu cache está fazendo
> isso
> ou o quê está ou não no cache. Infelizmente pré-fetching do arquivo, do
> ponto de
> vista jurídico de cache P2P é ilegal, pois com isso você está
> ajudando, mesmo que
> indiretamente, o usuário a baixar conteúdo da Internet. Como eu disse,
> a linha que
> separa o que é legal do que é ilegal é muito tênue. :)


Eu também acho que pre-fetching é ilegal, porque você também está baixando
conteúdo protegido
por lei.
Porém, nesse caso, eu não baixei nada de ninguém. É uma consulta simples ao
tracker para
saber de estatísticas.


> E com certeza eu o farei, se me for permitido. :)
>

Vou estar de férias no mês que vem e infelizmente não estou conseguindo
tempo livre para
dar conta disso, mas, tentarei dar notícias em breve.

Um abraço !



More information about the gter mailing list