處理internet協議（TIP）-要求和補充信息

本備忘錄的狀態

本備忘錄提供了inte.net社區的一些信息，但并沒有詳細講述任何一種internet
標準。本備忘錄的發布不受任何限制。

版權聲明

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

摘要

本文檔描述了處理Internet協議（TIP）[1]的目的（特定使用場景）和要求。
其被有意用來幫助限定此協議的一些必要特征和功能。本文檔也提供了一些輔助
理解和幫助TIP協議實現的補充信息。

目錄
1.介紹 2
2.處理Internet協議(TIP) 3
3.范圍 4
4.TIP的預期使用 4
5.TIP的適應系統 4
6.X/OpenDTP模型的關聯 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-phasecommitprotocol）（2-pc）。2-pc
協議已經在商業事務處理（TP）系統中使用了很多年了，并且它也是很好理解的（例
如12年前就開始應用的LU6.22-pc（同步點）協議）。今天，大量不同的2-pc協議在許
多TP監控器和數據庫產品中被支持。在參與一個分布工作單元（處理）的各個組分之間，
2-pc被用來確保與工作結果相關的所有部分（忽略任何失敗的成分）一致。今天，標準的
和個性化的2-pc協議都存在。這些協議典型的使用了一個“單管道”模型。就是說處理和
應用協議是緊密結合的，是在同一個通信頻道上執行的。一個應用可能只使用和處理協議
聯結在一起的特定通信機制。具有比較龐雜的內容和寬泛的結構和管理要求的標準協議

（OSITP，LU6.2)是復雜的。因此它們沒有被廣泛配置。如果處理能被使用的話，那么所
有這些組成的網絡將具有有限的應用靈活性和互用性。應用就能有希望使用大量沒有處理
變量的通信協議（例如HTTP），并被配置在不同種類的應用環境中。

概括來說，處理很大程度上簡化了分布式應用的編程。2-pc協議是一種關鍵的處理技術。
目前運行在一具有特殊目的（復雜的，同類的）的底部結構中的2-pc協議只給一套有限
制的應用提供了處理語義。這個應用使用一套特定的雙向通信協議。所以，被當前的2-pc
協議強加的約束限制了處理范例的廣泛使用，因此也抑制了新的分布式商業應用的發展。

（見[2]以得到更多有關處理，原子數，以及二段提交協議的大概知識。）

2.處理Internet協議(TIP)

TIP是在一異類（網絡化的）環境中，用來提供普遍分布式處理支持的一種2-pc協議，
TIP消除了目前2-pc協議中的約束，使新的分布式商業應用成為可能。

為了達到這個目的，首先要滿足兩個關鍵要求：
1)Keeptheprotocolsimple(yetfunctionallysufficient).Ifthe
protocoliscomplexitwillnotbewidelydeployedorquickly
adopted.Simplicityalsomeanssuitabilitytoawiderangeof
applicationenvironments.

2)Enabletheprotocoltobeusedwithanyapplications
communicationsprotocol(e.g.HTTP).Thisensuresheterogeneous
environmentscanparticipateindistributedwork.
1)保持協議的簡單性（功能仍然充分）。如果這個協議是復雜的話，將不能被廣泛
配置或者很快采用。簡單性也意味著在一個很大范圍應用環境里的適用性。

2)能使協議和任何應用通信協議（如HTTP）一起使用。這一點確保異類環境能參與
分布式工作。

TIP不會將已知要假定廢棄的2-pc協議作為基礎來重新改造2-pc協議本身。TIP的更新穎、
更有效之處在于其脫離了應用通信協議（雙管道模型）。
+-------------+應用通信+-------------+
|應用程序|---------------------------|應用程序|
||"管道1"||
+-------------++-------------+
||
|TIPTMAPITIPTMAPI|
||
+-----------------+TIP2-pc協議+-----------------+
|TIP處理管理器|----------------------|TIP處理管理器|
||"管道2"||
+-----------------++-----------------+

圖1:TIP的雙管道本性

3.范圍

TIP不會去描述商業事務處理或者電子商務在internet上將怎樣被管理。它只講述2-pc
處理協議（一種對于這些應用發展的輔助）。例如，TIP不會提供一種非評判性的機制。
一旦對普通電子商務的要求變得更好理解，這樣的協議可以是隨后IETF的行為的一個主
題。TIP不會排除這些協議后來的定義。

TIP不會講述應用編程接口（API）（請留意本文檔（附錄A中）包含的一個例子TIPTM
API，以幫助理解）。

4.TIP的預期使用

正如以上所形容的，處理在簡化分布式應用編程中是一個非常有用的工具。所以，TIP可
以定位于任何包括分布式工作的應用中。這樣的應用可以包含執行在一個簡單系統中的
成分。這個簡單系統可以穿過一個企業內部網，穿過internet網或者任何別的分布式系

統結構。這個應用可以是“企業”級的（要求有很高的性能以及實用性），或者級別要求
不那么高的。人們有意使TIP變得能普遍適用的，以符合任何能從這處理語義規定中獲益
的應用之需要。

5.TIP的適應系統

有兩種級別的TIP適應處理管理系統

1)單一客戶端系統。這指那些只提供一個應用接口以劃分TIP處理的界線，但是沒有提供
給本地恢復資源入口的系統。這樣一個輕量級實現只對那些只有客戶端應用的系統才有用
（如桌面機器）。這樣的客戶端系統可能是不可靠的，而且作為處理的協調器也是不合適
的（它們的不適用性可能導致在別的參與處理的系統上的資源被鎖定或者或者不可用）。
所以這些所謂的“不穩定的客戶端”系統將協調處理（以及從失敗中恢復）責任委托給別
的“完全”（服務器端）TIP系統去執行。對于這些輕量級系統，只有TIPIDENTIFY,
BEGIN,COMMIT,andABORT指令是需要的，不需要處理日志。

2)服務器端系統。即指那些提供上述支持，并且加入TIP處理協調和恢復服務的系統。
這些系統也可以提供入口給恢復資源（如相關數據庫）。服務器端系統支持所有TIP指

令，以及提供一個可恢復處理日志。

一個TIP適應處理管理器（TM）也將提供應用編程接口（如X/OpenTX接口[3]）以劃分
TIP處理的界線，并且加入指令以產生TIPURL，推/拉（PUSH/PULL）TIP處理以及安置
當前TIP處理的上下文。利用現有的API和2-pc協議，能把TIP支持加入TM中，而且處理
可以既包含私有化的處理又包含TIP處理分支（這是假定現有的TM實現將提供用來在TIP
和其他處理協議間起協調作用的“TIP網關”設備）。

6.X/OpenDTP模型的關聯

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/OpenXA接口規范[5]來定義的。TIP是和XA相適應的。一個TIP處理可以包含一些訪
問
多重RM的應用，這里XA接口被用來協調RM處理分支。

7.TIP特定使用場景的實例

可以預期一個典型的internet上的TIP使用將包括一些使用代理模型的應用。在這個模型
中，客戶端節點本身不完全直接包含在TIP協議中，也不需要一個本地TIPTM的服務。相
應代替的是一個代理應用控制了與客戶端的對話，并對TIP處理的協調負責。這個代理操
作和別的服務提供者一起把服務傳遞給客戶端。例如，作為一個旅行代理，其會在航空公
司/旅館/等服務公司和顧客之間充當媒介。這個模型的一個很大的優點就是代理得到服務
提供者的信任，并且這樣的代理數目上更少（和使用客戶相比），所以安全和性能上的問
題被減少了。

考慮一個旅行代理處的例子。一個客戶在一臺連網個人電腦上運行一個網頁瀏覽器以進入
這家旅行代理處的主頁。通過代理處提供的主頁（可以依次由航空公司和旅館服務商提供
的主頁創立），這個客戶選定了一條包括所選航空公司和旅館的路線。最后該客戶點擊“
進行預定”的按鈕。這時，下列事件將按序發生（通過有用的標準或個性化技術（例如
CGI），用戶寫入的申請代碼被不同的網絡服務商調用）。

1）首先，旅行代理處開始一個本地處理，并且為這個處理得到一個TIPURL（使用本地
TM的API去執行所有這些函數。例如，“tip_xid_to_url()”將返回TIPURL給本地
處理）。這個TIPURL包含了本地TM的IP地址的監聽端點和本地處理的處理校驗符。

2）然后，此旅行代理處的應用發一個請求給航空公司服務器（通過某種協議（如HTTP））
通過請求“book_flight”服務來傳遞那個客戶選定的航班和TIPURL（從上面1.中
獲得的）。

3）這個請求被調用book_flight應用的航空公司服務器收到。此應用在輸入數據中找回
TIPURL，并把其傳遞給一個“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）中獲得的TIPURL和在航空公司服務器上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”服務來傳遞那個客戶選定的航班和TIPURL（從上面1.中
獲得的）。


3）這個請求被調用book_flight應用的航空公司服務器收到。此應用在輸入數據中找
回TIPURL，并把其傳遞給一個“tip_pull()”API以請求它的本地TM。因為這個本地TM
已經“看到”這個URL（其已經被傳遞），本地TM簡單地返回book_flight應用，
book_flight現在正執行在先前創建的本地處理的上下文中。

[注意盡管這個例子中，處理協調者角色是由一個節點來扮演的，這個節點也參與了處理（旅
行代理處），但是別的結構也是可能的（如由一個非參與處理的第三方節點來扮演處理協調
者角色。]

8.TIP處理的恢復

直到處理達到已準備狀態，處理中的任何失敗的結果將被廢棄。一旦處理已經達到已準備狀
態，假設此時一個錯誤發生，那么處理恢復必須被執行。對于上下兩級TM來說，恢復行為
是不同的，其細節取決于處理（已提交或已廢棄）的結果以及失敗發生的確切位置。例如在
旅行代理處的應用，如果其到旅館服務器的連接在旅館服務器收到COMMIT指令之前
失敗，那么（一旦連接被恢復）：

1)上一級（旅行代理處）TM發送一個RECONNECT指令（傳遞下一級處理校驗符（如果
必須的話可以從處理中重新獲得））。

2)下一級（旅館）TM響應RECONNECTED（因為它從未收到COMMIT指令，仍然使處理為
已準備態（假如在下一級TM響應COMMITTED之后失敗發生，那么下一級的TM將已經忽略此
處理，并且對RECONNECT指令響應為NOTRECONNECTED））。

3)上一級TM發送一個COMMIT指令，下一級TM提交此處理并響應為COMMITTED。處理
現在已經被解析。

4)如果下一級TM在收到一個RECONNECT指令之前恢復和上一級TM的連接，那么它可能
發送一個QUERY指令。這樣的話，上一級TM將響應QUERIEDEXISTS，且下一級TM將等待上
一級發送RECONNECT指令。如果此處理已被廢棄的話，那么上一級TM可能響應
QUERIEDNOTFOUND，這樣，下一級TM將廢棄此處理（注意上一級TM沒有被迫為一個已廢棄
的處理發送一個RECONNECT指令（也就是說，上一級TM能在發出ABORT指令后和在收到一
個ABORTED響應之前就廢棄這個處理））。

如果客戶應用（調用“提交”的應用）處在失敗的環境中，將可能不會收到顯示處理最
終結果的響應（即使這個處理本身已經被成功完成了）。這是一個普遍問題，并不是TIP
所特有的。在這樣的環境中，直到查明處理的最終結果，應用才會終止（一個TIPTM可
以通過提供一些特殊機制的實現來使其更便利，如把結果寫入一個用戶日志）。

9.TIP處理和應用信息連續

一個聯系存在于TIP指令和應用信息之間：直到確定所有的參與者已經適當注冊并且已
經完成此處理之前的工作之后，一個TIP處理才能被提交。因為TIP的雙管道本性，這個
操作不是必要地要被TIP系統本身所強化（盡管在某些實現中是可能的）。所以使操作
正常是這個應用所擔負的責任。通常來說，一個應用不能：

1)當它還有任何和處理聯結在一起的請求仍然待處理時，調用它本地TM的“commit”
函數。

2)對從一參與應用來的一個事務處理請求產生確定響應。這個應用和處理一起預先登
記了它的本地TM。

10.TIP協議和本地操作

為了確保處理原子數能被恰當地保證，一個系統實現TIP就必須在協議交換里的某一點執
行一些別的本地操作。這些操作適合于創建和刪除“日志記錄”處理（失敗中幸存的必要
信息，可以確保處理恢復的正確運行）。下列關于TIP協議和日志記載事件之間聯系的信
息只是起參考作用，并非是定論（見[2]以獲得更多主題相關討論）。

1)在發送一個PREPARED響應之前，系統應該為處理創建一個準備好的恢復記錄。

2)如果已經創建了一個準備好的恢復記錄，則這個記錄不應該被刪除，除非：
a.收到一個ABORT信息；或者
b.收到一個COMMIT信息；或者
c.收到一個QUERIEDNOTFOUND響應。

3)如果一個準備好的恢復記錄存在的話，系統不應該發送一個COMMITTED或
NOTRECONNECTED信息。

4)在為處理創建一個提交恢復記錄之前，系統應該已經收到一個PREPARED響應。

5)處在已準備狀態的系統在發送一個COMMIT之前，應該已經為處理創建了一個提交恢
復記錄。

6)如果已經創建了一個提交恢復記錄，則這個記錄不應該被刪除，除非：
a.收到一個COMMITTED信息；或者
b.收到一個NOTRECONNECTED信息。

11.安全考慮

這種被應用用來通信和執行分布式工作的方法超出了TIP協議的范圍。這種在一個特定系
統上用做客戶的鑒定和授權以獲取節目和信息的機制，是應用通信協議和應用運行基層構
造的一部分。使用TIP協議不會影響這些考慮。

因為系統要求保護自己免遭未經授權的TIP指令或者一個可信任的參與TIPTM的模仿者的
干擾，所以安全是和TIP協議自身相關的?；蛟S最糟糕的后果就是可能的無法探測的矛盾數
據導致妨礙了TIP協議的義務（例如，在一個TIP連接的ABORT指令位置注入了一個COMMIT
指令）。TIP采用傳輸層安全協議（TLS）[6]來限制僅僅被信任的參與者能夠進入（即控制
從這些遠處端點來的TIP處理將被接受，并且驗證這些端點是否真實可信），并把TIP指令
譯成密碼。TLS的使用（或者不使用）是這些TIPTM參與者之間協定的。見[1]以得到更多
TIP使用TLS的細節。

TIPTM實現也可以提供本地化方法以得到間隔時間以及廢棄那些沒有在某些特定時間內完
成的處理（因此可以阻止由于有害內容引起的資源不可利用）。處理間隔時間也能作為一
種解決僵局的方法。

12.TIP要求

大多數的這些要求起源于最初把處理發展成一個無所不在的系統服務目的，能使所有的級
別的應用能使用它（正如TCP被假定為能到處使用）。通常這需要加入盡可能少的一些關于
TIP使用的限制（為了能使用處理，應用不應該被要求運行在某個“特殊”環境中），并且
保持協議簡單高效。這樣能讓TIP在很多系統（運行起來很廉價）上得到廣泛的實現（運作
起來很廉價）。

1)應用通信協議獨立

為了允許TIP能使用在和任何應用協議的聯結中，TIP協議必須獨立定義于用作轉錄應用數
據的通信協議之外。TIP協議必須可以使應用能使用任意的通信協議開始，結束，以及傳播
TIP處理。

這意味著TIP協議施用了一個2-管道操作模型。這個模型要求分隔應用通信和處理協調為
兩個離散的通信頻道（管道）。這個分隔使處理協調協議（TIP）可以和任何應用通信協議
（如HTTP,ODBC,無格式的TCP/UDP,等等）一起使用。

2)支持處理語義

TIP協議必須提供事實上標準的、假定廢棄的2-pc協議功能來保證甚至在失敗事件中的處
理原子數。TIP應該就象提供提交和恢復函數一樣來提供一種建造處理樹的方法。

3)應用處理傳播和互用

為了能夠推動協議的獨立性，應用的互用性，以及提供一種傳播TIP處理上下文的方法，
一種TIP處理上下文信息的標準表達方式是需要的（以一個URL的形式）。這個信息必須
包括TIPTM參與者的監聽端點地址以及處理校驗符信息。

4)易于實現

TIP協議必須能夠簡單地實現。它應該只支持那些具有能提供必需的一個有用的，可執行
的2-pc協議特征的服務。此協議不應該以額外的優化來增加復雜性。

5)適用于所有級別的應用

TIP協議應該是足夠完整和強壯的，這不僅僅是因為internet網上的電子商務的需要，還
由于企業內部網和傳統的跨越異種處理管理器環境的TP應用的需要。這個協議應該是可執
行的和有足夠等級范圍的以符合能力從低到高的應用需求。

a.TIP協議應該支持單客戶端處理參與者的概念（用做在低端平臺上超輕量級的實現）。

b.既然一些客戶端是不可靠的，那么TIP必須提供對授權處理協調的支持（一個更可靠
（可信任的）的節點）。

c.TIP協議必須在每個TCP連接上將1到n（>1）個并發處理分級。

d.TIP指令應該能被連接（可管道連接的）。

e.TIP應該和X/OpenXA接口相適應。

6)安全

TIP協議必須和現有的安全機制相適應，隱含加密，防火墻以及鑒別機制（如TLS可以用來
鑒別一個TIP指令的發送人，還可以用來給TIP指令加密）。協議定義沒有任何東西可以阻
止TIP工作在任何安全環境中。


7)TIP協議傳輸獨立

對于某些應用來說，允許TIP協議穿越不同的傳輸協議是有益的。益處在于當在為應用數
據使用不同的傳輸協議時，TIP2-pc協議能采用同樣的傳輸。所以TIP不必排除別的傳輸
協議的使用。

8)恢復

恢復語義需要充分定義以避免任何類型通信傳輸失敗事件中的模糊結果。

9)可擴展性

TIP協議應該能夠被擴展，同時保持和先前版本的兼容。

參考

[1]Lyon,J.,Evans,K.,andJ.Klein,"TheTransactionInternet
ProtocolVersion3.0",RFC2371,July1998.

[2]TransactionProcessing:ConceptsandTechniques.Morgan
KaufmannPublishers.(ISBN1-55860-190-2).J.Gray,A.Reuter.

[3]X/OpenCAESpecification,April1995,DistributedTransaction
Processing:TheTXSpecification.(ISBN1-85912-094-6).

[4]X/OpenGuide,November1993,DistributedTransactionProcessing:
ReferenceModelVersion2.(ISBN1-85912-019-9).

[5]X/OpenCAESpecification,December1991,DistributedTransaction
Processing:TheXASpecification.(ISBN1-872630-24-3).

[6]Dierks,T.,et.al.,"TheTLSProtocolVersion1.0",Workin
Progress.

作者的地址

KeithEvans
TandemComputersInc,LOC252-30
5425StevensCreekBlvd
SantaClara,CA95051-7200,USA

Phone:+1(408)2855314
Fax:+1(408)2855245
EMail:Keith.Evans@Tandem.Com


JohannesKlein
TandemComputersInc.
10555RidgeviewCourt
Cupertino,CA95014-0789,USA

Phone:+1(408)2850453
Fax:+1(408)2859818
EMail:Johannes.Klein@Tandem.Com


JimLyon
MicrosoftCorporation
OneMicrosoftWay
Redmond,WA98052-6399,USA

Phone:+1(206)9360867
Fax:+1(206)9367329
EMail:JimLyon@Microsoft.Com

評論

請將有關本文檔的評論發到作者的信箱<JimLyon@Microsoft.Com>,
<Keith.Evans@Tandem.Com>,<Johannes.Klein@Tandem.Com>,或者發到TIP郵件組
<Tip@Tandem.Com>。你可以通過發mail給<Listserv@Lists.Tandem.Com>來訂閱TIP
郵件組，此mail內容中的某一行要注明"subscribetip<fullname>"。

附錄A.一個TIP處理管理器API的實例

注意這個API是為了報告情況而被單獨加入本文檔，不是正式TIP的規范的一部分（用TIP
一致實現來定義可選擇的API是不受限制的）。

1)tip_open()-建立一個到一個TIPTM的連接

概要
inttip_open([out]tip_handle_t*ptiptm)

參數
ptiptm[out]
到這個TIPTM句柄的指針

形容
tip_open()建立了一個到一個TIPTM的連接。這個調用返回了一個鑒別此TIPTM的句
柄。這個函數必須在任何工作被執行于一個TIP處理上之前被調用。

返回值
[TIPOK]
連接已被成功建立。
[TIPNOTCONNECTED]
使用者已經被TIPTM斷開。
[TIPNOTCONFIGURED]
TIPTM還沒有被配置。
[TIPTRANSIENT]
太多的開始者，重試開始。
[TIPERROR]
一個不期望的錯誤發生。

2)tip_close()-斷開一個到一個TIPTM的連接

概要
inttip_close([in]tip_handle_thandle)

參數
handle[in]
此TIPTM的句柄

形容
tip_close()斷開一個到一個TIPTM的連接。所有和那個連接聯結的待處理要求都被
取消。

返回值
[TIPOK]

連接已被成功斷開。
[TIPINVALIDPARM]
無效的連接句柄指定。
[TIPERROR]
一個不期望的錯誤發生。

3)tip_push()-輸出一個本地處理到一個遠端節點并返回一個TIP處理校驗符給已聯合
的遠處處理。

概要
inttip_push([in]tip_handle_tTM,
[in]char*tm_url,
[in]void*plocal_xid,
[out]char*pxid_url,
[in]unsignedinturl_length)

參數
TM[in]
此TIPTM的句柄
tm_url[in]
到遠處處理管理器TIPURL的指針。一個處理管理器的TIPURL采用格式：
TIP://<主機>[:<端口>]
plocal_xid[in]
到本地處理校驗符的指針。處理校驗符的結構是由本地處理管理器來定義的。
pxid_url[out]
到聯結遠處處理TIPURL的指針。一個處理的TIPURL采用格式：
TIP://<主機>[:<端口>]/<處理標識符>
url_length[in]
遠處處理URL緩存的字節大小

形容
tip_push()輸出（推）一個本地處理到遠端節點。如果一個遠處處理校驗符沒有
被提供，則調用者的當前處理上下文被使用。這個調用返回一個TIPURL給已聯結
的遠處處理。這個TIP處理校驗符可能在應用請求上被傳遞到遠處節點（作為一個
TIPURL的一部分）。為了代表此處理的利益起作用，接收的進程使用這個信息。

返回值
[TIPOK]
處理已被成功地推到遠處節點。
[TIPINVALIDXID]
一個無效的處理校驗符已經被提供。
[TIPNOCURRENTTX]
當前進程沒有和一個處理相聯結。
[TIPINVALIDHANDLE]
無效的連接句柄指定。
[TIPNOTPUSHED]
處理不能被推到遠處節點。
[TIPNOTCONNECTED]
調用者已經失去與TIPTM的連接。
[TIPINVALIDURL]
無效的端點URL被提供。
[TIPTRANSIENT]
短暫的錯誤發生，重試操作。
[TIPTRUNCATED]
TIP處理校驗符的不足緩沖尺寸被指定。
[TIPERROR]
一個不期望的錯誤發生。

4)tip_pull()-創建一個本地處理并將它與TIP處理連接起來。

概要
inttip_pull([in]tip_handle_tTM,
[in]char*pxid_url,
[out]void*plocal_xid,
[in]unsignedintxid_length)

參數
TM[in]
此TIPTM的句柄。
pxid_url[in]
到聯結遠處處理TIPURL的指針。一個處理的TIPURL采用格式：
TIP://<主機>[:<端口>]/<處理校驗符>
plocal_xid[out]
到本地處理校驗符的指針。處理校驗符的結構是由本地處理管理器來定義的。
xid_length[in]
本地處理標識符緩存的字節大小。

形容
tip_pull()創建了一個本地處理并將本地處理和TIP處理連接起來（在此TIP處理中
調用者成為次一級的參與者）。遠處的TIPTM通過URL(*pxid_url)來識別。這個本
地處理的校驗符被返回。如果一個本地處理已經為了已提供的TIP處理校驗符而創建，
那么[TIPOK]被返回（和本地處理校驗符一起），并且沒有別的操作被執行。

返回值
[TIPOK]
本地處理已經被成功創建，且已和TIP處理連接。
[TIPINVALIDHANDLE]
無效的連接句柄指定。
[TIPTRUNCATED]
本地處理校驗符的不足緩沖尺寸被指定。
[TIPNOTPULLED]
本地處理和TIP處理之間的連接已失敗。
[TIPNOTCONNECTED]
調用者已經失去與TIPTM的連接。
[TIPINVALIDURL]
無效的端點URL被提供。
[TIPTRANSIENT]
短暫的錯誤發生，重試操作。
[TIPERROR]
一個不期望的錯誤發生。

5)tip_pull_async()-創建了一個本地處理并將本地處理和TIP處理連接起來.一個本
地處理一被創建，控制就被返回到調用者。

概要
inttip_pull_async([in]tip_handle_tTM
[in]char*pxid_url,
[out]void*plocal_xid,
[in]unsignedintxid_length)

參數
TM[in]
TIP網關句柄
pxid_url[in]
到聯結遠處處理TIPURL的指針。一個處理的TIPURL采用格式：
TIP://<主機>[:<端口>]/<處理校驗符>
plocal_xid[out]
到本地處理校驗符的指針。處理校驗符的結構是由本地處理管理器來定義的。
xid_length[in]
本地處理標識符緩存的字節大小。

形容
tip_pull()創建了一個本地處理并將本地處理和TIP處理連接起來（在此TIP處理中
調用者成為下一級的參與者）。遠處的TIPTM通過URL(*pxid_url)來校驗。這個本
地處理的校驗符被返回。在此本地處理已經被創建（在TIPPULL協議指令發送之前）
之后，一個對tip_pull_async()的調用立即返回。一個后來的對tip_pull_complete()
的調用必須得到發布，用來檢查PULL請求的完成成功與否。

返回值
[TIPOK]
本地處理已被成功創建。
[TIPINVALIDHANDLE]
無效的連接句柄指定。
[TIPNOTCONNECTED]
使用者已經失去與TIPTM的連接。
[TIPINVALIDURL]
無效的端點URL被提供。
[TIPTRANSIENT]
短暫的錯誤發生，重試操作。
[TIPTRUNCATED]
本地處理校驗符的不足緩沖尺寸被指定。
[TIPERROR]
一個不期望的錯誤發生。

6)tip_pull_complete()-檢查一個先前的tip_pull_async()請求是否已被成功完成。

概要
inttip_pull_complete([in]tip_handle_tTM,
[in]void*plocal_xid)
參數
TM[in]
此TIPTM的句柄。
plocal_xid[in]
到本地處理校驗符的指針。處理校驗符的結構是由本地處理管理器來定義的。

形容
tip_pull_complete()檢查一個先前的對tip_pull_async()調用是否已被成功完成。
即是否本地處理已經成功地和TIP處理連接在一起。調用者提供由先前對
tip_pull_async()的調用返回的本地處理校驗符。對同一個本地處理校驗符的
tip_pull_complete()的重復調用是等冪的。

返回值
[TIPOK]
本地處理已成功地和TIP處理連接。
[TIPINVALIDHANDLE]
無效的連接句柄指定。
[TIPINVALIDXID]
一個無效的處理校驗符已經被提供。
[TIPNOTPULLED]
和TIP處理相連接的本地處理已經失敗。本地處理已經被廢棄。
[TIPNOTCONNECTED]
調用者已經失去與TIPTM的連接。
[TIPERROR]
一個不期望的錯誤發生。

7)tip_xid_to_url()-返回一個TIP處理校驗符作為一個本地校驗標識符。

概要
inttip_xid_to_url([in]tip_handle_tTM,
[in]void*plocal_xid,
[out]char*pxid_url,
[in]unsignedinturl_length)

參數
TM[in]
此TIPTM的句柄。
plocal_xid[in]
到本地處理校驗符的指針。處理校驗符的結構是由本地處理管理器來定義的。
pxid_url[out]
到本地處理TIPURL的指針。一個處理的TIPURL采用格式：
TIP://<主機>[:<端口>]/<處理標識符>
url_length[in]
TIPURL緩存的字節大小。

形容
tip_xid_to_url()返回一個TIP處理校驗符作為一個本地處理校驗符。這個TIP處理
校驗符能被傳遞到遠處應用來使它們在處理上起作用。例如，拉本地處理到此遠處節
點。如果一個本地處理校驗符沒有被提供，那么調用者當前的處理上下文被使用。常
數TIPURLSIZE定義了一個TIP處理校驗符的字節大小。這個值是實現的細節。

返回值
[TIPOK]
TIP處理標識符已被返回。
[TIPNOTCONNECTED]
調用者已經失去與TIPTM的連接。
[TIPNOCURRENTTX]
當前的進程沒有和一個處理（且一個都沒有被提供）相聯結。
[TIPINVALIDXID]
一個無效本地處理校驗符已被提供。
[TIPTRUNCATED]
TIP處理校驗符的不足緩沖尺寸被指定。
[TIPERROR]
一個不期望的錯誤發生。

8)tip_url_to_xid()-返回一個本地處理校驗符作為一個TIP處理校驗符。

概要
inttip_url_to_xid([in]tip_handle_tTM,
[in]char*pxid_url,
[out]void*plocal_xid,
[in]unsignedintxid_length)
參數
TM[in]
此TIPTM的句柄。
pxid_url[in]
到本地處理TIPURL的指針。一個處理的TIPURL采用格式：
TIP://<主機>[:<端口>]/<處理標識符>
plocal_url[out]
到本地處理校驗符的指針。處理校驗符的結構是由本地處理管理器來定義的。
xid_length[in]
本地處理校驗符緩存的字節大小。

形容
tip_url_to_xid()返回一個本地處理校驗符作為一個TIP處理校驗符（注意本地處理
必須先前已通過一個tip_push()，或者tip_pull()(或者tip_pull_async())創建。
常數TIPXIDSIZE定義了一個TIP處理校驗符的字節大小。這個值是實現的細節。

返回值
[TIPOK]
TIP處理校驗符已被返回。
[TIPINVALIDURL]
一個無效TIP處理校驗符已被提供。
[TIPTRUNCATED]
本地處理校驗符的不足緩沖尺寸被指定。
[TIPERROR]
一個不期望的錯誤發生。
9)tip_get_tm_url()-以TIPURL的格式得到本地TIP處理管理器的名字。
概要
inttip_get_tm_url([in]tip_handle_tTM,
[out]char*tm_url,
[in]inttm_len);
參數
TM[in]
此TIPTM句柄。
tm_url[in]
到本地處理管理器TIPURL的指針。一個處理管理器的TIPURL采用格式：
TIP://<主機>[:<端口>]
tm_len[out]
本地處理管理器TIPURL緩存的字節大小。

形容
tip_get_tm_url()以TIPURL的格式得到本地TIP處理管理器的名字（即
TIP://<主機>[:<端口>]）。

返回值
[TIPOK]
本地處理管理器的名字已被成功返回。
[TIPTRUNCATED]
由于緩沖尺寸不足，本地處理管理器的名字已被截短。用更大的緩沖尺寸去重
試操作。

版權聲明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.