Mudanças entre as edições de "PTC29008: Gerenciamento de Sessão"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
(Criou página com '__toc__ A próxima função do protocolo de enlace envolve o estabelecimento, manutenção e terminação de conexão. Sendo um protocolo ponto-a-ponto, deve-se estabelecer um ...')
 
 
(45 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 1: Linha 1:
 +
[[PTC29008:_Projeto_2:_Protocolo_de_aplicação|Próxima aula]]
 +
 
__toc__
 
__toc__
  
Linha 21: Linha 23:
 
# Ao receber a mensagem ''CC'', o iniciador já pode enviar dados pela conexão
 
# Ao receber a mensagem ''CC'', o iniciador já pode enviar dados pela conexão
 
# Ao receber a terceira mensagem, o outro participante também pode enviar dados pela conexão. OBS: essa terceira mensagem pode ser uma mensagem de dados comum, pois ela serve para que o outro participante saiba que a conexão foi estabelecida com os parâmetros negociados.
 
# Ao receber a terceira mensagem, o outro participante também pode enviar dados pela conexão. OBS: essa terceira mensagem pode ser uma mensagem de dados comum, pois ela serve para que o outro participante saiba que a conexão foi estabelecida com os parâmetros negociados.
 +
 +
 +
'''Avalie seu conhecimento'''
 +
# Identifique um protocolo que use estabelecimento em duas vias, e outro que estabeleça em três vias.
 +
# Reflita sobre que restrições teria um protocolo que estabelecesse uma sessão bidirecional usando negociação em duas vias
  
 
== Manutenção de conexão ==
 
== Manutenção de conexão ==
Linha 48: Linha 55:
  
 
Por fim, pode acontecer de mensagens de terminação de conexão serem perdidas. Isso manteria um ou mesmo ambos participantes esperando indefinidamente pelo término de conexão. Uma solução para evitar essa situação é usar ''timeout'' para a espera de confirmação da mensagem de término de conexão.
 
Por fim, pode acontecer de mensagens de terminação de conexão serem perdidas. Isso manteria um ou mesmo ambos participantes esperando indefinidamente pelo término de conexão. Uma solução para evitar essa situação é usar ''timeout'' para a espera de confirmação da mensagem de término de conexão.
 +
 +
 +
'''Avalie seu conhecimento'''
 +
# Analise um protocolo hipotético do tipo mestre-escravo, em que apenas o lado escravo tem o poder de terminar uma sessão. Pense em diferentes situações de terminação, e como elas funcionariam.
  
 
== Atividade ==
 
== Atividade ==
  
−
# Identifique em que parte da estrutura do seu protocolo devem se encaixar o gerenciamento de conexão
+
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/poller.tgz Versão atualizada do poller (C++)]
 +
 
 +
 
 +
# Identifique em que parte da estrutura do seu protocolo deve se encaixar o gerenciamento de conexão
 
# Modele o ''gerenciamento de conexão'' do seu protocolo de enlace.
 
# Modele o ''gerenciamento de conexão'' do seu protocolo de enlace.
  
−
== Conclusão do projeto 1 ==
 
  
−
O protocolo desenvolvido no projeto 1 se destina a transportar dados entre placas de aquisição de dados e servidores de coleta. O protótipo se baseia em um Arduino UNO como placa de aquisição, e um PC como servidor de coleta. As funções do protocolo são:
+
[[imagem:PTC_Sessao-simetrico.jpg|700px]]
 +
<br>''MEF do gerenciamento de conexão do protocolo de enlace''
 +
 
 +
 
 +
'''Observações:'''
 +
* No estado ''CON'', o envio de mensagem KR ocorre somente se nada for recebido após um tempo ''CheckInterval''. Assim, a cada vez que uma mensagem for recebida no estado ''CON'', o timer deve ser reiniciado.
 +
* A subcamada ''ARQ'' deve tentar entregar uma mensagem em até ''LimitRetries'' tentativas. Se não conseguir entregá-la, deve notificar a subcamada superior (''Sessão'') de que houve um erro fatal. A subcamada ''Sessão'' deve desconectar imediatamente quando da ocorrência de um erro fatal.
 +
* Pode ser útil uma subcamada desativar temporariamente sua subcamada superior. Por exemplo, quando ''Enquadramento'' começa a receber um quadro, o envio de um novo quadro vindo de ''ARQ'' deveria ser inibido. Da mesma forma, quando ''ARQ'' envia um quadro de dados e está aguardando a recepção de sua confirmação, ''Sessão'' não deveria pedir o envio de uma nova mensagem. A classe ''Callback'' possui os métodos ''enable'' e ''disable'', que servem respectivamente para inibir ou ativar o monitoramento do descritor de arquivos do ''Callback'' (obs: o timeout do ''Callback'' não é afetado por esses métodos). No protocolo, a classe ''Layer'' poderia redefinir esses métodos, de forma a propagar para as subcamadas superiores a ação de inibir ou ativar.
 +
 
 +
 
 +
'''Legenda dos estados:'''
 +
* ''DISC:'' desconectado
 +
* ''HAND1:'' em aguardo por confirmação de pedido de conexão
 +
* ''HAND2:'' em aguardo por confirmação de pedido de conexão, após receber pedido de conexão do outro lado
 +
* ''HAND3:'' em aguardo por pedido de conexão
 +
* ''CON:'' conectado
 +
* ''CHECK:'' aguardando resposta para ''Keep Alive''
 +
* ''HALF1:'' em estado de terminação de enlace (''half-close''), quando tomou a iniciativa de terminá-lo
 +
* ''HALF2:'' em estado de terminação de enlace (''half-close''), quando o outro lado tomou a iniciativa
 +
* '''Timeout''': timeout de espera por um evento
 +
* '''Erro''': notificação de erro recebida de ARQ (quadro não entregue)
 +
* '''app?pld''': payload recebido da camada superior
 +
* '''app!pld''': payload enviado para camada superior
 +
 
 +
 
 +
 
 +
'''Legenda das transições:'''
 +
* ''CR'': pedido de conexão (''Connect.request'')
 +
* ''CC'': confirmação de conexão (''Connect.confirm'')
 +
* ''DR'': pedido de desconexão (''Disconnect.request'')
 +
* ''DC'': confirmação de desconexão (''Disconnect.confirm'')
 +
* ''KR'': pedido de ''keep alive''
 +
* ''KC'': confirmação de ''keep alive''
 +
 
 +
== Formato de quadro do gerenciamento de sessão ==
 +
 
 +
O gerenciamento de sessão implica estender o formato de quadro do protocolo.
 +
 
 +
[[imagem:ptc-Quadro-proto1-sessao.jpg]]
 +
<br>''Quadro com campo para ID de sessão''
 +
 
 +
O campo ''ID Sessão'' contém um número que identifica a sessão negociada pelo gerenciamento de sessão. Na garantia de entrega (ARQ), quadros com ''ID Sessão'' diferente do negociado devem ser ignorados.
 +
 
 +
O campo ''Proto'' identifica o tipo de conteúdo contido no quadro (''Dados''). A tabela a seguir associa o tipo de conteúdo a valores predefinidos para o campo ''Proto'':
 +
 
 +
 
 +
{| border=1
 +
!Proto
 +
!Tipo de conteúdo
 +
|-
 +
|1 || Datagrama IPv4
 +
|-
 +
|2 ||Datagrama IPv6
 +
|-
 +
|255 || Mensagem de controle do gerenciamento de sessão
 +
|}
 +
 
 +
 
 +
Além dessa modificação no quadro do protocolo, é necessário definir um formato de mensagem específico para o gerenciamento de sessão. O campo ''Dados'' deve incluir um único octeto cujo conteúdo identifica o tipo de mensagem. A tabela a seguir define os valores para esse octeto:
 +
 
 +
{| border=1
 +
!Valor
 +
!Descrição
 +
|-
 +
|0 || CR (Connect request)
 +
|-
 +
|1 || CC (Connect confirm)
 +
|-
 +
|2 || KR (Keep Alive Request)
 +
|-
 +
|3 || KC (Keep Alive Confirm)
 +
|-
 +
|4 || DR (Disconnect Request)
 +
|-
 +
|5 || DC (Disconnect Confirm)
 +
|}
 +
 
 +
<!--
 +
= Conclusão do projeto 1 (parte 1) =
 +
 
 +
* [https://realpython.com/instance-class-and-static-methods-demystified/ Dica sobre métodos em Python]
 +
 
 +
 
 +
O protocolo desenvolvido no projeto 1 se destina a estabelecer enlaces ponto-a-ponto entre computadores. As funções do protocolo são:
 
* Enquadramento
 
* Enquadramento
 +
* Detecção de erros com CRC-16
 
* Garantia de entrega com ARQ do tipo pare-e-espere
 
* Garantia de entrega com ARQ do tipo pare-e-espere
−
* Controle de acesso ao meio
+
* Controle de acesso ao meio do tipo Aloha
 +
* Gerenciamento de sessão (conexão)
 +
 
 +
 
 +
A versão final do protocolo deve ser demonstrada com enlace entre dois computadores, usando o transceiver RF como camada física. Além disso, deve ser entregue um relatório contendo a especificação do protocolo e a documentação do software (ex: diagramas UML de classes e de atividade ou sequência; Pydoc; ...). O relatório deve ser entregue segundo o [https://github.com/ifsc-saojose/modelos-latex/tree/master/artigo/modelo-ifsc-proppi modelo de artigo/relatório técnico] disponibilizado pelo professor Emerson Mello.
 +
 
  
 +
''Datas importantes:''
 +
* '''15/10''': [https://moodle.sj.ifsc.edu.br/mod/assign/view.php?id=5093 entrega do relatório e código-fonte via Moodle]
 +
* '''18/10''': prazo para apresentação e demonstração do protocolo, em horário a combinar com o professor
  
−
A versão final do protocolo deve ser demonstrada com o Arduino e o PC, usando o transceiver RF como camada física. A apresentação do protocolo desenvolvido deve ser feita até dia 6/10, em horário a combinar com o professor. O relatório deve ser entregue segundo o [https://github.com/ifsc-saojose/modelos-latex/tree/master/artigo/modelo-ifsc-proppi modelo de artigo/relatório técnico] disponibilizado pelo professor Emerson Mello.
+
-->
−
* [https://moodle.sj.ifsc.edu.br/mod/assign/view.php?id=3514 Entrega do relatório via Moodle]
+
<!--
 +
'''Programas para teste:''' inclui um programa transmissor (tx) e um receptor (rx) compilados estaticamente. Quadros ACK possuem somente o campo de controle no cabeçalho, e não possuem dados, Use o transmissor com seu programa receptor, e vice-versa. Execute-os com opção -h para obter uma ajuda.
 +
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/teste_com_sessao.tgz Versão COM gerenciamento de sessão]: transmissor (tx) inicia e termina a conexão. Receptor (rx) aguarda pedido de conexão.
 +
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/teste_sem_sessao.tgz Versão SEM gerenciamento de sessão]: cabeçalho de quadro não tem campo id_sessao
 +
-->

Edição atual tal como às 10h40min de 20 de agosto de 2020

Próxima aula


A próxima função do protocolo de enlace envolve o estabelecimento, manutenção e terminação de conexão. Sendo um protocolo ponto-a-ponto, deve-se estabelecer um enlace entre as duas pontas participantes antes de poder transferir dados. Isso evita que as transmissões entre um par de participantes sejam confundidas com transmissões de outros pares.

Nas seções 5.2 e 5.3 do capítulo 5 do livro Protocol Engineering, 2nd ed, de Hartmut Konig, há uma explicação sobre o gerenciamento de conexões e diversas formas de implementá-la. No caso do protocolo de enlace, serão usados estabelecimento e terminação explícitos de conexões, e manutenção de conexão.

Estabelecimento de conexão

Para criar uma conexão deve-se:

  • estabelecer a conexão: ambos participantes devem se sincronizar para aceitar ou recusar a conexão
  • negociar parâmetros de conexão: a conexão pode envolver parâmetros operacionais do protocolo que devem ser comuns a ambos participantes. Como exemplo, citam-se tamanho máximo de PDU e identificador de conexão.

A sincronização entre os participantes implica a troca de mensagens, a qual pode ser feita com duas (2-way handshaking) ou 3 (3-way handshaking) mensagens:


PTC-2-way 3-way.png


A sincronização do tipo 2-way é adequada em comunicações unidirecionais, mas não para comunicações bidirecionais. Isso se deve ao fato de que a primeira mensagem (CR) contém parâmetros de conexão do participante que iniciou o processo, e a segunda mensagem (CC) contém parâmetros do outro participante. Se a mensagem CC for perdida, o participante iniciador da conexão não tem como saber se a conexão foi aceita e quais os parâmetros definidos pelo outro participante. Assim, uma terceira mensagem enviada pelo iniciador serve para que o outro participante saiba que a conexão foi estabelecida, e que assim ele pode usá-la para enviar dados. De forma resumida:

  1. Ao receber a mensagem CC, o iniciador já pode enviar dados pela conexão
  2. Ao receber a terceira mensagem, o outro participante também pode enviar dados pela conexão. OBS: essa terceira mensagem pode ser uma mensagem de dados comum, pois ela serve para que o outro participante saiba que a conexão foi estabelecida com os parâmetros negociados.


Avalie seu conhecimento

  1. Identifique um protocolo que use estabelecimento em duas vias, e outro que estabeleça em três vias.
  2. Reflita sobre que restrições teria um protocolo que estabelecesse uma sessão bidirecional usando negociação em duas vias

Manutenção de conexão

Um enlace pode ter momentos de ociosidade, quando não há mensagens de dados para serem transmitidas. Isso pode ser confundido com casos em que o enlace se rompe (ex: um dos participantes é desligado, ou o meio de comunicação é seccionado). Para evitar que um enlace rompido seja interpretado com um enlace ocioso (e vice-versa), o protocolo deve fazer a manutenção de conexão.

A manutenção de conexão pode ser feita com o envio periódico de mensagens de verificação. Por exemplo, o protocolo PPP usa mensagens Keep-Alive enviadas a cada 10 segundos para monitorar o estado do enlace. Se três mensagens Keep-Alive consecutivas forem perdidas, o enlace é terminado. Nesse caso, após um certo tempo (ex: 30 segundos) o protocolo PPP tenta restabelecer o enlace. O protocolo TCP também possui um mecanismo opcional para manutenção de conexão chamado de Keep Alive. Uma abordagem como essa poderia ser incluída no protocolo de enlace em desenvolvimento.

Terminação de conexão

A terminação de conexão implica duas necessidades:

  1. A sincronização entre os participantes quanto ao término da conexão (ambos participantes devem fechar a conexão)
  2. A garantia de que todas as mensagens de dados pendentes sejam entregues


A solução não é tão simples quanto parece. Uma discussão detalhada pode ser lida na seção 5.3.3 do livro Protocol Engineering, 2nd ed, de Hartmut Konig. Com base nessa explicação e no fato de que o protocolo de enlace em desenvolvimento é bidirecional, deve-se usar a terminação de conexão feita por ambos participantes do enlace. Assim um participante envia uma mensagem para terminação de conexão, e após sua confirmação entra-se em estado de conexão parcialmente fechada (half-close connection). O outro participante envia suas mensagens pendentes, e em seguida envia sua mensagem de terminação de conexão. Após a confirmação dessa última mensagem de terminação, a conexão é considerada terminada. A figura a seguir exemplifica esse procedimento.


PTC-Half-close.png


Uma simplificação pode ser feita se ambos participantes encerrarem a conexão simultaneamente. Nesse caso, a terminação pode ser sincronizada com três mensagens (3-way handshake):


PTC-3-way-close.png


Por fim, pode acontecer de mensagens de terminação de conexão serem perdidas. Isso manteria um ou mesmo ambos participantes esperando indefinidamente pelo término de conexão. Uma solução para evitar essa situação é usar timeout para a espera de confirmação da mensagem de término de conexão.


Avalie seu conhecimento

  1. Analise um protocolo hipotético do tipo mestre-escravo, em que apenas o lado escravo tem o poder de terminar uma sessão. Pense em diferentes situações de terminação, e como elas funcionariam.

Atividade


  1. Identifique em que parte da estrutura do seu protocolo deve se encaixar o gerenciamento de conexão
  2. Modele o gerenciamento de conexão do seu protocolo de enlace.


PTC Sessao-simetrico.jpg
MEF do gerenciamento de conexão do protocolo de enlace


Observações:

  • No estado CON, o envio de mensagem KR ocorre somente se nada for recebido após um tempo CheckInterval. Assim, a cada vez que uma mensagem for recebida no estado CON, o timer deve ser reiniciado.
  • A subcamada ARQ deve tentar entregar uma mensagem em até LimitRetries tentativas. Se não conseguir entregá-la, deve notificar a subcamada superior (Sessão) de que houve um erro fatal. A subcamada Sessão deve desconectar imediatamente quando da ocorrência de um erro fatal.
  • Pode ser útil uma subcamada desativar temporariamente sua subcamada superior. Por exemplo, quando Enquadramento começa a receber um quadro, o envio de um novo quadro vindo de ARQ deveria ser inibido. Da mesma forma, quando ARQ envia um quadro de dados e está aguardando a recepção de sua confirmação, Sessão não deveria pedir o envio de uma nova mensagem. A classe Callback possui os métodos enable e disable, que servem respectivamente para inibir ou ativar o monitoramento do descritor de arquivos do Callback (obs: o timeout do Callback não é afetado por esses métodos). No protocolo, a classe Layer poderia redefinir esses métodos, de forma a propagar para as subcamadas superiores a ação de inibir ou ativar.


Legenda dos estados:

  • DISC: desconectado
  • HAND1: em aguardo por confirmação de pedido de conexão
  • HAND2: em aguardo por confirmação de pedido de conexão, após receber pedido de conexão do outro lado
  • HAND3: em aguardo por pedido de conexão
  • CON: conectado
  • CHECK: aguardando resposta para Keep Alive
  • HALF1: em estado de terminação de enlace (half-close), quando tomou a iniciativa de terminá-lo
  • HALF2: em estado de terminação de enlace (half-close), quando o outro lado tomou a iniciativa
  • Timeout: timeout de espera por um evento
  • Erro: notificação de erro recebida de ARQ (quadro não entregue)
  • app?pld: payload recebido da camada superior
  • app!pld: payload enviado para camada superior


Legenda das transições:

  • CR: pedido de conexão (Connect.request)
  • CC: confirmação de conexão (Connect.confirm)
  • DR: pedido de desconexão (Disconnect.request)
  • DC: confirmação de desconexão (Disconnect.confirm)
  • KR: pedido de keep alive
  • KC: confirmação de keep alive

Formato de quadro do gerenciamento de sessão

O gerenciamento de sessão implica estender o formato de quadro do protocolo.

Ptc-Quadro-proto1-sessao.jpg
Quadro com campo para ID de sessão

O campo ID Sessão contém um número que identifica a sessão negociada pelo gerenciamento de sessão. Na garantia de entrega (ARQ), quadros com ID Sessão diferente do negociado devem ser ignorados.

O campo Proto identifica o tipo de conteúdo contido no quadro (Dados). A tabela a seguir associa o tipo de conteúdo a valores predefinidos para o campo Proto:


Proto Tipo de conteúdo
1 Datagrama IPv4
2 Datagrama IPv6
255 Mensagem de controle do gerenciamento de sessão


Além dessa modificação no quadro do protocolo, é necessário definir um formato de mensagem específico para o gerenciamento de sessão. O campo Dados deve incluir um único octeto cujo conteúdo identifica o tipo de mensagem. A tabela a seguir define os valores para esse octeto:

Valor Descrição
0 CR (Connect request)
1 CC (Connect confirm)
2 KR (Keep Alive Request)
3 KC (Keep Alive Confirm)
4 DR (Disconnect Request)
5 DC (Disconnect Confirm)


Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=PTC29008:_Gerenciamento_de_Sessão&oldid=169729”