Protocole de niveau supérieur

Le réseau pose des problèmes particuliers lorsqu'un degré élevé d'interaction est requis entre l'utilisateur et un sous-système donné d'un hôte étranger. Ces problèmes résultent de l'hétérogénéité des consoles, de la charge des systèmes d'exploitation locaux et des délais de transmission du réseau. À moins d'employer des stratégies particulières, il peut être difficile, voire impossible, pour un utilisateur distant d'utiliser les sous-systèmes les plus sophistiqués offerts. Bien que ces difficultés soient particulièrement graves dans le domaine du graphique, des problèmes peuvent survenir même pour l'interaction par téléscripteur. Par exemple, supposons qu'un sous-système étranger soit conçu pour des consoles de téléscripteur reliées par téléphone, puis que ce sous-système devienne disponible pour les utilisateurs du réseau. Ce sous-système pourrait présenter les caractéristiques suivantes.

1. Sauf pour l'écho et la correction des fautes de frappe, aucune action n'est entreprise avant qu'un retour chariot ne soit tapé.
2. Tous les caractères, sauf "^", et "<-" et les retours chariot, sont renvoyés en écho au fur et à mesure de la frappe.
3. <- provoque la suppression du caractère immédiatement précédent et est renvoyé en écho sous la forme de ce caractère.
4. ^ provoque l'ignorance de tous les caractères précédemment tapés. Un retour chariot et un saut de ligne sont renvoyés en écho.
5. Un retour chariot est renvoyé en écho sous la forme d'un retour chariot suivi d'un saut de ligne.

Si chaque caractère tapé est envoyé dans son propre message, alors les caractères

H E L L O <- <- P c.r.

provoquent neuf messages dans chaque direction. En outre, chaque caractère est traité par un programme de niveau utilisateur dans l'hôte local avant d'être envoyé à l'hôte étranger.

Il est désormais clair que si cet exemple particulier était important, nous mettrions rapidement en œuvre les règles 1 à 5 dans un programme de l'hôte local et n'enverrions que des lignes complètes à l'hôte étranger. Si le programme de l'hôte étranger ne pouvait pas être modifié de manière à ne pas générer d'échos, alors le programme local pourrait non seulement produire un écho correct, mais aussi éliminer les échos ultérieurs provenant de l'hôte étranger. Toutefois, le problème n'est pas tel ou tel schéma d'interaction particulier ; le problème est que nous nous attendons à ce que beaucoup de ces schémas se produisent. Nous n'avons pas trouvé de solution générale à ces problèmes, mais quelques observations et conjectures pourraient ouvrir la voie.

En ce qui concerne les consoles hétérogènes, nous notons que, bien que les consoles soient rarement compatibles, beaucoup sont équivalentes. Il est probablement raisonnable de considérer un téléscripteur modèle 37 comme l'équivalent d'un IBM 2741. De même, la plupart des écrans à mémoire formeront une classe d'équivalence, et la plupart des écrans à rafraîchissement en formeront une autre. En outre, une hiérarchie pourrait émerger, les membres d'une classe étant utilisables à la place de ceux d'une autre, mais pas l'inverse. Nous pouvons imaginer que n'importe quel écran pourrait être un substitut adéquat pour un téléscripteur, mais difficilement l'inverse. Cette observation nous amène à nous demander si un langage de consoles à l'échelle du réseau serait possible. Un tel langage permettrait un traitement distinct des différentes classes de consoles, avec une sémantique appropriée à chaque classe. Chaque site pourrait alors écrire des programmes d'interface pour ses consoles afin de les faire ressembler à des dispositifs standard du réseau.

Une autre observation est qu'un utilisateur évalue un système interactif en comparant la vitesse des réponses du système à ses propres attentes. Parfois, un utilisateur estime n'avoir fait qu'une demande mineure, de sorte que la réponse devrait être immédiate ; d'autres fois, il estime avoir fait une demande importante et est donc disposé à attendre la réponse. Certains sous-systèmes interactifs sont particulièrement agréables à utiliser parce qu'un travail considérable a été consacré à adapter les réponses aux attentes de l'utilisateur. Dans le réseau, toutefois, un processus de niveau utilisateur local s'interpose entre une console locale et un sous-système étranger, et l'on peut s'attendre à ce que le temps de réponse des demandes mineures se dégrade. Or il peut se faire que tout cet ajustement de l'interaction soit assez indépendant de la partie du sous-système qui effectue les calculs lourds ou les I/O. Dans un tel cas, il peut être possible de scinder un sous-système en deux sections. Une section serait un "frontal" qui met en forme la sortie vers l'utilisateur, accepte son entrée et contrôle les réponses simples sur le plan du calcul, telles que les échos. Dans l'exemple ci-dessus, le programme qui accumule une ligne et génère les échos serait le frontal d'un sous-système. Nous prenons maintenant acte du fait que les hôtes locaux disposent d'une puissance de calcul substantielle, mais nos conceptions actuelles n'utilisent l'hôte local que comme concentrateur de données. Cela est quelque peu ironique, car non seulement l'hôte local est mal utilisé comme concentrateur de données, mais il dégrade aussi les performances en raison des délais qu'il introduit.

Ces arguments nous ont conduits à envisager la possibilité d'un Network Interface Language (NIL), qui serait un langage à l'échelle du réseau pour écrire le frontal des sous-systèmes interactifs. Ce langage aurait pour caractéristique que les sous-programmes communiquent par l'intermédiaire de connexions de type réseau. La stratégie consiste alors à transporter le code source du frontal d'un sous-système vers l'hôte local, où il serait compilé et exécuté.

Au cours de discussions préliminaires, nous avons convenu que NIL devrait posséder au moins les propriétés sémantiques suivantes, généralement absentes des autres langages.

1. Concurrence. Comme les messages arrivent de manière asynchrone sur différentes connexions, et comme l'entrée de l'utilisateur n'est pas synchronisée avec la sortie du sous-système, NIL doit inclure une sémantique permettant de modéliser avec précision les concurrences possibles.
2. Concaténation de programmes. Il est très utile de pouvoir insérer un programme entre deux autres programmes. Pour ce faire, l'interconnexion des programmes serait spécifiée à l'exécution et ne serait pas implicite dans le code source.
3. Substituabilité des dispositifs. Il est habituel de définir les langages de sorte qu'un dispositif puisse être substitué à un autre. L'exigence ici est que tout dispositif puisse être modélisé par un programme NIL. Par exemple, si un contrôleur d'affichage standard du réseau manipule des structures arborescentes en fonction des messages qui lui sont envoyés, alors ces structures doivent être facilement implémentables en NIL.

NIL n'a pas été entièrement spécifié, et des réserves ont été exprimées quant à son utilité. Ces réserves reposent sur notre conjecture selon laquelle il est possible de diviser un système interactif en un frontal transportable qui satisfait les attentes d'un utilisateur à faible coût et une section plus substantielle qui reste sur place. Si notre conjecture est fausse, NIL ne sera pas utile ; sinon, il semble digne d'être poursuivi. La vérification de cette conjecture et le développement ultérieur de NIL seront prioritaires une fois que le protocole HOST-HOST de bas niveau se sera stabilisé.