IV - User Control and Communication Protocol

Some process must exist which agrees to listen to anybody in the network and create a process for him upon proper identification. This process is called the logger and interacts through the NCP via the network-related User Control and Communication (UCC) module, which implements the necessary protocol. Except for one instance (CLOSEing connections of dead processes), the process operating the UCC module does not have special network privileges.

Under the UCC protocol a "requestor" process which has directed the creation of a "foreign" process maintains two full-duplex pseudo-typewriter connections: one to the foreign logger, and one to the created process. The duplex connection to the foreign logger is used to identify the requestor process to the logger, and after login to return to the requestor process basic information concerning the health of the created process. The duplex connection to the created process is used for control communication to it.

Maintaining two full-duplex connections avoids reconnection problems both when the logger transfers communication to the created process and when it needs to regain control. This is at the modest expense of requiring the requestor process to switch typewriter communications between two sets of connections.

The way that communication is established is essentially as follows: the requestor process first reserves four of its sockets having contiguous socket codes. Then it "signals" the UCC, specifying one of these sockets. From the "signal" the UCC knows which process is calling, and by protocol, on which requestor socket pair the UCC is to communicate with the requestor process, and which requestor socket pair the created process is to use for its communications. This is specified below in more detail.

Establishing and Operating a Remote Process

The UCC at each HOST always keeps a send socket with user number = 0, instance tag = 0 open (active and unconnected) as a "signal" socket, and periodically checks for INITs to this socket. Processes wishing to create a process at this HOST must first signal the UCC by issuing an INIT to this socket.

The requesting process must have four free sockets with contiguous socket codes: <base_socket> (receive) through <base_socket+3> (send). The high numbered send/receive set of sockets is used for typewriter communication with the foreign UCC, the low numbered set for typewriter communication with the created process.

The "requestor" process calls LISTEN twice to open the <base_socket+2> and <base_socket+3> receive/send pair over which it will talk to the foreign UCC. Then it sends out a "signalling" INIT call on <base_socket> to the UCC "signal" socket. The only thing that the UCC does with this "signalling" INIT call is to note down the socket number <base_socket> from which it originated. The UCC immediately rejects this request so as to keep its "signal" socket open for other signals.
After receiving the expected REJECT on its initial INIT call to the UCC's signal socket, the requestor process issues LISTENs for <base_socket> and <base_socket+1>. (The created process will INIT these sockets to establish control communication with the requestor process.) The requestor process then blocks by calling STATUS <base_socket+2> .
The UCC INITs a free send/receive socket pair to the requestor's <base_socket+2> and <base_socket+3> on which the requestor process is presumably LISTENing. The requestor process has called STATUS <base_socket+2> with block option after LISTENing for the two sockets, so that when the INIT from the foreign UCC reaches the requestor process, STATUS returns with the INIT indication. The requestor process verifies that the UCC is the process that is calling, then it ACCEPTs the call. The requestor process then calls STATUS <base_socket+3> and returns when the INIT for that socket reaches it. It does a similar verify and ACCEPT. (There is an arbitrary choice as for which socket the requestor process first calls STATUS.) Two way communication is established when the requestor process has ACCEPTed both INITs from the UCC. This connection is maintained during the login ritual and throughout the life of the created process. Should the requestor process fail to respond properly within a limited amount of time to the INITs of the UCC, the UCC abandons the connection attempt.
The requestor process must then perform the login ritual with the UCC. (The initial protocol might standardize the login ritual.) If the logger is not satisfied and wishes to cut off the requestor, the UCC module CLOSEs both <base_socket+2> and <base_socket+3>, perhaps after the logger has sent a suitable message.
If satisfied, the logger creates a process for the user. The UCC maintains direct communication with the requestor, but this connection is now used only to report basic information concerning the created process.
The first task of a created process is to establish a dual pseudo-typewriter control connection with its requestor process. The created process INITs one of its send/receive socket pairs to the requestor's <base_socket> and <base_socket+1>. If both requests are ACCEPTed, the created process sends an initial message over this connection. Then it goes to command level, in which it awaits a typewriter command message over the connection. If the created process is unable to establish duplex communication with the requestor process, it should destroy itself. The UCC will either CLOSE its own connections with the requestor or make arrangements for another process to be created.
When a created process is logged-out, the UCC uses a privileged entry to the NCP to CLOSE all connections between the dead process and other processes, and to deactivate all open sockets of the dead process. The UCC transmits a message back to the requestor process, then CLOSEs the dual connections between it and the requestor process.
The INTERRUPT call has a standard "quit" meaning when sent from a requestor process to a created process over the requestor's receive socket <base_socket>. All pending output from the created process is aborted, and the it enters "command level" where it awaits a command over the typewriter connection to the requestor process. The interrupted processing is resumable by issuing a "start" command to the created process. (Note that the rule about pending output is more restrictive than that implemented by the INT NCP command.)

This document was prepared through the use of the MULTICS "runoff" command. A source file consisting of intermixed text and "runoff" requests was created using the "qed" text editor. This file was then compiled by the "runoff" command to produce a finished copy. The latest version of this document exists online in MULTICS in the 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.

Figure 4: Establishing a Process at a Foreign HOST

Note: This RFC was put into machine readable form for entry into the online RFC archives by Miles McCredie 11/99.

Establishing and Operating a Remote Process​

Establishing and Operating a Remote Process