Peer-to-Peer em Redes Móveis

Bruno Oliveira Silvestrebrunoos@inf.puc-rio.br

PUC-Rio

Sumário

IntroduçãoArquiteturas Konark iMobile ME JXTA for J2ME

Conclusão

Introdução

Aumento na adoção de dispositivos móveis: notebooks, celulares, PDAs, etc.Maturidade e difusão das redes sem fio.Surgimento de um novo cenário para as aplicações.Características das aplicações P2P, como dinamismo e autonomia, casaram bem com computação móvel.

Konark

Konark

Proposto na Universidade da Flórida.Oferece suporte para redes parcialmente e complemente ad-hoc.Utiliza um micro servidor HTTP e mensagens em XML (SOAP).Não faz restrição ao protocolo de rede, mas exige o uso de TCP/IP como protocolo de transporte.O Konark é divido em dois componentes principais: Serviço de Descoberta Serviço de Entrega

Serviço de Descoberta

TC P/IP

Messaging Layer

Konark S DP M anager

A pp lica tion

TC P/IP

Messaging Layer

Konark S DP M anager

A pp lica tion

W ire les s L ink La ye r

Serviço de Descoberta

Realiza a descoberta de serviços na rede.A descoberta pode ser iniciada pelo cliente ou pelo servidor.Processo controlado pelo Konark SDP Manager.Utiliza uma estrutura em árvore para armazenar os serviços – tanto os anunciados como os locais.

Estrutura em árvore do Konark

Dois tipos de nós: Nó de classificação Nó de serviço

Por definição, os nós mais próximos da raiz recebem classificações genéricas, e os mais distantes recebem classificações mais específicas.Os nós também são classificados como: todos, genéricos e específicos.

Estrutura em árvore do KonarkRoot

Service

Devices Services

Information Shopping Entertainment

Personal Food Games Music

Internet Fax Restaurant Chess MP3

Estrutura em árvore do Konark

Um serviço é identificado utilizando o caminho dele até a raiz.

RootService:Services:Entretainment:Games:ChessPara diferenciar dois serviços providos por nós diferentes, o Konark utiliza a URL de localização do serviço.

Serviço de Descoberta

Quando o serviço não é se encontra na estrutura interna, a busca é realizada.Um cliente que deseja descobrir um serviço, envia uma mensagem contendo dois campos: Palavra-chave ou Caminho Porta de retorno

Devido aos recursos limitados, o cliente pode empregar filtros nos anúncios.

Serviço de Descoberta

Um servidor pode anunciar seus serviços espontaneamente ou em reposta a uma busca.Pode-se utilizar a classificação todos, genéricos e específicos na pesquisa/anúncio.Um anúncio contém cinco campos: Nome, Caminho, Tipo, URL e TTL

Serviço de Entrega

É responsável por receber as requisições, invocar o método e retornar o resultado.Todos os serviços são compostos de um arquivo de descrição (em XML) e uma parte computacional – por exemplo, uma DLL ou uma classe Java.

Serviço de Entrega<Service> <ServiceName> </ServiceName> <ServiceType> </ServiceType> <Keywords> <Word> </Word> </Keywords> <Properties> <Property> <Name> </Name> <Values> </Values> </Property> </Properties> <Functions> <Function>

<Name> </Name> <Parameter> <Name> </Name> <Type> </Type> </Parameter> <ReturnParameter> <Name> </Name> <Type> </Type> </ReturnParameter> </Function> </Functions></Service>

Serviço de Entrega

Para um nó requisitar um serviço, primeiro ele deve obter o arquivo XML de descrição contendo os parâmetros necessários para a realização da requisição.

Serviço de Entrega

URL

Servidor

Arquivo XML

Cliente

Árvore de Serviços

Requisição

iMobile ME

iMobile

Foi inicialmente desenvolvido para servir como proxy para os dispositivos sem fio – iMobile SE (Standard Edition).Executava em servidor na rede infra-estruturada.O iMobile SE é baseado em três componentes principais: devlets applets infolets

Arquitetura do iMobile SE

apple ts

in foletsdevlets eng ine

ce lu la rP D Abanco de dados

LD A P

iMobile Micro Edition

Para dar suporte a aplicações P2P, o iMobile SE foi portado para os dispositivos móveis.Foram feitas modificações na arquitetura e a principal mudança foi a retirada dos applets.Também foi acrescentado caixas de mensagens.Sem os applets o iMobile ME possibilita apenas o compartilhamento de dados.

iMobile ME

engineconsole echo

rpc

addr

rcm d

de v le ts in fo le ts

outbox o utb oxinbo x inbo x

iMobile ME

Não há padronização para os x-lets, deixando o desenvolvedor livre para implementar qualquer tipo de modelo ou protocolo – se suportado.Três x-lets desempenham papeis importantes na arquitetura: console (devlet): permite que o usuário interaja com o

sistema. rcmd (devlet): responsável por receber e tratar as

requisições vindas de outros dispositivos. rpc (infolet): responsável por interagir com os rcmds para

obter informações de outros dispositivos.

Caixas de Mensagem

O iMobile ME utiliza caixas de mensagens para garantir uma sessão de comunicação mais confiável, evitando problemas de desconexão ou variação de largura de banda.O usuário é responsável por iniciar o processo de sincronização.Caso o iMobile SE não localize o destinatário da mensagem na hora do roteamento, a mensagem é armazenada e será entregue quando o usuário se conectar.

Descoberta de Recursos

iMobile ME não suporta redes ad-hoc.Todo o processo de descoberta de recursos disponíveis e roteamento das mensagens é realizado pelo iMobile SE.Os nós móveis devem manter seus dados atualizados no iMobile SE.

JXTA for J2ME

JXTA

Arquitetura aberta para desenvolvimento de aplicações P2P.Criada pela Sun Microsystems, e, hoje, mantida por colaboradores de todo o mundo.Tem como ideais: Interoperabilidade. Independência de plataforma. Ubiquidade.

Arquitetura JXTA

Arquitetura JXTA

A arquitetura do JXTA pode ser dividida em três camada: Core: encapsula as primitivas essenciais

(descoberta de grupos e nós, transporte, etc.) Service: acomoda serviços adicionais

comumente utilizado ou desejáveis pelas aplicações (busca e indexação, diretórios, etc.)

Application: aplicações específicas que utilizam os serviços da rede.

Elementos do JXTA

PeerPeer GroupPipeMensagemAdvertisementsSegurançaProtocolos

Peer

Qualquer dispositivo que faça parte da rede JXTA.Cada nó opera independente e assincronamente dos outros.Os nós publicas os seus peer endpoints, por onde eles recebem conexões.Classificados como: Minimal edge peer Full-feature edge peer Rendezvous peer Relay peer

Peer

Peer Group

Os nós podem se auto-organizar em grupos, estabelecendo políticas internas.Os motivos que levam a criação de grupo varia.

Ex.: Definição de escopo computacional, comunicação segura e monitoramento.Grupos podem ser usados para prover serviços com tolerância a falha – se um membro ficar indisponível, outro pode tratar a requisição.

Pipes

São canais de comunicação assíncronos e unidirecionais.Não há nenhuma restrição sobre o tipo de dado que trafega por um pipe.Os pipes são dividos em pipe de entrada e de saída, provendo dois modos de comunicação: Ponto-a-Ponto: conecta um pipe de saída a um pipe de

entrada Propagação: conecta um pipe de saída a vários pipes de

entrada.

Modos de Comunicação

Mensagem

Uma mensagem pode ser representada em formato binário ou em formato XML.Elas são formadas de uma seqüência de elementos.Os elemento possuem um nome, um tipo e conteúdo.

Formato XML<?xml version="1.0"?><!DOCTYPE Message><Message version="0"> <Element name="jxta:SourceAddress“ mime_type="text/plain"> tcp://123.456.205.212 </Element> <Element name="stuff“ encoding="base64“ mime_type="application/octet-stream"> ............ </Element></Message>

Formato Binário

jxmg 0 01 05 proxy 05jxel 2 0 07 request 06 searchjxel 2 0 04 type 04 Peerjxel 2 0 04 attr 04 Namejxel 2 0 05 value 06 Waxsysjxel 2 0 09 requestId 01 1

Obs.: A mensagem em formato binário não possui espaços em branco ou quebras de linhas.

Advertisements

São os anúncios utilizados para descoberta de serviços, nós, grupos e pipes.São representados por documentos XMLs e também utilizam TTL para manutenção da arquitetura.Na implementação para J2SE, é provido pelos rendezvous peers um serviço de indexação para otimizar a busca.

Advertisements

Segurança

Os desenvolvedores do JXTA querem que os protocolos de comunicação sejam compatíveis com os protocolos de transporte seguro já difundidos (SSL, TLS, etc.).O uso de XML dá suporte a essa compatibilidade (certificado, digests, etc.).

Protocolos

A arquitetura JXTA já fornece um conjunto de protocolos padrões, que são divididos em duas categorias: Core Specification: protocolos obrigatórios que

devem ser implementados. Standard Service: protocolos opcionais, mas

que facilitam os desenvolvimento.

Java Micro Edition

J2ME é uma tecnologia Java destinada à pequenos dispositivos, como pagers, celulares, PDAs, set-top boxes, etc.Fornece dois tipos de configurações: CDC e CDLC.Fornece diversos profiles: MIDP, FP, PP, etc.

JXTA for J2ME

O projeto visa: Manter compatibilidade com o JXTA rodando

em desktops Prover infra-estrutura para desenvolvimento de

facilitado de aplicações P2P Ser compatível com CLDC e MIDP Ser pequeno o suficiente para rodar em

aparelhos celulares

Adaptações na Arquitetura

Devido à limitações, tanto dos equipamentos quanto da tecnologia Java, os desenvolvedores optaram por utilizar os relay peers como proxies para os dispositivos móveis.Eles provêem a interoperabilidade com a rede infra-estruturada, filtram os dados e fazem a conversão entre XML e binário.As APIs e serviços também foram reduzidos para se acomodar às limitações.Não fornece suporte à segurança.

Exemplo

Conclusões

Konark

Redes parcialmente ou totalmente ad-hoc.Utiliza padrões bem disseminados – HTTP e SOAP. Mas pode necessitar de mais recursos computacionais.Estrutura de armazenamento em árvore com classificação auxilia na busca.Utilização de propriedades nos serviços.Não há suporte a segurança.

iMobile ME

Utiliza a rede infra-estruturada (iMobile SE).Arquitetura centralizada.Suporte ao compartilhamento de recursos.Não há padronização, o que torna a arquitetura flexível, mas não interoperável.Suporte a desconexão através das caixas de mensagens.

JXTA for J2ME

Utiliza os relay peers para a execução de tarefas, como busca e criação de pipes.Não permite a criação de redes ad-hoc.Ubiquidade.Interoperabilidade com a rede infra-estruturada.Independência de plataforma.

Konark iMobile JXTAInfra-estrutura Não Sim Sim

Protocolo Transporte

HTTP sobre TCP/IP

Independente Independente

Protocolo de Rede Independente - Independente

Tipo de Mensagem XML - XML ou Binária

Suporte Desconexão

Não Sim Não

Protocolos Padronizados

Sim Não Sim

Descoberta de Recursos

Anúncio/Pesquisa

Via iMobile SE Anúncio/Pesquisa

Centralizado Não Sim Não*

Demanda de Recursos

Alto Variável Baixo

Perguntas?!?

Obrigado!