rfc2371.txt

RFC 的详细文档！

Network Working Group                                           J. Lyon
Request for Comments: 2371                                    Microsoft
Category: Standards Track                                      K. Evans
                                                               J. Klein
                                                       Tandem Computers
                                                              July 1998


                     Transaction Internet Protocol
                              Version 3.0

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   In many applications where different nodes cooperate on some work,
   there is a need to guarantee that the work happens atomically. That
   is, each node must reach the same conclusion as to whether the work
   is to be completed, even in the face of failures.  This document
   proposes a simple, easily-implemented protocol for achieving this
   end.

Table of Contents

 1. Introduction                                                       2
 2. Example Usage                                                      3
 3. Transactions                                                       4
 4. Connections                                                        4
 5. Transaction Identifiers                                            5
 6. Pushing vs. Pulling Transactions                                   5
 7. TIP Transaction Manager Identification & Connection Establishment  6
 8. TIP Uniform Resource Locators                                      8
 9. States of a Connection                                            10
 10. Protocol Versioning                                              12
 11. Commands and Responses                                           12
 12. Command Pipelining                                               13
 13. TIP Commands                                                     13
 14. Error Handling                                                   20



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


 15. Connection Failure and Recovery                                  20
 16. Security Considerations                                          22
 17. References                                                       25
 18. Authors' Addresses                                               26
 19. Comments                                                         26
 Appendix A. The TIP Multiplexing Protocol Version 2.0.               27
 Fully Copyright Statement                                            31

1. Introduction

   The standard method for achieving atomic commitment is the two-phase
   commit protocol; see [1] for an introduction to atomic commitment and
   two-phase commit protocols.

   Numerous two-phase commit protocols have been implemented over the
   years.  However, none of them has become widely used in the Internet,
   due mainly to their complexity.  Most of that complexity comes from
   the fact that the two-phase commit protocol is bundled together with
   a specific program-to-program communication protocol, and that
   protocol lives on top of a very large infrastructure.

   This memo proposes a very simple two-phase commit protocol.  It
   achieves its simplicity by specifying only how different nodes agree
   on the outcome of a transaction; it allows (even requires) that the
   subject matter on which the nodes are agreeing be communicated via
   other protocols. By doing so, we avoid all of the issues related to
   application communication semantics and data representation (to name
   just a few). Independent of the application communication protocol a
   transaction manager may use the Transport Layer Security protocol [3]
   to authenticate other transaction managers and encrypt messages.

   It is envisioned that this protocol will be used mainly for a
   transaction manager on one Internet node to communicate with a
   transaction manager on another node. While it is possible to use this
   protocol for application programs and/or resource managers to speak
   to transaction managers, this communication is usually intra-node,
   and most transaction managers already have more-than-adequate
   interfaces for the task.

   While we do not expect this protocol to replace existing ones, we do
   expect that it will be relatively easy for many existing
   heterogeneous transaction managers to implement this protocol for
   communication with each other.

   Further supplemental information regarding the TIP protocol can be
   found in [5].





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


2. Example Usage

   Today the electronic shopping basket is a common metaphor at many
   electronic store-fronts. Customers browse through an electronic
   catalog, select goods and place them into an electronic shopping
   basket. HTTP servers [2] provide various means ranging from URL
   encoding to context cookies to keep track of client context (e.g.
   the shopping basket of a customer) and resume it on subsequent
   customer requests.

   Once a customer has finished shopping they may decide to commit their
   selection and place the associated orders. Most orders may have no
   relationship with each other except being executed as part of the
   same shopping transaction; others may be dependent on each other (for
   example, if made as part of a special offering).  Irrespective of
   these details a customer will expect that all orders have been
   successfully placed upon receipt of a positive acknowledgment.
   Today's electronic store-fronts must implement their own special
   protocols to coordinate such placement of all orders. This
   programming is especially complex when orders are placed through
   multiple electronic store-fronts. This complexity limits the
   potential utility of internet applications, and constrains growth.
   The protocol described in this document intends to provide a standard
   for Internet servers to achieve agreement on a unit of shared work
   (e.g. placement of orders in an electronic shopping basket).  The
   server (e.g. a CGI program) placing the orders may want to start a
   transaction calling its local transaction manager, and ask other
   servers participating in the work to join the transaction.  The
   server placing the orders passes a reference to the transaction as
   user data on HTTP requests to the other servers.  The other servers
   call their transaction managers to start a local transaction and ask
   them to join the remote transaction using the protocol defined in
   this document. Once all orders have been placed, execution of the
   two-phase-commit protocol is delegated to the involved transaction
   managers. If the transaction commits, all orders have been
   successfully placed and the customer gets a positive acknowledgment.
   If the transaction aborts no orders will be placed and the customer
   will be informed of the problem.

   Transaction support greatly simplifies programming of these
   applications as exception handling and failure recovery are delegated
   to a special component. End users are also not left having to deal
   with the consequences of only partial success.  While this example
   shows how the protocol can be used by HTTP servers, applications may
   use the protocol when accessing a remote database (e.g. via ODBC), or
   invoking remote services using other already existing protocols (e.g.





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


   RPC). The protocol makes it easy for applications in a heterogeneous
   network to participate in the same transaction, even if using
   different communication protocols.

3. Transactions

   "Transaction" is the term given to the programming model whereby
   computational work performed has atomic semantics. That is, either
   all work completes successfully and changes are made permanent (the
   transaction commits), or if any work is unsuccessful, changes are
   undone (the transaction aborts). The work comprising a transaction
   (unit of work), is defined by the application.

4. Connections

   The Transaction Internet Protocol (TIP) requires a reliable ordered
   stream transport with low connection setup costs. In an Internet (IP)
   environment, TIP operates over TCP, optionally using TLS to provide a
   secured and authenticated connection, and optionally using a protocol
   to multiplex light-weight connections over the same TCP or TLS
   connection.

   Transaction managers that share transactions establish a TCP (and
   optionally a TLS) connection. The protocol uses a different
   connection for each simultaneous transaction shared betwween two
   transaction managers. After a transaction has ended, the connection
   can be reused for a different transaction.

   Optionally, instead of associating a TCP or TLS connection with only
   a single transaction, two transaction managers may agree on a
   protocol to multiplex light-weight connections over the same TCP or
   TLS connection, and associate each simultaneous transaction with a
   separate light-weight connection. Using light-weight connections
   reduces latency and resource consumption associated with executing
   simultaneous transactions. Similar techniques as described here are
   widely used by existing transaction processing systems.  See Appendix
   A for an example of one such protocol.

   Note that although the TIP protocol itself is described only in terms
   of TCP and TLS, there is nothing to preclude the use of TIP with
   other transport protocols. However, it is up to the implementor to
   ensure the chosen transport provides equivalent semantics to TCP, and
   to map the TIP protocol appropriately.








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


   In this document the terms "connection" or "TCP connection" can refer
   to a TIP TCP connection, a TIP TLS connection, or a TIP multiplexing
   connection (over either TCP or TLS). It makes no difference which,
   the behavior is the same in each case. Where there are differences in
   behavior between the connection types, these are stated explicitly.

5. Transaction Identifiers

   Unfortunately, there is no single globally-accepted standard for the
   format of a transaction identifier; there are various standard and
   proprietary formats.  Allowed formats for a TIP transaction
   identifier are described below in the section "TIP Uniform Resource
   Locators". A transaction manager may map its internal transaction
   identifiers into this TIP format in any manner it sees fit.
   Furthermore, each party in a superior/subordinate relationship gets
   to assign its own identifier to the transaction; these identifiers
   are exchanged when the relationship is first established.  Thus, a
   transaction manager gets to use its own format of transaction
   identifier internally, but it must remember a foreign transaction
   identifier for each superior/subordinate relationship in which it is
   involved.

6. Pushing vs. Pulling Transactions

   Suppose that some program on node "A" has created a transaction, and
   wants some program on node "B" to do some work as part of the
   transaction.  There are two classical ways that he does this,
   referred to as the "push" model and the "pull" model.

   In the "push" model, the program on A first asks his transaction
   manager to export the transaction to node B.  A's transaction manager
   sends a message to B's TM asking it to instantiate the transaction as
   a subordinate of A, and return its name for the transaction.  The
   program on A then sends a message to its counterpart on B on the
   order of "Do some work, and make it part of the transaction that your
   transaction manager already knows of by the name ...".  Because A's
   TM knows that it sent the transaction to B's TM, A's TM knows to
   involve B's TM in the two-phase commit process.

   In the "pull" model, the program on A merely sends a message to B on
   the order of "Do some work, and make it part of the transaction that
   my TM knows by the name ...".  The program on B asks its TM to enlist
   in the transaction.  At that time, B's TM will "pull" the transaction
   over from A.  As a result of this pull, A's TM knows to involve B's
   TM in the two-phase commit process.

   The protocol described here supports both the "push" and "pull"
   models.



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


7. TIP Transaction Manager Identification and Connection Establishment

   In order for TIP transaction managers to connect they must be able to
   identify and locate each other. The information necessary to do this
   is described by the TIP transaction manager address.

   [This specification does not prescribe how TIP transaction managers
   initially obtain the transaction manager address (which will probably
   be via some implementation-specific configuration mechanism).]

   TIP transaction manager addresses take the form:

     <hostport><path>

   The <hostport> component comprises:

     <host>[:<port>]

   where <host> is either a <dns name> or an <ip address>; and <port> is
   a decimal number specifying the port at which the transaction manager
   (or proxy) is listening for requests to establish TIP connections. If
   the port number is omitted, the standard TIP port number (3372) is
   used.

   A <dns name> is a standard name, acceptable to the domain name