PTC29008: Gerenciamento de Sessão

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:

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.

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

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

• Versão atualizada do poller (C++)

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.

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.

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)