Mudanças entre as edições de "PTC29008: Projeto 1: Garantia de entrega"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
 
(29 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
[[PTC29008:_Timeouts|Próxima aula]]
+
[[PTC29008:_O_controle_de_acesso_ao_meio|Próxima aula]]
  
 
__toc__
 
__toc__
Linha 44: Linha 44:
  
  
[[imagem:PTC-Proj1-Protocolo-estrutura.jpg]]
+
[[imagem:PTC-Protocolo-estrutura2.jpg]]
  
  
Assim, a subcamada ''ARQ'' envia e recebe quadros de dados e de confirmação da subcamada inferior (detecção de erros). O mecanismo ''ARQ'' implementado nessa subcamada pode ser modelado como duas máquinas de estado finitas: uma para transmissão e outra para recepção:
+
Assim, a subcamada ''ARQ'' envia e recebe quadros de dados e de confirmação da subcamada inferior (detecção de erros + enquadramento). O mecanismo ''ARQ'' implementado nessa subcamada pode ser modelado como duas máquinas de estado finitas: uma para transmissão e outra para recepção:
  
 
[[imagem:PTC-proj1-Mef-arq-tx.jpg]]
 
[[imagem:PTC-proj1-Mef-arq-tx.jpg]]
Linha 72: Linha 72:
 
A garantia de entrega deve ser feita com um mecanismo ARQ do tipo pare-e-espere. A máquina de estados finitos a seguir resume o comportamento do ARQ para o protocolo de comunicação.
 
A garantia de entrega deve ser feita com um mecanismo ARQ do tipo pare-e-espere. A máquina de estados finitos a seguir resume o comportamento do ARQ para o protocolo de comunicação.
  
<!--
+
 
 
[[imagem:PTC-Mef-arq2.jpg]]
 
[[imagem:PTC-Mef-arq2.jpg]]
 
<br><br>''A MEF do ARQ: N é o número de sequência de envio, e M o de recepção''
 
<br><br>''A MEF do ARQ: N é o número de sequência de envio, e M o de recepção''
 +
 +
OBS:
 +
* '''M''': numero de sequência de recepção
 +
* '''N''': numero de sequência de transmissão
 +
 +
<!--
 +
{{collapse top|Um possível modelo de software (esboço do diagrama de classes)}}
 +
[[imagem:ptc-Proto_v1.jpg|600px]]
 +
{{collapse bottom}}
 
-->
 
-->
  
= As sequências de processamento do protocolo =
+
== O formato de quadros no protocolo ==
 +
 
 +
* [http://vger.kernel.org/~davem/skb.html SKB: uma estrutura de dados para representar pacotes no kernel Linux]
 +
 
 +
 
 +
O quadro possui um cabeçalho com dois campos:
 +
* '''Controle''': contém tipo de quadro (ACK ou DATA) e número de sequẽncia (0 ou 1)
 +
* '''Proto:''' contém o tipo de conteúdo transportado pelo quadro ('''OBS''': este campo existe somente em quadros do tipo DATA)
 +
 
 +
O campo FCS, ao final do quadro, contém o valor do [https://tools.ietf.org/html/rfc1662#appendix-C código CRC-16-CCITT]. Esse campo ocupa 2 bytes, sendo o primeiro o LSB (''Least Significant Byte'') do código CRC, e o último o MSB.
 +
 
 +
 
 +
[[imagem:PTC-Quadro-proto1.jpg]]
 +
<br><br>''O formato de um quadro''
 +
 
 +
== Diferenciação de eventos nas MEF do protocolo ==
 +
 
 +
O componente ARQ está sujeito a pelo menos três tipos de eventos:
 +
* '''payload''': notificado quando a aplicação chama o método ''envia'' do Protocolo
 +
* '''quadro vindo do Enquadramento''': notificado pelo Enquadramento por meio do método ''notifica''
 +
* '''timeout''': notificado pelo poller via método ''handle_timeout''
 +
 
 +
 
 +
O componente Enquadramento, por sua vez, responde a dois eventos:
 +
* '''byte''': notificado pelo poller via método ''handle''
 +
* '''timeout''': notificado pelo poller via método ''handle_timeout''
 +
 
 +
 
 +
Esses eventos devem ser tratados por meio das respectivas máquinas de estados. Para diferenciá-los, uma forma é declarar um tipo Evento, o qual encapsule o tipo de evento e os dados a ele associados. Por exemplo, no caso do ARQ na versão C++ (a classe ''Frame'' não está descrita):
 +
 
 +
<syntaxhighlight lang=c>
 +
class ARQ : public Layer {
 +
public:
 +
  // métodos públicos
 +
 
 +
private:
 +
  enum TipoEvento {Payload, Quadro, Timeout};
 +
 
 +
  // esta struct descreve um Evento
 +
  struct Evento {
 +
    TipoEvento tipo;
 +
    Frame * frame_ptr;
 +
 
 +
    // construtor sem parâmetros: cria um Evento Timeout
 +
    Evento(): tipo(Timeout) {}
 +
 
 +
    // construtor com parâmetros: cria um evento Payload ou Quadro
 +
    // o objeto Frame representa tanto um payload quanto um quadro
 +
    Evento(TipoEvento t, Frame * a_frame) : tipo(t), frame_ptr(a_frame) {}
 +
  };
 +
 
 +
  // executa a MEF, passando como parâmetro um evento
 +
  void handle_fsm(Evento & e);
 +
};
 +
</syntaxhighlight>
 +
 
 +
... e na versão Python (note o uso de [https://dev.to/dstarner/using-pythons-type-annotations-4cfe type annotation], [https://docs.python.org/3/library/enum.html enum], e [https://www.attrs.org/en/stable/ attrs]):
 +
 
 +
<syntaxhighlight lang=python>
 +
from enum import Enum
 +
import attr
 +
 
 +
class TipoEvento(Enum):
 +
  'Identificadores para tipos de eventos'
 +
  Payload = 1
 +
  Timeout = 2
 +
  Quadro = 3
 +
 
 +
@attr.s
 +
class Evento:
 +
  'Representa um evento, contendo seu tipo e os dados a ele associados'
 +
  tipo = attr.ib(default=TipoEvento.Timeout)
 +
  msg = attr.ib(factory=bytes)
 +
 
 +
 
 +
class ARQ (Layer):
 +
  # demais métodos
 +
 
 +
  def handle_fsm(e:Evento):
 +
    '''executa a MEF, passando como parâmetro um evento'''
 +
    pass
 +
 
 +
</syntaxhighlight>
 +
 
 +
 
 +
<!-- = As sequências de processamento do protocolo =
  
 
O protocolo até o momento apresenta funcionalidades elementares que o tornam capaz de estabelecer enlaces rudimentares. Dois blocos funcionais importantes foram definidos:
 
O protocolo até o momento apresenta funcionalidades elementares que o tornam capaz de estabelecer enlaces rudimentares. Dois blocos funcionais importantes foram definidos:
Linha 111: Linha 205:
 
Assim, devem-se:
 
Assim, devem-se:
 
# '''Definir um modelo de software para o protocolo:''' do ponto de vista da estrutura, parece mais simples que cada subcamada seja implementada como uma classe, e que o protocolo como um todo seja uma [http://www.cleibsonalmeida.blog.br/site/uml-composicao-vs-agregacao/ composição] de objetos dessas classes. Do ponto de vista do comportamento, deve-se especificar como a aplicação interage com o protocolo, e como os diferentes eventos são tratados pelo protocolo.
 
# '''Definir um modelo de software para o protocolo:''' do ponto de vista da estrutura, parece mais simples que cada subcamada seja implementada como uma classe, e que o protocolo como um todo seja uma [http://www.cleibsonalmeida.blog.br/site/uml-composicao-vs-agregacao/ composição] de objetos dessas classes. Do ponto de vista do comportamento, deve-se especificar como a aplicação interage com o protocolo, e como os diferentes eventos são tratados pelo protocolo.
# '''Investigar técnicas para atendimento de eventos:''' o protocolo deve ser capaz de atender eventos conforme a necessidade. Isso envolve identificar mecanismos e facilidades apropriados da plataforma de software (sistema operacional, bibliotecas de programação).
+
# '''Investigar técnicas para atendimento de eventos:''' o protocolo deve ser capaz de atender eventos conforme a necessidade. Isso envolve identificar mecanismos e facilidades apropriados da plataforma de software (sistema operacional, bibliotecas de programação). Na verdade, isso já foi estudado quando se viu a [[PTC29008:_Projeto_1:_Integração_com_subsistema_de_rede_do_Linux|integração do protocolo com o subsistema de rede do Linux]].
 +
-->
 +
 
 +
== Atividade ==
 +
 
 +
# Implemente a garantia de entrega do seu protocolo, levando em conta os tipos de eventos que devem ser tratados
 +
 
 +
<!-- = Conjunto de mensagens (vocabulário) e regras de procedimento (gramática) =
 +
 
 +
O protocolo proposto no projeto 1 deve ser especificado. Isso implica sua descrição sem ambiguidades, para que possa ser corretamente implementado. A especificação envolve a definição do serviço oferecido, seu vocabulário e sintaxe, sua gramática, e a verificação de seu comportamento. Sua implementação se chama '''entidade de protocolo''', sendo composta por software e (por vezes) hardware.
 +
 
 +
 
 +
[[imagem:PTC-Protocolo-1.png|600px]]
 +
<br>''Diagrama simplificado da entidade de protocolo''
 +
 
 +
 
 +
A entidade de protocolo a ser desenvolvida implica pelo menos:
 +
* Especificar e implementar a interface de acesso ao protocolo para seus usuários.
 +
* Definir um vocabulário de mensagens, e a sintaxe abstrata dessas mensagens.
 +
* Modelar as regras de procedimento, que determinam as sequências de mensagens e eventos aceitas pelo protocolo.
 +
* Especificar a codificação das mensagens, o que se denomina sua sintaxe concreta.
 +
 
 +
== Vocabulário ==
 +
 
 +
Um protocolo envolve intercâmbio de mensagens entre duas ou mais entidades. O conjunto de mensagens que compõe o protocolo é chamado de ''vocabulário''.
 +
 
 +
Ex: um protocolo do tipo ''stop-and-wait'' possui um vocabulário dado por:
 +
 
 +
<math>M = \lbrace data_0, ~data_1, ~ack_0, ~ack_1 \rbrace</math>
 +
 
 +
 
 +
Essas mensagens podem ser usadas em sequências como mostrado neste diagrama de sequência temporal:
 +
 
 +
[[imagem:PTC-Stop-wait.png]]
 +
 
 +
 
 +
Cada mensagem carrega alguma informação composta por dados (o conteúdo gerado pela aplicação) e meta-dados (o conteúdo de controle gerado e usado pelo próprio protocolo). O formato das mensagens é dado pela '''sintaxe'' do protocolo, e existem diferentes métodos para sua descrição. Esse aspecto do protocolo deve ser trabalhado mais adiante.
 +
 
 +
 
 +
== Regras de procedimento ==
  
== Diferenciação de eventos nas MEF do protocolo ==
+
Intercâmbios de mensagens entre entidades de um protocolo devem respeitar regras quanto às sequências válidas de mensagens. O conjunto dessas regras é chamado de ''regras de procedimento'' (''procedure rules'').
  
O componente ARQ está sujeito a pelo menos três tipos de eventos:
 
* '''payload''': notificado quando a aplicação chama o método ''envia'' do Protocolo
 
* '''quadro vindo do Enquadramento''': notificado pelo Enquadramento por meio do método ''receive''
 
* '''timeout''': notificado de alguma forma ainda a ser determinada
 
  
 +
Um protocolo é um sistema a eventos-discretos. Isso significa que as ações em um protocolo ocorrem em instantes pontuais, e não continuamente. Essas ações, ou acontecimentos, são chamadas de ''eventos''. Por exemplo, a recepção ou envio de uma mensagem, a ocorrência de timeout, o início ou término de uma sessão são eventos ao longo de uma comunicação. Assim, um protocolo interage com seu ambiente (canal de comunicação, usuário), sendo acionado por eventos (ex: recepção de mensagem) que são respondidos com a realização de ações (ex: envio de mensagem). Seu comportamento depende do histórico de eventos passados, o que é chamado de estado. Esse tipo de sistema demanda modelos específicos para a descrição das sequências possíveis de eventos, incluindo a informação sobre o estado do protocolo.
  
O componente Enquadramento, por sua vez, responde a dois eventos:
 
* '''byte''': notificado pela Serial por meio de seu método ''read''
 
* '''timeout''': notificado de alguma forma ainda a ser determinada
 
  
 +
Um diagrama de sequência temporal, como mostrado no exemplo do protocolo stop-and-wait, apesar de ilustrativo não pode ser usado para especificar as regras de um protocolo. Esse tipo de diagrama é útil para apresentar uma sequência específica de troca de mensagens, mas não todas as sequências possíveis. Quer dizer, ele não tem '''expressividade''' para especificar todas as possíveis sequências de mensagens durante as comunicações. Outros tipos de diagramas e métodos formais devem ser usados nesse caso.
  
Esses eventos devem ser tratados por meio das respectivas máquinas de estados. Para diferenciá-los, uma forma é declarar um tipo Evento privativo, o qual encapsule o tipo de evento e os dados a ele associados. Por exemplo, no caso do ARQ:
+
== Máquinas de Estados Finitos ==
  
<syntaxhighlight lang=c>
+
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-8.pdf Capítulo 8 de ''Design and Validation of Computer Protocols'']
class ARQ {
 
public:
 
  // métodos públicos
 
  
private:
 
  enum TipoEvento {Payload, Quadro, Timeout};
 
  
  // esta struct descreve um Evento
+
O protocolo ''stop-and-wait'' usado como exemplo envia uma mensagem por vez, aguardando sua confirmação para enviar uma nova mensagem. Caso a confirmação não seja recebida, a última mensagem é retransmitida. Um exemplo de protocolo que usa esse tipo de mecanismo de controle de erros é o MAC CSMA/CA do padrão IEEE 802.11. Uma versão para o ''stop-and-wait'' usa um bit para numerar mensagens, de forma a evitar a duplicação de mensagens no receptor. Assim, seu vocabulário é composto pelas mensagens ''msg0, msg1, ack0, ack1''. As regras de procedimento desse protocolo podem ser ilustradas usando diagramas de '''máquinas de estados finitos''', como mostrado a seguir:
  struct Evento {
 
    TipoEvento tipo;
 
    char * ptr;
 
    int bytes;
 
  
    // construtor sem parâmetros: cria um Evento Timeout
 
    Evento() { tipo = Timeout;}
 
  
    // construtor com parâmetros: cria um evento Payload ou Quadro
+
{| border=0
    Evento(TipoEvento t, char * p, int len) : tipo(t), ptr(p), bytes(len) {}
+
| [[imagem:PTC-Stop-and-wait-fsm-tx.png|400px]]<br><center>''Máquinas de estados finitos do transmissor para o ARQ stop-and-wait''</center> || [[imagem:PTC-Stop-and-wait-fsm-rx.png|400px]]<br><center>''Máquinas de estados finitos do receptor para o ARQ stop-and-wait''</center>
  };
+
|}
  
  // executa a MEF, passando como parâmetro um evento
 
  void handle(Evento & e);
 
};
 
</syntaxhighlight>
 
  
== O formato de quadros no protocolo ==
+
Uma '''máquina de estados finitos''' (ou simplesmente MEF) é composta de um conjunto de estados (as bolas) e transições (as setas). Um estado representa uma instância de comportamento do sistema (ex: ''ocioso'', ''espera''), e uma transição representa uma mudança de estado. Uma transição possui um estado inicial e um ou mais estados finais, além de uma condição para que ocorra (a isso se chama ''evento''). Esse modelo básico de MEF possui expressividade para modelar alguns sistemas, e apresenta diversas propriedades importantes para analisar o comportamento desses sistemas.
  
O quadro possui um cabeçalho com dois campos:  
+
Formalmente, uma MEF é definida pela tupla ''(Q, q0, S, T)'', sendo:
* '''Controle''': contém tipo de quadro (ACK ou DATA) e número de sequẽncia (0 ou 1)
+
* '''Q:''' um conjunto não-vazio de estados
* '''Proto:''' contém o tipo de conteúdo transportado pelo quadro
+
* '''q0:''' um elemento de ''Q'' denominado estado inicial
 +
* '''S:''' um conjunto de eventos (ou mensagens), o qual forma um vocabulário
 +
* '''T:''' uma relação de transição de estados
  
O campo FCS, ao final do quadro, contém o valor do [https://tools.ietf.org/html/rfc1662#appendix-C código CRC-16-CCITT]. Esse campo ocupa 2 bytes, sendo o primeiro o LSB (''Least Significant Byte'') do código CRC, e o último o MSB.
+
A relação de transição de estados ''T'' é usualmente representada por uma tabela cujas linhas contêm o ''estado inicial'', uma ''ação'', e o ''estado final''. No caso da MEF do transmissor do protocolo ''stop-and-wait'', essa tabela poderia ser:
  
 +
{| border=1
 +
!Estado inicial
 +
!Ação
 +
!Estado final
 +
|-
 +
|0 || envia m0 || 1
 +
|-
 +
|1 || recebe ack1 || 2
 +
|-
 +
|1 || recebe ack0 || 0
 +
|-
 +
|1 || timeout || 0
 +
|-
 +
|2 || envia m1 || 3
 +
|-
 +
|3 || recebe ack0 || 0
 +
|-
 +
|3 || recebe ack1 || 2
 +
|-
 +
|3 || timeout || 2
 +
|}
  
[[imagem:PTC-Quadro-proto1.jpg]]
 
<br><br>''O formato de um quadro''
 
  
== Atividade ==
+
Para o projeto do '''protocolo de comunicação''', a MEF tem duas finalidades:
 +
* ''Modelar as regras de procedimento do protocolo:'' a MEF torna possível conceber o comportamento do protocolo, definindo o que deve ser feito a depender das mensagens recebidas e transmitidas, entre outros eventos. Além disso, mecanismos internos do protocolo também podem ser modelados com MEF (ex: enquadramento).
 +
* ''Verificar o comportamento do protocolo:'' o projeto do protocolo pode esconder problemas sutis e difíceis de identificar. Existem técnicas e ferramentas que auxiliam na verificação da correção das regras de procedimento do protocolo, evidenciando problemas tais como impasses e perdas de sincronismo.
  
# Implemente a garantia de entrega do seu protocolo, levando em conta os tipos de eventos que devem ser tratados
+
Num primeiro momento, as MEF serão utilizadas para modelar o protocolo de comunicação. Seu uso para verificar a correção do protocolo deve ser realizado após ter sido construído um protótipo.
 +
-->

Edição atual tal como às 16h20min de 29 de maio de 2020

Próxima aula



A garantia de entrega pode ser definida como um serviço do protocolo que possibilita que o transmissor se certifique de que uma mensagem foi entregue ou não ao destino. Enquanto uma mensagem não tiver sua entrega assegurada, ela permanece na fila de saída mantida no transmissor pelo protocolo. Esse serviço tipicamente é implementado usando algum mecanismo ARQ.


Mecanismos ARQ (Automatic Repeat reQuest) podem ser incorporados a protocolos para garantir a entrega de mensagens, preservando a ordem de envio e buscando eficiência no uso do canal. Tais mecanismos se baseiam em alguns elementos:

  • Mensagens de dados
  • Mensagens de confirmação positiva (ACK) e negativa (NAK)
  • Numeração de sequência de mensagens
  • Retransmissão de mensagens perdidas ou recusadas

Maiores detalhes podem ser lidos nesta descrição de mecanismos ARQ, incluindo uma análise simplificada de seu desempenho.

Escolha do mecanismo ARQ a ser utilizado no protocolo de enlace

Qual dentre os mecanismos ARQ deve ser o mais apropriado para o tipo de enlace do protocolo ?


Dentre os três mecanismos ARQ elementares, pare-e-espere atende plenamente a necessidade de garantia de entrega e eficiência no uso do canal de comunicação do protocolo de enlace. Isso se conclui com a análise de utilização do canal usando pare-e-espere. Sendo B a taxa de bits, F o tamanho de quadro, e L a distância a ser percorrida pelo sinal no enlace, a utilização do canal pode ser estimada desta forma:












Portanto, a utilização do meio seria no máximo em torno de 0.99 (ou 99%).

Modelagem do mecanismo ARQ

O mecanismo ARQ pare-e-espere deve ser modelado antes de ser implementado no protocolo. Sua disposição na estrutura do protocolo deve ser esta:


PTC-Protocolo-estrutura2.jpg


Assim, a subcamada ARQ envia e recebe quadros de dados e de confirmação da subcamada inferior (detecção de erros + enquadramento). O mecanismo ARQ implementado nessa subcamada pode ser modelado como duas máquinas de estado finitas: uma para transmissão e outra para recepção:

PTC-proj1-Mef-arq-tx.jpg
MEF para a transmissão do ARQ


PTC-proj1-Mef-arq-rx.jpg
MEF para a recepção do ARQ


Duas questões despontam quanto à modelagem com máquinas de estados finitos:

  1. As MEF projetadas podem ser minimizadas (terem menos estados) ?
  2. As MEF podem ser combinadas em uma nova MEF que contenha o comportamento tanto do transmissor quanto do receptor ?

Para investigar essas questões, devem-se estudar máquinas de estados finitos no contexto de protocolos de comunicação. MEF é uma ferramenta de modelagem útil para representar o comportamento ou regras de procedimento (proceding rules) de protocolos.

Atividade: MEF da garantia de entrega do protocolo de comunicação

  1. Modele a garantia de entrega como uma MEF, de forma que se combinem os comportamentos de receptor e transmissor em uma única MEF
  2. Implemente sua garantia de entrega como uma nova subcamada de seu protocolo !

A modelagem da garantia de entrega

A garantia de entrega deve ser feita com um mecanismo ARQ do tipo pare-e-espere. A máquina de estados finitos a seguir resume o comportamento do ARQ para o protocolo de comunicação.


PTC-Mef-arq2.jpg

A MEF do ARQ: N é o número de sequência de envio, e M o de recepção

OBS:

  • M: numero de sequência de recepção
  • N: numero de sequência de transmissão


O formato de quadros no protocolo


O quadro possui um cabeçalho com dois campos:

  • Controle: contém tipo de quadro (ACK ou DATA) e número de sequẽncia (0 ou 1)
  • Proto: contém o tipo de conteúdo transportado pelo quadro (OBS: este campo existe somente em quadros do tipo DATA)

O campo FCS, ao final do quadro, contém o valor do código CRC-16-CCITT. Esse campo ocupa 2 bytes, sendo o primeiro o LSB (Least Significant Byte) do código CRC, e o último o MSB.


PTC-Quadro-proto1.jpg

O formato de um quadro

Diferenciação de eventos nas MEF do protocolo

O componente ARQ está sujeito a pelo menos três tipos de eventos:

  • payload: notificado quando a aplicação chama o método envia do Protocolo
  • quadro vindo do Enquadramento: notificado pelo Enquadramento por meio do método notifica
  • timeout: notificado pelo poller via método handle_timeout


O componente Enquadramento, por sua vez, responde a dois eventos:

  • byte: notificado pelo poller via método handle
  • timeout: notificado pelo poller via método handle_timeout


Esses eventos devem ser tratados por meio das respectivas máquinas de estados. Para diferenciá-los, uma forma é declarar um tipo Evento, o qual encapsule o tipo de evento e os dados a ele associados. Por exemplo, no caso do ARQ na versão C++ (a classe Frame não está descrita):

class ARQ : public Layer {
 public:
   // métodos públicos

 private:
  enum TipoEvento {Payload, Quadro, Timeout};

  // esta struct descreve um Evento
  struct Evento {
    TipoEvento tipo;
    Frame * frame_ptr;

    // construtor sem parâmetros: cria um Evento Timeout
    Evento(): tipo(Timeout) {}

    // construtor com parâmetros: cria um evento Payload ou Quadro
    // o objeto Frame representa tanto um payload quanto um quadro
    Evento(TipoEvento t, Frame * a_frame) : tipo(t), frame_ptr(a_frame) {}
  };

  // executa a MEF, passando como parâmetro um evento
  void handle_fsm(Evento & e);
};

... e na versão Python (note o uso de type annotation, enum, e attrs):

from enum import Enum
import attr

class TipoEvento(Enum):
  'Identificadores para tipos de eventos'
  Payload = 1
  Timeout = 2
  Quadro = 3

@attr.s
class Evento:
  'Representa um evento, contendo seu tipo e os dados a ele associados'
  tipo = attr.ib(default=TipoEvento.Timeout)
  msg = attr.ib(factory=bytes)


class ARQ (Layer):
  # demais métodos

  def handle_fsm(e:Evento):
    '''executa a MEF, passando como parâmetro um evento'''
    pass


Atividade

  1. Implemente a garantia de entrega do seu protocolo, levando em conta os tipos de eventos que devem ser tratados