Network Working Group J. Lyon
Request for Comments: 2371 Microsoft
Category: Standards Track K. Evans
J. Klein
Tandem Computers
July 1998
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
交易互联网协议版本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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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
1. 导言2。示例用法3。交易4 4。连接4 5。事务标识符5 6。推送与拉送事务5 7。TIP事务管理器标识和连接建立6 8。提示统一资源定位器8 9。连接的状态10。协议版本12 11。命令和响应12。命令管道13。提示命令13 14。错误处理20
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
15. 连接故障和恢复20 16。安全考虑22 17。参考文献25 18。作者地址26 19。注释26附录A.TIP多路复用协议版本2.0。27完全版权声明31
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.
实现原子承诺的标准方法是两阶段提交协议；有关原子提交和两阶段提交协议的介绍，请参见[1]。
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.
本备忘录提出了一个非常简单的两阶段提交协议。它通过只指定不同节点对事务结果的一致性来实现其简单性；它允许（甚至要求）节点同意的主题通过其他协议进行通信。通过这样做，我们避免了与应用程序通信语义和数据表示相关的所有问题（仅举几个例子）。独立于应用程序通信协议，事务管理器可以使用传输层安全协议[3]来验证其他事务管理器并加密消息。
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.
可以预见，该协议将主要用于一个Internet节点上的事务管理器与另一个节点上的事务管理器通信。虽然应用程序和/或资源管理器可以使用此协议与事务管理器进行通信，但这种通信通常是在节点内进行的，并且大多数事务管理器已经为任务提供了足够的接口。
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].
有关TIP协议的更多补充信息，请参见[5]。
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.
如今，电子购物篮是许多电子商店的常用比喻。客户浏览电子目录，选择商品并将其放入电子购物篮中。HTTP服务器[2]提供从URL编码到上下文cookies的各种方法，以跟踪客户端上下文（例如客户的购物篮），并在后续客户请求时恢复。
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.
一旦客户完成购物，他们可能会决定提交他们的选择并下相关订单。除了作为同一购物交易的一部分执行外，大多数订单之间可能没有任何关系；其他人可能相互依赖（例如，如果作为特别发行的一部分进行）。无论这些细节如何，客户都希望在收到肯定的确认后，所有订单都已成功下达。今天的电子商店必须实施自己的特殊协议来协调所有订单的放置。当订单通过多个电子店面下单时，此编程尤其复杂。这种复杂性限制了互联网应用的潜在效用，并限制了增长。本文件中描述的协议旨在为互联网服务器提供一个标准，以便就共享工作单元达成协议（例如，在电子购物篮中下单）。下订单的服务器（例如CGI程序）可能希望启动一个调用其本地事务管理器的事务，并要求参与该工作的其他服务器加入该事务。下订单的服务器将对事务的引用作为HTTP请求上的用户数据传递给其他服务器。其他服务器调用其事务管理器来启动本地事务，并要求它们使用本文档中定义的协议加入远程事务。一旦下了所有订单，两阶段提交协议的执行将委托给相关的事务管理器。如果事务提交，则所有订单都已成功下单，客户得到肯定的确认。如果交易中止，则不会下订单，并将问题通知客户。
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.
事务支持大大简化了这些应用程序的编程，因为异常处理和故障恢复被委托给一个特殊的组件。最终用户也不必只处理部分成功的后果。虽然此示例显示HTTP服务器如何使用该协议，但应用程序在访问远程数据库（例如通过ODBC）或使用其他现有协议（例如通过ODBC）调用远程服务时可能会使用该协议。
RPC). The protocol makes it easy for applications in a heterogeneous network to participate in the same transaction, even if using different communication protocols.
RPC）。该协议使得异构网络中的应用程序可以轻松地参与同一事务，即使使用不同的通信协议。
"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.
“事务”是指编程模型中的术语，根据该术语，执行的计算工作具有原子语义。也就是说，要么所有工作成功完成，更改永久化（事务提交），要么如果任何工作不成功，更改撤消（事务中止）。包含事务（工作单元）的工作由应用程序定义。
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.
交易互联网协议（TIP）需要可靠的有序流传输，且连接设置成本较低。在Internet（IP）环境中，TIP通过TCP进行操作，可以选择使用TLS提供安全和经过身份验证的连接，也可以选择使用协议在同一TCP或TLS连接上多路传输轻型连接。
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.
共享事务的事务管理器建立TCP（以及可选的TLS）连接。该协议为两个事务管理器之间共享的每个并发事务使用不同的连接。事务结束后，可以将连接重新用于其他事务。
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.
可选地，两个事务管理器可以在协议上达成一致，通过相同的TCP或TLS连接多路复用轻量级连接，并将每个并发事务与单独的轻量级连接相关联，而不是仅将TCP或TLS连接与单个事务相关联。使用轻量级连接可以减少与同时执行事务相关的延迟和资源消耗。这里描述的类似技术被现有事务处理系统广泛使用。有关此类协议的示例，请参见附录A。
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.
请注意，尽管TIP协议本身仅根据TCP和TLS进行描述，但没有任何东西可以阻止TIP与其他传输协议一起使用。然而，由实现者来确保所选择的传输提供与TCP等价的语义，并适当地映射TIP协议。
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.
在本文档中，术语“连接”或“TCP连接”可指TIP TCP连接、TIP TLS连接或TIP多路复用连接（通过TCP或TLS）。这没什么区别，每种情况下的行为都是一样的。如果连接类型之间存在行为差异，则会明确说明这些差异。
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.
不幸的是，对于交易标识符的格式没有一个全球公认的标准；有各种标准和专有格式。TIP事务标识符的允许格式在“TIP统一资源定位器”一节中描述。事务管理器可以以其认为合适的任何方式将其内部事务标识符映射到此TIP格式。此外，上下级关系中的每一方都可以为交易分配自己的标识符；这些标识符在首次建立关系时交换。因此，事务管理器可以在内部使用自己的事务标识符格式，但它必须记住它所涉及的每个上级/下级关系的外部事务标识符。
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.
假设节点“A”上的某个程序创建了一个事务，并希望节点“B”上的某个程序作为事务的一部分执行某些工作。他这样做有两种经典方式，即“推”模式和“拉”模式。
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.
在“推送”模型中，A上的程序首先要求其事务管理器将事务导出到节点B。A的事务管理器向B的TM发送一条消息，要求其将事务实例化为A的从属事务，并返回其事务名称。然后，A上的程序向B上的对应程序发送一条消息，其顺序为“做一些工作，并使其成为事务经理已知的事务的一部分…”。因为A的TM知道它将事务发送给B的TM，所以A的TM知道让B的TM参与两阶段提交过程。
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.
在“拉”模式中，A上的程序只向B发送一条消息，顺序是“做一些工作，并使其成为我的TM通过名称知道的事务的一部分…”。B上的程序要求其TM加入事务。此时，B的TM将从A“拉”过来事务。作为拉的结果，A的TM知道B的TM将参与两阶段提交过程。
The protocol described here supports both the "push" and "pull" models.
这里描述的协议支持“推”和“拉”模型。
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.
为了使TIP事务管理器能够连接，他们必须能够相互识别和定位。执行此操作所需的信息由TIP事务管理器地址描述。
[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事务管理器最初如何获取事务管理器地址（可能通过某些特定于实现的配置机制）。]
TIP transaction manager addresses take the form:
TIP事务管理器地址采用以下形式：
<hostport><path>
<hostport><path>
The <hostport> component comprises:
<hostport>组件包括：
<host>[:<port>]
<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.
其中<host>是<dns name>或<ip地址>；<port>是一个十进制数，指定事务管理器（或代理）侦听建立TIP连接请求的端口。如果省略端口号，则使用标准TIP端口号（3372）。
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.
<dns名称>是域名服务可接受的标准名称。它必须足够合格，以便对命令接收者有用。
An <ip address> is an IP address, in the usual form: four decimal numbers separated by period characters.
<ip地址>是一个ip地址，通常的形式是：四个十进制数字，由句点字符分隔。
The <hostport> component defines the scope (locale) of the <path> component.
<hostport>组件定义<path>组件的作用域（区域设置）。
The <path> component of the transaction manager address contains data identifying the specific TIP transaction manager, at the location defined by <hostport>.
事务管理器地址的<path>组件包含标识特定TIP事务管理器的数据，位于<hostport>定义的位置。
The <path> component takes the form:
<path>组件采用以下形式：
"/" [path_segments]
“/”[路径\ U段]
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
unreserved = ASCII character octets with values in the range
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
unreserved = ASCII character octets with values in the range
(inclusive): 48-57, 65-90, 97-122 | "$" | "-" | "_" |
"." | "!" | "~" | "*" | "'" | "(" | ")" | ","
escaped = "%" hex hex
hex = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" |
"A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" |
"e" | "f"
(inclusive): 48-57, 65-90, 97-122 | "$" | "-" | "_" |
"." | "!" | "~" | "*" | "'" | "(" | ")" | ","
escaped = "%" hex hex
hex = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" |
"A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" |
"e" | "f"
The <path> component may consist of a sequence of path segments separated by a single slash "/" character. Within a path segment, the characters "/", ";", "=", and "?" are reserved. Each path segment may include a sequence of parameters, indicated by the semicolon ";" character. The parameters are not significant to the parsing of relative references.
<path>组件可能由一系列由单个斜杠“/”字符分隔的路径段组成。在路径段中，保留字符“/”、“；”、“=”和“？”。每个路径段可能包括一系列参数，由分号“；”字符表示。这些参数对于解析相对引用并不重要。
[It is intended that the form of the transaction manager address follow the proposed scheme for Uniform Resource Identifiers (URI) [8].]
[旨在事务管理器地址的形式遵循建议的统一资源标识符（URI）方案[8]。]
The TIP transaction manager address therefore provides to the connection initiator (the primary) the endpoint identifier to be used for the TCP connection (<hostport>), and to the connection receiver (the secondary) the path to be used to locate the specific TIP transaction manager (<path>). This is all the information required for the connection between the primary and secondary TIP transaction managers to be established.
因此，TIP事务管理器地址向连接启动器（主）提供用于TCP连接的端点标识符（<hostport>），并向连接接收器（次）提供用于定位特定TIP事务管理器的路径（<path>）。这是在主要和次要TIP事务管理器之间建立连接所需的所有信息。
After a connection has been established, the primary party issues an IDENTIFY command. This command includes as parameters two transaction manager addresses: the primary transaction manager address, and the secondary transaction manager address.
建立连接后，主要参与方发出标识命令。此命令包括两个事务管理器地址作为参数：主事务管理器地址和辅助事务管理器地址。
The primary transaction manager address identifies the TIP transaction manager that initiated the connection. This information is required in certain cases after connection failures, when one of the parties of the connection must re-establish a new connection to the other party in order to complete the two-phase-commit protocol. If the primary party needs to re-establish the connection, the job is easy: a connection is established in the same way as was the original connection. However, if the secondary party needs to re-establish the connection, it must be known how to contact the initiator of the original connection. This information is supplied to the secondary via the primary transaction manager address on the IDENTIFY command. If a primary transaction manager address is not supplied, the primary party must not perform any action which would require a connection to be re-established (e.g. to perform recovery actions).
主事务管理器地址标识启动连接的TIP事务管理器。在连接失败后的某些情况下，当连接的一方必须重新建立与另一方的新连接以完成两阶段提交协议时，需要此信息。如果主要参与方需要重新建立连接，那么这项工作很简单：连接的建立方式与原始连接相同。但是，如果辅助方需要重新建立连接，则必须知道如何联系原始连接的发起方。此信息通过IDENTIFY命令上的主事务管理器地址提供给辅助事务管理器。如果未提供主事务管理器地址，则主交易方不得执行任何需要重新建立连接的操作（例如，执行恢复操作）。
The secondary transaction manager address identifies the receiving TIP transaction manager. In the case of TIP communication via intermediate proxy servers, this URL may be used by the proxy servers to correctly identify and connect to the required TIP transaction manager.
辅助事务管理器地址标识接收TIP事务管理器。在通过中间代理服务器进行TIP通信的情况下，代理服务器可以使用此URL正确识别并连接到所需的TIP事务管理器。
Transactions and transaction managers are resources associated with the TIP protocol. Transaction managers and transactions are located using the transaction manager address scheme. Once a connection has been established, TIP commands may be sent to operate on transactions associated with the respective transaction managers.
事务和事务管理器是与TIP协议关联的资源。事务管理器和事务使用事务管理器地址方案定位。一旦建立了连接，就可以发送TIP命令来操作与各个事务管理器相关联的事务。
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 a reference to the remote transaction manager (i.e. the transaction manager to which the transaction is to be pushed), which allows the local transaction manager to locate the remote transaction manager. The TIP protocol defines a URL scheme [4] which allows applications and transaction managers to exchange references to transaction managers and transactions.
要从远程节点提取事务的应用程序必须提供对远程事务的引用，该引用允许本地事务管理器（即提取事务的事务管理器）连接到远程事务管理器并识别特定事务。要将事务推送到远程节点的应用程序必须提供对远程事务管理器（即，要将事务推送到的事务管理器）的引用，该引用允许本地事务管理器定位远程事务管理器。TIP协议定义了一个URL方案[4]，允许应用程序和事务管理器交换对事务管理器和事务的引用。
A TIP URL takes the form:
提示URL的形式如下：
tip://<transaction manager address>?<transaction string>
tip://<transaction manager address>?<transaction string>
where <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above); and <transaction string> specifies a transaction identifier, which may take one of two forms (standard or non-standard):
其中，<transaction manager address>标识TIP交易经理（定义见上文第7节）；和<transaction string>指定一个事务标识符，它可以采用两种形式之一（标准或非标准）：
i. "urn:" <NID> ":" <NSS>
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 [6] (valid characters, encoding, etc.).
标准事务标识符，符合RFC2141规定的统一资源名称（URN）的拟议互联网标准；其中<NID>是名称空间标识符，<NSS>是特定于名称空间的字符串。命名空间ID确定命名空间特定字符串的语法解释。命名空间特定的字符串是表示事务标识符的字符序列（由<NID>定义）。这些字段内容的规则由[6]指定（有效字符、编码等）。
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.
<transaction string>的这种格式可用于以标准表示形式表示全局事务标识符。<NID>的示例可能是<iso>或<xopen>。例如
tip://123.123.123.123/?urn:xopen:xid
tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration. See [7] for details on how to do this.
请注意，命名空间ID需要注册。有关如何执行此操作的详细信息，请参见[7]。
ii. <transaction identifier>
二,<事务标识符>
A sequence of printable ASCII characters (octets with values in the range 32 through 126 inclusive (excluding ":") representing a transaction identifier. In this non-standard case, it is the combination of <transaction manager address> and <transaction identifier> which ensures global uniqueness. e.g.
表示事务标识符的可打印ASCII字符序列（八位字节，其值范围为32到126（不包括“：”），在这种非标准情况下，是<transaction manager address>和<transaction identifier>的组合，可确保全局唯一性。例如。
tip://123.123.123.123/?transid1
tip://123.123.123.123/?transid1
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 transaction manager address. If the transaction identifier is one that you created, insert your own transaction manager address. If the transaction identifier is one that you received on a TIP connection that you initiated, use the secondary transaction manager address that was sent in the IDENTIFY command. If the transaction identifier is one that you received on a TIP connection that you did not initiate, use the primary transaction manager address that was received in the IDENTIFY command.
要从事务标识符创建非标准TIP URL，请首先将事务标识符中的所有保留字符替换为其等效转义序列，然后插入相应的事务管理器地址。如果事务标识符是您创建的，请插入您自己的事务管理器地址。如果事务标识符是您在启动的TIP连接上收到的，请使用在IDENTIFY命令中发送的辅助事务管理器地址。如果事务标识符是您在未启动的TIP连接上收到的，请使用在IDENTIFY命令中收到的主事务管理器地址。
TIP URLs must be guaranteed globally unique for all time. This uniqueness constraint ensures TIP URLs are never duplicated, thereby preventing possible non-deterministic behaviour. How uniqueness is achieved is implementation specific. For example, the Universally Unique Identifier (UUID, also known as a Globally Unique Identifier, or GUID (see [9])) could be used as part of the <transaction string>. Note also that some standard transaction identifiers may define their own rules for ensuring global uniqueness (e.g. OSI CCR atomic action identifiers).
提示URL必须保证在任何时候都是全局唯一的。此唯一性约束确保TIP URL永远不会重复，从而防止可能的不确定性行为。如何实现唯一性取决于具体的实现。例如，通用唯一标识符（UUID，也称为全局唯一标识符，或GUID（参见[9]）可以用作<transaction string>的一部分。还请注意，一些标准事务标识符可以定义自己的规则以确保全局唯一性（例如OSI CCR原子操作标识符）。
Except as otherwise described above, the TIP URL scheme follows the rules for reserved characters as defined in [4], and uses escape sequences as defined in [4] Section 5.
除非上文另有说明，TIP URL方案遵循[4]中定义的保留字符规则，并使用[4]第5节中定义的转义序列。
Note that the TIP protocol itself does not use the TIP URL scheme (it does use the transaction manager address scheme). The TIP URL scheme is proposed as a standard way to pass transaction identification
请注意，TIP协议本身不使用TIP URL方案（它使用事务管理器地址方案）。TIP URL方案被提议作为传递事务标识的标准方式
information through other protocols. e.g. between cooperating application processes. The TIP 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 ([5] includes examples of such APIs).
通过其他协议提供信息。e、 g.合作应用程序进程之间。然后，TIP URL可用于向本地事务管理器传送将应用程序与特定TIP事务关联所需的信息。e、 g.从远程事务管理器中提取事务。预计每个TIP实现将为此提供一些API集（[5]包括此类API的示例）。
At any instant, only one party on a connection is allowed to send commands, while the other party is only allowed to respond to 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 connection is primary; however, a few commands cause the roles to switch. A connection returns to its original polarity whenever the Idle state is reached.
在任何时刻，连接上只有一方被允许发送命令，而另一方只被允许响应他接收到的命令。在本文档中，允许发送命令的一方称为“主要”；另一方被称为“第二方”。最初，发起连接的一方是主要的；但是，一些命令会导致角色切换。当达到空闲状态时，连接将返回其原始极性。
When multiplexing is being used, these rules apply independently to 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). See section 12 for details.
请注意，辅助服务器可以通过使用流水线“带外”发送命令。这不会影响连接的极性（即，主要和次要角色不切换）。详情见第12节。
In the normal case, TIP connections should only be closed by the primary, when in Initial state. It is generally undesirable for a connection to be closed by the secondary, although this may be necessary in certain error cases.
在正常情况下，当处于初始状态时，叶尖连接应仅由一回路闭合。通常不希望由辅助服务器关闭连接，尽管在某些错误情况下可能需要这样做。
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 state changes when he receives a reply.
在任何时刻，连接都处于以下状态之一。从第二方的角度来看，当他发送回复时，状态发生变化；从主要政党的角度来看，当他收到答复时，国家就会发生变化。
Initial: The initial connection starts out in the Initial state. Upon entry into this state, the party that initiated the connection becomes primary, and the other party becomes secondary. There is no transaction associated with the connection in this state. From this state, the primary can send an IDENTIFY or a TLS command.
初始：初始连接在初始状态下启动。进入该状态后，发起连接的一方成为主要方，另一方成为次要方。在此状态下，没有与连接关联的事务。在此状态下，主服务器可以发送标识或TLS命令。
Idle: In this state, the primary and the secondary have agreed on a protocol version, and the primary supplied an identifier to the secondary party to reconnect after a failure. There is no transaction associated with the 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 any of the following commands: BEGIN, MULTIPLEX, PUSH, PULL, QUERY and RECONNECT.
进入此状态后，发起连接的一方成为主要连接方，另一方成为次要连接方。在此状态下，主设备可以发送以下任意命令：开始、多路传输、推送、拉送、查询和重新连接。
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 this state. Failure of a connection in Begun state implies that the transaction will be aborted. From this state, the primary can send an ABORT, or COMMIT command.
已开始：在此状态下，连接与活动事务关联，该事务只能通过一个阶段协议完成。对BEGIN命令的已开始响应将连接置于此状态。处于“已开始”状态的连接失败意味着事务将中止。在此状态下，主服务器可以发送中止或提交命令。
Enlisted: In this state, the connection is associated with an active transaction, which can be completed by a one-phase or, two-phase protocol. A PUSHED response to a PUSH command, or a PULLED response to a PULL command, places the connection into this state. Failure of the connection in Enlisted state implies that the transaction will be aborted. From this state, the primary can send an ABORT, COMMIT, or PREPARE command.
已登记：在此状态下，连接与活动事务关联，该事务可以通过一阶段或两阶段协议完成。对PUSH命令的PUSH响应或对PULL命令的PULL响应将连接置于此状态。处于登记状态的连接失败意味着事务将中止。在此状态下，主服务器可以发送中止、提交或准备命令。
Prepared: In this state, a connection is associated with a transaction that has been prepared. A PREPARED response to a PREPARE command, or a RECONNECTED response to a RECONNECT command places a connection into this state. Unlike other states, failure of a connection in this state does not cause the transaction to automatically abort. From this state, the primary can send an ABORT, or COMMIT command.
已准备：在此状态下，连接与已准备的事务相关联。准备好的对PREPARE命令的响应或重新连接的对RECONNECT命令的响应会将连接置于此状态。与其他状态不同，此状态下的连接失败不会导致事务自动中止。在此状态下，主服务器可以发送中止或提交命令。
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.
多路复用：在此状态下，多路复用协议正在使用连接，该协议提供自己的连接集。在此状态下，连接上不能使用TIP命令。（当然，在多路复用协议提供的连接上可以使用TIP命令。）连接永远不能离开此状态。
Tls: In this state, the connection is being used by the TLS protocol, which provides its own secured connection. In this state, no TIP commands are possible on the connection. (Of course, TIP commands are possible on the connection supplied by the TLS protocol.) The connection can never leave this state.
Tls：在此状态下，Tls协议正在使用连接，该协议提供自己的安全连接。在此状态下，连接上不能使用TIP命令。（当然，在TLS协议提供的连接上可以使用TIP命令。）连接永远不能离开此状态。
Error: In this state, a protocol error has occurred, and the connection is no longer useful. The connection can never leave this state.
错误：在此状态下，发生协议错误，连接不再有用。连接永远无法离开此状态。
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.
本文件描述了协议的第3版。为了适应未来的版本，主要方发送一条消息，指示它所理解的最低和最高版本号。辅助服务器以其理解的最高版本号进行响应。
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).
在这种交换之后，可以使用最高版本号中较小的版本号（即双方都能理解的最高版本号）进行通信。此交换是强制性的，使用IDENTIFIED命令（和IDENTIFIED响应）进行。
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.
如果一方支持的最高版本被认为已过时，而另一方不再支持，则无法进行有用的通信。在这种情况下，较新的一方只需断开连接即可。
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).
所有命令和响应都由一行ASCII文本组成，仅使用值范围为32到126（含）的八位字节，后跟CR（值为13的八位字节）或LR（值为10的八位字节）。每行可以分成一个或多个“字”，其中连续的字由一个或多个空格八位组分隔（值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.)
将忽略空行或完全由空格组成的行。（这意味着，如果需要，可以同时使用CR和LF终止行；LF将被视为终止空行，并被忽略。）
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.
命令行或响应行中第一个未定义单词之后（包括）的所有单词将被完全忽略。这些可用于传递人类可读的信息，以用于调试或其他目的。
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.
为了减少通信延迟并提高效率，可以将多条TIP“线路”（命令或响应）流水线（串联）在一起并作为单个消息发送。行也可以“提前”发送（由辅助设备发送，供主设备稍后处理）。例如，紧接着BEGIN命令的中止命令，或紧接着PULL命令的提交响应。
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.
当连接状态为应该读取一行（命令或响应）时，则处理该行（接收时）。在处理再次达到这种状态之前，不会从连接中读取更多的行。如果在未轮到另一方发送时，在连接上接收到一条线路，则该线路不会被拒绝。相反，当连接状态再次需要该行时，该行将被保留和处理。接收方必须按照收到的行的顺序处理行并发出响应。如果某一行导致错误，则连接将进入错误状态，并放弃连接上的所有后续行。
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.
命令与连接或事务相关。与连接相关的命令有：标识、多路复用和TLS。与事务相关的命令有：中止、开始、提交、准备、拉、推、查询和重新连接。
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 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.
已开始<transaction identifier>新事务已成功开始，该事务现在是连接的当前事务。连接进入开始状态。
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:
此命令在“已开始”、“已登记”或“已准备”状态下有效。在“已开始”或“已登记”状态下，它要求辅助服务器尝试提交事务；在准备就绪状态下，它会通知辅助服务器事务已提交。请注意，在登记状态下，此命令表示一个单阶段协议，仅当发送方1）事务中没有本地可恢复资源，2）只有一个下级（发送方将不参与任何事务恢复过程）时，才应执行此命令。可能的答复是：
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.
中止此响应只能从“已开始”和“已登记”状态开始。它表示某一方否决了事务的承诺，因此事务被中止而不是提交。连接进入空闲状态。
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>
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:
此命令仅在初始状态下有效。主要方通知次要方：1）支持的最低和最高协议版本（必须支持最低和最高版本之间的所有版本；2）如果需要，次要方可以在其中重新建立连接的主要方标识符（主要事务管理器地址）；以及3）中间代理服务器可用于连接到所需TIP事务管理器（辅助事务管理器地址）的标识符。如果未提供主事务管理器地址，则辅助方将以中止或只读方式响应任何准备命令。可能的答复是：
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.
已识别<协议版本>，已成功联系辅助方并已保存主事务管理器地址。响应包含辅助方支持的最高协议版本。假设所有未来的通信都使用IDENTIFY命令和IDENTIFY响应中较小的协议版本进行。连接进入空闲状态。
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
需求TLS第二方只愿意通过TLS安全连接进行通信。连接进入Tls状态，所有后续通信都由Tls协议定义。此协议将从行后的第一个八位组开始
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.
IDENTIFY命令的终止符（用于主要方发送的数据），以及NEEDTLS响应的行终止符之后的第一个字节（用于次要方发送的数据）。这意味着实现不能在IDENTIFY命令或NEEDTLS响应之后发送CR和LF八位字节，以免LF八位字节被误认为TLS协议的第一个字节。TLS协议提供的连接在初始状态下启动。协商TLS后，主要方必须重新发送标识命令。如果主要方不能支持（或拒绝使用）TLS协议，则会关闭连接。
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.
目前，唯一定义的协议标识符是“TMP2.0”，它是指TIP多路复用协议版本2.0。有关本协议的详细信息，请参见附录A。将来可以定义其他协议标识符。
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.
如果接受多路复用命令，指定的多路复用协议将完全控制基础连接。该协议将从多路复用命令行终止符之后的第一个八位字节（对于启动器发送的数据）和多路复用响应行终止符之后的第一个字节（对于启动器接收的数据）开始。这意味着实现在多路复用命令或多路复用响应之后不得同时发送CR和LF八位字节，以免LF八位字节被误认为多路复用协议的第一个字节。
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:
请注意，在使用TMP V2.0时，单个TIP命令（TMP应用程序消息）必须完全包含在单个TMP数据包中（TIP不使用TMP PUSH标志）。对多路复用命令的可能响应有：
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.
中止下级已否决提交事务。连接进入空闲状态。此响应后，上级对下级的交易不承担任何责任。
READONLY 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 subordinate with respect to the transaction.
只读下级不再关心事务是提交还是中止。连接进入空闲状态。此响应后，上级对下级的交易不承担任何责任。
ERROR 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>
PULL <superior's transaction identifier>
<subordinate's transaction identifier>
This command is only valid in Idle state. This command seeks to establish a superior/subordinate relationship in a transaction, 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 section "TIP Uniform Resource Locators") must be specified as the transaction identifier. Possible responses are:
他正在从第二方拉一笔交易）。请注意，<transaction string>（定义见“TIP统一资源定位器”一节）的整个值必须指定为事务标识符。可能的答复是：
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.
NotPull关系尚未建立（可能是因为第二方不再具有请求的事务）。连接仍处于空闲状态。
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:
此命令仅在空闲状态下有效。它寻求在以主要人员为上级的交易中建立上级/下级关系。请注意，<transaction string>（定义见“TIP统一资源定位器”一节）的整个值必须指定为事务标识符。可能的答复是：
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.
ALREADYPUSHED<下属事务标识符>已建立关系，且下属知道返回事务的标识符。但是，下级已经知道事务，并且期望两阶段提交协议通过不同的连接到达。在这种情况下，连接将保持空闲状态。
NOTPUSHED The relationship could not be established. The connection remains in the Idle state.
无法建立关系。连接仍处于空闲状态。
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.
QuerieDex显示事务仍然存在。连接仍处于空闲状态。
QUERIEDNOTFOUND The transaction no longer exists. The connection remains in the Idle state.
QUERIEDNOTFOUND发现事务不再存在。连接仍处于空闲状态。
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
TLS
This command is valid only in the Initial state. A primary uses this command to attempt to establish a secured connection using TLS.
此命令仅在初始状态下有效。主服务器使用此命令尝试使用TLS建立安全连接。
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.
如果接受TLS命令，TLS协议将完全控制底层连接。该协议将以TLS命令行终止符之后的第一个八位字节（对于主命令发送的数据）和TLSING响应行终止符之后的第一个字节（对于主命令接收的数据）开始。这意味着实现在TLS命令或TLSING响应之后不得同时发送CR和LF八位字节，以免LF八位字节被误认为TLS协议的第一个字节。
Possible responses to the TLS command are:
对TLS命令的可能响应有：
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.
第二方同意使用TLS协议[3]。连接进入Tls状态，所有后续通信都由Tls协议定义。TLS协议提供的连接在初始状态下启动。
CANTTLS The secondary party cannot support (or refuses to use) the TLS protocol. The connection remains in the Initial state.
第二方不能支持（或拒绝使用）TLS协议。连接保持在初始状态。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
错误命令在错误状态下发出，或格式不正确。连接进入错误状态。
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.
收到错误指示或错误响应表明另一方认为您未正确实施协议。
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).
连接故障可能由通信故障或关闭连接的任何一方造成。假设TIP实现将使用某种私有机制来检测TIP连接故障（例如套接字保持有效或超时方案）。
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.
如果上级确定事务提交，则它必须最终建立与下级的新连接，并为事务发送重新连接命令。如果它收到NOTRECONNECTED响应，则无需执行其他操作。但是，如果它接收到重新连接的响应，它必须发送提交请求并接收提交的响应。
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
请注意，下级可以在意识到上一次连接失败之前接收重新连接命令。在这种情况下，下级将重新连接命令视为
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.
1. 它从上级收到QUERIEDNOTFOUND响应。在这种情况下，下级应该中止事务。
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.
2. 上级在启动的某个连接上向下级发送事务的重新连接命令。在这种情况下，下级可以期望在这个新连接上了解事务的结果。如果此新连接在下级了解事务结果之前失败，则应再次开始发送查询命令。
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.
请注意，如果TIP系统接收到查询或重新连接命令，并且由于某种原因无法满足请求（例如，必要的恢复信息当前不可用），则应断开连接。
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.
本节旨在告知应用程序开发人员、事务管理器开发人员和用户本文档所述TIP的安全含义。虽然讨论中提出了一些降低安全风险的建议，但讨论中并未包括所述问题的最终解决方案。
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.
与所有两阶段提交协议一样，应用于应用程序通信协议的任何安全机制都可能被破坏，除非相应的机制应用于提交协议。例如，使用应用协议的各方之间的任何认证必须由TIP交换的安全性支持，至少具有相同的确定性。
TLS provides optional client-side authentication, optional server-side authentication, and optional packet encryption.
TLS提供可选的客户端身份验证、可选的服务器端身份验证和可选的数据包加密。
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).
除非使用TLS，否则TIP实现可能拒绝提供服务。如果不使用数据包加密，它可能会拒绝提供服务。除非远程方已通过认证（通过TLS），否则它可能拒绝提供服务。
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.
TIP实现应该愿意自己进行身份验证（通过TLS）。无论实现是作为客户机还是服务器，这都是正确的。
Once a remote party has been authenticated, a TIP transaction manager may use that remote party's identity to decide what operations to allow.
一旦远程方经过身份验证，TIP事务管理器可以使用该远程方的身份来决定允许哪些操作。
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.
是否在连接上使用TLS，如果是，如何使用TLS，以及随后允许哪些操作，由连接TIP事务管理器彼此之间的安全策略决定。这些安全策略是如何定义的，以及TIP事务管理器是如何了解它们的，这对于实现来说是完全私有的，超出了本文档的范围。
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.
假设恶意用户知道某个事务管理器中当前活动的事务的身份。如果罪犯打开到事务管理器的TIP连接，发送PULL命令，然后关闭连接，他可以导致事务中止。这将导致对交易合法所有者的拒绝服务。
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.
除非正在使用TLS、远程方已通过身份验证且远程方受信任，否则实现可以通过拒绝PULL命令来避免此攻击。
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, thus denying service to all legitimate users of that transaction manager.
如果恶意用户利用此事实重复创建事务，使其进入准备状态并断开连接，则可能会导致事务管理器资源耗尽，从而拒绝向该事务管理器的所有合法用户提供服务。
An implementation may avoid this attack by refusing PUSH commands unless TLS is being used, the remote party has been authenticated, and the remote party is trusted.
除非正在使用TLS、远程方已通过身份验证且远程方受信任，否则实现可以通过拒绝推送命令来避免此攻击。
If a subordinate transaction manager has lost its connection for a particular prepared transaction, a malicious user can initiate a TIP connection to the transaction manager, and send it a RECONNECT command followed by either a COMMIT or an ABORT command for the transaction. The malicious user could thus cause part of a transaction to be committed when it should have been aborted, or vice versa.
如果下级事务管理器已失去与特定已准备事务的连接，则恶意用户可以启动与事务管理器的TIP连接，并向其发送重新连接命令，然后发送事务的COMMIT或ABORT命令。因此，恶意用户可能导致事务的一部分在本应中止时提交，反之亦然。
An implementation may avoid this attack by recording the authenticated identity of its superior in a transaction, and by refusing RECONNECT commands unless TLS is being used and the authenticated identity of the remote party is the same as the identity of the original superior.
实现可以通过在事务中记录其上级的已验证身份，并通过拒绝重新连接命令来避免此攻击，除非正在使用TLS且远程方的已验证身份与原始上级的身份相同。
If a malicious user can intercept traffic on a TIP connection, he may be able to deduce information useful in planning other attacks. For example, if comment fields include the product name and version number of a transaction manager, a malicious user might be able to use this information to determine what security bugs exist in the implementation.
如果恶意用户可以截获TIP连接上的流量，他就可以推断出在策划其他攻击时有用的信息。例如，如果注释字段包括事务管理器的产品名称和版本号，则恶意用户可能会使用此信息来确定实现中存在哪些安全漏洞。
An implementation may avoid this attack by always using TLS to provide session encryption, and by not putting any personalizing information on the TLS/TLSING command/response pair.
通过始终使用TLS提供会话加密，并且不在TLS/TLS命令/响应对上放置任何个性化信息，实现可以避免这种攻击。
If a malicious user can intercept and alter traffic on a TIP connection, he can wreak havoc in a number of ways. For example, he could replace a COMMIT command with an ABORT command.
如果恶意用户可以拦截和改变TIP连接上的流量，他可以通过多种方式造成严重破坏。例如，他可以将COMMIT命令替换为ABORT命令。
An implementation may avoid this attack by always using TLS to provide session encryption and authentication of the remote party.
通过始终使用TLS提供远程方的会话加密和身份验证，实现可以避免这种攻击。
[1] Gray, J. and A. Reuter (1993), Transaction Processing: Concepts and Techniques. San Francisco, CA: Morgan Kaufmann Publishers. (ISBN 1-55860-190-2).
[1] Gray，J.和A.Reuter（1993），事务处理：概念和技术。旧金山，CA：摩根考夫曼出版社。（ISBN 1-55860-190-2）。
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[2] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[3] Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in Progress.
[3] Dierks，T.等人，“TLS协议1.0版”，正在进行中。
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[4] Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[5] Evans, K., Klein, J., and J. Lyon, "Transaction Internet Protocol - Requirements and Supplemental Information", RFC 2372, July 1998.
[5] Evans，K.，Klein，J.，和J.Lyon，“交易互联网协议-要求和补充信息”，RFC 2372，1998年7月。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[7] Faltstrom, P., et. al., "Namespace Identifier Requirements for URN Services", Work in Progress.
[7] Faltstrom，P.等人，“URN服务的命名空间标识符要求”，正在进行中。
[8] Berners-Lee, T., et. at., "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", Work in Progress.
[8] Berners Lee，T.，et.at.，“统一资源标识符（URI）：通用语法和语义”，正在进行中。
[9] Leach, P., and R. Salz, "UUIDs and GUIDs", Work in Progress.
[9] Leach，P.和R.Salz，“UUID和GUID”，正在进行中。
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399, USA
吉姆·里昂微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052-6399
Phone: +1 (206) 936 0867
Fax: +1 (206) 936 7329
EMail: JimLyon@Microsoft.Com
Phone: +1 (206) 936 0867
Fax: +1 (206) 936 7329
EMail: JimLyon@Microsoft.Com
Keith Evans Tandem Computers, Inc. 5425 Stevens Creek Blvd Santa Clara, CA 95051-7200, USA
美国加利福尼亚州圣克拉拉史蒂文斯克里克大道5425号基思·埃文斯串联计算机公司，邮编95051-7200
Phone: +1 (408) 285 5314
Fax: +1 (408) 285 5245
EMail: Keith.Evans@Tandem.Com
Phone: +1 (408) 285 5314
Fax: +1 (408) 285 5245
EMail: Keith.Evans@Tandem.Com
Johannes Klein Tandem Computers Inc. 10555 Ridgeview Court Cupertino, CA 95014-0789, USA
约翰内斯·克莱恩串联计算机公司，美国加利福尼亚州库比蒂诺市里奇维尤法院10555号，邮编95014-0789
Phone: +1 (408) 285 0453
Fax: +1 (408) 285 9818
EMail: Johannes.Klein@Tandem.Com
Phone: +1 (408) 285 0453
Fax: +1 (408) 285 9818
EMail: Johannes.Klein@Tandem.Com
Please send comments on this document to the authors at <JimLyon@Microsoft.Com>, <Keith.Evans@Tandem.Com>, <Johannes.Klein@Tandem.Com>, or to the TIP mailing list at <Tip@Lists.Tandem.Com>. You can subscribe to the TIP mailing list by sending mail to <Listserv@Lists.Tandem.Com> with the line "subscribe tip <full name>" somewhere in the body of the message.
请将对本文件的评论发送至以下地址的作者：<JimLyon@Microsoft.Com>基思。Evans@Tandem.Com>约翰。Klein@Tandem.Com>，或发送至<Tip@Lists.Tandem.Com>. 您可以通过将邮件发送到订阅TIP邮件列表<Listserv@Lists.Tandem.Com>在邮件正文的某个地方写上“订阅提示<全名>”。
Appendix A. The TIP Multiplexing Protocol Version 2.0.
附录A.TIP多路复用协议版本2.0。
This appendix describes version 2.0 of the TIP Multiplexing Protocol (TMP). TMP is intended solely for use with the TIP protocol, and forms part of the TIP protocol specification (although its implementation is optional). TMP V2.0 is the only multiplexing protocol supported by TIP V3.0.
本附录描述了TIP多路复用协议（TMP）的2.0版。TMP仅用于TIP协议，并构成TIP协议规范的一部分（尽管其实现是可选的）。TMP V2.0是TIP V3.0支持的唯一多路复用协议。
Abstract
摘要
TMP provides a simple mechanism for creating multiple lightweight connections over a single TCP connection. Several such lightweight connections can be active simultaneously. TMP provides a byte oriented service, but allows message boundaries to be marked.
TMP提供了一种简单的机制，用于通过单个TCP连接创建多个轻量级连接。可以同时激活多个此类轻型连接。TMP提供面向字节的服务，但允许标记消息边界。
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.
Internet上广泛使用的几种协议为每个事务创建一个TCP连接。不幸的是，由于这些事务的生命周期很短，因此建立和拆除这些TCP连接的成本变得非常高，无论是在所使用的资源方面，还是在与TCP拥塞控制机制相关的延迟方面。
The TIP Multiplexing Protocol (TMP) is a simple protocol running on top of TCP that can be used to create multiple lightweight 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.
TIP多路复用协议（TMP）是运行在TCP之上的简单协议，可用于通过单个传输连接创建多个轻量级连接。因此，TMP可以更有效地使用TCP连接。来自多个不同TMP连接的数据可以交错，并且可以提供消息边界和流结束标记。
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.
因为TMP运行在可靠的字节顺序传输服务之上，所以它可以避免TCP为确保可靠性而必须进行的大部分额外工作。例如，TMP连接不需要确认，因此在发送数据之前不需要等待握手完成。
Note: TMP is not intended as a generalized multiplexing protocol. If you are designing a different protocol that needs multiplexing, TMP may or may not be appropriate. Protocols with large messages can exceed the buffering capabilities of the receiver, and under certain conditions this can cause deadlock. TMP when used with TIP does not suffer from this problem since TIP is a request-response protocol, and all messages are short.
注：TMP不打算作为通用多路复用协议。如果您正在设计需要多路复用的不同协议，则TMP可能适用，也可能不适用。具有大消息的协议可能超过接收器的缓冲能力，在某些情况下，这可能导致死锁。TMP与TIP一起使用时不会出现此问题，因为TIP是一个请求-响应协议，并且所有消息都很短。
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.
基本协议模型是在可靠的字节流上运行的多个轻量级连接。发起连接的一方称为主连接方，接受连接的一方称为次连接方。
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.
连接可以是单向的或双向的；双向连接的每一端都可以单独闭合。连接可以正常关闭，也可以重置以指示释放失败。中止连接将关闭两个数据流。
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.
一旦连接打开，应用程序就可以通过它发送消息，并发出应用程序级消息结束的信号。应用程序消息封装在TMP数据包中，并通过字节流传输。单个TIP命令（TMP应用程序消息）必须完全包含在单个TMP数据包中。
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.
TMP数据包由一个64位报头和零个或多个八位字节的数据组成。标题包含三个字段；标志字节、连接标识符和数据包长度。整数、连接标识符和数据包长度必须按网络字节顺序发送。
FLAGS
+--------+--------+--------+--------+
|SFPR0000| Connection ID |
+--------+--------+--------+--------+
| | Length |
+--------+--------+--------+--------+
FLAGS
+--------+--------+--------+--------+
|SFPR0000| Connection ID |
+--------+--------+--------+--------+
| | Length |
+--------+--------+--------+--------+
+-------+-----------+-----------------------------------------+
| Name | Mask | Description |
+-------+-----------+ ----------------------------------------+
| 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 |
+-------+-----------+-----------------------------------------+
+-------+-----------+-----------------------------------------+
| Name | Mask | Description |
+-------+-----------+ ----------------------------------------+
| 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 |
+-------+-----------+-----------------------------------------+
Each TMP connection is identified by a 24 bit integer. TMP connections created by the party which initiated the underlying TCP connection must have even identifiers; those created by the other party must have odd identifiers.
每个TMP连接由一个24位整数标识。发起底层TCP连接的一方创建的TMP连接必须具有偶数个标识符；由另一方创建的标识符必须为奇数。
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.
TMP连接可以在几种不同的状态下存在；关闭、OpenWrite、OpenSynRead、OpenSynReset、OpenReadWrite、CloseWrite和CloseRead。连接可以更改其状态，以响应接收设置了SYN、FIN或RESET位的数据包，或响应应用程序的API调用。可用的API调用包括打开、关闭和中止。
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.
大多数状态的含义是显而易见的（例如，OpenWrite表示已打开连接进行写入）。OpenSynRead和OpenResetRead状态的含义需要更多解释。
In the OpenSynRead state a primary opened and immediately closed the output data stream of a connection, and is now waiting for a SYN response from the secondary to open the input data stream for reading.
在OpenSynRead状态下，主服务器打开并立即关闭连接的输出数据流，现在正在等待来自辅助服务器的SYN响应以打开输入数据流进行读取。
In the OpenResetRead state a primary opened and immediately aborted a connection, and is now waiting for a SYN response from the secondary to finally close the connection.
在OpenResetRead状态下，主服务器打开并立即中止连接，现在正在等待辅助服务器的SYN响应以最终关闭连接。
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.
下面显示的状态表描述了为响应给定事件而发生的操作和状态转换。每个状态接受的事件按优先级顺序列出，优先级最高的优先。如果消息中存在多个事件，则会处理与列表匹配的事件。如果多个事件匹配，则首先接受并处理具有最高优先级的事件。任何剩余事件都将在结果后续状态中处理。
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
例如，如果辅助设备上的TMP连接处于关闭状态，并且辅助设备接收到包含SYN事件、FIN事件和输入数据事件（即data-in）的数据包，则辅助设备首先接受SYN事件（因为它是关闭状态下的唯一匹配项）。辅助服务器接受连接，发送SYN事件并进入读写状态。SYN事件将从挂起事件列表中删除。其余事件为FIN和DATA-IN。在读写状态下，辅助设备读取输入数据（即，首先处理data-In事件，因为其优先级高于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.
事件）。一旦读取了数据并且从挂起事件列表中删除了data-IN事件，FIN事件将被处理，辅助系统将进入CloseWrite状态。
If the secondary receives a packet containing a SYN event, and is for some reason unable to accept the connection (e.g. insufficient resources), it should reject the request by sending a SYN event followed by a RESET event. Note that both events can be sent as part of the same TMP packet.
如果辅助设备接收到包含SYN事件的数据包，并且由于某种原因无法接受连接（例如资源不足），则应通过发送SYN事件，然后发送重置事件来拒绝请求。请注意，这两个事件都可以作为同一TMP数据包的一部分发送。
If either party receives a TMP packet that it does not understand, or an event in an incorrect state, it closes the TCP connection.
如果任何一方接收到它不理解的TMP数据包，或者接收到状态不正确的事件，它将关闭TCP连接。
+==============+=========+==========+==============+
| Entry State | Event | Action | Exit State |
+==============+=========+==========+==============+
| 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 |
+--------------+---------+----------+--------------+
+==============+=========+==========+==============+
| Entry State | Event | Action | Exit State |
+==============+=========+==========+==============+
| 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
TMP事件优先级和状态转换
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。