Un mécanisme adaptable

Nous souhaitons adapter à l'usage du réseau des programmes spécialisés qui n'ont pas été conçus en pensant au réseau et qui, sans aucun doute, ne se plieront pas facilement aux normes du réseau existant au moment de leur intégration. Ce problème d'incompatibilité est un élément tout aussi fondamental de la recherche qui sous-tend le réseau que la diversité des matériels des hôtes. Exiger des frontaux étendus sur chacun de ces programmes n'est pas un objectif raisonnable. Nous considérons le réseau comme un amalgame a) d'hôtes qui fournissent des services ; b) d'hôtes parasites qui font l'interface entre les terminaux et les services, et c) d'un éventail d'hôtes qui se comportent à la fois comme utilisateurs et comme fournisseurs de services. Exiger que chaque hôte parasite gère des protocoles et des formats de données différents pour tous les services dont ses utilisateurs ont besoin n'est pas un objectif raisonnable. Il en résulte des programmes et des terminaux qui souhaitent communiquer mais ne parlent pas la même langue.

Une approche des problèmes de protocoles et de formats de données consiste à fournir un mécanisme adaptable que les programmes et les terminaux peuvent utiliser pour accéder facilement aux ressources du réseau. ARPA parraine le projet Adaptive Communicator à Rand, un effort de recherche visant à étudier un processus frontal capable d'apprendre pour faire l'interface entre l'homme et le programme. La variété des dispositifs terminaux explorés comprend la voix, les tablettes, les terminaux graphiques évolués, etc.

L'Adaptive Communicator paraît très prometteur, mais il ne sera pas prêt avant un certain temps. Le projet Network à Rand a choisi l'approche adaptable (non adaptative, c'est-à-dire sans heuristique ni auto-apprentissage). Notre problème consiste à amener facilement les chercheurs de Rand sur le réseau, en supposant qu'ils ont différentes applications simultanées exigeant des protocoles de programme et des configurations de données différentes.

Les protocoles et les formats de données seront décrits séparément pour illustrer ce que nous entendons par adaptation. Les protocoles sont des séquences d'« appels système » qui correspondent à des commandes NCP (et entraînent leur émission par le NCP). Les formats de données sont les descriptions du contenu régulier des messages et n'ont pas de sens pour un NCP.

La Form Machine (adaptation aux formats de données)

Pour situer le lecteur, la Form Machine appartient à la classe des machines à états finis qui reconnaissent une forme d'expressions régulières_ qui, dans notre cas, décrivent des formats de données. La notation, toutefois, vise des descriptions particulières et peut donc être, pour nos besoins, plus concise que le langage des expressions régulières.

La Form Machine est un ensemble logiciel expérimental qui couple divers programmes et terminaux dont les exigences en matière de format de données diffèrent. Nous envisageons des Form Machines installées (afin de réduire le trafic réseau) chez divers hôtes fournissant des services.

Pour tester l'idée de la Form Machine, nous mettons en œuvre deux sous-programmes appelables par IBM OS ; un compilateur qui compile des instructions décrivant des formes de formats de données ; et un exécuteur qui exécute une forme compilée sur un flux de données.

Pour décrire le test de la Form Machine, il est nécessaire de mentionner un autre programme de Rand -- le Network Services Program (NSP), un programme multi-accès qui fait l'interface entre le Network Control Program et, d'une part, des programmes arbitraires, d'autre part, des consoles vidéo graphiques. (Nous considérons un terminal comme un simple programme doté d'une interface différente, c'est-à-dire un certain nombre de caractères par ligne, un certain nombre de lignes par page, des caractéristiques matérielles propres, l'application à laquelle il est destiné, etc.) Les sous-programmes de la Form Machine sont appelables depuis le NSP à la demande des consoles ou du programme.

Sur le plan opérationnel, un utilisateur de console nomme et spécifie les formes de données qu'il utilisera. Les formes sont compilées et stockées pour un usage ultérieur. Plus tard, lorsque l'utilisateur souhaite établir des connexions réseau et transmettre des données, il associe dynamiquement les formes nommées à chaque extrémité d'un port -- une connexion réseau bidirectionnelle nommée symboliquement. Les flux de données entrants ou sortants sont exécutés conformément à la forme compilée, et le flux de données transformé est ensuite transmis, respectivement, à la console, au programme ou au réseau.

Les détails de la syntaxe de notre notation Form Machine n'ont pas d'importance pour la communauté du réseau dans son ensemble. Toutefois, les dispositions de la notation présentent un intérêt. Elle finira par englober la description des affichages CRT haute performance, des TTY et des structures de fichiers arbitraires. Pour tester sa viabilité, un sous-ensemble de ces fonctionnalités est en cours de mise en œuvre.

La version actuelle se caractérise par les fonctionnalités suivantes :

1. Traduction de codes de caractères (à savoir décimal, octal, hexadécimal, ASCII 8 bits, ASCII 7 bits, EBCDIC et binaire).

2. Chaînes de coupure multiples (de nombreux terminaux ont plusieurs signaux de terminaison).

3. Insertion de littéraux (utilisée principalement pour la présentation d'informations à l'affichage).

4. Saut ou suppression de chaînes arbitraires (utilisés pour éliminer les numéros de séquence d'enregistrement, etc., qui ne doivent pas être affichés).

5. Génération de numéros de séquence d'enregistrement.

6. Calcul et insertion de la longueur des chaînes.

7. Arbitraires spécifications de longueur de chaîne de données, par exemple « une chaîne littérale hexadécimale suivie d'un nombre arbitraire de caractères EBCDIC, suivie d'une chaîne de coupure, ..... ».

8. Concaténation de messages réseau, c'est-à-dire l'exécution de formes compilées sur des chaînes de données incomplètes.

9. Transposition de champs de données.

10. Facteurs multiplicatifs à la fois explicites et indéfinis, pour les messages à ligne unique comme pour les messages multilignes.

Les fonctionnalités qui ne sont pas mises en œuvre mais qui seront ajoutées en cas de succès comprennent :

1. Descriptions orientées graphique.

2. Traductions de nombres générales.

3. Instructions conditionnelles.

4. Une capacité de pointeur.

Le Protocol Manager (adaptation aux séquences de commandes NCP)

Le NSP permet aux utilisateurs de terminaux et aux programmes de travailler au niveau du protocole NCP, c'est-à-dire LISTEN, INIT, etc. Il leur permet aussi de transmettre et de manipuler des informations qui n'ont de sens que pour eux-mêmes. Cette approche « directe » est souhaitable du point de vue du programmeur système ou de l'exploration. Toutefois, il est souhaitable d'éliminer le « dialogue de poignée de main » laborieux pour le chercheur qui utilise de façon répétée un programme distant donné, en lui permettant de définir, de stocker, de récupérer et d'exécuter des séquences de protocole « toutes faites ».

Nous spécifions actuellement un Protocol Manager comme module du NSP qui permettra les opérations ci-dessus sur les séquences de commandes NCP. Les fonctionnalités du module sont les suivantes :

1. Les séquences peuvent contenir des « points d'arrêt » permettant à l'utilisateur de la console d'injecter dynamiquement toute information nécessaire au contexte.

2. Les paramètres d'une commande peuvent contenir des jetons dont les valeurs sont fournies par la partie distante pendant le dialogue de protocole. Par exemple, dans la note #66, le numéro de socket fourni par le serveur doit être utilisé par l'utilisateur dans les commandes RTS et STR ultérieures.