rfc2371.txt

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

     he is pulling a transaction from the secondary party).  Note that
     the entire value of <transaction string> (as defined in the section
     "TIP Uniform Resource Locators") must be specified as the
     transaction identifier. Possible responses are:

     PULLED
       The relationship has been established.  Upon receipt of this
       response, the specified transaction becomes the current
       transaction of the connection, and the connection enters Enlisted
       state. Additionally, the roles of primary and secondary become
       reversed.  (That is, the superior becomes the primary for the
       connection.)

     NOTPULLED
       The relationship has not been established (possibly, because the
       secondary party no longer has the requested transaction).  The
       connection remains in Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

   PUSH <superior's transaction identifier>

     This command is valid only in the Idle state. It seeks to establish
     a superior/subordinate relationship in a transaction with the
     primary as the superior. Note that the entire value of <transaction
     string> (as defined in the section "TIP Uniform Resource Locators")
     must be specified as the transaction identifier. Possible responses
     are:

     PUSHED <subordinate's transaction identifier>
       The relationship has been established, and the identifier by
       which the subordinate knows the transaction is returned. The
       transaction becomes the current transaction for the connection,
       and the connection enters Enlisted state.

     ALREADYPUSHED <subordinate's transaction identifier>
       The relationship has been established, and the identifier by
       which the subordinate knows the transaction is returned.
       However, the subordinate already knows about the transaction, and
       is expecting the two-phase commit protocol to arrive via a
       different connection. In this case, the connection remains in the
       Idle state.

     NOTPUSHED
       The relationship could not be established. The connection remains
       in the Idle state.



Lyon, et. al.               Standards Track                    [Page 18]

RFC 2371                    TIP Version 3.0                    July 1998


     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters Error state.

   QUERY <superior's transaction identifier>

     This command is valid only in the Idle state. A subordinate uses
     this command to determine whether a specific transaction still
     exists at the superior. Possible responses are:

     QUERIEDEXISTS
       The transaction still exists.  The connection remains in the Idle
       state.

     QUERIEDNOTFOUND
       The transaction no longer exists.  The connection remains in the
       Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters Error state.

   RECONNECT <subordinate's transaction identifier>

     This command is valid only in the Idle state. A superior uses the
     command to re-establish a connection for a transaction, when the
     previous connection was lost during Prepared state. Possible
     responses are:

     RECONNECTED
       The subordinate accepts the reconnection. The connection enters
       Prepared state.

     NOTRECONNECTED
       The subordinate no longer knows about the transaction. The
       connection remains in Idle state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters Error state.

   TLS

     This command is valid only in the Initial state. A primary uses
     this command to attempt to establish a secured connection using
     TLS.





Lyon, et. al.               Standards Track                    [Page 19]

RFC 2371                    TIP Version 3.0                    July 1998


     If the TLS command is accepted, the TLS protocol will totally
     control the underlying connection. This protocol will begin with
     the first octet after the line terminator of the TLS command (for
     data sent by the primary), and the first byte after the line
     terminator of the TLSING response (for data received by the
     primary). This implies that an implementation must not send both a
     CR and a LF octet after either the TLS command or the TLSING
     response, lest the LF octet be mistaken for the first byte of the
     TLS protocol.

     Possible responses to the TLS command are:

     TLSING
       The secondary party agrees to use the TLS protocol [3]. The
       connection enters the Tls state, and all subsequent communication
       is as defined by the TLS protocol. The connection provided by the
       TLS protocol starts out in the Initial state.

     CANTTLS
       The secondary party cannot support (or refuses to use) the TLS
       protocol. The connection remains in the Initial state.

     ERROR
       The command was issued in the wrong state, or was malformed.  The
       connection enters the Error state.

14. Error Handling

   If either party receives a line that it cannot understand it closes
   the connection. If either party (either a command or a response),
   receives an ERROR indication or an ERROR response on a connection the
   connection enters the Error state and no further communication is
   possible on that connection. An implementation may decide to close
   the connection. Closing of the connection is treated by the other
   party as a communication failure.

   Receipt of an ERROR indication or an ERROR response indicates that
   the other party believes that you have not properly implemented the
   protocol.

15. Connection Failure and Recovery

   A connection failure may be caused by a communication failure, or by
   any party closing the connection. It is assumed TIP implementations
   will use some private mechanism to detect TIP connection failure
   (e.g. socket keepalive, or a timeout scheme).





Lyon, et. al.               Standards Track                    [Page 20]

RFC 2371                    TIP Version 3.0                    July 1998


   Depending on the state of a connection, transaction managers will
   need to take various actions when a connection fails.

   If the connection fails in Initial or Idle state, the connection does
   not refer to a transaction. No action is necessary.

   If the connection fails in the Multiplexing state, all connections
   provided by the multiplexing protocol are assumed to have failed.
   Each of them will be treated independently.

   If the connection fails in Begun or Enlisted state and COMMIT has
   been sent, then transaction completion has been delegated to the
   subordinate (the superior is not involved); the outcome of the
   transaction is unknown by the superior (it is known at the
   subordinate). The superior uses application-specific means to
   determine the outcome of the transaction (note that transaction
   integrity is not compromised in this case since the superior has no
   recoverable resources involved in the transaction). If the connection
   fails in Begun or Enlisted state and COMMIT has not been sent, the
   transaction will be aborted.

   If the connection fails in Prepared state, then the appropriate
   action is different for the superior and subordinate in the
   transaction.

   If the superior determines that the transaction commits, then it must
   eventually establish a new connection to the subordinate, and send a
   RECONNECT command for the transaction. If it receives a
   NOTRECONNECTED response, it need do nothing else. However, if it
   receives a RECONNECTED response, it must send a COMMIT request and
   receive a COMMITTED response.

   If the superior determines that the transaction aborts, it is allowed
   to (but not required to) establish a new connection and send a
   RECONNECT command for the transaction. If it receives a RECONNECTED
   response, it should send an ABORT command.

   The above definition allows the superior to reestablish the
   connection before it knows the outcome of the transaction, if it
   finds that  convenient. Having succeeded in a RECONNECT command, the
   connection is back in Prepared state, and the superior can send a
   COMMIT or ABORT command as appropriate when it knows the transaction
   outcome.

   Note that it is possible for a RECONNECT command to be received by
   the subordinate before it is aware that the previous connection has
   failed. In this case the subordinate treats the RECONNECT command as




Lyon, et. al.               Standards Track                    [Page 21]

RFC 2371                    TIP Version 3.0                    July 1998


   a failure indication and cleans-up any resources associated with the
   connection, and associates the transaction state with the new
   connection.

   If a subordinate notices a connection failure in Prepared state, then
   it should periodically attempt to create a new connection to the
   superior and send a QUERY command for the transaction. It should
   continue doing this until one of the following two events occurs:

   1. It receives a QUERIEDNOTFOUND response from the superior. In this
      case, the subordinate should abort the transaction.

   2. The superior, on some connection that it initiated, sends a
      RECONNECT command for the transaction to the subordinate. In this
      case, the subordinate can expect to learn the outcome of the
      transaction on this new connection. If this new connection should
      fail before the subordinate learns the outcome of the transaction,
      it should again start sending QUERY commands.

   Note that if a TIP system receives either a QUERY or a RECONNECT
   command, and for some reason is unable to satisfy the request (e.g.
   the necessary recovery information is not currently available), then
   the connection should be dropped.

16. Security Considerations

   This section is meant to inform application developers, transaction
   manager developers, and users of the security implications of TIP as
   described by this document. The discussion does not include
   definitive solutions to the issues described, though it does make
   some suggestions for reducing security risks.

   As with all two phase-commit protocols, any security mechanisms
   applied to the application communication protocol are liable to be
   subverted unless corresponding mechanisms are applied to the
   commitment protocol. For example, any authentication between the
   parties using the application protocol must be supported by security
   of the TIP exchanges to at least the same level of certainty.

16.1. TLS, Mutual Authentication and Authorization

   TLS provides optional client-side authentication, optional server-
   side authentication, and optional packet encryption.

   A TIP implementation may refuse to provide service unless TLS is
   being used. It may refuse to provide service if packet encryption is
   not being used. It may refuse to provide service unless the remote
   party has been authenticated (via TLS).



Lyon, et. al.               Standards Track                    [Page 22]

RFC 2371                    TIP Version 3.0                    July 1998


   A TIP implementation should be willing to be authenticated itself
   (via TLS). This is true regardless of whether the implementation is
   acting as a client or a server.

   Once a remote party has been authenticated, a TIP transaction manager
   may use that remote party's identity to decide what operations to
   allow.

   Whether TLS is to be used on a connection, and if so, how TLS is to
   be used, and what operations are to subsequently be allowed, is
   determined by the security policies of the connecting TIP transaction
   managers towards each other. How these security policies are defined,
   and how a TIP transaction manager learns of them is totally private
   to the implementation and beyond the scope of this document.

16.2. PULL-Based Denial-of-Service Attack

   Assume that a malicious user knows the identity of a transaction that
   is currently active in some transaction manager. If the malefactor
   opens a TIP connection to the transaction manager, sends a PULL
   command, then closes the connection, he can cause that transaction to
   be aborted. This results in a denial of service to the legitimate
   owner of the transaction.

   An implementation may avoid this attack by refusing PULL commands
   unless TLS is being used, the remote party has been authenticated,
   and the remote party is trusted.

16.3. PUSH-Based Denial-of-Service Attack

   When the connection between two transaction managers is closed while
   a transaction is in the Prepared state, each transaction manager
   needs to remember information about the transaction until a
   connection can be re-established.

   If a malicious user exploits this fact to repeatedly create
   transactions, get them into Prepared state and drop the connection,
   he may cause a transaction manager to suffer resource exhaustion,