トップ :: G 物理学 :: G06 計算;計数




【発明の名称】 マルチキャスト通信制御方法
【発明者】 【氏名】ヴ レ ファン

【氏名】小塚 宏

【氏名】前田 慎司

【氏名】佐藤 浩司
【要約】 【課題】マルチキャスト通信において、各通信装置に必要なバッファサイズを削減するとともに、喪失メッセージの回復処理に際してのネットワークの輻輳を防止する。

【解決手段】ノード順位決定手段１８を設けて各ノードにマルチキャストドメイン内での順位番号を設定し、一定範囲の順位番号を有するノードを回復処理を行うサーバ・ノードと規定するとともに、このサーバ・ノード間での回復処理の分担も該順位番号に基づいて決定する。さらに、該順位番号を使用して各サーバ・ノード毎に異なるタイマーを設定し、メッセージの喪失を検出したノードからの回復要求メッセージ、およびこれに対する回復応答メッセージのネットワーク送出タイミングをこのタイマーに基づいて決定する。
【特許請求の範囲】
【請求項１】 ネットワークに接続された複数のノード間相互の通信システムであるマルチキャスト通信システムにおいて、上記各ノードに優先順位番号を付け、上記各ノード間通信における受信メッセージにメッセージ喪失が検出された場合、下記ステップに従って動作するようにしたことを特徴とするマルチキャスト通信制御方法。
（ａ）メッセージ喪失を検出したノードが該喪失メッセージの回復を要求する回復要求メッセージを送信する回復要求メッセージ送信ステップ；
（ｂ）各ノードが該回復要求メッセージを受信する回復要求メッセージ受信ステップ；
（ｃ）最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、該回復要求メッセージに対して自ノードが応答するか否かの判定を行う応答判定ステップ；
（ｄ）上記応答判定ステップの判定結果に基づき上記最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、下記の（ｄ１）あるいは（ｄ２）いずれかのステップを実行するステップ；
（ｄ１）自ノードが応答すると判定した場合：バッファ内に保持しているメッセージを利用して該回復要求メッセージに対する第１の回復応答メッセージを作成して所定時間ｔ１経過後送信するように設定した後、下記（ｄ１１）あるいは（ｄ１２）のいずれかのステップを実行する回復処理ステップ；
（ｄ１１）上記所定時間ｔ１経過以前に他ノードが上記回復要求メッセージに対する第２の回復応答メッセージを送信した場合には、上記第１の回復応答メッセージの送信を中止するステップ；
（ｄ１２）上記所定時間ｔ１経過までに他ノードが上記回復要求メッセージに対する第２の回復応答メッセージを送信しなかった場合には、上記第１の回復応答メッセージを送信することにより回復処理を行うステップ；
（ｄ２）自ノードが応答すると判定しなかった場合：該回復要求メッセージを廃棄するステップ。
【請求項２】 応答判定ステップにおいて、最優先順位番号を有するノードのみが応答すると判定するようにしたことを特徴とする請求項１に記載のマルチキャスト通信制御方法。
【請求項３】 上記所定の優先順位番号は、最優先順位番号を有するノードの初期化動作時に決定される固有の値に設定されるようにしたことを特徴とする請求項１に記載のマルチキャスト通信制御方法。
【請求項４】 上記所定の優先順位番号は、最優先順位番号を有するノード上に搭載されたソフトウエアによって任意に設定可能であるようにしたことを特徴とする請求項１に記載のマルチキャスト通信制御方法。
【請求項５】 メッセージ喪失を検出したノードは、上記回復要求メッセージ送信ステップにおいて回復要求メッセージに判別番号を付けて送信し、上記最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、上記応答判定ステップにおいて該判別番号と自ノードの優先順位番号を用いて判定を行うようにしたことを特徴とする請求項１に記載のマルチキャスト通信制御方法。
【請求項６】 回復処理実行中のノードが回復処理不能に陥った場合、該ノードの優先順位番号を越える優先順位番号を持つ各ノードの優先順位番号を繰り上げるようにしたことを特徴とする請求項１〜請求項５のいずれかに記載のマルチキャスト通信制御方法。
【請求項７】 上記回復処理ステップにおける所定時間ｔ１は、該回復応答メッセージの送信元ノードの優先順位番号によって決定されるようにしたことを特徴とする請求項１に記載のマルチキャスト通信制御方法。
【請求項８】 上記所定時間ｔ１は、回復応答メッセージの送信元ノードの優先順位番号とこのマルチキャスト通信システムに接続されているノードの総数およびこのマルチキャスト通信システムの伝送経路の遅延時間を用いて算出するようにしたことを特徴とする請求項７に記載のマルチキャスト通信制御方法。
【請求項９】 最優先順位番号から所定の優先順位番号までの優先順位番号を持つノードがバッファ内に保持しているメッセージの削除範囲は、最優先順位番号を持つノードが設定するようにしたことを特徴とする請求項１に記載のマルチキャスト通信制御方法。
【請求項１０】 上記削除範囲は、過去このマルチキャスト通信システムに接続されたいずれかのノードがメッセージを送信した時刻と、いずれかのノードが上記メッセージの喪失を検出して回復要求メッセージを送信した場合の該回復要求メッセージの送信時刻との時間間隔に基づいて決定するようにしたことを特徴とする請求項９に記載のマルチキャスト通信制御方法。
【請求項１１】 上記削除範囲は、回復要求メッセージの送信頻度の増大に応じて縮小するようにしたことを特徴とする請求項９に記載のマルチキャスト通信制御方法。
【請求項１２】 最優先順位番号から所定の優先順位番号までの優先順位番号を持つノードがバッファ内に保持しているメッセージを、最優先順位番号を持つノードがいずれかのノードからの回復要求メッセージを受信した場合のみ、略同一時刻に削除するようにしたことを特徴とする請求項１または請求項９の何れかに記載のマルチキャスト通信制御方法。
【請求項１３】 ネットワークに接続された複数のノード間相互の通信システムであるマルチキャスト通信システムにおいて、上記各ノードに優先順位番号を付け、上記各ノード間通信における受信メッセージにメッセージ喪失が検出された場合、該メッセージの喪失を検出した第１のノードは第１の回復要求メッセージを作成し、自ノードの優先順位番号によって決定される所定時間ｔ２経過後送信するよう設定した後、以下のいずれかのステップにより動作するようにしたことを特徴とするマルチキャスト通信制御方法。
（ａ）第２のノードが上記喪失メッセージと同一のメッセージに対する回復要求メッセージを送信し、これに対する回復応答メッセージを上記第１のノードが上記所定時間ｔ２経過以前に受信した場合には、上記第１の回復要求メッセージの送信を中止するステップ；
（ｂ）第２のノードが上記喪失メッセージと異なるメッセージに対する回復要求メッセージを送信し、これに対する回復応答メッセージを上記第１のノードが上記所定時間ｔ２経過以前に受信した場合には、この回復応答メッセージを廃棄するステップ；
（ｃ）上記所定時間ｔ２経過までにいかなる回復応答メッセージも受信しなかった場合には上記第１の回復要求メッセージを送信するステップ。
【請求項１４】 上記所定時間ｔ２は、回復応答メッセージの送信元ノードの優先順位番号とこのマルチキャスト通信システムに接続されているノードの総数およびこのマルチキャスト通信システムの伝送経路の遅延時間を用いて算出することを特徴とする請求項１３に記載のマルチキャスト通信制御方法。
【請求項１５】 上記ノードの優先順位番号は下記のステップにより付けることを特徴とする請求項１〜請求項１４のいずれかに記載のマルチキャスト通信制御方法。
（ａ）マルチキャスト通信システムに参加しようとするノードが参加要求メッセージを送信する参加要求ステップ；
（ｂ）上記参加要求メッセージを送信したノードが、上記参加要求メッセージに応答して送信される参加確認メッセージを受信したか否かの判定を行い、該判定結果に基づいて上記参加要求メッセージを送信したノードが下記のいずれかのステップを実行する参加確認ステップ；
（ｂ１）参加確認メッセージを受信しなかった場合：自ノードに最優先順位番号を付け、以後他ノードが送信した参加要求メッセージを受信した場合には識別番号を含む参加確認メッセージを送信するよう自ノードを設定する最優先順位設定ステップ；
（ｂ２）参加確認メッセージを受信した場合：この参加確認メッセージに含まれる識別番号に基づいて決定される優先順位番号を自ノードに設定する一般順位設定ステップ。
【発明の詳細な説明】【０００１】
【発明の属する技術分野】この発明は、ネットワークに接続された複数の通信ノードからなるシステムの制御方法に関するものであり、さらに詳しくは各ノード間での通信にマルチキャスト・プロトコルを用いるマルチキャスト通信制御方法に関するものである。
【０００２】
【従来の技術】従来、ネットワークに接続された複数の通信装置から成るシステムにおいて、マルチキャスト通信を行う方法として、「Ａ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｌｉｇｈｔ−Ｗｅｉｇｈｔ Ｓｅｓｓｉｏｎｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｆｒａｍｉｎｇ」（Ｓｕｂｍｉｔｔｅｄ ｔｏ ＩＥＥＥ／ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎ ｏｎＮｅｔｗｏｋｉｎｇ，Ｎｏｖｅｍｂｅｒ １３，１９９５）に示される方法がある。
【０００３】まず、マルチキャスト通信について簡単に説明しておく。マルチキャスト通信において、ある通信装置からメッセージを送信する際には、通信装置は自分自身の通信装置の識別子と各通信装置毎に管理されるシーケンス番号をメッセージに付加して送信する。これをネットワーク上の一定範囲の通信装置群の全ての通信装置がこれを受信する。この一定の範囲をマルチキャストドメインと呼ぶ。また各通信装置とそこで使用されるアプリケーション・プログラムの組合わせをノードと呼ぶ。各ノードはマルチキャストドメインに送られるメッセージを受信したい場合には、このマルチキャストドメインに対応するＩＰアドレスを自ノードのネットワークインタフェースに設定し、マルチキャストドメインへ参加メッセージを送信する。
【０００４】次に、上記の従来のマルチキャスト通信の動作について図２６のフローチャートに沿って説明する。初めに、各ノードは動作状態になると（Ｓ１００１）、ネットワークからメッセージを受信し（Ｓ１００２）、メッセージの型を判定する（Ｓ１００３）。
【０００５】メッセージの型には、以下の４種類がある。１）通常メッセージであることを示す“ＮＯＲＭＡＬ”；
２）あるノードでメッセージの受信エラーが発生した時に、このノードが送信する回復要求メッセージであることを示す“ＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴ”；
３）（２）の回復要求メッセージに呼応して、他のノードから送信される回復応答メッセージであることを示す“ＲＥＰＡＩＲ＿ＲＥＰＬＹ”；
４）ロギングバッファのフラッシュ（削除）を指示する同期メッセージであることを示す“ＲＥＰＡＩＲ＿ＳＹＮＣ”である。ロギングバッファは過去のメッセージを保持するためのバッファである。また、回復応答メッセージには、この回復応答メッセージが送信される要因となった回復要求メッセージの送信元ノードが受信に失敗した通常メッセージを含んで送信される。
【０００６】以下、受信したメッセージの型により分類し、その後の動作について説明する。
【０００７】１）受信メッセージの型がＮＯＲＭＡＬの場合受信したメッセージの型がＮＯＲＭＡＬの場合、まずメッセージのシーケンス番号に飛びがあるかどうかを調べる（Ｓ１００４）。飛びがある場合にはメッセージを喪失したと判断し、回復要求メッセージを生成し（Ｓ１００５）、メッセージを送信したノードと自ノードとのラウンドトリップタイム（ＲＴＴ：一組のノードにおいて、一方のノードが送信したメッセージに対する応答が他方のノードから返って来るまでの時間）と乱数値を用いてタイマーを設定し、タイマーの完了時に回復要求メッセージを発行するように、回復要求メッセージを回復要求メッセージ送信キューへ投入する（Ｓ１００６）。このタイマーを回復要求バックオフタイマーと呼び、回復要求メッセージが回復要求メッセージ送信キューへ投入されてから、ネットワークへ送出されるまでの時間を決定する。
【０００８】次いで、メッセージ喪失の有無にかかわらず、後の回復処理のためにこのメッセージをロギングバッファに保持し（Ｓ１００７）、受信メッセージをアプリケーション・プログラムに引き渡す（Ｓ１００８）。
【０００９】２）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、送信元のノードが要求しているメッセージを、自ノードがロギングバッファに保持しているかどうかを調べる（Ｓ１００９）。保持していない場合は、自ノードもこの送信元のノードが要求しているメッセージを喪失しているので、この回復要求メッセージに呼応する回復応答メッセージが他ノードから送信されなかった場合に、再度自ノードが回復要求メッセージを発行するために、回復要求バックオフタイマーを設定する（Ｓ１０１０）。
【００１０】要求されているメッセージを保持している場合は、回復要求メッセージを送信したノードと自ノードとのラウンドトリップタイム（ＲＴＴ）と乱数値を用いて回復応答バックオフタイマーを設定し（Ｓ１０１１）、タイマーの完了時に回復応答メッセージを発行するように回復応答メッセージ送信キューへ投入する（Ｓ１０１２）。
【００１１】この回復応答バックオフタイマーは、回復応答メッセージ送信キューへ投入された回復応答メッセージがネットワークへ送出されるまでの時間を決定するタイマーである。
【００１２】３）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、メッセージが自ノードの要求への応答かを判断し（Ｓ１０１３）、もしそうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ１０１４）、通常メッセージ部分を通常メッセージ受信キューへ投入する（Ｓ１０１５）。さらにこの通常メッセージをロギングバッファに保持し（Ｓ１０１６）、アプリケーションへメッセージを引き渡す（Ｓ１０１７）。
【００１３】もし自ノードの要求への応答でない場合には、過去にこの回復応答メッセージの原因となった回復要求メッセージに対して自ノードが応答するために回復応答バックオフタイマーを設定したか否かを調べ（Ｓ１０１８）、設定していた場合には、応答の必要がなくなったので回復応答バックオフタイマーを取り消す（Ｓ１０１９）。
【００１４】上記の、受信した通常メッセージや自ノードが送信した回復要求メッセージは回復処理のためにロギングバッファに保持しておく。
【００１５】４）受信メッセージの型がＲＥＰＡＩＲ＿ＳＹＮＣの場合受信メッセージの型がＲＥＰＡＩＲ＿ＳＹＮＣの場合には、ロギングバッファに保持していたメッセージを削除する（Ｓ１０２０）。この同期メッセージは所定のタイミングに所定のノードから送信され、これに従って各ノードはロギングバッファ内の一定の範囲の過去のメッセージをフラッシュし、ロギングバッファのオーバフローを防止する。
【００１６】
【発明が解決しようとする課題】従来のマルチキャスト通信装置は、以上のようにマルチキャストドメイン内の全てのノードが喪失メッセージの回復処理について対等であるため、全てのノードが回復処理に備えなければならず、各ノードに用意すべき通信に必要なバッファサイズおよび回復処理のオーバヘッドが大きいという問題点があった。
【００１７】さらに、マルチキャストドメイン内の各ノード間で、喪失メッセージに関する回復処理を柔軟に分散することができないために、系全体で回復処理に要する負荷が高くなってしまうという問題点があった。
【００１８】さらに、喪失メッセージの回復処理を行うタイミングの決定に乱数値を用いているために、どのノードが実際に回復処理を行うかを事前に知ることができないという問題点があった。
【００１９】さらに、一つのマルチキャストドメインに多数のノードが接続されている場合に、通常は各ノード間のＲＴＴの値に有意な差が見られないため、各ノードが喪失メッセージの回復処理を行なってしまい、ネットワークの輻輳を起こしてしまうという問題点があった。
【００２０】さらに、ネットワーク通信量削減のために一部のノードだけが喪失メッセージの回復処理を行うように強いようとしても、系の特性に応じてその回復処理に責任を持つノードの数を制御することができないという問題点があった。
【００２１】さらに、喪失メッセージの回復処理のために必要とするロギングバッファのフラッシュのタイミングの決定にアプリケーションの特性を反映できないために、異なるアプリケーションが混在する通信環境で、必要なバッファサイズを最適化できないという問題点があった。
【００２２】さらに、喪失メッセージの回復処理のために必要になるバッファのフラッシュ処理のタイミングが、通信が行われるネットワーク環境の特性を反映できないために、異なる形態のネットワークに対して、このバッファサイズを柔軟に調整して回復処理性能を向上させることが困難であるという問題点があった。
【００２３】さらに、喪失メッセージの回復処理を行うノードの処理を効率化するためのバッファのフラッシュ処理に関して、そのフラッシュ範囲を安全かつ効率的に増減することが困難であるという問題点があった。
【００２４】この発明は上記のような問題点を解決するためになされたもので、ネットワークに接続された複数の通信ノードからなるシステムにおいて、各ノード間での通信にマルチキャスト・プロトコルを用いる際に喪失メッセージの回復処理を迅速に行い、かつシステムの性質の反映や拡張を容易にすることを特徴とするマルチキャスト通信制御方法を得ることを目的とする。
【００２５】
【課題を解決するための手段】第１の発明は、ネットワークに接続された複数のノード間相互の通信システムであるマルチキャスト通信システムにおいて、上記各ノードの初期化動作において上記各ノードに優先順位番号を付け、さらにマルチキャスト通信において１つ以上のノードがメッセージの受信に失敗するメッセージ喪失が発生した場合、下記ステップにより動作するようにしたものである。
（ａ）メッセージ喪失を起こしたノードが該喪失メッセージの回復を要求する回復要求メッセージを送信する回復要求メッセージ送信ステップ；
（ｂ）各ノードが該回復要求メッセージを受信する回復要求メッセージ受信ステップ；
（ｃ）最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、該回復要求メッセージに対して自ノードが応答するか否かの応答判定を行い、該判定結果に基づき該回復要求メッセージを受信した上記最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、下記の（ｃ１）あるいは（ｃ２）いずれかのステップを実行する応答判定ステップ；
（ｃ１）自ノードが応答すると判定した場合：バッファ内に保持している過去のメッセージを利用して該回復要求メッセージに応答する第１の回復応答メッセージを作成し、該第１の回復応答メッセージを回復応答メッセージ送信待ち行列に投入した後所定時間ｔ１経過後送信するように設定し、さらに上記最優先順位番号から上記所定の優先順位番号までの優先順位番号を持つ各ノードが下記のいずれかのステップにより動作する回復処理ステップ；
（ｃ１１）上記所定時間ｔ１経過以前に他ノードが上記回復要求メッセージに応答する第２の回復応答メッセージを送信した場合は上記第１の回復応答メッセージの送信を中止する応答中止ステップ；
（ｃ１２）上記所定時間ｔ１経過までに他ノードが上記回復要求メッセージに応答する第２の回復応答メッセージを送信しなかった場合は上記第１の回復応答メッセージを送信することにより回復処理を行う回復応答メッセージ送信ステップ；
（ｃ２）自ノードが応答すると判定しなかった場合：該回復要求メッセージを廃棄する応答拒否ステップ。
【００２６】第２の発明は、応答判定ステップにおいて、上記最優先順位番号を持つノードのみが自ノードが応答すると判定するようにしたものである。
【００２７】第３の発明は、上記所定の優先順位番号は、最優先順位番号を持つノードの初期化動作時に設定されるようにしたものである。
【００２８】第４の発明は、上記所定の優先順位番号は、最優先順位番号を持つノードの初期化後、該最優先順位番号を持つノードからの指示により任意に設定可能であるようにしたものである。
【００２９】第５の発明は、メッセージ喪失を起こしたノードが、上記回復要求メッセージ送信ステップにおいて該喪失メッセージの回復を要求する回復要求メッセージに判別番号を付けて送信し、該回復要求メッセージを受信した上記最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、上記応答判定ステップにおいて該判別番号と自ノードの優先順位番号を用いて応答判定を行うようにしたものである。
【００３０】第６の発明は、回復処理を行うノードが回復処理不能に陥った場合、その回復処理不能に陥ったノードの優先順位番号を越える優先順位番号を持つ各ノードの優先順位番号を繰り上げるようにしたものである。
【００３１】第７の発明は、上記回復応答メッセージ送信ステップにおける所定時間ｔ１は、該回復応答メッセージの送信元ノードの優先順位番号によって決定されるようにしたものである。
【００３２】第８の発明は、上記所定時間ｔ１は、回復応答メッセージの送信元ノードの優先順位番号とこのマルチキャスト通信システムに接続されているノードの総数およびこのマルチキャスト通信システムの伝送経路の遅延時間を用いて算出するようにしたものである。
【００３３】第９の発明は、最優先順位番号から所定の優先順位番号までの優先順位番号を持つノードがバッファ内に保持しているメッセージの削除範囲は、最優先順位番号を持つノードが設定するようにしたものである。
【００３４】第１０の発明は、上記削除範囲は、過去このマルチキャスト通信システムに接続されたいずれかのノードがメッセージを送信した時刻と、いずれかのノードが上記メッセージの喪失を検出して回復要求メッセージを送信した場合の該回復要求メッセージの送信時刻との時間間隔に基づいて決定するようにしたものである。
【００３５】第１１の発明は、上記削除範囲は、回復要求メッセージの送信頻度の増大に応じて縮小するようにしたものである。
【００３６】第１２の発明は、最優先順位番号から所定の優先順位番号までの優先順位番号を持つノードがバッファ内に保持しているメッセージを、最優先順位番号を持つノードがいずれかのノードからの回復要求メッセージを受信した場合のみ、略同一時刻に削除するようにしたものである。
【００３７】第１３の発明は、ネットワークに接続された複数のノード間相互の通信システムであるマルチキャスト通信システムにおいて、上記各ノードに優先順位番号を付け、上記各ノード間通信における受信メッセージにメッセージ喪失が検出された場合、該メッセージの喪失を検出した第１のノードは第１の回復要求メッセージを作成し、自ノードの優先順位番号によって決定される所定時間ｔ２経過後送信するよう設定した後、以下のいずれかのステップにより動作するようにしたものである。
（ａ）第２のノードが上記喪失メッセージと同一のメッセージに対する回復要求メッセージを送信し、これに対する回復応答メッセージを上記第１のノードが上記所定時間ｔ２経過以前に受信した場合には、上記第１の回復要求メッセージの送信を中止するステップ；
（ｂ）第２のノードが上記喪失メッセージと異なるメッセージに対する回復要求メッセージを送信し、これに対する回復応答メッセージを上記第１のノードが上記所定時間ｔ２経過以前に受信した場合には、この回復応答メッセージを廃棄するステップ；
（ｃ）上記所定時間ｔ２経過までにいかなる回復応答メッセージも受信しなかった場合には上記第１の回復要求メッセージを送信するステップ。
【００３８】第１４の発明は、上記所定時間ｔ２は、回復応答メッセージの送信元ノードの優先順位番号とこのマルチキャスト通信システムに接続されているノードの総数およびこのマルチキャスト通信システムの伝送経路の遅延時間を用いて算出するようにしたものである。
【００３９】第１５の発明は、ノードの優先順位番号は下記のステップにより付けるようにしたものである。
（ａ）マルチキャスト通信システムに参加しようとするノードが参加要求メッセージを送信する参加要求ステップ；
（ｂ）上記参加要求メッセージを送信したノードが、上記参加要求メッセージに応答して送信される参加確認メッセージを受信したか否かの判定を行い、該判定結果に基づいて上記参加要求メッセージを送信したノードが下記のいずれかのステップを実行する参加確認ステップ；
（ｂ１）参加確認メッセージを受信しなかった場合：自ノードに最優先順位番号を付け、以後他ノードが送信した参加要求メッセージを受信した場合には識別番号を含む参加確認メッセージを送信するよう自ノードを設定する最優先順位設定ステップ；
（ｂ２）参加確認メッセージを受信した場合：この参加確認メッセージに含まれる識別番号に基づいて決定される優先順位番号を自ノードに設定する一般順位設定ステップ。
【００４０】
【発明の実施の形態】
実施の形態１．この発明の実施の形態１について、図１から図４に基づいて説明する。図１はこの実施の形態１におけるマルチキャスト通信システムを構成する各ノードのブロック図、図２はこの実施の形態１におけるノードの初期化を示すフローチャート、図３はこの実施の形態１におけるサーバ・ノードの動作を示すフローチャート，図４はこの実施の形態１におけるクライアント・ノードの動作を示すフローチャートである。
【００４１】まず、この実施の形態１の構成について説明する。図１に示す装置のブロック図において、１Ａは通信装置、１Ｂはこの通信装置１を利用するためのアプリケーション・プログラムであり、この通信装置１Ａとアプリケーション・プログラム１Ｂの組合わせを以後ノードと呼ぶ。２は上記アプリケーション・プログラム１Ｂとこの通信装置１Ａのインタフェースを司るアプリケーション・メッセージ送受信手段、３は通常メッセージをアプリケーション・プログラム１Ｂ側から後述のネットワーク８側へ、またはネットワーク８側からアプリケーション・プログラム１Ｂ側へ、ヘッダの挿入あるいは削除を行って受け渡す通常メッセージ処理手段であり、このヘッダには発信元のノードに関する情報、発信元のノード毎に管理されるメッセージのシーケンス番号、メッセージの型等の情報が含まれている。
【００４２】４はネットワーク８へ送信される通常メッセージを到着順に処理する通常メッセージ送信キュー、５はネットワーク８から受信された通常メッセージを到着順に処理する通常メッセージ受信キュー、６はこの通信装置１Ａからメッセージをネットワーク８に送出するメッセージ送信手段、７はネットワーク８からメッセージをこの通信装置に取り込むメッセージ受信手段、８は複数のノードを相互に接続するネットワークであり、この中の一定範囲のノード群をここではマルチキャストドメインと呼ぶ。この範囲は物理的な距離で決定されるものではなく、また１つのマルチキャストドメイン内のノードの数は必ずしも固定されていない。９は受信したメッセージの型を分析して適切な処理部へ分配するメッセージ型判定手段、１０は回復要求メッセージ受信キュー、１１は回復応答メッセージ受信キュー、１２は回復要求メッセージ送信キュー、１３は回復応答メッセージ送信キュー、１４は喪失メッセージに対する回復処理を司る回復メッセージ処理手段、１５は回復要求に備えて通常メッセージをロギングする通常メッセージ格納手段、１６は受信した回復要求メッセージをロギングする回復要求メッセージ格納手段、１７はこのノードのマルチキャストドメイン内での役割を決定し、装置を初期化するマルチキャストドメイン管理手段、１８はこのノードのマルチキャストドメイン内でのノード順位を決定するノード順位決定手段、１９は現在のノード順位の状態を保持するノード順位管理手段である。
【００４３】以上のようなノードを複数含むマルチキャストドメインにおいて、１つのノードから送信されたメッセージは同じマルチキャストドメイン内の他のすべてのノードによって受信される。
【００４４】また、メッセージの型として、ここでは以下の４種を使用する。
１）通常メッセージであることを示す“ＮＯＲＭＡＬ”；
２）あるノードでメッセージのメッセージの喪失を検出した時に、このノードが送信する回復要求メッセージであることを示す“ＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴ”；
３）（２）の回復要求メッセージに呼応して他ノードから送信される回復応答メッセージであることを示す“ＲＥＰＡＩＲ＿ＲＥＰＬＹ”；
４）あるノードが新たにマルチキャストドメインへ参加する際に通知されるＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージであることを示す“ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹ”である。このうち回復応答メッセージには、この回復応答メッセージが送信される要因となった回復要求メッセージの送信元ノードが受信に失敗した通常メッセージを含んで送信される。
【００４５】以下、この装置の動作について、次の順に説明する。
１．初期化動作２．初期化後のサーバ・ノードの動作３．初期化後のクライアント・ノードの動作【００４６】１．初期化動作最初に、この実施の形態1におけるノードの初期化動作について、図２に示すフローチャートを用いて説明する。まず、通信装置１Ａが動作し始めると（Ｓ１０１）、マルチキャストドメイン管理手段１７は、カウンタｊｏｉｎ＿ｃｏｕｎｔの値を０に設定する（Ｓ１０２）。アプリケーション・プログラム１Ｂは、アプリケーション・メッセージ送受信手段２を用いて通信装置１Ａにマルチキャストドメインに参加する意志表示のメッセージ（ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージ）を送信するよう要求し、通常メッセージ処理手段３は、このメッセージに通常メッセージヘッダを付加し、通常メッセージ送信キュー４へ投入する。
【００４７】通常メッセージ送信キュー4は、投入されたメッセージを順次メッセージ送信手段６に送り、メッセージ送信手段６がこのメッセージをネットワーク８へ送信する（Ｓ１０３）。この時点で、マルチキャストドメイン管理手段はカウンタｊｏｉｎ＿ｃｏｕｎｔの値を１増加する（Ｓ１０４）。ｊｏｉｎ＿ｃｏｕｎｔの値が初期化境界値Ｎｉｎｉｔ（通常３程度）に達した場合には、マルチキャストドメイン管理手段は自ノードをサーバ・ノードとみなすことをノード順位決定手段１８に通知し、ノード順位決定手段１８はノード順位を１に決定し、ノード順位管理手段１９がこの値を保持する（Ｓ１０６）。
【００４８】前記の初期化境界値Ｎｉｎｉｔはサーバ・ノードのアプリケーション・プログラム１Ｂが持つ値が使用されるが、予めこのマルチキャストドメインで使用するマルチキャスト・プロトコルで設定されている値を使用してもよい。
【００４９】またサーバ・ノードについて補足すると、サーバ・ノードは他ノードが送信したＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージを受信したときに、このマルチキャストドメインへの参加を許可すると同時にこのマルチキャストドメインに参加した順位（ノード順位）を通知するメッセージ（ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージ）を送信する。
【００５０】さらにＳ１０５がＮＯの場合、すなわちｊｏｉｎ＿ｃｏｕｎｔの値が初期化境界値Ｎｉｎｉｔに達しておらずサーバ・ノードに設定されていない場合には、通信装置１Ａ内ではメッセージ受信手段７がネットワーク８からＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージが到着するのを待つ（Ｓ１０７）。
【００５１】ネットワーク８からメッセージ受信手段７を用いて受信されたメッセージの型を、メッセージ型判定手段９により分析してＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージであるか否かを判定し（Ｓ１０８）、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを受信した場合は、マルチキャストドメイン管理手段１７は自ノードをクライアント・ノードとして設定するようにノード順位決定手段１８へ受信メッセージと共に通知し、ノード順位決定手段１８はこのＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージからノード順位を取り出して、その値をノード順位管理手段１９に格納する（Ｓ１０９）。もしＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージが受信されていなければ、一定時間待機し（Ｓ１１０）、Ｓ１０４以降を繰り返す。
【００５２】このように、あるノードが初期化の段階でＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを所定の回数内に受信できなかった場合は同じマルチキャストドメイン内にサーバ・ノードは存在していないとみなして、これ以後ノード順位１のサーバ・ノードとして動作し、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを受信した場合はすでにサーバ・ノードが他に存在するので、これ以後ノード順位２以上のクライアント・ノードとして動作する。
【００５３】２．初期化後のサーバ・ノードの動作次に、初期化後のサーバ・ノードの動作について、図３のフローチャートに沿って説明する。サーバ・ノードが動作状態に入ると（Ｓ１２１）、メッセージ受信手段７がネットワーク８からメッセージを受信し（Ｓ１２２）、メッセージ型判定手段９がメッセージの型を判定する（Ｓ１２３）。
【００５４】以下受信したメッセージの型により分類し、その後の動作について説明する。
【００５５】１）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、メッセージは回復応答メッセージ受信キュー１１に投入され、回復メッセージ処理手段１４が回復要求メッセージ格納手段１６を参照して自ノードの要求への応答かを判断し（Ｓ１２４）、もしそうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ１２５）、通常メッセージ部分を通常メッセージ受信キュー５へ投入する（Ｓ１２６）。自ノードへの応答でない場合はこのメッセージは廃棄される。
【００５６】２）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、メッセージは回復要求メッセージ受信キュー１０に投入され、回復メッセージ処理手段１４によって回復の対象となる通常メッセージを通常メッセージ格納手段１５から検索して取り出す（Ｓ１２７）とともに、この回復要求メッセージを回復要求メッセージ格納手段１６にロギングする。さらにこの取り出した通常メッセージを含む回復応答メッセージを生成し（Ｓ１２８）、この回復応答メッセージを回復応答メッセージ送信キュー１３へ投入する（Ｓ１２９）。
【００５７】３）受信メッセージの型がＮＯＲＭＡＬの場合受信したメッセージの型がＮＯＲＭＡＬの場合は、通常メッセージ受信キュー５に投入され、通常メッセージ処理手段３が通常メッセージ格納手段１５に保持されている過去の受信メッセージとの照合により、メッセージのシーケンス番号に飛びがあるかどうかを調べる（Ｓ１３０）。飛びがある場合には、メッセージを喪失したと判断し、回復メッセージ処理手段１４に回復を要請する。回復メッセージ処理手段１４はこの要請を受け回復要求メッセージを生成し（Ｓ１３１）、回復要求メッセージを回復要求メッセージ送信キュー１２へ投入する（Ｓ１３２）。メッセージ喪失の有無にかかわらず、通常メッセージ処理手段３はこの受信メッセージを後の回復処理のために通常メッセージ格納手段１５を用いて保持し（Ｓ１３３）、その後、受信メッセージはアプリケーション・メッセージ送受信手段２のインタフェースを通して、アプリケーション・プログラム1に渡される（Ｓ１３４）。
【００５８】３．初期化後のクライアント・ノードの動作次いで、初期化後のクライアント・ノードの動作について図４のフローチャートに沿って説明する。まず、クライアント・ノードが動作状態に入ると（Ｓ１４１）、メッセージ受信手段７がネットワーク８からメッセージを受信し（Ｓ１４２）、メッセージ型判定手段９がメッセージの型を判定する（Ｓ１４３）。
【００５９】以下、受信したメッセージの型により分類し、その後の動作について説明する。
【００６０】１）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、メッセージは回復応答メッセージ受信キュー１１に投入され、回復メッセージ処理手段１４が自ノードの要求への応答かを判断し（Ｓ１４４）、もしそうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ１４５）、通常メッセージ部分を通常メッセージ受信キュー５へ投入する（Ｓ１４６）。自ノードへの応答でない場合はこのメッセージは廃棄される。
【００６１】２）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、メッセージ型判定手段９は何もせずにこのメッセージを廃棄する。
【００６２】３）受信メッセージの型がＮＯＲＭＡＬの場合受信メッセージの型がＮＯＲＭＡＬの場合は、通常メッセージ受信キュー５に投入され、通常メッセージ処理手段３が通常メッセージ格納手段１５に保持されている過去の受信メッセージとの照合により、メッセージのシーケンス番号に飛びがあるかどうかを調べる（Ｓ１４７）。飛びがある場合には、メッセージを喪失したと判断し、回復メッセージ処理手段１４に回復を要請する。回復メッセージ処理手段１４はこの要請を受け回復要求メッセージを生成し（Ｓ１４８）、回復要求メッセージを回復要求メッセージ送信キュー１２へ投入する（Ｓ１４９）。メッセージ喪失の有無にかかわらず、受信メッセージはアプリケーション・メッセージ送受信手段２のインタフェースを通して、アプリケーション・プログラム1に渡される（Ｓ１５０）。
【００６３】以上のように、この発明のマルチキャスト通信制御の方法によれば、装置の初期化においてマルチキャストドメイン管理手段１７がＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージとＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを用いて各ノードのノード順位を１以上の整数値に設定し、ノード順位が１であるノードを喪失メッセージの回復処理を行うサーバ・ノードに設定する。
【００６４】またノード順位が２以上の場合には、そのノードをクライアント・ノードに設定し、クライアント・ノードではいかなる回復処理も行わないため、従来全てのノードに必要であった回復要求メッセージ受信キュー１０、回復応答メッセージ送信キュー１３、通常メッセージ格納手段１５がクライアント・ノードでは不要になり、さらにクライアント・ノードの回復メッセージ処理手段１４ついては、回復応答を行うための通常メッセージ格納手段１５からのメッセージ検索処理が不要になるために、マルチキャスト通信装置に必要なバッファサイズおよび回復処理のオーバヘッドを削減することができる。この効果は、マルチキャスト通信への参加ノード数が増えれば更に顕著になる。
【００６５】また以上の例では、サーバ・ノードは他ノードが送信したＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージを受信したときに、このマルチキャストドメインへの参加を許可すると同時にこのマルチキャストドメインに参加した順位（ノード順位）を通知するメッセージ（ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージ）を送信する例を示したが、サーバ・ノードが送信するのはノード順位そのものの数字ではなく、間接的にノード順位を示す別の識別番号あるいは識別符号でもよい。
【００６６】実施の形態２．次に、この発明の実施の形態２について、図１、図４および図５に基づいて説明する。
【００６７】前記の実施の形態１では、通信システム内の各ノードに順位付けを行い、このノード順位１のノードを他ノードから出される喪失メッセージの回復要求に応じる責任を持つサーバ・ノードとし、ノード順位２以上のクライアント・ノードはこのような責任を持たないようにしたものであるが、本実施形態では系の性格によってサーバ・ノードの負荷が変動する場合に、実施の形態１と同じノードの順位付け方法を用いてサーバ・ノードの数を変更できるようにしたものである。
【００６８】ただし、本実施形態の説明では、初期化時に行われる複数のサーバ・ノードの決定法のみを説明しており、これら複数のサーバ・ノードの初期化後の動作については、実施の形態３以降で順次説明することとする。
【００６９】また、本実施形態における各ノードのブロック図は、前記実施の形態１で説明した図１に示すブロック図と同様であり、さらに、初期化後におけるクライアント・ノードの動作は前記実施の形態１で説明した図４のフローチャートに従うので、それぞれ説明を省略する。
【００７０】次にこの装置の動作について、図５に示すフローチャートを用いて初期化動作のみを説明する。まず、図５において通信装置１Ａが動作し始めると（Ｓ２０１）、マルチキャストドメイン管理手段１７は、カウンタｊｏｉｎ＿ｃｏｕｎｔの値を０に設定する（Ｓ２０２）。アプリケーション・プログラム１Ｂはアプリケーション・メッセージ送受信手段２を用いて通信装置１Ａにマルチキャストドメインに参加する意志表示のメッセージ（ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージ）を送信するよう要求し、通常メッセージ処理手段３は、このメッセージに通常メッセージヘッダを付加し、通常メッセージ送信キュー４へ投入する。通常メッセージ送信キュー4は投入されたメッセージを順次メッセージ送信手段６に送り、メッセージ送信手段６がこのメッセージをネットワーク８へ送信する（Ｓ２０３）。この時点で、マルチキャストドメイン管理手段はカウンタｊｏｉｎ＿ｃｏｕｎｔの値を１増加する（Ｓ２０４）。
【００７１】ｊｏｉｎ＿ｃｏｕｎｔの値が予めこのマルチキャストドメインで設定されている初期化境界値Ｎｉｎｉｔ（通常３程度）に達した場合には、マルチキャストドメイン管理手段１７は自ノードを主サーバ・ノードとみなすことをノード順位決定手段１８に通知し、ノード順位決定手段１８はノード順位を１に決定し、ノード順位管理手段１９がこの値を保持する（Ｓ２０６）。
【００７２】主サーバ・ノードは同じマルチキャストドメイン内の他のノードが発信したＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージを受信したときに、このマルチキャストドメインへの参加を許可すると同時にこのマルチキャストドメインに参加した順位（ノード順位）を通知するメッセージ（ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージ）を送信する。
【００７３】Ｓ２０５がＮＯの場合、すなわちｊｏｉｎ＿ｃｏｕｎｔの値が初期化境界値Ｎｉｎｉｔに達しておらず主サーバ・ノードに設定されていない場合には、通信装置１Ａ内ではメッセージ受信手段７がネットワーク８からＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージが到着するのを待ち（Ｓ２０７）、ネットワーク８からメッセージ受信手段７を用いて受信されたメッセージの型をメッセージ型判定手段９により分析して、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージであるか否かを判定する（Ｓ２０８）。
【００７４】ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを受信した場合は、そのＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージで示される自ノードのノード順位と、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージで示される系の信頼度基準値Ｎｒｅｌｙ（Ｎｒｅｌｙは正の整数）を比較し（Ｓ２０９）、ノード順位がＮｒｅｌｙ以下であれば自ノードを副サーバ・ノードとして設定する（Ｓ２１０）。
【００７５】この後、必要に応じて自ノードのノード順位を送信する（Ｓ２１１）。このノード順位はこの時点でのサーバ・ノードの総数Ｎｓを示しており、メッセージの型としてＳＥＲＶＥＲ＿ＮＵＭＢＥＲを持つサーバ数通知メッセージとして送信される。
【００７６】またノードの順位がＮｒｅｌｙを越える場合は、自ノードを一般のクライアント・ノードとして設定する（Ｓ２１２）。一方、Ｓ２０８においてＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージが受信されていなければ一定時間待機し（Ｓ２１３）、Ｓ２０４以下を繰り返す。
【００７７】このように、初期化の段階でＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを所定の回数内に受信できなかった場合は同じマルチキャストドメイン内に主サーバ・ノードは存在していないとみなして、これ以後ノード順位１の主サーバ・ノードとして動作する。ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを受信した場合はノード順位が系の信頼度基準値Ｎｒｅｌｙ以下であれば副サーバ・ノードとして動作し、Ｎｒｅｌｙを越える場合はクライアント・ノードとして動作する。
【００７８】すなわち、ノード順位１が主サーバ・ノード、ノード順位が２からＮｒｅｌｙまでが副サーバ・ノード、ノード順位がＮｒｅｌｙ＋１以上がクライアント・ノードである。ただしＮｒｅｌｙ＝１とした場合は副サーバ・ノードを使用せず、実施の形態１の形態を採用することを意味する。
【００７９】以上のように、この発明の実施形態２では、系の信頼度基準値Ｎｒｅｌｙを調整することにより、系の性格によって喪失メッセージの回復処理を行うサーバ・ノードの負荷が大きくなる場合にサーバ・ノードの数を増加させて負荷分散をするなど、実施の形態１と同じノードの順位付け方法を用いてサーバ・ノードの負荷変動に対応してサーバ・ノードの数を変更することができる。
【００８０】ここで使用する信頼度基準値Ｎｒｅｌｙは、主サーバ・ノードが使用する通信装置１Ａのマルチキャストドメイン管理手段１７で設定してもよく、この場合は装置の初期化動作の段階で設定される。また主サーバ・ノードが使用するアプリケーション・プログラム１Ｂで設定してもよく、この場合は装置の初期化以後にも任意の値に設定可能である。
【００８１】実施の形態３．次に、この発明の実施の形態３について、図６および図７に基づいて説明する。
【００８２】前記の実施の形態１では、回復要求メッセージおよび回復応答メッセージの送信までのタイミングについては特に触れていないが、本実施形態は、回復要求メッセージ送信キューおよび回復応答メッセージ送信キューから回復要求メッセージおよび回復応答メッセージが取り出され、ネットワークへ送信されるまでの時間を決定するタイマー（バックオフタイマー）を、ノード順位番号を用いて設定するようにしたものであリ、この設定法について説明する。
【００８３】ただし、ここで設定するバックオフタイマーは、回復処理を行うサーバ・ノードにおいては回復要求メッセージと回復応答メッセージの双方について有効であり、また、回復処理を行なわないクライアント・ノードにおいては回復要求メッセージについてのみ有効であることは、もちろんである。
【００８４】まず、図について説明すると、図６は本実施形態のマルチキャスト通信システムを構成する各ノードのブロック図であり、図７は本実施形態におけるバックオフタイマー設定手段の動作を示すフローチャートである。
【００８５】以下、この実施の形態３の構成について説明するが、図６のブロック図において、通信装置１Ａからノード順位管理手段１９まではこれまでの実施の形態１と同一であるので、同一符号を付し説明を省略する。またメッセージの型も前記の実施の形態１と同様である。
【００８６】図６における新たなブロックである２０は、回復メッセージ処理手段１４が回復要求メッセージ送信キュー１２および回復応答メッセージ送信キュー１３に設定するメッセージ発行遅延タイマー（バックオフタイマー）の値を設定するバックオフタイマー設定手段である。
【００８７】次に、動作について説明する。この実施の形態３の要点であるバックオフタイマーは、この装置の初期化時に設定される。その動作を図７のフローチャートに沿って説明する。また、今後の説明において、サーバ・ノードとはノード順位にかかわらず主サーバ・ノードと副サーバ・ノードの総称とする。まず、装置が起動すると（Ｓ３０１）、実施の形態２と同様の初期化を行い、このノードをサーバ・ノードあるいはクライアント・ノードとして設定する（Ｓ３０２）。さらに、バックオフタイマー設定手段２０は初期化を行った時点で予想されるこのマルチキャストドメインのラウンドトリップタイム（ＲＴＴ）値の最大値をＴに設定する（Ｓ３０３）。ＲＴＴは一組のノードにおいて、一方のノードが送信したメッセージに対する応答が他方のノードから返ってくるまでの時間を意味する。次に、このドメインに参加するノードの最大数をノード順位管理手段１９に問い合わせその値をＮに設定する（Ｓ３０４）。さらにノード順位管理手段１９から現在のノード順位を取得し、この値をＯｎに設定する（Ｓ３０５）。
【００８８】こうして収集した値をもとに、バックオフタイマーの値Ｔｂａｃｋｏｆｆ値を、算式（Ｏｎ―１）＊Ｔ／Ｎにより算出する（Ｓ３０６）。バックオフタイマー設定手段２０は、このＴｂａｃｋｏｆｆ値を回復メッセージ処理手段１４に通知する。回復メッセージ処理手段１４は、回復要求メッセージ送信キュー１２および回復応答メッセージ送信キュー１３に投入されたメッセージがメッセージ送信手段６へ送られるまでの時間をＴｂａｃｋｏｆｆ値に設定する。
【００８９】このバックオフタイマーの算式を使用すれば、ノード順位１（Ｏｎ＝１）のサーバ・ノードでは、回復要求メッセージ送信キュー１２および回復応答メッセージ送信キュー１３に投入されたメッセージがメッセージ送信手段６へ送られるまでの時間は０であり、以下ノード順位が大きくなるほどこの時間は長くなる。
【００９０】以上のように、本実施形態では、回復要求メッセージおよび回復応答メッセージの送出タイミングの算出に、各ノード間のＲＴＴ値を用いずにノードの順位番号を用いるために、ノード間のＲＴＴの値に有意な差が見られないような同一ネットワーク内の各マルチキャストノードに対しても、回復要求メッセージあるいは回復応答メッセージの多発によるネットワークの輻輳を招かないようにすることができる。さらに、回復応答メッセージの送出タイミングの算出に乱数値を用いていないために、各ノードのタイマーがいかなる値に設定しているかを確実な値として調べることが可能になる。
【００９１】また、Ｔｂａｃｋｏｆｆ値を算出する式は、各ノードから回復要求メッセージあるいは回復応答メッセージが送信されるタイミングがネットワークの輻輳を招かないもので、算式に各ノードのノード順位を使用していれば上記の形でなくてもよい。
【００９２】実施の形態４．次に、実施の形態４について、図５〜図８に基づいて説明する。
【００９３】前記の実施の形態２では、喪失メッセージの回復処理を行う複数のサーバ・ノードの設定法についてのみ説明し、これら複数のサーバ・ノード間の役割分担については触れていないが、この本実施形態では、複数のサーバ・ノードが喪失メッセージの回復処理の担当範囲を分担する場合の分担法について説明する。
【００９４】ただし、本実施形態における各ノードの構成は、すでに実施の形態３で説明した図６のブロック図と同様であり、また、図６中のバックオフタイマー設定手段の動作も同じ実施の形態３で説明した図７のフローチャートに従うので、これらの説明は省略する。
【００９５】さらに、本実施形態における各ノードの初期化動作は、すでに実施の形態２で説明した図５のフローチャートと同様であるので、これについても説明は省略する。
【００９６】以下、本実施形態における初期化後のサーバ・ノードの動作を、図８に示すフローチャートに沿って説明する。
【００９７】まず、図８において、サーバ・ノードが動作状態に入ると（Ｓ４０１）、メッセージ受信手段７がネットワーク８からメッセージを受信し（４０２）、メッセージ型判定手段９がメッセージの型を判定する（Ｓ４０３）。
【００９８】以下、受信したメッセージの型により分類し、その後の動作について説明する。
【００９９】１）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、前記の実施の形態１または実施の形態２と同様に自ノードの要求への応答かを判断し（Ｓ４０４）、そうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ４０５）、通常メッセージ部分を通常メッセージ受信キュー５へ投入する（Ｓ４０６）。Ｓ４０４がＮＯ、すなわち自ノードの要求への応答でない場合には、このメッセージは廃棄される。
【０１００】２）受信メッセージの型がＮＯＲＭＡＬの場合受信したメッセージの型がＮＯＲＭＡＬの場合も、前記の実施の形態１または実施の形態２と同様に、メッセージのシーケンス番号に飛びがあるかどうかを調べることにより、メッセージ喪失があるかどうかを調べる（Ｓ４１１）。メッセージ喪失の有無にかかわらず、通常メッセージ処理手段３は、このメッセージを後の回復処理のために通常メッセージ格納手段１５を用いて保持する（Ｓ４１４）。その後、受信メッセージは、アプリケーション・プログラム１に引き渡される（Ｓ４１５）。
【０１０１】３）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、メッセージは回復要求メッセージ受信キュー１０に投入される。回復メッセージ処理手段１４は後述の判断法によりこのメッセージが自ノードの担当かどうかを判断し（Ｓ４０７）、もし自ノードの担当であると判断したら回復メッセージ処理手段１４によって回復の対象となるメッセージを通常メッセージ格納手段１５から検索して取り出す（Ｓ４０８）。さらにこの取り出した通常メッセージを含む回復応答メッセージを生成し（Ｓ４０９）、この回復応答メッセージを回復応答メッセージ送信キュー１３へ投入する（Ｓ４１０）。自ノードの担当でないと判断したときはこのメッセージは廃棄される。
【０１０２】次に、上記のＳ４０７において回復要求メッセージが自ノードの担当であるかどうかを判断する際の判断法について説明する。
【０１０３】この判断法には，例えば自ノードのノード順位番号とメッセージのシーケンス番号を被除数とし、これをある正の整数である除数で割った時の剰余を利用する方法がある。
【０１０４】以下、この方法について説明するが，以下の説明において正の整数Ａを正の整数Ｂで割った時の剰余を求める剰余演算をＭＯＤ（Ａ，Ｂ）
で表わす。例えばＭＯＤ（５，２）＝１、ＭＯＤ（６，３）＝０である。またＭＯＤ（１，２）＝１、ＭＯＤ（４，６）＝４である。
【０１０５】最初に、ノード順位番号とメッセージのシーケンス番号に対して除数を２とした場合を例として示す。まず，各サーバ・ノードの回復メッセージ処理手段１４は初期化が完了した段階で自ノードのノード順位ＯｎについてＭＯＤ（Ｏｎ，２）
を求めておく。この値はノード順位１，２，３，４，・・・に対して１，０，１，０，・・・となり、ノード順位が奇数か偶数かによって決定される。
【０１０６】次いで、各サーバ・ノードの回復メッセージ処理手段１４は図８のＳ４０７において受信した回復要求メッセージのシーケンス番号Ｎｍ についてＭＯＤ（Ｎｍ，２）
を求める。この値はメッセージのシーケンス番号１，２，３，４，・・・に対して１，０，１，０，・・・となり、メッセージのシーケンス番号が奇数か偶数かによって決定される。
【０１０７】次いで、各サーバ・ノードの回復メッセージ処理手段１４は自ノードの ＭＯＤ（Ｏｎ，２） と受信した回復要求メッセージの ＭＯＤ（Ｎｍ，２） を比較し、一致すればその回復要求メッセージを自ノードの担当と判断する。すなわち、シーケンス番号が奇数の回復要求メッセージについてはノード順位が奇数のサーバ・ノードが自ノードの担当と判断し、シーケンス番号が偶数の回復要求メッセージについてはノード順位が偶数のサーバ・ノードが自ノードの担当と判断する。
【０１０８】この場合、サーバ・ノードの数が３以上の場合、シーケンス番号が奇数のメッセージについは、ノード順位が１，３・・・と複数のサーバ・ノードが担当と判断する。同じくサーバ・ノードの数が４以上であれば、シーケンス番号が偶数のメッセージについては、ノード順位が２，４・・・と複数のサーバ・ノードが自ノードの担当と判断する。
【０１０９】しかし、実施の形態３で説明したように、回復応答メッセージ送信キューから、回復応答メッセージが取り出されネットワークへ送出されるまでの時間を決定するタイマー（バックオフタイマー）の長さがノード順位が大きくなるほど長くなるので、通常はシーケンス番号が奇数のメッセージについてはノード順位１のサーバ・ノードが最も早く応答し、他のサーバ・ノードは応答する必要がない。同様にシーケンス番号が偶数のメッセージについては、通常はノード順位２のサーバ・ノードが応答し、他のサーバ・ノードは応答する必要がない。応答すべきサーバ・ノードが応答しない場合のみ、順次ノード順位の大きなサーバ・ノードが応答する。
【０１１０】以上のように、ノード順位番号とメッセージのシーケンス番号に対して除数を２とした場合は、２つのサーバ・ノードが自身のノード順位が偶数か奇数かに基づいて、他ノードから送信される回復要求メッセージのシーケンス番号が偶数のもののみ、あるいは奇数のもののみに対して、喪失メッセージの回復処理を分担して行うため、どのメッセージの喪失確率も一様である一般的状況に対して、サーバ・ノードの数が１つの場合に比べ平均的な回復処理用メッセージの数がほぼ半分になり、ネットワークの輻輳を防ぐことができる。
【０１１１】次に、ノード順位番号とメッセージのシーケンス番号に対して除数を３とした場合を例として示す。これも上述の除数２の場合と同様であり、各サーバ・ノードの回復メッセージ処理手段１４は初期化が完了した段階で自ノードのノード順位ＯｎについてＭＯＤ（Ｏｎ，３）
を求めておく。この値はノード順位１，２，３，４，５，６・・・に対して１，２，０，１，２，０・・・となる。
【０１１２】ついで、各サーバ・ノードの回復メッセージ処理手段１４は図８のＳ４０７において受信した回復要求メッセージのシーケンス番号ＮｍについてＭＯＤ（Ｎｍ，３）
を求める。この値はメッセージのシーケンス番号１，２，３，４，５，６・・・に対して１，２，０，１，２，０・・・となる。
【０１１３】次いで、各サーバ・ノードの回復メッセージ処理手段１４は、自ノードの ＭＯＤ（Ｏｎ，３） と受信した回復要求メッセージの ＭＯＤ（Ｎｍ，３）を比較し、一致すればその回復要求メッセージを自ノードの担当と判断する。例えば、シーケンス番号１の回復要求メッセージについてはノード順位１，４，７・・・のサーバ・ノードが同時に自ノードの担当と判断する。シーケンス番号４，７・・・の回復要求メッセージについても同様にノード順位１，４，７・・・のサーバ・ノードが同時に自ノードの担当と判断する。またシーケンス番号２，５，８・・・の回復要求メッセージについてはそれぞれノード順位２，５，８・・・のサーバ・ノードが、シーケンス番号３，６，９・・・の回復要求メッセージについてはそれぞれノード順位３，６，９・・・のサーバ・ノードが同時に自ノードの担当と判断する。
【０１１４】しかし、実施の形態３で説明したように、回復応答メッセージ送信キューから、回復応答メッセージが取り出されネットワークへ送出されるまでの時間を決定するタイマー（バックオフタイマー）の長さがノード順位が大きくなるほど長くなるので、通常はシーケンス番号が１，４，７・・・のメッセージについてはノード順位１のサーバ・ノードが最も早く応答し、他のサーバ・ノードは応答する必要がない。同様にシーケンス番号が２，５，８・・・のメッセージについては通常はノード順位２のサーバ・ノードが、シーケンス番号が２，５，８・・・のメッセージについてはノード順位３のサーバ・ノードが応答し、他のサーバ・ノードは応答する必要がない。応答すべきサーバ・ノードが応答しない場合のみ、順次ノード順位の大きなサーバ・ノードが応答する。
【０１１５】以上のように、ノード順位番号とメッセージのシーケンス番号に対して除数を３とした場合は、３つのサーバ・ノードが喪失メッセージの回復処理を分担して行うため、どのメッセージの喪失確率も一様である一般的状況に対して、サーバ・ノードの数が１つの場合に比べ平均的な回復処理用メッセージの数がほぼ３分の１になり、ネットワークの輻輳を防ぐことができる。
【０１１６】以上の例では、ノード順位番号とメッセージのシーケンス番号に対して除数を２あるいは３とした場合を示したが、これ以外の除数を用いてもよく、除数と等しい数のサーバ・ノードが回復処理を優先的に分担することになる。この際，除数をサーバ・ノードの数を越える数値に設定するとどのサーバ・ノードも応答しないメッセージが発生することがあるので、除数はサーバ・ノードの数以下に設定しなければならない。
【０１１７】また、除数が１の場合は、ノード順位番号１のサーバ・ノードが回復処理を優先的に担当し、このサーバ・ノードが応答しない場合のみ順次ノード順位の大きなサーバ・ノードが応答する。
【０１１８】さらに、除数をサーバ・ノードの総数Ｎｓと一致させれば、全てのサーバ・ノードが回復処理を分担して行うことになり効果が高い。これを実現するためには各サーバ・ノードがその時点でのサーバ・ノードの総数Ｎｓを保持している必要があるが、副サーバ・ノードは図５に示した初期化のフローチャート内で、副サーバ・ノードと設定された後でメッセージの型としてＳＥＲＶＥＲ＿ＮＵＭＢＥＲを持つサーバ・ノード数通知メッセージを送信する（Ｓ２１１）ので、これを各サーバ・ノードは回復メッセージ処理手段１４に保持し、サーバ数通知メッセージが送信されるたびにこれを更新することにより、常に最新のサーバ・ノードの総数Ｎｓを保持することが可能となる。
【０１１９】以上のように、本実施形態では複数のサーバ・ノードが任意の正の整数Ｐを用いて、自身のノード順位Ｏｎに対するＭＯＤ（Ｏｎ，Ｐ）と他ノードから送信される回復要求メッセージのシーケンス番号Ｎｍに対するＭＯＤ（Ｎｍ，Ｐ）を比較し、一致する場合のみ喪失メッセージの回復処理を分担して行うため、どのメッセージの喪失確率も一様である一般的状況に対して、サーバの数が１つの場合に比較して平均的な回復処理用メッセージの数がほぼＰ分の１になり、ネットワークの輻輳を防ぐことができる。特に、Ｐを全サーバ・ノード数と一致させた場合は全てのサーバ・ノードが回復処理をほぼ均等に分担するので、効果が高い。
【０１２０】本実施形態では、自身のノード順位Ｏｎに対するＭＯＤ（Ｏｎ，Ｐ）と他ノードから送信される回復要求メッセージのシーケンス番号Ｎｍに対するＭＯＤ（Ｎｍ，Ｐ）を比較したが、Ｏｎ、Ｎｍ を一定の規則の下で変形した後Ｐによる剰余演算を行うなど、他の方法を適用することも可能である。
【０１２１】実施の形態５．次に、実施の形態５について、図５および図９〜図１２に基づいて説明する。
【０１２２】前記の実施の形態１〜実施の形態４では、サーバ・ノードは初期化の段階のノード順位番号によって決定されていたが、ここではサーバ・ノードに障害が発生した際に、ノード順位が低い他のノードのノード順位を繰り上げ、この障害を起こしたサーバ・ノードに置き換わるようにした例ついて説明する。
【０１２３】まず、図について説明すると、図５は前記実施の形態２と同様であるこの実施の形態５におけるノードの初期化動作のフローチャートである。図９はこの実施の形態５におけるマルチキャスト通信システムを構成するブロック図、図１０はこの実施の形態５における副サーバ・ノードの動作のフローチャート、図１１はこの実施の形態におけるロギングバッファ同調処理のフローチャート、図１２はこの実施の形態におけるクライアント・ノードの動作のフローチャートである。
【０１２４】次に、この実施の形態５の構成について図９のブロック図に基づいて説明するが、図において、通信装置１Ａからバックオフタイマー設定手段２０までは前記の実施の形態３と同一であるので、同一符号を付し説明を省略する。
【０１２５】この図９における新たなブロックである２１は、回復メッセージ処理手段１４が処理した回復要求メッセージと回復応答メッセージの個数をカウントする回復メッセージ計数手段、２２は複数の副サーバ・ノード間でバッファのフラッシュ（削除）を同期して行うためのメッセージ処理を行う同期メッセージ処理手段である。
【０１２６】ここでバッファとは通常メッセージ格納手段１５と回復要求メッセージ格納手段１６の総称であり、以後も同様の意味で使用する。
【０１２７】また、ここではこれまでのメッセージの型に加えて、新たに以下の３種のメッセージの型を使用する。
１）複数のサーバ・ノード間でほぼ同時刻にバッファのほぼ同じ範囲のフラッシュを行い、各サーバ・ノードのバッファの内容を均一化するためサーバ・ノードから送信される同期メッセージであることを示す“ＲＥＰＡＩＲ＿ＳＹＮＣ”；
２）（１）の同期メッセージに対し、他ノードから送信されるバッファのフラッシュを拒否する応答である同期応答メッセージであることを示す“ＲＥＰＡＩＲ＿ＳＹＮＣ＿ＲＥＰＬＹ“；
３）ノード順位を１繰り上げる（小さくする）ことを指示する順位更新メッセージであることを示す”ＯＲＤＥＲ＿ＵＰＧＲＡＤＥ“である。
【０１２８】次に、本実施形態の動作について説明する。本実施形態では、既に説明した実施の形態２と同様に図５に示すフローチャートに従って初期化が行われ、この初期化によってノード順位１の主サーバ・ノードとノード順位２の副サーバ・ノード及びノード順位３以上のクライアント・ノードが決定される。
【０１２９】本実施形態の説明においては、信頼度基準値Ｎｒｅｌｙ＝２、すなわち主サーバ・ノードと１つの副サーバ・ノードを使用する場合について説明する。
【０１３０】まず、副サーバ・ノードの動作を図１０に示すフローチャートに沿って説明する。副サーバ・ノードが起動すると（Ｓ５０１）、カウンタＰｓｅｒｖｅｒＤｏｗｎの値を０にリセットし、次いでメッセージ受信手段７によりメッセージを受信し（Ｓ５０２）、メッセージ型判定手段９によりそのメッセージの型を判定する（Ｓ５０３）。
【０１３１】以下、受信したメッセージの型により分類し、その後の動作について説明する。
【０１３２】１）受信メッセージの型がＲＥＰＡＩＲ＿ＳＹＮＣの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＳＹＮＣの場合には、回復メッセージ処理手段１４が後述のロギングバッファ同調処理を行う（Ｓ５０４）。
【０１３３】２）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹである場合には、回復メッセージ計数手段２１がカウンタＰｓｅｒｖｅｒＤｏｗｎの値を０にリセットし（Ｓ５０５）、この回復応答メッセージのもととなった回復要求メッセージに対して自ノードが応答するために作成していた回復応答メッセージを、回復応答メッセージ送信キュー１３から削除する（Ｓ５０６）。次いで、この回復応答メッセージが自ノードの要求したものかを判断し（Ｓ５０７）、もしそうであれば、回復メッセージ処理手段１４は回復応答メッセージから通常メッセージ部分を取り出し（Ｓ５０８）、通常メッセージを通常メッセージ受信キュー５へ投入する（Ｓ５０９）。Ｓ５０７がＮＯ、すなわち自ノードが要求したものでない場合にはこのメッセージを廃棄する。
【０１３４】３）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、実施の形態４で述べた方法でバックオフタイマー設定手段２０がバックオフタイマーを設定し（Ｓ５１０）、回復メッセージ計数手段２１がカウンタＰｓｅｒｖｅｒＤｏｗｎの値を１だけ増加させる（Ｓ５１１）。もしここでカウンタＰｓｅｒｖｅｒＤｏｗｎの値が、装置であらかじめ指定された値ＭａｘＦａｉｌの値よりも大きければ（Ｓ５１２）、マルチキャストドメイン管理手段１７は同期メッセージ処理手段２２に対して同期メッセージの作成を指示し、作成された同期メッセージはメッセージ送信手段６によって、マルチキャストドメインに送信される（Ｓ５１３）。
【０１３５】この後、回復メッセージ処理手段１４が、ロギングバッファ同調処理を行う。ロギングバッファ同調処理が完了するとマルチキャストドメイン管理手段１７は、各ノードの順位更新メッセージ（ＯＲＤＥＲ＿ＵＰＧＲＡＤＥメッセージ）をメッセージ送信手段６を用いてマルチキャストドメイン内に送信する（Ｓ５１５）。そして自ノードのノード順位番号を１だけ減少させ主サーバ・ノードに昇格する（Ｓ５１６）。もし、Ｓ５１２がＮＯの場合、すなわちカウンタＰｓｅｒｖｅｒＤｏｗｎの値がＭａｘＦａｉｌの値未満ならばこのメッセージは廃棄される。
【０１３６】４）受信メッセージの型がＮＯＲＭＡＬの場合受信メッセージの型がＮＯＲＭＡＬの場合は、これまでの実施の形態２と同様に、メッセージのシーケンス番号に飛びがあるかどうかを調べることにより、メッセージ喪失があるかどうかを調べる（Ｓ５１７）。メッセージ喪失の有無にかかわらず、通常メッセージ処理手段３は、このメッセージを後の回復処理のために通常メッセージ格納手段１５を用いて保持する（Ｓ５２０）。その後、受信メッセージは、アプリケーション・プログラム1に引き渡される（Ｓ５２１）。
【０１３７】次に、図１０中のロギングバッファ同調処理の動作を図１１のフローチャートにしたがって説明する。ロギングバッファ同調処理が開始されると（Ｓ５３１）、回復要求メッセージ送信キュー内にまだ回復応答メッセージを受信していない回復要求メッセージが存在するかどうか調べる（Ｓ５３２）。もし存在する場合は、フラッシュ処理を拒否する同期応答メッセージを送信する（Ｓ５３３）。もし存在しない場合は、サーバ・ノードであれば同期メッセージに指定された範囲のバッファをフラッシュし（Ｓ５３５）、クライアント・ノードでは何も動作しない。
【０１３８】さらに、この実施の形態５におけるクライアント・ノードの動作を図１２のフローチャートに沿って説明する。クライアント・ノードが動作状態に入ると（Ｓ５４１）、メッセージ受信手段７がネットワーク８からメッセージを受信し（Ｓ５４２）、メッセージ型判定手段がメッセージの型を判定する（Ｓ５４３）。
【０１３９】以下、受信したメッセージの型により分類し、その後の動作について説明する。
【０１４０】１）受信メッセージの型がＯＲＤＥＲ＿ＵＰＧＲＡＤＥの場合受信したメッセージの型がＯＲＤＥＲ＿ＵＰＧＲＡＤＥの場合には、このメッセージはマルチキャストドメイン管理手段１７へ送られ、マルチキャストドメイン管理手段１７はノード順位決定手段１８にノード順位番号の更新を要求する。ノード順位が、系の信頼度基準値Ｎｒｅｌｙよりも小さい場合には（Ｓ５４５）、このノードがサーバ・ノードに昇格する（Ｓ５４６）。
【０１４１】２）受信メッセージの型がＲＥＰＡＩＲ＿ＳＹＮＣの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＳＹＮＣの場合には、前述のロギングバッファ同調処理が行われる（Ｓ５４７）。
【０１４２】３）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、メッセージは回復応答メッセージ受信キュー１１に投入され、回復メッセージ処理手段１４が自ノードの要求への応答かを判断し（Ｓ５４８）、もしそうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ５４９）、通常メッセージ部分を通常メッセージ受信キュー５へ投入する（Ｓ５５０）。
【０１４３】４）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、メッセージ型判定手段９は何もせずにこのメッセージを廃棄する。
【０１４４】５）受信メッセージの型がＮＯＲＭＡＬの場合受信メッセージの型がＮＯＲＭＡＬの場合は、前記の実施の形態２と同様に、メッセージのシーケンス番号に飛びがあるかどうかを調べることにより、メッセージ喪失があるかどうかを調べる（Ｓ５１７）。メッセージ喪失の有無にかかわらず、通常メッセージ処理手段３は、このメッセージを後の回復処理のために通常メッセージ格納手段１５を用いて保持する（Ｓ５２０）。その後、受信メッセージは、アプリケーション・プログラム1に引き渡される（Ｓ５２１）。
【０１４５】以上のように、この発明の実施形態５では、主サーバ・ノードが回復処理を実行できなかった場合、すなわち主サーバ・ノードがダウンした場合に、副サーバ・ノードがこれを自動的に検知して主サーバ・ノードに昇格するとともに他のノードのノード順位更新を行い、不足する副サーバ・ノードを補うので、システム全体としての堅牢性を高めることができる。
【０１４６】実施の形態６．次に、実施の形態６について、図１３〜図１６に基づいて説明する。
【０１４７】前記の実施の形態５では、バッファのフラッシュについて、その時間間隔については触れていないが、この実施の形態６では、バッファ内に存在するメッセージをフラッシュする時間間隔を主サーバ・ノードの使用するアプリケーション・プログラムから設定し、その値に基づいてバッファをフラッシュする方法について説明する。
【０１４８】図について説明すると、図１３はこの実施の形態６におけるマルチキャスト通信システムを構成するノードのブロック図、図１４はこの実施の形態６のノードの初期化動作のフローチャート、図１５はこの実施の形態６におけるバッファのフラッシュに関するフローチャート、図１６はこの実施の形態６におけるバッファフラッシュのタイミング情報の送信に関するフローチャートである。
【０１４９】まず、この実施の形態６の構成について、図１３のブロック図に基づいて説明するが、この図１３において通信装置１Ａからマルチキャストドメイン管理手段１７までは前記の実施の形態１〜実施の形態５と同一であるので、同一符号を付し説明を省略する。なおバッファとは通常メッセージ格納手段１５と回復要求メッセージ格納手段１６の総称であることは前述の通りである。
【０１５０】図１３における新たなブロックである２３は、回復メッセージ処理手段１４が通常メッセージ格納手段１５、回復要求メッセージ格納手段１６をフラッシュする際の時間間隔を設定するバッファフラッシュ間隔設定手段である。
【０１５１】次に本実施形態の動作について説明する。最初に、初期化動作を図１４に示すフローチャートに沿って説明する。まず、装置が動作し始めると（Ｓ６０１）、バッファフラッシュ間隔設定手段２３はアプリケーション・プログラム１Ｂから設定された時間間隔Ｔｔｍｐをマルチキャストドメイン管理手段１７に通知する（Ｓ６０２）。
【０１５２】次いで、マルチキャストドメイン管理手段１７は、カウンタｊｏｉｎ＿ｃｏｕｎｔの値を０に初期化し（Ｓ６０３）、以後前記の実施の形態１と同じ手順でマルチキャストドメイン管理手段１７が自ノードをサーバ・ノードまたはクライアント・ノードとして設定する。
【０１５３】以下、まずサーバ・ノードが実施の形態１と同様に１つの場合について説明する。
【０１５４】マルチキャストドメイン管理手段１７は自ノードをサーバ・ノードと設定した（６０７）場合、バッファフラッシュ間隔設定手段２３に対してＴｔｍｐを確認した旨通知する。バッファフラッシュ間隔設定手段２３はマルチキャストドメイン管理手段１７からこのＴｔｍｐ確認の通知を受け取ると、ＴｒｅｌｅｖａｎｃｙにＴｔｍｐの値を設定し（Ｓ６１２）、次いでバッファフラッシュ間隔設定手段２３は回復メッセージ処理手段１４に対してＴｒｅｌｅｖａｎｃｙを通知する。
【０１５５】一方、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹを受信して自ノードをクライアント・ノードとして設定した場合には、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージに含まれる値をＴｒｅｌｅｖａｎｃｙに設定する。
【０１５６】このようにして、この装置は初期化され、サーバ・ノードの場合にはアプリケーション・プログラムから指定された値ＴｔｍｐがＴｒｅｌｅｖａｎｃｙに設定される。
【０１５７】次に、初期化後のサーバ・ノードの動作について図１５のフローチャートに沿って説明する。まず、サーバ・ノードは回復メッセージ処理手段１４において、Ｔｒｅｌｅｖａｎｃｙを用いてタイマーをセットする（Ｓ６２２）。回復メッセージ処理手段１４は、このタイマーが切れた時に、通常メッセージ格納手段１５と回復要求メッセージ格納手段１６に格納されているメッセージのうち、現在の時刻ＴｎｏｗからＴｒｅｌｅｖａｎｃｙを引いた時刻以前に格納したメッセージを消去する（Ｓ６２３）。以下、Ｓ６２２以降を繰り返す。
【０１５８】以上のように、この実施の形態６では、サーバ・ノードにおけるメッセージ格納バッファのフラッシュを、サーバ・ノードが使用するアプリケーション・プログラム１Ｂから指定された時間間隔に基づいて行うことにより、バッファのフラッシュを行わない場合と比べてバッファサイズを小さく保つことができるので、サーバ・ノードにおける処理性能をあげることができる。
【０１５９】以上では、サーバ・ノードが前記実施の形態１と同様に１つの場合について説明したが、実施の形態２に示されるような、サーバ・ノードが主サーバ・ノードおよび副サーバ・ノードから構成される場合にも適用可能であり、図１６のフローチャートのように、主サーバ・ノードは他のノードからのＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＱＵＥＳＴメッセージに対して、Ｔｒｅｌｅｖａｎｃｙをデータとして含むＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを返答するようにする。副サーバ・ノードではこの主サーバ・ノードから通達されたＴｒｅｌｅｖａｎｃｙに基づき主サーバ・ノードと同様にバッファのフラッシュを行う。
【０１６０】さらに、前記実施の形態５のように、主サーバ・ノードが変更される可能性がある場合には、クライアント・ノードを含め、各ノードは主サーバ・ノードあるいは副サーバ・ノードへと変更されることに備えてＴｒｅｌｅｖａｎｃｙを保存する。
【０１６１】実施の形態７．次に実施の形態７について、図１７〜図２１に基づいて説明する。
【０１６２】前記の実施の形態６では、サーバ・ノードにおけるメッセージ格納バッファフラッシュの時間間隔を、初期化の際に主サーバ・ノードの使用するアプリケーション・プログラムから指定された値に設定する例を示したが、この時間間隔を過去の回復要求メッセージの履歴に基づいて設定するようにした実施の形態を説明する。
【０１６３】まず、図について説明すると、図１７はこの実施の形態７におけるマルチキャスト通信システムを構成する各ノードのブロック図、図１８はこの実施の形態７におけるノードの初期化動作のフローチャート、図１９はこの実施の形態７におけるサーバ・ノードの受信動作のフローチャート、図２０はこの実施の形態７におけるバッファのフラッシュの時間間隔の変更に関するフローチャート、図２１はこの実施の形態７におけるバッファのフラッシュに関するフローチャートである。
【０１６４】次に、この実施の形態７の構成について図１７のブロック図に基づいて説明するが、この図１７において、通信装置１Ａからマルチキャストドメイン管理手段１７までは前記の実施の形態１〜実施の形態６と同一であるので、同一符号を付し説明を省略する。また前記の実施の形態６と同様に２３は回復メッセージ処理手段１４が通常メッセージ格納手段１５、回復要求メッセージ格納手段１６をフラッシュする際の時間間隔を設定するバッファフラッシュ間隔設定手段である。
【０１６５】この図１７における新たなブロックである２４は、バッファフラッシュ間隔設定手段２３内に設けられたフラッシュ間隔計算手段である。
【０１６６】次に、この実施の形態７の動作について説明する。最初に初期化動作を図１８に示すフローチャートに沿って説明する。まず装置が動作し始めると（Ｓ７０１）、バッファフラッシュ間隔設定手段２３はアプリケーションから設定された時間間隔ＴｔｍｐおよびΔＴｔｍｐをマルチキャストドメイン管理手段１７に通知する（Ｓ７０２）。
【０１６７】次いで、マルチキャストドメイン管理手段１７は、カウンタｊｏｉｎ＿ｃｏｕｎｔの値を０に初期化し（Ｓ７０３）、以後実施の形態１と同じ手順でマルチキャストドメイン管理手段１７が自ノードをサーバ・ノードまたはクライアント・ノードとして設定する。
【０１６８】マルチキャストドメイン管理手段１７は自ノードをサーバ・ノードとみなした場合、バッファフラッシュ間隔設定手段２３に対して保持していたＴｔｍｐおよびΔＴｔｍｐを通知する。バッファフラッシュ間隔設定手段２３はマルチキャストドメイン管理手段１７からＴｔｍｐおよびΔＴｔｍｐを受け取ると、ＴｒｅｌｅｖａｎｃｙにＴｔｍｐの値を設定し、ΔＴにΔＴｔｍｐの値を設定する（Ｓ７１２）。バッファフラッシュ間隔設定手段２３は回復メッセージ処理手段１４に対してＴｒｅｌｅｖａｎｃｙおよびΔＴを通知する。
【０１６９】一方、ＤＯＭＡＩＮ＿ＪＯＩＮ＿ＲＥＰＬＹメッセージを受信して自ノードをクライアント・ノードとして設定した場合には、マルチキャストドメイン管理手段１７はＪＯＩＮ＿ＲＥＰＬＹメッセージに含まれる値をＴｒｅｌｅｖａｎｃｙに設定する。このようにして、この装置は初期化され、サーバ・ノードの場合にはアプリケーション・プログラムから指定された値ＴｔｍｐがＴｒｅｌｅｖａｎｃｙに、ΔＴｔｍｐがΔＴが設定される。
【０１７０】次に、初期化後のサーバ・ノードのメッセージ受信動作について図１９のフローチャートに沿って説明する。まず、サーバ・ノードが動作状態に入ると（Ｓ７２１）、メッセージ受信手段７がネットワーク８からメッセージを受信し（Ｓ７２２）、メッセージ型判定手段がメッセージの型を判定する（Ｓ７２３）。
【０１７１】以下受信したメッセージの型により分類し、その後の動作について説明する。
【０１７２】１）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、メッセージは回復応答メッセージ受信キュー１１に投入され、回復メッセージ処理手段１４が自ノードの要求への応答かを判断し（Ｓ７２４）、もしそうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ７２５）、通常メッセージ部分を通常メッセージ受信キュー５へ投入する（Ｓ７２６）。
【０１７３】２）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、メッセージは回復要求メッセージ受信キュー１０に投入され、回復メッセージ処理手段１４によって受信メッセージのタイムスタンプＴｒがバッファフラッシュ間隔設定手段に通知され（Ｓ７２７）た後、回復の対象となるメッセージを通常メッセージ格納手段１５から検索して取り出す（Ｓ７２８）。取り出した通常メッセージの持つタイムスタンプＴｎがバッファフラッシュ間隔設定手段に通知され（Ｓ７２９）、さらにこの取り出したメッセージを格納する回復応答メッセージを生成し（Ｓ７３０）、回復応答メッセージを回復応答メッセージ送信キュー１３へ投入する（Ｓ８３１）。
【０１７４】３）受信メッセージの型がＮＯＲＭＡＬの場合受信したメッセージの型がＮＯＲＭＡＬの場合は、前記の実施の形態１と同様に、メッセージのシーケンス番号に飛びがあるかどうかを調べることにより、メッセージ喪失があるかどうかを調べる（Ｓ５１７）。メッセージ喪失の有無にかかわらず、通常メッセージ処理手段３は、このメッセージを後の回復処理のために通常メッセージ格納手段１５を用いて保持する（Ｓ５２０）。その後、受信メッセージは、アプリケーション・プログラム1に引き渡される（Ｓ５２１）。
【０１７５】一方、バッファフラッシュ間隔設定手段２３においては、図２０のフローチャートに示すように、新たなＴｒ、Ｔｎの組が通知された時（Ｓ７４２）にフラッシュ間隔計算手段２４を用いて（Ｔｒ−Ｔｎ＋ΔＴ）の値を求め、この値を新たなＴｒｅｌｅｖａｎｃｙとして（Ｓ７４３）回復メッセージ処理手段１４に通知する（Ｓ７４４）。
【０１７６】また、この時、回復メッセージ処理手段１４においては、図２１のフローチャートに示すように、バッファフラッシュ間隔設定手段２３から新しいＴｒｅｌｅｖａｎｃｙを通知されると（Ｓ７５２）、Ｔｒｅｌｅｖａｎｃｙを新しい値に更新し（Ｓ７５３）する。Ｓ７５２がＮＯ、すなわち新しいＴｒｅｌｅｖａｎｃｙを通知されていない場合には、Ｔｒｅｌｅｖａｎｃｙの値は更新しない。次に、回復メッセージ処理手段１４は、Ｔｒｅｌｅｖａｎｃｙを用いてタイマーをセットする（Ｓ７５４）。回復メッセージ処理手段１４は、このタイマーが切れるまで待機し（Ｓ７５５）、通常メッセージ格納手段１５と回復要求メッセージ格納手段１６に格納されているメッセージのうち、現在の時刻ＴｎｏｗからＴｒｅｌｅｖａｎｃｙを引いた時刻以前に格納したメッセージを消去する（Ｓ７５６）。以下、Ｓ７５２以降を繰り返す。
【０１７７】以上のように、本実施形態では、メッセージの回復要求を受け取った際に、その回復要求メッセージのタイムスタンプＴｒと、その回復要求メッセージが回復を要求している通常メッセージのタイムスタンプＴｎの差を取り、この値にアプリケーションから初期化時に指定されたΔＴを加えた値を新しいＴｒｅｌｅｖａｎｃｙとして設定することで、バッファフラッシュの時間間隔およびフラッシュする範囲を動作環境に合わせて動的に変更することが可能となり、メッセージの回復に関する信頼性の向上やサーバ・ノードにおける処理性能をあげることができる。
【０１７８】また、以上の実施の形態ではＴｒｅｌｅｖａｎｃｙを決定するのに一組のＴｒとＴｎを使用する例を示したが、複数のＴｒとＴｎの組を使用してＴｒｅｌｅｖａｎｃｙを決定することも可能である。
【０１７９】以下にその一例の手順を示すが、この手順はフラッシュ間隔計算手段２４内で実行する。
（手順１）回復要求メッセージを受信するたびにその時のＴｒとＴｎの差（Ｔｒ−Ｔｎ）を求め、この値を蓄積していく。
（手順２）この複数の（Ｔｒ−Ｔｎ）の平均値Ｍおよび標準偏差σを求める。
（手順３）このＭおよびσを使用して、Ｔｒｅｌｅｖａｎｃｙ＝Ｍ＋Ｓσとして、Ｔｒｅｌｅｖａｎｃｙを求める。このＳは回復処理の信頼性を決定する定数であり、これが大きいと必要なバッファサイズは大きくなるが回復処理の信頼性は高くなる。このＳはアプリケーション・プログラム１ＢからΔＴｔｍｐの代わりに指定すればよい。
【０１８０】このように、複数の（Ｔｒ−Ｔｎ）の平均値Ｍ、標準偏差σおよび定数ＳからＴｒｅｌｅｖａｎｃｙを決定すれば、統計的手法から回復処理の信頼性を定量的に把握しながらバッファフラッシュの時間間隔やフラッシュする範囲を決定することが可能となる。
【０１８１】また、この複数の（Ｔｒ−Ｔｎ）の数に制限を設け、一定の数を越えるものは古い順に廃棄し、最近の一定の数の（Ｔｒ−Ｔｎ）のみからＴｒｅｌｅｖａｎｃｙを決定するようにすれば、メッセージ喪失の発生状況の時間的変動にも対応可能である。この廃棄する順は、ＴｒまたはＴｎが古い順等とすればよい。
【０１８２】このように、バッファフラッシュ間隔設定手段２３内のフラッシュ間隔計算手段２４におけるＴｒｅｌｅｖａｎｃｙの計算方法を変化させることで、信頼性を重視するシステムや処理性能を重視するシステムが構築できる。
【０１８３】実施の形態８．次に、実施の形態８を図２２〜図２５に基づいて説明する。
【０１８４】前記の実施の形態７では、バッファフラッシュの時間間隔を過去の回復要求メッセージの履歴に基づいて動的に設定するようにした例を示したが、本実施形態では、サーバ・ノードにおけるバッファ内に存在するメッセージを、複数サーバ間で同期してフラッシュする際に使われる同期メッセージを必要な場合にのみ生成・送信する方法について説明する。
【０１８５】まず、図について説明すると、図２２はこの実施の形態８におけるマルチキャスト通信システムを構成する各ノードのブロック図、図２３はこの実施の形態８のノードの初期化動作のフローチャート、図２４はこの実施の形態８におけるサーバ・ノードの受信動作のフローチャート、図２５はこの実施の形態８におけるバッファのフラッシュに関するフローチャートである。
【０１８６】最初に、この実施の形態８の構成を図２２に示すブロック図を用いて説明するが、この図２２において、通信装置１Ａからマルチキャストドメイン管理手段１７までは前記の実施の形態１〜実施の形態７と同一であるので、同一符号を付し説明を省略する。また２２は前記実施の形態５で説明したように、複数のサーバ間でバッファのフラッシュを同期して行うためのメッセージ処理を行う同期メッセージ処理手段、２３は実施の形態６および実施の形態７で説明したように、回復メッセージ処理手段１４が通常メッセージ格納手段１５、回復要求メッセージ格納手段１６ををフラッシュする際の時間間隔を設定するバッファフラッシュ間隔設定手段である。
【０１８７】図２２における新たなブロックである２５は、回復メッセージ処理手段１４内に設けられた、同期メッセージを作成する同期メッセージ作成手段である。
【０１８８】ついで、この実施の形態８の動作について説明する。まず、初期化動作を図２３のフローチャートに沿って説明する。装置が動作し始めると（Ｓ８０１）、バッファフラッシュ間隔設定手段２３はアプリケーションから設定された時間間隔Ｔｔｍｐをマルチキャストドメイン管理手段１７に通知する（Ｓ８０２）。
【０１８９】以後、図２３の破線で囲んだ内部のように実施の形態２と同様の手順に従って、このノードを主サーバ・ノードまたは副サーバ・ノード、あるいはクライアント・ノードとして設定する。
【０１９０】主サーバ・ノード、あるいは副サーバ・ノードと設定されたノードでは、マルチキャストドメイン管理手段１７がバッファフラッシュ間隔設定手段２３に対してＴｔｍｐを通知する。バッファフラッシュ間隔設定手段２３はマルチキャストドメイン管理手段１７からＴｔｍｐを受け取ると、ＴｒｅｌｅｖａｎｃｙにＴｔｍｐの値を設定する（Ｓ８１２）。バッファフラッシュ間隔設定手段２３は回復メッセージ処理手段１４に対してＴｒｅｌｅｖａｎｃｙを通知する。
【０１９１】次に、回復要求メッセージカウンタＣｒとＣｒｐｒｅｖを０に初期化する。また同期メッセージ内に設定する値であり、削除するメッセージの範囲を示すＳＹＮＣ＿ＲＡＮＧＥをすべてのメッセージをあらわすＦＵＬＬＲＡＮＧＥに設定し（Ｓ８１４）、同期メッセージのタイムアウト時間をあらわすＴｓｙｎｃを標準値に設定する。
【０１９２】クライアント・ノードとして設定された場合には、ＪＯＩＮ＿ＲＥＰＬＹメッセージに含まれる値をＴｒｅｌｅｖａｎｃｙに設定する。
【０１９３】このようにしてこの装置は初期化され、Ｔｒｅｌｅｖａｎｃｙが設定されるとともに、サーバ・ノードの場合には回復要求メッセージカウンタＣｒ、Ｃｒｐｒｅｖが０に初期化される。
【０１９４】次に初期化後のサーバ・ノードにおける喪失メッセージの回復用のメッセージ格納バッファのフラッシュ動作について図２４のフローチャートに沿って説明する。サーバ・ノードが動作状態に入ると（Ｓ８２１）、メッセージ受信手段７がネットワーク８からメッセージを受信し（Ｓ８２２）、メッセージ型判定手段がメッセージの型を判定する（Ｓ８２３）。
【０１９５】以下受信したメッセージの型により分類し、その後の動作について説明する。
【０１９６】１）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＰＬＹの場合には、前記の実施の形態１と同様に自ノードの要求への応答かを判断し（Ｓ８２４）、そうであればこのメッセージから通常メッセージ部分を取り出し（Ｓ８２５）、通常メッセージ部分を通常メッセージ受信キュー５へ投入する（Ｓ８２６）。Ｓ８２４がＮＯ、すなわち自ノードの要求への応答でない場合には、このメッセージは廃棄される。
【０１９７】２）受信メッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合受信したメッセージの型がＲＥＰＡＩＲ＿ＲＥＱＵＥＳＴの場合には、メッセージは回復要求メッセージ受信キュー１０に投入され、回復要求メッセージカウンタＣｒを１増やし（Ｓ８２７）た後、回復の対象となるメッセージを通常メッセージ格納手段１５から検索して取り出す（Ｓ８２８）。この取り出したメッセージを含む回復応答メッセージを生成し（Ｓ８２９）、回復応答メッセージを回復応答メッセージ送信キュー１３へ投入する（Ｓ８３０）。
【０１９８】３）受信メッセージの型がＮＯＲＭＡＬの場合受信したメッセージの型がＮＯＲＭＡＬの場合は、前記の実施の形態１と同様に、メッセージのシーケンス番号に飛びがあるかどうかを調べることにより、メッセージ喪失があるかどうかを調べる（Ｓ８３１）。メッセージ喪失の有無にかかわらず、通常メッセージ処理手段３は、このメッセージを後の回復処理のために通常メッセージ格納手段１５を用いて保持する（Ｓ８３４）。その後、受信メッセージは、アプリケーション・プログラム1に引き渡される（Ｓ８３５）。
【０１９９】一方、サーバ・ノードにおける回復メッセージ処理手段１４においては、図２５のフローチャートに示すように、喪失メッセージの回復処理用のメッセージ格納バッファをフラッシュする。この動作について以下に説明する。
【０２００】まず、回復要求メッセージのカウンタであるＣｒと前回までの値を持つＣｒｐｒｅｖを比較する（Ｓ８４２）。
【０２０１】もし前回のフラッシュ以降回復要求メッセージが無くＣｒ＝ＣｒｐｒｅｖであればＴｒｅｌｅｖａｎｃｙを用いてタイマーをセットする（Ｓ８４３）。タイマーが切れるとバッファに存在するメッセージの内、現在の時刻Ｔｎｏｗ−Ｔｒｅｌｅｖａｎｃｙで表わされる時刻よりも古いタイムスタンプを持つメッセージをバッファから削除する（Ｓ８４５）。次に、同期メッセージ内に指定する、削除するメッセージの範囲を示すＳＹＮＣ＿ＲＡＮＧＥを全体をあらわす値であるＦＵＬＬＲＡＮＧＥに設定し（Ｓ８４６）、Ｓ８４２に戻る。
【０２０２】このように、前回のフラッシュ以降新たな回復要求メッセージが出ていなければ、各サーバ・ノードがそれぞれ自サーバ・ノードのバッファをＴｒｅｌｅｖａｎｃｙに基づいてフラッシュする。
【０２０３】次に、Ｓ８４２がＮＯの場合、すなわち前回のフラッシュ以降回復要求メッセージが送信された場合は現在設定されているＳＹＮＣ＿ＲＡＮＧＥの値を用いて同期メッセージを作成し送信する（Ｓ８４７）。次に同期メッセージのタイムアウト時間を示すＴｓｙｎｃを用いてタイマーをセットする（Ｓ８４８）。このタイマーが切れたかどうかを判定し（Ｓ８４９）、もし切れていれば、バッファからＳＹＮＣ＿ＲＡＮＧＥの値で指定されている範囲のメッセージを削除し（Ｓ８５０），ＣｒｐｒｅｖにＣｒの値を設定する（Ｓ８５１）。
【０２０４】もし、Ｓ８４９でＮＯの場合、すなわちタイマーがきれていない場合には他ノードからフラッシュ停止を要求する同期応答メッセージを受信しているかどうかを判定し（Ｓ８５２）、受信していなければＳ８４９に戻る。
【０２０５】また、Ｓ８５２でＹＥＳの場合、すなわち同期応答メッセージを受信している場合には回復要求メッセージを受信しているかどうかを判定し（Ｓ８５３）、受信していればＣｒを１増加して（Ｓ８５４）、さらにＳＹＮＣ＿ＲＡＮＧＥを現在の値のよりも小さく再設定し（Ｓ８５５）、Ｔｓｙｎｃを用いたタイマーが切れるまで待機し（Ｓ８５６），Ｔｓｙｎｃの値を増加した（Ｓ８５８）後、Ｓ８４７に戻る。もしＳ８５３でＮＯの場合にはＳ８４９へと戻る。以上の操作を繰り返す。
【０２０６】以上のように、この発明の実施形態８では、複数サーバ・ノード間での同期メッセージに基づいたバッファのフラッシュを、回復要求メッセージが送信された場合にのみ行い、さらに回復要求メッセージが送信された場合にフラッシュするバッファの範囲を小さくするとともに、同期メッセージが送信されてから各サーバ・ノードがバッファのフラッシュを行うまでの時間を長くすることにより、回復要求に応じるサーバ・ノードの信頼性を向上することが可能となる。
【０２０７】
【発明の効果】以上のようにこの発明では、マルチキャスト通信システムにおいて、各ノードに優先順位番号を付け、メッセージ喪失が検出された場合、最優先順位番号から所定の優先順位番号までの優先順位番号を持つ各ノードが、該喪失メッセージの回復を要求する該回復要求メッセージに対して応答するか否かの判定を行うようにしたので、その他のノードは回復処理に要する負荷を軽減できるという効果がある。
【０２０８】また、メッセージ喪失が検出された場合、回復要求メッセージに対して応答すると判定したノードは第１の回復応答メッセージを作成して所定時間ｔ１経過後送信するように設定し、上記所定時間ｔ１経過以前に他ノードがこの回復要求メッセージに対する第２の回復応答メッセージを送信した場合には上記第１の回復応答メッセージの送信を中止し、上記所定時間ｔ１経過までに他ノードが第２の回復応答メッセージを送信しなかった場合は上記第１の回復応答メッセージを送信するようにしたので、回復応答メッセージの重複によるネットワークの輻輳が防げるという効果がある。
【０２０９】また、最優先順位番号を持つノードのみが応答すると判定するようにしたので、その他のノードは回復処理に要する負荷を軽減できるという効果がある。
【０２１０】また、上記所定の優先順位番号は、最優先順位番号を有するノードの初期化動作時に決定される固有の値に設定されるようにしたので、設定を容易に行なえるという効果がある。
【０２１１】また、上記所定の優先順位番号は、最優先順位番号を有するノード上に搭載されたソフトウエアによって任意に設定可能であるようにしたので、システムの動作状況を反映した柔軟性が高い運用ができるという効果がある。
【０２１２】また、メッセージ喪失を検出したノードが、該喪失メッセージの回復を要求する回復要求メッセージに判別番号を付けて送信し、該回復要求メッセージを受信した上記最優先順位番号から上記所定の優先順位番号までの優先順位番号を持つ各ノードが、該判別番号と自ノードの優先順位番号を用いて自ノードが応答するか否かの判定を行うようにしたので、回復処理を担当するノード間で負荷分散が可能となり、各ノードの負荷を軽減できるという効果がある。
【０２１３】また、回復処理中のノードが回復処理不能に陥った場合、その回復処理不能に陥ったノードの優先順位番号を越える優先順位番号を持つ各ノードの優先順位番号を繰り上げるようにしたので、回復処理を行うノードの数を維持し、システムの信頼性を確保できるという効果がある。
【０２１４】また、上記所定時間ｔ１は、回復応答メッセージの送信元ノードの優先順位番号によって決定されるようにしたので、回復応答メッセージの重複によるネットワークの輻輳が防止できるという効果がある。
【０２１５】また、最優先順位番号から所定の優先順位番号までの優先順位番号を持つノードがバッファ内に保持しているメッセージを、最優先順位番号を持つノードが削除範囲を設定して削除するようにしたのでバッファサイズを小さくできるという効果がある。
【０２１６】また、最優先順位番号から所定の優先順位番号までの優先順位番号を持つノードがバッファ内に保持しているメッセージを、過去いずれかのノードがメッセージを送信した時刻と、いずれかのノードが上記メッセージの喪失を起こし、上記喪失したメッセージの回復を要求して回復要求メッセージを送信した場合の送信時刻との時間間隔に基づいて削除範囲を決定して削除するようにしたので、バッファ削除範囲にシステムの履歴が反映され回復処理の信頼性が高くなるという効果がある。
【０２１７】また、回復要求メッセージの送信頻度の増大に応じてバッファの削除範囲を縮小するようにしたので、バッファ削除範囲にシステムの動作状況を反映できて回復処理の信頼性が高くなるという効果がある。
【０２１８】また、最優先順位番号から前記所定の優先順位番号までの優先順位番号を持つノードが回復処理用にバッファ内にそれぞれ保持している過去のメッセージを、最優先順位番号を有するノードがいずれかのノードから回復要求メッセージを受信した場合にのみ、略同一時刻に削除するようにしたので、各ノードにおけるバッファ削除タイミングにシステムの動作状況が反映され回復処理の信頼性が高くなるという効果がある。
【０２１９】また、ネットワークに接続された複数のノード間相互の通信システムであるマルチキャスト通信システムにおいて、上記各ノードに優先順位番号を付け、いずれかのノードがメッセージの喪失を検出して第１の回復要求メッセージを送信する際、該第１の回復要求メッセージを作成してから送信するまでの所定時間を各ノードの優先順位番号によって決定し、この所定時間内に他ノードが同一の喪失メッセージに対する回復要求メッセージを送信し、これに対する回復応答メッセージを受信した場合には上記第１の回復要求メッセージの送信を中止するようにしたので、回復応答メッセージの重複によるネットワークの輻輳が防止できるという効果がある。
【０２２０】また、マルチキャスト通信システム参加時に参加確認メッセージを受信しなかったノードが最優先順位番号を自ノードに設定し、以後参加するノードには、この最優先順位番号を有するノードが参加確認メッセージを送信して優先順位番号を通知するようにしたので、優先順位付けが容易で、参加ノードの増加にも対応しやすいという効果がある。
【出願人】 【識別番号】０００００６０１３
【氏名又は名称】三菱電機株式会社
【出願日】 平成９年（１９９７）８月２７日
【代理人】 【弁理士】
【氏名又は名称】宮田 金雄 （外２名）
【公開番号】 特開平１１−６５９７１
【公開日】 平成１１年（１９９９）３月９日
【出願番号】 特願平９−２３０７１７