rfc55.txt

RFC 的详细文档！

            Unless one has infinite queue space, it is desirable that
            some mechanism for purging the queues of old RFC's which the
            user never bothered to examine.  An obvious but informal
            method is to note the time when each RFC is entered into the
            queue, and then periodically refuse all RFC's which have
            exceeded some arbitrary time limit.  Another thought, which
            probably should be included within the context of any
            scheme, is for the NCP to send a CLS on all outstanding
            connections or pending calls when a user logs out or blows
            up.

            The scheme which is utilized in this description may seem at
            first blush to be non-intuitive; but we feel it is more
            realistic than other proposals.  Basically, when a CONNECT
            is issued, the NCP assumes that this socket wishes to talk
            to the specified foreign socket and to that socket only.  It
            therefore purges from the pending call queue all non-
            matching RFC's by sending back CLS's.  Similarly, when the
            connection is in the RFC-SEND state (a CONNECT has been
            issued), all non-matching RFC's are refused.  If a LISTEN-
            ACCEPT or LISTEN- CLOSE sequence is executed, the remainder





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


            of the pending calls are not removed from the queue, in the
            expectation that the user may wish to accept these requests
            in the future.

            Although the latter method may seem to be arbitrary and/or
            unnecessarily restrictive, we have not yet concocted a
            scenario which would be prohibited by this method, assuming
            that we are dealing with a competent programmer (i.e., one
            who is wary of race conditions and the asynchronous nature
            of the net).  Of course whatever scheme or schemes a
            particular site chooses is highly implementation dependent;
            we suggest that some provision for the queuing of RFC's be
            provided for a period of time at least of the order of
            magnitude that they are retained in the CONNECT-clear scheme
            mentioned above.

   B. Flow Control

      Meaningful data can only flow on a connection when it is fully
      opened (i.e., two RFC's have been exchanged and closing has not
      begun).  We assume that the NCP's have a buffer for receiving
      incoming data and that there is some meaningful quantity which
      they can advertise (on a per connection basis) indicating the size
      message they can handle.  We further assume that the sending side
      regulates its transmission according to the advertisements of that
      size.

      When a connection is opened, a cell (called 'Their Size') is set
      to zero.  The receive-side will decide how much space it can
      allocate and send an ALL message specifying that space.  The
      send-side will increment 'Their Size' by the allocated space and
      will then be able to send messages of length less than or equal to
      'Their Size' When messages are transmitted, the length of the
      message is subtracted from 'Their Size'.  When the receive-side
      allocates more buffer space (e.g. when a message is taken by the
      user, thus freeing some system buffer space), the number of bits
      released is sent to the send-side via an ALL message.

      Thus, 'Their Size' is never allowed to become negative and no
      transmission can take place if 'Their Size' equals zero.

      Notice that the lengths specified in ALL messages are increments
      not the absolute size of the receiving buffer.  This is
      necessitated  by the full duplex nature of the flow control
      protocol.  The length field of the ALL message can be 32 bits long
      (note: this is an unsigned integer), thus providing the facility
      for essentially an infinite "bit sink", if that may ever be
      desired.



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


   C. Closing

      Just as two RFC's are required to open a connection, two CLS's are
      required to close a connection.  Closing occurs under various
      circumstances and serves several purposes.  To simplify the
      analysis of race conditions, we distinguish four cases: aborting,
      refusing, termination by receiver, termination by sender.

      A user "aborts" a connection when he issues a CONNECT and then a
      CLOSE before the CONNECT is acknowledged.  Typically a user will
      abort following an extended wait for the acknowledgment; his
      system may also abort for him if he blows up.

      A user "refuses" a connection when he issues a LISTEN and, after
      being notified of a prospective caller, issues a CLOSE.  Any
      requests for connection to a socket which is expecting a call from
      a particular socket are also refused.

      After a connection is established, either side may terminate.  The
      required sequence of events suggests that attempts to CLOSE by the
      receive-side should be viewed as "requests" which are always
      honored as soon as possible by the send-side.  Any data which has
      not yet been passed to the user, or which continues over the
      network, is discarded.  Requests to CLOSE by the send-side are
      honored as soon as all data transmission is complete.

         1. Aborting

            We may distinguish three cases:

            a) In the simplest case, we send an RFC followed later by a
               CLS.  The other side responds with a CLS and the attempt
               to connect ends.

            b) The foreign process may accept the connection
               concurrently with the local process aborting it.  In this
               case, the foreign process will believe the local process
               is terminating an open connection.

            c) The foreign process may refuse the connection
               concurrently with the local process aborting it.  In this
               case, the foreign process will believe the local process
               is acknowledging its refusal.








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


         2. Refusing

            After an RFC is received, the local host may respond with an
            RFC or a CLS, or it may fail to respond.  (The local host
            may have already sent its own RFC, etc.)  If the local host
            sends a CLS, the local host is said to be "refusing" the
            request for connection.

            We require that CLS commands be exchanged to close a
            connection, so it is necessary for the local host to
            maintain the rendezvous table entry until an acknowledging
            CLS is returned.

         3. Terminating by the Sender

            When the user on the send side issues a CLOSE system call,
            his NCP must accept it immediately, but may not send out a
            CLS command until all the data in the local buffers has been
            passed to the foreign host.  It is thus necessary to test
            for both 'buffer-empty' and
            'RFNM-received' before sending the CLS command.  As usual,
            the CLS must be acknowledged before the entry may be
            deleted.

         4. Terminating by the Receiver

            When the user on the receive side issues a CLOSE system
            call, his NCP accepts and sends the CLS command immediately.
            Data may still arrive, however, and this data should be
            discarded.  The send side, upon receiving the CLS, should
            immediately terminate the data flow.

VII. Connection Status

   An excellent mechanism for describing the sequence of events required
   to establish and terminate a connection involves a state diagram.  We
   may assume that each socket can be associated with a state machine,
   and that this state machine may, at any time, be in one of ten
   possible states.  In any state, certain network events cause the
   connection status to enter another state; other events are ignored;
   still others are error.  A transition may also involve the local NCP
   performing some action.  Figure 7.1 depicts the state machine.
   Circles [now boxes: Ed] represent states (described below); arrows
   show legal transitions between states.  The labels on the arrows
   identify the event which caused them (note that CLOSE is a system
   call, CLS is a control command).  Phrases after slashes denote the
   action which should  be performed while traveling over that arrow.
   The arrow labeled '[E]RFC' (found between states 0 and 1) represents



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


   the condition that whenever a connection enters the CLOSED state, the
   pending call queue for that connection is checked [Original was
   backwards "E": Ed.]

   If any pending calls exist in the queue, the connection moves to the
   PENDING state.  If an RFC is received for a socket in the CLOSED
   state, it is also moved along this path to the PENDING state.  Events
   and the actions they cause are described in sections VIII and IX
   below.  Descriptions of the ten states follow:

      (0) CLOSED

          The local socket is not attached to any port and no user has
          requested a connection with it.  (The table entry is non-
          existent).

      (1) PENDING CALL

          The socket is not attached to any port but one or more
          requests for connection have been received.  A LISTEN system
          call will be satisfied immediately by the first entry in the
          pending call queue for a matching request; all other pending
          calls are deleted.

      (2) LISTENING

          The socket is attached to a port.  We are waiting for a user
          to request connection with this socket.

      (3) RFC-RCVD

          We are listening and an RFC was received.  The local user has
          been informed of the pending call.  He must respond with
          either a CLOSE or an ACCEPT.

      (4) ABORT

          We have notified the user that his LISTEN has been satisfied
          but he has not yet responded; if during this time the foreign
          user aborts the connection by sending a CLS, we send a CLS to
          acknowledge the abort and mark the fact with this state.  When
          the user accepts or refuses the call, we can inform him the
          connection has been prematurely terminated.








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


      (5) RFC-SENT

          This state is entered when:

          a)  The local user has attached this socket to a port by
              issuing a CONNECT.
          b)  An RFC has been sent, and
          c)  No reply has been received.

          When the user issues a CONNECT the pending call queue is
          searched.

          If a matching RFC is not found, the queue is deleted and this
          state is entered.  As new RFC's arrive they are compared with
          our user's request.  If they do not match, the RFC is
          immediately refused.  If the RFC matches, it completes the
          initialization process and the connection enters the OPEN
          state.

      (6) OPEN

          RFC's have been exchanged and the connection is securely
          established.  Transmission may begin following receipt of an
          ALL command from the receive side, and will then proceed
          subject to flow control.

      (7) CLS-WAIT

          After the local user has executed a CLOSE, and we have issued
          a CLS, we must wait for an acknowledging CLS before the
          connection can be completely closed.   If the appropriate CLS
          has not already been received, this state is entered.

      (8) DATA-WAIT

          If we are on the send side and the local user executes a CLOSE
          system call, a CLS cannot be issued if our data buffer is not
          empty or if a RFNM for the last data message is outstanding.
          The connection enters this state to wait for these conditions
          to be fulfilled.  Upon completion and acknowledgement of
          output a CLS may be issued and the connection enters the CLS-
          WAIT state, waiting for the acknowledging CLS.   If a CLS
          arrives while in the DATA-WAIT state we clear our buffer (the
          CLS came from a receive socket, indicating it is no longer
          interested in our data) and enter the RFNM-WAIT state to wait
          for the network to clear.





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


      (9) RFNM-WAIT

          If we are on the send side and a CLS command arrives, we
          cannot issue an acknowledging CLS if we have not received the
          RFNM for our last data message.  We enter this state to await
          the RFNM, and cease all further data transmission.  When the
          RFNM comes in, a CLS may then be issued, and the connection
          will be closed.