Você está na página 1de 50

EDUARDO SPONHOLZ FRANCISCO RICARDO ANDRASCHKO

ESTUDO DE APLICAÇÕES DISTRIBUÍDAS P2P

PONTA GROSSA 2008

UNIVERSIDADE ESTADUAL DE PONTA GROSSA SETOR DE CIÊNCIAS AGRÁRIAS E DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA

EDUARDO SPONHOLZ FRANCISCO RICARDO ANDRASCHKO

ESTUDO DE APLICAÇÕES DISTRIBUÍDAS P2P

PONTA GROSSA 2008

EDUARDO SPONHOLZ FRANCISCO RICARDO ANDRASCHKO

ESTUDO DE APLICAÇÕES DISTRIBUÍDAS P2P

Monografia apresentada para obtenção da titulação de Bacharel em Informática no curso de graduação em Bacharelado em Informática, Setor de Ciências Agrárias e de Tecnologia da Universidade Estadual de Ponta Grossa - Paraná.

PONTA GROSSA 2008

RESUMO

Com o advento da internet e da computação distribuída, soluções como redes P2P vêm popularizando-se cada vez mais. Em seu inicio P2P era apenas para troca de mensagens, mas com seu crescimento veio também sua melhoria. Devido ao crescente acesso a internet e à vantagem de atuação remota sobre redes convencionais cliente-servidor, surgiu então à necessidade de ampliação de sua aplicabilidade, levando ao modelo atual de compartilhamento de arquivos, recursos e informações diversas. Para isso ferramentas específicas ao desenvolvimento P2P foram necessárias. Plataformas como JXTA, GDK e .NET têm auxiliado a firmar estas redes num lugar de destaque entre as demais redes, formalizando sua arquitetura descentralizada (ausência de servidor dedicado) e seu propósito de compartilhamento de informações.

Palavras chave: Redes P2P, Plataforma JXTA, Compartilhamento de Arquivos e Recursos.

SUMÁRIO

1

INTRODUÇÃO ...................................................................................................... 1 1.1 RELEVÂNCIAS DO TRABALHO .................................................................... 1 1.2 PADRONIZAÇÃO ........................................................................................... 3 1.3 OBJETIVOS ................................................................................................... 6 1.4 ORGANIZAÇÃO DO TRABALHO................................................................... 6

2 3

METODOLOGIA ................................................................................................... 7 REDES P2P .......................................................................................................... 8 3.1 VANTAGENS P2P .......................................................................................... 9 3.2 DESVANTAGENS P2P .................................................................................. 9 3.3 ARQUITETURA P2P .................................................................................... 10 3.3.1 COM SERVIÇO DE LOCALIZAÇÃO CENTRALIZADA ..................... 11 3.3.2 BASEADA EM INUNDAÇÃO ............................................................. 12 3.3.3 BASEADA EM REDES DE SUPERPOSIÇÃO ................................... 14 3.4 COMPARATIVO ENTRE ARQUITETURAS P2P ......................................... 15 3.5 ALGORITMOS P2P ...................................................................................... 18 3.6 EXEMPLOS DE SISTEMAS P2P ................................................................. 19 3.6.1 NAPSTER .......................................................................................... 19 3.6.2 SETI@HOME ..................................................................................... 20 3.6.3 FREENET .......................................................................................... 20

4

PLATAFORMAS DE DESENVOLVIMENTO....................................................... 22 4.1 JXTA ............................................................................................................. 22 4.1.1 CAMADAS JXTA................................................................................ 23 4.1.2 GRUPOS............................................................................................ 25 4.1.3 AVISOS .............................................................................................. 26 4.1.4 PIPES E MENSAGENS ..................................................................... 27 4.1.5 PROTOCOLOS .................................................................................. 27 4.1.5.1 PEER DISCOVERY PROTOCOL – PDP .................................. 28

4.1.5.2 PEER RESOLVER PROTOCOL – PRP .................................... 28 4.1.5.3 PEER INFORMATION PROTOCOL – PIP ................................ 28 4.1.5.4 RENDEZVOUS PROTOCOL – RVP ......................................... 29 4.1.5.5 PIPE BINDING PROTOCOL – PBP .......................................... 29 4.1.5.6 ENDPOINT ROUTING – PEP.................................................... 30 4.1.6 DESENVOLVIMENTO P2P UTILIZANDO JXTA................................ 30 4.1.6.1 IMPLEMENTAÇÃO DO PEER................................................... 31 4.1.6.2 ORGANIZAÇÃO DAS CLASSES .............................................. 32 4.1.6.3 EXEMPLO DE IMPLEMENTAÇÃO ........................................... 33 4.1.6.4 JXTA SHELL.............................................................................. 34 4.1.6.5 .NET .......................................................................................... 35 4.1.6.6 GROOVE DEVELOPMENT KIT (GDK) ..................................... 35 4.1.7 PADRONIZACAO POR XML ............................................................. 36 4.1.8 DESEMPENHO JXTA ........................................................................ 37 5 6 CONCLUSÃO ..................................................................................................... 38 REFERÊNCIAS .................................................................................................. 39

LISTA DE FIGURAS
Figura 1 - Modelo de Rede Centralizada (cliente-servidor) (ASTIAZARA, 2008) ................................................................................................. 2 Figura 2 - Modelo de Rede Descentralizada (ARNAUTH, 2008).......................... 2 Figura 3 - Protocolo TCP/IP, suas camadas e seus agentes. (REMOALDO, 2008) ......................................................................... 5 Figura 4 - Exemplo de serviço de localização centralizada (APPLIED META COMPUTING, 2000) .............................................................. 12 Figura 5 Rede Baseada em Inundação (APPLIED META

COMPUTING, 2000) ......................................................................... 13 Figura 6 - Arquitetura de Super-Peers e peers convencionais (STOICA, MORRIS, KARGER, KAASHOEK, & BALAKRISHNAN, 2001) ................................................................................................. 15 Figura 7 - Arquitetura de Rede Virtual JXTA (PROJETO JXTA, 2007) ................ 23 Figura 8 - Estrutura das camadas lógicas JXTA (PROJETO JXTA, 2007) .......... 24 Figura 9 - Empilhamento de protocolos JXTA (PROJETO JXTA, 2007) .............. 28 Figura 10 - Demonstração do protocolo RVP (PANISSON, 2007) ....................... 29 Figura 11 - Demonstração do protocolo PEP (PANISSON, 2007) ....................... 30 Figura 12 - Exemplo de retorno das funções executadas (LIMA, 2005)............... 34

i

LISTA DE TABELAS
Tabela 1 - COMPARATIVO ENTRE AS ARQUITETURAS P2P (FRANCESQUINI, 2004) ................................................................... 16

ii

1

INTRODUÇÃO

1.1

RELEVÂNCIAS DO TRABALHO

A integração de recursos computacionais em larga escala através de redes de alto desempenho interligadas pela rede mundial de computadores (Internet), tem permitido que novas idéias e técnicas de computação sejam desenvolvidas. A rede mundial de computadores pode ser considerada, devido ao grande número de tecnologias de softwares utilizadas como um grande sistema distribuído. Sistemas computacionais distribuídos, em princípio são caracterizados por um grande conjunto de recursos interligados com o intuito de compartilhar conteúdo, melhorar o desempenho no processamento, tornar os recursos tolerantes a falhas e obter paralelismo entre os usuários que utilizam o sistema (COULOURIS, DOLLIMOREM, & KINDBERG, 2001). Redes de computadores são os meio encontrados pelos sistemas distribuídos para atuação, onde dois são os modelos mais vistos: Centralizado e Descentralizado. A organização da estrutura cliente-servidor (centralizado) nos sistemas distribuídos sugere a interligação de uma estação cliente atuando como Requisitante, com constantes solicitações a estação servidor, o qual atuará como Processante, limitando-se a processar e responder os pedidos (do Cliente). A Erro! Fonte de referência não encontrada. a seguir ilustra um modelo de rede centralizada, ou seja, um servidor central e n estações clientes conectado a ele. Um ou mais clientes podem requisitar ao servidor, porem estes apenas solicitarão processamentos e ficarão aguardando o retorno do servidor, o qual também apenas processa e retorna, ficando impossibilitado de requisitar.

1

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

Diferente da centralizada, a arquitetura descentralizada assume que cada estação poderá tanto requisitar quanto responder pedidos, o que torna cada estação tanto em cliente como servidor. O nome descentralizado vem daí, pois não contem um servidor centralizador. A Erro! Fonte de referência não encontrada. ilustra uma rede descentralizada, onde todos os computadores se comunicam, podendo requisitar e responder simultaneamente, sem a necessidade de autorização de um servidor

central.

Atualmente, um grande número de aplicações encontra uma excelente

2

Figura 2 - Modelo de Rede Descentralizada (ARNAUTH, 2008)

alternativa em redes descentralizadas, como é o caso das Redes Peer-to-Peer1 (P2P), seja para a execução de aplicações naturalmente paralelas, que são compostas por diferentes processos que interagem entre si para a resolução de um problema, ou para melhorar o desempenho e a tolerância às falhas de aplicações em geral, de diversas áreas do conhecimento, por exemplo: predições e análise de crédito no mercado financeiro, descoberta de genomas, mineração de dados, algoritmos de busca e computação evolutiva (ORAM, 2001) e (LUTHER, BUYYA, RANJAN, & VENUGOPAL, 2006). Os benefícios dessa tecnologia estão relacionados com: a melhor possibilidade de crescimento em escala por evitar a dependência de servidores centralizados, o estabelecimento de comunicação direta entre os computadores e a possibilidade de agregação de recursos. Além disso, a computação paralela e distribuída em redes P2P é bastante efetiva no aproveitamento do sistema computacional como um todo, possibilitando uma melhor utilização dos recursos circulantes nas redes (LUTHER, BUYYA, RANJAN, & VENUGOPAL, 2006). Assim, esforços nos estudos de tecnologias e soluções das redes P2P, bem como padronização das mesmas, que auxiliem o acesso à computação distribuída têm impacto imediato nos diferentes ramos da informática.

1.2

PADRONIZAÇÃO

Um problema comum no desenvolvimento de software, que também existe em redes distribuídas e P2P, é a necessidade de padronização, pois as mesmas atuam em grandes dimensões geográficas, com tecnologias diferenciadas. Estes

1

Peer: palavra inglesa que assume o significado de ‘par’. Peer-to-peer ou P2P seria então par-a-par,

ou seja, entidades distintas que possuem mesmo ‘peso’, ‘posição’, igual teor, ou seja, iguais perante o conjunto, porém mantendo suas características particulares. 3

padrões são necessários desde o desenvolvimento até a compatibilidade de tráfego da informação. Existem bibliotecas padronizadas, cada uma com sua peculiaridade e com sua finalidade bem definida. Essas bibliotecas, sejam protocolos, padrões de implementação ou ferramentas de desenvolvimentos, tendem a seguir normativas homologadas pelas mais renomadas entidades da informática, sejam elas ONG’s, entidades de Ensino, Instituições Públicas e/ou Privadas. Porém muitas tentativas de padronização não obtiveram o respaldo e a aceitação necessária na comunidade informática, já outras estão constantemente sendo atualizadas, para assim se tornarem e/ou continuarem sendo referencias, como é o caso da ODF2 (ISO, 2008) e ANSAware3 (ANSAWARE, 2008). Uma das bibliotecas mais utilizadas ao citar tráfego em redes é o protocolo de TCP/IP4 (TCP/IP, 1991) por tratar-se de um protocolo orientado a conexões, com grande portabilidade. Devido a isso se tornou o protocolo padrão da internet e com isso um protocolo padrão para sistemas distribuídos. A Figura 3 mostra as camadas do protocolo TCP/IP, seus agentes e em destaque os principais elementos do protocolo (TCP e IP).

2

ODF: abreviação de "OASIS Open Document Format for Office Applications", é um formato de

arquivos de suítes de escritório, como textos, planilhas, apresentações e base de dados. Desenvolvido pelo consórcio OASIS baseia-se na linguagem XML. O ODF é um formato aberto e público e foi aprovado como norma ISO/IEC em Maio de 2006 (ISO/IEC 26 300)
3

ANSA: Arquitetura para sistemas distribuídos abertos. É uma iniciativa colaborativa gerenciada

por Citrix Systens (Research & Development) Ltd.
4

TCP/IP: protocolo proveniente da mescla de protocolos, onde seus dois principais agentes são:

TCP (Transmition Control Protocol) e IP (Internet Protocol). Eles, respectivamente encontram-se nas camadas de Transporte e Rede do protocolo TCP/IP. O mesmo é referenciado pela RFC 1180. 4

Camadas

Agentes

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

Outros padrões muito utilizados em sistemas distribuídos são (LIMA Jr & de PAULA, 2001): • CORBA: Common Object Request Broker Architecture. Desenvolvido pela OMG (Object Management Group), é uma tecnologia que permite a interoperabilidade entre módulos de software executados em sistemas distribuídos. • IDL: Interface Definition Language. Assim como CORBA, possui os mesmos desenvolvedores, porem tem serventia de ligação dos múltiplos componentes CORBA com o usuário. • JAVA/RMI: Java Remote Method Invocation and Specification. Arquitetura de sistema distribuído programado em Java, o qual objetiva transparência na comunicação de componentes distribuídos de diferentes máquinas virtuais. Seguindo a padronização de sistemas distribuídos, a tecnologia JXTA, segundo (THEODOLOZ, 2004) e (PROJETO JXTA, 2007), apresenta-se como uma solução, fornecendo uma interface de programação padronizada, agregando interoperabilidade entre linguagens de programação, como exemplo entre Java e C, alem de outros serviços, como padrão para descoberta de recursos, comunicação de processos e segurança.

5

1.3

OBJETIVOS

O objetivo deste trabalho é apresentar um estudo relacionado aos sistemas distribuídos P2P, exemplificando arquiteturas, protocolos, ferramentas, modelos de desenvolvimento e de aplicativos P2P.

1.4

ORGANIZAÇÃO DO TRABALHO

O capítulo 2 aborda teoricamente a metodologia utilizada no estudo de aplicações P2P, o qual será consolidado no capitulo 4. A Revisão Bibliográfica é apresentada no capitulo 3, abordando conceitos de dados, informações e descrições dos sistemas distribuídos P2P (Redes P2P); apresenta as vantagens e as desvantagens deste tipo de sistema distribuído. Apresenta também os modelos triviais de arquiteturas e um breve comparativo entre eles. Também estão inclusos os modelos de algoritmos para Redes P2P e alguns exemplos de sistemas P2P. O capítulo 4 consiste num descritivo sobre desenvolvimento de aplicações P2P, exemplificando ferramentas e códigos-fonte para implementação do P2P e o desempenho dos itens citados em relação ao sistema P2P. O Capítulo 5 apresenta uma conclusão, após o fechamento dos trabalhos realizados neste estudo.

6

2

METODOLOGIA

A internet nos últimos anos vem sofrendo significativas alterações, sendo grande parte dessas, avanços tecnológicos, como divulgação de noticias, aberturas de novos mercados em vendas on-line e compartilhamentos, dentre outros. Engajado nisso que em 2001, redes P2P tomou uma proporção de conhecimento estrondosa, após o surgimento do compartilhador de arquivos pela Internet, Napster que atraiu não somente internautas5 residenciais, devido ao acesso fácil e gratuito, como também companhias musicais, como gravadoras, e entidades responsáveis por segurança e direitos autorais na internet. Este trabalho é voltado aos interessados em redes de compartilhamento P2P e aplicações à mesma. Desenvolvimento e modelos de ferramentas para estas aplicações serão assuntos abordados. Uma abordagem preliminar sobre redes P2P, modelos, exemplos, vantagens, desvantagens, arquiteturas existentes e os comparativos entre elas, são itens esclarecidos, para que um melhor entendimento haja. Contudo os modelos de padronização, protocolos, vantagens e

desvantagens e principalmente da ferramenta de desenvolvimento, sobretudo do JXTA (esta a mais comum dentre as existentes) são assuntos objetivados neste trabalho.

5

Internauta: dito ao chamado usuário da Internet. 7

3

REDES P2P

A maioria dos sistemas em uso em plataformas WEB são sistemas distribuídos e interagem em uma arquitetura convencional de cliente-servidor, onde cada cliente utiliza um protocolo específico à operação requerida. Essa abordagem concentra as operações no servidor, requerendo assim um equipamento de hardware e um sistema operacional em profunda sintonia com os demais sistemas em execução, pois o aumento de processamentos (diga-se simultâneos) afeta diretamente a desempenho do equipamento e com isso a qualidade de retorno (resultado) do aplicativo ao usuário. Rede Peer-To-Peer, ou apenas P2P é uma tecnologia a qual seus estudiosos, desenvolvedores e usuários vislumbram sanar o problema citado, pois a mesma segue a premissa de não concentrar todas as operações em uma única estação (servidor), atuando então no modelo Descentralizado. Essa topologia descentralizada auxilia ainda na expansão da rede, pois uma estação (seja computador ou outro equipamento) que possua uma interface de rede capaz de adquirir um endereço IP6, pode facilmente ingressar a rede, sem prévia autorização de um servidor, ou mesmo sem que haja alterações na estrutura lógica ou física da rede. Os requisitos para que tal estação ingresse na rede P2P, é possuir um meio de ligação e um aplicativo compatível com o da rede. As redes P2P exploram a conectividade entre seus integrantes, utilizando os recursos físicos e lógicos disponíveis (processador, memória, entre outros) do equipamento, fazendo com que a capacidade da rede cresça em larga escala. Devido à facilidade de ingresso, aos recursos disponíveis e a falta de um servidor central monitorando essas redes, é impossível diagnosticar com exatidão o tamanho atual e o tamanho que uma rede P2P pode atingir.

6

IP: internet protocol, pode ser considerado o endereço numérico que representa o local de um

determinado equipamento em uma rede privada ou pública. 8

3.1

VANTAGENS P2P

Conforme (BALAKRISHNAN, KAASHOEK, KARGER, MORRIS, & STOICA, 2003), existem muitos atrativos para a utilização de redes P2P, onde os principais são: • Facilidade de conexão – Empecilho de conexão para este tipo de redes é mínimo, pois diferente dos sistemas totalmente

centralizados não necessita de administração ou instalações específicas; • Conteúdo diversificado – Pelo aumento constante de estações conectadas a Internet, redes P2P tem também seu crescimento e com o conteúdo incluso nelas, a quantidade de recursos compartilhados é cada vez maior e mais diversificado. • Segurança no compartilhamento – Este modelo de rede esta menos suscetível a falhas de compartilhamento ou ataques intencionais, pois é nativo de sistemas distribuídos, tornando assim ambiente ideal para troca de informações em longo prazo e/ou computações demoradas. • Confiabilidade – Caso ocorra problema em algum peer, o sistema não irá parar totalmente, pois os demais podem manter-se atuantes, utilizando recursos e/ou conteúdos existentes; • Utilização dos Recursos – Caso um peer não esteja utilizando um recurso especial, ele pode “ofertar” seus recursos disponíveis a outros peers, aumentando assim a capacidade de processamento da rede.

3.2

DESVANTAGENS P2P

Algumas características P2P podem ser entendidas como desvantagens,
9

pois insinuam ambigüidade (BALAKRISHNAN, KAASHOEK, KARGER, MORRIS, & STOICA, 2003). Algumas dessas características e suas descrições são: • Redundância – Devido ao tamanho das redes, uma estação efetuar duas buscas e obter o mesmo resultado é incomum e improvável, porém possível; • Tempo de Resposta – Com o aumento da rede, o tempo de resposta pode variar consideravelmente, podendo em casos de alto tempo de retorno, perder a informação buscada na rede; • Perda de conteúdo – Como um peer possui a facilidade de entrar e sair da rede, um conteúdo compartilhado pode facilmente deixar de existir na rede; • Desempenho – Arquitetada para atuar com grande número de peers conectados, a rede pode perder desempenho caso esse numero venha a ser baixo, pois as buscas e recursos serão limitados.

3.3

ARQUITETURA P2P

Redes P2P podem ser nativas ou híbridas, (YANG & GARCIA-MOLINA, 2001). Sistemas híbridos são aqueles não puramente descentralizados, isto é, utilizam uma estação como concentrador central, para armazenar algumas informações e efetuar alguns processamentos, similar a arquitetura de rede convencional. Esses sistemas são maioria dentre as redes P2P. Sistemas Nativos são aqueles que ao contrario dos híbridos, são puramente descentralizados, ou seja, não necessitam de nenhum tipo de concentrador de informações. Exemplo de sistema nativo é USENET (PROJETO USENET, 2007). As arquiteturas P2P são comumente divididas em três modelos: - Com serviço de localização centralizada; - Baseada em inundação;
10

- Baseada em redes de superposição.

3.3.1

COM SERVIÇO DE LOCALIZAÇÃO CENTRALIZADA

Este modelo não é uma arquitetura P2P puramente descentralizada, pois ao acessar a rede, a estação conecta a um ou mais servidores e envia informações de compartilhamento aos mesmos para que neles sejam gerados índices sobre os recursos disponíveis na estação. Estes índices estarão disponíveis aos demais peers conectados ao mesmo servidor. As informações geradas pelos servidores são distribuídas aos peers e quando esses efetuarem uma busca será informado o endereço IP da máquina que aloca os dados. A estação cliente (peer) que efetuou a busca pode então conectarse diretamente à estação proprietária das informações, (APPLIED META COMPUTING, 2000). A Figura 4 exemplifica o funcionamento de uma rede centralizada, onde: 1. O novo cliente se conecta ao servidor e envia uma lista dos seus dados compartilhados. 2. O cliente já registrado no servidor solicita a pesquisa de dados. 3. O servidor retorna uma lista com o endereço de todos os peers que contém a informação desejada. 4. O cliente contata o nodo que contém o arquivo desejado e o requisita. 5. O peer contatado transfere o arquivo ao requisitante.

11

Figura 4 - Exemplo de serviço de localização centralizada (APPLIED META COMPUTING, 2000) Este modelo de arquitetura têem como ponto forte a facilidade de buscas por palavras-chave e critérios múltiplos, deixando assim a busca ágil e rápida, pois diminuem assim o tempo de comparação de conteúdo. Outra característica existente nesse modelo, negativa, porém significativa, é estar mais suscetível a falhas na rede, pois podem ocorrer erros nos pontos centrais, o que danifica toda a estrutura da rede, e também estar mais vulnerável a ataques, pois ao acessar o centralizador todo o roteamento da rede torna-se disponível. Um exemplo de um aplicativo bastante conhecido que utiliza uma rede P2P centralizada é o Napster, que utiliza um servidor central para retornar aos clientes os resultados das buscas realizadas (PROJETO NAPSTER, 2007).

3.3.2 BASEADA EM INUNDAÇÃO

Rede Baseada em Inundação (Flooding Style Network) é uma arquitetura totalmente distribuída (100% P2P). Esse tipo de rede não possui servidores centrais, assim não agregando os problemas existentes na arquitetura centralizada.
12

(APPLIED META COMPUTING, 2000). Um equipamento acessa toda a rede P2P simplesmente conhecendo outro peer. Cada requisição de compartilhamento de recurso circula livremente entre os peers, até que algum peer que continha tal recurso retorne seu IP. Usa-se como controle dos mecanismos de inundação o TTL7 da rede, o qual garante que uma requisição não trafegue indefinidamente na rede, (APPLIED META COMPUTING, 2000). A Figura 5, exemplifica uma rede baseada em inundação onde: • • A estação (peer 2) requisita um recurso na rede; Esta requisição percorre os peers ainda não pesquisados (1), até que algum resultado seja encontrado e o peer proprietário marcado como satisfatório • Aqueles quais os resultados não foram satisfatórios, não serão novamente questionados e são diferenciados (3) • • Aqueles quais os resultados são satisfatórios serão positivados (4) Dentre todos aqueles positivados (4), deve existir um ou mais, com melhor resultado e será este(s) que retornarão o recurso requisitado (5). • Será então criada uma ligação direta (se ainda não existir) entre o peer requisitante e o peer mantenedor do resultado mais satisfatório.

6

1) Peer’s existentes na rede, mas não visitados na busca; 2) Peer de onde originou a busca; 3) Peer’s visitados, mas sem resultado satisfatório; 4) Peer’s visitados com resultados satisfatórios; 5) Peer com melhor resultado dentre os satisfatórios. 6) Caminho percorrido entre o requisitante e o resultado

7

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

3.3.3 BASEADA EM REDES DE SUPERPOSIÇÃO

Devido a descentralização das redes P2P e seu rápido crescimento ao efetuar consecutivas buscas, obter os mesmos resultados, e principalmente que sejam os mais satisfatórios, é praticamente impossível. Esse problema não existe no modelo de rede centralizado e baseado neste que foi criado o modelo de redes de superposição 2001). Este tipo de rede delega funções especiais a alguns peers da rede (superpeers), tornando-os servidores para outros peers. Apenas Super-peers terão acesso efetivo a rede P2P, ou seja, somente os Super-Peers possuem conexão e operação direta com outros Super-peers. Os demais peers (convencionais) apenas requisitam e respondem aos respectivos super-peers. Outra característica deste modelo é que ao entrar na rede e conforme o critério utilizado para ordená-los (geralmente o IP da estação) os peers são reagrupados, ficando ordenados sequenciamente. A Figura 6 ilustra o modelo de tal rede, onde pode ser visualizado peers convencionados, ligados a super-peers, como se fossem pequenas comunidades. E entre essas comunidades existe uma ligação, garantindo assim comunicação total da rede. (STOICA, MORRIS, KARGER, KAASHOEK, & BALAKRISHNAN,

14

192.168.3.10 192.168.3.5 192.168.5.1

192.168.21.100 192.168.21.105 192.168.21.1 192.168.21.106

Convencionais

Super-peers

192.168.5.1 192.168.80.37 192.168.37.1 192.168.5.2 192.168.80.56

Figura 6 - Arquitetura de Super-Peers e peers convencionais (STOICA, MORRIS, KARGER, KAASHOEK, & BALAKRISHNAN, 2001)

Este tipo de rede P2P agrega as vantagens dos modelos de localização centralizada e do modelo baseado em inundação, pois mantém sempre uma tabela atualizada nos super-peers com o conteúdo disponível na rede, agilizando assim as buscas. Também comunica diretamente os super-peers, sem que estes passem por outro concentrador de rede. Embora essa arquitetura proporcione uma melhora significativa na rede, ela sobrecarrega os super-peers, por efetuarem maior número de operações.

3.4

COMPARATIVO ENTRE ARQUITETURAS P2P

Para que possa ser citado qual modelo de arquitetura é melhor em relação a falhas, pesquisa de dados, anonimato, rapidez, entre outros itens, é necessário que a mesma busca seja feita, utilizando a mesma proporção de peer pesquisados. Num estudo comparativo entre as arquiteturas P2P, (FRANCESQUINI, 2004) obteve os resultados citados na tabela 1, quantificando as características das
15

arquiteturas usando notas entre 0 e 3, onde melhores são as maiores notas. Os critérios de análise foram: • Tolerância à falhas – Quanto à rede é resistente à falhas e ataques. A remoção de algum peer especial traz grandes conseqüências à rede? • Escalabilidade – A rede consegue suportar um grande número de usuários? • Pesquisa de dados – Suporta pesquisa por palavras chave e coringas? E bom para pesquisas aleatórias? Tem garantias quanto à acessibilidade dos dados? • Anonimato – Tanto quem requisita quanto quem fornece a informação consegue manter a sua identidade em sigilo?

O resultado encontrado então foi: Tabela 1 - COMPARATIVO ENTRE AS ARQUITETURAS P2P (FRANCESQUINI, 2004)
Tolerância à falhas Centralizado Descentralizado Inundação Superposição 0 1 3 2 escalabilidade 2 3 1 3 Pesquisa de dados 3 3 2 1 Anonimato 0 0 3 0

Para um maior esclarecimento, descreve-se a tabela assim: • Centralizado – Arquitetura cliente/servidor convencional, onde as estações em rede comunicam-se exclusivamente por intermédio de um concentrador (servidor). • Descentralizado – Arquitetura puramente descentralizada,

desprovida de servidor central e sem qualquer variação em seu modelo original. Assumem que uma busca ocorrerá quantas vezes e quantos peers forem necessários.
16

Inundação – Busca baseada no modelo de rede baseado por inundação.

Superposição – Busca baseada no modelo de rede baseado por superposição.

Tolerância a falhas – Retirada de um peer especifico, mantenedor de conteúdo específico, pode alterar o resultado da rede, este é o principal teste deste item.

Escalabilidade – crescimento da rede seja baseado em números de peers ou de arquivos circulantes.

Pesquisa de Dados – Busca de dados utilizando coringas, ou seja, símbolos como * (todos), + (conjunção &), e buscas aleatórias, como múltiplas buscas e não seqüenciais e buscas de arquivos não conhecidos (não buscados recentemente).

Anonimato – item considerando tanto o anonimato do pesquisador quando dos pesquisados.

As considerações finais dos testes relatados na Tabela 1, demonstram que cada arquitetura sobressaiu-se em um item, porém numa análise conjunta de tais itens a arquitetura por inundação obteve os melhores resultados. Vale ressaltar ainda que a única arquitetura que obteve resultado no item anonimato foi por inundação, pois é o único modelo analisado que não necessita de nenhum tipo de concentrador e a busca percorre livremente, sem uma seqüência ou forma de busca definida. Outro item a ressaltar é o baixo resultado da arquitetura por superposição, em relação à busca de dados aleatórios ou utilizando caracteres coringas, isso porque o mesmo deve reordenar toda a rede, cada vez que existe a inserção ou remoção de um peer.

17

3.5

ALGORITMOS P2P

Os algoritmos P2P são aqueles que determinam os métodos de busca nas redes P2P, seja ela centralizada ou descentralizada. A eficiência da busca consiste na eficiência do algoritmo e está diretamente ligada ao número de peers ligados a rede no momento da busca (GOMES, PETEK, DIVERIO, & GEYER, 2006). Um exemplo de algoritmo de busca usado em redes P2P é o DHT, cuja sigla representa Distributed Hash Tables (ou Tabelas Hash Distribuídas). Esse algoritmo atua similarmente a uma tabela hash. Em DHT, identificadores são calculados de acordo com a função hash utilizada, onde tanto o peer quanto o conteúdo armazenado recebe tal identificador. Cada peer armazena informações de alguns outros peers, mas somente dos mais próximos. Esse modelo segue a seguinte ordem: a. é feita a busca do conteúdo na rede e esta para ao primeiro resultado satisfatório encontrado; b. é identificado o peer mais próximo ao satisfatório (item 1) e também ao peer de origem da busca; c. é atribuído o identificador ao peer comum (item 2); d. após atribuir o identificador (item 3), a busca é reiniciada; e. ao localizar outro resultado satisfatório, é atribuído um novo identificador a este peer e tambem armazenado o identificador do resultado anterior (item 4); f. a busca é finalizada quando o peer localizado é novamente o mais próximo do originário da pesquisa (item 2).

DHT é também distribuída entre os peers da rede de modo que haja perda de um nó, não cause perda considerável ao sistema, permitindo assim que haja uma escalabilidade perfeita à medida que novos peers são adicionados à rede, (DHT, 2007).
18

As vantagens enfatizadas no DHT são: • • • Descentralização; Escalabilidade; Tolerância à faltas.

Por suas características, tornou-se algoritmo base de aplicações P2P, bem como serviu de base para outros algoritmos de busca, como Tapestry, Chord, CAN e Pastry.

3.6

EXEMPLOS DE SISTEMAS P2P

Compartilhadores são exemplos de aplicações distribuídas que em sua maioria utilizam redes P2P, por meio da internet ou redes locais. Existem modelos diferenciados de compartilhadores, que podem ou não possuir configurações locais diferenciadas, assim como as estações que os alojam e arquiteturas similares, porém, todos respeitam requisitos básicos, como protocolos, e a mais importante, utilizam o mesmo meio de comunicação, uma rede local ou internet, em caso de redes remotas (CLARKE, 1999). Uma estação pode alojar mais de um compartilhador e estes podem atuar em redes distintas ou em uma mesma rede, podendo ainda compartilhar entre si os recursos ou objetos aos quais estejam disponíveis.

3.6.1 NAPSTER

Em 2001 Shawn Fanning estudante da Universidade de Boston, Northeastern University, buscando um modo mais fácil de pesquisar músicas na internet criou o compartilhador Napster. Este programa gerou muita polêmica, ao atingir uma enorme quantidade de usuários em todo o mundo, levantando uma legião de defensores e preocupando as grandes gravadoras de discos, devido à quebra de direitos autorais e a facilidade de aquisição gratuita de músicas,
19

(PROJETO NAPSTER, 2007). A arquitetura básica do Napster requer que clientes conectados a rede enviem uma lista dos arquivos compartilhados ao servidor central, o qual cria índice dos arquivos. Quando o cliente busca alguma música, se conecta ao servidor, e este atualiza a lista de índices e lhe encaminha o endereço do cliente que contém a música buscada e se inicia a troca, (ORAM, 2001). Com toda a polêmica gerada, judicialmente o desenvolvimento do Napster foi interrompido em julho de 2002.

3.6.2 SETI@HOME

Seti (Search for Extraterrestrial Intelligence) surgiu logo após o fenômeno Napster, simplificando um sistema de troca de informações sobre civilizações extraterrestres, onde utiliza a rede P2P para concretizar os cálculos e processamentos diversos, dos dados coletados pelo telescópio gigante Arecibo, (ANDERSON, COBB, KORPELA, LEBOFSKY, & WERTHIMER, 2002), os processamentos utilizados são de computadores ociosos ligados à rede pela internet (PROJETO SETI@home, 2007), utiliza uma arquitetura centralizada ou

descentralizada.

3.6.3 FREENET

Utilizando uma arquitetura totalmente descentralizada, seu propósito inicial possuía uso de sistemas remotos anônimos, ou seja, executaria pela rede uma série de instruções e processamentos remotamente (CLARKE, 1999). Isto é, um usuário pode requisitar à rede um local para armazenar um arquivo, e outro usuário pode responder a requisição, sem ao menos saber quem a fez. Outro ponto é, se um usuário tem armazenado um arquivo em seu sistema, ele é incapaz de saber quem o armazenou e está compartilhando este arquivo (CLARKE, SANDBERG, WILEY, &
20

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

21

4

PLATAFORMAS DE DESENVOLVIMENTO

Muitas aplicações requerem a utilização de uma plataforma específica de desenvolvimento, para que haja total integração entre peers na rede. Isso gera inconvenientes, pois tais aplicativos devem ser desenvolvidos em linguagem, tipo de rede, protocolos e outros, iguais. Este problema da compatibilidade e/ou portabilidade restringe tanto o desenvolvimento quanto o uso do aplicativo, por isso aplicativos com integração entre redes e sistemas operacionais têm destaque. Em aplicações P2P a portabilidade é algo extremamente importante, visto o tamanho das redes e a cultura de seus usuários, fazendo com que linguagens de programação, modelos de interfaces, protocolos utilizados e demais características de usuários, sejam diferentes. Devido a isso alguns padrões de programação são utilizados, como JXTA, .Net e Groove.

4.1

JXTA

A idéia original do Projeto JXTA, era criar um meio de integrar a tecnologia P2P ao núcleo da arquitetura de rede (PROJETO JXTA, 2007). O JXTA aglomera um conjunto de protocolos P2P simples para comunicação, colaboração e compartilhamento de recursos. Os peers JXTA criam uma rede virtual no topo de redes existentes, mascarando a complexidade das camadas inferiores. Na rede virtual JXTA, qualquer peer interage com outro, independendo de sua localização, tipo de serviço ou ambiente operacional. Assim, o acesso aos recursos da rede não são limitados por incompatibilidade de plataforma ou restrições da arquitetura cliente-servidor convencional (KAMIENSKI, 2004). A Figura 7 demonstra tal arquitetura de rede virtual.
22

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

Na topologia de rede virtual, cada peer é associado a um identificador único, chamado de Peer ID, e pertence a um ou mais peergroups, tendo em vista o suporte a grupos que o ambiente JXTA desenvolvido forneça8. Dentro dos peergroups os peers cooperam e têm as mesmas funções. A tecnologia JXTA objetiva: • • Interoperabilidade: entre diferentes sistemas e comunidades P2P; Independência de plataforma: diversas linguagens, sistemas e redes; • • Generalidade: qualquer tipo de dispositivo digital; Segurança.

4.1.1 CAMADAS JXTA

8

O números de grupos (peergroups) ao qual o peer pode pertencer é customizável no

desenvolvimento do aplicativo P2P. 23

Para que na prática ocorra o que na teoria é proposto pelo JXTA, sua estrutura é dividida em camadas: • Core – provê os elementos necessários ao aplicativo P2P, e nessa camada são implementados os grupos, os monitoramentos, as políticas de segurança e os túneis de comunicação; • De Serviços – Camada não obrigatória ao aplicativo, porém todo conteúdo desenvolvido nessa camada, torna-se compartilhado entre os demais peers e/ou entre aplicativos de um mesmo peer. Nessa camada encontram-se os comandos, serviços e o prompt de comando; • De Aplicação – É a camada visível ao usuário, pois nela são implementadas as integrações entre os aplicativos P2P e os protocolos internos a ele. Todo conteúdo da camada de serviços, torna usável por esta camada.

A Figura 8 ilustra tais camadas.

Figura 8 - Estrutura das camadas lógicas JXTA (PROJETO JXTA, 2007)
24

Como citado, nem todas as 3 camadas do JXTA são necessárias, porem existem alguns elementos que são básicos. São eles: • • • • Grupos; Avisos ou Comunicados; Pipes9 e mensagens; Protocolos.

4.1.2 GRUPOS

Os grupos servem não para distinguir um peer de outro, mas sim delimitar conjunto de serviços e recursos os quais os peers oferecerem a rede, para compartilhamento. Os grupos ou os peers podem ser dos tipos abaixo? Se o certo for escrever “Os peers podem ser do tipo”, então copiem o trecho abaixo para junto da figura 9. Os grupos podem ser do tipo Edge, Minimal, Proxy, Rendezvous e Relay, onde se tem: • EDGE PEERS: estações simples, computadores de mesa e outros equipamentos, podendo estar conectados por meio de uma rede local ou através da internet. • MINIMAL PEERS: Nesse grupo enquadram-se geralmente os dispositivos móveis como celulares e palmtops, ou outro

equipamento que possua restrição quanto ao carregamento de algumas funcionalidades do JXTA. • PROXY PEERS: Redes que ficam encobertas por firewall ou por equipamentos que atuam como Proxy ou ainda aqueles sem navegação livre ou limitada por autenticação de servidor, possuindo ou não um IP público.

9

Pipes: traduzido como tubo, cano, indica um túnel. 25

RENDEZVOUS PEERS: Neste grupo estão os peers de maior poder computacional (seja por capacidade de hardware ou de software), estações com IP estático e peers que fornecem cache de informações sobre outros peers conectados, auxiliando assim, na busca de recursos e resolução de problemas.

RELAY PEERS: Peers que assumem papel de roteadores, que ultrapassam o firewall, NAT10 ou simplesmente roteador, para trocar informações com outros peers do mesmo tipo.

4.1.3 AVISOS

Todas as informações coletadas e armazenadas pelo JXTA são representadas pelos avisos, que são expressos como documentos XML11. Avisos são criados e registrados com o ID do peer, que é único e universal, ou seja, não existirá jamais duplicidade das informações, as quais serão retransmitidas e armazenadas localmente nos demais peers. Os avisos possuem tempo de vida, para evitar que peers desativados, tenham suas informações em tráfego ainda, e esse tempo de vida é o tempo que o peer mantém-se ativo na rede, após isso as informações são excluídas. Os tipos básicos de avisos são: • • • • PEER: registro do peer; PEERGROUP: registro do grupo ao qual o peer pertence; PIPE: canal de comunicação peer-to-peer; SERVICE: serviço oferecido pelo peer ou peergroup;

10

NAT: Network Addrress Translation, termo em inglês, já adotado ao portugues, para Tradução

dos endereços de rede (IP).
11

XML: EXtensible Markup Language - Linguagem extensível de formatação. Linguagem

utilizada em metadados, ou seja, informações sobre informações. 26

ENDPOINT: pontos de conexão de um pipe.

4.1.4 PIPES E MENSAGENS

Mensagens são as informações unidirecionais e não-confiáveis, que possuem ID da origem e cabeçalho com informações sobre roteamento, que trafegam pelos pipes, que por sua vez são os canais de comunicação entre os peers. Os peers de origem e destino dos pipes e mensagens são chamados de Endpoints, e correspondem as interfaces de envio e recebimento das informações.

4.1.5 PROTOCOLOS

Os protocolos JXTA foram elaborados com base em mensagens XML, pela sua alta usabilidade e portabilidade, auxiliando no suporte ao seu processamento e em sua validação. O uso de tal padrão gerou a desvantagem das mensagens serem muito maiores do que num padrão binário, pois XML é uma forma não-compacta de transmissão de dados. A Figura 9 mostra a forma de empilhamento dos protocolos, tanto no peer local quanto no remoto.

27

Peer Local

Peer Remoto

Peer Discovery Protocol

Peer Discovery Protocol

Peer Information Protocol Pipe Binding Protocol

Peer Information Protocol Pipe Binding Protocol

Peer Resolver Protocol

Peer Resolver Protocol

Rendezvous Protocol

Rendezvous Protocol

Endpoint Routing Protocol

Endpoint Routing Protocol

Camada de Transporte

Camada de Transporte

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

4.1.5.1 PEER DISCOVERY PROTOCOL – PDP

Implementado pelo Discovery Service (Serviço de descoberta), o objetivo deste protocolo é descobrir dinamicamente quais recursos JXTA o peer utiliza.

4.1.5.2 PEER RESOLVER PROTOCOL – PRP

Utilizando unicast ou multicast, efetua consulta genérica a outros peers. Este protocolo pode ser considerado a base estrutural para outros protocolos JXTA, como o Peer Information (PIP) e o Peer Discovery (PDP);

4.1.5.3 PEER INFORMATION PROTOCOL – PIP

28

Protocolo de coleta de informações diversas do peer, como desempenho da rede, algoritmos executados, seu status no momento, controle do consumo de serviços providos.

4.1.5.4 RENDEZVOUS PROTOCOL – RVP

Este protocolo é responsável pela gerência das mensagens em tráfego no grupo, é base para os protocolos PBP e PRP. A Figura 10 traz uma breve explicação de RVP.

1. O Peer 1 envia uma mensagem RVP a todos os peers conhecidos.

Peer Edge 1

3. Um peer Edge que recebe a mensagem propagada envia a resposta diretamente ao peer inicialmente responsável pelo envio da mensagem.

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

Peer Edge 2

Peer Edge 3

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

4.1.5.5 PIPE BINDING PROTOCOL – PBP

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

4.1.5.6 ENDPOINT ROUTING – PEP

Por meio de mensagens de busca, encontra informações de roteamento, para posteriormente efetuar a busca de conteúdo entre peers. Os dados armazenados localmente, contem ID remetente, ID destino, TTL, e a seqüência ordenada de peers no roteamento, Figura 11 (PANISSON, 2007). Atualmente transportes: • • TCP: Usa socket para conectar-se diretamente a outro peer. HTTP: Usado para transpor barreiras como firewalls, ou permitir transferência de informações a dispositivos móveis como celulares, tem como desvantagem o fato de não permitir broadcast. • • Servlet HTTP: Usado em aplicações que suportem Servlets. TLS: Para prover comunicação segura, com o uso de autenticação. existem implementações para os seguintes tipos de

Rede interna 1. O Peer 1 envia a mensagem ao peer Roteador 1 a fim de encaminhá-la ao Peer 2 através do Roteador2, conforme informação obtida previamente

Rede Externa (Internet) 2. O Peer Roteador 1 encaminha a mensagem ao Peer Roteador 2

Rede interna 2 3. O Peer 2 periodicamente se conecta ao Peer Roteador 2 a fim de verificar as mensagens que chegaram.

Peer 1 Firewall 1

Peer Roteador 1

Peer Roteador 2 Firewall 2

Peer 2

Figura 11 - Demonstração do protocolo PEP (PANISSON, 2007) 4.1.6 DESENVOLVIMENTO P2P UTILIZANDO JXTA

Para desenvolvimento de aplicações P2P utilizando JXTA, várias linguagens de programação podem ser utilizadas, devido a sua grande portabilidade,

30

onde se destaca a linguagem Java. Esse destaque refere-se ao fato de desta apresentar um melhor aproveitamento e entendimento no tratamento de protocolos e principalmente do seu modo de compilação, que diferente de linguagens (pascal, delphi, fortran, por exemplo) é feito para um bytecode12 e não para código nativo. Esse bytecode é executado por uma máquina virtual, o que torna assim bastante portável. Outro motivo da diferenciação do Java das demais é a facilidade de integração com outras linguagens. Existe também a opção da utilização de várias ferramentas SDK13, levando em consideração a linguagem escolhida, Borland® Developer Studio, Microsoft® Visual Studio e NetBeans são as mais utilizadas, por suportarem várias linguagens. Outros tipos de ferramentas, com estruturas para desenvolvimento do JXTA podem ser encontradas, como é o caso do JXTA Shell, que traz implementados os protocolos, diminuindo assim as configurações a serem feitas.

4.1.6.1 IMPLEMENTAÇÃO DO PEER

A implementação dos peers pode ser feita de diferentes métodos, levando em consideração a aplicação dos mesmos. Essa aplicação influencia nos protocolos a serem desenvolvidos, e esses na complexidade do aplicativo como um todo. Por exemplo, um aplicativo pode armazenar todos os avisos em memória, assim não sendo necessário implementar o Peer Discovery Protocol. Outro exemplo pode ser um conjunto de instruções pré-definidos para encaminhar suas mensagens, não sendo necessário implementar o Peer Endpoint Protocol. Também pode não ser necessário implementar o Peer Information Protocol, caso o peer não precise obter ou fornecer informações de estado a outros peers.

12

Bytecode: refere-se a uma parte de código, um bloco. SDK: Software Development Kit, ou seja, Kit de Desenvolvimento de Software. 31

13

Mesmo podendo deixar algumas configurações sem implementação, seja por já as possuírem, ou por desuso, existem as classes principais, que obrigatoriamente devem ser implementadas: • • Net.jxta.* Net.jxta.impl.*

4.1.6.2 ORGANIZAÇÃO DAS CLASSES

As classes dentro do aplicativo têm funções diferenciadas e todas elas agrupam um ou mais funções. Em geral elas são agrupadas em pacotes, pois tamanho pode ser a quantidade de classes em uso, que torna oneroso à organizálas quando todas “soltas”. No desenvolvimento do P2P JXTA, duas são as classes principais: • net.jxta.*: Utilizada para armazenar interfaces aos protocolos JXTA e aos blocos centrais. Essa é a classe maior do JXTA, a principal e inicial. • net.jxta.impl.*: Utilizada para implementação das interfaces. Ela herda informações da classe principal, e utiliza esse conteúdo para confeccionar as interfaces. Como citado, existem outras classes: • net.jxta.impl.peergroup.boot: Utilizada para indicar ao peer qual grupo ele deve ingressar e inicializar. Em geral tal informação é setada diretamente na camada de “AVISOS” do JXTA, pelo PeerGroup. • net.jxta.platform.Application: Esta classe apesar de não ser obrigatória, torna-se indispensável quando muitas classes são implementadas, pois é responsável pelo acoplamento de todas as outras classes, fazendo com que o aplicativo seja formado.

32

4.1.6.3 EXEMPLO DE IMPLEMENTAÇÃO

Um modelo simples de implementação em linguagem java pode ser visto assim:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

import net.jxta.peergroup.*; // importação do grupo em que o peer está

import net.jxta.impl.id.UUID.*; // importação do nome do peer import net.jxta.impl.id.binaryID.*; // importação do ID do peer public class Hello { // ---------- inicialização das variáveis --------------static PeerGroup netPeerGroup = null; static DigestTool digestTool = new DigestTool(); // ---------- início do bloco principal do projeto ----------public static void main(String args[]) { try { netPeerGroup = PeerGroupFactory.newNetPeerGroup(); System.out.println("Hello from JXTA group" + netPeerGroup. getPeerGroupName() ); System.out.println("GroupID=" + netPeerGroup. getPeerGroupID().toString()); System.out.println("Peer name = " + netPeerGroup.getPeerName()); System.out.println("PeerID="+netPeerGroup.getPeerID().toString()); } catch(Exception e) { e.printStackTrace(); } // exception do try, erro } } // fim do main // fim da classe //inicio da classe local

33

A Figura 12 a seguir ilustra a tela que deve ser exibida ao compilar o código exemplificado. Tanto o código como a imagem foi obtida por (LIMA, 2005).

Figura 12 - Exemplo de retorno das funções executadas (LIMA, 2005)

4.1.6.4 JXTA SHELL

JXTA SHELL é uma interface auxiliar desenvolvida pela comunidade responsável pelo JXTA. Ela traz configurados valores e protocolos úteis ao P2P. Além de ser uma ferramenta OpenSource, ele é facilmente encontrado na Internet, inclusive seus manuais de utilização são disponibilizados pelo fabricante, (PROJETO JXTA, 2007). O JXTA SHELL possui os mesmos comandos que um Shell Unix14, sendo eles: • • • • • Man – Mostra as informações sobre um comando (Manual); Whoami – informa com qual usuário você está acessando; Peers – Lista os peers ativos no grupo; Importfile – Importa arquivo (caso necessário); Mkpipe – Cria um Pipe (túnel).

A função que cada comando citado executa pode variar de acordo com as instancias utilizadas em conjunto.

14

Shell Unix: tela de comando do sistema operacional Unix. 34

4.1.6.5 .NET

A plataforma .Net (.NET, 2003) disponibiliza uma gama de soluções para construção de aplicações P2P. Entretanto, é importante saber como tais funcionalidades podem ser utilizadas, assim facilitando a escolha do modelo adequado a cada aplicação. A plataforma .NET é disponibilizada em alguns moldes de aplicação para P2P (MSDN Magazine, 2001), podendo eles ser: • Web Services: Serviços de download e abertura de registros são mecanismos agregados nesse tipo de modelo. • Windows Forms: Interfaces gráficas mais atraentes para aplicações P2P podem facilmente ser desenvolvidas nesse tipo de modelo, por este manipular diretamente bibliotecas API’s e outras gráficas. • Service Process: Em sistemas distribuídos, onde o processamento paralelo é o recurso mais utilizado pela aplicação P2P, identifica-se mais com este modelo.

4.1.6.6 GROOVE DEVELOPMENT KIT (GDK)

O GDK (Networks, 2008) é uma plataforma de desenvolvimento de aplicações P2P que pode ser utilizada gratuitamente, contudo para distribuição das aplicações é necessário a aquisição das licenças de distribuição. Com seu desenvolvimento em MCOM (Microsof Component Object Model), o GROOVE além de permitir a prototipação rápida de aplicações P2P utilizando linguagens script (VBSCript ou JavaScript), requer que qualquer extensão deva ser implementada utilizando objetos COM, amarrando assim os programas às plataformas Microsoft. Outra característica do Groove é o mesmo utilizar uma abordagem híbrida,
35

permitindo o uso de soluções centralizadas e/ou descentralizadas. GROOVE tem disponível para implementação os seguintes serviços: • • • • Armazenamento de mensagens enviadas para clientes off-line Serviços de interface gráfica Sincronismo de dados (através de gerenciamento) Acesso compartilhado em tempo de execução, tornando assim ferramentas de desenvolvimento comuns a grupos • • Serviço de localização (identificação) de usuários on-line Ferramentas de publicação, que permitem disponibilizar, criar, refinar e testar os itens desenvolvidos.

4.1.7 PADRONIZACAO POR XML

As principais vantagens de JXTA são prover uma comunicação entre peers muito melhor do que os protocolos P2P existentes, permitindo uma grande variedade de serviços, dispositivos e formas de transporte na rede. O emprego de XML auxilia o JXTA, pois provê um formato padrão para a estruturação dos dados e uma melhor compatibilidade entre os meios de transporte. Mas também existem problemas na definição de JXTA, principalmente na chamada dos serviços. Atualmente existem padrões de como deve ser feita à chamada do serviço, entre eles o WSDL15 amplamente utilizado em serviços para internet, mas nenhum desses padrões é usado por JXTA. Ou seja, existe a troca de informações, porém nenhum método padrão de chamada de serviços, (SUNDSTED, 2001). A questão do uso de XML também é polêmica, apesar de ter as vantagens citadas, XML também apresenta desvantagens, sendo o overhead causado pela troca de mensagens XML, dependendo do tipo de aplicação, grande problema,

15

Web Services Description Language: Linguagem de Descrição dos Serviços WEB. 36

principalmente se uma aplicação não tem o objetivo de aproveitar as capacidades de JXTA de incorporar outros serviços P2P, (LUTHER, BUYYA, RANJAN, & VENUGOPAL, 2006).

4.1.8 DESEMPENHO JXTA

Para um desempenho eficiente, JXTA usa as seguintes técnicas, (SUNDSTED, 2001) e (PROJETO JXTA, 2007): • Alguns tipos de mensagens são encaminhados com um número definido de saltos, prevenindo o alcance a todos os peers da rede. • A informação da descoberta de peers na rede é armazenada em Cache, eliminando assim a necessidade de sempre enviar mensagens de descoberta de peers toda vez que a informação é requerida. • Os dados na rede, dependendo de seu tipo, possuem a propriedade do TTL ativa, prevenindo assim o acúmulo de informação, quando o TTL de uma mensagem expira, a mensagem é descartada. • Peers de alta capacidade são usados para reduzir a carga sobre os de baixa capacidade de processamento ou de banda. • O roteamento de mensagens é feito de forma inteligente por cada nó, para assegurar que a melhor rota está sendo tomada em direção ao destino das mensagens. • O protocolo de transporte é selecionado baseado na eficiência da parte da rede usada no momento. Por exemplo, IP broadcast é usado em redes locais, enquanto TCP ou HTTP são usados entre redes LAN para prover a comunicação direta entre os peers.

37

5

CONCLUSÃO

As redes P2P não são inovadoras aos usuários da Internet, nem aos mais novos e nem aos mais antigos. A diferença básica está na facilidade de acesso a esse tipo de redes e aos aplicativos que os agregam, principalmente pela facilidade de usuários residenciais da internet ingressar nas redes P2P. A diversidade de informações disponibilizadas, em sua maioria

gratuitamente, auxilia em muito no crescimento das redes P2P. Este trabalho mostrou algumas particularidades das Redes P2P, bem singularidades de desenvolvimento de aplicações e as plataformas disponíveis para tal. .Net, Groove e JXTA são as mais comumente usadas, onde esta última se sobressai das demais. Esta vantagem se deve as facilidades implementadas em sua arquitetura básica, aos protocolos padrões, métodos de comunicação e distribuição gratuita na internet. Aplicações de arquiteturas puramente descentralizadas em sua maioria foram desenvolvidas em plataforma JXTA e vários são os grupos acadêmicos em estudo de tal assunto, principalmente pelo seu baixo custo de implementação e pela confiabilidade de acesso ao conteúdo, porem deve-se tomar cuidado para não ferir leis de direitos autorais e precaver-se ao disseminar informações sigilosas nas redes P2P, justamente pela facilidade de distribuição e compartilhamento de conteúdo. Com tudo isso, é possível concluir que Redes P2P e, sobretudo a plataforma JXTA é ideal ao desenvolvimento de aplicações P2P.

38

6

REFERÊNCIAS

.NET, M. (Outubro de 2003). Microsoft .NET Homepage. Fonte: http://www.microsoft.com/net/ ANDERSON, D., COBB, J., KORPELA, E., LEBOFSKY, M., &

WERTHIMER, D. (Novembro de 2002). SETI@home: An Experiment in PublicResource Computing. ANSAWARE. (2008). ANSAware. Fonte: http://www.ansa.co.uk APPLIED META COMPUTING. (2000). Legion - An Integrated Architecture for Secure Resource Sharing. Applied Meta Computing Peer-to-Peer Architectural Proposal. ARNAUTH, J. (2008). Japão quer banir redes de troca de ficheiros. Acesso em 2008, disponível em Glob-PT Beta: http://globpt.com/2008/03/23/japao-querbanir-redes-de-troca-de-ficheiros/ ASADZADEH, P., BUYYA, R., KEI, C. L., NAYAR, D., & VEBUGOPAL, N. (2006). Global grids and software toolkits: a study of four grid middleware technologies. In High Performance Computing: Paradigm and Infrastructure , 431458. John Wiley and Sons Inc. ASTIAZARA, M. V. (2008). Classes Reutilizáveis em VB. Fonte: Classes VB: configuracao BALAKRISHNAN, h., KAASHOEK, m., KARGER, d., MORRIS, r., & STOICA, I. (Fevereiro de 2003). Looking up data in p2p systems. 42-43. ACM. CLARKE, I. A. (1999). Distributed Decentralized Information Storage and Retrieval System. Division of Informatics. University of Edinburgh. CLARKE, I., SANDBERG, O., WILEY, B., & HONG, T. (2001). Freenet: A Distributed Anonymous Information Storage and Retrieval System. Designing Privacy Enhancing Technologies: International Workshop on Design Issues in Anonymity and Unobservability. (H. Federrath, Ed.) New York: LNCS 2009.
39

http://classesvb.wikidot.com/framework-de-gerenciamento-de-itens-de-

COULOURIS, G., DOLLIMOREM, J., & KINDBERG, T. (2001). Distributed Systems: concepts and applications. Addisson-Wesley. DHT. (Setembro de 2007). DHT. Fonte:

http://en.wikipedia.org/wiki/Distributed_hash_table FOSTER, I. (2002). The Grid: A new infrastructure for 21st Century Science. Physics Today , 2 (55), pp. 42-47. FRANCESQUINI, E. C. (Junho de 2004). Um estudo sobre sistemas P2P. GOMES, D., PETEK, M., DIVERIO, T., & GEYER, C. (2006). Impacto de Diferentes Algoritmos Peer-to-Peer no Desenvolvimento de um Serviço de Localização de Replicas para Grades. Porto alegre, RS: PPGC–Instituto de Informatica–UFRGS. ISO. (2008). ISO and IEC approve OpenDocument OASIS standard for data interoperability of office applications. Acesso em Setembro de 2008, disponível em http://www.iso.org/iso/pressrelease.htm?refid=Ref1004 KAMIENSKI, C. S. (Julho de 2004). Colaboração na Internet e a Tecnologia Peer-to-Peer. LIMA Jr, & de PAULA, L. A. (2001). Objetos Distribuídos. pp. 145-173. LIMA, A. (2005). P2P, LBS Comunidades Virtuais: Os Ingredientes para Aplicações Inovadoras em Sistemas 3G. UFPE. LUTHER, A., BUYYA, R., RANJAN, R., & VENUGOPAL, S. (2006). Peerto-peer grid computing and .net-based alchemi framework. High Performance Computing: Paradigm and Infrastructure. John Wiley and Sons Inc. MILOJICI, D. S., KALOGERAKI, V., LUKOSE, R., NAGARAJA, K., PRUYNE, J., RICHARD, B., et al. (2003). Peer to peer computing. Palo Alto: HP Laboratories. MSDN Magazine. (Fevereiro de 2001). .NET P2P: Writing Peer-to-Peer Networked Apps with the Microsoft .NET. Networks, G. (2008). Groove Platform Development Kit (GDK). Fonte: http://www.groove.net/devzone/default.cfm?pagename=Platform_GDK
40

ORAM, A. (2001). Peer-to-peer: Harnessing the power of disruptive technologies. O’Relly. PANISSON, A. (2007). Redes P2P e a Plataforma JXTA. UFRGS. PFITZMANN, A., & WAIDNER, M. (1987). Networks without User Observability (Vol. 6). Computer Security 2. PROJETO JXTA. (2007). PROJETO JXTA. Acesso em Julho de 2007, disponível em JXTA: http://jxta.sun.org PROJETO NAPSTER. (2007). PROJETO NAPSTER. Acesso em Julho de 2007, disponível em http://www.napster.com PROJETO SETI@home. (Julho de 2007). PROJETO SETI@home. Fonte: http://setiathome.ssl.berkeley.edu PROJETO USENET. (2007). PROJETO USENET. Acesso em Julho de 2007, disponível em http://www.usenet.net REMOALDO, P. (2008). TCP/IP. Acesso em 10 de Setembro de 2008, disponível em TCP/IP: http://paginas.fe.up.pt/~mgi97018/tcpip.html STOICA, I., MORRIS, R., KARGER, D., KAASHOEK, M. F., & BALAKRISHNAN, H. (2001). Chord: A scalable peer-to-peer lookup service for internet applications. pp. 149-160. SUNDSTED, T. (Março de 2001). The practice of peer-to-peer computing: Introduction and history. TCP/IP, R. 1. (Janeiro de 1991). RFC 1180 - A TCP/IP Tutorial - from the Internet Engineering Task Force. Acesso em 2008, disponível em IETF: http://tools.ietf.org/html/rfc1180 THAIN, D., TANNENBAUM, T., & LIVNY, M. (Abril de 2005). Distributed Computing in Practice: The Condor Experience. Concurrency and Computation: Practice and Experience , 17, pp. 323-356. THEODOLOZ, N. (Fevereiro de 2004). DHT-based routing and discovery in JXTA. School of computer and communication sciences. Computer Science Department. École Polytechnique Fédérale de Lausanne.
41

VERBEKE, J., NADGIR, N., RUETSCH, G., & SHARAPOV, I. (2003). Framework for Peer-to-Peer Distribution Computing in a Heterogeneous,

Decentralized Environment. Palo Alto: Sun Microsystems Inc. YANG, B., & GARCIA-MOLINA, H. (Setembro de 2001). Comparing Hybrid Peer-to-Peer Systems. pp. 561-570.

42