Resumo

  • QUIC DATAGRAM leva um datagrama de aplicação de forma não confiável e preserva sua fronteira, sem retransmissão nem ordenação em relação a outras mensagens DATAGRAM.
  • max_datagram_frame_size sinaliza suporte direcional e tamanho, não capacidade, entrega ou processamento garantidos.
  • O ACK prova processamento na camada de transporte, não confirmação da aplicação nem conclusão da operação pela aplicação.

O erro operacional aparece quando uma chamada local bem-sucedida é registrada como recibo remoto. O QUIC DATAGRAM foi desenhado para transportar dados cuja perda pode ser aceita. Ele preserva uma unidade de mensagem, mas não cria offsets de stream, entrega ordenada de bytes ou retransmissão depois que a perda é detectada. Também não ordena uma mensagem DATAGRAM em relação a outra. A fronteira é uma propriedade do formato; a confiabilidade não vem junto.

Também é essencial distinguir um frame QUIC DATAGRAM do datagrama UDP que carrega um pacote QUIC. O frame está dentro do pacote QUIC, e o pacote pode estar dentro de um datagrama UDP. Observar o contêiner externo, construir o pacote ou receber um ACK não mostra que a aplicação remota recebeu e consumiu a mensagem.

max_datagram_frame_size é negociado em uma direção. O valor padrão é zero. Um valor diferente de zero anuncia disposição para receber frames DATAGRAM conformes naquela direção, respeitadas as condições do handshake e as regras aplicáveis ao estado 0-RTT mantido. O emissor não pode ultrapassar o valor anunciado. Ainda assim, o parâmetro não prova memória disponível, capacidade da aplicação, entrega futura ou processamento. O tamanho efetivo pode ser menor por causa de max_udp_payload_size e do MTU do caminho. A extensão não fragmenta frames DATAGRAM; o protocolo de aplicação precisa aceitar o limite menor.

Frames DATAGRAM pertencem à conexão QUIC e não têm QUIC stream ID. Identificadores de fluxos lógicos, significado dos dados, expiração, deduplicação, ordenação quando necessária e condição de conclusão são responsabilidades da aplicação. O transporte não consegue saber se duas mensagens são tentativas da mesma operação ou ações diferentes.

Quando a aplicação submete o datagrama, o QUIC cria um novo frame e tenta enviá-lo no primeiro pacote disponível, sujeito ao controle de congestionamento e ao pacing. Se o envio ainda não for permitido, a implementação precisa manter o frame até que seja permitido ou descartá-lo antes da transmissão. Um prazo definido pela aplicação também pode causar descarte pré-transmissão. Assim, o retorno de uma API deve ser descrito pelo seu contrato real; o RFC 9221 não transforma sucesso local em recibo de transmissão, recebimento remoto ou conclusão.

No receptor, um frame válido só deve ser entregue imediatamente à aplicação se houver capacidade de processá-lo e manter o conteúdo em memória. DATAGRAM não oferece controle explícito de fluxo e não conta para os limites comuns de dados de stream ou de conexão. A ausência de bloqueio por controle de fluxo não demonstra capacidade do receptor. Ele pode descartar o que não consegue processar.

Frames DATAGRAM solicitam ACK, embora não sejam retransmitidos depois da detecção de perda. O ACK pode ser atrasado dentro dos limites normais; pacotes de sondagem podem buscar uma confirmação mais rápida. Reordenação pode desfazer uma conclusão provisória de perda. O ACK prova processamento do frame pela camada de transporte do receptor, mas não prova processamento bem-sucedido pela aplicação, persistência ou conclusão da operação.

O registro deve manter separados: identidade da mensagem, aceitação local e resultado da chamada, política de expiração, suporte negociado e tamanho efetivo, atraso de congestionamento ou pacing, descarte pré-transmissão, número e espaço do pacote, ACK ou perda e suas reversões, processamento pela camada de transporte remota, processamento da aplicação e persistência durável ou conclusão da operação.