|
| Universidade
Federal do Rio de Janeiro
Departamento de Engenharia Eletrônica e de Computação
Disciplina: Redes de Computadores I
Professor: Otto Carlos M. B. Duarte
Aluno: Gabriel Barros Durante
|
|
Este trabalho contém
diversas seções a respeito de várias áreas da tecnologia e arquitetura
Peer-to-Peer (P2P). A rede peer-to- peer (P2P) difere da rede cliente/servidor convencional
porque seus métodos envolvem sistemas servindo outros sistemas. Em redes P2P cada
estação possui as mesmas capacidades e responsabilidades.
Com o aparecimento
do Napster foi dada maior atenção à tecnologia P2P e com isso um
grande número de redes foi surgindo. Logo, diversos estudos relacionados às redes P2P
como, arquiteturas de rede, mecanismos de procura, roteamento e segurança entre vário
outros também apareceram. Este trabalho tem o objetivo de comentar as principais tecnologias
a respeito das redes P2P, assim como suas principais ferramentas. |
|
As redes Peer-to-Peer
(P2P) atraem muita atenção da comunidade de Rede de
computadores, apesar de haver uma discordância à respeito do seu significado. A tecnologia
P2P promete alterar o futuro das redes, porém seu conceito já existe há muitos anos.
Cresce
também as questões de interesse cultural, como no caso do Napster, apesar das políticas
de
livre arquitetura de rede. Aparentemente esses paradoxos apenas acrescentam mais misticismo
que ronda o assunto P2P.
“Um tipo de
rede de computadores onde cada estação possui capacidades e
responsabilidades equivalentes. Isto difere da arquitetura cliente/servidor, no qual alguns
computadores são dedicados a servirem dados a outros”.
Esta definição
captura o significado tradicional da rede Peer-to- Peer. Computadores de um
determinado grupo, ou computadores domésticos, são configurados para compartilhar
recursos como arquivos e impressoras, Embora um computador possa atuar como servidor de
arquivos ou de impressora a qualquer momento, todos os computadores da rede geralmente
podem realizar essas funções por um curto período. Em particular, os computadores poderão
estar situados fisicamente à uma distância curta uns dos outros e poderão protocolos
de rede.
Uma boa proposta
técnica para P2P tem sido feita por Dave Winer da UserLand Software.
Dave sugeriu que os sistemas P2P envolvam essas sete características chave:
|
|
A história
das redes P2P não pode ser contada sem mencionarmos o Napster. O Napster se
tornou o mais popular sistema P2P quase que da noite para o dia.
Tudo começou
em 1999 quando o estudante de 18 anos, Shawn Fanning, deixou a faculdade
no primeiro semestre para se dedicar ao Napster. O Napster se tornou o software de
crescimento mais rápido de toda a história da Internet.
A idéia que
fez com que o Napster se tornasse esse fenômeno foi o fato de que fornecer P2P
gratuitamente a todos. Bastava baixar o software pela Internet, instalar e procurar por uma
música para obtê-la gratuitamente. No entanto o rápido crescimento do Napster se tornou
uma
grande preocupação para as empresas Fonográficas ao redor do mundo, e em 13 de abril
de
2000, logo após o lançamento de seu último álbum a banda Metallica abre um processo
contra
o Napster por ter infringido a lei de direitos autorais. Após uma longa batalha judicial as partes
chegam a um acordo em 25de setembro de 2001. O Napster deverá para 26 milhões de
dólares para autores e gravadoras, além de uma porcentagem de tudo o que o sistema
arrecadar até o início de 2003.
Desde o aparecimento
do Napster, muitos outros sistemas P2P surgiram como Gnutela,
KaZaa e WinMP e o mundo do P2P passou a ser muito mais do que a troca de músicas no
formato MP3. |
|
O número de
usuários de tecnologia P2P tem crescido exponencialmente desde o surgimento
do Napster. O vazio deixado pelo Napster foi preenchido por diversas companhias/aplicativos
como KaZaa e o Gnutela. Tem se verificado que o tráfego referente a estes dois aplicativos
tem sido da ordem de 40% a 60% de todo o tráfego da Internet. Diferentemente das técnicas
centralizadas do Napster, os novos aplicativos tem adotado um abordagem descentralizada,
fazendo com que o controle à esses sistemas seja muito mais difícil.
Ao longo desses
anos tem se verificado que diversas companhias tradicionais de grande porte
têm tentado aproveitar o grande potencial da tecnologia P2P. Dois grandes exemplos são a
Deloitte Touche Tomatsu e a Intel. Central de Banco de Dados não é mais necessária quando
se usa P2P. Isso significa que a escalabilidade se torna mais barata e muito mais rápida. A Intel
utiliza redes P2P desde 1992 privando-se então da utilização de grandes servidores. Bancos
de dados tradicionais ainda são largamente utilizados, porém cada vez mais empresas tomam
Intel como exemplo e logo todos os bancos de dados tradicionais serão substituídos por redes
P2P.
Uma grande virada
no desenvolvimento de redes P2P aconteceu quando recentemente a
Microsoft anunciou o investimento de 51 milhões de dólares numa companhia chamada
Groove Networks. Quem está a frente desta empresas é Ray Ozzie, o inventor do Lotus Note.
A Groove Networks está implementando uma técnica híbrida no seu desenvolvimento de P2P.
Isto significa que a empresa utilizará tanto técnicas de descentralização quanto
de centralização
esperando pegar o melhor dos dois mundos.
O desenvolvimento
de tecnologias P2P tem sido impedido por várias questões legais. Os
softwares como KaZaa tem aprendido com o exemplo do Napster a ter maiores proteções
legais. Eles argumentam que não são responsáveis por nenhuma atividade ilegal que seja
realizada por meio do aplicativo. Existem muitos argumentos legais que atribuídos ao uso de
redes P2P e isto pode garantir o seu futuro. Porém existe o problema da troca ilegal de
arquivos de multimídia. Até o momento não existe solução para o problema, mas
as pesquisas
avançam nesta direção.
Como muitos estão
expostos ao risco, as empresas Fonográficas estão atualmente procurando
um meio de impedir que as pessoas utilizem o aplicativos de trocas ilegais de arquivos. A
natureza destes sistemas permite que as gravadoras possam atacar de dentro. Criando seus
próprios pseudo- usuários que compartilham arquivos corrompidos ou com nomes que
confundam os outros usuário, ou sobrecarregando as redes com
suas próprias consultas. No
entanto a legalidade dessas ações está sendo questionada. É sugerido que os usuários
sejam
processados aleatoriamente, ou então que sejam identificados os usuários mais pesados, os
chamados fornecedores. Estas medidas parecem, nos dias de hoje, serem as mais aceitas para se
impedir esse tipo de ação. |
|
É difícil
prever qual o futuro do P2P enquanto não for determinada a situação legal não se
tornar clara. As companhias terão que gastar muitos recursos para se protegerem dos
processos legais. Sempre haverá troca ilegal de arquivos e quebra de direitos autorais, porém
essas ações acontecerão sempre nas periferias. Qualquer sistema que se torne muito grande
terá mesmo fim que teve o Napster. A não ser que ele seja tão descentralizado e anárquico
que nenhum usuário possa ser responsabilizado. Muitos dependem de legislações de
responsabilidades dos governos a respeito do P2P. Enquanto isso o fardo de impedir as
quebras de direitos autorais cai nas mãos dos desenvolvedores de sistemas P2P ou dos
usuários. O P2P também se expandirá além do PC e aparecerá nos PDA´s e
telefones
celulares com acesso à Internet.
Uma das questões
que deverão ser abordadas no futuro é a questão dos “freeloaders” –
usuários que obtém algum tipo de recurso do sistema P2P, mas não contribui. De acordo
com
pesquisadores da Xerox PARC, “70% dos usuários não contribui com nenhum recurso,
enquanto 1% dos pares (peers) é responsável por 50% das cargas”. Em um sistema gratuito,
aberto e sem obrigações sempre existirão usuários que sempre irão “pegar”,
mas nunca
“contribuir”. Quanto ao compartilhamento de banda em uma rede P2P, modelos tradicionais
de gerenciamento de recursos necessariamente não utilizam nenhuma ferramenta que realize
essa função porque a banda é “reabastecida” periodicamente e a banda não
utilizada não pode
ser armazenada.
Uma proposta para
sistemas P2P é utilizar alguma forma de “moeda digital” para beneficiar os
usuários mais robustos ajudar a diminuir de alguma forma a existência dos “freeloaders”.
No
caso do “MojoNation” [OR] é criado um mercado digital no qual os usuários que possuem
o
maior número de arquivos para compartilhamento são beneficiados com o “mojo”, uma
espécie de incentivo interno, e quanto mais arquivos compartilhados forem “consumidos”
mais
mojo é ganhado. Sempre haverá uma maneira tecnológica de se conseguir algo sem pagar.
Esses sistemas tem que botar fé na própria moeda e na massa crítica de usuários,
o que a
MojoNation ainda falta atingir. Além disso, dissuadindo os freeloaders poderemos
desencorajar o crescimento da rede e melhorar potencialmente os usuários mais freqüentes.
Outro problema
a ser enfrentado é a confiança de que um dos maiores problemas na
comunidade da Internet como, “spammers”, “crackers” e coisas do tipo não atinjam
as redes
P2P. Sua natureza aberta as tornam alvos fáceis. Qualquer um pode se juntar à rede e se seus
pares não puderem confiar na rede eles não irão usá-la. Permitir o acesso de estranhos à sua
rede doméstica pode provar ser uma má idéia.
A busca é
uma área definida na qual o P2P prosperará muito no futuro. As redes P2P
permitem que uma consulta seja enviada a certo número de máquinas. Se a consulta inicial não
tiver sucesso, a consulta é passada por cada uma das máquinas iniciais para tantas outras
máquinas posteriores. Assim a área de busca cresce exponencialmente até que a busca forneça
um resultado. Este processo elimina a necessidade de grandes centrais de mecanismos de
busca.
Os grandes como
a Intel, Microsoft e Xerox têm estressado o potencial das redes P2P e a
probabilidade é que ela continue a ser adotada por grandes negócios como uma maneira mais
barata de armazenar e compartilhar arquivos internamente. É como se as companhias
tradicionais fossem “abraçar e realçar” (embrace and enhance) o P2P ao invés
de tentar (em
vão) sufocá-lo. O futuro do P2P pode vir a aparecer de uma idéia original e crescer assim
como aconteceu com o Napster. Porém é mais provável que as grandes empresas explorem
qualquer possibilidade que possa vir a ter o P2P e tirar alguma vantagem disso. De qualquer
maneira, o futuro do P2P existe e estará disponível tão quanto for possível. |
|
|
|
|
|
|
|
A internet nasceu
como um sistema P2P no final da década de 1960 para compartilhar
recursos entre computadores dentro dos Estados Unidos. No início os principais usuários eram
pesquisadores que não precisavam de nenhuma espécie de proteção entre eles e servidores
de
proxy e firewall praticamente não existiam fazendo com que a Internet fosse muito menos
particionada do que é hoje. Entretanto em 1994 a estrutura da Internet mudou drasticamente
com milhões de pessoas aderindo à rede. Protocolos de conexão de Modem como SLIP e
PPP foram largamente utilizados. Aplicações como os navegadores de Internet são baseados
no protocolo cliente-servidor. A estrutura da Internet mudou do modelo P2P para o modelo
cliente-servidor.
Entretanto muitas
aplicações ainda utilizam o modelo P2P. Uma de grande sucesso foi o
Napster. Criado pelo estudante Shawn Fanning de 19 anos da Universidade Northeastern em
Boston, Tudo começou quando seu colega de quarto começou a reclamar dos “links
quebrados” de MP3 espalhados pela rede e então veio a idéia do Napster. Fanning disse: “Eu
tive essa idéia de que existia um monte de material parado nos discos rígidos das pessoas
e eu
tinha que pensar numa maneira de ir lá e pegá- los.”. Ele queria encontrar um caminho
fácil
para que as pessoas que escutam músicas no formato MP3 pudessem trocar suas músicas
favoritas através da Internet. Ele conhecia o bastante de programação UNIX e sabia que
o
objetivo era alcançável e dedicou todo o seu tempo e esforço para conseguir seu objetivo.
Toda a concepção do projeto o tomou pro completo e ele teve que largar a universidade para
terminar seu trabalho. Uma vez completo, o Napster se tornou um grande sucesso e foi um dos
site de maior crescimento de toda história da Internet.
Antes do Napster
havia alguns sites que disponibilizavam musicas no formato MP3 porém
quando havia alguma atualização do site era difícil encontrar as músicas que se
queriam pois a
maioria dos sites não possuíam muita capacidade de armazenamento, e por isso os links que
apontavam para algumas músicas já não serviam pois o arquivo tinha sido substituído
por
outro. Outro problema era que não se sabia quando um novo arquivo seria disponibilizado.
Como Napster esses problemas foram solucionados. Os link provenientes de uma busca pela
música desejada eram todos funcionais. E qualquer atualização também era fornecida
pela
busca. Os Servidores do Napster lidavam com a transferência dos arquivos entre os clientes,
porém não os armazenavam. O protocolo de rede do Napster criava um acesso P2P entre
seus clientes. A simplicidade de uso que o P2P fornece fez com que o Napster e outros
sistemas que o utilizam tivessem enorme sucesso. |
|
A internet nasceu
como um sistema P2P no final da década de 1960 para compartilhar
recursos entre computadores dentro dos Estados Unidos. No início os principais usuários eram
pesquisadores que não precisavam de nenhuma espécie de proteção entre eles e servidores
de
proxy e firewall praticamente não existiam fazendo com que a Internet fosse muito menos
particionada do que é hoje. Entretanto em 1994 a estrutura da Internet mudou drasticamente
com milhões de pessoas aderindo à rede. Protocolos de conexão de Modem como SLIP e
PPP foram largamente utilizados. Aplicações como os navegadores de Internet são baseados
no protocolo cliente-servidor. A estrutura da Internet mudou do modelo P2P para o modelo
cliente-servidor.
Entretanto muitas
aplicações ainda utilizam o modelo P2P. Uma de grande sucesso foi o
Napster. Criado pelo estudante Shawn Fanning de 19 anos da Universidade Northeastern em
Boston, Tudo começou quando seu colega de quarto começou a reclamar dos “links
quebrados” de MP3 espalhados pela rede e então veio a idéia do Napster. Fanning disse: “Eu
tive essa idéia de que existia um monte de material parado nos discos rígidos das pessoas
e eu
tinha que pensar numa maneira de ir lá e pegá- los.”. Ele queria encontrar um caminho
fácil
para que as pessoas que escutam músicas no formato MP3 pudessem trocar suas músicas
favoritas através da Internet. Ele conhecia o bastante de programação UNIX e sabia que
o
objetivo era alcançável e dedicou todo o seu tempo e esforço para conseguir seu objetivo.
Toda a concepção do projeto o tomou pro completo e ele teve que largar a universidade para
terminar seu trabalho. Uma vez completo, o Napster se tornou um grande sucesso e foi um dos
site de maior crescimento de toda história da Internet.
Antes do Napster
havia alguns sites que disponibilizavam musicas no formato MP3 porém
quando havia alguma atualização do site era difícil encontrar as músicas que se
queriam pois a
maioria dos sites não possuíam muita capacidade de armazenamento, e por isso os links que
apontavam para algumas músicas já não serviam pois o arquivo tinha sido substituído
por
outro. Outro problema era que não se sabia quando um novo arquivo seria disponibilizado.
Como Napster esses problemas foram solucionados. Os link provenientes de uma busca pela
música desejada eram todos funcionais. E qualquer atualização também era fornecida
pela
busca. Os Servidores do Napster lidavam com a transferência dos arquivos entre os clientes,
porém não os armazenavam. O protocolo de rede do Napster criava um acesso P2P entre
seus clientes. A simplicidade de uso que o P2P fornece fez com que o Napster e outros
sistemas que o utilizam tivessem enorme sucesso. |
|
Primeiramente cada
computador deveria ter o Napster instalado no seu computador. Uma vez
acionado o programa verifica a conexão com a Internet. Se existir a conexão com a Internet
o
computador se conecta com o servidor central do Napster. Essa conexão é feita através
do
software de troca de arquivos do Napster. O servidor centrar concentra o diretório de todos
os computadores clientes conectados a ele armazena informações de determinada maneira. Se
um usuário deseja certo arquivo, ele faz um requerimento ao servidor central do Napster ao
qual ele está conectado. O servidor verifica em seu diretório se existe um arquivo que
corresponda ao requerimento feito pelo usuário. O servidor então envia ao usuário todos
os
arquivos encontrados (se existirem) juntamente com o endereço IP, nome do usuário, tamanho
do arquivo, tempo de ping e taxa de transferência de cada um. Depois o usuário escolhe o
arquivo desejado da lista correspondente ao requerimento e tenta estabelecer uma
comunicação direta com o local onde se localiza o arquivo escolhido. O usuário tenta
fazer isto
enviando uma mensagem ao outro computador cliente juntamente com seu próprio endereço
IP e o nome do arquivo desejado. Se a conexão é estabelecida então o computador cliente
onde se localiza o arquivo é agora considerado o “host”. O “host” agora transfere
o arquivo
para o usuário. Quando a transferência é completada o “host” então interrompe
a conexão. |
|
O Napster procura por arquivos usando um protocolo cliente/servidor. Este protocolo
utiliza o
protocolo de comunicação TCP/IP. O servidor mantém uma “master list” de todos os
computadores conectados a ele e então ele faz a busca por arquivos procurando pelo diretório
destes computadores conforme descrito anteriormente.
O Napster permite transferência de arquivos que sejam independentes do servidor central.
Esta
transferência ocorre entre computadores cliente. Existem quatro modos de transferência: “upload”,
“download”, “firewall upload”, “firewall download”. |
|
|
|
|
Gnutella foi inventada
na Nullsoft, uma subsidiária da AOL, por Justin Frankel e Tom Pepper.
O programa foi disponibilizado em14 de março de 200 para o publico geral através do site da
Nullsoft. Ao mesmo tempo o Napster vinha sendo investigado pelo fato de estar permitindo a
distribuição de material ilegal de acordo com seus direitos autorais. Uma vez que foi conhecido
que o Gnutella era capaz de realizar a mesma função do Napster e que a AOL iria se fundir
com a Time Warner Music, a AOL forçou a Nullsoft a remover todos os links para o Gnutella
do seu site. Porém era tarde, apesar de ter estado apenas algumas horas no site, um grande
número de pessoas já tinham baixado o programa.
Uma vez que o programa
esteve na Internet, as pessoas que conseguiram adquiri-lo
começaram a fazer engenharia reversa a fim de obter o protocolo de comunicação do
programa. Em alguns dias o protocolo foi “quebrado” e o programa foi relançado na Internet.
Como diferentes pessoas conseguiram “quebrar” o protocolo, diferentes versões de programas
usando o protocolo da Gnutella foram disponibilizados na Internet como Morphues, LimeWire,
GNUcleus e outros. Todos eles usam o protocolo da Gnutella para se interagirem, porém cada
um é um programa diferente programado para agir da sua maneira.
Quando a Nullsoft
lançou sua versão original do Gnutella ele foi da forma de uma versão beta
da qual os programadores da Nullsoft tinham a intenção de desenvolver e otimizar. Como o
projeto foi colocado na prateleira, isto nunca aconteceu e o programa foi deixado para que os
usuários da rede se preocupassem em atualizá-lo. Quando o Gnutella foi lançado ele saiu
na
versão 0.4, versão que continua até hoje. Esta implementação, porém, sofreu
muitos
problemas substanciais que serão examinados em maiores detalhes mais tarde.
Um dos princípios
dos “designers” do Gnutela era lançá-lo como um protocolo aberto e utilizar
a licença General Public License (GPL) para permitir o envolvimento do protocolo em outros
projetos. Como os designers foram proibidos de fazer qualquer trabalho no programa, isto
nunca aconteceu realmente. Ao invés disso um consórcio de programadores foi feito para se
ter uma visão geral a respeito das mudanças e avanços do protocolo. A razão para
que este
programa não seja verdadeiramente um programa aberto é que seus idealizadores não estavam
à frente deste consórcio, como geralmente acontece com outros programas abertos sobre a
licença GPL. Também o código real do protocolo nunca foi de fato revelado, portanto o
consórcio só tinha a versão do protocolo da qual tinham feito a engenharia reversa. Para
se
ater à idéia geral da GPL, um site central foi criado para facilitar a discussão em torno
do
Gnutella. O site se encontra no endereço Gnutella.wego.com.
Gene Kan tomou
a frente do consórcio em torno do Gnutella. Ele se tornou líder do consórcio
através dos esforços aplicados nas semanas iniciais para garantir que Gnutella tivesse um
protocolo. Sua maior contribuição foi começar um projeto, com uma semana de planejamento,
que rapidamente solucionou diversos problemas do protocolo. Ele também montou o site de
discussão sobre o Gnutella. Como resultado dos seus esforços e de outros o Gnutella se
estabeleceu como um protocolo de redes P2P.
Como líder
do consórcio, Kan foi responsável pela divulgação e suporte do protocolo assim
como seu desenvolvimento. Com este fim ele realiza uma publicação periódica a respeito
do
Gnutella e informa o mundo a respeito dos benefícios do protocolo. |
|
O protocolo Gnutella,
na versão 0.4, executa sobre o TCP/IP um protocolo de conexão
orientada. A sessão típica inclui uma conexão entre cliente servidor. O cliente então
envia um
pacote do Gnutella avisando sua presença. Esse aviso é então propagado pelo servidor
por
toda a rede através de um encaminhamento recursivo para os servidores seguintes. Todos os
servidores que recebem esses pacotes respondem com outro pacote similar a respeito deles
mesmos.
Consultas são
propagadas da mesma maneira, com os resultados sendo retornados pelo
mesmo caminho. Quando um recurso é encontrado e selecionado para ser transferido, uma
conexão ponto-a-ponto é estabelecida entre o cliente e o “host” do recurso, e o
arquivo é
transferido diretamente usando HTTP. O servidor neste caso irá agir como um servidor web
capaz de responder ao pedido de HTTP GET.
Os pacotes Gnutella
são da forma:
|
Message ID (16 bytes)
|
Function ID (1 byte)
|
TTL (1 byte)
|
Hops (1 byte)
|
Payload length (4 bytes)
|
Onde:
Message ID em
conjunto ao TCP/IP é usado unicamente para identificar uma transação.
Function ID é
utilizado como: aviso (resposta), consulta (resposta), ou requisição.
TTL é
o tempo de vida do pacote (time-to-live), isto é, quantas vezes mais o pacote será
encaminhado.
Hops conta
o número de vezes que um dado pacote é encaminhado.
Payload length é
o tamanho em bytes do corpo do pacote.
Conectando
O cliente encontra
um servidor por tentar se conectar a algum da lista local de servidores
conhecidos que são igualmente disponibilizados. Esta lista pode ser conseguida da internet ou
pode ser compilado por um usuário final. Os pacotes de aviso (também conhecidos como Ping
ou Init) contêm um número de arquivos que o cliente está compartilhando, e o tamanho
em
Kilobytes do dado compartilhado. A resposta do servidor (Pongs) contém as mesmas
informações. Então, uma vez conectado, o cliente sabe quantos dados estão disponíveis
na
rede.
Consultas
Como mencionado
acima, as consultas são propagadas da mesma maneira que os avisos. Para
economizar banda, os servidores que não contém resultados para a consulta não precisam
enviar uma resposta.
A semântica
dos resultados da procura não é definida no protocolo atual. Os detalhes são
dependentes de cada servidor. Por exemplo, a busca por “.mp3” pode ser interpretada como
todos os arquivos como a mesma extensão ou qualquer arquivo que contenha “mp3” no seu
nome, etc.
Fazendo um “Download”
Um cliente que
deseja fazer uma transferência de “download” “abre” uma conexão de HTTP
(Hyper-Text Transfer Protocol) como o “host” e faz uma requisição do recurso enviando
um
“GET>URL<” que é um tipo de comando HTTP onde a URL (Uniform Resource Locator) é
retornado pela requisição da consulta. Portanto, um cliente compartilhando um recurso tem
que implementar um servidor web básico. |
|
Escalabilidade
O sistema foi desenvolvido
em um laboratório e foi concebido para funcionar para apenas
umas centenas de usuários. Quando este foi disponibilizado na Internet, ele rapidamente
cresceu para ter uma base de dez mil usuários. Infelizmente naquele estágio o sistema ficou
sobrecarregado não foi capaz de lidar com tamanho tráfego e nós que existiam na rede.
Vida dos pacotes
Para achar outros
usuários, um pacote tinha que ser enviado através da rede. Logo foi
percebido que o tempo de vida de alguns pacotes não foi configurado corretamente o que fazia
com que eles ficassem rodando pela rede indefinidamente. Isto resultava numa disponibilidade
menor de banda para os usuários da rede.
Velocidade de
conexão dos usuários
Usuários do
sistema agem como “gateways” para outros usuários para buscarem os dados que
estes últimos necessitam. Entretanto, nem todos os usuários possuem a mesma velocidade de
conexão. Isto resulta num problema como de usuários com uma banda de baixa velocidade
agindo como conectores para outros com uma velocidade maior. Isto resulta numa velocidade
de conexão que é ditada pelos usuários que possuem as menores velocidades de conexão
fazendo com que ocorram gargalos na comunicação.
Além do mais
a rede não é todo visualizada por todos os clientes. Usando o tempo de vida
padrão durante o aviso e a procura, apenas cerca de quatro mil pares são alcançados.
Isto
acontece pelo fato de que cada cliente mantém apenas quatro outros clientes e o pacote de
busca/init é encaminhado apenas cinco vezes. Na prática isto significa que mesmo que alguns
recursos estejam disponíveis na rede, eles podem não estar visíveis para quem está
procurando
porque ele pode está a muitos nós de distância. Para se aumentar a quantidade de pares
alcançáveis na rede Gnutella, precisaríamos aumentar o tempo de vida dos pacotes e número
de conexões que podem ser abertas. Infelizmente estas ações trariam outros problemas.
Se
aumentássemos tanto os números conexões quanto o número de hops para oito, 1,2 gigabytes
de dados agregados poderiam potencialmente cruzar a rede apenas para realizar uma consulta
de 18 bytes.
Outra questão
significante que pode ser identificada é a susceptibilidade do Gnutella para
negação de ataques ao serviço (denial of service attacks). Por exemplo, uma rajada de
pedidos pode facilmente saturar toda banda disponível à vizinhança do agressor, sem que
os
pares percebam que se trata de uma requisição maliciosa. Alguns trabalhos têm sido feitos
para poder minimizar esses tipos de problemas, porém muitos compromissos ainda precisam
ser acordados. Cada vez mais o serviço da rede Gnutella tem piorado. Isto se deve a uma
combinação de fatores, alguns se devem à característica do protocolo, outros induzidos
pelos
próprios usuários. |
|
|
|
|
Freenet é
um sistema P2P completamente descentralizado e distribuído. Toda a comunicação é
coordenada pelos pares em nível global.
O Freenet opera
como um sistema de arquivos distribuído independente da localização entre
vários computadores que permitem que a inserção, armazenamento, e requisição
de dados
anonimamente.
Um nó é
um simples computador que “percorre” todo o sistema, e todos os nós são tratados
como iguais pela rede. Cada nó mantém sua própria unidade de armazenamento a qual é
disponibilizada para a rede tanto para leitura e escrita quanto para a tabela de roteamento
dinâmico que contém endereços de outros nós. Isto exclui qualquer ponto de falha
ou controle.
Seguindo pelo protocolo do Freenet, seus nós se organizam espontaneamente dentro de uma
rede eficiente.
É sistema
foi designado a se adaptar ao uso de padrões (patterns) movendo-se
transparentemente, replicando, e apagando arquivos de acordo com a necessidade para
fornecer um serviço eficiente sem recorrer a “broadcast” de busca ou a índices de
localização
centralizados.
A pretensão
da maioria dos usuários do sistema é utilizar nós para promover uma segurança
garantida contra outros nós hostis e aumentar a capacidade de armazenamento da rede como
um todo.
O Freenet pode
habilitar a usuários compartilharem espaços de disco inutilizados, como
sistemas de rede distribuída que permitem que usuários compartilhem ciclos de processamento.
O sistema opera
na camada de aplicação e assume a existência de uma camada de transporte
segura, embora seja um transporte independente. Ele não procura providenciar anonimato para
utilização comum de rede, só entre transações de arquivos do Freenet. |
|
No começo
o sistema existia apenas na cabeça de Ian Clarck. Após ter estudado na escola
Dundalk Grammar onde ganhou o prêmio nacional de jovens cientistas por dois anos seguidos,
Ian deixou a Irlanda, em 1995, em favor da graduação em inteligência artificial e ciência
de
computação da universidade de Edimburgo na Escócia.
Em julho de 1999
Ian escreveu um artigo intitulado: “A Distributed Decentralized Information
Storage and Retrieval System". O artigo continha a idéia básica para o Freenet. Mantendo
sua
filosofia quanto à liberdade de informações com a sua intenção de por em prática
sua idéias
recrutou vários ajudantes através da Internet. Logo os trabalhos começaram a dar resultado
e
a versão 0.1 foi lançada em março do ano seguinte. Desde então o sistemas tem sido
freqüentemente atualizado e diversas versões já foram lançadas.
O ponto básico
do Freenet é que ele foi designado a permitir o total anonimato a autores e
fornecedores de informação, porque sua arquitetura distribuída torna impossível
a localização
de qualquer artigo por um nó e, portanto de seu autor. As pessoas que se submetem à rede
quem ou o que está utilizando sua máquina. Ian descreveu esse fenômeno como “machine
anarchy” (anarquia das máquinas). Ao mesmo tempo em que as noticias em torno da
potencialidade filosófica do sistema eram de grande euforia, a preocupação quanto ao
seu mau
uso já era uma preocupação. No mesmo mês em que foi lançado o Freenet, Roger
Darlington,
executivo da Internet Watch Foundation, falou para a revista New Scientist: “There is clear
potential for misuse by criminals, terrorists and pedophiles” (Há um claro potencial para
a
má utilização por parte dos criminosos, terroristas e pedófilos).
A publicidade em
torno do Freenet provavelmente ocorreu na mesma época do fim do
Napster, que foi vista por muitos como a melhor alternativa de segurança. A aquela altura era
óbvio que as críticas a respeito do Freenet não eram nada boas em grande parte devido
a
industria musical que queria defender seus direitos a qualquer custo. O interessante é que
desde então novos sistemas descentralizados de troca de arquivos como o KaZaa e o
Morpheus se tornaram os grandes programas de trocas de músicas digitais. E provavelmente
não é totalmente coincidência que Ian atinou para a nova possibilidade de utilização
que era
explorar aplicações comerciais do Freenet. Ao especular sobre o que esperar do futuro do
Freenet Ian considerou um importante ponto de vista. Ele disse: “Much like de WWW, it is a
plataform on which people build” (Parecido com o WWW, que é uma plataforma onde as
pessoas constroem). Ele também disse que as expectativas de como as pessoas vão utilizar o
Freenet sempre foram contrárias às verdadeiras atitudes dos seus usuários. Portanto os
avanços do sistema devem ser feitos da forma mais flexível possível. |
|
O freenet está
implementado como uma rede P2P adaptativa de nós que se consultam para
armazenar ou fornecer arquivos de dados, que são chamados de chaves de localização
independente (location-independent keys). Existem três tipos básicos de chave:
No modelo básico,
primeiramente uma chave é passada de nó a nó através de uma cadeia de
requisições no qual cada nó estabelece um local de decisão sobre onde irá enviar
a próxima
requisição, no estilo do roteamento IP. Depois dependendo da chave requisitada a rota irá
mudar. O algoritmo de roteamento se ajusta adaptativamente à rota de tempos em tempos
para promover um desempenho eficiente. Em seguinte cada nó possui apenas conhecimento a
respeito de seus nós vizinhos, para manter a privacidade. Para cada requisição é
dado um
tempo de “hops” limite (hops-to-live), que é decrementado a cada nó para evitar
cadeias
infinitas. Posteriormente cada requisição assume um identificador único, que faz com
que os
nós possam prevenir loops rejeitando requisições que eles já viram antes. Este processo
continua até que a requisição é satisfeita ou o tempo de “hops” (hops-to-live)
exceda o limite
estipulado. Então o sucesso ou a falha é retornado pela cadeia para informar ao nó. |
|
O usuário de um sistema P2P quer saber quanto tempo ele levará para obter um determinado
arquivo e quanto de banda sua consulta irá consumir. Esses dois parâmetros têm um impacto
direto na utilização e no sucesso de um sistema.
Dentre os problemas
que podem afetar o desempenho da rede P2P descentralizada do
Freenet, podemos citar a comunicação de rede. A velocidade de conexão é menos do
que a
velocidade de E/S (entrada/saída) e de processamento, o que causa um gargalo na
comunicação. Este problema é enfatizado pela grande natureza paralela do Freenet. Outro
ponto é que como não existe um armazenador central de índices, as mensagens devem passar
por muitos “hops”, para buscar através do sistema o arquivo desejado. Cada “hop”
não só
adiciona carga à banda total como também aumenta o tempo necessário para a realização
da
consulta. Se um para for inalcançável, pode levar vários minutos até que a comunicação
seja
interrompida. Uma necessidade que ocorre em todos os sistemas P2P é a dependência da
presença de uma base de usuários participativa, cooperativa e suficiente para que o sistema
possa funcionar com agilidade.
Efeito “small
world”
Duas características
que podem distinguir um sistema “small world” são:
O efeito “small
world” é fundamental para a operação do Freenet. Ele é importante porque
define o problema do posicionamento do arquivo numa rede P2P descentralizada e auto-
configurável como o Freenet. No Freenet as consultas são repassadas através dos nós
para o
próximo local de decisão no qual o recipiente potencial pode trazer maior progresso para o
alvo. As mensagens não são alvo de um específico par mas relaciona qualquer par que tenha
o
arquivo desejável no seu disco.
Apesar de a rede
ser longa, deve existir rotas curtas. Numa simulação da rede Freenet, com
mil nós idênticos, que estavam inicialmente vazios, metades das requisições da rede
obtiveram
sucesso com seis “hops”. Um quarto das requisições obtiveram sucesso com três
ou menos
“hops”. Comparado com a Internet como uma rede “small world” com tamanho de percurso
característico de 19, o Freenet obteve uma boa média de desempenho, mas um fraco pior
caso, por causa de algumas escolhas de rota ruins que podem lançar a requisição
completamente fora do percurso.
Alguns aspectos
de robustez afetam o Freenet assim como os sistemas P2P. Desde que os
paras tendem a ser computadores pessoais ao invés de servidores dedicados, eles são
desligados da rede aleatoriamente.
O roteamento de
requisições é a chave da eficiência e escalabilidade do Freenet. Ele também
permite aos dados se “movimentarem”. Cada nó tenta encaminhar sua requisição
cada vez
mais próximo do dado, a busca é muita mais poderosa que uma busca linear e muito mais
eficiente que um broadcast.
Questões
de desempenho
Confiança
Uma vez ativado
o sistema, o usuário está apto o realizar transferência de arquivos, podem
providenciar alguma garanta de que seus códigos não sejam corrompidos e facilitem a
construção de uma reputação associada a seus nomes chave.
Contabilidade
A lição
principal para um desenvolvedor P2P é que sem contabilidade é difícil executar regras
de responsabilidade social. Como o Usenet e o e-mail, hoje os sistemas P2P correm o risco
de sofrerem abusos de propagadas não solicitadas (spams).
Segurança
Firewalls, IP dinâmico
e NAT cresceram além da necessidade na arquitetura da Internet de se
tornar um sistema escalável e seguro. Novas aplicações P2P desafiam essa arquitetura
demandando que os participantes sirvam recursos como também os usem.
Interoperabilidade
através de “gateways”
Firewalls são
colocados nos gateways entre a rede interna e a Internet. Ele é uma ferramenta
de segurança muito útil, porém é um sério obstáculo para o modelo de comunicação
P2P.
Largura de Banda
Assimétrica
Em conexões
de rede como as ADSL (Assimetric Digital Subscribe Line), existe um
favorecimento ao uso dos clientes frente aos servidores. O problema hoje é que as aplicações
P2P estão mudando a concepção de que os usuários finais desejem apenas realizar
“downloads” da Internet, nunca “uploads”. Isto resultou numa infra-estrutura de
rede que é
otimizada para computadores que são apenas clientes, não servidores. Porém a tecnologia
P2P faz com que cada par aja tanto com o cliente quanto como servidor tornando a
concepção anterior incorreta. Portanto a arquitetura de rede que existe hoje terá que
passar
por uma grande mudança para lidar com este novo modelo de tráfego.
Abuso da porta
80
A porta 80 é
a porta utilizada para o tráfego http quando as pessoas navegam pela Internet.
Os Firewalls basicamente filtram o tráfego baseado na sua direção e na sua porta de destino.
As mais atuais aplicações P2P utilizam de alguma forma a porta 80 para burlar uma eventual
política de segurança de rede. O problema é que não existe uma boa maneira de identificar
qual aplicação está passando por uma porta. Também mesmo que a aplicação
possua uma
razão legítima para atravessar o Firewall, não existe uma maneira simples de se pedir
uma
permissão.
Anonimato
Como nenhum nó
pode dizer de onde chegou um pedido além do nó que o enviou, é muito
difícil encontrar a pessoa que começou esse pedido. O Freenet não fornece um anonimato
perfeito porque isto causaria um desequilíbrio entre eficiência e usabilidade. Se alguém
quer
saber exatamente o que outro usuário está fazendo, dados os recursos do sistema, ele
conseguirá. Entretanto o Freenet busca parar a indiscriminada fiscalização maciça
das pessoas. |
|
|
|
|
Neste capítulo
iremos introduzir o conceito de mecanismo de busca e descrever como
tradicionalmente funciona um mecanismo de busca numa rede cliente/servidor.
A World Wide Web
(WWW) consiste em literalmente bilhões de páginas, distribuídas através
de milhares de servidores ao redor do mundo. Desde que se tornou fisicamente impossível
para um indivíduo examinar todas as páginas à procura de uma determinada informação,
alguns
mecanismos de busca surgiram para fazer isto pelos usuários.
Os mecanismos de
busca utilizam softwares chamados de “spiders” vagam através da web
automaticamente seguindo “hiperlinks” de um documento para o outro extraindo importantes
informações textuais deles. Ele utiliza essas informações para construir um enorme índice
correlacionando palavras-chave a páginas da web. Os mecanismos de busca não podem
simplesmente inventar URL´s. Invés disso todas as buscas originadas das páginas da web
especificadas manualmente pelos usuários e os spiders subsequentemente seguem os links
destas páginas para outras. A rede web possui suas proteções e uma grande parte dela
está
invisível para os spiders. Entretanto o Google possui cerca de dois bilhões de páginas
em seu
banco de dados.
Quando um usuário
faz uma consulta em um mecanismo de busca no seu navegador da web,
sua entrada é processada e usada para procurar o banco de dados para a ocorrência de
determinada palavra-chave. As páginas se encontradas são ordenadas usando um ranking
escolhido através de um algoritmo particular para cada mecanismo de busca.
Obviamente a página
do topo do ranking “deve” ser a página que tenha mais afinidade com o
interesse do usuário. Esses rankings são geralmente baseados numa média de pesos de um
número relevante de pontos que são derivados de um número de ocorrências das palavras-
chave na página.
Portanto atualmente
os mecanismos de busca não procuram na web diretamente. Eles
meramente se referem ao banco de dados localizados em um servidor central. É claro que
quando as páginas mudam seus conteúdos, isto significa que quando uma busca é realizada
na
verdade é amostrada uma cópia da página que pode não ter mais relevância ou
nem existir.
Então para lidar com a questão de páginas modificadas, movidas, apagadas ou renomeadas,
o
índice no banco de dados precisam ser atualizados periodicamente para manterem a qualidade
do mecanismo utilizado. O problema é que no caso do Google que possui um banco de dados
imenso, se torna inviável fazer uma atualização.
Além do mais,
empresas como Google utilizam uma grande capacidade de armazenamento e
uma imensa largura de banda que custam uma fortuna. No lado do software, soluções de
compressão personalizada para reduzir os custos de armazenamento e algoritmos como o
“hashing” para aumentar a velocidade de indexação do banco de dados são algumas
das
técnicas utilizadas para assegurar maior eficiência e velocidade.
Enquanto os mecanismos
de busca atuais são adequados para a busca geral na web, eles
continuaram tendo muitas desvantagens. Os custos de construção e manutenção da infra-
estrutura são muito altos, eles não lidam adequadamente com páginas dinâmicas, eles
ignoram
a maioria das páginas disponíveis na web que são invisíveis pelos spiders. É
claro que todos
esses problemas estão sendo exacerbados, pois a medida que a rede cresce se torna cada vez
mais impossível para qualquer mecanismo de busca centralizada repetidamente visitar e indexar
todas as páginas acessíveis na web. |
|
Efetivos métodos
de busca devem confiar na grande variedade de informação sobre o recurso
desejado, tipicamente na forma de meta dado.
A maioria dos tipos
de métodos de busca está descrita aqui.
A implementação original do Gnutella é um exemplo de mecanismo
de busca de
transmissão de inundação. Quando um par faz uma consulta, esta consulta é transmitida
para todos os seus pares vizinhos. Se um par vizinho não fornecer resultados então esta
consulta e transmitida para os pares vizinhos do vizinho. Se o recurso é encontrado,
aquele par envia uma mensagem para o par que originou a consulta indicando que
encontrou resultados para a consulta, e então estabelece uma conexão P2P.
Cada consulta tem um contador de TTL (Time-To- Live). Tipicamente, o TTL é
ajustado entre cinco e sete, e o valor é decrementado à medida que a consulta passa
por um nó. Outro contador informa o número de saltos (hops). Uma vez que o
contador TTL atinge o valor zero, a consulta é então descartada.
Dada a natureza da transmissão de cada nó, o sistema não possui
um boa
escalabilidade (O(n²)), a largura de banda assume valores que crescem
exponencialmente com um aumento linear do número de pares. O crescimento do
número de pares no sistema causará uma rápida saturação da banda disponível
para a
rede.
Este tipo de método possui suas vantagens de flexibilidade no processamento
de
consultas. Cada par pode determinar como será processada consulta e responder de
acordo. Isto é fácil de desenvolver e eficiente. Infelizmente este método só é
apropriado para redes pequenas. Além do que este mecanismo é muito susceptível às
atividades maliciosas. Algum par pode enviar um número muito grande de consultas
que produziria uma carga significativa na rede.
Estes sistemas são mais escaláveis que os de transmissão e inundação.
Além de enviar
a consulta para todos ao pares, ele encaminha seletivamente a consulta para específicos
pares que são considerados possíveis locais onde o recurso pode ser encontrado. Os
pares se tornarão super pares automaticamente se eles tiverem largura de banda
suficiente para processarem suas potencialidades. Pares com conexão através de linha
discada (banda pequena) poderão fazer consultas à super pares. Este tipo de sistema
utiliza algoritmo de controle de fluxo (FCA – Flow Control Algoritm) que tenta aplicar
uma forma inteligente de controlar o fluxo de como um par encaminhará e responderá a
uma mensagem e um esquema sensível de prioridade para como descarta mensagens
que não caibam na conexão.
Com essa abordagem, ocorre uma grande redução da limitação
de largura de banda
para a escalabilidade. Mas esse sistema também esta susceptível a atividades ilegais.
Pares podem se inserir na rede em vários pontos diferentes e desorientando a rota das
consultas fazendo com que elas sejam descartadas.
Cada par pode conter também uma série de informações usadas
para o roteamento ou
para recebimento direto de consultas. O tamanho dessas informações é insignificante
numa rede de pequeno porte, mas numa rede grande, este “overhead” pode crescer a
níveis insuportáveis.
Neste tipo de rede, cada arquivo armazenado no sistema possui uma identidade
(id)
única, tipicamente um “hash sha-1” do seu conteúdo, que é usado para identificar
e
localizar um recurso. Dado essa id única, um recurso pode ser localizado rapidamente
apesar do tamanho da rede. Como cada recurso é identificado pela sua chave, é
impossível realizar uma busca nebulosa (fuzzy) dentro da rede. Se um par está
procurando um arquivo de um outro par, ele tem que conter essa chave antes para
poder receber o arquivo.
Estes sistemas também são, como todos os outros, susceptíveis
a atividades ilegais.
Um par pode descartar uma consulta, inserir uma porção de dados sem importância
para desordenar as chave, ou inundar a rede de consultas para denegrir o desempenho.
O Napster utiliza índices centralizados e sistema de repositório. Índices
de todos os
pares e seus recursos são armazenados em um grande servidor principal. Uma consulta
é enviada ao servidor e o servidor procura pelo índice correspondente, se a consulta
fornecer um resultado então o servidor envia uma mensagem para o par que realizou a
consulta sobre onde ele pode conseguir o arquivo.
Índices centralizados têm promovido o melhor desempenho para mecanismos
de
busca, porém a banda e o hardware necessários para uma rede P2P de grande porte
exigem um custo muito alto para o sistema.
Uma deficiência que pode ser observada neste sistema é que se ocorrer
alguma falha
no servidor principal toda rede vem a baixo. No caso do Napster, o sistema possuía
um “cluster” de servidores, se um falhar o resto dos servidores continuam a suportar a
rede.
Com esta abordagem nós podemos eliminar a necessidade dos caros servidores
centralizados. A idéia de índices distribuídos é que cada nó da rede contenha
um índice
de arquivos local assim como índices de arquivos armazenados de alguns pares
vizinhos. Quando um nó recebe uma consulta de um par, ele primeiro verifica se esta
consulta pode ser satisfeita naquela localidade. Se não puder, ele usa o índice local
para determinar para qual nó será encaminhada a consulta. O índice em cada máquina
local não é estático e muda de acordo com o movimento dos arquivos no sistema.
Se o sistema for bem elaborado, é fornece o melhor desempenho e a melhor
escalabilidade que qualquer outra solução assim como uma grande tolerância quanto à
falha num ponto, porque o nó apenas contém uma quantidade relativa de índices muito
pequena se comparado com o modelo centralizado, então se um nó “cair” a rede
continuará funcionando apropriadamente.
O problema mais complicado neste tipo de modelo é manter a coerência
de todos os
dados indexados. Se um arquivo é mudado de localização pó rum determinado par, o
nó não será informado que aquele arquivo em particular mudou posteriormente,
quando outro par requisitar este arquivo, o nó irá retornar uma cópia desatualizada.
O
“overhead” para manter todos atualizados e eficientemente distribuídos é o que mais
prejudica o sistema em nível de escalabilidade.
Invés de realizar uma consulta básica num determinado par, ele utiliza
um banco de
dados de informações existentes que o par acumulou para determinar quais recursos
encontrados podem ser relevantes ou não, ou são interessantes para o par.
Com o tempo, uma grande gama de informações é acumulada. Estas
informações são
analisadas para determinar quais elementos comuns o par achou ser relevante. O
“crawler” então atravessa a rede geralmente inserindo novas informações em
documentos em html que são comparados com o perfil destilado das informações do
par anterior.
O tempo necessário para que o “crawler” atravesse um número
muito grande de
índices é muito longo. Portanto esse sistema não é apropriado para redes de grandes.
|
|
Como dito anteriormente
existem dois tipo principais de modelos de rede P2P para a troca de
arquivos, o modelo centralizado usando cliente-servidor e o modelo descentralizado.
Os sistemas P2P
que utilizam em alguns aspectos redes cliente- servidor que estão operando
atualmente incluem:
-
Edonkey: Também
uma rede semi-centralizada, onde qualquer pessoa pode
“rodar” um servidor. Quando um cliente envia uma requisição de busca a um
servidor, apenas neste servidor é realizada a busca e quando essa busca se
completa o cliente pode enviar esta mesma requisição ao próximo servidor da sua
lista se necessário. Uma vez que um arquivo está na fila de download do cliente
outros servidores são consultados. Isto acontece porque o Edonkey foi a primeira
aplicação de cliente que possibilitou a realização simultânea de download de
múltiplas fontes, e também suporta o compartilhamento de arquivos parcialmente
baixados o que permite outros clientes a começarem a fazer download de um
arquivo de uma lista que ainda esta sendo carregado.
Redes P2P descentralizadas de busca
O conceito de descentralização é remover uma estrutura central de uma rede fazendo com que
um par possa se comunicar de igual para igual com outro par.
Embora este conceito
permita teoricamente a construção de uma rede infinita, em prática o
valor de TTL é usado para controlar o número de nós que uma consulta pode alcançar.
A vantagem de uma
arquitetura de rede descentralizada é que ela é bem mais difícil de ser
interrompida, pois não existe mais um ponto de falha. Porém a busca neste tipo de rede é
muito lenta e não é garantido que a consulta terá algum resultado, porque o arquivo desejado
pode estar a uma distância muito grande para ser alcançado.
As redes P2P descentralizadas que estão operando atualmente incluem:
|
|
O JXTA foi criado
pela empresa de Gene Khan, a Infrasearch. A companhia o desenvolveu
depois que o Gnutella foi lançado como uma solução de busca que podia acessar todos os
formatos de arquivos além do MP3. Khan descobriu que crawlers da web detinham dados
desatualizados por que levavam semanas para serem postados como recentes e
disponibilizados na rede, e em alguns casos não possuíam acesso a grandes bancos de das que
eram abertos na web especialmente depois de um “?” na URL. Para resolver esses problemas
ele desenvolveu um protótipo do Infrasearch baseado no Gnutella, além de também usar
o
“backend” do Gnutella. A idéia básica do Infrasearch era distribuir a consulta até
os limites da
rede e deixar que a inteligência do par destinatário processe a consulta qualquer que seja
o
formato apropriado e o responda. O Infrasearch foi comprado pela Sum Microsystem em
março de 2001 e o time de desenvolvimento dentro do projeto do JXTA da Sum com a
intenção de usar as idéias do Infrasearch na elaboração de um mecanismo de
busca para o
projeto JXTA. O time do Infrasearch decidiu não utilizar mais o “backend” do Gnutella
e
desenvolveram um protocolo próprio baseado em XML que foi de alguma forma utilizado no
protocolo do Gnutella, por exemplo, a noção de deixar cada par processar a consulta como
achar mais apropriado, e a distribuição das consultas entres os pares.
O mecanismo de
procura do JXTA possui os seguintes participantes:
-
“Hub”
de busca JXTA, é um mecanismo que facilita um roteamento eficiente de
consulta na rede JXTA traçando rotas entre consumidores e fornecedores. Os
fornecedores registram suas próprias descrições nos “hubs” e esperam por uma
comparação com êxito. Os consumidores consultam a rede através do hub e
esperam por um resultado. Os hubs também podem ser fornecedores ou
consumidores e podem ser cascateados numa rede.
Métodos extensos e profundos de busca
A busca JXTA possui
duas técnicas complementares de busca, a busca extensa (wide) e a
busca profunda (deep).
Numa busca JXTA de contexto extenso significa enviar dados de um hub de procura
para outro hub de procura. Estes hubs de procura são uma garantia eficiente entre uma
questão de gargalo em um extremo e uma questão de desperdício de banda em outro
extremo completamente conectado à rede. Cada hub pretende se especializar de
alguma maneira, isto é, uma aplicação de índice, etc. e se um hub não puder
responder
a uma consulta ele encaminha a consulta a outro hub.
Web crawlers freqüentemente possuem dados desatualizados e são apenas
eficientes
com conteúdos estáticos como algumas páginas da Internet. Páginas dinâmicas
com o
site de notícias não são indexadas com eficiência pelos crawlers. Mecanismos de
busca
profunda localizam dados em grandes bancos de dados como os da Amazon o de
grande sites de notícias. O JXTA decide que tipo de consulta deverá ser enviada e
então retorna os resultados. A intenção dos desenvolvedores do JXTA é de promover
um mecanismo de busca muito mais corajoso dos que os mecanismos convencionais
existentes.
O futuro do JXTA
O projeto JXTA da Sun foi lançado em uma comunidade de código aberto
com a
iniciativa de que outras pessoas contribuam com soluções que possam tornar o JXTA a
plataforma P2P número um do mundo. Este foi um passo muito importante para o
projeto porque afinal será a quantidade de pessoas que decidirá se a plataforma se
tornou a número um ou não. Até a presente data a Sun contabilizou mais de dezessete
mil membros da comunidade e ela continuou crescendo incluindo a comunidade de
código aberto o que faz com que sejam desenvolvidas cada vez mais aplicações
usando a plataforma do JXTA.
|
|
Existem muitas
redes P2P nos dias de hoje, cada uma utilizando uma maneira diferente de
rotear dados de um par para outro para descobrir novos recursos e se adaptar a mudanças de
topologia. Este capítulo descreve as técnicas de roteamento aplicada por quatro sistemas
diferentes a fim de atingir esses objetivos. |
|
Como dito anteriormente
o sistema Gnutella é um sistema descentralizado onde os pares
possuem iguais responsabilidades e deveres. Os pares se comunicam através de cinco tipos de
descritores: Ping, Pong, Query, QueryHit e Push. Cada descritor é precedido por um descritor
de cabeçalho (Descriptor Header) que já foi explicado anteriormente e possui o seguinte
formato:
Descriptor Header
|
Byte
Positions
|
0
- 15
|
16
|
17
|
18
|
19
- 22
|
|
Contents
|
Descriptor
ID
|
Function
ID
|
Time
To Live
|
Hops
|
Payload
Length
|
Ping
Um par utiliza
este mecanismo para descobrir sobre outros pares na rede. Este mensagem é
enviada sem “payload”. Isto significa que o descritor de cabeçalho possui toda a informação
necessária.
Pong
|
Byte
Positions
|
0
- 1
|
2
- 5
|
6
- 9
|
10 – 13
|
|
Contents
|
Port
|
IP
Address
|
File
Count
|
Total
File Size
|
È uma resposta
que um par realiza ao recebimento de um ping. Esta responta contém os
seguintes campos:
Port: è a
porta que o par utiliza para se comunicar.
IP Address: o endereço
IP do par.
File Count: Um
contador que possui o número de arquivos que o par compartilha com ouros
pares.
Total File Size:
o tamanho total de todos os arquivos que o par compartilha com outros pares
na rede em kilobytes.
Query
|
Byte
Positions
|
0
- 1
|
2
- N
|
|
Contents
|
Minimum
Speed
|
Search
Query
|
Quando um par deseja
encontrar arquivos na rede ele envia um descritor de consulta (query
descriptor), que contém os seguintes campos.
Minimum Speed:
Se um par em particular quer se comunicar com um par requisitor, ele deve
ser apto a fazê-lo a uma velocidade mínima ou maior. Só os pares que se encaixam neste
critério podem enviar uma resposta à consulta.
Search Query: Esta é uma string de dados de busca que contém a requisição do par. Esta
string deve conter um caractere vazio para marcar o fim do descritor.
QueryHit
|
Byte
Positions
|
0
|
1
- 2
|
3 – 6
|
7 – 10
|
11
- (N-1)
|
N
- (N+16)
|
|
Contents
|
Number
of Hits
|
Port
Number
|
IP
Address
|
Speed
|
Result
Set
|
Peer
ID
|
Este descritor é enviado em resposta a query posicionada na rede, mas apenas se o par puder
se comunicar à velocidade mínima especificada no campo de Query e se este par possuir um
arquivo que corresponda a string de busca. Este descritor possui os seguintes campos:
Number of hits:
O número de arquivos que correspondem à string de busca. Os detalhes
individuais de cada arquivo são agrupados. Esta estrutura de agrupamento será descrita
posteriormente.
Port Number: A
porta na qual o par fica escutando para estabelecer uma comunicação.
IP Address: O endereço
do par.
Speed: Velocidade
de transferência em kilobytes por segundos.
Result set: Este
campo possui os detalhes do arquivo. Ele manda o índice do arquivo
armazenado no par hospedeiro (este é um número dado a um arquivo pelo Gnutella), o
tamanho do arquivo em particular, em bytes, e uma string com o nome do arquivo encontrado.
Este campo é terminado por dois caracteres vazios. O índice e o tamanho do arquivo são
ambos de quatro bytes de comprimento. A string para o nome do arquivo é de pelo menos um
byte de comprimento.
Peer ID: Ele apenas
identifica um par na rede.
Push
|
Byte
Positions
|
0
- 15
|
16
- 19
|
20
- 23
|
24 – 25
|
|
Contents
|
Peer
ID
|
File
Index
|
IP
Address
|
Port
|
Se um par se encontra
protegido por um Firewall que não permita conexões externas, o cliente
pode utilizar um descritor “push” para receber os dados. O descritor contém os seguintes
campos:
Peer ID: Esta é
a única identidade de um par que possui o arquivo requerido. Este é campo é
obtido do descritor QueryHit retornado por um determinado par.
File index: Este é o mecanismo pelo qual o par requisitor para indicar qual arquivo ele que do
par com o peer ID. Este índice é obtido pelo descritor Query Hit.
IP Address: É
o endereço do par hospedeiro que contém o arquivo a ser transferido.
Port: Número
da porta pela qual o arquivo é transferido.
Regras de roteamento
para descritores
Para tentar minimizar
a quantidade de tráfego e nós envolvidos na transferência de pacotes
pela rede cada par deve possuir alguma forma de tabela de roteamento. Esta tabela é usada
para determinar quando um determinado descritor foi enviado antes. Desta maneira o par pode
decidir se a mensagem precisa ser encaminha a ou removida da rede.
Assuma a situação
onde um nó A se junta à rede e quer obter informações sobre outros nós.
Ele faz isso enviando um ping ao nó B. Ao receber um ping o nó B verifica sua tabela de
roteamento se já recebeu este ping particular antes. Inicialmente isto não aconteceu. Então
B
inclui os detalhes da mensagem na tabela de roteamento. Depois ele responde para A enviando
um pong contendo seus detalhes. B então encaminha o ping de A para seus vizinhos C, E e F.
Esses nós realizam as mesmas operações de B, armazenando os detalhes nas suas respectivas
tabelas de roteamento se necessário, retornam um pong par A e encaminha a mensagem
adiante. Devido de B ser vizinho desses nós ele irá receber novamente o ping. Porém
ao fazer
a verificação desse ping ele não irá armazenar suas informações e não
encaminhará mais o ping
a seus vizinhos. Quando B receber um pong de seus vizinhos ele encaminhará as informações
de desses nós vizinhos para A.
Se a rede for mais
extensa o ping irá se propagar até que o TTL deste ping se expire, que
ocasionará na remoção da mensagem da rede.
Desta mesma forma
o roteamento é usado para realizar consultas na rede e retornar
QueryHints.
Vantagens
A maior vantagem
do sistema de roteamento do Gnutella é que diferentemente do protocolo
do Napster ele não utiliza um servidor centralizado. Uma menor dependência de um servidor
significa que as falhas nesse sistema irão afetar poucos pares.
Gnutella foi desenvolvido
para transferir qualquer tipo de arquivo, diferentemente do seu
antecessor o Napster que transferi apenas arquivos MP3.
Desvantagens
A maior desvantagem é que quando se utiliza descritores como ping e query, o descritor deve
ser encaminhado pelo nó pata todos os seus vizinhos ou até que o TTL atinja o valor zero.
Isto
significa que um simples ping faz com que os vizinhos também enviem pings podendo gerar
milhares de pongs de retorno. As respostas à esses descritores são enviados de uma maneira
mais eficiente através do caminho percorrido pela requisição inicial.
Outra desvantagem
está no fato de que cada nó deve armazenar algumas informações sobre
quais pacotes foram vistos em um certo período de tempo. Para poder manter um bom
histórico do roteamento de pacotes é necessário que o par possua uma boa disponibilidade
de
memória. Por outro lado se o par possuir pouca memória ele pode ter que interromper
encaminhamentos de pacotes que foram previamente enviados criando tráfego desnecessário
na rede.
O protocolo depende
de que um par produza globalmente um único identificador para uma
mensagem particular. Isto em prática não acontece e como resultado uma falha geral no
sistema pode ocorrer se duas mensagens que supostamente deveriam ser únicas, isto é, foram
enviadas por dois servidores diferentes, acabam tendo o mesmo identificador.
Também ocorrerão
problemas se um par que está prestes a receber arquivos de um outro par
e o par remetente é desconectado da rede e ao ser reconectado recebe um índice diferente.
O
par requerente pode, portanto, estar pedindo um arquivo que não existe ou pedindo o arquivo
errado por estar indexando erradamente no arquivo do sistema. Isto caso também pode
significar que o par pode ter perdido todo o seu histórico de roteamento. |
|
Mensagens JXTA
No JXTA, a comunicação
entre os pares utiliza documentos XML. Mensagens são enviadas
de um par para outro como uma seqüência ordenada de bytes numa simples unidade de
mensagem. Mensagens são enviadas entre pares “endpoints”. Um “endpoint” é
um local em
qualquer rede capaz de receber mensagens no estilo de datagrama. O mapeamento dos
endpoints para um endereço físico é realizado em tempo real pela camada de envio. JXTA
pode usar protocolos de comunicação orientada (TCP/IP) como também pode usar
protocolos de transporte sem comunicação (UDP). Além de aceitar protocolos de transporte
emergentes.
As mensagens podem
ser vistas como envelopes com uma pilha de cabeçalhos de protocolos.
O envelope contém um cabeçalho, sumário da mensagem, endpoint fonte e endpoint de
destino. O endpoint fonte é opcional. O cabeçalho consiste em um rótulo do protocolo
e um
comprimento do corpo da mensagem. O rótulo do protocolo especifica qual o protocolo em
uso. O tamanho do corpo da mensagem depende do protocolo em uso. Quando se usa um
protocolo de comunicação não confiável as mensagens podem chegar ao endpoint mais
de
uma vez, numa ordem diferente da que foi enviada ou pode não chegar. Camadas superiores à
camada de transporte são responsáveis pela retransmissão e duplicação de uma
mensagem.
O corpo da mensagem
também possui uma chave credencial que é usada no endpoint para
identificar o remetente. E também verificar se o remetente tem direito de enviar uma mensagem
para aquele endpoint específico. Esta credencial deve ser usada cada vez que uma mensagem
é enviada.
Pipes do JXTA
Pipes formam um
canal de comunicação virtual usado para enviar e receber mensagens entre
pares. Eles são unidirecionais, “stateless” e promove uma abstração do tipo
de rede utilizada.
Os pipes podem se conectar um ou mais endpoints. Em cada endpoint é ssumido que existe
um software que controlará o envio e recebimento de mensagens usando o pipe. Entretanto
isto não é obrigatório. Cada endpoint possui dois pipes associados. Um pipe de entrada
e um
pipe de saída. Usando o protocolo de ligamento de pipe os pipes separados em tempo real.
Quando um par envia uma mensagem através de um pipe todo os outros pipes conectados à
esse pipe receberam a mensagem.
Os pipes podem
suportar dois tipos de comunicação. Primeiramente existe o modo padrão
ponto-a-ponto. Usando este modo apenas dois pipes não conectados, um pipe de entrada e
um pipe de saída. O pipe de entrada receberá mensagens enviadas através do pipe de saída.
Não existe apoio para uma operação de reposta. Uma informação adicional no
envelope da
mensagem como a chave credencial é usada para tratar as conjuntas. O segundo modo
utilizado é o modo propagado. É quando múltiplos pipes de entrada e de saída são
conectados
para ligar endpoints. Usando este modo, uma mensagem pode ser enviada para todos os pipes
de entrada que estiverem escutando. Também pode causar a duplicação de uma mensagem.
Como conseqüência, esse modo não é o favorito, especialmente quando se tem necessidade
de otimização de velocidade e tempo para a comunicação.
Protocolo de
roteamento de mensagens JXTA
O JXTA utiliza
seis protocolos especialmente desenvolvidos para atuarem em conjunto para
permitir o descobrimento, o monitoramento, a organização e a comunicação entre pares.
Os
protocolos são utilizados para anunciar e descobrir recursos disponíveis. O roteamento de
mensagens permite cooperativamente que todos os pares estejam conectados. Os protocolos
são:
-
Peer Discovery
Protocol
- Peer Resolver Protocol
- Peer Information Protocol
- Pipe Binding Protocol
- Endpoint Routing Protocol
- Rendezvous Protocol
Peer Discovery Protocol
Este protocolo
permite ao pares noticiarem seus recursos e buscarem recursos que estão
disponíveis de outros pares. Os recursos anunciados são representados como documentos
XML. Estes protocolos permitem que pares sejam encontrados sem que conheçam seus
nomes. Usando um processo conhecido como “screening” ele pode também ser usado para
sondar grupos de pares da rede para pares que pertençam a um grupo específico. “Screening”
funciona apresentando cada possível candidato com um nome de grupo de par. Qualquer par
que pertencer ao grupo responderá a mensagem. Uma lista de pares pode ser armazenada
permitindo uma comunicação unicast ao invés de usar mensagens broadcast. Mensagens para
conseguir anúncio de uma certa parte da rede nem sempre retornará uma lista exaustiva e
podia mesmo estar vazia.
Mensagens utilizadas:
Peer Resolver Protocol
Este protocolo
permite pares enviarem uma consulta para um ou múltiplos pares e receberam
uma resposta a uma consulta realizada. A consulta é enviada com uma identidade única que é
usada na resposta para identificar qual resposta pertence a que pergunta. Tais consultas podem
ser enviadas a um grupo intero de pares ou a um par específico. Este protocolo realiza uma
confirmação de mensagens e descarta qualquer mensagem inválida.
Mensagens utilizadas:
Peer Information Protocol
Permite a um par
descobrir informações de status sobre outros pares, isto é, estado, uptime e
capacidades. A mensagem é enviada pelo remetente original contento uma identidade única
q
deve ser utilizada na resposta. Este protocolo pode também ser usado para obter informações
do peer. Na mensagem de resposta cada propriedade é listada como um par nome/valor.
Mensagens utilizadas:
Pipe Binding Protocol
É um mecanismo
que permite aos pares realizarem um canal de comunicação virtual (pipe)
entre dois ou mais pares. Essencialmente ele liga dois finais de um pipe criando um canal
virtual. Pipes são os dispositivos mais utilizados para realizar uma comunicação entre
pares.
Mensagens utilizadas:
Endpoint Routing Protocol
Este protoolo permite
aos pares descobrirem uma rota entre dois pares. Esta rota poderia ser
usada para enviar uma mensagem para um par. Se o par X e o Y desejarem se comunicar mas
ainda não existe um link direto entre os dois este protocolo deve ser usado. Ele encontrará
o
par imediato através da mensagem que será roteada. Se aquela rota estiver interrompida o
protocolo pode ser usado para achar uma rota alternativa.
Mensagens utilizadas:
Rendezvous Protocol
Este protocolo
permite os pares se tornarem membros de um serviço de propagação. Como
membros de um serviço de propagação, pares receberão mensagens e informações
enviadas
por todos os membros daquele serviço. Então se um protocolo permite os pares enviarem
mensagens a todos os membros do serviço. Para se tornar um membro de um grupo de pares
um formulário deve ser obtido listando os requerimentos necessários para que seja efetivada
a
integração. Este formulário é um documento estruturado.
Mensagens utilizadas:
Figura 1– Protocolo de transporte de mensagens
retirada da página http://ntrg.cs.tcd.ie
|
|
Usando apenas ligações
ponto-a-ponto e recursos descentralizados, o Tapestry é uma infra-
estrutura de roteamento e de cobertura de posição que fornece um roteamento independente
da localização de mensagens diretamente a uma cópia mais próxima de um objeto ou
serviço.
O tapestry pode ostentar características como o balanceamento de carga, fault-resilience,
robustez, escalabilidade e auto-organização. |
|
Usando a localização
Plaxton as metas do mecanismo de roteamento do Tapestry são
adaptativas, auto-gerenciáveis e fault-resiliance. A arquitetura de roteamento do Tapestry
eficientemente “roteia” requisições mesmo na presença de falhas nos nós
ou uma carga alta na
rede. Através do uso de aleatoriedade ele realiza o roteamento localmente e carrega a
distribuição. O Tapestry vai lidar com os problemas da rede desviando se das rotas com
falhas, removendo nós sobrecarregado por um serviço, transparentemente mascarando
componentes com falhas e rapidamente adaptando a topologia de comunicação às
circunstâncias que dependem dos tipos de problemas encontrados.
Por ter suas rotas
fortemente ligadas ao mecanismo Plaxton, é apropriado discutir o que é
basicamente o método Plaxton para que se possa entender o mecanismo de roteamento do
Tapestry.
Arquitetura
de roteamento do Plaxton
O mecanismo de
roteamento do Plaxton possui em cada nó mapas de roteamento locais
chamados mapas de vizinhança (neighborhood maps) que incrementalmente “roteiam” as
mensagens cobertas ao local de destino (destination ID). Cada nó possui um mapa de
vizinhaça com múltiplas camadas. Cada camada possui um número de entradas igual à
base do
ID, onde uma de i entradas de uma das j camadas é a ID e o local mais próximo do nó.
Na
intenção de achar o próximo nó, procura-se nos n+1 níveis do mapa, e verifica-se
a entrada
correspondente ao valor do próximo dígito no local de destino. Usando este método de
roteamento num “namespace” de tamanho n e usando ID de base b pode-se garantir que em
no máximo hops lógicos um nó pode ser achado no sistema, assumindo que cada nó
tenha um
mapa de vizinhança consistente.
Como todos os mapas
de vizinhança em cada nó assumem que a predição de dígitos de cada
nó sempre “casa” com o sufixo do nó atual, ele só precisa manter um tamanho
constante b de
entradas em cada nível da rota:
NeighborMapSize = (entries/map) * (# of maps)
= b *
Mecanismo de
busca do Plaxton
Este mecanismo
permite um cliente localizar e enviar mensagens para um objeto encontrado
num servidor. Isto é realizado pelo servidor anunciando que ele possui o objeto. O servidor faz
isto “roteando” a mensagem para o nó raiz, um nó único na rede que é usado
para guardar a
raiz do objeto. De acordo com a finalidade crítica do nó raiz e sendo o único nó
deste tipo faz
com que haja no sistema um ponto único de falha. A publicação (publishing) é
o processo no
qual uma mensagem é enviada ao nó raiz e a cada nó ao longo do caminho entre os locais
onde se encontram armazenados o Object-ID (O) e Server-ID (S).
Por outro lado
um local de consulta permite o cliente enviar mensagem para objetos. Como as
mensagens percorrem um determinado caminho, então é verificado o nó por onde a mensagem
passar. A mensagem é redirecionada ao servidor contendo o objeto se a mensagem encontrar
um nó que possua a informação de localização para o objeto procurado. Senão,
a mensagem é
encaminhada um passo mais próximo da raiz. A informação de localização ou mapeamento
(mapping) para um objeto é a garantia de que este objeto será achado uma vez que a
mensagem atinja a raiz. O mecanismo de roteamento do Plaxton escolhe nós raiz usando um
algoritmo determinístico e globalmente consistente.
O mecanismo
de roteamento e localização do tapestry
As características
principais do mecanismo Tapestry são baseadas fortemente no mecanismo
Plaxton. Como o roteamento Plaxton, todos os nós da rede possuem um mapa de vizinhança
com múltiplos níveis de roteamento e cada entrada descreve a localização do seu
vizinho mais
próximo. O mecanismo de localização do Tapestry é similar o do Plaxton.
No método
Plaxton cada nó armazena apenas informação de localização: <Object-ID (O),
Server (S)> armazena o objeto mais próximo do nó. O Tapestry por outro lado armazena a
informação de localização de todos os objetos. Isto tem um efeito de aumento da
flexibilidade
semântica.
A seção
seguinte explica como o mecanismo Tapestry detecta, opera e se recupera de falhas
(faults) que afetam o roteamento e a funcionalidade da localização.
Fault Handling
Uma decisão
desenvolvida pelo Tapestry foi que componentes que lidam com o problema de
falha de adaptatividade usando de um estado suave para manter armazenado um conteúdo
para uma recuperação mais tranqüila, ao invés de um estado pesado que pudesse necessitar
de
providências de segurança. O conteúdo armazenado é atualizado através de mensagens
regulares. Ao invés de tratar as falhas como um caso especial, o Tapestry lida como se elas
fossem partes de uma operação normal.
Fault-tolerant
Routing
Tabelas corrompidas
de mapas de vizinhança, falhas de servidores e de “links” são tipos de
faltas esperadas que necessitam ser cuidadas pela rede. O sistema deveria, idealmente,
detectar essas faltas rapidamente, operá-las por baixo e recuperar o estado do roteador
quando elas forem corrigidas. O Tapestry confia no “timeout” do TCP para detectar falhas nos
“links” e servidores durante uma operação normal. Cada nó da rede contém
ponteiros de
retorno que enviam pacotes UDP´s regularmente para o vizinho mais próximo. Isto é feito
para
garantir que o roteamento pode ser realizado através daquele nó. Tabelas corrompidas podem
ser facilmente e rapidamente detectadas usando se uma mensagem para verificar a ID de cada
nó que ela passar. O mapa de vizinhança de um nó armazena dois vizinhos de “backup”
em
resposta ao vizinho mais próximo. Se o vizinho primário de um nó falhar então o
nó utiliza um
dos seus vizinhos de “backup” no lugar. Quando um nó falha, ele é geralmente encontrado
e
reparado rapidamente. Ao invés do nó remover o nó falhado do seu mapa de vizinhança
este
nó é indicado como inválido. O roteamento é então realizado através de
uma rota alternativa
até que o nó seja restaurado. Entretanto o nó permanecerá como inválido na
rede apenas por
um período fixo de tempo para dar uma chance de ele ser reparado. Mensagens de uma rota
falhada são verificadas para observar o momento em que esta rota foi reparada. Se após um
tempo específico o reparo do nó não for realizado então o nó é removido
do mapa de
vizinhança. Este processo é realizado a fim de que se possa evitar uma cara reinserção
dos nós
recuperados.
Fault-tolerant
Location
No mecanismo do
Plaxton o nó raiz é vulnerável no sentido de que ele se torna um ponto único
de falha. No Tapestry múltiplos nós raiz são usados. Cada objeto terá agora várias
raízes
atribuídas a ele. Durante o processo de publicação (publishing) descrito anteriormente
os nós
raízes são usados para inserir informações de localização nos nós.
Os objetos armazenados em
intervalos regulares têm suas informações de localização republicadas por servidores
de
armazenamento.
Surrogate Routing
O Tapestry utiliza
um mecanismo de roteamento substituto, que é na realidade apenas um
algoritmo distribuído que incrementalmente computa um único nó raiz. Este algoritmo é
determinístico, escalável, e pode chegar a resultados consistentes de qualquer ponto na rede.
O roteamento substituto opera escolhendo um objeto do nó raiz que tem o mesmo nome da
sua ID. Isto é, entretanto, improvável devido à natureza escassa do “namespace”
dos nós. O
Tapestry funciona como se o nó não existisse tentando “rotear” para ele. Uma rota
para um
identificador não existente irá encontrar entradas de vizinhos vazia em várias posições
ao longo
do percurso. Aqui, o algoritmo seleciona um “link” existente que aja como uma alternativa
a
um link desejado. Esta seleção é feita através de uma seleção determinística
entre ponteiros de
vizinhos existentes. O roteamento termina uma vez que um mapa de vizinhança foi alcançado
onde a única entrada não nula pertence ao nó atual. Aquele nó é então
designado como uma
raiz substituta para o objeto. |
|
Kademlia é
um sistema de informação P2P que retorna um resultado de uma busca completa
em uma rede com um tempo de O(), onde o n é o número de nós que existem na rede.
Obviamente este esquema é extremamente escalável, mas deve ser realizado de um “outset”
que um dado pedaço do conteúdo deve estar num nó em particular para ser achado e
recuperado. Dado isto, nenhuma conta é aceita de uma largura de banda disponível para um
nó, um PC com uma conexão discada de 56kbps pode esperar hospedar, por exemplo, um
grande arquivo de media, e disponibilizar para quem o quiser. Certamente o sistema não é
preparado para um compartilhamento em larga escala como o Napster, mas sim para
armazenar arquivos distribuídos numa rede de alta velocidade e de razoável homogeneidade.
Chaves e conteúdo
Para se decidir
onde o pedaço do conteúdo deve ser colocado na rede, um “hash” de 160-bits
é primeiramente obtido. Os “Hashes” devem ser únicos para cada arquivo. Podemos
imaginar
um esquema de “hashing” onde um arquivo é dividido em 160 partes e o primeiro bit de
cada
parte é guardado. Estes 160 bits podem ser usados como nosso “hash”, e dessa maneira
seria
muito difícil achar dois “hash” iguais para dois arquivos diferentes. Kademlia usas uma
técnica
similar a esta. Um “hash” é obtido e passaremos a se referir a ele como uma chave. Um
arquivo (ou outro conteúdo) é chamado de valor, e no Kademlia o par chave/valor é
armazenado no nó que possui a identidade (nodeID) de 160 bits mais próxima da chave. O
conceito de proximidade será discutido posteriormente. O conteúdo deve estar situado neste
nó em particular para que ele possa ser facilmente encontrado. Por esta razão o Kademlia é
tido como uma tabela de “hash” distribuída (Distributed Hash Table). De forma a encontrar
um
arquivo, o Kademlia simplesmente obtém a chave desse arquivo é o retira do nó que possui
a
identidade mais próxima dessa chave. A responsabilidade ter que armazenar o conteúdo de
outros faz com que o Kademlia provavelmente não possa ser usado como um compartilhador
de arquivos da maneira com que o Napster e o Gnutella foram.
Distância
Dado que um pedaço
de um conteúdo pode ter qualquer chave de 160 bits, mas apenas uma
fração dos 160 bits da identidade do nó são usados, deve existir um meio de decidir
onde
armazenar um conteúdo ao qual a chave não é exatamente igual a qualquer outra chave.
O
Kademlia resolve este problema inventando uma maneira de aproximação entre dois números
de 160 bits. Estamos nos referindo a uma métrica XOR, porque quando fazemos a operação
de XOR entre dois números obtemos sua diferença, que é tratada como uma distância.
Um
par chave/valor é então armazenado num nó com identidade próxima à da chave.
Esta métrica
é também usada para determinar quão próximo se encontram dois nós, o que importante
quando se realiza uma busca.
Busca
Cada nó da
rede mantém contato informando para apenas outros Logn outros nós que estão
conectados a ele. A informação é composta de identidade do nó (nodeID), endereço
IP, e
porta UDP do nó. Podemos pensar na rede como uma árvore binária de nós organizados
de
acordo com suas identidade (veja a figura abaixo). Qualquer nó dado deve possuir um contato
em cada sub-árvore na qual ele não está contido.
Figura 2
Na realidade cada
nó possui múltiplos (tipicamente 20) contatos em suas sub-árvores. Para
cada sub-árvore os contatos são armazenados num balde (bucket). A figura abaixo mostra um
exemplo onde cada balde guarda no máximo dois contatos.
Figura 3
De maneira a encontrar
uma chave em particular, o nó primeiramente determina a sub-árvore
que contém o nó desejado (baseado no início da chave). Então ele pede a todos os
seus
contatos daquela sub-árvore que o retornem seus contatos. O nó que fez a requisição
então
analisa os contatos e encontra contatos mais próximos do seu alvo. A cada passo a distância é
reduzida em até 50 % até que o alvo é atingido.
Nós entrando
e saindo
Assim que um nó
pede a outro seus contatos, o nó chamado armazena na usa lista de contato
o nó que o chamou. Este é o primeiro mecanismo pelo qual a tabela de roteamento de cada nó
se mantém atualizada. A propriedade simétrica do XOR permite que um nó possa ter o direito
de distribuir seus contatos, isto é, ele terá igual número de contatos que qualquer nó
na figura
3. Dado que cada balde de contatos tem uma capacidade finita se torna necessário descartar
algum contato ao gravar um novo. O Kademlia implementa uma política dos “recentemente
visitados”, removendo contatos que não se tem se escutado a um grande período de tempo.
Quando um nó
se junta à rede ele agrega alguns contatos de um nó arbitrário e os utiliza para si
próprio. Eles então realizam uma busca para eles próprios. Isto resulta num chamado a
outros
nós, o que faz com que eles sejam avisados quanto a presença desse novo nó. Porque uma
nova identidade foi atribuída, o novo nó pode ter se tornado o nó mais próximo de
alguma
chave. Uma vez avisados quanto a isso, os nós mais próximos replicaram o par chave/valor
apropriado para o novo nó. Desta maneira todos os pares chave/valor serão encontrados em
seus respectivos nós. |
|
A segurança é um componente essencial para qualquer sistema de computação e é
especialmente relevante para sistemas P2P. Neste capítulo iremos abordar alguns tópicos
principais de segurança de sistemas P2P como: necessidade de segurança, conseqüências
de
uma segurança fraca, métodos de segurança e o futuro da segurança. |
|
Nestes dias turbulentos
podemos pensar que a segurança P2P é o menor dos problemas do
mundo. Entretanto fraudes nas grandes corporações e perdas de receitas devidos a ataques a
redes internas tem trazido o P2P para a linha de frente no mundo de TI (tecnologia da
informação) O Napster foi o pioneiro mas desde que ele passou a travar brigas judiciais mais
e
mais aplicações P2P têm causado dores de cabeça nas grandes corporações
mundiais. Com
um protocolo de segurança bem desenvolvido essas dores de cabeça poderiam ser revertidas
em recursos valiosos para essas empresas.
O diagrama abaixo
ilustra as fendas na segurança quando usamos aplicações P2P. Podemos
observar que permitindo que essas aplicações sejam colocadas nas rede, essas redes passam
a
correr um risco enorme.
Figura 4- Fendas na segurança de rede com aplicações
P2P retirada da página http://ntrg.cs.tcd.ie
Seguindo este ponto
de vista, devemos estar preocupados de em nos defendermos de nós
mesmos. Os pontos mais importantes para isso são: controle de conexão, controle de acesso,
controle de operação, antivírus e é claro a proteção dos dados armazenados
nos nossos
computadores.
Ameaças externas
As redes P2P permitem
que sua rede principal seja aberta a várias formas de ataque, breack-
in, espionagens e danos maliciosos. O P2P em si não trás nenhuma nova ameaça a rede
apenas os familiares como worms e vírus.
As redes P2P também
podem permitir que um funcionário faça “download” e utilize materiais
sem permissão e que violem as leis de direitos autorais, e compartilhe arquivos desta mesma
maneira. Aplicações como Napster, KaZaa, Grokster e outros têm sido populares entre os
amantes de música e usuários de Internet por vários anos, e muitos funcionários
tiram vantagem
das redes de alta velocidade para fazer “downloads” de arquivos nos seus locais de trabalho.
Esta situação representa numerosos problemas para uma rede corporativa que utilizam grandes
largura de banda e estão sujeitos a ataques de vírus através de arquivos infectados que
foram
baixados através das redes P2P.
Roubo (Theft)
Empresas podem
perder milhões em propriedades tal como o código fonte que disfarçados em
outros arquivos usando tecnologias do P2P. Ferramentas de “warpping” como Warpstar
(freeware) pode disfarçar um arquivo “.zip” contendo um código fonte de uma empresa,
em
um arquivo de música MP3. Como resultado um cúmplice de fora da empresa pode acessar o
KaZaa e transferir o arquivo disfarçado. Para a segurança dessas companhias esta ação é tida
como uma transação normal, mesmo que as empresas não permitam que os seus funcionários
façam compartilhamento de músicas usando P2P.
Obstrução
da largura de banda e compartilhamento de arquivo
Aplicações
P2P como o KaZaa, Gnutella e FreeNet tornam essas ações possíveis para um
computador que compartilha arquivos com outros localizados em outras localidades na
Internet. O maior problema com o compartilhamento de arquivos é que eles resultam num
enorme tráfego que obstrui a rede das instituições. Isto afeta a comunicação
dos usuários
internos da rede assim como clientes de e-business o que resulta em perdas de capital para a
empresa.
Bugs
Para que as aplicações
de compartilhamento de arquivo funcionem apropriadamente o
software correto deve ser instalado no sistema dos usuários. Se este software contém um
“bug” isto pode expor a rede a inúmeros ricos.
Quebra de criptografia
Processamento distribuído é outra aplicação P2P. Pegar vários computadores e interligá-los
resulta numa enorme capacidade computacional para solucionar problemas complicados.
Distributed.Net é um exemplo proeminente deste tipo de aplicação. Em 1999 Distributed.Net
junto com o Eletronic Frontier Fondation ( www.eff.org
) lançaram um ataque força bruta no
algoritmo de criptografia de 56 bits DES. Eles quebraram o DES em menos de 24 horas. O
Distributed.Net tinha capacidade de testar 245 bilhões de chaves por segundo. Naquele tempo o
DES era o algoritmo de criptografia mais forte que o governo dos Estados Unidos permitiam
exportar.
Trojans, vírus
e Sabotagens
Um usuário
de um sistema P2P pode sem querer instalar um arquivo contaminado em sua
maquina que pode causar sérios danos. Por exemplo, um pedaço de código que possa parecer
familiar ou um programa de compartilhamento de arquivos poderia incluir uma “backdoor” que
permita o acesso a outros usuários de computadores. Um infrator poderia ser capaz de causar
sérios danos ou obter informações sigilosas.
Usuários de
sistemas P2P poderiam facilmente configurar suas aplicações para expor
informações confidenciais para ganho próprio. Aplicações de compartilhamento
de arquivos
podem resultar uma perda de controle de quais dados estão sendo enviados para fora de uma
organização.
Aplicativos P2P
burlam arquiteturas de segurança do mesmo modo que os Trojans fazem. A
aplicação P2P é instalada em “dispositivos confiáveis” que permitem a
comunicação através do
Firewall corporativo com outros usuários P2P. Uma vez estabelecida a comunicação o usuário
externo pode ter acesso remoto ao dispositivo confiável com o propósito de roubar dados
confidenciais da corporação, lançar um ataque de “Denial of Service” ou simplesmente
garantir
o acesso aos recursos da rede.
Acesso “backdoor”
Os aplicativos
P2P mais difundidos como KaZaa, Morpheus e Gnutella não foram
desenvolvidos para o uso em grandes corporações e o resultado dessa utilização introduz
sérios riscos de segurança de rede paras empresas. Por exemplo, se um usuário iniciar
o
Gnutella e então usar a Intranet da empresa para acessar a caixa de e-mail, um infrator usar
esse “backdoor” para ter acesso à LAN corporativa.
“Instant
Message” (IM) não criptografada
Os aplicativos
de “Instant mensage” (IM) como MSN, ICQ e o fornecido pela AOL também
são uma ameaça às informações de uma companhia. Se esses aplicativos são
usados a respeito
de informações sigilosas, o infrator pode ler todas as mensagens que são enviadas e recebidas
através da rede ou da internet utilizando um programa de monitoramento de rede.
Aplicações
de IM têm sido desenvolvidas e incrementadas com novas capacidades como
mensagem de voz e compartilhamento de arquivos. Adicionando o compartilhamento de
arquivo também são adicionados todos os riscos que este tipo de aplicação trás
como foi
apresentado anteriormente.
Confidencialidade
O KaZaa e o Gnutella dão acesso direto à arquivos armazenados nos discos rígidos
de outros
clientes. Como conseqüência é possível para um “hacker” descobrir qual
o sistema operacional
o computador hospedeiro possui e conectar a pastas que não estão permitidas para
compartilhamento obtendo assim acesso a informações sigilosas e arquivos de sistema.
Autenticação
Existe também
a questão da autenticação e autorização. Quando usamos um sistema P2P
temos que ser capazes de identificar se quando um par quiser acessar uma informação esse
usuário realmente é quem ele diz ser e só então autorizar a informação.
Ameaças Internas
Assim como as ameaças
externas existem algumas ameaças internas que deve ser discutidas.
Interoperabilidade
É a área
de maior interesse de segurança a respeito de redes P2P. A introdução de diferentes
plataformas, diferentes sistemas e diferentes aplicações trabalhando juntas numa dada infra-
estrutura abre uma série de questões a respeito de segurança que é associado com
a
interoperabilidade. Quanto maiores forem as diferenças dentro de uma infra-estrutura, maiores
serão os problemas de segurança associados.
Negócio
privado numa rede pública
Muitas companhias
conduzem negócios particulares através de redes públicas. Isto leva a
exposição do sistema a diversos riscos de segurança. Esses riscos devem ser endereçados
de
maneira a evitar a responsabilidade vinculada ao seu uso.
Adicionar e remover usuários
Deve existir um
método praticável para adicionar/deletar usuários para/da rede sem
acrescentar vulnerabilidade. O sistema esta sobre a ameaça de usuário que conhecem todas as
entrada e saídas do sistema, por exemplo, a existência de “trapdoors” etc.
Segurança
geral
P2P compartilha
muitos problemas de segurança e soluções com o resto da rede e sistemas
distribuídos. Por exemplo, dados corrompidos, transferência não confiável, problemas
de
latência e problemas de identificação etc.
Perigos da distribuição
Quando usamos aplicações
com processamento distribuído é pedido ao usuário para baixar,
instalar e rodar um arquivo executável na sua estação a fim de que ele possa participar.
Uma
negação de serviço (denial of service) poderia acontecer se o software for incompatível
ou se
ele estiver com algum “bug”.
O problema das
pessoas
Sempre existirão
usuários maliciosos que tem a intenção de ganharem acesso clandestino às
redes corporativas. E não importando qual o protocolo de segurança é colocado para impedir
a ação desses usuários, com o tempo eles encontraram um jeito de burlar esses protocolos.
Então o que os mecanismos de segurança precisam fazer é se manterem à frente desses
“hackers” criando cada vez maiores e melhores protocolos. Mas isto não tão simples
de ser
realizado. |
|
Todos os sistemas
de segurança atuais são baseados em criptografia que utiliza tanto chave
simétrica/privada quanto chave assimétrica/publica, ou às vezes uma combinação
das duas.
Nesta sub-seção iremos introduzir os aspectos básicos das técnicas das chaves públicas
e
privadas e compara-los as características principais.
Técnicas
da chave privada
As técnicas
de chave privada são baseadas no fato de que o remetente e o destinatário
compartilham um segredo, que é alterado através de várias operações de criptografia
como a
encriptação de decriptação de mensagens e a criação e verificação
de dados de autenticação
de mensagens. Essa chave pública deve ser trocada através do um processo fora do campo
anterior para a comunicação pretendida (Usando um PKI, por exemplo).
Técnicas da chave pública
Técnicas de
chave pública são baseadas nos pares de chaves assimétricas. Geralmente cada
usuário está em posse de apenas um par de chaves. Uma das chaves do par está publicamente
disponível enquanto que a outra está privada. Porque uma chave está disponível não é
necessária uma troca de chave fora da banda “out of band”, entretanto existe a necessidade
de
uma infra-estrutura para distribuir a chave pública autenticavelmente. Já que não é
necessário
um pré-compartilhamento dos segredos anteriores para a comunicação, as chaves públicas
são
ideais para apoiar segurança entre partes previamente conhecidas.
Par de chaves
assimétricas
Diferente de uma
chave da porta da frente, que permite ao seu portador bloquear ou
desbloquear esta porta com igual facilidade, a chave pública utilizada na criptografia é
assimétrica. Isto significa que a chave consegue encriptar uma mensagem com extrema
facilidade, porém decriptar como um todo, é considerado muito difícil.
Além disso,
sendo uma função de “mão única”, as chaves públicas cripitográficas
também
funcionam como “trapdoors”. O inverso pode ser obtido se a chave privada é conhecida. |
|
Mecanismos para
estabelecer uma criptografia forte e verificável são muito importantes. Estes
mecanismos são padrões de protocolos de autorização que permitem que pares assegurem
que eles estão falando com o sistema remoto pretendido.
Protocolo Secure
Sockets Layer (SSL)
Para uma proteção
das informações transmitidas em uma rede P2P, alguns sistemas empregam
o protocolo padrão Secure Sockets Level (SSL). Este protocolo garante que um arquivo e
eventos enviados cheguem intactos e invisíveis para qualquer um que um que não seja o
destinatário. Além disso, porque todos os pares usam SSL, ambos os lados automaticamente
provam quem eles são para cada um antes de transferirem qualquer informação pela rede.
O
protocolo providencia mecanismos de comunicação que são à prova de adulteração
e
confidenciais, usando as mesmas técnicas utilizadas pela maioria dos “webmasters” que
protegem usuário em transações financeiras transmitidas pela Internet.
Tecnologia IPSec
A maioria das VPN´s
(Virtual Private Networks) utilizam a tecnologia IPsec, o “framework”
que envolve vários protocolos que tem sido o padrão para vários especialistas. O IPsec é útil
porque ele é compatível com os mais diferentes tipos de hardware e software para VPN, e é
o
mais para redes com clientes com acesso remoto. O IPsec requer pouco conhecimento para
os cliente, porque a autenticação não é baseada no usuário, o que significa
que um “token”
(como um Secure ID ou um Crypto Card) não é utilizado. Invés disso, a segurança
vem do IP
da estação ou o seu certificado (e.g. X.509), que estabelece a identidade do usuário
e garante
sua integridade na rede. Um túnel IPsec basicamente age como uma camada de rede que
protege todos os pacotes de dados que passa por ela qualquer que seja a aplicação.
Infra-estrutura
de chave pública (PKI)
A Public Key Infrastruture
(PKI), toda caracterizada pelo X.509 sobre um “backbone” de
rede SSL. Essa combinação de X.509, autenticação PKI e encriptação de
transporte SSL é o
estabelecimento de um padrão criptográfico para o “e- commerce” na Internet.
Este padrão
permite certificados de segurança da Endeavors, ou de qualquer outra
reconhecida autoridade do certificado X.509, para fornecer uma identidade verdadeira a
qualquer par que surja na rede. O uso da encriptação de segurança ponto-a- ponto SSL
habilita cada par de “peers” que se comunicam a terem uma única chave. A vantagem é
que
quando um peer deixa a comunidade, todas as suas chaves únicas se tornam inválidas, mas as
chaves entre os outros membros da comunidade não são afetadas. |
|
As redes P2P têm
recebido cada vez mais atenção ao longo da sua existência. Cada vez mais
as pessoas tendem a compartilhar seus recursos e a necessitarem de cada vez mais segurança,
pois a industria da infração eletrônica também acompanha essa evolução.
Muitas propostas
já estão sendo estudadas. Pessoas estão percebendo que a segurança é uma
área muito importante para a credibilidade de uma aplicação P2P.
Usuários
ganhando confiança própria
Uma área de
estudo proposta recentemente é a que os usuários ganhem confiança dentro de
uma comunidade P2P. Todos os usuários devem possuir uma única assinatura digital, como um
IP, mas por usuários não por máquinas. Associada a esta assinatura deverá existir
um nível de
confiança varie de acordo com uma escala. Dependendo do comportamento do usuário o seu
grau de confiança deve aumentar ou diminuir.
A proposta é
que todos os usuários comecem com o grau de confiança mais baixo. Isto ocorre
para impedir que usuários não desejados entrem no sistema e criem novas contas e aumente os
seus próprios níveis de confiança imediatamente. Os usuários tem que estar ativos
na rede por
um certo período de tempo, antes que seus nível de confiança atinja níveis melhores.
Os
usuários também podem guardar seu locais confiáveis em disco, para que ele possa
compartilhar seus recursos sem precisar passar pela política de níveis de confiança.
Biometria
A biometria envolve
o uso de uma característica pessoal para autenticar o usuário.
Características que são comumente usadas incluem uma imagem facial da pessoa, uma
assinatura, uma impressão digital ou um padrão de retina. A vantagem da característica
biométrica é que os usuários não precisam lembra nenhuma senha ou armazenar nenhuma
chave, que são as maiores fraquezas num sistema de autenticação convencional.
Ultimamente, a
tecnologia tem encontrado um papel mais forte como uma integração e
complementação de um sistema de autenticação maior, talvez um em combinação
com um
certificado criptográfico mencionado acima, ao invés de defender um ponto singular de defesa.
Criptografia
por chave quântica
Muitos sistemas
de encriptação modernos dependem da dificuldade em realizar um ataque de
força bruta às chaves privadas, devido às restrições de processamento e de
tempo. Embora
ainda no estágio teórico, a melhoria de desempenho dado por um hipotético computador
quântico renderia uma quantidade bem inferior de algoritmos.
Obviamente novos
algoritmos de criptografia serão necessários. Criptografia quântica utiliza os
estados dos fótons como chaves para codificar informações. De acordo com Heisenberg, é
impossível descobrir ambos o momento e a posição de um fóton em um dado instante
de
tempo. Entretanto, em teoria um invasor não poderia descobrir uma chave privada baseando-
se na informação do estado do fóton; o invasor teria que ter o fóton atual para
decifrar
qualquer dado encriptado com uma chave.
Infelizmente este
conceito é, para o momento, muito complexo para ser implementado. Os
cientistas da IBM construíram o primeiro protótipo funcional de uma chave de distribuição
quântica (QKD) no final dos anos 80. Ainda está muito longe, mas já pudemos observar
grandes progressos nestas áreas. E embora nós não possamos ver o QKD no mercado por
ainda um bom tempo, a tecnologia soa incrivelmente promissora. |
|
Com
o tempo podemos observar que a tecnologia P2P vem crescendo
assustadoramente, porque hoje em dia praticamente todos os computadores
pessoais possuem alguma forma de aplicação que utilizam conceitos
P2P. E por causa da estrutura de rede existente desde o nascimento
da Internet estes sistemas só tendem a denegrir mais e mais
as condições de tráfego na rede. Já atentando para este fato
começam a surgir tecnologias simétricas de conexão de rede já
visando o tráfego que realmente está mais em foco no momento
por causa das aplicações P2P.
No caso da segurança é obvio pelas afirmações
acima que se trata de uma questão muito importante ainda mais
quando se trata de desenvolvimento de sistemas P2P. No momento,
talvez essas questões sejam o fator principal da inibição de
um crescimento ainda maior desses sistemas. È necessário que
todos os usuários se comprometam a utilizar os métodos P2P de
maneira mais responsáveis e quando qualquer descoberta em relação
a alguma falha geral de proteção de algum sistema que seja reportada
imediatamente.
|
|
|
|
|
|
|
|
O que são
redes Peer-to-peer?
São redes
onde todos os computadores que a compõe possuem os mesmos direitos e as
mesmas reponsabilidades, isto é, todos funcionam como clientes e servidores se comparados
com o sistema convencional. |
|
Descreva os dois
tipos de arquitetura de redes utilizadas em sistema P2P?
Arquitetura centralizada
onde existe um servidor (diretório) que armazenas diversas
informações de cada nó da rede e realiza o controle da transferência de arquivos
entre os
pares.
Arquitetura descentralizada
que não possui servidor central e todo o controle é feito através de
troca de mensagens entre os pares e através de protocolos rígidos de comunicação. |
|
Cite o nome de
cinco aplicativos desenvolvidos utilizando os métodos de transferência P2P?
Napster, Gnutella,
Morpheus, KaZaa, FreeNet |
|
Explique como funciona
um mecanismo de busca simples em uma rede descentralizada?
Quando um par faz
uma consulta, esta consulta é transmitida para todos os seus pares vizinhos.
Se um par vizinho não fornecer resultados então esta consulta e transmitida para os pares
vizinhos do vizinho. Se o recurso é encontrado, aquele par envia uma mensagem para o par
que originou a consulta indicando que encontrou resultados para a consulta, e então estabelece
uma conexão P2P.
Cada consulta tem
um contador de TTL (Time-To-Live). Tipicamente, o TTL é ajustado entre
cinco e sete, e o valor é decrementado à medida que a consulta passa por um nó. Outro
contador informa o número de saltos (hops). Uma vez que o contador TTL atinge o valor zero,
a consulta é então descartada. |
|
Cite dois tipos
de ameaça externas e dois tipos de ameaças internas em uma rede P2P e
explique como elas ocorrem?
Confidencialidade:
O KaZaa e o Gnutella dão acesso direto à arquivos armazenados nos
discos rígidos de outros clientes. Como conseqüência é possível para um “hacker”
descobrir
qual o sistema operacional o computador hospedeiro possui e conectar a pastas que não estão
permitidas para compartilhamento obtendo assim acesso a informações sigilosas e arquivos de
sistema.
Autenticação:
Existe também a questão da autenticação e autorização. Quando usamos um
sistema P2P temos que ser capazes de identificar se quando um par quiser acessar uma
informação esse usuário realmente é quem ele diz ser e só então autorizar
a informação.
Negócio privado
numa rede pública: Muitas companhias conduzem negócios particulares
através de redes públicas. Isto leva a exposição do sistema a diversos riscos de
segurança.
Esses riscos devem ser endereçados de maneira a evitar a responsabilidade vinculada ao seu
uso.
Adicionar e remover usuários:
Deve existir um método praticável para adicionar/deletar
usuários para/da rede sem acrescentar vulnerabilidade. O sistema esta sobre a ameaça de
usuário que conhecem todas as entrada e saídas do sistema, por exemplo, a existência
de
“trapdoors” etc. |
|
|
|
|
|
1. Resumo
