rfc46.txt

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

                     <============== 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]