JP3759527B2 - マルチキャストデータ通信システム及び方法、クライアント側ゲートウェイ、サーバ側ゲートウェイ、コンピュータプログラム、ならびに、コンピュータプログラムを記録した記録媒体 - Google Patents

Description

本発明は、１対１通信（ユニキャスト）だけがサポートされている既存のインターネットを介して、１対多通信プロトコル（マルチキャスト）対応の送信ホスト（サーバ）から複数の１対多通信プロトコル対応の受信ホスト（クライアント）に対してデータを同報するマルチキャストデータ通信システム及び方法等に関する。

従来、インターネット上で複数の受信ホストに対してデータを同報するマルチキャスト通信を実現する方法として、予め定められたマルチキャストＩＰ（Internet Protocol）アドレスを用いて行う方法（ＩＰマルチキャスト）がある。この方法は、送信ホスト（サーバ）がマルチキャストＩＰアドレスを宛先としてデータを送信すると、配送途中、インターネット上に配備されたマルチキャストルータ（中継ノード）が、データを適宜コピーすることにより、全ての受信ホスト（クライアント）まで同一のデータを届けるというものである。
前述したＩＰマルチキャストを実現するためには、全てのルータがＩＰマルチキャストに対応している必要がある。しかし、大部分のルータがＩＰマルチキャストに対応又は有効にしていない現状において、全てのルータをＩＰマルチキャスト対応又は有効にさせるのは困難である。

一方、送信端末と受信端末がＩＰマルチキャスト非対応網を跨いで、ＩＰマルチキャスト通信を実現する方法として、ＭＢＯＮＥ（マルチキャスト backBONE）と呼ばれる仮想マルチキャスト実験網で行われているようなトンネリングがある。これは、ＩＰマルチキャスト対応ＬＡＮ（Local Area Network）間をユニキャストでカプセル化することにより、前記ＬＡＮ間に仮想的な通信リンクを構築し、この上でＩＰマルチキャスト通信を行う方法である。しかしながら、この仮想的なリンクは、ポイント・ツー・ポイント接続であり、また手動で設定されるため、接続するＬＡＮの数が多い場合は、最適な配信ツリーを構築するのは極めて困難である。

さて、ＩＰマルチキャストでは、通常、送信ホストから複数の受信ホストまでのデータ配送経路は、送信ホストを根（ルート）とし、受信ホストを葉（リーフ）とするツリーとなる。これをマルチキャストツリーという。ＩＰマルチキャストにおいて、マルチキャストツリーを構築するプロトコルとしては、ＲＦＣ１０７５のＤＶＭＲＰ（Distance-Vector マルチキャスト Routing Protocol）や、ＲＦＣ１５８４のＭＯＳＰＲ（マルチキャスト Open Shortest Path First）や、ＲＦＣ２３６２のＰＩＭ−ＳＭ（Protocol Independent マルチキャスト-Sparse Mode）などがある。また、各受信ホストがツリーに参加したり、離脱したりする操作を管理するためのプロトコルとして、ＲＦＣ１１１２のＩＧＭＰ（Internet Group Managem
ent Protocol）がある。

しかし、マルチキャストツリー構築プロトコルには、ツリーを構成するルータ数に関してスケーラビリティが無いという欠点がある。そして、ＤＶＭＲＰでは、受信ホストの存在に関わらず、総てのルータを含む配信木が定期的に構築され、データが配信されてしまう。また、ＭＯＳＰＦは各中継ノードがマルチキャストツリー全体のトポロジー情報を保持する必要があり、マルチキャストツリーが大規模な場合に対応できない。また、ＰＩＭ−ＳＭはマルチキャストツリーに参加するホストがrendezvous point（ランデブーポイント）と呼ぶ特定のノードにアクセスする必要があり、どうしてもrendezvous pointにおいて輻輳が起き易くなる。

さらに、ＩＰマルチキャストでは、マルチキャストＩＰアドレスがグローバルかつユニーク（唯一）であることを保証する必要があるため、マルチキャストＩＰアドレスの唯一性を保つための管理コストがかかる。加えて、上記プロトコルではマルチキャストツリーに参加していないホストであっても送信ホストになることが可能であるため、悪意のある者がマルチキャストツリーの参加者に対して無用なトラヒックを送りつけるような攻撃を許してしまう。

これに対してＩＰマルチキャストの拡張である、非特許文献２は、Source-specific マルチキャスト（ＳＳＭ）と呼ばれており、送信元アドレスとマルチキャストアドレスの組によってマルチキャストツリーを特定している。これにより、マルチキャストＩＰアドレスは、各ホスト内でユニークに保てばよく、マルチキャストＩＰアドレスの管理コストの問題を解消することが出来る。また、各グループで送信できるホストはただ一つに限られているので、悪意のある者がマルチキャストツリーの参加者に対して無用なトラヒックを送りつけるような攻撃を防ぐことが出来る。しかしながら、依然として、総てのルータがＩＰマルチキャスト対応であることを要求するため、現状において広域展開は困難である。

一方、特許文献２には、ＩＰマルチキャストを使わず、ユニキャストだけを用いたマルチキャストデータ通信方法が開示されている。この方法は、受信ホストから送信された受信開始要求を受け取ったマルチキャストサーバ（中継ノード：中継装置）がその受信ホストを記憶し、以後、その受信ホストから受信終了要求を受け取るまで、マルチキャストデータをその受信ホストに配送するというものである。
しかし、この方法では、受信ホストからの受信終了要求が伝送途中に失われた時や受信ホストがハングアップした時は、上記受信ホストヘのマルチキャストデータの配送が止まらないという問題があった。また、受信開始要求により、一度配送経路が確定すると、ルータの経路情報の変化により、受信ホストに対し最寄りの中継ノードが変わった場合でも、その受信ホストに配送する経路は変わらないという問題があった。

以上述べた特許文献２に類似する技術として、非特許文献３がある。非特許文献３はアプリケーション層におけるマルチキャスト技術であって、一番最初に要求を出した受信ホストヘのforward-path（順方向パス）に基づいてマルチキャストツリーが決定される。その後にこの受信ホストがマルチキャストツリーから離脱すると、別の受信ホストヘのforward-pathに基づくマルチキャストツリーが決定されて、マルチキャストツリーの構成を変えるようになっている。

しかしながら、特許文献２、非特許文献３には次のようなセキュリティ上の問題がある。すなわち、送信ホスト又は受信ホストが、テーブル作成機能を持つパケット（例えば上述した受信要求パケット）を適当な端末アドレスに宛てて送出することで、ホストから宛先に至るパス上に存在する各ノードにテーブルを作成することが可能となる。この性質を利用することにより、悪意のあるユーザが多数のアドレス宛てにテーブル生成パケットを送出すると、無意味なテーブルがネットワーク内のノードに多数生成されてしまう。その結果、ノードの負荷が不必要に重くなってその性能を低下させてしまうという問題がある。

これに対し、非特許文献１では、ユニキャスト通信可能なネットワークを使い１対多通信を実現する方法であって、悪意のあるユーザによる攻撃によって無意味なテーブルがネットワーク内のノードに多数生成されて負荷が重くなるといった問題を生じず、高度なセキュリティを実現できる方法を開示している。また、非特許文献１では、受信ホストに対する最寄りの中継ノードが変化したり、中継ノードの負荷状態が変化した場合でも、１対多通信の通信経路を変更可能である。
特開２００１−２３０７７４号公報 特開平１０−６３５９８号公報 宮崎、谷、高橋，「IP unicast address を用いたマルチキャスト方式の提案」，電子情報通信学会，２００１年５月，信学技法ＩＮ２００１−９ Hugh．W．Holbrook（ヒュー・Ｗ・ホールブルック），David R．Cheriton（デビット・Ｒ・チェリトン），"IP マルチキャスト Channels: EXPRESS Support for Large-scale Single-source Applications（ＩＰマルチキャストチャネル：大規模シングルソースアプリケーションに対するエクスプレスサポート）"，１９９９， In Proc. of SIGCOMM（シグコム），p．６５-７８， Ion Stoica（イオン・ストイカ），T．S．Eugene Ng（Ｔ．Ｓ．ユージン），Hui Zhang（ホイ・チャン），"REUNITE: A Recursive Unicast Approach to マルチキャスト（リユニット：マルチキャストへのリカーシブ・ユニキャスト・アプローチ）"，In Proc. of lNFOCOM２０００（インフォコム２０００），p．１６４４-１６５３

現在、多くの市販されている同報配信用動画像送受信ソフトは、ＩＰマルチキャスト対応であり、独自のプロトコルを実装する必要のある非特許文献１の方法を利用することは困難である。すなわち、非特許文献１の方法を用いるためには、新たに対応端末ソフトを開発することが必要であり、コストがかかるという問題があった。

さらには、市販のパーソナルコンピュータにはＩＰマルチキャスト対応の同報配信用動画像送受信ソフトがインストール済みであることが多いにもかかわらず、これが使用できないために、新たに非特許文献１の方法に対応した新端末ソフトをユーザ自らインストールすることが必要であった。

一方、ＩＰマルチキャスト対応クライアント、及び、ＩＰマルチキャスト対応サーバの各サブネットにゲートウェイを置き、このゲートウェイが上記クライアントからの受信要求をユニキャストとして上記サーバが存在するサブネットのゲートウェイに送り、上記サーバの存在するサブネットのゲートウェイは、上記サーバが送出するマルチキャストパケットをユニキャストパケットに変換して上記クライアントが存在するサブネットのグートウェイに送り、該ゲートウェイは再びマルチキャストパケットに変換してサブネット内に流すことにより上記クライアントがマルチキャストパケットを受信可能にする手法が、特許文献１に開示されている。しかし、この方法は、ユニキャストによる一対一通信でゲートウェイ間を結ぶことを仮定しているため、クライアントの数が多い場合、サーバ側ゲー
トウェイに過大な負荷がかかるという問題がある。また、非特許文献１の方式は、クライアントが受信要求をしている間、配送経路を維持し続けるための制御が必要なため、特許文献１の方式のゲートウェイ間のユニキャスト部分に、非特許文献１の方式をそのまま用いることは出来ない。

本発明の目的は、ＩＰマルチキャスト対応クライアントがマルチキャストパケットの受信を要求している間、ＩＰマルチキャスト対応クライアント及びＩＰマルチキャスト対応サーバのそれぞれが属するＩＰマルチキャスト対応ネットワーク上の上記ゲートウェイ間に、非特許文献１の方式によるユニキャストのみを用いたツリー状配信経路を生成・維持することができるマルチキャストデータ通信システム及び方法、クライアント側ゲートウェイ、サーバ側ゲートウェイ、コンピュータプログラム、ならびに、コンピュータプログラムを記録した記録媒体を提供することにある。

この発明は、上記の課題を解決すべくなされたもので、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムであって、前記クライアント側ゲートウェイは、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段とを備え、前記サーバ側ゲートウェイは、前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段を備える、ことを特徴とするマルチキャストデータ通信システムである。
本発明によれば、ＩＰマルチキャスト対応のクライアントがＩＧＭＰ membership report（ＩＧＭＰメンバシップレポート）を定期的に発行することにより、ＩＰマルチキャスト対応のクライアントの存在を常に確認し、存在が確認できている期間のみ非特許文献１の方式における受信要求パケットを発行するクライアント側ゲートウェイと、この受信要求パケットを定期的に受信中の期間のみ、マルチキャストパケットをユニキャストに変換して、受信要求パケットの送信元に送るサーバ側ゲートウェイにより、ＩＰマルチキャスト端末が非特許文献１のマルチキャストデータ通信方法を使用することを可能にする。

また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるマルチキャストデータ通信方法であって、前記クライアント側ゲートウェイが、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信し、前記サーバ側ゲートウェイが、前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出し、前記クライアント側ゲートウェイが、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出する、ことを特徴とするマルチキャストデータ通信方法である。

また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイであって、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段と、を備えることを特徴とするクライアント側ゲートウェイである。

また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイであって、前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段、を備えることを特徴とするサーバ側ゲートウェイである。

また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムであって、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップと、をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラムである。

また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムであって、前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラムである。

また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップと、の各処理をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体である。
また本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体である。

また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムであって、前記クライアント側ゲートウェイは、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段とを備え、前記サーバ側ゲートウェイは、前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段を備えることを特徴とする。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるマルチキャストデータ通信方法であって、前記クライアント側ゲートウェイが、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信し、前記サーバ側ゲートウェイが、前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出し、前記クライアント側ゲートウェイが、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出することを特徴とする。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイであって、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段とを備えることを特徴とする。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイであって、前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段を備えることを特徴とする。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムであって、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップとをコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラムである。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムであって、前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラムである。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップとの各処理をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体である。
また、本発明は、マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップをコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体である。

以上説明したように、本発明によれば、クライアントが多数ある場合においても、サーバにフローが集中するという問題を解決しながら、マルチキャスト非対応網を経由したマルチキャスト対応ネットワーク間のマルチキャストデータ通信を可能とした。

以下、本発明を実施するための最良の形態について説明する。

１．ネットワーク構成
図１に本発明の一実施の形態によるマルチキャストデータ通信方法を用いてＩＰマルチキャスト対応端末を接続する場合のネットワーク構成例を示す。
図においては、３つのローカルネットワーク、ＬＡＮ（Ａ）、ＬＡＮ（Ｂ）、ＬＡＮ（Ｃ）が、ＩＰマルチキャスト非対応のネットワーク７００により接続されている。そして、ＩＰマルチキャスト対応のサーバ（以下、「ＩＰマルチキャストサーバ」）またはクライアント（以下、「ＩＰマルチキャストクライアント」）が接続している各ＬＡＮセグメントには、ゲートウェイを配置する。ここで、ゲートウェイとは、ＩＰマルチキャストクライアントが受信要求をしている間だけ、下記２章に示す従来技術のマルチキャストデータ通信方法によりネットワーク７００に配信経路を生成・維持し、かつ、ＩＰマルチキャストサーバが送出するＩＰマルチキャストをユニキャストに変換して、この配信経路に送出する機能を持つ装置である。図１の例では、各ＬＡＮは、１セグメントからなるが、複数セグメントからなるＬＡＮにおいては、各セグメントにゲートウェイを配置する。ＩＰマルチキャストサーバ側のセグメントとＩＰマルチキャストクライアント側のセグメントでは、ゲートウェイの機能が異なるが、例えば、個人用計算機を、その時々により、ＩＰマルチキャストサーバにしたり、あるいは、ＩＰマルチキャストクライアントにしたりする場合は、ＩＰマルチキャストサーバ側のゲートウェイ（以下、「サーバ側ゲートウェイ」）とＩＰマルチキャストクライアント側のゲートウェイ（以下、「クライアント側ゲートウェイ」）の両方を同じセグメントに配置すればよい。また、サーバ側ゲートウェイとクライアント側ゲートウェイが、同じホスト上で動作していても良い。
なお、ＩＰマルチキャスト非対応のネットワーク７００には、２章に示す従来技術に示される中継ノード、すなわち、ある送信ホストから複数の受信ホストヘのツリー状のデータ配信経路を構成するための分岐機能を持つ中継ノード６００が１つ以上配置されている。
図１において、ＬＡＮ（Ａ）には、ＩＰマルチキャストサーバ２００が配置され、ＬＡＮ（Ｂ）、ＬＡＮ（Ｃ）には、それぞれ、ＩＰマルチキャストクライアント５００ｂ、５００ｃ（以下、「ＩＰマルチキャストクライアント５００」）が配置されている。また、ゲートウェイとして、ＬＡＮ（Ａ）にはサーバ側ゲートウェイ３００が、ＬＡＮ（Ｂ）、ＬＡＮ（Ｃ）には、それぞれ、クライアント側ゲートウェイ４００ｂ、４００ｃ（以下、「クライアント側ゲートウェイ４００」）が配置されている。

２．従来技術のマルチキャストデータ通信方法
ここでは、非特許文献１に記載の技術を用いたマルチキャストデータ通信方法について示す。
２．１ 従来技術の実施の形態１
図５は、従来技術のマルチキャスト通信が行われるネットワーク構成の一例について示す。即ち、ここでは１つの中継ノード２１に４つの受信ホスト２２−１，２２−２，２２−３，２２−４がネットワークを介して接続され、送信ホスト（図示せず）もネットワークを介して中継ノード２１に接続されているものとする。なお、受信ホスト２２−１、２２−２、２２−３、２２−４のＩＰアドレスは、それぞれ、「１０．１０．９．８」、「１０．１１．１０．９」、「１０．１２．１１．１０」、「１０．１３．１２．１１」である。
各受信ホスト２２−１〜２２−４は、予め決められた値より小さい時間間隔毎に受信要求パケットを送出する。受信要求パケットが中継ノード２１に到着すると、その到着時刻が中継ノード２１のテーブル（以下、「配信テーブル」という）に記録される。なお、中継ノード２１の配信テーブルに登録された受信ホストを、中継ノード２１の子という。子が登録されている中継ノード２１自身も、予め決められた値より小さい時間間隔毎に受信要求パケットを送信ホストに向かって送出する。より送信ホストに近い中継ノードにこの受信要求パケットが到着すると、到着時刻が記録される。中継ノード自身が受信要求パケットを送信ホストに向かって送出するタイミングについては後述する。

図６は従来技術の実施の形態１の配信テーブルの一例を示すもので、各子のアドレスと各子からの受信要求パケットが中継ノード２１に到着した時刻が子毎に記録されている。

送信ホストからのデータパケットがこの中継ノード２１に到着した時、現在時刻と、配信テーブルに記録された各子毎の受信要求パケット到着時刻とを比較し、その間隔がある値以上である子はタイムアウトしたと見なし、その子に対してはデータパケットを送出しない。この時、配信テーブルからこの子を削除する。

例えば、図７は、中継ノード２１に送信ホストからのデータパケットが時刻１０：２３：１１に到着した時の様子を示すものである。タイムアウト時間間隔が００：００：１０であったとすると、図６より、子３だけがタイムアウトしていることになる。従って、このデータパケットは、図８に示すように、子１及び子２（受信ホスト２２−１，２２−２）に対してだけ送出される。また、この時、子３は配信テーブルから削除される。子３が削除された後の配信テーブルは、図９に示すようになる。

全ての子がタイムアウトしていた場合には、配信テーブル自体を削除する。配信テーブルに登録された子や配信テーブル自体を削除するための他の方法も考えられる。例えば、受信要求パケットが到着した時に、その受信要求パケットが対応するツリーＩＤの配信テーブルについて、タイムアウトした子の削除操作を行えば、データパケット転送時の処理量を減らすことが出来る。これは、リアルタイムストリームデータなど、転送レートが重要な場合は有益である。また、タイムアウトした子や配信テーブルが、より確実に削除されるようにするには、中継ノード自体に、タイムアウトした子や配信テーブルを削除するプログラムを定期的に起動する仕組みを作っておく方法もある。

図１０はマルチキャスト通信が行われるネットワーク構成の他の例について示す。即ち、ここでは３つの中継ノード３１−１，３１−２，３１−３に７つの受信ホスト３２−１，３２−２，３２−３，３２−４，３２−５，３２−６，３２−７及び１つの送信ホスト３３（本節では以下、「サーバ」と記述）がネットワークを介して接続されている状態を示している。

図１１は図１０の構成において、クライアント３２−１，３２−２，３２−４，３２−５，３２−６がマルチキャストに参加している状態から、さらにクライアント３２−７が新たに受信要求パケットを送出してきた状態を示している。ここで、中継ノード３１−３は既に高負荷状態になっており、クライアント３２−７のためにデータパケットを複製する回数を増やす余裕がないものとする。

この時、中継ノード３１−３はクライアント３２−７からの受信要求パケットをそのままサーバ３３に向かって転送する。中継ノード３１−２にクライアント３２−７からの受信要求パケットが到着した時、中継ノード３１−２が高負荷状態でなければ、当該中継ノード３１−２の配信テーブルに子として登録される。この結果、サーバ３３からのデータパケットは、中継ノード３１−２でクライアント３２−７のために複製され、ユニキャストで直接クライアント３２−７に送られる。

クライアント３２−７からの受信要求パケットは、予め決められた値以下の時間間隔で送出され続けられるので、その度毎に中継ノード３１−３で転送され、中継ノード３１−２では配信テーブルの受信要求パケット到着時刻が更新される。

次に、図１２に示すように、クライアント３２−５が離脱パケットもしくはタイムアウトにより中継ノード３１−３の配信テーブルから削除され、中継ノード３１−３の負荷が下がり、この結果、中継ノード３１−３は新たに子を増やすことが可能になったものとする。この時、中継ノード３１−３にクライアント３２−７の受信要求パケットが到着すると、中継ノード３１−３はこの受信要求パケットを中継ノード３１−２へ転送せずにクライアント３２−７を配信テーブルに登録する。この様子を、図１３に示す。

この結果、中継ノード３１−３からクライアント３２−７へデータパケットが送られることになる。以後、中継ノード３１−２にはクライアント３２−７からの受信要求パケットが届かなくなるので、中継ノード３１−２の配信テーブルでクライアント３２−７はタイムアウトし、中継ノード３１−２からクライアント３２−７へはデータパケットが送られなくなる。

この際、中継ノード３１−２でタイムアウトするまでの間、クライアント３２−７宛に、中継ノード３１−２及び３１−３から同じデータパケットが送られることになる。これに関しては予めデータパケットに番号を付けておき、その番号に基づいて中継ノード３１−３で重複したパケットを廃棄し、クライアント３２−７に対して同じパケットを複数送ることを防げば良い。また、クライアント３２−７においても、同じパケットが複数届いた時は廃棄するようにしておけば良い。

データパケットの番号付けに関しては、ＲＦＣ１８８９のReal-Time Transport Protocol（ＲＴＰ）のように、タイムスタンプとシーケンス番号の組で表しても良い。

以上のようにすることで、中継ノードの負荷状態に応じてマルチキャストツリーの構成を自律的に変更することが可能となって負荷分散を図ることができる。

このKeep alive（キープ・アライブ）方式は、クライアントやサーバが移動端末の場合も有用である。例えば、クライアントが移動端末である場合、クライアントが移動することにより、これまで収容されていた中継ノードの収容範囲の外に出た場合、このクライアントは異なる中継ノードに収容されることになる。このような場合でも、クライアントは受信要求パケットを出し続けることによって、新しく収容される中継ノードに登録され、また、これまで収容されていた中継ノードではタイムアウトする。このように、クライアントは収容される中継ノードを意識することなくサーバ３３からのデータパケットを受信し続けることが出来る。

逆に、サーバ３３が移動体である場合、mobile IP（モバイルＩＰ）等の移動体宛のユニキャストを可能にする仕組みがあれば、サーバ３３宛に送出された受信要求パケットは常にサーバ３３が実際に存在する位置に送られる。サーバ３３が移動することにより、異なる中継ノードに収容されることになった場合、各クライアントからサーバに至る経路上の中継ノードに配信テーブルが存在しない時にのみ、新たに配信テーブルが作られることになる。

例えば、図１４に示すように、これまで中継ノード３１−２に収容されていたサーバ３３が移動し、中継ノード３１−４に収容されるようになったものとする。

この時、任意のクライアントからサーバ３３へ至るパス上に、サーバ３３の移動前及び移動後において共通に存在する中継ノード３１−１及び３１−３の配信テーブルは変化せず、新たに上記パスに加わった中継ノード３１−４に配信テーブルが生成され、中継ノード３１−１及び３１−３が登録される。そして、中継ノード３１−４はサーバ３３に対して受信要求パケットを送出する。

各クライアントからサーバ３３に至るパスを外れた中継ノード３１−２には受信要求パケットが送られなくなるので、タイムアウトする。この結果、最終的に、図１５に示すような形態になる。

中継ノード３１−２がタイムアウトするまでの間に、中継ノード３１−１及び３１−３には、中継ノード３１−４及び３１−２を経由してデータパケットが届く可能性があり、この場合、同じデータパケットが重複して届くことになる。これに対しては、上記と同様に、シーケンス番号をデータパケットに付加しておくことにより、中継ノードまたはクライアントで、同じパケットが複数届いた時は廃棄するようにしておけば良い。

Keep alive（キープ・アライブ）方式において、タイムアウトしていない子を持つ中継ノードは、よりサーバに近い中継ノードの子としてタイムアウトしないようにしなければならない。最も簡単な方法は、タイマーによる割り込みを利用する方法である。中継ノード自身にタイマーをしかけておき、決められた時間間隔毎に配信テーブルの各子がタイムアウトしているかどうかチェックしにいく。その結果、一つでもタイムアウトしていない子があれば、サーバに向かって受信要求パケットを送出する。

しかし、この方法では、データパケットや受信要求パケットの処理の途中で、タイマー割り込みが入る可能性があり、場合によってはそのオーバーヘッドが深刻になることが考えられる。

タイマー割り込みを使わない方法としては、受信要求パケットの到着時の処理の一部として実現する方法である。

例えば、クライアントは、時間間隔Ｄ毎に受信要求パケットを送出するものとする。中継ノードは、サーバに向かって最後に受信要求パケットを送出した時刻Ｔを記録しておく。受信要求パケットが到着した時、送信元がまだ配信テーブルに登録されていなければ登録した上で、現在時刻と前記時刻Ｔとを比較し、（現在時刻−Ｔ）≧Ｄならば、サーバに向けて受信要求パケットを送出し、時刻Ｔに現在時刻を設定する。

クライアントから中継ノード（またはサーバ）までのリンクの数の最大値をその中継ノード（またはサーバ）の高さと呼ぶことにすると、中継ノード間またはクライアントと中継ノードとの間の伝送遅延にゆらぎがない場合、上記の方法によれば、高さｈの中継ノード（またはサーバ）に受信要求パケットが到着する時間間隔は、高々ｈ×Ｄである。この理由は次のように、帰納的に示すことが出来る。

ある中継ノードが子から受け取る受信要求パケットの（子毎に測定した場合の）到着間隔が高々Ｄ’であると仮定する。この時、上記の方法によれば、この中継ノードから受信要求パケットを送出する間隔が最大になるのは、前に受信要求パケットを送出し、それから時間Ｄが経過する直前に、ある子からの受信要求パケットが到着し、同じ子から次の受信要求パケットが到着するまで、（離脱やハングアップ等の理由により）他の子からの受信パケットが到着しない場合である。

この場合、結局、前に受信要求パケットを送出してから次に送出するまではＤ＋Ｄ’の時間が経過している。また、子が全てクライアントであるような中継ノードはＤ’がＤに等しい。

中継ノード間またはクライアントと中継ノードとの間の伝送遅延にゆらぎがある場合、伝送遅延の増加・減少の量の絶対値（ゆらぎ）をαとすると、子が全てクライアントであるような中継ノードに到着する受信要求パケットの到着時間間隔は、高々Ｄ＋２αになる。よって、上記と同様な理由により、高さｈの中継ノード（またはサーバ）に受信要求パケットが到着する時間間隔は、高々ｈ×（Ｄ＋２α）ということになる。

高さｈの中継ノード（またはサーバ）では、各子について、その子の高さをｈ−１とすると、前回、その子から受信要求パケットを受信してから、ｈ×（Ｄ＋２α）を越える時間が経過している場合はタイムアウトしたと判断すれば良い。さらに、中継ノードの処理遅延のゆらぎがある場合は、伝送遅延と処理遅延の揺らぎとの和をαとして考えれば良い。

但し、パケットが伝送途中で失われ得る場合、クライアントが受信要求パケットを送出し続けている場合でも、高さｈの中継ノード（またはサーバ）では、ｈ×（Ｄ＋２α）を越える時間間隔で受信要求パケットが到着する可能性がある。その場合、タイムアウトを判断する時間間隔を適宜延ばす必要がある。以下では、パケットが伝送途中で失われることがないと仮定する。

使用するネットワークから、ｈの値の上限Ｈが予めわかっている場合は、全ての中継ノードにおいてＨ×（Ｄ＋２α）をタイムアウトを判断するための値として用いれば良い。

ｈの値の上限Ｈが予めわからない場合、ｈを知るためには、例えば受信要求パケットを利用する方法が考えられる。受信要求パケットには、高さを表す変数ｈを用意しておく。クライアントはｈ＝０として、受信要求パケットを送出する。中継ノードでは、各子から受け取った受信要求パケットに含まれる変数ｈの最大値に１を足した値をｈの値として、受信要求パケットを送出する。このようにすることによって、中継ノードが、ある子から受け取った受信要求パケットのｈの値がｈ*であったとすると、その子は高さｈ*であることがわかる。このように、タイムアウトすべき時間間隔を、ツリーの形状に従って動的に変化させることが出来る。

受信要求パケット到着時の中継ノードでの処理フローを図１６に示す。但し、受信要求パケットに含まれる、ツリーＩＤとソース（送信元）アドレスをそれぞれＮ及びＳとする。図１６中の高負荷時の処理は図１７に示す。

また、データパケット到着時の中継ノードでの処理フローを図１８に示す。図１８中のエントリ削除操作は図１９に示す。但し、データパケットには、ツリーＩＤとソース（送信元）アドレスが含まれており、これをＮ及びＳで表すことにする。また、Ｘはタイムアウトと判断する時間間隔である。即ち、受信要求パケットが到着してから、現在までの経過時間がＸを越える場合はタイムアウトと判断する。図１６及び図１８では、Ｘは固定的に与えられる場合を想定している。

上記の方法は、ユーザがサーバを指定する際、予め決められたサーバ群の中から選択する場合は問題ないが、ユーザがキーボード等を用いてサーバのアドレスを入力する場合のように、サーバの指定間違いが起こり得る時は、実際には存在しないサーバのための配信テーブルが各中継ノードに生成される問題が起こる。このような場合は、受信要求パケットを送出する前に、サーバ宛にサーバ確認パケットを送出し、これに対してサーバの存在を示すパケットがサーバから返ってきた時に初めて、受信要求パケットを送出するようにすれば良い。

この従来技術の実施の形態１では、サーバおよび中継ノードは子から受信要求パケットを受信するとともに、子に向けてデータパケットを配信している。また、クライアント及び中継ノードはサーバに向けてデータパケットの配信を要求している。さらに、クライアント及び中継ノードが親ノードからデータパケットを受信したとき、クライアント及び中継ノードにはサーバからデータパケットが送られてくるように見えている。つまりこの従来技術の実施の形態１では、受信要求パケットやデータパケットを送信するにあたって、親ノードあるいは子の先にどれだけのノードが接続されているかを意識する必要がなく、スケーラビリティの点で優れている。

２．２ 従来技術の実施の形態２
２．１節に示す従来技術の実施の形態１では、サーバの指定間違いが起こり得る時の対策として、クライアントからサーバ確認パケットと受信要求パケットとの２種類のパケットを送出する方法を示したが、本節に示す従来技術の実施の形態２では、クライアントから送出される受信要求パケットのみであり、かつ、サーバの指定間違いが起こり得る時にも対応できる実施の形態を示す。

クライアントから送出された受信要求パケットは、クライアントに最寄りの中継ノードに配信テーブルがある場合は、２．１節に示す従来技術の実施の形態１の場合と同様に最寄りの中継ノードに登録される。最寄りの中継ノードが高負荷状態にあり、クライアントを子として収容できない場合も従来技術の実施の形態１の場合と同様である。

クライアントに最寄りの中継ノードに配信テーブルがない場合、受信要求パケットはサーバに向けて転送される。但し、転送の途中で通過した中継ノードが受信要求パケットに記録される。

受信要求パケットが、配信テーブルを既に持っている中継ノードまたはサーバに到着した時には、クライアントから上記中継ノードまたはサーバに至る経路情報が受信要求パケットに記述されていることになる。上記中継ノードまたはサーバは、この経路情報を含む配信テーブル生成パケットをクライアントに向かって送出する。

配信テーブル生成パケットは、上記の経路情報を逆に辿ることによりクライアントまで配送され、途中通過する中継ノードにおいて、上記サーバに対応する配信テーブルが既にあれば単に転送され、配信テーブルがなければ上記サーバに対応する配信テーブルを生成する。配信テーブル生成パケット内の経路情報に関して、次のノードを配信テーブル生成と同時に登録する方法も可能であるが以下では配信テーブル生成時には何も登録しない手法について説明する。

このように、配信テーブル生成パケットがクライアントに到着するまでに（正確に言うと配信テーブル生成パケットはクライアントの最寄りの中継ノードで廃棄される）、クライアントからサーバに至る経路上で配信テーブルを持たない中継ノードには、新たに配信テーブルが生成される。クライアントは、従来技術の実施の形態１の場合と同様に、予め決められた値以下の時間間隔で受信要求パケットを送出し続ける。そのため、クライアントからサーバに至る経路上の全ての中継ノードに配信テーブルが存在する状態になった後、従来技術の実施の形態１の場合と同様にクライアントが配信テーブルに登録され、必要であれば、中継ノード自身がサーバ宛に受信要求パケットを送出する。

図２０はマルチキャスト通信が行われるネットワーク構成の一例、ここでは４つの中継ノード４１−１，４１−２，４１−３，４１−４に５つの受信ホスト（以下、「クライアント」と呼ぶ）４２−１，４２−２，４２−３，４２−４，４２−５及び１つの送信ホスト４３（本節では、以下、「サーバ」と呼ぶ）がネットワークを介して接続されている状態を示している。

図２０の構成において、例えば図２１に示すように、クライアント４２−３から受信要求パケットが送出され、サーバ４３に至る経路上に中継ノード４１−３及び４１−２があったとする。中継ノード４１−３及び４１−２には配信テーブルがないので、受信要求パケットはサーバ４３まで転送される。但し、この時、転送経路として、中継ノード４１−３及び４１−２が受信要求パケット内に経路情報として書き込まれている。

図２２に示すように、サーバ４３から、この経路情報を含む配信テーブル生成パケットが送出されると、前記経路を逆に辿ることにより中継ノード４１−２及び４１−３に配信テーブルが生成される。仮に、サーバ４３からクライアント４２−３に至る通常の経路が中継ノード４１−４を通るものであっても、配信テーブル生成パケットは中継ノード４１−２及び４１−３を通ることになる。

この後、クライアント４２−３から送出される受信要求パケットより、図２３に示すように、中継ノード４１−３及び４１−２の配信テーブルにクライアント４２−３及び中継ノード４１−３がそれぞれ登録され、中継ノード４１−２からサーバ４３に受信要求パケットが送出される。

続いて、図２４に示すように、クライアント４２−２から受信要求パケットが送出された場合は、中継ノード４１−１に配信テーブルがないため、サーバ４３に向かって転送される。受信要求パケットが中継ノード４１−２に到着すると、中継ノード４１−２には配信テーブルが存在するので、中継ノード４１−２から配信テーブル生成パケットがクライアント４２−２に向かって送出される。図２５に示すように、配信テーブル生成パケットは中継ノード４１−１に配信テーブルを作成し、その後のクライアント４２−２からの受信要求パケットにより、図２６に示すように、クライアント４２−２が中継ノード４１−１の配信テーブルに登録され、中継ノード４１−１は中継ノード４１−２に登録される。

受信要求パケットにより経路情報が蓄えられ、サーバまたは中継ノードからクライアントに送出される配信テーブル生成パケットが、上記経路情報を逆に辿るのは、次の理由による。もし、クライアントからサーバに至る経路とサーバからクライアントに至る経路とが異なる場合、配信テーブル生成パケットが単純にクライアントに向けて送出された場合、配信テーブルはクライアントからサーバに至る経路とは異なる経路に作られることになる。この場合、配信テーブルが作られた中継ノードには、受信要求パケットが到着しないため、すぐにタイムアウトすることになる。また、受信要求パケットは、常に配信テーブル生成パケットを送出した中継ノードまたはサーバまで転送されることになる。このため、データパケットがいつまで経っても到着しないことになる。

従来技術の実施の形態２も従来技術の実施の形態１と同様、クライアントやサーバが移動端末の場合も有用である。クライアントが移動端末である場合、クライアントは受信要求パケットを出し続けることによって新しく収容される中継ノードに登録され、また、これまで収容されていた中継ノードではタイムアウトする。逆にサーバが移動体である場合、mobile IP等の移動体宛のユニキャストを可能にする仕組みがあれば、サーバ宛に送出された受信要求パケットは、常にサーバが実際に存在する位置に送られる。このため、新たに受信要求パケットを受信するようになった中継ノードには配信テーブルが作られ、受信要求パケットが到着しなくなった中継ノードの配信テーブルはタイムアウトする。

具体的な実装例を示す。受信要求パケットは、ツリーＩＤ Ｎと、ソース（送信元）アドレスＳと、ソース（送信元）側隣接ノードアドレスＰと、ソースから現ノードまでの経路情報Ｑを持っている。クライアントは、Ｓ及びＰをクライアントアドレス、Ｑ＝Ｓとして、受信要求パケットをサーバに向かって送出する。受信要求パケットが中継ノードに到着した時、既にツリーＩＤ Ｎに対応する配信テーブルがある場合、Ｓ＝ＰならばＳを登録し、Ｓ≠ＰならばＳに向かってＱを含む配信テーブル作成パケットを送出する。

ツリーＩＤ Ｎに対応する配信テーブルがない場合、Ｐを現中継ノードのアドレスに変え、Ｑに現中継ノードを加えて受信要求パケットを転送する。サーバまで受信パケットが到着した場合は、上記中継ノードの処理のうち、配信テーブルがある場合と同じ処理を行う。

受信要求パケットが中継ノードに到着した時の処理フローを図２７に示す。但し、図２７中の時間間隔Ｄは従来技術の実施の形態１の場合と同様に定義する。また、図２７中の高負荷時の処理は図１７と同じである。配信テーブル生成パケットが中継ノードに到着した時の処理フローを図２８に示す。

従来技術の実施の形態２では、受信要求パケットを送信したホストとデータパケットを送信したホストとを結ぶパス上に存在する中継ノードにのみ配信テーブルが生成されるようになっている。このため、適当なアドレスを宛先アドレスとして配信テーブル生成パケットを送出しても、この宛先アドレスに対応するノードが実際に存在しなければ配信テーブルが生成されることはない。したがって、ネットワーク内ノードのアドレスを隠蔽しておけば、配信テーブル生成パケットのみを用いてノードに無用な配信テーブルを作成させることは困難になる。また、配信テーブル生成パケット以外のパケットは配信テーブルの生成機能を持たないので、当然ながら配信テーブルが中継ノードに生成されることはない。さらに、たとえ、配信テーブル生成パケットを送出するホストと受信要求パケットを送出するホストを用意し、これらホストが互いに協力し合って無用なテーブルを両者の間にあるノードに生成させようとしても効果的な攻撃を行うことは難しい。

２．３ 従来技術の実施の形態３
従来技術の実施の形態３では、クライアントから送出されるのが受信要求パケットのみであり、かつ、サーバの指定間違いが起こり得る時にも対応できる他の実施の形態を示す。

この従来技術の実施の形態３では、クライアントが受信要求パケットを送出し、中継ノードに到着した時、配信テーブルがなければ、送信元を現中継ノードに変えてサーバ宛に転送を行い、配信テーブルがあれば、送信元を登録する。サーバから送出されたデータパケットは、中継ノードに到着すると、その中継ノードに配信テーブルがない場合は空の配信テーブルを生成して消滅し、配信テーブルがある場合は２．１節に示す従来技術の実施の形態１の場合と同様にタイムアウトしていない子に対して、必要ならば複製して、データパケットを転送する。

データパケットによって空の配信テーブルが生成された後に到着した受信要求パケットにより、クライアントからこの中継ノードに至るパス上のクライアント側隣接ノードが配信テーブルに登録される。なぜなら、到着した受信要求パケットの送信元アドレスは、上記クライアント側隣接ノードであるからである。この後に到着したデータパケットにより、上記クライアント側隣接ノードにデータパケットが配送され、その結果、上記クライアント側隣接ノードに空の配信テーブルが生成される。

このように、サーバからクライアントに向かって配信テーブルが生成されていき、やがてクライアントにデータパケットが配送されるようになる。

図２９はマルチキャスト通信が行われるネットワーク構成の一例、ここでは４つの中継ノード５１−１，５１−２，５１−３，５１−４に５つの受信ホスト（以下、本節では、「クライアント」と呼ぶ）５２−１，５２−２，５２−３，５２−４，５２−５及び１つの送信ホスト５３（以下、本節では、「サーバ」と呼ぶ）がネットワークを介して接続されている状態を示している。

図２９の構成において、例えば、クライアント５２−３から受信要求パケットが送出されると、このパケットは各中継ノードでその送信元アドレスを変更されながらサーバ５３まで転送される。サーバ５３は到着した受信要求パケットの送信元が中継ノード５１−２なので、図３０に示すように、中継ノード５１−２宛にデータパケットを送出する。データパケットが到着すると、中継ノード５１−２には配信テーブルがないので、空の配信テーブルが生成される。

その後、到着する受信要求パケットにより、図３１に示すように中継ノード５１−２の配信テーブルには、送信元である、中継ノード５１−３が登録される。その後、データパケットは、図３２に示すように、中継ノード５１−２の配信テーブルに基づいて中継ノード５１−３へ送出される。

同様に中継ノード５１−３でも空の配信テーブルが作られた後、図３３に示すように、受信要求パケットによりクライアント５２−３が登録され、最後には、データパケットがクライアント５２−３に配送される。

クライアントからサーバに向かう経路とサーバからクライアントに向かう経路とが異なる場合、配信テーブルは常にクライアントからサーバへ向かう経路上に作られ、データパケットもその経路上を通過するため、配信テーブルが作られる中継ノードまたはサーバと、受信要求パケットが到着する中継ノードまたはサーバとが異なるようなことは起こらない。
経路情報を持たない配信テーブル生成パケット（この従来技術の実施の形態３ではデータパケットに等しい）を単純にクライアントに向けて送出した場合、宛先アドレスが中継ノードに変更されることはないので、配信テーブルはどの中継ノードにもつくられない。

この従来技術の実施の形態３も従来技術の実施の形態１と同様、クライアントやサーバが移動端末の場合も有用である。クライアントが移動端末である場合、クライアントは受信要求パケットを出し続けることによって新しく収容される中継ノードに登録され、また、これまで収容されていた中継ノードではタイムアウトする。逆にサーバが移動体である場合、mobile IP等の移動体宛のユニキャストを可能にする仕組みがあれば、サーバ宛に送出された受信要求パケットは、常にサーバが実際に存在する位置に送られる。このため、新たに受信要求パケットを受信するようになった中継ノードには配信テーブルが作られ、受信要求パケットが到着しなくなった中継ノードの配信テーブルはタイムアウトする。

受信要求パケット及びデータパケットが中継ノードに到着した場合の処理フローをそれぞれ、図３４及び図３５に示す。図３４における高負荷時の処理は、図１７と同じである。図３５中のエントリ削除操作は図１９と同じである。但し、図３５中のＸは固定的に与えられる場合を仮定している。

従来技術の実施の形態１と同様に、この従来技術の実施の形態３でも、受信要求パケット，データパケットを転送するにあたり、親ノードあるいは子の先にどれだけのノードが接続されているかを意識する必要がないため、スケーラビリティの点で優れている。

また本節に示す従来技術の実施の形態３では、２．２節に示す従来技術の実施の形態２と同様に、受信要求パケットを送信したホストとデータパケットを送信したホストとを結ぶパス上に存在する中継ノードにのみ配信テーブルが生成されるようになっている。したがって、従来技術の実施の形態２と同様に、ネットワーク内のノードのアドレスを隠蔽しておくことにより、配信テーブル生成パケットを送出するホストと受信要求パケットを送出するホストとが協力しない限り、ノードに無用なテーブルが作られることはない。加えて、この従来技術の実施の形態３によれば、たとえ受信要求パケットをサーバ側で覗き見たとしても、サーバに隣接するノードを知ることができるのみであり、当該隣接ノード以外のネットワーク内のノードのアドレスを知り得ない。このため、従来技術の実施の形態２に比べてさらに安全なセキュリティを提供することができる。

２．４ ノードの構成
図３６は従来技術の実施の形態１、２及び３に共通のクライアントの構成を示すもので、図中、６１は時計、６２はパケット生成手段、６３は送信手段、６４は受信手段、６５は映像復号手段、６６は映像表示手段である。

クライアントでは、パケット生成手段６２が時計６１を用いて定期的に受信要求パケットを生成し、送信手段６３によってサーバへ向けて送信する。また、受信手段６４によってデータパケットを受け取ると、映像復号手段６５によってデータパケットにより運ばれてきた映像データを復号し、映像表示手段６６によって映像を表示する。

なお、特に実施の形態１のクライアントの場合、パケット生成手段６２を用いてサーバ確認パケットを生成し、送信手段６３によってサーバへ向けて送信し、その応答パケットを受信手段６４によって受信した場合のみ、前述した受信要求パケットの生成及び送信を行う。

図３７は従来技術の実施の形態１、２及び３に共通の中継ノードの構成を示すもので、図中、７１は時計、７２はノード負荷測定手段、７３は配信テーブル、７４は配信テーブル管理手段、７５はパケット生成手段、７６は送信手段、７７は受信手段、７８はパケット複製手段である。

中継ノードは、受信要求パケットを受信手段７７によって受信すると、ノード負荷測定手段７２によって測定した負荷状態により、負荷が高くない場合は時計７１を参照し、配信テーブル管理手段７４により、図１６（従来技術の実施の形態１の場合）、図２７（従来技術の実施の形態２の場合）、図３４（従来技術の実施の形態３の場合）に示したように配信テーブルを更新し、（必要があれば）パケット生成手段７５によって新たに受信要求パケットを生成し、送信手段７６によってサーバへ向けて送信する。また、データパケットを受信手段７７によって受信すると、図１８（従来技術の実施の形態１、２の場合）、図３５（従来技術の実施の形態３の場合）に示したように該データパケットの属するツリーに対応する配信テーブル７３に登録されている子の数だけ、パケット複製手段７８によりデータパケットを複製し、送信手段７６によって各子へ送信する。

なお、配信テーブル７３の生成は、配信テーブル管理手段７４により、図１６（従来技術の実施の形態１の場合）、図２８（従来技術の実施の形態２の場合）、図３５（従来技術の実施の形態３の場合）に示したように行われ、また、配信テーブル７３及びそのエントリの削除は、配信テーブル管理手段７４により、図１８（従来技術の施の形態１、２の場合）、図３５（従来技術の実施の形態３の場合）に示したように行われる。

図３８は従来技術の実施の形態１、２及び３に共通のサーバの構成を示すもので、図中、８１は時計、８２は配信テーブル、８３は配信テーブル管理手段、８４はパケット生成手段、８５は送信手段、８６は受信手段、８７はパケット複製手段、８８は配信用データ蓄積手段である。

サーバは、中継ノードと同様に、受信要求パケットの送信元及び受信要求パケットの到着時刻を配信テーブル８２に記憶する。この配信テーブル８２への削除・更新・登録などの管理は、配信テーブル管理手段８３が行う。サーバは、配信用データ蓄積手段８８に蓄積してある配信用データを、パケット生成手段８４を用いてパケット化し、配信テーブル８２に登録されているタイムアウトしていない子の数だけ、パケット複製手段８７を用いて複製を作り、送信手段８５を用いてこれらの子に送信する。

なお、特に実施の形態２のサーバの場合、配信テーブル生成パケットはパケット生成手段８４により生成され、送信手段８５により送信される。

２．５ パケットフォーマット
次に、上述した従来技術の実施の形態１〜３に係るパケットのフォーマットについて説明し、その前提としてフロー識別についても説明する。
ネットワーク内では様々なパケットが混在して転送されるため、この従来技術の各実施の形態に特有のパケット（受信要求パケット，データパケット，配信テーブル生成パケット，サーバ確認パケット）をクライアント，中継ノード，サーバが識別するためのフロー識別を行う必要がある。フロー識別を実現するには種々の手法が考えられるが、一例としてここでは特定ポート(「well-known port」と呼ぶ)を用いた場合を例に挙げる。同様の手法としては、ポート８０を利用したＨＴＴＰ(Hyper Text Transfer Protocol)が良く知られている。

ここではプロトコルとしてＵＤＰ(User Datagram Protocol)を想定する。フロー識別のために予め特定ポートを決めておき、パケットのポート番号を参照してこの特定ポートを宛先とするパケットをこの従来技術の各実施の形態に特有のパケットとして識別する。図３９はサーバ１０１，中継ノード１０２及び１０３，クライアント１０４及び１０５を含むネットワークにおける特定ポートを用いたフロー識別の様子を示す図である。同図では、受信要求パケットのソースポートとデータパケットの受信ポートが等しい場合について示してある。また、サーバ１０１のアドレスをＳ，中継ノード１０２及び１０３のアドレスをそれぞれＡ及びＢ、クライアント１０４及び１０５のアドレスをそれぞれＣ１及びＣ２としている。

受信要求パケットは宛先アドレスとしてアドレスＳ，宛先ポートとして上記特定ポートであるポートＰｗ，ソースアドレスとしてアドレスＸ（ここではＡ，Ｂ，Ｃ１，Ｃ２のいずれか），ソースポートとしてポートＰｘ（ここではソースアドレスＸに対応してＰａ，Ｐｂ，Ｐｃ１，Ｐｃ２のいずれか）を持つ。また、データパケットは宛先アドレスとしてアドレスＸ，宛先ポートとしてポートＰｘ，ソースアドレスとしてアドレスＳ，ソースポートとしてポートＰｓを持つ。なお、データパケットのソースアドレスがサーバ１０１のアドレスとなっているのは、配信テーブルがサーバ毎に生成されるために、中継ノードは各配信テーブルがどのサーバに対応するのかをデータパケットのソースアドレスを見て判断するためである。また、各中継ノード１０２，１０３が備える配信テーブル１０６，１０７には、受信要求パケットのソースポートと同一の値が格納される受信ポートのフィールドが、受信要求パケットの送信元（図中では「子」）及び到着時刻の各フィールドと組にされて登録される。

各クライアント及び各中継ノードは、受信要求パケットの宛先ポートを上記特定ポートとして、データパケットを受信したいポートから当該受信要求パケットをサーバ１０１宛てにユニキャストで送出する。例えば、クライアントＣ１が送出する受信要求パケットのソースアドレスはアドレスＣ１，ソースポートはポートＰｃ１であり、宛先アドレス及び宛先ポートは上述した通りである。

受信要求パケットが到着した中継ノードでは、受信要求パケットのソースアドレス及びソースポートを配信テーブルに記録する。また、中継ノードは配信テーブルを参照して、タイムアウトしてない各子の受信ポートに宛ててソースアドレス及びソースポートの組を宛先としたデータパケットをユニキャストする。例えば、中継ノード１０３はクライアント１０４からの受信要求パケットに基づいてソースアドレスＣ１，ソースポートＰｃ１，到着時刻１０：２３：０９を組にして配信テーブル１０７に登録する。また中継ノード１０３は、宛先アドレス，宛先ポートをそれぞれＣ１，Ｐｃ１とし、ソースアドレス及びソースポートとしてサーバ１０１側から送られたそのまま値Ｓ，Ｐｓを持つデータパケットをクライアント１０４に宛てて送出する。

また、中継ノードが受信要求パケットを親ノードに送出する場合はクライアントの場合と同様である。例えば、中継ノード１０３が送出する受信要求パケットでは、宛先アドレス及び宛先ポートはそれぞれ常にアドレスＳ，ポートＰｗであり、ソースアドレスはアドレスＢであり，ソースポートは任意のポート（例えばポートＰｂ）である。これは、受信要求パケットのみが宛先（サーバ）アドレスとは異なるアドレスを持つ中継ノードで処理される必要があるからである。ただし、ソースポートをポートＰｗにした場合、宛先ポートがポートＰｗであるデータパケットがネットワーク中を流れることになるが、宛先とは違う中継ノードではデータパケットを処理しないようにする必要がある。
また、受信要求パケットが到着したサーバ１０１は、ソースアドレス及びソースポートがそれぞれＳ，Ｐｓであり、宛先アドレス及び宛先ポートがそれぞれ中継ノード１０２からの受信要求パケットのソースアドレスＡ及びソースポートＰａに等しいデータパケットを送出する。

なお、あるホスト上に複数のサーバを立ち上げて複数種類のストリームを同時並行的に配信するような形態を採ることも考えられる。ここで、上述した通りフロー識別に特定ポートであるwell-known portを用いているため、ポートに基づいて同一ホスト上の各サーバを区別することはできない。そこで、チャネルＩＤと呼ぶ情報を新たに設けて同一ホスト上の複数のサーバを識別する。このチャネルＩＤは同一ホスト上において一意な値に設定する必要があるが、異なるホスト間では必ずしも一意である必要はない。こうしてサーバドレスとチャネルＩＤとを組にして用いることでサーバ及びマルチキャストツリーを一意に特定することができる。換言すれば、各中継ノードにはサーバアドレス及びチャネルＩＤの組毎に配信テーブルがそれぞれ生成されることになる。なお、チャネルＩＤは例えばパケットのペイロードに載せれば良い。

次に、いま述べたフロー識別を前提としたパケットフォーマットについて説明する。図４０は受信要求パケットのフォーマットの一例を示したものであり、宛先（サーバ）アドレス１１１，宛先（サーバ）ポート１１２，送信元アドレス１１３，送信元ポート１１４，チャネルＩＤ１１５，高さ１１６の各フィールドから構成される。宛先アドレス１１１〜チャネルＩＤ１１５は前述した通りである。高さ１１６は、２．１節の従来技術の実施の形態１で説明したように、中継ノードがマルチキャストツリー状における高さｈを知るために用いられる。なお、図３９を参照して説明したように、宛先アドレス１１１，宛先ポート１１２は常にサーバに宛てたものとなる。

図４１はデータパケットのフォーマットの一例を示したものであって、宛先アドレス１２１，宛先ポート１２２，送信元（サーバ）アドレス１２３，送信元（サーバ）ポート１２４，チャネルＩＤ１２５，データ１２６の各フィールドから構成される。宛先アドレス１２１〜チャネルＩＤ１２５は前述した通りである。データ１２６は配信されるストリーム（コンテンツ）である。なお、図３９を参照して説明したように、送信元アドレス１２３，送信元ポート１２４は常にサーバのものとなる。

３．マルチキャストデータ通信の動作
次に、図２を用いて図１に示す本発明の一実施の形態によるマルチキャストデータ通信の動作を説明する。
ＩＰマルチキャストサーバ２００は、宛先アドレス（マルチキャストアドレス）Ｇ、宛先ＵＤＰポートｐのＩＰマルチキャストパケットを送出する。次に、ＩＰマルチキャストクライアント５００ｂのユーザは、電子メールやＷＥＢサーバなどを通じて得られた、受信マルチキャストアドレスＧと受信ＵＤＰポートｐを、該ＩＰマルチキャストクライアント５００ｂに設定する。すると、ＩＰマルチキャストクライアント５００ｂからマルチキャストへの参加を要求するＩＧＭＰ（Internet Group Management Protocol） membership report（ＩＧＭＰメンバシップレポート）がマルチキャストアドレスＧ宛に送出される。

クライアント側ゲートウェイ４００ｂは、セグメント内を流れるＩＧＭＰ membership reportを監視している。そして、新たなマルチキャストアドレスＧに対するＩＧＭＰ membership reportを発見すると、このマルチキャストアドレスＧのパケットを送出するＩＰマルチキャストサーバ２００に対応したサーバ側ゲートウェイ３００のアドレスを取得し、このマルチキャストアドレスＧとサーバ側ゲートウェイ３００のアドレスの組をアドレス管理表に記録する。
尚、サーバ側ゲートウェイ３００のアドレスの取得の仕方は、種々の方法が想定される。例えば、各ＩＰマルチキャストサーバが使用するマルチキャストアドレスと、このＩＰマルチキャストサーバに対応するゲートウェイのアドレスの組を記述した表であるアドレス変換表を予め各ゲートウェイが保有しておく方法が考えられる。また、マルチキャストアドレスとそれを使用するＩＰマルチキャストサーバに対応するゲートウェイのアドレスの組を管理するサーバを用意して、このサーバに問い合わせる方法も考えられる。以下では、アドレス変換表を予めゲートウェイが保持していることを仮定する。

クライアント側ゲートウェイ４００ｂは、２章に示した受信要求パケット（図４０）にマルチキャストアドレスＧを乗せて、サーバ側ゲートウェイ３００宛に送出を開始する。２章に示した従来技術のマルチキャストデータ通信方法によれば、この受信要求パケットは、配信経路維持のために定期的に送出されなければならない。また、受信を希望するＩＰマルチキャストクライアント５００ｂが消滅したときには、この受信要求パケットの送出を停止する。

２章に示した従来技術のマルチキャストデータ通信方法にあるように、サーバ側ゲートウェイ３００とクライアント側ゲートウェイ４００ｂ間に中継ノード６００を置くことにより、マルチキャストアドレスＧを指定するサーバ側ゲートウェイ３００宛の受信要求パケットが複数の送信元から来た場合は、それが集約される。サーバ側ゲートウェイ３００の隣接中継ノードが一つである場合は、最終的に隣接中継ノードからの受信要求パケットがサーバ側ゲートウェイ３００に到着する。結果として、サーバ側ゲートウェイ３００を根とするツリー状の配信経路が生成されることになる。

サーバ側ゲートウェイ３００は、ＬＡＮ（Ａ）に流れるマルチキャストアドレスＧ宛のＩＰマルチキャストパケットをカプセル化することにより、２章に示した従来技術のマルチキャストデータ通信方法におけるデータパケット（図４１）に変換して、受信要求パケットの送信元に送る。中継ノード６００を経て、データパケットがクライアント側ゲートウェイ４００ｂに到着すると、このデータパケットを脱カプセル化することにより、ＩＰマルチキャストパケットに再変換してＬＡＮ（Ｂ）に送出する。この結果、ＩＰマルチキャストクライアント５００ｂは、ＩＰマルチキャストパケットを受信することが出来る。以上が一連の流れである。

上記により、２章に示した従来技術のマルチキャストデータ通信方法における「サーバ」が、ストリームデータを「配信用データ蓄積手段８８」から取得する代わりに、ＬＡＮセグメントに流れるＩＰマルチキャストパケットとして取得するサーバ側ゲートウェイに、また、２章に示した従来技術のマルチキャストデータ通信方法における「クライアント」が、受信したデータパケットを、ストリームデータを画像や音声として再現する代わりに、ＩＰマルチキャストパケットに変換してＬＡＮセグメントヘ流すクライアント側ゲートウェイに置き換えられたと考えることが出来る。

４．各ノードの構成
次に、図１に示す実施の形態による各ノードの構成について説明する。
図３にサーバ側ゲートウェイの構成を示す。
サーバ側ゲートウェイ３００は、時計３８１、配信テーブル３８２、配信テーブル管理手段３８３、パケット生成手段３８４、送信手段３８５、受信手段３８６、パケット複製手段３８７、及び、パケット変換手段３８８により構成される。点線に囲まれた部分は、２章に示した従来技術のマルチキャストデータ通信方法におけるサーバ（図３８）との共通の構成を表している。これは、前述の通り、ストリームデータを「配信用データ蓄積手段８８」から取得する代わりに、ＬＡＮセグメントに流れるＩＰマルチキャストパケットとして取得する機能と、それを図４１に示す従来技術のデータパケットに変換する手段が加わったと考えられるからである。

サーバ側ゲートウェイ３００は、受信要求パケットを受信手段３８６によって受信すると、配信テーブル管理手段３８３が、時計３８１を参照してこの受信要求パケットの送信元及び受信要求パケットの到着時刻を配信テーブル３８２に記憶する。この配信テーブル３８２への削除・更新・登録などの管理は、配信テーブル管理手段３８３が行う。

また、受信手段３８６により受信されたＩＰマルチキャストパケットは、２章に示した従来技術のマルチキャストデータ通信方法におけるデータパケット（図４１）のペイロードに搭載され、パケット生成手段３８４によりヘッダが付け加えられることにより、データパケットが生成される。そして、パケット複製手段３８７は、配信テーブル３８２に登録されているタイムアウトしていない子の数だけ、パケット生成手段３８４が生成したデータパケットの複製を作り、送信手段３８５を用いて、これらの子に送信する。
なお、このとき、図４１に示すデータパケットのフォーマットのチャネルＩＤ１２５にはマルチキャストアドレスが、データ１２６にはＩＰマルチキャストパケットがそのまま搭載される。また、宛先アドレス１２１には、受信要求パケットの送信元が、宛先ポート１２２には、受信要求パケットの送信元ポートが設定される。また、送信元アドレス１２３には、サーバ側ゲートウェイ３００のアドレスが設定され、送信元ポート１２４は、任意に設定される。

例えば、このデータパケットをＵＤＰパケットとして構成した場合、ＩＰマルチキャストパケットを搭載した結果、Ethernet（登録商標）フレームの最大サイズを超えたとしても、通常のＩＰ処理系であれば、そのような場合には、ＩＰフラグメントを行うため、問題なく送信することが出来る。
また、データパケットの送信元ポートをマルチキャストアドレスごとに予め決めておくことにより、この送信元ポートと送信元アドレスの組で、ＩＰマルチキャストアドレスを特定することができる。従って、送信元アドレスとポートの組からマルチキャストアドレスヘの対応関係をクライアント側ゲートウェイに予め与えておくことにより、２章に示した従来技術のマルチキャストデータ通信方法に示されるように、ＩＰヘッダの宛先アドレスを直接書き換える方法も動作可能となる。

図４は、クライアント側ゲートウェイ４００の構成を示す図である。
クライアント側ゲートウェイ４００は、受信手段４０１、ＩＧＭＰ制御手段４０２、ＩＧＭＰ管理表４０３、アドレス管理表制御手段４０４、アドレス変換表４０５、アドレス管理表４０６、受信要求パケット生成手段４０７、時計４０８、送信手段４０９、及び、パケット変換手段４１０から構成される。

受信手段４０１がＩＰマルチキャストクライアント５００からＩＧＭＰ membership reportを受信すると、ＩＧＭＰ制御手段４０２は、このＩＧＭＰ membership reportの宛先となっているマルチキャストアドレスが、既にＩＧＭＰ管理表４０３に登録されているか否かのチェックを行う。登録されている場合、ＩＧＭＰ管理表４０３にこのＩＧＭＰ membership reportを受信した最終受信時刻等が記録される。登録されていなければ、ＩＧＭＰ管理表４０３にマルチキャストアドレス（グループアドレス）とＩＧＭＰ membership reportの受信時刻を登録する。なお、ＩＧＭＰ管理表４０３とは、ＩＧＭＰ membership reportの受信により、マルチキャストパケットの受信を希望するＩＰマルチキャストクライアント５００の存在が確認されているマルチキャストアドレスを管理する表である。

ＩＧＭＰ管理表４０３の例を表１に示す。

以後の処理は、タイムアウトを利用して行う。すなわち、ＩＧＭＰ管理表４０３に登録されているが、一定時間以上、ＩＧＭＰ membership reportを送信してこないマルチキャストアドレスに対しては、このマルチキャストパケットの受信を希望するか否かを問い合わせるＩＧＭＰ membership query（ＩＧＭＰメンバシップクエリー）を自身の属するＬＡＮセグメント上のＩＰマルチキャストクライアント５００に送信する。そして、少なくとも一つのＩＧＭＰ membership reportが返送された場合には、ＩＧＭＰ管理表４０３の最終受信時刻を更新する。また、返送されなければ、ＩＧＭＰ管理表４０３へのエントリを削除する。なお、ＩＧＭＰ管理表４０３に対するエントリの削除及び追加は、全てＩＧＭＰ制御手段４０２が行う。

ＩＧＭＰ管理表４０３に新しいエントリが登録されると、アドレス管理表制御手段４０４は、アドレス変換表４０５を参照することによって、新たなエントリのマルチキャストアドレス宛のマルチキャストパケットを送信するＩＰマルチキャストサーバ２００に対応したサーバ側ゲートウェイのアドレスを取得し、これらの組をアドレス管理表４０６に記録する。アドレス変換表４０５とは、マルチキャストアドレスと、このマルチキャストアドレス宛のマルチキャストパケットを送信するＩＰマルチキャストサーバ２００に対応したサーバ側ゲートウェイ３００のアドレスを記述した表であり、予め与えられる。また、アドレス管理表４０６とは、ＩＧＭＰ管理表４０３に存在するエントリのマルチキャストアドレス宛のマルチキャストパケットを送信するＩＰマルチキャストサーバ２００に対応したサーバ側ゲートウェイ３００のアドレスを示す表である。

アドレス変換表４０５の例を表２に示す。

また、アドレス管理表４０６の例を表３に示す。

さらに、受信要求パケット生成手段４０７は、アドレス管理表４０６を参照して、受信要求パケット（図４０）に上記グループアドレス（マルチキャストアドレス）を載せ、送信手段４０９によりサーバ側ゲートウェイ３００に対して送信する。この受信要求パケットの送信は、時計４０８を用いてアドレス管理表４０６に存在する各エントリについて定期的に行う。また、アドレス管理表４０６のエントリは、ＩＧＭＰ管理表４０３の対応するエントリと同期させるものとする。すなわち、ＩＧＭＰ管理表４０３にエントリが追加されれば、同時にアドレス管理表４０６にも対応するエントリが追加され、ＩＧＭＰ管理表４０３からエントリが削除されれば、同時にアドレス管理表４０６の対応するエントリも削除するものとする。

なお、このとき、図４０に示す受信要求パケットのフォーマットのチャネルＩＤ１１５には、ＩＧＭＰ membership reportの宛先となっているマルチキャストアドレスが書き込まれる。また、宛先アドレス１１１には、サーバ側ゲートウェイ３００のアドレスが、送信元アドレス１１３には、クライアント側ゲートウェイ４００のアドレス（２章に示した従来技術のマルチキャストデータ通信方法に示されるように中継ノードで書き換えられる可能性がある）が設定される。宛先ポート１１２には、２章に示す従来技術の通信方式によるパケットであることを示す特定のポートが設定され、送信元ポート１１４には、任意のポートが設定される。そして、この送信元ポート１１４に設定されたポートには、サーバ側ゲートウェイ３００からのデータパケットが到着することになる。２章に示す従来技術のマルチキャストデータ通信方法に従って、データパケットが到着すると、パケット変換手段４１０は、このデータパケットをＩＰマルチキャストパケットに変換してＬＡＮセグメントに送出する。

なお、中継ノード６００の構成は、３．４節に示す従来技術の実施の形態１、２及び３に共通の中継ノードの構成（図３７）と同じである。

５．その他
なお、ＩＰマルチキャストサーバ２００とサーバ側ゲートウェイ３００が同じ装置上で実現されている場合には、移動端末として動作しうる。

上記により、中間部に従来技術のユニキャストを用いたマルチキャストデータ通信方法を使用し、かつ、従来技術において、ゲートウェイ間がこれらを１対１に結ぶユニキャストであるため、クライアントが多数ある場合、サーバにフローが集中するという問題を解決しながら、マルチキャスト非対応網を経由したマルチキャスト対応ネットワーク間のマルチキャストデータ通信を可能にした。

なお、上述したＩＰマルチキャスト対応サーバ（ＩＰマルチキャストサーバ２００）、ＩＰマルチキャスト対応クライアント（ＩＰマルチキャストクライアント５００ｂ、５００ｃ），ゲートウェイ（サーバ側ゲートウェイ３００、クライアント側ゲートウェイ４００ｂ，４００ｃ）内の各部が具備している機能は、実際にはいずれもコンピュータによって実現することが可能である。そのためには、本実施の形態の動作をコンピュータにより実行させるためのプログラムをコンピュータにより読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行させることにより、本実施形態の機能を実現にしてもよい。ここでいうコンピュータシステムとは、ＯＳ（オペレーティングシステム）に加えて周辺機器等のハードウェアを含むものとする。またＷＷＷ（World Wide Web）システムを利用している場合であれば、コンピュータはホームページ提供環境（あるいはその表示環境）を含むものとする。上記プログラムは、前述した機能の一部を実現するものでも良く、さらにコンピュータにすでに記録されているプログラムとの組み合わせでかかる機能を実現するもの（いわゆる差分プログラム）でも良い。コンピュータ読み取り可能な記録媒体は、フレキシブルディスク，光磁気ディスク，ＲＯＭ（読み出し専用メモリ），ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置を含む。さらに、コンピュータ読み取り可能な記録媒体は、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間だけ動的にプログラムを保持するものや、コンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。そして、以上のことはこれ以後に説明する各実施の形態やその応用例においても全く同様である。

次に図面を参照して本発明の第２の実施形態について説明する。図４２は、本実施形態におけるＩＰマルチキャスト対応端末を接続する場合のネットワーク構成例を示す。
図４２に示すように、３つのローカルネットワーク、ＬＡＮ（Ａ）、ＬＡＮ（Ｂ）、ＬＡＮ（Ｃ）がＩＰマルチキャスト非対応のネットワークにより接続されている。ＩＰマルチキャスト対応のサーバまたはクライアントが接続している各ＬＡＮセグメントにゲートウェイを配置する。サーバ側ゲートウェイ３００は、そのＬＡＮの入り口に設置する。
すなわち、本実施形態のマルチキャストデータ通信システムが第1の実施形態と異なる点は、サーバ側ゲートウェイ３００をＬＡＮ（Ａ）とネットワーク７００との接続点（ネットワークの境）に設ける点である。

ゲートウェイは、ＩＰマルチキャスト対応クライアントが受信要求をしている間だけ上述の２章に示した従来技術の方法による配信経路を生成・維持し、かつ、サーバが送出するＩＰマルチキャストをユニキャストに変換して上記配信経路に送出する機能を持つ装置である。
図４２の例では、各ＬＡＮは、１セグメントからなるが、複数セグメントからなるＬＡＮにおいては、各セグメントにゲートウェイを配置する。ゲートウェイは、サーバ側のセグメントとクライアント側のセグメントでは、機能が異なるが、例えば、個人用計算機を、その時々により、サーバにしたり、クライアントにしたりする場合は、サーバ側ゲートウェイ３００とクライアント側ゲートウェイの両方を同じセグメントに配置すればよい。サーバ側ゲートウェイ３００とクライアント側ゲートウェイは、同じホスト上で動作していても良い。

図４２のＬＡＮ（Ａ）、ＬＡＮ（Ｂ）、ＬＡＮ（Ｃ）に配置されたゲートウェイを、それぞれ、ゲートウェイＰＡ、ゲートウェイＰＢおよびゲートウェイＰＣと呼ぶことにする。
また、ＬＡＮ（Ａ）に配置されたIP マルチキャスト対応サーバをＳＡ、ＬＡＮ（Ｂ）およびＬＡＮ（Ｃ）に配置されたIP マルチキャスト対応クライアントを、それぞれ、ＣＢおよびＣＣと呼ぶことにする。

次に図４３を用いて動作を説明する。ＳＡは、宛先アドレスＧ、宛先ＵＤＰサポートｐのＩＰマルチキャストパケットを送出する。
次に、ＩＰマルチキャスト対応クライアントＣＢのユーザは、電子メールやＷＥＢサーバなどを通じて得られた、受信マルチキャストアドレスＧとIP マルチキャストサーバアドレスＳＡと受信ＵＤＰポートｐを、該クライアントに設定すると、IGMP membership reportがＧ宛に送出される。
このIGMP membership reportには、受信マルチキャストアドレスＧとIP マルチキャストサーバアドレスＳＡが記載されている。クライアント側ゲートウェイＰＢは、セグメント内を流れるIGMP membership reportを監視しており、新たなマルチキャストアドレスＧに対するIGMP membership reportを発見すると、アドレス管理表にＧとＳＡの組を記録する。
クライアント側ゲートウェイＰＢは、上述の２章に示した従来技術における受信要求パケットにＧを乗せて、ＳＡ宛に送出を開始する。

上述の２章に示した従来技術によれば、この受信要求パケットは、配信経路維持のために定期的に送出されなければならない。また、受信を希望するクライアントが消滅したときには、この受信要求パケットの送出を停止する。
上述の２章に示した従来技術にあるように、ＰＡとＰＢ間に中継ノードをおくことにより、マルチキャストアドレスＧを指定する、ＳＡ宛の受信要求パケットが複数の送信元から来た場合は、それが集約される。
ＰＡの隣接中継ノードが一つである場合は、最終的に隣接中継ノードからの受信要求パケットがＰＡに到着する。ここで、ＰＡは受信要求パケットを受信するがＳＡには転送しない。結果として、ＰＡを根とするツリー上の配信経路が生成される。
ＰＡは、ＳＡがＬＡＮ（Ａ）に送出したＧ宛のＩＰマルチキャストパケットをカプセル化することにより上述の２章に示した従来技術におけるデータパケットに変換して、受信要求パケットの送信元に送る。
中継ノードを経て、データパケットがＰＢに到着すると、脱カプセル化することにより、ＩＰマルチキャストパケットに再変換し、ＬＡＮ（Ｂ）に送出する。この結果、ＣＢは、ＳＡからのＩＰマルチキャストパケットを受信することができる。以上が一連の流れである。

上記の説明により、上述の２章に示した従来技術における「サーバ」が、ストリームデータを「配信用データ蓄積手段」から取得する代わりに、ＬＡＮセグメントに流れるＩＰマルチキャストパケットとして取得する（サーバ側）ゲートウェイに、また、上述の２章に示した従来技術における「クライアント」が、受信したデータパケットを、ストリームデータを画像や音声として再現する代わりに、ＩＰマルチキャストパケットに変換し、ＬＡＮセグメントへ流す（クライアント側）ゲートウェイに置き換えられたと考えることができる。

次に、各装置の構成について説明する。
図４５にサーバ側ゲートウェイ３００の構造を示す。網掛けの部分は、図４４に示す、上述の２章に示した従来技術におけるサーバの構成図との共通部分を表している。
これは、前述の通り、ストリームデータを「配信用データ蓄積手段」から取得する代わりに、ＬＡＮセグメントに流れるＩＰマルチキャストパケットとして取得する機能とそれを上述の２章に示した従来技術におけるデータパケットに変換する手段が加わったと考えられるからである。
すなわち、受信手段３８６により、受信されたＩＰマルチキャストパケットは、上述の２章に示した従来技術におけるデータパケットのペイロードに搭載され、パケット生成手段３８４によりヘッダを付け加えることによりデータパケットが生成される。

図４１は、上述の２章に示した従来技術におけるデータパケットのフォーマットであるが、チャンネルＩＤフィールドにはマルチキャストアドレスを、データフィールドにはＩＰマルチキャストパケットをそのまま搭載する。宛先アドレスは、受信要求パケットの送信元であり、宛先ポートは、受信要求パケットの送信元ポートである。また、送信元アドレスは、サーバ側ゲートウェイ３００アドレスであり、送信元ポートは、任意である。
例えば、上述の２章に示した従来技術におけるデータパケットをＵＤＰパケットとして構成すれば、ＩＰマルチキャストパケットを搭載した結果、Etherフレームの最大サイズを超えたとしても、通常のＩＰ処理系であれば、そのような場合、ＩＰフラグメントを行うので、問題なく送ることができる。

データパケットの送信元ポートについては、マルチキャストアドレスごとに予め決めておくことにより、この送信元ポートと送信元アドレスの組で、ＩＰマルチキャストアドレスを特定することができる。従って、送信元アドレスとポートの組からマルチキャストアドレスへの対応関係をクライアント側ゲートウェイに予め与えておくことにより、特許文献１に示されるように、ＩＰヘッダの宛先アドレスを直接書き換える方法でも動作可能である。

次に、図４６をもとにクライアント側ゲートウェイ４００の構成について説明する。クライアント５００からIGMP membership reportを受信手段４０１により受信すると、IGMP制御手段４０２により、宛先となっているマルチキャストアドレスとマルチキャストサーバアドレスが、既にIGMP管理表４０３に登録されているかチェックを行う。登録されていれば、最終受信時刻等が、IGMP管理テーブルに記録される。登録されていなければ、IGMP管理表４０３にマルチキャストアドレスとマルチキャストサーバアドレスとIGMP membership reportの受信時刻を登録する。IGMP管理表４０３とは、IGMP membership reportの受信により、受信を希望するクライアントの存在が確認されているマルチキャストアドレスを管理する表である。
その例を図４７に示す。以後の処理は、タイムアウトを利用して行う。つまり、一定時間以上、IGMP membership reportを送ってこないマルチキャストアドレスに対しては、IGMP membership queryを送り、一つのIGMP membership reportも返ってこなければ、IGMP管理表４０３のエントリを削除する。IGMP管理表に対するエントリの削除及び追加は、全てIGMP制御手段４０２が行う。

受信要求パケット生成手段４０７は、IGMP管理表４０３を参照して、上述の２章に示した従来技術における受信要求パケットにマルチキャストグループアドレスを載せ、マルチキャストサーバに対して、送信する。この受信要求パケットの送信は、IGMP管理表４０３に存在する各エントリについて定期的に行う。
図１９に上述の２章に示した従来技術の方法における受信要求パケットのフォーマットを示す。チャンネルＩＤフィールドには、IGMP membership reportの宛先となっているマルチキャストアドレスを書き込む。宛先アドレスは、マルチキャストサーバ２００のアドレスであり、送信元アドレスは、クライアント側ゲートウェイ４００のアドレス（上述の２章に示した従来技術に示されるように中継ノードで書き換えられる可能性がある）であり、宛先ポートは、上述の２章に示した従来技術の方式によるパケットであることを示す特定のポートであり、送信元ポートは、任意のポートである。
送信元ポートに、サーバ側ゲートウェイ３００からのデータパケットが到着することになる。上述の２章に示した従来技術の方法に従って、データパケットが到着すると、パケット変換手段４０９により、ＩＰマルチキャストパケットに変換してＬＡＮセグメントに送出する。

以上説明したように、本発明によれば、クライアントが多数ある場合においても、サーバにフローが集中するという問題を解決しながら、マルチキャスト非対応網を経由したマルチキャスト対応ネットワーク間のマルチキャストデータ通信を可能とした。

本発明の一実施の形態によるマルチキャストデータ通信方法を用いてＩＰマルチキャスト対応端末を接続する場合のネットワーク構成例を示す図である。 同実施の形態によるマルチキャストデータ通信の動作を示す図である。 同実施の形態によるサーバ側ゲートウェイの構成を示す図である。 同実施の形態によるクライアント側ゲートウェイの構成を示す図である。 従来技術の実施の形態１に関わるマルチキャスト通信におけるネットワーク構成の一例を示す説明図である。 中継ノードで生成され更新される従来技術の実施の形態１に関わる配信テーブルの一例を示す説明図である。 従来技術の実施の形態１に関わる中継ノードからデータがユニキャストされる過程の説明図である。 従来技術の実施の形態１に関わる中継ノードからデータがユニキャストされる過程の説明図である。 従来技術の実施の形態１に関わる更新後の配信テーブルの一例を示す図である。 従来技術の実施の形態１に関わるマルチキャスト通信におけるネットワーク構成の他の例を示す図である。 図１０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図１０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図１０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図１０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図１０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 従来技術の実施の形態１に関わる受信要求パケット到着時の処理を示すフローチャートである。 図１６中の高負荷時の処理を示すフローチャートである。 従来技術の実施の形態１に関わるデータパケット到着時の処理を示すフローチャートである。 図１８中のエントリ削除操作の処理を示すフローチャートである。 従来技術の実施の形態２に関わるマルチキャスト通信におけるネットワーク構成の一例を示す図である。 図２０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２０のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 本発明の実施の形態２に関わる受信要求パケット到着時の処理を示すフローチャートである。 従来技術の実施の形態２に関わる配信テーブル生成パケット到着時の処理を示すフローチャートである。 従来技術の実施の形態３に関わるマルチキャスト通信におけるネットワーク構成の一例を示す図である。 図２９のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２９のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２９のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 図２９のネットワーク構成におけるマルチキャストツリーの構成過程の説明図である。 従来技術の実施の形態３に関わる受信要求パケット到着時の処理を示すフローチャートである。 従来技術の実施の形態３に関わるデータパケット到着時の処理を示すフローチャートである。 従来技術の実施の形態１乃至３に関わるクライアントの構成例を示すブロック図である。 従来技術の実施の形態１乃至３に関わる中継ノードの構成例を示すブロック図である。 従来技術の実施の形態１乃至３に関わるサーバの構成例を示すブロック図である。 従来技術の実施の形態１乃至３における特定ポートを用いたフロー識別の様子を示す図である。 従来技術の実施の形態１乃至３における受信要求パケットのフォーマットの一例を示した図である。 従来技術の実施の形態１乃至３におけるデータパケットのフォーマットの一例を示した図である。 本発明の第2の実施形態によるマルチキャストデータ通信方法を用いてＩＰマルチキャスト対応端末を接続する場合のネットワーク構成例を示す図である。 同実施の形態によるマルチキャストデータ通信の動作を示す図である。 特願２００２−１３３２８６によるサーバの構成を示す図である。 同実施の形態によるサーバ側ゲートウェイ３００の構成を示す図である。 同実施の形態によるクライアント側ゲートウェイ４００の構成を示す図である。 ＩＧＭＰ管理テーブルのテーブル構成例を示す図である。

符号の説明

２１，３１−１〜３１−４，４１−１〜４１−４，５１−１〜５１−４，１０２，１０３，６００：中継ノード
２２−１〜２２−４，３２−１〜３２−７，４２−１〜４２−５，５２−１〜５２−５，１０４，１０５：受信ホスト（クライアント）
３３，４３，５３，１０１：送信ホスト（サーバ）
６１，７１，８１，３８１，４０８：時計
６２，７５，８４，３８４：パケット生成手段
６３，７６，８５，３８５，４０９：送信手段
６４，７７，８６，３８６，４０１：受信手段
６５：映像復号手段
６６：映像表示手段
７２：ノード負荷測定手段
７３，８２，１０６，１０７，３８２：配信テーブル
７４，８３，３８３：配信テーブル管理手段
７８，８７，３８７：パケット複製手段
８８：配信用データ蓄積手段
１１１，１２１：宛先アドレス
１１２，１２２：宛先ポート
１１３，１２３：送信元アドレス
１１４，１２４：送信元ポート
１１５，１２５：チャネルＩＤ
１１６：高さ
１２６：データ
２００：ＩＰマルチキャストサーバ
３００：サーバ側ゲートウェイ
３８８：パケット変換手段
４００，４００ｂ，４００ｃ：クライアント側ゲートウェイ
４０２：ＩＧＭＰ制御手段
４０３：ＩＧＭＰ管理表
４０４：アドレス管理表制御手段
４０５：アドレス変換表
４０６：アドレス管理表
４０７：受信要求パケット生成手段
４１０：パケット変換手段
５００ｂ，５００ｃ：ＩＰマルチキャストクライアント

Claims (16)

1. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムであって、
   前記クライアント側ゲートウェイは、
   前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、
   前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段とを備え、
   前記サーバ側ゲートウェイは、
   前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段を備える、
   ことを特徴とするマルチキャストデータ通信システム。
2. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるマルチキャストデータ通信方法であって、
   前記クライアント側ゲートウェイが、
   前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信し、
   前記サーバ側ゲートウェイが、
   前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出し、
   前記クライアント側ゲートウェイが、
   前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出する、
   ことを特徴とするマルチキャストデータ通信方法。
3. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイであって、
   前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、
   前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段と、
   を備えることを特徴とするクライアント側ゲートウェイ。
4. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイであって、
   前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段、
   を備えることを特徴とするサーバ側ゲートウェイ。
5. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムであって、
   前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、
   前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップと、
   をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラム。
6. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムであって、
   前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、
   をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラム。
7. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、
   前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバが接続されるセグメント上の前記サーバ側ゲートウェイへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、
   前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップと、
   の各処理をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体。
8. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバ及びサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、
   前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、
   をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体。
9. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
   マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
   前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムであって、
   前記クライアント側ゲートウェイは、
   前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、この参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、
   前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段とを備え、
   前記サーバ側ゲートウェイは、
   前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段を備える、
   ことを特徴とするマルチキャストデータ通信システム。
10. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるマルチキャストデータ通信方法であって、
    前記クライアント側ゲートウェイが、
    前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信し、
    前記サーバ側ゲートウェイが、
    前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出し、
    前記クライアント側ゲートウェイが、
    前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出する、
    ことを特徴とするマルチキャストデータ通信方法。
11. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイであって、
    前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信する受信要求パケット生成手段と、
    前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するパケット変換手段と、
    を備えることを特徴とするクライアント側ゲートウェイ。
12. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイであって、
    前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出する手段、
    を備えることを特徴とするサーバ側ゲートウェイ。
13. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムであって、
    前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、
    前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップと、
    をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラム。
14. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムであって、
    前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、
    をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラム。
15. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、
    前記マルチキャストクライアントからマルチキャストへの参加要求を受信している間だけ、参加要求が示すマルチキャストアドレス宛のマルチキャストパケットを送信する前記マルチキャストサーバへ、該マルチキャストアドレスを含んだ前記受信要求を定期的に送信するステップと、
    前記サーバ側ゲートウェイからのユニキャストパケットを受信し、このユニキャストパケットをマルチキャストパケットに変換して自身が接続するネットワークセグメントに送出するステップと、
    の各処理をコンピュータに実行させることを特徴とするクライアント側ゲートウェイのコンピュータプログラムを記録した記録媒体。
16. マルチキャストパケットを受信するマルチキャストクライアント及びクライアント側ゲートウェイが接続されるネットワークセグメントと、
    マルチキャストパケットを送信するマルチキャストサーバが接続されるとともに、入り口にサーバ側ゲートウェイが接続されるネットワークセグメントとを、
    前記クライアント側ゲートウェイから前記サーバ側ゲートウェイ宛の受信要求を受け、該クライアント側ゲートウェイから該サーバ側ゲートウェイヘの配信経路を生成し、該受信要求を受信している間この配信経路を維持する中継ノードを含むユニキャスト通信が可能なネットワークを介して接続してなるマルチキャストデータ通信システムに用いられるサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体であって、
    前記マルチキャストクライアントが接続されるネットワークセグメント上の前記クライアント側ゲートウェイからの前記受信要求を受信している間だけ、該受信要求の送信元のノードに対し、該受信要求が示すマルチキャストアドレス宛に自身が接続するネットワークセグメント上の前記マルチキャストサーバが送出したマルチキャストパケットを、ユニキャストパケットに変換して送出するステップ、
    をコンピュータに実行させることを特徴とするサーバ側ゲートウェイのコンピュータプログラムを記録した記録媒体。
    

Images