Protocole utilisateur-utilisateur (proposition)
Le protocole suivant est destiné à s'appliquer aux bits de données des messages, entre la fin des bits de marquage et le début des bits de remplissage. Les présents protocoles IMP-IMP et HOST-HOST ne sont pas affectés par cette proposition.
Le principe général est que chaque segment (ce n'est pas un terme technique) de données est précédé d'informations de contrôle spécifiant sa nature et son étendue. Le schéma de base a été élaboré à partir de celui utilisé dans le système de tamponnement SOS (voir les articles du JACM, avril 1959 et surtout celui de O.R. Mock).
Notre point de vue est qu'une liaison est un support d'information. L'information est transportée dans des segments d'une longueur maximale fixe appelés messages [1]. Qu'il en soit ainsi est un accident, du point de vue de l'utilisateur ; lorsqu'il souhaite transmettre un flux contigu de données, il le segmentera en général d'une manière différente (du point de vue des protocoles IMP-IMP ou HOST-HOST) -- nous appellerons son segment un enregistrement. Il devrait être clair que cela est entièrement analogue à la relation entre la notion de bloc (physique) et celle d'enregistrement (logique). Par ailleurs, les systèmes de stockage de fichiers font eux aussi usage d'informations de contrôle et d'état ; nous aussi.
Au niveau du protocole UTILISATEUR-UTILISATEUR, toute information transmise sur la liaison est une séquence de fanions suivis de blocs de données (éventuellement nuls).
Le format général sera le suivant :
OPERATION COUNT DATA
Le champ OPERATION est toujours présent et a une longueur de quatre bits. Le champ COUNT, lorsqu'il est présent, donne le nombre d'octets de données qui suivent dans le bloc de données. La taille d'octet est fixée par le dernier fanion SIZE précédent (dans la plupart des cas). L'octet peut avoir entre zéro et 255 bits de long (Oui, Virginia, zéro est zéro même quand on a un System/360). Le champ OPERATION et le champ COUNT (lorsqu'il est présent) sont appelés le fanion, et les octets de données (lorsqu'ils sont présents) le bloc de données. Les fanions suivis de blocs de données (même lorsqu'ils sont nuls du fait d'un compte nul) sont appelés fanions de bloc, et les autres fanions sont appelés fanions whyte [2].
Il convient de noter que, le fanion SIZE fixant la taille d'octet des blocs suivants, la taille d'octet peut être fixée à celle qui est « naturelle » pour le HOST émetteur ou pour le HOST récepteur, selon l'accord local entre les processus émetteur et récepteur. Il est expressément requis qu'un fanion SIZE apparaisse dans chaque message avant tout fanion de bloc (sauf le fanion ASCII) ; le fanion SIZE peut être introduit par défaut par la ou les routines implémentant le protocole et est destiné en partie à servir de moyen de détection de certaines classes d'erreur.
Le champ COUNT a une longueur de 8 bits (sauf dans le fanion EOM, où il a une longueur de 16 bits). Les fanions sont les suivants :
Fanions Whyte
| Fanion | Nom | Signification |
|---|---|---|
| 0 | NUL | Pas d'opération (considérer le fanion suivant) |
| 1 | RS | Séparateur d'enregistrement (fin d'enregistrement) |
| 2 | GS | Séparateur de groupe (fin de groupe) |
| 3 | FS | Séparateur de fichier (fin de fichier) |
| 4 | ESC | Échappement vers la convention locale pour les fanions |
| 5 | (réservé pour une affectation ultérieure) | |
| 6 | EOM N | Fin de message (N est le nombre total de bits) |
| 7 | SIZE N | La taille d'octet est de N bits |
| 8 | IGNORE N | Ignorer les bits de données suivants |
Fanions de bloc
| Fanion | Nom | Signification |
|---|---|---|
| 9 | SYS N | N octets de données pour le système HOST récepteur |
| 10 | CONTROL N | N octets de données de contrôle suivent |
| 11 | STATUS N | N octets de données d'état suivent |
| 12 | LABEL N | N octets de données d'identification suivent |
| 13 | KEY N | N octets de données de clé suivent |
| 14 | ASCII N | N octets (de 8 bits) de données ASCII suivent |
| 15 | BLOCK N | N octets de données suivent |
J'ai déjà mentionné l'exigence relative à SIZE. L'absence du fanion SIZE dans tout message contenant des fanions de bloc (sauf ASCII) est une erreur certaine. EOM est en partie un autre dispositif de contrôle d'erreur et en partie un dispositif permettant de contourner l'énigme du remplissage. Un programme utilisateur ne devrait jamais voir EOM en entrée ; l'utilisateur peut écrire un EOM pour forcer la transmission. EOM délimite la fin des informations utiles dans le message et redonne le nombre total de bits du message, en commençant par le premier bit suivant le marquage et en terminant par le dernier bit du champ de comptage EOM, afin de vérifier une éventuelle perte d'information. Il s'agit d'un contrôle contre les erreurs dans l'interface électrique IMP-HOST et dans le « mushyware » du HOST. EOM doit apparaître à la fin de chaque message, à moins qu'ESC soit apparu.
ESC est conçu comme une trappe de secours (espérons-le) inutilisée, destinée à ne pas être employée par les installations et/ou applications qui souhaitent éviter d'utiliser plus de quatre bits du protocole UTILISATEUR-UTILISATEUR sur une liaison quelconque. Par exemple, on peut souhaiter utiliser une liaison comme un flux de bits, en ignorant même les frontières de message. Si et quand les anarchistes parviennent à un accord local, tant mieux pour eux !
NUL et IGNORE sont destinés à servir de remplissage, au cas où il serait utile de faire tomber le premier bit du bloc de données suivant sur une frontière d'adresse commode. (Une routine d'interruption du HOST particulièrement serviable pourrait même coller une combinaison de NUL et d'IGNORE sur les bits de marquage à la réception d'un message -- auquel cas, leur compte de bits devrait être transmis aux routines GET pour corriger le contrôle du compte de bits EOM). Les opérations de séparation introduisent les notions d'enregistrement logique, de groupe et de fichier. En particulier, rien n'exige qu'un enregistrement soit entièrement contenu dans un message, ni qu'un seul enregistrement soit contenu dans un message ! En outre, rien n'exige qu'un seul fichier soit transmis pendant une connexion. Par exemple, un utilisateur pourrait souhaiter utiliser une liaison pour transmettre une collection de routines, puis faire autre chose de la liaison.
Par accord local, donc, une seule routine pourrait consister en un certain nombre d'enregistrements formant un groupe, l'ensemble de la collection pourrait former un fichier, et la liaison pourrait rester connectée après réception du fanion FS.
L'interprétation des divers fanions de bloc est pareillement ouverte à un accord local. Les deux fanions destinés à transporter des données pures sont ASCII et BLOCK ; la différence entre eux est seulement (pour autant que le protocole soit concerné) que la taille d'octet est implicite pour ASCII (8 bits) et explicite pour BLOCK (le champ de comptage du dernier fanion SIZE précédent). Au-delà de cela, toutefois, le contenu sémantique du bloc qui suit ASCII est régi par les normes en vigueur pour ASCII ; les informations EBCDIC ne peuvent pas être transmises dans un bloc ASCII !!
CONTROL et STATUS sont destinés à la communication d'informations de contrôle entre processus utilisateurs, et l'interprétation des blocs de données qui les accompagnent est ouverte à un accord local. Génériquement, CONTROL signifie « essayez de faire ce qui suit » et STATUS signifie « mais moi, je me sens comme ça, docteur. » Un fanion CONTROL provoquera un fanion STATUS en retour, tôt ou tard, ou jamais. LABEL est destiné à identifier la ou les unités de données suivantes, au niveau du fichier ou du groupe. Là encore, l'interprétation spécifique est une question d'accord local. KEY est destiné à imiter la notion d'adresse ou de clé -- cela se situe au niveau de l'enregistrement, de l'élément de données, ou même du bloc de stockage physique. Pour ceux qui sont familiers du système PDP-10 et/ou d'OS/360, les parallèles suivants sont offerts à titre d'indication :
USER-USER protocol OS/360 PDP-10
__________________ ______ ______
CONTROL OPEN OPEN
CLOSE CLOSE
LABEL DSCB File retrieval information
KEY KEY USETI/USETO argument
CONTROL READ IN/INPUT
WRITE OUT/OUTPUT
ALLOCATE ? ENTER
OPEN ? LOOKUP
STATUS ? GETSTS
Les notations « ? » ci-dessus indiquent l'absence d'un parallèle très direct. Il vaut la peine de noter que les GET et PUT d'OS/360 ont des parallèles directs dans toute implémentation du protocole UTILISATEUR-UTILISATEUR qui incarne la notion d'enregistrement ; notre implémentation du protocole conduira à introduire cette notion pour toute l'entrée/sortie du PDP-10 impliquant le stockage sur disque et sur bande, ainsi que la communication avec l'IMP.
Si je connaissais la terminologie de MULTICS, je pourrais étendre l'ensemble des parallèles ci-dessus avec plus de précision. Bien que ma terminologie soit tirée de systèmes à impératifs d'entrée/sortie explicites, je tiens à souligner que cette disposition est destinée à traiter la communication de contrôle et de données en général ; MULTICS est un système dans lequel la distinction classique entre stockage externe et interne est brouillée (du point de vue de l'utilisateur) d'une manière que je souhaite voir brouillée dans le protocole UTILISATEUR-UTILISATEUR. Je propose SYS avec seulement une légère appréhension. La notion générale est que l'on devrait pouvoir communiquer directement avec un HOST étranger plutôt que par l'intermédiaire d'un processus utilisateur étranger. SYS est comme un UUO ou un SVC, mais pour la consommation du HOST étranger plutôt que de mon HOST. Du point de vue du HOST, le problème d'implémentation consiste à établir un enregistrement de contexte de processus non relié à un quelconque processus utilisateur local. Ceci, toutefois, est fortement associé à notre énigme actuelle du LOGON. Sur le PDP-10, par exemple, les utilisateurs sont plus ou moins identifiés à des lignes de télétype locales, et une liaison quelconque n'est pas l'une d'elles ! Par conséquent, un subterfuge est nécessaire pour permettre à un utilisateur étranger de se connecter. OS/360 est tout aussi (en fait, plus) pervers à sa manière.
Le processus consistant à connecter un processus étranger sur mon système local n'est pas (sauf peut-être pour MULTICS) une simple question de présence d'une tâche utilisateur spéciale (!!) chargée de le faire. Quand et si autre chose est possible, le HOST doit fournir une instruction système (UUO ou SVC ou n'importe quoi) qui donne les informations requises établissant un processus indépendant à tous égards du processus qui a fait la demande. Sinon, les mécanismes d'auto-protection qui sont raisonnables pour tout système nous rendront tous beaucoup plus interdépendants que nous le souhaitons. Pour ce faire, il doit exister dans chaque système un UUO/SVC qui fait ce qu'il faut (ATTACH, mais oublie-moi). Si c'est vrai, alors le processus de LOGON sur le Network équivaut à l'émission d'un UUO/SVC étranger par un autre nœud du Network. Je ne vois aucun moyen raisonnable d'échapper à cela. Si tel est le cas, alors SYS N est le genre de fanion à utiliser pour transporter les données requises. Si tel est le cas, alors il n'est que raisonnable de laisser SYS transporter une demande pour toute instruction du système d'exploitation au niveau de l'interface programme utilisateur -- système d'exploitation !
Les questions pratiques d'implémentation sont une autre affaire ! Dans le cas du PDP-10, je vois assez bien comment transformer un SYS soit en une demande de LOGON visant à exécuter une commande du moniteur soit en un UUO (ah, s'ils étaient la même chose), selon le cas. OS/360 est plus sophistiqué, malheureusement. MULTICS pourrait y arriver. Néanmoins, j'espère qu'il est clair que ce que nous voulons faire, ce que le protocole devrait refléter, est une question tout à fait différente de celle de savoir comment le faire dans le contexte d'un système HOST spécifique. Ce que nous voulons faire est, en général, assez indépendant du système auquel nous avons affaire pour autant que le protocole soit concerné, et nous ne devrions pas manquer d'introduire des notions générales dans le protocole simplement parce que nous ne savons pas comment elles devront être traduites dans une pratique d'implémentation particulière.