rfc675.txt

RFC 相关的技术文档

   The scenario for a simultaneous attempt to establish the connection
   without the arrival of any delayed duplicates is --

                    A                                     B
            ------------                               ------------
            S1 S2 R                                         S1 S2 R

             0  0 0                                          0  0 0

      (M1)   1  0 0 --> <SEQ x><SYN>                    ...

      (M2)   0  0 0 <-- <SEQ y><SYN)                    <--  1  0 0

      (M1)              B returns no SYN sent           -->  0  0 0

      (M1)   1  0 0 --> <SEQ z><SYN>      *             -->  0  0 1

      (M3)   1  1 1 <-- <SEQ y+1><SYN,ACK z+1>          <--  1  0 1

      (M4)   1  1 1 --> <SEQ z+1><ACK y+1><DATA>        -->  1  1 1

      Note: "..." means that a message does not arrive, but is delayed
      in the network. State changes are upon arrival or upon departure
      of a given message, as the case may be. Packets containing the SYN
      or INT or DSN bits implicitly contain a "dummy" data octet which
      is never delivered to the user, but which causes the packet
      sequence numbers to be incremented by 1 even if no real data is
      sent. This permits the acknowledgment of these controls without
      acknowledging receipt of any data which might also have been
      carried in the packet. A packet containing a FIN bit has a dummy
      octet following the last octet of data (if any) in the packet.

      * Once in state 000 sender selects new ISN z when attempting to
      establish the connection again.

4.3.3 HALF-OPEN CONNECTIONS

   An established connection is said to be a "half-open" connection if
   one of the TCP's has closed the connection at its end without the
   knowledge of the other, or if the two ends of the connection have
   become desynchronized owing to a crash that resulted in loss of
   memory. Such connections will automatically become reset if an
   attempt is made to send data in either direction. However, half-open
   connections are expected to be unusual, and the recovery procedure is
   somewhat involved.






Cerf, Dalal & Sunshine                                         [Page 25]

RFC 675              Specification of Internet TCP         December 1974


   If one end of the connection no longer exists, then any attempt by
   the other user to send any data on it will result in the sender
   receiving the event code "Connection does not exist at foreign TCP".
   Such an error message should indicate to the user process that
   something is wrong and it is expected to CLOSE the connection.

   Assume that two user processes A and B are communicating with one
   another when a crash occurs causing loss of memory to B's TCP.
   Depending on the operating system supporting B's TCP, it is likely
   that some error recovery mechanism exists. When the TCP is up again B
   is likely to start again from the beginning or from a recovery point.
   As a result B will probably try to OPEN the connection again or try
   to SEND on the connection it believes open. In the latter case 1t
   receives the error message "connection not open" from the local TCP.
   In an attempt to establish the connection B's TCP will send a packet
   containing SYN. A's TCP thinks that the connection is already
   established and so will respond with the error "unacceptable SYN (or
   SYN/ACK) arrived at foreign TCP". B's TCP knows that this refers to
   the SYN it just sent out, and so should reset the connection and
   inform the user process of this fact.

   It may happen that B is passive and only wants to receive data. In
   this case A's data will not reach B because the TCP at B thinks the
   connection is not established. As a result A'S TCP will timeout and
   send a QRY to B's TCP. B's TCP will send STATUS saying the connection
   is not synched. A's TCP will treat this as if an implicit CLOSE had
   occurred and tell the user process, A, that the connection is
   closing. A is expected to respond with a CLOSE command to his TCP.
   However, A's TCP does not send a FIN to B's TCP, since it would not
   be accepted anyway on the unsynced connection. Eventually A will try
   to reopen the connection or B will give up and CLOSE. If B CLOSES,
   B's TCP will simply delete the connection since it was not
   established as far as B's TCP is concerned. No message will be sent
   to A'S TCP as a result.

4.3.4  RESYNCHRONIZING A CONNECTION

   Details of resynchronization have not yet been specified since the
   need for this should be infrequent in the initial testing stages.

4.3.5 CLOSING A CONNECTION

   There are essentially three cases:

      a) The user initiates by telling the TCP to CLOSE the connection

      b) The remote TCP initiates by sending a FIN control signal




Cerf, Dalal & Sunshine                                         [Page 26]

RFC 675              Specification of Internet TCP         December 1974


      c) Both users CLOSE simultaneously

   Two bits are used to maintain control over the closing of a
   connection: these are called the "FIN sent" bit [F] and the "USER
   Closed" bit, [C] respectively. The control procedure uses these two
   bits to assure that the connection is properly closed.

   Case 1: Local user initiates the close

      In this case, both the F and C bits are initially zero, but the C
      bit is set immediately upon receipt of the user call "CLOSE." When
      the FIN is sent out by the TCP, the F bit is set. All pending
      RECEIVES are terminated and the user is told that they have been
      prematurely terminated ("connection closing"} without data.
      Similarly, any pending SENDS are terminated with the same
      response, "connection closing."

      Several responses may arrive as the result of sending a FIN. The
      one which is generally expected is a matching FIN. When this is
      received, the TCB CAN BE ELIMINATED. If a "connection does not
      exist at foreign TCP" message comes in response to the FIN, then
      the TCB can likewise be eliminated. If no response is forthcoming,
      or if "Foreign TCP inaccessible" arrives then the resolution is
      moot. One might simply timeout and discard the TCB. Since the
      local user wants to CLOSE anyway, this is probably satisfactory,
      although it will leave a potential "half-open" connection at the
      other side. We deal with half open connections in section 4.3.3.

      When the acknowledging FIN arrives after the connection state bits
      are set (F=1, C=1), then the TCB can be deleted.

   Case 2: TCP receives a FIN from the network

      First of all, a FIN must have a sequence number which lies in the
      valid receive window. If not, it is discarded and the left window
      edge is sent as acknowledgment. If the FIN can be processed, it is
      handled (possibly out of order, since it is taken as an imperative
      to shut down the connection). All pending RECEIVES and SENDS are
      responded to by showing that they were terminated by the other
      side's close request (i.e. "connection closing"). The user is also
      told by an unsolicited event or signal that the connection has
      been closed (in some systems, the user might have to request
      STATUS to get this information). Finally, the TCP sends FIN in
      response.

      Thus, because a FIN arrived, a FIN is sent back, so the F bit is
      set. However, the TCB stays around until the local user does a
      CLOSE in acknowledgment of the unsolicited signal that the



Cerf, Dalal & Sunshine                                         [Page 27]

RFC 675              Specification of Internet TCP         December 1974


      connection has been closed by the other side. Thus, the C bit
      remains unset until this happens. If the C and F bits go from (F=1
      C=O) to (F=l, C=1), then the connection is closed and the TCB can
      be removed.

   Case 3: both users close simultaneously

      If this happens, both connections will be in the (F=1, C=1) state.
      When the FINs arrive, the connections w11i be shut down. If one
      FIN fails to arrive, we have two choices. One is to insist on
      acknowledgments for FINs, in which case the missing one will be
      retransmitted. Another is merely to permit the half-open
      connection to remain (we prefer this solution}. It can timeout
      independently and go away after a while. If an attempt is made to
      reestablish the connection, the initiator will discover the
      existence of the open connection since an "inappropriate SYN
      received" message will be sent by the TCP which holds the "half-
      open" connection. The receiver of this message can tell the other
      TCP to reset the connection. We cannot permit the holder of the
      half-open connection to reset automatically on receipt of the SYN
      since its receipt is not necessarily prima facie evidence of a
      half open connection. (The SYN could be a delayed duplicate.)

4.3.6.  CONNECTION STATE and its relation to USER and INCOMING CONTROL
   REQUESTS

   In order to formalize the action taken by the TCP when it receives
   commands from the User, or Control information from the network, we
   define a connection to be in one of 7 states at any instant. These
   are known as the TCB Major States. Each Major State is simply a
   convenient name for a particular setting or group of settings of the
   state bits, as follows:

      S1 S2  R  U  F  C   #   name

       -  -  -  -  -  -   0   no TCB

       0  0  0 0/1 0  0   1   unsync

       1  0  0  0  0  0   2   SYN sent

       1  0  1 0/1 0  0   3   SYN received

       1  1  1  0  0  0   4   established

       1 0/1 1 0/1 1  1   5   FIN wait

       1  1  1  0  1  0   6   FIN received



Cerf, Dalal & Sunshine                                         [Page 28]

RFC 675              Specification of Internet TCP         December 1974


   The connection moves from state to state as shown below. The
   transition from one state to another will be represented as

      [X, Y]<cause><action>

   which means that there is a transition from state X to state Y owing
   to <cause>. The action taken by the TCP is specified as <action>. We
   use this notation to give the important state transitions, often
   simplifying the cause and action fields to take into account a number
   of situations. Figure 1 illustrates these transitions in traditional
   state diagram form. Section 4.4.6 and section 4.4.7 fully specify the
   effect of all User commands and Control information arriving from the
   network.

      [0,l] <OPEN> <create TCB>

      [1,2] <SEND,INTERRUPT, or collision timeout> <send SYN>

      [1,3] <SYN arrives> <send SYN,ACK>

      [1,0] <CLOSE> <remove TCB>

      [2,1] <SYN arrives (collision)> <set timeout, forget SYNs>

      [2,0] <CLOSE> <remove TCB>

      [2,4] <appropriate SYN,ACK arrives> <send ACK>

      [3,4] <appropriate ACK arrives> <none>

      [3,1] <error arrives or timeout> <(forget SYN)>

      [3,5] <CLOSE> <send FIN>

      [4,5] <CLOSE> <send FIN>

      [4,6] <appropriate FIN arrives> <send FIN, inform user>

      [5,0] <FIN or error arrives, or timeout> <remove TCB>

      [6,0] <CLOSE> <remove TCB>

4.4  STRUCTURE 0F THE TCP

4.4.l  INTRODUCTION [See figure 2.1]

   There are many possible implementations of the TCP. We offer one
   conceptual framework in which to view the various algorithms that



Cerf, Dalal & Sunshine                                         [Page 29]

RFC 675              Specification of Internet TCP         December 1974


   make up the TCP design. In our concept, the TCP is written in two
   parts, an interrupt or signal driven part (consisting of four
   processes), and a reentrant library of subroutines or system calls
   which interface the user process to the TCP. The subroutines
   communicate with the interrupt part through shared data structures
   (TCB's, shared buffer queues etc.). The four processes are the Output
   Packet Handler which sends packets to the packet switch; the
   Packetizer which formats letters into internet packets; the Input
   Packet Handler which processes incoming packets; and the Reassembler
   which builds letters for users.

   The ultimate bottleneck is the pipe through which arriving and
   departing packets must travel. This is the Host/Packet Switch
   interface. The interrupt driven TCP shares among all TCB's its
   limited packet buffer resources for sending and receiving packets.
   From the standpoint of controlling buffer congestion, it appears
   better to TREAT INCOMING PACKETS WITH HIGHER PRIORITY THAN OUTGOING
   PACKETS. That is, packet buffers which can be released by copying
   their contents into user buffers clearly help to reduce congestion.
   Neither the packetizer nor the input packet handler should be allowed
   to take up all available packet buffer space; an analogous problem
   arises in the IMP in the allocation of store and forward, and
   reassembly buffer space. One policy is to permit neither contender
   more than, say, two-thirds of the space. The buffer allocation
   routines can enforce these limits and reject buffer requests as
   needed. Conceptually, the scheduler can monitor the amounts of
   storage dedicated to the input and output routines, and can force
   either to sleep if its buffer allocation exceeds the limit.

   As an example, we can consider what happens when a user executes a
   SEND call to the TCP service routines. The buffer containing the
   letter is placed on a SEND buffer queue associated with the user's
   TCB. A 'packetizer' process is awakened to look through all the TCB's
   for 'packetizing' work. The packetizer will keep a roving pointer
   through the TCB list which enables it to pick up new buffers from the
   TCB queue and packetize them into output buffers. The packetizer
   takes no more than one letter at a time from any single TCB. The
   packetizer attempts to maintain a non-empty queue of output packets
   so that the output handler will not fall idle waiting for the
   packetizing operation. However, since arriving packets compete with
   departing packets, care must be taken to prevent either class from
   occupying all of the shared packet buffer space. Similarly since the
   TCB's all compete for space in service to their connections, neither
   input nor output packet space should be dominated by any one TCB.

   When a packet is created, it is placed on a FIFO SEND packet queue
   associated with its origin TCB. The packetizer wakes the output
   handler and then continues to packetize a few more buffers, perhaps,



Cerf, Dalal & Sunshine