rfc2371.txt

RFC 的详细文档！

10. Protocol Versioning

   This document describes version 3 of the protocol. In order to
   accommodate future versions, the primary party sends a message
   indicating the lowest and the highest version number it understands.
   The secondary responds with the highest version number it
   understands.

   After such an exchange, communication can occur using the smaller of
   the highest version numbers (i.e., the highest version number that
   both understand). This exchange is mandatory and occurs using the
   IDENTIFY command (and IDENTIFIED response).

   If the highest version supported by one party is considered obsolete
   and no longer supported by the other party, no useful communication
   can occur.  In this case, the newer party should merely drop the
   connection.

11. Commands and Responses

   All commands and responses consist of one line of ASCII text, using
   only octets with values in the range 32 through 126 inclusive,
   followed by either a CR (an octet with value 13) or an LR (an octet
   with value 10).  Each line can be split up into one or more "words",
   where successive words are separated by one or more space octets
   (value 32).

   Arbitrary numbers of spaces at the beginning and/or end of each line
   are allowed, and ignored.

   Lines that are empty, or consist entirely of spaces are ignored.
   (One implication of this is that you can terminate lines with both a
   CR and an LF if desired; the LF will be treated as terminating an
   empty line, and ignored.)

   In all cases, the first word of each line indicates the type of
   command or response; all defined commands and responses consist of
   upper-case letters only.

   For some commands and responses, subsequent words convey parameters
   for the command or response; each command and response takes a fixed
   number of parameters.

   All words on a command or response line after (and including) the
   first undefined word are totally ignored. These can be used to pass
   human-readable information for debugging or other purposes.





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


12. Command Pipelining

   In order to reduce communication latency and improve efficiency, it
   is possible for multiple TIP "lines" (commands or responses) to be
   pipelined (concatenated) together and sent as a single message.
   Lines may also be sent "ahead" (by the secondary, for later procesing
   by the primary). Examples are an ABORT command immediately followed
   by a BEGIN command, or a COMMITTED response immediately followed by a
   PULL command.

   The sending of pipelined lines is an implementation option. Likewise
   which lines are pipelined together. Generally, it must be certain
   that the pipelined line will be valid for the state of the connection
   at the time it is processed by the receiver. It is the responsibility
   of the sender to determine this.

   All implementations must support the receipt of pipelined lines - the
   rules for processing of which are described by the following
   paragraph:

     When the connection state is such that a line should be read
     (either command or response), then that line (when received) is
     processed. No more lines are read from the connection until
     processing again reaches such a state. If a line is received on a
     connection when it is not the turn of the other party to send, that
     line is _not_ rejected. Instead, the line is held and processed
     when the connection state again requires it. The receiving party
     must process lines and issue responses in the order of lines
     received. If a line causes an error the connection enters the Error
     state, and all subsequent lines on the connection are discarded.

13. TIP Commands

   Commands pertain either to connections or transactions. Commands
   which pertain to connections are: IDENTIFY, MULTIPLEX and TLS.
   Commands which pertain to transactions are: ABORT, BEGIN, COMMIT,
   PREPARE, PULL, PUSH, QUERY, and RECONNECT.

   Following is a list of all valid commands, and all possible responses
   to each:

   ABORT

     This command is valid in the Begun, Enlisted, and Prepared states.
     It informs the secondary that the current transaction of the
     connection will abort. Possible responses are:





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


     ABORTED
       The transaction has aborted; the connection enters Idle state.

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

   BEGIN

     This command is valid only in the Idle state. It asks the secondary
     to create a new transaction and associate it with the connection.
     The newly created transaction will be completed with a one-phase
     protocol. Possible responses are:

     BEGUN <transaction identifier>
       A new transaction has been successfully begun, and that
       transaction is now the current transaction of the connection.
       The connection enters Begun state.

     NOTBEGUN
       A new transaction could not be begun; the connection remains in
       Idle state.

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

   COMMIT

     This command is valid in the Begun, Enlisted or Prepared states.
     In the Begun or Enlisted state, it asks the secondary to attempt to
     commit the transaction; in the Prepared state, it informs the
     secondary that the transaction has committed. Note that in the
     Enlisted state this command represents a one-phase protocol, and
     should only be done when the sender has 1) no local recoverable
     resources involved in the transaction, and 2) only one subordinate
     (the sender will not be involved in any transaction recovery
     process). Possible responses are:

     ABORTED
       This response is possible only from the Begun and Enlisted
       states. It indicates that some party has vetoed the commitment of
       the transaction, so it has been aborted instead of committing.
       The connection enters the Idle state.







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


     COMMITTED
       This response indicates that the transaction has been committed,
       and that the primary no longer has any responsibilities to the
       secondary with respect to the transaction. The connection enters
       the Idle state.

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

   ERROR

     This command is valid in any state; it informs the secondary that a
     previous response was not recognized or was badly formed.  A
     secondary should not respond to this command. The connection enters
     Error state.

   IDENTIFY  <lowest protocol version>
             <highest protocol version>
             <primary transaction manager address> | "-"
             <secondary transaction manager address>

     This command is valid only in the Initial state. The primary party
     informs the secondary party of: 1) the lowest and highest protocol
     version supported (all versions between the lowest and highest must
     be supported; 2) optionally, an identifier for the primary party at
     which the secondary party can re-establish a connection if ever
     needed (the primary transaction manager address); and 3) an
     identifier which may be used by intermediate proxy servers to
     connect to the required TIP transaction manager (the secondary
     transaction manager address). If a primary transaction manager
     address is not supplied, the secondary party will respond with
     ABORTED or READONLY to any PREPARE commands.  Possible responses
     are:

     IDENTIFIED <protocol version>
       The secondary party has been successfully contacted and has saved
       the primary transaction manager address. The response contains
       the highest protocol version supported by the secondary party.
       All future communication is assumed to take place using the
       smaller of the protocol versions in the IDENTIFY command and the
       IDENTIFIED response. The connection enters the Idle state.

     NEEDTLS
       The secondary party is only willing to communicate over TLS
       secured connections. The connection enters the Tls state, and all
       subsequent communication is as defined by the TLS protocol. This
       protocol will begin with the first octet after the line



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


       terminator of the IDENTIFY command (for data sent by the primary
       party), and the first byte after the line terminator of the
       NEEDTLS response (for data sent by the secondary party). This
       implies that an implementation must not send both a CR and a LF
       octet after either the IDENTIFY command or the NEEDTLS response,
       lest the LF octet be mistaken for the first byte of the TLS
       protocol. The connection provided by the TLS protocol starts out
       in the Initial state.  After TLS has been negotiated, the primary
       party must resend the IDENTIFY command. If the primary party
       cannot support (or refuses to use) the TLS protocol, it closes
       the connection.

     ERROR
       The command was issued in the wrong state, or was malformed.
       This response also occurs if the secondary party does not support
       any version of the protocol in the range supported by the primary
       party. The connection enters the Error state. The primary party
       should close the connection.

   MULTIPLEX  <protocol-identifier>

     This command is only valid in the Idle state. The command seeks
     agreement to use the connection for a multiplexing protocol that
     will supply a large number of connections on the existing
     connection. The primary suggests a particular multiplexing
     protocol. The secondary party can either accept or reject use of
     this protocol.

     At the present, the only defined protocol identifier is "TMP2.0",
     which refers to the TIP Multiplexing Protocol, version 2.0. See
     Appendix A for details of this protocol. Other protocol identifiers
     may be defined in the future.

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

     Note that when using TMP V2.0, a single TIP command (TMP
     application message) must be wholly contained within a single TMP
     packet (the TMP PUSH flag is not used by TIP). Possible responses
     to the MULTIPLEX command are:




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


     MULTIPLEXING
       The secondary party agrees to use the specified multiplexing
       protocol. The connection enters the Multiplexing state, and all
       subsequent communication is as defined by that protocol.  All
       connections created by the multiplexing protocol start out in the
       Idle state.

     CANTMULTIPLEX
       The secondary party cannot support (or refuses to use) the
       specified multiplexing protocol. The connection remains in the
       Idle state.

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

   PREPARE

     This command is valid only in the Enlisted state; it requests the
     secondary to prepare the transaction for commitment (phase one of
     two-phase commit). Possible responses are:

     PREPARED
       The subordinate has prepared the transaction; the connection
       enters PREPARED state.

     ABORTED
       The subordinate has vetoed committing the transaction. The
       connection enters the Idle state.  After this response, the
       superior has no responsibilities to the subordinate with respect
       to the transaction.