PTC29008: Diretrizes para projeto de protocolo

Próxima aula

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:

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):

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 publicação de mensagens anônimas, curtas e com duração definida, em repositórios denominados murais ou canais obtenção de mensagens com anonimato, a partir da identificação do mural ou canal que as contém

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 protocolo executado em plataforma com memória ilimitada e capacidade de processamento elevada taxa de transmissão variável, podendo ser baixa

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

Exemplo

GET: obter mensagem mural: string 16 caracteres ASCII indice: numero da mensagem, inteiro de 8 bits POST: publicar mensagem mural: string 16 caracteres ASCII mensagem: string de até 256 caracteres ASCII Resposta: status: inteiro de 8 bits com código de resposta len: quantidade de bytes de conteúdo da mensagem retornada, inteiro de 8 bits timestamp: o valor da data e horário na forma de um inteiro longo de 64 bits big-endian conteudo: string de len bytes (sel len > 0)

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 forma de web service ou coisa parecida)
• as mensagens devem ser entregues sem erros no servidor, porém o protocolo não precisa garantir que elas sejam entregues.

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.

• Entrega da tarefa via Moodle