Mudanças entre as edições de "PTC29008: Diretrizes para projeto de protocolo"
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. | |
− | + | ||
+ | |||
+ | 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 | ||
− | |||
− | |||
* modo não-conectado | * modo não-conectado | ||
− | |||
− | |||
{{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 | ||
− | |||
− | |||
{{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}} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{collapse bottom}} | {{collapse bottom}} | ||
4. Descreva seu comportamento | 4. Descreva seu comportamento | ||
{{collapse top|Exemplo}} | {{collapse top|Exemplo}} | ||
− | |||
− | |||
{{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 | + | * 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: | ||
− | * | + | * o servidor de murais |
− | * | + | * uma aplicação cliente |
− | A entrega da especificação e do protocolo implementado deve ser feita '''até dia | + | 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= | + | * [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:
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:
- 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.
- 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).
- 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.
- 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.
- Preservar independência: não conectar o que for independente, o que significa separar questões ortogonais.
- 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.
- 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.
- Torne-o eficiente: implemente o projeto, meça seu desempenho e, se necessário, otimize-o.
- Verifique a implementação: confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.
- 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 |
---|
|
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 |
---|
|
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.