PTC29008: Diretrizes para projeto de protocolo

De MediaWiki do Campus São José
Revisão de 12h20min de 12 de fevereiro de 2018 por 127.0.0.1 (discussão) (Criou página com '__toc__ Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protoco...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para navegação Ir para pesquisar


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

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:

1. Especifique o serviço provido pelo protocolo

Exemplo
  • protocolo de aplicação do tipo cliente-servidor
  • 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
  • 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

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
  • enlace com taxas de transmissão na ordem de Mbps
  • erros de bit são virtualmente inexistentes

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

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)

4. Descreva seu comportamento

Exemplo

PTC-Cliente simples.jpg
Cliente

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 medições devem ser garantidamente entregues no servidor, e sem erros.

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 coleta de dados


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