[GTER] Porta do Kazaa Ligth

Reinaldo Penno rpenno at nortelnetworks.com
Thu Apr 3 19:06:04 -03 2003


www.sandvine.com

> -----Original Message-----
> From: Fernando Ulisses dos Santos [mailto:fernando at araras.com.br] 
> Sent: Thursday, April 03, 2003 3:40 PM
> To: gter at eng.registro.br
> Subject: Re: [GTER] Porta do Kazaa Ligth
> 
> 
> On Thu, 2003-04-03 at 17:12, Andre Uratsuka Manoel wrote:
> 
> > 	Não se fala, normalmente, da banda da última milha, mas 
> da banda do 
> > provedor com a Internet. Se você usa, 24x7, 768kbps, então ele vai 
> > precisar, somente para você, de 768kbps a mais, pelos quais 
> ele paga. 
> > Você aumenta a média de uso e, portanto, diminui a capacidade dos 
> > provedores de fazer overprovisioning.
> 
> talvez o que precisamos então é de uma reengenharia do 
> protocolo P2P, para aproveitar melhor a banda da última milha.
> 
> quem sabe algo como um "cache", quando um cliente P2P recebe 
> um conteúdo para compartilhar ele pega esse conteúdo e envia 
> partes aleatóriamente para outros clientes com um MD5Sum, 
> assim, cada cliente P2P teria uma parte de muitos arquivos 
> que podem ser compartilhados.
> 
> quando outro usuário solicita o arquivo, recebe a lista dos 
> MD5Sum e pode fazer download de diferentes pontos, se os 
> caches forem grandes, corre o risco de ter partes do arquivo 
> no "vizinho", ele baixa as partes, compara o MD5Sum original 
> e remonta o arquivo.
> 
> seria uma forma de garantir maior disponibilidade de arquivos 
> e fazer cache desse tipo de conteúdo, aliás, isso teria tudo 
> a ver com a Internet, que só é o que é hoje por causa de cache.
> 
> nesse caso, as operadoras e provedores poderiam manter um 
> servidor cache gigantesco, seria até um diferencial.
> 
> também, para escolher quais arquivos vão para o cache, pode 
> ser feito um algorítimo baseado nas consultas, arquivos mais 
> baixados ou algo assim.
> 
> alguém a fim de escrever essa RFC ?
> 
> []'s
> Fernando Ulisses dos Santos
> Linkway Internet e Telecomunicações
> 
> 
> 
> --
> Essa mensagem foi verificada contra vírus e
> conteúdo malicioso.
> 
> --
> GTER list    http://eng.registro.br/mailman/listinfo/gter
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/gter/attachments/20030403/60d0c3b0/attachment.html>


More information about the gter mailing list