rfc55.txt

中、英文RFC文档大全打包下载完全版 .

         to-Imp transmission out of a resident buffer and wakes up the
         output scheduler when transmission is complete.

      3. The Input Interpreter

         This program decides whether the input is a regular message
         intended for a user, a network control message, an Imp-to Host
         message, or an error.  For each class of message this program
         invokes a subroutine to take the appropriate action.





Newkirk, et al.                                                 [Page 6]

RFC 55             Prototypical Implementation of NCP          June 1970


      4. The Output Scheduler

         Three classes of messages are sent to the Imp

            (a) Host-to-Imp messages
            (b) Control messages
            (c) Regular messages

         We believe that a priority should be imposed among these
         classes.  The priority we suggest is the ordering above.  The
         output scheduler selects the highest priority message and
         passes it to the output handler.

         Host-to-Imp messages are processed first come first served.
         Control messages are processed individually by host, each host
         being taken in turn.  A control message queue for each foreign
         host is provided.  When any particular host is scheduled for
         output, as many control commands for that host as will fit are
         concatenated into a single message.  Regular messages are
         processed in groups by host and link, each unique combination
         being taken in turn.

      5. The System Call Interpreter

         This program interprets requests from the user.  Each system
         call has a corresponding routine which takes the appropriate
         action.

      The two interesting components are the input interpreter and the
      system call interpreter.  These are similar in that the input
      interpreter services foreign requests and the system call
      interpreter services local requests.

      The diagram in Figure 4.1  is our conception of the Network
      Control Program.  Squishy amoeba-like objects represent component
      programs, cylinders represent queues, and the arrows represent
      data paths.  In this simplified diagram tables are not shown.
      ["Amoeba-like" objects in original hand drawing are now firm
      rectangular boxes: Ed.]

      The abbreviated labels in the figure have the following meanings:

            HIQ       -     Host-to-Imp Queue
            OCCQ      -     Output Control Command Queue
            DQ        -     Data Queue
            IHBUF     -     Input Handler Buffer
            OHBUF     -     Output Handler Buffer




Newkirk, et al.                                                 [Page 7]

RFC 55             Prototypical Implementation of NCP          June 1970


             ____________
            |    USER    |    STRUCTURE OF THE NETWORK CONTROL PROGRAM
            |____________|
               ^      |                      Fig. 4.1
          _____|______V____
         |                 |
         |     System      |
         |      Call       |
         |   Interpreter   |
         |_________________|              _____________
            ^  |      |                  |             |
            |  |      |  +---------------|    Input    |
            |  |      |  |         +-----| Interpreter |
            |  |      |  |         |     |             |
            |  V      V  V         V      -------------
          |======| |=========| |=======|     |      ^
          | D Q  | | O C C Q | | H I Q |     |      |
          |======| |=========| |=======|     |      |
            |  ^        |          |         |      |
            |  |        |          |         |      |
            |  +--------)----------)---------+      |
            |           |          |                |
            +-------+   |   +------+                |
                  __V___V___V__                     |
                 |             |                    |
                 |   Output    |                    |
                 |  Scheduler  |                    |
                 |_____________|                    |
                        |                           |
                        V                           |
                  (===========)               (===========)
                  ( O H B U F )               ( I H B U F )
                  (===========)               (===========)
                        |                           ^
                  ______V______               ______|______
                 |             |             |             |
                 |   Output    |             |    Input    |
                 |   Handler   |             |   Handler   |
                 |             |             |             |
                  -------------               -------------
                        |                           ^
                        |                           |
                        +----------+    +-----------+
                                   |    |
                               ____V____|____
                              |              |
                              |     I M P    |
                              |______________|



Newkirk, et al.                                                 [Page 8]

RFC 55             Prototypical Implementation of NCP          June 1970


V. Tables in the NCP

   We envision that the bulk of the NCP's data base is in associative
   tables.  By "associative" we mean that there is some lookup routine
   which is presented with a key and either returns successfully with a
   pointer to the corresponding entry, or fails if no entry corresponds
   to the key.  The major tables are as follows:

      1. The Rendezvous Table

         This table holds the attributes of a connection.  The table is
         accessed by the local socket, but other tables may have
         pointers to existing entries.

         The components of an entry are:

            (a) Local Socket
            (b) Foreign Socket
            (c) Link
            (d) Connection State
            (e) Flow State
            (f) Data Queue
            (g) Call Queue
            (h) Port Pointer
            (i) Their Buffer Size (only needed on the send side)
            (j) Error State

         An entry is created when either a CONNECT or a LISTEN system
         call is executed or when a request for connection is received.
         Various fields remain unused until after the connection is
         established.

      2. The Input Link Table

         The input interpreter uses the concatenation of the foreign
         host and link as a key into the input table.  The table is used
         in processing a user-destined message on an incoming link by
         providing a pointer into the rendezvous table.

      3. The Output Link Table

         The input interpreter uses the output link table to access the
         flow state as RFNM's return from transmitted messages.  The
         output link table is keyed by host and link and provides a
         pointer into the rendezvous table.






Newkirk, et al.                                                 [Page 9]

RFC 55             Prototypical Implementation of NCP          June 1970


      4. The Port Table

         The system call interpreter uses the concatenation of the
         process identification and the port identification as a key to
         obtain a pointer into the rendezvous table.

      5. The Output Control Command Table

         The system call interpreter and the input interpreter use this
         table to make entries in the appropriate output control command
         queues.  Commands are queued in separate table entries
         corresponding to foreign hosts.  Before output the contents of
         the queue are concatenated into a large control message.  The
         components of an entry are:

            (a)  Host
            (b)  Output Control Command Queue

      6. The Output Request Queue

         This queue contains an entry for each connection which has data
         requiring transmission to the net.  There is only one entry per
         connection, which is deleted when the last packet of data is
         transmitted and is entered whenever a user makes a system
         request for data transmission.

         The entry is re-inserted if transmission is not completed
         (message too long) or is prevented by the flow control
         mechanism.  The only component of an entry is a local socket.

      7. The Host Live Table

         This is a simple table listing the hosts which are alive.  This
         table is checked before establishing a connection and before
         sending any data to ensure that the destination host actually
         exists.  At present the protocol does not define the procedure
         to be followed for the Host up/Host down conditions.  See
         NWG/RFC#57.

      8. The Link Assignment Table

         Link numbers are assigned by the receiver.  This table records
         which links are free and can, therefore, be assigned.








Newkirk, et al.                                                [Page 10]

RFC 55             Prototypical Implementation of NCP          June 1970


VI.  Informal Description of Network Operations

   We present here narratives describing the operation conducted during
   the three major phases of network usage: opening, flow control, and
   closing.

   A. Opening

      In order to establish a connection for data transmission, a pair
      of RFC's must be exchanged.  An RTS must go from the receive-side
      to the send-side, and an STR must be issued by the send-side to
      the receive-side.  In addition, the receive-side, in its RTS, must
      specify a link number.  These RFC's (RFC is a generic term
      encompassing RTS and STR) may be issued in any time sequence.  A
      provision must also be made for queuing pending calls (i.e., RFC's
      which have not been dealt with by the user program).  Thus, when a
      user is finished with a connection, he may choose to examine the
      next pending call from another process and decide to either accept
      or refuse the request for connection.  A problem develops because
      the user may not choose to examine his pending calls; thus they
      will merely serve to occupy queue space in the NCP.  Several
      alternative solutions to this problem will be mentioned later.

      Utilizing the framework of the prototype system calls described
      above, we envision at least four temporal sequences for obtaining
      a successfully opened connection:

         1. The user may issue a LISTEN, indicating he is willing to
            consider connecting to anyone who sends him an RFC.  When an
            RFC comes in the user is notified.  The user then decides
            whether he wishes to connect to this socket and issues an
            ACCEPT or a CLOSE on the basis of that decision.  A CLOSE '
            refuses' the connection, as discussed under "Closing."  An
            ACCEPT indicates he is willing to connect; an RFC is issued,
            and the connection becomes fully opened.

         2. Upon processing a user request for a LISTEN, the NCP
            discovers that a pending call exists for that local socket.
            The user is immediately notified, and he may ACCEPT or
            CLOSE, as above.

         3. The user issues a CONNECT, specifying a particular foreign
            socket that he would like to connect to.  An RFC is issued.
            If the foreign process accepts the request, it answers by
            returning an RFC.  When this acknowledging RFC is received,
            the connection is opened.





Newkirk, et al.                                                [Page 11]

RFC 55             Prototypical Implementation of NCP          June 1970


         4. When presented with a CONNECT, the NCP may discover that a
            pending call exists from the specified foreign socket to the
            local socket in question.  An acknowledging RFC is issued
            and the connection is opened.

      In all of the above cases the user is notified when the connection
      is opened, but data flow cannot begin until buffer space is
      allocated and an ALL command is transmitted.

      Any of these connection scenarios will be interrupted if a CLS
      comes in, as discussed under "Closing."

         1. Pending Call Queues

            It is essential that some form of queuing for pending RFC's
            be implemented.  A simple way to see this is to examine a
            typical LISTEN-CONNECT sequence.  One side issues a LISTEN,
            the other a CONNECT.  If the LISTEN is issued before the RFC
            coming from the remote CONNECT arrives, all is fine.
            However, due to the asynchronous nature of the net, we can
            never guarantee that this sequence of events will occur.  If
            calls are not queued, and the RFC comes in before the LISTEN
            is issued, it will be refused; if it arrives later, it will
            be accepted.  Thus we have an extremely ambiguous situation.