Aller au contenu principal

Introduction

Il y a bien des bonnes raisons, et peut-être une ou deux mauvaises, de faire apparaître la communication sur le Network comme un simple cas particulier d'entrée/sortie -- du moins en ce qui concerne la programmation utilisateur. Ainsi, par exemple, l'approche de Harvard pour implémenter le protocole HOST-HOST et le Network Control Program traite chaque liaison comme un « dispositif logique » dans la terminologie du PDP-10. Établir une connexion est semblable à une affectation locale de dispositif, et la communication sur une liaison utilisera les UUO d'entrée/sortie standard du système. Cela rend possible l'emploi de programmes existants conjointement avec le Network sans modification -- du moins s'il s'agit d'autres PDP-10.

Cela ne nous mène cependant pas très loin. La notion de « dispositif logique » n'existe pas sur le PDP-10 ; elle existe sur l'IBM 360 (je parle ici au niveau de l'interface système d'exploitation -- programme utilisateur). En outre, en l'absence d'une norme Network exigeant des représentations fixes pour les entiers, les réels, etc. (ce à quoi je m'opposerais), toute paire de processus utilisateurs doit parvenir à un accord local, et l'un ou l'autre doit assumer la charge de la conversion des données lorsque c'est nécessaire. Tout protocole standard devrait permettre d'exprimer de tels accords et devrait prévoir au moins le minimum d'informations de contrôle qui permettra à ces accords de fonctionner en pratique. Enfin, nous devons noter que les protocoles IMP-IMP et HOST-HOST ne prévoient pas de vérifier qu'une action demandée par un processus utilisateur est effectivement accomplie par les autres processus ; ce type de question a toujours été considéré comme relevant du niveau du protocole UTILISATEUR-UTILISATEUR.

La présente proposition n'a l'intention d'affronter les trois types de questions ci-dessus que dans une certaine mesure. Je peux le mieux expliquer cette mesure en énonçant les critères dont je me servirais pour juger toute proposition de protocole UTILISATEUR-UTILISATEUR :

  1. La notion d'enregistrement (logique) devrait être présente, et la notion de message devrait être supprimée. (Pour un programmeur FORTRAN, ce qui est écrit au moyen d'une instruction WRITE sans FORMAT associé est un enregistrement ; pour un programmeur en langage machine OS/360, PUT écrit un enregistrement).

  2. Il devrait être possible d'implémenter le protocole dans les systèmes HOST et/ou les routines de bibliothèque de telle sorte que les programmes utilisateurs existants puissent accéder aux fichiers n'importe où dans le Network sans modification du programme. (Au début, du moins, cette capacité doit être restreinte aux systèmes HOST du même type).

  3. Le protocole devrait être implémentable (pas nécessairement implémenté) dans tout système HOST au niveau SVC ou UUO. Une connaissance spécifique des caractéristiques de l'autre HOST concerné devrait être inutile.

Il convient de noter que ce qui précède implique que certains programmes utilisateurs doivent connaître la nature de l'autre HOST -- du moins dans chaque cas où le deuxième critère fait défaut. À mesure que nous progressons dans les cas où la défaillance se produit actuellement (ou que nous y renonçons), la charge de la prise en compte des différences entre systèmes se déplacera vers l'implémentation dans les protocoles (c'est-à-dire les systèmes HOST) ou, par défaut, dans les programmes utilisateurs.

De toute évidence, toute proposition lancée aujourd'hui devrait être suspecte quant à la mesure dans laquelle elle « résout » les problèmes ultimes. Le degré d'ambition à avoir est strictement une affaire de goût. À ce stade, je préfère essayer quelque chose dont je crois qu'il peut être utilisé par nous tous (et qui, par conséquent, vaut la peine d'être fait), qui va raisonnablement loin dans la solution de nos problèmes à court terme, qui est facile à faire et qui offre l'espoir d'une viabilité à long terme. Dans ce qui suit, j'ai l'intention de décrire la proposition elle-même avec, je l'espère, les arguments de motivation appropriés pour ses éléments. Je brosserai ensuite l'implémentation spécifique que nous réalisons à Harvard pour le PDP-10 et je décrirai comment nous comptons l'appliquer au cas particulier du stockage de fichiers sur d'autres PDP-10 du Network.