Zum Hauptinhalt springen

IV - Protokoll für Benutzersteuerung und -kommunikation

Es muss einen Prozess geben, der bereit ist, jeden im Netz abzuhören und für ihn nach ordnungsgemäßer Identifikation einen Prozess zu erzeugen. Dieser Prozess heißt Logger und interagiert über das netzbezogene Modul für Benutzersteuerung und -kommunikation (UCC) durch das NCP; dieses Modul implementiert das notwendige Protokoll. Abgesehen von einem einzigen Fall (dem Schließen (CLOSE) von Verbindungen toter Prozesse) hat der das UCC-Modul betreibende Prozess keine besonderen Netzwerkprivilegien.

Nach dem UCC-Protokoll unterhält ein "anfordernder" Prozess, der die Erzeugung eines "fernen" Prozesses veranlasst hat, zwei Vollduplex-Pseudo-Fernschreiberverbindungen: eine zum fernen Logger und eine zum erzeugten Prozess. Die Duplexverbindung zum fernen Logger dient dazu, den anfordernden Prozess gegenüber dem Logger zu identifizieren, und nach der Anmeldung dazu, dem anfordernden Prozess grundlegende Informationen über die Gesundheit des erzeugten Prozesses zurückzumelden. Die Duplexverbindung zum erzeugten Prozess dient der Steuerkommunikation mit ihm.

Das Aufrechterhalten zweier Vollduplexverbindungen vermeidet Neuverbindungsprobleme, sowohl wenn der Logger die Kommunikation an den erzeugten Prozess übergibt, als auch wenn er die Kontrolle wiedererlangen muss. Dies geschieht zu dem bescheidenen Preis, dass der anfordernde Prozess die Fernschreiberkommunikation zwischen zwei Verbindungssätzen umschalten muss.

Die Art und Weise, wie die Kommunikation aufgebaut wird, ist im Wesentlichen folgende: Der anfordernde Prozess reserviert zunächst vier seiner Sockets mit aufeinanderfolgenden Socket-Codes. Dann "signalisiert" er dem UCC und gibt einen dieser Sockets an. Aus dem "Signal" entnimmt das UCC, welcher Prozess anruft, und protokollgemäß, auf welchem Socket-Paar des Anforderers das UCC mit dem anfordernden Prozess zu kommunizieren hat und welches Socket-Paar des Anforderers der erzeugte Prozess für seine Kommunikation verwenden soll. Dies wird unten ausführlicher spezifiziert.

Aufbau und Betrieb eines fernen Prozesses​

Das UCC jedes HOST hält stets einen Send-Socket mit Benutzernummer = 0 und Instanz-Tag = 0 als "signal"-Socket offen (aktiv und unverbunden) und prüft regelmäßig, ob INITs an diesen Socket gerichtet werden. Prozesse, die auf diesem HOST einen Prozess erzeugen möchten, müssen dem UCC zunächst signalisieren, indem sie ein INIT an diesen Socket ausgeben.

Der anfordernde Prozess muss vier freie Sockets mit aufeinanderfolgenden Socket-Codes haben: <base_socket> (Empfang) bis <base_socket+3> (Senden). Der Satz von Sende-/Empfangs-Sockets mit den hohen Nummern wird für die Fernschreiberkommunikation mit dem fernen UCC verwendet, der Satz mit den niedrigen Nummern für die Fernschreiberkommunikation mit dem erzeugten Prozess.

  1. Der "anfordernde" Prozess ruft zweimal LISTEN auf, um das Empfangs-/Sendepaar <base_socket+2> und <base_socket+3> zu öffnen, über das er mit dem fernen UCC sprechen wird. Dann sendet er einen "signalgebenden" INIT-Aufruf auf <base_socket> an den "signal"-Socket des UCC. Das Einzige, was das UCC mit diesem "signalgebenden" INIT-Aufruf tut, ist, die Socket-Nummer <base_socket> zu notieren, von der er ausging. Das UCC lehnt diese Anforderung unverzüglich ab, um seinen "signal"-Socket für weitere Signale offen zu halten.

  2. Nachdem der anfordernde Prozess den erwarteten REJECT auf seinen ersten INIT-Aufruf an den Signal-Socket des UCC erhalten hat, gibt er LISTENs für <base_socket> und <base_socket+1> aus. (Der erzeugte Prozess wird diese Sockets INITen, um die Steuerkommunikation mit dem anfordernden Prozess aufzubauen.) Der anfordernde Prozess blockiert dann, indem er STATUS <base_socket+2> aufruft.

  3. Das UCC führt INIT eines freien Sende-/Empfangs-Socket-Paares zu <base_socket+2> und <base_socket+3> des Anforderers aus, auf denen der anfordernde Prozess vermutlich abhört. Der anfordernde Prozess hat STATUS <base_socket+2> mit der Blockieroption aufgerufen, nachdem er die beiden Sockets abgehört hat, sodass STATUS mit der INIT-Anzeige zurückkehrt, wenn das INIT des fernen UCC den anfordernden Prozess erreicht. Der anfordernde Prozess überprüft, dass das UCC der anrufende Prozess ist, und führt dann ACCEPT des Anrufs aus. Danach ruft der anfordernde Prozess STATUS <base_socket+3> auf und kehrt zurück, wenn das INIT für diesen Socket ihn erreicht. Er führt eine ähnliche Überprüfung und ein ähnliches ACCEPT aus. (Die Wahl, für welchen Socket der anfordernde Prozess zuerst STATUS aufruft, ist beliebig.) Die beidseitige Kommunikation ist hergestellt, wenn der anfordernde Prozess beide INITs des UCC angenommen (ACCEPT) hat. Diese Verbindung wird während des Anmeldungsrituals und über die gesamte Lebensdauer des erzeugten Prozesses aufrechterhalten. Sollte der anfordernde Prozess nicht innerhalb einer begrenzten Zeit ordnungsgemäß auf die INITs des UCC antworten, bricht das UCC den Verbindungsversuch ab.

  4. Der anfordernde Prozess muss dann das Anmeldungsritual mit dem UCC durchführen. (Das Ausgangsprotokoll könnte das Anmeldungsritual standardisieren.) Ist der Logger nicht zufrieden und möchte den Anforderer abschneiden, so führt das UCC-Modul CLOSE für <base_socket+2> und <base_socket+3> aus, womöglich nachdem der Logger eine geeignete Nachricht gesendet hat.

  5. Ist er zufrieden, so erzeugt der Logger einen Prozess für den Benutzer. Das UCC unterhält die direkte Kommunikation mit dem Anforderer, doch diese Verbindung dient nun nur noch dazu, grundlegende Informationen über den erzeugten Prozess zu melden.

  6. Die erste Aufgabe eines erzeugten Prozesses ist es, eine doppelte Pseudo-Fernschreiber-Steuerverbindung mit seinem anfordernden Prozess herzustellen. Der erzeugte Prozess führt INIT eines seiner Sende-/Empfangs-Socket-Paare zu <base_socket> und <base_socket+1> des Anforderers aus. Wenn beide Anforderungen angenommen (ACCEPT) werden, sendet der erzeugte Prozess eine erste Nachricht über diese Verbindung. Dann geht er auf Befehlsebene über, wo er eine Fernschreiberbefehlsnachricht über die Verbindung erwartet. Ist der erzeugte Prozess nicht in der Lage, eine Duplexkommunikation mit dem anfordernden Prozess herzustellen, sollte er sich selbst zerstören. Das UCC wird entweder seine eigenen Verbindungen zum Anforderer mit CLOSE schließen oder Vorkehrungen dafür treffen, dass ein anderer Prozess erzeugt wird.

  7. Wenn ein erzeugter Prozess abgemeldet wird, nutzt das UCC einen privilegierten Zugang zum NCP, um alle Verbindungen zwischen dem toten Prozess und anderen Prozessen mit CLOSE zu schließen und alle offenen Sockets des toten Prozesses zu deaktivieren. Das UCC überträgt eine Nachricht zurück an den anfordernden Prozess und führt dann CLOSE für die beiden Verbindungen zwischen ihm und dem anfordernden Prozess aus.

  8. Der INTERRUPT-Aufruf hat eine standardmäßige "quit"-Bedeutung, wenn er von einem anfordernden Prozess über den Empfangs-Socket <base_socket> des Anforderers an einen erzeugten Prozess gesendet wird. Alle ausstehenden Ausgaben des erzeugten Prozesses werden abgebrochen, und er geht auf "Befehlsebene" über, wo er eine Ausgabe über die Fernschreiberverbindung zum anfordernden Prozess erwartet. Die unterbrochene Verarbeitung kann durch Ausgabe eines "start"-Befehls an den erzeugten Prozess fortgesetzt werden. (Beachten Sie, dass die Regel über ausstehende Ausgaben restriktiver ist als die vom INT-NCP-Befehl implementierte.)

Dieses Dokument wurde mit Hilfe des MULTICS-Befehls "runoff" erstellt. Eine Quelldatei aus vermischtem Text und "runoff"-Anweisungen wurde mit dem Texteditor "qed" erstellt. Diese Datei wurde dann durch den Befehl "runoff" kompiliert, um eine fertige Fassung zu erzeugen. Die neueste Fassung dieses Dokuments existiert online in MULTICS in dem Segment

>udd>Multics>Meyer>network_protocol.runoff

(END)

      REQUESTOR                                  FOREIGN
      PROCESS                                    LOGGER
      --------------                             -------------
      a. LISTEN to sockets
      <base_socket+2> and
      <base_socket+3> to be
      connected to foreign logger.

      b. INIT <base_socket>
      to "signal" socket of
      foreign logger.
                =======================================>

                                                c. remember <base_socket>
                                                   and REJECT connection
                                                   to signal socket.

      d. LISTEN to sockets                      e. INIT a logger socket
      <base_socket> and                            pair to the requestor's
      <base_socket_1> to be                       <base_socket+2> and
      connected to the created  process.          <base_socket+3>.
                                                   /
                       <==========================/

      f. ACCEPT connection
      with sockets from
      foreign logger.

                             PERFORM LOGIN RITUAL
                                                CREATED
                                                PROCESS
                                                -------------
                                                g. INIT any socket pair
                                                   to requestor's
                                                   <base_socket> and
                                                   <base_socket+1>
                                                    /
                       <===========================/
      h. ACCEPT connection
      with sockets from created
      process.

Abbildung 4: Aufbau eines Prozesses auf einem fernen HOST

Hinweis: Dieser RFC wurde von Miles McCredie 11/99 zur Aufnahme in die Online-RFC-Archive in maschinenlesbare Form gebracht.