JP2001168861A - マルチキャストシステム、マルチキャストグループ管理装置、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 マルチキャストのグループを容易、正確かつ
迅速に管理し、ネットワークの伝送効率の低下を防ぎ、
しかも簡単なオペレーションによりマルチキャスト送信
を行うこと。 【解決手段】 複数の受信ノード（受信ノードａ〜ｃ）
がグループ化されたグループに関するデータベースを管
理し、グループに更新が生じた場合または送信ノード
（送信側クライアント１０）からの通知要求があった場
合、送信ノードへ更新後のデータベースを通知する管理
サーバ３０を備え、送信ノードは管理サーバ３０から通
知されるデータベースに対応するグループへパケットを
送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチキャスト方
式により、一つの送信ノードから複数の受信ノードへパ
ケットを配信するマルチキャストシステム、マルチキャ
ストグループ管理装置、マルチキャストグループ管理プ
ログラムを記録したコンピュータ読み取り可能な記録媒
体に関するものである。

【０００２】従来より、インターネットを代表とする分
散パケット交換網では、パケット配信形式を宛先指定方
法により幾つかに分類されている。既存のインターネッ
トで使用されているＩＰｖ４や次世代インターネットの
標準であるＩＰｖ６では、つぎの（１）項から（３）項
までの都合三種類のパケット配信方式が用いられる。

【０００３】（１）宛先が、唯一のアドレスに対応する
ユニキャスト方式 （２）宛先が、複数のアドレスからなるグループに対応
し、それぞれのアドレスへパケットをコピーして配信す
るマルチキャスト方式 （３）宛先が複数のアドレスからなるグループに対応
し、グループ内のいずれか一つのアドレスへパケットを
配信するエニーキャスト方式

【０００４】本発明は、（２）項のマルチキャスト方式
に関するものである。このマルチキャスト方式は、同一
のパケットを複数の受信ノードに同報できるため、マル
チメディアデータの放送、他地点音声動画会議やネット
ワーク対戦型のゲーム等への応用が試みられている。

【０００５】

【従来の技術】図１６は、従来のマルチキャストシステ
ムの構成を示す図である。この図には、送信側クライア
ント１（送信ノード）と受信側クライアント２ａ〜２ｃ
（受信ノードａ〜ｃ）とが、ルータ３₁ 〜３₄ を含むネ
ットワーク（たとえば、インターネット）を介して接続
された構成が図示されている。送信側クライアント１
は、コンピュータであり、ネットワークを介して受信側
クライアント２ａ〜２ｃのうちあらかじめ設定されたグ
ループに対してパケットを送信する。ビデオカメラＶ
は、他地点音声動画会議時に人物Ｐや背景等を撮像し、
撮像データを送信側クライアント１へ出力する。

【０００６】マルチキャストグループ管理テーブル５
は、受信ノードａ〜ｃを複数組み合わせたグループを管
理するテーブルでである。このマルチキャストグループ
管理テーブル５において、「グループ」は、グループ名
称であり、「メンバ」は、当該グループを構成する受信
ノードである。

【０００７】具体的には、グループＸは、受信ノードａ
（受信側クライアント２ａ）、受信ノードｂ（受信側ク
ライアント２ｂ）および受信ノードｃ（受信側クライア
ント２ｃ）から構成されている。グループＹは、受信ノ
ードａ（受信側クライアント２ａ）および受信ノードｂ
（受信側クライアント２ｂ）から構成されている。ま
た、グループＺは、受信ノードｂ（受信側クライアント
２ｂ）および受信ノードｃ（受信側クライアント２ｃ）
から構成されている。これらのグループＸ〜Ｚは、パケ
ットをマルチキャスト方式により受信ノードへ配信する
際に、当該パケットの宛先情報とされる。

【０００８】ルータ３₁ 〜３₄ のそれぞれは、送信側ク
ライアント１から送信されたパケットの宛先情報（グル
ープ）を確認し、グループに応じて中継方向を動的に変
化させることにより、パケットを所望のグループ内の受
信ノードへ向けてルーティングする。これらのルータ３
₁ 〜３₄ には、ルーティングテーブル４₁ 〜４₄ が予め
保持されている。ルーティングテーブル４₁ 〜４₄ は、
グループＸ〜Ｚにそれぞれ対応する中継方向に関するデ
ータからなり、ルーティング時にルータ３₁ 〜３₄ によ
り参照される。

【０００９】上記構成において、たとえば、マルチキャ
ストグループ管理テーブル５内のグループＸへパケット
を送信する場合、送信側クライアント１のオペレータ
は、図示しないキーボードより、グループＸを構成する
受信ノードａ〜ｃのそれぞれに付与されているネットワ
ーク上のアドレスを順次入力する。これにより、送信側
クライアント１は、宛先情報としてグループＸが付加さ
れたパケットをネットワークへ送出する。

【００１０】そして、パケットがルータ３₁ に到着する
と、ルータ３₁ は、パケットの宛先情報（この場合、グ
ループＸ）をキーとして、マルチキャストルーティング
テーブル４₁ を参照することにより、パケットの中継方
向を確認する。この場合の中継方向は、ルータ３₂ 方向
（同図右矢印）および受信ノードｃ方向（同図下矢印）
である。つぎに、ルータ３₁ は、パケットのコピーを受
信ノードｃおよびルータ３₂ へ中継する。これにより、
受信ノードｃ（受信側クライアント２ｃ）では、パケッ
トが受信される。

【００１１】一方、パケットがルータ３₂ に到着する
と、ルータ３₂ は、パケットの宛先情報（この場合、グ
ループＸ）をキーとして、マルチキャストルーティング
テーブル４₂ を参照することにより、パケットの中継方
向を確認する。この場合の中継方向は、ルータ３₃ 方向
（同図右矢印）およびルータ３₄ 方向（同図右下矢印）
である。つぎに、ルータ３₂ は、パケットのコピーをル
ータ３₃ およびルータ３ ₄ へ中継する。

【００１２】そして、パケットがルータ３₃ に到着する
と、ルータ３₃ は、パケットの宛先情報（この場合、グ
ループＸ）をキーとして、マルチキャストルーティング
テーブル４₃ を参照することにより、パケットの中継方
向を確認する。この場合の中継方向は、受信ノードａ方
向（同図右矢印）である。つぎに、ルータ３₃ は、パケ
ットを受信ノードａへ中継する。これにより、受信ノー
ドａ（受信側クライアント２ａ）では、パケットが受信
される。

【００１３】一方、パケットがルータ３₄ に到着する
と、ルータ３₄ は、パケットの宛先情報（この場合、グ
ループＸ）をキーとして、マルチキャストルーティング
テーブル４₄ を参照することにより、パケットの中継方
向を確認する。この場合の中継方向は、受信ノードｂ方
向（同図右下矢印）である。つぎに、ルータ３₄ は、パ
ケットを受信ノードｂへ中継する。これにより、受信ノ
ードｂ（受信側クライアント２ｂ）では、パケットが受
信される。

【００１４】

【発明が解決しようとする課題】ところで、前述したよ
うに、従来のマルチキャストシステムにおいては、図１
６に示したマルチキャストルーティングテーブル４₁ 〜
４₄ でのグループの追加、削除、変更や受信ノードの追
加、削除、変更（以下、更新という）を行う場合、送信
側クライアント１の送信ノード管理者（または受信ノー
ドの受信ノード管理者）からルータ３₁ 〜３₄ のルータ
管理者に対して電話や電子メールにより、上記更新を依
頼した後、ルータ管理者により追加、削除、変更が行わ
れる。

【００１５】しかしながら、従来のマルチキャストシス
テムにおいては、人手を介してグループ（受信ノード）
の更新を行っているため、グループや受信ノードの数が
増えるにしたがって、グループ管理に要する時間、作業
コストが増大してしまうという問題があった。また、人
手によるグループ管理では、グループ（受信ノード）の
更新に関するミスや漏れが発生するとともに、作業量の
増大に伴って更新作業が大幅に遅れる場合があるという
問題もあった。

【００１６】また、従来のマルチキャストシステムで
は、受信ノードａ〜ｃがパケットを受信できる状態にあ
るか否かにかかわらず、マルチキャストルーティングテ
ーブル４₁ 〜４₄ に基づいて、機械的にパケットを中継
している。したがって、ネットワーク障害等によりパケ
ットを受信できない状態にある受信ノードが存在した場
合にも、当該受信ノードへ無駄なパケットが中継される
ため、その分だけネットワークのトラフィック量が増
え、ネットワークの伝送効率が悪くなるという問題があ
った。

【００１７】さらに、従来のマルチキャストシステムで
は、マルチキャストルーティングテーブル４₁ 〜４₄ が
更新された場合、更新後のグループ（受信ノード）に関
する情報が送信側クライアント１にリアルタイムで正し
く伝達されない可能性が高い。これは、電話や電子メー
ル等の手段を用いて人手を介在させて上記変更後の情報
が送信側ノード管理者へ伝達されるからである。したが
って、このような場合には、送信側クライアント１が更
新前のグループへ無駄なパケットを送信することになる
ため、その分だけネットワークのトラフィック量が増
え、ネットワークの伝送効率が悪くなるという問題があ
った。

【００１８】また、送信側クライアント１から、あるグ
ループへパケットをマルチキャスト送信する場合には、
当該グループを構成する受信ノードのそれぞれのアドレ
スを一々入力しなければならないため、マルチキャスト
送信のためのオペレーションが複雑であるという問題が
あった。

【００１９】本発明は、上記に鑑みてなされたもので、
マルチキャストのグループを容易、正確かつ迅速に管理
することができるとともに、ネットワークの伝送効率の
低下を防ぐことができ、しかも簡単なオペレーションに
よりマルチキャスト送信を行うことができるマルチキャ
ストシステム、マルチキャストグループ管理装置、マル
チキャストグループ管理プログラムを記録したコンピュ
ータ読み取り可能な記録媒体を提供することを目的とす
る。

【００２０】

【課題を解決するための手段】上記目的を達成するため
に、請求項１にかかる発明は、マルチキャスト方式によ
りパケットをネットワークを介して複数の受信ノード
（後述する一実施の形態の受信側クライアント２０ａ〜
２０ｃに相当）へ送信する送信ノード（後述する一実施
の形態の送信側クライアント１０に相当）を備えるマル
チキャストシステムにおいて、前記複数の受信ノードが
グループ化されたグループに関するグループ情報を管理
し、前記グループに更新が生じた場合または前記送信ノ
ードからの通知要求があった場合、前記送信ノードへ更
新後のグループ情報を前記ネットワークを介して通知す
るマルチキャストグループ管理装置（後述する一実施の
形態の管理サーバ３０に相当）を備え、前記送信ノード
は、前記マルチキャストグループ管理装置から通知され
るグループ情報に対応するグループへ前記パケットを送
信することを特徴とする。

【００２１】この発明によれば、マルチキャストグルー
プ管理装置により、グループ情報が管理されており、た
とえば、グループが動的に変化した場合には、グループ
情報が更新される。この場合、マルチキャストグループ
管理装置は、変更後のグループ情報すなわち最新のグル
ープ情報を送信ノードへ通知する。これにより、送信ノ
ードは、最新のグループ情報に対応するグループへパケ
ットを送信する。また、送信ノードから通知要求がある
と、マルチキャストグループ管理装置は、当該送信ノー
ドに対してグループ情報を通知する。

【００２２】このように、請求項１にかかる発明によれ
ば、従来の人手によらずマルチキャストグループ管理装
置によりグループ情報を管理し、グループが更新された
場合や送信ノードから通知要求された場合に更新後のグ
ループ情報を送信ノードに通知するようにしたので、マ
ルチキャストのグループを容易、正確かつ迅速に管理す
ることができる。

【００２３】また、請求項２にかかる発明は、請求項１
に記載のマルチキャストシステムにおいて、前記マルチ
キャストグループ管理装置は、前記複数の受信ノードの
それぞれがパケットを受信できる状態にあるか否かを監
視し、パケットを受信することができない受信ノードが
ある場合、当該受信ノードを前記グループから除外する
ことを特徴とする。

【００２４】この発明によれば、マルチキャストグルー
プ管理装置により、受信ノードの受信状態を監視し、パ
ケットを受信できない受信ノードがある場合、グループ
から当該受信ノードが除外されるため、不必要に当該受
信ノードに対してパケットが送信されないことから、ネ
ットワークの伝送効率の低下を防ぐことができる。

【００２５】また、請求項３にかかる発明は、請求項１
または２に記載のマルチキャストシステムにおいて、前
記送信ノードは、複数存在しており、前記マルチキャス
トグループ管理装置は、複数の送信ノードからの要求に
より前記グループ情報を通知すべき送信ノードに関する
通知リストを備え、該通知リスト内の送信ノードに対し
て変更後のグループ情報を前記ネットワークを介して通
知することを特徴とする。

【００２６】この発明によれば、通知リスト内の複数の
送信ノードに対して変更後のグループ情報を通知するよ
うにしたので、複数の送信ノードとグループとの間で多
対多でのマルチキャスト通信を容易に実現することがで
きる。

【００２７】また、請求項４にかかる発明は、請求項１
〜３のいずれか一つに記載のマルチキャストシステムに
おいて、少なくとも、前記送信ノードは、通知要求を出
す際にＵＲＬにより、通知を受けるグループ情報を指定
することを特徴とする。

【００２８】この発明によれば、インターネット等で周
知のＵＲＬという極めて簡単な指定方法によりグループ
情報を指定していることから、簡単なオペレーションに
よりマルチキャスト送信を行うことができる。

【００２９】また、請求項５にかかる発明は、マルチキ
ャスト方式によりパケットをネットワークを介して複数
の受信ノードへグループ情報に基づいて送信する送信ノ
ードを備えるマルチキャストシステムに適用されるマル
チキャストグループ管理装置であって、前記複数の受信
ノードがグループ化されたグループに関する前記グルー
プ情報を管理し、前記グループに更新が生じた場合また
は前記送信ノードからの通知要求があった場合、前記送
信ノードへ更新後のグループ情報を前記ネットワークを
介して通知するマルチキャストグループ管理手段を備え
ることを特徴とする。

【００３０】この発明によれば、マルチキャストグルー
プ管理手段により、グループ情報が管理されており、た
とえば、グループが動的に変化した場合には、グループ
情報が更新される。この場合、マルチキャストグループ
管理手段は、変更後のグループ情報すなわち最新のグル
ープ情報を送信ノードへ通知する。これにより、送信ノ
ードは、最新のグループ情報に対応するグループへパケ
ットを送信する。また、送信ノードから通知要求がある
と、マルチキャストグループ管理手段は、当該送信ノー
ドに対してグループ情報を通知する。

【００３１】このように、請求項５にかかる発明によれ
ば、従来の人手によらずマルチキャストグループ管理手
段によりグループ情報を管理し、グループが更新された
場合や送信ノードから通知要求された場合に更新後のグ
ループ情報を送信ノードに通知するようにしたので、マ
ルチキャストのグループを容易、正確かつ迅速に管理す
ることができる。

【００３２】また、請求項６にかかる発明は、マルチキ
ャスト方式によりパケットをネットワークを介して複数
の受信ノードへグループ情報に基づいて送信する送信ノ
ードを備えるマルチキャストシステムに適用されるマル
チキャストグループ管理プログラムを記録したコンピュ
ータ読み取り可能な記録媒体であって、前記複数の受信
ノードがグループ化されたグループに関する前記グルー
プ情報を管理させ、前記グループに更新が生じた場合ま
たは前記送信ノードからの通知要求があった場合、前記
送信ノードへ更新後のグループ情報を前記ネットワーク
を介して通知させるマルチキャストグループ管理工程
（後述する一実施の形態のステップＳＨ１〜ＳＨ１８に
相当）をコンピュータに実行させるためのマルチキャス
トグループ管理プログラムを記録したコンピュータ読み
取り可能な記録媒体である。

【００３３】この発明によれば、マルチキャストグルー
プ管理工程で、グループ情報が管理されており、たとえ
ば、グループが動的に変化した場合には、グループ情報
が更新される。この場合、マルチキャストグループ管理
工程では、変更後のグループ情報すなわち最新のグルー
プ情報が送信ノードへ通知される。これにより、送信ノ
ードは、最新のグループ情報に対応するグループへパケ
ットを送信する。また、送信ノードから通知要求がある
と、マルチキャストグループ管理工程では、当該送信ノ
ードに対してグループ情報が通知される。

【００３４】このように、請求項６にかかる発明によれ
ば、従来の人手によらずマルチキャストグループ管理工
程でグループ情報を管理し、グループが更新された場合
や送信ノードから通知要求された場合に更新後のグルー
プ情報を送信ノードに通知するようにしたので、マルチ
キャストのグループを容易、正確かつ迅速に管理するこ
とができる。

【００３５】

【発明の実施の形態】以下、図面を参照して本発明にか
かるマルチキャストシステム、マルチキャストグループ
管理装置、マルチキャストグループ管理プログラムを記
録したコンピュータ読み取り可能な記録媒体の一実施の
形態について詳細に説明する。

【００３６】図１は、本発明にかかる一実施の形態の構
成を示す図である。この図には、送信側クライアント１
０（送信ノード）と受信側クライアント２０ａ〜２０ｃ
（受信ノードａ〜ｃ）とが、ルータ４０₁ 〜４０₄ を含
むネットワーク（たとえば、インターネット）を介して
接続された構成が図示されている。送信側クライアント
１０は、コンピュータであり、ネットワークを介して受
信側クライアント２０ａ〜２０ｃのうちあらかじめ設定
されたグループに対してパケットを送信する。なお、同
図には、送信側クライアント１０のみ図示されている
が、他の送信側クライアントもネットワークに接続され
ている。ビデオカメラＶは、他地点音声動画会議時に人
物Ｐや背景等を撮像し、撮像データを送信側クライアン
ト１０へ出力する。

【００３７】受信側クライアント２０ａ〜２０ｃ（受信
ノードａ〜ｃ）は、複数のグループにグルーピングされ
ており、送信側クライアント１０からマルチキャスト送
信されたパケットをそれぞれ受信する。これらの受信側
クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）のそ
れぞれには、ネットワーク上のアドレスが付与されてい
る。また、受信側クライアント２０ａ〜２０ｃのそれぞ
れは、パケットを受信することができるか否かというネ
ットワーク状態を監視する監視機能、監視結果を管理サ
ーバ３０へ通知するネットワーク状態通知機能を備えて
いる。

【００３８】なお、同図には、受信側クライアントとし
て受信側クライアント２０ａ〜２０ｃが図示されている
が、これら以外にも図示しない受信側クライアントが多
数ネットワークに接続されている。

【００３９】管理サーバ３０は、ネットワークに接続さ
れており、マルチキャストグループ管理テーブル５０を
管理する。このマルチキャストグループ管理テーブル５
０は、たとえば、受信ノードａ〜ｃを複数組み合わせた
グループを管理するテーブルである。このマルチキャス
トグループ管理テーブル５０において、「グループ」
は、グループ名称であり、「メンバ」は、当該グループ
を構成する受信ノードである。

【００４０】同図に示した例では、グループＸは、受信
ノードａ（受信側クライアント２０ａ）、受信ノードｂ
（受信側クライアント２０ｂ）および受信ノードｃ（受
信側クライアント２０ｃ）から構成されている。グルー
プＹは、受信ノードａ（受信側クライアント２０ａ）お
よび受信ノードｂ（受信側クライアント２０ｂ）から構
成されている。また、グループＺは、受信ノードｂ（受
信側クライアント２０ｂ）および受信ノードｃ（受信側
クライアント２０ｃ）から構成されている。これらのグ
ループＸ〜Ｚは、パケットをマルチキャスト方式により
受信ノードへ配信する際に、当該パケットの宛先情報と
される。

【００４１】ここで、実際には、マルチキャストグルー
プ管理テーブル５０は、図２（ａ）に示したようなデー
タベースから構成されている。同図に示したデータベー
スは、マルチキャストグループ管理テーブル５０のグル
ープＸに対応しており、「受信ノード名」、「受信ノー
ドのアドレス」、「ネットワーク状態」および「タイム
アウト時刻」というデータからなる。「受信ノード名」
は、グループＸを構成する受信ノードの名称であり、ｎ
ｏｄｅＡ〜Ｃである。これらのｎｏｄｅＡ〜Ｃは、図１
に示した受信ノードａ〜ｃに対応している。

【００４２】「受信ノードのアドレス」は、それぞれの
受信ノードに付与されたネットワーク上のアドレスであ
る。「ネットワーク状態」は、受信ノードがパケットを
受信できる状態にあるか否かを示すフラグである。すな
わち、「ネットワーク状態」に「オフライン」フラグが
たっている場合には、当該受信ノード（この場合、図１
に示した受信ノードｂ）がパケットを受信できない状態
にあることを意味している。一方、「ネットワーク状
態」にいずれのフラグもたっていない場合には、当該受
信ノードがパケットを受信できる状態にあることを意味
している。「タイムアウト時刻」は、当該受信ノードが
パケットを受信できない状態にあることを判断するため
の時刻である。

【００４３】ルータ４０₁ 〜４０₄ のそれぞれは、送信
側クライアント１０から送信されたパケットの宛先情報
（グループ）を確認し、グループに応じて中継方向を動
的に変化させることにより、パケットを所望のグループ
内の受信ノードへ向けてルーティングする。これらのル
ータ４０₁ 〜４０₄ は、マルチキャストグループ管理テ
ーブル５０を参照することにより、パケットのルーティ
ングを行う。

【００４４】つぎに、図６〜図８に示したシーケンス図
を参照して一実施の形態の動作について説明する。図６
は一実施の形態の初期化処理を説明するシーケンス図で
あり、図７は一実施の形態の終了処理を説明するシーケ
ンス図であり、図８は一実施の形態のネットワーク監視
動作を説明するシーケンス図である。図６に示したステ
ップＳＡ１では、管理サーバの初期化処理が実行され
る。

【００４５】すなわち、ステップＳＡ１では、図１に示
した管理サーバ３０は、マルチキャストグループを設定
するための空のデータベース、後述する通知リストを作
成する。ここで作成されるデータベースは、図２（ａ）
に示したフォーマットのものである。また、作成された
空のデータベースには、いずれのデータも存在していな
い。

【００４６】つぎに、ステップＳＡ２〜ステップＳＡ８
までは、送信側クライアントの初期化処理が実行され
る。すなわち、ステップＳＡ２では、送信側クライアン
ト１０は、マルチキャスト方式によるパケットの配信を
実現するためのアプリケーションを初期化する。ここ
で、送信側クライアント１０のオペレータは、アクセス
先の管理サーバ３０、マルチキャストグループ管理テー
ブル５０におけるグループ等を指定するためのＵＲＬ
（Uniform Resource Locator）を入力する。

【００４７】ここで、図５（ａ）〜（ｅ）を参照してＵ
ＲＬ指定の例について説明する。これらの図に示したＵ
ＲＬでは、「プロトコル」、「ユーザ名」、「パスワー
ド」、「ホスト名」、「ポート番号」および「グループ
名」を指定することができる。上記「ホスト名」は、管
理サーバ３０のネットワーク上の名称であり、「グルー
プ名」は、マルチキャストグループ管理テーブル５０
（図１参照）におけるグループの名称である。すなわ
ち、ＵＲＬにより、少なくとも管理サーバ３０およびグ
ループを指定することが可能である。

【００４８】図６に戻り、ステップＳＡ３では、送信側
クライアント１０は、入力されたＵＲＬを解析し、「プ
ロトコル」、「パスワード」、「ユーザ名」、「ホスト
名」、「ポート番号」および「グループ名」を特定す
る。この場合、少なくとも「ホスト名」（管理サーバ３
０の名称）および「グループ名」が特定されたものとす
る。ステップＳＡ４では、送信側クライアント１０は、
ネットワークを介して管理サーバ３０にアクセスし、図
４（ａ）に示した通知リストへ自身のネットワーク上の
アドレス（たとえば、「２０２．３３．９６．４２」）
を追加するように要求する。

【００４９】ここで、同図に示した通知リストは、図１
に示したマルチキャストグループ管理テーブル５０を構
成する、たとえば、図３（ａ）に示したデータベース
（グループ情報）を通知すべき送信側クライアントのア
ドレスを表すリストであり、管理サーバ３０に保持され
ている。ステップＳＡ５では、管理サーバ３０は、図４
（ａ）に示した通知リストに、管理サーバ３０のアドレ
ス「２０２．３３．９６．４２」（図４（ｂ）参照）を
追加する。

【００５０】ステップＳＡ６では、送信側クライアント
１０は、管理サーバ３０に対して、ＵＲＬ指定された
「グループ名」に対応するグループ情報、すなわちデー
タベース（図２（ａ）参照）の送信を要求する。ここで
は、図２に示したデータベースには、いずれのデータも
存在しない。

【００５１】これにより、ステップＳＡ７では、管理サ
ーバ３０は、図２（ａ）に示したフォーマットの空のデ
ータベース（グループ情報）を送信側クライアント１０
へ送信する。ステップＳＡ８では、送信側クライアント
１０は、受信した空のデータベースから、図２（ｂ）に
示したようなフォーマットの宛先リストを生成する。こ
の場合、宛先リストには、いずれのデータも存在しな
い。宛先リストは、マルチキャスト送信により送信側ク
ライアント１０から送信すべきパケットの宛先（受信ノ
ードのアドレス）のリストである。

【００５２】つぎに、ステップＳＡ９〜ステップＳＡ１
４までは、受信側クライアントの初期化処理が実行され
る。すなわち、ステップＳＡ９では、受信側クライアン
ト（受信側クライアント２０ａ〜２０ｃ、その他の受信
側クライアントのうちいずれか一つまたは二つ以上）
は、マルチキャスト方式によるパケットの受信を実現す
るためのアプリケーションを初期化する。ここで、受信
側クライアントのオペレータは、送信側クライアント１
０のオペレータと同様にして、アクセス先の管理サーバ
３０、マルチキャストグループ管理テーブル５０におけ
るグループ等を指定するためのＵＲＬ（図５（ａ）〜
（ｅ）参照）を入力する。

【００５３】ステップＳＡ１０では、受信側クライアン
トは、入力されたＵＲＬを解析し、「プロトコル」、
「パスワード」、「ユーザ名」、「ホスト名」、「ポー
ト番号」および「グループ名」を特定する。この場合、
少なくとも「ホスト名」（管理サーバ３０の名称）およ
び「グループ名」が特定されたものとする。ステップＳ
Ａ１２では、受信側クライアントは、ネットワークを介
して管理サーバ３０にアクセスし、ステップＳＡ１で作
成されたデータベースに自身のネットワーク上のアドレ
スを登録するように要求する。すなわち、受信側クライ
アントは、マルチキャストグループ管理テーブル５０に
おけるグループに自身のアドレスを登録するための要求
を出す。

【００５４】ステップＳＡ１１では、管理サーバ３０
は、ステップＳＡ１で作成されたデータベースに当該受
信側クライアントの「ノード名」、「受信ノードのアド
レス」、「ネットワーク状態」および「タイムアウト時
刻」を登録する。たとえば、図２（ｃ）に示したよう
に、ｎｏｄｅＤの受信側クライアントからグループへの
登録要求があった場合、データベースには、ｎｏｄｅＤ
に関する「ノード名」、「受信ノードのアドレス」、
「ネットワーク状態」、「タイムアウト時刻」が登録さ
れる。

【００５５】ステップＳＡ１３では、管理サーバ３０
は、ステップＳＡ５の通知リスト（図４（ｂ）参照）に
基づいて、通知リストに存在するアドレス（送信側クラ
イアント１０）へ、ステップＳＡ１１で登録されたデー
タベースを新しいグループ情報として自動通知する。こ
の場合、図２（ａ）に示したデータベース（グループ情
報）が少なくとも送信側クライアント１０に通知された
ものとする。なお、データベースは、送信側クライアン
ト１０以外の送信側クライアントであって宛先リストに
アドレスが記載されているものにも送信される。

【００５６】これにより、ステップＳＡ１４では、送信
側クライアント１０は、図２（ａ）に示したデータベー
スから、図２（ｂ）に示した宛先リストを作成する。こ
の宛先リストは、上記データベースで「ネットワーク状
態」の欄に「オフライン」フラグがたっていない受信ノ
ードのアドレスからなる。すなわち、宛先リストのアド
レスは、パケットを正常に受信可能な受信ノードに対応
している。図２（ｂ）に示した例では、宛先リストに
は、図２（ａ）に示したｎｏｄｅＡ（受信ノードａ：図
１参照）のアドレス、およびｎｏｄｅＣ（受信ノード
ｃ：図１参照）のアドレスが含まれている。なお、図２
（ｃ）に示したデータベースからは、図２（ｄ）に示し
た宛先リストが生成され、図２（ｅ）に示したデータベ
ースからは、図２（ｆ）に示した宛先リストが生成され
る。

【００５７】ステップＳＡ１５では、送信側クライアン
ト１０は、図２（ｂ）に示した宛先リストに基づいて、
図１に示した受信ノードａおよび受信ノードｃに対して
パケットを送信する。また、ステップＳＡ１３で新しい
グループ情報が自動通知された他の送信側クライアント
（図示略）も、受信ノードａおよびｃに対してパケット
を送信する。この場合には、多対多の通信が実現され
る。

【００５８】つぎに、図７を参照して終了処理について
説明する。同図において、マルチキャスト送信を中止す
る場合、送信側クライアント１０は、ステップＳＢ１〜
ステップＳＢ４までの終了処理を実行する。すなわち、
ステップＳＢ２では、送信側クライアント１０は、図４
（ｂ）に示した通知リストからの自身のアドレス（「２
０２．３３．９６．４２」）の削除を管理サーバ３０へ
要求する。

【００５９】これにより、ステップＳＢ１では、管理サ
ーバ３０は、上記アドレスを通知リストから削除する。
これにより、通知リストは、図４（ａ）に示したものと
なる。なお、他の送信側クライアントからアドレス（た
とえば、「２０２．２３９．１６２．３４」）の削除要
求があった場合、管理サーバ３０は、図４（ｂ）に示し
た通知リストから上記アドレスを削除する。この場合、
通知リストは、図４（ｃ）に示したものとなる。

【００６０】ステップＳＢ３では、管理サーバ３０は、
送信側クライアント１０へのグループ情報（データベー
ス）の自動送信を停止する。ステップＳＢ４では、送信
側クライアント１０は、アプリケーションの終了処理を
実行する。これにより、ステップＳＢ５では、マルチキ
ャスト送信が中止される。

【００６１】また、受信側クライアントがパケットの受
信を終了する場合、ステップＳＢ６では、受信側クライ
アントは、データベース（たとえば、図２（ａ）参照）
に登録されている自身に関するデータを削除するように
管理サーバ３０へ要求する。これにより、ステップＳＢ
７では、管理サーバ３０は、データベースから当該受信
側クライアントに関するデータを削除する。

【００６２】すなわち、当該受信側クライアントは、マ
ルチキャストグループ管理テーブル５０のグループから
除外されたのである。ステップＳＢ８では、受信側クラ
イアントは、アプリケーションの終了処理を実行する。
また、ステップＳＢ９では、管理サーバ３０は、データ
ベースおよび通知リストを削除することにより、終了処
理を実行する。

【００６３】つぎに、図８を参照してネットワーク監視
動作について説明する。図１に示したネットワークが正
常である場合、ステップＳＣ１〜ステップＳＣ６までの
処理が実行される。すなわち、ステップＳＣ１では、受
信側クライアントは、管理サーバ３０に対してタイムア
ウト延長要求を出す。ここでタイムアウト延長要求と
は、図２（ａ）に示したデータベースにおける「タイム
アウト時刻」の延長を要求することをいう。また、受信
側クライアントは、一定時間毎（たとえば、３０秒毎）
にタイムアウト延長要求を管理サーバ３０に対して出
す。

【００６４】ステップＳＣ２では、管理サーバ３０は、
タイムアウト延長要求を受けると、データベースのタイ
ムアウト時刻をたとえば１分後の時刻に再設定する。ス
テップＳＣ３では、送信側クライアント１０は、マルチ
キャスト通信を継続する。そして、ステップＳＣ１でタ
イムアウト要求を出した時刻から３０秒経過すると、ス
テップＳＣ４では、当該受信側クライアントは、管理サ
ーバ３０に対して再びタイムアウト延長要求を出す。ス
テップＳＣ５では、管理サーバ３０は、タイムアウト延
長要求を受けると、データベースのタイムアウト時刻を
たとえば１分後の時刻に再設定する。ステップＳＣ６で
は、送信側クライアント１０は、マルチキャスト通信を
継続する。以後、上述した動作が繰り返される。

【００６５】ここでネットワーク故障が発生すると、ス
テップＳＣ７では、上記受信側クライアントからのタイ
ムアウト延長要求に失敗する。これは、データベース
（図２（ａ）参照）の「タイムアウト時刻」を経過して
も、受信側クライアントからのタイムアウト延長要求が
ない場合である。ステップＳＣ８では、管理サーバ３０
は、たとえば、図２（ｅ）に示したように、ｎｏｄｅＡ
およびＤからのタイムアウト延長要求が無かった場合、
ｎｏｄｅＡおよびＤに対応する「ネットワーク状態」の
欄にオフラインのフラグを設定する。すなわち、同図に
示したデータベースからは、ｎｏｄｅＣのみがパケット
の受信が可能な状態にあることがわかり、その他のｎｏ
ｄｅＡ、ｎｏｄｅＢおよびｎｏｄｅＤがパケットの受信
が出来ない状態（オフライン）にあることがわかる。

【００６６】ステップＳＣ９では、管理サーバ３０は、
たとえば、図２（ｅ）に示したデータベース（グループ
情報）を、宛先リストに基づいて、たとえば、送信側ク
ライアント１０へ自動通知する。これにより、ステップ
ＳＣ１０では、送信側クライアント１０は、図２（ｆ）
に示した宛先リストを生成する。ステップＳＣ１１で
は、送信側クライアント１０は、タイムアウト延長要求
に失敗した当該受信側クライアントに対するマルチキャ
スト送信を停止する。

【００６７】そして、ネットワークが回復すると、ステ
ップＳＣ１２では、ステップＳＣ７でタイムアウト延長
要求に失敗した受信側クライアントは、管理サーバ３０
に対するタイムアウト延長要求を再開する。これによ
り、ステップＳＣ１３では、管理サーバ３０は、データ
ベース（図２（ｅ）参照）から、当該受信側クライアン
トに対応するオフラインのフラグを消去する。

【００６８】ステップＳＣ１４では、管理サーバ３０
は、オフラインのフラグが消去されたデータベース（グ
ループ情報）を、宛先リストに基づいて、たとえば、送
信側クライアント１０へ自動通知する。これにより、ス
テップＳＣ１５では、送信側クライアント１０は、宛先
リストを生成する。この宛先リストには、オフラインの
フラグが消去された当該受信側クライアントのアドレス
が含まれている。これにより、ステップＳＣ１６では、
送信側クライアント１０は、タイムアウト延長要求を再
開した当該受信側クライアントに対するマルチキャスト
送信を再開する。

【００６９】なお、前述した図６では、送信側クライア
ントの初期化処理が受信側クライアントの初期化処理よ
り先に実行される場合について説明したが、これとは逆
に受信側クライアントの初期化処理が送信側クライアン
トの初期化処理より先に実行された場合には、図９に示
したシーケンスで各処理が実行される。図９において、
ステップＳＤ１は、ステップＳＡ１（図６参照）に対応
しており、ステップＳＤ２〜ステップＳＤ５は、ステッ
プＳＡ９〜ステップＳＡ１２に対応している。また、図
９に示したステップＳＤ６〜ステップＳＤ１３は、図６
に示したステップＳＡ２〜ステップＳＡ８およびステッ
プＳＡ１５に対応している。

【００７０】同様にして、前述した図７では送信側クラ
イアントの終了処理が受信側クライアントの終了処理よ
り先に実行される場合について説明したが、これとは逆
に受信側クライアントの終了処理が送信側クライアント
の終了処理より先に実行された場合には、図１０に示し
たシーケンスで各処理が実行される。図１０において、
ステップＳＥ１およびステップＳＥ２は、図７に示した
ステップＳＢ６およびステップＳＢ７に対応している。

【００７１】ステップＳＥ３では管理サーバ３０から送
信側クライアント１０へ新しいグループ情報が自動通知
され、ステップＳＥ４では宛先リストが生成される。こ
れにより、ステップＳＥ６では、マルチキャスト送信が
停止される。また、図１０に示したステップＳＥ８〜ス
テップＳＥ１２は、図７に示したステップＳＢ１〜ステ
ップＳＢ５およびステップＳＢ９に対応している。

【００７２】図１１は、二つの受信側クライアント
（１）および（２）がある場合の初期化処理を説明する
シーケンス図である。図１１に示したステップＳＦ１〜
ステップＳＦ５は、図９に示したステップＳＤ１〜ステ
ップＳＤ５に対応している。ただし、図１１に示したス
テップＳＦ１〜ステップＳＦ５までの処理は、受信側ク
ライアント（１）の初期化処理である。また、図１１に
示したステップＳＦ６〜ステップＳＦ１３は、図９に示
したステップＳＤ６〜ステップＳＤ１３に対応してい
る。だだし、ステップＳＦ１３の処理は、受信側クライ
アント（１）に対してマルチキャスト送信を開始する処
理である。

【００７３】さらに、図１１に示したステップＳＦ１４
〜ステップＳＦ２０は、受信側クライアント（２）の初
期化処理である。ステップＳＦ１４〜ステップＳＦ１７
までの処理は、ステップＳＦ２〜ステップＳＦ５の処理
と同様である。ステップＳＦ１８では管理サーバ３０か
ら受信側クライアント（２）を含む新しいグループ情報
が送信側クライアント１０に自動通知される。ステップ
ＳＦ１９では、送信側クライアント１０は、宛先リスト
を生成する。ステップＳＦ２０では、送信側クライアン
ト１０は、受信側クライアント（１）および（２）への
マルチキャスト送信を開始する。

【００７４】図１２は、二つの受信側クライアント
（１）および（２）がある場合の終了処理を説明するシ
ーケンス図である。図１２に示したステップＳＧ１〜ス
テップＳＧ６は、図１０に示したステップＳＥ１〜ステ
ップＳＥ６に対応している。ただし、図１１に示したス
テップＳＧ２〜ステップＳＧ６までの処理は、受信側ク
ライアント（１）の終了処理である。また、ステップＳ
Ｇ６では、受信側クライアント（１）に対するマルチキ
ャスト通信が停止され、受信側クライアント（２）に対
するマルチキャスト通信が継続される。

【００７５】また、図１２に示したステップＳＧ７〜ス
テップＳＧ１１は、図１０に示したステップＳＥ７〜ス
テップＳＥ１１に対応している。さらに、図１２に示し
たステップＳＧ１２〜ステップＳＧ１４は、図１０に示
したステップＳＥ１、ステップＳＥ２およびステップＳ
Ｅ５に対応している。ただし、ステップＳＧ１２〜ステ
ップＳＧ１４までの処理は、受信側クライアント（２）
の終了処理である。図１２に示したステップＳＧ１５
は、図１０に示したステップＳＥ１２に対応している。

【００７６】つぎに、図１３〜図１５に示したフローチ
ャートを参照して管理サーバ３０、送信側クライアント
１０および受信側クライアントの動作について説明す
る。これらの動作は、前述した図６〜図１２までのシー
ケンスに対応する動作である。図１３に示したステップ
ＳＨ１では、管理サーバ３０は、空のデータベースおよ
び通知リストを作成する（ステップＳＡ１：図６参
照）。ステップＳＨ２では、管理サーバ３０は、送信側
クライアント１０または受信側クライアントからリクエ
ストが到着しているか否かを判断する。

【００７７】この場合、ステップＳＨ２の判断結果が
「Ｎｏ」であるものとすると、ステップＳＨ３では、管
理サーバ３０は、タイムアウトした受信ノードをデータ
ベースから検索する。ステップＳＨ４では、管理サーバ
３０は、タイムアウトした受信ノードがあったか否かを
判断し、この判断結果が「Ｎｏ」である場合、ステップ
ＳＨ２の処理を実行する。一方、ステップＳＨ４の判断
結果が「Ｙｅｓ」である場合、ステップＳＨ５では、管
理サーバ３０は、データベースにオフラインのフラグを
設定する（ステップＳＣ８：図８参照）。

【００７８】ステップＳＨ９では、管理サーバ３０は、
通知リストに登録されている送信ノード（送信側クライ
アント１０）にデータベースの内容を通知する（ステッ
プＳＣ９：図８参照）。ステップＳＨ１７では、管理サ
ーバ３０は、処理を継続するか否かを判断し、この判断
結果が「Ｙｅｓ」である場合、ステップＳＨ２の処理を
実行する。

【００７９】ステップＳＨ２では、管理サーバ３０は、
リクエストが到着しているか否かを判断する。この場
合、判断結果が「Ｙｅｓ」であるものとする。ステップ
ＳＨ６では、管理サーバ３０は、リクエストの内容を判
断する。ここで、リクエストの内容が送信側クライアン
ト１０からのグループ情報の問い合わせ（ステップＳＡ
６：図６参照）である場合、ステップＳＨ７では、管理
サーバ３０は、データベース（グループ情報）を送信側
クライアント１０へ送信する（ステップＳＡ７：図６参
照）。

【００８０】また、リクエストの内容が受信側クライア
ントからのグループ登録解除（ステップＳＥ１：図１０
参照）である場合、ステップＳＨ８では、管理サーバ３
０は、データベースから受信ノードに関する情報を削除
する（ステップＳＥ２：図１０参照）。ステップＳＨ９
では、管理サーバ３０は、通知リストに登録されている
送信ノードにデータベースの内容を通知する（ステップ
ＳＥ３：図１０参照）。

【００８１】また、リクエストの内容が受信側クライア
ントからのグループ登録である場合（ステップＳＡ１
２：図６参照）、ステップＳＨ１０では、管理サーバ３
０は、データベースに受信ノード（ステップＳＡ１１：
図６参照）を追加する。ステップＳＨ１１では、タイム
アウト時刻の設定を行う。ステップＳＨ９では、管理サ
ーバ３０は、通知リストに登録されている送信ノードに
データベースの内容を通知する（ステップＳＡ１３：図
６参照）。

【００８２】また、リクエストの内容が受信側クライア
ントからのタイムアウト延長（ステップＳＣ１：図８参
照）である場合、ステップＳＨ１２では、管理サーバ３
０は、タイムアウト時刻を再設定する（ステップＳＣ
２：図８参照）。ステップＳＨ１３では、管理サーバ３
０は、データベース（図２（ａ）参照）にオフラインの
フラグがあるか否かを判断する。この判断結果が「Ｙｅ
ｓ」である場合、ステップＳＨ１４では、管理サーバ３
０は、上記オフラインのフラグを削除する（ステップＳ
Ｃ１３：図８参照）。ステップＳＨ９では、管理サーバ
３０は、通知リストに登録されている送信ノードにデー
タベースの内容を通知する（ステップＳＣ１４：図８参
照）。

【００８３】また、リクエストの内容が通知リストの登
録の解除である場合（ステップＳＢ２：図７参照）、ス
テップＳＨ１５では、管理サーバ３０は、通知リストか
ら送信ノードのアドレスを削除する（ステップＳＢ１：
図７参照）。また、リクエストの内容が送信ノードから
の通知リストの登録である場合（ステップＳＡ４：図６
参照）である場合、ステップＳＨ１６では、管理サーバ
３０は、通知リストに送信ノードのアドレスを追加する
（ステップＳＡ５：図６参照）。ステップＳＨ１７の判
断結果が「Ｎｏ」である場合、ステップＳＨ１８では、
管理サーバ３０は、データベースと通知リストを削除す
る（ステップＳＢ９：図７参照）。

【００８４】つぎに、図１４を参照して送信側クライア
ント１０の動作について説明する。図１４に示したステ
ップＳＩ１では、送信側クライアント１０は、マルチキ
ャスト通信用のアプリケーションを初期化する（ステッ
プＳＤ６：図９参照）。ステップＳＩ２では、送信側ク
ライアント１０は、入力されたＵＲＬを解析する（ステ
ップＳＤ７：図９参照）。ステップＳＩ３では、送信側
クライアント１０は、管理サーバ３０に対して、通知リ
ストへのアドレスの追加を要求する（ステップＳＤ８：
図９参照）。

【００８５】ステップＳＩ４では、送信側クライアント
１０は、グループ情報（データベース）の送信要求を管
理サーバ３０へ出した後、グループ情報（データベー
ス）を取得する（ステップＳＤ１１：図９参照）。ステ
ップＳＩ５では、送信側クライアント１０は、グループ
情報からオフラインの受信ノードを取り除き、宛先リス
トを作成する（ステップＳＤ１２：図９参照）。ステッ
プＳＩ６では、送信側クライアント１０は、宛先リスト
にしたがってマルチキャストデータグラム（パケット）
の送信を開始する（ステップＳＤ１３：図９参照）。

【００８６】ステップＳＩ７では、送信側クライアント
１０は、処理を継続するか否かを判断する。この判断結
果が「Ｙｅｓ」である場合、ステップＳＩ８では、送信
側クライアント１０は、新しいグループ情報（データベ
ース）が管理サーバ３０から届いているか否かを判断す
る。この判断結果が「Ｙｅｓ」である場合、送信側クラ
イアント１０は、ステップＳＩ５の処理を実行する。一
方、ステップＳＩ８の判断結果が「Ｎｏ」である場合、
送信側クライアント１０は、ステップＳＩ６の処理を実
行する。

【００８７】そして、ステップＳＩ７の判断結果が「Ｎ
ｏ」になると、ステップＳＩ９では、送信側クライアン
ト１０は、管理サーバ３０に対して通知リストからの削
除を要求する（ステップＳＥ７：図１０参照）。ステッ
プＳＩ１０では、送信側クライアント１０は、アプリケ
ーションを終了する（ステップＳＥ１０：図１０参
照）。

【００８８】つぎに、図１５を参照して受信側クライア
ント（受信側クライアント２０ａ〜２０ｃ）の動作につ
いて説明する。図１５に示したステップＳＪ１では、受
信側クライアントは、マルチキャスト受信用のアプリケ
ーションを初期化する（ステップＳＡ９：図６参照）。
ステップＳＪ２では、受信側クライアントは、入力され
たＵＲＬを解析する（ステップＳＡ１０：図６参照）。
ステップＳＪ３では、受信側クライアントは、管理サー
バ３０に対して、グループへの登録を要求する（ステッ
プＳＡ１２：図６参照）。

【００８９】ステップＳＪ４では、受信側クライアント
は、送信側クライアント１０からのマルチキャストデー
タグラム（パケット）を受信する。ステップＳＪ５で
は、受信側クライアントは、前回のタイムアウト延長要
求時から３０秒経過したか否かを判断する。この判断結
果が「Ｎｏ」である場合、ステップＳＪ７では、受信側
クライアントは、処理を継続するか否かを判断する。こ
の判断結果が「Ｙｅｓ」である場合、受信側クライアン
トは、ステップＳＪ４の処理を実行する。

【００９０】そして、ステップＳＪ５の判断結果が「Ｙ
ｅｓ」になると、ステップＳＪ６では、受信側クライア
ントは、管理サーバ３０にタイムアウト延長を要求する
（ステップＳＣ１：図８参照）。また、ステップＳＪ７
の判断結果が「Ｎｏ」である場合、ステップＳＪ８で
は、受信側クライアントは、管理サーバ３０に対してグ
ループからの登録を解除することを要求する（ステップ
ＳＢ６：図７参照）。ステップＳＪ９では、受信側クラ
イアントは、アプリケーションを終了する（ステップＳ
Ｂ８：図７参照）。

【００９１】以上説明したように、一実施の形態によれ
ば、従来の人手によらず管理サーバ３０によりデータベ
ース（グループ情報）を管理し、グループが更新された
場合や送信ノードから通知要求された場合に更新後のグ
ループ情報を送信ノードに通知するようにしたので、マ
ルチキャストのグループを容易、正確かつ迅速に管理す
ることができる。

【００９２】また、一実施の形態によれば、管理サーバ
３０により、受信ノードａ〜ｃの受信状態（ネットワー
ク状態）を監視し、パケットを受信できない受信ノード
がある場合、グループから当該受信ノードが除外される
ため、不必要に当該受信ノードに対してパケットが送信
されないことから、ネットワークの伝送効率の低下を防
ぐことができる。

【００９３】また、一実施の形態によれば、通知リスト
内の複数の送信ノードに対して変更後のグループ情報を
通知するようにしたので、複数の送信ノードとグループ
との間で多対多でのマルチキャスト通信を容易に実現す
ることができる。

【００９４】また、一実施の形態によれば、インターネ
ット等で周知のＵＲＬという極めて簡単な指定方法によ
りグループ情報等を指定していることから、簡単なオペ
レーションによりマルチキャスト送信を行うことができ
る。

【００９５】以上本発明にかかる一実施の形態について
図面を参照して詳述してきたが、具体的な構成例はこの
一実施の形態に限られるものではなく、本発明の要旨を
逸脱しない範囲の設計変更等があっても本発明に含まれ
る。たとえば、前述した一実施の形態においては、管理
サーバ３０の機能を実現するためのマルチキャストグル
ープ管理プログラムをコンピュータ読み取り可能な記録
媒体に記録して、この記録媒体に記録されたマルチキャ
ストグループ管理プログラムをコンピュータに読み込ま
せ、実行することによりグループ管理を行うようにして
もよい。

【００９６】コンピュータは、上記マルチキャストグル
ープ管理プログラムを実行するＣＰＵと、キーボード、
マウス等の入力装置と、各種データを記憶するＲＯＭ
（ReadOnly Memory）と、演算パラメータ等を記憶する
ＲＡＭ（Random Access Memory）と、記録媒体からマル
チキャストグループ管理プログラムを読み取る読取装置
と、ディスプレイ、プリンタ等の出力装置と、装置各部
を接続するバスとから構成されている。

【００９７】ＣＰＵは、読取装置を経由して記録媒体に
記録されているマルチキャストグループ管理プログラム
を読み込んだ後、マルチキャストグループ管理プログラ
ムを実行することにより、前述した処理を実行する。な
お、記録媒体には、光ディスク、フロッピーディスク、
ハードディスク等の可搬型の記録媒体が含まれることは
もとより、ネットワークのようにデータを一時的に記録
保持するような伝送媒体も含まれる。

【００９８】

【発明の効果】以上説明したように、請求項１にかかる
発明によれば、従来の人手によらずマルチキャストグル
ープ管理装置によりグループ情報を管理し、グループが
更新された場合や送信ノードから通知要求された場合に
更新後のグループ情報を送信ノードに通知するようにし
たので、マルチキャストのグループを容易、正確かつ迅
速に管理することができるという効果を奏する。

【００９９】また、請求項２にかかる発明によれば、マ
ルチキャストグループ管理装置により、受信ノードの受
信状態を監視し、パケットを受信できない受信ノードが
ある場合、グループから当該受信ノードが除外されるた
め、不必要に当該受信ノードに対してパケットが送信さ
れないことから、ネットワークの伝送効率の低下を防ぐ
ことができるという効果を奏する。

【０１００】また、請求項３にかかる発明によれば、通
知リスト内の複数の送信ノードに対して変更後のグルー
プ情報を通知するようにしたので、複数の送信ノードと
グループとの間で多対多でのマルチキャスト通信を容易
に実現することができるという効果を奏する。

【０１０１】また、請求項４にかかる発明によれば、イ
ンターネット等で周知のＵＲＬという極めて簡単な指定
方法によりグループ情報を指定していることから、簡単
なオペレーションによりマルチキャスト送信を行うこと
ができるという効果を奏する。

【０１０２】また、請求項５にかかる発明によれば、従
来の人手によらずマルチキャストグループ管理手段によ
りグループ情報を管理し、グループが更新された場合や
送信ノードから通知要求された場合に更新後のグループ
情報を送信ノードに通知するようにしたので、マルチキ
ャストのグループを容易、正確かつ迅速に管理すること
ができるという効果を奏する。

【０１０３】また、請求項６にかかる発明によれば、従
来の人手によらずマルチキャストグループ管理工程でグ
ループ情報を管理し、グループが更新された場合や送信
ノードから通知要求された場合に更新後のグループ情報
を送信ノードに通知するようにしたので、マルチキャス
トのグループを容易、正確かつ迅速に管理することがで
きるという効果を奏する。

【図面の簡単な説明】

【図１】本発明にかかる一実施の形態の構成を示す図で
ある。

【図２】同一実施の形態におけるデータベースおよび宛
先リストを示す図である。

【図３】同一実施の形態におけるデータベースおよび宛
先リストを示す図である。

【図４】同一実施の形態における通知リストを示す図で
ある。

【図５】同一実施の形態におけるＵＲＬ指定の例を示す
図である。

【図６】同一実施の形態の初期化処理を説明するシーケ
ンス図である。

【図７】同一実施の形態の終了処理を説明するシーケン
ス図である。

【図８】同一実施の形態のネットワーク監視動作を説明
するシーケンス図である。

【図９】同一実施の形態の初期化処理を説明するシーケ
ンス図である。

【図１０】同一実施の形態の終了処理を説明するシーケ
ンス図である。

【図１１】同一実施の形態の初期化処理を説明するシー
ケンス図である。

【図１２】同一実施の形態の終了処理を説明するシーケ
ンス図である。

【図１３】同一実施の形態の管理サーバ３０の動作を説
明するフローチャートである。

【図１４】同一実施の形態の通信側クライアント１０の
動作を説明するフローチャートである。

【図１５】同一実施の形態の受信側クライアントの動作
を説明するフローチャートである。

【図１６】従来におけるマルチキャストシステムの構成
を示す図である。

【符号の説明】

１０ 送信側クライアント ２０ａ〜２０ｃ 受信側クライアント ３０ 管理サーバ

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5K030 GA11 HB00 HB19 HC01 HD03 KA02 LD06 9A001 BB03 BB04 CC06 DD10 FF03 JJ18 JJ27 KK56

Claims (6)

【特許請求の範囲】
1. 【請求項１】 マルチキャスト方式によりパケットをネ
   ットワークを介して複数の受信ノードへ送信する送信ノ
   ードを備えるマルチキャストシステムにおいて、 前記複数の受信ノードがグループ化されたグループに関
   するグループ情報を管理し、前記グループに更新が生じ
   た場合または前記送信ノードからの通知要求があった場
   合、前記送信ノードへ更新後のグループ情報を前記ネッ
   トワークを介して通知するマルチキャストグループ管理
   装置を備え、 前記送信ノードは、前記マルチキャストグループ管理装
   置から通知されるグループ情報に対応するグループへ前
   記パケットを送信することを特徴とするマルチキャスト
   システム。
2. 【請求項２】 前記マルチキャストグループ管理装置
   は、前記複数の受信ノードのそれぞれがパケットを受信
   できる状態にあるか否かを監視し、パケットを受信する
   ことができない受信ノードがある場合、当該受信ノード
   を前記グループから除外することを特徴とする請求項１
   に記載のマルチキャストシステム。
3. 【請求項３】 前記送信ノードは、複数存在しており、
   前記マルチキャストグループ管理装置は、複数の送信ノ
   ードからの要求により前記グループ情報を通知すべき送
   信ノードに関する通知リストを備え、該通知リスト内の
   送信ノードに対して変更後のグループ情報を前記ネット
   ワークを介して通知することを特徴とする請求項１また
   は２に記載のマルチキャストシステム。
4. 【請求項４】 少なくとも、前記送信ノードは、通知要
   求を出す際にＵＲＬにより、通知を受けるグループ情報
   を指定することを特徴とする請求項１〜３のいずれか一
   つに記載のマルチキャストシステム。
5. 【請求項５】 マルチキャスト方式によりパケットをネ
   ットワークを介して複数の受信ノードへグループ情報に
   基づいて送信する送信ノードを備えるマルチキャストシ
   ステムに適用されるマルチキャストグループ管理装置で
   あって、 前記複数の受信ノードがグループ化されたグループに関
   する前記グループ情報を管理し、前記グループに更新が
   生じた場合または前記送信ノードからの通知要求があっ
   た場合、前記送信ノードへ更新後のグループ情報を前記
   ネットワークを介して通知するマルチキャストグループ
   管理手段を備えることを特徴とするマルチキャストグル
   ープ管理装置。
6. 【請求項６】 マルチキャスト方式によりパケットをネ
   ットワークを介して複数の受信ノードへグループ情報に
   基づいて送信する送信ノードを備えるマルチキャストシ
   ステムに適用されるマルチキャストグループ管理プログ
   ラムを記録したコンピュータ読み取り可能な記録媒体で
   あって、 前記複数の受信ノードがグループ化されたグループに関
   する前記グループ情報を管理させ、前記グループに更新
   が生じた場合または前記送信ノードからの通知要求があ
   った場合、前記送信ノードへ更新後のグループ情報を前
   記ネットワークを介して通知させるマルチキャストグル
   ープ管理工程をコンピュータに実行させるためのマルチ
   キャストグループ管理プログラムを記録したコンピュー
   タ読み取り可能な記録媒体。