Peer-to-Peer em Redes Móveis Bruno Oliveira Silvestre PUC-Rio.

Apresentação em tema: "Peer-to-Peer em Redes Móveis Bruno Oliveira Silvestre PUC-Rio."— Transcrição da apresentação:

1 Peer-to-Peer em Redes Móveis Bruno Oliveira Silvestre brunoos@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 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 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 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.

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

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 URL Servidor Arquivo XML Cliente Árvore de Serviços Requisição

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 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 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 <Element name="jxta:SourceAddress“ mime_type= "text/plain"> tcp://123.456.205.212 <Element name="stuff“ encoding="base64“ mime_type= "application/octet-stream">............

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 KonarkiMobileJXTA Infra-estruturaNãoSim Protocolo Transporte HTTP sobre TCP/IP Independente Protocolo de RedeIndependente- Tipo de MensagemXML-XML ou Binária Suporte Desconexão NãoSimNão Protocolos Padronizados SimNãoSim Descoberta de Recursos Anúncio/ Pesquisa Via iMobile SEAnúncio/ Pesquisa CentralizadoNãoSimNão* Demanda de Recursos AltoVariávelBaixo

51 Perguntas?!? Obrigado!