III. Le logiciel hôte
Établissement d'une connexion
La connexion la plus simple que nous puissions imaginer est celle où l'hôte local agit comme s'il était un TTY et a composé l'hôte distant. Après avoir examiné les problèmes d'initiation et de terminaison d'une telle connexion, il a été décidé de réserver le lien 0 pour la communication entre les systèmes d'exploitation hôtes. Les 31 liens restants doivent donc être utilisés comme lignes à composer.
Chaque système d'exploitation hôte doit fournir à ses programmes de niveau utilisateur une primitive (primitive) pour établir une connexion avec un hôte distant et une primitive pour rompre la connexion. Lorsque ces primitives sont invoquées, le système d'exploitation doit sélectionner un lien libre et envoyer un message sur le lien 0 à l'hôte distant demandant une connexion sur le lien sélectionné. Le système d'exploitation de l'hôte distant doit accepter et renvoyer un message d'acceptation sur le lien 0. Dans le cas où les deux hôtes sélectionnent le même lien pour initier une connexion et envoient tous deux des messages de demande à peu près au même moment, un simple schéma de priorité sera invoqué dans lequel l'hôte de priorité inférieure cède et sélectionne un autre lien libre. Un schéma de priorité utilisable consiste simplement à classer les hôtes par leurs numéros d'identification. Notez que les deux hôtes sont conscients que des demandes simultanées ont été faites, mais ils prennent des actions complémentaires : l'hôte de priorité supérieure ignore la demande tandis que l'hôte de priorité inférieure envoie à la fois une acceptation et une autre demande.
La connexion ainsi établie est une connexion de type TTY dans l'état pré-connexion. Cela signifie que le système d'exploitation de l'hôte distant traitera initialement le lien comme si un TTY venait d'appeler. L'hôte distant générera les mêmes échos, attendra la même séquence de connexion et recherchera les mêmes caractères d'interruption.
Transmission de gros volumes
Les télétypes agissant comme terminaux ont deux inconvénients particuliers lorsque nous envisageons la transmission d'un gros fichier. Le premier est que certains caractères sont des caractères d'interruption spéciaux. Le second est que des techniques de mise en mémoire tampon spéciales sont souvent employées, et celles-ci ne conviennent qu'à une transmission à faible vitesse caractère par caractère.
Nous définissons donc une autre classe de connexion à utiliser pour la transmission de fichiers ou d'autres grands volumes de données. Pour initier cette classe de lien, les programmes de niveau utilisateur aux deux extrémités d'un lien de type TTY établi doivent demander l'établissement d'une connexion de type fichier parallèle au lien de type TTY. Le schéma de priorité entre à nouveau en jeu, car l'hôte de priorité supérieure envoie un message sur le lien 0 tandis que l'hôte de priorité inférieure l'attend. Les programmes de niveau utilisateur ne sont bien sûr pas concernés par cela. La sélection du lien libre est effectuée par l'hôte de priorité supérieure.
Les liens de type fichier se distinguent par le fait qu'aucune recherche de caractères d'interruption n'a lieu et que des techniques de mise en mémoire tampon appropriées pour des débits de données plus élevés sont utilisées.
Un résumé des primitives
Chaque système d'exploitation hôte doit fournir au moins les primitives suivantes à ses utilisateurs. Cette liste est connue pour être nécessaire mais non suffisante.
a) Initier une connexion de type TTY avec l'hôte x.
b) Terminer la connexion.
c) Envoyer/Recevoir des caractères sur une connexion de type TTY.
d) Initier une connexion de type fichier parallèle à une connexion de type TTY.
e) Terminer la connexion de type fichier.
f) Envoyer/Recevoir sur une connexion de type fichier.
Vérification des erreurs
Nous proposons que chaque message porte un numéro de message, un compteur de bits et une somme de contrôle dans son corps, qui est transparent pour l'IMP. Pour une somme de contrôle, nous suggérons une somme de report de bout en bout (end-around-carry sum) de 16 bits calculée sur 1152 bits puis décalée circulairement vers la droite d'un bit. Le décalage circulaire droit tous les 1152 bits est conçu pour détecter les erreurs de réassemblage des messages par les IMP.
Interaction plus étroite
Les primitives décrites ci-dessus suggèrent comment un utilisateur peut faire une utilisation simple d'une installation distante. Elles ne donnent aucune indication sur la façon dont une utilisation beaucoup plus complexe du réseau doit être effectuée. Plus précisément, nous sommes préoccupés par le fait qu'à certains sites, beaucoup de travail a été consacré à rendre l'ordinateur très réactif à une console sophistiquée. Les consoles de Culler à UCSB et celles d'Englebart au SRI sont au moins deux exemples. Il est clair que des retards d'une demi-seconde environ pour des réponses triviales de type écho dégradent l'interaction au point de rendre la sophistication de la console non pertinente.
Nous croyons que la plupart des interactions avec la console peuvent être divisées en deux parties, une partie essentiellement locale, immédiate et triviale et une partie distante, plus longue et significative. Comme exemple simple, considérons un utilisateur à une console composée d'un clavier et d'un écran d'affichage rafraîchissant. Le programme dans lequel l'utilisateur tape accumule une chaîne de caractères jusqu'à ce qu'un retour chariot soit rencontré, puis il traite la chaîne. Pendant que les caractères sont tapés, il affiche les caractères sur l'écran. Lorsqu'un caractère d'effacement (rubout) est tapé, il supprime le caractère non-effacement précédent. Si l'utilisateur tape H E L L O <- <- P <CR> où <- est l'effacement et <CR> est le retour chariot, il a effectué neuf frappes. Si chacune de ces frappes entraîne l'envoi d'un message qui à son tour invoque des instructions à notre station d'affichage, nous nous ennuierons rapidement.
Une meilleure solution serait d'avoir la partie frontale du programme distant -- c'est-à-dire la partie qui recherche <- et <CR> -- résidente dans notre ordinateur. Dans ce cas, un seul message de cinq caractères serait envoyé, c'est-à-dire H E L P <CR>, et l'écran serait géré localement.
Nous proposons de mettre en œuvre cette solution en créant un langage pour le contrôle de la console. Ce langage, actuellement nommé DEL, serait utilisé par les concepteurs de sous-systèmes pour spécifier quels composants sont nécessaires dans un terminal et comment le terminal doit répondre aux entrées de son clavier, Lincoln Wand, etc. Ensuite, dans le cadre du protocole initial, l'hôte distant enverrait à l'hôte local le texte en langage source du programme qui contrôle la console. Ce programme aurait été écrit par le concepteur du sous-système en DEL, mais sera compilé localement.
Les spécifications de DEL sont en discussion. Les diagrammes suivants montrent la séquence d'actions.
A. Avant l'établissement du lien
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
B. Après l'établissement du lien et la connexion
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /
C. Après réception et compilation du programme DEL
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
Questions ouvertes
-
Si les IMP effectuent une conversion de code, la somme de contrôle ne sera pas correcte.
-
La procédure pour demander la partie frontale DEL n'est pas encore spécifiée.