JP3782272B2 - マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents
マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP3782272B2 JP3782272B2 JP35511299A JP35511299A JP3782272B2 JP 3782272 B2 JP3782272 B2 JP 3782272B2 JP 35511299 A JP35511299 A JP 35511299A JP 35511299 A JP35511299 A JP 35511299A JP 3782272 B2 JP3782272 B2 JP 3782272B2
- Authority
- JP
- Japan
- Prior art keywords
- multicast group
- node
- multicast
- receiving
- management server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、マルチキャスト方式により、一つの送信ノードから複数の受信ノードへパケットを配信するマルチキャストシステムと、同マルチキャストシステムにおいてもちいられる管理サーバおよびマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
従来より、インターネットを代表とする分散パケット交換網では、パケット配信形式を宛先指定方法により幾つかに分類されている。既存のインターネットで使用されているＩＰｖ４や次世代インターネットの標準であるＩＰｖ６では、つぎの（１）項から（３）項までの都合三種類のパケット配信方式が用いられる。
【０００３】
（１）宛先が、唯一のアドレスに対応するユニキャスト方式
（２）宛先が、複数のアドレスからなるグループに対応し、それぞれのアドレスへパケットをコピーして配信するマルチキャスト方式
（３）宛先が複数のアドレスからなるグループに対応し、グループ内のいずれか一つのアドレスへパケットを配信するエニーキャスト方式
【０００４】
本発明は、（２）項のマルチキャスト方式に関するものである。このマルチキャスト方式は、同一のパケットを複数の受信ノードに同報できるため、マルチメディアデータの放送、多地点音声動画会議やネットワーク対戦型のゲーム等への応用が試みられている。
【０００５】
【従来の技術】
図１６は、従来のマルチキャストシステムの構成を示す図である。この図には、送信側クライアント１（送信ノード）と受信側クライアント２ａ〜２ｃ（受信ノードａ〜ｃ）とが、ルータ３1 〜３4 を含むネットワーク（たとえば、インターネット）を介して接続された構成が図示されている。送信側クライアント１は、コンピュータであり、ネットワークを介して受信側クライアント２ａ〜２ｃのうちあらかじめ設定されたグループに対してパケットを送信する。ビデオカメラＶは、多地点音声動画会議時に人物Ｐや背景等を撮像し、撮像データを送信側クライアント１へ出力する。
【０００６】
マルチキャストグループ管理テーブル５は、受信ノードａ〜ｃを複数組み合わせたグループを管理するテーブルでである。このマルチキャストグループ管理テーブル５において、「グループ」は、グループ名称であり、「メンバ」は、当該グループを構成する受信ノードである。
【０００７】
具体的には、グループＸは、受信ノードａ（受信側クライアント２ａ）、受信ノードｂ（受信側クライアント２ｂ）および受信ノードｃ（受信側クライアント２ｃ）から構成されている。グループＹは、受信ノードａ（受信側クライアント２ａ）および受信ノードｂ（受信側クライアント２ｂ）から構成されている。また、グループＺは、受信ノードｂ（受信側クライアント２ｂ）および受信ノードｃ（受信側クライアント２ｃ）から構成されている。これらのグループＸ〜Ｚは、パケットをマルチキャスト方式により受信ノードへ配信する際に、当該パケットの宛先情報とされる。
【０００８】
ルータ３1 〜３4 のそれぞれは、送信側クライアント１から送信されたパケットの宛先情報（グループ）を確認し、グループに応じて中継方向を動的に変化させることにより、パケットを所望のグループ内の受信ノードへ向けてルーティングする。これらのルータ３1 〜３4 には、ルーティングテーブル４1 〜４4 が予め保持されている。ルーティングテーブル４1 〜４4 は、グループＸ〜Ｚにそれぞれ対応する中継方向に関するデータからなり、ルーティング時にルータ３1 〜３4 により参照される。
【０００９】
上記構成において、たとえば、マルチキャストグループ管理テーブル５内のグループＸへパケットを送信する場合、送信側クライアント１のオペレータは、図示しないキーボードより、グループＸを構成する受信ノードａ〜ｃのそれぞれに付与されているネットワーク上のアドレスを順次入力する。これにより、送信側クライアント１は、宛先情報としてグループＸが付加されたパケットをネットワークへ送出する。
【００１０】
そして、パケットがルータ３1 に到着すると、ルータ３1 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４1 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、ルータ３2 方向（同図右矢印）および受信ノードｃ方向（同図下矢印）である。つぎに、ルータ３1 は、パケットのコピーを受信ノードｃおよびルータ３2 へ中継する。これにより、受信ノードｃ（受信側クライアント２ｃ）では、パケットが受信される。
【００１１】
一方、パケットがルータ３2 に到着すると、ルータ３2 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４2 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、ルータ３3 方向（同図右矢印）およびルータ３4 方向（同図右下矢印）である。つぎに、ルータ３2 は、パケットのコピーをルータ３3 およびルータ３4 へ中継する。
【００１２】
そして、パケットがルータ３3 に到着すると、ルータ３3 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４3 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、受信ノードａ方向（同図右矢印）である。つぎに、ルータ３3 は、パケットを受信ノードａへ中継する。これにより、受信ノードａ（受信側クライアント２ａ）では、パケットが受信される。
【００１３】
一方、パケットがルータ３4 に到着すると、ルータ３4 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４4 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、受信ノードｂ方向（同図右下矢印）である。つぎに、ルータ３4 は、パケットを受信ノードｂへ中継する。これにより、受信ノードｂ（受信側クライアント２ｂ）では、パケットが受信される。
【００１４】
【発明が解決しようとする課題】
ところで、前述したように、従来のマルチキャストシステムにおいては、図１６に示したマルチキャストルーティングテーブル４1 〜４4 でのグループの追加、削除、変更や受信ノードの追加、削除、変更（以下、更新という）を行う場合、送信側クライアント１の送信ノード管理者（または受信ノードの受信ノード管理者）からルータ３1 〜３4 のルータ管理者に対して電話や電子メールにより、上記更新を依頼した後、ルータ管理者により追加、削除、変更が行われる。
【００１５】
しかしながら、従来のマルチキャストシステムにおいては、人手を介してグループ（受信ノード）の更新を行っているため、グループや受信ノードの数が増えるにしたがって、グループ管理に要する時間、作業コストが増大してしまうという問題があった。また、人手によるグループ管理では、グループ（受信ノード）の更新に関するミスや漏れが発生するとともに、作業量の増大に伴って更新作業が大幅に遅れる場合があるという問題もあった。
【００１６】
また、従来のマルチキャストシステムでは、受信ノードａ〜ｃがパケットを受信できる状態にあるか否かにかかわらず、マルチキャストルーティングテーブル４1 〜４4 に基づいて、機械的にパケットを中継している。したがって、ネットワーク障害等によりパケットを受信できない状態にある受信ノードが存在した場合にも、当該受信ノードへ無駄なパケットが中継されるため、その分だけネットワークのトラフィック量が増え、ネットワークの伝送効率が悪くなるという問題があった。
【００１７】
さらに、従来のマルチキャストシステムでは、マルチキャストルーティングテーブル４1 〜４4 が更新された場合、更新後のグループ（受信ノード）に関する情報が送信側クライアント１にリアルタイムで正しく伝達されない可能性が高い。これは、電話や電子メール等の手段を用いて人手を介在させて上記変更後の情報が送信側ノード管理者へ伝達されるからである。したがって、このような場合には、送信側クライアント１が更新前のグループへ無駄なパケットを送信することになるため、その分だけネットワークのトラフィック量が増え、ネットワークの伝送効率が悪くなるという問題があった。
【００１８】
また、送信側クライアント１から、あるグループへパケットをマルチキャスト送信する場合には、当該グループを構成する受信ノードのそれぞれのアドレスを一々入力しなければならないため、マルチキャスト送信のためのオペレーションが複雑であるという問題があった。
【００１９】
本発明は、上記に鑑みてなされたもので、マルチキャストのグループを容易、正確かつ迅速に管理することができるとともに、ネットワークの伝送効率の低下を防ぐことができ、しかも簡単なオペレーションによりマルチキャスト送信を行うことができるマルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２０】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、所定のマルチキャストグループに属することができる受信ノードと、マルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信する送信ノードと、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバとをネットワークを介して接続したマルチキャストシステムにおいて、前記受信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに該マルチキャストグループへの参加要求を送信し、前記管理サーバは、前記受信ノードより前記参加要求が送信された場合に、該参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶し、該マルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信し、前記送信ノードは、前記管理サーバより送信された最新の宛先リストに含まれるアドレスを指定して前記マルチキャストグループ向けのパケットを送信することを特徴とする。
【００２１】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかを管理サーバが記憶して、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、送信ノードは、管理サーバから送信されたリストに含まれる受信ノードに対してマルチキャストデータを送信する。
【００２２】
このように、請求項１にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、管理サーバが把握している情報に基づいて送信ノードがマルチキャストデータを送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００２３】
また、請求項２にかかる発明は、請求項１に記載のマルチキャストシステムにおいて、前記受信ノードは、自身が通信可能であることを示すパケットを前記管理サーバに所定の時間間隔で送信し、前記管理サーバは、所定の時間を経過しても前記受信ノードから前記パケットが送信されない場合は、前記記憶手段に該受信ノードが通信不能である旨を記憶し、前記宛先リストを生成する場合に、前記記憶手段において通信不能である旨が記憶されている受信ノードのアドレスを前記宛先リストから除外することを特徴とする。
【００２４】
この発明によれば、受信ノードから定期的に送信されるパケットの受信状況を監視することで受信ノードが通信可能な状態にあるかどうかを管理サーバが判断し、通信可能な状態にあると判断した受信ノードを宛先リストから除外するように構成したので、通信可能な状態にある受信ノードに対してマルチキャストデータが無駄に送信されることがなくなり、ネットワークの伝送効率の低下を防ぐことができる。
【００２５】
また、請求項３にかかる発明は、請求項１または２に記載のマルチキャストシステムにおいて、前記送信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに前記宛先リストの通知要求を送信し、前記管理サーバは、前記送信ノードより前記通知要求が送信された場合に、該通知要求にて指定されたアドレスをマルチキャストグループごとの通知リストに登録し、前記宛先リストを送信する場合に、該宛先リストに対応するマルチキャストグループの通知リストに登録されているアドレスに前記宛先リストを送信することを特徴とする請求項１または２に記載のマルチキャストシステムを特徴とする。
【００２６】
この発明によれば、どの送信ノードからどのマルチキャストグループの宛先リストの通知要求があったかを管理サーバが通知リストに登録し、宛先リストを送信ノードに送信する場合にこの通知リストに基づいて送信先を決定するように構成したので、マルチキャストグループに対応する送信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００２７】
また、請求項４にかかる発明は、請求項１〜３のいずれか一つに記載のマルチキャストシステムにおいて、前記送信ノードは、前記通知要求を送信するために必要なマルチキャストグループと管理サーバの指定をＵＲＬの書式で受け付けることを特徴とする。
【００２８】
この発明によれば、通知要求の送信時に、インターネット等で周知のＵＲＬという簡潔で定型化された書式をもちいて管理サーバとマルチキャストグループの指定を行うように構成したので、簡単なオペレーションにより通知要求の送信を行うことができる。
【００２９】
また、請求項５にかかる発明は、送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバであって、前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信手段と、前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録手段と、前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信手段とを備えたことを特徴とする。
【００３０】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかを管理サーバが記憶して、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、マルチキャストデータの送信先として利用させる。
【００３１】
このように、請求項５にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００３２】
また、請求項６にかかる発明は、送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理するマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信工程と、前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録工程と、前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信工程とをコンピュータに実行させることを特徴とする。
【００３３】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかをマルチキャストグループ管理プログラムが記憶手段に記憶させ、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、マルチキャストデータの送信先として利用させる。
【００３４】
このように、請求項６にかかる発明によれば、マルチキャストグループ管理プログラムが受信ノードから受信した参加要求に係る情報手段に記憶させることでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００３５】
【発明の実施の形態】
以下、図面を参照して本発明にかかるマルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体の一実施の形態について詳細に説明する。
【００３６】
図１は、本発明にかかる一実施の形態の構成を示す図である。この図には、送信側クライアント１０（送信ノード）と受信側クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）とが、ルータ４０1 〜４０4 を含むネットワーク（たとえば、インターネット）を介して接続された構成が図示されている。送信側クライアント１０は、コンピュータであり、ネットワークを介して受信側クライアント２０ａ〜２０ｃのうちあらかじめ設定されたグループに対してパケットを送信する。なお、同図には、送信側クライアント１０のみ図示されているが、他の送信側クライアントもネットワークに接続されている。ビデオカメラＶは、多地点音声動画会議時に人物Ｐや背景等を撮像し、撮像データを送信側クライアント１０へ出力する。
【００３７】
受信側クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）は、複数のグループにグルーピングされており、送信側クライアント１０からマルチキャスト送信されたパケットをそれぞれ受信する。これらの受信側クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）のそれぞれには、ネットワーク上のアドレスが付与されている。また、受信側クライアント２０ａ〜２０ｃのそれぞれは、パケットを受信することができるか否かというネットワーク状態を監視する監視機能、監視結果を管理サーバ３０へ通知するネットワーク状態通知機能を備えている。
【００３８】
なお、同図には、受信側クライアントとして受信側クライアント２０ａ〜２０ｃが図示されているが、これら以外にも図示しない受信側クライアントが多数ネットワークに接続されている。
【００３９】
管理サーバ３０は、ネットワークに接続されており、マルチキャストグループ管理テーブル５０を管理する。このマルチキャストグループ管理テーブル５０は、たとえば、受信ノードａ〜ｃを複数組み合わせたグループを管理するテーブルである。このマルチキャストグループ管理テーブル５０において、「グループ」は、グループ名称であり、「メンバ」は、当該グループを構成する受信ノードである。
【００４０】
同図に示した例では、グループＸは、受信ノードａ（受信側クライアント２０ａ）、受信ノードｂ（受信側クライアント２０ｂ）および受信ノードｃ（受信側クライアント２０ｃ）から構成されている。グループＹは、受信ノードａ（受信側クライアント２０ａ）および受信ノードｂ（受信側クライアント２０ｂ）から構成されている。また、グループＺは、受信ノードｂ（受信側クライアント２０ｂ）および受信ノードｃ（受信側クライアント２０ｃ）から構成されている。これらのグループＸ〜Ｚは、パケットをマルチキャスト方式により受信ノードへ配信する際に、当該パケットの宛先情報とされる。
【００４１】
ここで、実際には、マルチキャストグループ管理テーブル５０は、図２（ａ）に示したようなデータベースから構成されている。同図に示したデータベースは、マルチキャストグループ管理テーブル５０のグループＸに対応しており、「受信ノード名」、「受信ノードのアドレス」、「ネットワーク状態」および「タイムアウト時刻」というデータからなる。「受信ノード名」は、グループＸを構成する受信ノードの名称であり、ｎｏｄｅＡ〜Ｃである。これらのｎｏｄｅＡ〜Ｃは、図１に示した受信ノードａ〜ｃに対応している。
【００４２】
「受信ノードのアドレス」は、それぞれの受信ノードに付与されたネットワーク上のアドレスである。「ネットワーク状態」は、受信ノードがパケットを受信できる状態にあるか否かを示すフラグである。すなわち、「ネットワーク状態」に「オフライン」フラグがたっている場合には、当該受信ノード（この場合、図１に示した受信ノードｂ）がパケットを受信できない状態にあることを意味している。一方、「ネットワーク状態」にいずれのフラグもたっていない場合には、当該受信ノードがパケットを受信できる状態にあることを意味している。「タイムアウト時刻」は、当該受信ノードがパケットを受信できない状態にあることを判断するための時刻である。
【００４４】
つぎに、図６〜図８に示したシーケンス図を参照して一実施の形態の動作について説明する。図６は一実施の形態の初期化処理を説明するシーケンス図であり、図７は一実施の形態の終了処理を説明するシーケンス図であり、図８は一実施の形態のネットワーク監視動作を説明するシーケンス図である。図６に示したステップＳＡ１では、管理サーバの初期化処理が実行される。
【００４５】
すなわち、ステップＳＡ１では、図１に示した管理サーバ３０は、マルチキャストグループを設定するための空のデータベース、後述する通知リストを作成する。ここで作成されるデータベースは、図２（ａ）に示したフォーマットのものである。また、作成された空のデータベースには、いずれのデータも存在していない。
【００４６】
つぎに、ステップＳＡ２〜ステップＳＡ８までは、送信側クライアントの初期化処理が実行される。すなわち、ステップＳＡ２では、送信側クライアント１０は、マルチキャスト方式によるパケットの配信を実現するためのアプリケーションを初期化する。ここで、送信側クライアント１０のオペレータは、アクセス先の管理サーバ３０、マルチキャストグループ管理テーブル５０におけるグループ等を指定するためのＵＲＬ（Uniform Resource Locator）を入力する。
【００４７】
ここで、図５（ａ）〜（ｅ）を参照してＵＲＬ指定の例について説明する。これらの図に示したＵＲＬでは、「プロトコル」、「ユーザ名」、「パスワード」、「ホスト名」、「ポート番号」および「グループ名」を指定することができる。上記「ホスト名」は、管理サーバ３０のネットワーク上の名称であり、「グループ名」は、マルチキャストグループ管理テーブル５０（図１参照）におけるグループの名称である。すなわち、ＵＲＬにより、少なくとも管理サーバ３０およびグループを指定することが可能である。
【００４８】
図６に戻り、ステップＳＡ３では、送信側クライアント１０は、入力されたＵＲＬを解析し、「プロトコル」、「パスワード」、「ユーザ名」、「ホスト名」、「ポート番号」および「グループ名」を特定する。この場合、少なくとも「ホスト名」（管理サーバ３０の名称）および「グループ名」が特定されたものとする。ステップＳＡ４では、送信側クライアント１０は、ネットワークを介して管理サーバ３０にアクセスし、図４（ａ）に示した通知リストへ自身のネットワーク上のアドレス（たとえば、「２０２．３３．９６．４２」）を追加するように要求する。
【００４９】
ここで、同図に示した通知リストは、図１に示したマルチキャストグループ管理テーブル５０を構成する、たとえば、図３（ａ）に示したデータベース（グループ情報）を通知すべき送信側クライアントのアドレスを表すリストであり、管理サーバ３０に保持されている。ステップＳＡ５では、管理サーバ３０は、図４（ａ）に示した通知リストに、管理サーバ３０のアドレス「２０２．３３．９６．４２」（図４（ｂ）参照）を追加する。
【００５０】
ステップＳＡ６では、送信側クライアント１０は、管理サーバ３０に対して、ＵＲＬ指定された「グループ名」に対応するグループ情報、すなわちデータベース（図２（ａ）参照）の送信を要求する。ここでは、図２に示したデータベースには、いずれのデータも存在しない。
【００５１】
これにより、ステップＳＡ７では、管理サーバ３０は、図２（ａ）に示したフォーマットの空のデータベース（グループ情報）を送信側クライアント１０へ送信する。ステップＳＡ８では、送信側クライアント１０は、受信した空のデータベースから、図２（ｂ）に示したようなフォーマットの宛先リストを生成する。この場合、宛先リストには、いずれのデータも存在しない。宛先リストは、マルチキャスト送信により送信側クライアント１０から送信すべきパケットの宛先（受信ノードのアドレス）のリストである。
【００５２】
つぎに、ステップＳＡ９〜ステップＳＡ１４までは、受信側クライアントの初期化処理が実行される。すなわち、ステップＳＡ９では、受信側クライアント（受信側クライアント２０ａ〜２０ｃ、その他の受信側クライアントのうちいずれか一つまたは二つ以上）は、マルチキャスト方式によるパケットの受信を実現するためのアプリケーションを初期化する。ここで、受信側クライアントのオペレータは、送信側クライアント１０のオペレータと同様にして、アクセス先の管理サーバ３０、マルチキャストグループ管理テーブル５０におけるグループ等を指定するためのＵＲＬ（図５（ａ）〜（ｅ）参照）を入力する。
【００５３】
ステップＳＡ１０では、受信側クライアントは、入力されたＵＲＬを解析し、「プロトコル」、「パスワード」、「ユーザ名」、「ホスト名」、「ポート番号」および「グループ名」を特定する。この場合、少なくとも「ホスト名」（管理サーバ３０の名称）および「グループ名」が特定されたものとする。ステップＳＡ１２では、受信側クライアントは、ネットワークを介して管理サーバ３０にアクセスし、ステップＳＡ１で作成されたデータベースに自身のネットワーク上のアドレスを登録するように要求する。すなわち、受信側クライアントは、マルチキャストグループ管理テーブル５０におけるグループに自身のアドレスを登録するための要求を出す。
【００５４】
ステップＳＡ１１では、管理サーバ３０は、ステップＳＡ１で作成されたデータベースに当該受信側クライアントの「ノード名」、「受信ノードのアドレス」、「ネットワーク状態」および「タイムアウト時刻」を登録する。たとえば、図２（ｃ）に示したように、ｎｏｄｅＤの受信側クライアントからグループへの登録要求があった場合、データベースには、ｎｏｄｅＤに関する「ノード名」、「受信ノードのアドレス」、「ネットワーク状態」、「タイムアウト時刻」が登録される。
【００５５】
ステップＳＡ１３では、管理サーバ３０は、ステップＳＡ５の通知リスト（図４（ｂ）参照）に基づいて、通知リストに存在するアドレス（送信側クライアント１０）へ、ステップＳＡ１１で登録されたデータベースを新しいグループ情報として自動通知する。この場合、図２（ａ）に示したデータベース（グループ情報）が少なくとも送信側クライアント１０に通知されたものとする。なお、データベースは、送信側クライアント１０以外の送信側クライアントであって宛先リストにアドレスが記載されているものにも送信される。
【００５６】
これにより、ステップＳＡ１４では、送信側クライアント１０は、図２（ａ）に示したデータベースから、図２（ｂ）に示した宛先リストを作成する。この宛先リストは、上記データベースで「ネットワーク状態」の欄に「オフライン」フラグがたっていない受信ノードのアドレスからなる。すなわち、宛先リストのアドレスは、パケットを正常に受信可能な受信ノードに対応している。図２（ｂ）に示した例では、宛先リストには、図２（ａ）に示したｎｏｄｅＡ（受信ノードａ：図１参照）のアドレス、およびｎｏｄｅＣ（受信ノードｃ：図１参照）のアドレスが含まれている。なお、図２（ｃ）に示したデータベースからは、図２（ｄ）に示した宛先リストが生成され、図２（ｅ）に示したデータベースからは、図２（ｆ）に示した宛先リストが生成される。
【００５７】
ステップＳＡ１５では、送信側クライアント１０は、図２（ｂ）に示した宛先リストに基づいて、図１に示した受信ノードａおよび受信ノードｃに対してパケットを送信する。また、ステップＳＡ１３で新しいグループ情報が自動通知された他の送信側クライアント（図示略）も、受信ノードａおよびｃに対してパケットを送信する。この場合には、多対多の通信が実現される。
【００５８】
つぎに、図７を参照して終了処理について説明する。同図において、マルチキャスト送信を中止する場合、送信側クライアント１０は、ステップＳＢ１〜ステップＳＢ４までの終了処理を実行する。すなわち、ステップＳＢ２では、送信側クライアント１０は、図４（ｂ）に示した通知リストからの自身のアドレス（「２０２．３３．９６．４２」）の削除を管理サーバ３０へ要求する。
【００５９】
これにより、ステップＳＢ１では、管理サーバ３０は、上記アドレスを通知リストから削除する。これにより、通知リストは、図４（ａ）に示したものとなる。なお、他の送信側クライアントからアドレス（たとえば、「２０２．２３９．１６２．３４」）の削除要求があった場合、管理サーバ３０は、図４（ｂ）に示した通知リストから上記アドレスを削除する。この場合、通知リストは、図４（ｃ）に示したものとなる。
【００６０】
ステップＳＢ３では、管理サーバ３０は、送信側クライアント１０へのグループ情報（データベース）の自動送信を停止する。ステップＳＢ４では、送信側クライアント１０は、アプリケーションの終了処理を実行する。これにより、ステップＳＢ５では、マルチキャスト送信が中止される。
【００６１】
また、受信側クライアントがパケットの受信を終了する場合、ステップＳＢ６では、受信側クライアントは、データベース（たとえば、図２（ａ）参照）に登録されている自身に関するデータを削除するように管理サーバ３０へ要求する。これにより、ステップＳＢ７では、管理サーバ３０は、データベースから当該受信側クライアントに関するデータを削除する。
【００６２】
すなわち、当該受信側クライアントは、マルチキャストグループ管理テーブル５０のグループから除外されたのである。ステップＳＢ８では、受信側クライアントは、アプリケーションの終了処理を実行する。また、ステップＳＢ９では、管理サーバ３０は、データベースおよび通知リストを削除することにより、終了処理を実行する。
【００６３】
つぎに、図８を参照してネットワーク監視動作について説明する。図１に示したネットワークが正常である場合、ステップＳＣ１〜ステップＳＣ６までの処理が実行される。すなわち、ステップＳＣ１では、受信側クライアントは、管理サーバ３０に対してタイムアウト延長要求を出す。ここでタイムアウト延長要求とは、図２（ａ）に示したデータベースにおける「タイムアウト時刻」の延長を要求することをいう。また、受信側クライアントは、一定時間毎（たとえば、３０秒毎）にタイムアウト延長要求を管理サーバ３０に対して出す。
【００６４】
ステップＳＣ２では、管理サーバ３０は、タイムアウト延長要求を受けると、データベースのタイムアウト時刻をたとえば１分後の時刻に再設定する。ステップＳＣ３では、送信側クライアント１０は、マルチキャスト通信を継続する。そして、ステップＳＣ１でタイムアウト要求を出した時刻から３０秒経過すると、ステップＳＣ４では、当該受信側クライアントは、管理サーバ３０に対して再びタイムアウト延長要求を出す。ステップＳＣ５では、管理サーバ３０は、タイムアウト延長要求を受けると、データベースのタイムアウト時刻をたとえば１分後の時刻に再設定する。ステップＳＣ６では、送信側クライアント１０は、マルチキャスト通信を継続する。以後、上述した動作が繰り返される。
【００６５】
ここでネットワーク故障が発生すると、ステップＳＣ７では、上記受信側クライアントからのタイムアウト延長要求に失敗する。これは、データベース（図２（ａ）参照）の「タイムアウト時刻」を経過しても、受信側クライアントからのタイムアウト延長要求がない場合である。ステップＳＣ８では、管理サーバ３０は、たとえば、図２（ｅ）に示したように、ｎｏｄｅＡおよびＤからのタイムアウト延長要求が無かった場合、ｎｏｄｅＡおよびＤに対応する「ネットワーク状態」の欄にオフラインのフラグを設定する。すなわち、同図に示したデータベースからは、ｎｏｄｅＣのみがパケットの受信が可能な状態にあることがわかり、その他のｎｏｄｅＡ、ｎｏｄｅＢおよびｎｏｄｅＤがパケットの受信が出来ない状態（オフライン）にあることがわかる。
【００６６】
ステップＳＣ９では、管理サーバ３０は、たとえば、図２（ｅ）に示したデータベース（グループ情報）を、宛先リストに基づいて、たとえば、送信側クライアント１０へ自動通知する。これにより、ステップＳＣ１０では、送信側クライアント１０は、図２（ｆ）に示した宛先リストを生成する。ステップＳＣ１１では、送信側クライアント１０は、タイムアウト延長要求に失敗した当該受信側クライアントに対するマルチキャスト送信を停止する。
【００６７】
そして、ネットワークが回復すると、ステップＳＣ１２では、ステップＳＣ７でタイムアウト延長要求に失敗した受信側クライアントは、管理サーバ３０に対するタイムアウト延長要求を再開する。これにより、ステップＳＣ１３では、管理サーバ３０は、データベース（図２（ｅ）参照）から、当該受信側クライアントに対応するオフラインのフラグを消去する。
【００６８】
ステップＳＣ１４では、管理サーバ３０は、オフラインのフラグが消去されたデータベース（グループ情報）を、宛先リストに基づいて、たとえば、送信側クライアント１０へ自動通知する。これにより、ステップＳＣ１５では、送信側クライアント１０は、宛先リストを生成する。この宛先リストには、オフラインのフラグが消去された当該受信側クライアントのアドレスが含まれている。これにより、ステップＳＣ１６では、送信側クライアント１０は、タイムアウト延長要求を再開した当該受信側クライアントに対するマルチキャスト送信を再開する。
【００６９】
なお、前述した図６では、送信側クライアントの初期化処理が受信側クライアントの初期化処理より先に実行される場合について説明したが、これとは逆に受信側クライアントの初期化処理が送信側クライアントの初期化処理より先に実行された場合には、図９に示したシーケンスで各処理が実行される。図９において、ステップＳＤ１は、ステップＳＡ１（図６参照）に対応しており、ステップＳＤ２〜ステップＳＤ５は、ステップＳＡ９〜ステップＳＡ１２に対応している。また、図９に示したステップＳＤ６〜ステップＳＤ１３は、図６に示したステップＳＡ２〜ステップＳＡ８およびステップＳＡ１５に対応している。
【００７０】
同様にして、前述した図７では送信側クライアントの終了処理が受信側クライアントの終了処理より先に実行される場合について説明したが、これとは逆に受信側クライアントの終了処理が送信側クライアントの終了処理より先に実行された場合には、図１０に示したシーケンスで各処理が実行される。図１０において、ステップＳＥ１およびステップＳＥ２は、図７に示したステップＳＢ６およびステップＳＢ７に対応している。
【００７１】
ステップＳＥ３では管理サーバ３０から送信側クライアント１０へ新しいグループ情報が自動通知され、ステップＳＥ４では宛先リストが生成される。これにより、ステップＳＥ６では、マルチキャスト送信が停止される。また、図１０に示したステップＳＥ８〜ステップＳＥ１２は、図７に示したステップＳＢ１〜ステップＳＢ５およびステップＳＢ９に対応している。
【００７２】
図１１は、二つの受信側クライアント（１）および（２）がある場合の初期化処理を説明するシーケンス図である。図１１に示したステップＳＦ１〜ステップＳＦ５は、図９に示したステップＳＤ１〜ステップＳＤ５に対応している。ただし、図１１に示したステップＳＦ１〜ステップＳＦ５までの処理は、受信側クライアント（１）の初期化処理である。また、図１１に示したステップＳＦ６〜ステップＳＦ１３は、図９に示したステップＳＤ６〜ステップＳＤ１３に対応している。だだし、ステップＳＦ１３の処理は、受信側クライアント（１）に対してマルチキャスト送信を開始する処理である。
【００７３】
さらに、図１１に示したステップＳＦ１４〜ステップＳＦ２０は、受信側クライアント（２）の初期化処理である。ステップＳＦ１４〜ステップＳＦ１７までの処理は、ステップＳＦ２〜ステップＳＦ５の処理と同様である。ステップＳＦ１８では管理サーバ３０から受信側クライアント（２）を含む新しいグループ情報が送信側クライアント１０に自動通知される。ステップＳＦ１９では、送信側クライアント１０は、宛先リストを生成する。ステップＳＦ２０では、送信側クライアント１０は、受信側クライアント（１）および（２）へのマルチキャスト送信を開始する。
【００７４】
図１２は、二つの受信側クライアント（１）および（２）がある場合の終了処理を説明するシーケンス図である。図１２に示したステップＳＧ１〜ステップＳＧ６は、図１０に示したステップＳＥ１〜ステップＳＥ６に対応している。ただし、図１１に示したステップＳＧ２〜ステップＳＧ６までの処理は、受信側クライアント（１）の終了処理である。また、ステップＳＧ６では、受信側クライアント（１）に対するマルチキャスト通信が停止され、受信側クライアント（２）に対するマルチキャスト通信が継続される。
【００７５】
また、図１２に示したステップＳＧ７〜ステップＳＧ１１は、図１０に示したステップＳＥ７〜ステップＳＥ１１に対応している。さらに、図１２に示したステップＳＧ１２〜ステップＳＧ１４は、図１０に示したステップＳＥ１、ステップＳＥ２およびステップＳＥ５に対応している。ただし、ステップＳＧ１２〜ステップＳＧ１４までの処理は、受信側クライアント（２）の終了処理である。図１２に示したステップＳＧ１５は、図１０に示したステップＳＥ１２に対応している。
【００７６】
つぎに、図１３〜図１５に示したフローチャートを参照して管理サーバ３０、送信側クライアント１０および受信側クライアントの動作について説明する。これらの動作は、前述した図６〜図１２までのシーケンスに対応する動作である。図１３に示したステップＳＨ１では、管理サーバ３０は、空のデータベースおよび通知リストを作成する（ステップＳＡ１：図６参照）。ステップＳＨ２では、管理サーバ３０は、送信側クライアント１０または受信側クライアントからリクエストが到着しているか否かを判断する。
【００７７】
この場合、ステップＳＨ２の判断結果が「Ｎｏ」であるものとすると、ステップＳＨ３では、管理サーバ３０は、タイムアウトした受信ノードをデータベースから検索する。ステップＳＨ４では、管理サーバ３０は、タイムアウトした受信ノードがあったか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＨ２の処理を実行する。一方、ステップＳＨ４の判断結果が「Ｙｅｓ」である場合、ステップＳＨ５では、管理サーバ３０は、データベースにオフラインのフラグを設定する（ステップＳＣ８：図８参照）。
【００７８】
ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノード（送信側クライアント１０）にデータベースの内容を通知する（ステップＳＣ９：図８参照）。ステップＳＨ１７では、管理サーバ３０は、処理を継続するか否かを判断し、この判断結果が「Ｙｅｓ」である場合、ステップＳＨ２の処理を実行する。
【００７９】
ステップＳＨ２では、管理サーバ３０は、リクエストが到着しているか否かを判断する。この場合、判断結果が「Ｙｅｓ」であるものとする。ステップＳＨ６では、管理サーバ３０は、リクエストの内容を判断する。ここで、リクエストの内容が送信側クライアント１０からのグループ情報の問い合わせ（ステップＳＡ６：図６参照）である場合、ステップＳＨ７では、管理サーバ３０は、データベース（グループ情報）を送信側クライアント１０へ送信する（ステップＳＡ７：図６参照）。
【００８０】
また、リクエストの内容が受信側クライアントからのグループ登録解除（ステップＳＥ１：図１０参照）である場合、ステップＳＨ８では、管理サーバ３０は、データベースから受信ノードに関する情報を削除する（ステップＳＥ２：図１０参照）。ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノードにデータベースの内容を通知する（ステップＳＥ３：図１０参照）。
【００８１】
また、リクエストの内容が受信側クライアントからのグループ登録である場合（ステップＳＡ１２：図６参照）、ステップＳＨ１０では、管理サーバ３０は、データベースに受信ノード（ステップＳＡ１１：図６参照）を追加する。ステップＳＨ１１では、タイムアウト時刻の設定を行う。ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノードにデータベースの内容を通知する（ステップＳＡ１３：図６参照）。
【００８２】
また、リクエストの内容が受信側クライアントからのタイムアウト延長（ステップＳＣ１：図８参照）である場合、ステップＳＨ１２では、管理サーバ３０は、タイムアウト時刻を再設定する（ステップＳＣ２：図８参照）。ステップＳＨ１３では、管理サーバ３０は、データベース（図２（ａ）参照）にオフラインのフラグがあるか否かを判断する。この判断結果が「Ｙｅｓ」である場合、ステップＳＨ１４では、管理サーバ３０は、上記オフラインのフラグを削除する（ステップＳＣ１３：図８参照）。ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノードにデータベースの内容を通知する（ステップＳＣ１４：図８参照）。
【００８３】
また、リクエストの内容が通知リストの登録の解除である場合（ステップＳＢ２：図７参照）、ステップＳＨ１５では、管理サーバ３０は、通知リストから送信ノードのアドレスを削除する（ステップＳＢ１：図７参照）。また、リクエストの内容が送信ノードからの通知リストの登録である場合（ステップＳＡ４：図６参照）である場合、ステップＳＨ１６では、管理サーバ３０は、通知リストに送信ノードのアドレスを追加する（ステップＳＡ５：図６参照）。ステップＳＨ１７の判断結果が「Ｎｏ」である場合、ステップＳＨ１８では、管理サーバ３０は、データベースと通知リストを削除する（ステップＳＢ９：図７参照）。
【００８４】
つぎに、図１４を参照して送信側クライアント１０の動作について説明する。図１４に示したステップＳＩ１では、送信側クライアント１０は、マルチキャスト通信用のアプリケーションを初期化する（ステップＳＤ６：図９参照）。ステップＳＩ２では、送信側クライアント１０は、入力されたＵＲＬを解析する（ステップＳＤ７：図９参照）。ステップＳＩ３では、送信側クライアント１０は、管理サーバ３０に対して、通知リストへのアドレスの追加を要求する（ステップＳＤ８：図９参照）。
【００８５】
ステップＳＩ４では、送信側クライアント１０は、グループ情報（データベース）の送信要求を管理サーバ３０へ出した後、グループ情報（データベース）を取得する（ステップＳＤ１１：図９参照）。ステップＳＩ５では、送信側クライアント１０は、グループ情報からオフラインの受信ノードを取り除き、宛先リストを作成する（ステップＳＤ１２：図９参照）。ステップＳＩ６では、送信側クライアント１０は、宛先リストにしたがってマルチキャストデータグラム（パケット）の送信を開始する（ステップＳＤ１３：図９参照）。
【００８６】
ステップＳＩ７では、送信側クライアント１０は、処理を継続するか否かを判断する。この判断結果が「Ｙｅｓ」である場合、ステップＳＩ８では、送信側クライアント１０は、新しいグループ情報（データベース）が管理サーバ３０から届いているか否かを判断する。この判断結果が「Ｙｅｓ」である場合、送信側クライアント１０は、ステップＳＩ５の処理を実行する。一方、ステップＳＩ８の判断結果が「Ｎｏ」である場合、送信側クライアント１０は、ステップＳＩ６の処理を実行する。
【００８７】
そして、ステップＳＩ７の判断結果が「Ｎｏ」になると、ステップＳＩ９では、送信側クライアント１０は、管理サーバ３０に対して通知リストからの削除を要求する（ステップＳＥ７：図１０参照）。ステップＳＩ１０では、送信側クライアント１０は、アプリケーションを終了する（ステップＳＥ１０：図１０参照）。
【００８８】
つぎに、図１５を参照して受信側クライアント（受信側クライアント２０ａ〜２０ｃ）の動作について説明する。図１５に示したステップＳＪ１では、受信側クライアントは、マルチキャスト受信用のアプリケーションを初期化する（ステップＳＡ９：図６参照）。ステップＳＪ２では、受信側クライアントは、入力されたＵＲＬを解析する（ステップＳＡ１０：図６参照）。ステップＳＪ３では、受信側クライアントは、管理サーバ３０に対して、グループへの登録を要求する（ステップＳＡ１２：図６参照）。
【００８９】
ステップＳＪ４では、受信側クライアントは、送信側クライアント１０からのマルチキャストデータグラム（パケット）を受信する。ステップＳＪ５では、受信側クライアントは、前回のタイムアウト延長要求時から３０秒経過したか否かを判断する。この判断結果が「Ｎｏ」である場合、ステップＳＪ７では、受信側クライアントは、処理を継続するか否かを判断する。この判断結果が「Ｙｅｓ」である場合、受信側クライアントは、ステップＳＪ４の処理を実行する。
【００９０】
そして、ステップＳＪ５の判断結果が「Ｙｅｓ」になると、ステップＳＪ６では、受信側クライアントは、管理サーバ３０にタイムアウト延長を要求する（ステップＳＣ１：図８参照）。また、ステップＳＪ７の判断結果が「Ｎｏ」である場合、ステップＳＪ８では、受信側クライアントは、管理サーバ３０に対してグループからの登録を解除することを要求する（ステップＳＢ６：図７参照）。ステップＳＪ９では、受信側クライアントは、アプリケーションを終了する（ステップＳＢ８：図７参照）。
【００９１】
以上説明したように、一実施の形態によれば、従来の人手によらず管理サーバ３０によりデータベース（グループ情報）を管理し、グループが更新された場合や送信ノードから通知要求された場合に更新後のグループ情報を送信ノードに通知するようにしたので、マルチキャストのグループを容易、正確かつ迅速に管理することができる。
【００９２】
また、一実施の形態によれば、管理サーバ３０により、受信ノードａ〜ｃの受信状態（ネットワーク状態）を監視し、パケットを受信できない受信ノードがある場合、グループから当該受信ノードが除外されるため、不必要に当該受信ノードに対してパケットが送信されないことから、ネットワークの伝送効率の低下を防ぐことができる。
【００９３】
また、一実施の形態によれば、通知リスト内の複数の送信ノードに対して変更後のグループ情報を通知するようにしたので、複数の送信ノードとグループとの間で多対多でのマルチキャスト通信を容易に実現することができる。
【００９４】
また、一実施の形態によれば、インターネット等で周知のＵＲＬという極めて簡単な指定方法によりグループ情報等を指定していることから、簡単なオペレーションによりマルチキャスト送信を行うことができる。
【００９５】
以上本発明にかかる一実施の形態について図面を参照して詳述してきたが、具体的な構成例はこの一実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。たとえば、前述した一実施の形態においては、管理サーバ３０の機能を実現するためのマルチキャストグループ管理プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたマルチキャストグループ管理プログラムをコンピュータに読み込ませ、実行することによりグループ管理を行うようにしてもよい。
【００９６】
コンピュータは、上記マルチキャストグループ管理プログラムを実行するＣＰＵと、キーボード、マウス等の入力装置と、各種データを記憶するＲＯＭ（Read Only Memory）と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）と、記録媒体からマルチキャストグループ管理プログラムを読み取る読取装置と、ディスプレイ、プリンタ等の出力装置と、装置各部を接続するバスとから構成されている。
【００９７】
ＣＰＵは、読取装置を経由して記録媒体に記録されているマルチキャストグループ管理プログラムを読み込んだ後、マルチキャストグループ管理プログラムを実行することにより、前述した処理を実行する。なお、記録媒体には、光ディスク、フロッピーディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【００９８】
【発明の効果】
以上説明したように、請求項１にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、管理サーバが把握している情報に基づいて送信ノードがマルチキャストデータを送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【００９９】
また、請求項２にかかる発明によれば、受信ノードから定期的に送信されるパケットの受信状況を監視することで受信ノードが通信可能な状態にあるかどうかを管理サーバが判断し、通信可能な状態にあると判断した受信ノードを宛先リストから除外するように構成したので、通信可能な状態にある受信ノードに対してマルチキャストデータが無駄に送信されることがなくなり、ネットワークの伝送効率の低下を防ぐことができるという効果を奏する。
【０１００】
また、請求項３にかかる発明によれば、どの送信ノードからどのマルチキャストグループの宛先リストの通知要求があったかを管理サーバが通知リストに登録し、宛先リストを送信ノードに送信する場合にこの通知リストに基づいて送信先を決定するように構成したので、マルチキャストグループに対応する送信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【０１０１】
また、請求項４にかかる発明によれば、通知要求の送信時に、インターネット等で周知のＵＲＬという簡潔で定型化された書式をもちいて管理サーバとマルチキャストグループの指定を行うように構成したので、簡単なオペレーションにより通知要求の送信を行うことができるという効果を奏する。
【０１０２】
また、請求項５にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【０１０３】
また、請求項６にかかる発明によれば、マルチキャストグループ管理プログラムが受信ノードから受信した参加要求に係る情報を記憶手段に記憶させることでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明にかかる一実施の形態の構成を示す図である。
【図２】同一実施の形態におけるデータベースおよび宛先リストを示す図である。
【図３】同一実施の形態におけるデータベースおよび宛先リストを示す図である。
【図４】同一実施の形態における通知リストを示す図である。
【図５】同一実施の形態におけるＵＲＬ指定の例を示す図である。
【図６】同一実施の形態の初期化処理を説明するシーケンス図である。
【図７】同一実施の形態の終了処理を説明するシーケンス図である。
【図８】同一実施の形態のネットワーク監視動作を説明するシーケンス図である。
【図９】同一実施の形態の初期化処理を説明するシーケンス図である。
【図１０】同一実施の形態の終了処理を説明するシーケンス図である。
【図１１】同一実施の形態の初期化処理を説明するシーケンス図である。
【図１２】同一実施の形態の終了処理を説明するシーケンス図である。
【図１３】同一実施の形態の管理サーバ３０の動作を説明するフローチャートである。
【図１４】同一実施の形態の通信側クライアント１０の動作を説明するフローチャートである。
【図１５】同一実施の形態の受信側クライアントの動作を説明するフローチャートである。
【図１６】従来におけるマルチキャストシステムの構成を示す図である。
【符号の説明】
１０ 送信側クライアント
２０ａ〜２０ｃ 受信側クライアント
３０ 管理サーバ
【発明の属する技術分野】
本発明は、マルチキャスト方式により、一つの送信ノードから複数の受信ノードへパケットを配信するマルチキャストシステムと、同マルチキャストシステムにおいてもちいられる管理サーバおよびマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
従来より、インターネットを代表とする分散パケット交換網では、パケット配信形式を宛先指定方法により幾つかに分類されている。既存のインターネットで使用されているＩＰｖ４や次世代インターネットの標準であるＩＰｖ６では、つぎの（１）項から（３）項までの都合三種類のパケット配信方式が用いられる。
【０００３】
（１）宛先が、唯一のアドレスに対応するユニキャスト方式
（２）宛先が、複数のアドレスからなるグループに対応し、それぞれのアドレスへパケットをコピーして配信するマルチキャスト方式
（３）宛先が複数のアドレスからなるグループに対応し、グループ内のいずれか一つのアドレスへパケットを配信するエニーキャスト方式
【０００４】
本発明は、（２）項のマルチキャスト方式に関するものである。このマルチキャスト方式は、同一のパケットを複数の受信ノードに同報できるため、マルチメディアデータの放送、多地点音声動画会議やネットワーク対戦型のゲーム等への応用が試みられている。
【０００５】
【従来の技術】
図１６は、従来のマルチキャストシステムの構成を示す図である。この図には、送信側クライアント１（送信ノード）と受信側クライアント２ａ〜２ｃ（受信ノードａ〜ｃ）とが、ルータ３1 〜３4 を含むネットワーク（たとえば、インターネット）を介して接続された構成が図示されている。送信側クライアント１は、コンピュータであり、ネットワークを介して受信側クライアント２ａ〜２ｃのうちあらかじめ設定されたグループに対してパケットを送信する。ビデオカメラＶは、多地点音声動画会議時に人物Ｐや背景等を撮像し、撮像データを送信側クライアント１へ出力する。
【０００６】
マルチキャストグループ管理テーブル５は、受信ノードａ〜ｃを複数組み合わせたグループを管理するテーブルでである。このマルチキャストグループ管理テーブル５において、「グループ」は、グループ名称であり、「メンバ」は、当該グループを構成する受信ノードである。
【０００７】
具体的には、グループＸは、受信ノードａ（受信側クライアント２ａ）、受信ノードｂ（受信側クライアント２ｂ）および受信ノードｃ（受信側クライアント２ｃ）から構成されている。グループＹは、受信ノードａ（受信側クライアント２ａ）および受信ノードｂ（受信側クライアント２ｂ）から構成されている。また、グループＺは、受信ノードｂ（受信側クライアント２ｂ）および受信ノードｃ（受信側クライアント２ｃ）から構成されている。これらのグループＸ〜Ｚは、パケットをマルチキャスト方式により受信ノードへ配信する際に、当該パケットの宛先情報とされる。
【０００８】
ルータ３1 〜３4 のそれぞれは、送信側クライアント１から送信されたパケットの宛先情報（グループ）を確認し、グループに応じて中継方向を動的に変化させることにより、パケットを所望のグループ内の受信ノードへ向けてルーティングする。これらのルータ３1 〜３4 には、ルーティングテーブル４1 〜４4 が予め保持されている。ルーティングテーブル４1 〜４4 は、グループＸ〜Ｚにそれぞれ対応する中継方向に関するデータからなり、ルーティング時にルータ３1 〜３4 により参照される。
【０００９】
上記構成において、たとえば、マルチキャストグループ管理テーブル５内のグループＸへパケットを送信する場合、送信側クライアント１のオペレータは、図示しないキーボードより、グループＸを構成する受信ノードａ〜ｃのそれぞれに付与されているネットワーク上のアドレスを順次入力する。これにより、送信側クライアント１は、宛先情報としてグループＸが付加されたパケットをネットワークへ送出する。
【００１０】
そして、パケットがルータ３1 に到着すると、ルータ３1 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４1 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、ルータ３2 方向（同図右矢印）および受信ノードｃ方向（同図下矢印）である。つぎに、ルータ３1 は、パケットのコピーを受信ノードｃおよびルータ３2 へ中継する。これにより、受信ノードｃ（受信側クライアント２ｃ）では、パケットが受信される。
【００１１】
一方、パケットがルータ３2 に到着すると、ルータ３2 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４2 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、ルータ３3 方向（同図右矢印）およびルータ３4 方向（同図右下矢印）である。つぎに、ルータ３2 は、パケットのコピーをルータ３3 およびルータ３4 へ中継する。
【００１２】
そして、パケットがルータ３3 に到着すると、ルータ３3 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４3 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、受信ノードａ方向（同図右矢印）である。つぎに、ルータ３3 は、パケットを受信ノードａへ中継する。これにより、受信ノードａ（受信側クライアント２ａ）では、パケットが受信される。
【００１３】
一方、パケットがルータ３4 に到着すると、ルータ３4 は、パケットの宛先情報（この場合、グループＸ）をキーとして、マルチキャストルーティングテーブル４4 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、受信ノードｂ方向（同図右下矢印）である。つぎに、ルータ３4 は、パケットを受信ノードｂへ中継する。これにより、受信ノードｂ（受信側クライアント２ｂ）では、パケットが受信される。
【００１４】
【発明が解決しようとする課題】
ところで、前述したように、従来のマルチキャストシステムにおいては、図１６に示したマルチキャストルーティングテーブル４1 〜４4 でのグループの追加、削除、変更や受信ノードの追加、削除、変更（以下、更新という）を行う場合、送信側クライアント１の送信ノード管理者（または受信ノードの受信ノード管理者）からルータ３1 〜３4 のルータ管理者に対して電話や電子メールにより、上記更新を依頼した後、ルータ管理者により追加、削除、変更が行われる。
【００１５】
しかしながら、従来のマルチキャストシステムにおいては、人手を介してグループ（受信ノード）の更新を行っているため、グループや受信ノードの数が増えるにしたがって、グループ管理に要する時間、作業コストが増大してしまうという問題があった。また、人手によるグループ管理では、グループ（受信ノード）の更新に関するミスや漏れが発生するとともに、作業量の増大に伴って更新作業が大幅に遅れる場合があるという問題もあった。
【００１６】
また、従来のマルチキャストシステムでは、受信ノードａ〜ｃがパケットを受信できる状態にあるか否かにかかわらず、マルチキャストルーティングテーブル４1 〜４4 に基づいて、機械的にパケットを中継している。したがって、ネットワーク障害等によりパケットを受信できない状態にある受信ノードが存在した場合にも、当該受信ノードへ無駄なパケットが中継されるため、その分だけネットワークのトラフィック量が増え、ネットワークの伝送効率が悪くなるという問題があった。
【００１７】
さらに、従来のマルチキャストシステムでは、マルチキャストルーティングテーブル４1 〜４4 が更新された場合、更新後のグループ（受信ノード）に関する情報が送信側クライアント１にリアルタイムで正しく伝達されない可能性が高い。これは、電話や電子メール等の手段を用いて人手を介在させて上記変更後の情報が送信側ノード管理者へ伝達されるからである。したがって、このような場合には、送信側クライアント１が更新前のグループへ無駄なパケットを送信することになるため、その分だけネットワークのトラフィック量が増え、ネットワークの伝送効率が悪くなるという問題があった。
【００１８】
また、送信側クライアント１から、あるグループへパケットをマルチキャスト送信する場合には、当該グループを構成する受信ノードのそれぞれのアドレスを一々入力しなければならないため、マルチキャスト送信のためのオペレーションが複雑であるという問題があった。
【００１９】
本発明は、上記に鑑みてなされたもので、マルチキャストのグループを容易、正確かつ迅速に管理することができるとともに、ネットワークの伝送効率の低下を防ぐことができ、しかも簡単なオペレーションによりマルチキャスト送信を行うことができるマルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２０】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、所定のマルチキャストグループに属することができる受信ノードと、マルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信する送信ノードと、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバとをネットワークを介して接続したマルチキャストシステムにおいて、前記受信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに該マルチキャストグループへの参加要求を送信し、前記管理サーバは、前記受信ノードより前記参加要求が送信された場合に、該参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶し、該マルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信し、前記送信ノードは、前記管理サーバより送信された最新の宛先リストに含まれるアドレスを指定して前記マルチキャストグループ向けのパケットを送信することを特徴とする。
【００２１】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかを管理サーバが記憶して、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、送信ノードは、管理サーバから送信されたリストに含まれる受信ノードに対してマルチキャストデータを送信する。
【００２２】
このように、請求項１にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、管理サーバが把握している情報に基づいて送信ノードがマルチキャストデータを送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００２３】
また、請求項２にかかる発明は、請求項１に記載のマルチキャストシステムにおいて、前記受信ノードは、自身が通信可能であることを示すパケットを前記管理サーバに所定の時間間隔で送信し、前記管理サーバは、所定の時間を経過しても前記受信ノードから前記パケットが送信されない場合は、前記記憶手段に該受信ノードが通信不能である旨を記憶し、前記宛先リストを生成する場合に、前記記憶手段において通信不能である旨が記憶されている受信ノードのアドレスを前記宛先リストから除外することを特徴とする。
【００２４】
この発明によれば、受信ノードから定期的に送信されるパケットの受信状況を監視することで受信ノードが通信可能な状態にあるかどうかを管理サーバが判断し、通信可能な状態にあると判断した受信ノードを宛先リストから除外するように構成したので、通信可能な状態にある受信ノードに対してマルチキャストデータが無駄に送信されることがなくなり、ネットワークの伝送効率の低下を防ぐことができる。
【００２５】
また、請求項３にかかる発明は、請求項１または２に記載のマルチキャストシステムにおいて、前記送信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに前記宛先リストの通知要求を送信し、前記管理サーバは、前記送信ノードより前記通知要求が送信された場合に、該通知要求にて指定されたアドレスをマルチキャストグループごとの通知リストに登録し、前記宛先リストを送信する場合に、該宛先リストに対応するマルチキャストグループの通知リストに登録されているアドレスに前記宛先リストを送信することを特徴とする請求項１または２に記載のマルチキャストシステムを特徴とする。
【００２６】
この発明によれば、どの送信ノードからどのマルチキャストグループの宛先リストの通知要求があったかを管理サーバが通知リストに登録し、宛先リストを送信ノードに送信する場合にこの通知リストに基づいて送信先を決定するように構成したので、マルチキャストグループに対応する送信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００２７】
また、請求項４にかかる発明は、請求項１〜３のいずれか一つに記載のマルチキャストシステムにおいて、前記送信ノードは、前記通知要求を送信するために必要なマルチキャストグループと管理サーバの指定をＵＲＬの書式で受け付けることを特徴とする。
【００２８】
この発明によれば、通知要求の送信時に、インターネット等で周知のＵＲＬという簡潔で定型化された書式をもちいて管理サーバとマルチキャストグループの指定を行うように構成したので、簡単なオペレーションにより通知要求の送信を行うことができる。
【００２９】
また、請求項５にかかる発明は、送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバであって、前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信手段と、前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録手段と、前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信手段とを備えたことを特徴とする。
【００３０】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかを管理サーバが記憶して、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、マルチキャストデータの送信先として利用させる。
【００３１】
このように、請求項５にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００３２】
また、請求項６にかかる発明は、送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理するマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信工程と、前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録工程と、前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信工程とをコンピュータに実行させることを特徴とする。
【００３３】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかをマルチキャストグループ管理プログラムが記憶手段に記憶させ、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、マルチキャストデータの送信先として利用させる。
【００３４】
このように、請求項６にかかる発明によれば、マルチキャストグループ管理プログラムが受信ノードから受信した参加要求に係る情報手段に記憶させることでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【００３５】
【発明の実施の形態】
以下、図面を参照して本発明にかかるマルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体の一実施の形態について詳細に説明する。
【００３６】
図１は、本発明にかかる一実施の形態の構成を示す図である。この図には、送信側クライアント１０（送信ノード）と受信側クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）とが、ルータ４０1 〜４０4 を含むネットワーク（たとえば、インターネット）を介して接続された構成が図示されている。送信側クライアント１０は、コンピュータであり、ネットワークを介して受信側クライアント２０ａ〜２０ｃのうちあらかじめ設定されたグループに対してパケットを送信する。なお、同図には、送信側クライアント１０のみ図示されているが、他の送信側クライアントもネットワークに接続されている。ビデオカメラＶは、多地点音声動画会議時に人物Ｐや背景等を撮像し、撮像データを送信側クライアント１０へ出力する。
【００３７】
受信側クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）は、複数のグループにグルーピングされており、送信側クライアント１０からマルチキャスト送信されたパケットをそれぞれ受信する。これらの受信側クライアント２０ａ〜２０ｃ（受信ノードａ〜ｃ）のそれぞれには、ネットワーク上のアドレスが付与されている。また、受信側クライアント２０ａ〜２０ｃのそれぞれは、パケットを受信することができるか否かというネットワーク状態を監視する監視機能、監視結果を管理サーバ３０へ通知するネットワーク状態通知機能を備えている。
【００３８】
なお、同図には、受信側クライアントとして受信側クライアント２０ａ〜２０ｃが図示されているが、これら以外にも図示しない受信側クライアントが多数ネットワークに接続されている。
【００３９】
管理サーバ３０は、ネットワークに接続されており、マルチキャストグループ管理テーブル５０を管理する。このマルチキャストグループ管理テーブル５０は、たとえば、受信ノードａ〜ｃを複数組み合わせたグループを管理するテーブルである。このマルチキャストグループ管理テーブル５０において、「グループ」は、グループ名称であり、「メンバ」は、当該グループを構成する受信ノードである。
【００４０】
同図に示した例では、グループＸは、受信ノードａ（受信側クライアント２０ａ）、受信ノードｂ（受信側クライアント２０ｂ）および受信ノードｃ（受信側クライアント２０ｃ）から構成されている。グループＹは、受信ノードａ（受信側クライアント２０ａ）および受信ノードｂ（受信側クライアント２０ｂ）から構成されている。また、グループＺは、受信ノードｂ（受信側クライアント２０ｂ）および受信ノードｃ（受信側クライアント２０ｃ）から構成されている。これらのグループＸ〜Ｚは、パケットをマルチキャスト方式により受信ノードへ配信する際に、当該パケットの宛先情報とされる。
【００４１】
ここで、実際には、マルチキャストグループ管理テーブル５０は、図２（ａ）に示したようなデータベースから構成されている。同図に示したデータベースは、マルチキャストグループ管理テーブル５０のグループＸに対応しており、「受信ノード名」、「受信ノードのアドレス」、「ネットワーク状態」および「タイムアウト時刻」というデータからなる。「受信ノード名」は、グループＸを構成する受信ノードの名称であり、ｎｏｄｅＡ〜Ｃである。これらのｎｏｄｅＡ〜Ｃは、図１に示した受信ノードａ〜ｃに対応している。
【００４２】
「受信ノードのアドレス」は、それぞれの受信ノードに付与されたネットワーク上のアドレスである。「ネットワーク状態」は、受信ノードがパケットを受信できる状態にあるか否かを示すフラグである。すなわち、「ネットワーク状態」に「オフライン」フラグがたっている場合には、当該受信ノード（この場合、図１に示した受信ノードｂ）がパケットを受信できない状態にあることを意味している。一方、「ネットワーク状態」にいずれのフラグもたっていない場合には、当該受信ノードがパケットを受信できる状態にあることを意味している。「タイムアウト時刻」は、当該受信ノードがパケットを受信できない状態にあることを判断するための時刻である。
【００４４】
つぎに、図６〜図８に示したシーケンス図を参照して一実施の形態の動作について説明する。図６は一実施の形態の初期化処理を説明するシーケンス図であり、図７は一実施の形態の終了処理を説明するシーケンス図であり、図８は一実施の形態のネットワーク監視動作を説明するシーケンス図である。図６に示したステップＳＡ１では、管理サーバの初期化処理が実行される。
【００４５】
すなわち、ステップＳＡ１では、図１に示した管理サーバ３０は、マルチキャストグループを設定するための空のデータベース、後述する通知リストを作成する。ここで作成されるデータベースは、図２（ａ）に示したフォーマットのものである。また、作成された空のデータベースには、いずれのデータも存在していない。
【００４６】
つぎに、ステップＳＡ２〜ステップＳＡ８までは、送信側クライアントの初期化処理が実行される。すなわち、ステップＳＡ２では、送信側クライアント１０は、マルチキャスト方式によるパケットの配信を実現するためのアプリケーションを初期化する。ここで、送信側クライアント１０のオペレータは、アクセス先の管理サーバ３０、マルチキャストグループ管理テーブル５０におけるグループ等を指定するためのＵＲＬ（Uniform Resource Locator）を入力する。
【００４７】
ここで、図５（ａ）〜（ｅ）を参照してＵＲＬ指定の例について説明する。これらの図に示したＵＲＬでは、「プロトコル」、「ユーザ名」、「パスワード」、「ホスト名」、「ポート番号」および「グループ名」を指定することができる。上記「ホスト名」は、管理サーバ３０のネットワーク上の名称であり、「グループ名」は、マルチキャストグループ管理テーブル５０（図１参照）におけるグループの名称である。すなわち、ＵＲＬにより、少なくとも管理サーバ３０およびグループを指定することが可能である。
【００４８】
図６に戻り、ステップＳＡ３では、送信側クライアント１０は、入力されたＵＲＬを解析し、「プロトコル」、「パスワード」、「ユーザ名」、「ホスト名」、「ポート番号」および「グループ名」を特定する。この場合、少なくとも「ホスト名」（管理サーバ３０の名称）および「グループ名」が特定されたものとする。ステップＳＡ４では、送信側クライアント１０は、ネットワークを介して管理サーバ３０にアクセスし、図４（ａ）に示した通知リストへ自身のネットワーク上のアドレス（たとえば、「２０２．３３．９６．４２」）を追加するように要求する。
【００４９】
ここで、同図に示した通知リストは、図１に示したマルチキャストグループ管理テーブル５０を構成する、たとえば、図３（ａ）に示したデータベース（グループ情報）を通知すべき送信側クライアントのアドレスを表すリストであり、管理サーバ３０に保持されている。ステップＳＡ５では、管理サーバ３０は、図４（ａ）に示した通知リストに、管理サーバ３０のアドレス「２０２．３３．９６．４２」（図４（ｂ）参照）を追加する。
【００５０】
ステップＳＡ６では、送信側クライアント１０は、管理サーバ３０に対して、ＵＲＬ指定された「グループ名」に対応するグループ情報、すなわちデータベース（図２（ａ）参照）の送信を要求する。ここでは、図２に示したデータベースには、いずれのデータも存在しない。
【００５１】
これにより、ステップＳＡ７では、管理サーバ３０は、図２（ａ）に示したフォーマットの空のデータベース（グループ情報）を送信側クライアント１０へ送信する。ステップＳＡ８では、送信側クライアント１０は、受信した空のデータベースから、図２（ｂ）に示したようなフォーマットの宛先リストを生成する。この場合、宛先リストには、いずれのデータも存在しない。宛先リストは、マルチキャスト送信により送信側クライアント１０から送信すべきパケットの宛先（受信ノードのアドレス）のリストである。
【００５２】
つぎに、ステップＳＡ９〜ステップＳＡ１４までは、受信側クライアントの初期化処理が実行される。すなわち、ステップＳＡ９では、受信側クライアント（受信側クライアント２０ａ〜２０ｃ、その他の受信側クライアントのうちいずれか一つまたは二つ以上）は、マルチキャスト方式によるパケットの受信を実現するためのアプリケーションを初期化する。ここで、受信側クライアントのオペレータは、送信側クライアント１０のオペレータと同様にして、アクセス先の管理サーバ３０、マルチキャストグループ管理テーブル５０におけるグループ等を指定するためのＵＲＬ（図５（ａ）〜（ｅ）参照）を入力する。
【００５３】
ステップＳＡ１０では、受信側クライアントは、入力されたＵＲＬを解析し、「プロトコル」、「パスワード」、「ユーザ名」、「ホスト名」、「ポート番号」および「グループ名」を特定する。この場合、少なくとも「ホスト名」（管理サーバ３０の名称）および「グループ名」が特定されたものとする。ステップＳＡ１２では、受信側クライアントは、ネットワークを介して管理サーバ３０にアクセスし、ステップＳＡ１で作成されたデータベースに自身のネットワーク上のアドレスを登録するように要求する。すなわち、受信側クライアントは、マルチキャストグループ管理テーブル５０におけるグループに自身のアドレスを登録するための要求を出す。
【００５４】
ステップＳＡ１１では、管理サーバ３０は、ステップＳＡ１で作成されたデータベースに当該受信側クライアントの「ノード名」、「受信ノードのアドレス」、「ネットワーク状態」および「タイムアウト時刻」を登録する。たとえば、図２（ｃ）に示したように、ｎｏｄｅＤの受信側クライアントからグループへの登録要求があった場合、データベースには、ｎｏｄｅＤに関する「ノード名」、「受信ノードのアドレス」、「ネットワーク状態」、「タイムアウト時刻」が登録される。
【００５５】
ステップＳＡ１３では、管理サーバ３０は、ステップＳＡ５の通知リスト（図４（ｂ）参照）に基づいて、通知リストに存在するアドレス（送信側クライアント１０）へ、ステップＳＡ１１で登録されたデータベースを新しいグループ情報として自動通知する。この場合、図２（ａ）に示したデータベース（グループ情報）が少なくとも送信側クライアント１０に通知されたものとする。なお、データベースは、送信側クライアント１０以外の送信側クライアントであって宛先リストにアドレスが記載されているものにも送信される。
【００５６】
これにより、ステップＳＡ１４では、送信側クライアント１０は、図２（ａ）に示したデータベースから、図２（ｂ）に示した宛先リストを作成する。この宛先リストは、上記データベースで「ネットワーク状態」の欄に「オフライン」フラグがたっていない受信ノードのアドレスからなる。すなわち、宛先リストのアドレスは、パケットを正常に受信可能な受信ノードに対応している。図２（ｂ）に示した例では、宛先リストには、図２（ａ）に示したｎｏｄｅＡ（受信ノードａ：図１参照）のアドレス、およびｎｏｄｅＣ（受信ノードｃ：図１参照）のアドレスが含まれている。なお、図２（ｃ）に示したデータベースからは、図２（ｄ）に示した宛先リストが生成され、図２（ｅ）に示したデータベースからは、図２（ｆ）に示した宛先リストが生成される。
【００５７】
ステップＳＡ１５では、送信側クライアント１０は、図２（ｂ）に示した宛先リストに基づいて、図１に示した受信ノードａおよび受信ノードｃに対してパケットを送信する。また、ステップＳＡ１３で新しいグループ情報が自動通知された他の送信側クライアント（図示略）も、受信ノードａおよびｃに対してパケットを送信する。この場合には、多対多の通信が実現される。
【００５８】
つぎに、図７を参照して終了処理について説明する。同図において、マルチキャスト送信を中止する場合、送信側クライアント１０は、ステップＳＢ１〜ステップＳＢ４までの終了処理を実行する。すなわち、ステップＳＢ２では、送信側クライアント１０は、図４（ｂ）に示した通知リストからの自身のアドレス（「２０２．３３．９６．４２」）の削除を管理サーバ３０へ要求する。
【００５９】
これにより、ステップＳＢ１では、管理サーバ３０は、上記アドレスを通知リストから削除する。これにより、通知リストは、図４（ａ）に示したものとなる。なお、他の送信側クライアントからアドレス（たとえば、「２０２．２３９．１６２．３４」）の削除要求があった場合、管理サーバ３０は、図４（ｂ）に示した通知リストから上記アドレスを削除する。この場合、通知リストは、図４（ｃ）に示したものとなる。
【００６０】
ステップＳＢ３では、管理サーバ３０は、送信側クライアント１０へのグループ情報（データベース）の自動送信を停止する。ステップＳＢ４では、送信側クライアント１０は、アプリケーションの終了処理を実行する。これにより、ステップＳＢ５では、マルチキャスト送信が中止される。
【００６１】
また、受信側クライアントがパケットの受信を終了する場合、ステップＳＢ６では、受信側クライアントは、データベース（たとえば、図２（ａ）参照）に登録されている自身に関するデータを削除するように管理サーバ３０へ要求する。これにより、ステップＳＢ７では、管理サーバ３０は、データベースから当該受信側クライアントに関するデータを削除する。
【００６２】
すなわち、当該受信側クライアントは、マルチキャストグループ管理テーブル５０のグループから除外されたのである。ステップＳＢ８では、受信側クライアントは、アプリケーションの終了処理を実行する。また、ステップＳＢ９では、管理サーバ３０は、データベースおよび通知リストを削除することにより、終了処理を実行する。
【００６３】
つぎに、図８を参照してネットワーク監視動作について説明する。図１に示したネットワークが正常である場合、ステップＳＣ１〜ステップＳＣ６までの処理が実行される。すなわち、ステップＳＣ１では、受信側クライアントは、管理サーバ３０に対してタイムアウト延長要求を出す。ここでタイムアウト延長要求とは、図２（ａ）に示したデータベースにおける「タイムアウト時刻」の延長を要求することをいう。また、受信側クライアントは、一定時間毎（たとえば、３０秒毎）にタイムアウト延長要求を管理サーバ３０に対して出す。
【００６４】
ステップＳＣ２では、管理サーバ３０は、タイムアウト延長要求を受けると、データベースのタイムアウト時刻をたとえば１分後の時刻に再設定する。ステップＳＣ３では、送信側クライアント１０は、マルチキャスト通信を継続する。そして、ステップＳＣ１でタイムアウト要求を出した時刻から３０秒経過すると、ステップＳＣ４では、当該受信側クライアントは、管理サーバ３０に対して再びタイムアウト延長要求を出す。ステップＳＣ５では、管理サーバ３０は、タイムアウト延長要求を受けると、データベースのタイムアウト時刻をたとえば１分後の時刻に再設定する。ステップＳＣ６では、送信側クライアント１０は、マルチキャスト通信を継続する。以後、上述した動作が繰り返される。
【００６５】
ここでネットワーク故障が発生すると、ステップＳＣ７では、上記受信側クライアントからのタイムアウト延長要求に失敗する。これは、データベース（図２（ａ）参照）の「タイムアウト時刻」を経過しても、受信側クライアントからのタイムアウト延長要求がない場合である。ステップＳＣ８では、管理サーバ３０は、たとえば、図２（ｅ）に示したように、ｎｏｄｅＡおよびＤからのタイムアウト延長要求が無かった場合、ｎｏｄｅＡおよびＤに対応する「ネットワーク状態」の欄にオフラインのフラグを設定する。すなわち、同図に示したデータベースからは、ｎｏｄｅＣのみがパケットの受信が可能な状態にあることがわかり、その他のｎｏｄｅＡ、ｎｏｄｅＢおよびｎｏｄｅＤがパケットの受信が出来ない状態（オフライン）にあることがわかる。
【００６６】
ステップＳＣ９では、管理サーバ３０は、たとえば、図２（ｅ）に示したデータベース（グループ情報）を、宛先リストに基づいて、たとえば、送信側クライアント１０へ自動通知する。これにより、ステップＳＣ１０では、送信側クライアント１０は、図２（ｆ）に示した宛先リストを生成する。ステップＳＣ１１では、送信側クライアント１０は、タイムアウト延長要求に失敗した当該受信側クライアントに対するマルチキャスト送信を停止する。
【００６７】
そして、ネットワークが回復すると、ステップＳＣ１２では、ステップＳＣ７でタイムアウト延長要求に失敗した受信側クライアントは、管理サーバ３０に対するタイムアウト延長要求を再開する。これにより、ステップＳＣ１３では、管理サーバ３０は、データベース（図２（ｅ）参照）から、当該受信側クライアントに対応するオフラインのフラグを消去する。
【００６８】
ステップＳＣ１４では、管理サーバ３０は、オフラインのフラグが消去されたデータベース（グループ情報）を、宛先リストに基づいて、たとえば、送信側クライアント１０へ自動通知する。これにより、ステップＳＣ１５では、送信側クライアント１０は、宛先リストを生成する。この宛先リストには、オフラインのフラグが消去された当該受信側クライアントのアドレスが含まれている。これにより、ステップＳＣ１６では、送信側クライアント１０は、タイムアウト延長要求を再開した当該受信側クライアントに対するマルチキャスト送信を再開する。
【００６９】
なお、前述した図６では、送信側クライアントの初期化処理が受信側クライアントの初期化処理より先に実行される場合について説明したが、これとは逆に受信側クライアントの初期化処理が送信側クライアントの初期化処理より先に実行された場合には、図９に示したシーケンスで各処理が実行される。図９において、ステップＳＤ１は、ステップＳＡ１（図６参照）に対応しており、ステップＳＤ２〜ステップＳＤ５は、ステップＳＡ９〜ステップＳＡ１２に対応している。また、図９に示したステップＳＤ６〜ステップＳＤ１３は、図６に示したステップＳＡ２〜ステップＳＡ８およびステップＳＡ１５に対応している。
【００７０】
同様にして、前述した図７では送信側クライアントの終了処理が受信側クライアントの終了処理より先に実行される場合について説明したが、これとは逆に受信側クライアントの終了処理が送信側クライアントの終了処理より先に実行された場合には、図１０に示したシーケンスで各処理が実行される。図１０において、ステップＳＥ１およびステップＳＥ２は、図７に示したステップＳＢ６およびステップＳＢ７に対応している。
【００７１】
ステップＳＥ３では管理サーバ３０から送信側クライアント１０へ新しいグループ情報が自動通知され、ステップＳＥ４では宛先リストが生成される。これにより、ステップＳＥ６では、マルチキャスト送信が停止される。また、図１０に示したステップＳＥ８〜ステップＳＥ１２は、図７に示したステップＳＢ１〜ステップＳＢ５およびステップＳＢ９に対応している。
【００７２】
図１１は、二つの受信側クライアント（１）および（２）がある場合の初期化処理を説明するシーケンス図である。図１１に示したステップＳＦ１〜ステップＳＦ５は、図９に示したステップＳＤ１〜ステップＳＤ５に対応している。ただし、図１１に示したステップＳＦ１〜ステップＳＦ５までの処理は、受信側クライアント（１）の初期化処理である。また、図１１に示したステップＳＦ６〜ステップＳＦ１３は、図９に示したステップＳＤ６〜ステップＳＤ１３に対応している。だだし、ステップＳＦ１３の処理は、受信側クライアント（１）に対してマルチキャスト送信を開始する処理である。
【００７３】
さらに、図１１に示したステップＳＦ１４〜ステップＳＦ２０は、受信側クライアント（２）の初期化処理である。ステップＳＦ１４〜ステップＳＦ１７までの処理は、ステップＳＦ２〜ステップＳＦ５の処理と同様である。ステップＳＦ１８では管理サーバ３０から受信側クライアント（２）を含む新しいグループ情報が送信側クライアント１０に自動通知される。ステップＳＦ１９では、送信側クライアント１０は、宛先リストを生成する。ステップＳＦ２０では、送信側クライアント１０は、受信側クライアント（１）および（２）へのマルチキャスト送信を開始する。
【００７４】
図１２は、二つの受信側クライアント（１）および（２）がある場合の終了処理を説明するシーケンス図である。図１２に示したステップＳＧ１〜ステップＳＧ６は、図１０に示したステップＳＥ１〜ステップＳＥ６に対応している。ただし、図１１に示したステップＳＧ２〜ステップＳＧ６までの処理は、受信側クライアント（１）の終了処理である。また、ステップＳＧ６では、受信側クライアント（１）に対するマルチキャスト通信が停止され、受信側クライアント（２）に対するマルチキャスト通信が継続される。
【００７５】
また、図１２に示したステップＳＧ７〜ステップＳＧ１１は、図１０に示したステップＳＥ７〜ステップＳＥ１１に対応している。さらに、図１２に示したステップＳＧ１２〜ステップＳＧ１４は、図１０に示したステップＳＥ１、ステップＳＥ２およびステップＳＥ５に対応している。ただし、ステップＳＧ１２〜ステップＳＧ１４までの処理は、受信側クライアント（２）の終了処理である。図１２に示したステップＳＧ１５は、図１０に示したステップＳＥ１２に対応している。
【００７６】
つぎに、図１３〜図１５に示したフローチャートを参照して管理サーバ３０、送信側クライアント１０および受信側クライアントの動作について説明する。これらの動作は、前述した図６〜図１２までのシーケンスに対応する動作である。図１３に示したステップＳＨ１では、管理サーバ３０は、空のデータベースおよび通知リストを作成する（ステップＳＡ１：図６参照）。ステップＳＨ２では、管理サーバ３０は、送信側クライアント１０または受信側クライアントからリクエストが到着しているか否かを判断する。
【００７７】
この場合、ステップＳＨ２の判断結果が「Ｎｏ」であるものとすると、ステップＳＨ３では、管理サーバ３０は、タイムアウトした受信ノードをデータベースから検索する。ステップＳＨ４では、管理サーバ３０は、タイムアウトした受信ノードがあったか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＨ２の処理を実行する。一方、ステップＳＨ４の判断結果が「Ｙｅｓ」である場合、ステップＳＨ５では、管理サーバ３０は、データベースにオフラインのフラグを設定する（ステップＳＣ８：図８参照）。
【００７８】
ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノード（送信側クライアント１０）にデータベースの内容を通知する（ステップＳＣ９：図８参照）。ステップＳＨ１７では、管理サーバ３０は、処理を継続するか否かを判断し、この判断結果が「Ｙｅｓ」である場合、ステップＳＨ２の処理を実行する。
【００７９】
ステップＳＨ２では、管理サーバ３０は、リクエストが到着しているか否かを判断する。この場合、判断結果が「Ｙｅｓ」であるものとする。ステップＳＨ６では、管理サーバ３０は、リクエストの内容を判断する。ここで、リクエストの内容が送信側クライアント１０からのグループ情報の問い合わせ（ステップＳＡ６：図６参照）である場合、ステップＳＨ７では、管理サーバ３０は、データベース（グループ情報）を送信側クライアント１０へ送信する（ステップＳＡ７：図６参照）。
【００８０】
また、リクエストの内容が受信側クライアントからのグループ登録解除（ステップＳＥ１：図１０参照）である場合、ステップＳＨ８では、管理サーバ３０は、データベースから受信ノードに関する情報を削除する（ステップＳＥ２：図１０参照）。ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノードにデータベースの内容を通知する（ステップＳＥ３：図１０参照）。
【００８１】
また、リクエストの内容が受信側クライアントからのグループ登録である場合（ステップＳＡ１２：図６参照）、ステップＳＨ１０では、管理サーバ３０は、データベースに受信ノード（ステップＳＡ１１：図６参照）を追加する。ステップＳＨ１１では、タイムアウト時刻の設定を行う。ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノードにデータベースの内容を通知する（ステップＳＡ１３：図６参照）。
【００８２】
また、リクエストの内容が受信側クライアントからのタイムアウト延長（ステップＳＣ１：図８参照）である場合、ステップＳＨ１２では、管理サーバ３０は、タイムアウト時刻を再設定する（ステップＳＣ２：図８参照）。ステップＳＨ１３では、管理サーバ３０は、データベース（図２（ａ）参照）にオフラインのフラグがあるか否かを判断する。この判断結果が「Ｙｅｓ」である場合、ステップＳＨ１４では、管理サーバ３０は、上記オフラインのフラグを削除する（ステップＳＣ１３：図８参照）。ステップＳＨ９では、管理サーバ３０は、通知リストに登録されている送信ノードにデータベースの内容を通知する（ステップＳＣ１４：図８参照）。
【００８３】
また、リクエストの内容が通知リストの登録の解除である場合（ステップＳＢ２：図７参照）、ステップＳＨ１５では、管理サーバ３０は、通知リストから送信ノードのアドレスを削除する（ステップＳＢ１：図７参照）。また、リクエストの内容が送信ノードからの通知リストの登録である場合（ステップＳＡ４：図６参照）である場合、ステップＳＨ１６では、管理サーバ３０は、通知リストに送信ノードのアドレスを追加する（ステップＳＡ５：図６参照）。ステップＳＨ１７の判断結果が「Ｎｏ」である場合、ステップＳＨ１８では、管理サーバ３０は、データベースと通知リストを削除する（ステップＳＢ９：図７参照）。
【００８４】
つぎに、図１４を参照して送信側クライアント１０の動作について説明する。図１４に示したステップＳＩ１では、送信側クライアント１０は、マルチキャスト通信用のアプリケーションを初期化する（ステップＳＤ６：図９参照）。ステップＳＩ２では、送信側クライアント１０は、入力されたＵＲＬを解析する（ステップＳＤ７：図９参照）。ステップＳＩ３では、送信側クライアント１０は、管理サーバ３０に対して、通知リストへのアドレスの追加を要求する（ステップＳＤ８：図９参照）。
【００８５】
ステップＳＩ４では、送信側クライアント１０は、グループ情報（データベース）の送信要求を管理サーバ３０へ出した後、グループ情報（データベース）を取得する（ステップＳＤ１１：図９参照）。ステップＳＩ５では、送信側クライアント１０は、グループ情報からオフラインの受信ノードを取り除き、宛先リストを作成する（ステップＳＤ１２：図９参照）。ステップＳＩ６では、送信側クライアント１０は、宛先リストにしたがってマルチキャストデータグラム（パケット）の送信を開始する（ステップＳＤ１３：図９参照）。
【００８６】
ステップＳＩ７では、送信側クライアント１０は、処理を継続するか否かを判断する。この判断結果が「Ｙｅｓ」である場合、ステップＳＩ８では、送信側クライアント１０は、新しいグループ情報（データベース）が管理サーバ３０から届いているか否かを判断する。この判断結果が「Ｙｅｓ」である場合、送信側クライアント１０は、ステップＳＩ５の処理を実行する。一方、ステップＳＩ８の判断結果が「Ｎｏ」である場合、送信側クライアント１０は、ステップＳＩ６の処理を実行する。
【００８７】
そして、ステップＳＩ７の判断結果が「Ｎｏ」になると、ステップＳＩ９では、送信側クライアント１０は、管理サーバ３０に対して通知リストからの削除を要求する（ステップＳＥ７：図１０参照）。ステップＳＩ１０では、送信側クライアント１０は、アプリケーションを終了する（ステップＳＥ１０：図１０参照）。
【００８８】
つぎに、図１５を参照して受信側クライアント（受信側クライアント２０ａ〜２０ｃ）の動作について説明する。図１５に示したステップＳＪ１では、受信側クライアントは、マルチキャスト受信用のアプリケーションを初期化する（ステップＳＡ９：図６参照）。ステップＳＪ２では、受信側クライアントは、入力されたＵＲＬを解析する（ステップＳＡ１０：図６参照）。ステップＳＪ３では、受信側クライアントは、管理サーバ３０に対して、グループへの登録を要求する（ステップＳＡ１２：図６参照）。
【００８９】
ステップＳＪ４では、受信側クライアントは、送信側クライアント１０からのマルチキャストデータグラム（パケット）を受信する。ステップＳＪ５では、受信側クライアントは、前回のタイムアウト延長要求時から３０秒経過したか否かを判断する。この判断結果が「Ｎｏ」である場合、ステップＳＪ７では、受信側クライアントは、処理を継続するか否かを判断する。この判断結果が「Ｙｅｓ」である場合、受信側クライアントは、ステップＳＪ４の処理を実行する。
【００９０】
そして、ステップＳＪ５の判断結果が「Ｙｅｓ」になると、ステップＳＪ６では、受信側クライアントは、管理サーバ３０にタイムアウト延長を要求する（ステップＳＣ１：図８参照）。また、ステップＳＪ７の判断結果が「Ｎｏ」である場合、ステップＳＪ８では、受信側クライアントは、管理サーバ３０に対してグループからの登録を解除することを要求する（ステップＳＢ６：図７参照）。ステップＳＪ９では、受信側クライアントは、アプリケーションを終了する（ステップＳＢ８：図７参照）。
【００９１】
以上説明したように、一実施の形態によれば、従来の人手によらず管理サーバ３０によりデータベース（グループ情報）を管理し、グループが更新された場合や送信ノードから通知要求された場合に更新後のグループ情報を送信ノードに通知するようにしたので、マルチキャストのグループを容易、正確かつ迅速に管理することができる。
【００９２】
また、一実施の形態によれば、管理サーバ３０により、受信ノードａ〜ｃの受信状態（ネットワーク状態）を監視し、パケットを受信できない受信ノードがある場合、グループから当該受信ノードが除外されるため、不必要に当該受信ノードに対してパケットが送信されないことから、ネットワークの伝送効率の低下を防ぐことができる。
【００９３】
また、一実施の形態によれば、通知リスト内の複数の送信ノードに対して変更後のグループ情報を通知するようにしたので、複数の送信ノードとグループとの間で多対多でのマルチキャスト通信を容易に実現することができる。
【００９４】
また、一実施の形態によれば、インターネット等で周知のＵＲＬという極めて簡単な指定方法によりグループ情報等を指定していることから、簡単なオペレーションによりマルチキャスト送信を行うことができる。
【００９５】
以上本発明にかかる一実施の形態について図面を参照して詳述してきたが、具体的な構成例はこの一実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。たとえば、前述した一実施の形態においては、管理サーバ３０の機能を実現するためのマルチキャストグループ管理プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたマルチキャストグループ管理プログラムをコンピュータに読み込ませ、実行することによりグループ管理を行うようにしてもよい。
【００９６】
コンピュータは、上記マルチキャストグループ管理プログラムを実行するＣＰＵと、キーボード、マウス等の入力装置と、各種データを記憶するＲＯＭ（Read Only Memory）と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）と、記録媒体からマルチキャストグループ管理プログラムを読み取る読取装置と、ディスプレイ、プリンタ等の出力装置と、装置各部を接続するバスとから構成されている。
【００９７】
ＣＰＵは、読取装置を経由して記録媒体に記録されているマルチキャストグループ管理プログラムを読み込んだ後、マルチキャストグループ管理プログラムを実行することにより、前述した処理を実行する。なお、記録媒体には、光ディスク、フロッピーディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【００９８】
【発明の効果】
以上説明したように、請求項１にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、管理サーバが把握している情報に基づいて送信ノードがマルチキャストデータを送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【００９９】
また、請求項２にかかる発明によれば、受信ノードから定期的に送信されるパケットの受信状況を監視することで受信ノードが通信可能な状態にあるかどうかを管理サーバが判断し、通信可能な状態にあると判断した受信ノードを宛先リストから除外するように構成したので、通信可能な状態にある受信ノードに対してマルチキャストデータが無駄に送信されることがなくなり、ネットワークの伝送効率の低下を防ぐことができるという効果を奏する。
【０１００】
また、請求項３にかかる発明によれば、どの送信ノードからどのマルチキャストグループの宛先リストの通知要求があったかを管理サーバが通知リストに登録し、宛先リストを送信ノードに送信する場合にこの通知リストに基づいて送信先を決定するように構成したので、マルチキャストグループに対応する送信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【０１０１】
また、請求項４にかかる発明によれば、通知要求の送信時に、インターネット等で周知のＵＲＬという簡潔で定型化された書式をもちいて管理サーバとマルチキャストグループの指定を行うように構成したので、簡単なオペレーションにより通知要求の送信を行うことができるという効果を奏する。
【０１０２】
また、請求項５にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【０１０３】
また、請求項６にかかる発明によれば、マルチキャストグループ管理プログラムが受信ノードから受信した参加要求に係る情報を記憶手段に記憶させることでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明にかかる一実施の形態の構成を示す図である。
【図２】同一実施の形態におけるデータベースおよび宛先リストを示す図である。
【図３】同一実施の形態におけるデータベースおよび宛先リストを示す図である。
【図４】同一実施の形態における通知リストを示す図である。
【図５】同一実施の形態におけるＵＲＬ指定の例を示す図である。
【図６】同一実施の形態の初期化処理を説明するシーケンス図である。
【図７】同一実施の形態の終了処理を説明するシーケンス図である。
【図８】同一実施の形態のネットワーク監視動作を説明するシーケンス図である。
【図９】同一実施の形態の初期化処理を説明するシーケンス図である。
【図１０】同一実施の形態の終了処理を説明するシーケンス図である。
【図１１】同一実施の形態の初期化処理を説明するシーケンス図である。
【図１２】同一実施の形態の終了処理を説明するシーケンス図である。
【図１３】同一実施の形態の管理サーバ３０の動作を説明するフローチャートである。
【図１４】同一実施の形態の通信側クライアント１０の動作を説明するフローチャートである。
【図１５】同一実施の形態の受信側クライアントの動作を説明するフローチャートである。
【図１６】従来におけるマルチキャストシステムの構成を示す図である。
【符号の説明】
１０ 送信側クライアント
２０ａ〜２０ｃ 受信側クライアント
３０ 管理サーバ
Claims (6)
- 所定のマルチキャストグループに属することができる受信ノードと、マルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信する送信ノードと、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバとをネットワークを介して接続したマルチキャストシステムにおいて、
前記受信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに該マルチキャストグループへの参加要求を送信し、
前記管理サーバは、前記受信ノードより前記参加要求が送信された場合に、該参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶し、該マルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信し、
前記送信ノードは、前記管理サーバより送信された最新の宛先リストに含まれるアドレスを指定して前記マルチキャストグループ向けのパケットを送信することを特徴とするマルチキャストシステム。 - 前記受信ノードは、自身が通信可能であることを示すパケットを前記管理サーバに所定の時間間隔で送信し、
前記管理サーバは、所定の時間を経過しても前記受信ノードから前記パケットが送信されない場合は、前記記憶手段に該受信ノードが通信不能である旨を記憶し、前記宛先リストを生成する場合に、前記記憶手段において通信不能である旨が記憶されている受信ノードのアドレスを前記宛先リストから除外することを特徴とする請求項１に記載のマルチキャストシステム。 - 前記送信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに前記宛先リストの通知要求を送信し、
前記管理サーバは、前記送信ノードより前記通知要求が送信された場合に、該通知要求にて指定されたアドレスをマルチキャストグループごとの通知リストに登録し、前記宛先リストを送信する場合に、該宛先リストに対応するマルチキャストグループの通知リストに登録されているアドレスに前記宛先リストを送信することを特徴とする請求項１または２に記載のマルチキャストシステム。 - 前記送信ノードは、前記通知要求を送信するために必要なマルチキャストグループと管理サーバの指定をＵＲＬの書式で受け付けることを特徴とする請求項１〜３のいずれか一つに記載のマルチキャストシステム。
- 送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバであって、
前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信手段と、
前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録手段と、
前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信手段と
を備えたことを特徴とする管理サーバ。 - 送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理するマルチキャストグループ管理 プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信工程と、
前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録工程と、
前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信工程と
をコンピュータに実行させるためのマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35511299A JP3782272B2 (ja) | 1999-12-14 | 1999-12-14 | マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35511299A JP3782272B2 (ja) | 1999-12-14 | 1999-12-14 | マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001168861A JP2001168861A (ja) | 2001-06-22 |
| JP3782272B2 true JP3782272B2 (ja) | 2006-06-07 |
Family
ID=18442013
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP35511299A Expired - Fee Related JP3782272B2 (ja) | 1999-12-14 | 1999-12-14 | マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3782272B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7075904B1 (en) * | 2001-11-16 | 2006-07-11 | Sprint Spectrum L.P. | Method and system for multicasting messages to select mobile recipients |
| US8688853B2 (en) * | 2001-12-21 | 2014-04-01 | Agere Systems Llc | Method and apparatus for maintaining multicast lists in a data network |
| AU2003296056A1 (en) | 2002-12-20 | 2004-07-14 | Matsushita Electric Industrial Co., Ltd. | Information management system |
| JP2004303041A (ja) * | 2003-03-31 | 2004-10-28 | Tm T & D Kk | データ通信方法、データ通信システムおよびそのためのプログラム |
| JP2005197844A (ja) * | 2003-12-26 | 2005-07-21 | Kenwood Corp | 業務用無線ネットワークにおける擬似マルチキャスト通信システムおよびその方法 |
| CN103905583B (zh) * | 2014-04-25 | 2017-06-23 | 国家电网公司 | 以太网无源光网络控制方法、系统及olt |
| JP6919213B2 (ja) * | 2017-02-15 | 2021-08-18 | 日本電気株式会社 | 通信機、通信システム、通信方法、およびプログラム |
| KR102137914B1 (ko) * | 2019-11-20 | 2020-07-24 | 전자부품연구원 | IoT/M2M 플랫폼에서 그룹 통지 취합 방법 |
-
1999
- 1999-12-14 JP JP35511299A patent/JP3782272B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001168861A (ja) | 2001-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4077330B2 (ja) | データ生成装置 | |
| TWI268065B (en) | Method and apparatus for managing multicast groups in a system area network | |
| US7450580B2 (en) | Application layer multicast system and intermediate node therefor | |
| JP4803562B2 (ja) | アクセスネットワークのための経路指定装置、経路指定モジュールおよび経路指定方法 | |
| KR100268194B1 (ko) | 혼성피어-서버통신구조를위한방법및시스템 | |
| KR100811890B1 (ko) | 인터넷 시스템에서 서비스 플로우를 보장하는 애니캐스트라우팅 방법 및 장치 | |
| EP1890424A1 (en) | A system and method for achieving the data communication | |
| WO2008064591A1 (fr) | Procédé, système et dispositif pour augmenter la capacité d'un système de services de messagerie multimédia | |
| JP2000307657A (ja) | ホスト・クラスタのためのネットワーク・ディスパッチャを利用するデータ伝送システムにおけるルータ監視システム | |
| JP2007013684A (ja) | 通信システム、サーバ装置及びデータ端末装置 | |
| JP2003188903A (ja) | ルータ装置、端末装置、通信システム及びルーティング方法 | |
| JP3782272B2 (ja) | マルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| US20080294785A1 (en) | Communication system, node device, node process program and a message transmitting and receiving method | |
| JP4574684B2 (ja) | 通信ネットワークシステム及びこれを用いたメッセージルーティング方法 | |
| JP4391960B2 (ja) | リソース管理装置、システムおよび方法 | |
| JP4782799B2 (ja) | 通信ネットワークシステム及びこれを用いたサービス間のデータ送受信方法。 | |
| KR100684166B1 (ko) | 멀티캐스트 통신 네트워크 시스템 및 이를 이용한 데이터송/수신 방법 | |
| KR100333679B1 (ko) | 멀티캐스트 통신 서비스 제공 시스템 및 멀티캐스트 서비스제어방법 | |
| KR100431206B1 (ko) | 고속 라우터에서 분산 포워딩을 위한 테이블 관리 방법 | |
| JP2004129159A (ja) | パケット変換方法、パケット通信システム、パケット変換装置、パケット変換プログラムおよび記録媒体 | |
| JP4352645B2 (ja) | 端末装置、中継装置、通信方法及びその通信プログラムを記録した記録媒体 | |
| JP4432626B2 (ja) | マルチキャストツリー構築システム及び方法、ネットワークノード装置並びにサーバ装置 | |
| WO2021005756A1 (ja) | コンテンツ配信システム、ユニキャストマルチキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム | |
| US7228562B2 (en) | Stream server apparatus, program, and NAS device | |
| JP3637893B2 (ja) | ネットワークアドレス変換装置の分離方式および分離方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040324 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051125 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051206 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060202 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060307 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060309 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130317 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130317 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140317 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |