Capítulo 3 Simulação em RSSF para Protocolos de Roteamento usando uma Abordagem Geocast Harilton da Silva Araújo, Wagner Luis T. de Castro, Raimir Holanda Filho Abstract The Wireless Sensor Networks (WSN) can be utilized as powerful tools in order to monitor and, eventually, control an environment. The applications, in that type of network, impose specific requisites related to the energy consumption and reliable delivery. The routing protocols, for the WSN, must have self-configuration characteristics aimed at discovering which is the best way for transferring the information, with delivery assurance and with minimum energy consumption, among the nodes that compose the network. This article proposes a modification of the Directed Diffusion routing protocol so as to reduce the energy consumption in the network when there is an occurrence of failures. The proposal utilizes a Geocast approach to repair broken paths by constructing a new routing tree. The performed simulations demonstrated that our proposal is more efficient from the energy viewpoint. Resumo As Redes de Sensores Sem Fio (RSSF) podem ser utilizadas como ferramentas poderosas para monitorar e, eventualmente, controlar um ambiente. Aplicações nesse tipo de rede impõem requisitos específicos relacionados ao consumo de energia e confiabilidade de entrega. Protocolos de roteamento para as RSSF devem possuir características de auto-configuração para descobrir qual a melhor forma de transferir, com garantia de entrega e com consumo mínimo de energia, a informação entre os nós que compõem a rede. Este trabalho propõe uma alteração ao protocolo de roteamento Difusão Direcionada (Directed Diffusion), de forma a reduzir o consumo de energia na rede quando há ocorrência de falhas. A proposta utiliza uma abordagem geocast para reparar caminhos quebrados construindo uma nova árvore de roteamento. Simulações realizadas demonstraram que nossa proposta é mais eficiente do ponto de vista de energia.
3.1. Introdução Uma rede de sensores é constituída por um grande número de nós, utilizados sob demanda em uma área de interesse. Cada nó possui um ou mais sensores, além da capacidade de processamento, armazenamento e comunicação. As redes de sensores sem fio têm despertado o interesse da comunidade científica devido a sua aplicabilidade que abrange diversas áreas, tais como militar, ambiental, médica e industrial. Essas redes diferem de redes tradicionais em vários aspectos. Algumas características são: composta por um grande número de nós sensores; os sensores possuem altas limitações de energia, baixa capacidade de processamento e memória. Além disso, algumas aplicações de RSSF requerem características de auto-organização, podendo se ajustar de forma autônoma às possíveis mudanças estruturais devido a intervenções externas, tais como alterações da topologia causadas por falhas, inclusão de nós ou por uma solicitação feita por uma entidade externa (usuário). O objetivo de uma RSSF é coletar dados de uma região sensoriada e permitir a extração destes por uma entidade externa através do nó sink. O principal requisito da rede, que afeta todas as fases de seu ciclo de vida e independe da aplicação, é o consumo de energia. A comunicação em RSSF consome mais energia do que o processamento e o sensoriamento realizado pelos nós da rede. Esta característica requer protocolos de roteamento que possibilite que os nós sensores se comuniquem de forma eficiente e eficaz com o mínimo de consumo de energia. Os protocolos de roteamento para redes de sensores devem possuir características de auto-configuração para descobrir qual a melhor forma de transferir, com garantia de entrega, a informação de um para o outro, com consumo mínimo de energia com finalidade de prolongar o tempo de vida da rede. Se um nó por onde trafega uma dada informação falhar, terá que ser feito um novo roteamento para que a informação a ser coletada consiga atingir o nó destino. A comunicação entre os nós da rede deve ser feita de maneira que seja otimizado o consumo de energia. Neste sentido, alguns protocolos têm o papel fundamental de aumentar o tempo de vida útil da rede. Este trabalho propõe uma alteração ao protocolo de roteamento Difusão Direcionada (Directed Diffusion), com a finalidade de reduzir o consumo de energia na rede mediante a presença de falhas. Uma abordagem geocast, foi utilizada para reduzir o número de mensagens de controle enviadas e recebidas. Essa redução foi alcançada através da construção de uma nova árvore de roteamento limitada e direcionada a uma região específica da rede mediante ocorrência de falhas. O capítulo é organizado da seguinte forma: o item 3.2 apresenta os trabalhos relacionados. O item 3.3 descreve as modificações que fizemos no protocolo Difusão Direcionada. A avaliação do algoritmo é discutida no item 3.4. Os itens 3.5 e 3.6 tratam aspectos relacionados à simulação, seguidos de conclusões no item 3.7. 3.2. Trabalhos Relacionados Uma proposta de otimização do consumo de energia é tratada em [Chen et al., 2001]. A idéia desta proposta é colocar determinados nós no modo sleep (desligado) para conservar a energia, enquanto mantêm a conectividade da rede garantindo a comunicação.
Em [Shah and Rabaey 2002] é descrito o protocolo EAR (Energy Aware Routing). O EAR é um protocolo reativo que busca caminhos de mínimo dispêndio de energia pela rede. O funcionamento básico consiste no uso ocasional de um conjunto de caminhos escolhidos através de uma função de probabilidade (a qual é dependente do consumo de energia de cada caminho). Desta forma, evita que o melhor caminho tenha a sua energia esgotada, aumentando o tempo de sobrevida da rede. Assume-se que cada nó possui um endereço e informação sobre sua localização. Em [Lee et al., 2003] é proposto um algoritmo que utiliza GPS para restringir a área de inundação dos pacotes. Este algoritmo utiliza duas abordagens para determinar que nós devem propagar as mensagens de controle. A primeira é determinada pela posição e o tamanho da área. A segunda é pela distância e a localização do destino. Um protocolo de roteamento que limita a pesquisa para busca de novas rotas em redes ad hoc é descrito em [Ko and Vaidya 2000]. Nessa proposta é utilizada uma abordagem baseada em flooding e na localização dos nodos para limitar a área da inundação. Ao enviar uma mensagem, o nodo emissor define uma zona esperada do nó destino. Se algum nodo que receber a mensagem estiver fora dessa zona, ela é descartada. O objetivo é reduzir o custo das retransmissões de cada mensagem pela rede inteira. Definições alternativas de zonas de requisição ciente de localização são tratadas em [Ko and Vaidya 1998]. Essas definições objetivam otimizar o desempenho delimitando as áreas de interesse. Para isso, são abordadas as zonas em formato retangular, circular e cone. Em [Intanagonwiwat et al., 2000] é descrito um algoritmo de disseminação de dados (Directed Diffusion), onde é proposto um esquema de roteamento centrado em dados, não havendo semântica de endereçamento. Ele também tenta atender redes dinâmicas através de um esquema de negociação com disseminação de interesses e reforços de caminhos, permitindo a rede convergir perante qualquer alteração topológica. Além disso, o Directed Diffusion utiliza como métrica para a escolha da rota aquela que possui menor retardo, o que geralmente leva à rota com menor quantidade de saltos. Uma desvantagem desta abordagem é o alto custo de comunicação para reparo de caminhos quando há ocorrência de falhas, devido à necessidade de realizar periodicamente um inundamento na rede para reforçar outros caminhos. Neste trabalho apresentamos uma proposta de protocolo de roteamento para redes de sensores sem fio. A proposta é implementada como uma modificação do protocolo de difusão direcionada (Directed Diffusion), e diferencia-se das soluções apresentadas na literatura pelo fato de usar uma abordagem para minimizar o consumo de energia durante a recuperação de falhas. São utilizadas informações de localização para redução do consumo de energia. O algoritmo é descrito em detalhes na próxima seção. 3.3. Proposta do Protocolo Ciente de Energia Neste trabalho, nós propomos uma extensão a um protocolo de roteamento centrado em dados já existente, o Directed Diffusion [Intanagonwiwat et al., 2000]. O principal objetivo da nossa proposta é desenvolver um protocolo tolerante a falhas com um mínimo de consumo de energia. Para alcançar simultaneamente esses
requisitos, foi utilizado, em nosso algoritmo, uma abordagem baseada no método de roteamento geocast. A abordagem consiste em reparar caminhos quebrados construindo uma nova árvore de roteamento limitada e direcionada. A abordagem utilizada no algoritmo de roteamento proposto é descrita a seguir: 3.3.1. Abordagem Geocast Limitada e Direcionada Inspirado em [Ko and Vaidya 1998a, Ko and Vaidya 1998b, Ko and Vaidya 1998c], a abordagem geocast limitada e direcionada foi criada a fim de realizar a construção de uma nova árvore de roteamento limitada e direcionada a uma região específica da rede, denominada de região geocast. Para tanto, o uso de informações de localização geográfica dos nós faz-se necessário, o que permiti direcionar o roteamento das mensagens. A abordagem adotada neste trabalho restringe, em formato retangular, a região que contem a área de incidência de eventos. Cada nó ao receber uma mensagem, verifica se pertence à região geocast. Se pertencer, envia novamente a mensagem para seus vizinhos; caso contrário, ignora a mensagem de controle. É assumido que todos os nós conhecem suas posições geográficas. O esquema que restringe a região geocast é semelhante ao esquema de otimização citado em [Akyildiz et al., 2002]. Esta abordagem restringe a área de inundação pelas retas,,. Assume que o nó ( ) conhece a localização (, ) do nó ( ). Seja a reta que passa pelos pontos e. A distância entre os pontos e é representada por,. é o ponto médio entre e. O raio é a distância utilizada para traçar as retas paralelas ( ) e perpendiculares ( ) a reta. A distância entre e é representada por:, =2 +, (1) Se a distância entre e é representada por (1), então a distância entre e P é denotada por:, =, A figura 1 mostra um exemplo da área geocast restringida. (2) Figura 1. Esquema de restrição da região geocast Um campo, denominado, foi criado para calcular o número de hops a partir do nó sink. O valor do raio é calculado como sendo a distância entre o sink e o nó mais distante que puder ser alcançado com saltos. A mensagem de construção de raio é enviada utilizando um determinado número inteiro, armazenado no campo, que será decrementado em uma unidade a
cada retransmissão e quando chegar a zero, a mensagem de construção de raio será descartada e uma mensagem informando a posição geográfica desses nós é enviada para ( ) a fim de determinar qual o nó mais distante. Dessa forma, a mensagem de construção de raio terá cumprido a sua meta, ou seja, alcançar os nós atendendo o número de saltos pré-determinado na fase de configuração. O tamanho da região geocast é calculada com base em e,. A redução da área para a construção de uma nova árvore de roteamento obtém vantagens, pois o número de mensagens de controle a serem trocadas será reduzido. Quanto menor for o, menor será o tamanho da zona de broadcast. Seguindo esse esquema de restrição da área, os nós devem propagar as mensagens de controle somente para os nós que pertencem à região geocast, conforme mostra a figura 2. Figura 2. Propagação de mensagens As informações para criar a região geocast são enviadas na mensagem de controle; O nó ao receber uma mensagem de controle verifica se pertence à zona restringida; Se pertencer, propaga a mensagem aos vizinhos, caso contrário, descarta a mesma, como é o caso dos nós J e K. Apenas os nós dentro da região geocast propagam as mensagens; O nosso algoritmo de roteamento é realizado em quatro fases: A. Fase de Configuração O sorvedouro realiza inundações com mensagens de interesse para seus vizinhos em cada rodada do protocolo. As mensagens de interesse descrevem a tarefa através de um par atributo-valor [Akyildiz et al., 2002]. Quando um nó recebe um interesse, ele verifica se o interesse existe no cache. Se não existe associação com nenhum dos interesses distintos armazenados, o nó cria uma nova entrada de interesse. Cada entrada no cache do nó possui um gradiente que aponta para o vizinho que o enviou o interesse. Utilizando interesses e gradientes, caminhos são estabelecidos entre o sink e os nós fontes. Após receber um interesse, um nó re-envia este interesse utilizando um gradiente. Para os seus vizinhos, o interesse parece ser originado pelo nó emissor da
mensagem, embora possa vir de outro nó distante. Assim, este protocolo realiza apenas interações locais para a disseminação dos interesses. B. Fase de Estabelecimento de Rota Quando o interesse chega a uma região apropriada, através das mensagens exploratórias, um ou mais sensores são ativados, tornando-se fontes. Os nós fontes enviam dados para os vizinhos que têm um gradiente. Os primeiros dados são chamados de dado exploratório. Na difusão direcionada, os nós re-enviam o primeiro dado exploratório recebido até chegar ao nó sorvedouro, favorecendo os caminhos de baixa latência. Conforme citado em [Akyildiz et al., 2002], a rota com baixa latência não é uma métrica eficaz em RSSF. Em nosso protocolo, cada nó insere na mensagem exploratória o número de saltos e o somatório das energias residuais de cada nó que compõe o caminho entre a fonte e o destino. Em seguida, a mensagem de dados é enviada para seus vizinhos. As mensagens exploratórias são armazenadas em um cache local para que seja feita a seleção de rotas. Um temporizador é criado em cada nó na rede e utilizado após a recepção das mensagens exploratórias. O uso do temporizador é adequado para fazer com que as mensagens exploratórias dos nós mais distantes cheguem e possam também fazer parte da seleção do caminho. A seleção das rotas é feita utilizando o mesmo mecanismo adotado em [Teixeira et al., 2004], que permite os nós decidirem localmente por qual rota encaminhar os dados sem incorrer em altos custos relacionados ao conhecimento de toda a topologia da rede. Pode-se representar o processo de seleção de rotas como a seguir. Seja =(, ) um grafo direcionado onde é um conjunto de vértices (nós sensores) e é o conjunto de pares (, ) não ordenados de elementos em (conexões). Se for encaminhada uma mensagem por um caminho =( 1, 2,,, ) em um grafo, onde,..., são vértices e (, ),..., (, ) são arestas, então cada nó em perde uma parcela de sua energia associada ao custo de envio de mensagens. Seja o custo de envio da mensagem de, a energia inicial de e a energia residual de após o envio de uma mensagem. Então, =, para =1,, 1. Portanto, a energia do caminho é denotada por, onde: = (3) A regra implementada no protocolo não escolhe apenas o caminho que possui o maior valor de energia residual disponível por todos os nós, mas também o número de nós que compõem o caminho. Como a solução utiliza apenas interações localizadas, é usada a razão λ para obtenção do melhor caminho. A razão λ é obtida através da divisão entre o somatório da energia residual ( ) e o número de saltos que compõem o caminho ( 1), conforme mostra a equação (4). λ= Considera-se, portanto, que o melhor caminho a ser escolhido é aquele que dentre todos os caminhos disponíveis de um dado par de vértices de origem e destino obtiver o maior valor correspondente a razão λ. (4)
Com base nas mensagens exploratórias e no mecanismo de seleção de rotas, o melhor caminho é selecionado, o que significa que é o caminho que possui maior energia residual com menor número de saltos. C. Fase de Comunicação de Dados A fase de comunicação de dados ocorre utilizando um gradiente entre o nó receptor e o nó que enviou a mensagem. O gradiente é estabelecido pela mensagem exploratória. Assim que o nó fonte começar a enviar seus dados, as mensagens são encaminhadas pelos nós intermediários seguindo a direção apontada pelo gradiente pré-determinado na fase anterior. Cada um dos nós intermediários encaminha o pacote de dados até chegar ao nó sorvedouro. D. Fase de Reconstrução de Caminhos Em caso de ocorrência de falha de um caminho entre o nó fonte e o sorvedouro, uma rota alternativa deve ser estabelecida. Para isso, o protocolo Directed Diffusion basicamente reinicia o mecanismo de reforço para procurar outros caminhos. Entretanto, o esquema de reparo de caminhos no Directed Diffusion possui um alto custo com relação ao consumo de energia, pois exige um inundamento da rede para reforçar outros caminhos. No caso de ocorrência de falhas nos nós que perfazem os trajetos, o nosso algoritmo, ao invés de realizar um inundamento da rede para reforço de outros caminhos, utiliza uma abordagem geocast. Essa abordagem tem o objetivo de reparar caminhos quebrados construindo uma árvore de roteamento limitada e direcionada a uma região específica da rede na qual se encontra o conjunto de nós fonte, minimizando o número de mensagens de controle enviadas e recebidas. A abordagem restringe, em formato retangular, a área que será construída a nova árvore de roteamento, conforme mostra a figura 3. Cada nó ao receber um pacote, verifica se pertence à região geocast. Se pertencer, envia novamente a mensagem para seus vizinhos; caso contrário, ignora a mensagem de controle. Figura 3. Reconstrução de caminhos No momento de definição da região geocast, o protocolo ignora o nó que falhou a fim de que este não faça parte da nova árvore de roteamento que será criada. Ao término do envio do evento que foi interrompido por falha da rota, o protocolo reinicia a
fase de configuração. As falhas nas rotas são identificadas quando o sorvedouro deixa de receber os eventos associados ao interesse atendido. A abordagem utilizada nesse algoritmo garante a reconstrução rápida de caminhos na presença de falhas, e a redução do consumo de energia, pois evita o inundamento em toda a rede para a reconstrução de novas rotas. A diferença principal entre a abordagem utilizada no Directed Diffusion e a que está sendo proposta neste trabalho, é a construção da árvore de roteamento mediante a ocorrência de falhas. Na primeira abordagem, o broadcast para a construção da árvore tem alcançabilidade máxima, ou seja, atinge todos os nós da rede. Na segunda, é efetuada a construção limitada e direcionada da árvore de roteamento, com o objetivo de alcançar apenas os nós que estão próximos a ocorrência de eventos. 3.4. Avaliação de Desempenho Para avaliação do desempenho da nossa proposta, utilizamos o simulador Sinalgo [Sinalgo 2007]. Sinalgo é um framework, escrito em Java, que permite a simulação de redes sem fio abstraindo-se das camadas mais baixas da pilha de protocolo. 3.4.1. Cenário de Simulação e Métricas Utilizadas O cenário de simulação foi construído para permitir uma compreensão didática do algoritmo proposto. A topologia do nosso cenário permite que cada nó se comunique com até 8 vizinhos. Há 121 nós, em uma topologia de rede 11 x 11. Figura 4. Topologia do Cenário Existe um fluxo de dados que consiste em uma fonte (Source) e um destino (Sink). O nó fonte gera um evento a cada segundo e está localizado conforme mostra a figura 4. O tempo total de simulação foi de 540 segundos e repetimos a mesma três vezes. As mensagens foram simuladas com pacotes de 500 bytes. A duração do interesse é de 150 segundos. O modelo de dissipação de energia adotado foi o mesmo utilizado em [Heinzelman et al., 2002]. A energia inicial dos nós foi ajustada para 1,5J. Foram escolhidas duas métricas para avaliar o desempenho da nossa proposta em relação ao protocolo Directed Diffusion: mapa de energia da rede e o consumo de energia. O mapa de energia da rede mostra a energia residual de cada nó sensor. O consumo de energia mede a taxa de energia total disponível em todos nós da rede. 3.4.2. Resultados Obtidos As distribuições energéticas da rede no tempo t=450s são mostradas nas figuras 5 e 6. Analisando a superfície observamos os seguintes resultados: no Directed Diffusion (Figura 5), a energia é consumida em todos os nós da rede, por isso, pode-se observar que a malha encontra-se posicionada em um nível mais baixo que o da nossa proposta
(Figura 6). Isso ocorre devido aos broadcasts periódicos para a reconstrução de rotas no Directed Diffusion, enquanto que na nossa proposta, os broadcasts são limitados a região geocast e direcionados a região de interesse. Figura 5. Mapa de energia (Directed Diffusion) Figura 6. Mapa de energia (Directed Diffusion + Abordagem Geocast) As depressões apresentadas nas figuras 5 e 6 referem-se à região entre o sink e o nó fonte. Percebe-se que com relação ao estado de energia inicial dos nós (1,5J) e não em relação ao posicionamento da malha, a nossa proposta apresenta uma depressão menos acentuada em decorrência do mecanismo de seleção de rotas utilizado, que propicia um balanceamento do consumo de energia. Figura 7. Consumo de energia
A Figura 7 mostra que o consumo de energia de toda a rede é reduzido utilizando nossa proposta. Isso é conseguido devido ao uso da abordagem geocast e do mecanismo de seleção de rotas, que escolhe o caminho que possui maior energia residual com menor número de saltos. Dessa forma, verifica-se que o algoritmo de roteamento apresentado neste trabalho objetiva reduzir o consumo de energia da rede. A proposta consiste na modificação do protocolo do Directed Diffusion. Foram implementadas no protocolo original duas modificações: a primeira é uma abordagem geocast e a segunda é um mecanismo de seleção de rotas. As modificações têm o objetivo de reduzir a inundação realizada pelo Directed Diffusion para recuperar caminhos quebrados e estabelecer a melhor rota para entrega do evento coletado. A avaliação da proposta por meio de simulação demonstrou que a utilização da abordagem geocast e do mecanismo de seleção de rotas apresenta resultados positivos para reduzir e balancear o consumo de energia da rede. 3.5. Simulação Anos atrás, Uzi Landman e seus colegas da Universidade da Georgia, Estados Unidos, descobriram algumas das regras que explicam porque um metal não-reativo como o ouro funciona como um catalisador quando ele se uni em agrupamentos de alguns poucos átomos. Eles não se utilizaram de experimentos reais com porções do metal precioso. Ao invés disso, eles simularam em computador e descobriram que o ouro é um catalisador muito efetivo quando se encontra na forma de partículas que contenham entre 8 e 24 átomos. Eles também descobriram que a absorção de cargas elétricas pelo metal tem um papel crucial em seu funcionamento como catalisador [Zhang et al., 2008]. Apenas seis anos mais tarde, a tecnologia disponibilizou o aparato técnico que permitiu que a equipe realizasse testes de suas previsões experimentalmente. A experiência mostrou que seus cálculos estavam corretos. Landman e seus colegas utilizaram-se da metodologia científica para validar seu trabalho. Tal metodologia orienta-se sobre os seguintes passos: observação, formulação de pergunta, formulação de hipótese, experiência controlada e análise conclusiva dos dados. Com base no trabalho de Landman e na realidade atual, percebe-se que a simulação tornou-se uma ferramenta importante para a verificação de uma hipótese formulada. Geralmente, o experimento valida uma hipótese. Entretanto, em cenários de redes, uma hipótese pode ser validada utilizando-se de um ou mais dos seguintes métodos: analítico, simulação e experimento controlado; como pode-se observar na figura 8.
Figura 8. Etapas do método científico para cenários de rede. Para a validação de uma hipótese, o modelamento matemático analítico se utiliza de modelos matemáticos e equações, já o experimento, utiliza-se de uma situação real controlada. Nas simulações, cria-se um modelo virtual próximo à realidade onde se pode, com o auxílio de computador, testar e colher resultados antes de conduzir algum experimento real. Para a realização de simulações em redes, são utilizadas ferramentas de simulação ou simuladores. Destes, podemos citar o NS2 [NS2 2008], o NS-3[NS3 2009] e o [Sinalgo 2007]. 3.6. Simulação com framework Sinalgo Abordaremos neste item, um framework para simulação e validação de algoritmos de rede, o Sinalgo. Diferentemente de outros simuladores, este tem um foco voltado para os algoritmos de rede, abstraindo-se, desta forma, das camadas inferiores à de rede presentes na pilha de protocolos, tais como a camada de enlace, por exemplo. Desenvolvido em Java, o Sinalgo permite uma prototipagem rápida de algoritmos de rede, possibilitando a realização de simulações com até 100000 nós em tempo aceitável, o que lhe confere um excelente desempenho. É possível, também, simular cenários em duas ou três dimensões. Quanto ao tipo de simulação, pode-se realizar simulações síncronas, onde todos os eventos têm seus inícios sincronizados com um clock, similar ao clock de um processador de computador, por exemplo; ou assíncronas, onde os eventos dependem uns dos outros para seus inícios e realizações. Publicado sobre a licença BSD, esta ferramenta pode ser utilizada gratuitamente, se respeitados os direitos de tal licença. Do ponto de vista da interação com o usuário, o Sinalgo oferece dois modos de simulação: modo GUI, que oferece uma interface gráfica; e o modo Batch, que possui apenas linhas de comando e quase nenhuma interação com o usuário. O modo GUI é muito útil para observar o funcionamento do algoritmo e interagir com o mesmo em tempo de execução, o que não é possível com o modo Batch. Este último é ideal para colher resultados rapidamente, uma vez que sem a interface gráfica, o desempenho da
simulação aumenta. O modo Batch deve ser utilizado quando já houver um projeto totalmente livre de falhas e uma simulação bem definida e automática. Figura 9a. Modo GUI Figura 9b. Modo Batch Basicamente, para simular algo simples e básico com o Sinalgo, é necessário conhecer apenas 3 classes deste framework. Estas classes são abstratas, portanto, deve- se criar extensões para elas a fim de que assumam um comportamento desejado para cada simulação. Estas classes são: Node, Message e Timer. A) Node Esta classe representa qualquer entidade de rede, que no escopo deste trabalho é representada pelos nós sensores. Então, seja para nós sensores fonte ou para o sink, ambas as implementações devem ser extensões desta classe. Vejamos alguns dos atributos e métodos mais importantes: Tabela 3.1. Atributos importantes da classe Node e suas s descrições. Atributo Descrição int ID Connections outgoingconnections Um número único que é dado automaticamente a cada objeto quando criado. Coleção de objetos Edge, que representam, cada um, a conexão entre dois nodos. Tabela 3.2.. Métodos importantes da classe Node e suas descrições. Método void send(message m, Node target) throws NoConnectionException; void senddirect(message msg, Node target); void broadcast(message m); Position getposition(); void setcolor(color c); Descrição Envia uma mensagem a um nó vizinho. Envia uma mensagem a qualquer nó da rede, independente da existência de conectividade. Envia uma mensagem a todos os nós vizinhos. Retorna a posição corrente do nó Altera a cor do nó
Color getcolor(); void draw(...); Retorna a cor do nó Implementa a maneira como o nó será desenhado na GUI. Você pode sobrescrever este método em sua subclasse de sinalgo.node.node para definir um desenho customizado. B) Message Esta classe abstrai o conceito de mensagem e pacote que são utilizados no mundo real. Como em uma situação real, na simulação, toda e qualquer informação trocada entre os nós deve ser por meio de mensagens. A classe Message não possui atributos, pois estes atributos correspondem aos cabeçalhos e informações contidas em um pacote de rede. Desta forma, estes atributos são específicos de cada aplicação e tipo de mensagem. Vejamos na tabela abaixo suas características: Tabela 3.3. Métodos importantes da classe Message e suas descrições. Método Descrição Message clone() Utilizado para clonar os atributos do objeto. Este método é chamado quando a mensagem é enviada a outro nó. C) Timer Esta classe abstrai um temporizador que, diferentemente dos nativos do Java, possui métodos para se trabalhar com o tempo de simulação, que é, geralmente, diferente do tempo real. A classe Timer também não possui atributos visíveis e significativos. Alguns métodos importantes e suas funções podem ser observados na tabela abaixo: Tabela 3.4. Métodos importantes da classe Timer e suas descrições. Método Descrição void fire() void startglobaltimer(double relativetime) void startrelative(double relativetime, Node n) Este método deve ser sobrescrito. Ele deve conter a tarefa a ser executada quanto este timer for disparado. Este método dispara a ação de acordo com o tempo relativo, ou seja, se o relativetime = 10, então a ação iniciará no round 10. Dispara a ação em um tempo relativo a determinado nó. 3.6.1. Instalando o Sinalgo O framework constitui um projeto Java que deve ser importado por qualquer IDE para programação Java. Neste capítulo, será utilizado como IDE padrão o Eclipse [Eclipse 2009]. Recomenda-se a utilização da versão regular release do Sinalgo que pode ser adquirida em [Sinalgo 2007]. A seguir, veremos os passos para realizar a instalação do Sinalgo. Passo 1 Instalar o Sinalgo. Considerando que o Eclipse já encontra-se instalado, deve-se, neste passo, realizar o download da versão do Sinalgo descrita anteriormente. De posse do projeto
compactado, o mesmo deve ser descompactado em qualquer diretório do sistema operacional. Recomenda-se que seja descompactado dentro do workspace do Eclipse. Passo 2 Importar o projeto instalado para o Eclipse. Com o projeto Sinalgo descompactado e de posse do caminho de seu diretório, deve-se neste momento, fazer com que o Eclipse importe o projeto descompactado. Para isso, deve-se iniciar o Eclipse e criar um novo projeto conforme mostra a figura 10. Figura 10. Criação de um novo projeto Eclipse. Na tela subseqüente, deve-se escolher Java Project e clicar em next. Em seguida, conforme mostra a figura 11, define-se um nome para o projeto e marca-se a opção Create project from existing source selecionando o diretório onde o projeto Sinalgo foi descompactado. Clica-se em finish para finalizar este passo. Figura 11. Criação de um novo projeto: Detalhes. Passo 3 Executar o Sinalgo pela primeira vez. Deve-se clicar com o botão direito na pasta src dentro da aba Project Explorer ou Navigator do Eclipse, e escolher a opção Run As Java Application. Em seguida, na tela Select Java Application, seleciona-se a classe Run e clica-se em OK. 3.6.2. Um Modelo de Simulação Básico A simulação tratada neste item é simples e deve ser considerada apenas para efeito didático. O objetivo é compreender como deve-se relacionar as classes, descritas no item anterior, a fim de alcançar um resultado desejado.
A simulação que será mostrada neste item deve atender aos seguintes requisitos: Possuir um sink e alguns nós fonte. Para que haja rotas até o nó sink, este deve criá-las. Para isso, clicando-se com o botão direito sobre o sink, deve haver uma opção construir roteamento até o sink para que se inicie o processo de construção destas rotas. A construção de rotas deve se dar da seguinte forma: cada nó fonte deve possuir em sua tabela de roteamento, apenas uma rota e esta deve ser apontada para o sink; este deve enviar, em broadcast, uma mensagem especial de construção de rotas; a cada nova construção de rotas, o sink deverá enviar uma mensagem de construção de rotas distinta das anteriores já enviadas; cada nó fonte ao receber esta mensagem, deve apontar o vizinho imediato que lhe entregou primeiro esta mensagem como rota até o nó sink e esta deve ser repassada adiante em forma de broadcast; para evitar loop, caso a mesma mensagem seja recebida e a rota já estiver estabelecida, a mesma deve ser descartada e não deve ser repassada. Clicando-se com o botão direito sobre o nó fonte, deve haver uma opção enviar mensagem para que seja enviada uma mensagem até o nó sink. O roteamento de mensagens até o sink deve funcionar da seguinte maneira: de posse de uma mensagem, sua ou de outro nó fonte, o nó deve enviá-la para o vizinho correspondente a uma rota, presente em sua tabela de roteamento, que aponta para o sink. Caso não haja rota para o sink em sua tabela de roteamento, o nó deverá descartar esta mensagem e nada fazer. No passo-a-passo a seguir, será montada uma simulação básica atendendo ao requisito acima. No passo 1, será explanado como criar um novo projeto. No passo 2, serão criadas as mensagens que serão utilizadas na simulação. No passo 3, será criado um temporizador que disparará uma mensagem quando o usuário clicar em algum nó e escolher alguma opção correspondente ao envio de mensagem, seja ela de construção de rotas, por parte do sink, seja ela uma mensagem comum, por parte do nó fonte. O passo 4 mostrará como implementar o nó sink. No passo 5 é implementado o nó fonte. Por último, o passo 6 mostrará como executar uma simulação e como visualizar seu funcionamento. Passo 1 Criando um novo projeto Com apenas uma instalação do Sinalgo, é possível realizar várias simulações distintas. Para distinguir entre as diferentes simulações, os arquivos pertencentes a uma simulação são agrupados em um projeto que deve estar dentro do diretório src/projects do classpath do Sinalgo. O nome do projeto é definido pelo nome do diretório contido nesse caminho. Para criar-se então um novo projeto, basta realizar uma copia do projeto src/projects/template para src/projects/ercemapisimulacaobasica, por exemplo, e utilizar a estrutura já pronta. Assim, o projeto automaticamente foi nomeado como ercemapisimulacaobasica. Agora, devem ser corrigidos os imports de duas classes, a classe projects. ercemapisimulacaobasica.customglobal.java e projects. ercemapisimulacaobasica.logl.java. Para isso, altera-se estes dois arquivos incluindo a linha de código:
Código: package projects.template para Código: package projects.ercemapisimulacaobasica Feito isto, tem-se agora um esqueleto de projeto pronto para ser modificado para atender aos requisitos deste item. Passo 2 Implementar as mensagens Para atender aos requisitos, acima já descritos, serão utilizados dois tipos de mensagem: uma mensagem especial para construção de rotas, que dever ser utilizada sempre que o nó sink desejar construir ou reconstruir as rotas em direção a si mesmo, e uma mensagem comum, que deve ser utilizada sempre que um nó fonte queira se comunicar com o nó sink. Para isso, serão criadas, respectivamente, as classes RoteamentoMessage e ComumMessage para representar estes tipos de mensagens. Ambas as classes, devem possuir algum atributo que referencie o último nó por onde a mensagem passou, que será chamado de idlast. Em especial, a classe RoteamentoMessage deve possuir um atributo que será usado para a comparação entre mensagens, ou seja, mensagens com o mesmo valor neste atributo serão consideradas mensagens iguais, este atributo será chamado serialnum. Sempre que um novo processo de construção de roteamento for iniciado, uma mensagem com um novo serialnum deve ser criada e enviada. Toda e qualquer classe de mensagem no Sinalgo, deve ser uma herança da classe abstrata Message e deve ser criada no pacote projects.<nome do seu projeto>.nodes.messages. Desta forma, seguem abaixo os exemplos das classes comentadas neste passo: Código: package projects.ercemapisimulacaobasica.nodes.messages; import sinalgo.nodes.messages.message; public class ComumMessage extends Message { /** * Id do último nó que repassou a mensagem. */ protected int idlast; /** * Id do nó que originou a mensagem */ protected int idorigem; public ComumMessage(int idorigem) { super(); this.idorigem = idorigem; this.idlast = idorigem; protected ComumMessage(int idorigem, int idlast) { super(); this.idorigem = idorigem; this.idlast = idlast;
@Override public Message clone() { return new ComumMessage(idOrigem, idlast); public int getidlast() { return idlast; public int getidorigem() { return idorigem; public void setidlast(int idlast) { this.idlast = idlast; Código: package projects.ercemapisimulacaobasica.nodes.messages; import sinalgo.nodes.messages.message; public class RoteamentoMessage extends ComumMessage { /** * Variável é incrementada a cada novo objeto criado por métodos * públicos. */ private static int contador; /** * Número usado para saber se uma mensagem é igual à outra. Será igual se * possuir o mesmo serialnum. Isso é necessário por conta do método * clone(). */ private int serialnum; public RoteamentoMessage(int idorigem) { super(idorigem); this.serialnum = contador++; protected RoteamentoMessage(int serialnum, int idorigem, int idlast) { super(idorigem, idlast); this.serialnum = serialnum; @Override public Message clone() { return new RoteamentoMessage(serialNum, idorigem, idlast); @Override public boolean equals(object obj) { return obj instanceof RoteamentoMessage && serialnum == ((RoteamentoMessage) obj).getserialnum(); protected int getserialnum() { return serialnum;
Passo 3 Implementar um temporizador para o envio de mensagens No Sinalgo por padrão, as simulações são feitas no modo síncrono, o que significa que todos os eventos acontecem sincronizados com uma unidade mínima de tempo em uma simulação: o round. Não há como dividir um round como podemos dividir um segundo em décimos de segundo, por exemplo. Desta forma, quando a simulação está em execução, existem ações que são disparadas em um round, mas seu efeito não pode ocorrer neste mesmo round. Existem, também, casos em que o usuário necessita interagir com a simulação. Nestes últimos, o Sinalgo não permite que esta interação ocorra com a simulação em andamento. Assim, faz-se necessário uma pausa na mesma para que ocorra a interação. Se esta interação disparar algum comportamento em um nó, por exemplo, este só poderá executar o comportamento quando a simulação retomar sua execução. Para estes e outros casos mais específicos, devemos criar um temporizador para agendar o inicio de um comportamento, utilizando-se heranças da classe abstrata Timer. Em nossos requisitos de simulação, existem duas interações do usuário com a simulação para enviar mensagens. Para isso, deve-se criar um ou mais temporizadores. Estas interações, caracterizam dois tipos e sentidos de envio de mensagens, um por parte do sink, que enviará uma mensagem de construção de rotas no sentido do nó sink para todos os nós fonte; e outro por parte do nó fonte que enviará uma mensagem comum no sentido do nó fonte em direção ao sink. Assim, percebe-se que no primeiro caso, o sink deve enviar uma mensagem para quem estiver ao seu redor, o que caracteriza um broadcast, que é representado no Sinalgo através método broadcast() da classe Node. Já no segundo, o nó fonte deve enviar uma mensagem apenas a um nó vizinho, o que caracteriza um unicast, representado no Sinalgo através do método send() da classe Node. Para criar-se uma classe que atenda a estas duas necessidades, pode-se seguir o exemplo abaixo: Código: package projects.ercemapisimulacaobasica.nodes.timers; import sinalgo.nodes.node; import sinalgo.nodes.messages.message; import sinalgo.nodes.timers.timer; public class EnvioTimer extends Timer { private Message msg; private boolean isbroadcast; private Node destino; /** * Este construtor cria um timer que enviará a mensagem via * broadcast, ou seja, todos os vizinhos do nó que está enviando a * receberam. * * @param msg * Mensagem a ser enviada em broadcast */ public EnvioTimer(Message msg) { this.msg = msg; this.isbroadcast = true;
/** * Este construtor criar um timer que enviará a mensagem * diretamente ao destino, sem que outros a recebam. * * @param msg * Mensagem a ser enviada * @param destino * Nó vizinho para onde a mensagem deverá seguir. */ public EnvioTimer(Message msg, Node destino) { this.msg = msg; this.destino = destino; this.isbroadcast = false; @Override public void fire() { if (isbroadcast) node.broadcast(msg); else node.send(msg, destino); Passo 4 Implementar o nó sink De uma maneira geral, em RSSF, o papel do nó sink é de receber e concentrar todas as informações geradas pelos nós fonte. Porém, em muitos casos, o nó sink também envia comandos à rede. Obedecendo aos requisitos desta simulação, o nó sink proposto deve utilizar-se de ambos os papéis. Neste passo, devemos implementar um mecanismo para envio de mensagens e outro para o recebimento. Para o recebimento, recomenda-se fortemente a criação de um método para tratar cada tipo de mensagem, onde, a escolha de cada método é feita dentro do método handlemessages() da classe Node, com base nos diferentes tipos de mensagens, conforme mostra o exemplo deste passo. Já para o envio de mensagens, deve-se utilizar alguma forma para que o usuário clique com o botão direito sobre um nó e escolha uma opção correspondente ao método de envio de uma mensagem de construção de rotas. Para isso, pode-se utilizar a notação @NodePopupMethod, que faz com que apareça uma determinada opção para o usuário (figura 12) e que, escolhendo-a, o método que possui esta notação é executado. Figura 12. Exemplo de uso da notação @NodePopupMethod.
Conforme abordado no passo anterior, para que haja a interação acima, é necessário pausar a simulação, interagir e retomar a execução da simulação novamente. No entanto, a notação @NodePopupMethod faz com que o método que a possui, seja executado no momento exato do clique, ou seja, quando a simulação está pausada. Ao clicar na opção Construir rotas até o sink, deve ser realizado um envio de mensagem para todos os vizinhos. Para isso, o método broadcast() deve ser chamado. Porém, se ele for chamado com a simulação pausada, causará um erro crítico. Dessa forma, faz-se necessário o uso de um temporizador. O temporizador utilizado será o do passo anterior, onde este é quem invocará o método broadcast(). Baseado nos requisitos e comentários deste passo, pode-se utilizar o código abaixo: Código: import java.awt.graphics; import projects.*; import sinalgo.*; public class Sink extends Node { /** * Sobrescrevendo este método, podemos mudar a forma como o nó aparecerá * na GUI durante a simulação. */ @Override public void draw(graphics g, PositionTransformation pt, boolean highlight) { drawnodeassquarewithtext(g, pt, highlight, "Sink", 16, Color.WHITE); setcolor(color.blue); @NodePopupMethod(menuText = "Construir rotas até o sink") public void enviarroteamentomessage() { Message m = new RoteamentoMessage(ID); EnvioTimer timer = new EnvioTimer(m); timer.startrelative(1, this); @Override public void handlemessages(inbox inbox) { while (inbox.hasnext()) { Message msg = inbox.next(); if (msg instanceof RoteamentoMessage) tratarroteamentomessage((roteamentomessage) msg); else if (msg instanceof ComumMessage) tratarcomummessage((comummessage) msg); private void tratarcomummessage(comummessage msg) { // Um exemplo de como exibir algum texto no output da GUI. Tools.appendToOutput("Sink recebeu msg de " + msg.getidorigem() + "\n"); private void tratarroteamentomessage(roteamentomessage msg) { // Aqui fica um exemplo de como tratar mensagens específicas.
Passo 5 Implementar o nó fonte Seguindo o requisito que explica como deve ser o roteamento nesta simulação, cria-se um atributo na classe fonte chamado rotasink, que corresponde a uma referência para um nó vizinho por onde devem ser encaminhadas as mensagens cujo destino é o sink. A construção em si do roteamento acontece nó a nó através do método tratarroteamentomessage(). O nó recebe a mensagem especial de roteamento, verifica se é igual à anterior. Se não for, armazena a referência do nó vizinho que enviou a mensagem no atributo rotasink, onde este, servirá de rota para qualquer mensagem destinada ao sink. Após isso, o nó repassa a mensagem para que os próximos nós também possam descobrir uma rota para o nó sink. Em RSSF, é comum haver um trabalho colaborativo entre os nós da rede, onde ora agem como origem de informações, ora agem como rota para seus vizinhos enviarem mensagens utilizando uma comunicação multi-salto. Nesta simulação não é diferente, portanto, deve-se implementar dois comportamentos distintos: originar uma mensagem enviando-a em direção ao destino final e repassar mensagens originadas por outros nós. Para originar a mensagem, utiliza-se a notação @NodePopupMethod, um método a ser disparado e um timer, como já descritos no passo anterior. Já para repassar uma mensagem comum recebida de um nó vizinho, utilizou-se o método tratarcomummessage(), que é chamado durante a manipulação de mensagens novas recebidas pelo método handlemessages(). Código: package projects.ercemapisimulacaobasica.nodes.nodeimplementations; import java.awt.*; import projects.ercemapisimulacaobasica.nodes.*; import sinalgo.configuration.wrongconfigurationexception; import sinalgo.gui.transformation.positiontransformation; import sinalgo.nodes.*; import sinalgo.tools.tools; public class Fonte extends Node { /** * Referência para o nó vizinho que representa um caminho para o sink. */ Node rotasink; /** * Última mensagem de roteamento recebida. */ RoteamentoMessage lastroteamentomessage; @Override public void draw(graphics g, PositionTransformation pt, boolean highlight) { drawnodeasdiskwithtext(g, pt, highlight, "" + ID, 16, Color.WHITE); @NodePopupMethod(menuText = "Enviar mensagem ao Sink") public void EnviarComumMessage() { // Se houver rota if (rotasink!= null) { ComumMessage msg = new ComumMessage(ID);
EnvioTimer timer = new EnvioTimer(msg, rotasink); timer.startrelative(1, this); @Override public void handlemessages(inbox inbox) { while (inbox.hasnext()) { Message msg = inbox.next(); if (msg instanceof RoteamentoMessage) tratarroteamentomessage((roteamentomessage) msg); else if (msg instanceof ComumMessage) tratarcomummessage((comummessage) msg); private void tratarcomummessage(comummessage msg) { // Se houver rota if (rotasink!= null) // repassa a mensagem em direção ao sink send(msg, rotasink); private void tratarroteamentomessage(roteamentomessage msg) { // Se a mensagem não for igual a última recebida, então if (!msg.equals(lastroteamentomessage)) { // Atualiza a rota para o sink rotasink = Tools.getNodeByID(msg.getIdLast()); // Atualiza a mensagem msg.setidlast(id); // Repassa broadcast(msg); // Guarda a referencia lastroteamentomessage = msg; Passo 6 Executar a simulação e observar seu funcionamento. Ao seguir os passos anteriores, obtém-se uma simulação básica que atende aos requisitos propostos neste item. No entanto, ao executar tal simulação, não será possível observar o que realmente está ocorrendo durante a execução. Para visualizar os acontecimentos, o código abaixo deve ser incluído no arquivo de configurações src/projects/ercemapisimulacaobasica/config.xml dentro do nó Document/Framework. Código: <!-- ********** Configurações de Animação ************ --> <!--Desenha um envelope para cada mensagem envida--> <showmessageanimations value="true" /> <!--Largura do envelope (quando a animação de mensagem está ligada)--> <messageanimationenvelopewidth value="30.0" /> <!--Altura do envelope (quando a animação de mensagem está ligada)--> <messageanimationenvelopeheight value="20.0" /> <!--Cor do envelope (quando a animação de mensagem está ligada)--> <messageanimationenvelopecolor value="r=255,g=255,b=0" />
Feito esta inclusão, ao se executar o Sinalgo clicando em Run, no Eclipse, é possível construir a árvore de roteamento e enviar mensagens ao sink. Perceba que a velocidade do envelope ao trafegar na rede deve está alta. Então, para reduzi-la, procure no arquivo de configuração pela chave MessageTransmission e altere o atributo ConstantTime. Quanto maior o valor deste atributo, menor a velocidade do tráfego da mensagem. 3.6.3. Modelo de Simulação Utilizando uma Abordagem Geocast Para uma abordagem geocast, é necessária a utilização de coordenadas geográficas. Veremos adiante como fazer isso utilizando o Sinalgo. Neste item, será utilizada toda a simulação do item anterior, onde serão feitas algumas modificações nas classes Sink, RoteamentoMessage e Fonte, que devem atender a todos os requisitos do item 3.6.2 e ao requisito abaixo: Ao receber uma mensagem especial de roteamento, o nó deverá consultar, com base nas informações da mensagem, se pertence à zona geocast ou não. Caso pertença, aplica-se o processo de construção de rotas do item anterior, caso contrário, a mensagem deve ser descartada. Para que a lógica geocast seja implementada totalmente, o funcionamento se dará da seguinte forma: o sink instanciará um objeto Zona Geocast com as informações que este objeto utilizará para calcular a zona geocast. Em seguida, ele deve colocar este objeto dentro de uma mensagem do tipo RoteamentoMessage e enviá-la em broadcast para a rede inteira; quando um nó fonte receber esta mensagem, este deve utilizar o objeto Zona Geocast, informando sua posição geográfica a ele, para testar se pertence ou não à zona geocast. Caso afirmativo, o nó dará continuidade ao procedimento de construção de rota normalmente, caso contrário, descartará a mensagem e nada mais fará até receber outra mensagem. No passo-a-passo a seguir, será montada uma simulação utilizando uma abordagem geocast, atendendo aos requisitos do item anterior e ao único deste item. No passo 1, serão feitas algumas orientações para reutilizar a simulação do item anterior. No passo 2, será mostrada uma classe que implementa toda a lógica da zona geocast. No passo 3, será realizada uma modificação na classe Sink. No passo 4, serão feitas as alterações necessárias na classe RoteamentoMessage. No passo 5, será realizada uma modificação na classe Fonte. No passo 6, será mostrado como testar a simulação. Passo 1 Reutilizar uma simulação Para se reutilizar a simulação do item anterior, pode-se seguir o passo 1 daquele item. Porém, ao invés de utilizar como projeto fonte o projeto src/projects/template, utilize a simulação básica anteriormente implementada. Passo 2 Implementar o objeto Zona Geocast A idéia principal deste passo é implementar toda a lógica de como calcular uma zona geocast e realizar testes para saber se uma dada coordenada pertence ou não a uma zona geocast. Esta lógica estará dentro de um objeto cuja classe foi aqui denominada de Zona Geocast. Segue abaixo o código da classe com a lógica da zona geocast.
Código: package projects.ercemapisimulacaogeocast.util; import java.awt.geom.point2d; import java.util.arraylist; import sinalgo.nodes.position; public class ZonaGeocast { private double r, d1, d2; private Point2D.Double a1, a2; private Point2D.Double[] vertices; private double[] eqa1, eqb1; private ArrayList<ZonaGeocast> gbs; public ZonaGeocast(double r, Point2D.Double a1, Point2D.Double a2) { eqa1 = geteqgeralreta(a1, a2); eqb1 = geteqgeralretaperpendicular(a1, a2); d1 = r; d2 = (2 * r + getdistanciaeuclidiana(a1, a2)) / 2; public ZonaGeocast(double r, Position a1, Position... a2) { this(r, new Point2D.Double(a1.xCoord, a1.ycoord), new Point2D.Double( a2[0].xcoord, a2[0].ycoord)); if (a2.length > 1) { System.out.println(a2 + " " + a2.length); gbs = new ArrayList<ZonaGeocast>(a2.length - 1); for (int i = 1; i < a2.length; i++) { gbs.add(new ZonaGeocast(r, a1, a2[i])); private double calcularcoeficienteangular(point2d.double A, Point2D.Double B) throws CoeficienteAngularException { if (A.x - B.x == 0) throw new CoeficienteAngularException(A, B); return (B.y - A.y) / (B.x - A.x); private double getdistanciaeuclidiana(point2d.double a1, Point2D.Double a2) { return Math.sqrt(Math.pow(a1.x - a2.x, 2) + Math.pow(a1.y - a2.y, 2)); public double getdistanciapontoreta(point2d.double ponto, double[] reta){ double a = reta[0], b = reta[1], c = reta[2], x = ponto.x, y = ponto.y; return Math.abs(a * x + b * y + c) / Math.sqrt(a * a + b * b); /** * Retorna a equação geral da reta ax + by + c. * * @param A * Ponto A(x,y) * @param B * Ponto B(x,y) * @return Um array de 3 posições correspondentes a 'a', 'b' e 'c', * respectivamente, na equação geral da reta. * @throws CoeficienteAngularException
* Caso os pontos informados gerem uma reta paralela ao eixo * das ordenadas. */ private double[] geteqgeralreta(point2d.double A, Point2D.Double B) { try { double[] r = new double[3]; // coeficiente angular double k = calcularcoeficienteangular(a, B); // a = k; r[0] = k; // calculo do c r[2] = (k * (-1 * A.x)) + A.y; // calculo do b r[1] = -1; return r; catch (CoeficienteAngularException e) { // então é uma paralela ao eixo das ordenadas (y) return new double[] { 1, 0, (-1 * A.x) ; private double[] geteqgeralretaperpendicular(point2d.double A, Point2D.Double B) { try { double[] r = new double[3]; // coeficiente angular double k = -1 / calcularcoeficienteangular(a, B); // a = k; r[0] = k; // calculo do c Point2D.Double pm = getpontmedio(a, B); r[2] = (k * (-1 * pm.x)) + pm.y; // calculo do b r[1] = -1; return r; catch (CoeficienteAngularException e) { // então é uma paralela ao eixo das ordenadas (y) return new double[] { 0, 1, (-1 * A.y) ; private Point2D.Double getpontmedio(point2d.double A, Point2D.Double B) { return new Point2D.Double((A.x + B.x) / 2, (A.y + B.y) / 2); public boolean isinterno(point2d.double x) { return getdistanciapontoreta(x, eqa1) <= d1 && getdistanciapontoreta(x, eqb1) <= d2; public boolean isinterno(position x) { if (gbs == null) return isinterno(new Point2D.Double(x.xCoord, x.ycoord));
else { boolean acumulador = false; for (ZonaGeocast gb : gbs) acumulador = acumulador gb.isinterno(x); return isinterno(new Point2D.Double(x.xCoord, x.ycoord)) acumulador; Passo 3 Modificar a classe Sink Seguindo o funcionamento da lógica Geocast, este passo mostrará o que modificar na classe Sink. Será necessário um método, que pergunte qual a coordenada do ponto que indica a direção do geocast, a ser invocado pelo usuário quando este clicar com o botão direito sobre o nó sink. Em seguida, este mesmo método deve criar um objeto Zona Geocast, colocá-lo dentro de uma mensagem do tipo RoteamentoMessage e enviá-lo em broadcast a seu vizinho. Seguindo esta lógica, o código abaixo foi elaborado e deve ser acrescentado à classe Sink. Código: @NodePopupMethod(menuText = "Construir rotas com geocast") public void enviarroteamentomessagegeocast() { // Código para colher as coordenadas String resposta = JOptionPane.showInputDialog("Digite as coordenadas X e Y, respectivamente, da direção do geocast separadas por vírgula. ( Ex. 50,50 )"); String[] coordenadasstring = resposta.split(","); int x = Integer.parseInt(coordenadasString[0]); int y = Integer.parseInt(coordenadasString[1]); // Fim código para colher as coordenadas // Criando o gerenciador geocast ZonaGeocast zg = new ZonaGeocast(100.0, getposition(), new Position(x, y, 0)); // Criando a mensagem a ser enviada Message m = new RoteamentoMessage(ID, zg); // Criando o timer para enviar a mensagem EnvioTimer timer = new EnvioTimer(m); // Agendando o envio para o próximo round timer.startrelative(1, this); Passo 4 Modificar a classe RoteamentoMessage Neste passo, deve-se modificar a classe RoteamentoMessage para que as instâncias da mesma possam carregar, dentro de si, um objeto Zona Geocast. Para isso, deve-se acrescentar as seguintes linhas de código: Código: private ZonaGeocast zonageocast; public RoteamentoMessage(int idorigem, ZonaGeocast zonageocast) { super(idorigem); this.zonageocast = zonageocast; this.serialnum = contador++; protected RoteamentoMessage(int serialnum, int idorigem, int idlast, ZonaGeocast zg) { super(idorigem, idlast);
this.serialnum = serialnum; this.zonageocast = zg; public ZonaGeocast getgerenciadorgeocast() { return zonageocast; Passo 5 Modificar a classe Fonte A última modificação a ser feita é a da classe Fonte. O nó fonte deve, durante o processo de construção de rotas, testar se pertence ou não à zona geocast. Para que isso aconteça, pode-se modificar a classe Fonte substituindo o método tratarroteamentomessage pelo código abaixo: Código: private void tratarroteamentomessage(roteamentomessage msg) { // Se o nó está numa posição geográfica que satisfaça ao geocast e se a // mensagem não for igual à última recebida, então if ((msg.getgerenciadorgeocast()!= null && msg.getgerenciadorgeocast().isinterno(getposition()) &&!msg.equals(lastroteamentomessage)) (msg.getgerenciadorgeocast() == null &&!msg.equals(lastroteamentomessage))) { // Atualiza a rota para o sink rotasink = Tools.getNodeByID(msg.getIdLast()); // Atualiza a mensagem msg.setidlast(id); // Repassa broadcast(msg); // Guarda a referencia lastroteamentomessage = msg; Passo 6 Testar a simulação Com base nas modificações realizadas nos passos anteriores, pode-se agora direcionar um geocast na simulação proposta. Para isso, execute a simulação e clique com o botão direito sobre o sink e escolha a opção correspondente à construção de rotas com geocast. Surgirá então uma caixa conforme mostra a figura 13. Figura 13. Caixa de entrada das coordenadas do ponto que direciona o Geocast