só complementando, a 2 dias ja to com alguns torrent ligado, e já baixo 30 gb

Cristopher,

Com o speedr P2P já seriam 30GB a menos de consumo de link.

Acredito que Hds para P2P não necessitariam de performance, então qualquer HD barato de 2TB serviria. Imagina um servidor que caibam uns 6 discos, 1 para sistema e 5 de chache, só ai ja seriam 10TB de cache. Olha esse HD ai.

https://www.bugsinformatica.com.br/index.php?page=direita_detalhes&id=155

Encher 10 TB de cache a possibilidade de hit é grande, já que os arquivos não necessitariam ser nem da mesma fonte, basta ter o mesmo Hash conforme o Guilherme informou:

http://speedr.com.br/forum/view?id=3205&p=0

E mais um detalhe, se não fosse viável, então porque a GVT está fazendo.??

Fica ai minha opinião.

Sim Sim,

Mais faltou um detalhe que esqueci de completar, estava falando em um provedor médio, Onde eu atuo tem 1200 clientes, não compensa pra mim pois a demanda para determinados arquivos são pequenos, o speedr me ajuda so em hit, e youtube

Cabe uma analise de trafego de cada provedor, eu gasto 10.000 de link, consumo de P2P representa aqui mais de 40% da minha demanda, quer dizer R$ 4000 p/ mês, se o cache de P2P me economizar 20% disso já é SUPER viável.

So pra não morrem o tópico e o Pedido!!

CARAMBAAA!!!!
Acer Telecomunicações Ltda quanto de link voce tem mesmo? (ja te pedi uma vez se nao me engano x.x) Deve pagar uma FACADAA...

Correção, o linux tem a partição Swap (memória Virtual), então um HD de 500 GB e metade dele para a SWAP para deixar de teste fica interessante também.
O único problema é que se a máquina vier a travar ou desligar todos os arquivos que estiverem em memória irão se perder...
Para algo gratuito...

Alguém testou o sistema?

Acer, eu ja tinha lido ha alguns meses sobre esse sistema. Na minha humilde opniao, a abordagem deles ta errada, e a sua ideia de armazenamento temporario na SWAP tb.

Vou tentar explicar as minhas razoes, por partes:

a) O protocolo de torrent, especificamente, eh um protocolo semi-distribuido e que depende de alguns canais de comando e controle para coordenacao. Essa coordenacao eh do cliente para um tracker.

Como temos controle de toda a infra-estrutura, me parece melhor a ideia de interceptar esse vetor (comunicacao de CC cliente <-> tracker) do que tentar fazer malabarismo com TCP Splicing ou transformar as CPUs em torradeiras fazendo buffer e L7 do conteudo pra identificar o inicio de uma transferencia de dados entre dois peers bittorrent (ja em uma segunda etapa da comunicacao, quando poderiamos ter atuado na primeira etapa).

b) Em relacao a persistencia em disco, nao basta simplesmente mapear o disco como SWAP e deixar o kernel resolver.

O acesso em disco eh MUITO mais lento que o acesso em memoria, e normalmente quando a performance eh critica, pequenos blocos de metadados sao mantidos em memoria para evitar IO lenta em disco antes da certeza absoluta da necessidade de que esse acesso seja feito.

Quando seu swapspace atingir 3 ou 4 vezes o total de memoria fisica disponivel (- a memoria nao paginavel do kernel, que nao vai ser pequena se vc tiver muitas conexoes abertas, mesmo que IDLE), voce vai ter mais de 90% de CPU time sendo usado so movimentando paginas entre os discos e o pedacinho de memoria fisica que sobrou.

Imagina uma desreferencia a um ponteiro se transformar em um page fault que vai gerar um acesso a disco para movimentar uma pagina inteira de 4k. Nao vai ser uma boa :)

Ja temos bastante coisa disso pronta aqui, mas todas essas modificacoes de distribuicao de conteudo acabaram gerando centenas de horas de trabalho que nao eram esperadas, e ai nao deu tempo de concluir a coisa toda.

Agora com o aumento de equipe vamos poder ter mais tempo disponivel pra voltar a se focar nisso e em outras coisinhas, e em breve voce vera novidades bem legais.

Vlw Guilherme pela ótima explicação.
O sistema está muito bom, queria apenas que funcionasse o TPROXY comigo XD, já tentei 3 tickets e todos deram fail...