Resumo

  • RFC 938 mandava responder com PORT NAK quando um DATA estava na janela de confirmação, mas sua porta era desconhecida; o módulo devolvia o rcv_nxt atual e descartava os dados.
  • O retorno reconhece números de pacote recebidos até aquela fronteira. Ele recusa a porta, não prova que uma aplicação recebeu, autorizou, gravou ou concluiu a carga.

O nome Internet Reliable Transaction Protocol convida a imaginar uma garantia ampla. A parte mais instrutiva de RFC 938, publicada em fevereiro de 1985, oferece uma garantia bem menor e mais honesta. PORT NAK reconhece recepção cumulativa até o número de sequência informado; o NAK é da porta, e não do número do pacote. Assim, um host pode conservar a verdade sobre seu estado de recepção sem inventar um destinatário local para os dados.

A página informativa do RFC o classifica como experimental/proposto. A fonte descreve um protocolo desenhado, não a extensão de sua implantação, tráfego observado ou uso atual. Também RFC 791 só estabelece que o campo Protocol do IP aponta para o protocolo de nível seguinte. O registro IANA associa hoje o número 28 a IRTP; isso coordena um número, não mede operação.

Sequência e porta respondiam a perguntas diferentes

O cabeçalho de IRTP tinha oito octetos: tipo, porta, sequência, tamanho e checksum. Os tipos eram SYNCH, SYNCH ACK, DATA, DATA ACK e PORT NAK. A sequência descrevia a relação confiável entre hosts; a porta identificava o protocolo superior ou processo local pretendido. Um processo podia reivindicar várias portas, mas uma determinada porta somente podia ser reivindicada por um processo.

A conexão era por endereço Internet remoto, não por combinação de host e porta. A tabela mantinha, entre outros, snd_nxt, rcv_nxt e snd_una; SYNCH e SYNCH ACK estabeleciam ou resincronizavam essa relação entre hosts. A porta não nomeava a conexão. Ela era consultada quando dados, já avaliados nessa relação, procuravam um responsável local.

O procedimento de recepção preservava essa ordem. Para DATA, o módulo verificava primeiro a janela de confirmação. Se o pacote estava nela, recalculava rcv_nxt e então verificava se a porta era conhecida. Para uma porta conhecida, podia enfileirar os dados para o processo depois de enviar DATA ACK. Para uma porta desconhecida, enviava PORT NAK e descartava os dados. As duas respostas carregavam o rcv_nxt corrente.

Não há contradição: uma mensagem de transporte pode dizer “esta é a fronteira até a qual minha recepção progrediu” e “não tenho aqui o processo pedido”. Não é pedido de retransmissão daquele pacote, nem autorização para uma aplicação. Um traço permite concluir, no máximo, que o módulo tratou o pacote como pertencente ao intervalo relevante e não conhecia naquele momento um claim para a porta.

A palavra entrega esconde uma cadeia de decisões

O traço não mostra que bytes foram lidos, que sintaxe foi aceita, que identidade foi verificada, que uma política autorizou a ação, que uma base persistiu dados ou que uma tarefa acabou. Nem prova ausência permanente do serviço: o claim de porta é local e pode mudar. Recepção de sequência, mapeamento de porta e resultado da aplicação são objetos de evidência e de responsabilidade distintos.

Esse limite ilumina a Nota 64 de Heng Lu. Uma regra comum pode ser mínima, determinística e verificável dentro de seu próprio mecanismo, sem decidir a escolha posterior de um ator local. O protocolo confirma seu estado; não pode decidir pelo processo que não reivindicou a porta nem pelo operador que dará significado à carga.

RFC 938 também não unificou a política operacional. Exigia um meio de iniciar retransmissão e a retransmissão de snd_una, mas deixava estratégia e temporizadores à implementação. A referência a dois minutos de silêncio em RFC 793 é uma comparação limitada, não identidade com TCP nem evidência de implantação comum.

Fontes e limites

RFC 938 sustenta a semântica de PORT NAK; sua página estabelece o status; RFC 791 limita o papel do campo IP; RFC 793 é usado apenas para a comparação de quiet time; IANA confirma o número 28. Nenhuma fonte demonstra adoção, desempenho, tráfego ou uso presente, e nenhuma transforma um NAK em prova de segurança ou resultado de negócio.