Benutzer-Benutzer-Protokoll (Vorschlag)
Das folgende Protokoll soll für die Datenbits in Nachrichten zwischen dem Ende der Markierungsbits und dem Beginn der Auffüllbits gelten. Die gegenwärtigen IMP-IMP- und HOST-HOST-Protokolle werden von diesem Vorschlag nicht berührt.
Das allgemeine Prinzip ist, dass jedem Segment (dies ist kein technischer Begriff) von Daten Steuerinformationen vorausgehen, die seine Art und seinen Umfang angeben. Das Grundschema wurde aus dem entwickelt, das im SOS-Pufferungssystem verwendet wird (siehe die Aufsätze in JACM, April 1959 und insbesondere den von O.R. Mock).
Unser Standpunkt ist, dass eine Verbindung ein Träger von Informationen ist. Informationen werden in Segmenten fester Höchstlänge übertragen, die Nachrichten genannt werden [1]. Dass dies so ist, ist vom Standpunkt des Benutzers aus ein Zufall; wenn er einen zusammenhängenden Datenstrom übertragen möchte, wird er ihn im Allgemeinen auf eine andere Weise (als es die Sicht des IMP-IMP- oder HOST-HOST-Protokolls ist) unterteilen – wir nennen sein Segment einen Satz. Es sollte klar sein, dass dies völlig analog ist zur Beziehung zwischen dem Begriff des (physischen) Block und dem des (logischen) Satzes. Nebenbei bemerkt machen auch Dateispeichersysteme Gebrauch von Steuer- und Statusinformationen; das werden wir ebenfalls tun.
Auf der Ebene des BENUTZER-BENUTZER-Protokolls sind alle über die Verbindung übertragenen Informationen eine Folge von Flags, gefolgt von (möglicherweise leeren) Datenblöcken.
Das allgemeine Format wird sein:
OPERATION COUNT DATA
Das OPERATION-Feld ist stets vorhanden und vier Bit lang. Das COUNT-Feld gibt, wenn es vorhanden ist, die Anzahl der im Datenblock folgenden Datenbytes an. Die Bytegröße wird (in den meisten Fällen) durch das letzte vorausgehende SIZE-Flag festgelegt. Das Byte kann zwischen null und 255 Bit lang sein (Ja, Virginia, null ist null, auch wenn Sie eine System/360 haben). Das OPERATION-Feld und das COUNT-Feld (wenn vorhanden) heißen das Flag, und die Datenbytes (wenn vorhanden) heißen der Datenblock. Flags, auf die Datenblöcke folgen (selbst wenn diese wegen einer Zählung von null leer sind), heißen Block-Flags, und andere Flags heißen Whyte-Flags [2].
Es ist zu beachten, dass, da das SIZE-Flag die Bytegröße für die folgenden Blöcke festlegt, die Bytegröße auf den für den sendenden oder für den empfangenden HOST „natürlichen“ Wert gesetzt werden kann, je nach lokaler Vereinbarung zwischen dem sendenden und dem empfangenden Prozess. Es wird ausdrücklich verlangt, dass in jeder Nachricht vor jedem Block-Flag (außer dem ASCII-Flag) ein SIZE-Flag erscheint; das SIZE-Flag kann von der oder den das Protokoll implementierenden Routinen standardmäßig eingeführt werden und ist teilweise als Mittel zur Erkennung bestimmter Fehlerklassen gedacht.
Das COUNT-Feld ist 8 Bit lang (außer im EOM-Flag, wo es 16 Bit lang ist). Die Flags sind wie folgt:
Whyte-Flags
| Flag | Name | Bedeutung |
|---|---|---|
| 0 | NUL | Keine Operation (nächstes Flag betrachten) |
| 1 | RS | Satzseparator (Satzende) |
| 2 | GS | Gruppenseparator (Gruppenende) |
| 3 | FS | Dateiseparator (Dateiende) |
| 4 | ESC | Ausweichen auf lokale Vereinbarung für Flags |
| 5 | (für spätere Zuweisung reserviert) | |
| 6 | EOM N | Nachrichtenende (N ist die Gesamtbitzahl) |
| 7 | SIZE N | Bytegröße ist N Bit |
| 8 | IGNORE N | Nachfolgende Datenbits ignorieren |
Block-Flags
| Flag | Name | Bedeutung |
|---|---|---|
| 9 | SYS N | N Bytes Daten für das empfangende HOST-System |
| 10 | CONTROL N | N Bytes Steuerdaten folgen |
| 11 | STATUS N | N Bytes Statusdaten folgen |
| 12 | LABEL N | N Bytes Identifikationsdaten folgen |
| 13 | KEY N | N Bytes Schlüsseldaten folgen |
| 14 | ASCII N | N (8-Bit-)Bytes ASCII-Daten folgen |
| 15 | BLOCK N | N Bytes Daten folgen |
Ich habe die Anforderung an SIZE bereits erwähnt. Das Fehlen des SIZE-Flags in einer Nachricht, die Block-Flags enthält (außer ASCII), ist ein eindeutiger Fehler. EOM ist teils eine weitere Einrichtung zur Fehlerprüfung und teils eine Einrichtung, um das Auffüll-Dilemma zu umgehen. Ein Benutzerprogramm sollte EOM bei der Eingabe nie zu sehen bekommen; der Benutzer kann ein EOM schreiben, um die Übertragung zu erzwingen. EOM begrenzt das Ende der nutzbaren Informationen in der Nachricht und wiederholt die Gesamtzahl der Bits in der Nachricht, beginnend mit dem ersten Bit nach der Markierung und endend mit dem letzten Bit des EOM-Zählfelds, um einen möglichen Informationsverlust zu prüfen. Dies ist eine Prüfung gegen Fehler in der elektrischen IMP-HOST-Schnittstelle und in der HOST-Mushyware. EOM muss am Ende jeder Nachricht erscheinen, sofern nicht ESC erschienen ist.
ESC ist als eine (hoffentlich) ungenutzte Notluke gedacht, zur Nichtverwendung durch jene Installationen und/oder Anwendungen, die vermeiden wollen, mehr als vier Bit des BENUTZER-BENUTZER-Protokolls auf einer Verbindung zu verwenden. Beispielsweise kann es erwünscht sein, eine Verbindung als Bitstrom zu nutzen und dabei sogar Nachrichtengrenzen zu ignorieren. Wenn und falls Anarchisten eine lokale Vereinbarung erzielen können – umso besser für sie!
NUL und IGNORE sind als Füllzeichen gedacht, für den Fall, dass es hilfreich ist, das erste Bit des nachfolgenden Datenblocks auf einer günstigen Adressgrenze liegen zu lassen. (Eine besonders hilfreiche HOST-Interrupt-Routine könnte beim Empfang einer Nachricht sogar eine Kombination aus NUL und IGNORE über die Markierungsbits kleben – in diesem Fall sollte deren Bitzahl an die GET-Routinen weitergegeben werden, um die EOM-Bitzahlprüfung zu korrigieren.) Die Trennoperationen führen die Begriffe des logischen Satzes, der Gruppe und der Datei ein. Insbesondere besteht keine Anforderung, dass ein Satz vollständig innerhalb einer Nachricht enthalten ist oder dass nur ein einziger Satz in einer Nachricht enthalten ist! Außerdem besteht keine Anforderung, dass während einer Verbindung nur eine Datei übertragen wird. Beispielsweise könnte ein Benutzer eine Verbindung nutzen wollen, um eine Sammlung von Routinen zu übertragen, und dann etwas anderes mit der Verbindung tun.
Durch lokale Vereinbarung könnte dann eine einzelne Routine aus einer Anzahl von Sätzen bestehen, die eine Gruppe bilden, die gesamte Sammlung könnte eine Datei bilden, und die Verbindung könnte nach Empfang des FS-Flags verbunden bleiben.
Die Interpretation der verschiedenen Block-Flags ist in ähnlicher Weise einer lokalen Vereinbarung überlassen. Die beiden Flags, die reine Daten übermitteln sollen, sind ASCII und BLOCK; der Unterschied zwischen ihnen besteht (soweit es das Protokoll betrifft) nur darin, dass die Bytegröße bei ASCII implizit (8 Bit) und bei BLOCK explizit ist (das Zählfeld des nächstvorausgehenden SIZE-Flags). Darüber hinaus wird jedoch der semantische Inhalt des auf ASCII folgenden Blocks durch die aktuellen Standards für ASCII bestimmt; EBCDIC-Informationen dürfen nicht in einem ASCII-Block übertragen werden!!
CONTROL und STATUS sind für die Übermittlung von Steuerinformationen zwischen Benutzerprozessen gedacht, und die Interpretation der sie begleitenden Datenblöcke ist einer lokalen Vereinbarung überlassen. Gattungsmäßig bedeutet CONTROL „versuche, das Folgende zu tun“, und STATUS bedeutet „aber mir geht es so, Doktor“. Ein CONTROL-Flag wird ein zurückgesandtes STATUS-Flag hervorrufen, früher oder später, oder nie. LABEL ist zur Verwendung bei der Identifizierung der folgenden Dateneinheit(en) auf der Datei- oder Gruppenebene gedacht. Auch hier ist die konkrete Interpretation Sache lokaler Vereinbarung. KEY soll den Begriff der Adresse oder des Schlüssels nachahmen – dies auf der Ebene des Satzes, des Datenelements oder sogar des physischen Speicherblocks. Für diejenigen, die mit dem PDP-10-System und/oder OS/360 vertraut sind, werden zur Orientierung die folgenden Parallelen angeboten:
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
Die obigen „?“-Notationen zeigen das Fehlen einer sehr direkten Parallele an. Es ist bemerkenswert, dass OS/360 GET und PUT in jeder Implementierung des BENUTZER-BENUTZER-Protokolls, die den Begriff des Satzes verkörpert, direkte Parallelen haben; unsere Implementierung des Protokolls wird zur Einführung dieses Begriffs für die gesamte PDP-10-Ein-/Ausgabe führen, die Platten- und Bandspeicherung sowie IMP-Kommunikation einschließt.
Wenn ich die MULTICS-Terminologie kennte, könnte ich die obige Menge von Parallelen mit größerer Genauigkeit erweitern. Obwohl meine Terminologie aus Systemen mit expliziten Ein-/Ausgabe-Imperativen stammt, möchte ich betonen, dass diese Anordnung dazu gedacht ist, Steuerungs- und Datenkommunikation ganz allgemein zu behandeln; MULTICS ist ein System, in dem die klassische Unterscheidung zwischen externem und internem Speicher (vom Standpunkt des Benutzers aus) in einer Weise verwischt wird, wie ich sie im BENUTZER-BENUTZER-Protokoll verwischt wünschen würde. Ich biete SYS nur mit leichtem Zagen an. Die allgemeine Vorstellung ist, dass man direkt mit einem fremden HOST kommunizieren können sollte statt über einen fremden Benutzerprozess als Vermittler. SYS ist wie ein UUO oder SVC, aber für den Verbrauch durch den fremden HOST statt durch meinen HOST. Vom Standpunkt des HOST aus liegt das Problem der Implementierung darin, einen Prozesskontext-Satz einzurichten, der mit keinem lokalen Benutzerprozess verbunden ist. Dieser hängt jedoch stark mit unserem gegenwärtigen LOGON-Dilemma zusammen. Auf der PDP-10 beispielsweise sind Benutzer mehr oder weniger mit lokalen Fernschreibleitungen identifiziert, und eine Verbindung ist keine davon! Daher ist eine List nötig, damit ein fremder Benutzer sich anmelden kann. OS/360 ist auf seine eigene Weise ebenso (eigentlich noch mehr) pervers.
Der Vorgang, einen fremden Prozess an meinem lokalen System anzumelden, ist (außer möglicherweise bei MULTICS) keine einfache Sache eines speziellen (!!) vorhandenen Benutzerjobs, der dafür verantwortlich ist. Wann und falls etwas anderes möglich ist, muss der HOST eine Systemanweisung (UUO oder SVC oder was auch immer) bereitstellen, die die erforderlichen Informationen liefert, um einen Prozess zu etablieren, der in jeder Hinsicht unabhängig von dem Prozess ist, der die Anforderung gestellt hat. Andernfalls werden Selbstschutzmechanismen, die für jedes System vernünftig sind, uns alle weit stärker voneinander abhängig machen, als wir wünschen. Um dies zu tun, muss in jedem System ein UUO/SVC existieren, der das Richtige tut (ATTACH, aber vergiss mich). Wenn dies zutrifft, dann kommt der LOGON-Vorgang über das Network der Ausgabe eines fremden UUO/SVC durch einen anderen Knoten im Network gleich. Ich sehe keinen vernünftigen Weg darum herum. Wenn das der Fall ist, dann ist SYS N die Art von Flag, die zu verwenden ist, um die erforderlichen Daten zu übermitteln. Wenn das so ist, dann ist es nur vernünftig, SYS eine Anforderung für jede OS-Anweisung auf der Ebene der Schnittstelle zwischen Benutzerprogramm und Betriebssystem übermitteln zu lassen!
Die praktischen Fragen der Implementierung sind etwas anderes! Im Fall der PDP-10 kann ich recht gut erkennen, wie ein SYS je nach Fall in eine LOGON-Anforderung zur Ausführung eines Monitorbefehls oder eines UUO zu verwandeln ist (wollte Gott, sie wären dasselbe). OS/360 ist leider raffinierter. MULTICS könnte es schaffen. Nichtsdestoweniger hoffe ich, dass klar ist, dass das, was wir tun wollen – und was das Protokoll widerspiegeln sollte –, eine ganz andere Frage ist als die, wie es im Kontext eines bestimmten HOST-Systems zu tun ist. Was wir tun wollen, ist, soweit es das Protokoll betrifft, im Allgemeinen recht unabhängig von dem System, mit dem wir es zu tun haben, und wir sollten es nicht versäumen, allgemeine Begriffe in das Protokoll einzuführen, nur weil wir unsicher sind, wie sie in die jeweilige Implementierungspraxis übersetzt werden müssen.