Transaction Internet Protocol Working Group J. Lyon
Internet-Draft Microsoft
Obsoletes <draft-lyon-itp-nodes-02.txt> K. Evans
Expires in 6 months J. Klein
Tandem Computers
October 20th, 1997
Transaction Internet Protocol
Version 2.0
<draft-lyon-itp-nodes-03.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six=20
months and may be updated, replaced, or obsoleted by other documents=20
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
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.
Lyon, et al [Page 1]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
Table of Contents
Status of this memo 1
Abstract 1
Table of Contents 2
1. Introduction 3
2. Example Usage 3
3. Transactions 4
4. Connections 4
5. Transaction Identifiers 5
6. Pushing vs. Pulling Transactions 5
7. Endpoint Identification 6
8. TIP Uniform Resource Locators 7
9. States of a Connection 8
10. Protocol Versioning 9
11. Commands and Responses 10
12. Command Pipelining 10
13. TIP Commands 11
14. Error Handling 16
15. Connection Failure and Recovery 16
16. Security Considerations 18
17. Significant changes from previous version 19
References 19
Authors' Addresses 19
Comments 19
App A. The TIP Multiplexing Protocol Version 2.0 21
Lyon, et al [Page 2]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
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=20
protocol a transaction manager may use the Transport Layer Security
protocol [3] to authenticate other transaction managers and encrypt=20
messages.=20
=20
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=20
do expect that it will be relatively easy for many existing=20
heterogeneous transaction managers to implement this protocol for
communication with each other.
Further supplemental information regarding the TIP protocol can be
found in [5].
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=20
encoding to context cookies to keep track of client context (e.g.
the shopping basket of a customer) and resume it on subsequent=20
customer requests.=20
Once a customer has finished shopping they may decide to commit=20
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
Lyon, et al [Page 3]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
=20
(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.=20
Today's electronic store-fronts must implement their own special=20
protocols to coordinate such placement of all orders. This=20
programming is especially complex when orders are placed through=20
multiple electronic store-fronts. This complexity limits the=20
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=20
(e.g. placement of orders in an electronic shopping basket).=20
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.=20
The server placing the orders passes a reference to the transaction=20
as user data on HTTP requests to the other servers. The other=20
servers call their transaction managers to start a local transaction
and ask them to join the remote transaction using the protocol =20
defined in this document. Once all orders have been placed, execution
of the two-phase-commit protocol is delegated=20
to the involved transaction managers. If the transaction commits,=20
all orders have been successfully placed and the customer gets a=20
positive acknowledgment. If the transaction aborts no orders will=20
be placed and the customer will be informed of the problem.=20
Transaction support greatly simplifies programming of these=20
applications as exception handling and failure recovery are delegated
to a special component. End users are also not left having to deal=20
with the consequences of only partial success.
While this example shows how the protocol can be used by HTTP=20
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. 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=20
all work completes successfully and changes are made permanent (the=20
transaction commits), or if any work is unsuccessful, changes are=20
undone (the transaction aborts). The work comprising a transaction=20
(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 a protocol to=20
multiplex light-weight connections over the same TCP connection.=20
=20
Lyon, et al [Page 4]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
Transaction managers which share transactions establish a TCP=20
connection. The protocol uses a different connection for each=20
simultaneous transaction shared between two transaction managers.
After a transaction has ended, the connection can be reused for=20
a different transaction.
=20
Optionally, instead of associating a TCP connection with only a=20
single transaction, two transaction managers may agree on a protocol
to multiplex light-weight connections over the same TCP 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=20
transactions. Similar techniques as described here are widely used=20
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, 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.=20
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=20
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.
Lyon, et al [Page 5]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
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.
7. Endpoint Identification
In certain cases after connection failures, one of the parties of
a connection may have a responsibility to re-establish a new=20
connection to the other party in order to complete the=20
two-phase-commit protocol. If the party that initiated the original=20
connection needs to re-establish it, the job is easy: he merely=20
establishes a connection in the same way that he originally did it.=20
However, if the other party needs to re-establish the connection,=20
he needs to know how to contact the initiator of the original=20
connection. He gets this information in the following way:
After a TCP connection has been established the initiating party
issues an IDENTIFY command and supplies an endpoint identifier which
is used to re-establish the connection if needed. If the initiating=20
party does not supply an endpoint identifier on the IDENTIFY command,
he must not perform any action which would require a connection to be
re-established (e.g. perform recovery actions).
An <endpoint identifier> as used in the IDENTIFY (and a few other)
commands has one of the following formats:
<dns name>
<ip address>
<dns name>:<port number>
<ip address>:<port number>
A <dns name> is a standard name, acceptable to the domain name
service. It must be sufficiently qualified to be useful to the
receiver of the command.
An <ip address> is an IP address, in the usual form: four decimal
numbers separated by period characters.
The <port number> is a decimal number specifying the port at which
the transaction manager is listening for requests to establish TCP
connections. Two standard transaction service port numbers are
defined: 3372 for TLS secured connections, and 3371 for unsecured
connections. If the port number is omitted from the endpoint=20
identifier, and if the current connection is TLS secured, then the
standard TLS secured transaction service port number is assumed;
otherwise the standard unsecured transaction service port number is
assumed. Likewise, if a port number is specified, then it must
represent a port with the same security capabilities as the current
connection (i.e. TLS or unsecured).
Lyon, et al [Page 6]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
8. TIP Uniform Resource Locators
Transactions and transaction managers are resources associated=20
with the TIP protocol. Transaction managers and transactions are=20
located using TCP/IP endpoint identifiers. Once a TCP connection has=20
been established, TIP commands may be sent to operate on transactions
associated with the respective transaction managers.=20
Applications which want to pull a transaction from a remote node
must supply a reference to the remote transaction which allows
the local transaction manager (i.e. the transaction manager pulling
the transaction) to connect to the remote transaction
manager and identify the particular transaction. Applications
which want to push a transaction to a remote node must supply=20
a reference to the remote transaction manager (i.e. the transaction
manager to which the transaction is to be pushed), which allows the=20
local transaction manager to locate the remote transaction=20
manager.=20
The TIP protocol defines a URL scheme [4] which allows applications=20
and transaction managers to exchange references (i.e. TIP URLs) to=20
transaction managers and transactions.
A TIP URL takes the form:
TIP://<host>[:<port>]/<transaction string>
=20
where <host> is an IP address or a DNS name as defined above; and
<port> is a valid TCP port number. <transaction string> may take one
of two forms (standard or non-standard):
i. "urn:" <NID> ":" <NSS>
A standard transaction identifier, conforming to the proposed
Internet Standard for Uniform Resource Names (URNs), as
specified by RFC2141; where <NID> is the Namespace Identifier,
and <NSS> is the Namespace Specific String. The Namespace ID
determines the syntactic interpretation of the Namespace
Specific String. The Namespace Specific String is a sequence of
characters representing a transaction identifier (as defined by
<NID>). The rules for the contents of these fields are
specified by [7] (valid characters, encoding, etc.).
This format of <transaction string> may be used to express
global transaction identifiers in terms of standard
representations. Examples for <NID> might be <iso> or <xopen>.
e.g.
TIP://123.123.123.123/urn:xopen:xid
=20
ii. <transaction identifier>
=20
A sequence of printable ASCII characters (octets with values in
the range 32 through 126 inclusive (excluding ":"))
Lyon, et al [Page 7]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
representing a transaction identifier. In this non-standard
case, it is the combination of <host> and
<transaction identifier> which ensures global uniqueness. e.g.
TIP://123.123.123.123/transid1 =20
Except as otherwise described above, the TIP URL scheme follows the
rules for reserved characters as defined in [4], and uses escape=20
sequences as defined in [4] Section 5.=20
Note that the TIP protocol itself does not use the TIP URL scheme.
This URL scheme is proposed as a standard way to pass transaction
identification information through other protocols. e.g. between
cooperating application processes. The URL may then be used to
communicate to the local transaction manager the information
necessary to associate the application with a particular TIP
transaction. e.g. to PULL the transaction from a remote transaction
manager. It is anticipated that each TIP implementation will provide
some set of APIs for this purpose.
To create a non-standard TIP URL from a transaction identifier, first
replace any reserved characters in the transaction identifier with
their equivalent escape sequences, then insert the appropriate host
endpoint identification. If the transaction identifier is one that
you created, insert your own endpoint identification. If the
transaction identifier is one that you received on a TIP connection
that you initiated, insert the identification of the party to which
you connected. If the transaction identifier is one that you received
on a TIP connection that you did not initiate, use the identification
that was received in the IDENTIFY command.
9. States of a Connection
At any instant, only one party on a connection is allowed to send=20
commands, while the other party is only allowed to respond to=20
commands that he receives. Throughout this document, the party that
is allowed to send commands is called "primary"; the other party is
called "secondary". Initially, the party that initiated the=20
connection is primary; however, a few commands cause the
roles to switch. A connection returns to it's original polarity
whenever the Idle state is reached.
When multiplexing is being used, these rules apply independently to=20
each "virtual" connection, regardless of the polarity of the
underlying connection (which will be in the Multiplexing state).
Note that commands may be sent "out of band" by the secondary via the
use of pipelining. This does not affect the polarity of the
connection (i.e. the roles of primary and secondary do not switch).=20
See section 12 for details.
At any instant, a connection is in one of the following states.
From the point of view of the secondary party, the state changes when
he sends a reply; from the point of view of the primary party, the
Lyon, et al [Page 8]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
state changes when he receives a reply.
Initial: The initial connection starts out in the Initial state.=20
Upon entry into this state, the party that initiated the=20
connection becomes primary, and the other party becomes secondary.
There is no transaction associated with the connection in this=20
state. From this state, the primary can send the IDENTIFY command.
Idle: In this state, the primary and the secondary have=20
agreed on a protocol version, and the primary supplied an=20
endpoint identifier to the secondary party to reconnect after=20
a failure. There is no transaction associated with the=20
connection in this state. Upon entry to this state, the party
that initiated the connection becomes primary, and the other
party becomes secondary. From this state, the primary can send=20
any of the following commands: BEGIN, MULTIPLEX, PUSH, PULL,
QUERY and RECONNECT.=20
Begun: In this state, a connection is associated with an active
transaction, which can only be completed by a one-phase protocol.
A BEGUN response to a BEGIN command places a connection into=20
this state. Failure of a connection in Begun state implies=20
that the transaction will be aborted. From this state, the=20
primary can send an ABORT, or COMMIT command.
Enlisted: In this state, the connection is associated with an active
transaction, which can be completed by a one-phase or, two-phase=20
protocol. A PUSHED response to a PUSH command, or a PULLED=20
response to a PULL command, places the connection into this state.
Failure of the connection in Enlisted state implies that the=20
transaction will be aborted. From this state, the primary can=20
send an ABORT, COMMIT, or PREPARE command.
Prepared: In this state, a connection is associated with a=20
transaction that has been prepared. A PREPARED response to a=20
PREPARE command, or a RECONNECTED response to a RECONNECT=20
command places a connection into this state. Unlike other=20
states, failure of a connection in this state does not cause=20
the transaction to automatically abort. From this state, the
primary can send an ABORT, or COMMIT command.
Multiplexing: In this state, the connection is being used by a
multiplexing protocol, which provides its own set of connections.
In this state, no TIP commands are possible on the connection.
(Of course, TIP commands are possible on the connections
supplied by the multiplexing protocol.) The connection can
never leave this state.
Error: In this state, a protocol error has occurred, and the
connection is no longer useful.=20
10. Protocol Versioning
This document describes version 2 of the protocol. In order to
Lyon, et al [Page 9]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
accommodate future versions, the primary party sends a message
indicating the lowest and the highest version number it understands.=20
The secondary responds with the highest version number it=20
understands.=20
=20
After such an exchange, communication can occur using the smaller of
the highest version numbers (i.e., the highest version number that=20
both understand). This exchange is mandatory and occurs using the
IDENTIFY command (and IDENTIFIED response).=20
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=20
type of command or response; all defined commands and responses=20
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=20
first undefined word are totally ignored. These can be used to pass
human-readable information for debugging or other purposes.
12. Command Pipelining
In order to reduce communication latency and improve efficiency, it=20
is possible for multiple TIP "lines" (commands or responses) to be=20
pipelined (concatenated) together and sent as a single message. Lines =
may also be sent "ahead" (by the secondary, for later procesing by=20
the primary). Examples are an ABORT command immediately followed by a =
BEGIN command, or a COMMITTED response immediately followed by a PULL =
command.
=20
Lyon, et al [Page 10]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
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=20
reaches such a state. If a line is received on a connection when it's =
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 and MULTIPLEX. Commands
which pertain to transactions are: ABORT, BEGIN, COMMIT, PREPARE,=20
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:
ABORTED=20
The transaction has aborted; the connection enters Idle=20
state.
ERROR=20
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=20
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
Lyon, et al [Page 11]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
transaction is now the current transaction of the connection.
The connection enters Begun state.
NOTBEGUN=20
A new transaction could not be begun; the connection=20
remains in Idle state.
ERROR=20
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.=20
In the Begun or Enlisted state, it asks the secondary to attempt=20
to commit the transaction; in the Prepared state, it informs the=20
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=20
process). Possible responses are:
ABORTED=20
This response is possible only from the Begun and Enlisted=20
states. It indicates that some party has vetoed the commitment
of the transaction, so it has been aborted instead of=20
committing. The connection enters the Idle state.
COMMITTED=20
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=20
The command was issued in the wrong state, or was malformed.
The connection enters the Error state.
ERROR=20
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>
<initiating party's endpoint identifier> | "-"
This command is valid only in the Initial state. The primary party
informs the secondary party of the lowest and highest protocol=20
version supported (all versions between the lowest and highest
must be supported), and optionally of an IP address and a port=20
=20
Lyon, et al [Page 12]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
number at which the other party can re-establish a connection=20
if ever needed. If the primary party does not supply an endpoint=20
identifier the secondary party will respond with ABORTED or=20
READONLY to any PREPARE commands. Possible responses are:
IDENTIFIED <protocol version>
The accepting party has saved the identification. The response
contains the highest protocol version supported by the
secondary party. All future communication is assumed to take=20
place using the smaller of the protocol versions in the=20
IDENTIFY command and the IDENTIFIED response. The connection
enters the Idle state.=20
ERROR=20
The command was issued in the wrong state, or was malformed.
This response also occurs if the accepting party does not
support any version of the protocol in the range supported
by the initiator. The connection enters the Error state. The
initiator should close the connection.
MULTIPLEX <protocol-identifier>
This command is only valid in the Idle state. The command=20
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=20
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 byte 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:
MULTIPLEXING
The secondary party agrees to use the specified multiplexing
protocol. The connection enters the Multiplexing state, and
=20
Lyon, et al [Page 13]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
all subsequent communication is as defined by that protocol.
All connections created by the multiplexing protocol start
out in the Idle state.=20
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=20
This command is valid only in the Enlisted state; it requests=20
the secondary to prepare the transaction for commitment (phase
one of two-phase commit). Possible responses are:
PREPARED=20
The subordinate has prepared the transaction; the connection
enters PREPARED state.
ABORTED=20
The subordinate has vetoed committing the transaction. The
connection enters the Idle state. After this response, the=20
superior has no responsibilities to the subordinate with=20
respect to the transaction.
READONLY=20
The subordinate no longer cares whether the transaction
commits or aborts. The connection enters the Idle state. After
this response, the superior has no responsibilities to the=20
subordinate with respect to the transaction.
ERROR=20
The command was issued in the wrong state, or was malformed.
The connection enters the Error state.
PULL <superior's transaction identifier>
<subordinate's transaction identifier>
This command is only valid in Idle state. This command seeks to=20
establish a superior/subordinate relationship in a transaction,=20
with the primary party of the connection as the subordinate (i.e., =
he is pulling a transaction from the secondary party). Note that
the entire value of <transaction string> (as defined in the=20
section "TIP Uniform Resource Locators") must be specified as the
transaction identifier. Possible responses are:
PULLED=20
The relationship has been established. Upon receipt of this
response, the specified transaction becomes the current
transaction of the connection, and the connection enters=20
=20
Lyon, et al [Page 14]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
Enlisted state. Additionally, the roles of primary and=20
secondary become reversed. (That is, the superior becomes=20
the primary for the connection.)
NOTPULLED=20
The relationship has not been established (possibly, because
the secondary party no longer has the requested transaction).
The connection remains in Idle state.
ERROR=20
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=20
establish a superior/subordinate relationship in a transaction=20
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=20
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=20
The relationship could not be established. The connection
remains in the Idle state.
ERROR=20
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=20
exists at the superior. Possible responses are:
QUERIEDEXISTS=20
The transaction still exists. The connection remains in the=20
Idle state.
=20
Lyon, et al [Page 15]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
QUERIEDNOTFOUND=20
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=20
command to re-establish a connection for a transaction, when the=20
previous connection was lost during Prepared state. Possible=20
responses are:
RECONNECTED=20
The subordinate accepts the reconnection. The connection enters
Prepared state.
NOTRECONNECTED=20
The subordinate no longer knows about the transaction. The=20
connection remains in Idle state.
ERROR=20
The command was issued in the wrong state, or was malformed.
The connection enters 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),=20
receives an ERROR indication or an ERROR response on a connection=20
the connection enters the Error state and no further communication=20
is possible on that connection. An implementation may decide to=20
close the connection. Closing of the connection is treated by the=20
other party as a communication failure.=20
Receipt of an ERROR indication or an ERROR response indicates that=20
the other party believes that you have not properly implemented the=20
protocol.=20
=20
15. Connection Failure and Recovery
A connection failure may be caused by a communication failure, or by
any party closing the connection. Depending on the state of a=20
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.
Lyon, et al [Page 16]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
If the connection fails in Begun or Enlisted state and COMMIT has=20
been sent, then transaction completion has been delegated to the=20
subordinate (the superior is not involved); the outcome of the=20
transaction is unknown by the superior (it is known at the=20
subordinate). The superior uses application-specific means to=20
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=20
RECONNECT command for the transaction. If it receives a RECONNECTED=20
response, it should send an ABORT command.
The above definition allows the superior to reestablish the=20
connection before it knows the outcome of the transaction, if it=20
finds that convenient. Having succeeded in a RECONNECT command,=20
the connection is back in Prepared state, and the superior can send a =
COMMIT or ABORT command as appropriate when it knows the transaction=20
outcome.
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.=20
the necessary recovery information is not currently available), then
the connection should be dropped.
Lyon et al [Page 17]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
16. Security Considerations
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.
=20
If a system does not protect itself through usage of another protocol
such as the Transport Layer Security protocol, then security
implications fall into the following categories:
1. Someone PUSHED a new transaction to us that we don't want.
Depending on his correctness or intentions, he may or may not ever
complete it. Thus, an arbitrary computer may cause us to save a
little bit of state. An implementation concerned about this will
probably drop the TCP connection if the other system does not=20
complete transactions in a timely manner.=20
=20
The Transport Layer Security protocol [3] may be used by a
transaction manager to restrict access to trusted clients only.=20
2. Someone PULLED a transaction from us when we didn't want him to.
In this case, he will become involved in the atomic commitment
protocol. At worst, he may cause a transaction to abort that
otherwise would have committed. Since transaction managers
traditionally reserve the right to abort any transaction for any
reason they see fit, this does not represent a disaster to the
applications. However, if done frequently, it may represent a
denial-of-service attack.=20
Implementations concerned about this kind of attack can use the=20
Transport Layer Security protocol [3] to restrict access to
trusted partners (i.e. to control from which remote endpoints
TIP transactions will be accepted, and to verify that an end-point
is genuine), and encrypt TIP commands thus preventing unauthorized
disclosure of transaction identifiers.
3. Someone violates the TIP commitment protocol. (e.g. a COMMIT
command is injected on a TIP connection in place of an ABORT
command). This yields the possibility of data inconsistency.
Implementations concerned about this kind of attack can also use
the Transport Layer Security protocol [3] to restrict access to
only trusted partners and to encrypt TIP commands.
It is assumed that implementation-specific configuration information
will define whether a partner should be connected to using either a
mandatory TLS secured connection, or an unsecured connection (in=20
which case any security risk is accepted). "Optionally TLS secured"=20
is in effect unsecured (since there is no guarantee of a TLS secured
connection).
Lyon, et al [Page 18]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
17. Significant changes from previous version of this Internet-Draft
(<draft-lyon-itp-nodes-02.txt>):
None (minor editorial changes to aid understanding and fix errors).
References
[1] Gray, J. and A. Reuter (1993), Transaction Processing: Concepts
and Techniques. San Francisco, CA: Morgan Kaufmann Publishers.
(ISBN 1-55860-190-2).
[2] RFC2068 Standards Track "Hypertext Transfer Protocol --
HTTP/1.1".
R. Fielding et al.
[3] Internet-Draft "The TLS Protocol Version 1.0".
T. Dierks et al.
[4] RFC1738 Standards Track "Uniform Resource Locators (URL)".
T. Berners-Lee et al.
[5] Internet-Draft "Transaction Internet Protocol - Requirements and
Supplemental Information".
K. Evans et al.
[6] Internet-Draft "Session Control Protocol V 2.0".
K. Evans et al.
[7] RFC2141 "URN Syntax".
R. Moats.
Authors' Addresses
Jim Lyon Keith Evans
Microsoft Corporation Tandem Computers, Inc.
One Microsoft Way 5425 Stevens Creek Blvd
Redmond, WA 98052-6399, USA Santa Clara, CA 95051-7200, USA
Phone: +1 (206) 936 0867 Phone: +1 (408) 285 5314
Fax: +1 (206) 936 7329 Fax: +1 (408) 285 5245
Email: JimLyon@Microsoft.Com Email: Keith@Loc252.Tandem.Com
Johannes Klein
Tandem Computers Inc.
10555 Ridgeview Court
Cupertino, CA 95014-0789, USA
Phone: +1 (408) 285 0453
Fax: +1 (408) 285 9818
Email: Klein_Johannes@Tandem.Com
Comments
Please send comments on this document to the authors at=20
=20
Lyon, et al [Page 19]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
<JimLyon@Microsoft.Com>, <Keith@Loc252.Tandem.Com>,
<Klein_Johannes@Tandem.Com>, or to the TIP mailing list at
<Tip@Tandem.Com>. You can subscribe to the TIP mailing list by
sending mail to <Listserv@Tandem.Com> with the line "subscribe tip"=20
somewhere in the body of the message.
Lyon, et al [Page 20]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
Appendix A. The TIP Multiplexing Protocol Version 2.0.
This appendix describes version 2.0 of the TIP Multiplexing Protocol
(TMP). TMP V2.0 is the same as the Session Control Protocol (SCP)
version 2.0, as described by [6]. TMP is intended solely for use
with the TIP protocol, and forms part of the TIP protocol
specification (although its implementation is optional), hence its
inclusion in this document. TMP V2.0 is the only multiplexing=20
protocol supported by TIP V2.0. The following text is a copy of [6]
with no substantive changes, it is edited only as necessary to
reflect the name change and for inclusion in this document.=20
Abstract=20
TMP provides a simple mechanism for creating multiple lightweight=20
connections over a single TCP connection. Several such lightweight
connections can be active simultaneously. TMP provides a byte=20
oriented service, but allows message boundaries to be marked.=20
A.1. Introduction=20
There are several protocols in widespread use on the Internet which
create a single TCP connection for each transaction. Unfortunately,
because these transactions are short lived, the cost of setting up
and tearing down these TCP connections becomes significant, both in
terms of resources used and in the delays associated with TCP's
congestion control mechanisms.=20
The TIP Multiplexing Protocol (TMP) is a simple protocol running on
top of TCP that can be used to create multiple lightweight=20
connections over a single transport connection. TMP therefore
provides for more efficient use of TCP connections. Data from
several different TMP connections can be interleaved, and both
message boundaries and end of stream markers can be provided.=20
=20
Because TMP runs on top of a reliable byte ordered transport
service it can avoid most of the extra work TCP must go through in
order to ensure reliability. For example, TMP connections do not
need to be confirmed, so there is no need to wait for handshaking
to complete before data can be sent.
A.2. Protocol Model=20
The basic protocol model is that of multiple lightweight
connections operating over a reliable stream of bytes. The party
which initiated the connection is referred to as the primary, and
the party which accepted the connection is referred to as the
secondary.
=20
Connections may be unidirectional or bi-directional; each end of a
bi-directional connection may be closed separately. Connections may
be closed normally, or reset to indicate an abortive release.
Aborting a connection closes both data streams.=20
=20
Lyon, et al [Page 21]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
Once a connection has been opened, applications can send messages
over it, and signal the end of application level messages.
Application messages are encapsulated in TMP packets and
transferred over the byte stream. A single TIP command (TMP
application message) must be wholly contained within a single TMP
packet.
A.3. TMP Packet Format=20
A TMP packet consists of a 64 bit header followed by zero or more
octets of data. The header contains three fields; a flag byte, the
connection identifier, and the packet length. Both integers, the
connection identifier and the packet length must be sent in network
byte order.=20
FLAGS
+--------+--------+--------+--------+
|SFPR0000| Connection ID |
+--------+--------+--------+--------+
| | Length |
+--------+--------+--------+--------+=20
A.3.1. Flag Details
+-------+-----------+-----------------------------------------+
| Name | Mask | Description |
+-------+-----------+ ----------------------------------------+=20
| SYN | 1xxx|0000 | Open a new connection |
| FIN | x1xx|0000 | Close an existing connection |
| PUSH | xx1x|0000 | Mark application level message boundary |
| RESET | xxx1|0000 | Abort the connection |=20
+-------+-----------+-----------------------------------------+
A.4. Connection Identifiers=20
=20
Each TMP connection is identified by a 24 bit integer. TMP
connections created by the party which initiated the underlying TCP=20
connection must have even identifiers; those created by the other
party must have odd identifiers.=20
A.5. TMP Connection States=20
TMP connections can exist in several different states; Closed,
OpenWrite, OpenSynRead, OpenSynReset, OpenReadWrite, CloseWrite,
and CloseRead. A connection can change its state in response to
receiving a packet with the SYN, FIN, or RESET bits set, or in
response to an API call by the application. The available API calls
are open, close, and abort.=20
The meaning of most states is obvious (e.g. OpenWrite means that a
connection has been opened for writing). The meaning of the states
OpenSynRead and OpenResetRead need more explanation.
In the OpenSynRead state a primary opened and immediately closed the
=20
Lyon, et al [Page 22]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
output data stream of a connection, and is now waiting for a SYN
response from the secondary to open the input data stream for=20
reading.=20
In the OpenResetRead state a primary opened and immediately aborted
a connection, and is now waiting for a SYN response from the=20
secondary to finally close the connection.
A.6. Event Priorities and State Transitions=20
The state table shown below describes the actions and state
transitions that occur in response to a given event. The events
accepted by each state are listed in priority order with highest
priority first. If multiple events are present in a message, those
events matching the list are processed. If multiple events match,
the event with the highest priority is accepted and processed
first. Any remaining events are processed in the resultant
successor state.=20
For example, if a TMP connection at the secondary is in the Closed
state, and the secondary receives a packet containing a SYN event, a
FIN event and an input data event (i.e. DATA-IN), the secondary first
accepts the SYN event (because it is the only match in Closed
state). The secondary accepts the connection, sends a SYN event and
enters the ReadWrite state. The SYN event is removed from the list
of pending events. The remaining events are FIN and DATA-IN. In the
ReadWrite state the secondary reads the input data (i.e. the DATA-IN
event is processed first because it has higher priority than the
FIN event). Once the data has been read and the DATA-IN event has
been removed from the list of pending events, the FIN event is
processed and the secondary enters the CloseWrite state.
If either party receives a TMP packet that it does not understand,
or an event in an incorrect state, it closes the TCP connection.
Lyon, et al [Page 23]
=0C
INTERNET-DRAFT TIP Version 2.0 Oct 1997
=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| Entry State | Event | Action | Exit State |
=
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| Closed | SYN | SYN | ReadWrite |
| | OPEN | SYN | OpenWrite |
+--------------+---------+----------+--------------+
| OpenWrite | SYN | Accept | ReadWrite |
| | WRITE | DATA-OUT | OpenWrite |
| | CLOSE | FIN | OpenSynRead |
| | ABORT | RESET | OpenSynReset |
+--------------+---------+----------+--------------+
| OpenSynRead | SYN | Accept | CloseRead |
+--------------+---------+----------+--------------+
| OpenSynReset | SYN | Accept | Closed |
+--------------+---------+----------+--------------+
| ReadWrite | DATA-IN | Accept | ReadWrite |
| | FIN | Accept | CloseWrite |
| | RESET | Accept | Closed |
| | WRITE | DATA-OUT | ReadWrite |
| | CLOSE | FIN | CloseRead |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
| CloseWrite | RESET | Accept | Closed |
| | WRITE | DATA-OUT | CloseWrite |
| | CLOSE | FIN | Closed |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
| CloseRead | DATA-IN | Accept | CloseRead |
| | FIN | Accept | Closed |
| | RESET | Accept | Closed |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
TMP Event Priorities and State Transitions=20
Lyon, et al [Page 24]