[GTER] Cache de BitTorrent

[Provedor Bogus]

Fabrício,

    Estou comentando in-line, ok ?


>      respostas de outros interessados para formular nossa forma de
> > funcionamento.
>
> Os aspecto jurídico vai depender de como o seu cache funciona. Assim,
> você poderia explicar *detalhamente* como ele funciona?


O cache é 100% transparente e foi desenvolvido usando TPROXY. Assim, a
resposta para as requisições
são feitas usando os endereços IP dos peers que por ventura forem
fornecedores da parte do arquivo solicitada
e somente ela.

O nosso cache não funciona como o Oversi que analisa o payload das
requisições para os
trackers e baixa junto com o peer da sua rede o mesmo conteúdo para então
participar como sendo um seeder.
Acho que essa forma seria juridicamente problemática.


>
> >      Nossa máquina de produção tem exatamente essa configuração e custou
> > cerca de R$ 2.800 com placa-mãe Supermicro.
>
> Cache "normalmente" consome mais disco e ram do que CPU. Cache P2P é
> um caso a parte, se for levado em consideração de *como* você está fazendo
> o reconhecimento desse tráfego. Se for análise de payload, com certeza ele
> vai consumir muita CPU (obviamente, também depende da quantidade de
> tráfego).


O tráfego é reconhecido através de análise de payload, mas, desenvolvemos um
algoritmo que otimiza bem
essa tarefa porque fica em kernel-mode. A máquina supra-citada consegue
processar 400 mbps com 30% de carga.
Não fizemos muitos testes de estresse porque consideramos essa performance
muito razoável.
Nosso plano não é ter somente uma máquina para toda a rede e sim dividir a
carga entre duas ou três máquinas.

Há a opção de se colocar uma máquina para toda a rede e outra em hot
stand-by com Keepalived rodando
para se ter redundância.

A parte de disco fica por conta da máquina de conteúdo que tem capacidade de
processamento e
subsistema de disco apropriados para essa tarefa.


>
>
> >      O problema atual é que possuímos pouco volume de tráfego para
> popular
> > o cache e com isso o hit ratio alcançado fica em
> >      torno de 6%, sendo que o desejável é qualquer coisa acima de 35%.
>
> Não entendi direito essa dificuldade de popular o cache. Para o hit ratio
> ficar
> baixo assim, só se houverem muitos usuários de P2P baixando conteúdos
> diferentes (sempre novos) e poucos baixando conteúdos populares, o que soa
> meio estranho.


O cache de P2P difere em muito de um cache de Youtube, por exemplo.
No Youtube, muitas pessoas acessam vídeos de, em média, 8 mega. Um arquivo
pequeno.
No P2P, poucas pessoas baixam arquivos grandes, na nossa média, 1,5 giga.
Assim, o tempo para que o cache seja populado com apenas 3 arquivos é muito
maior.

1 arquivo de 1,5 giga dá pra guardar ~ 183 arquivos do Youtube.

Qual das duas situações tem mais chance de ter um hit ? :-)

A diversidade de conteúdo também é um problema, pois, dependem de buscas
individuais
dos clientes, diferente do Youtube em que vídeos são acessados por sites de
blogs conhecidos
(como o Kibeloco e o Buteco da Net) ou mesmo enviados como referência em
e-mails.
Eu nunca recebi um .torrent de alguém sugerindo que eu baixasse para dar uma
olhada. :-)

Temos cerca de 300 mbps só de tráfego Torrent e isso é insuficiente para
gerar um bom hit ratio.


> Quanto de disco o seu cache está consumindo? Qual política de replacement
> você está utilizando? Como funciona *exatamente* o seu cache?


Estamos com 5 TB ocupados e ainda estudando a política de replacement, mas,
temos muito
tempo para definí-la já que nem tão cedo os 45 TB da máquina serão ocupados.
:-)
Provavelmente ela será baseada em uma busca do INFOHASH nos sites mininova,
isohunt e
torrentz para definir a popularidade do Torrent e também a quantidade de
vezes que ele foi baixado
pelos nossos usuários. Através disso geraremos um rank que será usado para
eliminar
os arquivos de menor popularidade.

Idéias são bem-vindas. :-)