LogMiddle: Um Middleware P2P para Replicação de Dados em Redes Móveis Ad Hoc

Transcrição

1 LogMiddle: Um Middleware P2P para Replicação de Dados em Redes Móveis Ad Hoc Fabricio A. Diógenes, Nabor C. Mendonça Mestrado de Informática Aplicada (MIA) Universidade de Fortaleza (Unifor) Fortaleza CE Brasil Abstract. Advances in personal device technologies, together with the wide adoption of wireless P2P networking technologies, have geared the use of the P2P paradigm in the mobile computing area. An interesting and challenging environment where P2P technologies could be employed is represented by mobile ad hoc networks (MANETs). However, many of the issues dealt with by classical wired P2P systems are not applicable in such environments. Developers have to deal with a new set of problems caused by mobility, such as low bandwidth and loss of connectivity. During disconnections, users typically update local replicas of shared data, possibly generated by peers. Possible inconsistencies need to be reconciled upon reconnection. To support building mobile applications that share data over ad-hoc networks, this paper presents LogMiddle, a P2P middleware for mobile computing. LogMiddle belongs to class of solutions that focuses on replication as the key mechanism for sharing data over MANETs, and uses the concept of a single data log to reduce replica management and storage costs in each device. Resumo. Avanços nas tecnologias de dispositivos pessoais e a adoção em massa das tecnologias de redes sem fio ponto a ponto, têm direcionado o uso do paradigma P2P na área da computação móvel. Um interessante e desafiador ambiente onde a tecnologia P2P pode ser aplicada é representado pelas redes móveis ad hoc (MANETs). Contudo muitas questões tratadas pelos sistemas P2P clássicos não são aplicáveis nesse ambiente. Desenvolvedores têm que tratar com um novo conjunto de problemas causados pela mobilidade, como largura de banda limitada e perda de conectividade. Durante os períodos de desconexão, os usuários tipicamente atualizam réplicas locais de dados compartilhados, possivelmente gerados pelos nós (peers). Possíveis inconsistências devem ser reconciliadas no momento da reconexão. Para dar suporte à construção de aplicações móveis que compartilham dados sobre redes ad hoc, este artigo apresenta LogMiddle, um middleware P2P para computação móvel. O LogMiddle pertence a uma classe de soluções com foco na replicação como mecanismo para compartilhamento de dados em ambientes de MANETs, e utiliza o conceito de log único de dados para reduzir os custos de gerência e armazenamento das réplicas de cada dispositivo. 1. Introdução Os últimos anos têm testemunhado uma drástica redução do tamanho dos computadores pessoais. Essa redução tem revolucionado a forma com que nós usamos a computação e influenciado diretamente no nosso cotidiano. O avanço da tecnologia de dispositivos pessoais, principalmente celulares de terceira geração, possibilitou a disponibilidade de diversas plataformas de software, desde protocolos de comunicação ponto a ponto,

2 como Bluetooth, até linguagens de última geração, como Java. A combinação dessas tecnologias aliada à característica móvel desses dispositivos vem criando um cenário para uma crescente demanda por aplicações distribuídas que enfocam a colaboração ponto a ponto e que utilizam as redes móveis ad hoc (ou MANETs) [Giordano and Urpi 2004] como infra-estrutura. Em sistemas distribuídos fixos, a complexidade envolvida nos aspectos de distribuição é em geral transparente aos desenvolvedores por meio das tecnologias de middleware, que elevam o nível de abstração. Tecnologias de middleware existentes, como RPC e objetos distribuídos, escondem a complexidade e heterogeneidade dos programadores de aplicação, e assim os apóiam na construção e manutenção das aplicações de forma eficaz. Contudo, estas tecnologias foram construídas para redes fixas e são inadequadas para uma configuração móvel [Mascolo et al. 2002] [Capra et al. 2001]. Em particular, primitivas de interação suportadas por esses middlewares, como chamadas de procedimento remoto, requisições a objetos e invocações de método remoto, assumem um ambiente estável de comunicação com alta largura de banda e conectividade constante. Em sistemas móveis, ao invés, desconexões e velocidades de transmissão variáveis são características normais nesse ambiente. Em vista das considerações acima, acreditamos que sistemas de middleware para computação móvel precisam prover diferentes primitivas de interação para acomodar a possibilidade de que componentes móveis fiquem sem comunicação. Por exemplo, muitas aplicações para PDA copiam agendas, listas de tarefas, e registros de endereço, de um desktop para a memória local deles, de forma que eles possam ter acesso independente. Em geral, aplicações móveis devem poder reproduzir informação para ter acesso off-line sobre os dados. A replicação gera a necessidade de haver uma sincronização dos dados quando uma conexão é restabelecida. Esta necessidade não é abordada propriamente por middlewares existentes. O princípio de transparência, comumente usado, impede que o middleware explore o conhecimento que só a aplicação tem, tal como a identificação dos dados que devem ser replicados e a política de reconciliação que deve ser aplicada. A computação P2P [Schollmeier 2001] tem se tornado um paradigma comum para muitas aplicações distribuídas, permitindo um compartilhamento de recursos e dados através de uma comunicação direta entre os nós. Sistemas P2P têm sido inicialmente desenvolvidos para redes com uma infra-estrutura fixa de comunicação, onde é formada uma rede virtual (de overlay) sobre a rede de dados subjacente (IP, no caso da Internet) dos pontos conectados [Oram 2001]. Contudo, esse rico paradigma pode ser naturalmente estendido para uma configuração móvel, onde dispositivos sem fio podem compartilhar informações diretamente entre eles. Entre as soluções propostas que utilizam o paradigma P2P em ambientes móveis, destacamos o projeto Xmiddle [Mascolo et al. 2001], uma das soluções de middleware ponto a ponto pioneira em mecanismos de replicação e reconciliação de dados em redes móveis ad hoc puras (sem o apoio de uma infra-estrutura fixa). A solução aborda características necessárias nesse ambiente, como tratamento de desconexões e percepção de contexto (context-awareness), contudo peca na arquitetura de gerência de réplicas, baseada na manipulação de documentos XML DOM, o que gera um alto custo de armazenamento de dados em memória.

3 Nesse artigo nós apresentamos o LogMiddle, um middleware P2P para computação móvel, que pertence a uma classe de soluções com foco na replicação como mecanismo para compartilhamento de dados em ambiente de MANETs. O LogMiddle foi inspirado no projeto do Xmiddle herdando mecanismos relacionados ao tratamento de inconsistências entre as réplicas, contudo o alto custo da solução de replicação nos motivou a propor uma nova e mais eficiente arquitetura de gerenciamento das réplicas, visando reduzir os custos de armazenamento e processamento, viabilizando também o uso da solução em dispositivos móveis com recursos limitados (PDAs, celulares etc). A idéia chave da nossa abordagem é utilizar o conceito de log único de armazenamento, onde são inseridos os dados e metadados utilizados nos processos de versionamento e reconciliação das réplicas de cada dispositivo. O resto do artigo está organizado como segue. Na seção 2, apresentamos uma visão geral do LogMiddle. Na seção 3, descrevemos a arquitetura de replicação, detalhando os mecanismos de armazenamento, controle de versão e reconciliação. Na seção 4, apresentamos outros trabalhos relacionados. Concluímos o artigo na seção Visão Geral do LogMiddle O LogMiddle é um middleware para computação móvel que permite o compartilhamento ponto a ponto de dados entre dispositivos sobre redes móveis ad hoc puras (sem a presença de qualquer infra-estrutura de rede fixa). Para realizar o compartilhamento dos dados, o LogMiddle utiliza a estratégia da replicação otimista, que consiste em manter múltiplas cópias de dados, uma em cada dispositivos da rede, permitindo operações offline nos dados locais, baseando-se no princípio que eventuais conflitos podem ser resolvidos oportunamente durante o sincronismo das réplicas [Demers et al. 1987]. Um processo de reconciliação é responsável por disseminar as alterações nas réplicas locais para outras réplicas, que as repassam de forma epidêmica para todo o sistema, conduzindo-o para uma eventual convergência dos dados. 2.1 Elementos de Arquitetura A arquitetura do LogMiddle é típica de um sistema de middleware, ou seja, uma camada localizada entre a aplicação e os protocolos de rede, implementando as camadas de sessão e apresentação do modelo ISO/OSI. O protótipo do LogMiddle foi implementado na plataforma J2ME, da Sun, e utiliza o Bluetooth como protocolo de comunicação em virtude da sua natureza ponto a ponto. A Figura 1 apresenta a estrutura de software do LogMiddle. Os principais módulos do LogMiddle são: Middleware Façade. As aplicações somente têm acesso às funcionalidades do middleware através desse componente, criando assim uma abstração aos desenvolvedores do restante dos módulos. Isso é uma característica importante para manter uma visão unificada e de alto nível do middleware. DataSet e Log Manager. São módulos responsáveis pelo armazenamento de dados. O módulo DataSet provê às aplicações primitivas para manipulação dos dados, que são mapeados em entradas no log através do módulo Log Manager.

4 Reconciliation Manager. Responsável pela gerência dos mecanismos de atualização e disseminação das réplicas e pelo protocolo de reconciliação. Session Manager. Gerencia as redes individuais ad hoc formadas pelos peers remotos conectados, e é responsável pelo processo de descoberta de novos nós. Communication Manager. Responsável pela comunicação com as camadas de rede abaixo do middleware. Aplicação Aplicação LogMiddle Storage Management Middleware Façade DataSet Log Manager Reconciliation Manager Núcleo do LogMiddle Session Manager Local Peer Manager Remote Peer manager Communication Manager J2ME Comunicação Sem Fio MIDP JSR 82 Java Libraries (Optional Packs) KVM (CLDC 1.0 ) Pilha Bluetooth Figura 1. Arquitetura de software do LogMiddle Conexões e Desconexões Em geral, o conceito de conexão em sistemas tradicionais ou até mesmo em sistemas nômades, que são compostos por dispositivos móveis que utilizam o suporte de uma infra-estrutura de rede fixa para se comunicarem, está relacionado à comunicação física dos dispositivos com os equipamentos de controle de rede, seja de forma cabeada ou sem fio. No caso de uma formação móvel ad hoc, o controle de conexão ou desconexão deve ser distribuído e tratado por cada dispositivo. O LogMiddle implementa essa característica da seguinte forma: cada aplicação LogMiddle gera e controla uma rede individual que inicialmente considera apenas seu próprio dispositivo como nó dela mesma. À medida que outros dispositivos remotos iniciam mecanismos de descoberta de nós dentro do raio de alcance do sinal, pedidos de conexão são automaticamente disparados ao dispositivo local. Da mesma forma e concomitantemente, o dispositivo local gera requisições de conexão aos dispositivos remotos de forma inversa. Assim, para o LogMiddle, a formação de redes ad hoc é gerenciada individualmente por cada dispositivo, baseada nos equipamentos que solicitaram conexão. O número de redes ad hoc formadas e do número de nós participante de cada uma, está relacionado à visibilidade que cada dispositivo tem dos demais. A Figura 2 apresenta as listas de dispositivos conectados nos nós M X, M Y e M Z.

5 No LogMiddle, as conexões são simétricas mas não são transitivas, ou seja, por um dispositivo X estar conectado com os dispositivos Y e Z não significa que Y e Z estejam necessariamente conectados. Na Figura 2 mostramos um arranjo onde o dispositivo móvel M X está conectado somente ao dispositivo M Y, enquanto que M Y está conectado também as formações ad hoc de M W e M Z. Lista de dispositivos da rede virtual gerenciada por M Z M Z M Y M W M K M Z Lista de dispositivos da rede virtual gerenciada por M Y M Y M Z M W M X Lista de dispositivos da rede virtual gerenciada por M X M X M Y M K M W M Y M X Figura 2. Representação das redes ad hoc formadas de forma aleatória pelos dispositivos M X, M Y e M Z e suas respectivas listas de nós conectados Aspectos de Rede A atual versão do LogMiddle utiliza o RFCOMM [Bluetooth 1999] da pilha Bluetooth para as comunicações entre dois dispositivos. O RFCOMM é um protocolo de transporte simples e leve que roda sobre o protocolo L2CAP e suporta até sessenta conexões simultâneas entre dois dispositivos Bluetooth. É importante ressaltar que o LogMiddle utiliza as conexões fim-a-fim do protocolo RFCOMM somente para a troca de pacotes durante o processo de reconciliação das réplicas. Isso significa que as conexões gerenciadas pelo LogMiddle (nível de aplicação) não estão relacionadas diretamente com as conexões estabelecidas nas camadas mais baixas, evitando assim uma inundação na rede (flooding) com pacotes de controle. Além disso, essa característica permite que, enquanto a aplicação não solicita uma comunicação direta, um dispositivo remoto possa sair temporariamente do alcance do sinal do nó local sem ser desconectado da rede ad hoc. O LogMiddle pode executar sobre outras tecnologias de comunicação, como por exemplo, o TCP/IP sobre WiFi. Para isso, seu framework de implementação disponibiliza uma API que permite a implementação de protocolos de comunicação diferentes dos que foram desenvolvidos para o protótipo atual. 3. Esquema de Replicação O LogMiddle utiliza o conceito de log como estrutura básica para sua arquitetura de gerência das réplicas, similar à utilizada no trabalho de Hupfeld [Hupfeld 2004] para bando de dados distribuído. O aspecto fundamental da eficiência da nossa abordagem é utilizar o conceito de log único de armazenamento, otimizando o espaço útil de dados manipulado. Além disso, exploramos a estrutura em log para embutir no armazenamento dos dados os metadados utilizados no processo de versionamento e reconciliação das

6 réplicas de cada dispositivo do sistema. Outro aspecto importante é que estes metadados são utilizados pelo middleware não somente para a gerência da réplica local, mas também para o controle das réplicas de todos os dispositivos remotos que se conectaram ao dispositivo local Modelo de dados No modelo de dados utilizado pelo LogMiddle, o componente DataSet gerencia o estado corrente do conjunto de dados manipulado localmente pela aplicação. O conjunto de dados é composto por múltiplas tuplas no formato (chave, valores), onde a chave é única para cada item de dado, permitindo distintos valores para cada chave. O estado atual do conjunto de dados pode ser alterado pelas operações disponibilizadas no middleware ou em virtude do processo de reconciliação. Existem três operações básicas: add (chave, valor), remove (chave) e set (chave, valor). Valores distintos podem ser associados apenas uma vez para uma determinada chave, portanto essas operações são idempotentes. Isto significa que adicionar, remover e substituir o mesmo valor mais de uma vez não gera nenhum efeito adicional, isto é, nenhuma tupla a mais será registrada. Alterar um registro é conceitualmente realizado através da operação set, que remove a versão antiga do registro e adiciona uma nova. As operações add e remove são utilizadas para criar e remover registros, respectivamente Registros das Operações no Log Quando a aplicação realiza operações sobre o conjunto de dados corrente, o LogMiddle gera, em paralelo, registros no log de armazenamento. O log é composto por um conjunto ordenado de entradas no formato: ( + /, chave, valor), indicando que um certo valor foi adicionado ( + ) ou removido ( ). Essas entradas no log agem como uma operação de diferença para o estado anterior do conjunto de dados. Apenas as operações que têm efeito no estado atual dos dados são registradas no log. Em virtude da propriedade de idempotência, operações tais como, add com um valor que já está presente, ou um remove de um valor não existente, não alteram o conjunto de dados e portanto não resultam em uma entrada adicional no log. Uma vez que o log só registra alterações efetivas sobre o conjunto de dados, uma operação set é registrada com uma entrada (remove) no log para remover o antigo valor, seguido de uma entrada + (add) no log para o novo valor. Conceitualmente, poderíamos tratar o conjunto de dados, gerenciados pelo DataSet, e os registros no log separadamente. De fato, o log único completo já contém o estado corrente do conjunto de dados embutido nele. Portanto, manter em separado o armazenamento dos dados da aplicação seria armazenar informações redundantes. Utilizando um armazenamento totalmente estruturado em log, que funde o estado corrente dos dados e o log, nós removemos essa redundância na implementação. A Figura 3 apresenta os registros no log gerados por operações no conjunto de dados através de uma aplicação exemplo do LogMiddle para controle compartilhado de uma cesta de compras. Pela figura, notamos que as tuplas do DataSet são de fato implementadas como referências para as entradas no log.

7 Aplicação Móvel LogMiddle Detalhe da aplicação Operações no Log ( +, laranja, 20, 0.80 ) ( +, maça, 10, 0.95 ) ( +, tomate, 7, 1.00 ) (, maça, 20, 0.95 ) (, laranja, 20, 0.80 ) ( +, tangerina, 15, 1.10 ) DataSet 1 <referência> 2 <referência> Figura 3. Estrutura do armazenamento dos dados do LogMiddle Mecanismo de Versionamento Multi-Réplicas As entradas do log são organizadas dentro de regiões. Uma região contém todas as atualizações realizadas no conjunto de dados de um dispositivo entre duas reconciliações. Todas as entradas de uma região compartilham um identificador do dispositivo e um número lógico de versão. O início de uma região é registrado no log através de um marcador no formato: (device-id, logical version), onde device-id é um inteiro utilizado como identificador do dispositivo, e logical version é número seqüencial representando a versão da região em relação à quantidade de reconciliações realizadas pelo dispositivo, gerada no momento da criação da região. As regiões são as unidades de transferência de dados no momento do processo de reconciliação. Elas são criadas no dispositivo local através de alterações locais que são registradas ao final do log ou através de regiões remotas recebidas de outros dispositivos durante a reconciliação. Para iniciar uma reconciliação, uma região deve ser fechada antes de ser enviada a outro dispositivo, de forma que todas aquelas entradas sejam associadas à versão da região. Depois do sincronismo, uma nova região associada ao dispositivo local é criada, e um novo marcador de início de região é gerado. Com a reconciliação, algumas regiões são transmitidas às outras réplicas que adicionam as regiões recebidas ao log. Portanto, o log único é composto por regiões criadas localmente e regiões criadas remotamente por outros dispositivos. O log completo de uma réplica representa a diferença entre o estado corrente e o estado inicial (vazio) do conjunto de dados da réplica, ou seja, ele contém o estado atual (corrente) do conjunto de dados no respectivo dispositivo. O estado corrente é representado em cada dispositivo por um vetor de estado lógico, que contém as versões mais recentes das regiões localmente conhecidas de cada dispositivo remoto. Esse vetor de estado é indexado pelo identificador do dispositivo utilizado no marcador de início das suas regiões. Normalmente, o middleware armazena o vetor de estado na memória para uso em tempo de execução, considerando o pouco espaço ocupado por ele, contudo ele pode ser reconstruído percorrendo o log em ordem cronológica, e identificando e atualizando o vetor de estado com as versões mais recentes das regiões

8 de cada dispositivo conhecido localmente. A Figura 4 mostra o exemplo dos logs dos dispositivos 0 e 1 e seus respectivos vetores de estado. Log com regiões no dispositivo 0 Marcador de início dessa região ( =, 1, 1 ) Versões das regiões mais recentes. ID do Dispositivo Versão da região ID dos dispositivos reconciliados Vetor de estado Log com regiões no dispositivo 1 ID do Dispositivo Versão da região Figura 4. Regiões marcadas nos logs dos dispositivos 0 e 1 e seus vetores de estado Processo de Reconciliação Vetor de estado Essencialmente, o processo de reconciliação visa obter uma versão consistente entre as réplicas de dois dispositivos que se conectaram e realizaram operações off-line. Ele é baseado no uso do conteúdo do log, cujas informações são utilizadas pelo protocolo de reconciliação para trazer um dispositivo remoto a um estado atualizado do seu conjunto de dados em relação às mudanças ocorridas localmente e vice-versa. Destacamos dois aspectos positivos no projeto do protocolo de reconciliação: o primeiro é a preocupação em minimizar a transferência de dados entre os dispositivos, transmitindo apenas as diferenças entre eles (mínimo necessário); a segunda é minimizar o processamento na identificação dessas diferenças. Para isso, utilizamos o vetor de estado dos dispositivos para descobrir, dentre as regiões conhecidas localmente, quais são desconhecidas pelo dispositivo remoto. A reconciliação ocorre em par entre os dispositivos, onde um deles assume o papel de cliente e o outro de servidor. O protocolo de reconciliação consiste em cinco etapas, descritas abaixo. A Figura 5 ilustra as etapas baseando-se no estado corrente dos dispositivos da figura Com o objetivo de minimizar a quantidade de dados para sua atualização o cliente envia no passo 1 o vetor de estado, representando o seu atual estado (Fig. 5, passo1); 2. Usando o vetor de estado recebido, o servidor no passo 2 compara cada entrada do seu vetor com o do cliente. Dessa forma, se uma determinada entrada do seu vetor de estado for maior que a do cliente, ele identifica o intervalo cronológico das regiões que ele deve enviar ao cliente, iniciando com a versão da região seguinte a do cliente, até a atual versão do servidor (Fig. 5, passo 2); 3. O terceiro passo é montar o intervalo das regiões definidas no passo anterior, seguindo a seqüência cronológica de criação e enviar ao cliente. Dessa forma,

9 após aplicar no seu log essas regiões enviadas o cliente estará atualizado. Contudo, para haver o sincronismo entre as réplicas o servidor necessitará ser atualizado também. Assim, como se ele executasse o passo 1 no sentido contrário, o servidor envia junto com as regiões o seu vetor de estado (Fig. 5, passo 3); 4. O quarto passo seria a execução do passo 2 no sentido contrário, isto é, o cliente identifica o intervalo das regiões desconhecidas pelo servidor (Fig. 5, passo 4); 5. O quinto passo seria montar a seqüência de regiões do intervalo e enviar para o servidor (Fig. 5, passo 5); 6. O sexto passo seria adicionar as regiões trocadas no log local de cada dispositivos alcançando um sincronismo entre os logs de ambos. 1 Dispositivo 0 (Cliente) Cli=( 3, 1, 1 ) Envia vetor de estado 2 Identifica regiões 4 no log desconhecidas pelo dispositivo 1 in local 5 Envia regiões em ordem cronológica Peers: Peers: Srv=( 1, 3, 2 ) 3 Dispositivo 1 (Servidor) Identifica regiões no log desconhecidas pelo dispositivo 1 Envia regiões em ordem cronológica junto com o vetor de estado local Figura 5. Etapas do protocolo de reconciliação em par Atualização Epidêmica das Réplicas A atualização do sistema é realizada de forma epidêmica, ou seja, cada dispositivo executa o processo de reconciliação em par com os dispositivos conectados, e esses por sua vez, repassam as atualizações da mesma forma para os dispositivos próximos a ele, e assim por diante. Assim, gradativamente as réplicas vão acompanhando as atualizações otimistas realizadas localmente em cada dispositivo da rede móvel ad hoc. Entretanto, é importante ressaltar que, devido a mobilidade dos dispositivos, a atualização do sistema vai depender da topologia. O processo de disseminação epidêmica é ativado individualmente por cada dispositivo nas seguintes situações: Quando o dispositivo realiza alterações no seu conjunto de dados. Nesse caso, o processo só é iniciado em par com cada dispositivo vizinho em uma das duas situações (a que ocorre primeiro): após um determinado número de operações sobre o conjunto de dados, ou após um período decorrido da última alteração. A definição do período e da quantidade é definida pelo middleware. O objetivo é evitar uma atualização automática do sistema a cada atualização do conjunto de dados, o que poderia reduzir o desempenho da rede; Quando o dispositivo recebe as atualizações de outro dispositivo que solicitou a reconciliação;

10 Quando um dispositivo reconecta a rede após um período desconectado. Independente se ele realizou operações off-line ou não, o dispositivo solicita a reconciliação com seus vizinhos para manter-se atualizado. No caso, se não tiver ocorrido alterações, o processo limita-se apenas a troca de vetores de estado. A Figura 6 ilustra um exemplo de uma atualização epidêmica em um sistema formado por seis dispositivos móveis, onde M B e M E formam uma rede móvel ad hoc entre eles e ao mesmo tempo funcionam como uma espécie de ponte para atualização de outros dispositivos que, em virtude da mobilidade, se distanciaram. Na representação 6(a) da figura, os dispositivos M C e M D iniciam em paralelo uma reconciliação com os dispositivos vizinhos, que da mesma forma ao final também disparam solicitações de reconciliação com seus respectivos vizinhos. Na representação 6(b) da figura, os dispositivos M B e M E identificam diferenças entre seus estados, conseqüência do processo anterior, gerando uma reconciliação entre os dois. Como resultado disso, na representação 6(c), os mesmos dispositivos propagam as alterações recebidas na última reconciliação alcançando um sincronismo das réplicas do sistema. a) M D M A M B M E M C M F b) M D M A M C M B M E M F c) M D M A M C M B M E M F Figura 6. Representação de uma atualização epidêmica do sistema: a) reconciliação ativada pelos dispositivos M C e M D ; b) reconciliação decorrente da anterior (a) ativada pelos dispositivos M B e M E ; c) Reconciliação decorrente da anterior (b) ativada novamente pelos dispositivos M B e M E Tratamento de Conflitos Tratar conflitos envolve detectá-los e resolvê-los. Entretanto, é importante ressaltar que detecção de conflitos é um problema sintático, enquanto que resolução de conflitos é uma questão tipicamente semântica. Os nós podem até comparar suas estruturas de dados, mas não podem resolver conflitos sem saber o que elas representam. A participação da aplicação (application-aware) é fundamental na resolução dos possíveis conflitos. Utilizando o mesmo modelo que o Xmiddle, o LogMiddle usa reflexão e

11 metadados para permitir que o middleware possa decidir transparentemente como se comportar em diferentes situações de conflito. A política de resolução é definida pelo programador da aplicação em conjunto com a definição do modelo de dados em um documento XML. 4. Trabalhos Relacionados Nas seções anteriores, nós descrevemos o LogMiddle e sua solução para replicação de dados em rede P2P móveis. Abaixo comparamos o LogMiddle com algumas soluções para computação P2P em ambientes móveis. Mobile Chedar [Kotilainen et al. 2005] é um middleware para aplicações moveis P2P. Ele é uma extensão da rede P2P Chedar, permitindo que dispositivos moveis acessem a rede Chedar e possam se comunicar com outros nós (peers) Chedar móveis. Ao contrário do LogMiddle, o Mobile Chedar depende do suporte de servidores fixos da rede Chedar e portanto não aborda o ambiente das MANETs. JMobiPeer [Bisignano et al. 2005] e Proem [Kortuem 2001] são middlewares para computação P2P móvel em ambiente de MANETs. A primeira tem como característica principal à interoperabilidade com os protocolos JXME. As duas disponibilizam um framework para o desenvolvimento de aplicações P2P genéricas. Contudo, abordagens específicas, como reconciliação, em aplicações para o compartilhamento de dados, devem ser desenvolvidas pelos programadores. O LogMiddle foca na solução de replicação disponibilizando mecanismos de reconciliação para o sincronismo das réplicas. Da mesma forma que o LogMiddle, o Xmiddle [Mascolo et al. 2001] é um middleware P2P reflexivo para compartilhamento de dados em MANETs. Ele utiliza fortemente a tecnologia XML na sua arquitetura de dados e reconciliação. Nessa área específica, o Xmiddle destaca-se por abordar requisitos funcionais necessários a um middleware em uma configuração de rede puramente ad hoc. Embora ele utilize documentos XML como uma solução estruturada para o modelo de dados, sua solução para gerência de réplicas utiliza um esquema para controle de versão que exige um alto custo de armazenamento, além disso, o protocolo de reconciliação, que utiliza manipulação de documentos XML DOM em memória, elevando significantemente a quantidade de dados mantido em memória, exige ainda um custo elevado de processamento para gerar o documento reconciliado. Em virtude disso, o protótipo atual do Xmiddle só roda na plataforma J2SE. O LogMiddle utiliza uma arquitetura de gerenciamento de réplica otimizada, alcançando um baixo custo de armazenamento, o que permitiu sua implementação na plataforma J2ME para dispositivos limitados. Em [Diogenes 2006] apresentamos um modelo analítico sobre os custos de armazenamento e processamento do LogMiddle e do Xmiddle e mostramos através de uma análise comparativa entre as duas soluções que nos cenários apresentados a nossa solução obtém menores custos. 5. Conclusão Neste artigo, nós apresentamos o LogMiddle, um middleware para compartilhamento de dados ponto a ponto em redes móveis ad hoc com foco em dispositivos limitados. O LogMiddle utiliza a estratégia de replicação otimista como mecanismo para compartilhamento de dados. A arquitetura para gerência de réplicas do LogMiddle é

12 baseada no uso de log único de armazenamento, o que permite um baixo custo de armazenamento e otimiza o custo de processamento durante o processo de reconciliação. O LogMiddle ainda disponibiliza um framework para a construção de aplicações que usam o middleware, elevando assim o nível de abstração em relação aos aspectos distribuídos. O modelo de dados das aplicações é restrito a tipos básicos como valores texto e numéricos. Assim, uma evolução do middleware seria utilizar estruturas de dados mais complexos, como por exemplo, dados binários. Como trabalhos futuros, pretende-se conduzir uma avaliação sistemática da solução proposta, tanto em ambientes de simulação quanto de forma empírica, de forma a podermos correlacionar os resultados analíticos, descritos em [Diógenes 2006], com aqueles obtidos a partir da utilização do modelo na prática. 6. Referências Bisignano, M., Modica, G. D., and Tomarchio, O. (2005), JMobiPeer: a middleware for mobile peer-to-peer computing in MANETs, In Proc. of the 25th IEEE International Conference on Distributed Computing Systems Workshops (ICDCSW 05). Bluetooth (1999), Bluetooth Core Specification v1.2, disponível em: Acesso em: dezembro/2005. Capra, L., Emmerich, W. and Mascolo. C. (2001), Middleware for Mobile Computing: Awareness vs. Transparency, In Int. 8th Workshop on Hot Topics in Op. Systems, May. Demers, A., Greene, D., Hauser, C., Irish, W., Larson, J., Shenker, S., Sturgis, H., Swinehart, D. and Terry, D. (1987), Epidemic Algorithms for Replicated Database Maintenance, In Proc. of the sixth annual ACM Symposium on Principles of distributed computing,, Canada. Diogenes, F. (2006), Logmiddle: Um Middleware para o Compartilhamento de Dados em Redes Móveis Ad Hoc, Dissertação de Mestrado no curso de Mestrado em Informática Aplicada (MIA) na Universidade de Fortaleza, Em preparação. Giordano, S., and Urpi, A. (2004), Self-Organized and Cooperative Ad Hoc Networking, Chapter 13 in Mobile Ad hoc networking, IEEE Press and John Wiley. Hupfeld F. (2004), Log-Structured Storage for Efficient Weakly-Connected Replication, IEEE: 24 th Inter. Conf. on Distributed Computing System Workshops, May, Tokyo, Japan. Kotilainen, N., Weber, M., Vapa, M. and Vuori, J. (2005), Mobile Chedar - A Peer-to-Peer Middleware for Mobile Devices, In Proc. of the 3rd Int. Conf. on Pervasive Computing and Communications Workshops, March. Kortuem, G. (2001), Proem: a peer-to-peer computing platform for mobile ad-hoc networks, In Proc. of the International Conference (UbiComp2001), Atlanta, Georgia, Octuber. Mascolo, C., Capra, L., and Emmerich, W. (2001), An XML-based Middleware for Peer-to- Peer Computing, In Proc. of the Inter. Conf. on P2P Computing, Linkoping, Sweden, Aug. Mascolo, C., Capra, L. and Emmerich, W. (2002) Mobile Computing Middleware, Advanced Lectures on Networking, NETWORKING Conference in Pisa (May 2002), Italy. Oram, A. (2001), Peer-to-Peer: Harnessing the Power of Disruptive Technologies, O Reilly. Schollmeier, R. (2001), A definition of peer-to-peer networking towards a delimitation against classical client-server concepts, In Proc. of the 7th EUNICE Open European Summer School and the IFIP Workshop on IP and ATM traffic management, Paris, September.