Aller au contenu principal

III. Conclusion

Extensions du protocole​

Certaines questions n'ont pas été traitées de manière adéquate dans le protocole actuel. Nous envisageons d'examiner plus en profondeur les sujets suivants, et peut-être d'expérimenter à leur sujet.

  1. Contrôle de flux plus élaboré.

    Comme indiqué plus haut, d'autres schémas de contrôle de flux sont encore à l'étude. Hormis la nécessité d'en fournir une forme quelconque, nous ignorons totalement la nature du problème. Il se peut que le schéma actuel soit tout à fait adéquat, mais il se peut aussi que nous ayons besoin d'un schéma beaucoup plus complexe.

  2. Détection des erreurs et reprise

    À mesure que nous acquerrons de l'expérience avec le réseau, nous comprendrons mieux quelles erreurs peuvent survenir et, peut-être plus important encore, que faire face à ces erreurs. Nous nous attendons à ce que le protocole évolue à mesure que nous comprendrons le contrôle des erreurs.

  3. Procédures de démarrage et d'arrêt

    Nous n'avons pas suffisamment réfléchi au problème de l'hôte qui participe au réseau à temps partiel, qui cesse le fonctionnement normal sur le réseau tout en y restant pour des besoins particuliers, ou qui se rétablit après une panne système. Ces questions sont essentielles à un fonctionnement robuste du réseau et constituent peut-être notre plus haute priorité.

  4. Requête et réponse

    Un test d'état d'hôte à hôte serait un outil précieux, mais on ne sait pas encore clairement ce qu'il convient de fournir.

Rejoindre le réseau​

Nous suggérons que les hôtes rejoignent le réseau avec prudence. D'abord, chaque hôte devrait éprouver soigneusement des connexions vers lui-même. Ensuite, il devrait organiser des expériences avec un autre hôte déjà opérationnel. Enfin, il pourra commencer à utiliser les ressources d'autres hôtes. On ne sait pas encore quel hôte sera le mieux placé pour aider les autres en premier, mais l'UCLA s'efforcera de remplir ce rôle.

Réseaux privés​

Une pratique courante consiste à utiliser l'IMP pour relier plusieurs ordinateurs locaux, dont un ou plusieurs ne sont pas accessibles à l'ensemble du réseau. Par exemple, Harvard relie son PDP-1 à son PDP-10 via un IMP, Lincoln Laboratories relie son TSP au 360/67 et au TX2 via un IMP, et l'UCLA relie de même un XDS 920 à son Sigma-7. Dans chacun de ces cas, la petite machine ne fournira pas initialement de services au réseau.

Bien qu'aucun trafic indésirable ne doive parvenir à ces hôtes supplémentaires, il est souhaitable qu'ils se conforment a minima au protocole du réseau. Pourvu qu'ils n'initient jamais de connexion et n'envoient pas de commandes de contrôle intempestives, il suffit qu'un hôte réponde aux commandes CLS par des commandes CLS d'acquittement, et aux commandes ECO par des commandes ERP.