Como funciona pesquisa no Kazaa?

Elohim

Power Member
Boas! :)

Estou a desenvolver um pequeno trabalho em Java (tipo o Kazaa muito simplificado), em que vários clientes partilham os ficheiros de uma pasta. As transferências dos ficheiros entre os clientes fazem-se através de ligações peer-2-peer. Cada ficheiro é identificado pelo seu CRC.
O que eu peço a quem me possa ajudar são propostas de métodos de pesquisa de ficheiros, tendo em conta que os ficheiros podem ter mais de 1 G, e pode haver um número muito elevado de clientes.
Não será boa política ter um único servidor central que conheça todos os clientes, porque pode facilmente ficar saturado. Talvez existindo um conjunto de servidores (super-nós) que se conheçam e partilhem informação. Alguém faz ideia como funciona o Kazza, por exemplo, quando efectuamos a pesquisa de um ficheiro?

Obrigado!
 
Originally posted by Elohim
Boas! :)

Estou a desenvolver um pequeno trabalho em Java (tipo o Kazaa muito simplificado), em que vários clientes partilham os ficheiros de uma pasta. As transferências dos ficheiros entre os clientes fazem-se através de ligações peer-2-peer. Cada ficheiro é identificado pelo seu CRC.
O que eu peço a quem me possa ajudar são propostas de métodos de pesquisa de ficheiros, tendo em conta que os ficheiros podem ter mais de 1 G, e pode haver um número muito elevado de clientes.
Não será boa política ter um único servidor central que conheça todos os clientes, porque pode facilmente ficar saturado. Talvez existindo um conjunto de servidores (super-nós) que se conheçam e partilhem informação. Alguém faz ideia como funciona o Kazza, por exemplo, quando efectuamos a pesquisa de um ficheiro?

Obrigado!

Eu conheço um projecto português: www.gnutellapt.cjb.net em que pegaram num software opensource e o adaptaram para Portugal... talvez lá encontres info's uteis...
 
Originally posted by Elohim
Alguém faz ideia como funciona o Kazza, por exemplo, quando efectuamos a pesquisa de um ficheiro?

É feito o broadcast do pedido a todos os clientes que tu sabes que estão ligados e perto de tu, que por sua vez reenviam para todos os outros que estão ligados a eles. Isto só pode ser feito um número MUITO limitado de vezes sob pena de muito facilmente saturares a rede... daí também se chamar o kazaa de Network Killer. Se fizeres uma pesquisa a 10 clientes com 20 hops geras 1GB de tráfego... Deu para perceber...?
 
Obrigado aos dois! :)

Já entendi, Tafinho. Agora ainda vou resolver o problema da ligação inicial, isto é, quando um cliente ainda não conhece nenhum outro cliente. Provavelmente terá que, inicialmente, ligar-se a um super-nó.
Vou estudar um documento do site dado pelo SoundSurfer que já está a ajudar muito. Parece que tem mesmo o que preciso.
Mais uma vez, obrigado SoundSurfer e Tafinho!
 
Originally posted by Elohim
o um cliente ainda não conhece nenhum outro cliente. Provavelmente terá que, inicialmente, ligar-se a um super-nó.

+-, o kazaa tem uma hierarquia de nós em que só apenas alguns nós com mais largura de banda vêm listados no super nó(mas este super nó pode ser mais que um...).
 
da tb uma olhadela a algortimos de routing , k pode ser k te ajude :P , sendo k é relativamente facil implementar variantes mais simples , e mesmo pequenas optimizacoes dependendo do algoritmo de routing escolhido


:P

Lucky_JL
 
Originally posted by Lucky_JL
da tb uma olhadela a algortimos de routing , k pode ser k te ajude :P , sendo k é relativamente facil implementar variantes mais simples , e mesmo pequenas optimizacoes dependendo do algoritmo de routing escolhido
Lucky_JL

Na minha terra só existem +- 2, dysktra e Distance Vector, com e sem reverse poisoning...
 
Acabei por decidir sobre o protocolo usado no Kazaa. Existem 2 tipos de clientes: os nós (normais) e os (super-nós) que são alguns dos clientes com maior largura de banda. Cada nó tem uma lista de possiveis super-nós (ou pede essa lista a um servidor) e liga-se a um deles. É a esse super-nó que são feitos os pedidos dos ficheiros (e respectivas actualizações). Os super-nós contêm a informação de todos os ficheiros (com respectivos atributos a serem usados nas pesquisas) de todos os clientes a si ligados (numa hash table ou duas). E cada super-nó conhece outros super-nós, aos quais também faz os pedidos dos ficheiros (mas estes pedidos não causam congestionamento, uma vez que se circulam em circuitos de banda larga, e com ttl´s - time to live - curtos).

Bom, isto foi um resumo do esquema que vou implementar. Não me vou preocupar com algoritmos de routing, uma vez que as respostas são enviadas pelo caminho inverso pelo qual chegaram os pedidos.
Agora vou começar a programar, porque tenho apenas uma semana...

Obrigado pelas ajudas! :)
 
Originally posted by Elohim
(mas estes pedidos não causam congestionamento, uma vez que se circulam em circuitos de banda larga, e com ttl´s - time to live - curtos).

Lá por serem circuitos de banda larga não quer dizer que nãu gerem um tráfego na rede completamente absurdo...
 
Originally posted by Tafinho
Lá por serem circuitos de banda larga não quer dizer que nãu gerem um tráfego na rede completamente absurdo...

Absurdo é mandar bocas para o ar sem avaliar primeiro as condições. Em primeiro lugar, os pedidos de ficheiros são mensagens pequenas. Em segundo lugar há que considerar o número de super-nós, o número de clientes ligados a cada super-nó, o número de pedidos, o estado da rede, etc... Por outro lado, com ttls com o valor 3, por exemplo, no máximo haverá 3 hops por mensagem.
Numa aula de sistemas distribuidos estivemos a considerar esta hipótese, com valores reais e verificámos que esta situação não gera tráfego significativo. Agora se o sistema que gere a promoção de super-nós dinamicamente, por exemplo, estiver mal implementada, poderão existir problemas de tráfego, mas só em condições muito especiais...
 
offtopic:

Digamos que depois de ler esta conversa percebi pq raio me inscrevo no minimo de cadeiras de redes de computadores possiveis.....bem que me chegou IRT.
 
tafinho :

nao é relativamente facil implementar o vector distance pelo menos ? mesmo com reverse poisoning ...

:P


awake :

a cadeira é obrigatoria de 4 ano , Sistemas Distribudos I :) , portanto nao ha volta a dar , e o projecto é para executar numa semana


Lucky_JL
 
Originally posted by Lucky_JL

a cadeira é obrigatoria de 4 ano , Sistemas Distribudos I :) , portanto nao ha volta a dar , e o projecto é para executar numa semana

Pois, eheh... E ainda querem que seja possivel interromper a transferência de um ficheiro para continuar mais tarde, a partir de outra localização. Uma semana daria para implementar um servidor central a atender todos os pedidos, eheh... E depois ainda há trabalhos das outras cadeiras, como inteligência artificial, métodos quantitativos, computação gráfica, etc...
Uma semana pode dar para fazer as interfaces em Java...
:P
 
Originally posted by Elohim
Absurdo é mandar bocas para o ar sem avaliar primeiro as condições. Em primeiro lugar, os pedidos de ficheiros são mensagens pequenas. Em segundo lugar há que considerar o número de super-nós, o número de clientes ligados a cada super-nó, o número de pedidos, o estado da rede, etc... Por outro lado, com ttls com o valor 3, por exemplo, no máximo haverá 3 hops por mensagem.

É sobejamente conhecido que o grande defeito do protocolo gnutella é a largura de banda abusiva que usa...

LE!!

http://www.tch.org/gnutella.html

Tento um TTL de 3, com o numero de ligacoes default do gnutella (4) consegues estar ligado a 56 outros PC's, leia-se, inutil!
Se queres alguma coisa minimamente decente, digamos 10000 outrs PC's , tens de ter TTL=5 e 7 ligacoes, o que te gera o minusculo trafego de 903,455bytes POR PESQUISA

Gostava de conhecer esse teu prof...


Lucky_JL, a última vez que viz isso demorei meia hora, mais 5 mins para meter o reverse poisoning, e outra meia hora para fazer o Dysjtra
 
Originally posted by Tafinho
É sobejamente conhecido que o grande defeito do protocolo gnutella é a largura de banda abusiva que usa...

LE!!


Caso não tenhas reparado eu estava a falar do sistema que vou implementar, que será mais parecido com o protocolo fastrack do que o do Gnutella. LÊ!

Gostava de ver os teus cálculos... Ah, e parece-me razoável um super-nó ter 1000 clientes! Isto pode ser definido pelo algoritmo que gere dinamicamente as promoções de super-nós. Se tiveres apenas 10 super-nós já tens os tais 10.000 clientes ligados...
E com 10 super-nós, mesmo que cada um só conheça 2, o ttl a 3 é mais que suficiente para fazeres o pedido à maioria dos nós...
 
Originally posted by AwakE
offtopic:

Digamos que depois de ler esta conversa percebi pq raio me inscrevo no minimo de cadeiras de redes de computadores possiveis.....bem que me chegou IRT.
No meu curso a falta dessas cadeiras era apontado por muitos o grande handicap. Hoje trabalho nessa área e posso dizer que num mundo cada vez mais ligado e onde a informação circula cada vez mais rápidamente o saber dessas áreas é uma mais valia para ti, mesmo que não venhas a exercer nada desse conhecimento, pois mais vale prevenir do que remediar :)

ONTOPIC:

A discussão estava a ser interessante de seguir enquanto se limitarem ao tópico, se começarem a flamar perde-se muito do interesse :sad:
 
Originally posted by Elohim
Caso não tenhas reparado eu estava a falar do sistema que vou implementar, que será mais parecido com o protocolo fastrack do que o do Gnutella. LÊ!

/me le o topico : Como funciona pesquisa no Kazaa?

Algo Deve ir aqui mal...

Quanto aos calculos, lê o artigo sff...

Já agora, não contes a ninguem, mas no gnutella, as pesquisas não passam pelos nós... o termo P2P não te diz nada...?
 
Última edição:
Originally posted by Tafinho
/me le o topico : Como funciona pesquisa no Kazaa?

Algo Deve ir aqui mal...

Quanto aos calculos, lê o artigo sff...

Já agora, não contes a ninguem, mas no gnutella, as pesquisas não passam pelos nós... o termo P2P não te diz nada...?

Tafinho: Já vi que és uma pessoa muito persistente e essa qualidade é importante na vida profissional! ;)
No entanto, acho que não me fiz entender, quando descrevi o projecto que estou a implementar. Este baseia-se no rotocolo usado pelo Kazza (que é o fastrack, e não o gnutella, como podes ver no artigo). No Kazza, as mensagens de pesquisa circulam entre os super-nós. A ligação P2P efectua-se apenas entre dois clientes, para a transferência do ficheiro, após os resultados de pesquisa...
Já agora, no meu trabalho a ligação entre cilente e super-nós, e entre estes, é feita por Java RMI. A transferência de ficheiros, essa sim, é P2P, usando TCP/IP. E garanto que as pesquisas apenas circulam entre super-nós, afinal, sou eu quem programa, não é?

Por falar nisso, vou trabalhar no projecto! :)
 
Back
Topo