Download - TCC - Estudo de Aplicações Dstribuidas P2P
EDUARDO SPONHOLZ
FRANCISCO RICARDO ANDRASCHKO
ESTUDO DE APLICAÇÕES DISTRIBUÍDAS P2P
PONTA GROSSA
2008
UNIVERSIDADE ESTADUAL DE PONTA GROSSA
SETOR DE CIÊNCIAS AGRÁRIAS E DE TECNOLOGIA
DEPARTAMENTO DE INFORMÁTICA
EDUARDO SPONHOLZ
FRANCISCO RICARDO ANDRASCHKO
ESTUDO DE APLICAÇÕES DISTRIBUÍDAS P2P
PONTA GROSSA
2008
EDUARDO SPONHOLZ
FRANCISCO RICARDO ANDRASCHKO
ESTUDO DE APLICAÇÕES DISTRIBUÍDAS P2P
Monografia apresentada para obtenção da titulação de Bacharel em Informática no curso de graduação em Bacharelado em Informática, Setor de Ciências Agrárias e de Tecnologia da Universidade Estadual de Ponta Grossa - Paraná.
PONTA GROSSA
2008
RESUMO
Com o advento da internet e da computação distribuída, soluções como
redes P2P vêm popularizando-se cada vez mais. Em seu inicio P2P era apenas para
troca de mensagens, mas com seu crescimento veio também sua melhoria. Devido
ao crescente acesso a internet e à vantagem de atuação remota sobre redes
convencionais cliente-servidor, surgiu então à necessidade de ampliação de sua
aplicabilidade, levando ao modelo atual de compartilhamento de arquivos, recursos
e informações diversas. Para isso ferramentas específicas ao desenvolvimento P2P
foram necessárias. Plataformas como JXTA, GDK e .NET têm auxiliado a firmar
estas redes num lugar de destaque entre as demais redes, formalizando sua
arquitetura descentralizada (ausência de servidor dedicado) e seu propósito de
compartilhamento de informações.
Palavras chave: Redes P2P, Plataforma JXTA, Compartilhamento de Arquivos e
Recursos.
SUMÁRIO
1 INTRODUÇÃO ...................................................................................................... 1
1.1 RELEVÂNCIAS DO TRABALHO .................................................................... 1
1.2 PADRONIZAÇÃO ........................................................................................... 3
1.3 OBJETIVOS ................................................................................................... 6
1.4 ORGANIZAÇÃO DO TRABALHO................................................................... 6
2 METODOLOGIA ................................................................................................... 7
3 REDES P2P .......................................................................................................... 8
3.1 VANTAGENS P2P .......................................................................................... 9
3.2 DESVANTAGENS P2P .................................................................................. 9
3.3 ARQUITETURA P2P .................................................................................... 10
3.3.1 COM SERVIÇO DE LOCALIZAÇÃO CENTRALIZADA ..................... 11
3.3.2 BASEADA EM INUNDAÇÃO ............................................................. 12
3.3.3 BASEADA EM REDES DE SUPERPOSIÇÃO ................................... 14
3.4 COMPARATIVO ENTRE ARQUITETURAS P2P ......................................... 15
3.5 ALGORITMOS P2P ...................................................................................... 18
3.6 EXEMPLOS DE SISTEMAS P2P ................................................................. 19
3.6.1 NAPSTER .......................................................................................... 19
3.6.2 SETI@HOME ..................................................................................... 20
3.6.3 FREENET .......................................................................................... 20
4 PLATAFORMAS DE DESENVOLVIMENTO ....................................................... 22
4.1 JXTA ............................................................................................................. 22
4.1.1 CAMADAS JXTA ................................................................................ 23
4.1.2 GRUPOS............................................................................................ 25
4.1.3 AVISOS .............................................................................................. 26
4.1.4 PIPES E MENSAGENS ..................................................................... 27
4.1.5 PROTOCOLOS .................................................................................. 27
4.1.5.1 PEER DISCOVERY PROTOCOL – PDP .................................. 28
4.1.5.2 PEER RESOLVER PROTOCOL – PRP .................................... 28
4.1.5.3 PEER INFORMATION PROTOCOL – PIP ................................ 28
4.1.5.4 RENDEZVOUS PROTOCOL – RVP ......................................... 29
4.1.5.5 PIPE BINDING PROTOCOL – PBP .......................................... 29
4.1.5.6 ENDPOINT ROUTING – PEP.................................................... 30
4.1.6 DESENVOLVIMENTO P2P UTILIZANDO JXTA ................................ 30
4.1.6.1 IMPLEMENTAÇÃO DO PEER................................................... 31
4.1.6.2 ORGANIZAÇÃO DAS CLASSES .............................................. 32
4.1.6.3 EXEMPLO DE IMPLEMENTAÇÃO ........................................... 33
4.1.6.4 JXTA SHELL.............................................................................. 34
4.1.6.5 .NET .......................................................................................... 35
4.1.6.6 GROOVE DEVELOPMENT KIT (GDK) ..................................... 35
4.1.7 PADRONIZACAO POR XML ............................................................. 36
4.1.8 DESEMPENHO JXTA ........................................................................ 37
5 CONCLUSÃO ..................................................................................................... 38
6 REFERÊNCIAS .................................................................................................. 39
i
LISTA DE FIGURAS
Figura 1 - Modelo de Rede Centralizada (cliente-servidor) (ASTIAZARA,
2008) ................................................................................................. 2
Figura 2 - Modelo de Rede Descentralizada (ARNAUTH, 2008).......................... 2
Figura 3 - Protocolo TCP/IP, suas camadas e seus agentes.
(REMOALDO, 2008) ......................................................................... 5
Figura 4 - Exemplo de serviço de localização centralizada (APPLIED
META COMPUTING, 2000) .............................................................. 12
Figura 5 - Rede Baseada em Inundação (APPLIED META
COMPUTING, 2000) ......................................................................... 13
Figura 6 - Arquitetura de Super-Peers e peers convencionais (STOICA,
MORRIS, KARGER, KAASHOEK, & BALAKRISHNAN,
2001) ................................................................................................. 15
Figura 7 - Arquitetura de Rede Virtual JXTA (PROJETO JXTA, 2007) ................ 23
Figura 8 - Estrutura das camadas lógicas JXTA (PROJETO JXTA, 2007) .......... 24
Figura 9 - Empilhamento de protocolos JXTA (PROJETO JXTA, 2007) .............. 28
Figura 10 - Demonstração do protocolo RVP (PANISSON, 2007) ....................... 29
Figura 11 - Demonstração do protocolo PEP (PANISSON, 2007) ....................... 30
Figura 12 - Exemplo de retorno das funções executadas (LIMA, 2005) ............... 34
ii
LISTA DE TABELAS
Tabela 1 - COMPARATIVO ENTRE AS ARQUITETURAS P2P
(FRANCESQUINI, 2004) ................................................................... 16
1
1 INTRODUÇÃO
1.1 RELEVÂNCIAS DO TRABALHO
A integração de recursos computacionais em larga escala através de redes
de alto desempenho interligadas pela rede mundial de computadores (Internet), tem
permitido que novas idéias e técnicas de computação sejam desenvolvidas. A rede
mundial de computadores pode ser considerada, devido ao grande número de
tecnologias de softwares utilizadas como um grande sistema distribuído.
Sistemas computacionais distribuídos, em princípio são caracterizados por
um grande conjunto de recursos interligados com o intuito de compartilhar conteúdo,
melhorar o desempenho no processamento, tornar os recursos tolerantes a falhas e
obter paralelismo entre os usuários que utilizam o sistema (COULOURIS,
DOLLIMOREM, & KINDBERG, 2001).
Redes de computadores são os meio encontrados pelos sistemas
distribuídos para atuação, onde dois são os modelos mais vistos: Centralizado e
Descentralizado.
A organização da estrutura cliente-servidor (centralizado) nos sistemas
distribuídos sugere a interligação de uma estação cliente atuando como
Requisitante, com constantes solicitações a estação servidor, o qual atuará como
Processante, limitando-se a processar e responder os pedidos (do Cliente).
A Erro! Fonte de referência não encontrada. a seguir ilustra um modelo
de rede centralizada, ou seja, um servidor central e n estações clientes conectado a
ele. Um ou mais clientes podem requisitar ao servidor, porem estes apenas
solicitarão processamentos e ficarão aguardando o retorno do servidor, o qual
também apenas processa e retorna, ficando impossibilitado de requisitar.
2
Diferente da centralizada, a arquitetura descentralizada assume que cada
estação poderá tanto requisitar quanto responder pedidos, o que torna cada estação
tanto em cliente como servidor. O nome descentralizado vem daí, pois não contem
um servidor centralizador.
A Erro! Fonte de referência não encontrada. ilustra uma rede
descentralizada, onde todos os computadores se comunicam, podendo requisitar e
responder simultaneamente, sem a necessidade de autorização de um servidor
central.
Atualmente, um grande número de aplicações encontra uma excelente
Figura 2 - Modelo de Rede Descentralizada (ARNAUTH, 2008)
Figura 1 - Modelo de Rede Centralizada (cliente-servidor) (ASTIAZARA, 2008)
3
alternativa em redes descentralizadas, como é o caso das Redes Peer-to-Peer1
(P2P), seja para a execução de aplicações naturalmente paralelas, que são
compostas por diferentes processos que interagem entre si para a resolução de um
problema, ou para melhorar o desempenho e a tolerância às falhas de aplicações
em geral, de diversas áreas do conhecimento, por exemplo: predições e análise de
crédito no mercado financeiro, descoberta de genomas, mineração de dados,
algoritmos de busca e computação evolutiva (ORAM, 2001) e (LUTHER, BUYYA,
RANJAN, & VENUGOPAL, 2006).
Os benefícios dessa tecnologia estão relacionados com: a melhor
possibilidade de crescimento em escala por evitar a dependência de servidores
centralizados, o estabelecimento de comunicação direta entre os computadores e a
possibilidade de agregação de recursos.
Além disso, a computação paralela e distribuída em redes P2P é bastante
efetiva no aproveitamento do sistema computacional como um todo, possibilitando
uma melhor utilização dos recursos circulantes nas redes (LUTHER, BUYYA,
RANJAN, & VENUGOPAL, 2006). Assim, esforços nos estudos de tecnologias e
soluções das redes P2P, bem como padronização das mesmas, que auxiliem o
acesso à computação distribuída têm impacto imediato nos diferentes ramos da
informática.
1.2 PADRONIZAÇÃO
Um problema comum no desenvolvimento de software, que também existe
em redes distribuídas e P2P, é a necessidade de padronização, pois as mesmas
atuam em grandes dimensões geográficas, com tecnologias diferenciadas. Estes
1 Peer: palavra inglesa que assume o significado de ‘par’. Peer-to-peer ou P2P seria então par-a-par,
ou seja, entidades distintas que possuem mesmo ‘peso’, ‘posição’, igual teor, ou seja, iguais perante o conjunto,
porém mantendo suas características particulares.
4
padrões são necessários desde o desenvolvimento até a compatibilidade de tráfego
da informação.
Existem bibliotecas padronizadas, cada uma com sua peculiaridade e com
sua finalidade bem definida. Essas bibliotecas, sejam protocolos, padrões de
implementação ou ferramentas de desenvolvimentos, tendem a seguir normativas
homologadas pelas mais renomadas entidades da informática, sejam elas ONG’s,
entidades de Ensino, Instituições Públicas e/ou Privadas.
Porém muitas tentativas de padronização não obtiveram o respaldo e a
aceitação necessária na comunidade informática, já outras estão constantemente
sendo atualizadas, para assim se tornarem e/ou continuarem sendo referencias,
como é o caso da ODF2 (ISO, 2008) e ANSAware3 (ANSAWARE, 2008).
Uma das bibliotecas mais utilizadas ao citar tráfego em redes é o protocolo
de TCP/IP4 (TCP/IP, 1991) por tratar-se de um protocolo orientado a conexões, com
grande portabilidade. Devido a isso se tornou o protocolo padrão da internet e com
isso um protocolo padrão para sistemas distribuídos.
A Figura 3 mostra as camadas do protocolo TCP/IP, seus agentes e em
destaque os principais elementos do protocolo (TCP e IP).
2 ODF: abreviação de "OASIS Open Document Format for Office Applications", é um formato de
arquivos de suítes de escritório, como textos, planilhas, apresentações e base de dados. Desenvolvido pelo
consórcio OASIS baseia-se na linguagem XML. O ODF é um formato aberto e público e foi aprovado como
norma ISO/IEC em Maio de 2006 (ISO/IEC 26 300)
3 ANSA: Arquitetura para sistemas distribuídos abertos. É uma iniciativa colaborativa gerenciada
por Citrix Systens (Research & Development) Ltd.
4 TCP/IP: protocolo proveniente da mescla de protocolos, onde seus dois principais agentes são:
TCP (Transmition Control Protocol) e IP (Internet Protocol). Eles, respectivamente encontram-se nas camadas
de Transporte e Rede do protocolo TCP/IP. O mesmo é referenciado pela RFC 1180.
5
Outros padrões muito utilizados em sistemas distribuídos são (LIMA Jr & de
PAULA, 2001):
• CORBA: Common Object Request Broker Architecture. Desenvolvido
pela OMG (Object Management Group), é uma tecnologia que permite
a interoperabilidade entre módulos de software executados em
sistemas distribuídos.
• IDL: Interface Definition Language. Assim como CORBA, possui os
mesmos desenvolvedores, porem tem serventia de ligação dos
múltiplos componentes CORBA com o usuário.
• JAVA/RMI: Java Remote Method Invocation and Specification.
Arquitetura de sistema distribuído programado em Java, o qual objetiva
transparência na comunicação de componentes distribuídos de
diferentes máquinas virtuais.
Seguindo a padronização de sistemas distribuídos, a tecnologia JXTA,
segundo (THEODOLOZ, 2004) e (PROJETO JXTA, 2007), apresenta-se como uma
solução, fornecendo uma interface de programação padronizada, agregando
interoperabilidade entre linguagens de programação, como exemplo entre Java e C,
alem de outros serviços, como padrão para descoberta de recursos, comunicação
de processos e segurança.
Figura 3 - Protocolo TCP/IP, suas camadas e seus agentes. (REMOALDO, 2008)
Camadas Agentes
6
1.3 OBJETIVOS
O objetivo deste trabalho é apresentar um estudo relacionado aos sistemas
distribuídos P2P, exemplificando arquiteturas, protocolos, ferramentas, modelos de
desenvolvimento e de aplicativos P2P.
1.4 ORGANIZAÇÃO DO TRABALHO
O capítulo 2 aborda teoricamente a metodologia utilizada no estudo de
aplicações P2P, o qual será consolidado no capitulo 4.
A Revisão Bibliográfica é apresentada no capitulo 3, abordando conceitos
de dados, informações e descrições dos sistemas distribuídos P2P (Redes P2P);
apresenta as vantagens e as desvantagens deste tipo de sistema distribuído.
Apresenta também os modelos triviais de arquiteturas e um breve comparativo entre
eles. Também estão inclusos os modelos de algoritmos para Redes P2P e alguns
exemplos de sistemas P2P.
O capítulo 4 consiste num descritivo sobre desenvolvimento de aplicações
P2P, exemplificando ferramentas e códigos-fonte para implementação do P2P e o
desempenho dos itens citados em relação ao sistema P2P.
O Capítulo 5 apresenta uma conclusão, após o fechamento dos trabalhos
realizados neste estudo.
7
2 METODOLOGIA
A internet nos últimos anos vem sofrendo significativas alterações, sendo
grande parte dessas, avanços tecnológicos, como divulgação de noticias, aberturas
de novos mercados em vendas on-line e compartilhamentos, dentre outros.
Engajado nisso que em 2001, redes P2P tomou uma proporção de conhecimento
estrondosa, após o surgimento do compartilhador de arquivos pela Internet, Napster
que atraiu não somente internautas5 residenciais, devido ao acesso fácil e gratuito,
como também companhias musicais, como gravadoras, e entidades responsáveis
por segurança e direitos autorais na internet.
Este trabalho é voltado aos interessados em redes de compartilhamento
P2P e aplicações à mesma. Desenvolvimento e modelos de ferramentas para estas
aplicações serão assuntos abordados.
Uma abordagem preliminar sobre redes P2P, modelos, exemplos,
vantagens, desvantagens, arquiteturas existentes e os comparativos entre elas, são
itens esclarecidos, para que um melhor entendimento haja.
Contudo os modelos de padronização, protocolos, vantagens e
desvantagens e principalmente da ferramenta de desenvolvimento, sobretudo do
JXTA (esta a mais comum dentre as existentes) são assuntos objetivados neste
trabalho.
5 Internauta: dito ao chamado usuário da Internet.
8
3 REDES P2P
A maioria dos sistemas em uso em plataformas WEB são sistemas
distribuídos e interagem em uma arquitetura convencional de cliente-servidor, onde
cada cliente utiliza um protocolo específico à operação requerida. Essa abordagem
concentra as operações no servidor, requerendo assim um equipamento de
hardware e um sistema operacional em profunda sintonia com os demais sistemas
em execução, pois o aumento de processamentos (diga-se simultâneos) afeta
diretamente a desempenho do equipamento e com isso a qualidade de retorno
(resultado) do aplicativo ao usuário.
Rede Peer-To-Peer, ou apenas P2P é uma tecnologia a qual seus
estudiosos, desenvolvedores e usuários vislumbram sanar o problema citado, pois a
mesma segue a premissa de não concentrar todas as operações em uma única
estação (servidor), atuando então no modelo Descentralizado.
Essa topologia descentralizada auxilia ainda na expansão da rede, pois
uma estação (seja computador ou outro equipamento) que possua uma interface de
rede capaz de adquirir um endereço IP6, pode facilmente ingressar a rede, sem
prévia autorização de um servidor, ou mesmo sem que haja alterações na estrutura
lógica ou física da rede. Os requisitos para que tal estação ingresse na rede P2P, é
possuir um meio de ligação e um aplicativo compatível com o da rede.
As redes P2P exploram a conectividade entre seus integrantes, utilizando
os recursos físicos e lógicos disponíveis (processador, memória, entre outros) do
equipamento, fazendo com que a capacidade da rede cresça em larga escala.
Devido à facilidade de ingresso, aos recursos disponíveis e a falta de um
servidor central monitorando essas redes, é impossível diagnosticar com exatidão o
tamanho atual e o tamanho que uma rede P2P pode atingir.
6 IP: internet protocol, pode ser considerado o endereço numérico que representa o local de um
determinado equipamento em uma rede privada ou pública.
9
3.1 VANTAGENS P2P
Conforme (BALAKRISHNAN, KAASHOEK, KARGER, MORRIS, & STOICA,
2003), existem muitos atrativos para a utilização de redes P2P, onde os principais
são:
• Facilidade de conexão – Empecilho de conexão para este tipo de
redes é mínimo, pois diferente dos sistemas totalmente
centralizados não necessita de administração ou instalações
específicas;
• Conteúdo diversificado – Pelo aumento constante de estações
conectadas a Internet, redes P2P tem também seu crescimento e
com o conteúdo incluso nelas, a quantidade de recursos
compartilhados é cada vez maior e mais diversificado.
• Segurança no compartilhamento – Este modelo de rede esta menos
suscetível a falhas de compartilhamento ou ataques intencionais,
pois é nativo de sistemas distribuídos, tornando assim ambiente
ideal para troca de informações em longo prazo e/ou computações
demoradas.
• Confiabilidade – Caso ocorra problema em algum peer, o sistema
não irá parar totalmente, pois os demais podem manter-se atuantes,
utilizando recursos e/ou conteúdos existentes;
• Utilização dos Recursos – Caso um peer não esteja utilizando um
recurso especial, ele pode “ofertar” seus recursos disponíveis a
outros peers, aumentando assim a capacidade de processamento
da rede.
3.2 DESVANTAGENS P2P
Algumas características P2P podem ser entendidas como desvantagens,
10
pois insinuam ambigüidade (BALAKRISHNAN, KAASHOEK, KARGER, MORRIS, &
STOICA, 2003). Algumas dessas características e suas descrições são:
• Redundância – Devido ao tamanho das redes, uma estação efetuar
duas buscas e obter o mesmo resultado é incomum e improvável,
porém possível;
• Tempo de Resposta – Com o aumento da rede, o tempo de resposta
pode variar consideravelmente, podendo em casos de alto tempo de
retorno, perder a informação buscada na rede;
• Perda de conteúdo – Como um peer possui a facilidade de entrar e
sair da rede, um conteúdo compartilhado pode facilmente deixar de
existir na rede;
• Desempenho – Arquitetada para atuar com grande número de peers
conectados, a rede pode perder desempenho caso esse numero
venha a ser baixo, pois as buscas e recursos serão limitados.
3.3 ARQUITETURA P2P
Redes P2P podem ser nativas ou híbridas, (YANG & GARCIA-MOLINA,
2001). Sistemas híbridos são aqueles não puramente descentralizados, isto é,
utilizam uma estação como concentrador central, para armazenar algumas
informações e efetuar alguns processamentos, similar a arquitetura de rede
convencional. Esses sistemas são maioria dentre as redes P2P.
Sistemas Nativos são aqueles que ao contrario dos híbridos, são
puramente descentralizados, ou seja, não necessitam de nenhum tipo de
concentrador de informações. Exemplo de sistema nativo é USENET (PROJETO
USENET, 2007).
As arquiteturas P2P são comumente divididas em três modelos:
- Com serviço de localização centralizada;
- Baseada em inundação;
11
- Baseada em redes de superposição.
3.3.1 COM SERVIÇO DE LOCALIZAÇÃO CENTRALIZADA
Este modelo não é uma arquitetura P2P puramente descentralizada, pois
ao acessar a rede, a estação conecta a um ou mais servidores e envia informações
de compartilhamento aos mesmos para que neles sejam gerados índices sobre os
recursos disponíveis na estação. Estes índices estarão disponíveis aos demais
peers conectados ao mesmo servidor.
As informações geradas pelos servidores são distribuídas aos peers e
quando esses efetuarem uma busca será informado o endereço IP da máquina que
aloca os dados. A estação cliente (peer) que efetuou a busca pode então conectar-
se diretamente à estação proprietária das informações, (APPLIED META
COMPUTING, 2000).
A Figura 4 exemplifica o funcionamento de uma rede centralizada, onde:
1. O novo cliente se conecta ao servidor e envia uma lista dos seus dados
compartilhados.
2. O cliente já registrado no servidor solicita a pesquisa de dados.
3. O servidor retorna uma lista com o endereço de todos os peers que
contém a informação desejada.
4. O cliente contata o nodo que contém o arquivo desejado e o requisita.
5. O peer contatado transfere o arquivo ao requisitante.
12
Este modelo de arquitetura têem como ponto forte a facilidade de buscas
por palavras-chave e critérios múltiplos, deixando assim a busca ágil e rápida, pois
diminuem assim o tempo de comparação de conteúdo.
Outra característica existente nesse modelo, negativa, porém significativa,
é estar mais suscetível a falhas na rede, pois podem ocorrer erros nos pontos
centrais, o que danifica toda a estrutura da rede, e também estar mais vulnerável a
ataques, pois ao acessar o centralizador todo o roteamento da rede torna-se
disponível.
Um exemplo de um aplicativo bastante conhecido que utiliza uma rede P2P
centralizada é o Napster, que utiliza um servidor central para retornar aos clientes os
resultados das buscas realizadas (PROJETO NAPSTER, 2007).
3.3.2 BASEADA EM INUNDAÇÃO
Rede Baseada em Inundação (Flooding Style Network) é uma arquitetura
totalmente distribuída (100% P2P). Esse tipo de rede não possui servidores centrais,
assim não agregando os problemas existentes na arquitetura centralizada.
Figura 4 - Exemplo de serviço de localização centralizada (APPLIED META COMPUTING,
2000)
13
(APPLIED META COMPUTING, 2000). Um equipamento acessa toda a rede P2P
simplesmente conhecendo outro peer.
Cada requisição de compartilhamento de recurso circula livremente entre
os peers, até que algum peer que continha tal recurso retorne seu IP. Usa-se como
controle dos mecanismos de inundação o TTL7 da rede, o qual garante que uma
requisição não trafegue indefinidamente na rede, (APPLIED META COMPUTING,
2000).
A Figura 5, exemplifica uma rede baseada em inundação onde:
• A estação (peer 2) requisita um recurso na rede;
• Esta requisição percorre os peers ainda não pesquisados (1), até
que algum resultado seja encontrado e o peer proprietário marcado
como satisfatório
• Aqueles quais os resultados não foram satisfatórios, não serão
novamente questionados e são diferenciados (3)
• Aqueles quais os resultados são satisfatórios serão positivados (4)
• Dentre todos aqueles positivados (4), deve existir um ou mais, com
melhor resultado e será este(s) que retornarão o recurso requisitado
(5).
• Será então criada uma ligação direta (se ainda não existir) entre o
peer requisitante e o peer mantenedor do resultado mais satisfatório.
7 TTL: Time-To-Live, que significa o tempo de vida de trafego das informações na rede.
1) Peer’s existentes na rede, mas não visitados na busca;
2) Peer de onde originou a busca;
3) Peer’s visitados, mas sem resultado satisfatório;
4) Peer’s visitados com resultados satisfatórios;
5) Peer com melhor resultado dentre os satisfatórios.
6) Caminho percorrido entre o requisitante e o resultado
6
14
3.3.3 BASEADA EM REDES DE SUPERPOSIÇÃO
Devido a descentralização das redes P2P e seu rápido crescimento ao
efetuar consecutivas buscas, obter os mesmos resultados, e principalmente que
sejam os mais satisfatórios, é praticamente impossível. Esse problema não existe no
modelo de rede centralizado e baseado neste que foi criado o modelo de redes de
superposição (STOICA, MORRIS, KARGER, KAASHOEK, & BALAKRISHNAN,
2001).
Este tipo de rede delega funções especiais a alguns peers da rede (super-
peers), tornando-os servidores para outros peers. Apenas Super-peers terão acesso
efetivo a rede P2P, ou seja, somente os Super-Peers possuem conexão e operação
direta com outros Super-peers. Os demais peers (convencionais) apenas requisitam
e respondem aos respectivos super-peers.
Outra característica deste modelo é que ao entrar na rede e conforme o
critério utilizado para ordená-los (geralmente o IP da estação) os peers são
reagrupados, ficando ordenados sequenciamente.
A Figura 6 ilustra o modelo de tal rede, onde pode ser visualizado peers
convencionados, ligados a super-peers, como se fossem pequenas comunidades. E
entre essas comunidades existe uma ligação, garantindo assim comunicação total
da rede.
15
Este tipo de rede P2P agrega as vantagens dos modelos de localização
centralizada e do modelo baseado em inundação, pois mantém sempre uma tabela
atualizada nos super-peers com o conteúdo disponível na rede, agilizando assim as
buscas. Também comunica diretamente os super-peers, sem que estes passem por
outro concentrador de rede.
Embora essa arquitetura proporcione uma melhora significativa na rede, ela
sobrecarrega os super-peers, por efetuarem maior número de operações.
3.4 COMPARATIVO ENTRE ARQUITETURAS P2P
Para que possa ser citado qual modelo de arquitetura é melhor em relação
a falhas, pesquisa de dados, anonimato, rapidez, entre outros itens, é necessário
que a mesma busca seja feita, utilizando a mesma proporção de peer pesquisados.
Num estudo comparativo entre as arquiteturas P2P, (FRANCESQUINI,
2004) obteve os resultados citados na tabela 1, quantificando as características das
Super-peers
Convencionais
192.168.21.105
192.168.21.106
192.168.80.37
192.168.80.56
192.168.21.100
192.168.3.5
192.168.5.2
192.168.5.1
192.168.37.1
192.168.21.1
192.168.5.1
192.168.3.10
Figura 6 - Arquitetura de Super-Peers e peers convencionais (STOICA, MORRIS, KARGER,
KAASHOEK, & BALAKRISHNAN, 2001)
16
arquiteturas usando notas entre 0 e 3, onde melhores são as maiores notas.
Os critérios de análise foram:
• Tolerância à falhas – Quanto à rede é resistente à falhas e ataques.
A remoção de algum peer especial traz grandes conseqüências à
rede?
• Escalabilidade – A rede consegue suportar um grande número de
usuários?
• Pesquisa de dados – Suporta pesquisa por palavras chave e
coringas? E bom para pesquisas aleatórias? Tem garantias quanto à
acessibilidade dos dados?
• Anonimato – Tanto quem requisita quanto quem fornece a
informação consegue manter a sua identidade em sigilo?
O resultado encontrado então foi:
Tabela 1 - COMPARATIVO ENTRE AS ARQUITETURAS P2P (FRANCESQUINI, 2004)
Tolerância à falhas escalabilidade Pesquisa de dados Anonimato
Centralizado 0 2 3 0
Descentralizado 1 3 3 0
Inundação 3 1 2 3
Superposição 2 3 1 0
Para um maior esclarecimento, descreve-se a tabela assim:
• Centralizado – Arquitetura cliente/servidor convencional, onde as
estações em rede comunicam-se exclusivamente por intermédio de
um concentrador (servidor).
• Descentralizado – Arquitetura puramente descentralizada,
desprovida de servidor central e sem qualquer variação em seu
modelo original. Assumem que uma busca ocorrerá quantas vezes e
quantos peers forem necessários.
17
• Inundação – Busca baseada no modelo de rede baseado por
inundação.
• Superposição – Busca baseada no modelo de rede baseado por
superposição.
• Tolerância a falhas – Retirada de um peer especifico, mantenedor
de conteúdo específico, pode alterar o resultado da rede, este é o
principal teste deste item.
• Escalabilidade – crescimento da rede seja baseado em números de
peers ou de arquivos circulantes.
• Pesquisa de Dados – Busca de dados utilizando coringas, ou seja,
símbolos como * (todos), + (conjunção &), e buscas aleatórias, como
múltiplas buscas e não seqüenciais e buscas de arquivos não
conhecidos (não buscados recentemente).
• Anonimato – item considerando tanto o anonimato do pesquisador
quando dos pesquisados.
As considerações finais dos testes relatados na Tabela 1, demonstram que
cada arquitetura sobressaiu-se em um item, porém numa análise conjunta de tais
itens a arquitetura por inundação obteve os melhores resultados.
Vale ressaltar ainda que a única arquitetura que obteve resultado no item
anonimato foi por inundação, pois é o único modelo analisado que não necessita de
nenhum tipo de concentrador e a busca percorre livremente, sem uma seqüência ou
forma de busca definida.
Outro item a ressaltar é o baixo resultado da arquitetura por superposição,
em relação à busca de dados aleatórios ou utilizando caracteres coringas, isso
porque o mesmo deve reordenar toda a rede, cada vez que existe a inserção ou
remoção de um peer.
18
3.5 ALGORITMOS P2P
Os algoritmos P2P são aqueles que determinam os métodos de busca nas
redes P2P, seja ela centralizada ou descentralizada. A eficiência da busca consiste
na eficiência do algoritmo e está diretamente ligada ao número de peers ligados a
rede no momento da busca (GOMES, PETEK, DIVERIO, & GEYER, 2006).
Um exemplo de algoritmo de busca usado em redes P2P é o DHT, cuja
sigla representa Distributed Hash Tables (ou Tabelas Hash Distribuídas). Esse
algoritmo atua similarmente a uma tabela hash. Em DHT, identificadores são
calculados de acordo com a função hash utilizada, onde tanto o peer quanto o
conteúdo armazenado recebe tal identificador. Cada peer armazena informações de
alguns outros peers, mas somente dos mais próximos.
Esse modelo segue a seguinte ordem:
a. é feita a busca do conteúdo na rede e esta para ao primeiro
resultado satisfatório encontrado;
b. é identificado o peer mais próximo ao satisfatório (item 1) e também
ao peer de origem da busca;
c. é atribuído o identificador ao peer comum (item 2);
d. após atribuir o identificador (item 3), a busca é reiniciada;
e. ao localizar outro resultado satisfatório, é atribuído um novo
identificador a este peer e tambem armazenado o identificador do
resultado anterior (item 4);
f. a busca é finalizada quando o peer localizado é novamente o mais
próximo do originário da pesquisa (item 2).
DHT é também distribuída entre os peers da rede de modo que haja perda
de um nó, não cause perda considerável ao sistema, permitindo assim que haja uma
escalabilidade perfeita à medida que novos peers são adicionados à rede, (DHT,
2007).
19
As vantagens enfatizadas no DHT são:
• Descentralização;
• Escalabilidade;
• Tolerância à faltas.
Por suas características, tornou-se algoritmo base de aplicações P2P, bem
como serviu de base para outros algoritmos de busca, como Tapestry, Chord, CAN e
Pastry.
3.6 EXEMPLOS DE SISTEMAS P2P
Compartilhadores são exemplos de aplicações distribuídas que em sua
maioria utilizam redes P2P, por meio da internet ou redes locais.
Existem modelos diferenciados de compartilhadores, que podem ou não
possuir configurações locais diferenciadas, assim como as estações que os alojam e
arquiteturas similares, porém, todos respeitam requisitos básicos, como protocolos,
e a mais importante, utilizam o mesmo meio de comunicação, uma rede local ou
internet, em caso de redes remotas (CLARKE, 1999).
Uma estação pode alojar mais de um compartilhador e estes podem atuar
em redes distintas ou em uma mesma rede, podendo ainda compartilhar entre si os
recursos ou objetos aos quais estejam disponíveis.
3.6.1 NAPSTER
Em 2001 Shawn Fanning estudante da Universidade de Boston,
Northeastern University, buscando um modo mais fácil de pesquisar músicas na
internet criou o compartilhador Napster. Este programa gerou muita polêmica, ao
atingir uma enorme quantidade de usuários em todo o mundo, levantando uma
legião de defensores e preocupando as grandes gravadoras de discos, devido à
quebra de direitos autorais e a facilidade de aquisição gratuita de músicas,
20
(PROJETO NAPSTER, 2007).
A arquitetura básica do Napster requer que clientes conectados a rede
enviem uma lista dos arquivos compartilhados ao servidor central, o qual cria índice
dos arquivos. Quando o cliente busca alguma música, se conecta ao servidor, e este
atualiza a lista de índices e lhe encaminha o endereço do cliente que contém a
música buscada e se inicia a troca, (ORAM, 2001).
Com toda a polêmica gerada, judicialmente o desenvolvimento do Napster
foi interrompido em julho de 2002.
3.6.2 SETI@HOME
Seti (Search for Extraterrestrial Intelligence) surgiu logo após o fenômeno
Napster, simplificando um sistema de troca de informações sobre civilizações
extraterrestres, onde utiliza a rede P2P para concretizar os cálculos e
processamentos diversos, dos dados coletados pelo telescópio gigante Arecibo,
(ANDERSON, COBB, KORPELA, LEBOFSKY, & WERTHIMER, 2002), os
processamentos utilizados são de computadores ociosos ligados à rede pela internet
(PROJETO SETI@home, 2007), utiliza uma arquitetura centralizada ou
descentralizada.
3.6.3 FREENET
Utilizando uma arquitetura totalmente descentralizada, seu propósito inicial
possuía uso de sistemas remotos anônimos, ou seja, executaria pela rede uma série
de instruções e processamentos remotamente (CLARKE, 1999). Isto é, um usuário
pode requisitar à rede um local para armazenar um arquivo, e outro usuário pode
responder a requisição, sem ao menos saber quem a fez. Outro ponto é, se um
usuário tem armazenado um arquivo em seu sistema, ele é incapaz de saber quem
o armazenou e está compartilhando este arquivo (CLARKE, SANDBERG, WILEY, &
21
HONG, 2001) e (PFITZMANN & WAIDNER, 1987).
22
4 PLATAFORMAS DE DESENVOLVIMENTO
Muitas aplicações requerem a utilização de uma plataforma específica de
desenvolvimento, para que haja total integração entre peers na rede. Isso gera
inconvenientes, pois tais aplicativos devem ser desenvolvidos em linguagem, tipo de
rede, protocolos e outros, iguais.
Este problema da compatibilidade e/ou portabilidade restringe tanto o
desenvolvimento quanto o uso do aplicativo, por isso aplicativos com integração
entre redes e sistemas operacionais têm destaque.
Em aplicações P2P a portabilidade é algo extremamente importante, visto o
tamanho das redes e a cultura de seus usuários, fazendo com que linguagens de
programação, modelos de interfaces, protocolos utilizados e demais características
de usuários, sejam diferentes.
Devido a isso alguns padrões de programação são utilizados, como JXTA,
.Net e Groove.
4.1 JXTA
A idéia original do Projeto JXTA, era criar um meio de integrar a tecnologia
P2P ao núcleo da arquitetura de rede (PROJETO JXTA, 2007).
O JXTA aglomera um conjunto de protocolos P2P simples para
comunicação, colaboração e compartilhamento de recursos. Os peers JXTA criam
uma rede virtual no topo de redes existentes, mascarando a complexidade das
camadas inferiores. Na rede virtual JXTA, qualquer peer interage com outro,
independendo de sua localização, tipo de serviço ou ambiente operacional. Assim, o
acesso aos recursos da rede não são limitados por incompatibilidade de plataforma
ou restrições da arquitetura cliente-servidor convencional (KAMIENSKI, 2004).
A Figura 7 demonstra tal arquitetura de rede virtual.
23
Na topologia de rede virtual, cada peer é associado a um identificador
único, chamado de Peer ID, e pertence a um ou mais peergroups, tendo em vista o
suporte a grupos que o ambiente JXTA desenvolvido forneça8. Dentro dos
peergroups os peers cooperam e têm as mesmas funções.
A tecnologia JXTA objetiva:
• Interoperabilidade: entre diferentes sistemas e comunidades P2P;
• Independência de plataforma: diversas linguagens, sistemas e
redes;
• Generalidade: qualquer tipo de dispositivo digital;
• Segurança.
4.1.1 CAMADAS JXTA
8 O números de grupos (peergroups) ao qual o peer pode pertencer é customizável no
desenvolvimento do aplicativo P2P.
Figura 7 - Arquitetura de Rede Virtual JXTA (PROJETO JXTA, 2007)
24
Para que na prática ocorra o que na teoria é proposto pelo JXTA, sua
estrutura é dividida em camadas:
• Core – provê os elementos necessários ao aplicativo P2P, e nessa
camada são implementados os grupos, os monitoramentos, as
políticas de segurança e os túneis de comunicação;
• De Serviços – Camada não obrigatória ao aplicativo, porém todo
conteúdo desenvolvido nessa camada, torna-se compartilhado entre
os demais peers e/ou entre aplicativos de um mesmo peer. Nessa
camada encontram-se os comandos, serviços e o prompt de
comando;
• De Aplicação – É a camada visível ao usuário, pois nela são
implementadas as integrações entre os aplicativos P2P e os
protocolos internos a ele. Todo conteúdo da camada de serviços,
torna usável por esta camada.
A Figura 8 ilustra tais camadas.
Figura 8 - Estrutura das camadas lógicas JXTA (PROJETO JXTA, 2007)
25
Como citado, nem todas as 3 camadas do JXTA são necessárias, porem
existem alguns elementos que são básicos. São eles:
• Grupos;
• Avisos ou Comunicados;
• Pipes9 e mensagens;
• Protocolos.
4.1.2 GRUPOS
Os grupos servem não para distinguir um peer de outro, mas sim delimitar
conjunto de serviços e recursos os quais os peers oferecerem a rede, para
compartilhamento.
Os grupos ou os peers podem ser dos tipos abaixo? Se o certo for escrever
“Os peers podem ser do tipo”, então copiem o trecho abaixo para junto da figura 9.
Os grupos podem ser do tipo Edge, Minimal, Proxy, Rendezvous e Relay,
onde se tem:
• EDGE PEERS: estações simples, computadores de mesa e outros
equipamentos, podendo estar conectados por meio de uma rede
local ou através da internet.
• MINIMAL PEERS: Nesse grupo enquadram-se geralmente os
dispositivos móveis como celulares e palmtops, ou outro
equipamento que possua restrição quanto ao carregamento de
algumas funcionalidades do JXTA.
• PROXY PEERS: Redes que ficam encobertas por firewall ou por
equipamentos que atuam como Proxy ou ainda aqueles sem
navegação livre ou limitada por autenticação de servidor, possuindo
ou não um IP público.
9 Pipes: traduzido como tubo, cano, indica um túnel.
26
• RENDEZVOUS PEERS: Neste grupo estão os peers de maior poder
computacional (seja por capacidade de hardware ou de software),
estações com IP estático e peers que fornecem cache de
informações sobre outros peers conectados, auxiliando assim, na
busca de recursos e resolução de problemas.
• RELAY PEERS: Peers que assumem papel de roteadores, que
ultrapassam o firewall, NAT10 ou simplesmente roteador, para trocar
informações com outros peers do mesmo tipo.
4.1.3 AVISOS
Todas as informações coletadas e armazenadas pelo JXTA são
representadas pelos avisos, que são expressos como documentos XML11.
Avisos são criados e registrados com o ID do peer, que é único e universal,
ou seja, não existirá jamais duplicidade das informações, as quais serão
retransmitidas e armazenadas localmente nos demais peers.
Os avisos possuem tempo de vida, para evitar que peers desativados,
tenham suas informações em tráfego ainda, e esse tempo de vida é o tempo que o
peer mantém-se ativo na rede, após isso as informações são excluídas.
Os tipos básicos de avisos são:
• PEER: registro do peer;
• PEERGROUP: registro do grupo ao qual o peer pertence;
• PIPE: canal de comunicação peer-to-peer;
• SERVICE: serviço oferecido pelo peer ou peergroup;
10 NAT: Network Addrress Translation, termo em inglês, já adotado ao portugues, para Tradução
dos endereços de rede (IP).
11 XML: EXtensible Markup Language - Linguagem extensível de formatação. Linguagem
utilizada em metadados, ou seja, informações sobre informações.
27
• ENDPOINT: pontos de conexão de um pipe.
4.1.4 PIPES E MENSAGENS
Mensagens são as informações unidirecionais e não-confiáveis, que
possuem ID da origem e cabeçalho com informações sobre roteamento, que
trafegam pelos pipes, que por sua vez são os canais de comunicação entre os
peers.
Os peers de origem e destino dos pipes e mensagens são chamados de
Endpoints, e correspondem as interfaces de envio e recebimento das informações.
4.1.5 PROTOCOLOS
Os protocolos JXTA foram elaborados com base em mensagens XML, pela
sua alta usabilidade e portabilidade, auxiliando no suporte ao seu processamento e
em sua validação. O uso de tal padrão gerou a desvantagem das mensagens serem
muito maiores do que num padrão binário, pois XML é uma forma não-compacta de
transmissão de dados.
A Figura 9 mostra a forma de empilhamento dos protocolos, tanto no peer
local quanto no remoto.
28
4.1.5.1 PEER DISCOVERY PROTOCOL – PDP
Implementado pelo Discovery Service (Serviço de descoberta), o objetivo
deste protocolo é descobrir dinamicamente quais recursos JXTA o peer utiliza.
4.1.5.2 PEER RESOLVER PROTOCOL – PRP
Utilizando unicast ou multicast, efetua consulta genérica a outros peers.
Este protocolo pode ser considerado a base estrutural para outros protocolos JXTA,
como o Peer Information (PIP) e o Peer Discovery (PDP);
4.1.5.3 PEER INFORMATION PROTOCOL – PIP
Peer Discovery Protocol
Peer Local
Peer Information Protocol
Pipe Binding Protocol
Peer Resolver Protocol
Rendezvous Protocol
Endpoint Routing Protocol
Camada de Transporte
Peer Discovery Protocol
Peer Remoto
Peer Information Protocol
Pipe Binding Protocol
Peer Resolver Protocol
Rendezvous Protocol
Camada de Transporte
Endpoint Routing Protocol
Figura 9 - Empilhamento de protocolos JXTA (PROJETO JXTA, 2007)
29
Protocolo de coleta de informações diversas do peer, como desempenho
da rede, algoritmos executados, seu status no momento, controle do consumo de
serviços providos.
4.1.5.4 RENDEZVOUS PROTOCOL – RVP
Este protocolo é responsável pela gerência das mensagens em tráfego no
grupo, é base para os protocolos PBP e PRP.
A Figura 10 traz uma breve explicação de RVP.
4.1.5.5 PIPE BINDING PROTOCOL – PBP
Através de mensagem de consulta, requer qual peer deve ser ligada a qual
endpoint.
Peer 1
Peer Edge 1
Peer RendezVous
Peer Edge 2
Peer Edge 3
1. O Peer 1 enviauma mensagem RVPa todos os peersconhecidos.
2. O Peer RendezVous querecebe a mensagem RVP retornauma resposta contendo todos osanúncios existentes em suacache. Além disso, propaga abusca a todos os peersconhecidos.
3. Um peer Edge que recebe amensagem propagada envia aresposta diretamente ao peerinicialmente responsável peloenvio da mensagem.
Figura 10 - Demonstração do protocolo RVP (PANISSON, 2007)
30
4.1.5.6 ENDPOINT ROUTING – PEP
Por meio de mensagens de busca, encontra informações de roteamento,
para posteriormente efetuar a busca de conteúdo entre peers.
Os dados armazenados localmente, contem ID remetente, ID destino, TTL,
e a seqüência ordenada de peers no roteamento, Figura 11 (PANISSON, 2007).
Atualmente existem implementações para os seguintes tipos de
transportes:
• TCP: Usa socket para conectar-se diretamente a outro peer.
• HTTP: Usado para transpor barreiras como firewalls, ou permitir
transferência de informações a dispositivos móveis como celulares,
tem como desvantagem o fato de não permitir broadcast.
• Servlet HTTP: Usado em aplicações que suportem Servlets.
• TLS: Para prover comunicação segura, com o uso de autenticação.
4.1.6 DESENVOLVIMENTO P2P UTILIZANDO JXTA
Para desenvolvimento de aplicações P2P utilizando JXTA, várias
linguagens de programação podem ser utilizadas, devido a sua grande portabilidade,
2. O Peer Roteador 1encaminha amensagem ao PeerRoteador 2
Peer 1 Peer Roteador 1 Peer Roteador 2 Peer 2
Rede interna
Firewall 1 Firewall 2
1. O Peer 1 envia a mensagemao peer Roteador 1 a fim deencaminhá-la ao Peer 2através do Roteador2,conforme informação obtidapreviamente
Rede Externa (Internet) Rede interna 2
3. O Peer 2 periodicamente seconecta ao Peer Roteador 2 afim de verificar as mensagensque chegaram.
Figura 11 - Demonstração do protocolo PEP (PANISSON, 2007)
31
onde se destaca a linguagem Java. Esse destaque refere-se ao fato de desta
apresentar um melhor aproveitamento e entendimento no tratamento de protocolos e
principalmente do seu modo de compilação, que diferente de linguagens (pascal,
delphi, fortran, por exemplo) é feito para um bytecode12 e não para código nativo.
Esse bytecode é executado por uma máquina virtual, o que torna assim bastante
portável. Outro motivo da diferenciação do Java das demais é a facilidade de
integração com outras linguagens.
Existe também a opção da utilização de várias ferramentas SDK13, levando
em consideração a linguagem escolhida, Borland® Developer Studio, Microsoft®
Visual Studio e NetBeans são as mais utilizadas, por suportarem várias linguagens.
Outros tipos de ferramentas, com estruturas para desenvolvimento do
JXTA podem ser encontradas, como é o caso do JXTA Shell, que traz
implementados os protocolos, diminuindo assim as configurações a serem feitas.
4.1.6.1 IMPLEMENTAÇÃO DO PEER
A implementação dos peers pode ser feita de diferentes métodos, levando
em consideração a aplicação dos mesmos. Essa aplicação influencia nos protocolos
a serem desenvolvidos, e esses na complexidade do aplicativo como um todo. Por
exemplo, um aplicativo pode armazenar todos os avisos em memória, assim não
sendo necessário implementar o Peer Discovery Protocol.
Outro exemplo pode ser um conjunto de instruções pré-definidos para
encaminhar suas mensagens, não sendo necessário implementar o Peer Endpoint
Protocol. Também pode não ser necessário implementar o Peer Information
Protocol, caso o peer não precise obter ou fornecer informações de estado a outros
peers.
12 Bytecode: refere-se a uma parte de código, um bloco.
13 SDK: Software Development Kit, ou seja, Kit de Desenvolvimento de Software.
32
Mesmo podendo deixar algumas configurações sem implementação, seja
por já as possuírem, ou por desuso, existem as classes principais, que
obrigatoriamente devem ser implementadas:
• Net.jxta.*
• Net.jxta.impl.*
4.1.6.2 ORGANIZAÇÃO DAS CLASSES
As classes dentro do aplicativo têm funções diferenciadas e todas elas
agrupam um ou mais funções. Em geral elas são agrupadas em pacotes, pois
tamanho pode ser a quantidade de classes em uso, que torna oneroso à organizá-
las quando todas “soltas”.
No desenvolvimento do P2P JXTA, duas são as classes principais:
• net.jxta.*: Utilizada para armazenar interfaces aos protocolos JXTA e
aos blocos centrais. Essa é a classe maior do JXTA, a principal e
inicial.
• net.jxta.impl.*: Utilizada para implementação das interfaces. Ela
herda informações da classe principal, e utiliza esse conteúdo para
confeccionar as interfaces.
Como citado, existem outras classes:
• net.jxta.impl.peergroup.boot: Utilizada para indicar ao peer qual
grupo ele deve ingressar e inicializar. Em geral tal informação é
setada diretamente na camada de “AVISOS” do JXTA, pelo
PeerGroup.
• net.jxta.platform.Application: Esta classe apesar de não ser
obrigatória, torna-se indispensável quando muitas classes são
implementadas, pois é responsável pelo acoplamento de todas as
outras classes, fazendo com que o aplicativo seja formado.
33
4.1.6.3 EXEMPLO DE IMPLEMENTAÇÃO
Um modelo simples de implementação em linguagem java pode ser visto
assim:
1. import net.jxta.peergroup.*; // importação do grupo em que o peer está
2. import net.jxta.impl.id.UUID.*; // importação do nome do peer
3. import net.jxta.impl.id.binaryID.*; // importação do ID do peer
4. public class Hello //inicio da classe local
5. {
6. // ---------- inicialização das variáveis ---------------
7. static PeerGroup netPeerGroup = null;
8. static DigestTool digestTool = new DigestTool();
9. // ---------- início do bloco principal do projeto -----------
10. public static void main(String args[]) {
11. try {
12. netPeerGroup = PeerGroupFactory.newNetPeerGroup();
13. System.out.println("Hello from JXTA group" +
14. netPeerGroup. getPeerGroupName() );
15. System.out.println("GroupID=" +
16. netPeerGroup. getPeerGroupID().toString());
17. System.out.println("Peer name = " + netPeerGroup.getPeerName());
18. System.out.println("PeerID="+netPeerGroup.getPeerID().toString());
19. } catch(Exception e) { e.printStackTrace(); } // exception do try, erro
20. } // fim do main
21. } // fim da classe
22.
34
A Figura 12 a seguir ilustra a tela que deve ser exibida ao compilar o
código exemplificado. Tanto o código como a imagem foi obtida por (LIMA, 2005).
4.1.6.4 JXTA SHELL
JXTA SHELL é uma interface auxiliar desenvolvida pela comunidade
responsável pelo JXTA. Ela traz configurados valores e protocolos úteis ao P2P.
Além de ser uma ferramenta OpenSource, ele é facilmente encontrado na
Internet, inclusive seus manuais de utilização são disponibilizados pelo fabricante,
(PROJETO JXTA, 2007).
O JXTA SHELL possui os mesmos comandos que um Shell Unix14, sendo
eles:
• Man – Mostra as informações sobre um comando (Manual);
• Whoami – informa com qual usuário você está acessando;
• Peers – Lista os peers ativos no grupo;
• Importfile – Importa arquivo (caso necessário);
• Mkpipe – Cria um Pipe (túnel).
A função que cada comando citado executa pode variar de acordo com as
instancias utilizadas em conjunto.
14 Shell Unix: tela de comando do sistema operacional Unix.
Figura 12 - Exemplo de retorno das funções executadas (LIMA, 2005)
35
4.1.6.5 .NET
A plataforma .Net (.NET, 2003) disponibiliza uma gama de soluções para
construção de aplicações P2P. Entretanto, é importante saber como tais
funcionalidades podem ser utilizadas, assim facilitando a escolha do modelo
adequado a cada aplicação.
A plataforma .NET é disponibilizada em alguns moldes de aplicação para
P2P (MSDN Magazine, 2001), podendo eles ser:
• Web Services: Serviços de download e abertura de registros são
mecanismos agregados nesse tipo de modelo.
• Windows Forms: Interfaces gráficas mais atraentes para aplicações
P2P podem facilmente ser desenvolvidas nesse tipo de modelo, por
este manipular diretamente bibliotecas API’s e outras gráficas.
• Service Process: Em sistemas distribuídos, onde o processamento
paralelo é o recurso mais utilizado pela aplicação P2P, identifica-se
mais com este modelo.
4.1.6.6 GROOVE DEVELOPMENT KIT (GDK)
O GDK (Networks, 2008) é uma plataforma de desenvolvimento de
aplicações P2P que pode ser utilizada gratuitamente, contudo para distribuição das
aplicações é necessário a aquisição das licenças de distribuição.
Com seu desenvolvimento em MCOM (Microsof Component Object Model),
o GROOVE além de permitir a prototipação rápida de aplicações P2P utilizando
linguagens script (VBSCript ou JavaScript), requer que qualquer extensão deva ser
implementada utilizando objetos COM, amarrando assim os programas às
plataformas Microsoft.
Outra característica do Groove é o mesmo utilizar uma abordagem híbrida,
36
permitindo o uso de soluções centralizadas e/ou descentralizadas.
GROOVE tem disponível para implementação os seguintes serviços:
• Armazenamento de mensagens enviadas para clientes off-line
• Serviços de interface gráfica
• Sincronismo de dados (através de gerenciamento)
• Acesso compartilhado em tempo de execução, tornando assim
ferramentas de desenvolvimento comuns a grupos
• Serviço de localização (identificação) de usuários on-line
• Ferramentas de publicação, que permitem disponibilizar, criar,
refinar e testar os itens desenvolvidos.
4.1.7 PADRONIZACAO POR XML
As principais vantagens de JXTA são prover uma comunicação entre peers
muito melhor do que os protocolos P2P existentes, permitindo uma grande
variedade de serviços, dispositivos e formas de transporte na rede. O emprego de
XML auxilia o JXTA, pois provê um formato padrão para a estruturação dos dados e
uma melhor compatibilidade entre os meios de transporte.
Mas também existem problemas na definição de JXTA, principalmente na
chamada dos serviços. Atualmente existem padrões de como deve ser feita à
chamada do serviço, entre eles o WSDL15 amplamente utilizado em serviços para
internet, mas nenhum desses padrões é usado por JXTA. Ou seja, existe a troca de
informações, porém nenhum método padrão de chamada de serviços, (SUNDSTED,
2001).
A questão do uso de XML também é polêmica, apesar de ter as vantagens
citadas, XML também apresenta desvantagens, sendo o overhead causado pela
troca de mensagens XML, dependendo do tipo de aplicação, grande problema,
15 Web Services Description Language: Linguagem de Descrição dos Serviços WEB.
37
principalmente se uma aplicação não tem o objetivo de aproveitar as capacidades de
JXTA de incorporar outros serviços P2P, (LUTHER, BUYYA, RANJAN, &
VENUGOPAL, 2006).
4.1.8 DESEMPENHO JXTA
Para um desempenho eficiente, JXTA usa as seguintes técnicas,
(SUNDSTED, 2001) e (PROJETO JXTA, 2007):
• Alguns tipos de mensagens são encaminhados com um número
definido de saltos, prevenindo o alcance a todos os peers da rede.
• A informação da descoberta de peers na rede é armazenada em
Cache, eliminando assim a necessidade de sempre enviar
mensagens de descoberta de peers toda vez que a informação é
requerida.
• Os dados na rede, dependendo de seu tipo, possuem a propriedade
do TTL ativa, prevenindo assim o acúmulo de informação, quando o
TTL de uma mensagem expira, a mensagem é descartada.
• Peers de alta capacidade são usados para reduzir a carga sobre os
de baixa capacidade de processamento ou de banda.
• O roteamento de mensagens é feito de forma inteligente por cada
nó, para assegurar que a melhor rota está sendo tomada em direção
ao destino das mensagens.
• O protocolo de transporte é selecionado baseado na eficiência da
parte da rede usada no momento. Por exemplo, IP broadcast é
usado em redes locais, enquanto TCP ou HTTP são usados entre
redes LAN para prover a comunicação direta entre os peers.
38
5 CONCLUSÃO
As redes P2P não são inovadoras aos usuários da Internet, nem aos mais
novos e nem aos mais antigos. A diferença básica está na facilidade de acesso a
esse tipo de redes e aos aplicativos que os agregam, principalmente pela facilidade
de usuários residenciais da internet ingressar nas redes P2P.
A diversidade de informações disponibilizadas, em sua maioria
gratuitamente, auxilia em muito no crescimento das redes P2P.
Este trabalho mostrou algumas particularidades das Redes P2P, bem
singularidades de desenvolvimento de aplicações e as plataformas disponíveis para
tal. .Net, Groove e JXTA são as mais comumente usadas, onde esta última se
sobressai das demais. Esta vantagem se deve as facilidades implementadas em sua
arquitetura básica, aos protocolos padrões, métodos de comunicação e distribuição
gratuita na internet.
Aplicações de arquiteturas puramente descentralizadas em sua maioria
foram desenvolvidas em plataforma JXTA e vários são os grupos acadêmicos em
estudo de tal assunto, principalmente pelo seu baixo custo de implementação e pela
confiabilidade de acesso ao conteúdo, porem deve-se tomar cuidado para não ferir
leis de direitos autorais e precaver-se ao disseminar informações sigilosas nas redes
P2P, justamente pela facilidade de distribuição e compartilhamento de conteúdo.
Com tudo isso, é possível concluir que Redes P2P e, sobretudo a
plataforma JXTA é ideal ao desenvolvimento de aplicações P2P.
39
6 REFERÊNCIAS
.NET, M. (Outubro de 2003). Microsoft .NET Homepage. Fonte:
http://www.microsoft.com/net/
ANDERSON, D., COBB, J., KORPELA, E., LEBOFSKY, M., &
WERTHIMER, D. (Novembro de 2002). SETI@home: An Experiment in Public-
Resource Computing.
ANSAWARE. (2008). ANSAware. Fonte: http://www.ansa.co.uk
APPLIED META COMPUTING. (2000). Legion - An Integrated Architecture
for Secure Resource Sharing. Applied Meta Computing Peer-to-Peer Architectural
Proposal.
ARNAUTH, J. (2008). Japão quer banir redes de troca de ficheiros. Acesso
em 2008, disponível em Glob-PT Beta: http://globpt.com/2008/03/23/japao-quer-
banir-redes-de-troca-de-ficheiros/
ASADZADEH, P., BUYYA, R., KEI, C. L., NAYAR, D., & VEBUGOPAL, N.
(2006). Global grids and software toolkits: a study of four grid middleware
technologies. In High Performance Computing: Paradigm and Infrastructure , 431-
458. John Wiley and Sons Inc.
ASTIAZARA, M. V. (2008). Classes Reutilizáveis em VB. Fonte: Classes
VB: http://classesvb.wikidot.com/framework-de-gerenciamento-de-itens-de-
configuracao
BALAKRISHNAN, h., KAASHOEK, m., KARGER, d., MORRIS, r., &
STOICA, I. (Fevereiro de 2003). Looking up data in p2p systems. 42-43. ACM.
CLARKE, I. A. (1999). Distributed Decentralized Information Storage and
Retrieval System. Division of Informatics. University of Edinburgh.
CLARKE, I., SANDBERG, O., WILEY, B., & HONG, T. (2001). Freenet: A
Distributed Anonymous Information Storage and Retrieval System. Designing Privacy
Enhancing Technologies: International Workshop on Design Issues in Anonymity and
Unobservability. (H. Federrath, Ed.) New York: LNCS 2009.
40
COULOURIS, G., DOLLIMOREM, J., & KINDBERG, T. (2001). Distributed
Systems: concepts and applications. Addisson-Wesley.
DHT. (Setembro de 2007). DHT. Fonte:
http://en.wikipedia.org/wiki/Distributed_hash_table
FOSTER, I. (2002). The Grid: A new infrastructure for 21st Century
Science. Physics Today , 2 (55), pp. 42-47.
FRANCESQUINI, E. C. (Junho de 2004). Um estudo sobre sistemas P2P.
GOMES, D., PETEK, M., DIVERIO, T., & GEYER, C. (2006). Impacto de
Diferentes Algoritmos Peer-to-Peer no Desenvolvimento de um Serviço de
Localização de Replicas para Grades. Porto alegre, RS: PPGC–Instituto de
Informatica–UFRGS.
ISO. (2008). ISO and IEC approve OpenDocument OASIS standard for
data interoperability of office applications. Acesso em Setembro de 2008, disponível
em http://www.iso.org/iso/pressrelease.htm?refid=Ref1004
KAMIENSKI, C. S. (Julho de 2004). Colaboração na Internet e a Tecnologia
Peer-to-Peer.
LIMA Jr, & de PAULA, L. A. (2001). Objetos Distribuídos. pp. 145-173.
LIMA, A. (2005). P2P, LBS Comunidades Virtuais: Os Ingredientes para
Aplicações Inovadoras em Sistemas 3G. UFPE.
LUTHER, A., BUYYA, R., RANJAN, R., & VENUGOPAL, S. (2006). Peer-
to-peer grid computing and .net-based alchemi framework. High Performance
Computing: Paradigm and Infrastructure. John Wiley and Sons Inc.
MILOJICI, D. S., KALOGERAKI, V., LUKOSE, R., NAGARAJA, K.,
PRUYNE, J., RICHARD, B., et al. (2003). Peer to peer computing. Palo Alto: HP
Laboratories.
MSDN Magazine. (Fevereiro de 2001). .NET P2P: Writing Peer-to-Peer
Networked Apps with the Microsoft .NET.
Networks, G. (2008). Groove Platform Development Kit (GDK). Fonte:
http://www.groove.net/devzone/default.cfm?pagename=Platform_GDK
41
ORAM, A. (2001). Peer-to-peer: Harnessing the power of disruptive
technologies. O’Relly.
PANISSON, A. (2007). Redes P2P e a Plataforma JXTA. UFRGS.
PFITZMANN, A., & WAIDNER, M. (1987). Networks without User
Observability (Vol. 6). Computer Security 2.
PROJETO JXTA. (2007). PROJETO JXTA. Acesso em Julho de 2007,
disponível em JXTA: http://jxta.sun.org
PROJETO NAPSTER. (2007). PROJETO NAPSTER. Acesso em Julho de
2007, disponível em http://www.napster.com
PROJETO SETI@home. (Julho de 2007). PROJETO SETI@home. Fonte:
http://setiathome.ssl.berkeley.edu
PROJETO USENET. (2007). PROJETO USENET. Acesso em Julho de
2007, disponível em http://www.usenet.net
REMOALDO, P. (2008). TCP/IP. Acesso em 10 de Setembro de 2008,
disponível em TCP/IP: http://paginas.fe.up.pt/~mgi97018/tcpip.html
STOICA, I., MORRIS, R., KARGER, D., KAASHOEK, M. F., &
BALAKRISHNAN, H. (2001). Chord: A scalable peer-to-peer lookup service for
internet applications. pp. 149-160.
SUNDSTED, T. (Março de 2001). The practice of peer-to-peer computing:
Introduction and history.
TCP/IP, R. 1. (Janeiro de 1991). RFC 1180 - A TCP/IP Tutorial - from the
Internet Engineering Task Force. Acesso em 2008, disponível em IETF:
http://tools.ietf.org/html/rfc1180
THAIN, D., TANNENBAUM, T., & LIVNY, M. (Abril de 2005). Distributed
Computing in Practice: The Condor Experience. Concurrency and Computation:
Practice and Experience , 17, pp. 323-356.
THEODOLOZ, N. (Fevereiro de 2004). DHT-based routing and discovery in
JXTA. School of computer and communication sciences. Computer Science
Department. École Polytechnique Fédérale de Lausanne.
42
VERBEKE, J., NADGIR, N., RUETSCH, G., & SHARAPOV, I. (2003).
Framework for Peer-to-Peer Distribution Computing in a Heterogeneous,
Decentralized Environment. Palo Alto: Sun Microsystems Inc.
YANG, B., & GARCIA-MOLINA, H. (Setembro de 2001). Comparing Hybrid
Peer-to-Peer Systems. pp. 561-570.