rfc1644.txt

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

      guard against antique non-SYN segments by simply checking the CC
      value in the segment againsts TCB.CCrecv.  Note that this check
      does not use the monotonic property of the CC values, only that
      they not cycle in less than 2*MSL.  Again, the quiet time at
      system restart protects against errors due to crash with loss of
      state.

      If the connection duration exceeds MSL, safety from old duplicates
      still requires a TIME-WAIT delay of 2*MSL.  Thus, truncation of
      TIME-WAIT state is only possible for short connections.  (This
      problem has also been noticed by Shankar and Lee [ShankarLee93]).
      This difference in behavior for long and for short connections
      does create a slightly complex service model for applications
      using T/TCP.  An application has two different strategies for
      multiple connections.  For "short" connections, it should use a
      fixed port pair and use the T/TCP mechanism to get rapid and
      efficient transaction processing.  For connections whose durations
      are of the order of MSL or longer, it should use a different user
      port for each successive connection, as is the current practice
      with unmodified TCP.  The latter strategy will cause excessive
      overhead (due to TCB's in TIME-WAIT state) if it is applied to
      high-frequency short connections.  If an application makes the
      wrong choice, its attempt to open a new connection may fail with a
      "busy" error.  If connection durations may range between long and
      short, an application may have to be able to switch strategies
      when one fails.

   2.4  Truncating TIME-WAIT State

      Truncation of TIME-WAIT state is necessary to achieve high
      transaction rates.  As Figure 2 illustrates, a standard
      transaction leaves the client end of the connection in TIME-WAIT
      state.  This section explains the protocol implications of
      truncating TIME-WAIT state, when it is allowed (i.e., when the
      connection has been in existence for less than MSL).  In this
      case, the client host should be able to interrupt TIME-WAIT state
      to initiate a new incarnation of the same connection (i.e., using
      the same host and ports).  This will send an initial <SYN>
      segment.

      It is possible for the new <SYN> to arrive at the server before
      the retransmission state from the previous incarnation is gone, as
      shown in Figure 5.  Here the final <ACK> (segment #3) from the
      previous incarnation is lost, leaving retransmission state at B.
      However, the client received segment #2 and thinks the transaction
      completed successfully, so it can initiate a new transaction by
      sending <SYN> segment #4.  When this <SYN> arrives at the server
      host, it must implicitly acknowledge segment #2, signalling



Braden                                                         [Page 12]

RFC 1644                    Transaction/TCP                    July 1994


      success to the server application, deleting the old TCB, and
      creating a new TCB, as shown in Figure 5.  Still assuming that the
      new <SYN> is known to be valid, the server host marks the new
      connection half-synchronized and delivers data3 to the server
      application.  (The details of how this is accomplished are
      presented in Section 3.3.)

      The earlier discussion of the TAO mechanism assumed that the
      previous incarnation was closed before a new <SYN> arrived at the
      server.  However, TAO cannot be used to validate the <SYN> if
      there is still state from the previous incarnation, as shown in
      Figure 5; in this case, it would be exceedingly awkward to perform
      a 3WHS if the TAO test should fail.  Fortunately, a modified
      version of the TAO test can still be performed, using the state in
      the earlier TCB rather than the cached state.

      (A)  If the <SYN> segment contains a CC or CC.NEW option, the
           value SEG.CC from this option is compared with TCB.CCrecv,
           the CC value in the still-existing state block of the
           previous incarnation.  If SEG.CC > TCB.CCrecv, the new <SYN>
           segment must be valid.

      (B)  Otherwise, the <SYN> is an old duplicate and is simply
           discarded.

      Truncating TIME-WAIT state may be looked upon as composing an
      extended state machine that joins the state machines of the two
      incarnations, old and new.  It may be described by introducing new
      intermediate states (which we call I-states), with transitions
      that join the two diagrams and share some state from each.  I-
      states are detailed in Section 3.3.

      Notice also segment #2' in Figure 5.  TCP's mechanism to recover
      from half-open connections (see Figure 10 of [STD-007]) cause TCP
      A to send a RST when 2' arrives, which would incorrectly make B
      think that the previous transaction did not complete successfully.
      The half-open recovery mechanism must be defeated in this case, by
      A ignoring segment #2'.













Braden                                                         [Page 13]

RFC 1644                    Transaction/TCP                    July 1994



      TCP A  (Client)                                     TCP B (Server)
      _______________                                     ______________

      CLOSED                                                      LISTEN

  #1                --> <...,FIN,CC=x> -->                     LAST-ACK*

  #2         <-- <...ACK(FIN),data2,FIN,CC=y,CC.ECHO=x>  <---  LAST-ACK*
      TIME-WAIT
    (data2->user_A)


  #3  TIME-WAIT          --> <ACK(FIN),CC=x> --> X (DROP)

      (New Active Open)                           (New Passive Open)

  #4  SYN-SENT*    -->  <SYN, data3,CC=z> ...

                                                               LISTEN-LA
  #2' (discard) <-- <...ACK(FIN),data2,FIN,CC=y> <--- (retransmit)

  #4  SYN-SENT*        ... <SYN,data3,CC=z> -->            ESTABLISHED*
                                                    SYN OK (see text) =>
                                                            {Ack seg #2;
                                                         Delete old TCB;
                                                         Create new TCB;
                                                        data3 -> user_B;
                                                        cache.CC[A]= z;}

        Figure 5: Truncating TIME-WAIT State: SYN as Implicit ACK


   2.5  Transition to Standard TCP Operation

      T/TCP includes all normal TCP semantics, and it will continue to
      operate exactly like TCP when the particular assumptions for
      transactions do not hold.  There is no limit on the size of an
      individual transaction, and behavior of T/TCP should merge
      seamlessly from pure transaction operation as shown in Figure 2,
      to pure streaming mode for sending large files.  All the sequences
      shown in [STD-007] are still valid, and the inherent symmetry of
      TCP is preserved.

      Figure 6 shows a possible sequence when the request and response
      messages each require two segments.  Segment #2 is a non-SYN
      segment that contains a TCP option.  To avoid compatibility
      problems with existing TCP implementations, the client side should



Braden                                                         [Page 14]

RFC 1644                    Transaction/TCP                    July 1994


      send segment #2 only if cache.CCsent[B] is defined, i.e., only if
      host A knows that host B plays the new game.



          TCP A  (Client)                                 TCP B (Server)
          _______________                                 ______________

          CLOSED                                                  LISTEN


       #1  SYN-SENT*       --> <SYN,data1,CC=x>  -->        ESTABLISHED*
                                                       (TAO test OK =>
                                                        data1-> user)

       #2  SYN-SENT*       --> <data2,FIN,CC=x>  -->         CLOSE-WAIT*
                                                       (data2-> user)

                                                             CLOSE-WAIT*
       #3  FIN-WAIT-2  <-- <SYN,ACK(FIN),data3,CC=y,CC.ECHO=x> <--
            (data3->user)

       #4  TIME_WAIT   <-- <ACK(FIN),data4,FIN,CC=y> <--       LAST-ACK*
            (data4->user)

       #5  TIME-WAIT       --> <ACK(FIN),CC=x> -->                CLOSED


            Figure 6. Multi-Packet Request/Response Sequence

      Figure 7 shows a more complex example, one possible sequence with
      TAO combined with simultaneous open and close.  This may be
      compared with Figure 8 of [STD-007].


















Braden                                                         [Page 15]

RFC 1644                    Transaction/TCP                    July 1994



          TCP A                                                    TCP B
          _______________                                 ______________

          CLOSED                                                  CLOSED

      #1  SYN-SENT*         --> <SYN,data1,FIN,CC=x> ...

      #2  CLOSING*     <-- <SYN,data2,FIN,CC=y> <--            SYN-SENT*
          (TAO test OK =>
           data2->user_A

      #3  CLOSING*      --> <FIN,ACK(FIN),CC=x,CC.ECHO=y> ...

      #1'                       ... <SYN,data1,FIN,CC=x> -->    CLOSING*
                                                       (TAO test OK =>
                                                        data1->user_B)

      #4  TIME-WAIT   <-- <FIN,ACK(FIN),CC=y,CC.ECHO=x> <--     CLOSING*

      #5  TIME-WAIT    --> <ACK(FIN),CC=x> ...

      #3'              ... <FIN,ACK(FIN),CC=x,CC.ECHO=y> -->   TIME-WAIT

      #6  TIME-WAIT            <-- <ACK(FIN),CC=y> <---        TIME-WAIT

      #5' TIME-WAIT               ... <ACK(FIN),CC=x> -->      TIME-WAIT

          (timeout)                                            (timeout)
            CLOSED                                                CLOSED

                  Figure 7: Simultaneous Open and Close



















Braden                                                         [Page 16]

RFC 1644                    Transaction/TCP                    July 1994


3.  FUNCTIONAL SPECIFICATION

   3.1  Data Structures

      A connection count is an unsigned 32-bit integer, with the value
      zero excluded.  Zero is used to denote an undefined value.

      A host maintains a global connection count variable CCgen, and
      each connection control block (TCB) contains two new connection
      count variables, TCB.CCsend and TCB.CCrecv.  Whenever a TCB is
      created for the active or passive end of a new connection, CCgen
      is incremented by 1 and placed in TCB.CCsend of the TCB; however,
      if the previous CCgen value was 0xffffffff (-1), then the next
      value should be 1.  TCB.CCrecv is initialized to zero (undefined).

      T/TCP adds a per-host cache to TCP.  An entry in this cache for
      foreign host fh includes two CC values, cache.CC[fh] and
      cache.CCsent[fh].  It may include other values, as discussed in
      Sections 4.3 and 4.4.  According to [STD-007], a TCP is not
      permitted to send a segment larger than the default size 536,
      unless it has received a larger value in an MSS (Maximum Segment
      Size) option.  This could constrain the client to use the default
      MSS of 536 bytes for every request.  To avoid this constraint, a
      T/TCP may cache the MSS option values received from remote hosts,
      and we allow a TCP to use a cached MSS option value for the
      initial SYN segment.

      When the client sends an initial <SYN> segment containing data, it