Mudanças entre as edições de "PTC29008: Diretrizes para projeto de protocolo"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
Linha 36: Linha 36:
 
= TAREFA: um protocolo simples =
 
= TAREFA: um protocolo simples =
  
<!--
+
Um protocolo para mensagens curtas entre usuários foi imaginado para funcionar como um mural de recados. Um usuário pode acessar o servidor de murais, e lá deixar uma ou mais mensagens em um determinado mural. Murais podem ser criados, sendo identificados por nomes arbitrários. Cada mensagem armazenada em um mural é etiquetada com a data e horário de publicação, e também sua duração (o autor da mensagem não é identificado pelo protocolo). Mensagens de um mural são ordenadas pela data e horário de publicação, e são removidas automaticamente ao expirarem. Usuários podem também acessar o servidor de murais e obterem as mensagens de um mural. Para isso, deve-se conhecer o nome do mural que se deseja acessar, pois o protocolo não possibilita listar os murais existentes. As mensagens são obtidas na ordem em que estão dispostas no mural, porém pode-se filtrá-las por intervalos de data e horário de publicação.  
Uma placa de aquisição de dados possui um conjunto de sensores, cujas medições são realizadas com diferentes frequências. Essa placa envia suas medições para um servidor de armazenamento, que as registra em algum tipo de repositório. O período entre envios da placa é parametrizável, e cada envio de dados pode conter um ou mais valores de medições. Cada medição é composta por uma identificação sobre a grandeza medida, seu timestamp e seu valor. Sendo assim:
+
 
 +
 
 +
Com base nessa descrição resumida do protocolo:
  
 
1. Especifique o serviço provido pelo protocolo
 
1. Especifique o serviço provido pelo protocolo
Linha 43: Linha 45:
 
* protocolo de aplicação do tipo cliente-servidor
 
* protocolo de aplicação do tipo cliente-servidor
 
* protocolo orientado a mensagens
 
* protocolo orientado a mensagens
* transmissão de mensagens que podem conter de 1 até N medições
 
* garantia de entrega de mensagens de medição
 
 
* modo não-conectado
 
* modo não-conectado
* parâmetros operacionais: período de envio de mensagens, quantidade máxima de medições por mensagem (N)
 
* parâmetros operacionais definidos pelo servidor de armazenamento, podendo ser modificados pelo servidor a qualquer momento
 
 
{{collapse bottom}}
 
{{collapse bottom}}
 
2. Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)
 
2. Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)
Linha 53: Linha 51:
 
* canal de comunicação UDP
 
* canal de comunicação UDP
 
* cliente executado em plataforma com memória ilimitada e capacidade de processamento elevada
 
* cliente executado em plataforma com memória ilimitada e capacidade de processamento elevada
* enlace com taxas de transmissão na ordem de Mbps
 
* erros de bit são virtualmente inexistentes
 
 
{{collapse bottom}}
 
{{collapse bottom}}
 
3. Defina seu vocabulário, e também a codificação de mensagens a ser adotada
 
3. Defina seu vocabulário, e também a codificação de mensagens a ser adotada
 
{{collapse top|Exemplo}}
 
{{collapse top|Exemplo}}
* mensagem de dados:
 
** identificação da placa de aquisição
 
** número de sequência
 
** sequência de tuplas (id_sensor,timestamp,valor)
 
* mensagem de confirmação:
 
** número de sequência confirmado
 
** parâmetros operacionais da placa (opcional)
 
 
{{collapse bottom}}
 
{{collapse bottom}}
 
4. Descreva seu comportamento
 
4. Descreva seu comportamento
 
{{collapse top|Exemplo}}
 
{{collapse top|Exemplo}}
[[imagem:PTC-Cliente_simples.jpg|400px]]
 
<br>Cliente
 
 
{{collapse bottom}}
 
{{collapse bottom}}
  
 
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:
 
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:
 
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)
 
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)
* as medições devem ser garantidamente entregues no servidor, e sem erros.
+
* as mensagens devem ser garantidamente entregues no servidor, e sem erros.
 +
 
  
 
A implementação deve ser feita por meio de um protótipo composto por:
 
A implementação deve ser feita por meio de um protótipo composto por:
* uma emulação da placa de aquisição de dados
+
* o servidor de murais
* o servidor de coleta de dados
+
* uma aplicação cliente
  
  
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.
+
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 01/03'''.
* [https://moodle.sj.ifsc.edu.br/mod/assign/view.php?id=3138 Entrega da tarefa via Moodle]
+
* [https://moodle.sj.ifsc.edu.br/mod/assign/view.php?id=4144 Entrega da tarefa via Moodle]
-->
 

Edição das 14h17min de 20 de fevereiro de 2018


Ainda segundo Gerard Holzmann, no capítulo 2 de seu livro Design and Validation of Computer Protocols, um protocolo possui algumas propriedades desejáveis:

  • Simplicidade: um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.
  • Modularidade: um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.
  • Adequação: um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.
  • Robustez: um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.
  • Consistência: protocolos não devem apresentar interações que os levem a falhar, tais como deadlocks, livelocks e terminações inesperadas.


A figura a seguir mostra a arquitetura do protocolo de enlace PPP como exemplo de simplicidade e modularidade:

PTC-Ppp-estrutura.png


Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):

PTC-Ppp-comportamento.png

Diretrizes de projeto

No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:

  1. Definição do problema: certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.
  2. Definição do serviço: deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (o que vem antes de como).
  3. Funcionalidades externas primeiro: projete a funcionalidade externa antes da interna. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.
  4. Mantenha a simplicidade: protocolos extravagantes são mais propensos a ter bugs que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.
  5. Preservar independência: não conectar o que for independente, o que significa separar questões ortogonais.
  6. Mantenha o projeto extensível: não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.
  7. Crie um protótipo: antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.
  8. Torne-o eficiente: implemente o projeto, meça seu desempenho e, se necessário, otimize-o.
  9. Verifique a implementação: confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.
  10. Não pule as regras 1 a 7

TAREFA: um protocolo simples

Um protocolo para mensagens curtas entre usuários foi imaginado para funcionar como um mural de recados. Um usuário pode acessar o servidor de murais, e lá deixar uma ou mais mensagens em um determinado mural. Murais podem ser criados, sendo identificados por nomes arbitrários. Cada mensagem armazenada em um mural é etiquetada com a data e horário de publicação, e também sua duração (o autor da mensagem não é identificado pelo protocolo). Mensagens de um mural são ordenadas pela data e horário de publicação, e são removidas automaticamente ao expirarem. Usuários podem também acessar o servidor de murais e obterem as mensagens de um mural. Para isso, deve-se conhecer o nome do mural que se deseja acessar, pois o protocolo não possibilita listar os murais existentes. As mensagens são obtidas na ordem em que estão dispostas no mural, porém pode-se filtrá-las por intervalos de data e horário de publicação.


Com base nessa descrição resumida do protocolo:

1. Especifique o serviço provido pelo protocolo

Exemplo
  • protocolo de aplicação do tipo cliente-servidor
  • protocolo orientado a mensagens
  • modo não-conectado

2. Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)

Exemplo
  • canal de comunicação UDP
  • cliente executado em plataforma com memória ilimitada e capacidade de processamento elevada

3. Defina seu vocabulário, e também a codificação de mensagens a ser adotada

Exemplo

4. Descreva seu comportamento

Exemplo

Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:

  • o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)
  • as mensagens devem ser garantidamente entregues no servidor, e sem erros.


A implementação deve ser feita por meio de um protótipo composto por:

  • o servidor de murais
  • uma aplicação cliente


A entrega da especificação e do protocolo implementado deve ser feita até dia 01/03.