Pretende-se com esta secção apresentar, de forma concreta, quais os componentes que formam os vários níveis do sistema implementado, reservando um maior enfoque no cerne da implementação: o nível middleware das VLS. A figura 3.3 ilustra cada um desses componentes principais, e sua relação funcional, para cada nível da pilha imple- mentada, com base na arquitectura conceptual de referência descrita acima na secção 3.3.
Aplicação
TinyOS API de VLS
API Gestão de VLS API de Espaços de Tuplos
Middleware de VLS Gestor de VLS Sistema TeenyLIME TeenyLIME Local TeenyLIME Distribuído
Directed Diffusion Gestor de Envios
“Stack” Comunicações TinyOS TinySec
Figura 3.3: Arquitectura instanciada e componentes principais da pilha estruturada das Vizinhanças Lógicas Seguras.
A API do sistema de VLS concretizado nesta dissertação divide-se em dois com- ponentes: API de Gestão de VLS e API de Suporte a Espaços de Tuplos. A primeira interface é suportada pelo sistema Gestor de VLS que, passe-se a redundância, suporta a gestão das mesmas, usando directamente o suporte de pesquisa e difusão para alcan- çar os possíveis participantes de um agrupamento lógico. Por outro lado, a segunda interface da API principal é suportada pelo sistema de gestão de espaços de tuplos partilhados concretizado pelo Sistema TeenyLIME, abordado no capítulo 2.6.6 da in- vestigação recente das RSSF, acedendo a um ponto cimeiro do MW. Esta estratificação de pontos de acesso ao MW conferem à API das VLS um acesso de estilo multinível,
possibilitando à aplicação um teor de flexibilidade que vai desde criar e aceder a infor- mação de uma VLS até criar uma VLS e gerir o espaço de tuplos partilhado da mesma. Relativamente ao restante suporte a espaço de tuplos partilhados, o Sistema Teeny- LIME é o seu ponto de acesso, concretizando a comutação operações locais e distri- buidas, suportadas, correspondentemente, pelo componente TeenyLIME Local e pelo TeenyLIME Distribuído. Conceptualmente, esta organização é idêntica à do middleware TeenyLIME original, mantendo-se as seguintes funcionalidades operadas sobre o repo- sitório de tuplos local ou distribuído:
• Operações de inserção, leitura e remoção de tuplos do repositório;
• Instalação e desinstalação de reacções ao surgimento de tuplos no repositório. A concepção do suporte a espaços de tuplos partilhados mantém-se inalterada face ao seu desenho geral, exceptuando no facto de ser necessário agregar-se às operações um conjunto de informação identificativa das VLS. Tal justifica-se pela necessidade de se elevar a noção de vizinhança concretizada pelo sistema original, que, na pilha de serviços das VLS, não é representada pela vizinhança física directa mas sim por outros dispositivos além desse conjunto de nós.
Com base no ponto conclusivo do parágrafo anterior, é necessário existir um ma- peamento entre uma vizinhança criada e uma qualquer operação sobre o espaço de tuplos associado à mesma. Tal é conseguido pela obtenção de uma identificação única da VLS no momento da criação da mesma e o seu fornecimento por parâmetro em cada operação de espaço de tuplos efectuada. O sistema de vizinhanças incluído no Teeny- LIME acaba por ser desprezado, sendo agora essa tarefa incumbida ao gestor de VLS, por motivos directamente relacionados com sua funcionalidade de criação e atribuição de identificadores às vizinhanças formadas.
Além de gerir as vizinhanças às quais o nó actual está associado, o gestor de VLS mantém informação adicional sobre os agrupamentos lógicos nele despoletados, como o tempo actual até à sua expiração. Isso permite verificar se qualquer operação sobre o espaço de tuplos da VLS pode ser efectuada ou não, e com base nessa necessidade que surge a relação entre o Gestor de VLS e o TeenyLIME Distribuído.
O Suporte à Pesquisa e Difusão de Dados serve como forma de acesso à RSSF, incor- porando os mecanismos de disseminação e de resiliência de fluxo de dados, com base nas linhas conceptuais do Directed Diffusion, sistema esse que foi também apresen- tado na secção 2.5.2 do trabalho relacionado. Em termos dos objectivos funcionais da arquitectura de VLS, este seu sistema interno de pesquisa e difusão de dados suporta:
• Pesquisa de nós que correspondam a uma VLS;
• Operações de gestão de VLS, como inicio, destruicao, suspensao e reinicio de VLS;
• Disseminação pelas rotas criadas das operaçoes distribuídas sobre espaços de tuplos partilhados;
• Resposta às operações efectuadas pelas rotas;
• Modificação da frequência da obtenção de dados de uma VLS; • Automatização da inserção e remoção de participantes de uma VLS.
Ao nível das comunicações, a pilha de VLS incorpora um componente intermediá- rio para gerir as mensagens a enviar. A necessidade da existência deste módulo surge com a problemática da frequência excessivamente elevada dos envios de mensagens realizados por um nó da RSSF, que pode, eventualmente, gerar um número significa- tivo de tentativas falhadas. Essa falha deriva do facto do módulo de envio poder já estar a ser utilizado para enviar uma outra mensagem anterior, pelo que a transmissão de uma nova só incorre em sucesso se a que se encontrava a ser transmitida tiver sido completamente enviada. Assim, de forma a não se descartarem mensagens de saída que não podem ser enviadas no momento, estas são entregues ao Gestor de Envios.
O componente interno de gestão de envios, contido na arquitectura de VLS, ma- nipula um buffer circular de mensagens pendentes, para mais tarde serem enviadas sem qualquer tipo de interrupção. Este módulo baseia-se na pilha de comunicação do TinyOS para realizar as transmissões. Relativamente à recepção de mensagens, é também usada a mesma pilha de primitivas de comunicação, mas directamente ligada ao suporte de pesquisa e difusão de dados, que trata as mensagens recebidas por um nó. Esta pilha de comunicação é complementada pelo módulo TinySec, que confere à arquitectura as propriedades de segurança ao nível das comunicações: autenticação, confidencialidade e integridade de dados, e que será abordado na secção 3.6.
Na seguinte secção 3.5 descreve-se, de forma mais refinada, cada um destes compo- nentes que formam todo o middleware das VLS desenvolvido na presente dissertação.