Peer-to-Peer em Redes M

1
Peer-to-Peer em Redes Móveis

• Bruno Oliveira Silvestre
• brunoos_at_inf.puc-rio.br
• PUC-Rio

2
Sumário

• Introdução
• Arquiteturas
• Konark
• iMobile ME
• JXTA for J2ME
• Conclusão

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

4
Konark
5
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

6
Serviço de Descoberta
7
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.

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

9
Estrutura em árvore do Konark
10
Estrutura em árvore do Konark

• Um serviço é identificado utilizando o caminho
  dele até a raiz.
• RootServiceServicesEntretainmentGamesChess
• Para diferenciar dois serviços providos por nós
  diferentes, o Konark utiliza a URL de localização
  do serviço.

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

12
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

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

14
Serviço de Entrega

• ltServicegt
• ltServiceNamegt lt/ServiceNamegt
• ltServiceTypegt lt/ServiceTypegt
• ltKeywordsgt
• ltWordgt lt/Wordgt
• lt/Keywordsgt
• ltPropertiesgt
• ltPropertygt
• ltNamegt lt/Namegt
• ltValuesgt lt/Valuesgt
• lt/Propertygt
• lt/Propertiesgt
• ltFunctionsgt
• ltFunctiongt

• ltNamegt lt/Namegt
• ltParametergt
• ltNamegt lt/Namegt
• ltTypegt lt/Typegt
• lt/Parametergt
• ltReturnParametergt
• ltNamegt lt/Namegt
• ltTypegt lt/Typegt
• lt/ReturnParametergt
• lt/Functiongt
• lt/Functionsgt
• lt/Servicegt

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

16
Serviço de Entrega
Servidor
Cliente
Árvore de Serviços
17
iMobile ME
18
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

19
Arquitetura do iMobile SE
20
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.

21
iMobile ME
22
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.

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

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

25
JXTA for J2ME
26
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.

27
Arquitetura JXTA
28
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.

29
Elementos do JXTA

• Peer
• Peer Group
• Pipe
• Mensagem
• Advertisements
• Segurança
• Protocolos

30
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

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

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

34
Modos de Comunicação
35
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.

36
Formato XML

• lt?xml version"1.0"?gt
• lt!DOCTYPE Messagegt
• ltMessage version"0"gt
• ltElement name"jxtaSourceAddress mime_type
• "text/plain"gt
• tcp//123.456.205.212
• lt/Elementgt
• ltElement name"stuff encoding"base64
  mime_type
• "application/octet-stream"gt
• ............
• lt/Elementgt
• lt/Messagegt

37
Formato Binário

• jxmg 0 01 05 proxy 05
• jxel 2 0 07 request 06 search
• jxel 2 0 04 type 04 Peer
• jxel 2 0 04 attr 04 Name
• jxel 2 0 05 value 06 Waxsys
• jxel 2 0 09 requestId 01 1
• Obs. A mensagem em formato binário não possui
  espaços em branco ou quebras de linhas.

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

39
Advertisements
40
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.).

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

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

43
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

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

45
Exemplo
46
Conclusões
47
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.

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

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

50
Konark iMobile JXTA
Infra-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
51
Perguntas?!?
Obrigado!