Résumé

  • Le bit URG ne créait aucun canal parallèle : il rendait significatif un pointeur vers la fin d’une zone urgente dans le même espace de séquence.
  • Telnet associait la notification à un DATA MARK présent dans le flux. Le réveil venait de TCP, mais la preuve de synchronisation appartenait à l’application.
  • Après une correction normative ignorée par les implémentations courantes, RFC 6093 rétablit leur convention tout en déconseillant tout nouvel usage ; RFC 9293 conserve ce compromis.

Un réveil au milieu de la file

Dans RFC 793, l’émetteur ne glisse pas un message dans une voie rapide. Le champ de seize bits devient actif avec URG ; ajouté au numéro de séquence du segment, il désigne une position du flux. Le récepteur avertit l’application tant que cette position devance les octets déjà consommés.

Le mécanisme communique donc un état, pas une unité autonome. Si le pointeur avance pendant le mode urgent, l’application ne reçoit pas nécessairement un nouveau réveil. Compter les notifications comme des commandes était déjà une erreur de modèle.

La borne que Telnet devait encore trouver

RFC 854 montre l’usage historique le plus clair. Telnet Synch joint une notification urgente à la commande DATA MARK. Le premier événement attire l’attention d’un processus bloqué ; le second, livré dans le flux ordinaire, indique où finit le balayage spécial.

Plusieurs Synch peuvent fusionner. Même si TCP annonce trop tôt la fin des données urgentes, Telnet doit poursuivre jusqu’au DATA MARK. L’application ne délègue donc jamais entièrement son sens au transport.

FTP hérita de cette technique. RFC 959 propose Interrupt Process, Synch, puis une commande telle qu’ABOR lorsqu’un serveur ne surveille pas aisément transfert et contrôle à la fois. Le signal ouvre les yeux ; la commande suivante donne l’ordre.

Une frontière, deux phrases

Le texte de RFC 793 place d’abord le pointeur sur l’octet qui suit les données urgentes. Plus loin, le traitement de SEND calcule SND.NXT-1, soit le dernier octet urgent. RFC 1011 tranche en faveur du dernier octet. RFC 1122 transforme cette lecture en obligation et exige aussi des séquences urgentes de longueur quelconque.

Une correction publiée ne déplace pourtant aucun octet dans un noyau déjà diffusé. Le contrat écrit s’était resserré ; le contrat exécuté était resté ailleurs.

L’octet extrait par l’API

RFC 6093 constate que les implémentations populaires testées suivaient presque toutes la convention « octet suivant ». Leur comportement par défaut retirait souvent le dernier octet urgent des lectures normales pour le livrer via MSG_OOB.

Cette interface donna corps au mot « hors bande », mais elle ne créa pas de bande. Elle réduisit une zone théoriquement quelconque à une case d’un octet, susceptible d’être écrasée par une indication suivante. SO_OOBINLINE pouvait remettre l’octet dans le flux sans harmoniser tous les pairs.

Le chemin pouvait supprimer le signal

Certains équipements intermédiaires effaçaient URG et mettaient le pointeur à zéro. Les octets continuaient, mais l’événement attendu disparaissait. Une application pouvait alors lire une structure différente de celle qu’imaginait un inspecteur de sécurité, ou attendre indéfiniment un réveil que le chemin avait neutralisé.

RFC 6093 choisit la convention réellement commune, puis réduit son mandat : conserver le support, déconseiller les nouvelles applications, livrer en ligne lorsque l’ancien usage subsiste et fonctionner même si URG est effacé. RFC 9293 maintient exactement cette séparation entre compatibilité obligatoire et dépendance déconseillée.

Sources et limites de preuve

Ces RFC documentent l’intention, deux lectures de la borne, les usages Telnet et FTP, un ensemble d’implémentations et des middleboxes connues. Elles ne prouvent ni uniformité mondiale ni date unique de bascule. Le signal urgent ne garantit pas un passage avant les autres octets, et un paquet URG ne révèle pas ce que l’API a remis à l’application.

La fonction n’a pas disparu. Ce qui a disparu est son droit à porter la correction d’une nouvelle application.