Résumé

  • RDP promettait de livrer tous les messages sans imposer que l’application les reçoive toujours dans l’ordre ; ce mode était fixé lors de l’ouverture de la connexion.
  • ACK gardait la limite de la séquence continue, tandis qu’EACK nommait les segments ultérieurs déjà reçus correctement afin de ne retransmettre que la lacune.
  • La réception par le transport, la remise au tampon utilisateur et l’effet applicatif restaient trois preuves distinctes ; la fermeture ne les fusionnait pas.

Le récepteur tenait deux comptes

Un protocole qui ne conserve qu’un numéro cumulatif raconte une histoire simple : « tout est reçu jusqu’ici ». Cette histoire est indispensable, mais incomplète lorsque le réseau réordonne les paquets. Le bloc attendu peut manquer alors que plusieurs blocs plus récents sont déjà présents. Les ignorer dans le dialogue avec l’émetteur gaspille une information réelle.

RFC 908 ajoutait donc un second compte. RCV.CUR indiquait le dernier segment reçu correctement et dans l’ordre. Un ACK ordinaire confirmait cette frontière continue. EACK, l’accusé étendu, transportait les numéros de segments arrivés correctement au-delà de cette frontière. L’émetteur savait alors quelle île existait déjà et quel trou restait à réparer.

Le protocole ne disait pas que l’île et le continent étaient réunis. Les segments EACKés ne déplaçaient pas le bord gauche de la fenêtre au-delà du manque. Lorsque l’émetteur approchait du bord droit autorisé, il devait s’arrêter tant que la lacune n’était pas comblée. L’information sélective supprimait des retransmissions inutiles ; elle n’annulait ni la perte ni la limite de mémoire du récepteur.

« Reçu » avait déjà plusieurs sens

RDP avait été conçu pour le chargement, la copie de mémoire et le débogage à distance. Ces usages partageaient un besoin : aucun bloc ne devait disparaître définitivement. Ils ne partageaient pas nécessairement le besoin d’attendre l’ordre.

Un chargeur peut recevoir des blocs qui portent leur destination logique. Le bloc 42 peut être placé même si le bloc 41 voyage encore. Un débogueur peut avoir une dépendance plus stricte : installer un point d’arrêt doit précéder l’ordre de reprendre l’exécution. Dans le premier cas, retenir un bloc intact ajoute du délai. Dans le second, le livrer trop tôt change le sens de l’opération.

RFC 908 ne transformait pas cette différence en jugement central du transport. La requête Open indiquait le mode séquencé ou non séquencé. Si le mode non séquencé avait été choisi, un segment hors ordre pouvait être copié dans le tampon utilisateur dès sa réception valide. En mode séquencé, le même segment pouvait être EACKé, donc reconnu au niveau transport, mais sa remise à l’application attendait la continuité.

Ainsi, l’accusé de réception et la visibilité applicative n’étaient pas le même événement. Un administrateur qui ne conserve que les ACK perd une partie de l’histoire. Un administrateur qui voit un EACK et conclut « l’application l’a traité » en invente une autre.

Le choix durait autant que la connexion

L’ordre n’était pas renégocié message par message. Il figurait parmi les paramètres de l’ouverture et restait valable pendant toute la connexion. Le SYN échangeait aussi les numéros de séquence initiaux, la taille maximale d’un segment et le nombre maximal de segments non acquittés que chaque côté acceptait.

Cette disposition donnait un contexte stable à l’interprétation. Le même segment 102, reçu avant 101, n’avait pas la même conséquence selon le bit de mode établi par le SYN. Une capture qui commence après l’ouverture peut observer ACK, EACK et données sans connaître la règle de remise. Elle voit le mécanisme, pas tout le contrat.

Les paramètres de flux exprimaient des capacités locales. Chaque récepteur annonçait la quantité qu’il pouvait soutenir. Le protocole imposait ensuite le respect déterministe de cette limite, mais il ne prescrivait pas un nombre universel de tampons comme mesure de qualité. C’est une forme précise de coordination minimale : rendre la limite commune sans décider à la place de l’implémentation quelle capacité elle doit acheter.

La lacune n’était pas la seule frontière

RDP reconnaissait les connexions simultanées : deux SYN pouvaient se croiser et chaque côté renvoyait le même numéro initial accompagné de l’ACK du SYN reçu. Il conservait aussi un état pour détecter une connexion à moitié ouverte. Un segment NUL, qui consommait un numéro de séquence, pouvait demander si le RDP distant reconnaissait encore la connexion.

La réponse prouvait quelque chose de limité : le transport distant possédait encore l’état attendu. Elle ne prouvait ni la santé du débogueur ni l’intégrité de l’image chargée. De même, un checksum valide attestait le contrôle défini pour un segment, pas l’identité cryptographique de l’émetteur.

La fermeture rendait la limite encore plus nette. RDP utilisait RST puis CLOSE-WAIT. RFC 908 demandait à l’utilisateur de déterminer que les données avaient été livrées de façon fiable avant de fermer. Le protocole ne fabriquait pas un reçu final d’application à partir de son propre arrêt. Une remise au tampon pouvait être nécessaire sans être suffisante pour conclure que le travail était accompli.

L’expérience a changé les bits communs

RFC 1151, publié en 1990, rapporte les problèmes découverts lors d’expériences menées en 1986 et 1987. Le checksum non linéaire de 32 bits de la première version avait un coût très dépendant de la représentation interne des machines. Deux optimisations sur du matériel comparable différaient d’un facteur cinq. La version 2 adopta le checksum TCP de 16 bits.

Les ports RDP passèrent aussi de huit à seize bits. Ces changements touchaient l’en-tête ; le numéro de version fut donc incrémenté. Le texte corrigea en outre la mise à jour de SND.UNA : après l’acquittement de SEG.ACK, le plus ancien segment non acquitté devient SEG.ACK + 1.

Le fait important n’est pas qu’un RFC plus récent aurait automatiquement remplacé le code ancien. RFC 1151 évoque au contraire une demande limitée et justifie une liste de corrections plutôt qu’une réécriture complète. Le document décrit un ensemble de compatibilité proposé. Il ne prouve pas qui l’a adopté.

Le registre IANA des numéros de protocole associe toujours la valeur 27 à RDP et à RFC 908. Cette ligne maintient une coordination de vocabulaire. Elle ne mesure aucun trafic, ne sélectionne aucune version et ne garantit qu’une machine sait traiter EACK.

La fiabilité n’était pas un mot magique

RDP oblige à décomposer un terme commode. La fiabilité du transport signifiait ici que les messages acceptés seraient identifiés, contrôlés, acquittés et retransmis en cas de manque. L’ordre signifiait que l’application ne verrait pas un message plus récent avant les précédents. La réussite applicative exigeait encore une autre preuve.

Cette décomposition protège les décisions. Un chargeur peut choisir la remise non séquencée s’il sait placer et valider chaque bloc. Un débogueur peut choisir la séquence parce que ses commandes sont causales. Aucun n’a besoin d’imposer son choix à l’autre pour que le protocole reste interopérable.

Sources