Plugin 2003P2PJXTA

Antonio Augusto Mariano da SilvaRicardo Augusto MiguelRicardo Ribeiro Tavares

Desenvolvendo aplicaçõespeer-to-peer em JAVA com

JXTA

São Paulo2003

4

SUMÁRIO

1. INTRODUÇÃO ....................................................................................................................6

2. CONCEITOS E ARQUITETURAS DE REDES P2P.....................................................11

2.1 CARACTERÍSTICAS DAS REDES P2P......................................................................112.2 PROCESSAMENTO DISTRIBUÍDO: SETI@HOME .................................................122.3 REDES P2P COM INDEXAÇÃO CENTRALIZADA: O NAPSTER .........................132.4 A REDE DESCENTRALIZADA: PROJETO GNUTELLA.........................................14

3. INTRODUÇÃO AO JXTA................................................................................................20

3.1 PRINCIPAIS CONCEITOS DA TECNOLOGIA .........................................................233.1.1 JXTA ID ...................................................................................................................233.1.2 ADVERTISEMENTS................................................................................................243.1.3 PEERS .....................................................................................................................243.1.4 PEER GROUPS.......................................................................................................253.1.5 PIPES.......................................................................................................................253.1.6 ENDPOINTS............................................................................................................263.1.7 JXTA MESSAGES....................................................................................................263.1.8 RENDEZVOUS PEERS ...........................................................................................273.1.9 RELAY PEERS.........................................................................................................28

3.2 PROTOCOLOS JXTA ...................................................................................................293.2.1 PEER DISCOVERY PROTOCOL (PDP)................................................................303.2.2 PEER RESOLVER PROTOCOL (PRP) ..................................................................313.2.3 PEER INFORMATION PROTOCOL (PIP) ............................................................333.2.5 PIPE BINDING PROTOCOL (PBP).......................................................................343.2.6 ENDPOINT ROUTING PROTOCOL (ERP)...........................................................36

4. JXTA SHELL .....................................................................................................................39

4.1 CONFIGURAÇÃO INICIAL JXTA SHELL.................................................................404.2 COMANDOS JXTA SHELL .........................................................................................43

4.2.1 MAN.........................................................................................................................434.2.2 PEERCONFIG.........................................................................................................444.2.3 RDVSTATUS............................................................................................................444.2.4 ENV..........................................................................................................................444.2.5 CAT..........................................................................................................................444.2.6 GREP.......................................................................................................................444.2.7 HISTORY .................................................................................................................454.2.8 VERSION.................................................................................................................454.2.9 EXIT.........................................................................................................................454.2.10 GROUPS................................................................................................................454.2.11 PEERS ...................................................................................................................464.2.12 WHOAMI...............................................................................................................47

4.3 CRIANDO UM GRUPO NA REDE JXTA...................................................................474.4 CONVERSANDO NA REDE JXTA.............................................................................504.5 CACHING DE ADVERTISEMENTS...........................................................................524.6 A IMPORTÂNCIA DOS PIPES ....................................................................................53

5

5. ESTUDO DE CASO: CHAT P2P DESCENTRALIZADO............................................56

5.1 CHAT CLIENTE/SERVIDOR X CHAT P2P ...............................................................565.2 ARQUITETURA HÍBRIDA CLIENTE/SERVIDOR E P2P ........................................585.3 EXECUTANDO A APLICAÇÃO .................................................................................605.4 CONFIGURANDO O AMBIENTE JXTA....................................................................615.5 ANALISANDO O CÓDIGO FONTE............................................................................615.6 CLASSE CHAT.CHATAPP.JAVA...............................................................................62

6. CONCLUSÃO.....................................................................................................................69

REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................72

GLOSSÁRIO ..........................................................................................................................77

APÊNDICE A – CÓDIGOS FONTE DA IMPLEMENTAÇÃO .......................................79

6

1. INTRODUÇÃO

No final da década de 60 a Internet foi concebida como um sistema originalmente

P2P, onde as máquinas participantes dessa rede trocavam informações com apenas alguns

servidores robustos. Com a popularização e o avanço dos navegadores, e o aumento da

capacidade de processamento dos servidores, a internet tornou-se uma rede de potentes

servidores entregando conteúdo para os clientes requisitantes.

Como proposta inicial da Internet haveria acesso irrestrito a todos os recursos da rede,

a qualquer momento, de qualquer lugar, com o uso de qualquer dispositivo. Apesar disso, a

Web, ainda hoje está sujeita a um modelo de rede capaz de inibir o acesso a recursos,

restringir a riqueza e a profundidade do conteúdo e até mesmo impedir o crescimento da

própria Web.

A Tecnologia P2P é um esforço concebido, com o objetivo de fornecer acesso total a

Web, acompanhando sua constante expansão e aprofundamento.

A popularidade de tecnologias de rede P2P aumentou dramaticamente nos últimos

anos. Esses serviços estão se proliferando cada vez mais, pela conveniência da comunicação

instantânea que proporcionam e pela redução constante dos limites de tráfego que permite a

distribuição de filmes, músicas e outros recursos com grande volume de dados.

As pessoas buscam, então, acesso a um conteúdo cada vez com maior qualidade.

7

A Web atual utiliza um modelo cliente-servidor no qual servidores centralizados

executam tarefas para clientes distribuídos. No modelo P2P, qualquer cliente autorizado pode

ter acesso a qualquer serviço na rede comunicando-se com o servidor em que o serviço está

residente.

Quanto à comunicação P2P, se necessitarmos de caminho inverso ou até mesmo para

uma máquina cliente conectar-se a um outro ponto remoto, diversos problemas e dificuldades

ainda são enfrentados, basta lembrar o funcionamento do popular software de mensagem

instantâneas ICQ. Utilizar o ICQ corretamente via um servidor proxy e principalmente através

de um firewall é uma tarefa que exige configurações especiais nesses servidores.

As maiorias das redes protegidas permitem apenas o tráfego de informações por

http/https, geralmente na porta 80/443. Para envio de mensagens assíncronas alguns softwares

usam técnicas como postagem de conteúdo xml e web-services para um servidor que conhece

ambos os nós, porém para a transferência de arquivos entre nós remotos isto é praticamente

impossível.

Outro exemplo clássico das dificuldades enfrentadas por aplicativos P2P como os

famosos compartilhadores de arquivos Kazaa e o antigo Napster, é a utilização adequada da

largura de banda. Precisamos considerar nestes aplicativos que a utilização de banda ocorre

principalmente na hora da transferência de arquivos entre as máquinas. Uma rede local

compartilhando 10 máquinas com uma banda de 256 k para download e 128 k para upload

(como atualmente ser fornecem os serviços de ADSL mais comuns no Brasil) é praticamente

sobrecarregada tanto agindo como cliente P2P ou como aplicação servidora de arquivos.

8

Porém uma das características de sucesso das redes P2P é que ela pode ser totalmente

descentralizada.

O maior problema enfrentado pelo Napster foi a questão jurídica da troca de arquivos

.mp3 entre os usuários. O que realmente o condenou ao “desaparecimento” foi o fato de ser

um aplicativo que utilizava metodologias de redes P2P híbridas. Sendo assim a lista de

arquivos .mp3 de seus usuários ficavam centralizadas em seu servidor, que “negociava”

depois a conexão dos pontos remotos. Com essa centralização tirá-lo do ar foi uma tarefa

relativamente simples para os advogados das grandes gravadoras. A solução do Napster

tecnicamente é uma solução bastante interessante, pois garantindo a centralização dos dados

diminui-se a redundância dos arquivos e ao mesmo tempo agiliza e facilita o processo de

pesquisa de arquivos, porém para um assunto tão polêmico como compartilhamento de mp3,

esta característica significou a morte desta rede.

Diante dessa questão da sobrevivência da rede independente de um servidor

centralizado, muitas técnicas surgiram e hoje são utilizados em aplicativos como o

compartilhador de arquivos e-donkey. A técnica é basicamente fazer com que cada cliente

“compartilhe” além dos arquivos também os nós de rede conhecidos e próximos. A grande

desvantagem é a forma como é realizada a pesquisa dos arquivos. Uma consulta simples pode

viajar por diversos nós até encontrar uma resposta, e mesmo você não tendo arquivo algum a

compartilhar seus recursos estarão sendo utilizado.

Como se tem visto nos últimos anos, os usuários da internet querem muito mais do que

receber conteúdo pela porta 80, e a explosão da utilização dos softwares descritos

anteriormente prova isso mesmo enfrentando os problemas mencionados acima.

9

Tentaremos resgatar neste estudo a real necessidade da cooperação entre os

computadores participantes da internet, utilizando assim uma estrutura de rede menos

centralizada e restrita. Apesar do assunto principal discutido aqui ser redes P2P não teremos

como fugir de conceitos computacionais tradicionais como criptografia, segurança, algoritmos

de compactação,redes tcp/ip entre outros, pois os mesmo sempre estarão sendo aplicados na

construção de aplicativos P2P.

Para o arquiteto de soluções P2P, muitos outros problemas acontecem, como por

exemplo a escolha adequada da tecnologia e plataforma a serem utilizadas.

Neste estudo estaremos mostrando a importância do framework JXTA para o

desenvolvimento de aplicações P2P em JAVA.

O objetivo principal de qualquer framework de desenvolvimento é aumentar a

produtividade e encapsular funcionalidades, permitindo ao desenvolvedor concentrar-se nas

características de sua aplicação, e não reescrevendo e testando funcionalidades que não dizem

respeito diretamente ao escopo inicial do seu projeto.

"O Projeto JXTA ampliará o acesso à Web e a profundidade do contúdo disponível",

Joy Bill (Sun Microsystems,Inc).

Através do JXTA a computação distribuída e as tecnologias não-hierárquicas entram

em ação.

10

Apesar de ser baseado na tecnologia P2P, o JXTA é muito mais do que uma proposta

P2P, pois oferece mecanismos para a criação e o fornecimento de uma categoria de serviços e

aplicativos inteiramente nova e para a ampliação dos serviços Web de locais fixos ou

centralizados para a borda da rede.

Considerando as dificuldades do tema abordado e para fixar e exemplificar os

conceitos aqui apresentados, estaremos desenvolvendo uma aplicação case onde os pontos

(Nós da rede) trocam mensagens de texto como em uma aplicação de chat tradicional.

Estaremos disponibilizando os códigos fonte para quem tiver interessado.

11

2. CONCEITOS E ARQUITETURAS DE REDES P2P

2.1 CARACTERÍSTICAS DAS REDES P2P

Nos últimos anos tivemos diversas aplicações P2P sendo usadas por milhões de

usuários. Para citar algumas das mais populares podemos lembrar do ICQ (I seek you) e do

Napster. Estas duas aplicações revolucionaram a utilização da internet e aproximaram cada

vez mais as pessoas conectadas através da internet.

Diversas funcionalidades podem ser fornecidas por dispositivos conectados em uma

rede P2P:

· Compartilhamento de arquivos e publicações.

· Armazenamento distribuído e compartilhamento de capacidade de armazenamento.

· Busca Semântica e distribuída entre os peers.

· Compartilhamento de capacidade de processamento e processamento distribuído

· Formação de grupos ou comunidades de peers.

· Colaboração de informações, trocas de mensagens instantâneas e comunicação entre

os peers.

Antes do surgimento das aplicações P2P, a utilização da internet por usuários comuns

consistia em uma rede praticamente cliente/servidor, com diversos clientes requisitando

conteúdo e serviços publicados por servidores com endereços fixos registrados no DNS

(Domain Name System) [TRUELOVE, K., 2001].

12

Com a inovação tecnológica e a popularização de diversos dispositivos com acesso a

Internet, como por exemplo, celulares de última geração e PDA’s (Personal Digital

Assistants), passamos a contar com uma rede mais transiente, na qual estes dispositivos

também são capazes de fornecer recursos, porém nem sempre estarão conectados ou

utilizando-os o mesmos endereços. O aumento da largura de banda, e a maior disponibilidade

de acesso fizeram com que os usuários sentissem a necessidade de uma rede mais

colaborativa, na qual a busca de conteúdo e serviços, além da interação com outros usuários,

deixa de ser privilégio de alguns servidores. Essas talvez tenham sido as motivações para o

constante crescimento das redes e aplicativos P2P [TRUELOVE, K., 2001]. Diversas

arquiteturas de aplicações tem sido utilizadas ao longo do tempo em aplicações P2P. A

seguir abordaremos o funcionamento básico de algumas aplicações importantes na evolução

de sistemas P2P.

2.2 PROCESSAMENTO DISTRIBUÍDO: SETI@HOME

O grande poder de processamento dos atuais computadores pessoais e a ociosidade da

maioria desses computadores, possibilitam o surgimento de aplicações com um

processamento realmente distribuído, espalhadas pela internet [SUN MICROSYSTEMS,

INC., 2001]. O projeto SETI@HOME (Search for Extraterrestrial Intelligence), com objetivo

de identificar vida inteligente fora do planeta terra, é um exemplo bem sucedido deste tipo de

aplicação. Ao instalar o screen-saver do projeto, estaremos contribuindo com parte dos

cálculos para análise de sinais de rádios, capturados diariamente por potentes telescópios.

Depois de realizada a análise dos dados obtidos quando o computador está ocioso, os

13

resultados são enviados para os servidores localizados na Califórnia, que mantém centralizado

todos resultados obtidos. Para realizar a análise desses dados em um único computador, uma

capacidade de processamento muito grande seria necessária por um longo tempo, e o custo

para realização dessa tarefa poderia inviabilizar o projeto. A utilização de recursos ociosos

espalhados pela internet, de forma gratuita, era talvez uma das poucas soluções disponíveis

que viabilizariam o projeto [Web site SETI@home]. Os diversos resultados obtidos das

análises realizadas, e a evolução do projeto, podem ser conferidos no site

http://setiathome.ssl.berkeley.edu/.

O projeto SETI@HOME foi um dos pioneiros na distribuição de tarefas para

processamento distribuído pela internet, e a quantidade de resultados obtidos contribuem para

a análise de vida extra terrestre, alem de possibilitar que diversos usuários anônimos pela

internet possam dar sua contribuição em termos de recursos para o projeto.

2.3 REDES P2P COM INDEXAÇÃO CENTRALIZADA: O NAPSTER

O Napster pode ser considerado um marco na história da internet, especialmente

quando falamos de um assunto tão polêmico como compartilhamento de MP3. Criado

originalmente com este propósito, o Napster permitia a seus usuários a rápida pesquisa de

arquivos .mp3 compartilhados e a troca de mensagens instantâneas entre peers.

Depois de configurada a pasta de compartilhamento de conteúdo, o Napster enviava a

lista de arquivos compartilhados para um repositório central de dados, que era o responsável

também pelo armazenamento e atualização do endereço IP de cada conexão realizada pelo

14

programa. Este repositório central de dados também indica se um determinado usuário está

on-line naquele momento ou não [PARAMESWARAN, M.; SUSARLA, A.; WHINSTON ,

A., 2001].

Essa arquitetura centralizada de indexação de conteúdo foi a grande responsável pela

eficiência da procura de arquivos .mp3 no Napster, pois dessa maneira, os servidores

responsáveis pela indexação, poderiam retornar todos os peers on-line que possuíam um

determinado arquivo em uma busca rápida e precisa. Depois de realizada a busca do conteúdo

desejado, toda a comunicação e troca de informações eram feitas diretamente entre os peers,

sem carga adicional nos servidores de indexação, que atuavam apenas realizando buscas,

autenticando usuários e “apresentando” peers, possibilitando que esses efetuassem a

transferência de dados diretamente da melhor forma possível.

Esta arquitetura centralizada também foi a grande responsável pelo fim do Napster.

Após uma ação judicial, os servidores centrais de indexação de conteúdo foram impedidos de

funcionar, e os peers não podiam mais contar com a busca centralizada e não sabiam mais

quem possuía um determinado conteúdo. Também ficou fácil para as autoridades saberem

quem estava requisitando um determinado tipo de conteúdo, e em pouco tempo, grande parte

das buscas que envolviam conteúdos com direitos autorais estavam censuradas, o que levou

gradativamente a rede Napster ao fim.

2.4 A REDE DESCENTRALIZADA: PROJETO GNUTELLA

15

O aplicativo compartilhador de arquivos GNUTELLA foi desenvolvido em meados de

março de 2000. Sua versão inicial foi desenvolvida por Justin Frankel e Tom Pepper,

criadores do famoso player de arquivos de áudio WINAMP. A empresa criada por eles

chamada NULLSOFT, detentora inicial do WINAMP foi adquirida pela AOL em 1999

[ANDY, O., 2001].

Desenvolvido em apenas 14 dias, o GNUTELLA ficou poucas horas hospedado nos

servidores da AOL, e foi baixado por mais de 10.000 usuários. Imediatamente receosa de

futuras ações judiciais por parte das grandes gravadoras musicais, o software foi retirado do ar

e o projeto encerrado dentro da empresa. Porém, os 10.000 downloads realizados foram

suficientes para a continuidade da rede [ANDY, O., 2001]. Brian Mayland iniciou o processo

de engenharia reversa do software original, continuando a idéia em um projeto open source

com ajuda de diversos outros programadores espalhados pelo mundo. Atualmente diversos

softwares compartilhadores de arquivo utilizam o protocolo de comunicação criado no projeto

GNUTELLA, e assim compartilham a mesma rede.

Por atuarem tanto como clientes quanto servidores, esses softwares são apelidados de

“servents”. Cada servent funciona basicamente como um web server, servindo os conteúdos

compartilhados; e como um browser, pesquisando e requisitando os conteúdos armazenados

distribuidamente nos servents de outros peers. Toda a comunicação realizada pelos peers é

efetuada pela porta 80, utilizando o protocolo HTTP (Hiper Text Transfer Protocol), o mesmo

utilizado pelos web browsers [ANDY, O., 2001].

O objetivo inicial do projeto era desenvolver um aplicativo compartilhador de

arquivos totalmente descentralizado, e que sobrevivesse a qualquer tipo de intervenção. Para

que isso seja possível, a rede formada pelos usuários do GNUTELLA não tem um servidor

16

central de indexação e a busca é realizada ponto a ponto por cada computador participante da

rede, utilizando técnicas como flooding, isto é, enviando consultas para todos os

computadores conhecidos de um peer, e esses computadores enviam a mesma consulta para

todos os seus conhecidos, com objetivo de propagar as consultas para o maior número de

peers conhecidos.

Cada nó nesta rede é responsável por manter a lista de nós conhecidos, buscar novos

peers na rede, e encaminhar cada requisição (Identificada unicamente por uma chave gerada)

para os peers conhecidos, até que algum deles responda avisando que possui o conteúdo

desejado. Neste caso as respostas percorrem o caminho de volta, identificando o peer que

possui o conteúdo. Toda e qualquer requisição de consulta é armazenada em cache, isto é,

armazenada localmente pelos peers para uma futura consulta, evitando que as informações

sejam desperdiçadas e que requisições duplicadas sejam reenviadas. Além disso, somente a

identidade do último peer que encaminhou a requisição é conhecida, garantindo a privacidade

na busca de conteúdo. Somente o conteúdo que fez a requisição sabe que uma determinada

consulta pertence a ele. Para os participantes da rede, não há como distinguir se o peer que

encaminha uma consulta, é realmente o que originou esta consulta ou simplesmente mais um

peer encaminhando a consulta, dando assim a continuidade do processo de pesquisa do

conteúdo requerido [ANDY, O., 2001].

17

Figura 1 - Propagação de busca entre peers na rede GNUTELLA.

Por ser uma rede totalmente descentralizada, é necessário conectar-se a um host

participante da rede para poder ingressá-la. Um cache de host também é fornecido

inicialmente e permite a descoberta e a apresentação de outros peers.

Um dos notórios problemas dos aplicativos que utilizam o protocolo GNUTELLA, é o

seu consumo de banda e a demora na realização de buscas. Isso acontece devido a total

descentralização da rede e a repetição das mensagens de busca enviadas. Cada mensagem de

busca contém um TTL (Time To Live), caracterizado pelo número de saltos máximos (Hops

to Live, HTL) entre peers que a mensagem deve sobreviver na rede. O padrão utilizada no

GNUTELLA é de 256 HTLs para cada busca realizada. A cada peer em que a busca é

encaminhada este valor é decrementado, evitando que uma mensagem seja propagada

infinitamente pela rede [ANDY, O., 2001], [ANDY, O., 2001]. Apesar do consumo de banda

excessivo e da demora na obtenção de resultados, as buscas são sempre efetivas e o conteúdo,

18

caso disponível na rede, quase sempre encontrado. Caso o conteúdo procurado seja

encontrado, toda e qualquer transferência de dados é realizada diretamente entre o peer que

contém o conteúdo e o que iniciou a busca, pois ambos já conhecem os endereços de rede

utilizados, caracterizando uma comunicação totalmente P2P.

Apesar da descentralização da rede GNUTELLA, alguns softwares clientes possuem

algoritmos para análise da rede, permitindo que peers mais capacitados em processamento e

recursos de banda, fiquem no topo da hierarquia em relação aos peers menos favorecidos.

Desta forma conseguimos manter a descentralização da rede, porém de uma forma mais

organizada, otimizando o tempo necessário para propagação de buscas e reduzindo o consumo

de banda (Figura 2). Dos diversos softwares que utilizam a rede GNUTELLA nem todos

implementam esta funcionalidade ainda, dificultando uma análise efetiva da rede formada

[ANDY, O., 2001].

Figura 2 - Rede GNUTELLA organizada por algoritmos de análise de rede. Peers que possuem maiorcapacidade de processamento ou maior largura de banda ficam no topo da hierarquia, atuando como

reendereçadores de mensagens e indexadores de conteúdo.

A grande vantagem dessa arquitetura totalmente descentralizada em relação à

abordagem cliente/servidor anterior, é a impossibilidade de se acabar com a rede ou inutilizá-

la caso um dos peers participantes saia da rede por algum motivo. A censura de um

19

determinado conteúdo torna-se praticamente impossível dessa forma, e o anonimato e a

privacidade dos publicadores e compartilhadores de conteúdo são garantidas. Mas se

compararmos a eficiência e a rapidez da busca com a arquitetura cliente/servidor utilizada

pelo Napster veremos que esta última leva uma grande vantagem.

Recentemente alguns usuários da rede GNUTELLA foram processados por gravadoras

que descobriram a sua identidade. Mas como isso foi possível em uma rede descentralizada,

sem um controle central de autenticação? A resposta é bem simples. A rede GNUTELLA trata

todos os nós da rede da mesma forma. Não seria difícil para um nó arbitrário forjar a

publicação de um conteúdo bastante requisitado e descobrir o endereçamento IP dos seus

requisitantes. Apesar da pesquisa de conteúdo não revelar a identidade do peer que iniciou a

requisição, a transferência de dados do conteúdo, caso aconteça, e feita diretamente entre os

peers, permitindo que um deles obtenha o endereço de rede utilizado pelo outro [ANDY, O.,

2001]. Com esses dados em mãos a identificação de um usuário em toda a internet é na

maioria dos casos bem simples, uma vez que cada provedor de acesso mantém o histórico e a

localização física de cada conexão.

Figura 3 - Comparação entre as buscas realizadas na rede Napster (Indexação de conteúdo centralizada) ena rede GNUTELLA (Busca distribuída por “flooding”).

20

3. INTRODUÇÃO AO JXTA

JXTA (Juxtapose) é um projeto open source de protocolos P2P baseados em

mensagens XML para o desenvolvimento de aplicativos distribuídos, permitindo que qualquer

dispositivo conectado em uma rede, independente de sua plataforma, natureza, ou protocolo

de rede possa interagir, compartilhar recursos, e formar uma rede distribuída, descentralizada

e cooperativa.

O projeto foi iniciado pela Sun Microsystem em abril de 2001 e teve como arquiteto

líder o chefe do departamento de computação da Sun Billy Joe [SUN MICROSYSTEMS,

INC.]. O nome vem de juxtapose, uma referência ao modelo oposto de aplicações P2P em

relação aos modelos tradicionais utilizados como cliente/servidor. JXTA não é uma

linguagem de programação, é uma especificação que tem implementações em diversas

linguagens como C e Java.

O objetivo do JXTA é facilitar o desenvolvimento de aplicativos P2P, encapsulando

funcionalidades e serviços comuns, escondendo a complexidade das implementações para o

desenvolvedor de aplicativos, podendo esse se preocupar somente com a lógica e os detalhes

pertinentes a sua aplicação [SUN MICROSYSTEMS, INC.].

A idéia básica do JXTA é formar uma camada de rede virtual, independente da rede

real utilizada por cada dispositivo, provendo transparência da rede utilizada pelos dispositivos

e permitindo que mesmo dispositivos conectados indiretamente à internet através de um

proxy, ou por um gateway que realiza o NAT (Network Address Translation), ou até mesmo

21

com restrições de um firewall, possam participar da rede oferecendo serviços. Nessa situação

todo o roteamento necessário para a comunicação de peers entre redes distintas é realizado de

forma transparente, utilizando-se de peers intermediários que possam encaminhar as

requisições entre redes. A especificação JXTA foi concebida para ser independente de uma

linguagem específica de programação (como por exemplo C ou Java), plataformas e sistemas

operacionais (como Windows e LINUX), e mesmo dos protocolos de rede utilizados (como

TCP/IP ou Bluetooth) [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.;

HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003]. A forma básica de

comunicação entre os participantes dessa rede é através de mensagens XML padronizadas,

chamadas advertisements, respeitando os protocolos definidos nas especificações definidas no

projeto JXTA. [GONG, Li, 2002].

Rede Virtual JXTA

Rede Física Mapeamento Virtual

TCP/IP

Firewall

HTTPNAT

PeerID

PeerID

PeerID PeerIDPeerID

PeerIDPeerID

PeerID

Peer

Peer

Peer

Peer

Peer

Peer

Peer

Peer

Figura 4 - JXTA forma uma rede virtual, permitindo a comunicação transparente entre peers queutilizam protocolos diferentes ou pertencem a redes diferentes.

Um dos fatores que contribuem para o sucesso da tecnologia P2P atualmente, e

conseqüentemente do projeto JXTA, é a diversidade de dispositivos tecnológicos presentes

em nossas vidas atualmente. Celulares, PDAs e desktops compartilham muitas informações,

22

mas quase sempre de uma forma indireta, com intermediários, através de servidores e

dependendo de uma rede comum, como a Internet ou uma rede local. Utilizando JXTA

podemos ter esses diversos dispositivos conectados sem a necessidade de uma estrutura

centralizada de rede. O JXTA também permite que a topologia de rede mais adequada para

uma aplicação seja definida por seus criadores, possibilitando o surgimento de novos serviços

e funcionalidades. Cada aplicação possui requisitos de rede que nem sempre se encaixam nos

modelos e arquiteturas tradicionais existentes. Em muitos casos precisamos utilizar mais de

uma arquitetura simultaneamente para suprir os requisitos de uma aplicação, como por

exemplo, utilizar uma comunicação típica cliente/servidor, e em alguns casos específicos

poder comunicar diretamente dois peers sem a necessidade de utilizar um servidor como

intermediário.

Figura 5 - Diversos dispositivos podem compartilhar informações, independente de sua origem ouprotocolo de rede, através da camada de rede virtual oferecida por JXTA.

23

3.1 PRINCIPAIS CONCEITOS DA TECNOLOGIA

O JXTA define algumas abstrações importantes de rede que permitem a formação de

uma camada de rede virtual: Primeiramente um endereço lógico para cada peer é definido em

toda rede, através de um peer ID. Os peers auto-organizam-se em grupos chamados peer

groups, formando domínios virtuais com características pré-definidas. Os peers são

responsáveis também pela criação de recursos e serviços, como por exemplo os peers groups,

que precisam ser publicados para serem válidos para os outros peers participantes da rede

JXTA. Cada recurso e serviço possue um tipo específico de advertisement. As operações de

bind necessárias em ambientes distribuídos, como traduções de nomes em endereços de rede,

são implementadas por mecanismos denominados resolvers. Finalmente pipes são utilizados

para comunicação entre peers de uma forma transparente [TRAVERSAT, B.; ARORA, A.;

ABDELAZIZ, M.; DUIGOU, M.; HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER,

B., 2003]. A seguir definiremos as principais abstrações e componentes característicos da rede

JXTA.

3.1.1 JXTA ID

Cada elemento participante da rede recebe um identificador UUID de 128 bits,

garantido sua correta e única identificação na rede [TRAVERSAT, B.; ABDELAZIZ, M.;

DUIGOU, M.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2002], [TRAVERSAT, B.;

ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.; HAYWOOD, C.; HUGLY, J.; POUYOUL,

E.; YEAGER, B., 2003].

24

3.1.2 ADVERTISEMENTS

Todas as entidades participantes da rede P2P (peers) são representadas por

advertisements. Peers publicam, isto é, disponibilizam dados na rede, mantém um cache e

trocam advertisements para descobrir novos peers e buscar novos recursos na rede. Os

advertisements representam uma abstração de um determinado recurso disponível em uma

rede JXTA. Toda e qualquer publicação e descoberta de objetos participantes na rede JXTA é

feita através de publicação de advertisements específicos [TRAVERSAT, B.; ABDELAZIZ,

M.; DUIGOU, M.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2002], [TRAVERSAT, B.;


E.; YEAGER, B., 2003].

Figura 6 - Exemplo de um advertisement para criação de um peer grupo na rede JXTA.

3.1.3 PEERS

Peer é qualquer entidade que possa participar e interagir com a rede, seja ela um

computador, um processo, um processador ou até mesmo um usuário. Para ser considerado

um peer essa entidade deve ao menos entender os protocolos de comunicação básicos

definidos pela tecnologia, como o Peer Resolver Protocol e o EndPoint Router Protocol,

explicados mais adiante neste capítulo [TRAVERSAT, B.; ABDELAZIZ, M.; DUIGOU, M.;

HUGLY, J.; POUYOUL, E.; YEAGER, B., 2002], [TRAVERSAT, B.; ARORA, A.;

<?xml version=”1.0”?><!DOCTYPE jxta:PGA><jxta:PGA xmlns:jxta=”http://jxta.org”><GID>urn:jxta:jxta-NetGroup</GID><MSID>urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000010206</MSID><Name>NepPeerGroup</Name><Desc>NetPeerGroup by default</Desc></jxta:PGA>

25


B., 2003], [SUN MICROSYSTEMS, INC., 2002].

3.1.4 PEER GROUPS

Os peers estão organizados em peer groups. Peers agrupados sob o mesmo grupo tem

algo em comum, como por exemplo, o seu conteúdo compartilhado, e seguem as regras

definidas e atribuídas pelo seu criador. A criação de peer groups e suas regras de utilização

podem ser definidas por qualquer participante da rede JXTA [TRAVERSAT, B.;

ABDELAZIZ, M.; DUIGOU, M.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2002],

[TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.; HAYWOOD, C.;

HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003], [SUN MICROSYSTEMS, INC., 2002].

3.1.5 PIPES

Pipes são canais de comunicação virtuais usados para envio e recebimento de

mensagens entre peers. Pipes não estão associados fisicamente com a localização/endereço de

um peer e são identificados por um pipe ID. Pipes também possibilitam uma comunicação

assíncrona, definindo pipes de entrada e saída. Por não estarem associados com o endereço

físico de um peer, aplicações e serviços que se comunicam através de pipes não são afetadas

pela mudança de localização dos peers e eventuais mudanças de rota que possam acontecer

durante a transmissão de dados. Mensagens são enviadas pelos pipes e recebidas pelos

“ouvintes” registrados neste pipe. Pipes podem restringir o conteúdo a ser trafegado e prover

comunicação segura entre os endPoints [TRAVERSAT, B.; ABDELAZIZ, M.; DUIGOU, M.;

26




Peer B Peer C

Peer D

Peer EPeer A

Pipe

Pipe entrePeer B e Peer E

Figura 7 - A Comunicação entre peers é realizada através de pipes.

3.1.6 ENDPOINTS

É o endereço de rede ao qual um peer está localizado. Ao se estabelecer uma conexão

entre peers os pipes se encarregam de saber o endPoint dos participantes, abstraindo os peers

de um endereçamento físico [TRAVERSAT, B.; ABDELAZIZ, M.; DUIGOU, M.; HUGLY,

J.; POUYOUL, E.; YEAGER, B., 2002], [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ,

M.; DUIGOU, M.; HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003],

[SUN MICROSYSTEMS, INC., 2002].

3.1.7 JXTA MESSAGES

JXTA Messages são mensagens XML padronizadas, utilizadas para a comunicação

entre os peers. A comunicação é feita enviando e recebendo mensagens. Messages podem ser

de vários tipos, cada um específico para o tipo de conteúdo trafegado, como por exemplo,

27

dados binários em grande quantidade [TRAVERSAT, B.; ABDELAZIZ, M.; DUIGOU, M.;




3.1.8 RENDEZVOUS PEERS

Rendezvous Peers são peers especiais que indexam informações sobre outros peers

que ele tem conhecimento. Sendo assim, este peer pode ajudar na busca por um peer

específico ou no roteamento de mensagens propagadas na rede. Caso não haja nenhuma

informação disponível em seu índice, a requisição é passada adiante para outro rendezvous

peer, e assim por diante. Rendezvous peers são de fundamental importância na rede para

diminuir o tráfego de mensagens enviadas e para otimizar o processo de busca de recursos,

evitando que a busca propague-se pela a rede inteira. A publicação de um Rendezvous peers é

feita pela publicação de um advertisements específico para este propósito. [TRAVERSAT, B.;

ABDELAZIZ, M.; DUIGOU, M.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2002],

[TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.; HAYWOOD, C.;

HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003].

28

Rede Virtual JXTA

Rede Física

NAT

Peer A

Adv

Peer 1Peer 2

Firewall

Adv

Adv

Index Index

Adv

Super-Peers

Peer BQuery(1)

Propagação(2)Resposta(3)

Resposta(4)

Índice

Rdv 1 Rdv 2

Figura 8 - Peers rendezvouz otimizam a procura de advertisements na rede, reduzindo o número demensagens propagadas, funcionando muitas vezes como um atalho para encontrar os recursos disponíveis

na rede.

3.1.9 RELAY PEERS

Muito dos peers participantes da rede JXTA possuem conexões temporárias, e

freqüentemente tem o acesso direto à internet restrito por um firewall ou por uma conexão a

ser realizada através de um NAT. Para conseguir acesso aos recursos da rede JXTA, relay

peers podem efetuar o roteamento de mensagens entre peers, possibilitando que ambos se

comuniquem. Relay peers ajudam o roteamento de mensagens entre peers, indicando os

passos necessários (Hops) para que uma determinada mensagem atinja seu destino. Qualquer

peer, desde que tenha as devidas permissões em seu grupo, pode tornar-se um relay peer. A

publicação de Relay peers é feita pela publicação de um advertisement específico para esta

finalidade [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.; HAYWOOD,

C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003].

29

Rede Virtual JXTA

Rede Física

NAT

Peer A

Peer C

Firewall

Super-Peers

Peer B

Resposta(4)

Relay

Relay CRelay D

HTTP

Envio

EnvioPulling

Pulling

Figura 9 - Relay peers possibilitam a comunicação entre peers pertencentes a redes distintas ou comrestrições de um firewall ou NAT.

3.2 PROTOCOLOS JXTA

O JXTA define diversos protocolos, sendo cada um deles responsável por executar

uma tarefa específica na rede P2P como, por exemplo, realizar o roteamento de mensagens e

possibilitar a comunicação entre peers. Cada protocolo é definido por uma ou mais mensagens

em formato XML, trocadas entre os peers participantes da rede. Atualmente estão definidos

seis protocolos com suas funcionalidades explicadas a seguir [TRAVERSAT, B.; ARORA,

A.; ABDELAZIZ, M.; DUIGOU, M.; HAYWOOD, C.; HUGLY, J.; POUYOUL, E.;

YEAGER, B., 2003], [SUN MICROSYSTEMS, INC., 2002]:

30

3.2.1 PEER DISCOVERY PROTOCOL (PDP)

Este protocolo habilita um peer a procurar advertisements do tipo peers, peers groups,

pipes e conteúdo, além de enviar os advertisements publicados pelo próprio peer para o

restante da rede. Este é o principal canal de comunicação do peer com o restante da rede. A

descoberta de novos peers na rede, pode ser feita explicitamente, especificando o UUID do

peer ou do peer group desejado, neste último caso retornando todos os peers pertencentes ao

grupo. A descoberta de todos os peers groups também é possível [TRAVERSAT, B.;


E.; YEAGER, B., 2003], [SUN MICROSYSTEMS, INC., 2002].

Figura 10 - XML Schema que define os elementos de uma Discovery Query.

<Type>

Deve conter o tipo de advertisement que está sendo enviado:

31

0 - Peer Advertisements

1 - Peergroup Advertisements

2 - Qualquer tipo de advertisement

<Threshold>

Deve conter o número máximo de respostas que um peer deve enviar ao receber este

advertisement.

<PeerAdv>

O conteúdo xml do advertisement específico que deve ser enviado.

<Attribute>, <Value>

Elementos podem ser definidos e adicionados ao advertisement a ser enviado. Dessa

forma, outros peers podem procurar por um advertisement específico, contendo um

elemento correspondente ao definido em <Attribute> e também a um valor

específicado em <Value>.

3.2.2 PEER RESOLVER PROTOCOL (PRP)

O PRP habilita um peer a enviar e receber queries para procura de peers, peers groups,

pipes e outras informações na rede. Cada query é associada a um Handler, responsável por

processar a mensagem e aguardar as respostas resultantes da query a serem enviadas pelos

peers. Peers que provêem compartilhamento de arquivos podem oferecer uma busca avançada

de seu repositório de dados para os outros peers [TRAVERSAT, B.; ARORA, A.;



32

Figura 11 - XML Schema para uma Resolver Query, que deve ser enviada a um Handler específicodefinido na rede JXTA. As respostas, caso disponíveis, serão enviadas seguindo as especificações do

Response Query Schema.

<jxta:Cred>

Credêncial do peer que envia a query.

<HandlerName>

Deve conter uma string especificando o Handler de destino que receberá esta query.

<SrcPeerID>

Deve conter o id do peer que originou a query no formato URN.

<QueryID>

Deve conter o id associado a esta query para futuramente identificar as respostas

recebidas.

<HC>

Indica o número de peers que esta query já percorreu. A cada peer que encaminha esta

query, este valor deve ser incrementado.

<Query>

Deve conter a query a ser enviada.

33

3.2.3 PEER INFORMATION PROTOCOL (PIP)

Responsável por obter informações de outros peers, como seu estado atual, tempo de

resposta, utilização de recursos e tráfego atual. Podemos enviar uma mensagem de ping e

saber se o peer ainda continua na rede ou não. Utiliza o Peer Resolver Protocol para enviar e

propagar as requisições de informação [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.;

DUIGOU, M.; HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003], [SUN

MICROSYSTEMS, INC., 2002].

Figura 12 - XML Schema definindo os elementos necessários para o envio de queries para obtenção deinformações de outros peers.

<sourcePid>

Contém o peer id do peer que originou a query.

<targetPid>

Contém o peer id do peer que se quer mais informações.

<request>

Deve contér o tipo de resposta que se quer obter , como por exemplo, o número de

Hops necessários para se comunicar com o peer.

34

3.2.4 RENDEZVOUS PROTOCOL (RVP)

Peers podem se tornar peers do tipo Rendezvous, indexando advertisements do grupo

a que pertence e propagando mensagens para os ouvintes (Listeners) que estão registrados

nele. Este protocolo controla a propagação de mensagens dos peers Rendezvous para os peers

que pertencem ao mesmo grupo [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.;

DUIGOU, M.; HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003].

Figura 13 - XML Schema definindo os elementos necessários para publicação de um RendezvousAdvertisement, transformando um determinado peer como Rendezvous do grupo a que ele pertence.

<Name>

Pode conter um nome opcional associado a este rendezvous peer.

<RdvGroupId>

Deve conter o ID do PeerGroup que este peer se tornará um rendezvous peer.

<RdvPeerId>

Deve conter o ID do Peer que se tornará um rendezvous peer.

3.2.5 PIPE BINDING PROTOCOL (PBP)

Protocolo responsável por realizar a conexão de um peer com um ou mais peers.

35

Para cada peer destino que a conexão virtual é estabelecida, um pipe de entrada e saída é

aberto (isto é, é realizado um “bind”), permitindo assim comunicação assíncrona entre os

participantes. Utiliza o Peer Resolver Protocol para enviar e propagar a requisição de bind dos

pipes [TRAVERSAT, B.; ABDELAZIZ, M.; DUIGOU, M.; HUGLY, J.; POUYOUL, E.;

YEAGER, B., 2002], [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.;

HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003].

Figura 14 - XML Schema definindo os elementos necessários para a criação de um Pipe Advertisement.

<Id>

Deve conter um identificador único para o pipe.

<Type>

Indica o tipo de pipe que está sendo publicado:

JxtaUnicast - Pipe não confiável, não garante a entrega do contéudo, pode entregar o

conteúdo mais de uma vez e não garante a ordem da entrega de conteúdo.

JxtaUnicastSecure – Fornece as mesmas funcionalidades do tipo JxtaUnicast, porém

permite comunicação segura, tendo o seu contéudo criptografado.

JxtaPropagate – Pipe de difusão, utilizado para o envio de mensagens de um para

muitos (one-to-many) pipes.

36

<Name>

Elemento opcional que pode ser adicionado ao advertisement, indicando um nome não

único, facilitando a sua identificação na rede JXTA.

3.2.6 ENDPOINT ROUTING PROTOCOL (ERP)

Protocolo responsável por informar a rota para comunicação entre dois peers distintos

quando uma conexão direta não é possível entre ele. A comunicação direta não será possível

quando dois peers utilizarem redes de protocolos diferentes ou quando entre eles há um

firewall ou a conexão é realizada por NAT. Neste caso o Endpoint Routing Protocol informa a

rota necessária, indicando os gateways necessários para realizar a conexão. Caso a rota entre

dois peers mude, ou a topologia da rede mude por qualquer motivo, este protocolo será

utilizado para indicar a nova rota de comunicação entre eles.

Qualquer peer pode ser um roteador deste tipo implementando o Endpoint Routing

Protocol [TRAVERSAT, B.; ABDELAZIZ, M.; DUIGOU, M.; HUGLY, J.; POUYOUL, E.;

YEAGER, B., 2002], [TRAVERSAT, B.; ARORA, A.; ABDELAZIZ, M.; DUIGOU, M.;

HAYWOOD, C.; HUGLY, J.; POUYOUL, E.; YEAGER, B., 2003].

37

Figura 15 - XML Schema definindo os elementos necessários para o envio de Advertisements, contendoinformações de rota para um determinado peer.

<DstPID>

Deve conter o Peer ID do peer que as informações de rota estão sendo descritas.

<APA>

Contém uma lista de endereço associados com o peer informado.

<Hops>

Contém uma coleção de Advertisements descrevendo uma rota para o peer indicado

em <DstPID>

38

ProtocoloPeer Discovery

ProtocoloPipe Binding

ProtocoloPeer Information

ProtocoloPeer Resolver

ProtocoloRendezvous

ProtocoloEndpoint Routing

Protocolos deServiçosPadrão

(opcional)

ProtocolosCore

(obrigatório)

Figura 16 - Protocolos opcionais e obrigatórios definidos na tecnologia JXTA.

ServiçoDiscovery

ServiçoPipe

ServiçoMembership

ServiçoPeer Info

RPV WalkerServiço

RendezvousSRDI

ServiçoResolver

Serviço Endpoint

Mensageiro Virtual

Mensagem

TransporteHTTP

TransporteTCP/IP

TransporteTLS

AdvertisementsXML

Parser

Gerente deCache Index

ID Relay Router

Serviço PeerGroup

Figura 17 - Referência de Implementação JXTA na plataforma Java 2 Standard Edition.

39

4. JXTA SHELL

Uma aplicação SHELL permite a digitação e execução de comandos em forma de

textos, exibindo o resultado da execução dos comandos para o usuário. Uma das principais

aplicações oferecidas para plataforma JXTA atualmente é o JXTA shell. O JXTA shell, é um

ambiente que através de comandos simples permite explorar a rede, adicionando peers,

peersgroups e enviar qualquer tipo de advertisements, sem a necessidade da utilização de uma

linguagem de programação [KRISHNAN, N., 2003].

Para aqueles que já conhecem o básico do shell de qualquer sistema operacional do

tipo UNIX like (UNIX, LINUX, e derivados), encontramos diversas semelhanças neste

aplicativo, além de muitos comandos com a mesma funcionalidade, como mostramos a seguir.

Para instalar o JXTA Shell, basta realizar o download dos arquivos necessários em

http://download.jxta.org/easyinstall/install.html. A instalação é simples, bastando seguir as

instruções disponibilizadas na página de download.

Além do JXTA shell, a instalação básica disponibiliza uma aplicação chamada

InstantP2P, na qual podemos trocar mensagens instantâneas entre peers, realizar sessões de

chat, compartilhar e pesquisar arquivos compartilhados pelos peers na rede. Tanto o JXTA

shell como o InstantP2P são aplicações codificadas em Java. Diversas API´s (Application

Program Interface) são disponibilizadas, e tarefas como publicação de advertisements,

compartilhamento de arquivos e comunicação entre peers podem ser implementadas para

construção de novos aplicativos.

40

4.1 CONFIGURAÇÃO INICIAL JXTA SHELL

Depois de realizada a instalação, deve-se realizar as configurações básicas e de

segurança de ambas as aplicações. Todas as informações relativas às configurações da

aplicação, bem como o cache de informações da rede realizado, é armazenado no diretório de

instalação escolhido para aplicação.

Depois de instalado, basta iniciar o shell pelo arquivo shell.bat, disponibilizado dentro

da pasta shell contida no diretório escolhido para instalação. Caso o sistema operacional

utilizado seja o Microsoft Windows, uma pasta no menu iniciar estará disponível, contendo os

atalhos correspondentes a cada aplicação. Ao acessar pela primeira vez ambas aplicações,

acessaremos automaticamente as telas de configuração da rede. Nessa tela (Figura 18)

podemos verificar quatro botões correspondentes aos tipos de configuração. Para

configuração utilização inicial siga os passos abaixo [KRISHNAN, N., 2003], [SUN

MICROSYSTEMS, INC., 2001], [OAKS, S.; TRAVERSAT, B.; GONG, Li.]:

1 - Clique no botão nomeado "basic" e preecha a configuração básica, informando o

nome que será identificado o seu peer na rede. Caso sua conexão seja feita por um servidor

proxy é necessário informar o endereço utilizado.

41

Figura 18 - Escolhendo o nome do peer que será identificado na rede JXTA.

2 - Clique no último botão nomeado "security". Escolha um nome de usuário e uma

senha, que serão utilizadas posteriormente para acesso ao shell e a rede JXTA. Essa será a

identificação de seu peer na rede.

Figura 19 - Escolhendo o nome de usuário e senha, dados que são necessários a cada vez que o shell éiniciado.

42

3 – Clique no botão nomeado rendezvous/relays. Clique no botão “download relay and

rendezvous lists”. Marque a opção “use a relay”.

Figura 20 - Recuperando os peers que serão utilizados como relay e rendezvous.

Depois de realizada a configuração, o shell estará pronto para ser utilizado. Ao

visualizar o prompt "JXTA>", podemos digitar qualquer comando válido, que o mesmo será

executado e sua resposta, caso disponível, será exibida na tela.

43

Figura 21 - Tela inicial do JXTA shell.

4.2 COMANDOS JXTA SHELL

Atualmente estão implementados mais de 40 comandos no JXTA Shell [KRISHNAN,

N., 2003], [SUN MICROSYSTEMS, INC., 2001]. A seguir explicaremos os principais

comandos aproveitando para conhecer a rede JXTA e visualizar alguns conceitos

anteriormente explicados.

4.2.1 MAN

Lista todos os comandos disponíveis para serem utilizados. Similar ao comando man

do UNIX. Pode ser utilizado para obter ajuda sobre um comando específico. Ex: man cat

44

4.2.2 PEERCONFIG

Inicia a tela de configuração do Shell novamente na próxima execução do programa.

4.2.3 RDVSTATUS

Indica quais são os peers do tipo rendezvous que estamos conectados. Precisamos

estar conectados pelo menos em um rendezvous peer para conhecer o restante da rede.

4.2.4 ENV

Lista todas as variáveis usados pelo shell. Por padrão são definidas sete variáveis.

4.2.5 CAT

Exibe o conteúdo de uma variável definida pelo shell. Similar ao comando cat

utilizado no UNIX. Esta é a forma básica de exibir o conteúdo de variáveis e objetos criados

no shell.

4.2.6 GREP

Procura uma string específica em uma variável. Similar ao comando grep do UNIX.

45

4.2.7 HISTORY

Lista o histórico de comandos digitados anteriormente

4.2.8 VERSION

Indica a versão atual do shell.

4.2.9 EXIT

Encerra a sessão atual do shell.

4.2.10 GROUPS

Lista todos os grupos que o shell tem conhecimento em seu cache. Para procurar

novos groups na rede devemos enviar o comando groups –r. Para atualizar as informações

mantidas no cache, devemos enviar o comando groups –f. Para listar as informações dos

grupos conhecidos, podemos utilizar a opção –l

46

Figura 22 - Depois de executado o comando groups -r para a descoberta de novos grupos, exibimos osgrupos encontrados com o comando groups.

4.2.11 PEERS

Lista todos os peers que o shell tem conhecimento em seu cache. Da mesma forma que

o comando anterior, podemos descobrir novos peers com o comando peers –r, e atualizar as

informações armazenadas em cache com o comando peers –f. Para listar as informações dos

peers conhecidos devemos utilizar a opção –l.

47

Figura 23 - Resultado da execução do comando peers.

4.2.12 WHOAMI

Indica as informações do seu peer, exibindo os endereços TCP e HTTP utilizados além

dos identificadores(UUID) atribuídos ao peer. Utilizado com a opção –g informa em qual

grupo o peer pertence.

Figura 24 - Resultado da exibição do comando whoami e whoami –g executados no JXTA shell.

4.3 CRIANDO UM GRUPO NA REDE JXTA

Para criar um grupo na rede JXTA, precisamos primeiramente criar o Advertisement

correspondente, e depois publicá-lo para os outros componentes da rede. Segue abaixo um

48

exemplo da criação do Advertisement para grupo com o comando mkadv [KRISHNAN, N.,

2003], [SUN MICROSYSTEMS, INC., 2001], [OAKS, S.; TRAVERSAT, B.; GONG, Li].

JXTA> grupoAdv=mkadv –g grupoteste

Para visualizar o conteúdo do advertisement criado podemos exibir o conteúdo da

variável grupoAdv criada com o comando abaixo:

JXTA> cat grupoAdv

Figura 25 - Ao exibir o advertisement criado, podemos verificar os identificadores atribuídos para amensagem (<MSID>) e para o grupo (<GID>).

Basta agora criarmos o grupo associando o advertisement a ser publicado com o

comando mkpgrp

JXTA> mkpgrp –d grupoAdv

Com o grupo criado podemos visualiza-lo após enviar o comando groups –r e

posteriormente groups:

JXTA> groups –r

JXTA> groups

Figura 26 - Resultado da criação do grupo definido anteriormente, sendo listado após a execução docomando groups.

49

Por default todos os peers pertencem ao NetPeerGroup, que é o grupo no topo da

hierarquia JXTA. Cada peer pode juntar-se a qualquer grupo JXTA existente na rede desde

que possua permissão para integrar o mesmo. Em nosso caso nenhuma forma de autenticação

foi especificada. Para fazer parte do grupo criado anteriormente usaremos o comando join:

JXTA> join grupoteste

Como somos o criador do grupo, podemos especificar o nome dele diretamente no

comando join. Para ingressar outros grupos devemos enviar o comando na seguinte forma:

JXTA> join –d group1

Ao listarmos os grupos com o comando groups os mesmos serão exibidos inicialmente

com o nome seqüencial group1,group2 e assim por diante. Para ingressarmos no grupo

remoto, basta informar o “indíce” atribuído para o grupo. No caso acima estamos acessando o

primeiro grupo listado.

Para deixarmos o grupo basta executar o comando leave.

Figura 27 - Por padrão todos os peers pertencem ao NetPeerGroup, como pode ser verificado pelaexibição do comando whoami -g ao iniciar o JXTA shell. Após requisitar a entrada no grupo 2,

executamos novamente whoami -g, que exibe as informações do grupo atual.

50

4.4 CONVERSANDO NA REDE JXTA

Através do comando talk é possível o envio de mensagens instantâneas para os peers

conectados na rede JXTA. Basicamente podemos enviar mensagens com ou sem segurança,

isto é, podemos enviar mensagens criptografadas aumentando a privacidade e a segurança da

comunicação [KRISHNAN, N., 2003], [OAKS, S.; TRAVERSAT, B.; GONG, Li].

Primeiramente precisamos iniciar o comando talk fornecendo um nick:

JXTA> talk –register meunick

O comando acima basicamente encapsula a criação de um advertisement para os pipes

que serão responsáveis pelo envio e recebimento de mensagens.

Depois de registrado no serviço talk e escolhido um nick precisamos efetuar o login

para iniciar a conversação:

JXTA> talk –login meunick

Após o login qualquer mensagem enviada por um peer remoto será exibida no console.

O comando de login inicia o pipe de entrada, disponibilizando uma thread para verificar a

chegada de conteúdo, permitindo a exibição das mensagens recebidas instantaneamente.

Para procurar outros peers disponíveis para conversação, podemos utilizar o comando

talk-search. Abaixo segue um exemplo para o envio de uma mensagem para você mesmo:

JXTA> talk –u meunick meunick

51

Após executar o comando acima basta digitar a mensagem e terminá-la com um ponto

final “.”.

O comando talk facilita a comunicação na rede evitando a necessidade da criação de

advertisements e outros objetos que permitem a comunicação. Caso seja necessário podemos

criar os advertisements, pipes e enviar mensagens para os peers com os comandos disponíveis

no Shell [KRISHNAN, N., 2003], [OAKS, S.; TRAVERSAT, B.; GONG, Li].

Figura 28 - Exemplo de dois peers (Peer1 e Peer2) conversando na rede JXTA com o comando talk.

52

4.5 CACHING DE ADVERTISEMENTS

Na rede JXTA peers são descobertos freqüentemente, porém não podemos garantir

que sua conexão está disponível em um outro momento. Esses peers são transientes, e é por

isso que as redes P2P são chamadas de redes não confiáveis [KRISHNAN, N., 2003].

Todos as informações e advertisements descobertos pelo shell ficam armazenadas no

diretório ./cm, dentro da pasta escolhida para a instalação do JXTA. A cada reinício o shell

recupera as informações obtidas anteriormente. Muitas dessas informações armazenadas

estarão desatualizadas e em muitos casos inválidas.

Para atualizar as informações armazenadas em cache, os comandos peers e groups

aceitam um argumento –f, realizando uma atualização (flush) das informações quando

solicitado.

Essa técnica de cache é fundamental para diminuir o tráfego de mensagens

redundantes na rede. Para evitar que os advertisements fiquem armazenados por um longo

período no cache das aplicações, um TTL(Time To Live) é especificado junto com o seu

envio, definindo assim o tempo de vida de cada recurso criado na rede JXTA. Essa

característica é fundamental para a auto-suficiência e atualização da rede sem um controle

centralizado [OAKS, S.; TRAVERSAT, B.; GONG, Li.].

53

O cache de advertisements, apesar de padrão nas API’s de binding JXTA, não é

obrigatório e nem padronizado. Cada aplicação escolhe a melhor forma de realizá-lo de

acordo com seus recursos disponíveis [OAKS, S.; TRAVERSAT, B.; GONG, Li].

Figura 29 - Caching de advertisements realizado pela aplicação JXTA Shell. Ao executar qualqueraplicação JXTA, um diretório “\.jxta\cm\“ será criado automaticamente no diretório em que a aplicaçãoestá sendo executada. Nesta figura podemos observar os diversos tipos de advertisements (PeerGroups,

Peers, Messages) armazenados após a primeira execução da aplicação. Ao abrir um dos arquivos em umeditor de texto, podemos verificar o conteúdo XML dos advertisements.

4.6 A IMPORTÂNCIA DOS PIPES

A descentralização e a natural distribuição dos peers na rede JXTA, torna-se um

desafio para a realização de uma comunicação e transferência de dados efetiva. Cada peer

poderá juntar-se a rede em apenas alguns momentos, e ainda assim sua conexão poderá ser

transiente, além de ser realizada em redes que utilizam protocolos diferentes. O principal

objetivo para os desenvolvedores de soluções P2P, é garantir o sucesso na comunicação dos

peers independente da forma de conexão e do protocolo de rede utilizado. Além disso, os

peers podem estar conectados a rede através de um NAT, ou sofrendo restrições na

transmissão de dados por um firewall. Uma das principais soluções adotadas por JXTA para

enfrentar essas dificuldades são a utilização de pipes [OAKS, S.; TRAVERSAT, B.; GONG,

Li].

Para realizar a comunicação entre dois peers em uma rede transiente, heterogênea e

com as dificuldades listadas anteriormente, precisamos realizar várias conexões

54

intermediárias, e utilizar os atalhos e peers roteadores participantes da rede. Por esse motivo,

as conexões realizadas por pipes são comumente referidas como conexões virtuais ou lógicas

[OAKS, S.; TRAVERSAT, B.; GONG, Li]. Essa é uma importante abstração que permite a

efetividade da comunicação e transmissão de dados entre os peers. A forma como é realizada

a comunicação entre pipes, permite que as aplicações se adaptem com as constantes falhas da

rede, requisito fundamental para redes P2P.

Uma das principais características dos pipes é a transparência de rede que eles

permitem para o desenvolvedor de aplicativos. Para realizar a comunicação entre dois pipes,

precisamos apenas de sua identificação na rede JXTA, e todos os processos intermediários

necessários serão executados sempre escolhendo as melhores alternativas e soluções. Em uma

rede local, por exemplo, a melhor forma de se estabelecer comunicação entre dois peers pode

ser utilizando TCP/IP. Esta solução talvez não seja válida para peers que precisam se

comunicar através de um firewall ou pertençam a redes diferentes, e conseqüentemente

utilizarão HTTP para efetuar a transmissão de dados [OAKS, S.; TRAVERSAT, B.; GONG,

Li]. A abstração na forma como é realizada a comunicação entre peers, permitem aos pipes a

utilização dos protocolos TCP/IP e HTTP para a transmissão de dados, de uma forma

transparente para o desenvolvedor de aplicações. A utilização do protocolo HTTP ocorre

quando é necessária a comunicação de peers pertencentes a redes distintas, ou quando um dos

peers tem restrições impostas pela rede utilizada, como por exemplo, um firewall.

A comunicação básica entre pipes é unidirecional e assíncrona, e não há garantia de

que a mensagem será enviada. Porém outros tipos de conexão estão disponíveis e podem ser

utilizadas [OAKS, S.; TRAVERSAT, B.; GONG, Li]:

· Síncrona request/response: Após o envio de uma mensagem uma resposta é enviada

pelo receptor.

55

· Publish/Subscribe: Um pipe do tipo EndPoint registra-se como ouvinte (Subscribe)

para as mensagens enviadas por um publicador(Publish).

· Bulk data transfer: Uma conexão confiável para a transferência de dados binários.

· Streaming: Realiza uma transferência eficiente de dados através de um canal com

controle de fluxo.

Figura 30 - Tipos de pipes que podem ser utilizados para comunicação entre peers.

56

5. ESTUDO DE CASO: CHAT P2P DESCENTRALIZADO

5.1 CHAT CLIENTE/SERVIDOR X CHAT P2P

Chats são aplicações que permitem a troca de mensagens de texto entre uma ou mais

pessoas, e são comumente encontradas em diversos sites da web. A maioria das salas de chat

necessitam de um servidor central para que os clientes possam se conectar e receber novas

mensagens. Ao estabelecer uma conexão com esse servidor central, qualquer nova mensagem

disponível será enviada para o usuário, que recebe todas as mensagens enviada pelos outros

participantes da sala. Toda e qualquer comunicação realizada entre os peers nesta arquitetura

tem que necessariamente passar por este servidor centralizado, que encarrega-se de enviar a

mensagem até o seu correto destino.

Essa arquitetura, apesar de suas peculiaridades, é tipicamente cliente/servidor, e o seu

funcionamento é ideal em muitos casos. Os benefícios oferecidos por uma aplicação

cliente/servidor são diversos, porém muitas desvantagens encontradas nesta arquitetura são

cruciais para outros tipos de aplicação.

O que aconteceria com nossa aplicação de chat se houvesse uma falha neste servidor

centralizado, ou até mesmo na infra-estrutura que conecta o servidor com os diversos

clientes? Quantos clientes simultâneos essa arquitetura é capaz de suportar? Qual o custo para

manter esta aplicação o mais redundante e confiável possível? Mesmo com os avanços das

tecnologias para aplicações de missão crítica qualquer indisponibilidade neste servidor

significa a perda da conexão de muitos usuários, e em muitos casos os custos envolvidos para

57

manter uma alta disponibilidade podem inviabilizar o projeto. No caso de uma aplicação de

chat, geralmente com o objetivo de puro entretenimento, esta talvez não seja uma questão

primordial, porém para aplicações de leilões on-line e negociação em tempo real esta é uma

questão crucial. A arquitetura utilizada para a colaboração e publicação de informações nestas

aplicações é basicamente a mesma utilizada por um chat, logicamente com inúmeras

especificidades que estão além do escopo de nossa aplicação case.

Uma alternativa para o atual modelo cliente/servidor é a comunicação totalmente P2P

entre os participantes. A comunicação neste caso muda radicalmente e passa a ser totalmente

descentralizada. Este modelo de comunicação oferece algumas vantagens, como por exemplo,

uma maior tolerância à falhas. Qualquer peer que tenha problemas na sua conexão com a rede,

não prejudicará os peers restantes, não comprometendo o funcionamento total da aplicação.

Em nossa aplicação, temos ainda a vantagem oferecida por JXTA de comunicar

transparentemente dispositivos pertencentes a redes diferentes, sem nos preocupar qual o

protocolo utilizado, ou qual a melhor rota para realizar a conexão entre eles. Esta

transparência é uma grande funcionalidade oferecida pela tecnologia, e a adição de novas

API´s para outras linguagens, além do Java, contribuirão muito para o crescimento da rede e o

aperfeiçoamento do JXTA.

A principal desvantagem na utilização de uma arquitetura totalmente P2P para uma

aplicação de chat é a quantidade de banda utilizada pelos peers para realizar a comunicação

com todos os outros participantes da rede quando necessário. No caso de enviarmos uma

mensagem para todos os integrantes de uma sala ocupada por 40 usuários, serão necessárias

39 conexões, sendo uma conexão aberta para cada usuário pertencente à sala com exceção do

próprio usuário, e a mesma mensagem será enviada repetidamente para cada usuário.

58

Figura 31 - Chat utilizando arquitetura P2P. Em uma sala contendo N peers serão necessárias N-1conexões para enviar a mesma mensagem para todos os participantes da rede. Neste caso específico, o

consumo de banda entre os peers será maior, porém não precisamos de um servidor central replicando asmensagens, o que limita o número de usuários simultaneamente conectados.

Figura 32 - Chat utilizando arquitetura Cliente x Servidor. Para cada cliente, a conexão é estabelecidaapenas uma vez com o servidor, que replica as mensagens entre os outros usuários conectados. O consumode banda no servidor e a quantidade de recursos necessários aumentam proporcionalmente ao número deusuários conectados. Para os peers, o consumo de banda e recursos necessários para utilizar a aplicação

são mínimos, porém qualquer falha no servidor compromete o funcionamento de todos os clientes.

5.2 ARQUITETURA HÍBRIDA CLIENTE/SERVIDOR E P2P

Uma alternativa para minimizar os impactos negativos, tanto da arquitetura P2P

quanto da arquitetura cliente/servidor, é a utilização de uma arquitetura híbrida, isto é, uma

arquitetura que utilize os modelos cliente/servidor e P2P, aproveitando as vantagens

oferecidas por cada modelo.

A grande diferença desse modelo para a aplicação aqui apresentada, é no envio de

mensagens para todos os usuários de uma sala. Como visto anteriormente, para replicar uma

mensagem enviada para todos os participantes da sala, é necessário que se abra uma conexão

para cada peer individualmente, enviando a mesma mensagem para cada um deles

repetidamente.

59

Utilizando uma arquitetura híbrida, poderíamos manter esta funcionalidade,

aproveitando as vantagens oferecidas pelo modelo cliente/servidor. Neste caso elegemos um

ou mais peers na rede JXTA para exercer a funcionalidade de um servidor, e seria de

responsabilidade deste peer replicar as mensagens para todos os participantes do chat. A única

restrição para essa escolha, é que este peer possa se comunicar com os demais sem nenhuma

restrição. Esse peer poderia ser escolhido segundo determinados critérios de recursos, como

por exemplo, o peer com a melhor conexão em termos de velocidade de rede ou poder de

processamento. Caso um peer deseje enviar uma mensagem exclusivamente para outro peer,

ou mesmo para poucos peers, este poderia realizar a conexão diretamente, sem a necessidade

de enviar esta mensagem para o nosso servidor. Sendo assim, os recursos de banda também

seriam otimizados em comparação ao modelo cliente/servidor, pois utilizando uma arquitetura

híbrida, somente as mensagens destinadas a todos os usuários da sala passariam pelo controle

centralizado.

Figura 33 - Chat utilizando arquitetura híbrida P2P e cliente/servidor. A comunicação direta entre ospeers é freqüentemente utilizada, sendo o servidor necessário apenas quando uma mensagem para todos

os peers é enviada. Dessa forma utilizamos o melhor fornecido por cada arquitetura.

Este capítulo demonstra como foi desenvolvida uma aplicação de chat totalmente P2P,

utilizando as API´s JXTA existentes para java.

Os códigos fontes desta aplicação encontram-se documentados no apêndice A, e os

arquivos, compilados e pronto para serem executados, podem ser obtidos no site

http://www34.brinkster.com/mackjxta, juntamente com as bibliotecas necessárias para

execução do programa.

60

Para executar a aplicação é necessário ter instalado na máquina alguma versão recente

do JRE (Java Runtime Enviroment), que pode ser obtida gratuitamente no site

http://www.java.sun.com.

A aplicação de chat desenvolvida neste estudo tem como objetivo demonstrar os

recursos da plataforma JXTA, além das principais API`s java utilizadas para construção de

aplicativos P2P. O funcionamento da aplicação é baseado no envio de mensagens simples de

texto para todos os participantes do chat, é contém uma área que possibilita a exibição das

novas mensagens enviadas.

A arquitetura de comunicação utilizada é P2P, totalmente descentralizada, sem a necessidade

de um servidor central que replique as mensagens para todos os participantes do chat.

Qualquer novo usuário que realizar o login na aplicação de chat, terá sua entrada notificada

para os outros participantes através da publicação de um advertisement, definido

especificamente para esta aplicação. A descoberta de novos usuários, bem como a verificação

se todos os participantes do chat ainda estão disponíveis, é feita periodicamente por cada

programa cliente. O envio de mensagens só é possível para todos os participantes do chat, não

sendo possível o envio de mensagens reservadas nem direcionadas apenas para um usuário.

5.3 EXECUTANDO A APLICAÇÃO

Depois de instalado e configurado o JRE devidamente, basta descompactar o arquivo

.zip disponibilizado em qualquer diretório. Para executar a aplicação, execute o arquivo

chat.bat, localizado na raiz do diretório onde os arquivos foram descompactados.

61

5.4 CONFIGURANDO O AMBIENTE JXTA

Ao acessar a aplicação pela primeira vez, a configuração básica para acesso a rede

JXTA será requisitada. Verifique as configurações realizadas na secção “Configuração Inicial

JXTA Shell” no capítulo JXTA shell.

5.5 ANALISANDO O CÓDIGO FONTE

A aplicação é construída pela compilação das seguintes classes Java:

Tabela 1 – Classes utilizadas para implementação da aplicação de chat.

Figura 34 – Diagrama UML de classes para a aplicação de chat.

Figura 35 – Diagrama de sequência para as classes Java da aplicação de chat.

Outros dois arquivos, chat.log e logo.jpg, também compõe a aplicação, porém não

contém nenhum código Java , e são apenas arquivos auxiliares para o funcionamento do chat.

62

O arquivo chat.log pode ser analisado para detectar eventuais erros da aplicação, bem como o

resultado de cada ação realizada.

As classes chat.ChatLoginFrame e chat.ChatFrame realizam apenas tarefas simples,

como a escolha do apelido (nick) utilizado, e a exibição de mensagens para o usuário.

Figura 36 - Tela de boas-vindas do Chat

Figura 37 - Tela de conversas do Chat (Peer1)

Figura 38 - Tela de conversas do Chat (Peer2)

5.6 CLASSE CHAT.CHATAPP.JAVA

Ao executar o método main desta classe, instanciaremos um objeto representando ela

própria, e executaremos o método startJxta(), dando início a rede JXTA.

10 public static void main(String args[]){20 ChatApp chat=new ChatApp();

63

30 chat.startJxta();40 }

Exemplo 1 – Após executar o construtor da aplicação, a plataforma JXTA é iniciada.

O método startJxta() tem como principal objetivo inicializar o peer atual na rede

JXTA. Todos os peers, por padrão, pertecem ao World Peer Group, que é o primeiro grupo da

rede JXTA, e pai de todos os outros grupos. O World Peer Group oferece alguns serviços

básicos, como por exemplo a descoberta de novos peers, e outras funcionalidades simples.

Depois de iniciado os serviços básicos da rede JXTA, nosso peer irá se integrar ao Net

Peer Grupo, um grupo especial que oferece serviços e funcionalidades adicionais ao World

Peer Group, como por exemplo, o monitoramento de serviços, definições de credenciais e

conhecimento de gateways específicos. O principal motivo para a separação do Net Peer

Group do World Peer Group, deve-se ao fato de JXTA não fazer nenhuma imposição aos

requisitos mínimos do peers participantes da rede. Caso os recursos utilizados por um

determinado peer sejam compatíveis com Net Peer Group, este poderá instancia-lo sem

restrições, e caso contrário, poderá apenas usufruir dos serviços básicos oferecidos pelo

World Peer Group.

Após ingressar no Net Peer Group, utilizaremos os métodos getDiscoveryService() e

getPipeService() para obter os serviços de Discovery e Pipe, respectivamente.

10 try{20 group=PeerGroupFactory.newNetPeerGroup();30 }catch(Exception e){40 e.printStackTrace();50 }60 discovery=group.getDiscoveryService();70 pipeSvc=group.getPipeService();

Exemplo 2 – Depois de iniciado o Net Peer Group, os serviços de Pipe e Discovery são recuperados.

64

A interface DiscoveryService especifica diversos métodos para recuperação,

publicação e descoberta de advertisements , implementados pela classe

DiscoveryServiceImpl. Publicar advertisements é uma das principais tarefas de qualquer

aplicação na rede JXTA, pois é desta maneira que são feitas as descobertas de peers, pipes e

outros recursos.

Após recuperado os serviços de discovery e pipes, e caso não nenhum erro seja

encontrado, instanciaremos a classe chat.ChatLoginFrame, permitindo ao usuário escolher o

nick a ser utilizado, e dando início a aplicação. O método responsável por realizar o login

deste usuário no chat, é o método public int loginChat(String name).

A primeira ação realizada por este método, é verificar se o login na aplicação de chat

ainda não foi realizado, alertando o usuário de que não será possível entrar na rede novamente

caso o login já tenha sido escolhido. Com o serviço de discovery recuperado corretamente,

registraremos a própria classe chat.ChatApp como ouvinte para os eventos de discovery

recebidos.

10 if(!loggedIn){20 this.nick=name;30 discovery.addDiscoveryListener(this);40 }

Exemplo 3 - Caso o apelido escolhido esteja disponível, registramos a classe atual como listenet doseventos recebidos de Discovery recebidos pela aplicação.

Para que a classe possa receber eventos de discovery, é necessário que o método

public void discoveryEvent(DiscoveryEvent ev) seja implementado, fornecendo as ações que

o programa deve realizar ao receber um evento. Nesta aplicação, este método apenas informa

o recebimento de um evento, sem qualquer ação específica que envolva a lógica da aplicação.

65

Em seguida procuramos um advertisement localmente para o nick informado. A

distinção dos advertisements que pertencem a nossa aplicação é feita pela recuperação do

valor contido no elemento <Name> do xml correspondente ao advertisement de pipes

encontrados. Todo advertisement enviado pela aplicação de chat, conterá o prefixo que foi

definido na constante CHAT_NAME_TAG, além do nick escolhido pelo usuário no início da

aplicação:

10 public static final String CHAT_NAME_TAG="ChatMack";

Exemplo 4 – Constante definindo o elemento a ser anexado nos advertisements publicados pela aplcaçãona rede JXTA, permitindo a identificação futura pelos outros clientes do chat.

Caso já exista um advertisement armazenado localmente no cache da aplicação,

informaremos que já existe um outro usuário com este mesmo nick participando do chat, e

solicitamos a escolha de outro nick para o usuário atual.

Não existindo um outro usuário com o mesmo nick na rede JXTA para a aplicação de

chat, criamos um novo advertisement para o pipe de entrada, que será utilizado para o

recebimento de mensagens, e logo em seguida, realizamos a publicação deste advertisement

para os outros peers, alertando a presença deste novo usuário:

10 try{20 //criando um adv de pipe para este user...30 adv = (PipeAdvertisement) _40 AdvertisementFactory.newAdvertisement _50 (PipeAdvertisement.getAdvertisementType());60 adv.setPipeID(IDFactory.newPipeID _70 (group.getPeerGroupID()));80 adv.setName(CHAT_NAME_TAG+":"+name);90 adv.setType(PipeService.PropagateType);100110 }catch(Exception e){120 e.printStackTrace();130 return -1;140 }

66

Exemplo 5 - Criação do advertisement para o Pipe que receberá as mensagens do chat.

10 try{20 discovery.publish(adv,DiscoveryService.ADV, _30 ADV_LIFETIME,ADV_LIFETIME);40 discovery.remotePublish(adv,DiscoveryService.ADV, _50 ADV_LIFETIME);60 }catch(Exception e){70 e.printStackTrace();80 return -1;90 }

Exemplo 6 - Publicação do advertisement de Pipe na rede JXTA.

O método private void createInputPipe() é responsável pela criação do pipe de entrada.

A partir deste momento qualquer mensagem enviada para este pipe será recebida pelo método

public void pipeMsgEvent(PipeMsgEvent pipeMsgEvent):

10 try{20 pipeIn=pipeSvc.createInputPipe(userAdv,this);30 }catch(Exception e){40 System.out.println("Erro ao criar _50 inputPipe:"+e.getMessage());60 return;70 }

Exemplo 7 - Criação do Pipe de entrada que recebe as mensagens enviadas no chat.

O parâmetro “this” informado no método createInputPipe, especifica qual classe deve

implementar o método de recebimento de eventos de pipe. Nesta aplicação a própria classe

chat.ChatApp fornece a implementação, como veremos a seguir:

10 public void discoveryEvent(DiscoveryEvent ev){20 DiscoveryResponseMsg res=ev.getResponse();30 String name="Unknown";40 PeerAdvertisement peerAdv=res.getPeerAdvertisement();

Exemplo 8 - Implementação do método responsável por tratar os eventos de Discovery recebidos.

Depois de recuperado o evento recebido, extraímos o remetente e a mensagem enviada

por ele, definidas pelos valores contidos nas constantes private static final String

SENDER_NAME="ChatSenderName" e private static final String

67

MESSAGE_TAG="ChatSenderMessage", respectivamente. Com a mensagem e o remetente

recuperados, executamos o método chatFrame.printMessage(msg,from) da classe

chat.ChatFrame, responsável pela exibição formatada da mensagem na tela.

O método public void sendMessageToAll(String texto) é responsável pelo envio de

mensagens para o chat. A cada mensagem enviada por este usuário, precisamos recuperar

todos os advertisements de pipes armazenados no cache local de nossa aplicação, criar um

pipe de saída para cada pipe encontrado, e enviar a mensagem, repetidamente para cada peer.

O método private Collection getAllPipeLocalAdvertisements() é o responsável por recuperar

os advertisements armazenados localmente pela aplicação:

10 private Collection getAllPipeLocalAdvertisements(){20 Collection pipes=new ArrayList();30 try{40 Enumeration enum=discovery.getLocalAdvertisements( _50 DiscoveryService.ADV,60 "Name","*"+CHAT_NAME_TAG+":*");70 if(enum!=null){80 while(enum.hasMoreElements()){90 try{100 PipeAdvertisement _110 adv=(PipeAdvertisement)_120 enum.nextElement();130 pipes.add(adv);140 }catch(Exception e){150 continue;160 }170 }180 }190 }catch(Exception e){200 e.printStackTrace();210 }220 return pipes;230 }

Exemplo 9 - Recuperação dos Advertisements armazenados em cache pela aplicação.

Ao criar um pipe de saída para cada advertisement recuperado, estabelecemos um

timeout de 100 ms para realizar a conexão. Se o peer responsável pela publicação do pipe não

68

puder ser contato, ignoramos este advertisement e repetimos o mesmo processo para os

restantes encontrados.

10 public void sendMessageToAll(String texto){20 Collection pipes=getAllPipeLocalAdvertisements();30 if(pipes!=null){40 Iterator it=pipes.iterator();50 while(it.hasNext()){60 PipeAdvertisement adv=(PipeAdvertisement) _70 it.next();80 OutputPipe pipeOut=null;90 try{100 pipeOut=pipeSvc.createOutputPipe(adv,100);110 }catch(Exception e){120 System.out.println("\nErro ao Criar _130 pipeOut para "+adv.getName());140 }150 if(pipeOut!=null){160 Message msg=null;170 String userInput=null;180 InputStream inputStream=null;190 try{200 msg=pipeSvc.createMessage();210 //inputStream = new _220 ByteArrayInputStream()230 StringMessageElement sme=new _240 StringMessageElement(SENDER_NAME,_250 nick,null);260 StringMessageElement sme2=new _270 StringMessageElement(MESSAGE_TAG,_280 texto,null);290 msg.replaceMessageElement(sme);300 msg.replaceMessageElement(sme2);310 pipeOut.send(msg);320 }catch(Exception e){330 System.out.println("Erro ao enviar_340 conteudo para pipeOut:" _350 +e.getMessage());360370 }380 }390 }400 }410 }

Exemplo 10 - Envio da mensagem para cada pipe recuperado através dos advertisements armazenados nocache da aplicação.

69

6. CONCLUSÃO

A necessidade de um tipo de computação descentralizada, mais colaborativa,

transiente e adaptativa aumenta à medida que surgem novos dispositivos e plataformas. Com

a popularização dos dispositivos móveis, como os Palm Tops, Hand Helds e celulares de

última geração, torna-se clara a necessidade de comunicação entre dispositivos pertencentes a

redes diferentes e plataformas distintas.

A iniciativa do projeto JXTA, com o objetivo de especificar protocolos independentes

de plataforma, dispositivo ou linguagem de programação, torna-se fundamental para a

construção de novas aplicações P2P, além da possibilidade de integrar, sem grandes

dificuldades, as novas aplicações que serão construídas seguindo as futuras especificações a

serem definidas em JXTA.

Outro fator fundamental para o sucesso futuro do projeto, é o fato dele não ser

proprietário, apesar de ter sido iniciado e ainda incentivado pela Sun Microsystem.

Atualmente o projeto JXTA é mantido sob uma variação da Apache Software License, o que

garante a continuidade do projeto independente de qualquer empresa, além da contribuição

constante da comunidade open-source, e a transparência de como o desenvolvimento da

tecnologia é conduzido.

Muitas dificuldades e problemas ainda precisam ser resolvidos. O consumo excessivo

de banda para realização de buscas em redes P2P, utilizando técnicas como flooding, precisa

70

ser melhorado. A falta de implementações em outras linguagens além do java, ainda torna

restrito o uso da tecnologia, fato que deve ser resolvido em breve com novas implementações.

A versão JXTA 2.1.1, sendo a mais recente lançada até o momento, traz diversas

otimizações em relação à primeira versão, como a possibilidade da utilização de sockets,

similares aos disponíveis na versão J2SE, além da criação de pipes bidirecionais, otimizando a

troca de mensagens entre peers. Muitas outras otimizações relativas aos recursos de rede

utilizados foram adicionadas, e diversas API´s foram alteradas para simplificar o

desenvolvimento e aperfeiçoar as já existentes. A cada versão disponibilizada, torna-se

fundamental a participação da comunidade envolvida no projeto, que através de listas de

discussões, identifica os pontos falhos e analisa novas necessidades para que em um futuro

breve, esta tecnologia possa ser utilizada em larga escala pela indústria com sucesso.

Diversos sub-projetos estão sendo desenvolvidos paralelamente ao projeto JXTA,

disponibilizando soluções e alternativas importantes para a indústria de tecnologia. Entre

esses sub-projetos, podemos destacar o vop2p (Voice Over Peer to Peer), disponível em

http://vop2p.jxta.org/servlets/ProjectHome, que tem como objetivo a possibilidade de criação

de uma rede telefônica descentralizada para comunicação entre peers. Além do vop2p, outros

projetos merecem destaque, como o gamePlataform (Plataforma para jogos on-line

possibilitando vários participantes), disponível em

http://gameplatform.jxta.org/servlets/ProjectHome, e o p2pConference, disponível em

http://p2pconference.jxta.org/servlets/ProjectHome, que permite a criação de conferências

virtuais sobre a plataforma JXTA. Outros sub-projetos estão sendo adicionados mensalmente

ao projeto JXTA, e o amadurecimento e a estabilidade das próximas versões da plataforma,

devem favorecer o surgimento de aplicações realmente inovadoras para o setor de tecnologia.

71

Apesar das dificuldades existentes, o desenvolvimento e amadurecimento para

construção de redes P2P vêm sendo notado a cada ano, bastando observar o sucesso na

utilização de aplicativos compartilhadores de arquivos e de troca de mensagens instantâneas.

A adoção de aplicações P2P por empresas privadas deve popularizar a tecnologia, e

conseqüentemente disponibilizar e capacitar mão de obra para o desenvolvimento de novas

aplicações P2P em JXTA.

Mesmo com poucos anos de desenvolvimento, a implementação para linguagem java

da plataforma JXTA ,mostra-se bastante avançada, permitindo a construção de aplicações P2P

sem grandes dificuldades e com resultados satisfatórios. Porém, a melhora da documentação,

sendo traduzida em outras linguagens além do inglês, além da publicação de novos livros e

artigos sobre o assunto, será fundamental para a adoção desta tecnologia por diversos

arquitetos de soluções P2P e pelas empresas de tecnologia.

A aplicação de chat desenvolvida neste trabalho, pode servir de ponto de partida para

os interessados nas API´s java para desenvolvimento de aplicação P2P utilizando a plataforma

JXTA, além de permitir o entendimento de vários sub-projetos e códigos disponibilizados no

site oficial do projeto.

72

REFERÊNCIAS BIBLIOGRÁFICAS

[1] TRUELOVE, Kelly. 2001. Gnutella and the Transient Web. Online, disponível em

http://www.openP2P.com/lpt/a/705. Publicado em março de 2001; último acesso em outubro

de 2003.

[2] ANDY, Oram. 2000. Gnutella and Freenet represent true technological innovation. Online,

disponível em http://www.oreillynet.com/lpt/a/208. Publicado em maio de 2000; último

acesso em outubro de 2003.

[3] ORAM, Andy. 2001. O poder transformador das redes P2P. Berkeley Brasil, 2001.

[4] SUN MICROSYSTEMS, INC.. 2001. Project JXTA: An open, Innovative Collaboration.

Online, disponível em http://www.jxta.org/project/www/docs/OpenInnovative.pdf. Publicado

em abril de 2001; último acesso em outubro de 2003.

[5] Web site SETI@home. Online, disponível em http://setiathome.ssl.berkeley.edu/. Último


[6] PARAMESWARAN, Manoj; SUSARLA, Anjana; WHINSTON , Andrew B.. 2001. P2P

Networking: An information –Sharing Alternative. Online, disponível em

http://cism.bus.utexas.edu/works/articles/PARA.Cxs2final.pdf. Publicado em julho de 2001;

último acesso em outubro de 2003.

[7] GONG, Li. 2001. JXTA: A network programming environment. Online, disponível em

http://www.jxta.org/project/www/docs/JXTAnetworkProgEnv.pdf. Publicado em junho de

2001; último acesso em outubro de 2003.

[8] GONG, Li. 2002. Project JXTA: A Technology Overview. Online, disponível em

http://www.jxta.org/project/www/docs/jxtaview_01nov02.pdf. Publicado em Outubro de


73

[9] TRAVERSAT, Bernard; ABDELAZIZ, Mohamed; DUIGOU, Mike; HUGLY, Jean-

Christophe; POUYOUL, Eric; YEAGER, Bill. 2002. Project JXTA Virtual Network. Online,

disponível em http://www.jxta.org/docs/JXTAprotocols.pdf. Publicado em fevereiro de 2002;


[10] TRAVERSAT, Bernard; ARORA, Ahkil; ABDELAZIZ, Mohamed; DUIGOU, Mike;

HAYWOOD, Carl; HUGLY, Jean-Christophe; POUYOUL, Eric; YEAGER, Bill. 2003.

Project JXTA 2.0 Super-Peer Virtual Network. Online, disponível em

http://www.jxta.org/project/www/docs/JXTA2.0protocols1.pdf. Publicado em maio de 2003;


[11] KRISHNAN, Navaneeth. 2003. Master the Jxta shell, Part 1. Online, disponível em

http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-jxtashell_p.html. Publicado em

janeiro de 2003; último acesso em outubro de 2003.

[12] SUN MICROSYSTEMS, INC.. 2001 Project JXTA: Technical Shell Overview. Online,

disponível em http://www.jxta.org/project/www/docs/GettingStarted.pdf. Publicado em abril

de 2001; último acesso em outubro de 2003.

[13] OAKS, Scott; TRAVERSAT, Bernard; GONG, Li. Getting Started with JXTA, Part 1.

Online, disponível em http://www.onjava.com/lpt/a/2619. Último acesso em outubro de 2003.









74

[18] KURNIAWAN, Budi. A JXTA Chat. Online, disponível em

http://www.fawcette.com/javapro/2001_12/magazine/features/bkurniawan/. Último acesso em

outubro de 2003.

[19] MINAR, Nelson. 2001. JXTA Chat, Sans Server. Online, disponível em

http://www.openP2P.com/lpt/a/912. Publicado em junho de 2001; último acesso em outubro

de 2003.

[20] BAEHNI, Sebastien. Wire chat. Online, disponível em

http://lpdwww.epfl.ch/sbaehni/work/jxta/wireChat/pages/wireChat.html. Último acesso em

outubro de 2003.

[21] SUN MICROSYSTEMS, INC.. 2003. Project JXTA Technology:Creating Connected

Communities. Online, disponível em http://jxta-wire.jxta.org/project/www/docs/JXTA-Exec-

Brief-032803.pdf. Publicado em março de 2003; último acesso em outubro de 2003.

[22] SUN MICROSYSTEMS, INC.. Project JXTA. Online, disponível em

http://wwws.sun.com/software/jxta/. Último acesso em outubro de 2003.

[23] CLAßEN, Michael. 2001. Project JXTA: An Open, Peer-to-Peer Collaboration Platform

using Java and XML. Online, disponível em

http://www.webreference.com/xml/column32/index.html. Publicado em maio de 2001; último


[24] SUN MICROSYSTEMS, INC.. Project JXTA: Scenarios. Online, disponível em

http://wwws.sun.com/software/jxta/features/scenarios.html. Último acesso em outubro de

1003.

[25] KRISHNAN, Navaneeth. 2001. The Jxta solution to P2P. Online, disponível em

http://www.javaworld.com/javaworld/jw-10-2001/jw-1019-jxta_p.html. Publicado em

outubro de 2001; último acesso em outubro de 2003.

75

[26] KRIKORIAN, Raffi. 2001. Hello JXTA!. Online, disponível em

http://www.onjava.com/lpt/a/802. Publicado em abril de2001; último acesso em outubro de

2003.

[27] DORNFEST, Rael. 2001. JXTA Takes Its Position. Online, disponível em

http://www.openP2P.com/pub/a/P2P/2001/04/25/jxta_position.html. Publicado em abril de


[28] SUN MICROSYSTEMS, INC.. 2002. Five Abstractions. Online, disponível em

http://www.sun.com/2002-0604/feature/five-ab.html. Publicado em junho de 2002; último


[29] SUN MICROSYSTEMS, INC.. 2002. Six Protocols. Online, disponível em

http://www.sun.com/2002-0604/feature/six.html. Publicado em junho de 2002; último acesso

em outubro de 2003.

[30] HALEPOVIC, Emir; DETERS, Ralph. The Costs of Using JXTA. Online, disponível em

http://bistrica.usask.ca/madmuc/Grads/Emir/pub/P2P03_Halepovic_CostsOfUsingJXTA.pdf.

Último acesso em outubro de 2003.

[31] ROCHA, Rafael R.. 2003. Redes Peer-to-Peer para Compartilhamento de Arquivos. Online,

disponível em http://www.gta.ufrj.br/seminarios/semin2003_1/rafael/principal.htm.

Publicado em junho de 2003; último acesso em outubro de 2003.

[32] SUNDSTED, Todd. 2001. The practice of peer-to-peer computing: Introduction and history.

Online, disponível em http://www-106.ibm.com/developerworks/java/library/j-P2P/.

Publicado em março de 2001; último acesso em outubro de 2003.

[33] SUNDSTED, Todd.. 2001. The practice of peer-to-peer computing: Discovery. Online,

disponível em http://www-106.ibm.com/developerworks/java/library/j-P2Pdisc/. Publicado

em novembro de 2001. último acesso em outubro de 2003.

[34] LI, Sing. 2002. P2P interoperable: Creating JXTA systems. Online, disponível em

76

http://www-106.ibm.com/developerworks/java/library/j-P2Pint3/. Publicado em abril de


[35] SUNDSTED, Todd.. 2002. The practice of peer-to-peer computing: IP Multicast-based

discovery. Online, disponível em http://www-106.ibm.com/developerworks/java/library/j-

P2Pdisc2/. Publicado em janeiro de 2002; último acesso em outubro de 2003.

77

GLOSSÁRIO

Browser

Designação genérica do tipo de programa que nos permite navegar na Internet (Internet

Explorer, Netscape Navigator, etc).

Cache

Refere-se ao local onde os dados são armazenados temporariamente.

Distributed Network

Uma rede na qual o processamento, o armazenamento e outras funções são executados em

unidades (nós) separados, e não concentradas em um único computador.

Firewall

Um sistema de segurança ( hardware e/ou software ) cujo principal objetivo é filtrar os

acessos a uma rede. As empresas utilizam o firewall para proteger as suas redes internas

conectadas à Internet contra a entrada de pessoas não autorizadas. (Hackers). Existem

diversas tecnologias possíveis para a construção de um Firewall.

Gateway

Sistema que permite o intercâmbio de serviços e informações entre redes com tecnologias

iguais ou distintas.

HTTP

Hyper Text Transfer Protocol (Protocolo de transferência de Hipertexto). O HTTP é o

protocolo usado para a transmissão de dados no sistema World-Wide Web.

JXTA

Sigla para a JustaPose, uma tecnologia para construção de aplicativos P2P independente de

plataforma e dispositivos, liderada pela SUN Microsystem.

78

NAT

Sigla para Network Address Translation. Ocorre quando vários endereços IP em uma LAN

(Local área network) privada são convertidos para um endereço público. Esse endereço

público é enviado para a Internet. A NAT acrescenta níveis de segurança porque o endereço

IP de um PC conectado a LAN privada nunca é transmitido para a Internet. O usuário pode ter

vários endereços privados mascarados pelo endereço único fornecido pelo Provedor Internet.

A NAT evita rejeições de serviço (DoS) de redes externas em hosts internos.

P2P

Peer to Peer, comunicação direta entre dois pontos sem a necessidade de um intermediário. Os

peers geralmente possuem capacidades e responsabilidades iguais em uma rede. Uma rede

P2P é formada pelo conjunto de diversos peers participantes.

Proxy

Sevidor que atua como um intermediário entre a estação de trabalho e a Internet ou alguma

outra rede, garantindo um certo nível de segurança por realizar uma comunicação indireta.

Serviços como controle administrativo, limitação de recursos utilizados e cache podem ser

fornecidos, dependendo da implementação utilizada.

TCP/IP

Transmission Control Protocol/Internet Protocol. Conjunto de protocolos da Internet que

definem como se processam as comunicações entre vários computadores PDAs.

79

APÊNDICE A – CÓDIGOS FONTE DA IMPLEMENTAÇÃO

Arquivo ChatApp.java

package chat;

import java.io.InputStream;import java.text.DateFormat;import java.util.ArrayList;import java.util.Collection;import java.util.Date;import java.util.Enumeration;import java.util.Iterator;import java.util.Locale;import net.jxta.discovery.DiscoveryEvent;import net.jxta.discovery.DiscoveryListener;import net.jxta.discovery.DiscoveryService;import net.jxta.document.AdvertisementFactory;import net.jxta.endpoint.Message;import net.jxta.endpoint.StringMessageElement;import net.jxta.id.IDFactory;import net.jxta.peergroup.PeerGroup;import net.jxta.peergroup.PeerGroupFactory;import net.jxta.pipe.InputPipe;import net.jxta.pipe.OutputPipe;import net.jxta.pipe.PipeMsgEvent;import net.jxta.pipe.PipeMsgListener;import net.jxta.pipe.PipeService;import net.jxta.protocol.DiscoveryResponseMsg;import net.jxta.protocol.PeerAdvertisement;import net.jxta.protocol.PipeAdvertisement;import net.jxta.rendezvous.RendezVousService;import org.apache.log4j.Logger;

/** * Classe principal para aplicação do chat P2P, implementa as interfacesPipeMsgListener * para recebimento de eventos de pipes e DiscoveryListener para eventos deDiscovery * de novos peers. */public class ChatApp implements PipeMsgListener, DiscoveryListener {

/** * Nome do elemento que definirá qual advertisement de pipe pertence

a este chat. */public static final String CHAT_NAME_TAG = "ChatMack";

/** * Tempo de vida do advertisement de pipe na rede. Após isso o chat

parará de funcionar. */private static final long ADV_LIFETIME = 210 * 1000;

/**

80

* Frame responsável por exibir e enviar as mensagens para outrosusuários.

*/private static ChatFrame chatFrame;

/** * Frame responsável por recuperar o nick escolhido. */private static ChatLoginFrame chatLoginFrame;

/** * Log 'chat' definido em classes/log4j.xml. */private static Logger log = Logger.getLogger("chat");

/** * Nome do elemento que conterá mensagem enviada por um usuário. */private static final String MESSAGE_TAG = "ChatSenderMessage";

/** * Nome do elemento que conterá o nome do enviador da mensagem */private static final String SENDER_NAME = "ChatSenderName";

/** * Tempo de espera antes de tentar recuperar após um advertisement

após um publish. */private static final int WAITING_TIME = 5 * 1000;

private DiscoveryService discovery;private PeerGroup group;

/** * Indica se o flush de advertisements já foi realizado. */private boolean isFlushed;

/** * Indica se o usuário atual já esta logado. */private boolean loggedIn;

/** * Nick escolhido pelo usuário. */private String nick;

private PipeService pipeSvc;private RendezVousService rdv;

/** * Irá procurar remotamente novos advertisements. */private Thread thread;

/**

81

* Utilizado para recebimento das mensagens enviadas para esteusuário.

*/private PipeAdvertisement userAdv;

/** *Método para exibição formatada de data *@return String contendo data no formato dd/mm/aa hh:mm *@see <code>java.text.DateFormat#getDateTimeInstance(int, int,

java.util.Locale)</code> */public static String getShortDate() {

DateFormat df =DateFormat.getDateTimeInstance(

DateFormat.SHORT,DateFormat.SHORT,new Locale("pt", "BR"));

return df.format(new Date(System.currentTimeMillis()));}

public static void main(String args[]) {ChatApp chat = new ChatApp();log.debug("Aplicação iniciada...");chat.startJxta();

}

/** * Cria um input pipe e adiciona a própria classe como ouvinte de

eventos recebido * por este pipe */private void createInputPipe() {

InputPipe pipeIn = null;try {

pipeIn = pipeSvc.createInputPipe(userAdv, this);} catch (Exception e) {

log.fatal("Impossível criar pipe de entrada:" +e.getMessage());

System.exit(-1);}log.info("Pipe de entrada criado com sucesso...");

}

/** * Recebe os eventos de discovery para esta classe. Apenas registra

no log * os advertisements recebidos pertencente a este chat, e mostra * quais foram as respostas recebidas e por quem foram enviadas * * @param ev Evento de Discovery recebido */public void discoveryEvent(DiscoveryEvent ev) {

DiscoveryResponseMsg res = ev.getResponse();String name = "Unknown";PeerAdvertisement peerAdv = res.getPeerAdvertisement();if (peerAdv != null) {

name = peerAdv.getName();}log.debug(

82

res.getResponseCount()+ " resposta[s] de discovery recebida[s] de "+ name+ "...");

PipeAdvertisement adv = null;Enumeration enum = res.getAdvertisements();if (enum != null) {

while (enum.hasMoreElements()) {try {

adv = (PipeAdvertisement) enum.nextElement();log.debug(

"Pipe para usuário '"+ adv.getName()+ "' recuperado no evento de

discovery:\n"+ adv.toString());

} catch (Exception e) {}

}}

}

/** * Procura por advertisements de pipe de um determinado usuário

localmente * e remotamente * @param name Nick de qual usuário que desejamos procurar advs * @return <code>PipeAdvertisement</code> contendo o advertisement

recuperado * para este usuário ou null, caso nenhum tenha sido encontrado. * @see #findUserAdvLocal(String). * @see #findUserAdvRemote(String). */private PipeAdvertisement findUserAdv(String name) {

PipeAdvertisement adv = findUserAdvLocal(name);if (adv == null) {

adv = findUserAdvRemote(name);adv = findUserAdvLocal(name);

}return adv;

}

/** * Realiza o flush dos advertisements locais, e recupera * os advertisements ainda validos que correspondam a esta aplicação

de chat, * procurando por um usuário específico. * * @param name Nick do usuário desejado. * @return null ou PipeAdvertiment já atribuído a este usuário

anteriormente. */private PipeAdvertisement findUserAdvLocal(String name) {

Enumeration enum = null;try {

if(isFlushed){discovery.flushAdvertisements(null,

DiscoveryService.ADV);

83

log.info(" flush de advertisements executados comsucesso...");

}

enum =discovery.getLocalAdvertisements(

DiscoveryService.ADV,"Name",CHAT_NAME_TAG + ":" + nick);

if (enum != null) {PipeAdvertisement adv = null;while (enum.hasMoreElements()) {

try {adv = (PipeAdvertisement)

enum.nextElement();if ((CHAT_NAME_TAG + ":" + name)

.equals(adv.getName())) {return adv;

}} catch (Exception e) {}

}}

} catch (Exception e) {log.error(

"Erro ao recuperar advertisements de cache:" +e.getMessage());

}return null;

}

/** * Procura remotamente os advertisements de pipe desta

aplicação * e que correspondam a um determinado usuário informado.

* * @param name Nick do usuário desejado * @return null ou <code>PipeAdvertiment</code> deste usuário

válido na rede JXTA */

private PipeAdvertisement findUserAdvRemote(String name) {PipeAdvertisement adv = null;try {

//ache todos os advertisiments locais de pipes publicadospor esta aplicação....

discovery.getRemoteAdvertisements(null,DiscoveryService.ADV,"Name","*" + CHAT_NAME_TAG + ":*",2);

try {Thread.sleep(WAITING_TIME);

} catch (Exception e) {}


"Erro ao recuperar advertisements remotos:" +e.getMessage());

84

}return null;

}

/** * Recupera todos os advertisements locais desta aplicação, * verificando qual corresponde a PipeAdvertisement. * * @return <code>Collection</code> contendo todos os

PipeAdvertisement encontrados. */private Collection getAllPipeLocalAdvertisements() {

Collection pipes = new ArrayList();try {

Enumeration enum =discovery.getLocalAdvertisements(

DiscoveryService.ADV,"Name","*" + CHAT_NAME_TAG + ":*");

if (enum != null) {while (enum.hasMoreElements()) {

try {PipeAdvertisement adv =

(PipeAdvertisement)enum.nextElement();

pipes.add(adv);} catch (Exception e) {

continue;}

}}


"Erro ao recuperar cache de advertisements:" +e.getMessage());

}return pipes;

}public String getNick() {

return nick;}

/** * Efetua o login na aplicação de chat, criando um PipeAdvertisement * para este usuário, e publicando este pipe localmente e remotamente * na rede JXTA. Após realizada a publicação do advertisement,o frame

que exibe e permite * o envio de mensagens é exibido, uma mensagem para todos é enviada * alertando a presença de um novo usuário, e uma thread é iniciada

para descoberta * de novos advertisements na rede JXTA. Caso haja algum problema

antes de terminar a rotina, * a aplicação é encerrada com código de erro -1. * * @param name Nick escolhido pelo usuário na tela de login * @return <code>int</code> , -1 caso o usuário já tenha realizado * o login anteriormente, ou 1 caso tudo tenha sido realizado com

sucesso.

85

*/public int loginChat(String name) {

if (!loggedIn) {this.nick = name;discovery.addDiscoveryListener(this);PipeAdvertisement adv = findUserAdv(name);if (adv != null) {

log.fatal("Erro, Advertisiment já existente para este

usuário, saindo da aplicação...");System.exit(-1);

}try {

//criando um adv de pipe para este user...adv =

(PipeAdvertisement)AdvertisementFactory.newAdvertisement(

PipeAdvertisement.getAdvertisementType());

adv.setPipeID(IDFactory.newPipeID(group.getPeerGroupID()));adv.setName(CHAT_NAME_TAG + ":" + name);adv.setType(PipeService.PropagateType);

} catch (Exception e) {log.fatal(

"Impossível criar advertisement de pipe:" +e.getMessage());

System.exit(-1);}try {

discovery.publish(adv,DiscoveryService.ADV,ADV_LIFETIME,ADV_LIFETIME);

discovery.remotePublish(adv,DiscoveryService.ADV,ADV_LIFETIME);

} catch (Exception e) {log.fatal(

"Impossível publicar advertisement de pipe:"+ e.getMessage());

System.exit(-1);}adv = findUserAdvLocal(name);if (adv == null) {

log.fatal("Impossível recuperar advertisement de pipe

para este usuário...");System.exit(-1);

}userAdv = adv;loggedIn = true;createInputPipe();chatFrame.setTitle(getNick() + " - JXTA Chat P2P ");chatFrame.show();sendMessageToAll(" Entrei no chat....");

86

//thread que vai recuperar novos pipes de tempos emtempos...

log.info("Criando thread para Discovery de pipes...");DiscoveryPipes discoveryPipes = new

DiscoveryPipes(discovery);} else {

log.fatal("Atenção , você já esta logado no chat...");return -1;

}return 1;

}public void pipeMsgEvent(PipeMsgEvent pipeMsgEvent) {

try {Message message = pipeMsgEvent.getMessage();String from =

message.getMessageElement(SENDER_NAME).toString();String msg =

message.getMessageElement(MESSAGE_TAG).toString();chatFrame.printMessage(msg, from);

} catch (Exception e) {log.error("Erro ao receber evento de pipe:" +

e.getMessage());}

}public void sendMessageToAll(String texto) {

Collection pipes = getAllPipeLocalAdvertisements();if (pipes != null) {

Iterator it = pipes.iterator();while (it.hasNext()) {

PipeAdvertisement adv = (PipeAdvertisement)it.next();

OutputPipe pipeOut = null;try {

pipeOut = pipeSvc.createOutputPipe(adv, 100);} catch (Exception e) {

log.error("Erro ao criar OutputPipe para '"

+ adv.getName()+ "':"+ e.getMessage());

}if (pipeOut != null) {

Message msg = null;String userInput = null;InputStream inputStream = null;try {

msg = pipeSvc.createMessage();//inputStream=new ByteArrayInputStream()StringMessageElement sme =

newStringMessageElement(SENDER_NAME, nick, null);

StringMessageElement sme2 =new

StringMessageElement(MESSAGE_TAG, texto, null);msg.replaceMessageElement(sme);msg.replaceMessageElement(sme2);pipeOut.send(msg);


87

"Erro ao enviar mensagem para '"+ adv.getName()+ "':"+ e.getMessage());

}}

}}

}public void startJxta() {

try {group = PeerGroupFactory.newNetPeerGroup();log.info("NetPeerGroup iniciado com sucesso...");

} catch (Exception e) {log.fatal("Erro ao iniciar netPeerGroup:" +

e.getMessage());System.exit(-1);

}discovery = group.getDiscoveryService();rdv = group.getRendezVousService();log.info("Rendezvous service recuperado...");while (rdv.isConnectedToRendezVous()) {

try {log.info("Aguardando conexão com Rendezvous...");Thread.sleep(2000);

} catch (InterruptedException e) {}

}log.info(

"Conexão com Rendezvous estabelecida, recuperando serviçode pipe...");

pipeSvc = group.getPipeService();chatLoginFrame = new ChatLoginFrame(this);chatFrame = new ChatFrame(this);

}}

Arquivo DiscoveryPipes.java

package chat;

import net.jxta.discovery.DiscoveryService;

import org.apache.log4j.Logger;

/** * Esta classe implementa a interface Runnable, e inicia uma * thread que procura por novos advertisements na rede a cada 60 segundos. */public class DiscoveryPipes implements Runnable {

private DiscoveryService discoverySvc;

/** * Log 'chat' definido em classes/log4j.xml.

88

*/private static Logger log = Logger.getLogger("chat");

/** * Construtor da classe que recebe o serviço de discovery

(DiscoveryService) * da classe chat.ChatApp, e inicia uma nova thread para a procura de

Advertisements. * @see chat.ChatApp */public DiscoveryPipes(DiscoveryService discoverySvc) {

this.discoverySvc = discoverySvc;Thread t = new Thread(this);t.start();log.info("Thread para Discovery de pipes criada e

iniciada....");}

public void run() {while (true) {

try {log.info("Tentando descobrir novos pipes

remotamente...");discoverySvc.getRemoteAdvertisements(

null,DiscoveryService.ADV,null,null,100);

Thread.sleep(60 * 1000);} catch (InterruptedException e) {}

}}

}

Arquivo ChatLoginFrame.java

package chat;

import java.awt.Color;import java.awt.MediaTracker;import java.awt.Rectangle;import java.awt.event.ActionEvent;import java.awt.event.KeyEvent;import java.awt.event.KeyListener;import javax.swing.BorderFactory;import javax.swing.ImageIcon;import javax.swing.JButton;import javax.swing.JFrame;import javax.swing.JLabel;import javax.swing.JOptionPane;import javax.swing.JPanel;import javax.swing.JTextField;

89

import javax.swing.border.Border;import javax.swing.border.TitledBorder;import org.apache.log4j.Logger;

public class ChatLoginFrame extends JFrame implements KeyListener {

private static Logger log = Logger.getLogger("chat");JTextField jtLogin = new JTextField();JButton jbLogin = new JButton();JLabel jLabelNick = new JLabel();JLabel jLabelLogoMack = new JLabel();TitledBorder titledBorder1;JLabel jLabel1 = new JLabel();JLabel jLabel2 = new JLabel();Border border1;JLabel jLabel3 = new JLabel();JLabel jLabel4 = new JLabel();JPanel jPanel1 = new JPanel();JLabel jLabel5 = new JLabel();private ChatApp chat;

public ChatLoginFrame() {}

public ChatLoginFrame(ChatApp app) {chat = app;try {

jbInit();} catch (Exception e) {

e.printStackTrace();}

}

private void jbInit() throws Exception {this.setTitle("Implementação JXTA chat P2P");border1 = BorderFactory.createLineBorder(Color.white, 1);jtLogin.setBounds(new Rectangle(5, 184, 171, 21));this.getContentPane().setLayout(null);jbLogin.setBounds(new Rectangle(244, 182, 95, 23));jbLogin.setText("Entrar");this.setResizable(false);jLabelNick.setText("Digite abaixo o seu nick:");jLabelNick.setBounds(new Rectangle(6, 163, 141, 15));jLabel1.setFont(new java.awt.Font("SansSerif", 1, 12));jLabel1.setText("Implementação JXTA CHAT");jLabel1.setBounds(new Rectangle(8, 0, 175, 23));jLabel2.setText("Antonio Augusto Mariano Da Silva");jLabel2.setBounds(new Rectangle(5, 12, 197, 17));jLabel3.setText("Ricardo Augusto Miguel");jLabel3.setBounds(new Rectangle(6, 36, 205, 20));jLabel4.setText("Ricardo Ribeiro Tavares");jLabel4.setBounds(new Rectangle(7, 65, 155, 17));jPanel1.setBorder(BorderFactory.createEtchedBorder());jPanel1.setLayout(null);jPanel1.setBounds(new Rectangle(7, 52, 209, 99));jLabel5.setFont(new java.awt.Font("SansSerif", 1, 12));jLabel5.setForeground(Color.red);jLabel5.setText("Orientador: Prof. Rogério Oliveira");

90

jLabel5.setBounds(new Rectangle(7, 25, 201, 20));jPanel1.add(jLabel4, null);jPanel1.add(jLabel3, null);jPanel1.add(jLabel2, null);jtLogin.addKeyListener(this);this.getContentPane().add(jtLogin, null);this.getContentPane().add(jLabelNick, null);this.getContentPane().add(jPanel1, null);this.getContentPane().add(jbLogin, null);this.getContentPane().add(jLabel5, null);this.getContentPane().add(jLabel1, null);this.getContentPane().add(jLabelLogoMack, null);try {

MediaTracker tracker = new MediaTracker(this);ImageIcon img = new

ImageIcon(getClass().getResource("logo.gif"));tracker.addImage(img.getImage(), 0);tracker.waitForAll();jLabelLogoMack.setIcon(img);

jLabelLogoMack.setBounds(new Rectangle(

230,10,img.getIconWidth() + 8,img.getIconHeight() + 8));

} catch (Exception e) {log.warn("Erro ao carregar imagens:" + e.getMessage());

}this.setSize(380, 250);this.setDefaultCloseOperation(3);jbLogin.addActionListener(new java.awt.event.ActionListener() {

public void actionPerformed(ActionEvent e) {doLogin();

}});show();

}

private void hideFrame() {this.hide();

}

private void doLogin() {String nick = jtLogin.getText();hideFrame();int resultado = chat.loginChat(nick);if (resultado < 0) {

JOptionPane.showMessageDialog(null,"Atenção, já existe um usuário com este nick no

chat, escolha outro!");log.fatal("Atenção, já existe um usuário com este nick no

chat, escolha outro!");System.exit(0);

}jtLogin.setText("");

}

public void keyPressed(KeyEvent arg0) {

91

if (arg0.getKeyCode() == 10) {doLogin();

}}public void keyReleased(KeyEvent arg0) {}public void keyTyped(KeyEvent arg0) {}

}

Arquivo ChatFrame.java

package chat;

import java.awt.MediaTracker;import java.awt.Rectangle;import java.awt.event.ActionEvent;import java.awt.event.KeyEvent;import java.awt.event.KeyListener;import java.util.Date;import javax.swing.ImageIcon;import javax.swing.JButton;import javax.swing.JFrame;import javax.swing.JLabel;import javax.swing.JOptionPane;import javax.swing.JScrollPane;import javax.swing.JTextArea;import javax.swing.JTextField;import org.apache.log4j.Logger;

public class ChatFrame extends JFrame implements KeyListener {

private static Logger log = Logger.getLogger("chat");private ChatApp chat;JButton jbEnviar = new JButton();JLabel jLabelLogoJxta = new JLabel();JLabel jLabelLogoMack = new JLabel();JScrollPane jScrollPane1 = new JScrollPane();JTextField jtMsg = new JTextField();JTextArea jtMsgAll = new JTextArea();

public ChatFrame(ChatApp chatApp) {try {

jbInit();this.chat = chatApp;

} catch (Exception e) {e.printStackTrace();

}}

private void jbInit() throws Exception {jtMsg.setBounds(new Rectangle(13, 272, 395, 19));this.setDefaultCloseOperation(3);this.getContentPane().setLayout(null);jbEnviar.setBounds(new Rectangle(439, 272, 77, 21));jbEnviar.setText("Enviar");

92

//jScrollPane1.setHorizontalScrollBarPolicy(JScrollPane.HORIZONTAL_SCROLLBAR_ALWAYS);

jScrollPane1.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_ALWAYS);

jScrollPane1.setAutoscrolls(true);jScrollPane1.setBounds(new Rectangle(13, 8, 402, 251));jtMsgAll.setWrapStyleWord(true);jtMsgAll.setBounds(new Rectangle(13, 8, 350, 200));jtMsgAll.setEditable(false);jScrollPane1.getViewport().add(jtMsgAll, null);

try {MediaTracker tracker = new MediaTracker(this);ImageIcon img = new

ImageIcon(getClass().getResource("logo.gif"));ImageIcon img2 =

newImageIcon(getClass().getResource("logo_jxta.gif"));

tracker.addImage(img.getImage(), 0);tracker.addImage(img2.getImage(), 0);tracker.waitForAll();jLabelLogoMack.setIcon(img);jLabelLogoMack.setBounds(

new Rectangle(430,10,img.getIconWidth() + 8,img.getIconHeight() + 8));

jLabelLogoJxta.setIcon(img2);jLabelLogoJxta.setBounds(

new Rectangle(430,120,img2.getIconWidth() + 8,img2.getIconHeight() + 8));

} catch (Exception e) {log.warn("Erro ao carregar imagens:" + e.getMessage());

}jbEnviar.addActionListener(new java.awt.event.ActionListener()

{public void actionPerformed(ActionEvent e) {

sendMessage(jtMsg.getText());jtMsg.setText("");

}});this.getContentPane().add(jScrollPane1, null);this.getContentPane().add(jbEnviar, null);this.getContentPane().add(jtMsg, null);this.getContentPane().add(jLabelLogoJxta, null);this.getContentPane().add(jLabelLogoMack, null);setSize(580, 360);setResizable(false);jtMsg.requestFocusInWindow();jbEnviar.setFocusPainted(true);jtMsg.addKeyListener(this);

}

public void keyPressed(KeyEvent arg0) {

93

//user apertou enterif (arg0.getKeyCode() == 10) {

if ("".equals(jtMsg.getText())) {System.out.println("Mensagem inválida, digite

algo...");JOptionPane.showMessageDialog(null, "Mensagem

inválida!");} else {

sendMessage(jtMsg.getText());jtMsg.setText("");

}}

}

public void keyReleased(KeyEvent arg0) {}

public void keyTyped(KeyEvent arg0) {}

public void printMessage(String msg) {jtMsgAll.append("\n" + new Date() + " - " + msg);

}

public void printMessage(String msg, String from) {String msgFormatada =

ChatApp.getShortDate() + " - " + from + " fala paratodos:" + msg;

jtMsgAll.append("\n" + msgFormatada);}

public void sendMessage(String mensagem) {chat.sendMessageToAll(mensagem);

}}

Arquivo log4j.xml

log4j.rootLogger=WARN,rootlog4j.appender.root=org.apache.log4j.ConsoleAppenderlog4j.appender.root.layout=org.apache.log4j.PatternLayoutlog4j.appender.root.layout.ConversionPattern=%d - %-4r- %3x - [%t] %-5p(%F:%L) - %m%n

log4j.logger.chat=WARN,a#log4j.additivity.login=falselog4j.appender.a=org.apache.log4j.RollingFileAppenderlog4j.appender.a.File=chat.loglog4j.appender.a.layout=org.apache.log4j.PatternLayoutlog4j.appender.a.layout.ConversionPattern=%d - %-4r- %3x - [%t] %-5p(%F:%L) - %m%n

Antonio Augusto Mariano da SilvaRicardo Augusto MiguelRicardo Ribeiro Tavares

Desenvolvendo aplicações peer-to-peer em JAVA com JXTA

Trabalho apresentado à disciplina deTrabalho de Graduação Interdisciplinar II,como parte das exigências para a obtenção

do título de Bacharel em Sistemas de Informaçãopela Faculdade de Computação e Informática

da Universidade Presbiteriana Mackenzie

Orientador: Rogério de Oliveira

São PauloOutubro de 2003

RESUMO

Nos dias atuais, para o desenvolvimento e melhor obtenção de recursos da

Internet, necessitaremos de uma computação distribuída com compartilhamento de

recursos, conteúdo, e estrutura de rede independente, redundante e segura em tempo

real. Neste estudo estaremos apresentando os principais modelos e implementações

atuais de aplicações P2P e as necessidades existentes. Os conceitos envolvidos em uma

construção serão apresentados detalhadamente, e posteriormente aplicados em um

projeto open source Java JXTA, que permitirá um novo tipo de computação distribuída

tornando muito mais fácil as tarefas que as pessoas executam na Web atualmente:

encontrar, obter, utilizar. Codificaremos em JAVA algumas aplicações JXTA simples

que exemplificam o potencial dessa tecnologia.

ABSTRACT

Nowadays, for a development and to get Internet resources, need a the

distributed computing and sharing of resources over the internet need a distributed

computation with resource sharing, content, and independent, redundant and a security

network infrastructure in real time. In this study we are showing the core models and

implementations for peer-to-peer applications and the real necessity of use it. The

concepts involved in construction of peer-to-peer applications are showing deeply, and

after that, we are introducing the main concepts of JXTA, that it will allow a new type

of distributed computation that it becomes much more easy the tasks that the people run

in the Web: search, get, use.To exemplify the power of this technology we are coding

some simple examples like a chat in JAVA with JXTA framework. After read this study

you’ll be able to understand the main concepts of peer-to-peer, and the challeng

involved in it, in addition to develop simple applications using JAVA with JXTA

framework.

Date post:	22-Oct-2015
Category:	Documents
Upload:	nicolasaraujo
View:	49 times
Download:	0 times

Plugin 2003P2PJXTA

Documents