Transaction Internet Protocol Version 3.0
Extracted elements (28)
TIP achieves simplicity by specifying only how different nodes agree on the outcome of a transaction, deliberately leaving the subject matter of the transaction to be communicated via other protocols. This avoids all issues related to application communication semantics and data representation.
TIP supports both 'push' and 'pull' transaction models. In push, the superior's TM exports the transaction to the subordinate before the application sends work. In pull, the application passes a transaction reference and the subordinate's TM pulls it on demand. Both models result in the superior knowing to involve the subordinate in two-phase commit.
TMP is intentionally not a general-purpose multiplexing protocol. It is designed solely for TIP's short request-response messages; protocols with large messages can exceed receiver buffering and cause deadlock under TMP, which TIP avoids because all TIP messages are short.
A subordinate that notices a connection failure in Prepared state SHOULD periodically create a new connection to the superior and send QUERY until it receives QUERIEDNOTFOUND (abort) or the superior sends RECONNECT on a new connection.
All implementations MUST support receipt of pipelined lines. A line received when it is not the other party's turn is held and processed when the connection state requires it; responses must be issued in the order lines were received. An error on any line causes the connection to enter Error state and all subsequent lines are discarded.
If the connection fails in Begun or Enlisted state and COMMIT has not been sent, the transaction will be aborted. If COMMIT was sent, the outcome is unknown to the superior and must be determined by application-specific means.
TIP operates over TCP, optionally using TLS to provide a secured and authenticated connection, and optionally using a multiplexing protocol over the same TCP or TLS connection.
TIP URLs must be guaranteed globally unique for all time to prevent possible non-deterministic behavior from duplicate identifiers. How uniqueness is achieved is implementation-specific.
A TIP transaction manager address takes the form <hostport><path>, where <hostport> is <host>[:<port>] and <path> is a URI-style path identifying the specific transaction manager at that host. The <hostport> is used for TCP connection endpoint; the <path> routes to the specific TM.
A TIP URL takes the form tip://<transaction manager address>?<transaction string>, where the transaction string is either a URN ("urn:<NID>:<NSS>") for standard global identifiers, or a printable ASCII sequence for non-standard identifiers whose uniqueness is guaranteed by combining it with the transaction manager address.
Protocol version negotiation is mandatory and occurs via the IDENTIFY command: the primary sends the lowest and highest version numbers it supports; the secondary responds with the highest version it supports. Communication uses the lower of the two highest versions. If no common version exists the newer party drops the connection.
The IDENTIFY command (valid only in Initial state) carries the lowest and highest supported protocol versions, the primary transaction manager address (or "-" if not supplied), and the secondary transaction manager address. If no primary address is supplied, the secondary will respond with ABORTED or READONLY to any subsequent PREPARE commands.
The PREPARE command (valid only in Enlisted state) requests the secondary to prepare the transaction for commitment (phase one of two-phase commit). Responses are PREPARED (enters Prepared state), ABORTED (subordinate vetoes; enters Idle), or READONLY (subordinate no longer cares; enters Idle).
The PULL command (valid in Idle state) has two parameters: the superior's transaction identifier and the subordinate's transaction identifier. On a PULLED response, roles reverse so the superior becomes primary, and the connection enters Enlisted state.
The PUSH command (valid in Idle state) carries the superior's transaction identifier. A PUSHED response returns the subordinate's identifier and enters Enlisted state; ALREADYPUSHED returns the subordinate's identifier but keeps the connection in Idle state, indicating the two-phase commit will arrive on a different connection.
The QUERY command (valid in Idle state) lets a subordinate ask whether a specific transaction still exists at the superior. Responses are QUERIEDEXISTS or QUERIEDNOTFOUND; receipt of QUERIEDNOTFOUND means the subordinate should abort the transaction.
The RECONNECT command (valid in Idle state) allows a superior to re-establish a connection for a transaction that was in Prepared state when the previous connection failed. A RECONNECTED response puts the connection back into Prepared state.
The standard TIP port number is 3372. If the port number is omitted from a TIP transaction manager address, this default port is used.
TMP connection identifiers are 24-bit integers. Connections created by the party that initiated the underlying TCP connection must have even identifiers; connections created by the accepting party must have odd identifiers.
Any security mechanisms applied to the application communication protocol are liable to be subverted unless corresponding mechanisms are applied to the TIP commitment protocol at the same level. A TIP implementation may refuse to provide service unless TLS is used with packet encryption and mutual authentication.
Man-in-the-middle attack: an interceptor can alter TIP traffic, e.g. replacing COMMIT with ABORT. Mitigation: always use TLS for session encryption and authentication of the remote party.
PULL-based denial-of-service: a malicious user who knows an active transaction's identity can open a TIP connection, send PULL, then close the connection, causing the transaction to abort. Mitigation: refuse PULL commands unless TLS is in use with the remote party authenticated and trusted.
PUSH-based denial-of-service: an attacker can repeatedly push transactions to Prepared state and drop connections, exhausting transaction manager resources. Mitigation: refuse PUSH commands unless TLS is in use with the remote party authenticated and trusted.
Transaction corruption attack: an attacker can send RECONNECT followed by COMMIT or ABORT to a subordinate awaiting recovery, forcing an incorrect outcome. Mitigation: record the authenticated identity of the superior and refuse RECONNECT unless TLS is in use and the remote party's authenticated identity matches.
A TIP connection passes through states: Initial (before IDENTIFY), Idle (version negotiated, no transaction), Begun (one-phase transaction active), Enlisted (two-phase-capable transaction active), Prepared (phase-one complete), Multiplexing (TMP in control), Tls (TLS in control), and Error (unrecoverable). Connection failure in Prepared state does not automatically abort the transaction; all other active transaction states do.
TMP connection states are: Closed, OpenWrite, OpenSynRead, OpenSynReset, ReadWrite, CloseWrite, and CloseRead. State transitions are driven by SYN, FIN, RESET, DATA-IN events and API calls (open, close, abort). Receipt of a TMP packet in an incorrect state causes the underlying TCP connection to be closed.
A TMP packet consists of a 64-bit header followed by zero or more data octets. The header contains a flag byte (SYN, FIN, PUSH, RESET flags in the high nibble), a 24-bit connection identifier, and a 32-bit packet length; both the connection identifier and length are in network byte order.
All TIP commands and responses are lines of ASCII text using only octets 32–126 inclusive, terminated by CR (0x0D) or LF (0x0A). Words within a line are separated by one or more space octets. The first word identifies the command or response type in upper-case letters only.