Résumé

  • Dans la RFC 794, un processus qui sert un terminal peut conserver un LISTEN TCP pendant qu’il traite déjà des connexions : la requête prioritaire entre, puis ce processus choisit éventuellement la connexion à interrompre.
  • L’exemple du FTP « flash-override » expose les deux côtés de la préemption : le service destinataire doit libérer une place, tandis que le système de départ peut devoir dégager ses propres ressources avant d’envoyer la requête.

À l’hôte X, un fichier ordinaire part vers Y. À Z, une demande FTP d’urgence vise X. Le SYN atteint le bon port. À ce stade, le mot « priorité » est facile à prononcer ; expliquer ce qu’on fait du transfert interrompu l’est beaucoup moins. Dans sa RFC 794 de septembre 1981, Vint Cerf ne confie pas cette décision à une formule magique au cœur du réseau. Il va chercher le service qui connaît ses utilisateurs et son travail en cours.

Le texte passe d’abord par trois salles d’attente. Dans un réseau téléphonique à circuits, la capacité reste réservée au titulaire du circuit, même silencieux : un nouvel appel peut être bloqué et, dans certains systèmes, un usager très prioritaire peut couper une communication moins urgente. Dans un commutateur de messages, un message urgent peut passer avant d’autres et interrompre jusqu’à l’impression d’un message. Dans un réseau à paquets saturé, l’enjeu se déplace vers l’ordre du trafic présenté à l’entrée. La préséance sert à répartir une ressource rare. Encore faut-il nommer cette ressource.

Pour l’accès à un terminal d’AUTODIN II, Cerf imagine un processus hôte, le THP, qui garde un LISTEN sur le port du terminal alors que des connexions sont déjà actives. Une nouvelle demande entre avec son rang de priorité visible. Le THP compare les rangs, ferme ou abandonne la connexion la moins prioritaire si la place manque, bascule l’utilisateur vers la nouvelle et remet un LISTEN en attente. La porte reste ouverte pour entendre la prochaine urgence ; la salle ne gagne aucune chaise par miracle.

Il faut donc exposer la priorité d’une demande entrante au processus qui emploie TCP. Cerf remarque que TCP, en règle générale, dessert des processus ; il ne crée pas tout seul celui qui accueillera un appel entrant. Créer un processus pour un terminal éteint ou déconnecté serait un travail bien théorique. Le logiciel au contact du terminal connaît l’utilisateur, l’état de ses connexions et les conditions de sécurité qui limitent les sessions simultanées. La décision de l’écarter appartient à cet endroit du système.

Le FTP donne au raisonnement des mains et des câbles. Le service de X peut laisser un LISTEN supplémentaire même pendant un transfert ordinaire vers Y. Quand le SYN prioritaire de Z arrive, il peut accepter la nouvelle connexion, sacrifier la moins prioritaire si nécessaire et engager le nettoyage du travail interrompu. Un service qui ne laisse aucun LISTEN quand il travaille ne peut pas être préempté de cette façon. Son règlement intérieur peut promettre ce qu’il veut : personne ne répond au coup frappé.

Cerf examine aussi le seuil de départ. Si les ressources FTP ou TCP de Z sont épuisées, l’usager urgent ne peut même pas lancer sa demande. Le système d’exploitation local peut alors dégager une place, éventuellement en déconnectant un usager moins prioritaire. La préséance pourrait être attachée à la personne ou au terminal ; selon l’implémentation, TCP ou le système d’exploitation prendrait les décisions locales. Le réseau ne vient pas ranger les bureaux des deux hôtes.

Ce court mémo a le mérite de présenter l’urgence avec sa facture. À X, le service qui interrompt une session doit traiter ce qu’elle laisse derrière elle. À Z, quelqu’un doit fournir les ressources pour que la nouvelle session commence. Cerf fait passer la priorité par TCP et installe le pouvoir de préemption là où il peut être exercé sans escamoter l’ancien travail.