Résumé

  • Publié en avril 1983 par Andrew G. Malis, RFC 852 décrivait pour les hôtes raccordés à un IMP C/30 une option limitant à deux secondes le blocage provoqué par un message. La pratique ordinaire pouvait retenir tous les envois de l’hôte jusqu’à quinze secondes. Si les ressources manquaient encore, l’IMP refusait le message et renvoyait une réponse Type 9 expliquant la cause.
  • Cette liberté avait un prix. Un message plus tardif pouvait être accepté avant que l’hôte reçoive le refus du premier. La livraison séquentielle suivait l’ordre d’acceptation pour une même priorité, une même source et une même destination; une application attachée à l’ordre initial devait choisir l’ancienne voie ou gérer elle-même le décalage.

Le guichetier reçoit un formulaire épais et appelle un autre bureau. En attendant la réponse, il baisse le rideau sur toute la file. La personne suivante n’a qu’une formalité de dix secondes; elle attend aussi. C’est le défaut décrit dans RFC 852. Quand un ordinateur remettait un message à son Interface Message Processor, l’IMP pouvait manquer de ressources pour le traiter immédiatement. Il cessait alors d’accepter les messages suivants de cet ordinateur. Or la ressource demandée dépendait du type, de la longueur et de la destination du message. Un cas difficile fermait le guichet à des cas parfaitement faisables.

Le délai maximal du blocage ordinaire atteignait quinze secondes. Malis proposa de donner à l’hôte une autre façon de patienter: un message marqué «short blocking» ne devait le retenir que deux secondes au plus. Si l’IMP n’avait toujours pas de quoi le traiter, il le rejetait, envoyait une réponse Incomplete Transmission de Type 9 avec une raison précise et poursuivait sa recherche de ressources. L’hôte pouvait présenter d’autres messages et réessayer le premier ensuite. Le guichet s’ouvrait; le formulaire compliqué retournait au demandeur avec un motif, pas avec une garantie de livraison.

Ce choix prenait place dans les sous-types de messages réguliers. Le Type 0, sous-type 0, gardait les facilités normales et les quinze secondes possibles. Le sous-type 1 demandait les mêmes facilités avec la limite de deux secondes. Pour les paquets dits «uncontrolled», sans garantie de livraison, le sous-type 3 conservait l’ancien délai et le sous-type 4 demandait le court. L’hôte qui activait cette option devait comprendre les réponses Type 9. Le texte couvrait les IMP C/30 avec le protocole d’accès 1822 ou 1822L.

Une ancienne interface présentée comme non bloquante dans le rapport 1822 n’avait jamais été mise en œuvre; RFC 852 proposait un mécanisme nouveau et sollicitait les réactions de ceux qui maintenaient les logiciels des hôtes.

Les réponses de refus servaient aussi de diagnostic. Le Type 9 distinguait le délai d’établissement d’une connexion, le contrôle de flux de bout en bout, le manque de mémoire tampon sur l’IMP de destination, la congestion du trajet et le manque de ressources sur l’IMP de départ. Ces causes n’immobilisaient pas les mêmes voisins. Un problème de connexion laissait passer des messages destinés ailleurs. Une pénurie locale de tampons ou d’entrées de table risquait d’atteindre presque tous les messages, hormis les paquets sans contrôle. L’expression «réseau occupé» masquait des décisions de reprise très différentes.

La limite de flux donne à cette histoire un nombre presque comique: huit messages pouvaient rester en attente de réponse sur une même connexion. Le neuvième ne pouvait pas être accepté tant que cette connexion était pleine. Un autre obstacle concernait les messages de plus de 1 008 bits, en dehors de leur en-tête de 96 bits: ils exigeaient une réservation de tampon sur l’IMP de destination. Un court message ou un envoi vers une autre connexion pouvait donc avoir une issue plus rapide. Les deux secondes empêchaient le neuvième dossier de retenir toute la clientèle de l’hôte.

Reste la question la plus chère: dans quel ordre les messages arrivent-ils? L’ARPANET garantissait une livraison séquentielle, pour une priorité, une source et une destination identiques, dans l’ordre où l’IMP avait accepté les messages. L’hôte envoyait et recevait ses réponses sur deux flux qui ne marchaient pas au même pas. Avant d’apprendre que le premier message avait été refusé, il pouvait en soumettre un deuxième, que l’IMP accepterait. Un nouvel essai du premier arriverait alors après le deuxième dans la file reconnue par le réseau. Malis disait de laisser l’option courte de côté lorsque l’ordre séquentiel du sous-réseau était indispensable.

Le gain n’était donc pas une simple économie de treize secondes. RFC 852 évitait qu’un manque de ressources pour une destination monopolise l’entrée entière d’un ordinateur. En échange, le logiciel de cet ordinateur devait lire le reçu de refus, choisir quand recommencer et décider si un autre message pouvait passer devant. Le guichet avait appris à dire «revenez» plus vite. À l’hôte de tenir le carnet des passages.