JP4920157B2

JP4920157B2 - マルチキャスト・データを受信する方法

Info

Publication number: JP4920157B2
Application number: JP2001552231A
Authority: JP
Inventors: エムダイアー，ダグラス; エーボレイ，デイヴィッド
Original assignee: エクスィジェントインターナショナルインコーポレイテッド
Priority date: 2000-01-13
Filing date: 2001-01-04
Publication date: 2012-04-18
Anticipated expiration: 2021-01-04
Also published as: WO2001052080A1; CA2391473A1; JP2003519872A; EP1247193B1; US6349340B1; EP1247193A1; AU2001227604A1; ATE557493T1; EP1247193A4

Description

【０００１】
［技術分野］
本発明は、ネットワーク・データ配信に関し、特にマルチキャスト技術を利用するネットワークにおいて改善された実効性を提供する方法に関する。
【０００２】
［関連技術の説明］
従来のデータ・ネットワーク配信では、周知のネットワーク・プロトコルを利用して、１つ又はそれ以上のサーバ・ノードおよび複数のクライアント・ノードが互いに通信を行う。一般に、配信されるデータ・アプリケーションは、ネットワークに結合されたクライアント・ノードに対する中央配信および統合を行うことが可能なサーバ・ノードを包含する。現在のところ、クライアント・ノードは２つの方向に向かいつつあり：データの小さな部分集合で動作し又は監視する「シン・クライアント(thin-client)」と、ネットワークにおける大量のリアル・タイム情報のデータ削減、データ記録その他の同様な動作を実行する「ファット・クライアント(fat-client)」である。後者に関し、重要な処理がファット・クライアント内で発生することが可能であり、高速、リアル・タイムの大きな部分集合を取り扱う必要がある。
【０００３】
配信データ・ネットワークにおける高速データの取り扱いは、２つの基本的な手法を包含する。非常に一般的な手法は、「クライアント・ベース(client-based)」手法と呼ばれるものであり、クライアント・ノードが、サーバ・ノードに、所望のデータにおける興味の対象を通知する。実際、クライアント・ベース手法は、加入−未加入形態(subscribe-unsubscribe-paradigm)を改善する。クライアント・ベース手法を利用すると、各々の関心のある加入クライアントに個別にデータ・パケットを配信することが可能である。しかしながら、ネットワーク要求が多くなるにつれて、サーバーに過剰に負荷を与える傾向がある(overload)。特に、追加的なクライアント・ノードがネットワークに負荷される場合に、対象のクライアント・ノードの各々にデータ・パケットを個々に配信する必要があるだけでなく、サーバは付加的な加入クライアント・ノードの各々にもデータ・パケットを個々に配信する必要がある。したがって、クライアント・ノード・リストが大きくなるにつれて、サーバの負担も大きくなる。
【０００４】
第２の手法は、「サーバ・ベース(server-based)」手法であり、ネットワークにある総てのクライアント・ノードにブロードキャスト・データ・パケットを提供するものである。マルチキャスト技術を利用することにより、サーバは各データ・パケットを一度だけ送信する。それに対応して、総てのクライアント・ノードは、１つずつ送信されたデータ・パケットを同時に受信する。特に、データ・パケットをブロードキャスト配信するために、サーバは、クラアイント・ノードの具体的な物理アドレスではなく、特定のマルチキャスト・セッションを指定するマルチキャスト宛先アドレスに、データ・パケットを送信する。ブロードキャスト・データを受信するために、関心のあるクラアイント・ノードは、サーバではなくマルチキャスト・アドレスに加入するだけである。マルチキャスト技術を利用することにより、クライアント数が増加しても、サーバは、増加したクライアント数を増加したデータ・パケット転送数に合わせる必要がない。その結果、データ・パケットの内容によらず、サーバには過剰な負荷が課せられないようになり、各クライアント・ノードは、各データ・パケットの受領時に望まないデータをフィルタ処理する(filter)必要がある。
【０００５】
一般にクライアント・ノードはブロードキャスト・データのほとんどに関心がなく、その結果、クライアントは、望まないデータ・パケットを識別および破棄するのに相当なプロセッサ資源を消費する。特に、ブロードキャスト・データを受信するクライアント・ノードにおけるネットワーク・アプリケーションは、受信したデータ・パケットの各々を識別し、同時に破棄すべきか否かを判定しなければならない。したがって、前述した手法は、上述したプロセッサ・オーバーヘッドに起因して、サーバが高速データ伝送レートでより多くのクライアント・ノードにデータを提供可能にするが、結局その手法は、望まないデータ・パケットをフィルタ処理するために、クライアント・ノードの能力を制限する。特に、今日のコンピュータはより高速な処理を達成し、ネットワーク帯域も大きく、ネットワーク・ユーザはそのネットワークを通じてより多くのデータをブロードキャストするが、クライアント・ノードに対して、データに関する増加要求を満足すると同時に、不要なデータ・パケットをフィルタ処理する能力を要求する。
【０００６】
［発明の概要］
本発明によるマルチキャスト・ネットワーク環境において望まれないデータを効率的にフィルタ処理する方法は、不要なデータを包含するチャネルを選択的にディセーブルすることによりマルチキャスト・データを選択的にフィルタ処理するハードウエアおよびソフトウエア解決手段の組み合わせを適用することにより、従来技術で切望されていた要請を満足する。本発明形態は、他の総てのデータ配信方法を越える利点を有し、そのようなシステムに関する欠点を回避しつつマルチキャストの恩恵を受ける新規かつ自明でない方法を提供する。
【０００７】
本方法は、クライアント・ノードにおけるプロセスからマルチキャスト・データの要求を受信するステップ；要求されたマルチキャスト・データに関するソースを識別するステップ；要求されたマルチキャスト・データを受信するためのソース通信チャネルを判定するステップ；ソース通信チャネルを使用可能にするステップ；ソース通信チャネルを通じてマルチキャスト・データを受信するステップ；およびマルチキャスト・データを、要求するクライアント・ノード・プロセスに転送するステップを包含する。更に、本方法は、受信したマルチキャスト・データから、要求されなかったマルチキャスト・データをフィルタ処理するステップ；
前記要求されなかったマルチキャスト・データを破棄するステップ；および
フィルタ処理されたマルチキャスト・データを前記プロセスに転送するステップ；より成る。
【０００８】
好適実施例では、ソース通信チャネルを判定するいくつかの動的な方法を包含し得る。例えば、判定するステップが、要求されたマルチキャスト・データの識別されたソースをハッシュ化するステップ；および
ハッシュ化されたマルチキャスト・データのソースを前記ソース通信チャネルとして識別するステップより成る。あるいは、判定するステップが、要求されたマルチキャスト・データのソースから、前記ソース通信チャネルを識別するチャネル識別メッセージを受信するステップより成る。そして、判定するステップは、要求されたマルチキャスト・データに関して前記マルチキャスト・チャネルを監視するステップ；およびマルチキャスト・チャネルを通じて受信したマルチキャスト・データを処理し、要求されたマルチキャスト・データが送信されるソース通信チャネルを判定するステップより成り得る。上記の動的な識別手法とは異なり、ソース通信チャネルを判定する少なくとも１つの静的な方法も使用され得る。具体的には、その静的な方法において、判定するステップが、マルチキャスト・データ・ソースおよびソース通信チャネルのコンフィギュレーション・テーブルを構築する。マルチキャスト・データ・ソースの各々はソース通信チャネルに対応する。その後に、前記コンフィギュレーション・テーブル内で、要求されたマルチキャスト・データのマルチキャスト・データ・ソースに対応するソース通信チャネルが見出され得る。
【０００９】
複数のマルチキャスト通信チャネルから要求されるマルチキャスト・データを受信する方法は、要求されるマルチキャスト・データを受信するソース通信チャネルを判定するステップ；ソース通信チャネルをイネーブルにするステップ；ソース通信チャネルを通じて要求されるマルチキャスト・データを受信するステップ；および要求されるマルチキャスト・データを、要請プロセスに転送するステップより成る。好適実施例では、前記ソース通信チャネルが、複数のマルチキャスト・データ・ソースからのマルチキャスト・データによりオーバーロードになる。その結果、本方法は更に、受信したマルチキャスト・データから不要なマルチキャスト・データをフィルタ処理するステップ；およびフィルタ処理されたマルチキャスト・データを、要請プロセスに転送するステップの両者を包含し得る。
【００１０】
好適実施例では、判定するステップが、更に、要求されたマルチキャスト・データのソースに対応する識別子をハッシュ化するステップ；およびハッシュ化された識別子を前記ソース通信チャネルとして識別するステップより成る。他の実施例では、判定するステップが、要求されたマルチキャスト・データのソースから、前記ソース通信チャネルを識別するチャネル識別メッセージを受信するステップより成る。更なる他の実施例では、判定するステップが、要求されたデータに関して前記複数の通信チャネルを監視するステップ；および前記通信チャネルを通じて受信したマルチキャスト・データを処理し、前記要求されたマルチキャスト・データが送信されるところの少なくとも１つのソース通信チャネルを判定するステップより成る。ソース通信チャネルを判定する上記の動的識別方法とは異なり、他の実施例は静的な方法も取り得る。静的方法では、判定するステップが、マルチキャスト・データ・ソースおよびソース通信チャネルのコンフィギュレーション・テーブルを構築するステップであって、マルチキャスト・データ・ソースの各々がソース通信チャネルに対応するところのステップより成る。その後に、前記コンフィギュレーション・テーブル内で、要求されたマルチキャスト・データのマルチキャスト・データ・ソースに対応するソース通信チャネルが見出される。
【００１１】
ネットワーク・クライアント・ノードにおいてマルチキャスト・データのフィルタ処理を効率的に行う方法は、以下のステップより成る：クライアント・ノードにおいて複数のプロセスからマルチキャスト・データに関する要求を受信するステップ；各々の要求に対するマルチキャスト・データ・ソースを識別するステップ；各ソース通信チャネルをイネーブルにするステップ；ソース通信チャネルを通じてマルチキャスト・データを受信するステップ；および要請プロセスによる要求に対応するマルチキャスト・データを、要請プロセスの各々に転送するステップより成る。本方法は、更に、前記ソース通信チャネルを通じて受信した前記マルチキャスト・データから、要求されていないマルチキャスト・データをフィルタ処理するステップ；前記要求されていないマルチキャスト・データを破棄するステップ；およびフィルタ処理されたマルチキャスト・データを前記プロセスに配信するステップより成る。好適実施例では、判定するステップが、識別されたマルチキャスト・データ・ソースの各々をハッシュ化するステップ；およびハッシュ化されたマルチキャスト・データ・ソースの各々について、ソース通信チャネルを識別するステップより成る。更に、一実施例にあっては、前記識別されたソースが、要求されたマルチキャスト・データを包含する少なくとも１つのモジュールを有するドメイン名称である。
【００１２】
［発明の詳細な説明］
データ・マルチキャスト・チャネル(data multicast channelization)は、配信データ・ネットワークにおけるサーバ・ベース・マルチキャストのデータ配信の問題に対して、有利な解決手段を提供する。マルチキャスト・チャネルは、ネットワーク・インターフェース回路で一般に利用可能なネットワーク・プロトコル属性を利用し、それはマルチキャスト・データ・ストリームの選択可能なハードウエア・フィルタ処理を許容し得る。本発明の好適実施例では、データ領域にあるモジュールにグループ化されるデータは、分散されたデータ・ネットワーク内のクライアント・ノードに分散されるプロセスにより要求され得る。本発明方法を利用すると、必要なデータの領域に対応するこれらマルチキャスト・チャネルのみが、ハードウエア・イネーブルされる。更に、イネーブルされたマルチキャスト・データのソフトウエアのフィルタ処理が実行され、イネーブルされたマルチキャスト・チャネルの過剰負荷（オーバーロード）の例に包含される不要なデータを更に破棄する。
【００１３】
図１は、本発明を使用可能なネットワーク形態を示す。図１では、いくつかのクライアント・コンピュータ２がローカル・エリア・ネットワーク（ＬＡＮ）４に動作可能に接続され、サーバ６も同様にＬＡＮ４に接続されている。ＬＡＮ４は、イーサーネットワーク（登録商標）、トークン・リング・ネットワークその他のマルチキャスト・メッセージを取り扱うのに適切なネットワーク・トポロジとすることが可能である。ＬＡＮ４に取り付けられる各々のクライアント・コンピュータ２は、当該技術分野で知られた任意の適切なクライアント・コンピュータより成り得る。クライアント２は、クライアント・ノードで必要な処理、画像出力の表示、キーボードおよびマウス入力の受け入れを実行すること、およびネットワーク通信を実行することに適切なハードウエアを包含する。なお、当業者は、本発明が個々のＬＡＮトポロジに限定されないことを理解するであろう。むしろ本発明は更に、複数のＬＡＮが例えばルータ接続を利用して相互にネットワーク化された大きなＷＡＮ形態で動作することが可能もある。
【００１４】
好適実施例によれば、クライアント２はファット・クライアントと呼ばれ、アプリケーションに関して相当なリアル・タイム処理が実行される。図２は、本発明に使用する一般的なクライアント・コンピュータ・システムを示す。このシステムは、中央処理装置（ＣＰＵ）、１つ又はそれ以上の固定メモリ装置１６Ａ，１６Ｂおより関連する回路を包含する汎用コンピュータ１４より成るのが好ましい。ＣＰＵは、当業者に周知の任意の適切なマイクロプロセッサその他の電子処理装置より成る。そのようなＣＰＵの例は、インテル・コーポレーション（商標）から入手可能なペンティアム（登録商標）ＩＩまたはペンティアム（登録商標）ＩＩＩブランドのマイクロプロセッサ、又は同様な機能を有する他のマイクロプロセッサを包含する。
【００１５】
また、システムは、必要な命令および制御メッセージに加えて、更新されたデータを受信するのに適切なインターフェース回路１０を包含する。インターフェース回路１０は、従来のネットワーク通信の形態をとることが可能であり、マルチキャスト・データを受信するよう構築可能である。従来のネットワーク通信カードの例は、イーサーネットワーク（登録商標）アダプタを包含し得る。
【００１６】
画像データ端末（ＶＤＴ）のような少なくとも１つのユーザ・インターフェース表示装置は、コンピュータ２に動作可能に接続されることが好ましい。マウス１８のようなインターフェース装置は、システムに設けられ得るが、ここに説明する本発明の動作には必須ではない。コンピュータ・システムは、１つ又はそれ以上の固定されたコンピュータ・メモリ装置１６Ａ，１６Ｂを包含することが好ましく、電子ランダム・アクセス・メモリ１６Ａおよび磁気ディスク・ドライブのようなバルク・データ格納媒体１６Ｂを包含し得る。特に、ここに説明する本発明方法は、バルク・データ格納媒体１６Ｂに格納され、実行時にランダム・アクセス・メモリ１６Ａにロードされるマイクロプロセッサ命令のルーチン・セットに組み込まれ得る。具体的には、ネットワーク・アプリケーション・プログラム２０は、バルク・データ格納媒体１６Ｂに格納され、実行のために電子ランダム・アクセス・メモリ１６Ａにロードされる。ここに説明されるようなコンピュータ・システムに関する様々なハードウエア要請は、インターナショナル・ビジネス・マシーンズ・コーポレーション（ＩＢＭ）（商標）、コンパック（商標）、ヒューレット・パッカード（商標）又はアップル・コンピュータ（商標）のような製造業者により提供される商業的に入手可能な多くの高速汎用パーソナル・コンピュータにより一般に充足される。
【００１７】
説明される好適実施例では、クライアント・ノード・コンピュータ・システム２のオペレーティング・システムは、ワシントン州レッドモンドのマイクロソフト・コーポレーション（商標）から入手可能なＷｉｎｄｏｗｓ（登録商標）ＮＴまたはＷｉｎｄｏｕｗｓ（登録商標）９８のようなウィンドウズ（登録商標）・ファミリーのオペレーティング・システムの１つとすることが可能である。しかしながら、システムはこれらの限定されず、本発明は、ＵＮＩＸ（登録商標），Ｌｉｎｕｘ，ＭａｃＯＳまたはＳｏｒａｒｉｓのような他の任意のコンピュータ・オペレーティング・システムの形態を利用可能である。開示されるシステムは、マイクロソフト・ウィンドウズ（登録商標）環境に対するＭｉｃｒｏｓｏｆｕｔＩｎｔｅｅｒｄｅｖ又はＬｉｎｕｘオペレーティング・システムの一部として包含される任意のＧＮＵコンパイラのような、上述したオペレーティングシステム用の商業的に入手可能な開発ツールを利用するプログラマにより実行され得る。
【００１８】
サーバ６は、ネットワーク４に接続されたクライアントに対するファイルを提供するネットワーク・オペレーティング・システムを有するアプリケーション・サーバ・コンピュータ・システムである。ネットワーク・オペレーティング・システムは、マイクロソフト・ウィンドウズ（登録商標）ＮＴサーバとすることが可能であるが、本発明はそれに限定されず、例えばＮｏｖｅｌｌＮｅｔｗａｒｅ，ＵＮＩＸ（登録商標），またはＯＳ／２ＷａｒｐＳｅｒｖｅｒのような任意の商業的に入手可能なネットワーク・オペレーティング・システムが本発明に利用可能である。サーバは、適切なネットワーク通信ポートを有するクライアント通信システム２に類似するものとすることが可能である。また、当該技術分野で周知のような、ネットワーク通信ポートを有する任意のミッドレンジ(midrange)コンピュータまたはメイン・フレーム形式コンピュータも利用可能である。
【００１９】
図３は、ネットワーク・アプリケーション・ソフトウエア２０およびネットワーク・インターフェース回路１０を示す図１における典型的なネットワーク・クライアント・ノード２のハイ・レベル・アーキテクチャである。ネットワーク・アプリケーション・ソフトウエア２０は、サーバ６から必要とされるデータを要求することが可能なハイ・レベル・プロセス２８と、ＬＡＮ４におけるサーバ６およびプロセス２８間で要求および要求されたデータを配信するデータ配信ソフトウエアとの両者を包含し得る。データ配信ソフトウエアは、データ配信ライブラリ２６およびデータ配信管理部２４を包含し得る。各データ配信ライブラリ２６は、ネットワーク４におけるモジュールから利用可能であり、プロセス２８により要求可能なデータのカタログを包含し得る。各プロセス２８は、データ配信ライブラリ２６にカタログ化されたデータを要求し得る。データに関する要求の各々および要求されたデータは、プロセス２８およびＬＡＮ４の間でチャネル２２を通じてインターフェース回路１０へおよびそこから通信を行うことが可能である。
【００２０】
クライアント・ノード２におけるプロセス２８にデータを伝送する場合に、好適実施例は、マルチキャスト技術を利用して、クライアント・ノード２にデータをブロードキャストする。マルチキャスト技術は、当該技術分野でよく知られたデータ・ブロードキャスト方法であり、http://ds.internic.net/rfc/rfc1112.txtのＩｎｔｅｒｎｉｃから利用可能なRFC 1112, Host Extensions for IP Multicastに詳細の述べられており、本願の参考に供せられる。マルチキャスト技術を利用することによって、サーバ６は、ブロードキャスト・データ・パケットを同時に受信する各クライアント・ノード２に、データ・パケットを一度送信することが可能である。そして、好適実施例では、サーバ５は、各クライアント・ノード２に関係なしに、総てのマルチキャスト・データを各クライアント・ノード２に送信する。結果として、各クライアント・ノード２は到来するデータ・ストリームをフィルタ処理し、ブロードキャスト・データの集合内で必要なデータを識別し、要求されていない総ての不要なデータを破棄する必要がある。そして、各クライアント・ノード２は、クライアント・ノード２内の要請プロセス２８に必要なマルチキャスト・データを適切に配信する。
【００２１】
有利なことに、ネットワーク・アプリケーション・ソフトウエアが入来する各々のデータ・パケットを検査し、それらの中で不要なデータを識別するところのマルチキャスト技術を利用する従来の配信データ・ネットワークとは異なり、好適実施例では、クライアント・ノード２は、インターフェース回路１０およびネットワーク・アプリケーション・ソフトウエア２０の両者において入来するデータ・ストリームをフィルタ処理する。インターフェース回路１０に関し、好適実施例では、インターフェース回路１０は、ＬＡＮ４に関してデータ・ストリームを受信および送信する６４までのアドレス可能なチャネル２２を包含し得る。なお、本発明はこれに限定されない。むしろ、例えば、カリフォルニア州パロ・アルトのサン・マイクロシステムズ（商標）から入手可能なＳＰＡＲＣワークステーション（商標）のインターフェース回路のような、ほとんどのクラアイント・ノード・プラットフォームは、いくつかのアドレス可能なマルチキャスト・イネーブル・チャネルを包含する。さらに、当業者は、配下のインターフェース回路を制御するリンク階層プログラム・インターフェースの一般的利用可能性を認識するであろう。
【００２２】
本発明によれば、データ配信管理部２４は、インターフェース回路１０に関する対応するリンク階層プログラム・インターフェース３２を利用して、インターフェース１０内のチャネル２２の各々をイネーブル又はディセーブルすることが可能である。しかしながら、アドレス可能なチャネルがディセーブルされるならば、チャネル２２を通じて何らのデータもネットワーク・アプリケーション・ソフトウエア２０に伝送されない。例えば、図３に示すように、総てのチャネル２２はデータを受信することが可能であるが、インターフェース回路１０は、チャネル０，６，５８を除いて総てのチャネル２２をフィルタ処理し得る。図３から明らかなように、チャネル２−５，７，５９−６３がディセーブルされる場合は、これらのチャネルにおけるデータ・ストリームは完全にフィルタ処理される。例として、ネットワーク・アプリケーション・ソフトウエアは、チャネル６３のディセーブルによる入来データのフィルタ処理の結果として、チャネル６３で入来するデータを分析およびフィルタ処理する必要がない。なお、これまでの例は、説明の目的のためにのみなされている。つまり、インターフェース回路１０に対するリンク階層プログラム・インターフェース３２を利用して、本発明は、インターフェース回路１０内でアドレス可能なチャネル２２の任意の組み合わせをフィルタ処理し、ディセーブルされたチャネルにおける不要なデータを効率的にフィルタ処理する。
【００２３】
特に、チャネル２２の数を超えるマルチキャスト・データ量を収容するため、各チャネル２２は加重に負荷が課され得る（オーバーロードされ得る。）。すなわち、１データ・ストリーム以上が単独のチャネル２２にマルチプレクスされ得る。その結果、インターフェース回路１０は完全なチャネル２２をイネーブルまたはディセーブルすることが可能であるので、イネーブルされたチャネル２２でマルチプレクスされた不要なデータは、インターフェース回路１０で実行されるフィルタ処理プロセスを逃れることが可能であり、ネットワーク・アプリケーション・ソフトウエア２０を通じて伝達され得る。これに対処するために、好適実施例では、ネットワーク・アプリケーション・ソフトウエア２０で付加的なフィルタ処理プロセスが実行され得る。特に、データ配信管理部２４はイネーブルされたチャネル各々におけるデータ・ストリームの入来データを検査することが可能である。例えば、図３に示すように、データ配信管理部２４は、プロセス２８により要求されたイネーブルされたチャネル０，６，５８から抽出し得る。その後にデータ配信管理部２４は必要なデータを要請プロセス２８に転送し得る。
【００２４】
有利なことに、入来データ・ストリーム内のデータ検査において、データ配信管理部２４は、不要なデータをゴミ箱を表現するもの３０に置くことによって過剰な不要なデータを破棄し得る。しかしながら、当業者はこれらが例示目的のためのみに提供されていることを認識するであろう。つまり、不要なデータを破棄する更に効率的かつ好適な方法は、単に、不要なデータをプロセス２８に更に送信しないことである。
【００２５】
ＴＣＰ／ＩＰハードウエア１０におけるフィルタ処理およびデータ配信管理部２４におけるソフトウエア・フィルタ処理の両者を実行することによって、データ配信管理部２４が、必要なデータのみを要請プロセス２８に配信するように、データ配信管理部２４は、どのハードウエア・チャネル２２がイネーブルされるべきであってどれがディセーブルされるべきかを判定する。この判定を行うため、データ配信管理部２４は、ハードウエア・チャネル２２に要求された及び要求されなかった総てのデータをマッピングすることが可能である。より具体的には、データ配信管理部２４は、静的解決手段（ソリューション）では参照することが可能であり、動的解決手段ではイネーブルする適切なチャネルのデータ・ソースにより通知され、プロセス２８により要求されるデータを受信する。
【００２６】
静的解決手段では、コンフィギュレーション・ファイルがデータ配信管理部２４で作成され、ハードウエア・チャネル２２に要求されたデータに対応するデータ領域の静的マッピングを包含する。プロセス２８によるデータの要求時に、データ配信管理部２４は、コンフィギュレーション・ファイルに問い合わせることのみを要し、インターフェース回路１０でイネーブルにする適切なチャネル２２を判定する。しかしながら、当業者は、本発明がデータ領域のマッピングに限定されないことを認めるであろう。むしろ、コンフィギュレーション・ファイルは、要求されたマルチキャスト・データのソースに対応する任意の識別子の静的マッピングを包含することが可能であり、例えば、所有者ネットワーク・アドレス又はそのマルチキャスト・データのネットワーク・ソースに対応するネットワーク・アダプタ・アドレスのようなものである。一般に、コンフィギュレーション・ファイルは、対応するハードウエア・チャネル２２に対する各識別子をマッピングすることが可能である。
【００２７】
本発明方法は、チャネル判定問題に対するいくつかの動的解決手段を包含する。１つの動的解決手段では、データ配信管理部２４は、データ配信管理部２４がそこを通じて要求されたデータを受信し得るところの適切なチャネル２２を識別する要求データのソースから、点対点(point-to-point)メッセージを受信し得る。更なる他の動的解決手段では、データ配信管理部２４は、総てのチャネル２２をポーリング(poll)し、各々のデータ・ストリーム内でデータ・ストリームのソースを識別することが可能である。このように、データ配信管理部２４は、対応するチャネル２２に関するデータ・ストリームのソースを動的にマッピングすることが可能である。
【００２８】
しかしながら、本発明の好適実施例では、データ配信管理部２４は、当該技術分野で周知のハッシュ(hash)技術を利用して、イネーブルする適切なチャネルを動的に識別することが可能である。一般に、探査および格納アルゴリズムは、データを辞書またはシンボル・テーブルに格納する。辞書における各事項は対応する探索キーを有し、それを通じてその事項は辞書からの抽出時に識別される。ハッシュ技術は、ハッシュ関数を利用して動的に計算され得るハッシュ・テーブルを利用する。具体的には、ハッシュ関数はデータに対する算術演算を使用して、探索キーを生成し、ハッシュ・テーブル内の場所にちりばめる。理想的には各々の探索キーは異なる位置に対応する。有利なことに、同一の算術演算が探索要求に関して行われ、探索キーを生成し、対応するデータを見出す。
【００２９】
したがって、本発明にハッシュ技術を利用すると、好適実施例では、各々のマルチキャスト・データは、ブロードキャストされるデータを包含するドメインの名称にハッシュ関数を適用することによって、選択されたチャネルにおけるデータをブロードキャストすることが可能である。対応して、入来するマルチキャスト・データを受信するための適切なチャネル２２を判定する場合に、データ配信管理部２４は、要求されたマルチキャスト・データに関連するドメイン名称(domain name)にハッシュ関数を動的に適用し、ブロードキャスト・データを受信するための対応するチャネル２２を識別する。ドメイン名称へのハッシュ関数の適用は、「ドメイン名称のハッシュ化(hashing the domain name)」と呼ばれる。しかしながら、当業者は、本発明がドメイン名称のみをハッシュ化することに限定されないことを認めるであろう。むしろ、ハッシュ技術は、マルチキャスト・データ・ソースに対応する任意の識別子をハッシュ化することによって利用され得る。
【００３０】
ドメイン名称のハッシュ化による探索キーは、「ハッシュ化ドメイン名称(hashed domain name)」と呼ばれる。ハッシュ化ドメイン名称は適切なチャネル２２に対応し、これを通じてデータ配信管理部２４は入来するマルチキャスト・データを受信する。対応するチャネル２２が識別されると、その後にデータ配信管理部２４は識別されたチャネル２２をイネーブルにし、それを通じてデータ配信管理部２４は要求されたブロードキャストされたマルチキャスト・データを受信することが可能である。
【００３１】
図４Ａないし４Ｃは、全体として、本発明の好適実施例による方法を示すフローチャートである。図４Ａないし４Ｃに示される方法は、ネットワーク・アプリケーション２０で実行されることが好ましい。より具体的には、本発明方法は、例えばサーバ６およびデータ配信管理部２４のようなＬＡＮ４におけるブロードキャスト・データ・ソースからのデータを要求する各プロセス２８の間の相互作用を含み、チャネル２２におけるブロードキャスト・データのハードウエアおよびソフトウエア・フィルタ処理を行う。
【００３２】
本発明方法はステップ１００から始まり、プロセス２８は、その特定のプロセス２８で要求されるブロードキャスト・データを識別する。好適実施例では、ブロードキャスト・データは、データ・セットまたはモジュールにグループ化され得る。さらに、各モジュールはドメイン--一般的にはデータのより高いレベルのソースに関連づけられる。しかしながら、本発明はこれに限定されない。むしろ、データ・モジュール・ドメインの階層構造は、データの可能な１形態にすぎない。本発明は、平坦な(flat)データのみの構造にも等しく効果的である。
【００３３】
ステップ１０２では、プロセス２８はデータ配信ライブラリ２６に問い合わせを行い、要求されたブロードキャスト・データを包含するモジュールを区別する。その後に、ステップ１０４において、このプロセスは、データ配信管理部２４に「オープン＿モジュール(open_module)」を送信することによって、必要なマルチキャスト・データに加入することができる。特に、加入およびフィルタ処理手順の残りは、要請プロセス２８には明白(transparent)であり続ける。プロセス２８が必要なマルチキャスト・データに加入すると、マルチキャスト・データがマルチキャスト・データ・ソースからブロードキャスト送信される場合に、プロセス２８は必要なマルチキャスト・データを時々受信することのみを要する。したがって、データ配信管理部２４から要求されたデータを受領するまで、要請プロセス２８は通常の動作を再開することが可能である。
【００３４】
図４Ｂを参照するに、図４Ａのステップ１０４で送信されたオープン＿モジュール要求を受領すると、ステップ１１２において、データ配信管理部２４は要求されたモジュールに対応するドメインを識別し得る。ステップ１１４では、データ配信管理部２４が、ドメイン名称にハッシュ関数を適用し、イネーブルする適切なチャネル２２を判定する。ステップ１１６において、判定されたチャネル２２が既にオープンされてはいないならば、ステップ１１８において、データ配信管理部２４が、例えば転送制御プロトコル(TCP: transport control protocol)「ソケット（）」関数呼出を利用して、チャネルを解放する（オープン）ことが可能であり、そこではインターネット・プロトコル（ＩＰ）ソース・アドレス、ＩＰ宛先アドレス、ソース・ポートおよび宛先ポートが指定される。特に、要求されるデータはＩＰマルチキャスト・データであり得るので、ＩＰソース・アドレスは、ＲＦＣ１１１２で詳細に説明されるクラスＤのＩＰマルチキャスト・アドレスとすることが可能である。
【００３５】
詳細に上述したように、各チャネル２２は、マルチキャスト・データ・ソースからの複数のデータ・ストリームに関して、過剰に負荷が課せられ得る（オーバーロードされ得る）。このため、ステップ１１６において、データ配信管理部２４は既にオープン・チャネル２２を識別し得るが、データ配信管理部２４は所望のマルチキャスト・データ・ソースから発したデータをここで排除することが可能である。判定ステップ１２０において、データ配信管理部２４は、所望のモジュールが不要なデータとして処理される目下のソフトウエアであるか否かを判定する。具体的には、データ配信管理部２４は、オープンのチャネル２２の各々に関して過剰に負荷の課されたモジュールのリストを維持することが可能である。モジュールのリストに問い合わせることによって、データ配信管理部２４は、オープンのチャネル２２におけるモジュールの存在を検出することが可能である。
【００３６】
より具体的には、データ配信管理部２４は、オープンのチャネル２２の各々に関する過剰に負荷の課された特定のモジュールからのデータに加入するプロセスのリストを維持し得る。ステップ１２０では、特定のモジュールからのデータに加入するプロセスのリストにより、データ配信管理部２４は、プロセスが既にオープン・チャネル２２におけるモジュールに加入しているか否かを判定することが可能である。他のプロセスが既に特定のモジュールに加入しているならば、要請プロセス２８はステップ１２６においてプロセスのリストに付加されるにすぎない。そうでなければ、要請プロセス２８がモジュールからのデータを要求する最初のものであるならば、データ配信管理部２４はステップ１２４において、オープン・チャネル２２に関するオーバーロードのモジュールのリストにそのモジュールを追加することによって、オープン・チャネル２２におけるモジュールに加入することが可能である。そして、ステップ１２６において、データ配信管理部２４は、要請プロセス２８を、モジュールに包含されるデータを要請プロセスのリストに付加することが可能である。
【００３７】
図４Ａを参照するに、ステップ１０４におけるオープン＿モジュール・メッセージを送信することによる要求マルチキャスト・データへの加入の後に、プロセス２８は、データ配信管理部２４から要求されたブロードキャスト・データを受信するまで、通常の動作で進行することが可能である。より具体的には、データ配信管理部２４が、モジュールのリストに包含されるモジュールに関するオープン・チャネルにおけるブロードキャスト・データを識別する場合に、データ配信管理部はモジュール・ユーザのリストを問い合わせ、モジュール・ユーザのリスト内の各プロセス２８の各々に受信したブロードキャスト・データを配信する。このようにして、最初にインターフェース回路１０の階層において、そして第２にデータ配信管理部２４の階層において、プロセス２８は要求されるブロードキャスト・データを容易に受信する一方、要求されないブロードキャスト・データは選択的に破棄される。
【００３８】
プロセス２８がもはや要求されるブロードキャスト・データを必要としなくなるまで、プロセス２８は要求されるブロードキャスト・データを受信し続ける。判定ステップ１０８において、プロセス２８がもはや要求されたマルチキャスト・データを必要しないと判定されるならば、ステップ１１０においてプロセス２８は、「クローズ＿モジュール(close_module)」要求をデータ配信管理部２４に送信することによって、マルチキャスト・データに対して非加入になることが可能である。特に、非加入手順の残りは要請プロセス２８にとって明白である。プロセス２８が以前の要求されたマルチキャスト・データに非加入になると、プロセス２８は通常の動作に戻ることが可能である。以前の要求されたマルチキャスト・データは、データ配信管理部２４の命令により、ソフトウエアおよび可能なハードウエア処理がなされ、プロセス２８はもはや、以前の要求されたマルチキャスト・データのソースからブロードキャスト・データ・パケットを受信しない。
【００３９】
図４Ｃを参照するに、クローズ＿モジュール要求を受領すると、ステップ１２８において、データ配信管理部２４は、モジュール・ユーザのリストから要請プロセス２８を除去することが可能である。判定ステップ１３０において、要請プロセス２８がそのモジュールの利用を要求する最後のプロセスでないならば、データ配信管理部２４は依然としてそのモジュールにおける他のプロセスにデータを配信する必要があるので、データ配信管理部２４は他のプロセスのために実行する必要がある。逆に、判定ステップ１３０で要請プロセス２８がモジュールの利用を要求する最後のプロセスであるならば、ステップ１３４において、データ配信管理部２４は、オーバーロード・オープン・チャネル２２におけるモジュールのリストからそのモジュールを除去することにより、その要請プロセス２８をブロードキャスト・データから非加入にすることができる。しかしながら、有利なことに、オープン・チャネル２２がオーバーロードでなく、あるソース・モジュールからのデータ・ストリームのみがチャネル２２を利用しているようならば、データ配信管理部２４はそのチャネルをディセーブルにすることが可能である。データ配信管理部２４は、インターフェース回路１０に対するリンク階層プログラム・インターフェースを再び利用して、ステップ１３８においてチャネル２４をクローズすることができる。そして、本方法はステップ１４０で終了する。
【００４０】
要するに、マルチキャスト技術を利用してクライアント・ノードへデータを配信するサーバ・ベース手法は、データ配信ネットワークにクライアント・ノードを追加する結果としての帯域を縮小することによる実効性のペナルティの影響を受けやすい。本発明のマルチキャスト・チャネル手法は、複数のチャネルにわたってブロードキャスト・データを配信することによって、拡張するクライアント・ノード・ベースに利用可能な帯域を増加させることが可能である。したがって、クライアント・ノードは、クライアント・ノード各々のネットワーク・インターフェース回路内で不要なブロードキャスト・データを選択的にフィルタ処理することが可能である。具体的には、過剰なソフトウエア・フィルタ処理を回避するために、クライアント・ノードは、関心のあるデータが流れているネットワーク・インターフェース回路におけるチャネルのみをイネーブルにすることが可能である。チャネルがオーバーロードする場合には依然としてソフトウエア・フィルタ処理が必要とされ得るが、実効性利得(performance gain)は依然として良好であり得る。
【図面の簡単な説明】
【図１】図１は、本発明が使用され得るコンピュータ・ネットワークに基づくサーバを示す図である。
【図２】図２は、典型的なクライアント・ノードを示す図である。
【図３】図３は、ネットワーク・アプリケーション・ソフトウエアおよびハードウエアを示す図１の典型的なネットワーク・クライアント・ノードのハイ・レベル・アーキテックチャである。
【図４Ａ】図４Ａ−４Ｃは、本発明の好適実施例による方法を示すフロー・チャートである。
【図４Ｂ】図４Ａ−４Ｃは、本発明の好適実施例による方法を示すフロー・チャートである。
【図４Ｃ】図４Ａ−４Ｃは、本発明の好適実施例による方法を示すフロー・チャートである。

Claims

要求したマルチキャスト・データを複数のマルチキャスト通信チャネルを通じて受信する方法であって、
前記複数のマルチキャスト通信チャネルの中から、前記要求したマルチキャスト・データを受信するためのソース通信チャネルをクライアント・コンピュータが選択するステップと、
前記クライアント・コンピュータが、ハードウェアインターフェースを利用して、選択されたソース通信チャネルをイネーブルにし、選択されなかったソース通信チャネルをディセーブルにするステップと、
前記クライアント・コンピュータが、イネーブルにされたソース通信チャネルから、前記ハードウェアインターフェースを用いてマルチキャスト・データを受信するステップと、
前記クライアント・コンピュータにおいてコンピュータプログラムを実行する要請プロセス部が、受信したマルチキャスト・データを必要とするか否かを検査するステップと、
前記要請プロセス部が前記受信したマルチキャスト・データを必要とする場合、該受信したマルチキャスト・データを前記要請プロセス部に転送し、前記要請プロセス部が前記受信したマルチキャスト・データを必要としない場合、該受信したマルチキャスト・データを破棄するステップと
を有する方法。
前記ソース通信チャネルが、
前記要求したマルチキャスト・データのソースに対応する識別子をハッシュ化し、ハッシュ化された前記識別子を前記ソース通信チャネルとして識別するステップを実行することで選択される、請求項１記載の方法。
前記ソース通信チャネルが、
前記要求したマルチキャスト・データに関して前記複数のマルチキャスト通信チャネルを監視し、前記複数のマルチキャスト通信チャネルを通じて受信したマルチキャスト・データを処理し、前記要求したマルチキャスト・データを送信する前記ソース通信チャネルを選択するステップを実行することで選択される、請求項１記載の方法。
前記ソース通信チャネルが、
複数のマルチキャスト・データ・ソースおよび複数のソース通信チャネルのコンフィギュレーション・テーブルを構築するステップであって、前記マルチキャスト・データ・ソースの各々が前記ソース通信チャネルの内の何れかに対応する、ステップと、
前記コンフィギュレーション・テーブルを用いて、前記要求したマルチキャスト・データの送信元である何れかのマルチキャスト・データ・ソースに対応する前記ソース通信チャネルを選択するステップと
を実行することで選択される、請求項１記載の方法。