[GTER] Cache de BitTorrent

Provedor Bogus provedorbogus at gmail.com
Thu Jul 9 18:59:40 -03 2009


Gustavo,

Seu sonho (open source) até pode se tornar realidade.
99% de todas as máquinas da empresa são Linux. O cache foi desenvolvido
sobre Linux.
Somos **MUITO** simpáticos com a idéia de torná-lo open source.
Contudo, neste momento, precisamos amadurecer o projeto e torná-lo útil para
a
sociedade e no formato que você propõe, isso infelizmente é impossível.

Nosso objetivo não é ganhar dinheiro vendendo o cache. Como já disse nessa
lista,
nós somos um provedor de Internet. Ganhamos dinheiro vendendo acesso e
quanto
melhor ele for, mais clientes teremos e mais dinheiro ganharemos.
Esse é o nosso "core bussiness" e continuará sendo.

Nós temos 800 mbps de link de Internet e mais um tanto flutuante no PTT da
Terremark
e isso não é suficiente para que o cache seja útil. O taxa de acerto é de
apenas 6%.

Com os seus 200 mbps, calculo que você teria entre 1,5 a 2% de hit ratio.
:-(

Esse é o principal entrave para que o cache seja algo interessante pra você.

Um abraço !


2009/7/8 Gustavo Santos <gustkiller at gmail.com>

> O ideal seria se fosse disponibilizado mesmo que para venda ou mesmo
> opensource ( sonho ) .. os argumentos utilizados sobre precisar de
> participar de um ptt, ter 1gigabit de banda para poder participar me deixou
> decepcionado. acho que com os 200mbits daqui daria pra fazer uma bricadeira
> boa.
>
> 2009/7/8 Fabrício Cabral <fabriciofx at gmail.com>
>
> > 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
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list