Diagrama de Estados do Servidor TCP

Begin Accept Receive Send BeginAccept BeginAccept BeginReceive BeginReceive BeginSend

Os tipos de mensagens que são enviadas entre os clientes e o servidor podem ser consultadas em seguida, acompanhadas da descrição da situação em que essa mensagem é enviada.

Figura 4.29 – Lista de mensagens que são trocadas entre Servidor/Cliente

Com base no diagrama de estados e na lista de mensagens, foi desenvolvido um cliente TCP, com objectivo de ser o servidor de dados da monitorização. A junção destes dois programas constitui o servidor do projecto, denominado Eolitor Server.

Este programa permite configurar a porta de comunicação (System.IO.Port.SerialPort) que foi aberta devido à ligação física entre a placa do sistema de monitorização e o computador, de forma a poder receber as tramas. Em seguida o programa processa essas mesmas tramas, obtendo os valores da monitorização, para posterior armazenamento na base de dados através da execução de store procedures, que foram mapeadas pela classe DataContext criada a partir do recurso LINQ to SQL. Ao mesmo tempo os dados são enviados para o servidor TCP, que por sua vez, envia para os clientes que estiverem ligados. Deste modo, todos os clientes que se ligarem ao Eolitor Server começam a receber de imediato dados, podendo visualizar o estado da monitorização, em tempo real.

Existe um caso particular para as ligações que são estabelecidas a partir do interface da Figura 3.6 - Eolitor System - µSD Terminal. Para estes clientes, a comunicação é feita ponto a ponto, isto é, cada cliente envia mensagens para o servidor, e este envia as mensagens de volta apenas para esse cliente, após contactar o microcontrolador e o cartão µSD que estão inseridos na placa do sistema de monitorização. Para os clientes que estabelecerem ligações a partir do interface da Figura 3.4 - Eolitor System – Monitor, as mensagens são envidas ponto multiponto, isto é, o servidor é a fonte das mensagens enviando a mesma mensagem para todos os clientes.

A implementação desta arquitectura cliente - servidor no projecto, tem como grandes vantagens:

-Possibilidade de ligação com o servidor em qualquer lugar, bastando para isso um acesso à internet, assumindo que o PC servidor ou o router de interligação entre a internet e a intranet, não tenha o acesso ao MS SQL Server e ao porto TCP do programa Eolitor TCP Server bloqueados;

-Distribuição do processamento, ficando o programa de servidor menos exigente. • Novo cliente estabelece ligação com o Servidor

• Servidor aceita ligação e adiciona novo cliente à lista de clientes

Login

• Um cliente terminou a sua ligação com o Servidor • Servidor apaga cliente da lista de clientes

• Envia para todos os clientes o nome do cliente que terminou ligação

Logout

• Mensagem que o cliente envia para o servidor e o servidor replica para os restantes clientes

Message

• Lista com todos os clientes que estão actualmente ligados ao servidor • Servidor envia a lista quando um novo cliente estabelece ligação

List

• Sem Comando

A contrapor com estas vantagens está o facto de a programação de ambos os programas ter um grau de dificuldade maior.

Figura 4.30 - Rede Servidor/Cliente do projecto Eolitor

4.10.2. Processamento de Tramas - Recepção

Os dados, em forma de tramas, que chegam ao PC Servidor, têm de ser processados de forma a obter, correctamente, a informação contida. Assim, a programação do processador de tramas tem de ser feita em conformidade com a programação do microcontrolador que edita e envias as tramas, i.e., o programa tem de ser programado para receber tramas com o formato descrito na Tabela 4.2 - Estrutura da Trama e os dados têm de ser correctamente etiquetados com os identificadores descritos na Tabela 4.3 - Identificadores dos dados. O diagrama de estados para processar os dados tem de ser igual ao Diagrama 4.8. Sempre que existem dados no buffer da porta de comunicação para serem processados, o processador de tramas vai sincronizar (syncro) com o inicio de uma trama, procurando um Byte igual a 0. Se encontrar esse Byte, esse pode ser o inicio de uma nova trama se o Byte seguinte for igual a 1NNNNNNN (length), em que o valor do NNNNNNN é igual ao tamanho da trama. Caso contrário, o processador de tramas vai para o estado de sincronização. Este é o primeiro mecanismo de detecção de erros que existe. Se o tamanho da trama for válido, o processador vai para o estado de dados (Data) e depois para o estado do código de erros (CRC). Este código CRC é o segundo mecanismo de detecção de erros na trama e é gerado e introduzido na final da trama. O PC está também programado para gerar o mesmo código CRC de modo a poder verificar a existência de erros no envio da trama. Caso o código gerado pelo PC seja igual ao código da trama então a trama não contem erros e consequentemente os dados

Monitor

µSD Terminal Eolitor Server

contidos vão ser processados. Caso contrário significa que existiu algum erro no envio ou na formação da trama e sendo assim o processador de tramas vai voltar ao estado de sincronização.

Se todo o mecanismo anterior não tiver erros, o processador de dados vai continuar, importando agora ler o identificador dos dados de forma a saber interpretar o seu valor. Consoante o identificador os dados vão ser convertidos de modo a informação fazer sentido para o sistema. Se o tamanho de dados processados ainda não é igual ao tamanho da trama inicial então significa que ainda existem dados para ser processados e o processo de identificação dos dados vota a ser repetido.

Sempre que existirem tramas para serem processadas, o ciclo de processamento é sempre repetido com o aspecto do diagrama seguinte. Caso exista a necessidade de introduzir informação na trama proveniente do sistema de monitorização, que leve à alteração do formato da trama, essas alterações tem de ser repercutidas no processador de dados de modo a este poder sincronizar os dados e poder retirar informação válida para o sistema.