rfc46.txt

RFC 的详细文档！

   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'