Les jours suivants
Depuis la réunion, j'ai eu des conversations avec Steve Wolfe (UCLA-CCN), Bill Crowther (BBN), ainsi qu'avec John Heafner et Erick Harslem (RAND). Les commentaires de Wolf paraîtront sous la forme du NWG/RFC #38 et relèvent d'une catégorie que je commenterai ci-dessous.
Crowther a soumis ce qui suit :
« Brève description de deux idées visant à simplifier le protocole hôte décrit lors de la réunion de mars. Ces idées n'ont pas été soigneusement élaborées.
Idée 1. Reconnecter.
« Un NCP qui veut se reconnecter dit à chacun de ses voisins « je veux me reconnecter ». Ils attendent qu'il n'y ait plus de messages en transit et répondent « OK ». Il dit alors « Reconnectez comme suit » et ils le font. Dans le cas rare, le NCP reçoit en retour un « je veux me reconnecter » au lieu d'un « OK » ; alors l'un doit partir et l'autre doit s'arrêter. Traitez donc un « reconnecter » venant d'un utilisateur hôte supérieur, etc., comme un ok, et venant d'un inférieur comme un « Non — attendez que je vous reconnecte », puis effectuez la connexion.
Idée 2
« Découplez les connexions et les liaisons. Établissez toujours des connexions, mais utilisez n'importe quelle liaison disponible pour les messages. N'envoyez pas un autre message sur une connexion tant qu'un RFNM n'est pas revenu. Incluez les numéros de socket source et destination dans le paquet.
« Pour reconnecter, dites à chacun des voisins « veuillez me reconnecter comme suit... ». Retenez la connexion pendant un court instant (quelques secondes) et envoyez à la fois les paquets et les messages de connexion vers leurs destinations. Je n'ai pas déterminé comment maintenir l'ordre des messages en transit, mais tout fonctionne probablement si vous n'envoyez pas de reconnexion lorsque des RFNM sont en attente. »
La première idée de Bill ne me semble ni nettement meilleure ni (après réflexion) très différente, et je l'examine. Je n'ai pas encore d'opinion arrêtée à son sujet, mais j'essaie de m'en former une.
La seconde idée de Bill semble contraire à ma conception du rôle des liaisons. Un argument en faveur du découplage des connexions et des liaisons est que le nombre de connexions entre deux hôtes pourrait vouloir dépasser 255, et que, même sinon, il est plus sain d'isoler les dépendances dans la conception. D'un autre côté, la facilité « arrêt de liaison » (Cease on Link) récemment fournie* (page 22 du rapport BBN #1822 à paraître prochainement, révisé en février 1970) devient inutile. (Bill, qui vient d'ajouter cette fonction, s'en moque.) Une autre objection est qu'il semble intuitivement mauvais de gaspiller la possibilité d'utiliser le champ de liaison pour transporter de l'information. (Notez le conflit de sentiments viscéraux).
Dans une conversation avec John Haefner et Eric Harslem de RAND, ils ont fait remarquer que le protocole actuel ne prévoit rien pour la détection et le signalement des erreurs, le test et le signalement de l'état, ainsi que l'expansion et l'expérimentation. La détection des erreurs et le test de l'état exigeront une discussion assez longue pour déterminer ce qui est utile, et je m'attends à ce qu'une telle discussion ait lieu pendant que l'implémentation progresse. Réserver de la place pour l'expansion et l'expérimentation du protocole, en revanche, se fait mieux dès maintenant.
Je propose que deux zones d'expansion soient réservées. L'une est que seule une fraction des 256 liaisons soit utilisée, disons les 32 premières. L'autre zone consiste à utiliser des codes de commande à partir de 255 vers le bas, avec des codes permanents attribués depuis le nombre de liaisons en service jusqu'à 32 ; j'estime qu'il est tout à fait improbable que nous ayons besoin de plus de 32 avant longtemps, et de plus, le réseau ne supporterait probablement pas le trafic qu'impliquerait une attribution massive de liaisons. (Ces deux choses ne sont pas nécessairement fortement couplées : on peut avoir de nombreuses liaisons attribuées mais seulement quelques-unes transportant du trafic à un moment donné.)
Certaines des autres idées de Heafner et de Harslem pourront paraître sous forme de NWG/RFC.
Interaction immédiate
Pendant les quelques jours à venir, je resterai intéressé par les critiques du protocole actuel qui pourraient conduire à son rejet ou à une modification sérieuse. Par la suite, l'accent portera sur le raffinement, l'implémentation, l'extension et l'utilisation. On peut me joindre à UCLA par l'intermédiaire de ma secrétaire, Mme Benita Kristel, au (213) 825-2368. De plus, tout le monde est invité à contribuer à la série des NWG/RFC. Les numéros uniques sont attribués par Benita.
* La facilité « arrêt de liaison » (Cease on Link) est une manière pour un hôte récepteur de modifier les RFNM afin de leur donner un sens d'extinction de flux. Une procédure alternative consiste à utiliser une commande de contrôle hôte-à-hôte.
Note : Cette RFC a été mise sous forme lisible par machine pour être versée dans les archives RFC en ligne par Ron Fitzherbert 1/97.