[GTER] Cache de BitTorrent

[Fabrício Cabral]

Olá! Vou responder in-line, ok?

> Pelo que verificamos, o tráfego criptografado é pequeno e ainda não vale a
> pena investir em descriptografá-lo,
> mas, há um hardware de custo mediano (US$ 560) que pode ajudar com essa
> operação se no futuro isso valer a pena.
> Por enquanto, o investimento ainda não compensaria.

Não acho que dê pra descriptografá-lo. Talvez um Man-In-The-Middle seja a
solução.


> Aliás, nenhum cache comercial (Oversi e PeerApp) lida com tráfego
> criptografado.

A abordagem de alguns, pelo que eu pude ver, é fazer com que o usuário
ache bom usar o cache. Para isso, alguns disponibilizaram plugins para
que os aplicativos P2P procurasse o cache e o utilizassem. Acredito que
dessa maneira, eles optem por não usar criptografia.


> Esse throughput foi alcançado baixando algo do próprio cache e não da
> Internet.

Ah, ok. :)


> O cache todo funciona por partes, assim, ele estando de posse de uma
> determinada parte, esta já
> pode ser enviada para outras requisições.

Ah, ótimo. :)


> Exatamente. O que eu quis dizer é que sites de blogs conhecidos são muito
> acessados
> pelos usuários e consequentemente incrementam o hit ratio. O que não
> acontece com P2P.

Sinceramente, eu ainda acho que tem alguma coisa errada. Não é possível.
Quer dizer que aquele filme quentíssimo, que está pipocando no PirateBay
e no Mininova (altos seeders e leechers) tem pouca gente baixando? Só consigo
imaginar quatro hipóteses:

1. O perfil dos seus usuários não é de baixar arquivos via P2P;

2. Alta variabilidade dos requests dos seus usuários. E aí a pergunta
é por que isso ocorre;

3. Tem alguma coisa errada com o seu cache;

4. Eu estou completamente perdido. :D


> A diversidade de conteúdo do P2P é muito grande e popular o cache leva muito
> tempo.
> Diferente de uma página Web.
> O usuário faz uma busca num indexador de Torrent e pode escolher qual das
> várias opções
> ele decidirá baixar.

Como você faz para dar o "matching" entre o arquivo que está no caching e o
que o usuário procura?


> Não achamos como comparar o "cacheability" destes dois tipos de tráfego.

E nem acho que dê. Workloads diferentes, protocolos diferentes, utilização
diferente. Se você achar um jeito de comparar isso ae, pode botar no papel
que isso ae dá um paper fácil, fácil. :)

> Fizemos alguns "trials" com outros caches e esse número só se estabilizou em
> 13 TB.

Bom, o paper que eu vi isso é um pouco antigo. Não sei se mudou muita coisa.
Além do mais, uma coisa é um paper, outra é o mundo real. Normalmente, as
coisas não casam bem entre esses 2 mundos... :D


> Mas, não consideramos que disco seja um problema. A política de replacement
> é mais para
> não sobrecarregar o filesystem da máquina com Torrents "velhos".
> Espero vê-la funcionando bem pouco. :-)

Bom, pra mim disco é custo. Se você vai partir para uma solução comercial,
diminuir os seus custos não seria nada mal, não é? ;)


> Se eles sairem do ar, existirão outros indexadores que poderão ser usados da
> mesma forma
> e podemos alterar o código rapidamente se mudarem a página. O cache
> replacement não é
> uma tarefa tão crítica que não possa falhar por cerca de 3 horas.
> Além do mais, serão consultados vários indexadores. Se um falhar, ainda
> haverá a resposta dos
> outros.
> Há a opção de mapear os infohash com as requisições de trackers, o que
> eliminaria a necessidade
> dos indexadores.

Bom, aí já são outros 500. :)


> Não vejo como uma consulta a sites de indexação de Torrent possa configurar
> um problema jurídico. Quem faz essa tarefa é a máquina de conteúdo que nesse
> caso se
> comportaria como um simples cliente do tracker, apenas para consulta da
> popularidade do
> arquivo, tal qual fazem as empresas de monitoramento de copyright. Nenhuma
> parte do arquivo
> será baixada.

A questão é: o fato do cache fazer uma consulta externa da
popularidade do arquivo
ajuda em algum sentido o usuário a baixar conteúdo? Você pode achar que não,
e uns 200 advogados podem argumentar que sim. Quem está certo? Eu prefiro
não arriscar. Veja que utilizar um algoritmo de replacement não cai
nessa questão,
pois ele atuaria sobre os dados em si.


> Recebi alguns e-mails de pessoas que "duvidam" que tal solução tenha sido
> desenvolvido
> por uma empresa tupiniquim (fato que nos orgulhamos) então, em duas ou três
> semanas vou
> tentar disponibilizar uma máquina com VNC para demonstrações.

Não vejo nada de impossível nisso. E acredito piamente que muitos brasileiros
duvidam da sua própria capacidade. :)

No mais, você e sua empresa estão de parabéns. E quando o VNC estiver liberado,
avise aqui na lista do GTER. Eu mesmo estou doido pra ver isso funcionando... :)

[]'s

-- 
--fx