Trabalho de Redes de Sensores Sem Fio

Trabalho Prático 2 Redes de Sensores Sem Fio Entrega Individual Data de Entrega 08 de janeiro de 2025 as 2359 Introdução As Redes de Sensores Sem Fio RSSF representam uma tecnologia crucial para a coleta de dados em tempo real em ambientes diversos com aplicações como monitoramento ambiental automação industrial e até atuações dentro de seres vivos Essas redes consistem em pequenos dispositivos sensores geralmente distribuídos em uma área capazes de captar informações como temperatura umidade pressão etc Cada sensor se comunica sem fio com outros dispositivos ou diretamente com um servidor central permitindo a criação de sistemas distribuídos e escaláveis Nas figuras abaixo um exemplo de um diagrama de rede e um sensor ambos para situações embaixo dágua Imagem 1 Sala de Espera do jogo Among Us Para ilustrar o funcionamento de uma RSSF este trabalho prático tem como objetivo simular uma rede composta por três tipos de sensores espalhados em uma região delimitada Os sensores serão responsáveis por coletar e reportar informações de forma periódica Esses sensores se comunicarão com um servidor central utilizando um modelo publishsubscribe onde as mensagens serão enviadas a tópicos específicos de acordo com o tipo de sensor Clientes conectados a esses tópicos poderão receber os dados e atualizar suas medições com base na proximidade aos sensores Objetivo Você desenvolverá 2 programas para o sistema de salas de espera utilizando apenas as funcionalidades da biblioteca de sockets POSIX e a comunicação via protocolo TCP O código do servidor deverá utilizar múltiplas threads para a manutenção das múltiplas conexões As próximas seções detalham o que cada entidade servidor e cliente deve fazer Os objetivos deste trabalho são Desenvolver um servidor utilizando a interface de sockets na linguagem C Desenvolver um cliente utilizando a interface de sockets na linguagem C Permitir que múltiplos clientes sejam conectados ao servidor e que ele encaminhe as mensagens dos sensores Fazer com que os clientes reportem as medições de tempos em tempos e que atualizem suas medidas com base nos vizinhos Protocolo O protocolo de comunicação entre o cliente e o servidor será modelado de tal forma que as operações sejam representadas pela seguinte estrutura struct sensormessage char12 type int coords2 float measurement Abaixo descrição de cada uma das propriedades type Essa propriedade armazena o tipo do sensor Neste trabalho serão 3 diferentes temperature que vai medir a temperatura do ambiente humidity para sensores de umidade airquality para medir a qualidade do ar coords Essa propriedade representa as coordenadas do sensor no espaço Neste trabalho será considerado um grid 10x10 onde o primeiro valor do vetor representa em que linha o sensor está e o segundo a coluna measurement Já essa propriedade representa a medição de cada sensor que ele mantém e envia em cada intervalo de tempo além de atualizar conforme os vizinhos Inicialização O código do cliente deve ser executado passando como argumento as coordenadas Conforme mencionado anteriormente o espaço dos sensores é um grid 10x10 de forma que as coordenadas em cada eixo vão variar de 0 à 9 e devem ser passadas da seguinte forma client 127001 51511 type temperaturehumidityairquality coords x y O usuário pode passar parâmetros errados na hora de inicializar o cliente onde a ordem prioritária dos erros bem como as mensagens que devem ser exibidas são Tabela 1 Erros de inicialização e tratativas Descrição do Erro Exemplo Mensagem Faltando argumentos client 127001 51511 type temperature coords 5 Error Invalid number of arguments Argumento type faltando client 127001 51511 tipo temperature coords 5 7 Error Expected type argument Tipo de sensor não definido client 127001 51511 type pression coords 5 7 Error Invalid sensor type Argumento coords faltando client 127001 51511 type temperature pos 5 7 Error Expected coords argument Coordenadas fora do intervalo client 127001 51511 type temperature coords 10 7 Error Coordinates must be in the range 09 OBS Após cada mensagem de erro devese exibir também a seguinte mensagem padrão na linha de baixo Usage client serverip port type temperaturehumidityairquality coords x y Também erros que não estão listados como passar chars ao invés de inteiros não precisam ser tratados e não serão testados na avaliação Exemplo completo de erro e mensagem client 127001 51511 type temperature coords 5 Error Invalid number of arguments Usage client serverip port type tipos coords x y onde tipos temperaturehumidityairquality só para destacar que é na mesma linha Uma vez corretamente inicializado o sensor vai realizar sua medição que consiste em um valor aleatório no intervalo descrito na Tabela 2 A cada intervalo de tempo também descrito nesta tabela o cliente vai mandar uma mensagem para o servidor informando sua localização tipo e medição Tabela 2 Valores e Intervalos dos Sensores Tipo do sensor Intervalo das medições Intervalo entre mensagens Temperatura ºC 200 400 5 segundos Humidade 100 900 7 segundos Qualidade do ar μgm³ 150 300 10 segundos Funcionamento da Rede Após a inicialização dos valores o funcionamento do sistema segue uma abordagem baseada no padrão publishsubscribe Nesse sistema cada sensor já é inscrito no tópico correspondente ao seu tipo por exemplo temperature humidity ou airquality de forma que todas as mensagens enviadas pelos sensores de um determinado tipo são transmitidas para todos os sensores do mesmo tipo O servidor é responsável por gerenciar os tópicos garantindo que as mensagens sejam encaminhadas corretamente para os sensores interessados Os sensores enviam suas medições periodicamente para o tópico correspondente e o servidor as propaga para todos os sensores inscritos Cada sensor ao receber uma nova medição de outro sensor utiliza essa informação para corrigir sua própria medição com base na proximidade e na diferença entre os valores caso seja um dos três sensores mais próximos Isso significa que somente a primeira medição quanto o cliente é inicializado que escolhida aleatoriamente o restante são só ajustes nessa escolha A fórmula para atualizar a medição é dada da seguinte forma 𝑛𝑜𝑣𝑎𝑚𝑒𝑑𝑖çã𝑜 𝑚𝑒𝑑𝑖çã𝑜𝑎𝑡𝑢𝑎𝑙 0 1 1 𝑑 1 𝑚𝑒𝑑𝑖çã𝑜𝑟𝑒𝑚𝑜𝑡𝑎 𝑚𝑒𝑑𝑖çã𝑜𝑎𝑡𝑢𝑎𝑙 Onde novamedição é o novo valor do sensor após a correção mediçãoatual é o valor atual do sensor mediçãoremota é o valor enviado pelo sensor remoto d é a distância euclidiana entre o sensor atual e o sensor remoto 𝑑 𝑥1 𝑥2 2 𝑦1 𝑦2 2 Essa fórmula leva em conta tanto a diferença entre o valor do sensor que recebeu a mensagem e o valor atual quanto a proximidade entre os sensores Se após a atualização o valor corrigido ultrapassar o intervalo permitido Tabela 2 ele deve ser ajustado automaticamente para o limite mais próximo inferior ou superior Isso assegura que todas as medições permaneçam válidas dentro do contexto da aplicação Conforme já citado um aspecto crucial do sistema é o gerenciamento dos vizinhos mais próximos Cada sensor deve manter a informação de seus vizinhos pois vai atualizar sua medição somente com base nos três sensores mais próximos de sua posição descartando as medidas dos outros Manter todos os vizinhos e não só os 3 mais próximos é importante porque caso um dos sensores próximos saia do sistema o sensor atual deve identificar o próximo da fila para substituílo na lista de vizinhos mais próximos Essa feature é importante considerando as RSSF que têm que lidar constantemente com sensores saindo da rede eg sem bateria destruído pelo ambiente etc Descoberta Dinâmica de Sensores A descoberta de novos sensores no sistema é dinâmica Quando um novo sensor entra na rede ele pode começar recebendo e consequentemente utilizando para atualizar a sua medições de sensores que não necessariamente são seus vizinhos mais próximos considerando todos da rede devido à falta de conhecimento inicial sobre o ambiente Conforme novas mensagens são recebidas o sensor atual ajusta sua lista de vizinhos e passa a priorizar as medições dos mais próximos Para exemplificar considere o seguinte cenário um ambiente com 5 sensores do mesmo tipo e um novo sensor desse mesmo tipo entra no sistema Se ele receber mensagens na ordem do mais distante para o mais próximo ele realizará 5 atualizações até estabilizar com os três vizinhos mais próximos Se a ordem for do mais próximo para o mais distante apenas 3 atualizações serão realizadas pois ele estabiliza sua lista de vizinhos antes de processar as medições mais distantes Esse comportamento dinâmico ilustra o procedimento real de muitos sistemas em RSSF para descobrir seus vizinhos e a fórmula de atualização também considera esse caso ao considerar a distância e consequentemente diminuir a influência de sensores distantes Exibição das mensagens O servidor deve exibir todas as mensagens recebidas em um formato padronizado permitindo fácil rastreamento e depuração log type sensor in xy measurement measurement onde type Tipo do sensor temperature humidity ou airquality xy Coordenadas do sensor que enviou a mensagem measurement Valor da medição enviado Os clientes por sua vez vão exibir todas as mensagens que chegam para ele ou seja todas do mesmo tipo dele Isso inclui a deles mesmos já que não devem exibir nada ao enviar uma mensagem O formato de exibição é o mesmo do servidor mas com um campo a mais log type sensor in xy measurement measurement action status Esse último campo descreve o tratamento realizado daquela mensagem devendo ser exibido not neighbor Caso o sensor que recebeu considere que o emissor está muito longe para ser considerado vizinho e descarta a medição Essa ação só é possível caso o receptor já tenha três vizinhos e essa nova mensagem venha de um mais distante que esses três correction of value Caso onde o sensor é um vizinho e portanto é feita correção na medição O valor a ser exibido é o que vai ser corrigido da medição atual arredondado para quatro casas decimais Se negativo indicar com sinal na frente same location Caso o sensor emissor esteja na mesma célula que o receptor e portanto não deve ser considerada não é vizinho removed Caso em que o sensor saiu do sistema explicado no tópico abaixo Perceba que é possível sensores ocuparem o mesmo espaço do grid não bloqueamos isso na inicialização e como não passamos nenhum ID de cada sensor não temos como saber se a mensagem que chegou é a que o próprio sensor enviou ou de outro Assim para simplificar vamos considerar como não vizinho e descartar todas as medições da mesma célula que o sensor Obs Existe um no final do log que significa para adicionar mais uma quebra de linha para separar melhor os logs no terminal dando uma linha em branco entre eles Encerramento de um sensor Os clientes não vão receber nenhum input por parte do usuário Isso é proposital já que em Redes de Sensores Sem Fio os dispositivos são autônomos e descartáveis Assim para finalizar o sensor é necessário parar o processo do cliente Ctril C o que representa a destruiçãoinatividade do dispositivo O servidor por sua vez vai perceber que o cliente foi desconectado e deve exibir o log padrão mas com medida negativa 10000 e enviar essa medição para os sensores do mesmo tipo como se fosse uma medição normal desse sensor só que com valor negativo log type sensor in xy measurement 10000 Os clientes por sua vez devem interpretar que essa medição negativa representa que esse sensor não está mais disponível e devem removêlo de suas bases de dados Devem exibir a action como removed Exemplo de Execução Esta seção apresenta alguns exemplos de execuções do sistema A fim de facilitar a explicação as tabelas a seguir detalham o passo a passo das mensagens ao longo do tempo Nesse primeiro exemplo temos dois sensores do mesmo tipo se conectando no servidor inicialmente sem sensores Considere que o Sensor 1 teve medição inicial de 25 ºC e o segundo 20 ºC e que o envio e recebimento de mensagens é instantâneo Tempo 1 s Servidor Terminal 1 Terminal 2 T0 client 127001 51511 type temperature coords 2 2 T1 T2 client 127001 51511 type temperature coords 4 4 T3 T4 T5 log temperature sensor in 22 measurement 250000 log temperature sensor in 22 measurement 250000 action same location log temperature sensor in 22 measurement 250000 action correction of 01306 T6 T7 log temperature sensor in 44 measurement 201306 log temperature sensor in 44 measurement 201306 action correction of 01272 log temperature sensor in 44 measurement 201306 action same location T8 T9 T10 log temperature sensor in 22 measurement 248728 log temperature sensor in 22 measurement 248728 log temperature sensor in 22 measurement 248728 action same location action correction of 01239 T11 T12 log temperature sensor in 44 measurement 202542 log temperature sensor in 44 measurement 202545 action correction of 01206 log temperature sensor in 44 measurement 202545 action same location Abaixo um exemplo com 3 sensores um de cada tipo e entra um quarto sensor Considere as medidas iniciais como Sensor 1 Tipo temperature posição 22 medição inicial 250 Sensor 2 Tipo humidity posição 33 medição inicial 500 Sensor 3 Tipo airquality posição 11 medição inicial 220 Sensor 4 Tipo temperature posição 44 medição inicial 200 Tempo Servidor Terminal 1 Terminal 2 Terminal 3 Terminal 4 T0 client 127001 51511 type temperature coords 2 2 client 127001 51511 type humidity coords 3 3 client 127001 51511 type airquality coords 1 1 T1 T2 T3 client 127001 51511 type temperature coords 4 4 T4 T5 log temperature sensor in 22 log temperature sensor in 22 log temperature sensor in 22 measurement 250000 measurement 250000 action same location measurement 250000 action correction of 01306 T6 T7 log humidity sensor in 33 measurement 500000 log humidity sensor in 33 measurement 500000 action same location T8 log temperature sensor in 44 measurement 201306 log temperature sensor in 44 measurement 201306 action correction of 01272 log temperature sensor in 44 measurement 201306 action same location T9 T10 log temperature sensor in 22 measurement 248728 log airquality sensor in 11 measurement 220000 log temperature sensor in 22 measurement 248728 action same location log airquality sensor in 11 measurement 220000 action same location log temperature sensor in 22 measurement 248728 action correction of 01239 T11 T12 T13 log temperature sensor in 44 measurement 202545 log temperature sensor in 44 measurement 202545 action correction of 01206 log temperature sensor in 44 measurement 202545 action same location T14 log humidity sensor in 33 measurement 500000 log humidity sensor in 33 measurement 500000 action same location Por fim um exemplo em que um sensor se desconecta Considere os seguintes sensores Sensor 1 Tipo humidity posição 22 medição atual de 500 Sensor 2 Tipo humidity posição 23 medição atual de 550 Sensor 3 Tipo humidity posição 32 medição atual de 580 Sensor 4 Tipo humidity posição 33 medição atual de 520 Sensor 5 Tipo humidity posição 99 medição atual de 600 Cada um entrou no sistema com um segundo de diferença em ordem crescente ou seja primeiro o sensor 1 vai mandar mensagem depois o 2 etc Nesse exemplo os sensores já trocaram algumas mensagens de forma que os dispositivos 1 2 e 3 e 4 são vizinhos entre si Contudo quando o sensor 2 sai do sistema os outros consideram o 5 como um vizinho próximo Tempo Terminal 1 Terminal 2 Terminal 3 Terminal 4 Terminal 5 T0 log humidity sensor in 22 measurement 500000 action same location log humidity sensor in 22 measurement 500000 action correction of 02500 log humidity sensor in 22 measurement 500000 action correction of 01000 log humidity sensor in 22 measurement 500000 correction of 00828 log humidity sensor in 22 measurement 500000 action not neighbor T1 log humidity sensor in 23 measurement 547500 action correction of 02375 log humidity sensor in 23 measurement 547500 action action same location log humidity sensor in 23 measurement 547500 action correction of 02755 log humidity sensor in 23 measurement 547500 action correction of 01416 log humidity sensor in 23 measurement 547500 action correction of 00514 T2 log humidity sensor in 32 measurement 483755 action correction of 00931 log humidity sensor in 32 measurement 483755 action correction of 02640 log humidity sensor in 32 measurement 483755 action same location log humidity sensor in 32 measurement 483755 action correction of 01842 log humidity sensor in 32 measurement 483755 action correction of 01132 T3 log humidity sensor in 33 measurement 518746 action correction of 00717 log humidity sensor in 33 measurement 518746 action correction of 01306 log humidity sensor in 33 measurement 518746 action correction of 01750 log humidity sensor in 33 measurement 518746 action same location log humidity sensor in 33 measurement 518746 action correction of 00839 T4 log humidity sensor in 99 measurement 597515 action not neighbor log humidity sensor in 99 measurement 597515 action not neighbor log humidity sensor in 99 measurement 597515 action not neighbor log humidity sensor in 99 measurement 597515 action not neighbor log humidity sensor in 99 measurement 597515 action same location T5 T6 log humidity sensor in 23 measurement 10000 action removed Ctril C Cliente se desconecta Servidor manda mensagem com medida 10000 log humidity sensor in 23 measurement 10000 action removed log humidity sensor in 23 measurement 10000 action removed log humidity sensor in 23 measurement 10000 action removed T7 log humidity sensor in 22 measurement 502161 action same location log humidity sensor in 22 measurement 502161 action correction of 00833 log humidity sensor in 22 measurement 502161 action correction of 00687 log humidity sensor in 22 measurement 502161 action correction of 00875 T8 T9 log humidity sensor in 32 measurement 486337 action correction of 00791 log humidity sensor in 32 measurement 486337 action same location log humidity sensor in 32 measurement 486337 action correction of 01586 log humidity sensor in 32 measurement 486337 action correction of 01079 T10 log humidity sensor in 33 measurement 516473 action correction of 00626 log humidity sensor in 33 measurement 516473 action correction of 01507 log humidity sensor in 33 measurement 516473 action same location log humidity sensor in 33 measurement 516473 action correction of 00834 T11 log humidity sensor in 99 measurement 594727 action correction of 00851 log humidity sensor in 99 measurement 594727 action correction of 01046 log humidity sensor in 99 measurement 594727 action correction of 00825 log humidity sensor in 99 measurement 594727 action same location Detalhes de implementação Gerenciamento de Sensores O servidor será responsável por manter o registro de todos os sensores conectados incluindo suas coordenadas e tipo Os sensores devem manter a lista dos vizinhos mais próximos Caso um vizinho caia o sensor deve atualizar sua lista promovendo o próximo da fila à posição de vizinho próxmo Tipos de Sensores Apenas três tipos de sensores serão aceitos temperature humidity e airquality Qualquer tipo diferente deve resultar em um erro e impedir a execução do cliente Coordenadas dos Sensores As coordenadas dos sensores devem ser especificadas ao iniciar o cliente e precisam estar dentro do intervalo 0 9 Caso as coordenadas estejam fora do intervalo ou não sejam numéricas o cliente deve exibir uma mensagem de erro e não iniciar Mensagens e Tópicos Cada tipo de sensor possui um tópico exclusivo no qual serão publicadas e recebidas as mensagens Mensagens de sensores do mesmo tipo devem ser encaminhadas apenas para outros sensores do mesmo tipo Atualização de Medições As medições iniciais são aleatórias dentro dos intervalos definidos mas todas as atualizações subsequentes devem usar a fórmula de correção com base nos vizinhos mais próximos Apenas os três vizinhos mais próximos serão usados para corrigir medições Se não houver vizinhos a medição fica sempre a mesma Novos Sensores Sensores que entram dinamicamente no sistema podem usar medições de outros sensores fora de sua vizinhança real até descobrirem os vizinhos mais próximos Limites e Formatação As medições devem ser exibidas com até 4 casas decimais As coordenadas dos sensores no log devem estar no formato xy Desempenho e Limites Serão testados até 12 sensores simultâneos Certifiquese de que o sistema funcione corretamente dentro deste limite Erros e Validações Mensagens de erro específicas devem ser exibidas para parâmetros inválidos tipo ou coordenadas impedindo o cliente de iniciar Sensores sobrepostos Mais de um sensor podem ocupar o mesmo espaço no sistema de tipos iguais ou diferentes As medições da mesma localização do sensor não são usadas para atualizar as medições e nem são consideradas vizinhos Ou seja se só houver sensores num mesmo local ninguém atualiza as medições Desenvolvimento O projeto requer a implementação de dois componentes essenciais um servidor e um cliente ambos baseados no protocolo TCP É crucial garantir que ambos os componentes sejam compatíveis tanto com o IPv4 quanto com o IPv6 proporcionando flexibilidade na escolha do endereço IP Para configurar o servidor corretamente este deve ser capaz de receber seguindo rigorosamente essa ordem o tipo de endereço desejado v4 para IPv4 ou v6 para IPv6 e um número de porta especificado na linha de comando Recomendase a utilização da porta 51511 para manter a padronização do projeto Da mesma forma os clientes precisam receber também rigorosamente nessa ordem o endereço IP do servidor e o número de porta para estabelecer a conexão com sucesso Certifiquese de que ambos os componentes sejam configurados de acordo com essas diretrizes para uma integração eficaz e a comunicação adequada entre servidor e cliente A seguir um exemplo de execução dos programas em dois terminais distintos IPv4 no terminal 1 server v4 51511 no terminal 2 client 127001 51511 type temperature coords 1 1 no terminal 3 client 127001 51511 type airquality coords 2 2 IPv6 no terminal 1 server v6 51511 no terminal 2 client 1 51511 type humidity coords 5 6 no terminal 3 client 1 51511 type humidity coords 6 5 Sobre Threads O uso de threads em servidores é uma abordagem eficiente para lidar com múltiplas conexões simultâneas Em um servidor multithread cada cliente conectado é gerenciado por uma thread separada permitindo que o servidor processe várias requisições de forma paralela Essa arquitetura tem várias vantagens com talvez a principal de evitar que a execução de uma operação mais demorada por um cliente bloqueie o atendimento de outros garantindo maior responsividade do sistema No contexto deste trabalho prático o servidor será responsável por criar uma nova thread para cada cliente que se conecta Cada thread atuará de forma independente lidando com as mensagens daquele cliente Ao mesmo tempo o servidor principal continuará rodando em sua thread principal aceitando novas conexões sem interrupções Essa abordagem permite manter um fluxo contínuo de comunicação entre os sensores e o servidor assegurando que todas as mensagens sejam tratadas adequadamente mesmo em cenários com vários sensores conectados simultaneamente Para aqueles que não conhecem ou desejam relembrar esses conceitos recomendo essa playlist em especial os vídeos 5 6 e 7 Materiais para Consulta e Dicas Capítulo 2 e 3 do livro sobre programação com sockets disponibilizado no Moodle Playlist de programação com sockets do professor Ítalo Cunha O guia de programação em rede do Beej httpbeejusguidebgnet tem bons exemplos de como organizar um servidor Implemente o trabalho por partes Por exemplo implemente o tratamento das múltiplas conexões depois crie os formatos das mensagens e por fim trate os tópicos e as especifidades Procure resolver os desafios da maneira mais simples possível Avaliação O trabalho deve ser realizado individualmente e deve ser implementado com a linguagem de programação C não sendo permitida a utilização de C utilizando somente a biblioteca padrão interface POSIX de sockets de redes Deve ser possível executar seu programa no sistema operacional Linux e não deve utilizar bibliotecas Windows como o winsock Seu programa deve interoperar com qualquer outro programa implementando o mesmo protocolo você pode testar com as implementações dos seus colegas Procure escrever seu código de maneira clara com comentários pontuais e bem identados Isto facilita a correção dos monitores e tem impacto positivo na avaliação Correção Semiautomática Seu servidor será corrigido de forma semiautomática por uma bateria de testes Cada teste verifica uma funcionalidade específica do servidor Para a correção os seguintes testes serão realizados com IPv4 e IPv6 Conexão de múltiplos clientes 10 Gerenciamento correto dos vizinhos descoberta dinâmica 15 Encaminhamento correto das mensagens para os clientes 15 Atualização correta das medições 15 Impressão correta das mensagens 10 Fechamento de conexão 10 Tratativa dos erros 5 Documentação 20 Informações importantes Cada aluno deve entregar documentação em PDF de até 4 páginas duas folhas sem capa utilizando fonte Arial tamanho 12 e figuras de tamanho adequado ao tamanho da fonte A documentação deve discutir desafios dificuldades e imprevistos do projeto bem como as soluções adotadas para os problemas Atenção Será dado grande importância a parte da discussão dos desafios encontrados pois as dificuldades ao longo do projeto sempre existem A documentação corresponde a 20 dos pontos do trabalho mas só será considerada para as funcionalidades implementadas corretamente Será utilizado um sistema para detecção de código repetido portanto não é admitido cola de trabalhos Será adotada média harmônica entre as notas da documentação e da execução o que implica que a nota final será 0 se uma das partes não for apresentada Cada aluno deve entregar além da documentação o código fonte em C e um Makefile para compilação do programa Instruções para submissão e compatibilidade com o sistema de correção semiautomática O Makefile deve compilar o cliente em um binário chamado client e o servidor em um binário chamado server dentro de uma pasta chamada bin na raiz do projeto Seu programa deve ser compilado ao se executar apenas o comando make ou seja sem a necessidade de parâmetros adicionais A entrega deve ser feita no formato ZIP com o nome seguindo o seguinte padrão TP2MATRICULAzip Desconto de Nota por Atraso Os trabalhos poderão ser entregues até a meianoite do dia especificado para a entrega Não serão aceitos trabalhos com atraso Redes de Sensores sem Fio Nome 1 Contextualização do Projeto As Redes de Sensores Sem Fio RSSF têm se mostrado indispensáveis em diversos campos abrangendo desde o acompanhamento ambiental e a automação industrial até aplicações no setor de saúde A habilidade de coletar e processar dados em tempo real de forma distribuída e autônoma aliada à sua flexibilidade de implantação as torna uma solução atraente para uma ampla variedade de problemas O uso de RSSF encontra aplicações em uma variedade de contextos práticos como o monitoramento de condições ambientais em áreas remotas o controle de processos em plantas industriais a coleta de dados de saúde em pacientes em domicílio e o acompanhamento de parâmetros em atividades agrícolas Nesses casos a capacidade de operar de forma autônoma e sem a necessidade de infraestrutura cabeada torna essa tecnologia particularmente valiosa Este trabalho prático tem como propósito explorar a implementação de uma RSSF simulada utilizando as ferramentas e conceitos adquiridos em sala de aula Para isso será desenvolvido um sistema fundamentado em comunicação via sockets TCP empregando um modelo de publicaçãoassinatura publishsubscribe para a troca de informações entre sensores e um servidor central O sistema é composto por dois elementos cruciais um servidor responsável por gerenciar os tópicos encaminhar as mensagens e manter o registro de todos os sensores conectados e um cliente que simula um sensor e envia medições periódicas ajustandoas com base nos sensores próximos A comunicação entre esses elementos se dará através da interface POSIX para sockets e a linguagem de programação C garantindo compatibilidade e portabilidade para o sistema operacional Linux O projeto aborda desafios como o manejo de múltiplas conexões simultâneas a implementação do modelo de comunicação o gerenciamento da vizinhança em um ambiente dinâmico e a atualização das medições com base na proximidade dos sensores Buscase desse modo aprofundar a compreensão dos principais conceitos relacionados às RSSF e ao desenvolvimento de aplicações em rede além de demonstrar o domínio das ferramentas e técnicas de programação em C e comunicação via sockets 2 Propósitos do Projeto Este estudo prático visa a implementação de um sistema simulado de Rede de Sensores Sem Fio RSSF que ilustre o funcionamento da coleta e processamento de dados em tempo real Para alcançar este propósito geral foram definidos os seguintes objetivos específicos Desenvolvimento do Servidor Multithread Implementar um servidor em linguagem C utilizando a interface POSIX para sockets para aceitar conexões de múltiplos clientes de maneira simultânea através do uso de threads gerenciando temperatura umidade e qualidade do ar e encaminhando as mensagens para os sensores inscritos no tópico apropriado Devese manter um registro de todos os sensores conectados exibir as mensagens recebidas dos sensores em formato padrão e tratar o encerramento das conexões Desenvolvimento do Cliente Sensor Implementar um cliente em linguagem C utilizando a interface POSIX para sockets capaz de se conectar ao servidor utilizando os endereços IPv4 e IPv6 O cliente deve ser inicializado corretamente recebendo como argumentos o tipo de sensor e suas coordenadas efetuando medições periódicas de maneira aleatória dentro de intervalos predefinidos para cada tipo de sensor As medições devem ser enviadas periodicamente ao servidor e o cliente deve também receber mensagens de outros sensores atualizando as medições e considerando a proximidade dos três sensores vizinhos Devese gerenciar a lista de vizinhos e remover sensores que se desconectam ou que não são mais vizinhos próximos tratando apropriadamente os erros de inicialização Implementação do Paradigma PublishSubscribe Assegurar que a comunicação entre sensores e servidor siga o modelo publishsubscribe de modo que as mensagens enviadas por um sensor sejam direcionadas para todos os sensores inscritos no mesmo tópico e garantir que o servidor e o cliente sejam compatíveis com IPv4 e IPv6 Gerenciamento da Dinâmica da Rede Garantir que o sistema consiga lidar com a entrada e saída de sensores de forma dinâmica adaptando as listas de vizinhos e as medições de maneira eficiente 3 Abordagem de Desenvolvimento O desenvolvimento foi realizado utilizando o compilador GCC para a linguagem C e o ambiente de desenvolvimento integrado IDE Visual Studio Code que facilitaram a escrita depuração e gestão do código O projeto foi estruturado em torno de dois componentes principais o servidor servidorc responsável pela gestão da rede e o cliente clientec que simula os sensores O arquivo Makefile foi usado para automatizar o processo de compilação A abordagem de desenvolvimento foi modular permitindo a separação de responsabilidades e facilitando a manutenção e a reutilização do código 31 Arquitetura do Servidor servidorc O servidor foi concebido para ser o coração da rede simulada gerenciando conexões tópicos de informação e a comunicação entre os sensores Início da Operação O servidor inicia a sua operação com a criação do socket TCP associandoo a um endereço e porta especificados e iniciando a escuta por novas conexões Gerenciamento de Conexões O servidor implementa um loop principal que aceita novas conexões de clientes Para cada nova conexão é criada uma thread permitindo que o servidor lide com múltiplos sensores simultaneamente Gestão de Tópicos O servidor mantém uma estrutura de dados para organizar os tópicos de informação como temperatura umidade e qualidade do ar e registrar os sensores inscritos em cada um deles Encaminhamento de Dados As mensagens recebidas de um sensor são encaminhadas para todos os outros sensores inscritos no mesmo tópico utilizando um modelo publishsubscribe Manutenção de Registros O servidor mantém um registro de todos os sensores conectados incluindo os seus IDs coordenadas e tipos Tratamento de Desconexão Quando um cliente se desconecta o servidor envia uma mensagem com um valor negativo 10000 para os outros sensores do mesmo tipo indicando a sua indisponibilidade 32 Estrutura do Cliente clientec O cliente foi projetado para simular o comportamento de um sensor em uma RSSF gerando e enviando dados para o servidor Conexão com o Servidor O cliente inicia a sua operação criando um socket TCP e estabelecendo uma conexão com o servidor utilizando os endereços IPv4 ou IPv6 fornecidos Validação de Parâmetros O cliente valida os parâmetros de entrada como IP porta tipo de sensor e coordenadas tratando possíveis erros de configuração Inscrição em Tópicos Após estabelecer a conexão o cliente envia uma mensagem ao servidor indicando o seu tipo de sensor e as suas coordenadas inscrevendose assim nos tópicos relevantes Geração Periódica de Medições O cliente simula medições gerando valores aleatórios dentro de intervalos definidos enviando esses dados periodicamente para o servidor Ajuste das Medições O cliente ajusta as suas medições com base na fórmula fornecida e na proximidade dos seus vizinhos obtendo os dados de outros sensores do mesmo tipo através do servidor Gerenciamento da Vizinhança O cliente mantém uma lista dos seus três vizinhos mais próximos atualizando essa lista de forma dinâmica com base nas mensagens recebidas do servidor Processamento de Mensagens O cliente recebe mensagens do servidor interpretandoas para atualizar as suas medições e a lista de vizinhos e exibindo as informações de forma adequada Encerramento Controlado O cliente trata corretamente o encerramento da aplicação 33 Regras de Comunicação A comunicação entre o servidor e os clientes segue um protocolo baseado em uma estrutura de mensagem comum e um modelo publishsubscribe Estrutura de Mensagem A estrutura struct sensormessage é utilizada para a comunicação entre servidor e clientes Essa estrutura contém informações relevantes sobre o tipo de mensagem o identificador do sensor as suas coordenadas e o valor da medição Gestão de Tópicos Os tópicos são gerenciados pelo servidor Os clientes se inscrevem nos tópicos relevantes enviando mensagens ao servidor no início de suas operações Modelo PublishSubscribe O modelo publishsubscribe adotado permite que os sensores após se inscreverem em um tópico específico ex temperatura recebam automaticamente as medições enviadas por outros sensores nesse mesmo tópico Isso assegura uma comunicação eficaz e escalável sem que cada sensor necessite gerenciar diretamente a lista de seus destinatários 4 Avaliação dos Resultados 41 Testes Individuais dos Componentes O arquivo servidorc foi testado individualmente para verificar o funcionamento adequado do socket o tratamento de múltiplas conexões com threads a gestão dos tópicos temperatura umidade e qualidade do ar e o envio das mensagens para os clientes corretos O arquivo clientec foi testado para verificar o funcionamento da conexão com o servidor o tratamento dos argumentos de inicialização tipo de sensor coordenadas a geração de medições aleatórias dentro dos intervalos predefinidos o envio periódico das medições para o servidor o ajuste das medições e o gerenciamento da lista de vizinhos Os resultados obtidos nos testes individuais apontaram o funcionamento correto de cada componente No entanto a necessidade de gerenciar adequadamente a concorrência e a detecção de erros foram identificadas como desafios que demandaram atenção 42 Testes de Integração do Sistema O sistema foi testado de forma integrada simulando múltiplos sensores clientes de diferentes tipos e em variadas situações como a entrada e saída de sensores da rede a troca de mensagens de medição e atualização etc Os testes foram conduzidos em ambientes IPv4 e IPv6 para assegurar a compatibilidade Durante os testes de integração foram identificados os seguintes desafios e dificuldades Gerenciamento da Concorrência O compartilhamento de recursos críticos como a lista de sensores e dados de medição entre múltiplas threads no servidor apresentou um desafio em termos de concorrência Detecção de Erros de Rede Em um ambiente simulado a ocorrência de erros de rede como perdas de pacotes ou conexões interrompidas exigiu a implementação de mecanismos robustos de detecção e tratamento Validação da Configuração A configuração do sistema incluindo parâmetros como tipos de sensores coordenadas e limites de medição necessitou de validação e tratamento de erros detalhados Escalabilidade Embora o sistema tenha sido testado com até 12 sensores simultâneos a avaliação da escalabilidade para um número maior de sensores revelou que a performance do servidor poderia ser afetada A capacidade de suportar um número crescente de conexões sem comprometer o desempenho apresentou um desafio a ser considerado 5 Considerações Finais O sistema foi avaliado utilizando script de teste e apresentou um desempenho satisfatório em relação aos requisitos estabelecidos após a correção manual do código O desenvolvimento deste sistema simulado de RSSF proporcionou uma boa experiência na aplicação prática dos conceitos de redes sockets threads modelo publishsubscribe e programação em C A implementação de um sistema que se adapta de forma dinâmica à entrada e saída de sensores e que gerencia múltiplas conexões simultâneas foi um desafio interessante que exigiu atenção com a sincronização tratamento de erros e avaliação de desempenho