rfc2372.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：cata_xu  （cata_xu [e-mail]）              
译文发布时间：2001-7-4
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                         K. Evans
Request for Comments: 2372                                    J. Klein
Category: Informational                               Tandem Computers
                                                               J. Lyon
                                                             Microsoft
                                                             July 1998

处理internet协议（TIP）-要求和补充信息
(Transaction Internet Protocol - Requirements and
Supplemental Information)

本备忘录的状态
 
本备忘录提供了internet社区的一些信息，但并没有详细讲述任何一种internet
标准。本备忘录的发布不受任何限制。

版权声明

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

摘要

本文档描述了处理Internet协议（TIP）[1]的目的（特定使用场景）和要求。
其被有意用来帮助限定此协议的一些必要特征和功能。本文档也提供了一些辅助
理解和帮助TIP协议实现的补充信息。

目录
1. 介绍	2
2. 处理Internet协议(TIP)	3
3. 范围	4
4. TIP的预期使用	4
5.  TIP的适应系统	4
6.  X/Open DTP模型的关联	5
7.  TIP特定使用场景的实例	5
8.  TIP处理的恢复	8
9.  TIP处理和应用信息连续	8
10. TIP协议和本地操作	9
11. 安全考虑	10
12. TIP要求	10
参考	12
作者的地址	12
评论	13
附录A.  一个TIP处理管理器API的实例	13
版权声明	21

1. 介绍

处理是一个非常有用的编程范例，很大程度上简化了分布式应用的书写。当处理被使用
时，不管参与一个特定的工作单元有多少分布式应用组分，可能的结果被减少至两个，
即：要么所有工作完全成功，要么什么都完不成（这个特征常被称做原子数）。由于程
序员不必应付大量可能失败的场景，所以应用编程变得简单了。典型地，处理语义是由
一些基本的系统底层结构（通常是一种产品，诸如事务处理监控器，和/或者数据库的形
式）提供的。这底部结构应付失败以及执行必要的恢复操作以保证原子数的特性。处理
的使用能使可靠的分布式应用得以发展，否则，尽管不是不可能使分布式应用取得进展，
但是会使其变得困难。

支持分布处理的一个关键技术是二段提交协议（two-phase commit protocol）（2-pc）。2-pc
协议已经在商业事务处理（TP）系统中使用了很多年了，并且它也是很好理解的（例
如12年前就开始应用的LU6.2 2-pc（同步点）协议）。今天，大量不同的2-pc协议在许
多TP监控器和数据库产品中被支持。在参与一个分布工作单元（处理）的各个组分之间，
2-pc被用来确保与工作结果相关的所有部分（忽略任何失败的成分）一致。今天，标准的
和个性化的2-pc协议都存在。这些协议典型的使用了一个“单管道”模型。就是说处理和
应用协议是紧密结合的，是在同一个通信频道上执行的。一个应用可能只使用和处理协议
联结在一起的特定通信机制。具有比较庞杂的内容和宽泛的结构和管理要求的标准协议

（OSI TP，LU6.2)是复杂的。因此它们没有被广泛配置。如果处理能被使用的话，那么所
有这些组成的网络将具有有限的应用灵活性和互用性。应用就能有希望使用大量没有处理
变量的通信协议（例如HTTP），并被配置在不同种类的应用环境中。

概括来说，处理很大程度上简化了分布式应用的编程。2-pc协议是一种关键的处理技术。
目前运行在一具有特殊目的（复杂的，同类的）的底部结构中的2-pc协议只给一套有限
制的应用提供了处理语义。这个应用使用一套特定的双向通信协议。所以，被当前的2-pc
协议强加的约束限制了处理范例的广泛使用，因此也抑制了新的分布式商业应用的发展。

（见[2]以得到更多有关处理，原子数，以及二段提交协议的大概知识。）

2. 处理Internet协议(TIP)

TIP是在一异类（网络化的）环境中，用来提供普遍分布式处理支持的一种2-pc协议，
TIP消除了目前2-pc协议中的约束，使新的分布式商业应用成为可能。

为了达到这个目的，首先要满足两个关键要求：
   1) Keep the protocol simple (yet functionally sufficient). If the
      protocol is complex it will not be widely deployed or quickly
      adopted. Simplicity also means suitability to a wide range of
      application environments.

   2) Enable the protocol to be used with any applications
      communications protocol (e.g. HTTP). This ensures heterogeneous
      environments can participate in distributed work.
1) 保持协议的简单性（功能仍然充分）。如果这个协议是复杂的话，将不能被广泛
配置或者很快采用。简单性也意味着在一个很大范围应用环境里的适用性。

2) 能使协议和任何应用通信协议（如HTTP）一起使用。这一点确保异类环境能参与
分布式工作。

TIP不会将已知要假定废弃的2-pc协议作为基础来重新改造2-pc协议本身。TIP的更新颖、
更有效之处在于其脱离了应用通信协议（双管道模型）。
      +-------------+         应用通信          +-------------+
      |  应用程序   |---------------------------|   应用程序   |
      |             |         " 管道 1"         |             |
      +-------------+                           +-------------+
             |                                         |
             | TIP TM API                   TIP TM API |
             |                                         |
    +-----------------+     TIP 2-pc 协议     +-----------------+
    |  TIP 处理管理器  |----------------------|  TIP 处理管理器  |
    |                 |       "管道 2"        |                 |
    +-----------------+                       +-----------------+

                 图 1:  TIP的双管道本性

3. 范围

TIP不会去描述商业事务处理或者电子商务在internet上将怎样被管理。它只讲述2-pc
处理协议（一种对于这些应用发展的辅助）。例如，TIP不会提供一种非评判性的机制。
一旦对普通电子商务的要求变得更好理解，这样的协议可以是随后IETF的行为的一个主
题。TIP不会排除这些协议后来的定义。

TIP不会讲述应用编程接口（API）（请留意本文档（附录A中）包含的一个例子TIP TM 
API，以帮助理解）。

4. TIP的预期使用

正如以上所形容的，处理在简化分布式应用编程中是一个非常有用的工具。所以，TIP可
以定位于任何包括分布式工作的应用中。这样的应用可以包含执行在一个简单系统中的
成分。这个简单系统可以穿过一个企业内部网，穿过internet网或者任何别的分布式系

统结构。这个应用可以是“企业”级的（要求有很高的性能以及实用性），或者级别要求
不那么高的。人们有意使TIP变得能普遍适用的，以符合任何能从这处理语义规定中获益
的应用之需要。

5.  TIP的适应系统

有两种级别的TIP适应处理管理系统

1)  单一客户端系统。这指那些只提供一个应用接口以划分TIP处理的界线，但是没有提供
给本地恢复资源入口的系统。这样一个轻量级实现只对那些只有客户端应用的系统才有用
（如桌面机器）。这样的客户端系统可能是不可靠的，而且作为处理的协调器也是不合适
的（它们的不适用性可能导致在别的参与处理的系统上的资源被锁定或者或者不可用）。
所以这些所谓的“不稳定的客户端”系统将协调处理（以及从失败中恢复）责任委托给别
的“完全”（服务器端）TIP系统去执行。对于这些轻量级系统，只有TIP IDENTIFY, 
BEGIN,COMMIT, and ABORT指令是需要的，不需要处理日志。

2) 服务器端系统。即指那些提供上述支持，并且加入TIP处理协调和恢复服务的系统。
这些系统也可以提供入口给恢复资源（如相关数据库）。服务器端系统支持所有TIP指

令，以及提供一个可恢复处理日志。

一个TIP适应处理管理器（TM）也将提供应用编程接口（如X/Open TX接口[3]）以划分
TIP处理的界线，并且加入指令以产生TIP URL，推/拉（PUSH/PULL）TIP处理以及安置
当前TIP处理的上下文。利用现有的API和2-pc协议，能把TIP支持加入TM中，而且处理
可以既包含私有化的处理又包含TIP处理分支（这是假定现有的TM实现将提供用来在TIP
和其他处理协议间起协调作用的“TIP网关”设备）。

6.  X/Open DTP模型的关联

X/Open分布式事务处理（DTP）模型[4]定义了四种成分：1）应用编程（AP），2）处理
管理器（TM），3）资源管理器（RM），以及4）通信资源管理器（CRM）。在这个模型中，TIP
定义了一个TM到TM的互用性协议，这个协议是独立于应用通信之外的（X/Open中没有
这样相当的协议被阐明，X/Open中所有的处理和应用通信都发生在CRM（单管道模型）间）。
AP和TM/RM间的编程接口不会被TIP影响，但可以被其使用。从TM到RM的相互作用是通
过X/Open XA接口规范[5]来定义的。TIP是和XA相适应的。一个TIP处理可以包含一些访
问
多重RM的应用，这里XA接口被用来协调RM处理分支。

7.  TIP特定使用场景的实例

可以预期一个典型的internet上的TIP使用将包括一些使用代理模型的应用。在这个模型
中，客户端节点本身不完全直接包含在TIP协议中，也不需要一个本地TIP TM的服务。相
应代替的是一个代理应用控制了与客户端的对话，并对TIP处理的协调负责。这个代理操
作和别的服务提供者一起把服务传递给客户端。例如，作为一个旅行代理，其会在航空公
司/旅馆/等服务公司和顾客之间充当媒介。这个模型的一个很大的优点就是代理得到服务
提供者的信任，并且这样的代理数目上更少（和使用客户相比），所以安全和性能上的问
题被减少了。

考虑一个旅行代理处的例子。一个客户在一台连网个人电脑上运行一个网页浏览器以进入
这家旅行代理处的主页。通过代理处提供的主页（可以依次由航空公司和旅馆服务商提供
的主页创立），这个客户选定了一条包括所选航空公司和旅馆的路线。最后该客户点击“
进行预定”的按钮。这时，下列事件将按序发生（通过有用的标准或个性化技术（例如
CGI），用户写入的申请代码被不同的网络服务商调用）。

  1）首先，旅行代理处开始一个本地处理，并且为这个处理得到一个TIP URL（使用本地
     TM的API去执行所有这些函数。例如，“tip_xid_to_url()”将返回TIP URL给本地
     处理）。这个 TIP URL包含了本地TM的IP地址的监听端点和本地处理的处理校验符。

  2）然后，此旅行代理处的应用发一个请求给航空公司服务器（通过某种协议（如HTTP））
     通过请求“book_flight”服务来传递那个客户选定的航班和TIP URL（从上面1.中
     获得的）。

  3）这个请求被调用book_flight应用的航空公司服务器收到。此应用在输入数据中找回
     TIP URL，并把其传递给一个“tip_pull()”API以请求它的本地TM。这个tip_pull()                    
函数引起以下事件发生：
     a. 本地TM创建一个本地处理（将要被执行的工作在此之后），

     b. 如果一个TIP连接并不总是生存到上一级（旅行代理处）TM为止（正如通过在TIP 
        URL里传递的IP地址来定义的一样），一个连接被创建且一个IDENTIFY（识别）
        交换发生（如果多路技术被使用在这个连接上，接下来将是一个多路交换），

     c. 一个PULL指令被送到上一级TM，

     d. 作为PULL的响应，上一级TM和下一级（航空公司）TM通过处理建立联结（通过
结这个处理的连接），以及发送一个PULLED响应给下一级TM，

   e. 下一级TM返回控制给book_flight应用，book_flight现在正执行在新的已创建的
本地处理的上下文中。

   4) book_flight应用开始起作用（它可能包括至一个可恢复资源管理器（如一个RDBMS）
的入口，在这种情况下本地TM将和具有本地处理的RM建立联结（通过XA接口或者别的什
么））。
   
   5) book_flight应用返回给旅行代理应用指示成功。
 
   6) 接着，步骤2-5在旅馆服务器“book_room”应用上重复。在这些步骤结束后，上一      
级的TM已经登记了两个下一级的TM参与处理。一个是代理TM和航空公司和旅馆服务器                        
TM之间的TIP联系，另一个是航空公司和旅馆服务器上正在进行中的处理。[注意步骤2-5
和6能被同时执行。

   7) 旅行代理处应用发布一个“提交处理”请求（使用本地TM的API）。本地TM在TIP
连接上发送一个PREPARE指令给航空公司和旅馆的TM（此时这些TM被定义为次一级的      
理参与者）。

   8) 在航空公司和旅馆服务器上的TM执行必要的步骤以准备他们的本地可恢复资源（例      
如通过发布xa_prepare()请求）。如果成功的话，下一级的TM改变他们的TIP处理状                              
态为已准备，并将恢复信息（例如本地的和上一级的处理分支校验符，以及上一级TM                              
的IP地址）记入日志。然后这些下一级的TM发送PREPARED指令给上一级TM。

   9) 如果两个下一级TM都响应PREPARED，则上一级TM记录下处理已提交，以及恢复信
息(例如本地和下一级处理校验符，以及下一级TM的IP地址）。然后上一级TM在两个下      
一级TIP连接上发送COMMIT指令。

   10) 在航空公司和旅馆服务器上的TM执行必要的步骤来提交他们的本地可恢复资源（如       
通过发布xa_commit()请求）。下一级的TM废弃此处理。接着下一级的TM发送                            
COMITTED指令给上一级的TM。

   11) 上一级的TM废弃此处理。上下两级TM之间的TIP连接返回到闲置状态（断开和任
何处理的联结）。上一级的TM返回成功信息给旅行代理处的应用“提交处理”请求。

   12) 旅行代理处的应用返回“预定完成”给客户。

这个例子例证了PULL的使用。如果 PUSH被替代使用的话，上面的事件2）和3）将做如下
改变：

   2) 旅行代理处的应用：
 
      a. 将以上1）中获得的TIP URL和在航空公司服务器上TM的监听端点地址一起，通
         过一个“tip_push()”API请求，传递给它的本地TM。这个tip_pull()函数引
         起以下事件发生：

         i.如果一个TIP连接并不总是生存到下一级（航空公司服务器）TM为止（正如通           
过在tip_push()上传递的IP地址来定义的一样），一个连接被创建且一个                                                       
IDENTIFY（识别）交换发生（如果多路技术被使用在这个连接上，接下来将是                                 
一个多路交换），


         ii.一个 PUSH 指令被发送到下一级TM，
 
         iii.作为对PUSH的响应，下一级的TM创建了一个本地处理，将TIP连接和处理
             联结起来然后发送一个PUSHED响应给上一级的TM，
 
         iv.作为对PUSH的响应，上一级的TM通过处理和下一级TM联结，

         v.上一级的TM返回控制给旅行代理应用。

      b. 旅行代理应用发一个请求给航空公司服务器（通过某种协议（如HTTP）），通过
         请求“book_flight”服务来传递那个客户选定的航班和TIP URL（从上面1.中
         获得的）。

 
   3）这个请求被调用book_flight应用的航空公司服务器收到。此应用在输入数据中找      
回TIP URL，并把其传递给一个“tip_pull()”API以请求它的本地TM。因为这个本地TM
已经“看到”这个URL（其已经被传递），本地TM简单地返回book_flight应用，                  
book_flight现在正执行在先前创建的本地处理的上下文中。

[注意尽管这个例子中，处理协调者角色是由一个节点来扮演的，这个节点也参与了处理（旅