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
【発明の属する技術分野】
本発明は、マルチキャスト方式により、一つの送信ノードから複数の受信ノードへパケットを配信するマルチキャストシステムと、同マルチキャストシステムにおいてもちいられる管理サーバおよびマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【0002】
従来より、インターネットを代表とする分散パケット交換網では、パケット配信形式を宛先指定方法により幾つかに分類されている。既存のインターネットで使用されているIPv4や次世代インターネットの標準であるIPv6では、つぎの(1)項から(3)項までの都合三種類のパケット配信方式が用いられる。
【0003】
(1)宛先が、唯一のアドレスに対応するユニキャスト方式
(2)宛先が、複数のアドレスからなるグループに対応し、それぞれのアドレスへパケットをコピーして配信するマルチキャスト方式
(3)宛先が複数のアドレスからなるグループに対応し、グループ内のいずれか一つのアドレスへパケットを配信するエニーキャスト方式
【0004】
本発明は、(2)項のマルチキャスト方式に関するものである。このマルチキャスト方式は、同一のパケットを複数の受信ノードに同報できるため、マルチメディアデータの放送、多地点音声動画会議やネットワーク対戦型のゲーム等への応用が試みられている。
【0005】
【従来の技術】
図16は、従来のマルチキャストシステムの構成を示す図である。この図には、送信側クライアント1(送信ノード)と受信側クライアント2a〜2c(受信ノードa〜c)とが、ルータ31 〜34 を含むネットワーク(たとえば、インターネット)を介して接続された構成が図示されている。送信側クライアント1は、コンピュータであり、ネットワークを介して受信側クライアント2a〜2cのうちあらかじめ設定されたグループに対してパケットを送信する。ビデオカメラVは、多地点音声動画会議時に人物Pや背景等を撮像し、撮像データを送信側クライアント1へ出力する。
【0006】
マルチキャストグループ管理テーブル5は、受信ノードa〜cを複数組み合わせたグループを管理するテーブルでである。このマルチキャストグループ管理テーブル5において、「グループ」は、グループ名称であり、「メンバ」は、当該グループを構成する受信ノードである。
【0007】
具体的には、グループXは、受信ノードa(受信側クライアント2a)、受信ノードb(受信側クライアント2b)および受信ノードc(受信側クライアント2c)から構成されている。グループYは、受信ノードa(受信側クライアント2a)および受信ノードb(受信側クライアント2b)から構成されている。また、グループZは、受信ノードb(受信側クライアント2b)および受信ノードc(受信側クライアント2c)から構成されている。これらのグループX〜Zは、パケットをマルチキャスト方式により受信ノードへ配信する際に、当該パケットの宛先情報とされる。
【0008】
ルータ31 〜34 のそれぞれは、送信側クライアント1から送信されたパケットの宛先情報(グループ)を確認し、グループに応じて中継方向を動的に変化させることにより、パケットを所望のグループ内の受信ノードへ向けてルーティングする。これらのルータ31 〜34 には、ルーティングテーブル41 〜44 が予め保持されている。ルーティングテーブル41 〜44 は、グループX〜Zにそれぞれ対応する中継方向に関するデータからなり、ルーティング時にルータ31 〜34 により参照される。
【0009】
上記構成において、たとえば、マルチキャストグループ管理テーブル5内のグループXへパケットを送信する場合、送信側クライアント1のオペレータは、図示しないキーボードより、グループXを構成する受信ノードa〜cのそれぞれに付与されているネットワーク上のアドレスを順次入力する。これにより、送信側クライアント1は、宛先情報としてグループXが付加されたパケットをネットワークへ送出する。
【0010】
そして、パケットがルータ31 に到着すると、ルータ31 は、パケットの宛先情報(この場合、グループX)をキーとして、マルチキャストルーティングテーブル41 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、ルータ32 方向(同図右矢印)および受信ノードc方向(同図下矢印)である。つぎに、ルータ31 は、パケットのコピーを受信ノードcおよびルータ32 へ中継する。これにより、受信ノードc(受信側クライアント2c)では、パケットが受信される。
【0011】
一方、パケットがルータ32 に到着すると、ルータ32 は、パケットの宛先情報(この場合、グループX)をキーとして、マルチキャストルーティングテーブル42 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、ルータ33 方向(同図右矢印)およびルータ34 方向(同図右下矢印)である。つぎに、ルータ32 は、パケットのコピーをルータ33 およびルータ34 へ中継する。
【0012】
そして、パケットがルータ33 に到着すると、ルータ33 は、パケットの宛先情報(この場合、グループX)をキーとして、マルチキャストルーティングテーブル43 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、受信ノードa方向(同図右矢印)である。つぎに、ルータ33 は、パケットを受信ノードaへ中継する。これにより、受信ノードa(受信側クライアント2a)では、パケットが受信される。
【0013】
一方、パケットがルータ34 に到着すると、ルータ34 は、パケットの宛先情報(この場合、グループX)をキーとして、マルチキャストルーティングテーブル44 を参照することにより、パケットの中継方向を確認する。この場合の中継方向は、受信ノードb方向(同図右下矢印)である。つぎに、ルータ34 は、パケットを受信ノードbへ中継する。これにより、受信ノードb(受信側クライアント2b)では、パケットが受信される。
【0014】
【発明が解決しようとする課題】
ところで、前述したように、従来のマルチキャストシステムにおいては、図16に示したマルチキャストルーティングテーブル41 〜44 でのグループの追加、削除、変更や受信ノードの追加、削除、変更(以下、更新という)を行う場合、送信側クライアント1の送信ノード管理者(または受信ノードの受信ノード管理者)からルータ31 〜34 のルータ管理者に対して電話や電子メールにより、上記更新を依頼した後、ルータ管理者により追加、削除、変更が行われる。
【0015】
しかしながら、従来のマルチキャストシステムにおいては、人手を介してグループ(受信ノード)の更新を行っているため、グループや受信ノードの数が増えるにしたがって、グループ管理に要する時間、作業コストが増大してしまうという問題があった。また、人手によるグループ管理では、グループ(受信ノード)の更新に関するミスや漏れが発生するとともに、作業量の増大に伴って更新作業が大幅に遅れる場合があるという問題もあった。
【0016】
また、従来のマルチキャストシステムでは、受信ノードa〜cがパケットを受信できる状態にあるか否かにかかわらず、マルチキャストルーティングテーブル41 〜44 に基づいて、機械的にパケットを中継している。したがって、ネットワーク障害等によりパケットを受信できない状態にある受信ノードが存在した場合にも、当該受信ノードへ無駄なパケットが中継されるため、その分だけネットワークのトラフィック量が増え、ネットワークの伝送効率が悪くなるという問題があった。
【0017】
さらに、従来のマルチキャストシステムでは、マルチキャストルーティングテーブル41 〜44 が更新された場合、更新後のグループ(受信ノード)に関する情報が送信側クライアント1にリアルタイムで正しく伝達されない可能性が高い。これは、電話や電子メール等の手段を用いて人手を介在させて上記変更後の情報が送信側ノード管理者へ伝達されるからである。したがって、このような場合には、送信側クライアント1が更新前のグループへ無駄なパケットを送信することになるため、その分だけネットワークのトラフィック量が増え、ネットワークの伝送効率が悪くなるという問題があった。
【0018】
また、送信側クライアント1から、あるグループへパケットをマルチキャスト送信する場合には、当該グループを構成する受信ノードのそれぞれのアドレスを一々入力しなければならないため、マルチキャスト送信のためのオペレーションが複雑であるという問題があった。
【0019】
本発明は、上記に鑑みてなされたもので、マルチキャストのグループを容易、正確かつ迅速に管理することができるとともに、ネットワークの伝送効率の低下を防ぐことができ、しかも簡単なオペレーションによりマルチキャスト送信を行うことができるマルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【0020】
【課題を解決するための手段】
上記目的を達成するために、請求項1にかかる発明は、所定のマルチキャストグループに属することができる受信ノードと、マルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信する送信ノードと、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバとをネットワークを介して接続したマルチキャストシステムにおいて、前記受信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに該マルチキャストグループへの参加要求を送信し、前記管理サーバは、前記受信ノードより前記参加要求が送信された場合に、該参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶し、該マルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信し、前記送信ノードは、前記管理サーバより送信された最新の宛先リストに含まれるアドレスを指定して前記マルチキャストグループ向けのパケットを送信することを特徴とする。
【0021】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかを管理サーバが記憶して、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、送信ノードは、管理サーバから送信されたリストに含まれる受信ノードに対してマルチキャストデータを送信する。
【0022】
このように、請求項1にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、管理サーバが把握している情報に基づいて送信ノードがマルチキャストデータを送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【0023】
また、請求項2にかかる発明は、請求項1に記載のマルチキャストシステムにおいて、前記受信ノードは、自身が通信可能であることを示すパケットを前記管理サーバに所定の時間間隔で送信し、前記管理サーバは、所定の時間を経過しても前記受信ノードから前記パケットが送信されない場合は、前記記憶手段に該受信ノードが通信不能である旨を記憶し、前記宛先リストを生成する場合に、前記記憶手段において通信不能である旨が記憶されている受信ノードのアドレスを前記宛先リストから除外することを特徴とする。
【0024】
この発明によれば、受信ノードから定期的に送信されるパケットの受信状況を監視することで受信ノードが通信可能な状態にあるかどうかを管理サーバが判断し、通信可能な状態にあると判断した受信ノードを宛先リストから除外するように構成したので、通信可能な状態にある受信ノードに対してマルチキャストデータが無駄に送信されることがなくなり、ネットワークの伝送効率の低下を防ぐことができる。
【0025】
また、請求項3にかかる発明は、請求項1または2に記載のマルチキャストシステムにおいて、前記送信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに前記宛先リストの通知要求を送信し、前記管理サーバは、前記送信ノードより前記通知要求が送信された場合に、該通知要求にて指定されたアドレスをマルチキャストグループごとの通知リストに登録し、前記宛先リストを送信する場合に、該宛先リストに対応するマルチキャストグループの通知リストに登録されているアドレスに前記宛先リストを送信することを特徴とする請求項1または2に記載のマルチキャストシステムを特徴とする。
【0026】
この発明によれば、どの送信ノードからどのマルチキャストグループの宛先リストの通知要求があったかを管理サーバが通知リストに登録し、宛先リストを送信ノードに送信する場合にこの通知リストに基づいて送信先を決定するように構成したので、マルチキャストグループに対応する送信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【0027】
また、請求項4にかかる発明は、請求項1〜3のいずれか一つに記載のマルチキャストシステムにおいて、前記送信ノードは、前記通知要求を送信するために必要なマルチキャストグループと管理サーバの指定をURLの書式で受け付けることを特徴とする。
【0028】
この発明によれば、通知要求の送信時に、インターネット等で周知のURLという簡潔で定型化された書式をもちいて管理サーバとマルチキャストグループの指定を行うように構成したので、簡単なオペレーションにより通知要求の送信を行うことができる。
【0029】
また、請求項5にかかる発明は、送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバであって、前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信手段と、前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録手段と、前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信手段とを備えたことを特徴とする。
【0030】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかを管理サーバが記憶して、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、マルチキャストデータの送信先として利用させる。
【0031】
このように、請求項5にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【0032】
また、請求項6にかかる発明は、送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理するマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信工程と、前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録工程と、前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信工程とをコンピュータに実行させることを特徴とする。
【0033】
この発明によれば、どの受信ノードからどのマルチキャストグループへの参加要求があったかをマルチキャストグループ管理プログラムが記憶手段に記憶させ、参加要求があったマルチキャストグループに対応する送信ノードに対してそのマルチキャストグループに参加要求があった受信ノードのリストを送信し、マルチキャストデータの送信先として利用させる。
【0034】
このように、請求項6にかかる発明によれば、マルチキャストグループ管理プログラムが受信ノードから受信した参加要求に係る情報手段に記憶させることでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができる。
【0035】
【発明の実施の形態】
以下、図面を参照して本発明にかかるマルチキャストシステム、管理サーバ、マルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体の一実施の形態について詳細に説明する。
【0036】
図1は、本発明にかかる一実施の形態の構成を示す図である。この図には、送信側クライアント10(送信ノード)と受信側クライアント20a〜20c(受信ノードa〜c)とが、ルータ401 〜404 を含むネットワーク(たとえば、インターネット)を介して接続された構成が図示されている。送信側クライアント10は、コンピュータであり、ネットワークを介して受信側クライアント20a〜20cのうちあらかじめ設定されたグループに対してパケットを送信する。なお、同図には、送信側クライアント10のみ図示されているが、他の送信側クライアントもネットワークに接続されている。ビデオカメラVは、多地点音声動画会議時に人物Pや背景等を撮像し、撮像データを送信側クライアント10へ出力する。
【0037】
受信側クライアント20a〜20c(受信ノードa〜c)は、複数のグループにグルーピングされており、送信側クライアント10からマルチキャスト送信されたパケットをそれぞれ受信する。これらの受信側クライアント20a〜20c(受信ノードa〜c)のそれぞれには、ネットワーク上のアドレスが付与されている。また、受信側クライアント20a〜20cのそれぞれは、パケットを受信することができるか否かというネットワーク状態を監視する監視機能、監視結果を管理サーバ30へ通知するネットワーク状態通知機能を備えている。
【0038】
なお、同図には、受信側クライアントとして受信側クライアント20a〜20cが図示されているが、これら以外にも図示しない受信側クライアントが多数ネットワークに接続されている。
【0039】
管理サーバ30は、ネットワークに接続されており、マルチキャストグループ管理テーブル50を管理する。このマルチキャストグループ管理テーブル50は、たとえば、受信ノードa〜cを複数組み合わせたグループを管理するテーブルである。このマルチキャストグループ管理テーブル50において、「グループ」は、グループ名称であり、「メンバ」は、当該グループを構成する受信ノードである。
【0040】
同図に示した例では、グループXは、受信ノードa(受信側クライアント20a)、受信ノードb(受信側クライアント20b)および受信ノードc(受信側クライアント20c)から構成されている。グループYは、受信ノードa(受信側クライアント20a)および受信ノードb(受信側クライアント20b)から構成されている。また、グループZは、受信ノードb(受信側クライアント20b)および受信ノードc(受信側クライアント20c)から構成されている。これらのグループX〜Zは、パケットをマルチキャスト方式により受信ノードへ配信する際に、当該パケットの宛先情報とされる。
【0041】
ここで、実際には、マルチキャストグループ管理テーブル50は、図2(a)に示したようなデータベースから構成されている。同図に示したデータベースは、マルチキャストグループ管理テーブル50のグループXに対応しており、「受信ノード名」、「受信ノードのアドレス」、「ネットワーク状態」および「タイムアウト時刻」というデータからなる。「受信ノード名」は、グループXを構成する受信ノードの名称であり、nodeA〜Cである。これらのnodeA〜Cは、図1に示した受信ノードa〜cに対応している。
【0042】
「受信ノードのアドレス」は、それぞれの受信ノードに付与されたネットワーク上のアドレスである。「ネットワーク状態」は、受信ノードがパケットを受信できる状態にあるか否かを示すフラグである。すなわち、「ネットワーク状態」に「オフライン」フラグがたっている場合には、当該受信ノード(この場合、図1に示した受信ノードb)がパケットを受信できない状態にあることを意味している。一方、「ネットワーク状態」にいずれのフラグもたっていない場合には、当該受信ノードがパケットを受信できる状態にあることを意味している。「タイムアウト時刻」は、当該受信ノードがパケットを受信できない状態にあることを判断するための時刻である。
【0044】
つぎに、図6〜図8に示したシーケンス図を参照して一実施の形態の動作について説明する。図6は一実施の形態の初期化処理を説明するシーケンス図であり、図7は一実施の形態の終了処理を説明するシーケンス図であり、図8は一実施の形態のネットワーク監視動作を説明するシーケンス図である。図6に示したステップSA1では、管理サーバの初期化処理が実行される。
【0045】
すなわち、ステップSA1では、図1に示した管理サーバ30は、マルチキャストグループを設定するための空のデータベース、後述する通知リストを作成する。ここで作成されるデータベースは、図2(a)に示したフォーマットのものである。また、作成された空のデータベースには、いずれのデータも存在していない。
【0046】
つぎに、ステップSA2〜ステップSA8までは、送信側クライアントの初期化処理が実行される。すなわち、ステップSA2では、送信側クライアント10は、マルチキャスト方式によるパケットの配信を実現するためのアプリケーションを初期化する。ここで、送信側クライアント10のオペレータは、アクセス先の管理サーバ30、マルチキャストグループ管理テーブル50におけるグループ等を指定するためのURL(Uniform Resource Locator)を入力する。
【0047】
ここで、図5(a)〜(e)を参照してURL指定の例について説明する。これらの図に示したURLでは、「プロトコル」、「ユーザ名」、「パスワード」、「ホスト名」、「ポート番号」および「グループ名」を指定することができる。上記「ホスト名」は、管理サーバ30のネットワーク上の名称であり、「グループ名」は、マルチキャストグループ管理テーブル50(図1参照)におけるグループの名称である。すなわち、URLにより、少なくとも管理サーバ30およびグループを指定することが可能である。
【0048】
図6に戻り、ステップSA3では、送信側クライアント10は、入力されたURLを解析し、「プロトコル」、「パスワード」、「ユーザ名」、「ホスト名」、「ポート番号」および「グループ名」を特定する。この場合、少なくとも「ホスト名」(管理サーバ30の名称)および「グループ名」が特定されたものとする。ステップSA4では、送信側クライアント10は、ネットワークを介して管理サーバ30にアクセスし、図4(a)に示した通知リストへ自身のネットワーク上のアドレス(たとえば、「202.33.96.42」)を追加するように要求する。
【0049】
ここで、同図に示した通知リストは、図1に示したマルチキャストグループ管理テーブル50を構成する、たとえば、図3(a)に示したデータベース(グループ情報)を通知すべき送信側クライアントのアドレスを表すリストであり、管理サーバ30に保持されている。ステップSA5では、管理サーバ30は、図4(a)に示した通知リストに、管理サーバ30のアドレス「202.33.96.42」(図4(b)参照)を追加する。
【0050】
ステップSA6では、送信側クライアント10は、管理サーバ30に対して、URL指定された「グループ名」に対応するグループ情報、すなわちデータベース(図2(a)参照)の送信を要求する。ここでは、図2に示したデータベースには、いずれのデータも存在しない。
【0051】
これにより、ステップSA7では、管理サーバ30は、図2(a)に示したフォーマットの空のデータベース(グループ情報)を送信側クライアント10へ送信する。ステップSA8では、送信側クライアント10は、受信した空のデータベースから、図2(b)に示したようなフォーマットの宛先リストを生成する。この場合、宛先リストには、いずれのデータも存在しない。宛先リストは、マルチキャスト送信により送信側クライアント10から送信すべきパケットの宛先(受信ノードのアドレス)のリストである。
【0052】
つぎに、ステップSA9〜ステップSA14までは、受信側クライアントの初期化処理が実行される。すなわち、ステップSA9では、受信側クライアント(受信側クライアント20a〜20c、その他の受信側クライアントのうちいずれか一つまたは二つ以上)は、マルチキャスト方式によるパケットの受信を実現するためのアプリケーションを初期化する。ここで、受信側クライアントのオペレータは、送信側クライアント10のオペレータと同様にして、アクセス先の管理サーバ30、マルチキャストグループ管理テーブル50におけるグループ等を指定するためのURL(図5(a)〜(e)参照)を入力する。
【0053】
ステップSA10では、受信側クライアントは、入力されたURLを解析し、「プロトコル」、「パスワード」、「ユーザ名」、「ホスト名」、「ポート番号」および「グループ名」を特定する。この場合、少なくとも「ホスト名」(管理サーバ30の名称)および「グループ名」が特定されたものとする。ステップSA12では、受信側クライアントは、ネットワークを介して管理サーバ30にアクセスし、ステップSA1で作成されたデータベースに自身のネットワーク上のアドレスを登録するように要求する。すなわち、受信側クライアントは、マルチキャストグループ管理テーブル50におけるグループに自身のアドレスを登録するための要求を出す。
【0054】
ステップSA11では、管理サーバ30は、ステップSA1で作成されたデータベースに当該受信側クライアントの「ノード名」、「受信ノードのアドレス」、「ネットワーク状態」および「タイムアウト時刻」を登録する。たとえば、図2(c)に示したように、nodeDの受信側クライアントからグループへの登録要求があった場合、データベースには、nodeDに関する「ノード名」、「受信ノードのアドレス」、「ネットワーク状態」、「タイムアウト時刻」が登録される。
【0055】
ステップSA13では、管理サーバ30は、ステップSA5の通知リスト(図4(b)参照)に基づいて、通知リストに存在するアドレス(送信側クライアント10)へ、ステップSA11で登録されたデータベースを新しいグループ情報として自動通知する。この場合、図2(a)に示したデータベース(グループ情報)が少なくとも送信側クライアント10に通知されたものとする。なお、データベースは、送信側クライアント10以外の送信側クライアントであって宛先リストにアドレスが記載されているものにも送信される。
【0056】
これにより、ステップSA14では、送信側クライアント10は、図2(a)に示したデータベースから、図2(b)に示した宛先リストを作成する。この宛先リストは、上記データベースで「ネットワーク状態」の欄に「オフライン」フラグがたっていない受信ノードのアドレスからなる。すなわち、宛先リストのアドレスは、パケットを正常に受信可能な受信ノードに対応している。図2(b)に示した例では、宛先リストには、図2(a)に示したnodeA(受信ノードa:図1参照)のアドレス、およびnodeC(受信ノードc:図1参照)のアドレスが含まれている。なお、図2(c)に示したデータベースからは、図2(d)に示した宛先リストが生成され、図2(e)に示したデータベースからは、図2(f)に示した宛先リストが生成される。
【0057】
ステップSA15では、送信側クライアント10は、図2(b)に示した宛先リストに基づいて、図1に示した受信ノードaおよび受信ノードcに対してパケットを送信する。また、ステップSA13で新しいグループ情報が自動通知された他の送信側クライアント(図示略)も、受信ノードaおよびcに対してパケットを送信する。この場合には、多対多の通信が実現される。
【0058】
つぎに、図7を参照して終了処理について説明する。同図において、マルチキャスト送信を中止する場合、送信側クライアント10は、ステップSB1〜ステップSB4までの終了処理を実行する。すなわち、ステップSB2では、送信側クライアント10は、図4(b)に示した通知リストからの自身のアドレス(「202.33.96.42」)の削除を管理サーバ30へ要求する。
【0059】
これにより、ステップSB1では、管理サーバ30は、上記アドレスを通知リストから削除する。これにより、通知リストは、図4(a)に示したものとなる。なお、他の送信側クライアントからアドレス(たとえば、「202.239.162.34」)の削除要求があった場合、管理サーバ30は、図4(b)に示した通知リストから上記アドレスを削除する。この場合、通知リストは、図4(c)に示したものとなる。
【0060】
ステップSB3では、管理サーバ30は、送信側クライアント10へのグループ情報(データベース)の自動送信を停止する。ステップSB4では、送信側クライアント10は、アプリケーションの終了処理を実行する。これにより、ステップSB5では、マルチキャスト送信が中止される。
【0061】
また、受信側クライアントがパケットの受信を終了する場合、ステップSB6では、受信側クライアントは、データベース(たとえば、図2(a)参照)に登録されている自身に関するデータを削除するように管理サーバ30へ要求する。これにより、ステップSB7では、管理サーバ30は、データベースから当該受信側クライアントに関するデータを削除する。
【0062】
すなわち、当該受信側クライアントは、マルチキャストグループ管理テーブル50のグループから除外されたのである。ステップSB8では、受信側クライアントは、アプリケーションの終了処理を実行する。また、ステップSB9では、管理サーバ30は、データベースおよび通知リストを削除することにより、終了処理を実行する。
【0063】
つぎに、図8を参照してネットワーク監視動作について説明する。図1に示したネットワークが正常である場合、ステップSC1〜ステップSC6までの処理が実行される。すなわち、ステップSC1では、受信側クライアントは、管理サーバ30に対してタイムアウト延長要求を出す。ここでタイムアウト延長要求とは、図2(a)に示したデータベースにおける「タイムアウト時刻」の延長を要求することをいう。また、受信側クライアントは、一定時間毎(たとえば、30秒毎)にタイムアウト延長要求を管理サーバ30に対して出す。
【0064】
ステップSC2では、管理サーバ30は、タイムアウト延長要求を受けると、データベースのタイムアウト時刻をたとえば1分後の時刻に再設定する。ステップSC3では、送信側クライアント10は、マルチキャスト通信を継続する。そして、ステップSC1でタイムアウト要求を出した時刻から30秒経過すると、ステップSC4では、当該受信側クライアントは、管理サーバ30に対して再びタイムアウト延長要求を出す。ステップSC5では、管理サーバ30は、タイムアウト延長要求を受けると、データベースのタイムアウト時刻をたとえば1分後の時刻に再設定する。ステップSC6では、送信側クライアント10は、マルチキャスト通信を継続する。以後、上述した動作が繰り返される。
【0065】
ここでネットワーク故障が発生すると、ステップSC7では、上記受信側クライアントからのタイムアウト延長要求に失敗する。これは、データベース(図2(a)参照)の「タイムアウト時刻」を経過しても、受信側クライアントからのタイムアウト延長要求がない場合である。ステップSC8では、管理サーバ30は、たとえば、図2(e)に示したように、nodeAおよびDからのタイムアウト延長要求が無かった場合、nodeAおよびDに対応する「ネットワーク状態」の欄にオフラインのフラグを設定する。すなわち、同図に示したデータベースからは、nodeCのみがパケットの受信が可能な状態にあることがわかり、その他のnodeA、nodeBおよびnodeDがパケットの受信が出来ない状態(オフライン)にあることがわかる。
【0066】
ステップSC9では、管理サーバ30は、たとえば、図2(e)に示したデータベース(グループ情報)を、宛先リストに基づいて、たとえば、送信側クライアント10へ自動通知する。これにより、ステップSC10では、送信側クライアント10は、図2(f)に示した宛先リストを生成する。ステップSC11では、送信側クライアント10は、タイムアウト延長要求に失敗した当該受信側クライアントに対するマルチキャスト送信を停止する。
【0067】
そして、ネットワークが回復すると、ステップSC12では、ステップSC7でタイムアウト延長要求に失敗した受信側クライアントは、管理サーバ30に対するタイムアウト延長要求を再開する。これにより、ステップSC13では、管理サーバ30は、データベース(図2(e)参照)から、当該受信側クライアントに対応するオフラインのフラグを消去する。
【0068】
ステップSC14では、管理サーバ30は、オフラインのフラグが消去されたデータベース(グループ情報)を、宛先リストに基づいて、たとえば、送信側クライアント10へ自動通知する。これにより、ステップSC15では、送信側クライアント10は、宛先リストを生成する。この宛先リストには、オフラインのフラグが消去された当該受信側クライアントのアドレスが含まれている。これにより、ステップSC16では、送信側クライアント10は、タイムアウト延長要求を再開した当該受信側クライアントに対するマルチキャスト送信を再開する。
【0069】
なお、前述した図6では、送信側クライアントの初期化処理が受信側クライアントの初期化処理より先に実行される場合について説明したが、これとは逆に受信側クライアントの初期化処理が送信側クライアントの初期化処理より先に実行された場合には、図9に示したシーケンスで各処理が実行される。図9において、ステップSD1は、ステップSA1(図6参照)に対応しており、ステップSD2〜ステップSD5は、ステップSA9〜ステップSA12に対応している。また、図9に示したステップSD6〜ステップSD13は、図6に示したステップSA2〜ステップSA8およびステップSA15に対応している。
【0070】
同様にして、前述した図7では送信側クライアントの終了処理が受信側クライアントの終了処理より先に実行される場合について説明したが、これとは逆に受信側クライアントの終了処理が送信側クライアントの終了処理より先に実行された場合には、図10に示したシーケンスで各処理が実行される。図10において、ステップSE1およびステップSE2は、図7に示したステップSB6およびステップSB7に対応している。
【0071】
ステップSE3では管理サーバ30から送信側クライアント10へ新しいグループ情報が自動通知され、ステップSE4では宛先リストが生成される。これにより、ステップSE6では、マルチキャスト送信が停止される。また、図10に示したステップSE8〜ステップSE12は、図7に示したステップSB1〜ステップSB5およびステップSB9に対応している。
【0072】
図11は、二つの受信側クライアント(1)および(2)がある場合の初期化処理を説明するシーケンス図である。図11に示したステップSF1〜ステップSF5は、図9に示したステップSD1〜ステップSD5に対応している。ただし、図11に示したステップSF1〜ステップSF5までの処理は、受信側クライアント(1)の初期化処理である。また、図11に示したステップSF6〜ステップSF13は、図9に示したステップSD6〜ステップSD13に対応している。だだし、ステップSF13の処理は、受信側クライアント(1)に対してマルチキャスト送信を開始する処理である。
【0073】
さらに、図11に示したステップSF14〜ステップSF20は、受信側クライアント(2)の初期化処理である。ステップSF14〜ステップSF17までの処理は、ステップSF2〜ステップSF5の処理と同様である。ステップSF18では管理サーバ30から受信側クライアント(2)を含む新しいグループ情報が送信側クライアント10に自動通知される。ステップSF19では、送信側クライアント10は、宛先リストを生成する。ステップSF20では、送信側クライアント10は、受信側クライアント(1)および(2)へのマルチキャスト送信を開始する。
【0074】
図12は、二つの受信側クライアント(1)および(2)がある場合の終了処理を説明するシーケンス図である。図12に示したステップSG1〜ステップSG6は、図10に示したステップSE1〜ステップSE6に対応している。ただし、図11に示したステップSG2〜ステップSG6までの処理は、受信側クライアント(1)の終了処理である。また、ステップSG6では、受信側クライアント(1)に対するマルチキャスト通信が停止され、受信側クライアント(2)に対するマルチキャスト通信が継続される。
【0075】
また、図12に示したステップSG7〜ステップSG11は、図10に示したステップSE7〜ステップSE11に対応している。さらに、図12に示したステップSG12〜ステップSG14は、図10に示したステップSE1、ステップSE2およびステップSE5に対応している。ただし、ステップSG12〜ステップSG14までの処理は、受信側クライアント(2)の終了処理である。図12に示したステップSG15は、図10に示したステップSE12に対応している。
【0076】
つぎに、図13〜図15に示したフローチャートを参照して管理サーバ30、送信側クライアント10および受信側クライアントの動作について説明する。これらの動作は、前述した図6〜図12までのシーケンスに対応する動作である。図13に示したステップSH1では、管理サーバ30は、空のデータベースおよび通知リストを作成する(ステップSA1:図6参照)。ステップSH2では、管理サーバ30は、送信側クライアント10または受信側クライアントからリクエストが到着しているか否かを判断する。
【0077】
この場合、ステップSH2の判断結果が「No」であるものとすると、ステップSH3では、管理サーバ30は、タイムアウトした受信ノードをデータベースから検索する。ステップSH4では、管理サーバ30は、タイムアウトした受信ノードがあったか否かを判断し、この判断結果が「No」である場合、ステップSH2の処理を実行する。一方、ステップSH4の判断結果が「Yes」である場合、ステップSH5では、管理サーバ30は、データベースにオフラインのフラグを設定する(ステップSC8:図8参照)。
【0078】
ステップSH9では、管理サーバ30は、通知リストに登録されている送信ノード(送信側クライアント10)にデータベースの内容を通知する(ステップSC9:図8参照)。ステップSH17では、管理サーバ30は、処理を継続するか否かを判断し、この判断結果が「Yes」である場合、ステップSH2の処理を実行する。
【0079】
ステップSH2では、管理サーバ30は、リクエストが到着しているか否かを判断する。この場合、判断結果が「Yes」であるものとする。ステップSH6では、管理サーバ30は、リクエストの内容を判断する。ここで、リクエストの内容が送信側クライアント10からのグループ情報の問い合わせ(ステップSA6:図6参照)である場合、ステップSH7では、管理サーバ30は、データベース(グループ情報)を送信側クライアント10へ送信する(ステップSA7:図6参照)。
【0080】
また、リクエストの内容が受信側クライアントからのグループ登録解除(ステップSE1:図10参照)である場合、ステップSH8では、管理サーバ30は、データベースから受信ノードに関する情報を削除する(ステップSE2:図10参照)。ステップSH9では、管理サーバ30は、通知リストに登録されている送信ノードにデータベースの内容を通知する(ステップSE3:図10参照)。
【0081】
また、リクエストの内容が受信側クライアントからのグループ登録である場合(ステップSA12:図6参照)、ステップSH10では、管理サーバ30は、データベースに受信ノード(ステップSA11:図6参照)を追加する。ステップSH11では、タイムアウト時刻の設定を行う。ステップSH9では、管理サーバ30は、通知リストに登録されている送信ノードにデータベースの内容を通知する(ステップSA13:図6参照)。
【0082】
また、リクエストの内容が受信側クライアントからのタイムアウト延長(ステップSC1:図8参照)である場合、ステップSH12では、管理サーバ30は、タイムアウト時刻を再設定する(ステップSC2:図8参照)。ステップSH13では、管理サーバ30は、データベース(図2(a)参照)にオフラインのフラグがあるか否かを判断する。この判断結果が「Yes」である場合、ステップSH14では、管理サーバ30は、上記オフラインのフラグを削除する(ステップSC13:図8参照)。ステップSH9では、管理サーバ30は、通知リストに登録されている送信ノードにデータベースの内容を通知する(ステップSC14:図8参照)。
【0083】
また、リクエストの内容が通知リストの登録の解除である場合(ステップSB2:図7参照)、ステップSH15では、管理サーバ30は、通知リストから送信ノードのアドレスを削除する(ステップSB1:図7参照)。また、リクエストの内容が送信ノードからの通知リストの登録である場合(ステップSA4:図6参照)である場合、ステップSH16では、管理サーバ30は、通知リストに送信ノードのアドレスを追加する(ステップSA5:図6参照)。ステップSH17の判断結果が「No」である場合、ステップSH18では、管理サーバ30は、データベースと通知リストを削除する(ステップSB9:図7参照)。
【0084】
つぎに、図14を参照して送信側クライアント10の動作について説明する。図14に示したステップSI1では、送信側クライアント10は、マルチキャスト通信用のアプリケーションを初期化する(ステップSD6:図9参照)。ステップSI2では、送信側クライアント10は、入力されたURLを解析する(ステップSD7:図9参照)。ステップSI3では、送信側クライアント10は、管理サーバ30に対して、通知リストへのアドレスの追加を要求する(ステップSD8:図9参照)。
【0085】
ステップSI4では、送信側クライアント10は、グループ情報(データベース)の送信要求を管理サーバ30へ出した後、グループ情報(データベース)を取得する(ステップSD11:図9参照)。ステップSI5では、送信側クライアント10は、グループ情報からオフラインの受信ノードを取り除き、宛先リストを作成する(ステップSD12:図9参照)。ステップSI6では、送信側クライアント10は、宛先リストにしたがってマルチキャストデータグラム(パケット)の送信を開始する(ステップSD13:図9参照)。
【0086】
ステップSI7では、送信側クライアント10は、処理を継続するか否かを判断する。この判断結果が「Yes」である場合、ステップSI8では、送信側クライアント10は、新しいグループ情報(データベース)が管理サーバ30から届いているか否かを判断する。この判断結果が「Yes」である場合、送信側クライアント10は、ステップSI5の処理を実行する。一方、ステップSI8の判断結果が「No」である場合、送信側クライアント10は、ステップSI6の処理を実行する。
【0087】
そして、ステップSI7の判断結果が「No」になると、ステップSI9では、送信側クライアント10は、管理サーバ30に対して通知リストからの削除を要求する(ステップSE7:図10参照)。ステップSI10では、送信側クライアント10は、アプリケーションを終了する(ステップSE10:図10参照)。
【0088】
つぎに、図15を参照して受信側クライアント(受信側クライアント20a〜20c)の動作について説明する。図15に示したステップSJ1では、受信側クライアントは、マルチキャスト受信用のアプリケーションを初期化する(ステップSA9:図6参照)。ステップSJ2では、受信側クライアントは、入力されたURLを解析する(ステップSA10:図6参照)。ステップSJ3では、受信側クライアントは、管理サーバ30に対して、グループへの登録を要求する(ステップSA12:図6参照)。
【0089】
ステップSJ4では、受信側クライアントは、送信側クライアント10からのマルチキャストデータグラム(パケット)を受信する。ステップSJ5では、受信側クライアントは、前回のタイムアウト延長要求時から30秒経過したか否かを判断する。この判断結果が「No」である場合、ステップSJ7では、受信側クライアントは、処理を継続するか否かを判断する。この判断結果が「Yes」である場合、受信側クライアントは、ステップSJ4の処理を実行する。
【0090】
そして、ステップSJ5の判断結果が「Yes」になると、ステップSJ6では、受信側クライアントは、管理サーバ30にタイムアウト延長を要求する(ステップSC1:図8参照)。また、ステップSJ7の判断結果が「No」である場合、ステップSJ8では、受信側クライアントは、管理サーバ30に対してグループからの登録を解除することを要求する(ステップSB6:図7参照)。ステップSJ9では、受信側クライアントは、アプリケーションを終了する(ステップSB8:図7参照)。
【0091】
以上説明したように、一実施の形態によれば、従来の人手によらず管理サーバ30によりデータベース(グループ情報)を管理し、グループが更新された場合や送信ノードから通知要求された場合に更新後のグループ情報を送信ノードに通知するようにしたので、マルチキャストのグループを容易、正確かつ迅速に管理することができる。
【0092】
また、一実施の形態によれば、管理サーバ30により、受信ノードa〜cの受信状態(ネットワーク状態)を監視し、パケットを受信できない受信ノードがある場合、グループから当該受信ノードが除外されるため、不必要に当該受信ノードに対してパケットが送信されないことから、ネットワークの伝送効率の低下を防ぐことができる。
【0093】
また、一実施の形態によれば、通知リスト内の複数の送信ノードに対して変更後のグループ情報を通知するようにしたので、複数の送信ノードとグループとの間で多対多でのマルチキャスト通信を容易に実現することができる。
【0094】
また、一実施の形態によれば、インターネット等で周知のURLという極めて簡単な指定方法によりグループ情報等を指定していることから、簡単なオペレーションによりマルチキャスト送信を行うことができる。
【0095】
以上本発明にかかる一実施の形態について図面を参照して詳述してきたが、具体的な構成例はこの一実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。たとえば、前述した一実施の形態においては、管理サーバ30の機能を実現するためのマルチキャストグループ管理プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたマルチキャストグループ管理プログラムをコンピュータに読み込ませ、実行することによりグループ管理を行うようにしてもよい。
【0096】
コンピュータは、上記マルチキャストグループ管理プログラムを実行するCPUと、キーボード、マウス等の入力装置と、各種データを記憶するROM(Read Only Memory)と、演算パラメータ等を記憶するRAM(Random Access Memory)と、記録媒体からマルチキャストグループ管理プログラムを読み取る読取装置と、ディスプレイ、プリンタ等の出力装置と、装置各部を接続するバスとから構成されている。
【0097】
CPUは、読取装置を経由して記録媒体に記録されているマルチキャストグループ管理プログラムを読み込んだ後、マルチキャストグループ管理プログラムを実行することにより、前述した処理を実行する。なお、記録媒体には、光ディスク、フロッピーディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【0098】
【発明の効果】
以上説明したように、請求項1にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、管理サーバが把握している情報に基づいて送信ノードがマルチキャストデータを送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【0099】
また、請求項2にかかる発明によれば、受信ノードから定期的に送信されるパケットの受信状況を監視することで受信ノードが通信可能な状態にあるかどうかを管理サーバが判断し、通信可能な状態にあると判断した受信ノードを宛先リストから除外するように構成したので、通信可能な状態にある受信ノードに対してマルチキャストデータが無駄に送信されることがなくなり、ネットワークの伝送効率の低下を防ぐことができるという効果を奏する。
【0100】
また、請求項3にかかる発明によれば、どの送信ノードからどのマルチキャストグループの宛先リストの通知要求があったかを管理サーバが通知リストに登録し、宛先リストを送信ノードに送信する場合にこの通知リストに基づいて送信先を決定するように構成したので、マルチキャストグループに対応する送信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【0101】
また、請求項4にかかる発明によれば、通知要求の送信時に、インターネット等で周知のURLという簡潔で定型化された書式をもちいて管理サーバとマルチキャストグループの指定を行うように構成したので、簡単なオペレーションにより通知要求の送信を行うことができるという効果を奏する。
【0102】
また、請求項5にかかる発明によれば、管理サーバが受信ノードから受信した参加要求に係る情報を記憶することでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【0103】
また、請求項6にかかる発明によれば、マルチキャストグループ管理プログラムが受信ノードから受信した参加要求に係る情報を記憶手段に記憶させることでどのマルチキャストグループに属する受信ノードを把握することし、把握している情報に基づいてマルチキャストグループに属する受信ノードのリストを作成して送信ノードに送信するように構成したので、マルチキャストグループに受信ノードを登録するために必要な更新処理を自動化し、容易、正確かつ迅速に実行することができるという効果を奏する。
【図面の簡単な説明】
【図1】本発明にかかる一実施の形態の構成を示す図である。
【図2】同一実施の形態におけるデータベースおよび宛先リストを示す図である。
【図3】同一実施の形態におけるデータベースおよび宛先リストを示す図である。
【図4】同一実施の形態における通知リストを示す図である。
【図5】同一実施の形態におけるURL指定の例を示す図である。
【図6】同一実施の形態の初期化処理を説明するシーケンス図である。
【図7】同一実施の形態の終了処理を説明するシーケンス図である。
【図8】同一実施の形態のネットワーク監視動作を説明するシーケンス図である。
【図9】同一実施の形態の初期化処理を説明するシーケンス図である。
【図10】同一実施の形態の終了処理を説明するシーケンス図である。
【図11】同一実施の形態の初期化処理を説明するシーケンス図である。
【図12】同一実施の形態の終了処理を説明するシーケンス図である。
【図13】同一実施の形態の管理サーバ30の動作を説明するフローチャートである。
【図14】同一実施の形態の通信側クライアント10の動作を説明するフローチャートである。
【図15】同一実施の形態の受信側クライアントの動作を説明するフローチャートである。
【図16】従来におけるマルチキャストシステムの構成を示す図である。
【符号の説明】
10 送信側クライアント
20a〜20c 受信側クライアント
30 管理サーバ
Claims (6)
- 所定のマルチキャストグループに属することができる受信ノードと、マルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信する送信ノードと、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバとをネットワークを介して接続したマルチキャストシステムにおいて、
前記受信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに該マルチキャストグループへの参加要求を送信し、
前記管理サーバは、前記受信ノードより前記参加要求が送信された場合に、該参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶し、該マルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信し、
前記送信ノードは、前記管理サーバより送信された最新の宛先リストに含まれるアドレスを指定して前記マルチキャストグループ向けのパケットを送信することを特徴とするマルチキャストシステム。 - 前記受信ノードは、自身が通信可能であることを示すパケットを前記管理サーバに所定の時間間隔で送信し、
前記管理サーバは、所定の時間を経過しても前記受信ノードから前記パケットが送信されない場合は、前記記憶手段に該受信ノードが通信不能である旨を記憶し、前記宛先リストを生成する場合に、前記記憶手段において通信不能である旨が記憶されている受信ノードのアドレスを前記宛先リストから除外することを特徴とする請求項1に記載のマルチキャストシステム。 - 前記送信ノードは、マルチキャストグループと自身のアドレスとを指定して前記管理サーバに前記宛先リストの通知要求を送信し、
前記管理サーバは、前記送信ノードより前記通知要求が送信された場合に、該通知要求にて指定されたアドレスをマルチキャストグループごとの通知リストに登録し、前記宛先リストを送信する場合に、該宛先リストに対応するマルチキャストグループの通知リストに登録されているアドレスに前記宛先リストを送信することを特徴とする請求項1または2に記載のマルチキャストシステム。 - 前記送信ノードは、前記通知要求を送信するために必要なマルチキャストグループと管理サーバの指定をURLの書式で受け付けることを特徴とする請求項1〜3のいずれか一つに記載のマルチキャストシステム。
- 送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理する管理サーバであって、
前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信手段と、
前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録手段と、
前記参加要求受信手段により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信手段と
を備えたことを特徴とする管理サーバ。 - 送信ノードがマルチキャストグループに属する受信ノードのアドレスを個別に指定してパケットを送信することによりマルチキャストを実現するマルチキャストシステムにおいて、どのマルチキャストグループにどの受信ノードが属し、どのマルチキャストグループとどの送信ノードが対応するかを管理するマルチキャストグループ管理 プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記受信ノードよりマルチキャストグループと該受信ノードのアドレスとが指定されたマルチキャストグループへの参加要求を受信する参加要求受信工程と、
前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループとアドレスとを対応付けて記憶手段に記憶させる宛先アドレス登録工程と、
前記参加要求受信工程により受信された参加要求にて指定されたマルチキャストグループと対応付けて記憶されているアドレスを前記記憶手段より抽出した宛先リストを生成し、該宛先リストを前記マルチキャストグループに対応する前記送信ノードに送信する宛先リスト送信工程と
をコンピュータに実行させるためのマルチキャストグループ管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
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 |