JP4714572B2 - ウェブサービスのための信頼性のあるメッセージングプロトコルを使用したメッセージの効率的な転送 - Google Patents

Description

本発明は、一般にウェブサービスの信頼性のあるメッセージングに関する。詳細には、本発明は、２つのエンドポイント間のフロー制御、およびこのネットワーク配線（ｎｅｔｗｏｒｋ ｗｉｒｅ）にわたる輻輳制御のためのウェブサービスについての信頼性のあるメッセージングプロトコルによるメッセージの効率的な転送を提供する。

コンピュータネットワークは、１台のコンピュータまたはデバイス（以降、「コンピューティングデバイス」または「コンピューティングシステム」と呼ぶ）が電子メッセージを使用して別のコンピューティングシステムとネットワークを介して通信できるようにすることにより、通信し、情報にアクセスする我々の能力を拡大した。コンピューティングシステム間で電子メッセージを転送するときに、この電子メッセージは、多くの場合、電子メッセージ内のデータに関するオペレーション（例えば、構文解析（ｐａｒｓｉｎｇ）、ルーティング、フロー制御など）を行うプロトコルスタックを通過することになる。このＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔ）モデルは、プロトコルスタックを実装するためのネットワークフレームワークの一例である。

このＯＳＩモデルは、電子メッセージを転送するためのオペレーションを７つの異なる層へと分解し、各層がこのデータ転送プロセス中のある特定のオペレーションを実行するように指定されている。プロトコルスタックは、可能性としてこれらの層のそれぞれを実装することもできるが、多くのプロトコルスタックでは、ネットワークにわたってデータを転送する際の使用のために選択的な層のみを実装している。データが、コンピューティングシステムから送信されるときに、このデータは、アプリケーション層から出て、より低い中間層に渡され、次いでネットワーク上に伝えられる。データがネットワークから受信されるときには、このデータは、物理層に入力され、より高い中間層に渡され、次いで最終的にそのアプリケーション層で受信される。このアプリケーション層（最上位層）は、アプリケーションおよびエンドユーザの処理をサポートする役割を担う。さらに、アプリケーション層内には、いくつかの他の層（例えば、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｐｅｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）層）が存在することもある。ほとんどのプロトコルスタックによって組み込まれる他の層は、トランスポート層である。トランスポート層の一例は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）である。

ＷＳ（Ｗｅｂ Ｓｅｒｖｉｃｅ）は、コンピューティングシステム間の通信を進歩させる際の原動力になっており、我々がソフトウェアを構築し使用するやり方をすっかり変えようとしている。ウェブサービスは、アプリケーションにデータを共有させ、さらに強力なこととして、他のアプリケーションの機能を呼び出させ、これらのアプリケーションがどのように構築されたか、これらのアプリケーションがどのようなオペレーティングシステムまたはプラットフォーム上で実行されるか、そしてどのようなデバイスを使用してこれらのアプリケーションにアクセスするかに関係なくこれを行う。ウェブサービスは、ＳＯＡＰ、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ，Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などを含む業界標準プロトコルを用いて、インターネットを介して呼び出される。ウェブサービスは、互いに独立したままであるが、これらのウェブサービスは、それら自体を特定のタスクを行う協調グループにゆるくリンクすることができる。

現在のＷＳ技術は、イニシエータ（例えば、クライアント）とアクセプタ（例えば、サービス）の間の直接ＳＯＡＰ−メッセージ通信を提供している。一般的な双方向メッセージングの場合、ＳＯＡＰ要求メッセージが、イニシエータからアクセプタに送信され、ＳＯＡＰリプレイメッセージが、それに応答して送信される。エンドポイント間の別の通信変形形態は、単方向メッセージであり、この場合には、イニシエータは、メッセージを応答なしでアクセプタに送信する。

新興のＷＳアーキテクチャの重要な利点は、統合された相互運用可能なソリューションを提供することができることである。しかし、ウェブサービスは、インターネットなど信頼性のない通信チャネルを経由して異なる企業、起点、および他のサービスプロバイダから様々なサービスを提供するので、ＷＳの信頼性は、ますます重要なファクタになりつつある。ＷＳの信頼性は、それだけには限定されないが、ウェブサービスエンドポイントの信頼性、ウェブサービスがアクセスされる通信チャネルの信頼性特性、性能特性およびフォールトトレランス特性、ならびにウェブサービスが同時クライアントアクセスを処理することができる程度を含むいくつかのファクタによって影響を受ける。

これらのメッセージ（例えば、ＳＯＡＰメッセージ）をエンドポイント間で交換する、信頼性のあるトランスポートプロトコルを選ぶことにより、ウェブサービスの信頼性のあるメッセージングを実現しようとする試みが行われている。例えば、メッセージキューなどの信頼性のあるメッセージングトランスポートを使用して、イニシエータとアクセプタの間でメッセージを確実に配信することができる。メッセージキュー通信技術により、異なるシステム上のアプリケーションは、キューにメッセージを送信し、信頼性についての障害にわたって持続するキューからメッセージを読み取ることにより、互いに通信することができるようになる。

キューイングシステムは、ＳＯＡＰメッセージを確実に伝えるために使用することができるトランスポートを提供するが、このようなシステムには、いくつかの欠点が存在する。例えば、これらのシステムは、要求（および場合によってはそれらの応答）が転送され、分離して処理される非同期オペレーションについてのソリューションを提供する。したがって、これらのシステムは、通常、リソースの点で重く、耐久性のあるトランザクション処理メッセージストアを有し、展開、プログラミングモデル、および管理がかなり複雑となる複数の仲介手段を伴う。すべては、信頼性のある直接通信には不必要であり、レイテンシを最小化する目標からはそれている。さらに、このプログラムモデルは、要求−応答スタイルのプログラミングまたはセッションを直接サポートしない。したがって、キュー通信モデルは、現行の「インタラクティブ」なウェブサービスモデルとは異なり、クリティカルな「接続」シナリオおよび「インタラクティブ」アプリケーションには対処していない。例えば、応答がタイムリに期待される場合や、分散したトランザクションコンテキストがイニシエータとアクセプタの間で共有される必要がある場合には、あまり適していない。

基本的に信頼性のないトランスポートプロトコルを介して信頼性のある転送層、例えば信頼性のあるＨＴＴＰまたはＨＴＴＰＲを定義する試みも行われている。しかし、このソリューション（ならびにキューイングソリューション）を厄介なものにする共通の問題は、特定の信頼性のあるトランスポートプロトコルがイニシエータとアクセプタの間の通信のために使用される場合にしか、信頼性のあるメッセージングは達成できないことである。ウェブサービスの基本的な性質は、特定のベンダプラットフォーム、実装言語、および特定のトランスポートプロトコルからの独立を求める。一般的なケースでは、イニシエータが特定のプロトコルを使用してアクセプタに直接にメッセージを送信することができない（例えば、アクセプタがこのプロトコルをサポートしていない）こともあるし、あるいはメッセージが送信ノードを離れた後にその宛先ノードに到着するのに先立って、複数のホップを通過する必要がある場合もある。特定のホップに関与する２つのノード間の接続性の性質によっては、信頼性のあるメッセージング特性を提供しない適切なトランスポートプロトコルが選ばれざるを得ないこともある。

仲介手段はまた、プロトコルスタック中の様々なレベルに存在し、それゆえ完全なエンドツーエンドの信頼性を提供できないこともある。例えば、トランスポートプロトコルは、より低いレベルの仲介手段（例えば、ＩＰレベルの仲介手段−例えば、ＩＰルータ）にわたる信頼性を提供することができる。しかし、トランスポートプロトコルは、ＳＯＡＰ仲介手段、またはアプリケーション層で終了することもある。したがって、トランスポートプロトコルは、仲介手段にわたる信頼性、すなわちこのアプリケーション層にわたるエンドツーエンドの信頼性を提供することができないこともある。

さらに最近では、（以下で、「ＲＭ−ＷＳプロトコル」と呼ぶ）ウェブサービスの様々な信頼性のあるメッセージングプロトコル、例えばＷＳＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇが、現行の信頼性のあるメッセージングシステムの上で特定した欠陥に対するソリューションを提供している。これらのプロトコルは、ソフトウェアコンポーネント障害、システム障害、またはネットワーク障害の存在下において、エンドポイントアプリケーション間をメッセージが確実に配信され得るようにするトランスポート不可知論的（ｔｒａｎｓｐｏｒｔ ａｇｎｏｓｔｉｃ）接続プロトコルである。したがって、ＲＭ−ＷＳプロトコルは、イニシエータとアクセプタの間の信頼性のあるエンドツーエンドのセッション指向通信についてのソリューションを提供する。

これらのＲＭ−ＷＳプロトコルは、ＴＣＰが、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ルータおよび複数のネットワークにわたってＴＣＰ送信側からＴＣＰ受信側へのバイトのストリームの信頼性があり、正に一度だけの順序正しい配信を提供する点でＴＣＰに類似している。ＷＳについての信頼性のあるメッセージングプロトコルは、複数の仲介手段（ＳＯＡＰレベル仲介手段を含む）、トランスポートおよび接続にわたるメッセージについて同等以上のものを提供する（注：転送の単位は、メッセージであり、バイトではない）。ＴＣＰプロトコルもＲＭ−ＷＳプロトコルも共に「信頼性のある」プロトコルであるが、ＲＭ−ＷＳは、ＯＳＩモデルにおいてアプリケーション層またはＳＯＡＰ層に存在するので、ＲＭ−ＷＳプロトコルは、データを転送するのに使用されるトランスポートプロトコルに関係なく信頼性のあるメッセージングを提供する。したがって、ＲＭ−ＷＳプロトコルは、エンドポイント間でメッセージングを転送するのに使用される特定のトランスポートプロトコルまたは他のプロトコルに縛られない。

ここしばらくの間、いくつかのＲＭ−ＷＳプロトコルが存在しているが、これらのプロトコル仕様については、依然としていくつかの欠点および欠陥がある。例えば、エンドポイント間のメッセージのフロー制御については、これらのプロトコルによって定義されるソリューションは現在ない。通常、信頼性のあるメッセージ交換におけるアクセプタは、受信されたメッセージが処理アプリケーションに配信するために格納されるバッファを有している。これにより、システムにおける柔軟性が可能になる。というのは、処理アプリケーションは、プロセスメッセージが受信されると、利用可能になる必要はないからである。しかし、どのようなシステムも、そのシステムにとって利用可能な有限なリソースを有するにすぎないので（ハードウェアおよび／またはソフトウェアによって制限される）、このバッファは、容量に制限がある。このように、受信アプリケーションが、メッセージが送信および／または受信される速度よりも遅い速度でメッセージを処理している場合には、ある問題が生じる可能性がある。このような場合には、アクセプタバッファは、満杯になり、これらの受信メッセージは、トランスポートから読み取られないだろうし、脱落する可能性があり（これは、トランスポートからメッセージを読み取るが、スペースの不足のためにこのバッファ中に捕捉しないというアクションである）、それ故に、このメッセージについての受信肯定応答を送信しない。

メッセージの脱落は、典型的なＲＭ−ＷＳプロトコルによって許可され、致命的な障害とは考えられない。アクセプタからの受信肯定応答がないので、イニシエータは転送を再試行するであろう。しかし、再試行は、ネットワークおよびシステムリソースを浪費し、それ故に、イニシエータが、メッセージを脱落させることなくアクセプタにどれだけ多くのメッセージを送信できるかを知るための効率的なメカニズムについての必要性が生ずる。

上述のフロー制御問題と同様に、ネットワーク配線上の輻輳制御もまた、関心事である。通常、ネットワーク上で送信されるメッセージは、様々なノード、例えばルータによってブリッジされるいくつかのトランスポート接続を介して転送される。異なるトランスポート接続は、異なる速度となるかもしれない（例えば、イニシエータからノードへの１００ｍｂｐｓのイーサネット（登録商標））接続、およびこのノードからアクセプタへの５６ｋｂｐｓのダイアルアップ接続）。このトランスポート接続の速度の違いに起因して、ノードからアクセプタへの接続は、渋滞する可能性があり、これは、ネットワークが配信のための何ら新しいコンテンツを取り込むことができないことを意味しており、これはこのコンテンツの一部をまず取り除く必要があるからである。これは、ノードがそのリレー伝送の速度を落とし、着信メッセージをその宛先に送信できる前にバッファさせるようにしなければならないことを意味する。他のコンピューティングリソースと同様に、ノードは、新しい着信メッセージを脱落し始める必要がある前に、どれだけかのメッセージをバッファすることしかできない。バッファリングは、過渡的なトラフィックスパイクを処理するために受け入れることができる技法であるが、レイテンシを最小化するために、システムは、これらの仲介手段中で生じるバッファリングの量を最小化することを目指すべきである。さらに、メッセージを脱落させる他の理由には、すべてが同じ発信リンクを求めて競うノードに対する着信リンクの数、要求を処理するのが遅い受信側、またはそのノードにおけるアクティビティのバーストが含まれる。

信頼性のあるメッセージングシステムにおいて、これらのネットワーク脱落メッセージの理由にかかわらず、前述のように、脱落メッセージは配信を確実にするために再試行する必要がある。順序正しい配信が必要な場合には、シーケンス番号が脱落メッセージよりも大きいメッセージの処理は、この脱落メッセージが受信されるまで遅らされ、その結果、アクセプタ側で処理が非効率となるであろう。さらに、脱落メッセージの再試行により、イニシエータからノードに至るリンク上にさらに多くのメッセージがもたらされ、究極的には、さらに多くの脱落メッセージ、すなわち輻輳、性能障害、およびリソースの浪費がもたらされる可能性があろう。

したがって、フロー制御について調整するだけでなく、ネットワーク配線上の輻輳についての変化に適合するようにもするソリューションについての必要性が生じている。理解することができるように、この問題は、複数のノード、例えばルータが、イニシエータからアクセプタに至るパス上で用いられるシナリオにも拡張される。このように、ルータ数がイニシエータに未知であり、実際に時間と共に変化し得るので、ソリューションはルータ数を考慮に入れるべきではない。さらに、ソリューションは、ネットワークの帯域幅、性能、およびトポロジの変化に適合できるようにもすべきである。

ウェブサービスについての現行の信頼性のあるメッセージングプロトコルの上で特定した欠陥および欠点は、本発明の例示の実施形態に従って克服される。例えば、本発明は、アクセプタの利用可能なバッファサイズに基づいて、メッセージを送信するためのメッセージウィンドウサイズを動的に決定することにより、ＷＳ（ＲＭ−ＷＳ）についての信頼性のあるメッセージングプロトコルに従ってエンドポイント間でメッセージを効率的に転送することを提供する。さらに、本発明は、ネットワークの帯域幅、性能、およびトポロジの変化などの状況に適合させるために、ＲＭ−ＷＳプロトコルに従ってエンドポイントにメッセージを送信するための伝送ウィンドウを調整することにより、ネットワークの輻輳を制御することを提供する。

例えば、フロー制御を対象とした一実施形態は、ＲＭ−ＷＳプロトコルに従ってイニシエータとアクセプタの間のシーケンスセッションをアプリケーション層で確立することを提供する。予期されるバッファサイズ情報を含むメッセージが、このシーケンスセッションを介して受信される（アクセプタバッファサイズ情報は、アプリケーションによって処理されるために待っているメッセージをバッファするための利用可能なメモリの量を示している）。さらに、いくつかの伝送中のメッセージ（ｉｎ−ｆｌｉｇｈｔ ｍｅｓｓａｇｅ）が特定され、これらは、ＲＭ−ＷＳプロトコルに従って、対応する肯定応答を受信することなく、アクセプタに送信されたメッセージである。このアクセプタバッファサイズ情報および伝送中のメッセージの数に基づいて、バッファオーバーランに起因したメッセージの再送信を防止するためにアクセプタに送信することができるメッセージの数の上限を表すメッセージウィンドウサイズが計算される。

輻輳制御についての別の例としての実施形態においては、本発明は、ＲＭ−ＷＳプロトコルに従って、確立されたシーケンスセッションを介してアクセプタにメッセージウィンドウサイズに対応するいくつかのメッセージを送信することを提供する。このメッセージウィンドウサイズは、ネットワーク配線上でアクセプタに送信する伝送中のメッセージの数の上限を表している。メッセージウィンドウサイズに基づいて、これらいくつかのメッセージを送信してから、対応する肯定応答メッセージを受信するまでの予期される時間制限を定義する予期メッセージ転送時間が特定される。その後に、この予期メッセージ転送時間が満了する前に、対応する肯定応答メッセージが受信されたか否かについての指示が提供され、この指示は、ネットワーク輻輳に起因してメッセージを再送信することがないようにするためにメッセージウィンドウサイズおよび／または再試行期間を調整するのに使用される。

本発明の追加の特徴および利点については、以下に続く説明中で述べ、部分的にはこれらの説明から明らかになり、あるいは本発明を実施することにより確認することができよう。本発明の特徴および利点は、添付の特許請求の範囲において特に指摘した手段および組合せを用いて実現し、得ることができる。本発明のこれらおよび他の特徴については、以下の説明および添付の特許請求の範囲から、さらに十分に明らかとなり、あるいは以下で述べる本発明の実施により確認することができよう。

本発明の上で列挙した利点および特徴、ならびに他の利点および特徴を得ることができる態様について説明するために、上で簡単に説明した本発明のより詳細な説明を、添付図面中に例示されるその特定の実施形態を参照して表現することにする。これらの図面は、本発明の典型的な実施形態を示すにすぎず、それ故に本発明の範囲を限定するものと考えるべきではないことを理解して、本発明について、添付図面を使用することにより、さらに具体的にまた詳細に記述し説明することにする。

本発明は、ウェブサービス環境についての信頼性のあるメッセージングプロトコルにおけるフロー制御および輻輳制御のための方法、システムおよびコンピュータプログラム製品に拡張される。本発明の実施形態は、以下でさらに詳細に説明するように様々なコンピュータハードウェアを含む専用または汎用コンピュータを備えることができる。

本発明は、（以下で「ＲＭ−ＷＳ」プロトコルと呼ぶ）ウェブサービスについての信頼性のあるメッセージングプロトコルの拡張を対象としており、これは、ソフトウェアコンポーネント障害、システム障害、またはネットワーク障害の存在下において、分散されたアプリケーションの間でメッセージを確実に配信できるようにするプロトコルについて説明している。ウェブサービスについての信頼性のあるメッセージングプロトコルは、ソース（以下では「イニシエータ」）から、宛先、例えばサービス（以下では「アクセプタ」）へのメッセージの正常な伝送を容易にし、エラー状態が検出可能であるようにする。これらのプロトコルは、トランスポート不可知論的であり、それにより、これらのプロトコルは、異なるネットワーク転送技術を使用して実装することができるようにする。さらに、信頼性のあるメッセージングプロトコルの様々な実施形態は、そのアプリケーションから間欠的な通信障害を隠し、システム障害の場合における回復可能性を提供することができる。

例としての実施形態は、アクセプタの利用可能なバッファサイズに基づいて、メッセージを送信するためのメッセージウィンドウサイズを動的に決定することにより、ＲＭ−ＷＳプロトコルを使用してこれらのメッセージの効率的な転送を提供する。より詳細には、本発明は、このアクセプタが、このアクセプタバッファ中にどれだけの余裕があるかをイニシエータに知らせるフロー制御メカニズムを提供する。このアクセプタバッファサイズ情報は、応答メッセージ中に、例えばインフラストラクチャ肯定応答メッセージ中に含まれ、次いでこの情報は、イニシエータによって使用されて、メッセージウィンドウサイズを計算する。次いで、この計算されたウィンドウサイズは、バッファオーバーランに起因したメッセージの再送信を防止するために、アクセプタに送信することができるメッセージの数の上限を定義する。

図１Ａは、上述の例のフロー制御の実施形態を示している。図１Ａは、イニシエータ１０５およびアクセプタ１２０を含む分散ネットワーク１００を示している。イニシエータ１０５とアクセプタ１２０の間に、ＲＭ−ＷＳプロトコルに従ってメッセージを交換するための接続が確立される。確立されると、アクセプタ１２０は、メッセージ（例えばインフラストラクチャメッセージ１１５）内のそのバッファサイズについての情報をイニシエータ１０５に定期的に送信することができる。アクセプタバッファサイズ情報は、アプリケーション１３５によって処理されるために待っているバッファされたメッセージ１８５のために利用可能なメモリ１３０の量を示すことになる。

通常、インフラストラクチャメッセージ１１５を使用して、アクセプタバッファサイズ情報をイニシエータ１０５に送信することになるが、アプリケーション層メッセージ（例えば、アクセプタからの出力として送信されるメッセージ）は、アクセプタ１２０についてのメモリの利用可能なサイズを特定する拡張を含むこともできることに留意されたい。さらに、インフラストラクチャメッセージ１１５は、通常、ＲＭ−ＷＳプロトコルによる肯定応答メッセージになるであろう。しかし、本発明は、特定のどのようなタイプのインフラストラクチャメッセージ１１５にも限定されることはない。したがって、アクセプタバッファサイズ情報を配信する際に、インフラストラクチャメッセージ１１５（ならびに言及したどの特定のタイプのインフラストラクチャメッセージ）の使用については、例示の目的のためだけに使用され、明示的に主張しない限り、本発明の範囲を限定し、またはその他に狭めることを意味していない。

メッセージのタイプに関係なく、インフラストラクチャメッセージ１１５内のアクセプタバッファサイズの指示を受信すると、イニシエータ１０５は、バッファサイズ情報によって示されるメッセージの数まで送信することができる。換言すれば、アクセプタメモリ１３０は、アプリケーション１３５によって処理されるために待っているある数のバッファされたメッセージ１８５をすでに有している。したがって、メッセージが脱落させられる前にイニシエータ１０５がアクセプタ１２０に送信することができるメッセージの最大数は、メモリ１３０内の利用可能なバッファサイズによって決まる。

インフラストラクチャメッセージ１１５内のアクセプタバッファサイズ情報は、イニシエータ１０５がアクセプタ１２０に送信することになるメッセージ数の上限であることに留意されたい。しかし、この上限は、伝送中のメッセージの数、以前に受信した肯定応答の数、現在肯定応答されているメッセージの数などの状況に基づいて修正されることもある。例えば、イニシエータ１０５は、伝送中のメッセージ１２５の数を特定することができ、これは、ＲＭ−ＷＳプロトコルに従って、対応する肯定応答を受信することなく、アクセプタに送信されたメッセージである。これらの伝送中のメッセージ１２５は、アクセプタ１２０によって脱落され、または配線上で失われたメッセージでもよい。伝送中のメッセージ１２５はまた、アクセプタ１２０によって受信されるが、これらのメッセージについての肯定応答が失われたか、または以下で説明する計算前のイニシエータ１０５への移動中のメッセージでもよい。別の可能性は、伝送中のメッセージ１２５が、このネットワーク中の仲介手段、例えばルータまたはＳＯＡＰ仲介手段において遅延される場合もあることである。

いずれにしても、伝送中のメッセージ１２５の数を知ると、イニシエータ１０５は、ウィンドウサイズ計算モジュール１１０を利用して、メッセージウィンドウサイズ１５５を計算するときに、利用可能なアクセプタバッファサイズから伝送中のメッセージ１２５の数を差し引くことができる。前述のように、メッセージウィンドウサイズ１５５は、バッファオーバーランに起因したメッセージの再送信を防止するために、アクセプタ１２０に送信することができるメッセージの数の上限を表している。

インフラストラクチャメッセージ１１５内のバッファ情報サイズは、通常バイトではなく、メッセージの数に関することに留意されたい。同様に、メッセージウィンドウサイズ１５５もまた、特定のバイトサイズではなくメッセージの数に関することがある。さらに、イニシエータ１０５は、送信したメッセージ、例えば伝送中のメッセージ１２５の数と、アクセプタ１２０のメモリ１３０で利用可能なスペースの数を追跡するので、イニシエータは、アクセプタ１２０の側に利用可能な余裕がどれだけあるかを常に知っている。したがって、イニシエータ１０５は、処理アプリケーション１３５のメッセージ処理速度を推定しようせず、むしろアクセプタがどれだけの数のメッセージをバッファできるかをイニシエータに伝えるアクセプタ１２０に依存している。これにより、ウィンドウサイズ計算モジュール１１０は、コンスタントレート処理やランダムバースト処理など任意の処理レート下で機能する。

他の例としての実施形態は、インフラストラクチャメッセージ１１５、例えば肯定応答メッセージが信頼性のない（すなわち、アクセプタからイニシエータへの移動中に失われることがある）という事実から生ずる問題に対処する。このような実施形態においては以下でさらに詳細に説明するように、メッセージウィンドウサイズ１５５がゼロに等しいときに、イニシエータ１０５は、この特定のＲＭ−ＷＳプロトコルに従って、例えば肯定応答要求メッセージを送信することによって利用可能なスペースについて定期的にプローブすることができる。この肯定応答要求メッセージに応答して、対応する１つ（または複数）の肯定応答は、通常、現在のアクセプタバッファサイズ情報を含むことになる。

バッファサイズ情報および伝送中のメッセージ１２５の数以外の情報は、メッセージウィンドウサイズ１５５を計算する際にウィンドウサイズ計算モジュール１１０によって利用することができることに留意されたい。例えば、インフラストラクチャメッセージ１１５が肯定応答メッセージであるときに、肯定応答される現在のメッセージの数はまた、メッセージウィンドウサイズ１５５を低減する際に使用することもできる。さらに、バッチ肯定応答の場合には、以前に受信された肯定応答の数も、同様に使用される必要があるかもしれない。

以下は、例示の実施形態による、メッセージウィンドウサイズ１５５を計算するために使用することができるアルゴリズムの一例である。イニシエータ１０５とアクセプタ１２０の間の通信の開始時には、この受信されたウィンドウサイズは、１に等しいものと想定され、伝送中のメッセージの数はゼロに等しいものとする。さらに、以前に受信された肯定応答もまた、ゼロに設定される。イニシエータ１０５の側では、アルゴリズムは、以下のように見えるかもしれない。メッセージウィンドウサイズ１５５がゼロよりも大きい場合、イニシエータ１０５は、メッセージを送信し、伝送中のメッセージカウントを１だけ増加し、同様にメッセージウィンドウサイズ１５５を１だけ減少することができる。

他方、この受信されたウィンドウサイズがゼロに等しい場合には、例としての実施形態は、このウィンドウサイズの再計算結果がゼロよりも大きくなるまで、メッセージの送信をブロックする。このウィンドウサイズがゼロよりも大きいときには、前述のプロセスが繰り返される。

肯定応答またはインフラストラクチャメッセージ１１５を受信すると、この例としてのアルゴリズムは、以下を行う。最初に、メッセージ１１５からアクセプタバッファサイズ情報を抽出することになる。さらに、ウィンドウサイズ計算モジュール１１０は、現在肯定応答されているメッセージの数を計算する。このように、計算モジュール１１０は、新しい肯定応答の数を決定する必要があるかもしれず、これは、現在肯定応答されているメッセージから以前に受信された肯定応答を差し引いた数に等しい。この最後の計算は、ＲＭ−ＷＳプロトコルが肯定応答をバッチ処理する場合についても必要とされ得ることに留意されたい。しかし、本発明は、必ずしもこのようなバッチ処理プロセスだけに限定されない。したがって、以前に受信された肯定応答と現在肯定応答されているメッセージの数の差を取ることによって、新しい肯定応答の数の計算は、例示の目的のためだけに使用され、明示的に主張しない限り、本発明の範囲を限定し、またはその他の点で狭めることを意味するものではない。

それにもかかわらず、新しい肯定応答の数が使用される場合には、伝送中のメッセージ１２５は、以前に送信されたメッセージの数から新しい肯定応答の数を差し引いたものを含む。さらに、以前に受信された肯定応答数は、今や現在肯定応答されている（先と同様に、バッチ肯定応答の場合の）メッセージに等しくなる。最終的に、メッセージウィンドウサイズ１５５は、ウィンドウサイズ計算モジュール１１０を使用して計算される、アクセプタバッファサイズ情報から伝送中のメッセージ１２５の数を差し引いたものに等しくなる。

以下の例は、上述のメッセージウィンドウサイズ追跡プロセスを示している。この例においては、イニシエータ１０５は、アクセプタ１２０に対して１０個のメッセージを送信し、これらの１０個のメッセージについての１つの肯定応答１１５をちょうど受信したところであり、これは、アクセプタ１２０が５個のメッセージをバッファできることを示すアクセプタバッファサイズ情報を含んでいる。イニシエータ１０５は、メッセージ１１ないし１５を送信し、それ以上のメッセージを送信するのを停止する。次に、イニシエータ１０５は、メッセージ１ないし１３についての肯定応答１１５、および５個分のスペースがアクセプタ１２０の受信メモリ１３０で利用可能であることを示すアクセプタバッファサイズ情報を受信する。２個のメッセージが、アクセプタ１２０への伝送中のメッセージ１２５であることを知って、イニシエータ１０５は、このアクセプタに対してさらに３個のメッセージしか送信せず、次いでより多くのスペースが利用可能になるのを待つであろう。

別の例としての実施形態は、接続ごとに基づいて、動的に構成可能なメモリ１３０のバッファサイズを利点として提供する。この機能により、高い（または低い）バッファリングニーズを有するイニシエータ１０５のためにメモリ１３０を適切に割り振ることにより、このフローを、接続ごとに最適に達成することができるようにシステムリソースのバランス化を可能にする。受信側でメッセージをバッファするハードコード化されたメモリ割り振りを有するＴＣＰと違って、例としての実施形態は、アクセプタ１２０のメモリ１３０の容量（すなわち、この接続のために割り振る総バッファサイズ）がイニシエータ１０５の処理速度、この要求の複雑さなどの状況に基づいて構成可能にすることができる。

例えば、定期的に１つのメッセージしか送信しないイニシエータ１０５に対する確立された接続は、バッファされたメッセージ１８５のために大きな容量のメモリ１３０を必要としないであろう。したがって、イニシエータ１０５とアクセプタ１２０の間のネゴシエーションが、イニシエータ１０５の特定のニーズ、およびメモリ１３０の対応する割り振りを決定するために行われ得る。さらに、このネゴシエーションプロセスは、様々な分散デバイス間でメモリ１３０のリソースを適切にバランス化させるために、確立された接続ごとに行うことができる。

他の例としての実施形態は、ネットワークの帯域幅、性能およびトポロジの変化などの状況に適合させるために、エンドポイントにメッセージを送信するための伝送ウィンドウおよび／または再試行期間を調整することにより、輻輳制御を提供する。このメカニズムは、メッセージが送信される時点から、対応する肯定応答が受信される時点までに経過するラウンドトリップタイムを測定することを伴う。以下は、どのようにこの輻輳制御プロセスが機能し得るかについての一例の簡単な説明である。

最初に、例示の実施形態は、所望のまたは最適なレートに近い近似レートを、積極的に求める。本発明は、例えば、障害ポイントが見つかるまで伝送中のメッセージの数を指数関数的に増大させることにより、それを行う。この障害ポイント以下の最後の正常レートは、最適ポイントに対する最も近い既知のポイントである。次いで、例としての実施形態は、リセットを行い、再び（例えば、指数関数的なレートの増大を使用して）このレートを最後の既知の良好なポイントまで上げて、最適レートに漸近させるアルゴリズムを使用してそこからの微調整を行う。

図１Ｂは、上で特定された実施形態の一部を行うためのネットワーク１００を示している。図に示すように、イニシエータ１０５は、第１の数のメッセージ１７５をアクセプタ１２０に送信することができる。アクセプタ１２０が第１の数のメッセージ１７５を受信すると、第１の肯定応答１６５がイニシエータ１０５に送信される。第１の肯定応答１６５を受信すると、どのようにメッセージウィンドウサイズ１５５を調整すべきか、および／または再試行期間を（さらに速くまたはさらに遅く）調整すべきかを決定するために、メッセージ転送時間比較モジュール１４０を利用することができる。

例えば、メッセージ転送時間比較モジュール１４０は、予期メッセージ転送時間を決定し、これは、これらいくつかの第１のメッセージ１７５を送信してから、イニシエータ１０５において対応する第１の肯定応答１６５を受信するまでの予期されるタイムリミットを定義する。換言すれば、メッセージ１７５をアクセプタ１２０に送信してから、イニシエータ１０５において対応する肯定応答１６５を受信するまでの期待ラウンドトリップタイムによって定義される予期メッセージ転送時間が存在する。以下でさらに詳細に説明するように、通常この予期メッセージ転送時間は、メッセージウィンドウサイズ１５５に基づくことになり、これは、ネットワーク配線上でアクセプタに送信される伝送中のメッセージの数の上限を表す。

メッセージ転送時間比較モジュール１４０がこの予期メッセージ転送時間を決定すると、第１の数のメッセージ１７５をアクセプタ１２０に送信してから、第１の肯定応答１６５を受信するまでの実際の時間とこの予期メッセージ転送時間を比較する。第１の肯定応答１６５が、予期メッセージ転送時間が満了する前に受信される場合、メッセージ転送時間比較モジュール１４０は、メッセージウィンドウサイズ調整モジュール１４５に成功指示を与えることになる。したがって、メッセージウィンドウサイズ調整モジュール１４５は、メッセージウィンドウサイズ１５５を増大させ、この成功を最後の既知の良好な値１８０としてメモリ１５０に記録することになる。換言すれば、以前のメッセージウィンドウサイズ１５５は、最後の既知の良好な値１８０として記録され、以前のメッセージウィンドウサイズ１５５は、あるファクタだけ、通常は指数関数的な増大分だけ増大される。次いで、この増大されたメッセージウィンドウサイズ１５５に対応する第２の数のメッセージ１７０が、アクセプタ１２０に送信され、第２の１つ（または複数）の肯定応答１６０が、第２の数のメッセージ１７０について受信され、プロセスは、障害が起こるまで継続される。

他方、予期メッセージ転送時間が、第１の肯定応答１６５（または、１７０の場合には第２の肯定応答）を受信する前に経過する場合には、メッセージ転送時間比較モジュール１４０は、メッセージウィンドウサイズ調整モジュール１４５に対して失敗指示を与えることになる。このような場合には、失敗指示は、いくつかの出来事が発生したことを示唆し得ることに留意されたい。例えば、これらの送信されたメッセージ（第１の数のメッセージ１７５、または増大された第２の数のメッセージ１７０）が失われた可能性がある。あるいは、またはこれと関連して、これらの送信されたメッセージ１７５、１７０についての１つまたは複数の対応する肯定応答メッセージ１６５、１６０が失われるか、あるいは予期メッセージ転送時間が満了した後に受信されることもある。

いずれにしても、メッセージウィンドウサイズ調整モジュール１４５は、通常、メモリ１５０に格納された最後の既知の良好な値１８０よりも小さなある値までメッセージウィンドウサイズ１５５を減少させ、そして／または再試行期間を増大させる（すなわち、メッセージを再試行するために待つ持続期間を長くする）ことになる。例示の実施形態は、メッセージウィンドウサイズ１５５を最後の既知の良好な値１８０より小さなある値に減少させるが、本発明はこの特定の実施形態だけには限定されないことに留意されたい。例えば、メッセージウィンドウサイズ調整モジュール１４５は、成功が達成されるまで、メッセージウィンドウサイズ１５５を徐々に減少させることもでき、これは、最後の既知の良好な値１８０であっても、そうでなくてもよい。同様に成功指示を受信したときのメッセージウィンドウサイズ１５５の上述の増大については、必ずしも指数関数的増大である必要があるとは限らず、その小さな増分とすることもできる。実際に、以下でさらに詳細に説明するように、微調整および他の目的のために、メッセージウィンドウサイズ１５５を調整するための異なるアルゴリズムを使用することもできる。したがって、この成功指示または失敗指示に基づいた、ウィンドウサイズ１５５のどの特定の増大または減少も、例示の目的のためだけに使用され、明示的に主張しない限り、本発明の範囲を限定し、またはその他の点で狭めることを意味するものではない。

それにもかかわらず、失敗指示がメッセージウィンドウサイズ調整モジュール１４５において受信されるときに、例としての実施形態は、メッセージウィンドウサイズ１５５が１のサイズまで縮小することになることを提供する。その後に、メッセージ１７５、１７０を転送するための連続的な試みは、メッセージウィンドウサイズ１５５を最後の既知の良好な値１８０まで指数関数的に増大させることになる。メッセージウィンドウサイズ１５５の過激な減少は、伝送レートの低下を引き起こし、この指数関数的増大プロセスをその初期状態へと事実上リセットすることに留意されたい。しかし、イニシエータ１０５によってメッセージを送信するための実際のバッファサイズは、縮小せず、送信するためにすでにバッファされているメッセージは、バッファから取り除かれないかもしれないが、新しいメッセージは、インフラストラクチャによって受け入れられず（すなわち、送信オペレーションがブロックされ）、イニシエータ１０５を事実上減速させることになる。このバッファ中のメッセージ数が、有効なメッセージウィンドウサイズ１５５よりも小さくなると、新しいメッセージは、このインフラストラクチャによって受け入れることができる。

上述のリセットの後に、イニシエータ１０５のバッファ中の最も古いメッセージを再送信する試みが行われ、新しい予期メッセージ転送時間が設定される。この再送信されたメッセージについての対応する肯定応答を受信する前に、新しい予期メッセージ転送時間が満了する場合、例としての実施形態は、予期メッセージ転送時間を２倍にし、再試行することを提供する。このプロセスは、正常状態に達するまで、または構成可能な試行回数が行われるまで、繰り返して行うことができ、この場合には、この転送は、不成功と宣言することができ、イニシエータ１０５のアプリケーションにエラーを提起することができる。この実施形態は、効果的にメッセージバックオフ再試行メカニズムを実施し、これにより、ネットワーク１００上の輻輳も正常化され、または定常状態に到達することができるようになる。

正常な転送を受信すると、メッセージウィンドウサイズ１５５およびメッセージについての転送レートの増大を上述のようにこの場合も試みることができる。前述のように、最後の試みの間に学習されたことを適用するために、例示の実施形態は、メッセージウィンドウサイズ１５５を最後の既知の良好な値１８０まで積極的に増大させることを提供する。このポイントにおいて、メッセージウィンドウサイズ調整モジュール１４５は、アルゴリズムを変更して、試み、最適なポイントを見出す。例えば、実施形態は、以下のような漸近アルゴリズム（およびメッセージウィンドウサイズ１５５の日和見主義的増大（ｏｐｐｏｒｔｕｎｉｓｔｉｃ ｉｎｃｒｅａｓｅ））を提供する。メッセージウィンドウサイズについての最後の既知の良好な値１８０に到達するときに、メッセージウィンドウサイズ調整モジュール１４５は、最後の失敗したメッセージウィンドウサイズ１５５と最後の既知の良好な値１８０の間のポイントについて、最適ポイントを推測しようと試みて、この差をあるファクタによって除算することにより、ピックすることができる。この値が高すぎる（すなわち、最適レートを超過しており、メッセージが失われるか、または過度に遅延される）場合には、メッセージウィンドウサイズ調整モジュール１４５は、このファクタをより低い値に再調整する。

もちろん、メッセージウィンドウサイズ１５５を微調整し、または調整するために使用することができる他の特定の実装形態またはアルゴリズムも存在する。例えば、最後の既知の良好な値１８０に到達した後に、メッセージウィンドウサイズ調整モジュール１４５は、最適サイズが達成されるまで、メッセージウィンドウサイズ１５５を単純に付加的に増大させることもできる。したがって、前述のように、特定の任意のアルゴリズムの使用により、最適なメッセージウィンドウサイズ１５５を積極的に近似したり、またはメッセージウィンドウサイズ１５５を微調整したりすることは、例示の目的のためだけに使用され、明示的に主張しない限り、本発明の範囲を限定し、またはその他の点で狭めることを意味するものではない。

最適なメッセージウィンドウサイズ１５５が決定されると、他の例としての実施形態はまた、帯域幅の増大に向けて調整するために、最適値を増大しようと定期的に試みることも提供する。さらなる例としての実施形態は、ネットワーク１００にわたる帯域幅の減少を示す障害が起こるときを検出することを提供する。このような場合には、メッセージウィンドウサイズ１５５は、リセットすることができ、上述した増大プロセスは、最後の既知の良好な値１８０にまで増大させることができ、微調整プロセスをこの場合にも実施することができる。最後の既知の良好な値１８０が失敗する場合には、例としての実施形態は、以前の最後の既知の良好な値、すなわちこの最後の既知の良好な値の直前の値を決定することを提供することに留意されたい。次いで、この以前の値は、最後の既知の良好な値１８０に代えることができ、前述のプロセスを継続することができる。

障害を検出するために、以上で指摘したように、例示の実施形態は、転送時間、すなわちメッセージを送信してから、それについての肯定応答を受信するまでにかかる時間を測定する。この問題は、１つの肯定応答が、複数のメッセージの受信について肯定応答するように、ＲＭ−ＷＳプロトコルにより、アクセプタ１２０が肯定応答を集約できるようにする場合には複雑になる。したがって、例としての実施形態は、対応するバッチ化された肯定応答が受信されるまで、メッセージウィンドウサイズ１５５に対応するこれらメッセージのそれぞれを転送するために経過した時間を追跡する。次いで、実際の転送時間が、このラウンドトリップタイムの集約分布の平均および／または分散を用いて計算される。

ラウンドトリップタイムの分散は、このバッチで肯定応答されるメッセージの数に依存することになるので、予期メッセージ転送時間は、メッセージウィンドウサイズ１５５に基づいて変化するはずである。換言すれば、予期メッセージ転送時間は、メッセージウィンドウサイズ１５５が増大するにつれて、通常、増大することになる。しかし、例えば、メッセージを送信することと、このメッセージについての肯定応答を受信することの間の１対１対応が実装される場合に、予期メッセージ転送時間は、必ずしもメッセージウィンドウサイズ１５５に基づく必要があるとは限らないことに留意されたい。したがって、予期メッセージ転送時間をメッセージウィンドウサイズ１５５に基づくことは、例示の目的のためだけに使用され、明示的に主張しない限り、本発明の範囲を限定し、またはその他の点で狭めることを意味するものではない。

以下の例は、上述の様々な実施形態を示している。この例においては、メッセージウィンドウサイズ１５５は、１のウィンドウサイズ、すなわち１つのメッセージのみがイニシエータ１０５からアクセプタ１２０への伝送中のメッセージであるウィンドウサイズで開始することができる。したがって、メッセージ番号１は、アクセプタ１２０によって受信することができ、対応する肯定応答メッセージ番号１は、イニシエータ１０５によって受信することができる。次いでメッセージ転送時間比較モジュール１４０は、このラウンドトリップタイムを測定し、この特定のメッセージウィンドウサイズ１５５について予期メッセージ転送時間に対して比較する。この比較について成功がもたらされるとすると、メッセージウィンドウサイズ調整モジュール１４５は、メッセージウィンドウサイズ１５５を２に増大し、ここで、メッセージ番号２および３が送信され、これらのメッセージについての肯定応答が、イニシエータ１０５によって受信される。この場合にも、正常な転送時間を仮定すると、メッセージウィンドウサイズ調整モジュール１４５は、メッセージウィンドウサイズ１５５を４に増大することになり、ここで、メッセージ番号４ないし７が送信され、対応する肯定応答が受信される。このプロセスは、障害が検出されるまで継続される。

８のメッセージウィンドウサイズ１５５の次の増大が障害を引き起こす場合、このアルゴリズムは再開され、最後の既知の良好な値１８０まで積極的に増大され、これは、この場合には４であった。次いでこの漸近アルゴリズムは、最後の既知の良好な値１８０に、あるデルタを、すなわち最後の既知の良好な値１８０（すなわち、４）と障害ポイント（すなわち、８）の間の変化をあるファクタで除算した値を加えたものに等しい初期値と共に使用される。例えば、このファクタが２である場合には、メッセージウィンドウサイズ１５５は、６（すなわち、４＋（８−４）／２＝６）になる。この６の値が失敗すると、次いで、このプロセスは、５というメッセージウィンドウサイズ１５５に従ってメッセージの送信を試み、ここで、もし成功なら、５が最適な選択であり、もし失敗なら、４が最適な選択となる。

本発明はまた、機能的ステップ（ｆｕｎｃｔｉｏｎａｌ ｓｔｅｐ）および／または非機能的アクト（ｎｏｎ−ｆｕｎｃｔｉｏｎａｌ ａｃｔ）を備える方法の点から説明することもできる。以下は、本発明を実施する際に行うことができるステップおよび／またはアクトの説明である。通常、機能的ステップは、達成される結果の点で本発明を説明するのに対して、非機能的アクトは、特定の結果を実現するためのさらに特定のアクションを説明する。この機能的ステップおよび／または非機能的アクトは、特定の順序で記述または主張することができるが、本発明は、必ずしもステップおよび／またはアクトのどの特定の順序または組合せにも限定されない。さらに、請求項の引用における（また図２および３についてのフローチャートの以下の説明における）ステップおよび／またはアクトの使用については、当該用語の所望の特定の使用を示すために使用される。

図２および３は、本発明の様々な例示の実施形態についてのフローチャートを示している。図２および３の以下の説明では、ときに図１Ａおよび１Ｂからの対応するエレメントについて言及することになる。これらの図面からの特定のエレメントに対して参照を行うことができるが、このようなエレメントは、例示の目的のためだけに使用され、明示的に主張しない限り、本発明の範囲を限定し、またはその他の点で狭めることを意味するものではない。

図２は、アクセプタの利用可能なバッファサイズに基づいてメッセージを送信するためのメッセージウィンドウサイズを動的に決定することにより、ＲＭ−ＷＳプロトコルに従って、エンドポイント間で効率的にメッセージを転送するための方法２００のフローチャート例を示している。方法２００は、シーケンスセッションを確立するアクト２０５を含んでいる。例えば、図１Ａに示すように、アプリケーション層（例えば、ＳＯＡＰ層）におけるシーケンスセッションは、ＲＭ−ＷＳプロトコル（例えば、ＷＳＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇ）に従ってイニシエータ１０５とアクセプタ１２０の間に確立することができる。方法２００は、このシーケンスセッションを介してＲＭ−ＷＳメッセージを受信するアクト２１０も含んでいる。例えば、イニシエータ１０５は、アクセプタ１２０からアクセプタバッファサイズ情報を含むメッセージ１１５を受信することができ、この情報は、アプリケーション１３５によって処理されるために待っているメッセージ１８５をバッファするために利用可能なメモリ１３０の量を示す。通常、メッセージ１１５は、インフラストラクチャメッセージ、例えば肯定応答メッセージ１１５になるであろう。

その後に、方法２００は、伝送中のメッセージの数を特定するアクト２１５をさらに含んでいる。すなわち、イニシエータ１０５は、ＲＭ−ＷＳプロトコルに従って、対応する１つ（または複数）の肯定応答を受信することなくアクセプタに送信された伝送中のメッセージ１２５の数を決定することができる。このアクセプタバッファサイズ情報および伝送中のメッセージの数に基づいて、方法２００は、メッセージウィンドウサイズを計算するアクト２２５をさらに含んでいる。例えば、ウィンドウサイズ計算モジュール１１０を使用して、インフラストラクチャメッセージ１１５内のアクセプタバッファサイズ情報、および伝送中のメッセージ１２５の数に基づいてメッセージウィンドウサイズ１５５を計算することができる。メッセージウィンドウサイズ１５５は、アクセプタ１２０上のバッファオーバーランに起因したメッセージの再送信を防止するために、アクセプタに送信することができるメッセージ数の上限を表している。

例示の実施形態は、このウィンドウサイズがゼロより大きい場合、この計算されたメッセージウィンドウサイズ１５５に対応するいくつかのメッセージをアクセプタ１２０に送信できることを提供する。他方、メッセージウィンドウサイズ１５５がゼロである場合には、例示の実施形態は、インフラストラクチャメッセージ（または他のメッセージ）が受信され、使用されてメッセージウィンドウサイズ１５５がゼロより大きいことが計算されるまで、メッセージが送信されないようにブロックすることを提供する。このインフラストラクチャメッセージが、ＲＭ−ＷＳプロトコルによる肯定応答メッセージ１１５である場合には、他の例示の実施形態は、肯定応答要求メッセージをアクセプタ１２０に定期的に送信することを提供する。これに応答して、メッセージウィンドウサイズ１５５を再計算するためのアクセプタバッファサイズ情報を含む肯定応答メッセージ１１５を受信することができる。したがって、再計算されたメッセージウィンドウサイズ１５５がゼロより大きいときに、再計算されたメッセージウィンドウサイズ１５５に対応するいくつかのメッセージを送信することができる。

前述のように、このバッファ情報は、送信されるべきメッセージの数に関するものであり、メモリ中の利用可能なバイトの数に関するものとすることができる。さらに例としての実施形態は、アプリケーションによって処理されるために待っているメッセージをバッファするために割り振られたアクセプタの総メモリが接続ごとに動的に構成可能であることを提供する。さらに、このメッセージウィンドウサイズ１５５の計算は、さらにこの肯定応答メッセージ、および／または以前に送信されたメッセージについての以前に受信された肯定応答中で肯定応答されたメッセージの数に基づいてもよい。

図３は、ネットワークの帯域幅、性能およびトポロジの変化などの状況に適合させるために、ＲＭ−ＷＳプロトコルに従ってエンドポイントにメッセージを送信するために伝送ウィンドウを調整することにより、ネットワークの輻輳を制御するための方法３００のフローチャート例を示している。方法３００は、第１の数のメッセージを送信するアクト３０５を含んでいる。例えば、図１Ｂに示すように、イニシエータ１０５は、ＲＭ−ＷＳプロトコル（例えば、ＷＳＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇ）に従って確立されたシーケンスセッションを介して第１の数のメッセージ１７５をアクセプタ１２０に送信することができる。この第１の数のメッセージ１７５は、メッセージウィンドウサイズ１５５に対応しており、ここで、メッセージウィンドウサイズ１５５は、ネットワーク配線上でアクセプタ１２０に送信される伝送中のメッセージの数の上限を表している。

方法３００はまた、メッセージウィンドウサイズを調整するステップ３２０を含んでいる。ステップ３２０は、予期メッセージ転送時間を特定するアクト３１０を含んでいる。例えば、メッセージ転送時間比較モジュール１４０を使用して、予期メッセージ転送時間を特定することができ、これは、いくつかのメッセージを送信してから、対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する。ステップ３２０はまた、対応する肯定応答メッセージが受信されたか否かについての指示を提供するアクト３１５も含んでいる。例えば、メッセージ転送時間比較モジュール１４０は、予期メッセージ転送時間が満了する前に、対応する肯定応答メッセージ１６５が受信されたか否かを示す指示をメッセージサイズ調整モジュール１４５に提供することができる。次いでメッセージウィンドウサイズ調整モジュール１４５は、ネットワーク輻輳に起因するメッセージの再送信を防止するために、メッセージウィンドウサイズ１５５および／または再試行期間を調整するためのこの指示を使用することができる。

他の例示の実施形態は、メッセージウィンドウサイズ１５５の調整が、予期メッセージ転送時間が満了する前に、対応する１つ（または複数）の肯定応答メッセージ１６５が受信されたことを示す、メッセージウィンドウサイズ１５５の増大であることを提供する。メッセージウィンドウサイズ１５５の増大後に、他の例示の実施形態は、この増大されたメッセージウィンドウサイズ１５５に対応する増大された数のメッセージを送信することを提供する。例えば、第２の数のメッセージ１７５をイニシエータ１０５からアクセプタ１２０に送信することができ、ここで、この増大されたメッセージウィンドウサイズ１５５に基づいてメッセージ転送時間比較モジュール１４０は、第２の予期メッセージ転送時間を特定することができる。この増大された予期メッセージ転送時間は、増大された数のメッセージ１７０を送信してから、１つまたは複数の対応する肯定応答メッセージ１６０を受信するまでの予期されるタイムリミットを定義している。

その後に、メッセージ転送時間比較モジュール１４０は、第２の予期メッセージ転送時間が満了する前に、この増大された数のメッセージ１７０についての１つまたは複数の対応する肯定応答メッセージ１６０が受信されたか否かについての指示を提供することができる（注：第２の予期メッセージ転送時間は、通常、送信されるメッセージの数の増大に起因して、以前の値から増大されることになる）。一実施形態において、このメッセージウィンドウサイズ調整モジュールは、増大されたメッセージウィンドウサイズを減少させるが、これは以下の、増大された数のメッセージ１７０の１つまたは複数のメッセージが失われたこと、増大された数のメッセージ１７０についての対応する肯定応答メッセージ１６０の１つまたは複数のメッセージが失われ、そして／または第２の予期メッセージ転送時間が満了した後に、受信されたことの少なくとも１つを示している。増大されたメッセージウィンドウサイズの減少により、メッセージウィンドウサイズと増大されたメッセージウィンドウサイズの間のサイズとすることができる。

他の例としての実施形態において、メッセージウィンドウサイズ１５５は、最後の既知の良好な値１８０と考えられ、メモリ１５０に記憶されており、ここで増大されたメッセージウィンドウサイズ１５５の減少については、メッセージウィンドウサイズ１５５よりも小さく、これが減少されたメッセージウィンドウサイズ１５５という結果になる。さらに他の例示の実施形態は、減少されたメッセージウィンドウサイズ１５５に対応する減少された数のメッセージを送信することを提供する。この減少されたメッセージウィンドウサイズ１５５に基づいて、第２の予期メッセージ転送時間が特定され（注：減少された数のメッセージが送信されているが、第２の予期メッセージ転送時間は、以前の予期されたメッセージ転送から増大したものとしてネットワーク輻輳を補償することもできる）、これは、減少された数のメッセージを送信してから、対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義している。その後に、第２の予期メッセージ転送時間が満了する前に、減少された数のメッセージについての１つまたは複数の対応する肯定応答メッセージが受信されたことを示す指示を提供することができる。このように、メッセージウィンドウサイズ１５５のサイズ（すなわち、最後の既知の良好な値１８０）をメモリ１５０から取り出すことができ、次いで減少されたメッセージウィンドウサイズ１５５は、メッセージウィンドウサイズ１５５まで増大される。

その後に、例示の実施形態は、メッセージウィンドウサイズ１５５の単一調整（すなわち、付加的な増大および減少）により、メッセージウィンドウサイズ１５５を微調整することを提供する。他の例示の実施形態は、メッセージウィンドウサイズ１５５が最後の既知の良好な値であると考えられ、増大されたメッセージウィンドウサイズの減少により、メッセージウィンドウサイズ１５５になることを提供する。

他の例示の実施形態は、対応する肯定応答メッセージを単一のメッセージ中にバッチ化することができることを提供する。このような場合には、予期メッセージ転送時間は、このいくつかのメッセージを送信してから、単一のメッセージを受信するまでの予期メッセージ転送タイムリミットについての平均および／または分散に基づいている。

本発明の範囲内の実施形態はまた、コンピュータ実行可能命令を有するコンピュータ読取り可能媒体またはその媒体上に記憶されたデータ構造も含まれる。このようなコンピュータ読取り可能媒体は、汎用または専用コンピュータによってアクセスできる任意の利用可能な媒体とすることができる。限定ではなく一例として、このようなコンピュータ読取り可能媒体は、汎用または専用コンピュータによってアクセスすることができるコンピュータ実行可能命令またはデータ構造の形態で所望のプログラムコード手段を担持または記憶するために使用することができる、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは任意の他の媒体を含むことができる。情報が、（ハードワイヤ、ワイヤレス、あるいはハードワイヤまたはワイヤレスの組合せによる）ネットワークまたは他の通信接続を介してコンピュータに転送または提供されるときに、このコンピュータは、この接続をコンピュータ読取り可能媒体として見ることが適切である。このように、任意のこのような接続も、コンピュータ読取り可能媒体と称することが適切である。上記の組合せもまた、コンピュータ読取り可能媒体の範囲内に含められるべきである。コンピュータ実行可能命令は、例えば汎用コンピュータ、専用コンピュータ、または特定目的の処理デバイスに、ある種のファンクションまたはファンクションのグループを実行させる命令およびデータを備えている。

図４および以下の説明は、本発明を実施することができる適切なコンピューティング環境の簡潔で一般的な説明を提供することを意図したものである。必須ではないが、本発明は、ネットワーク環境中のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することにする。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでいる。コンピュータ実行可能命令、関連するデータ構造、およびプログラムモジュールは、本明細書中に開示された方法のステップを実行するためのプログラムコード手段の例を表している。このような実行可能命令の特定のシーケンス、または関連するデータ構造は、このようなステップで記述されるファンクションを実装するための対応するアクトの例を表している。

本発明は、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、多くのタイプのコンピュータシステムコンフィギュレーションを有するネットワークコンピューティング環境中において実施できることが当業者には理解されよう。本発明はまた、タスクが通信ネットワークを介して（ハードワイヤリンク、ワイヤレスリンクあるいはハードワイヤリンクまたはワイヤレスリンクの組合せによって）リンクされるリモート処理デバイスによって実行される分散コンピューティング環境中で実施することもできる。分散コンピューティング環境においては、プログラムモジュールは、ローカルおよびリモートメモリストレージデバイス中に配置することができる。

図４を参照すると、本発明を実施するための例示のシステムは、処理ユニット４２１、システムメモリ４２２、およびシステムメモリ４２２を含む様々なシステムコンポーネントを処理ユニット４２１に結合するシステムバス４２３を含む従来のコンピュータ４２０の形態の汎用コンピューティングデバイスを含んでいる。システムバス４２３は、メモリバスまたはメモリコントローラ、ペリフェラルバス、および様々なバスアーキテクチャのうちのどれかを使用したバスを含め、いくつかのタイプのバス構造のいずれかとすることができる。このシステムメモリは、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）４２４およびＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）４２５を含んでいる。起動中などにコンピュータ４２０内のエレメント間で情報を転送する助けをする基本ルーチンが入ったＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）４２６は、ＲＯＭ４２４に格納することができる。

コンピュータ４２０はまた、磁気ハードディスク４３９から情報を読み取り、それに情報を書き込む磁気ハードディスクドライブ４２７、リムーバブルな磁気ディスク４２９から情報を読み取り、それに情報を書き込む磁気ディスクドライブ４２８、およびＣＤ−ＲＯＭや他の光媒体などリムーバブルな光ディスク４３１から情報を読み取り、またはそれに情報を書き込む光ディスクドライブ４３０も含んでいる。この磁気ハードディスクドライブ４２７、磁気ディスクドライブ４２８、および光ディスクドライブ４３０は、それぞれハードディスクドライブインターフェース４３２、磁気ディスクドライブインターフェース４３３、および光ドライブインターフェース４３４によってシステムバス４２３に接続される。これらのドライブおよびこれらに関連するコンピュータ読取り可能媒体は、コンピュータ４２０のためのコンピュータ実行可能命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージを提供する。本明細書中で説明している例示の環境は、磁気ハードディスク４３９、リムーバブルな磁気ディスク４２９およびリムーバブルな光ディスク４３１を使用しているが、磁気カセット、フラッシュメモリカード、デジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含め、データを格納するための他のタイプのコンピュータ読取り可能媒体を使用することもできる。

オペレーティングシステム４３５、１つまたは複数のアプリケーションプログラム４３６、他のプログラムモジュール４３７、およびプログラムデータ４３８を含め、１つまたは複数のプログラムモジュールを含むプログラムコード手段は、ハードディスク４３９、磁気ディスク４２９、光ディスク４３１、ＲＯＭ４２４またはＲＡＭ４２５に格納することができる。ユーザは、キーボード４４０、ポインティングデバイス４４２、またはマイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなど他の入力デバイス（図示せず）を介して、コンピュータ４２０にコマンドおよび情報を入力することができる。これらおよび他の入力デバイスは、しばしば、システムバス４２３に結合されたシリアルポートインターフェース４４６を介して処理ユニット４２１に接続される。あるいは、これらの入力デバイスは、パラレルポート、ゲームポート、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）など他のインターフェースによって接続することもできる。モニタ４４７または他のディスプレイデバイスもまた、ビデオアダプタ４４８などのインターフェースを介してシステムバス４２３に接続される。このモニタに加えて、パーソナルコンピュータは、一般的にスピーカやプリンタなど他のペリフェラル出力デバイス（図示せず）を含んでいる。

コンピュータ４２０は、リモートコンピュータ４４９ａや４４９ｂなど１つまたは複数のリモートコンピュータに対する論理接続を使用して、ネットワーク化された環境中で動作することができる。リモートコンピュータ４４９ａおよび４４９ｂはそれぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、通常、コンピュータ４２０に関連して以上で説明したエレメントの多くまたはすべてを含むが、メモリストレージデバイス４５０ａおよび４５０ｂとこれらの関連するアプリケーションプログラム４３６ａおよび４３６ｂしか、図４には示していない。図４に示す論理接続は、限定ではなく例として、ここに提示されているＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）４５１およびＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）４５２を含んでいる。このようなネットワーキング環境は、オフィス規模または企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて、一般的である。

ＬＡＮネットワーキング環境中で使用されるときには、コンピュータ４２０は、ネットワークインターフェースまたはアダプタ４５３を介して、ネットワーク４５１に接続される。ＷＡＮネットワーキング環境中で使用されるときには、コンピュータ４２０は、インターネットなどのワイドエリアネットワーク４５２上で通信を確立するためのモデム４５４、無線リンク、または他の手段を含むことができる。モデム４５４は、内蔵または外付けとすることができ、シリアルポートインターフェース４４６を介してシステムバス４２３に接続される。ネットワーク環境においては、コンピュータ４２０に関連して示すプログラムモジュール、またはその一部分は、このリモートメモリストレージデバイスに格納することもできる。図に示すこれらのネットワーク接続は、例示的なものであり、ワイドエリアネットワーク４５２上で通信を確立する他の手段を使用することもできることが理解されよう。

本発明は、本発明の趣旨または必須の特徴を逸脱することなく、他の特定の形態で実施することができる。これら記載の実施形態は、すべての点で例示的にすぎず、限定的ではないと考えるべきである。それゆえ、本発明の範囲は、前述の説明によってではなく、添付の特許請求の範囲によって示される。請求項の意味および等価の範囲内に入るすべての変更が本発明の範囲内に包含される。

本発明の例示の実施形態による、２つのエンドポイント間のフロー制御変化について調整するように構成されたコンピューティングシステムを示す図である。 本発明の例示の実施形態による、ネットワーク配線上の輻輳変化に適合するように構成されたコンピューティングシステムを示す図である。 本発明の例示の実施形態による、エンドポイント間でメッセージを効率的に転送する方法の流れ図を示す図である。 本発明の例示の実施形態による、ネットワークの輻輳を制御する方法の流れ図を示す図である。 本発明についての適切な動作環境を提供するシステム例を示す図である。

符号の説明

１００ ネットワーク
１０５ イニシエータ
１１０ ウィンドウサイズ計算モジュール
１１５ アクセプタバッファサイズ情報
１２０ アクセプタ
１２５ 伝送中のメッセージ
１３０ メモリ
１３５ アプリケーション
１４０ メッセージ転送時刻比較モジュール
１４５ メッセージウィンドウサイズ調整モジュール
１５０ メモリ
１５５ メッセージウィンドウサイズ
１６０ 第２の肯定応答
１６５ 第１の肯定応答
１７０ 第２の数のメッセージ
１７５ 第１の数のメッセージ
１８５ バッファされたメッセージ
１８０ 最後の既知の良好な値
４２０ コンピュータ
４２１ 処理ユニット
４２２ システムメモリ
４２３ システムバス
４２７ 磁気ハードディスクドライブ
４２８ 磁気ディスクドライブ
４２９ 磁気ディスク
４３０ 光ディスクドライブ
４３１ 光ディスク
４３２ ハードディスクドライブインターフェース
４３３ 磁気ディスクドライブインターフェース
４３４ 光ドライブインターフェース
４３５ オペレーティングシステム
４３６ アプリケーションプログラム
４３６ａ アプリケーションプログラム
４３６ｂ アプリケーションプログラム
４３７ 他のプログラムモジュール
４３８ プログラムデータ
４３９ 磁気ハードディスク
４４０ キーボード
４４２ ポインティングデバイス
４４６ シリアルポートインターフェース
４４７ モニタ
４４８ ビデオアダプタ
４４９ａ リモートコンピュータ
４４９ｂ リモートコンピュータ
４５０ａ メモリストレージデバイス
４５０ｂ メモリストレージデバイス
４５１ ローカルエリアネットワーク
４５２ ワイドエリアネットワーク
４５３ ネットワークインターフェース
４５４ モデム

Claims (42)

1. ウェブサービス（ＷＳ）環境内のコンピューティングシステムにおいて、アクセプタの利用可能なバッファサイズに基づいて、メッセージを送信するためのメッセージウィンドウサイズを動的に決定することにより、ＷＳの信頼性のあるメッセージング（ＲＭ−ＷＳ）プロトコルに従って、エンドポイント間で前記メッセージを効率的に転送する方法であって、
   アプリケーション層において、ＲＭ−ＷＳプロトコルに従って、イニシエータとアクセプタの間のシーケンスセッションを確立するアクトと、
   アプリケーションによる処理を待っているメッセージをバッファするために利用可能なメモリの量を示すアクセプタバッファサイズ情報を含むメッセージを前記シーケンスセッションを介して受信するアクトと、
   前記ＲＭ−ＷＳプロトコルに従って、対応する肯定応答を受信することなく前記アクセプタに送信された伝送中のメッセージの数を特定するアクトと、
   前記アクセプタバッファサイズ情報および前記伝送中のメッセージの数を使用して、バッファオーバーランに起因したメッセージの再送信を防止するために、前記アクセプタに送信することができるメッセージの数の上限を表すメッセージウィンドウサイズを計算するアクトと
   を備えることを特徴とする方法。
2. 前記アクセプタバッファサイズ情報を含む前記メッセージは、ＲＭ−ＷＳプロトコルインフラストラクチャメッセージであることを特徴とする請求項１に記載の方法。
3. 前記アプリケーションによる処理を待つメッセージをバッファするために割り振られる前記アクセプタの総メモリは、接続ごとのベースで動的に構成可能であることを特徴とする請求項２に記載の方法。
4. ゼロよりも大きい前記メッセージウィンドウサイズに基づいて、
   前記計算されたメッセージウィンドウサイズに対応するいくつかのメッセージを送信するアクトを
   さらに備えることを特徴とする請求項２に記載の方法。
5. ゼロである前記メッセージウィンドウサイズに基づいて、
   インフラストラクチャメッセージを使用して、前記メッセージウィンドウサイズがゼロよりも大きくなることを計算するまで、メッセージが送信されないようにブロックするアクトを
   さらに備えることを特徴とする請求項２に記載の方法。
6. 前記インフラストラクチャメッセージは、前記ＲＭ−ＷＳプロトコルによる肯定応答メッセージであり、前記方法は、
   肯定応答要求メッセージを前記アクセプタに定期的に送信するアクトと、
   前記メッセージウィンドウサイズを再計算するためのアクセプタバッファサイズ情報を含む１つまたは複数の肯定応答メッセージを受信するアクトと、
   前記再計算されたメッセージウィンドウサイズがゼロより大きいときに、前記再計算されたメッセージウィンドウサイズに対応するいくつかのメッセージを送信するアクトと
   をさらに備えることを特徴とする請求項５に記載の方法。
7. 前記アクセプタバッファサイズ情報は、送信することができるメッセージの数に関するものであることを特徴とする請求項２に記載の方法。
8. 前記ＲＭ−ＷＳプロトコルは、ＷＳＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇであることを特徴とする請求項２に記載の方法。
9. 前記インフラストラクチャメッセージは、以前に送信された１つまたは複数のメッセージの受信を肯定応答する肯定応答メッセージであることを特徴とする請求項２に記載の方法。
10. 前記メッセージウィンドウサイズの前記計算は、前記肯定応答メッセージ中の肯定応答されるメッセージの数にさらに基づくことを特徴とする請求項９に記載の方法。
11. 前記メッセージウィンドウサイズの前記計算は、１つまたは複数の以前に送信されたメッセージについての以前に受信された肯定応答数にさらに基づくことを特徴とする請求項１０に記載の方法。
12. ウェブサービス（ＷＳ）環境中のコンピューティングシステムにおいて、ＷＳの信頼性のあるメッセージング（ＲＭ−ＷＳ）プロトコルに従って、エンドポイントにメッセージを送信するための伝送ウィンドウを調整することにより、ネットワーク輻輳を制御する方法であって、
    ＲＭ−ＷＳプロトコルに従って、確立されたシーケンスセッションを介してアクセプタに対して、ネットワーク配線上で前記アクセプタに送信する伝送中のメッセージの数の上限を表すメッセージウィンドウサイズに対応するいくつかのメッセージを送信するアクトと、
    前記メッセージウィンドウサイズに基づいて、前記いくつかのメッセージを送信してから、１つまたは複数の対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する予期メッセージ転送時間を特定するアクトと、
    前記予期メッセージ転送時間が満了する前に、前記１つまたは複数の対応する肯定応答メッセージが受信されたか否かについての指示を提供するアクトであって、前記指示は、ネットワーク輻輳に起因するメッセージの再送信を防止するために、前記メッセージウィンドウサイズまたはメッセージ再試行期間の少なくとも１つを調整する際に使用されるアクトと
    を備えることを特徴とする方法。
13. 前記調整は、前記予期メッセージ転送時間が満了する前に前記１つまたは複数の対応する肯定応答メッセージが受信されたことを示す前記メッセージウィンドウサイズの増大であることを特徴とする請求項１２に記載の方法。
14. 前記メッセージウィンドウサイズの前記増大の後に、前記方法は、
    前記増大されたメッセージウィンドウサイズに対応する増大された数のメッセージを送信するアクトと、
    前記増大されたメッセージウィンドウサイズに基づいて、前記増大された数のメッセージを送信してから、１つまたは複数の対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する第２の予期メッセージ転送時間を特定するアクトと、
    前記第２の予期メッセージ転送時間が満了する前に、前記増大された数のメッセージについての前記１つまたは複数の対応する肯定応答メッセージが受信されたか否かについての指示を提供するアクトと、
    増大された数のメッセージの１つまたは複数のメッセージが失われたこと、あるいは前記増大された数のメッセージについての前記１つまたは複数の対応する肯定応答メッセージの１つまたは複数の肯定応答メッセージが失われるか、または前記第２の予期メッセージ転送時間が満了した後に受信されたことの少なくとも１つを示して前記増大されたメッセージウィンドウサイズを減少させるアクトと
    をさらに備えることを特徴とする請求項１３に記載の方法。
15. 前記メッセージウィンドウサイズは、最後の既知の良好な値と考えられ、メモリに記憶され、前記増大されたメッセージウィンドウサイズの前記減少は、減少されたメッセージウィンドウサイズという結果になる前記メッセージウィンドウサイズよりも小さいことを特徴とする請求項１４に記載の方法。
16. 前記減少されたメッセージウィンドウサイズに対応する減少された数のメッセージを送信するアクトと、
    前記減少されたメッセージウィンドウサイズに基づいて、前記減少された数のメッセージを送信してから、１つまたは複数の対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する第２の予期メッセージ転送時間を特定するアクトと、
    前記第２の予期メッセージ転送時間が満了する前に前記減少された数のメッセージについての前記１つまたは複数の対応する肯定応答メッセージが受信されたことを示す指示を提供するアクトと、
    メモリから前記メッセージウィンドウサイズのサイズを取り出すアクトと、
    前記減少されたメッセージウィンドウサイズを前記メッセージウィンドウサイズまで増大させるアクトと
    をさらに備えることを特徴とする請求項１５に記載の方法。
17. 前記メッセージウィンドウサイズは、メッセージウィンドウサイズ調整における単一の増大および減少により微調整されることを特徴とする請求項１６に記載の方法。
18. 前記メッセージウィンドウサイズは、最後の既知の良好な値と考えられ、前記増大されたメッセージウィンドウサイズの前記減少により、前記メッセージウィンドウサイズになることを特徴とする請求項１４に記載の方法。
19. 前記増大されたメッセージウィンドウサイズの前記減少により、前記メッセージウィンドウサイズと前記増大されたメッセージウィンドウサイズとの間のサイズになることを特徴とする請求項１４に記載の方法。
20. 前記１つまたは複数の対応する肯定応答メッセージは、単一メッセージ中にバッチ化されることを特徴とする請求項１２に記載の方法。
21. 前記予期メッセージ転送時間は、前記数のメッセージを送信してから、前記単一メッセージを受信するまでの前記予期されるタイムリミットについての平均または分散時間に基づくことを特徴とする請求項２０に記載の方法。
22. ウェブサービス（ＷＳ）環境内のコンピューティングシステムにおいて、ＷＳの信頼性のあるメッセージング（ＲＭ−ＷＳ）プロトコルに従って、エンドポイントにメッセージを送信するための伝送ウィンドウを調整することにより、ネットワーク輻輳を制御する方法であって、
    ＲＭ−ＷＳプロトコルに従って、確立されたシーケンスセッションを介してアクセプタに対して、ネットワーク配線上で前記アクセプタに送信する伝送中のメッセージ数の上限を表す第１のメッセージウィンドウサイズに対応する第１の数のメッセージを送信するアクトと、
    ネットワーク輻輳に起因するメッセージの再送信を防止するために、前記第１のメッセージウィンドウサイズを第２のメッセージウィンドウサイズまで調整するステップであって、前記調整は、前記第１の数のメッセージを送信してから、１つまたは複数の対応する第１の肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する第１の予期メッセージ転送時間の満了の前に、前記第１の数のメッセージについての１つまたは複数の肯定応答メッセージが受信されるか否かに基づくステップと
    を備えることを特徴とする方法。
23. 前記第１の予期メッセージ転送時間は、前記メッセージウィンドウサイズに基づくことを特徴とする請求項２２に記載の方法。
24. 前記調整は、前記第１の予期メッセージ転送時間が満了する前に前記１つまたは複数の対応する肯定応答メッセージが受信されたことを示す前記メッセージウィンドウサイズの増大であることを特徴とする請求項２２に記載の方法。
25. ウェブサービス（ＷＳ）環境内のコンピューティングシステムにおいて、アクセプタの利用可能なバッファサイズに基づいて、メッセージを送信するためのメッセージウィンドウサイズを動的に決定することにより、ＷＳの信頼性のあるメッセージング（ＲＭ−ＷＳ）プロトコルに従って、エンドポイント間で前記メッセージを効率的に転送する方法を実施するためのコンピュータプログラムであって、前記コンピュータプログラムは、プロセッサによって実行されるときに、前記メッセージングシステムに、
    アプリケーション層において、ＲＭ−ＷＳプロトコルに従って、イニシエータとアクセプタの間のシーケンスセッションを確立することと、
    アプリケーションによる処理を待っているメッセージをバッファするための利用可能なメモリの量を示すアクセプタバッファサイズ情報を含むメッセージを前記シーケンスセッションを介して受信することと、
    前記ＲＭ−ＷＳプロトコルに従って、対応する肯定応答を受信することなく前記アクセプタに送信された伝送中のメッセージの数を特定することと、
    前記アクセプタバッファサイズ情報および前記伝送中のメッセージの数を使用して、バッファオーバーランに起因したメッセージの再送信を防止するために、前記アクセプタに送信することができるメッセージの数の上限を表すメッセージウィンドウサイズを計算することと
    を実行させることができるコンピュータ実行可能命令を備えたことを特徴とするコンピュータプログラム。
26. 前記アクセプタバッファサイズ情報を含む前記メッセージは、ＲＭ−ＷＳプロトコルインフラストラクチャメッセージであることを特徴とする請求項２５に記載のコンピュータプログラム。
27. 前記アプリケーションによる処理を待つメッセージをバッファするために割り振られる前記アクセプタの総メモリは、接続ごとのベースで動的に構成可能であることを特徴とする請求項２６に記載のコンピュータプログラム。
28. ゼロよりも大きな前記メッセージウィンドウサイズに基づいて、前記メッセージングシステムに、
    前記計算されたメッセージウィンドウサイズに対応するいくつかのメッセージを送信することを実行させることができるコンピュータ実行可能命令をさらに備えたことを特徴とする請求項２６に記載のコンピュータプログラム。
29. ゼロである前記メッセージウィンドウサイズに基づいて、前記メッセージングシステムに、
    インフラストラクチャメッセージを使用して、前記メッセージウィンドウサイズがゼロよりも大きくなることを計算するまで、メッセージが送信されないようにブロックすることを実行させることができるコンピュータ実行可能命令をさらに備えたことを特徴とする請求項２６に記載のコンピュータプログラム。
30. 前記インフラストラクチャメッセージは、前記ＲＭ−ＷＳプロトコルによる肯定応答メッセージであり、前記コンピュータプログラムは、前記メッセージングシステムに、
    肯定応答要求メッセージを前記アクセプタに定期的に送信することと、
    前記メッセージウィンドウサイズを再計算するためのアクセプタバッファサイズ情報を含む１つまたは複数の肯定応答メッセージを受信することと、
    前記再計算されたメッセージウィンドウサイズがゼロより大きいときに、前記再計算されたメッセージウィンドウサイズに対応するいくつかのメッセージを送信することと
    を実行させることができるコンピュータ実行可能命令をさらに備えたことを特徴とする請求項２９に記載のコンピュータプログラム。
31. 前記アクセプタバッファサイズ情報は、送信することができるメッセージの数に関するものであることを特徴とする請求項２６に記載のコンピュータプログラム。
32. 前記ＲＭ−ＷＳプロトコルは、ＷＳＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇであることを特徴とする請求項２６に記載のコンピュータプログラム。
33. 前記インフラストラクチャメッセージは、以前に送信された１つまたは複数のメッセージの受信を肯定応答する肯定応答メッセージであることを特徴とする請求項２６に記載のコンピュータプログラム。
34. 前記メッセージウィンドウサイズの前記計算は、前記肯定応答メッセージ中の肯定応答されるメッセージの数にさらに基づいていることを特徴とする請求項３３に記載のコンピュータプログラム。
35. 前記メッセージウィンドウサイズの前記計算は、１つまたは複数の以前に送信されたメッセージについての以前に受信された肯定応答の数にさらに基づいていることを特徴とする請求項３４に記載のコンピュータプログラム。
36. ウェブサービス（ＷＳ）環境内のコンピューティングシステムにおいて、ＷＳの信頼性のあるメッセージング（ＲＭ−ＷＳ）プロトコルに従って、エンドポイントにメッセージを送信するための伝送ウィンドウを調整することにより、ネットワーク輻輳を制御する方法を実施するためのコンピュータプログラムであって、プロセッサによって実行されるときに、前記メッセージングシステムに、
    ＲＭ−ＷＳプロトコルに従って、確立されたシーケンスセッションを介してアクセプタに対して、ネットワーク配線上で前記アクセプタに送信する伝送中のメッセージの数の上限を表すメッセージウィンドウサイズに対応するいくつかのメッセージを送信することと、
    前記メッセージウィンドウサイズに基づいて、前記いくつかのメッセージを送信してから、１つまたは複数の対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する予期メッセージ転送時間を特定することと、
    前記予期メッセージ転送時間が満了する前に、前記１つまたは複数の対応する肯定応答メッセージが受信されたか否かについての指示を提供することであって、前記指示は、ネットワーク輻輳に起因するメッセージの再送信を防止するために、前記メッセージウィンドウサイズまたは再試行期間の少なくとも１つを調整する際に使用されることと
    を実行させることができるコンピュータ実行可能命令を備えたことを特徴とするコンピュータプログラム。
37. 前記調整は、前記予期メッセージ転送時間が満了する前に前記１つまたは複数の対応する肯定応答メッセージが受信されたことを示す前記メッセージウィンドウサイズの増大であることを特徴とする請求項３６に記載のコンピュータプログラム。
38. 前記メッセージウィンドウサイズの前記増大の後に、前記メッセージングシステムに、
    前記増大されたメッセージウィンドウサイズに対応する増大された数のメッセージを送信することと、
    前記増大されたメッセージウィンドウサイズに基づいて、前記増大された数のメッセージを送信してから、１つまたは複数の対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する第２の予期メッセージ転送時間を特定することと、
    前記第２の予期メッセージ転送時間が満了する前に、前記増大された数のメッセージについての前記１つまたは複数の対応する肯定応答メッセージが受信されたか否かについての指示を提供することと、
    増大された数のメッセージの１つまたは複数のメッセージが失われたこと、あるいは前記増大された数のメッセージについての前記１つまたは複数の対応する肯定応答メッセージの１つまたは複数の肯定応答メッセージが失われるか、または前記第２の予期メッセージ転送時間が満了した後に受信されたことの少なくとも１つを示す前記増大されたウィンドウサイズを減少させることと
    を実行させることができるコンピュータ実行可能命令をさらに備えたことを特徴とする請求項３７に記載のコンピュータプログラム。
39. 前記メッセージウィンドウサイズは、最後の既知の良好な値と考えられ、メモリに記憶され、前記増大されたメッセージウィンドウサイズの前記減少は、減少されたメッセージウィンドウサイズをもたらす前記メッセージウィンドウサイズよりも小さいことを特徴とする請求項３８に記載のコンピュータプログラム。
40. 前記メッセージングシステムに、
    前記減少されたメッセージウィンドウサイズに対応する減少された数のメッセージを送信することと、
    前記減少されたメッセージウィンドウサイズに基づいて、前記減少された数のメッセージを送信してから、１つまたは複数の対応する肯定応答メッセージを受信するまでの予期されるタイムリミットを定義する第２の予期メッセージ転送時間を特定することと、
    前記第２の予期メッセージ転送時間が満了する前に前記減少された数のメッセージについての前記１つまたは複数の対応する肯定応答メッセージが受信されたことを示す指示を提供することと、
    メモリから前記メッセージウィンドウサイズのサイズを取り出すことと、
    前記減少されたメッセージウィンドウサイズを前記メッセージウィンドウサイズまで増大させることと
    を実行させることができるコンピュータ実行可能命令をさらに備えたことを特徴とする請求項３９に記載のコンピュータプログラム。
41. 前記メッセージウィンドウサイズは、メッセージウィンドウサイズ調整における単一の増大および減少により微調整されることを特徴とする請求項４０に記載のコンピュータプログラム。
42. 前記メッセージウィンドウサイズは、最後の既知の良好な値と考えられ、前記増大されたメッセージウィンドウサイズの前記減少により、前記メッセージウィンドウサイズになることを特徴とする請求項３８に記載のコンピュータプログラム。

Images