3. O Protocolo DCCP
O Datagram Congestion Control Protocol, desde 2006, é um padrão proposto na Internet Engineering Task Force - IETF; esse, seguindo os requisitos apontados na seção 2.3, tem como proposta a versatilidade no que diz respeito às aplicações multimídia. Sendo um protocolo pensado para a modalidade real-time, o DCCP não possui garantias de entrega confiável. Sua principal característica é a possibilidade de oferecimento de mais de uma opção de controle de congestionamento.
Nas próximas sub-seções, o protocolo é descrito com mais detalhes.
3.1 Pacotes padrão
Os protocolo DCCP possui, por padrão, dez tipos de pacotes: DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close, DCCP-Reset, DCCP-Sync e DCCP-SyncAck.
3.1.1 Formato dos pacotes
Todo pacote que desempenha funções do DCCP é acompanhado de um cabeçalho genérico. A Figura 1 mostra a representação dos pacotes.
Figura 1
3.1.1.1 Cabeçalho Genérico
O cabeçalho genérico do DCCP, Figura 2, possui tamanho variável, dependendo do valor do campo X.
Figura 2 -Source and Destination port - 16 bits cada campo: expressos os valores das portas de remetente e da porta de destino;
-Data Offset - 8 bits: tamanho do cabeçalho do pacote;
-CCVal - 4 bits: especifica o código do tipo de controle de congestionamento usado;
-CsCov - 4 bit: informa qual parte do pacote vai ser checada pelo algoritmo de Checksum, permitindo a tolerância à corrupção de dados;
-Checksum - 16 bits: Soma de verificação do pacote;
-Res - 3 bits: campo reservado;
-Type - 4 bits: especifica o tipo do pacote;
-X - 1 bit: Especifica o tamanho dos números de sequência usados nos pacotes. Quando X=1, Sequence Number possui 48 bits, quando X=0, 24 bits;
-Sequence Number - 24 ou 48 bits: número de sequência dos pacotes. Acrescido de um por pacote;
-Acknowledgement Number - 24 ou 48 bits: expressa o maior número de sequência recebido por um pacote acknowledgement - Ack.
3.1.2 Tipos de pacotes
3.1.2.1 DCCP-Request
Pacote usado pelo cliente na inicialização da conexão. Imagem abaixo (Figura 3). Os pacote deve usar o campo X com o valor 1.
Figura 3 -Service Code - 32 bits: informa o tipo de aplicação que deseja realizar a conexão.
3.1.2.2 DCCP-Response
Resposta do servidor ao pacote de tipo DCCP-Request. O pacote deve usar o campo X com o valor 1.
Figura 4
3.1.2.3 DCCP-Data
O pacote DCCP-Data carrega os dados transferidos.
Figura 5
3.1.2.4 DCCP-Ack e DCCP-DataAck
Os pacotes DCCP-Ack e DCCP-DataAck são usados para acknowledgements, sendo que o segundo transporta, também, dados. Os pacotes podem possuir opções.
Figura 6
3.1.2.5 DCCP-CloseReq e DCCP-Close
Pacotes participam do fechamento da conexão. Cliente e servidor podem enviar pacotes DCCP-Close, mas apenas o esse pode enviar requisições de encerramento DCCP-CloseReq. Os pacotes devem usar o campo X com o valor 1.
Figura 7
3.1.2.6 DCCP-Reset
Pacote termina a conexão. O pacote deve usar o campo X com o valor 1.
Figura 8
-Reset Code - 8 bits: motivo do encerramento da conexão.
Figura 9
-Data 1, 2 e 3 - 8 bits cada: informação adicional sobre encerramento.
-Application Data Error: Descrição, em linguagem legível, de erros ocorridos.
3.1.2.7 DCCP-Sync e DCCP-SyncAck
Pacotes auxiliam na recuperação de sincronização após perdas sucessivas de pacotes. Os pacotes devem usar o campo X com o valor 1.
Figura 10
3.1.3 Campo Options
Qualquer pacote DCCP pode conter opções. Cada opção tem como tamanho múltiplos de 8 bits e opções do tipo Padding devem ser utilizadas para preencher o espaço até o fim do campo.
Figura 11
3.1.3.1 Negociação de Features
Geralmente no início das conexões, o cliente e o servidor negociam os parâmetros que serão utilizados durante sua comunicação. As opções 32-35, na Figura 11, expressam as opções usadas pelos pacotes para a realização da tarefa: as opções Change iniciam a negociação, as Confirm realizam o término; opções L são enviadas por quem inicia a negociação, e opções R, para quem é solicitada a mudança. Pacotes com opções de negociação são retransmitidos.
Nas negociações, são especificados o tipo de parâmetro que é desejada a mudança e a ordem de preferência daquela estação para aquele campo. “Change L(CCID, 3 2)” deseja a mudança do parâmetro CCID, e a ordem de preferência é expressa após a vírgula; “Confirm R(CCID, 3, 3 2)” diz a confirmação da segunda estação, confirmando o parâmetro 3 e expressando sua ordem de preferência.
3.2 Conexão
O DCCP é um protocolo unicast com troca de mensagens bidirecional: é possível a troca de dados por ambas as partes comunicantes. Sua conexão é realizada por duas conexões unidirecionais separadas, chamadas de meia-conexões, que são definidas como dados sendo enviados por uma estação, e o ACK correspondente respondido pela outra parte. Sua inicialização é feita por um three-way handshake.
A conexão é caracterizada por estados e uma sequência de pacotes bem definidos. A Figura 12 mostra um exemplo, especificando os estados de conexão.
Figura 12
-CLOSED: não há conexão;
-LISTEN: estação em estado passivo;
-REQUEST: cliente entra nesse estado após o envio de um pacote tipo DCCP-Request;
-RESPOND: servidor entra nesse estado após o recebimento de um pacote do tipo DCCP-Request;
-PARTOPEN: terceira parte do three-way handshake. Cliente entra nesse estado após o recebimento de um pacote do tipo DCCP-Response;
-OPEN: estado central de troca de dados;
-CLOSEREQ: servidor entra nesse estado quando faz requisita o término da conexão;
-CLOSING: servidor e cliente entram nesse estado para fechar a conexão;
-TIMEWAIT: cliente e servidor entram nesse estado após o término da conexão por determinado tempo, para evitar a entrega de pacotes antigos.
Imagens e exemplos reproduzidos da RFC 4340.