Resumo
- Receber os objetos 418 e 420 não autoriza chamar o 419 de perdido: a lacuna numérica, isoladamente, não informa se o objeto existe.
- O rascunho atual distingue ausência permanente, estado desconhecido e término do orçamento de espera de um relé; a observabilidade deve guardar os três recibos.
O contador pula de 418 para 420. Um dashboard ansioso registra uma perda e encerra a investigação. O draft-ietf-moq-transport-21 faz o contrário: ele mantém a incerteza até aparecer uma evidência com autoridade suficiente.
No MOQT, objetos podem seguir por streams ou datagramas, por assinatura ou FETCH, diretamente ou por vários relés. O 419 pode ainda não ter sido produzido, estar fora do filtro desta rota, aguardar uma consulta upstream, ter ultrapassado o tempo que um relé aceitou esperar ou ter sido declarado definitivamente inexistente pelo publicador. A aparência no gráfico é parecida; os responsáveis e os mecanismos não são.
A lacuna não é um veredito
A revisão 21, de 8 de setembro, conserva o modelo de três estados já presente na 20. Para assinante ou cache, um objeto é conhecido como existente, conhecido como inexistente ou desconhecido porque ainda não chegou ou foi produzido. A revisão atual reorganiza principalmente o texto; não criou esse modelo.
A regra operacional é direta: uma lacuna observada em Object IDs não diz nada, por si só, sobre os objetos pulados. Subgrupos podem usar streams distintos; um datagrama pode chegar antes; o cache pode ter as duas bordas enquanto busca o meio; um filtro pode excluir parte do intervalo.
O primeiro recibo precisa registrar Track, Group, Object, Subgroup, caminho, mecanismo, observador e horário. “Não apareceu aqui até este prazo” é verificável. “Nunca existirá” exige uma declaração mais forte.
Quem pode declarar o “nunca”
Prior Object ID Gap permite ao Original Publisher afirmar que um intervalo anterior não existe e jamais existirá. Relés não podem criar a propriedade. Só podem removê-la quando o mesmo fato já estiver implícito em um FETCH. Prior Group ID Gap aplica a regra a grupos.
Um FETCH concluído e limitado também informa estados, mas tem três marcadores: End of Non-Existent Range, End of Unknown Range e End of Timed-Out Range. O publicador controla a declaração durável de criação; o relé relata custódia e espera; o assinante oferece um orçamento. Nenhuma camada deve falar silenciosamente pelas outras.
Timeout é recibo de orçamento, não prova de perda
A mudança recente carregada para o rascunho atual é o intervalo Timed-Out, adicionado na revisão 20. O código 0x20C separa objetos que o relé abandonou ao expirar FILL_TIMEOUT daqueles que continuam genuinamente desconhecidos.
O timeout é um orçamento total, em milissegundos, para FETCHes upstream de uma solicitação. Zero pede somente o que está disponível na hora. Sem parâmetro, vale uma duração específica da implementação. O relé pode até reduzir o valor solicitado sem avisar.
Assim, Timed-Out prova apenas que este relé, nesta requisição, parou de esperar sob aquele orçamento. Não prova perda de pacote, inexistência ou impossibilidade de entrega posterior por outra assinatura ou outro relé. O texto também admite que um objeto chegue por uma fonte atrasada depois de ter sido registrado como inexistente em outra, sem tornar automaticamente o Track malformado. O cache precisa reconciliar proveniência, não congelar a primeira resposta.
O player opera com outro relógio
A mídia tem prazo de apresentação. Um objeto pode existir e chegar corretamente, mas tarde demais para sua dependência de decodificação. Uma camada de melhoria pode nunca ser criada sem interromper a camada básica. Usuários com buffer, momento de entrada ou representação diferentes podem ver resultados diferentes.
O MOQT não define essas dependências. A operação deve relacionar sem fundir observação do objeto, emissor do estado, orçamento do relé, transição do cache, dependência do codec, prazo do player e resultado percebido. Só essa cadeia distingue atraso de rota, cache incompleto, decisão do publicador e descarte de dado válido porém tardio.
Fontes
- Registro MOQT no Datatracker
- MOQT Transport revisão 21
- MOQT Transport revisão 20
- Histórico do MOQT Transport
- Mudança de lacunas expiradas
- Remoção da retenção de Largest Location
- Repositório do MOQT Transport
- RFC 9000: QUIC
- RFC 9221: QUIC Datagram
- Rascunho WebTransport sobre HTTP/3
- Heng Lu: especificação inicial mínima
- Heng Lu: camadas da realidade
- Heng Lu: primazia do código em execução
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

