Resumo

  • Um bloco LTP pode ter um prefixo vermelho, confirmado e retransmitido, seguido por um sufixo verde, enviado sem esses mecanismos. As cores definem tratamento, não urgência.
  • A conclusão da sessão de transmissão comprova que todos os bytes foram transmitidos e que o vermelho foi informado como recebido. Ela não comprova a chegada do verde, o encaminhamento Bundle ou o uso pela aplicação final.

A palavra de status muda de significado com um número

O número é o comprimento vermelho. Se ele cobre todo o bloco, o encerramento inclui prova de recepção de todos os bytes. Se cobre só o início, o encerramento garante apenas aquele início. Se vale zero, uma sessão pode terminar sem confirmação de dados. Um painel que mostra as três situações como “100% concluídas” mede atividade, não confiabilidade.

RFC 5326 exige duas condições para o aviso de conclusão da sessão. O ambiente operacional deve ter indicado que todos os dados do bloco foram efetivamente encaminhados para transmissão. Além disso, os relatórios acumulados precisam cobrir toda a parte vermelha não vazia. A parte verde não aparece na segunda condição.

Isso preserva uma escolha intencional. O cliente decide quais bytes justificam gasto adicional de energia, tempo, armazenamento e capacidade de contato. RFC 5325 ressalta que vermelho não significa prioritário ou urgente. Metadados podem ser vermelhos porque o conteúdo verde é inútil sem eles; outro cliente pode proteger tudo ou aceitar tudo sem reparo.

A fronteira executada merece atenção. Um segmento contém apenas uma cor. Quando a divisão solicitada cai no meio de um segmento adequado ao enlace, a implementação pode tratar o restante desse segmento como vermelho. O registro correto inclui o comprimento efetivo, EORP, EOB, offsets e tamanhos, não apenas a política solicitada.

Há também uma regra estrutural: vermelho é sempre prefixo, verde é sempre sufixo. Se o receptor observa vermelho depois de um offset já verde, ou verde abaixo de uma posição já vermelha, considera o segmento mal colorido, descarta-o e inicia cancelamento. A cor é uma propriedade verificável do contrato.

Os recibos pertencem a lados diferentes

O aviso de conclusão da transmissão inicial nasce no transmissor quando todos os segmentos originais foram enviados. Retransmissões vermelhas ainda podem estar pendentes. Ele encerra a primeira passagem.

O aviso de recepção da parte vermelha nasce no receptor quando o comprimento vermelho é conhecido e todos os seus bytes chegaram. Ele informa ao cliente local se o fim vermelho também é o fim do bloco. Em um bloco misto, a resposta negativa impede confundir a parte garantida com o conjunto.

O verde gera avisos por segmento, com dados, offset, tamanho e indicação de EOB. Receber o segmento final revela o final lógico, não a ausência de buracos anteriores. Não existe um relatório agregado de retransmissão verde porque o próprio cliente escolheu não comprar essa garantia.

O aviso de conclusão da sessão, no transmissor, combina envio total e recepção vermelha comprovada. Continua sem afirmar o verde. Já o cancelamento pode vir de erro, limite administrativo, falta de recursos ou solicitação do par. A especificação diz que um cancelamento de transmissão não dá garantia de que o cliente de destino recebeu qualquer parte.

Esses eventos não são etapas intercambiáveis de uma barra de progresso. Cada um tem emissor, objeto e alcance próprios. A operação precisa registrar essa autoria.

Um relatório é um mapa recortado

Um checkpoint pede ao receptor um relatório. O relatório declara limites inferior e superior e, dentro deles, faixas recebidas. Não há informação sobre offsets fora desse recorte. Ausência fora da janela não é perda; é desconhecimento.

O estado pode exigir vários segmentos de relatório independentes. A conclusão vermelha resulta da união coerente de faixas ligadas à mesma sessão. Um percentual ou uma lista sem limites não permite distinguir lacuna, área não observada e sobreposição incompatível.

O acknowledgement de relatório é outra armadilha. Ele leva apenas o número de série do relatório que chegou ao transmissor. Sua função é fazer o receptor parar de retransmitir esse relatório. Não confirma a recepção do payload pelo receptor e muito menos pela aplicação. Dizer apenas “acknowledged” sem nomear o objeto inverte a prova.

O relógio recebe ordens da oportunidade de contato

O LTP não presume conectividade contínua. O ambiente informa quando a transmissão em cada direção começa ou termina, qual é o tempo de luz unidirecional e qual taxa está disponível. O cronômetro de um checkpoint ou relatório começa quando o segmento é retirado para transmissão real, não quando entra em uma fila de aplicação.

Quando o par não tem oportunidade de transmitir, os cronômetros relevantes são suspensos e retomados na próxima janela. Um timeout pode refletir perda, mas também calendário antigo, estimativa de distância incorreta, sinal de fila atrasado ou pausa esperada.

Quem controla o plano de contato influencia o momento em que o protocolo declara uma tentativa esgotada. O histórico de sinais e a versão do plano devem acompanhar qualquer conclusão sobre falha remota.

O limite da prova fica abaixo do usuário

Um engine ID identifica um motor em um conjunto fechado. O adaptador de convergência pode associá-lo a um endpoint Bundle, mas a associação é local à implementação. Ele não é, por si só, uma identidade humana, institucional ou de aplicação.

Depois que o vermelho chega ao cliente LTP, o Bundle pode aguardar em armazenamento, expirar, falhar em outro salto, ser recusado por segurança ou nunca chegar ao consumidor. Também não se pode concluir perda definitiva a partir de uma sessão falha se houver outra cópia, contato ou rota.

RFC 5327 acrescenta autenticação e cookies para enfrentar problemas de origem e abuso de recursos. Isso não aumenta a faixa recebida. Um relatório autêntico ainda pode cobrir apenas o vermelho, e vermelho completo pode coexistir com verde incompleto.

RFC 5326 é Experimental. A nota do IESG não apresenta sua publicação como revisão plena de padrão de Internet para segurança, congestionamento e interação. O protocolo não oferece controle de fluxo ou congestionamento, não se destina ao uso ubíquo na Internet pública e, nessa versão, o uso sobre UDP era limitado a desenvolvimento ou LAN privada. RFCs posteriores dão contexto de registros e Bundle, não evidência sobre uma instalação específica.

Fontes e limite da conclusão

As fontes demonstram semântica, status e arquitetura relacionada. Não demonstram implantação atual, resultado de missão, parte verde completa, entrega Bundle ou consumo pela aplicação.