Résumé

  • Dans RFC 938, un paquet DATA dont le numéro est dans la fenêtre d'acquittement mais dont le port est inconnu reçoit un PORT NAK ; les données sont écartées et la réponse porte le rcv_nxt courant.
  • Ce NAK accuse réception des numéros de paquets jusqu'à cette borne, mais refuse le port. Il ne prouve ni remise à une application, ni autorisation, ni écriture durable, ni résultat métier.

Le détail le plus éclairant de l'Internet Reliable Transaction Protocol n'est pas une promesse de transaction achevée. C'est une phrase de RFC 938, publiée en février 1985 : un PORT NAK refuse le numéro de port, « non le numéro de paquet ». En quelques octets, le protocole tient séparées deux propositions que les journaux d'exploitation mélangent encore volontiers : la machine a reçu suffisamment de séquence pour faire progresser son état, et aucun processus local ne s'est présenté pour le port demandé.

Le document est expérimental/proposé, ce que confirme sa fiche RFC. Il faut donc lire ses règles comme une conception publiée, non comme une statistique d'adoption, un relevé de trafic ou la preuve qu'un service quelconque les emploie aujourd'hui. Son intérêt historique tient à la netteté de la séparation proposée.

IRTP est un protocole au-dessus d'IP. RFC 791 indique que le champ Protocol d'IP désigne le protocole du niveau suivant, tandis que le registre IANA des numéros de protocoles attribue actuellement le numéro 28 à IRTP et renvoie à RFC 938. Cette inscription coordonne un nom et un numéro ; elle ne mesure pas des implémentations ni un usage effectif.

Dans huit octets, deux questions différentes

L'en-tête IRTP fait huit octets : type de paquet, numéro de port, numéro de séquence, longueur et somme de contrôle. Les cinq types définis sont SYNCH, SYNCH ACK, DATA, DATA ACK et PORT NAK. Leur voisinage dans le même en-tête ne les rend pas interchangeables.

Le numéro de séquence appartient au mécanisme fiable entre hôtes. Le port désigne le protocole supérieur ou le processus censé recevoir les données. Un processus peut réclamer plusieurs numéros de port, mais un seul processus peut réclamer un numéro donné. C'est une règle d'appropriation locale, non le nom d'une connexion fiable.

Cette dernière liait des hôtes, identifiés par l'adresse Internet distante, et non chaque paire hôte-port. La table de connexion conservait notamment snd_nxt, rcv_nxt et snd_una. SYNCH et SYNCH ACK servaient à établir ou à remettre d'aplomb cet état entre hôtes. Au sein de cette relation, le port surgit au moment précis où l'on cherche un destinataire local pour des données déjà soumises au contrôle de séquence.

La distinction paraît scolaire jusqu'à ce qu'elle manque. Une ligne « message délivré » confond souvent arrivée du paquet, acceptation de séquence, recherche de port, mise en file et traitement applicatif. RFC 938 répartit ces affirmations entre des champs, des conditions et des acteurs différents.

La fenêtre précède la recherche de port

La procédure de réception suit un ordre qui interdit le raccourci. À l'arrivée d'un DATA, le module examine d'abord si le numéro de séquence appartient à la fenêtre d'acquittement. Pour un paquet qui entre dans cette fenêtre, il recalcule rcv_nxt, puis demande si le port est connu.

Si le port est connu, les données peuvent être mises en file pour le processus utilisateur après l'envoi d'un DATA ACK. S'il ne l'est pas, le module émet un PORT NAK, y place le rcv_nxt courant et jette les données. Dans les deux réponses, la borne de séquence rapporte donc un fait sur l'état de réception ; seule la sorte de réponse révèle le résultat de la recherche de port.

Le texte de RFC 938 est explicite : PORT NAK reconnaît la réception de tous les numéros de paquet jusqu'au numéro placé dans son champ séquence. Le refus vise le port. Il ne redemande pas ce paquet-là et ne concède aucun accès à une application.

Cette économie permet à un récepteur de dire : « je ne perds pas la trace de cette progression de séquence ; cependant, je ne possède pas ici l'extrémité locale demandée ». Les données disparaissent au bord de l'aiguillage. Leur présence dans l'histoire de transport ne les transforme pas en entrée acceptée par un service.

Trois niveaux d'évidence, trois responsabilités

Une trace qui contient un PORT NAK peut étayer un constat modeste : le module IRTP a considéré le paquet reçu dans la plage pertinente et a rapporté une réception cumulée jusqu'à une certaine borne ; au même moment, aucun processus connu ne réclamait ce port. Elle ne peut pas prouver qu'une application a interprété les octets, que l'émetteur a été authentifié, qu'une politique a autorisé une opération, qu'une base a été modifiée ou qu'une action a abouti.

Elle ne prouve pas davantage que le service était absent pour toujours. Une réclamation de port est locale et peut changer. Le NAK décrit un état et une observation, pas la biographie complète d'un processus.

Il est plus juste de conserver trois objets de preuve. La séquence décrit la relation de transport entre hôtes. La réclamation de port décrit le choix local d'un module et d'un processus. Une décision applicative éventuelle décrit encore un autre contrôle : syntaxe, identité, droit, transaction ou persistance. Déclarer le premier ou le deuxième comme équivalent du troisième fait traverser à l'évidence une frontière d'autorité.

Cette retenue rejoint la Note 64 de Heng Lu : une règle commune peut produire un résultat déterministe et vérifiable localement sans décider à la place de l'acteur qui détient la conséquence. Le fil commun sait quelque chose de son état. Il ne parle pas au nom d'un processus qui n'a pas réclamé le port, et encore moins au nom d'une institution qui attribue du sens à une demande.

« Fiable » ne prescrivait pas tout

RFC 938 prévoyait sommes de contrôle, synchronisation, acquittements et retransmission, sans édicter une politique universelle de temporisation. L'implémentation devait avoir un moyen de déclencher une retransmission et retransmettre snd_una, mais le choix du temporisateur et de la stratégie restait ouvert. La syntaxe commune ne s'appropriait pas cette décision d'exploitation.

Le renvoi à une période de silence de deux minutes est tout aussi limité. IRTP demande cette période lorsqu'une adresse distante devient connue et renvoie à la discussion de RFC 793. Le renvoi éclaire une précaution de conception ; il ne confond pas IRTP avec TCP, ne rend pas leurs paquets équivalents et ne documente pas une histoire de déploiement commune.

Ainsi, « reliable » n'annonce pas qu'un processus est prêt, et « transaction » n'atteste pas qu'une transaction humaine ou commerciale est close. Le protocole a proposé une réception séquencée et un verdict d'aiguillage étroitement bornés. Sa force historique est de ne pas masquer le vide entre ces deux résultats.

Des journaux qui peuvent encore répondre

Pour comprendre un PORT NAK, il faut garder l'adresse distante, le port, le numéro reçu, la borne rcv_nxt retournée, la fenêtre applicable, l'époque de la connexion, le résultat de somme de contrôle, les échanges de synchronisation et l'état de réclamation du port. Il faut aussi conserver la stratégie locale de temporisation et de retransmission, que RFC 938 ne fixe précisément pas.

Avec cette chaîne, l'opérateur peut distinguer un port non réclamé d'un échec antérieur de somme de contrôle ou de fenêtre ; une remise en synchronisation d'une absence de processus ; une réaction de retransmission d'un résultat applicatif. Une métrique unique appelée « échec de livraison » détruit ces différences au lieu de les expliquer.

Sources et limites

RFC 938 établit ici la structure et la procédure spécifiées ; sa fiche établit son statut expérimental/proposé ; RFC 791 borne le rôle du champ IP Protocol ; RFC 793 n'est invoqué que pour la comparaison sur la période de silence ; IANA établit l'attribution du numéro 28. Aucune de ces sources ne quantifie l'adoption, les performances, le trafic ou un usage actuel.

Elles ne transforment pas non plus un PORT NAK en résultat de sécurité ou de gestion. L'acquittement peut être vrai à son niveau tandis que le refus est vrai au suivant. C'est précisément ce que le protocole a choisi de conserver visible.