rfc46.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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