JP2005509370A

JP2005509370A - 信頼性の低い通信環境における通信効率および性能の改良

Info

Publication number: JP2005509370A
Application number: JP2003543259A
Authority: JP
Inventors: バドヴィナッツ、ピーター、アール; バエ、ミュン、エイ; ツァン、ジファン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-11-06
Filing date: 2002-10-26
Publication date: 2005-04-07
Also published as: US6910080B2; WO2003041345A1; US20030088692A1; EP1461919A1; CA2459103A1

Abstract

【課題】並列コンピューティング環境、分散コンピューティング環境におけるメッセージ伝送を改良すること。
【解決手段】マルチノード・データ処理システムにおいて、アプリケーション・プログラムの要求ごとに、ノードからノードへと伝送されるメッセージを、ノードのキューに記憶する。メッセージの受信確認応答を使用して、キューから送信すべき許容可能なメッセージの最大数を調整し、確認応答がないメッセージを再送信する前にこのシステムが待つ時間間隔を調整することによって、将来のメッセージ伝送を制御する。こうすることで、いわゆる「信頼性の低い」メッセージ・プロトコルの使用が可能になり、アプリケーション・プログラムおよびプログラマは、より複雑なプロトコルを使用する負担から解放される。

Description

本発明は、一般的に喪失したメッセージを再伝送したことによってネットワーク内のノード間のデータ伝送要求が容量の低下を引き起こす可能性があるデータ処理ネットワークにおける通信の方法およびシステムを対象としている。より詳細には、本発明は、メッセージ伝送レートを現在のネットワーク容量に精度よくマッチングさせるシステムおよび方法を対象としている。さらにより詳細には、本発明では、受信した確認応答の数と送信したメッセージの数との比較に基づいてネットワーク容量を定期的に再評価するメッセージ・ドライバとともにメッセージ・キューを使用する。

一般的に、ＵＤＰ（ＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌ）のような通信方法は、基本的に「信頼性の低い」ものであると考えられている。「信頼性のある」プロトコルであるＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）と違って、ＵＤＰメッセージは、最終の宛先に到達しないこともあり、ソース・ノードまたは中間ノードによって脱落させられ、または削除される可能性があり、あるいは通信パスのどこかで喪失してしまうこともあり得るのである。メッセージは、メッセージ・パケットを喪失した旨の通知をすることなく、宛先ノードで気付かないうちに削除されることもある。（なお、用語「信頼性の低いプロトコル」および「信頼性のあるプロトコル」は、本明細書で使用する相対的な用語であって、２つの異なる範疇の伝送プロトコルをより詳細に区別するものであることに留意されたい。したがって、これらの用語の使用によって、いわゆる「信頼性の低いプロトコル」を使用すべきではないということを意図しているわけではない。逆に、本明細書中で提供される改良は、その複雑さとオーバヘッドが少ないという利点を依然として保持しつつ、その短所の多くを解消することによって、そのような「信頼性の低い」プロトコルはさらにずっと実用的なものとする）。

より単純なプロトコルによる「信頼性の低い」メッセージ配信の品質のために、アプリケーション・プログラムは、意図したメッセージが配信されたかどうかをこのアプリケーション・プログラム自身が判定できるように、伝送プロトコルの多くの機能（他端からの確認応答、タイムアウト、再伝送など）を実装しなければならない。しかし、単純に再伝送をすることによって、より多くの通信トラフィックが頻繁に発生し、メッセージが脱落する確率がいっそう高くなる。そのようなときは、通信チャネルが容量の限界または限界を超えている、すなわち飽和している可能性がある状態なので、ネットワークは非常に不安定になる。

多数の分散されたデータ処理ノードが存在する環境を考えると、この問題は非常に重大なものとなる。１つのノード上で実行される分散アプリケーションが、ＵＤＰプロトコルを使用して、異なる多数のノード上で実行されるピア・アプリケーションに大量のメッセージを送信するときに、多数のメッセージが最終的に脱落してしまう可能性がある。このことは、再送信が必要となることを意味している。再送信は、一般的に再送信が必要となってから短時間で行われるが、そのときは依然としてネットワークはメッセージで飽和したままである。この状況の結果として、ノードで実行されるアプリケーション・プログラムが、設計の目的であったタスクを実施するのでなくメッセージを再送信することにその時間のほとんどを費やすということが、場合によっては起こり得る。例えば、５００ノード以上の負荷の重い大規模なシステムで、あるノードから他の５００のノードへと送信される多数のメッセージがある場合には、多数のメッセージを数回か再送信しなければならない可能性も大きい。したがって、メッセージ・フローを制御することが非常に重要となることが理解される。この課題は、本明細書中に提示するように、送信するメッセージの数およびサイズを調整し、そのメッセージをよりインテリジェントに再送信する方法によって達成することができる。

本発明を使用することによって、いくつかの問題が解決する。例えば、本発明によれば、メッセージの脱落する確率にあまり影響を与えず、それほど多数のメッセージ再送信を引き起こさずに、大量のメッセージを多数のピアに対して伝送することが可能になる。インテリジェントでないメッセージ再送信の方法では、より多くの通信トラフィックが生じ、メッセージの脱落する確率が増大し、アプリケーション性能が低下するので、このことは特に問題となる。

本発明は、ネットワークの状態を実時間ベースで測定して、所与の期間内にどれだけ多数のメッセージを配信することができるかを決定する方法を提供することによって、上記の問題を解決する。好適には、この方法は、返信された確認応答（ＡＣＫ）メッセージ数を、送信したメッセージ数と比較してカウントすることを含んでいる。このカウントの使用によって、通信チャネルについての事前の知識、その他実行されるアプリケーションの動作に関する知識を必要とすることなく、通信チャネルの状態（すなわち、受信したＡＣＫの数）に応じて、通信の再送信レートを自動的に調整するための基礎が提供される。

したがって、本発明をデータ処理ネットワークに使用すれば、アプリケーションにとって重要な利点を得ることができる。例えば、アプリケーションは、信頼性の低い通信チャネル上で、小さなオーバヘッド、低いメッセージの脱落率でメッセージ送信をすることができる。メッセージの再送信の回数も減らされ、全体の通信性能が高められる。メッセージ伝送は、現在のネットワークの状態に、自動的かつ実質的に連続的に適合される。スイッチ・ポート構成に１つまたは複数の変更を加えることにより、確認応答の監視、再試行のタイミング、およびメッセージ再送信の雑用からアプリケーション・プログラムを解放してくれるさらに簡単なプロトコルを使用して、今や外部のプログラミングによってさらにうまくメッセージ伝送の雑用を処理することによって、アプリケーション・プログラミングをさらに簡単にすることができることを意味する。

したがって、本発明の目的の一つは、並列コンピューティング環境、分散コンピューティング環境におけるメッセージ伝送を改良することである。

本発明の他の目的は、存在するシステム容量をすべて使用するだけでなく、再送信されるメッセージ（特に、新たに再送信されるメッセージ）によってシステム容量が過負荷にならないよう保証するようにも動作する適応性のある伝送プロトコルを提供することである。

本発明のさらに他の目的は、「信頼性の低い」プロトコルが十分なものとなるメカニズムを提供することによって、アプリケーション・プログラムがより複雑な「信頼性のある」プロトコルを使用することを避けることができるようにすることである。

本発明のさらに他の目的は、１以上のメッセージを後で再送信しなければならない確率をさらに少なくしながら、ネットワーク・ピアに多数のメッセージを容易に送信できるメッセージ伝送メカニズムを提供することである。

本発明のさらに他の目的は、アプリケーション・プログラムおよびプログラマのために必要となる通信の需要を減少させることである。

本発明のさらに他の目的は、ネットワーク化されたデータ処理環境内の脱落メッセージ数を減少させることである。

本発明のさらに他の目的は、特に分散データ処理ネットワーク、並列データ処理ネットワークにおいて、全体としての通信性能を向上することである。

本発明のさらに他の目的は、分散データ処理ネットワーク、並列データ処理ネットワーク中でメッセージを送信するために要する時間を減少させることである。

本発明のさらに他の目的は、アプリケーション・プログラムによって一度に送信されるメッセージ数を最大にすることである。

本発明のさらに他の目的は、送信するメッセージ数を通信チャネルの現在の容量にマッチングさせることである。

本発明のさらに他の目的は、脱落した可能性のあるメッセージの再送信をしようとする前に、メッセージ・システムがどの程度の時間を待たされるかを管理するタイマをより正確に制御することである。

本発明のさらに他の目的は、メッセージ再送信の数を減少させることである。

これに限定されないが、最後に、本発明の目的の一つは、いわゆる「信頼性の低い」通信プロトコルの適用可能な範囲を拡張することである。

本発明の様々な実施形態が満たす望ましい目的を本明細書に列挙したが、この列挙によって、これらの目的のいずれかまたはすべてが、個々に、あるいはまとめて本発明の最も一般的な実施形態、またはそのより特定の実施形態に本質的な特徴として存在することを暗示し、または示唆することを意図するものではない。

マルチノード・データ処理環境でメッセージを伝送する方法は、複数のステップを含んでいる。複数のステップは、伝送アプリケーションの識別子とともに送信するメッセージを、ノードのうちの１つで実行されるアプリケーションからメッセージ・キューに配置するステップから開始する。ネットワーク伝送容量の現在の指標に基づいて、いくつかのメッセージを伝送するために選択し、選択されたメッセージを送信する。送信ノードは、送信したメッセージの到着を示す、メッセージ受信側からの確認応答を監視し続ける。次に、本方法では、送信したメッセージの数と比べた受信した確認応答の数に基づいて、その後に送信するメッセージの数を修正する。この比較は、現在のネットワーク容量の指標および予測量として使用される。この比較は絶対値の差の形式で実行され、より好適には、割合の比較の形態で実行される。

本発明の対象は、本明細書の最後の部分で指摘し、明確に請求されている。しかし、本発明については、以下の説明を添付の図面と併せて参照することによって、さらなる目的および利点とともに、構成および実施の方法を最も良く理解することができるだろう。

図１に示すように、データ処理ネットワーク内の通信を以下のようにモデリングすることができる。送信ノード上のＣＯＭＭＡＧＥＮＴ１００（ノードＡ上の送信ＣＯＭＭＡＧＥＮＴ）が送信側（アプリケーション・プログラム）からの送信要求を受信すると、この送信ＣＯＭＭＡＧＥＮＴは、その送信要求を処理し、指定された宛先ノード２００（例えば、受信側ノードＢ上の受信ＣＯＭＭＡＧＥＮＴ）へ送信する。宛先ノード（ノードＢ）上の受信ＣＯＭＭＡＧＥＮＴ２００が通信チャネルを介して送信側からのメッセージを受信すると、この受信ＣＯＭＭＡＧＥＮＴは、自身のノード（ノードＢ）上の受信側に通知し（アプリケーション・プログラムに通知し）、確認応答（ＡＣＫ）を送信側ノード、ここではノード１００（ノードＡ）に送信する。

ノードＡ上の送信ＣＯＭＭＡＧＥＮＴが、受信側ノードＢからＡＣＫメッセージを受信すると、送信ＣＯＭＭＡＧＥＮＴは、元の送信側に送信要求の完了通知を送信し、送信要求を完了（終了）する。ノードＡ上の送信ＣＯＭＭＡＧＥＮＴが所定の期間内（再試行要求の発行または再試行タイマの時間経過まで）にＡＣＫメッセージを受信しない場合には、以前に送信したメッセージが喪失した可能性があるので、送信ＣＯＭＭＡＧＥＮＴは、このメッセージを、もう一度宛先ノードに再送信する。

以上で説明した図１にある通信モデルにおいて示されるように、以下の要因が全体的としての通信性能に影響を与える可能性がある。
非常に多数のメッセージが通信チャネルに送信される場合、特にメッセージ数が通信チャネルの容量を超える場合には、ある一定数のメッセージが、意図した宛先に到達しない可能性があること。
再試行要求の間隔が短くすると、送信要求を完了するための時間の合計が短くなる可能性はあるがが、通信チャネル上のメッセージ・トラフィックが増加して、通信性能低下の影響が出る可能性があること。
他方で、再試行間隔を長くすると、送信要求を完了するための時間の合計が長くなる可能性があるが、この戦略によると即時の通信オーバヘッドは低下するであろうこと。

本発明は、ＣＯＭＭＡＧＥＮＴ（送信ＣＯＭＭＡＧＥＮＴおよび受信ＣＯＭＭＡＧＥＮＴ）に伝送要求からのメッセージの数を調整させ、また再試行間隔を調整させて、最小の通信オーバヘッド、最大スループットを達成する。一対全部（ｏｎｅ−ｔｏ−ａｌｌ）のメッセージ同報通信を重視する本発明においては、メッセージを受信すると、受信ＣＯＭＭＡＧＥＮＴは、単にＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔｓｉｇｎａｌ、確認応答）をすぐに送信し、受信側アプリケーションに通知する。図３に、好適な受信ＣＯＭＭＡＧＥＮＴの動作が示される。

図２は、本発明の方法およびシステムによる通信トラフィックの調整の構造をブロック図の形式で示している。

１．本発明の方法では、すぐにメッセージを送信するのではなく、メッセージを処理して送信する前に、送信要求を最初にメッセージ・キュー３００に配置する。この動作によって、通信チャネル容量が有限であるチャネルにあふれてしまうほどのメッセージを伝送することが防止される。

２．本発明の動作の重要な部分は、本明細書においてメッセージ・ドライバ４００あるいはドライブ・メッセージング・エンジン４００と呼ばれるソフトウェア・ドライバを使用して実現される。本発明のドライブ・メッセージング・エンジン４００は、現在の通信容量に基づいて、メッセージの最大伝送可能数（すなわち、ＭＡＸＮＵＭＭＳＧＳ）を選択する。このパラメータ（ＭＡＸＮＵＭＭＳＧＳ）は、現在の判定済みのネットワーク状態（例えば、送出されたメッセージの数と比較した受信ＡＣＫの数）に従って調整されることに留意されたい。

通信チャネル上に送信するように要求することが可能なメッセージの最大サイズを指定するために、ＭＡＸＳＩＺＥパラメータを使用される。要求されたメッセージがあまりにも大きすぎる場合には、この要求されたメッセージは、複数の小さなメッセージに分割される。

number of the split messages = |requested message size| / MAXSIZE

ＣＯＭＭＡＧＥＮＴに関する限りでは、分割メッセージ数（number of the split messages）は、要求されたメッセージ数の真の尺度となる。ＭＡＸＮＵＭＭＳＧＳは、一度に送信できる分割メッセージの最大数である。ＭＡＸＮＵＭＭＳＧＳを調整する方法はいくつかあるが、以下は、本明細書における好適な方法の１つである。

MAXNUMMSGS_next = MAXNUMMSGS_prev * (1 - penalty + reward),
where
ack_miss_rate = (NumberOfACKs - NumberOfMsgSent) / NumberOfMsgSent
penalty = 0 if ack_miss_rate < epsilon (a small predefined number e.g. 0.1), or
= ack_miss_rate / 2, otherwise
reward = value by which MAXNUMMSGS is increased.

定義されている方法によれば、ａｃｋ＿ｍｉｓｓ＿ｒａｔｅは、０（すべてのメッセージが配信されたことを示している）と１（すべてのメッセージが喪失したことを示している）の間にある。上記の式で、ａｃｋ＿ｍｉｓｓ＿ｒａｔｅを２で割って、ＭＡＸＮＵＭＭＳＧＳになされる変更を低下させていくことが好ましい。例えば、ＭＡＸＮＵＭＭＳＧＳが最初１００であり、メッセージを全て喪失した場合、ＭＡＸＮＵＭＭＳＧＳパラメータの次の値は１００＊（１−１／２）＝５０となる。
ｒｅｗａｒｄ値は、好適には、以下のように計算される。

AvgMsgsPerSend = AccumulatedTotalMsgsSent / AccumulatedTotalStepsToSend
reward = 0 if a predefined value (e.g.,0.1) < (AvgMsgsPerSend / MAXNUMMSGS) <
a predefined value (for example, 0.9). otherwise
= ( |AvgMsgsPerSend - MAXNUMMSGS| ) / (2 * MAXNUMMSGS).

上記の式の中で、ＡｃｃｕｍｕｌａｔｅｄＴｏｔａｌＭｓｇｓＳｅｎｔパラメータは、送信するメッセージの数の合計である。これによって、再試行回数も明らかになる。ＡｃｃｕｍｕｌａｔｅｄＴｏｔａｌＳｔｅｐｓＴｏＳｅｎｄパラメータは送信の数の合計である。したがって、ＡｖｇＭｓｇｓＰｅｒＳｅｎｄｓは、送信ごとのメッセージの平均数である。このＡｖｇＭｓｇｓＰｅｒＳｅｎｄｓが所定のパーセント（例えば９０％）よりも大きい場合、あるいは、ＭＡＸＮＵＭＭＳＧＳの所定のパーセント（例えば１０％）よりも小さく、その結果２つの値の偏差が相対的に小さい場合には、ｒｅｗａｒｄが加えられる。

上記の式では、ノード間通信の状態に対して所望の依存性を示す「ｐｅｎａｌｔｙ」計算および「ｒｅｗａｒｄ」計算の好適な例を提供している。本発明は、これら特定の式には限定されない。メッセージ伝送および配信に際してシステムの正常終了に基づいたｐｅｎａｌｔｙまたはｒｅｗａｒｄを提供する限り、任意の１組の他の式を使用することができる。

３．本発明の方法では、選択されたメッセージを通信チャネルへと送信し、メッセージ状況を「送信済み（Ｓｅｎｔ）」としてマークし、再試行間隔タイマを以下のプロトコルによって決定される現在の値（すなわち、ＲＥＴＲＹＩＮＴＥＲＶＡＬ）に設定する。このＲＥＴＲＹＩＮＴＥＲＶＡＬは、初期の再試行間隔タイマである。実際の再試行間隔タイマは、メッセージの再送信が行われるときに再計算される。

再試行間隔を、キューのメッセージの再送信を試みるときに長くする。この時、新しいメッセージを開始するときのように、ＲＥＴＲＹＩＮＴＥＲＶＡＬの値を初期値にリセットする。ＲＥＴＲＹＩＮＴＥＲＶＡＬの調整は、以下のように表現される。

N_round = 0, t = t₀ (where t₀ is initial value (RETRYINTERVAL) and t is the retry inverval).

この間隔ｔは、メッセージが再試行されない限り同じ値にとどまる。しかし、メッセージの再送信が試みられるときはいつでも、以下のようになる。

t = t + t_delta (where t_deltais the incrementing value).

すべての保留中のメッセージが送られ、新しいメッセージが開始されると、以下のようになる

t = t₀

上式の背後にある基礎を成す概念は、メッセージが配信されない間隔期間を長くすることである。したがって、上式が必ずしも厳密に以上のように表現されなければならないというわけではない。関連する態様では、この値は、ネットワーク中の正常なメッセージ伝送に応じて動的に変更される。

４．ＣＯＭＭＡＧＥＮＴが宛先からＡＣＫメッセージを受信するときはいつでも、ドライブ・メッセージング・エンジン４００は、関連するメッセージ状況に「実行済み（Ｄｏｎｅ）」とマークを付け、すべてのＡＣＫを受信したかどうかを検査して調べる。すべてのＡＣＫを受信した場合、もともと要求していたアプリケーションは、その送信要求が完了したことを通知され、その再試行タイマがリセットされる。ここで、再試行タイマをリセットするためのトリガの実施にはある程度の柔軟性があることに留意されたい。複数のアプリケーションが同時に実行される状況（典型的な場合）では、再試行タイマのリセットを１つまたは複数のアプリケーションに依存するように行うことができる。この再試行タイマをリセットする目的で、かかるアプリケーションを、必須のアプリケーションとして指定することができる。さらに、確認応答の合計数を、すべての実行されるアプリケーションについて累積して、すなわち平均数を決定して、この平均値が閾値を超える場合に、タイマをリセットする。

ａ．（Ｒｅｗａｒｄ）すべてのＡＣＫが受信される場合、通信パラメータ：ＭＡＸＮＵＭＭＳＧＳに対して拡張を徐々に行い、通信チャネル容量を増大させる方向に再試行間隔を増大させる。すなわち、ＭＡＸＮＵＭＭＳＧＳを増大させ、再試行間隔を減少させる。この再試行間隔は、retry_interval = t₀ などとして元の値にリセットすることになる。このｒｅｗａｒｄは、以下のように計算される。

AvgMsgsPerSend = AccumulatedTotalMsgsSent / AccumulatedTotalStepsToSend
reward = 0 if a predefined value (e.g.,0.1) < (AvgMsgsPerSend / MAXNUMMSGS) <
a predefined value (for example, 0.9) = ( |AvgMsgsPerSend - MAXNUMMSGS| ) / (2 * MAXNUMMSGS),
otherwise as descrived above.

５．再試行タイマの時間が経過したときに、所与の伝送におけるメッセージの最大可能数には制限があるので、メッセージの一部が送信されていないことがあり得る（すなわち、未送信のメッセージが依然としてメッセージ・キューに残っている可能性がある）。この場合、本方法では、次の組のメッセージを選択し、それらを送出する。

６．再試行タイマの時間が経過したとき、キューからすべてのメッセージの伝送を試みた後に一部のＡＣＫを受け取っていないので、本方法では、ネットワーク状態を評価し、通信パラメータ（伝送ごとのメッセージの最大数（ＭＡＸＮＵＭＭＳＧＳ）および再試行間隔（ＲＥＴＲＹＩＮＴＥＲＶＡＬ））を調整する。

ａ．（Ｐｅｎａｌｔｙ）喪失したＡＣＫの数が非常に多い場合、すなわち喪失したＡＣＫの数が所定の数よりも大きい場合、またはａｃｋ＿ｍｉｓｓ＿ｒａｔｅが、例えば、（５００メッセージの伝送のうちの５０メッセージの損失率を表す）０．１より大きい場合には、まず、ＭＡＸＮＵＭＭＳＧＳパラメータを徐々に小さくし、次いで、ＭＡＸＮＵＭＳＧＳパラメータがすでに所与の定義済みの最小値に達している場合、または再試行が依然として行われる場合に、再試行間隔（ＲＥＴＲＹＩＮＴＥＲＶＡＬ）を長くする。例えば、以下の式は、メッセージを再試行するとき、またはＭＡＸＮＵＭＭＳＧＳが、定義済みの値（例えば、ＭＡＸＮＵＭＭＳＧＳ_ｍｉｎ）より小さいときに、メッセージ伝送の失敗を考慮してこれらのパラメータを調整することが可能な好ましい方法のうちの１つを指定するものである。

MAXNUMMSGS_next = MAXNUMMSGS_prev * (1 - penalty)
penalty = ack_miss_rate / 2
and
t = t + t_delta (where t_deltais the incrementing value).

このようにして、伝送ごとのメッセージ数および再試行間隔をネットワーク状態に応じて調整して、通信オーバヘッドを減少させる。

本発明は、好適には、本発明の譲受人であるインターナショナル・ビジネス・マシーンズ・コーポレーションによって開発され、販売されているｐＳｅｒｉｅｓプロセッサなどのデータ処理システムにおいて使用される。好適なシステムには、公に定義されているＭＰＩ（ＭｅｓｓａｇｅＰａｓｓｉｎｇＩｎｔｅｒｆａｃｅ）を使用するスイッチを介して互いに通信を行う複数のデータ処理ノードが含まれる。したがって、ノード−ノード間からの１次情報交換は、定義済みの組の他ノードを対象とするメッセージ交換を介したものである。これらのノード上で実行されるアプリケーションが、並列データ処理タスクおよび分散データ処理タスクを実施することができるように、開発され市販されるときに、定義済みのノード・グループにこれらのノードを形成することができる。特に、これらの公共利用可能なシステムには、グループ・サービスと呼ばれるプログラミングが含まれ、これによって、アプリケーション・プログラムがノード・グループを確立し、これらのグループ中でメンバシップを制御し、様々なグループ機能を利用することができるようになる。グループ・サービスは、基礎となるオペレーティング・システムに関連して実行されるユーティリティと見なすことが最良である。本明細書に記載されるように、グループ・サービス・プログラミングはまた、そのメッセージのノード−ノード間伝送を制御する。したがって、本発明は、グループ・サービス・ソフトウェア・システム内で実施され、以下に記載されるような状況を改善する。

通常は、グループ・サービスは、非常に大規模な負荷の重いシステム（例えば、５００ノード）上ですべてのノードが応答する必要がある伝送プロトコルを実施するときに、まずプロトコル・メッセージをすべての指定ノードに送信し、その応答を待つ。グループ・サービスは、非応答ノードに再送信の前に所与の時間間隔でメッセージを送信し続ける。しかし、ある状況では、通信チャネルが他のアプリケーションの動作に起因してすでに容量がオーバーフローしているので、多数のグループ・サービス・メッセージが少なくとも一時的に失われる。さらに、反復された再送信により、通信チャネルのオーバヘッドが増大し、さらにメッセージ脱落率が増大する。したがって、通常のプロトコルは、妥当な時間内に完了することができず、それによって、グループ・サービスを使用するアプリケーションの性能がさらに低下することさえあり得る。しかし、本発明のプロトコルを使用することにより、グループ・サービスは、要求されたメッセージを複数のステップで送信し、再試行間隔を調整し、その結果、本発明のプロトコルの使用によって、通信チャネルに悪影響を及ぼすことなく、通信性能が向上することが可能になる。

したがって、通信トラフィックを調整する本発明の方法を使用することにより、アプリケーション・プログラムに、以下の利点、すなわち（１）送信するメッセージのレートを調整することによる通信オーバヘッドの低減、および（２）通信性能の全体的な改善がもたらされる。

本発明を、いくつかの好適な実施形態に従って本明細書に詳細に記載してきたが、当業者は、多くの修正形態および変更形態を実施することができる。したがって、添付の特許請求の範囲は、そのような本発明の真の趣旨および範囲に含まれる修正形態および変更形態をすべて含んでいる。

データ処理ネットワーク中におけるノード間でメッセージを送信するための通信モデルを示すブロック図である。プロトコルを動作させる適応メッセージに関連してメッセージ・キューを使用する、本発明の好ましい実施形態を示すブロック図である。受信されたメッセージの処理を示すブロック図である。

Claims

マルチノード・データ処理環境においてメッセージを伝送する方法であって、
アプリケーションから送信するメッセージを前記アプリケーションの識別子とともにメッセージ・キューに配置するステップと、
現在のネットワーク伝送容量の指標に基づいて、いくつかの送信するメッセージを選択するステップと、
前記選択されたメッセージを送信するステップと、
前記送信されたメッセージの到着の確認応答を受信するステップと、
送信したメッセージの数に比較した受信した確認応答の数に基づいて、前記送信するメッセージを修正するステップと、
を含む方法。
確認応答がない場合に、次のメッセージ再送信のタイミングを決定するのに使用される時間間隔を修正するステップをさらに含む、請求項１に記載の方法。
受信した確認応答の数が所定の値を超える場合に、前記送信するメッセージの数を増加させる、請求項１に記載の方法。
受信した確認応答の数が所定の値より小さい場合に、前記送信するメッセージの数を減少させる、請求項１に記載の方法。
受信した確認応答の数が所定の値を超える場合に、確認応答がない場合に、次のメッセージ再送信のタイミングを決定するのに使用される時間間隔を減少させる、請求項１に記載の方法。
受信した確認応答の数が所定の値を超える場合に、確認応答がない場合に、次のメッセージ再送信のタイミングを決定するのに使用される時間間隔を増加させる、請求項１に記載の方法。
少なくとも３つのノードと、
前記少なくとも３つのノードを接続するノード間通信リンクと、
前記ノードのうちの少なくとも１つの内部のメッセージ・キューと、、
前記キューからのメッセージを伝送し、前記ノードのうちの他ノードからの伝送確認応答を監視して、伝送再試行間隔、および前記キューから伝送すべきメッセージの最大数を決定するパラメータを調整するための前記少なくとも１つのノード上のプログラミングと、
を備えるマルチノード・データ処理システム。