Peer-to-Peer em Redes Móveis
Bruno Oliveira Silvestre
[email protected]
PUC-Rio
Sumário
Introdução
Arquiteturas
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
Application
Application
Konark SDP Manager
Konark SDP Manager
Messaging Layer
Messaging Layer
TCP/IP
TCP/IP
Wireless Link Layer
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 Konark
Root
Service
Devices
Information
Personal
Internet
Fax
Shopping
Services
Entertainment
Food
Games
Music
Restaurant
Chess
MP3
Estrutura em árvore do Konark
Um serviço é identificado utilizando o
caminho dele até a raiz.
RootService:Services:Entretainment:Games:Chess
Para 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
Cliente
Servidor
Requisição
Arquivo XML
URL
Árvore de
Serviços
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
PDA
celular
devlets
applets
banco de dados
LDAP
engine
infolets
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
devlets
infolets
console
echo
engine
addr
rpc
rcmd
inbox
outbox
inbox
outbox
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
Peer
Peer Group
Pipe
Mensagem
Advertisements
Segurança
Protocolos
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
jxel
jxel
jxel
jxel
jxel
0
2
2
2
2
2
01 05 proxy 05
0 07 request 06 search
0 04 type 04 Peer
0 04 attr 04 Name
0 05 value 06 Waxsys
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 infraestruturada.
Independência de plataforma.
Konark
iMobile
JXTA
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
Infra-estrutura
Perguntas?!?
Obrigado!