doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc46.txt b/doc/rfc/rfc46.txt
new file mode 100644
index 0000000..e71db88
--- /dev/null
+++ b/doc/rfc/rfc46.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                Edwin E. Meyer, Jr.
+Request for Comments: 46           Massachusetts Institute of Technology
+                                                           17 April 1970
+
+
+                      ARPA Network Protocol Notes
+
+   The attached document contains comments and suggestions of the
+   Network Working Group at Project MAC.  It is based upon the protocol
+   outlined in NWG/RFC 33, 36, and later documents.
+
+   This proposal is intended as a contribution to the dialog leading to
+   a protocol specification to be accepted by the entire Network Working
+   Group.
+
+   We solicit your comments.
+
+I - INTRODUCTION
+
+   In this document the Network Working Group at MIT Project MAC suggest
+   modifications and extensions to the protocol specified by Carr,
+   Crocker, and Cerf in a preprint of their 1970 SJCC paper and extended
+   by Crocker in NWG/RFC 36.  This document broadly outlines our
+   proposal but does not attempt to be a complete specification.  It is
+   intended to be an indication of the type and extent of the protocol
+   we think should be initially implemented.
+
+   We agree with the basic concept of simplex communication between
+   sockets having unique identifiers.  We propose the implementation of
+   a slightly modified subset of the network commands specified in
+   NWG/RFC36 plus the ERR command as specified by Harslem and Heafner in
+   NWG/RFC 40.
+
+   Given the basic objective of getting all ARPA contractors onto the
+   network and talking to each other at the earliest possible date, we
+   think that it is important to implement an initial protocol that is
+   reasonably simple yet extendable while providing for the major
+   initial uses of the network.  It should be a simple protocol so as to
+   elicit the broadest possible support and to be easily implementable
+   at all installations with a minimum of added software.
+
+   While the protocol will evolve, the fundamentals of a protocol
+   accepted and implemented by all installations are likely to prove
+   very resistant to change.  Thus it is very important to make the
+   initial protocol open-ended and flexible.  A simple basic protocol is
+   more likely to succeed in this respect than a complicated one.  This
+
+
+
+
+
+                                                                [Page 1]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+   does not preclude the existence of additional layers of protocol
+   between several installations so long as the basic protocol remains
+   supported.
+
+   We feel that three facilities must be provided for in the initial
+   protocol:
+
+   1. Multi-path communication between two existing processes which know
+      how to connect to each other.
+
+   2. A standard way for a process to connect to the logger (logging
+      process at a HOST) at a foreign HOST and request the creation of a
+      user process.  (The login ritual may or may not be standardized.)
+
+   3. A standard way for a newly created process to initiate pseudo-
+      typewriter communication with the foreign process which requested
+      its creation.
+
+   The major differences between the protocol as proposed by Carr,
+   Crocker, and Cerf and this proposal are the following:
+
+   1. The dynamic reconnection strategy specified in Crocker's
+      NWG/RFC 36 is reserved for future implementation.  We feel that
+      its inclusion would unduly complicate the initial implementation
+      of the protocol.  We outline a strategy for foreign process
+      creation that does not require dynamic reconnection.  Nothing in
+      this proposal precludes the implementation of dynamic reconnection
+      at a later date.
+
+   2. We propose that an "instance tag" be added to the socket
+      identifier so as to separate sockets belonging to different
+      processes of the same user coexisting at one HOST.
+
+   3. The following NCP commands have been added:
+
+      a. The ERR command specified in NWG/RFC 40 is included.
+
+      b. BLK and RSM commands are presented as possible alternatives to
+         the "cease on link" IMP command and SPD and RSM commands set
+         forth in NWG/RFC 36.  Because these commands operate on socket
+         connections rather than link numbers, they do not impede the
+         implementation of socket connection multiplexing over a single
+         link number, should that later prove desirable.
+
+      c. An INT command that interrupts a process is specified.  We feel
+         that it is highly important to be able to interrupt a process
+         that may be engaged in unwanted computation or output.  To
+         implement the interrupt as a special format within a normal
+
+
+
+                                                                [Page 2]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+         message raises severe difficulties: the connection may be
+         blocked when the interrupt is needed, and the NCP must scan
+         each incoming message for an interrupt signal.
+
+      d. An ECO echoing command to test communications between NCPs is
+         included.
+
+   4. Sockets are conceptualized as having several states, and these are
+      related to conditions under which network requests may be queued.
+      This differs from the unlimited queuing feature, which presents
+      certain implementation difficulties.
+
+   5. The protocol regarding creation of a foreign process and
+      communication with it is removed to a separate User Control and
+      Communication (UCC) protocol level and is more fully specified.
+
+II - A HIERARCHY OF PROTOCOLS
+
+   It seems convenient and useful to view the network as consisting of a
+   hierarchy of protocol and implementation levels.  In addition to
+   aiding independent software and hardware development, provisions for
+   a layered protocol allow additions and substitution of certain levels
+   in experimental or special purpose systems.
+
+   We view the initial network communications system as a hierarchy of
+   three systems of increasing generality and decreasing privilege
+   level.  These are:
+
+   1. IMP Network - The network of IMPs and physical communication lines
+      is the basic resource which higher level systems convert into more
+      generalized communication facilities.  The IMP network acts as a
+      "wholesaler" of message transmission facilities to a highly
+      privileged module within each HOST.
+
+   2. Network Control Program - Each HOST contains a module called the
+      Network Control Program (NCP) which has sole control over
+      communications between its HOST and the IMP network.  It acts as a
+      "retailer" of the wholesale communications facilities provided by
+      the IMP network.  The network of NCPs can be viewed as a higher
+      level communications system surrounding the IMP network which
+      factors raw message transmission capabilities between HOSTs into
+      communication facilities between ordinary unprivileged processes.
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+              H O S T  A                      H O S T  C
+    ______________________________       ______________________
+   |                              |     |                      |
+   |  ____   ____   ____   ____   |     |  ____   ____   ____  |
+   | |Proc| |Proc| |Proc| |    |  |     | |Proc| |Proc| |    | |
+   | | A  | | B  | | C  | |UCC |  |     | | D  | | E  | |UCC | |
+   | |____| |____| |____| |____|  |     | |____| |____| |____| |
+   |    |     |      |      |     |     |    |     |      |    |
+  - - - - - - |- - - |- - - |- - -|- - -|- - |- - -|- - - |- - - - - -
+   |    |     |      |      |   NCP NETWORK  |     |      |    |
+   |    |     |      |      |     |     |    |     |      |    |
+   |   _|_____|______|______|_    |     |   _|_____|______|_   |
+   |  |                       |   |     |  |                |  |
+   |  |      N C P   A        |   |     |  |   N C P   C    |  |
+   |  |_______________________|   |     |  |________________|  |
+   |                     ||       |     |       ||             |
+   |_____________________||_______|     |_______||_____________|
+                         ||                     ||
+  - - - - - - - - - - - -|| - - - - - - - - - - ||- - - - - - - - - -
+                         ||     IMP NETWORK     ||
+                      ___||___              ____||__
+                     |        |            |        |
+                     |  IMP   |------------|  IMP   |
+                     |   A    |            |   C    |
+                     |________|            |________|
+                         |                     |
+                         |       ________      |
+                         |      |        |     |
+                         +------|  IMP   |-----+
+                                |   B    |
+                                |________|
+
+                     FIG 1. Modular View Of Network
+
+
+   3. User Control and Communication Module - The preceding two
+      communication systems are sufficient to permit communication
+      between unprivileged processes that already exist.  However, one
+      of the primary initial uses of the network is thought to involve
+      the creation of a foreign user process through interaction with
+      the foreign HOST's logger.  The User Control and Communication
+      Module (UCC) implements protocol sufficient for a process to
+      communicate with a foreign HOST's logger and to make initial
+      control communication with a created process.  Such a process is
+      to have the same privileges (subject to administrative control) as
+      a local (to the foreign HOST) user process.  The UCC module
+      communicates through the NCP in a manner similar to an ordinary
+      process.  Except for the ability to close connections to a dead
+
+
+
+                                                                [Page 4]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      process, the UCC module has no special network privileges.  The
+      UCC protocol is only one of several third-level protocols that
+      could be implemented.  For example, a set of batch processing
+      systems connected through the NCP system might implement a load-
+      sharing protocol, but not a UCC.
+
+III - NETWORK CONTROL PROGRAM
+
+   Each HOST implements a module called the Network Control Program
+   (NCP) which controls all network communications involving that HOST.
+   The network of NCPs forms a distributed communication system that
+   implements communication paths between individual processes.  The NCP
+   protocol issues involve:  (i) the definition of these communication
+   paths, and (ii) a system for coordinating the distributed NCP system
+   in maintaining these communication paths.  These are discussed below.
+
+   Sockets
+
+   Communication between two processes is made through a simplex
+   connection between two sockets:  a send socket attached to one
+   process and a receive socket attached to another process.  Sockets
+   have the following characteristics:
+
+   Socket Identifier - A socket identifier is used throughout the
+   network to uniquely identify a socket.  It consists of 48 bits,
+   having the following components:
+
+      a. User Number (24 bits) - A socket attached to a process is
+         identified as belonging to that process by a user number
+         consisting of 8 bits of "home" HOST code plus 16 bits of user
+         code assigned by the home HOST.  This user number is the same
+         for all sockets attached to any of his processes in any HOST.
+
+      b. Instance Tag (8 bits) - More than one process belonging to a
+         user may simultaneously exist within a single HOST.  The
+         instance tag identifies the particular process to which a
+         socket belongs.  A user's first process at a HOST to use the
+         network receives instance tag = 0 by convention.
+
+      c. HOST Number (8 bits) - This is the code of the HOST on which
+         the attached process exists.
+
+      d. Socket Code (8 bits) - This code provides for 128 send and 128
+         receive sockets in each process.  The low order bit determines
+         whether this is a "send" (= 1) or "receive" (= 0) socket.
+
+
+
+
+
+
+                                                                [Page 5]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+   States of Sockets - Each socket has an associated state.  The NCP may
+   implement more transitory states of a socket, but the three following
+   are of conceptual importance.
+
+      a. Inactive - there is no currently existing process which has
+         told the NCP that it wishes to listen to this socket.  No other
+         process can successfully communicate with an inactive socket.
+
+      b. Open - Some process has agreed to listen to events concerning
+         this socket but it is not yet connected.
+
+      c. Connected - This socket is currently connected to another
+         socket.
+
+   Socket Event Queue - A queue of events to be disclosed to the owning
+   process is maintained for each open or connected socket.  It consists
+   of a chronologically ordered list of certain events generated by the
+   action of one or more foreign processes trying to connect or
+   disconnect this socket.  An entry in the event queue consists of the
+   event type plus the identifier of the foreign socket concerned.  The
+   following event types are defined:
+
+      a. "request" - a foreign socket requests connection.  (not queued
+         if local socket is already connected)
+
+      b. "accept" - a foreign socket accepts requested connection.
+
+      c. "reject" - a foreign socket rejects requested connection.
+
+      d. "close" - a foreign socket disconnects an existing connection.
+
+   A "request" event is removed from the queue when it is accepted or
+   rejected.  The other events are removed from the queue as they are
+   disclosed to the owning process.
+
+   Some events are intended to be transparent to the process owning the
+   socket, and they do not generate entries in the event queue.
+
+   Although an event queue is conceptually unlimited, it seems necessary
+   to place some practical limit on its length.  When an event queue for
+   a socket is full, any incoming event that would add to the queue
+   should be discarded and the sending NCP notified (via ERR command
+   described below).
+
+
+
+
+
+
+
+
+                                                                [Page 6]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+NCP Control Communications
+
+   The NCP network coordinates its activities through control commands
+   passed between its individual components.  These commands generally
+   concern the creation and manipulation of socket connections
+   controlled by the NCP receiving the command.  A control command is
+   directed to a particular NCP by being sent to its HOST as a message
+   over link number 1 (designated as the control link), which is
+   reserved for that purpose.  The IMP network does not distinguish
+   between these messages and regular data messages implementing
+   communication through a socket connection.
+
+      The following NCP control commands are defined:
+
+      a. Request for Connection
+
+         RFC <local socket> <foreign socket> [<link no.>]
+
+      An NCP directs this command to a foreign NCP to attempt to
+      initiate a connection between a local socket and a foreign socket.
+      If the foreign socket is open, the foreign NCP places a "request"
+      event into the socket's event queue for disclosure to the process
+      that owns it.  If the foreign process accepts, the foreign NCP
+      returns a positive acknowledgement in the form of another RFC.  It
+      rejects connection by issuing the CLS command (see below).  An RFC
+      is automatically rejected without consulting the owning process if
+      the foreign socket is not open (inactive or connected).  Multiple
+      RFCs to the same socket are placed into its event queue in order
+      of receipt.  Any queued RFCs are automatically rejected by the NCP
+      once the owning process decides to accept a connection.  The NCP
+      which has control of the "receive" socket of the potentially
+      connected pair designates a link number over which messages are to
+      flow.
+
+      b. Close a Connection
+
+         CLS <local socket> <foreign socket>
+
+      An NCP issues this network command to disconnect an existing
+      connection or to negatively acknowledge an RFC.  There is a
+      potential race problem if an NCP closes a local send socket in
+      that the CLS command may reach the foreign NCP prior to the last
+      message over that socket connection.  This race is prevented by
+      adhering to two standards: (i) A CLS command for a local send
+      socket is not transmitted until the RFNM for the last message to
+      the foreign socket comes back, and (ii) the foreign NCP processes
+      all incoming messages in the order received.
+
+
+
+
+                                                                [Page 7]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      c. Block Output over a Connection
+
+         BLK <foreign send socket>
+
+      A process may read data through a receive socket slower than
+      messages are coming in and thus the NCP's buffers may tend to clog
+      up.  The NCP issues this command to a foreign NCP to block further
+      transmission over the socket pair until the receiving process
+      catches up.
+
+      d. Resume Output over a Blocked Connection
+
+         RSM <foreign send socket>
+
+      An NCP issues this command to unblock a previously blocked
+      connection.
+
+      e. Interrupt the Process Attached to a Connection
+
+         INT <foreign socket>
+
+      Receipt of this message causes the foreign NCP to immediately
+      interrupt the foreign process attached to <foreign socket> if it
+      is connected to a local socket.  Data already in transit within
+      the NCP network over the interrupted connection will be
+      transmitted to the destination socket.  The meaning of "interrupt"
+      is that the process will immediately break off its current
+      execution and execute some standard procedure.  That procedure is
+      not defined at this protocol level.
+
+      f. Report an Erroneous Command to a Foreign NCP
+
+         ERR <code> <command length> <command in error>
+
+      This command is used to report spurious network commands or
+      messages, or overload conditions that prevent processing of the
+      command.  <code> specifies the error type.  If <code> specifies an
+      erroneous network command, <command in error> is that command (not
+      including IMP header) and <command length> is an integer
+      specifying its length in bits.  If <code> specifies an erroneous
+      message, <command in error> contains only the link number over
+      which the erroneous message was transmitted.  (This is slightly
+      modified from the specification in NWG/RFC 40.)
+
+
+
+
+
+
+
+
+                                                                [Page 8]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      g. Network Test Command
+
+         ECO <48 bit code> <echo switch>
+
+      An NCP may test the quality of communications between it and a
+      foreign NCP by directing to it an ECO command with an arbitrary
+      <48 bit code> (of the same length as a socket identifier) and
+      <echo switch> 'on'.  An NCP receiving such a ECO command should
+      immediately send an acknowledging ECO with the same <48 bit code>
+      and <echo switch> 'off' to the originating NCP.  An NCP does not
+      acknowledge an ECO with <echo switch> 'off'.  We feel that this
+      command will be of considerable aid in the initial shakedown of
+      the entire network.
+
+      h. No Operation Command
+
+         NOP
+
+      An NCP discards this command upon receipt.
+
+User Interface to the NCP
+
+   The NCP at each HOST has an interface through which a local process
+   can exercise the network, subject to the control of the NCP.  The
+   exact specification of this interface is not a network protocol
+   issue, since each installation will have its own interface keyed to
+   its particular requirements.  The protocol requirements for the user
+   interface to an NCP are that it provide all intended network
+   functions and no illegal privileges.  Examples of such illegal
+   privileges include the ability to masquerade as another process,
+   eavesdrop on communications not intended for it, or to induce the NCP
+   to send out spurious network commands or messages.
+
+   We outline here an interface based on the Carr, Crocker, and Cerf
+   proposal that is sufficient to fully utilize the network.  While this
+   particular set of calls is intended mainly for illustrative purposes,
+   it indicates the types of functions necessary.
+
+      The following calls to the NCP are available:
+
+      a. LISTEN <my 8 bit socket code>
+
+      A user opens this socket, creating an empty event queue for it.
+      This LISTEN call may block waiting for the first "request" event,
+      or it may return immediately.
+
+
+
+
+
+
+                                                                [Page 9]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      b. INIT <my socket code> <foreign socket>
+
+      A user attempts to connect <my socket> to <foreign socket>.  The
+      local NCP sends an RFC to the foreign NCP requesting that the
+      connection be created.  The returned acknowledgemnet is either an
+      RFC (request accepted) or CLS (request rejected).  At the caller's
+      option, the INIT call blocks on the expected "accept" or "reject"
+      event, or it can return immediately without waiting.  In this case
+      the user must call STATUS (see below) at a later time to determine
+      the action by the foreign NCP.  When a blocked INIT call returns,
+      the "accept" or "reject" event is removed from the event queue.
+
+      c. STATUS <my socket code>
+
+      This call reports out the earliest previously unreported event in
+      the queue of <my socket>.  The STATUS call deletes the event from
+      the queue if that type of event is deleteable by disclosure.
+
+      d. ACCEPT <my socket code>
+
+      The user accepts connection with the foreign socket whose
+      "request" event is earliest in the event queue for <my socket>.
+      An acknowledging RFC is sent to the accepted foreign socket, and
+      the "request" event is deleted from the event queue.  Should any
+      other "request" event exist in the queue, the NCP automatically
+      denies connection by sending out a CLS command and deleting the
+      event.
+
+      e. REJECT <my socket code>
+
+      The user rejects connection with the foreign socket whose
+      "request" event is earliest in the event queue for <my socket>.
+      The NCP sends out a CLS command and deletes the "request" event
+      from the queue.
+
+      f. CLOSE <my socket code>
+
+      The user directs the NCP to disconnect any active connection to
+      this socket and to deactivate the socket.  The NCP sends out a CLS
+      command to the foreign socket if a connection has existed.  The
+      status of the foreign socket also becomes closed once the "close"
+      event is disclosed to the foreign process.
+
+      g. INTERRUPT <my socket code>
+
+      The user directs the NCP to send out an INT command to the foreign
+      socket connected to <my socket>.
+
+
+
+
+                                                               [Page 10]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      h. TRANSMIT <my socket code> <pointer> <nbits>
+
+      The user wishes to read (<my socket> is receive) or write (<my
+      socket> is send) <nbits> of data into or out of an area pointed to
+      by <pointer>.  A call to write returns immediately after the NCP
+      has queued the data to send a message over the connection.  The
+      call to write blocks only if the connection is blocked or if the
+      local NCP is too loaded to process the request immediately.  Data
+      to be transmitted over a connection is formatted into one or more
+      IMP messages of maximum length 8095 bits and transmitted to the
+      foreign HOST over the link number specified in the RFC sent by the
+      NCP controlling the receiving connection.  A "close" event in the
+      event queue for <my socket> is disclosed through the action of
+      TRANSMIT.  A call to write discloses the "close" event
+      immediately.  A read call discloses it when all data has been
+      read.
+
+The History of a Connection From a User View
+
+An Illustrative Example
+
+   Assume that process 'a' on HOST A wishes to establish connection with
+   process 'b' on HOST B.  Before communication can take place, two
+   conditions must be fulfilled:
+
+      a. process 'a' must be able to specify to its NCP a socket in 'b's
+      socket space to which it wants to connect.
+
+      b. process 'b' must already be LISTENing to this socket.
+
+   1. Establishing the Connection
+
+      a. process 'b' LISTENs to socket 'Bb9'.
+
+      b. process 'a' INITs 'Bb9' to its 'Aa12'.  The NCP at A generates
+      an RFC specifying link number = 47, which it chooses from its
+      available set of links.  This is the link over which it will
+      receive messages if the connection is ACCEPTed by process 'b'.
+
+      c. process 'b' is informed of A's INIT request.  He may REJECT
+      connection (NCP B sends back a CLS) or ACCEPT (NCP B sends back an
+      RFC).
+
+      d. If process 'b' ACCEPTs, the confirming RFC establishes the
+      connection, and messages can now flow.
+
+
+
+
+
+
+                                                               [Page 11]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+          HOST  A               |          HOST B
+          INITIATOR             |          ACCEPTOR
+          PROCESS 'a'           |          PROCESS 'b'
+                                |
+                                |
+                                |  a. LISTEN 'socket code 9'
+                                |
+                                |
+ b. INIT 'socket code 12' 'Bb9' |
+      RFC 'AA12' 'Bb9' 'link 47' ==========>
+                                |
+                                | c. ACCEPT 'socket code 9'
+                                |        RFC 'Bb9' 'Aa12'
+                                |
+                                | d. TRANSMIT 'send buffer' 'len'
+                                |                        'socket 9'
+                     <============== IMP message 'link 47' 'send buffer'
+                                |
+ e. TRANSMIT 'rec buffer' 'length'
+                    'socket 12' ============>
+                                |
+                                | f. CLOSE 'socket code 9'
+                                |
+                             last RFNM ===>
+                      <============== CLS 'Bb9' 'Aa12'
+     closes socket 'Aa12'       |
+                                |
+
+     FIG 2.  Establishing and Communicating over a Socket Connection
+
+   2. Sending Messages over a Connection.
+
+      a. Process 'b' issues a TRANSMIT call to send data through the
+      connection.  NCP B formats this into an IMP message and sends it
+      to NCP A with link number = 47 as specified by A's RFC.
+
+      b. NCP A receives the raw message from NCP B with link number =
+      47.  NCP A uses this link number in deciding who the intended
+      recipient is, and stores the message in a buffer for the recipient
+      process.
+
+      c. Process 'a' may issue a read (TRANSMIT) call for socket code 12
+      at any arbitrary time.  The read call blocks if there is no data
+      pending for the socket.  The read call picks up the specified
+      number of bits transmitted over socket code 12, perhaps across an
+      IMP message boundary.  The boundaries of the IMP messages are
+      invisible to the read call.
+
+
+
+
+                                                               [Page 12]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      d. Should process 'b' send data over the connection at a faster
+      rate than process 'a' picks it up, NCP A can issue a BLK command
+      to NCP B if A's buffers start filling.  Later, when process 'a'
+      catches up NCP A can tell B to resume transmission via an RSM
+      command.
+
+   3. Process 'b' Closes the Connection
+
+      a. Process 'b' decides to close the connection, and it issues the
+      CLOSE call to NCP B.  To avoid race problems B waits for the RFNM
+      from the previous message over this connection, then sends the CLS
+      command to NCP A.  When the RFNM from the CLS command message
+      returns, NCP B flushes socket 'Bb9' from its tables, effecting the
+      close at its end and deactivating 'Bb9'.
+
+      b. Because of sequential processing within NCP A, the last message
+      to socket 'Aa12' is guaranteed to have been directed to a process
+      before the CLS from NCP B comes through.  Upon receipt of the CLS
+      from B, NCP A marks socket 'Aa12' as "close pending" and places a
+      "close" event into the event queue of 'Aa12'.
+
+      c. Process 'a' can still issue read calls for socket 'Aa12' while
+      there is buffered data pending.  When 'a' issues a read call after
+      the buffer has been emptied, the "close" event is disclosed to
+      inform 'a' of the closure, and socket 'Aa12' is flushed from the
+      tables of NCP A.
+
+   4. Process 'a' Closes the Connection
+
+      a. Let us return to step 2. and assume that process 'a' wants to
+      close the connection from its end.  There is no race problem
+      because we assume that once 'a' issues a CLOSE call, it no longer
+      wants to read messages over that socket.
+
+      b. Assume that process 'a' issues a CLOSE call on socket 'Aa12'.
+      NCP A immediately sends out a CLS command to NCP B and marks
+      socket 'Aa12' as "close pending".  Any data buffered for read on
+      'Aa12' is discarded.  To allow remaining messages already in
+      transit from process 'b' to percolate through the IMP network to
+      NCP A and be discarded without error comments, NCP A retains
+      'Aa12' in its tables for a suitable period of time after receiving
+      the RFNM from the CLS command.  During this period NCP A discards
+      all messages received over the closing connection.  After allowing
+      a reasonable amount of time for these dead messages to come in,
+      NCP A flushes 'Aa12' from its tables, effectively closing the
+      connection and deactivating 'Aa12'.  Further messages to socket
+      'Aa12' result in NCP A sending an ERR "erroneous command" to the
+      originating NCP.
+
+
+
+                                                               [Page 13]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      c. When NCP B receives the CLS command, socket 'Bb9' is marked as
+      "close pending", and the CLS event is placed into the event queue
+      of 'Bb9'.  The next time process 'b' wishes to write over that
+      socket, the CLS event is disclosed to inform him of the closure,
+      and socket 'Bb9' is removed from NCP B's tables.
+
+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.
+
+
+
+
+                                                               [Page 14]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+   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.
+
+   1. 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.
+
+   2. 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> .
+
+   3.  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.
+
+   4. 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.
+
+
+
+
+
+
+                                                               [Page 15]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+   5.  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.
+
+   6. 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.
+
+   7. 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.
+
+   8. 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)
+
+
+
+
+
+
+
+
+                                                               [Page 16]
+
+RFC 46                ARPA Network Protocol Notes             April 1970
+
+
+      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.
+
+               FIG. 4 Establishing a Process at a Foreign HOST
+
+
+          [ This RFC was put into machine readable form for entry ]
+          [ into the online RFC archives by Miles McCredie 11/99  ]
+
+
+
+
+                                                               [Page 17]
+