JP2003519872A - データ・マルチキャスト・チャネル - Google Patents

Abstract

(57)【要約】 複数のマルチキャスト通信チャネル（２２）から要求されるマルチキャスト・データを受信する方法は、要求されるマルチキャスト・データを受信するソース通信チャネルを判定するステップ；ソース通信チャネルをイネーブルにするステップ；ソース通信チャネルを通じて要求されるマルチキャスト・データを受信するステップ；および要求されるマルチキャスト・データを、要請プロセス（２８）に転送するステップより成る。好適実施例では、前記ソース通信チャネルが、複数のマルチキャスト・データ・ソースからのマルチキャスト・データによりオーバーロードになる。本方法は更に、受信したマルチキャスト・データから不要なマルチキャスト・データをフィルタ処理するステップ；およびフィルタ処理されたマルチキャスト・データを、要請プロセス（２８）に配信するステップの両者を包含し得る。好適実施例では、判定するステップが、更に、要求されたマルチキャスト・データのマルチキャスト・データ・ソースに対応する識別子をハッシュ化するステップ；およびハッシュ化された識別子を前記ソース通信チャネルとして識別するステップより成る。

Description

【発明の詳細な説明】

【０００１】 ［技術分野］ 本発明は、ネットワーク・データ配信に関し、特にマルチキャスト技術を利用
するネットワークにおいて改善された実効性を提供する方法に関する。

【０００２】 ［関連技術の説明］ 従来のデータ・ネットワーク配信では、周知のネットワーク・プロトコルを利用
して、１つ又はそれ以上のサーバ・ノードおよび複数のクライアント・ノードが互
いに通信を行う。一般に、配信されるデータ・アプリケーションは、ネットワー
クに結合されたクライアント・ノードに対する中央配信および統合を行うことが
可能なサーバ・ノードを包含する。現在のところ、クライアント・ノードは２つの
方向に向かいつつあり：データの小さな部分集合で動作し又は監視する「シン・
クライアント(thin-client)」と、ネットワークにおける大量のリアル・タイム情
報のデータ削減、データ記録その他の同様な動作を実行する「ファット・クライ
アント(fat-client)」である。後者に関し、重要な処理がファット・クライアン
ト内で発生することが可能であり、高速、リアル・タイムの大きな部分集合を取
り扱う必要がある。

【０００３】 配信データ・ネットワークにおける高速データの取り扱いは、２つの基本的な
手法を包含する。非常に一般的な手法は、「クライアント・ベース(client-based
)」手法と呼ばれるものであり、クライアント・ノードが、サーバ・ノードに、所
望のデータにおける興味の対象を通知する。実際、クライアント・ベース手法は
、加入−未加入形態(subscribe-unsubscribe-paradigm)を改善する。クライアン
ト・ベース手法を利用すると、各々の関心のある加入クライアントに個別にデー
タ・パケットを配信することが可能である。しかしながら、ネットワーク要求が
多くなるにつれて、サーバーに過剰に負荷を与える傾向がある(overload)。特に
、追加的なクライアント・ノードがネットワークに負荷される場合に、対象のク
ライアント・ノードの各々にデータ・パケットを個々に配信する必要があるだけで
なく、サーバは付加的な加入クライアント・ノードの各々にもデータ・パケットを
個々に配信する必要がある。したがって、クライアント・ノード・リストが大きく
なるにつれて、サーバの負担も大きくなる。

【０００４】 第２の手法は、「サーバ・ベース(server-based)」手法であり、ネットワーク
にある総てのクライアント・ノードにブロードキャスト・データ・パケットを提供
するものである。マルチキャスト技術を利用することにより、サーバは各データ
・パケットを一度だけ送信する。それに対応して、総てのクライアント・ノードは
、１つずつ送信されたデータ・パケットを同時に受信する。特に、データ・パケッ
トをブロードキャスト配信するために、サーバは、クラアイント・ノードの具体
的な物理アドレスではなく、特定のマルチキャスト・セッションを指定するマル
チキャスト宛先アドレスに、データ・パケットを送信する。ブロードキャスト・デ
ータを受信するために、関心のあるクラアイント・ノードは、サーバではなくマ
ルチキャスト・アドレスに加入するだけである。マルチキャスト技術を利用する
ことにより、クライアント数が増加しても、サーバは、増加したクライアント数
を増加したデータ・パケット転送数に合わせる必要がない。その結果、データ・パ
ケットの内容によらず、サーバには過剰な負荷が課せられないようになり、各ク
ライアント・ノードは、各データ・パケットの受領時に望まないデータをフィルタ
処理する(filter)必要がある。

【０００５】 一般にクライアント・ノードはブロードキャスト・データのほとんどに関心がな
く、その結果、クライアントは、望まないデータ・パケットを識別および破棄す
るのに相当なプロセッサ資源を消費する。特に、ブロードキャスト・データを受
信するクライアント・ノードにおけるネットワーク・アプリケーションは、受信し
たデータ・パケットの各々を識別し、同時に破棄すべきか否かを判定しなければ
ならない。したがって、前述した手法は、上述したプロセッサ・オーバーヘッド
に起因して、サーバが高速データ伝送レートでより多くのクライアント・ノード
にデータを提供可能にするが、結局その手法は、望まないデータ・パケットをフ
ィルタ処理するために、クライアント・ノードの能力を制限する。特に、今日の
コンピュータはより高速な処理を達成し、ネットワーク帯域も大きく、ネットワ
ーク・ユーザはそのネットワークを通じてより多くのデータをブロードキャスト
するが、クライアント・ノードに対して、データに関する増加要求を満足すると
同時に、不要なデータ・パケットをフィルタ処理する能力を要求する。

【０００６】 ［発明の概要］ 本発明によるマルチキャスト・ネットワーク環境において望まれないデータを
効率的にフィルタ処理する方法は、不要なデータを包含するチャネルを選択的に
ディセーブルすることによりマルチキャスト・データを選択的にフィルタ処理す
るハードウエアおよびソフトウエア解決手段の組み合わせを適用することにより
、従来技術で切望されていた要請を満足する。本発明形態は、他の総てのデータ
配信方法を越える利点を有し、そのようなシステムに関する欠点を回避しつつマ
ルチキャストの恩恵を受ける新規かつ自明でない方法を提供する。

【０００７】 本方法は、クライアント・ノードにおけるプロセスからマルチキャスト・データ
の要求を受信するステップ；要求されたマルチキャスト・データに関するソース
を識別するステップ；要求されたマルチキャスト・データを受信するためのソー
ス通信チャネルを判定するステップ；ソース通信チャネルを使用可能にするステ
ップ；ソース通信チャネルを通じてマルチキャスト・データを受信するステップ
；およびマルチキャスト・データを、要求するクライアント・ノード・プロセスに
転送するステップを包含する。更に、本方法は、受信したマルチキャスト・デー
タから、要求されなかったマルチキャスト・データをフィルタ処理するステップ
； 前記要求されなかったマルチキャスト・データを破棄するステップ；および フィルタ処理されたマルチキャスト・データを前記プロセスに転送するステッ
プ；より成る。

【０００８】 好適実施例では、ソース通信チャネルを判定するいくつかの動的な方法を包含
し得る。例えば、判定するステップが、要求されたマルチキャスト・データの識
別されたソースをハッシュ化するステップ；および ハッシュ化されたマルチキャスト・データのソースを前記ソース通信チャネル
として識別するステップより成る。あるいは、判定するステップが、要求された
マルチキャスト・データのソースから、前記ソース通信チャネルを識別するチャ
ネル識別メッセージを受信するステップより成る。そして、判定するステップは
、要求されたマルチキャスト・データに関して前記マルチキャスト・チャネルを監
視するステップ；およびマルチキャスト・チャネルを通じて受信したマルチキャ
スト・データを処理し、要求されたマルチキャスト・データが送信されるソース通
信チャネルを判定するステップより成り得る。上記の動的な識別手法とは異なり
、ソース通信チャネルを判定する少なくとも１つの静的な方法も使用され得る。
具体的には、その静的な方法において、判定するステップが、マルチキャスト・
データ・ソースおよびソース通信チャネルのコンフィギュレーション・テーブルを
構築する。マルチキャスト・データ・ソースの各々はソース通信チャネルに対応す
る。その後に、前記コンフィギュレーション・テーブル内で、要求されたマルチ
キャスト・データのマルチキャスト・データ・ソースに対応するソース通信チャネ
ルが見出され得る。

【０００９】 複数のマルチキャスト通信チャネルから要求されるマルチキャスト・データを
受信する方法は、要求されるマルチキャスト・データを受信するソース通信チャ
ネルを判定するステップ；ソース通信チャネルをイネーブルにするステップ；ソ
ース通信チャネルを通じて要求されるマルチキャスト・データを受信するステッ
プ；および要求されるマルチキャスト・データを、要請プロセスに転送するステ
ップより成る。好適実施例では、前記ソース通信チャネルが、複数のマルチキャ
スト・データ・ソースからのマルチキャスト・データによりオーバーロードになる
。その結果、本方法は更に、受信したマルチキャスト・データから不要なマルチ
キャスト・データをフィルタ処理するステップ；およびフィルタ処理されたマル
チキャスト・データを、要請プロセスに転送するステップの両者を包含し得る。

【００１０】 好適実施例では、判定するステップが、更に、要求されたマルチキャスト・デ
ータのソースに対応する識別子をハッシュ化するステップ；およびハッシュ化さ
れた識別子を前記ソース通信チャネルとして識別するステップより成る。他の実
施例では、判定するステップが、要求されたマルチキャスト・データのソースか
ら、前記ソース通信チャネルを識別するチャネル識別メッセージを受信するステ
ップより成る。更なる他の実施例では、判定するステップが、要求されたデータ
に関して前記複数の通信チャネルを監視するステップ；および前記通信チャネル
を通じて受信したマルチキャスト・データを処理し、前記要求されたマルチキャ
スト・データが送信されるところの少なくとも１つのソース通信チャネルを判定
するステップより成る。ソース通信チャネルを判定する上記の動的識別方法とは
異なり、他の実施例は静的な方法も取り得る。静的方法では、判定するステップ
が、マルチキャスト・データ・ソースおよびソース通信チャネルのコンフィギュレ
ーション・テーブルを構築するステップであって、マルチキャスト・データ・ソー
スの各々がソース通信チャネルに対応するところのステップより成る。その後に
、前記コンフィギュレーション・テーブル内で、要求されたマルチキャスト・デ
ータのマルチキャスト・データ・ソースに対応するソース通信チャネルが見出され
る。

【００１１】 ネットワーク・クライアント・ノードにおいてマルチキャスト・データのフィル
タ処理を効率的に行う方法は、以下のステップより成る：クライアント・ノード
において複数のプロセスからマルチキャスト・データに関する要求を受信するス
テップ；各々の要求に対するマルチキャスト・データ・ソースを識別するステップ
；各ソース通信チャネルをイネーブルにするステップ；ソース通信チャネルを通
じてマルチキャスト・データを受信するステップ；および要請プロセスによる要
求に対応するマルチキャスト・データを、要請プロセスの各々に転送するステッ
プより成る。本方法は、更に、前記ソース通信チャネルを通じて受信した前記マ
ルチキャスト・データから、要求されていないマルチキャスト・データをフィルタ
処理するステップ；前記要求されていないマルチキャスト・データを破棄するス
テップ；およびフィルタ処理されたマルチキャスト・データを前記プロセスに配
信するステップより成る。好適実施例では、判定するステップが、識別されたマ
ルチキャスト・データ・ソースの各々をハッシュ化するステップ；およびハッシュ
化されたマルチキャスト・データ・ソースの各々について、ソース通信チャネルを
識別するステップより成る。更に、一実施例にあっては、前記識別されたソース
が、要求されたマルチキャスト・データを包含する少なくとも１つのモジュール
を有するドメイン名称である。

【００１２】 ［発明の詳細な説明］ データ・マルチキャスト・チャネル(data multicast channelization)は、配
信データ・ネットワークにおけるサーバ・ベース・マルチキャストのデータ配信の
問題に対して、有利な解決手段を提供する。マルチキャスト・チャネルは、ネッ
トワーク・インターフェース回路で一般に利用可能なネットワーク・プロトコル
属性を利用し、それはマルチキャスト・データ・ストリームの選択可能なハードウ
エア・フィルタ処理を許容し得る。本発明の好適実施例では、データ領域にある
モジュールにグループ化されるデータは、分散されたデータ・ネットワーク内の
クライアント・ノードに分散されるプロセスにより要求され得る。本発明方法を
利用すると、必要なデータの領域に対応するこれらマルチキャスト・チャネルの
みが、ハードウエア・イネーブルされる。更に、イネーブルされたマルチキャス
ト・データのソフトウエアのフィルタ処理が実行され、イネーブルされたマルチ
キャスト・チャネルの過剰負荷（オーバーロード）の例に包含される不要なデー
タを更に破棄する。

【００１３】 図１は、本発明を使用可能なネットワーク形態を示す。図１では、いくつかの
クライアント・コンピュータ２がローカル・エリア・ネットワーク（ＬＡＮ）４に
動作可能に接続され、サーバ６も同様にＬＡＮ４に接続されている。ＬＡＮ４は
、イーサーネットワーク（登録商標）、トークン・リング・ネットワークその他の
マルチキャスト・メッセージを取り扱うのに適切なネットワーク・トポロジとする
ことが可能である。ＬＡＮ４に取り付けられる各々のクライアント・コンピュー
タ２は、当該技術分野で知られた任意の適切なクライアント・コンピュータより
成り得る。クライアント２は、クライアント・ノードで必要な処理、画像出力の
表示、キーボードおよびマウス入力の受け入れを実行すること、およびネットワ
ーク通信を実行することに適切なハードウエアを包含する。なお、当業者は、本
発明が個々のＬＡＮトポロジに限定されないことを理解するであろう。むしろ本
発明は更に、複数のＬＡＮが例えばルータ接続を利用して相互にネットワーク化
された大きなＷＡＮ形態で動作することが可能もある。

【００１４】 好適実施例によれば、クライアント２はファット・クライアントと呼ばれ、ア
プリケーションに関して相当なリアル・タイム処理が実行される。図２は、本発
明に使用する一般的なクライアント・コンピュータ・システムを示す。このシステ
ムは、中央処理装置（ＣＰＵ）、１つ又はそれ以上の固定メモリ装置１６Ａ，１
６Ｂおより関連する回路を包含する汎用コンピュータ１４より成るのが好ましい
。ＣＰＵは、当業者に周知の任意の適切なマイクロプロセッサその他の電子処理
装置より成る。そのようなＣＰＵの例は、インテル・コーポレーション（商標）
から入手可能なペンティアム（登録商標）ＩＩまたはペンティアム（登録商標）
ＩＩＩブランドのマイクロプロセッサ、又は同様な機能を有する他のマイクロプ
ロセッサを包含する。

【００１５】 また、システムは、必要な命令および制御メッセージに加えて、更新されたデ
ータを受信するのに適切なインターフェース回路１０を包含する。インターフェ
ース回路１０は、従来のネットワーク通信の形態をとることが可能であり、マル
チキャスト・データを受信するよう構築可能である。従来のネットワーク通信カ
ードの例は、イーサーネットワーク（登録商標）アダプタを包含し得る。

【００１６】 画像データ端末（ＶＤＴ）のような少なくとも１つのユーザ・インターフェー
ス表示装置は、コンピュータ２に動作可能に接続されることが好ましい。マウス
１８のようなインターフェース装置は、システムに設けられ得るが、ここに説明
する本発明の動作には必須ではない。コンピュータ・システムは、１つ又はそれ
以上の固定されたコンピュータ・メモリ装置１６Ａ，１６Ｂを包含することが好
ましく、電子ランダム・アクセス・メモリ１６Ａおよび磁気ディスク・ドライブの
ようなバルク・データ格納媒体１６Ｂを包含し得る。特に、ここに説明する本発
明方法は、バルク・データ格納媒体１６Ｂに格納され、実行時にランダム・アクセ
ス・メモリ１６Ａにロードされるマイクロプロセッサ命令のルーチン・セットに組
み込まれ得る。具体的には、ネットワーク・アプリケーション・プログラム２０は
、バルク・データ格納媒体１６Ｂに格納され、実行のために電子ランダム・アクセ
ス・メモリ１６Ａにロードされる。ここに説明されるようなコンピュータ・システ
ムに関する様々なハードウエア要請は、インターナショナル・ビジネス・マシーン
ズ・コーポレーション（ＩＢＭ）（商標）、コンパック（商標）、ヒューレット・
パッカード（商標）又はアップル・コンピュータ（商標）のような製造業者によ
り提供される商業的に入手可能な多くの高速汎用パーソナル・コンピュータによ
り一般に充足される。

【００１７】 説明される好適実施例では、クライアント・ノード・コンピュータ・システム２
のオペレーティング・システムは、ワシントン州レッドモンドのマイクロソフト・
コーポレーション（商標）から入手可能なＷｉｎｄｏｗｓ（登録商標）ＮＴまた
はＷｉｎｄｏｕｗｓ（登録商標）９８のようなウィンドウズ（登録商標）・ファ
ミリーのオペレーティング・システムの１つとすることが可能である。しかしな
がら、システムはこれらの限定されず、本発明は、ＵＮＩＸ（登録商標），Ｌｉ
ｎｕｘ，ＭａｃＯＳまたはＳｏｒａｒｉｓのような他の任意のコンピュータ・オ
ペレーティング・システムの形態を利用可能である。開示されるシステムは、マ
イクロソフト・ウィンドウズ（登録商標）環境に対するＭｉｃｒｏｓｏｆｕｔ
Ｉｎｔｅｅｒｄｅｖ又はＬｉｎｕｘオペレーティング・システムの一部として包
含される任意のＧＮＵコンパイラのような、上述したオペレーティングシステム
用の商業的に入手可能な開発ツールを利用するプログラマにより実行され得る。

【００１８】 サーバ６は、ネットワーク４に接続されたクライアントに対するファイルを提
供するネットワーク・オペレーティング・システムを有するアプリケーション・サ
ーバ・コンピュータ・システムである。ネットワーク・オペレーティング・システム
は、マイクロソフト・ウィンドウズ（登録商標）ＮＴサーバとすることが可能で
あるが、本発明はそれに限定されず、例えばＮｏｖｅｌｌ Ｎｅｔｗａｒｅ，Ｕ
ＮＩＸ（登録商標），またはＯＳ／２ＷａｒｐＳｅｒｖｅｒのような任意の商業
的に入手可能なネットワーク・オペレーティング・システムが本発明に利用可能で
ある。サーバは、適切なネットワーク通信ポートを有するクライアント通信シス
テム２に類似するものとすることが可能である。また、当該技術分野で周知のよ
うな、ネットワーク通信ポートを有する任意のミッドレンジ(midrange)コンピュ
ータまたはメイン・フレーム形式コンピュータも利用可能である。

【００１９】 図３は、ネットワーク・アプリケーション・ソフトウエア２０およびネットワー
ク・インターフェース回路１０を示す図１における典型的なネットワーク・クライ
アント・ノード２のハイ・レベル・アーキテクチャである。ネットワーク・アプリケ
ーション・ソフトウエア２０は、サーバ６から必要とされるデータを要求するこ
とが可能なハイ・レベル・プロセス２８と、ＬＡＮ４におけるサーバ６およびプロ
セス２８間で要求および要求されたデータを配信するデータ配信ソフトウエアと
の両者を包含し得る。データ配信ソフトウエアは、データ配信ライブラリ２６お
よびデータ配信管理部２４を包含し得る。各データ配信ライブラリ２６は、ネッ
トワーク４におけるモジュールから利用可能であり、プロセス２８により要求可
能なデータのカタログを包含し得る。各プロセス２８は、データ配信ライブラリ
２６にカタログ化されたデータを要求し得る。データに関する要求の各々および
要求されたデータは、プロセス２８およびＬＡＮ４の間でチャネル２２を通じて
インターフェース回路１０へおよびそこから通信を行うことが可能である。

【００２０】 クライアント・ノード２におけるプロセス２８にデータを伝送する場合に、好
適実施例は、マルチキャスト技術を利用して、クライアント・ノード２にデータ
をブロードキャストする。マルチキャスト技術は、当該技術分野でよく知られた
データ・ブロードキャスト方法であり、http://ds.internic.net/rfc/rfc1112.tx
tのＩｎｔｅｒｎｉｃから利用可能なRFC 1112, Host Extensions for IP Multic
astに詳細の述べられており、本願の参考に供せられる。マルチキャスト技術を
利用することによって、サーバ６は、ブロードキャスト・データ・パケットを同時
に受信する各クライアント・ノード２に、データ・パケットを一度送信することが
可能である。そして、好適実施例では、サーバ５は、各クライアント・ノード２
に関係なしに、総てのマルチキャスト・データを各クライアント・ノード２に送信
する。結果として、各クライアント・ノード２は到来するデータ・ストリームをフ
ィルタ処理し、ブロードキャスト・データの集合内で必要なデータを識別し、要
求されていない総ての不要なデータを破棄する必要がある。そして、各クライア
ント・ノード２は、クライアント・ノード２内の要請プロセス２８に必要なマルチ
キャスト・データを適切に配信する。

【００２１】 有利なことに、ネットワーク・アプリケーション・ソフトウエアが入来する各々
のデータ・パケットを検査し、それらの中で不要なデータを識別するところのマ
ルチキャスト技術を利用する従来の配信データ・ネットワークとは異なり、好適
実施例では、クライアント・ノード２は、インターフェース回路１０およびネッ
トワーク・アプリケーション・ソフトウエア２０の両者において入来するデータ・
ストリームをフィルタ処理する。インターフェース回路１０に関し、好適実施例
では、インターフェース回路１０は、ＬＡＮ４に関してデータ・ストリームを受
信および送信する６４までのアドレス可能なチャネル２２を包含し得る。なお、
本発明はこれに限定されない。むしろ、例えば、カリフォルニア州パロ・アルト
のサン・マイクロシステムズ（商標）から入手可能なＳＰＡＲＣワークステーシ
ョン（商標）のインターフェース回路のような、ほとんどのクラアイント・ノー
ド・プラットフォームは、いくつかのアドレス可能なマルチキャスト・イネーブル
・チャネルを包含する。さらに、当業者は、配下のインターフェース回路を制御
するリンク階層プログラム・インターフェースの一般的利用可能性を認識するで
あろう。

【００２２】 本発明によれば、データ配信管理部２４は、インターフェース回路１０に関す
る対応するリンク階層プログラム・インターフェース３２を利用して、インター
フェース１０内のチャネル２２の各々をイネーブル又はディセーブルすることが
可能である。しかしながら、アドレス可能なチャネルがディセーブルされるなら
ば、チャネル２２を通じて何らのデータもネットワーク・アプリケーション・ソフ
トウエア２０に伝送されない。例えば、図３に示すように、総てのチャネル２２
はデータを受信することが可能であるが、インターフェース回路１０は、チャネ
ル０，６，５８を除いて総てのチャネル２２をフィルタ処理し得る。図３から明
らかなように、チャネル２−５，７，５９−６３がディセーブルされる場合は、
これらのチャネルにおけるデータ・ストリームは完全にフィルタ処理される。例
として、ネットワーク・アプリケーション・ソフトウエアは、チャネル６３のディ
セーブルによる入来データのフィルタ処理の結果として、チャネル６３で入来す
るデータを分析およびフィルタ処理する必要がない。なお、これまでの例は、説
明の目的のためにのみなされている。つまり、インターフェース回路１０に対す
るリンク階層プログラム・インターフェース３２を利用して、本発明は、インタ
ーフェース回路１０内でアドレス可能なチャネル２２の任意の組み合わせをフィ
ルタ処理し、ディセーブルされたチャネルにおける不要なデータを効率的にフィ
ルタ処理する。

【００２３】 特に、チャネル２２の数を超えるマルチキャスト・データ量を収容するため、
各チャネル２２は加重に負荷が課され得る（オーバーロードされ得る。）。すな
わち、１データ・ストリーム以上が単独のチャネル２２にマルチプレクスされ得
る。その結果、インターフェース回路１０は完全なチャネル２２をイネーブルま
たはディセーブルすることが可能であるので、イネーブルされたチャネル２２で
マルチプレクスされた不要なデータは、インターフェース回路１０で実行される
フィルタ処理プロセスを逃れることが可能であり、ネットワーク・アプリケーシ
ョン・ソフトウエア２０を通じて伝達され得る。これに対処するために、好適実
施例では、ネットワーク・アプリケーション・ソフトウエア２０で付加的なフィル
タ処理プロセスが実行され得る。特に、データ配信管理部２４はイネーブルされ
たチャネル各々におけるデータ・ストリームの入来データを検査することが可能
である。例えば、図３に示すように、データ配信管理部２４は、プロセス２８に
より要求されたイネーブルされたチャネル０，６，５８から抽出し得る。その後
にデータ配信管理部２４は必要なデータを要請プロセス２８に転送し得る。

【００２４】 有利なことに、入来データ・ストリーム内のデータ検査において、データ配信
管理部２４は、不要なデータをゴミ箱を表現するもの３０に置くことによって過
剰な不要なデータを破棄し得る。しかしながら、当業者はこれらが例示目的のた
めのみに提供されていることを認識するであろう。つまり、不要なデータを破棄
する更に効率的かつ好適な方法は、単に、不要なデータをプロセス２８に更に送
信しないことである。

【００２５】 ＴＣＰ／ＩＰハードウエア１０におけるフィルタ処理およびデータ配信管理部
２４におけるソフトウエア・フィルタ処理の両者を実行することによって、デー
タ配信管理部２４が、必要なデータのみを要請プロセス２８に配信するように、
データ配信管理部２４は、どのハードウエア・チャネル２２がイネーブルされる
べきであってどれがディセーブルされるべきかを判定する。この判定を行うため
、データ配信管理部２４は、ハードウエア・チャネル２２に要求された及び要求
されなかった総てのデータをマッピングすることが可能である。より具体的には
、データ配信管理部２４は、静的解決手段（ソリューション）では参照すること
が可能であり、動的解決手段ではイネーブルする適切なチャネルのデータ・ソー
スにより通知され、プロセス２８により要求されるデータを受信する。

【００２６】 静的解決手段では、コンフィギュレーション・ファイルがデータ配信管理部２
４で作成され、ハードウエア・チャネル２２に要求されたデータに対応するデー
タ領域の静的マッピングを包含する。プロセス２８によるデータの要求時に、デ
ータ配信管理部２４は、コンフィギュレーション・ファイルに問い合わせること
のみを要し、インターフェース回路１０でイネーブルにする適切なチャネル２２
を判定する。しかしながら、当業者は、本発明がデータ領域のマッピングに限定
されないことを認めるであろう。むしろ、コンフィギュレーション・ファイルは
、要求されたマルチキャスト・データのソースに対応する任意の識別子の静的マ
ッピングを包含することが可能であり、例えば、所有者ネットワーク・アドレス
又はそのマルチキャスト・データのネットワーク・ソースに対応するネットワー
ク・アダプタ・アドレスのようなものである。一般に、コンフィギュレーション
・ファイルは、対応するハードウエア・チャネル２２に対する各識別子をマッピ
ングすることが可能である。

【００２７】 本発明方法は、チャネル判定問題に対するいくつかの動的解決手段を包含する
。１つの動的解決手段では、データ配信管理部２４は、データ配信管理部２４が
そこを通じて要求されたデータを受信し得るところの適切なチャネル２２を識別
する要求データのソースから、点対点(point-to-point)メッセージを受信し得る
。更なる他の動的解決手段では、データ配信管理部２４は、総てのチャネル２２
をポーリング(poll)し、各々のデータ・ストリーム内でデータ・ストリームのソ
ースを識別することが可能である。このように、データ配信管理部２４は、対応
するチャネル２２に関するデータ・ストリームのソースを動的にマッピングする
ことが可能である。

【００２８】 しかしながら、本発明の好適実施例では、データ配信管理部２４は、当該技術
分野で周知のハッシュ(hash)技術を利用して、イネーブルする適切なチャネルを
動的に識別することが可能である。一般に、探査および格納アルゴリズムは、デ
ータを辞書またはシンボル・テーブルに格納する。辞書における各事項は対応す
る探索キーを有し、それを通じてその事項は辞書からの抽出時に識別される。ハ
ッシュ技術は、ハッシュ関数を利用して動的に計算され得るハッシュ・テーブル
を利用する。具体的には、ハッシュ関数はデータに対する算術演算を使用して、
探索キーを生成し、ハッシュ・テーブル内の場所にちりばめる。理想的には各々
の探索キーは異なる位置に対応する。有利なことに、同一の算術演算が探索要求
に関して行われ、探索キーを生成し、対応するデータを見出す。

【００２９】 したがって、本発明にハッシュ技術を利用すると、好適実施例では、各々のマ
ルチキャスト・データは、ブロードキャストされるデータを包含するドメインの
名称にハッシュ関数を適用することによって、選択されたチャネルにおけるデー
タをブロードキャストすることが可能である。対応して、入来するマルチキャス
ト・データを受信するための適切なチャネル２２を判定する場合に、データ配信
管理部２４は、要求されたマルチキャスト・データに関連するドメイン名称(doma
in name)にハッシュ関数を動的に適用し、ブロードキャスト・データを受信する
ための対応するチャネル２２を識別する。ドメイン名称へのハッシュ関数の適用
は、「ドメイン名称のハッシュ化(hashing the domain name)」と呼ばれる。し
かしながら、当業者は、本発明がドメイン名称のみをハッシュ化することに限定
されないことを認めるであろう。むしろ、ハッシュ技術は、マルチキャスト・デ
ータ・ソースに対応する任意の識別子をハッシュ化することによって利用され得
る。

【００３０】 ドメイン名称のハッシュ化による探索キーは、「ハッシュ化ドメイン名称(has
hed domain name)」と呼ばれる。ハッシュ化ドメイン名称は適切なチャネル２２
に対応し、これを通じてデータ配信管理部２４は入来するマルチキャスト・デー
タを受信する。対応するチャネル２２が識別されると、その後にデータ配信管理
部２４は識別されたチャネル２２をイネーブルにし、それを通じてデータ配信管
理部２４は要求されたブロードキャストされたマルチキャスト・データを受信す
ることが可能である。

【００３１】 図４Ａないし４Ｃは、全体として、本発明の好適実施例による方法を示すフロ
ーチャートである。図４Ａないし４Ｃに示される方法は、ネットワーク・アプリ
ケーション２０で実行されることが好ましい。より具体的には、本発明方法は、
例えばサーバ６およびデータ配信管理部２４のようなＬＡＮ４におけるブロード
キャスト・データ・ソースからのデータを要求する各プロセス２８の間の相互作用
を含み、チャネル２２におけるブロードキャスト・データのハードウエアおよび
ソフトウエア・フィルタ処理を行う。

【００３２】 本発明方法はステップ１００から始まり、プロセス２８は、その特定のプロセ
ス２８で要求されるブロードキャスト・データを識別する。好適実施例では、ブ
ロードキャスト・データは、データ・セットまたはモジュールにグループ化され得
る。さらに、各モジュールはドメイン--一般的にはデータのより高いレベルのソ
ースに関連づけられる。しかしながら、本発明はこれに限定されない。むしろ、
データ・モジュール・ドメインの階層構造は、データの可能な１形態にすぎない。
本発明は、平坦な(flat)データのみの構造にも等しく効果的である。

【００３３】 ステップ１０２では、プロセス２８はデータ配信ライブラリ２６に問い合わせ
を行い、要求されたブロードキャスト・データを包含するモジュールを区別する
。その後に、ステップ１０４において、このプロセスは、データ配信管理部２４
に「オープン＿モジュール(open_module)」を送信することによって、必要なマ
ルチキャスト・データに加入することができる。特に、加入およびフィルタ処理
手順の残りは、要請プロセス２８には明白(transparent)であり続ける。プロセ
ス２８が必要なマルチキャスト・データに加入すると、マルチキャスト・データが
マルチキャスト・データ・ソースからブロードキャスト送信される場合に、プロセ
ス２８は必要なマルチキャスト・データを時々受信することのみを要する。した
がって、データ配信管理部２４から要求されたデータを受領するまで、要請プロ
セス２８は通常の動作を再開することが可能である。

【００３４】 図４Ｂを参照するに、図４Ａのステップ１０４で送信されたオープン＿モジュ
ール要求を受領すると、ステップ１１２において、データ配信管理部２４は要求
されたモジュールに対応するドメインを識別し得る。ステップ１１４では、デー
タ配信管理部２４が、ドメイン名称にハッシュ関数を適用し、イネーブルする適
切なチャネル２２を判定する。ステップ１１６において、判定されたチャネル２
２が既にオープンされてはいないならば、ステップ１１８において、データ配信
管理部２４が、例えば転送制御プロトコル(TCP: transport control protocol)
「ソケット（）」関数呼出を利用して、チャネルを解放する（オープン）ことが
可能であり、そこではインターネット・プロトコル（ＩＰ）ソース・アドレス、Ｉ
Ｐ宛先アドレス、ソース・ポートおよび宛先ポートが指定される。特に、要求さ
れるデータはＩＰマルチキャスト・データであり得るので、ＩＰソース・アドレス
は、ＲＦＣ１１１２で詳細に説明されるクラスＤのＩＰマルチキャスト・アドレ
スとすることが可能である。

【００３５】 詳細に上述したように、各チャネル２２は、マルチキャスト・データ・ソースか
らの複数のデータ・ストリームに関して、過剰に負荷が課せられ得る（オーバー
ロードされ得る）。このため、ステップ１１６において、データ配信管理部２４
は既にオープン・チャネル２２を識別し得るが、データ配信管理部２４は所望の
マルチキャスト・データ・ソースから発したデータをここで排除することが可能で
ある。判定ステップ１２０において、データ配信管理部２４は、所望のモジュー
ルが不要なデータとして処理される目下のソフトウエアであるか否かを判定する
。具体的には、データ配信管理部２４は、オープンのチャネル２２の各々に関し
て過剰に負荷の課されたモジュールのリストを維持することが可能である。モジ
ュールのリストに問い合わせることによって、データ配信管理部２４は、オープ
ンのチャネル２２におけるモジュールの存在を検出することが可能である。

【００３６】 より具体的には、データ配信管理部２４は、オープンのチャネル２２の各々に
関する過剰に負荷の課された特定のモジュールからのデータに加入するプロセス
のリストを維持し得る。ステップ１２０では、特定のモジュールからのデータに
加入するプロセスのリストにより、データ配信管理部２４は、プロセスが既にオ
ープン・チャネル２２におけるモジュールに加入しているか否かを判定すること
が可能である。他のプロセスが既に特定のモジュールに加入しているならば、要
請プロセス２８はステップ１２６においてプロセスのリストに付加されるにすぎ
ない。そうでなければ、要請プロセス２８がモジュールからのデータを要求する
最初のものであるならば、データ配信管理部２４はステップ１２４において、オ
ープン・チャネル２２に関するオーバーロードのモジュールのリストにそのモジ
ュールを追加することによって、オープン・チャネル２２におけるモジュールに
加入することが可能である。そして、ステップ１２６において、データ配信管理
部２４は、要請プロセス２８を、モジュールに包含されるデータを要請プロセス
のリストに付加することが可能である。

【００３７】 図４Ａを参照するに、ステップ１０４におけるオープン＿モジュール・メッセ
ージを送信することによる要求マルチキャスト・データへの加入の後に、プロセ
ス２８は、データ配信管理部２４から要求されたブロードキャスト・データを受
信するまで、通常の動作で進行することが可能である。より具体的には、データ
配信管理部２４が、モジュールのリストに包含されるモジュールに関するオープ
ン・チャネルにおけるブロードキャスト・データを識別する場合に、データ配信管
理部はモジュール・ユーザのリストを問い合わせ、モジュール・ユーザのリスト内
の各プロセス２８の各々に受信したブロードキャスト・データを配信する。この
ようにして、最初にインターフェース回路１０の階層において、そして第２にデ
ータ配信管理部２４の階層において、プロセス２８は要求されるブロードキャス
ト・データを容易に受信する一方、要求されないブロードキャスト・データは選択
的に破棄される。

【００３８】 プロセス２８がもはや要求されるブロードキャスト・データを必要としなくな
るまで、プロセス２８は要求されるブロードキャスト・データを受信し続ける。
判定ステップ１０８において、プロセス２８がもはや要求されたマルチキャスト
・データを必要しないと判定されるならば、ステップ１１０においてプロセス２
８は、「クローズ＿モジュール(close_module)」要求をデータ配信管理部２４に
送信することによって、マルチキャスト・データに対して非加入になることが可
能である。特に、非加入手順の残りは要請プロセス２８にとって明白である。プ
ロセス２８が以前の要求されたマルチキャスト・データに非加入になると、プロ
セス２８は通常の動作に戻ることが可能である。以前の要求されたマルチキャス
ト・データは、データ配信管理部２４の命令により、ソフトウエアおよび可能な
ハードウエア処理がなされ、プロセス２８はもはや、以前の要求されたマルチキ
ャスト・データのソースからブロードキャスト・データ・パケットを受信しない。

【００３９】 図４Ｃを参照するに、クローズ＿モジュール要求を受領すると、ステップ１２
８において、データ配信管理部２４は、モジュール・ユーザのリストから要請プ
ロセス２８を除去することが可能である。判定ステップ１３０において、要請プ
ロセス２８がそのモジュールの利用を要求する最後のプロセスでないならば、デ
ータ配信管理部２４は依然としてそのモジュールにおける他のプロセスにデータ
を配信する必要があるので、データ配信管理部２４は他のプロセスのために実行
する必要がある。逆に、判定ステップ１３０で要請プロセス２８がモジュールの
利用を要求する最後のプロセスであるならば、ステップ１３４において、データ
配信管理部２４は、オーバーロード・オープン・チャネル２２におけるモジュール
のリストからそのモジュールを除去することにより、その要請プロセス２８をブ
ロードキャスト・データから非加入にすることができる。しかしながら、有利な
ことに、オープン・チャネル２２がオーバーロードでなく、あるソース・モジュー
ルからのデータ・ストリームのみがチャネル２２を利用しているようならば、デ
ータ配信管理部２４はそのチャネルをディセーブルにすることが可能である。デ
ータ配信管理部２４は、インターフェース回路１０に対するリンク階層プログラ
ム・インターフェースを再び利用して、ステップ１３８においてチャネル２４を
クローズすることができる。そして、本方法はステップ１４０で終了する。

【００４０】 要するに、マルチキャスト技術を利用してクライアント・ノードへデータを配
信するサーバ・ベース手法は、データ配信ネットワークにクライアント・ノードを
追加する結果としての帯域を縮小することによる実効性のペナルティの影響を受
けやすい。本発明のマルチキャスト・チャネル手法は、複数のチャネルにわたっ
てブロードキャスト・データを配信することによって、拡張するクライアント・ノ
ード・ベースに利用可能な帯域を増加させることが可能である。したがって、ク
ライアント・ノードは、クライアント・ノード各々のネットワーク・インターフェ
ース回路内で不要なブロードキャスト・データを選択的にフィルタ処理すること
が可能である。具体的には、過剰なソフトウエア・フィルタ処理を回避するため
に、クライアント・ノードは、関心のあるデータが流れているネットワーク・イン
ターフェース回路におけるチャネルのみをイネーブルにすることが可能である。
チャネルがオーバーロードする場合には依然としてソフトウエア・フィルタ処理
が必要とされ得るが、実効性利得(performance gain)は依然として良好であり得
る。

【図面の簡単な説明】

【図１】 図１は、本発明が使用され得るコンピュータ・ネットワークに基づくサーバを
示す図である。

【図２】 図２は、典型的なクライアント・ノードを示す図である。

【図３】 図３は、ネットワーク・アプリケーション・ソフトウエアおよびハードウエアを
示す図１の典型的なネットワーク・クライアント・ノードのハイ・レベル・アーキテ
ックチャである。

【図４Ａ】 図４Ａ−４Ｃは、本発明の好適実施例による方法を示すフロー・チャートであ
る。

【図４Ｂ】 図４Ａ−４Ｃは、本発明の好適実施例による方法を示すフロー・チャートであ
る。

【図４Ｃ】 図４Ａ−４Ｃは、本発明の好適実施例による方法を示すフロー・チャートであ
る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｃ Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ， ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ， ＺＡ，ＺＷ Ｆターム(参考） 5B045 BB02 BB06 BB28 BB42 5K030 LC01 LC18 LD06

Claims (17)

【特許請求の範囲】
1. 【請求項１】 要求されたマルチキャスト・データを複数のマルチキャスト
   通信チャネルを通じて受信する方法であって： 複数のマルチキャスト通信チャネルから、前記要求されたマルチキャスト・デ
   ータを受信するためのソース通信チャネルを選択するステップ； 選択されたソース通信チャネルをイネーブルにするステップ； イネーブルされたソース通信チャネルを通じて前記要求されたマルチキャスト
   ・データを受信するステップ； 前記要求されたマルチキャスト・データを、要求するプロセスに転送するステ
   ップ；および 前記選択されたソース通信チャネルを通じて更なるデータが受信されることは
   もはや要求されないことを、前記要求プロセスが示す場合に、前記選択されたソ
   ース通信チャネルをディセーブルにするステップ； より成ることを特徴とする方法。
2. 【請求項２】 請求項１記載の方法において、前記ソース通信チャネルが、
   複数のマルチキャスト・データ・ソースからのマルチキャスト・データによりオー
   バーロードになることを特徴とする方法。
3. 【請求項３】 請求項２記載の方法において、更に： 受信したマルチキャスト・データから不要なマルチキャスト・データをフィルタ
   処理するステップ；および フィルタ処理されたマルチキャスト・データを、要求するプロセスに転送する
   ステップ； より成ることを特徴とする方法。
4. 【請求項４】 請求項１記載の方法において、前記選択するステップが、更
   に： 要求されたマルチキャスト・データのソースに対応する識別子をハッシュ化す
   るステップ；および ハッシュ化された識別子を前記ソース通信チャネルとして識別するステップ； より成ることを特徴とする方法。
5. 【請求項５】 請求項１記載の方法において、前記選択するステップが、更
   に、要求されたマルチキャスト・データのソースから、前記ソース通信チャネル
   を識別するチャネル識別メッセージを受信するステップより成ることを特徴とす
   る方法。
6. 【請求項６】 請求項１記載の方法において、前記選択するステップが、更
   に： 要求されたマルチキャスト・データに関して前記複数の通信チャネルを監視す
   るステップ；および 前記通信チャネルを通じて受信したマルチキャスト・データを処理し、前記要
   求されたマルチキャスト・データが送信されるところの少なくとも１つのソース
   通信チャネルを選択するステップ； より成ることを特徴とする方法。
7. 【請求項７】 請求項１記載の方法において、前記選択するステップが、更
   に： マルチキャスト・データ・ソースおよびソース通信チャネルのコンフィギュレー
   ション・テーブルを構築するステップであって、マルチキャスト・データ・ソース
   の各々がソース通信チャネルに対応するところのステップ；および 前記コンフィギュレーション・テーブル内で、要求されたマルチキャスト・デ
   ータのマルチキャスト・データ・ソースに対応するソース通信チャネルを見出すス
   テップ； より成ることを特徴とする方法。
8. 【請求項８】 複数のマルチキャスト・チャネルを通じてマルチキャスト・デ
   ータを受信するネットワーク・クライアント・ノードにおいてデータの効率的なフ
   ィルタ処理を行う方法であって： クライアント・ノードにおけるプロセスから、マルチキャスト・データの要求を
   受信するステップ； 要求されたデータのマルチキャスト・データ・ソースを識別するステップ； 複数のマルチキャスト通信チャネルから、識別されたマルチキャスト・データ・
   ソースからの前記要求されたマルチキャスト・データを受信するためのソース通
   信チャネルを選択するステップ； 前記選択されたソース通信チャネルをイネーブルにするステップ； イネーブルにされたソース通信チャネルを通じて、識別されたマルチキャスト
   ・データ・ソースから前記マルチキャスト・データを受信するステップ； 前記マルチキャスト・データを、要求するクライアント・ノード・プロセスに転
   送するステップ；および 前記選択されたソース通信チャネルを通じて前記識別されたマルチキャスト・
   データ・ソースから、更なるデータが受信されることはもはや要求されないこと
   を、前記要求クライアント・ノード・プロセスが示す場合であって、前記選択され
   たソース通信チャネルを通じて前記識別されたマルチキャスト・データ・ソースか
   ら受信されるべき更なるデータの継続的必要性を、他の要求クライアント・ノー
   ド・プロセスが示さない場合に、前記選択されたソース通信チャネルをディセー
   ブルにするステップ； より成ることを特徴とする方法。
9. 【請求項９】 請求項８記載の方法において、更に： 受信したマルチキャスト・データから、要求されなかったマルチキャスト・デー
   タをフィルタ処理するステップ； 前記要求されなかったマルチキャスト・データを破棄するステップ；および フィルタ処理されたマルチキャスト・データを前記プロセスに転送するステッ
   プ； より成ることを特徴とする方法。
10. 【請求項１０】 請求項８記載の方法において、前記選択するステップが、
    更に： 識別されたマルチキャスト・データ・ソースをハッシュ化するステップ；および ハッシュ化されたマルチキャスト・データ・ソースを前記ソース通信チャネルと
    して識別するステップ； より成ることを特徴とする方法。
11. 【請求項１１】 請求項８記載の方法において、前記選択するステップが、
    更に、前記ソースから、前記ソース通信チャネルを識別するチャネル識別メッセ
    ージを受信するステップより成ることを特徴とする方法。
12. 【請求項１２】 請求項８記載の方法において、前記選択するステップが、
    更に： 要求されたマルチキャスト・データに関して前記マルチキャスト・チャネルを監
    視するステップ；および マルチキャスト・チャネルを通じて受信したマルチキャスト・データを処理し、
    要求されたマルチキャスト・データが送信されるソース通信チャネルを選択する
    ステップ； より成ることを特徴とする方法。
13. 【請求項１３】 請求項８記載の方法において、前記選択するステップが、
    更に： マルチキャスト・データ・ソースおよびソース通信チャネルのコンフィギュレー
    ション・テーブルを構築するステップであって、マルチキャスト・データ・ソース
    の各々がソース通信チャネルに対応するところのステップ；および 前記コンフィギュレーション・テーブル内で、要求されたマルチキャスト・デ
    ータのマルチキャスト・データ・ソースに対応するソース通信チャネルを見出すス
    テップ； より成ることを特徴とする方法。
14. 【請求項１４】 ネットワーク・クライアント・ノードにおけるマルチキャス
    ト・データの効率的なフィルタ処理の方法であって： クライアント・ノードにおける複数のプロセスからマルチキャスト・データの要
    求を受信するステップ； 前記要求の各々についてマルチキャスト・データ・ソースを識別するステップ；
    および 識別されたマルチキャスト・データ・ソースの各々について、複数のマルチキャ
    スト通信チャネルから、対応するソース通信チャネルを選択し，選択されたソー
    ス通信チャネルをイネーブルし，前記ソース通信チャネルを通じてマルチキャス
    ト・データを受信し，要求するプロセスの各々に、前記要求するプロセスによる
    前記要求に対応するマルチキャスト・データを転送し，前記選択されたソース通
    信チャネルを通じて前記識別されたマルチキャスト・データ・ソースから、更なる
    データが受信されることはもはや要求されないことを、前記要求クライアント・
    ノード・プロセスが示す場合であって、前記選択されたソース通信チャネルを通
    じて前記識別されたマルチキャスト・データ・ソースから受信されるべき更なるデ
    ータの継続的必要性を、他の要求クライアント・ノード・プロセスが示さない場合
    に、前記選択されたソース通信チャネルをディセーブルにするところのステップ
    ； より成ることを特徴とする方法。
15. 【請求項１５】 請求項１４記載の方法において、更に： 前記ソース通信チャネルを通じて受信した前記マルチキャスト・データから、
    要求されていないマルチキャスト・データをフィルタ処理するステップ； 前記要求されていないマルチキャスト・データを破棄するステップ；および フィルタ処理されたマルチキャスト・データを前記プロセスに配信するステッ
    プ； より成ることを特徴とする方法。
16. 【請求項１６】 請求項１４記載の方法において、前記選択するステップが
    、更に： 識別されたマルチキャスト・データ・ソースの各々をハッシュ化するステップ；
    および ハッシュ化されたマルチキャスト・データ・ソースの各々について、ソース通信
    チャネルを識別するステップ； より成ることを特徴とする方法。
17. 【請求項１７】 請求項１４記載の方法において、前記識別されたマルチキ
    ャスト・データ・ソースが、要求されたマルチキャスト・データを包含する少なく
    とも１つのモジュールを有するドメイン名称であることを特徴とする方法。