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
 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

i
 LISTA DE TABELAS

Tabela 1 - COMPARATIVO ENTRE AS ARQUITETURAS P2P

(FRANCESQUINI, 2004) ................................................................... 16

ii
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.

1
 Figura 1 - Modelo de Rede Centralizada (cliente-servidor) (ASTIAZARA, 2008)

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)

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.

3
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.

4
 Camadas Agentes

Figura 3 - Protocolo TCP/IP, suas camadas e seus agentes. (REMOALDO, 2008)

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.

5
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.

6
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.

7
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.

8
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,

9
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;

10
 - 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.

11
Figura 4 - Exemplo de serviço de localização centralizada (APPLIED META COMPUTING,
2000)

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.

12
(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.

1) Peer’s existentes na rede, mas não visitados na busca;

6
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

7
TTL: Time-To-Live, que significa o tempo de vida de trafego das informações na rede.

13
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.

14
 192.168.3.10
192.168.21.100

192.168.21.105
192.168.3.5
192.168.21.1
Convencionais
192.168.5.1
192.168.21.106
Super-peers

192.168.5.1
192.168.80.37
192.168.37.1
192.168.5.2 192.168.80.56

Figura 6 - Arquitetura de Super-Peers e peers convencionais (STOICA, MORRIS, KARGER,

KAASHOEK, & BALAKRISHNAN, 2001)

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

15
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.

16
 • 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.

17
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).

18
 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,

19
(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, &

20
HONG, 2001) e (PFITZMANN & WAIDNER, 1987).

21
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.

22
 Figura 7 - Arquitetura de Rede Virtual JXTA (PROJETO JXTA, 2007)

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.

23
 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)

24
 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.

25
 • 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.

26
 • 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.

27
 Peer Local Peer Remoto

Peer Discovery Protocol Peer Discovery Protocol

Peer Information Protocol Peer Information Protocol

Pipe Binding Protocol Pipe Binding Protocol

Peer Resolver Protocol Peer Resolver Protocol

Rendezvous Protocol Rendezvous Protocol

Endpoint Routing Protocol Endpoint Routing Protocol

Camada de Transporte Camada de Transporte

Figura 9 - Empilhamento de protocolos JXTA (PROJETO JXTA, 2007)

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

28
 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.

3. Um peer Edge que recebe a

1. O Peer 1 envia mensagem propagada envia a
uma mensagem RVP resposta diretamente ao peer
a todos os peers inicialmente responsável pelo
conhecidos. Peer Edge 1 envio da mensagem.

Peer 1 Peer Edge 2

Peer RendezVous
2. O Peer RendezVous que
recebe a mensagem RVP retorna
uma resposta contendo todos os
anúncios existentes em sua
cache. Além disso, propaga a
busca a todos os peers
conhecidos. Peer Edge 3

Figura 10 - Demonstração do protocolo RVP (PANISSON, 2007)

4.1.5.5 PIPE BINDING PROTOCOL – PBP

Através de mensagem de consulta, requer qual peer deve ser ligada a qual

endpoint.

29
 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.

Rede interna Rede Externa (Internet) Rede interna 2

1. O Peer 1 envia a mensagem 2. O Peer Roteador 1 3. O Peer 2 periodicamente se

ao peer Roteador 1 a fim de encaminha a conecta ao Peer Roteador 2 a
encaminhá-la ao Peer 2 mensagem ao Peer fim de verificar as mensagens
através do Roteador2, Roteador 2 que chegaram.
conforme informação obtida
previamente

Peer 1 Peer Roteador 1 Peer Roteador 2 Peer 2

Firewall 1 Firewall 2

Figura 11 - Demonstração do protocolo PEP (PANISSON, 2007)

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,

30
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.

31
 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.

32
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.

33
 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).

Figura 12 - Exemplo de retorno das funções executadas (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.

34
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,

35
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.

36
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.

37
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.

38
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.

39
 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

40
 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.

41
 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.

42