A computação P2P está se tornando um paradigma comum para muitas aplicações distribuídas, permitindo o compartilhamento de recursos e a comunicação direta entre
pares, ou nós. Várias soluções de middleware (BISIGNANO et al., 2003; BISIGNANO et al., 2004; BISIGNANO; MODICA; TOMARCHIO, 2005; KORTUEM, 2002; WANG;
BJORNSGARD; SAXLUND, 2007) para as MANETs têm usado as abordagens dos mid-dleware para redes P2P, principalmente devido à característica descentralizada destas redes.
2.2.1 Proem (2002)
O Proem (KORTUEM, 2002) foi desenvolvido pelo Wearable Computing Laboratory na Universidade de Oregon (EUA). Ele fornece uma solução para o desenvolvimento e a implantação de aplicações P2P nas MANETs. Seus objetivos incluem suporte ao desenvol-vimento em alto nível, independência de plataforma, interoperabilidade e extensibilidade.
A figura 2.6 ilustra a arquitetura domiddleware. As aplicações, chamadas de peerlets, utilizam o modelo de programação baseada em eventos. Tais eventos são acionados nas seguintes situações: (i) como reação às alterações no seu estado interno e no contexto externo; (ii) como reação às mensagens recebidas dos nós próximos.
Figura 2.6: Arquitetura do Proem.
Fonte: Adaptado de (KORTUEM, 2002)
O núcleo do Proem fornece quatro protocolos de comunicação que definem a sintaxe e a semântica das mensagens trocadas pelos nós. O Protocolo de Transporte Proem é assíncrono, sem conexão e não confiável, dando suporte à comunicação básica entre os
nós. O Protocolo de Presença permite que os nós anunciem a sua presença e descubram a presença de outros nós no sistema. O Protocolo de Dados possibilita o compartilhamento e a sincronização dos dados. Finalmente, o Protocolo de Comunidade é responsável pelo estabelecimento das relações de confiança entre os nós e formação de grupos.
O Proem fornece seis serviços às aplicações que são executadas como um conjunto de APIs de alto nível. O gerenciador de presença é responsável pela descoberta de nós próximos. O gerenciador de perfil mantém as informações sobre a identidade dos nós e os recursos compartilhados. O gerenciador de espaços de dados realiza o armazenamento persistente dos espaços de dados e controla o acesso a esses dados. O gerenciador de comunidade registra a associação do nó em grupos e valida outras associações de grupo.
O banco de dados do nó mantém um registro persistente dos encontros com outros nós, permitindo que as aplicações determinem quando e com que frequência um nó em par-ticular foi encontrado no passado. Finalmente, o barramento de eventos possibilita a comunicação baseada em eventos entre as aplicações.
2.2.2 ExPeerience (2003)
O ExPeerience (BISIGNANO et al., 2003; BISIGNANO et al., 2004) fornece uma ca-mada capaz de esconder a complexidade das MANETs para os programadores, permitindo o desenvolvimento de aplicações que podem usar as peculiaridades de tais ambientes. Ele utiliza os serviços fornecidos por um ambiente P2P. Para isso, ele utiliza um framework P2P, chamado JXTA (JXTA, 2014), que fornece interoperabilidade, independência de plataforma e ubiquidade.
Segundo os autores, embora o JXTA seja altamente eficaz, ele não endereça algumas características chaves das MANETs, como, por exemplo, o gerenciamento de conexões intermitentes. O objetivo do ExPeerience é aumentar alguns serviços do JXTA, forne-cendo uma outra camada que considera as características das MANETs, mantendo alta compatibilidade com as redes JXTA tradicionais. A figura 2.7 ilustra a arquitetura do middleware. A camada Motor, construída sobre o JXTA, fornece uma interface às apli-cações. Algumas funcionalidades introduzidas pelo ExPeerience são: gerenciamento de
conexões intermitentes e múltiplas interfaces, mecanismos de descoberta de recursos mais eficiente e mobilidade de código.
Figura 2.7: Arquitetura do ExPeerience.
Fonte: Adaptado de (BISIGNANO et al., 2003)
No ExPeerience, a estrutura do JXTA foi estendida com o objetivo de tratar múltiplas interfaces. Assim, ele permite o uso de múltiplas interfaces de rede para cada nó e a associação de mais de um endereço para a mesma interface. O serviço TCPTransport do JXTA foi modificado para tratar as conexões intermitentes das MANETs, nas quais os nós podem entrar e sair da rede com frequência.
O serviço de descoberta de recursos fornece uma memória central para tratar as fre-quentes desconexões e reconexões dos nós. Ele também fornece informações atualizadas sobre os nós e seus serviços compartilhados, baseado em avisos com informações que os nós desejam compartilhar. Todos os avisos possuem um tempo de vida e são mantidos pelo gerenciador decache. Após a expiração do seu tempo de vida, os avisos são excluídos.
O serviço de código móvel define os métodos para o gerenciamento da mobilidade do código. Qualquer nó no ExPeerience é capaz de migrar um serviço de/para outro nó.
Pelo servidor de código móvel, os nós são capazes de compartilhar dados e códigos. Essa abordagem possibilita a instalação de novos serviços dinamicamente, permitindo que o middleware se adapte a situações imprevisíveis.
2.2.3 JMobiPeer (2004)
O middleware JMobiPeer (BISIGNANO; MODICA; TOMARCHIO, 2005) também fornece uma camada sobre o JXTA para esconder a complexidade das MANETs no de-senvolvimento das aplicações. Ele é uma melhoria do ExPeerience (BISIGNANO et al., 2003; BISIGNANO et al., 2004), sendo que ambos possuem conceitos similares e apresen-tam funcionalidades em comum.
A arquitetura do JMobiPeer é modular, a fim de torná-lo aplicável e adaptável para qualquer dispositivo. Seus princípios podem ser resumidos nos seguintes pontos: ser compatível com os protocolos JXTA; ser capaz de trabalhar nas MANETs, mesmo quando desconectados das redes JXTA tradicionais; rodar em dispositivos com recursos limitados;
superar as limitações da arquiteturaJXTA for Micro Edition (JXME), um subprojeto do JXTA para dispositivos compatíveis com o Java 2 Mobile Environment (J2ME) (J2ME, 2014). Entre as limitações do JXME está a necessidade de um proxy para efetuar a comunicação entre os nós.
A figura 2.8 mostra uma visão geral da arquitetura do JMobiPeer, em que todas as camadas são compatíveis com o J2ME. O middleware possui duas camadas: serviços e núcleo, que são acessadas pelas aplicações, como mensagens instantâneas. A camada de serviço implementa as funcionalidades para indexar e descobrir recursos. A camada núcleo fornece o Mensageiro Virtual, que suporta a comunicação central, e os módulos Gerenciamento do Nó, Gerenciamento de Grupo, Gerenciamento de Avisos e Descoberta.
O Mensageiro Virtual provê os protocolos de transporte e serviço para gerenciar a comunicação dos nós com a rede. Ele é responsável por abstrair os endereços físicos dos nós na rede lógica e gerenciar a transmissão e recepção das mensagens. O Gerenciamento do Nó mantém as informações relevantes do nó, como endereço, identificador e descrição.
O Gerenciamento de Grupo permite iniciar os serviços e os protocolos que podem ser usados pelos nós e mantém a lista dos grupos que o nó pertence. O Gerenciamento de Avisos mantém todos os avisos, que fornecem informações sobre os serviços, nós, grupos e endereços disponíveis. Dessa forma, encontrar nós e todos os seus recursos compartilhados se reduz a uma consulta aos avisos que foram trocados pelos nós. O módulo Descoberta
Figura 2.8: Arquitetura do JMobiPeer.
Fonte: Adaptado de (BISIGNANO; MODICA; TOMARCHIO, 2005) é responsável pela busca e publicação dos avisos para os membros de um grupo.
2.2.4 Peer2Me (2007)
O Peer2Me (WANG; BJORNSGARD; SAXLUND, 2007) fornece um framework de programação de alto nível e transparente que esconde a tecnologia de rede usada na comunicação, possibilitando o desenvolvimento rápido de aplicações P2P nas MANETs.
Ele oferece serviços de descoberta de nós e mensagens para facilitar o desenvolvimento de aplicações colaborativas. Contudo, o Peer2Me é projetado apenas para ser implantado em nós móveis que usam dispositivos Bluetooth.
O Peer2Me considera o uso de J2ME com o Connected Limited Device Configuration (CLDC) e oMobile Information Device Profile(MIDP). A figura 2.9 mostra a arquitetura geral do Peer2Me e como ela se encaixa no ambiente J2ME. Além do MIDP e do CLDC do J2ME, o middleware usa duas APIs opcionais do J2ME: JSR82 para acessar e gerenciar redes Bluetooth e JSR75 para acessar o Gerenciador de Informações Pessoais.
Como o Peer2Me é desenvolvido para rodar sobre dispositivos Bluetooth, as comuni-cações devem usar um protocolo mestre-escravo. Por outro lado, o nó mestre pode ser um ponto único de falhas, o que não é desejável nas MANETs. Para mitigar esse problema, as conexões mestre-escravo são estabelecidas dinamicamente quando dois nós desejam se
Figura 2.9: Arquitetura do Peer2Me.
Fonte: Adaptado de (WANG; BJORNSGARD; SAXLUND, 2007)
comunicar. Dessa forma, todos os nós se conhecem mutuamente e todos os nós têm a mesma responsabilidade.
A descoberta de novos nós foi implementada usando o protocolo de descoberta Blue-tooth fornecido no J2ME que pesquisa todos os dispositivos BlueBlue-tooth na proximidade.
No Peer2Me, o middleware filtra e realiza uma busca por todos os nós rodando um ser-viço Peer2Me. Após essa busca, o nó compartilha o resultado com todos os nós que ele encontrou. Um busca por novos nós é iniciada quando uma nova aplicação é executada.
2.2.5 Comparativos dos middleware baseados em P2P
A tabela 2.3 resume as soluções de middleware baseadas em P2P, considerando os requisitos das MANETs. As soluções apresentadas não apresentam nem mecanismos de localização nem de segurança para suportar as operações das MANETs. Por outro lado, todos os middleware baseados em P2P fornecem mecanismos para suporte a grupos, já que a organização baseada em grupos é comum nas redes P2P.
Além disso, todas as soluções apresentadas fornecem um meio para a descoberta de recursos. No Proem, os nós anunciam a sua presença e os recursos que eles compartilham.
O Peer2Me usa o protocolo de descoberta Bluetooth, não sendo aplicável para as redes de grande escala. Por fim, o ExPeerience e o JMobiPeer usam avisos para informar os
Tabela 2.3: Comparativos dos middleware baseados em P2P
Middleware Suporte a grupos Descoberta de re-cursos
nós sobre os recursos disponíveis na rede. Esta estratégia pode gerar um alto custo de comunicação, se todos os nós enviarem avisos sobre todos os recursos que eles conhecem no sistema.