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 Status of this Memo このドキュメントは、インターネット社会の為のインターネット標準トラッ クプロトコルを規定しており、改善の為の議論と提案を求めている。この プロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配 布は制限されない。 Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract 異なるノードが幾つかの作業を協調する多くのアプリケーションでは、作 業が原子的に起こることを保証する必要性がある。すなわち、各ノードは たとえ障害に直面しても、作業が完了したか否かについて同じ結論に達し なければならない。このドキュメントは、簡易な、この完了を容易に実装 できるプロトコルを提案する。 Table of Contents 1. 導入 2. 利用例 3. トランザクション 4. コネクション 5. トランザクション識別子 6. プッシュ vs. プルトランザクション 7. TIP トランザクションマネージャー識別とコネクション確立 8. TIP ユニフォーム資源位置子 9. コネクションの状態 10. プロトコルバージョン 11. コマンドと応答 12. コマンドパイプライン 13. TIP コマンド 14. エラー処理 15. コネクション障害とリカバリ 16. セキュリティの考慮 17. 参照 18. 作者のアドレス 19. コメント 付録 A. TIP 多重化プロトコルバージョン 2.0 完全なコピーライト宣言 1. 導入 原子的コミットメントを達成するための標準的な方法は、2 フェーズコミッ トプロトコルである。原子的コミットメントと 2 フェーズコミットプロト コルについては [1] を参照されたい。 多数の 2 フェーズコミットプロトコルが、数年にわたって実装され続けて いる。しかし、主に複雑であるが故に、それらのどれもインターネットで 広く使用されていない。その複雑性の大半は、2 フェーズコミットプロト コルが、特定のプログラムツープログラム通信プロトコルと一緒にまとめ られ、そのプロトコルが非常に大規模な基盤の頂上に存在するという事実 から来る。 このメモは、非常に簡易な 2 フェーズコミットプロトコルを提案する。異 なるノードがトランザクションの結果にどのように同意するかだけを規定 することによって、その簡易性を達成する。どのノードが同意しているか という主要点は、他のプロトコルを経て通信されることを可能にする (要 求もする)。そうすることによって、アプリケーション通信セマンティクス とデータ表現 (2, 3 個命名するだけ) に関する全ての問題を避ける。アプ リケーション通信プロトコルに依存せず、トランザクションマネージャー は他のトランザクションマネージャーと暗号メッセージを認証するために、 トランスポート層セキュリティプロトコル [3] を使用してもよい。 このプロトコルは、あるインターネットノード上のトランザクションマネ ージャーが、別のノード上のトランザクションマネージャーと通信するた めに主に使用されるだろうと予測される。アプリケーションプログラムと 資源マネージャーが、トランザクションマネージャーに話し掛けるために このプロトコルを使用できるが、この通信は大抵イントラノードであり、 大半のトランザクションマネージャーは既にそのタスクに対する十分過ぎ るインタフェースを持っている。 このプロトコルが既存のものを置き換えることは期待しないが、多くの既 存の混成トランザクションマネージャーがお互いに通信するためにこのプ ロトコルを実装することが、比較的に容易であることは期待する。 TIP プロトコルに関連する補足情報については、[5] で見ることができる。 2. 利用例 今日、電子買い物かごは多くの電子店舗において共通的な比喩である。消 費者は電子カタログに目を通し、商品を選択し、それを電子買い物かごに 入れる。HTTP サーバ [2] は、クライアントコンテキスト (例えば消費者 の買い物かご) の足跡を保持し、後続の消費者要求を再開するために、URL 符号化からコンテキストクッキーにわたる様々な手段を提供する。 一旦消費者が買い物を終了したら、それらの選択をコミットし、交わした 注文を確認する決定を下すかもしれない。大半の注文は、同じ買い物トラ ンザクションの一部として実行されることを除いて、お互いに関係を持た ない。あるいは、お互いに依存しているかもしれない (例えば、特殊な注 文の一部として行われたならば)。これらの詳細にも関わらず、消費者は全 ての注文が信頼のある確認レシートに正常に記入されることを期待するだ ろう今日の電子店舗は、そのような全ての注文の受領を調整するために、 独自の特別なプロトコルを実装しなければならない。このプログラミング は、注文が複数の電子店舗を通じて受領される場合特に複雑である。この 複雑性は、インターネットアプリケーションの潜在的な利便性を制限し、 成長の制約となる。このドキュメントで規定されるプロトコルは、インタ ーネットサーバが共有作業 (電子買い物かご中の注文の受領) の単位にお いて、合意を達成するための標準を提供することを意図している。注文を 受領するサーバ (例えば CGI プログラム) は、ローカルのトランザクショ ンマネージャーを呼んでトランザクションを開始し、その作業に参加して いる他のサーバにそのトランザクションへの加入を求めたいかもしれない。 注文を受領するサーバは、HTTP 要求のユーザデータとしてトランザクショ ンへの参照を、他のサーバに渡す。他のサーバは、ローカルトランザクショ ンを開始するためにトランザクションマネージャを呼び、このドキュメン トで定義されたプロトコルを使用しているトランザクションに加わること を求める。一旦全ての注文が受領されたら、2 フェーズコミットプロトコ ルの実行が、関わりのあるトランザクションマネージャーに委任される。 もしトランザクションがコミットしたら全ての注文が正常に受領され、消 費者は信頼のある確認を得る。もしトランザクションがアボートしたら、 どの注文も受領されず、消費者はその問題を通知されるだろう。 例外処理と障害回復が特別なコンポーネントに委任されるので、トランザ クションはこれらのアプリケーションの非常に簡素なプログラミングをサ ポートする。さらに、エンドユーザは部分的な成功のみの結果を取り扱う 必要はない。この例は、HTTP サーバがどのようにプロトコルを使用できる かを示すが、アプリケーションは遠隔データベースにアクセスする (例え ば ODBC 経由) 時や、他の既存のプロトコル (例えば RPC) を使用する遠 隔サービスを呼び出す際にこのプロトコルを使用してもよい。プロトコル は、混成のネットワークにあるアプリケーションが、たとえ異なる通信プ ロトコルを使用していても、同じトランザクションに参加することを容易 にする。 3. トランザクション "トランザクション" は、実行されるコンピュータの作業が原始的なセマン ティクスを持つプログラミングモデルに与えられた用語である。すなわち、 全ての作業が正常に完了し永久的な更新となる (トランザクションコミッ ト) か、もしいずれかの作業が失敗したら更新されない (トランザクショ ンアボート)。トランザクション (作業の単位) を構成する作業は、アプリ ケーションによって定義される。 4. コネクション トランザクションインターネットプロトコル (TIP) は、低いコネクション 設定コストの、順番を信頼できるストリームトランスポートを必要とする。 インターネット (IP) 環境では TIP は TCP 上で動作し、オプションで、 安全で認証されたコネクションを提供するために TLS を使用する。またオ プションで、同じ TCP か TLS コネクション上で軽量コネクションを多重 化するためのプロトコルを使用する。 トランザクションを共有するトランザクションマネージャーは、TCP コネ クション (オプションで TLS) を確立する。プロトコルは、2 つのトラン ザクションマネージャー間で共有された各々の同時トランザクションのた めに、異なるコネクションを使用する。トランザクションが終了した後、 そのコネクションは異なるトランザクションで再使用できる。 オプションで、一つのトランザクションのみに TCP か TLS を割り当てる 代わりに、2 つのトランザクションマネードャは同じ TCP か TLS コネク ション上で、軽量コネクションを多重化するプロトコルに同意し、各々の 同時トランザクションを別々の軽量コネクションに割り当ててもよい。軽 量コネクションの使用は、冗長性と同時トランザクションの実行に割り当 てられた資源消費を減らす。ここに記述されたものと同様の技術は、既存 のトランザクション処理システムで広く使用されている。そうしたプロト コルの一つにの例として、付録 A を参照されたい。 TIP プロトコル自身は TCP と TLS の言葉で規定されているが、他のトラ ンスポートプロトコルでの TIP の使用を除外するわけではないことに注意 されたい。しかし、選択されたトランザクションが TCP と同等の意味を提 供し、TIP プロトコルを適切にマッピングすることを保証することは、実 装者の範疇である。 このドキュメントでは、"コネクション" または "TCP コネクション" とい う用語は TIP TCP コネクション、TIP TLS コネクション、あるいは TIP 多重コネクション (TCP か TLS 上の) のことを言う。各々のケースで振る 舞いは同じであり相違は生まれない。コネクションのタイプ間の振る舞い には相違があるが、これらは明示的に言及される。 5. トランザクション識別子 不幸にも、トランザクションと識別子の形式についてグローバルに受諾さ れた標準が全く無く、様々な標準や専用形式がある。TIP トランザクショ ン識別子で許された形式は、以下の "TIP ユニフォーム資源位置子" のセ クションに規定されている。トランザクションマネージャーは、適切な方 法でその内部トランザクションに識別子をこの TIP 形式にマッピングする。 さらに、スーペリア/サブオーディネートの関係におけるグループはトラン ザクションに自身の識別子を割り当て、これらの識別子は関係が最初に確 立される時に交換される。従って、トランザクションマネージャーはトラ ンザクション識別子の自分自身の形式を内部的に使用する。しかし、関与 している各々のスーペリア/サブオーディネートの関係に対して、相手のト ランザクション識別子を覚えておかなければならない。 6. プッシュ vs. プルトランザクション ノード "A" 上のあるプログラムがトランザクションを生成し、ノード "B" 上のあるプログラムにトランザクションの一部の作業を行うことを望むと 仮定する。これを行うために二つの古典的な方法がある。"プッシュ" モデ ルと "プル" モデルと呼ばれるものである。 "プッシュ" モデルでは、A 上のプログラムは自分のトランザクションマネ ージャーに、ノード B にそのトランザクションのエクスポートすることを 最初に依頼する。A のトランザクションマネージャーは B の TM にメッセ ージを送信し、A のサブオーディネートとしてトランザクションを実体化 することを依頼し、そのトランザクションの名前を返却する。そして、A 上のプログラムは B 上の対応者にメッセージを送信し、"作業を実行し、 そちらのトランザクションマネージャーが既に名前を知っているトランザ クションに参加してほしい ..." 旨の指示を命ずる。A の TM はトランザ クションを B の TM に送信したことを知っているので、A の TM は B の TM が 2 フェーズコミット処理に入ることを知る。 "プル" モデルでは、A 上のプログラムは "作業を実行し、そちらのトラン ザクションマネージャーが既に名前を知っているトランザクションに参加 してほしい ..." 旨の指示を命ずるメッセージを B に単に送信するだけで ある。B 上のプログラムは、自分の TM にトランザクションへの参加を依 頼する。その時、B の TM は A からトランザクションを "取り込む" だろ う。この取り込みの結果、A の TM は B の TM が 2 フェーズコミット処 理に入ることを知る。 ここで規定されたプロトコルは、"プッシュ" と "プル" モデルの両方をサ ポートする。 7. TIP トランザクションマネージャー識別とコネクション確立 TIP トランザクションマネージャーが接続するために、お互いを識別し、 所在を突き止められなければならない。これを行うために必要な情報は、 TIP トランザクションマネージャーアドレスによって示される。 [この規約は、TIP トランザクションマネージャーが最初に獲得するトラン ザクションマネージャーアドレス (恐らく幾つかの実装特定の設定メカニ ズムを通じたものだろう) を規定しない。] TIP トランザクションマネージャーアドレスは以下の形式である。 の要素は以下のように構成される。 [:] は か のいずれかであり、 はト ランザクションマネージャー (あるいはプロクシ) が TIP コネクションの 確立要求をリッスンしているポートを示す 10進数である。もしポート番号 が省略されていたら、標準的な TIP ポート番号 (3372) が使用される。 は標準的な名前であり、ドメイン名サービスで受け入れられる。 それはコマンドの受信者に有効である資格を十分持つ。 は IP アドレスで、一般的な形式: ピリオドの文字で区切ら れた 4 つの 10 進数である。 の要素は 要素の範囲 (場所) を定義する。 トランザクションマネージャーアドレスの 要素は、 に よって定義された場所にある特定の TIP トランザクションマネージャーを 識別するデータを含む。 要素は以下の形式である。 "/" [path_segments] path_segments = segment *( "/" segment ) segment = *pchar *( ";" param ) param = *pchar 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" 要素は、一つのスラッシュ "/" 文字で区切られたパスセグメント のシーケンスから成る。パスセグメントの中で、文字 "/", ";", "=", "?" は予約されている。各々のパスセグメントは、セミコロン ";" 文字によっ て指し示されるパラメタのシーケンスを含んでもよい。パラメタは、相対 的な参照の解析には意味を持たない。 [トランザクションマネージャーアドレスの形式は、ユニフォーム資源識別 子 (URI) [8] で提案されたスキームに従うことを意図している。] 従って、TIP トランザクションマネージャーアドレスは、コネクション起 動者 (一次) に TCP コネクション () で使用される終点識別子 を提供し、コネクション受信者 (二次) に特定の TIP トランザクションマ ネージャー () の位置を決めるパスを提供する。これは、一次と二 次の TIP トランザクションマネージャー間で確立されるコネクションで必 要な情報の全てである。 コネクションが確立された後、一次側は IDENTIFY コマンドを発行する。 このコマンドは、一次側トランザクションマネージャーアドレスと二次側 トランザクションマネージャーアドレスの 2 つのトランザクションマネー ジャーアドレスをパラメタで含む。 一次側トランザクションマネージャーアドレスは、コネクションを起動す る TIP トランザクションマネージャーを識別する。この情報は、コネクショ ンのいずれか一方が、2 フェーズコミットプロトコルを完了するために他 方との新しいコネクションを再確立しなければならない時、コネクション 障害後のあるケースにおいて必要である。もし一次側がコネクションの再 確立を必要とするならば、そのジョブは容易であり、元のコネクションと 同じ方法でコネクションが確立される。しかし、もし二次側がコネクショ ンの再確立を必要とするならば、元のコネクションの起動側への接触方法 を知らなければならない。この情報は、IDENTIFY コマンド上の一次側トラ ンザクションマネージャーアドレスを通じて二次側に提供される。もし一 次側トランザクションマネージャーアドレスが提供されないならば、一次 側はコネクションの再確立を必要とする (すなわちリカバリ動作の実行) アクションを実行してはならない。 二次側トランザクションマネージャーアドレスは、受信側 TIP トランザク ションマネージャーを識別する。中間プロクシサーバ経由の TIP 通信の場 合、プロクシサーバはこの URL を要求された TIP トランザクションマネ ージャーを正しく識別し、接続するために使用してもよい 8. TIP ユニフォーム資源位置子 トランザクションとトランザクションマネージャーは、TIP プロトコルに 割り当てられた資源である。トランザクションマネージャーとトランザク ションは、トランザクションマネージャーアドレススキームを使用して配 置される。一旦コネクションが確立されたら、それぞれのトランザクショ ンマネージャーに割り当てられたトランザクションを操作するために、TIP コマンドを送信してもよい。 リモートノードからトランザクションをプルしたいアプリケーションは、 リモートトランザクションへの参照を提供しなければならない。その参照 により、ローカルトランザクションマネージャー (すなわちトランザクショ ンをプルするトランザクションマネージャー) は、リモートトランザクショ ンマネージャーに接続し、特定のトランザクションを識別することが可能 になる。トランザクションをリモートノードにプッシュしたいアプリケー ションは、リモートトランザクションマネージャー (すなわちトランザク ションがプッシュされるトランザクションマネージャー) への参照を提供 しなければならない。その参照により、ローカルトランザクションマネー ジャーはリモートトランザクションマネージャーの位置を突き止めること が可能になる。TIP プロトコルは、アプリケーションとトランザクション マネージャーがトランザクションマネージャーやトランザクションへの参 照を交換することを可能にする URL スキーム [4] を定義する。 TIP URL は以下の形式である。 tip://? は、TIP トランザクションマネージャ ーを識別し (上記のセクション 7 で定義されているように)、< transaction string> はト ランザクション識別子を指定する。以下の 2 つの形式のうちのどちらであっ てもよい。 i. "urn:" ":" 標準的なトランザクション識別子。RFC 2142 で規定されている、ユニフォ ーム資源名 (URN) として提案されたインターネット標準に適合し、 は名前空間識別子であり、 は名前空間特定文字列である。名前 空間 ID は、名前空間特定文字列の記法上の解釈を決定する。名前空間 特定文字列は、トランザクション識別子 ( で定義される) を表す 文字列のシーケンスである。これらのフィールドの内容における 規則は、[6] で規定される (正しい文字、符号化等)。 のこの形式は標準的な表現で、グローバルトラン ザクション識別子を表現するために使用してもよい。 の例は、< iso> か である。例えば、 tip://123.123.123.123/?urn:xopen:xid 名前空間 ID は登録が必要である。これを行うための詳細は、[7] を参 照されたい。 ii. トランザクション識別子を表している表示可能な ASCII 文字のシーケン ス (":" を除く 32 〜 126 までの範囲の値を持つオクテット)。この非 標準のケースでは、グローバルなユニーク性を保証するのは、 と の結合 である。例えば、 tip://123.123.123.123/?transid1 トランザクション識別子から非標準の TIP URL を生成するには、最初に トランザクション識別子中の全ての予約文字を同等のエスケープシーケ ンスに置き換え、その後適切なトランザクションマネージャーアドレス を挿入する。もしトランザクション識別子が自分が生成したものならば、 自分自身のトランザクションマネージャーアドレスを挿入する。もしト ランザクション識別子が、自分で起動した TIP コネクション上で受信し たものならば、IDENTIFY コマンドで送信した二次側トランザクションマ ネージャーアドレスを使用する。もしトランザクション識別子が、自分 で起動しなかった TIP コネクション上で受信したものならば、IDENTIFY コマンドで受信した一次側トランザクションマネージャーアドレスを使 用する。 TIP URL はグローバルな永久的なユニークさを保証しなければならない。 このユニーク性制約は TIP URL が決して重複しないことを保証する。それ により、起こり得る決定的でない振る舞いを避けられる。どのようにユニ ーク性を達成するかは実装特定である。例えば、汎用ユニーク識別子 (UUID、さらにグローバルユニーク識別子、GUID ([9] 参照) としても知ら れる) を、 の部分に使用することができる。ある標 準的なトランザクション識別子は、グローバルなユニークを保証するため の自身の規則 (例えば OSI CCR 原子動作識別子) を定義してもよいことに 注意されたい。 上記で規定されたものを除いて、TIP URL スキームは [4] で定義された予 約文字の規則に従い、[4] のセクション 5 で定義されているようにエスケ ープシーケンスを使用する。 TIP プロトコル自身は、TIP URL スキームを使用しないことに注意された い (TIP プロトコルは、トランザクションマネージャーアドレススキーム を使用する)。TIP URL スキームは、他のプロトコル、例えば協調アプリケ ーション処理、を通じてトランザクション識別子情報を渡すための標準的 な方法として提案されている。TIP URL は、ローカルトランザクションマ ネージャーと、例えばトランザクションをリモートのトランザクションマ ネージャーからプルするために、アプリケーションをある特定の TIP トラ ンザクションに割り当てるのに必要な情報を通信するために使用してもよ い。各々の TIP 実装は、この目的のために API の幾つかのセットを提供 する ([5] はそうした API の例を含む) ことが予想される。 9. コネクションの状態 どんな時でも、コネクションの一方の側だけがコマンドの送信を許され、 他方の側は受信したコマンドに応答することが許されるだけである。この ドキュメント全体で、コマンドの送信をやるされた側を "一次側" と呼び、 他方の側を "二次側" と呼ぶ。最初に、コネクションを起動した側が一次 側であるが、幾つかのコマンドによりこの役割が切り替わる。アイドル状 態に達した時には常に、元の極に戻る。 多重化が使用される時は、根本のコネクション (多重化状態になっている だろう) の極に関わらず、これらの役割は各々の "仮想" コネクションに 個別に適用される。 パイプラインを使用して、二次側は "帯域外" でコマンドを送信してもよ い。これは、コネクションの極に影響しない (一次側と二次側の役割は切 り替わらない)。詳細はセクション 12 を参照されたい。 通常のケースでは、初期状態の時 TIP コネクションは一次側だけがクロー ズすべきである。ある異常ケースでは必要になるかもしれないが、二次側 によってコネクションがクローズされることは通常望ましくない。 如何なる時も､コネクションは以下の状態の一つである。二次側の観点では、 応答を送信した時に状態は変わり、一次側の観点では、応答を受信した時 に状態は変わる。 Initial: 初期コネクションは Initial 状態で開始される。この状態に入 る際、コネクションを起動した側が一次側になり、他方の側が二次側に なる。この状態でコネクションに割り当てられたトランザクションは存 在しない。この状態から、一次側は IDENTIFY か TLS コマンドを送信で きる。 Idle: この状態では、一次側と二次側はプロトコルバージョンを合意して おり、一次側は二次側に障害後の再接続のために識別子を供給している。 この状態でコネクションに割り当てられたトランザクションは存在しな い。この状態に入る際、コネクションを起動した側が一次側になり、他 方の側が二次側になる。この状態から、一次側は次のコマンドを送信で きる: BEGIN, MULTIPLEX, PUSH, PULL, QUERY, RECONNECT。 Begun: この状態では、コネクションは活性トランザクションに割り当てら れ、1 フェーズプロトコルによってのみ完了できる。BEGIN コマンドに 対する BEGUN 応答が、コネクションをこの状態に変える。Begun 状態で のコネクション障害は、トランザクションがアボートすることを意味す る。この状態から、一次側は ABORT か COMMIT コマンドを送信すること ができる。 Enlisted: この状態では、コネクションは活性トランザクションに割り当 てられ、1 フェーズプロトコルか 2 フェーズプロトコルによって完了で きる。PUSH コマンドに対する PUSHED 応答か、PULL コマンドに対する PULLED 応答がコネクションをこの状態に変える。Enlisted 状態でのコ ネクション障害は、トランザクションがアボートすることを意味する。 この状態から、一次側は ABORT か COMMIT か PREPARE コマンドを送信 することができる。 Prepared: この状態では、コネクションは準備されたトランザクションに 割り当てられる。PREPARE コマンドに対する PREPARED 応答か、 RECONNECT コマンドに対する RECONNECTED 応答が、コネクションをこの 状態に変える。他の状態とは異なり、この状態でのコネクション障害は、 トランザクションを自動的にアボートさせない。この状態から、一次側 は ABORT か COMMIT コマンドを送信することができる。 Multiplexing: この状態では、コネクションは多重化プロトコルによって 使用され、それ自身のコネクションのセットを提供する。この状態では、 そのコネクション上での TIP コマンドは可能ではない。(無論、多重化 プロトコルによって提供されたコネクション上では、TIP コマンドは可 能である)。コネクションは、この状態から抜けることはできない。 Tls: この状態では、コネクションは TLS プロトコルによって使用されて おり、そのセキュリティを考慮したコネクションを提供する。この状態 では、そのコネクション上での TIP コマンドは可能ではない。(無論、 TLS プロトコルによって提供されたコネクション上では、TIP コマンド は可能である)。コネクションは、この状態から抜けることはできない。 Error: この状態では、プロトコルエラーが発生しコネクションがもはや有 効でない。コネクションは、この状態から抜けることはできない。 10. プロトコルバージョン このドキュメントは、プロトコルのバージョン 3 を規定している。将来の バージョンを適応するために、一次側は自身が理解する最小と最大のバー ジョン番号を示すメッセージを送信する。二次側は、自身が理解する最大 のバージョンで応答する。 こうした交換を行った後、最大のバージョン番号のより小さいもの (すな わち、両方が理解できる最大のバージョン番号) を使用して通信を行うこ とできる。この交換は必須であり、IDENTIFY コマンド (と IDENTIFIED 応 答) を使用して行う。 もし、一方の側でサポートされた最大のバージョン番号が廃止されたもの と見なし、もう一方の側ではもはやサポートしていなければ、有効な通信 を行うことはできない。この場合、より新しい側がコネクションを単に切 断すべきである。 11. コマンドと応答 全てのコマンドと応答は、CR (13 の値を持つオクテット) か LR (10 の値 を持つオクテット) が後ろに続く、32 〜 126 までの範囲の値を持つオク テットだけを使用した、ASCII テキストの 1 行で構成される。各行は 1 つ以上の "単語" に分割でき、連続した単語は 1 つ以上の空白オクテット (値 32) によって区切られる。 各行の開始と終端に任意の個数の空白を付与することは許されており、無 視される。 空か全体的に空白から成る行は無視される。(これの一つの意味は、もし望 むなら CR と LF の両方で行を終了できるということである。LF は空行の 終了として扱われ、無視される)。 全てのケースにおいて、各行の最初のワードはコマンドや応答のタイプを 示す。定義された全てのコマンドと応答は、英大文字のみから成る。 幾つかのコマンドと応答では、後続のワードはコマンドや応答に対するパ ラメタを運び、各々のコマンドや応答は固定数のパラメタを採る。 最初の未定義ワード (を含む) の後ろのコマンドや応答行上の全てのワー ドは、全て無視される。これらはデバッグや他の目的のために、人間が読 める情報を渡すために使用できる。 12. コマンドパイプライン 通信の冗長性を減らし効率を改善するために、複数の TIP "行" (コマンド や応答) を一緒にパイプライン化 (連結) し、単一のメッセージとして送 信することが可能である。(一次側によって後で処理するために、二次側に よって) 行を "前に" 送信してもよい。例えば、ABORT コマンドの直後に 続く BEGIN コマンドや、COMMITTED 応答の直後に続く PULL コマンドがそ うである。 パイプライン行を送信することは、実装オプションである。どの行を一緒 にパイプライン化するかについても同様である。通常、パイプライン化さ れた行が、受信側によって処理される時のコネクションの状態に正当であ ることは明白でなければならない。これを決定することは送信側の責任で ある。 全ての実装体は、パイプライン化された行の受信をサポートしなければな らない。その処理についての規則は、以下のパラグラフで規定される。 コネクション状態が一行を読める (コマンドか応答のいずれか) 状態で ある時、その行は (受信した時) 処理される。そのような状態に再び達 するまで、コネクションから行は読まれない。もし、他方の側が送信す る番ではない時に一行がコネクション上で受信されたら、その行は拒否 しない。その代わりに、コネクション状態が再び行を必要とする時にそ れを取り出して処理する。受信側は受信した行の順序で行を処理し、応 答を発行しなければならない。もし行が異常を引き起こしたら、そのコ ネクションは Error 状態に入り、そのコネクション上の全ての後続行を 破棄する。 13. TIP コマンド コマンドは、コネクションかトランザクションのいずれかに関係する。コ ネクションに関係するコマンドは、IDENTIFY, MULTIPLEX, TLS である。ト ランザクションに関係するコマンドは、ABORT, BEGIN, COMMIT, PREPARE, PULL, PUSH, QUERY, RECONNECT である。 以下は全ての正しいコマンドの一覧であり、各コマンドに対する全ての可 能な応答である。 ABORT このコマンドは Begun, Enlisted, Prepared 状態で有効である。これは、 そのコネクションの現トランザクションをアボートすることを二次側に 通知する。可能な応答は以下のものである。 ABORTED トランザクションがアボートした。そのコネクションは Idle 状態に 入る。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 BEGIN このコマンドは Idle 状態でのみ有効である。これは、新しいトランザ クションを生成し、それをコネクションに割り当てることを二次側に依 頼する。新たに生成されたトランザクションは、1 フェーズプロトコル で完了する。可能な応答は以下のものである。 BEGUN <トランザクション識別子> 新しいトランザクションが正常に開始され、そのトランザクションは コネクションの現トランザクションである。そのコネクションは Begun 状態に入る。 NOTBEGUN 新しいトランザクションを開始できなかった。そのコネクションは Idle 状態のままである。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 COMMIT このコマンドは Begun, Enlisted, Prepared 状態で有効である。Begun か Enlisted 状態では、トランザクションをコミットする試みを二次側 に依頼し、Prepared 状態では、トランザクションがコミットしたことを 二次側に通知する。Enlisted 状態では、このコマンドは 1 フェーズプ ロトコルを表し、送信側が 1) トランザクションに関連するローカルな 回復可能資源が無く、2) サブオーディネートが一つだけである (送信側 は如何なるトランザクションリカバリ処理にも関係しないだろう) 時に のみ行われるべきであることに注意されたい。可能な応答は以下のもの である。 ABORTED この応答は、Begun と Enlisted 状態からのみ可能である。これはあ る側がトランザクションのコミットメントを拒否したことを示す。そ して、トランザクションはコミットの代わりにアボートされた。その コネクションは Idle 状態に入る。 COMMITTED この応答はトランザクションがコミットし、一次側がそのトランザク ションに関して二次側への責任をもはや持たないことを示す。そのコ ネクションは Idle 状態に入る。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 ERROR このコマンドは如何なる状態でも有効であり、前の応答が認識されなかっ たか不正な形式であったことを二次側に通知する。二次側はこのコマン ドに対して応答すべきではない。そのコネクションは Error 状態に入る。 IDENTIFY <最小のプロトコルバージョン> <最大のプロトコルバージョン> <一次側トランザクションマネージャーアドレス> | "-" <二次側トランザクションマネージャーアドレス> このコマンドは Initial 状態でのみ有効である。一次側は二次側に次の ことを通知する、1) サポートされる最小と最大のプロトコルバージョン (最小と最大の間の全てのバージョンをサポートしていなければならな い)、2) オプションで、それによって二次側が必要になった場合にコネ クションを再確立できる一次側の識別子 (一次側トランザクションマネ ージャアドレス)、3) 要求された TIP トランザクションマネージャに接 続するために、中間プロクシサーバが使用してもよい識別子 (二次側ト ランザクションマネージャアドレス)。もし一次側トランザクションマネ ージャアドレスが供給されないならば、二次側は如何なる PREPARE コマ ンドに対しても ABORTED か READONLY で応答するだろう。可能な応答は 以下のものである。 IDENTIFIED <プロトコルバージョン> 二次側は正常に接触し、一次側トランザクションマネージャーアドレ スを保存した。この応答は、二次側によってサポートされている最大 のプロトコルバージョンを含む。全ての将来の通信は、IDENTIFY コマ ンドと IDENTIFIED 応答中のプロトコルバージョンのより小さいもの を使用して行われると想定される。そのコネクションは Idle 状態に 入る。 NEEDTLS 二次側は TLS のセキュリティを考慮したコネクション上の通信だけを 望んでいる。そのコネクションは Tls 状態に入り、以降の全ての通信 は TLS ロトコルによって定義された通りに行われる。このプロトコル は、IDENTIFY コマンドの行終端後の最初のオクテット (一次側によっ て送信されたデータ) と NEEDTLS 応答の行終端後の最初バイト (二次 側によって送信されたデータ) から開始される。これは、実装体が IDENTIFY コマンドか NEEDTLS 応答のいずれかの後に、CR と LF オク テットの両方を送信してはならないことを意味する。TLS プロトコル の最初のバイトが LF オクテットであることは誤りである。TLS プロ トコルによって提供されるコネクションは、Initial 状態で始まる。 TLS が折衝された後、一次側は IDENTIFY コマンドを再送しなければ ならない。もし一次側が TLS プロトコルをサポートできない (あるい は使用を拒否する) ならば、そのコネクションをクローズする。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。この応答 は、二次側が一次側によってサポートされた範囲のプロトコルバージョ ンを全てサポートしていない場合でも発生する。そのコネクションは Error 状態に入る。一次側はそのコネクションをクローズすべきであ る。 MULTIPLEX <プロトコル識別子> このコマンドは Idle 状態でのみ有効である。このコマンドは、既存の コネクション上で非常に数多くのコネクションを供給する、多重化プロ トコルとしてコネクションを使用するための同意を求める。一次側は、 ある特定の多重化プロトコルを提案する。二次側は、このプロトコルの 使用を受諾するか拒否するかのいずれかを行うことができる。 現在、唯一定義済みのプロトコル識別子は "TMP2.0" であり、TIP 多重 化プロトコル、バージョン 2.0 を指す。このプロトコルに関する詳細は、 付録 A を参照されたい。将来、他のプロトコル識別子が定義されるかも しれない。 もし MULTIPLEX が受諾されたら、指定された多重化プロトコルは基礎的 なコネクションを全体的に制御する。このプロトコルは、MULTIPLEX コ マンドの行終端後の最初のオクテット (一次側によって送信されたデー タ) と MULTIPLEXING 応答の行終端後の最初バイト (起動側によって受 信されたデータ) から開始される。これは、実装体が MULTIPLEX コマン ドか MULTIPLEXING 応答のいずれかの後に、CR と LF オクテットの両方 を送信してはならないことを意味する。多重化プロトコルの最初のバイ トが LF オクテットであることは誤りである。 TMP V2.0 を使用する時、単一の TIP コマンド (TMP アプリケーション メッセージ) は、単一の TMP パケットの中に完全に含まなければならな いことに注意されたい (TMP PUSH フラグは TIP では使用しない)。 MULTIPLEX コマンドに対する可能な応答は以下のものである。 MULTIPLEXING 二次側は、指定された多重化プロトコルの使用を同意する。そのコネ クションは Multiplexing 状態に入り、以降の全ての通信はそのプロ トコルによって定義された通りに行われる。多重化プロトコルによっ て生成された全てのコネクションは、Idle 状態から開始される。 CANTMULTIPLEX 二次側は、指定された多重化プロトコルをサポートできない (あるい は使用を拒否)。そのコネクションは、Idle 状態のままである。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 PREPARE このコマンドは Enlisted 状態でのみ有効である。このコマンドは、二 次側にトランザクションのコミットメントのための準備 (2 フェーズコ ミットのフェーズ 1) を要求する。可能な応答は以下のものである。 PREPARED サブオーディネートはトランザクションを準備した。そのコネクショ ンは PREPARED 状態に入る。 ABORTED サブオーディネートはトランザクションのコミットを拒否した。その コネクションは Idle 状態に入る。この応答の後、スーペリアはその トランザクションに関する責任をサブオーディネートに対して持たな い。 READONLY サブオーディネートは、トランザクションがコミットするかアボート するかもはや気にしない。この応答の後、スーペリアはそのトランザ クションに関する責任をサブオーディネートに対して持たない。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 PULL <スーペリアのトランザクション識別子> <サブオーディネートのトランザクション識別子> このコマンドは Idle 状態でのみ有効である。このコマンドは、トラン ザクションにおいてスーペリア/サブオーディネートの関係を確立するこ とを求め、コネクションの一次側はサブオーディネートになる (つまり、 一次側は二次側からトランザクションを取り込む)。<トランザクション 文字列> の全体の値 ("TIP ユニフォーム資源位置子" のセクションで規 定) を、トランザクション識別子として指定しなければならない。可能 な応答は以下のものである。 PULLED 関係が確立された。この応答を受信した時、指定されたトランザクショ ンはコネクションの現トランザクションになり、そのコネクションは Enlisted 状態に入る。さらに、一次側と二次側の役割が逆転する。 (すなわち、スーペリアはそのコネクションの一次側になる)。 NOTPULLED 関係は確立されなかった (おそらく二次側が要求されたトランザクショ ンを持っていなかったため)。そのコネクションは Idle 状態のままで ある。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 PUSH <スーペリアのトランザクション識別子> このコマンドは Idle 状態でのみ有効である。このコマンドは、トラン ザクションにおいてスーペリア/サブオーディネートの関係を確立するこ とを求め、コネクションの一次側はスーペリアになる。<トランザクショ ン文字列> の全体の値 ("TIP ユニフォーム資源位置子" のセクションで 規定) を、トランザクション識別子として指定しなければならない。可 能な応答は以下のものである。 PUSHED <サブオーディネートのトランザクション識別子> 関係が確立され、サブオーディネートがそれによってトランザクショ ン認識する識別子を返却する。トランザクションはコネクションの現 トランザクションになり、そのコネクションは Enlisted 状態に入る。 ALREADYPUSHED <サブオーディネートのトランザクション識別子> 関係が確立され、サブオーディネートがそれによってトランザクショ ン認識する識別子を返却する。しかし、サブオーディネートはそのト ランザクションを既に認識しており、2 フェーズコミットプロトコル が異なるコネクションを経由して到達することを期待している。この 場合、そのコネクションは Idle 状態のままである。 NOTPUSHED 関係が確立できなかった。そのコネクションは Idle 状態のままであ る。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 QUERY <スーペリアのトランザクション識別子> このコマンドは Idle 状態でのみ有効である。サブオーディネートは、 特定のトランザクションがまだスーペリア側に存在するか否かを決定す るために、このコマンドを使用する。可能な応答は以下のものである。 QUERIEDEXISTS トランザクションがまだ存在している。そのコネクションは Idle 状 態のままである。 QUERIEDNOTFOUND トランザクションはもう存在しない。そのコネクションは Idle 状態 のままである。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 RECONNECT <サブオーディネートのトランザクション識別子> このコマンドは Idle 状態でのみ有効である。スーペリアは、前のコネ クションが Prepared 状態中に消失した時、トランザクションのための コネクションを再確立するためにこのコマンドを使用する。可能な応答 は以下のものである。 RECONNECTED サブオーディネートは再確立を受諾する。そのコネクションは Prepared 状態に入る。 NOTRECONNECTED サブオーディネートは、そのトランザクションをもはや知らない。そ のコネクションは Idle 状態のままである。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 TLS このコマンドは Initial 状態でのみ有効である。一次側は、TLS を使用 してセキュリティを考慮したコネクションの確立を試みるために、この コマンドを使用する。 もし TLS コマンドが受諾されたら、TLS プロトコルは基礎的なコネクショ ンを全体的に制御する。このプロトコルは、TLS コマンドの行終端後の 最初のオクテット (一次側によって送信されたデータ) と TLSING 応答 の行終端後の最初バイト (一次側によって受信されたデータ) から開始 される。これは、実装体が TLS コマンドか TLSING 応答のいずれかの後 に、CR と LF オクテットの両方を送信してはならないことを意味する。 TLS プロトコルの最初のバイトが LF オクテットであることは誤りであ る。 TLS コマンドに対する可能な応答は以下のものである。 TLSING 二次側は、TLS プロトコル [3] の使用を同意する。そのコネクション は Tls 状態に入り、以降の全ての通信は TLS ロトコルによって定義 された通りに行われる。TLS プロトコルによって提供された全てのコ ネクションは、Initial 状態から開始される。 CANTTLS 二次側は、TLS プロトコルをサポートできない (あるいは使用を拒否)。 そのコネクションは、Initial 状態のままである。 ERROR コマンドが無効な状態で発行されたか、不正な形式である。そのコネ クションは Error 状態に入る。 14. エラー処理 もしいずれかの側が理解できない行を受信したら、そのコネクションをク ローズする。もしいずれかの側 (コマンドか応答のいずれか) がコネクショ ン上で ERROR 指示か ERROR 応答を受信したら、そのコネクションは Error 状態に入り、そのコネクション上で更に通信を行うことはできない。 実装体はコネクションをクローズしてもよい。コネクションのクローズは、 他方の側によって通信障害として扱われる。 ERROR 指示か ERROR 応答の受信は、他方の側があなたはプロトコルを適切 に実装していないと思っていることを示す。 15. コネクション障害とリカバリ コネクション障害は、通信障害やいずれかの側がコネクションをクローズ することにより引き起こされるかもしれない。TIP 実装体は、TIP コネク ション障害を検出するために私的なメカニズム (例えばソケットキープア ライブやタイムアウトスキーム) を使用すると想定される。 コネクションの状態によって、コネクション障害時に、トランザクション マネージャーは様々な動作を行う必要があるだろう。 もしコネクションが Initial か Idle 状態で障害になったら、そのコネク ションはトランザクションを参照していない。何の動作も必要ない。 もしコネクションが Multiplexing 状態で障害になったら、多重化プロト コルによって提供された全てのコネクションが失敗したと想定される。そ の各々が独立して処理される。 もしコネクションが Begun か Enlisted 状態で COMMIT が送信された後で 障害になったら、トランザクションの完了がサブオーディネートに委任さ れ (スーペリアは関係していない)、スーペリアはトランザクションの結果 を知らない (サブオーディネートは知っている)。スーペリアは、トランザ クションの結果を決定するためにアプリケーション特定の手段を 使用する。(スーペリアはそのトランザクションに関係する回復可能な資源 を持っていないので、この場合トランザクションの完全性について妥協し ない)。もしコネクションが Begun か Enlisted 状態で COMMIT が送信さ れる前に障害になったら、そのトランザクションはアボートするだろう。 もしコネクションが Prepared 状態で障害になったら、スーペリアとサブ オーディネートで適切な動作が異なる。 もしスーペリアがトランザクションのコミットを決定したら、最終的に新 しいコネクションをサブオーディネートに確立しなければならず、そのト ランザクションに対して RECONNECT コマンドを送信する。もしスーペリア が NOTRECONNECTED 応答を受信したら、他に何も行う必要はない。しかし、 もし RECONNECTED 応答を受信したら、スーペリアは COMMIT 要求を送信し、 COMMITTED 応答を受信しなければならない。 もしスーペリアがトランザクションのアボートを決定したら、新しいコネ クションを確立して、そのトランザクションに対する RECONNECT コマンド を送信してもよい (が、必要ではない)。もしスーペリアが RECONNECTED 応答を受信したら、ABORT コマンドを送信すべきである。 上記の定義は、もし都合が良ければ、スーペリアがトランザクションの結 果を知る前にコネクションを再確立することを可能にする。RECONNECT コ マンドが成功したら、そのコネクションは Prepared 状態に戻り、トラン ザクションの結果が分かった時に、スーペリアは適宜 COMMIT か ABORT コ マンドを送信することができる。 サブオーディネートは、前のコネクションが障害になったことを認識する 前に、RECONNECT コマンドを受信する可能性があることに注意されたい。 この場合、サブオーディネートは RECONNECT 応答を障害指示として扱い、 そのコネクションに関連する資源を一掃し、トランザクション状態を新し いコネクションに割り当てる。 もしサブオーディネートが、Prepared 状態でコネクション障害を検出した ら、サブオーディネートはスーペリアへの新しいコネクションの生成を定 期的に試み、そのトランザクションに対して QUERY コマンドを送信すべき である。サブオーディネートは、以下の二つのイベントの一つが発生する までこれを継続すべきである。 1. スーペリアから QUERIEDNOTFOUND 応答を受信する。この場合、サブオ ーディネートはトランザクションをアボートすべきである。 2. スーペリアが、起動したコネクション上で、サブオーディネートにトラ ンザクションに対する RECONNECT コマンドを送信する。この場合サブ オーディネートは、この新しいコネクション上でトランザクションの結 果を知ることを期待できる。もしサブオーディネートがトランザクショ ンの結果を知る前に、新しいコネクションが障害になったら、サブオー ディネートは QUERY コマンドの送信から再び開始すべきである。 もし TIP システムが QUERY か RECONNECT コマンドのいずれかを受信し、 ある理由によりその要求を満足することができない (例えば、必要なリカ バリ情報が現在利用できない) ならば、そのコネクションを落とすべきで あることに注意されたい。 16. セキュリティの考慮 このセクションは、アプリケーション開発者やトランザクション開発者、 及びユーザに、このドキュメントによって示された TIP のセキュリティの 意味を知らせることを意図している。セキュリティリスクを減らすために 幾つかの提案を行っているが、この議論は記述された問題に対する決定的 な解決方法を含んでいない。 全ての 2 フェーズコミットプロトコルのように、対応するメカニズムが通 信プロトコルに適用されなければ、アプリケーション通信プロトコルに適 用されるセキュリティメカニズムは覆され易い。例えば、アプリケーショ ンプロトコルを使用する側の間での認証では、少なくとも確実性の同じレ ベルへの TIP 交換のセキュリティをサポートしなければならない。 16.1. TLS 相互認証と認可 TLS はオプションのクライアント側認証、オプションのサーバ側認証、オ プションのパケット暗号化を提供する。 TIP 実装体は、もし TLS が使用されなければサービスの提供を拒否しても よい。もしパケット暗号化が使用されなければ、サービスの提供を拒否し てもよい。もしリモート側が認証されなかったら (TLS を経て)、サービス の提供を拒否してもよい。 TIP 実装体は自身の (TLS による )認証を望むべきである。これは、実装 体がクラテアントとして動作するのでも、サーバとして動作するのでも真 である。 一旦リモーと側が認証されたら、TIP トランザクションマネージャーは、 どの操作を許可するかを決定するために、そのリモート側の識別子を使用 してもよい。 コネクション上で TLS を使用するか否か、そしてもし使用するならどのよ うに TLS を使用するか、またその後何の操作を許すかについては、TIP ト ランザクションマネージャーをお互いに接続するセキュリティ指針によっ て決定される。どのようにこれらのセキュリティ指針を決定するか、そし てどのように TIP トランザクションマネージャーがそれよを認識するかに ついては、実装にとっては全て私的事項であり、このドキュメントのスコ ープ外である。 16.2. プルベースのサービス拒否攻撃 悪意のあるユーザが、あるトランザクションマネージャーで現在活性中の トランザクションの識別子を知っていると仮定する。もし悪者がトランザ クションマネージャーへの TIP コネクションをオープンし、PULL コマン ドを送信し、そのコネクションをクローズすると、そのトランザクション をアボートさせることができる。結果的に、トランザクションの正当な所 有者に対してサービスの拒否を引き起こす。 もし TLS を使用しない、あるいはリモード側が認証されていない、あるい はリモート側が承認されていないならば、実装体は PULL コマンドを拒否 することによってこの攻撃を回避してもよい。 16.3. プッシュベースのサービス拒否攻撃 トランザクションが Prepared 状態の間に、二つのトランザクションマネ ージャー間のコネクションがクローズされると、各々のトランザクション マネージャーは、コネクションが再確立できるまでトランザクションにつ いての情報を覚えておく必要がある。 もし悪意のあるユーザが、この事実を利用して繰り返しトランザクション を生成し、Prepared 状態にしてコネクションを落としたら、トランザクショ ンマネージャーがリソースの疲弊に陥るかもしれない。結果、そのトラン ザクションマネージャーの全ての正当なユーザに対して、サービスが拒否 される。 もし TLS を使用しない、あるいはリモード側が認証されていない、あるい はリモート側が承認されていないならば、実装体は PUSH コマンドを拒否 することによってこの攻撃を回避してもよい。 16.4. トランザクション転化攻撃 もしサブオーディネートトランザクションマネージャーが、ある特定の準 備されたトランザクションのためのコネクションを失ったら、悪意のある ユーザはトランザクションマネージャーへの TIP コネクションを起動し、 そのトランザクションのための RECONNECT コマンド、続いて COMMIT か ABORT コマンドを送信することができる。従って、アボートさせるべき場 合に、悪意のあるユーザがトランザクションの一部をコミット等をさせる ことができる。 実装体は、トランザクション中のスーペリアの認証された識別子を記録し、 もし TLS を使用しない、あるいはリモード側の認証された識別子が元のス ーペリアの識別子と同一でないならば RECONNECT コマンドを拒否すること によって、この攻撃を回避してもよい。 16.5. パケット盗聴攻撃 もし悪意のあるユーザが TIP コネクション上のトラフィックを捕捉できる ならば、別の攻撃を計画する際に有効な情報を推論できるかもしれない。 例えば、もしコメントフィールドにトランザクションマネージャーの製品 名とバージョン番号が含まれているならば、悪意のあるユーザはその実装 体に何のセキュリティバグが存在するかを決めるのに、この情報を使用で きるかもしれない。 実装体はセション暗号化を提供する TLS を常に使用し、TLS/TLSING コマ ンド/応答のペアに所有者を示す情報を含めないことによって、この攻撃を 回避してもよい。 16.6. 介在者の攻撃 もし悪意のあるユーザが TIP コネクション上のトラフィックを捕捉し、変 更できるならば、数多くの方法で破壊をもたらすことができる。例えば、 COMMIT コマンドを ABORT コマンドに置き換えることができるだろう。 実装体は、セション暗号化とリモート側の認証を提供する TLS を常に使用 することによって、この攻撃を回避することができる。 17. 参照 [1] Gray, J. and A. Reuter (1993), Transaction Processing: Concepts and Techniques. San Francisco, CA: Morgan Kaufmann Publishers. (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. [3] Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in Progress. [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [5] Evans, K., Klein, J., and J. Lyon, "Transaction Internet Protocol - Requirements and Supplemental Information", RFC 2372, July 1998. [6] Moats, R., "URN Syntax", RFC 2141, May 1997. [7] Faltstrom, P., et. al., "Namespace Identifier Requirements for URN Services", Work in Progress. [8] Berners-Lee, T., et. at., "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", Work in Progress. [9] Leach, P., and R. Salz, "UUIDs and GUIDs", Work in Progress. 18. 作者のアドレス Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399, USA 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 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 Phone: +1 (408) 285 0453 Fax: +1 (408) 285 9818 EMail: Johannes.Klein@Tandem.Com 19. コメント このドキュメントに対するコメントは作者 (, , ) か、TIP メー リングリスト () に送信されたい。TIP メーリン グリストには、メッセージ本体のどこかに "subscribe tip " という行を含んだメールを に送信すること によって購読できる。 付録 A. TIP 多重化プロトコルバージョン 2.0 この付録は、TIP 多重化プロトコル (TMP: TIP Multiplexing Protocol) のバージョン 2.0 を規定している。TMP は TIP プロトコルと単独で使用 することを意図しており、TIP プロトコル規定の一部を形成している。TMP V2.0 は、TIP V3.0 によってサポートされた多重化プロトコルのみである。 Abstract TMP は、単一の TCP コネクション上に複数の軽量コネクションを生成する ための単純なメカニズムを提供する複数のそうした軽量コネクションは同 時に活性化することができる。TMP はバイト型のサービスを提供するが、 メッセージの境界線のマーキングを可能にしている。 A.1. 導入 各々のトランザクションのために単一の TCP コネクションを生成するため に、インターネット上で広く使用されている幾つかのプロトコルが存在す る。不幸にもこれらのトランザクションは短命であるため、使用される資 源と TCP の輻輳制御メカニズムに関連する遅延の両方に関して、これらの TCP コネクションを設定したり解放するコストが重要になる。 TIP 多重化プロトコル (TMP) は TCP の最上位で動作する単純なプロトコ ルであり、複数の軽量コネクションを単一のトランスポートコネクション 上で使用できる。従って TMP は TCP コネクションのより効率的な利用を 提供する。複数の TMP コネクションからのデータを挟むことができ、メッ セージの境界線とストリームマーカの終端の両方を提供できる。 TMP は信頼できるバイト順番のトランスポートサービスの最上位で動作す るので、TCP が信頼性を保証するために行わなければならない追加作業の 大半を避けることができる。例えば、TMP コネクションは確認が不要なの で、データを送信する前に完了の同期をとるために待つ必要が無い。 注記: TMP は多重化プロトコルを一般化することを意図してはいない。も し多重化を必要とする異なるプロトコルを設計するならば、TMP は適切か もしれないし不適切かもしれない。大きいメッセージを持つプロトコルは 受信側のバッファ容量を超えることがあり得、ある条件下においてこれは デットロックを引き起こし得る。TIP は要求-応答のプロトコルであり、全 てのメッセージは短いので、TMP を TIP と一緒に使用する場合、この問題 を被ることはない。 A.2. プロトコルモデル 基本的なプロトコルモデルは、信頼できるバイトストリーム上で処理する 複数の軽量コネクションのモデルである。コネクションを起動する側は一 次側と呼ばれ、コネクションを受諾する側は二次側と呼ばれる。 コネクションは片方向でも両方向でもよく、両方向コネクションの終端は 別々にクローズしてもよい。コネクションは正常にクローズしてもよいし、 異常解放を示すためにリセットしてもよい。コネクションのアボートは、 両方のデータストリームをクローズする。 一旦コネクションがオープンされたら、アプリケーションはそのコネクショ ン上にメッセージを送信し、アプリケーションレベルのメッセージの終端 を通知することができる。アプリケーションメッセージは TMP パケットに カプセル化され、バイトストリーム上で転送される。単一の TIP コマンド (TMP アプリケーションメッセージ) は、単一の TMP パケット内に全体を 含めなければならない。 A.3. TMP パケット形式 TMP パケットは、0 個以上のデータのオクテットが続く 64 ビットのヘッ ダから構成される。ヘッダは、フラグバイト、コネクション識別子、パケッ ト長の三つのフィールドを含む。コネクション識別子とパケット長はどち らも整数であり、ネットワークバイトオーダで送信しなければならない。 フラグ +--------+--------+--------+--------+ |SFPR0000| Connection ID | +--------+--------+--------+--------+ | | Length | +--------+--------+--------+--------+ A.3.1. フラグ詳細 +-------+-----------+-----------------------------------------+ | 名前 | マスク | 説明 | +-------+-----------+ ----------------------------------------+ | SYN | 1xxx|0000 | 新しいコネクションをオープンする | | FIN | x1xx|0000 | 既存のコネクションをクローズする | | PUSH | xx1x|0000 | アプリケーションレベルのメッセージ境界を| | | | マークする | | RESET | xxx1|0000 | コネクションをアボートする | +-------+-----------+-----------------------------------------+ A.4. コネクション識別子 各々の TMP コネクションは、24 ビット整数によって識別される。元にな る TCP コネクションを起動した側によって生成された TMP コネクション は識別子を持たなければならず、他方の側によって生成されたコネクショ ンは片方の識別子を持たなければならない。 A.5. TMP コネクション状態 TMP コネクションは複数の異なる状態、Closed, OpenWrite, OpenSynRead, OpenSynReset, OpenReadWrite, CloseWrite, CloseRead、で存在すること ができる。コネクションは SYN, FIN, RESET ビットを持ったパケットの受 信に対する応答か、アプリケーションによって呼ばれた API に対する応答 で、その状態を変更できる。利用可能な API 呼びだしは、オープン、クロ ーズ、アボートである。 大半の状態の意味は明白である (例えば OpenWrite は、コネクションが書 き込みのためにオープンされたことを意味する)。OpenSynRead と OpenResetRead の意味については、より詳細な説明が必要である。 OpenSynRead 状態では、一次側がコネクションの出力データストリームを オープンして、即座にクローズし、読み込むための入力データストリーム をオープンするための二次側からの SYN 応答を待っている。 OpenResetRead 状態では、一次側がコネクションをオープンして、即座に アボートし、最終的にコネクションをクローズするための二次側からの SYN 応答を待っている。 A.6. イベンと優先度と状態遷移 以下に表される状態表は、与えられたイベントに対する応答で発生するア クションと状態遷移を示している。各状態で受け入れられるイベントは、 優先度の最も高いものが一番最初に現れるよう優先度順でリスト化されて いる。もし一つのメッセージに複数のイベントが提供されたら、リストに 一致するイベントが処理される。もし複数のイベントが一致したら、最も 高い優先度を持つイベントが受け入れられ、一番最初に処理される。残り のイベントは全て、結果的に後続する状態で処理される。 例えば、もし 二次側の TMP コネクションが Closed 状態にあり、二次側 が SYN イベント、FIN イベント、入力データイベント (例えば DATA-IN) を含むパケットを受信したら、二次側は最初に SYN イベントを受け入れる (それは Close 状態で唯一一致するので)。二次側はコネクションを受諾し、 SYN イベントを送信して ReadWrite 状態に入る。SYN イベントは未処理の イベントのリストから除去される。残りのイベントは FIN と DATA-IN で ある。ReadWrite 状態で、二次側は入力データを読む (DATA-IN イベント は FIN イベントよりも高い優先度を持っているので、DATA-IN イベントが 最初に処理される)。一旦データが読み込まれ、DATA-IN イベントが未処理 イベントのリストから除去されたら、FIN イベントが処理され、二次側は CloseWrite 状態に入る。 もし二次側が SYN イベントを含んでいるパケットを受信し、ある理由 (例 えば資源不足) によりそのコネクションを受け入れられないならば、二次 側は SYN イベントと、それに続く RESET イベントを送信することによっ て拒否すべきである。両方のイベントは同じ TMP パケットの一部として送 信できることに注意されたい。 いずれかの側が理解できない TMP パケットか、不正な状態であるイベント を受信したら、TCP コネクションをクローズする。 +==============+=========+==========+==============+ | エントリ状態 | イベント|アクション| 次の状態 | +==============+=========+==========+==============+ | 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 イベント優先度と状態遷移 完全なコピーライト宣言 Copyright (C) The Internet Society (1998). All Rights Reserved. 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.