(57)【要約】【課題】  データ転送の負荷を低減することができる通信装置及び通信方法を提供する。【解決手段】  通信装置は、トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第１記憶部と、前記配信データを受信する第１受信部と、前記第１受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第１転送処理部と、前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第２受信部と、前記第２受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有する。【選択図】図８
2019049950.tif 000002
【特許請求の範囲】
【請求項１】
トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第１記憶部と、
前記配信データを受信する第１受信部と、
前記第１受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第１転送処理部と、
前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第２受信部と、
前記第２受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有することを特徴とする通信装置。
【請求項２】
前記トピック名に応じた前記要求メッセージの転送先ノードが登録されたメッセージテーブルを記憶する第２記憶部と、
前記第２受信部が受信した前記要求メッセージを、前記要求メッセージに指定された前記トピック名に応じた転送先ノードが前記配信テーブルに登録されていない場合、前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに転送する第２転送処理部とを有することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記配信データの要求に応じて前記要求メッセージを生成する生成部と、
前記第２受信部が受信した前記要求メッセージの前記要求元ノード及び前記トピック名を記録する記録部とを有し、
前記生成部は、前記記録部が記録した前記トピック名を指定した前記要求メッセージを生成した場合、前記記録部が記録した前記要求元ノードの識別子を、前記生成した前記要求メッセージに追加し、前記要求メッセージを前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに送信することを特徴とする請求項２に記載の通信装置。
【請求項４】
前記登録部は、前記第２受信部が受信した前記要求メッセージに、前記要求メッセージの前記要求元ノードとは別のノードの識別子が含まれる場合、前記配信テーブルに登録された転送先ノードのうち、前記別のノードに該当する転送先ノードを前記要求元ノードに更新することを特徴とする請求項１乃至３の何れかに記載の通信装置。
【請求項５】
前記要求メッセージには、前記配信データの通信品質の指標値が含まれ、
前記登録部は、前記第２受信部が受信した前記要求メッセージに含まれる前記通信品質の指標値と所定値とを比較し、該比較結果に応じて前記要求元ノードを前記配信テーブルに登録することを特徴とする請求項１乃至４の何れかに記載の通信装置。
【請求項６】
トピック名に応じた配信データの転送先ノードが登録される配信テーブルを用い、
前記配信データを受信し、
前記受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送し、
前記トピック名を指定して前記配信データを要求する要求メッセージを受信し、
前記受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録することを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、通信装置及び通信方法に関する。
【背景技術】
【０００２】
例えば、企業間でデータ交換を行うため、インターネットなどのＩＰ（Internet Protocol）ネットワーク及び物理ネットワーク上にＰ２Ｐ（Peer to Peer）のオーバレイネットワークが形成される。このオーバレイネットワークでは、例えば企業ごとのゲートウェイ装置が、所定のトピック名に応じたデータを配信するパブリッシャ、及びパブリッシャからデータ配信を受けるサブスクライバの一方または両方として機能することにより、Ｐｕｂ／Ｓｕｂ（Publish/Subscribe）モデル（例えば特許文献１及び非特許文献１を参照）を構成する。
【０００３】
サブスクライバは、トピック名を指定した事前の契約（サブスクライブ）に従って、そのトピック名に応じたデータを受信する。オーバレイネットワークには、トピック名に対応するハッシュ値によるハッシュ空間が形成されており、サブスクライバが、サブスクライブを要求するサブスクライブメッセージを送信すると、サブスクライブメッセージは、トピック名に応じたハッシュ値に従い、ハッシュ値を管理する管理ノードまで転送される。
【０００４】
また、パブリッシャは、管理ノードを根とするツリー状の経路を介して複数のサブスクライバにデータをマルチキャスト配信する。このため、サブスクライブメッセージの経路とデータの経路は互いに逆向きの関係となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−１１５７８４号公報
【非特許文献】
【０００６】
【非特許文献１】M.Castro et al.,”SCRIBE: A large-scale and decentralized application-level multicast infrastructure”,IEEE Journal on Selected Areas in communications,vol.20,no.8,pp.1489-1499,2002
【発明の概要】
【発明が解決しようとする課題】
【０００７】
データの経路上には、そのデータの配信先のサブスクライバ以外のサブスクライバや、他のトピックのデータを配信するパブリッシャも存在する。これらのサブスクライバやパブリッシャは、自己の受信対象または配信対象のデータの転送処理だけでなく、他のデータの転送処理も行うため、負荷が高くなる。
【０００８】
これに対し、特許文献１には、共通のトピックへの参加ノードだけで配信ツリーを構成する点が記載されているが、他の各ノードから、トピックを識別するキーの通知を受けることによりトピックに基づく経路表を構築する必要があるため、処理が複雑化し、かえって負荷が増加するおそれがある。
【０００９】
そこで本件は、データ転送の負荷を低減することができる通信装置及び通信方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様では、通信装置は、トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第１記憶部と、前記配信データを受信する第１受信部と、前記第１受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第１転送処理部と、前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第２受信部と、前記第２受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有する。
【００１１】
１つの態様では、通信方法は、トピック名に応じた配信データの転送先ノードが登録される配信テーブルを用い、前記配信データを受信し、前記受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送し、前記トピック名を指定して前記配信データを要求する要求メッセージを受信し、前記受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する方法である。
【発明の効果】
【００１２】
１つの側面として、データ転送の負荷を低減することができる。
【図面の簡単な説明】
【００１３】
【図１】Ｐ２Ｐネットワークの一例を示す構成図である。
【図２】比較例におけるサブスクライブメッセージ及び配信データの経路を示す図である。
【図３】実施例におけるサブスクライブメッセージ及び配信データの経路を示す図である。
【図４】ゲートウェイ装置の一例を示す構成図である。
【図５】登録要求メッセージ及びサブスクライブメッセージの転送処理の一例を示す図である。
【図６】メッセージ情報テーブル及び配信ルーティングテーブルの例を示す図である。
【図７】サブスクライブメッセージの転送処理の一例を示す図である。
【図８】配信データの転送処理の一例を示す図である。
【図９】サブスクライブメッセージの転送処理の他の例を示す図である。
【図１０】配信データの転送処理の他の例を示す図である。
【図１１】パブリッシャにおけるハッシュ値の登録処理の一例を示すフローチャートである。
【図１２】登録要求メッセージによるハッシュ値の登録処理の一例を示すフローチャートである。
【図１３】サブスクライブメッセージ及び配信データの受信処理の一例を示すフローチャートである。
【図１４】接続要求メッセージの受信処理の一例を示すフローチャートである。
【図１５】サブスクライブＭＳＧの送信処理の一例を示すフローチャートである。
【図１６】他の実施例における配信ルーティングテーブルを示す図である。
【図１７】他の実施例におけるサブスクライブメッセージの転送処理を示す図である。
【図１８】他の実施例における配信データの転送処理を示す図である。
【図１９】サブスクライブメッセージの送信処理の他の例を示すフローチャートである。
【図２０】サブスクライブメッセージ及び配信データの受信処理の他の例を示すフローチャートである。
【発明を実施するための形態】
【００１４】
図１は、Ｐ２Ｐネットワークの一例を示す構成図である。Ｐ２Ｐネットワーク（点線参照）は、一例として、インターネット上のオーバレイネットワークとして構成され、４つの企業（Ｗ社、Ｖ社、Ｙ社、Ｚ社）の間のデータ交換に用いられる。
【００１５】
Ｗ社、Ｖ社、Ｙ社、及びＺ社のデータ処理システムには、例えばＬＡＮ（Local Area Network）などの社内ネットワークＮＷａ〜ＮＷｄと、社内ネットワークＮＷａ〜ＮＷｄをインターネットと接続するためのゲートウェイ装置１とが設けられている。各ゲートウェイ装置１は、通信装置の一例であり、所定のトピック名に応じたデータを配信するパブリッシャ、及びパブリッシャからデータ配信を受けるサブスクライバの一方または両方として機能することにより、Ｐｕｂ／Ｓｕｂモデルを構成する。
【００１６】
各ゲートウェイ装置１の間に論理的なリンク（以下、「論理リンク」と表記）が設定されることにより、インターネット上にＰ２Ｐネットワークがオーバレイされる。なお、本例のＰｕｂ／Ｓｕｂモデルは、ネットワーク監視制御装置などが用いられず、各ゲートウェイ装置１の間の協調動作によりトピック名ごとのデータの配信が行われる。なお、配信されるデータを、以下の説明では「配信データ」と表記する。
【００１７】
図２は、比較例におけるサブスクライブメッセージ及び配信データの転送経路を示す図である。より具体的には、図２には、ゲートウェイ装置１がそれぞれ設けられたノードＡ〜Ｈ，Ｘから構成されるＰ２Ｐネットワークが示されている。なお、以降の説明では、ゲートウェイ装置１を「ノード」と記載する。符号Ｓは、所定のトピック名に関するサブスクライバを示し、符号Ｐは、そのトピック名に関するパブリッシャを示す。つまり、ノードＡ，Ｄ，Ｅ，Ｇはサブスクライバであり、ノードＸはパブリッシャである。
【００１８】
符号Ｇｐは、サブスクライブメッセージ（ＭＳＧ）の経路の例を示す。サブスクライブＭＳＧは、トピック名を指定して配信データを要求する要求メッセージの一例であり、ノードＡ〜ＨはサブスクライブＭＳＧを送信することによりサブスクライバとして動作することができる。
【００１９】
ノードＡ〜Ｈ，Ｘは全体でハッシュ空間を形成しており、各ノードＡ〜Ｈ，Ｘは一部のハッシュ空間を管理する。サブスクライブＭＳＧには、トピック名に応じたハッシュ値が含まれており、ハッシュ値に従って、各サブスクライバからハッシュ値を管理する管理ノードＣに転送される。
【００２０】
また、符号Ｇｑは、配信データの経路の例を示す。配信データは、パブリッシャであるノードＸから、サブスクライブＭＳＧの経路を反対方向にたどるように各サブスクライバにマルチキャスト配信される。このとき、配信データの経路は、ノードＸを根とするツリー状の経路となる。
【００２１】
配信データの経路上には、配信データのトピック名に関するサブスクライバ及びパブリッシャ以外のノードＢ，Ｃ，Ｆ（つまり、配信データの配信先のサブスクライバ以外のサブスクライバや、他のトピックの配信データを配信するパブリッシャ）も存在する。これらのノードＢ，Ｃ，Ｆ（以下、「非配信ノード」と表記）では、自己の受信対象または配信対象のデータの転送処理だけでなく、他のデータの転送処理も行われるため、負荷が高くなる（「負荷高」参照）。
【００２２】
そこで、実施例のゲートウェイ装置１は、非配信ノードＢ，Ｃ，Ｆを除くオーバレイネットワークをサブスクライブＭＳＧに基づいて構成することで、非配信ノードＢ，Ｃ，Ｆのデータ転送の負荷を低減する。
【００２３】
図３は、実施例におけるサブスクライブメッセージ及び配信データの経路を示す図である。図３において、図２と共通する構成には同一の符号を付し、その説明は省略する。
【００２４】
符号Ｇｒは、サブスクライブＭＳＧの経路（点線参照）を示す。サブスクライブＭＳＧは、新規のサブスクライバからハッシュ値に従った経路に沿って既存のサブスクライバまたはパブリッシャまで転送される。例えば、ノードＡがサブスクライバとなる場合、サブスクライブＭＳＧは、ノードＡからノードＣを経由して、パブリッシャのノードＸまで転送され、ノードＤがサブスクライバとなる場合、サブスクライブＭＳＧは、ノードＤからノードＣを経由して、パブリッシャのノードＸまで転送される。
【００２５】
また、ノードＥがサブスクライバとなる場合、サブスクライブＭＳＧは、ノードＥからノードＢを経由して、既存のサブスクライバのノードＡまで転送され、ノードＧがサブスクライバとなる場合、サブスクライブＭＳＧは、ノードＧからノードＦを経由して、既存のサブスクライバのノードＥまで転送される。
【００２６】
符号Ｇａは、サブスクライブＭＳＧの一例を示す。サブスクライブＭＳＧには、配信の要求対象のトピック名に応じたハッシュ値と、サブスクライバＩＤとが含まれる。サブスクライバＩＤは、新規のサブスクライバとなるノードＡ〜Ｈの識別子、つまり配信データの要求元ノードＡ〜Ｈの識別子（ＩＤ）である。
【００２７】
また、符号Ｇｓは、配信データの経路（実線参照）を示す。点線は、上述したサブスクライブＭＳＧの経路を構成するためのＰ２Ｐネットワーク（以下、「ＭＳＧ転送ネットワーク」と表記）のリンクを示す。
【００２８】
パブリッシャまたは各サブスクライバは、サブスクライブＭＳＧを受信したとき、そのサブスクライブＭＳＧに示されるサブスクライバＩＤを配信データの転送先ノードと判断し、配信ルーティングテーブルに登録する。なお、配信ルーティングテーブルの構成については後述する。
【００２９】
また、符号Ｇｂは、配信データを含む配信データＭＳＧの一例を示す。配信データＭＳＧには、配信データのトピック名に応じたハッシュ値と、配信元のパブリッシャのノードＸの識別子であるパブリッシャＩＤと、配信データとが含まれる。ハッシュ値は、例えばハッシュ関数により配信データのトピック名から一意に定まる識別子である。
【００３０】
パブリッシャまたは各サブスクライバは、配信ルーティングテーブルに従って配信データＭＳＧのハッシュ値に応じた転送先ノードに配信データを転送する。これにより、パブリッシャまたは各サブスクライバは、配信データに非配信ノードＢ，Ｃ，Ｆを経由させずに、配信データをサブスクライバに転送することができるため、非配信ノードＢ，Ｃ，Ｆのデータ転送の負荷が低減される。
【００３１】
例えば、パブリッシャのノードＸは、新規のサブスクライバのノードＤを配信ルーティングテーブルの転送先ノードとして登録することにより、配信データに非配信ノードＣを経由させずに配信データをノードＤに転送することができる。また、既存のサブスクライバのノードＥは、新規のサブスクライバのノードＧを配信ルーティングテーブルの転送先ノードとして登録することにより、配信データに非配信ノードＦを経由させずに配信データをノードＧに転送することができる。
【００３２】
また、パブリッシャまたは各サブスクライバは、配信ルーティングテーブルへのサブスクライバＩＤの登録とともに、新規のサブスクライバに対して論理リンク（実線参照）を確立する。例えば、パブリッシャのノードＸは、新規のサブスクライバのノードＤと論理リンクを確立し、既存のサブスクライバのノードＥは、新規のサブスクライバのノードＧと論理リンクを確立する。
【００３３】
これにより、特定のトピック名（ハッシュ値）について、パブリッシャのノードＸと各サブスクライバのノードＡ、Ｄ，Ｅ，Ｇから構成されるＰ２Ｐネットワークが、ＭＳＧ転送ネットワークとは別に形成される。すなわち、パブリッシャ及び各サブスクライバは、配信データを転送するための新たなオーバレイネットワーク（以下、「配信ネットワーク」と表記）を形成する。以下に、ゲートウェイ装置１の構成について述べる。
【００３４】
図４は、ゲートウェイ装置１の一例を示す構成図である。ゲートウェイ装置１は、ＣＰＵ（Central Processing Unit）１０、ＲＯＭ（Read Only Memory）１１、ＲＡＭ（Random Access Memory）１２、ストレージメモリ１３、及び複数の通信ポート１４を有する。ＣＰＵ１０は、互いに信号の入出力ができるように、ＲＯＭ１１、ＲＡＭ１２、ストレージメモリ１３、及び複数の通信ポート１４と、バス１９を介して接続されている。
【００３５】
ＲＯＭ１１は、ＣＰＵ１０を駆動するプログラムが格納されている。プログラムには、実施例の通信方法を実行する命令群が含まれている。ＲＡＭ１２は、ＣＰＵ１０のワーキングメモリとして機能する。
【００３６】
複数の通信ポート１４は、例えば他のノードＡ〜Ｈ，Ｘまたは社内ネットワークＮＷａ〜ＮＷｄとの通信を処理する。通信ポート１４は、例えばＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specified Integrated Circuit）などのハードウェアから構成される回路である。
【００３７】
より具体的には、通信ポート１４は、第１受信部の一例として、社内ネットワークＮＷａ〜ＮＷｄやパブリッシャまたはサブスクライバから配信データ（つまり配信データＭＳＧ）を受信し、バス１９を介しＣＰＵ１０に出力する。また、通信ポート１４は、第２受信部の一例として、新規のサブスクライバからサブスクライブＭＳＧを受信し、バス１９を介しＣＰＵ１０に出力する。なお、通信ポート１４は、他のメッセージなども受信してＣＰＵ１０に出力し、ＣＰＵ１０から入力された配信データや各種のメッセージなどを他のノードＡ〜Ｈ，Ｘや社内ネットワークＮＷａ〜ＮＷｄに送信する。
【００３８】
ＣＰＵ１０は、ＲＯＭ１１からプログラムを読み込むと、機能として、動作制御部１００、ハッシュ値登録部１０１、ＭＳＧ転送処理部１０２、ＭＳＧ生成部１０３、ＭＳＧ記録部１０４、配信データ転送処理部１０５、リンク確立部１０６、データ経路登録部１０７、及びノード接続要求部１０８が形成される。
【００３９】
また、ストレージメモリ１３には、ハッシュ値管理テーブル１３０、ＭＳＧルーティングテーブル１３１、ＭＳＧ情報テーブル１３２、及び配信ルーティングテーブル１３３が記憶されている。なお、ストレージメモリ１３は、配信ルーティングテーブル１３３を記憶する第１記憶部の一例、及びＭＳＧルーティングテーブル１３１を記憶する第２記憶部の一例である。ここで、配信ルーティングテーブル１３３及びＭＳＧルーティングテーブル１３１は別々のストレージメモリ１３に記憶されてもよい。
【００４０】
動作制御部１００はゲートウェイ装置１の全体の動作を制御する。動作制御部１００は、プログラムに定めされたシーケンスに従いハッシュ値登録部１０１、ＭＳＧ転送処理部１０２、ＭＳＧ生成部１０３、ＭＳＧ記録部１０４、配信データ転送処理部１０５、リンク確立部１０６、データ経路登録部１０７、及びノード接続要求部１０８に対して動作を指示する。
【００４１】
ハッシュ値登録部１０１は、社内ネットワークＮＷａ〜ＮＷｄから登録を要求されたハッシュ値を、そのハッシュ値が当該ノードの管理対象である場合、パブリッシャのノードＸの識別子に対応付けてハッシュ値管理テーブル１３０に登録する。また、ハッシュ値登録部１０１は、ハッシュ値が当該ノードの管理対象ではない場合、ハッシュ値の登録要求ＭＳＧを、ＭＳＧルーティングテーブル１３１に従った転送先ノードに転送する。登録要求ＭＳＧには、登録対象のハッシュ値と、そのハッシュ値に応じた配信データのパブリッシャのノードＸの識別子（例えばＩＰアドレス）とが含まれる。
【００４２】
ハッシュ値登録部１０１は、ＭＳＧルーティングテーブル１３１に基づきハッシュ値が当該ノードＡ〜Ｈ，Ｘの管理対象であるか否かを判定する。ＭＳＧルーティングテーブル１３１には、後述するようにハッシュ空間（ハッシュ値の範囲）とノードＡ〜Ｈ，Ｘの対応関係が予め登録されている。ＭＳＧルーティングテーブル１３１は、ＭＳＧ転送ネットワークにおけるルーティングテーブルである。
【００４３】
ＭＳＧ転送処理部１０２は、ＭＳＧルーティングテーブル１３１に従いサブスクライブＭＳＧの転送処理を行う。ＭＳＧ転送処理部１０２は、通信ポート１４が受信したサブスクライブＭＳＧを、サブスクライブＭＳＧに指定されたハッシュ値に応じた転送先ノードが配信ルーティングテーブル１３３に登録されていない場合、ＭＳＧルーティングテーブル１３１に従ってハッシュ値に応じた転送先ノードに転送する。なお、ＭＳＧ転送処理部１０２は第２転送処理部の一例である。
【００４４】
つまり、ＭＳＧ転送処理部１０２は、当該ノードが非配信ノードである場合、サブスクライブＭＳＧをＭＳＧルーティングテーブル１３１に従い転送先ノードＡ〜Ｈ，Ｘに転送する。このため、サブスクライブＭＳＧは、新規のサブスクライバから既存のサブスクライバまたはパブリッシャまで転送される。
【００４５】
一方、ＭＳＧ転送処理部１０２は、当該ノードがサブスクライバまたはパブリッシャである場合、サブスクライブＭＳＧを他のノードＡ〜Ｈ，Ｘに転送しない。このため、サブスクライブＭＳＧの転送処理の負荷が、ＭＳＧ転送ネットワークにおいて低減される。
【００４６】
また、ＭＳＧ転送処理部１０２は、サブスクライブＭＳＧに指定されたハッシュ値が、ＭＳＧルーティングテーブル１３１に基づき当該ノードの管理対象であると判定した場合、ハッシュ値管理テーブル１３０に従ってパブリッシャのノードＸに転送する。このため、ＭＳＧ転送処理部１０２は、当該ノードの管理対象のハッシュ値が指定されたサブスクライブＭＳＧをパブリッシャに転送することができる。
【００４７】
ＭＳＧ転送処理部１０２は、通信ポート１４とノードＡ〜Ｈ，Ｘの対応関係に基づき、転送先ノードに該当する通信ポート１４に対してサブスクライブＭＳＧを出力する。ここで、通信ポート１４とノードＡ〜Ｈ，Ｘの対応関係は、例えば通信ポート１４の接続先が設定されるたびにＭＳＧ転送処理部１０２に通知される。また、ハッシュ値登録部１０１も、上記と同様に、通信ポート１４とノードＡ〜Ｈ，Ｘの対応関係に基づき、転送先ノードに該当する通信ポート１４に対して登録要求ＭＳＧを出力する。
【００４８】
ＭＳＧ生成部１０３は、生成部の一例であり、配信データの要求に応じてサブスクライブＭＳＧを生成する。より具体的には、ＭＳＧ生成部１０３は、当該ノードが新規のサブスクライバとなる場合、サブスクライブＭＳＧを生成する。ＭＳＧ生成部１０３は、例えば社内ネットワークＮＷａ〜ＮＷｄから通信ポート１４を介してサブスクライバの登録要求を受けた場合、当該ノードが新規のサブスクライバであると判断する。ＭＳＧ生成部１０３は、ＭＳＧルーティングテーブル１３１に従って通信ポート１４からサブスクライブＭＳＧを転送する。
【００４９】
図５は、登録要求ＭＳＧ及びサブスクライブＭＳＧの転送処理の一例を示す図である。図５において、図２と共通する構成には同一の符号を付し、その説明は省略する。
【００５０】
各ノードＡ〜Ｈ，ＸにはＭＳＧルーティングテーブル１３１が設けられている。ＭＳＧルーティングテーブル１３１は、メッセージテーブルの一例であり、ハッシュ値に応じたサブスクライブＭＳＧの転送先ノードが登録されている。より具体的には、ＭＳＧルーティングテーブル１３１には、転送先ノードまたは管理ノードを示すノードＩＤとハッシュ空間、つまりハッシュ値の範囲の対応関係が登録されている。
【００５１】
また、ＭＳＧルーティングテーブル１３１中、下線を付した部分は、管理ノードに関する登録内容である。つまり、各ノードＡ〜Ｈ，ＸのＭＳＧルーティングテーブル１３１において、当該ノードＩＤに対応するハッシュ空間は、そのノードＡ〜Ｈ，Ｘの管理対象のハッシュ値の範囲を示す。各ノードＡ〜Ｈ，Ｘには、管理対象のハッシュ値に関するハッシュ値管理テーブル１３０が設けられている。なお、本例では、ノードＣのハッシュ値管理テーブル１３０だけが示されている。
【００５２】
例えば、ノードＸのＭＳＧルーティングテーブル１３１では、ノードＸとハッシュ空間「０００−９９９」が対応付けられ、ノードＣとハッシュ空間「１００−８９９」が対応付けられている。このため、ノードＸは、０００〜０９９のハッシュ値を管理し、ノードＸのＭＳＧ転送処理部１０２は、ハッシュ値が「１００」〜「８９９」であるサブスクライブＭＳＧをノードＣに転送する。
【００５３】
また、ノードＸのハッシュ値登録部１０１は、ハッシュ値が「１００」〜「８９９」である登録要求ＭＳＧを、点線で示されるようにノードＣに転送する。なお、以降の説明では、ハッシュ値の一例として「１２３」を挙げる。
【００５４】
ノードＣのＭＳＧルーティングテーブル１３１では、ノードＣとハッシュ空間「１００−１９９」が対応付けられている。このため、ノードＣは、ハッシュ値「１００」〜「１９９」を管理する。
【００５５】
したがって、ノードＸのハッシュ値登録部１０１は、ノードＸからの登録要求ＭＳＧを受信したとき、登録要求ＭＳＧのハッシュ値「１２３」を当該ノードの管理対象であると判断し、ハッシュ値管理テーブル１３０に登録する。これにより、ハッシュ値管理テーブル１３０には、該当ハッシュ空間内のハッシュ値「１２３」に対応して、ノードＸのパブリッシャＩＤが登録される。
【００５６】
このように、登録要求ＭＳＧは、パブリッシャのノードＸからハッシュ値「１２３」を管理対象とするノードＣまで転送される。
【００５７】
次に、ノードＤ，Ｅが、パブリッシャのノードＸからのデータ配信を受けるためにサブスクライブＭＳＧを送信する例を挙げる。新規のサブスクライバであるノードＤ，ＥのＭＳＧ生成部１０３は、ハッシュ値「１２３」が指定されたサブスクライブＭＳＧを生成する。
【００５８】
ノードＤのＭＳＧルーティングテーブル１３１では、ノードＣとハッシュ空間「０００−１９９」が対応付けられている。このため、ノードＣのＭＳＧ転送処理部１０２は、ハッシュ値「１２３」が指定されたサブスクライブＭＳＧをノードＣに転送する。
【００５９】
ノードＣのＭＳＧ転送処理部１０２は、ノードＤからサブスクライブＭＳＧを受信したとき、そのハッシュ値をＭＳＧルーティングテーブル１３１に基づきノードＣの管理対象と判断する。このため、ノードＣのＭＳＧ転送処理部１０２は、サブスクライブＭＳＧをハッシュ値管理テーブル１３０に従ってノードＸに転送する。このようにして、サブスクライブＭＳＧは、点線で示されるように、新規のサブスクライバのノードＤからパブリッシャのノードＸまで転送される。
【００６０】
また、ノードＥのＭＳＧルーティングテーブル１３１では、ノードＢとハッシュ空間「０００−４９９」が対応付けられている。このため、ノードＥのＭＳＧ転送処理部１０２は、ハッシュ値「１２３」が指定されたサブスクライブＭＳＧを、ＭＳＧルーティングテーブル１３１に従ってノードＢに転送する。
【００６１】
ノードＢのＭＳＧルーティングテーブル１３１では、ノードＡとハッシュ空間「０００−３９９」が対応付けられている。このため、非配信ノードであるノードＢのＭＳＧ転送処理部１０２は、ノードＥからのサブスクライブＭＳＧを、ＭＳＧルーティングテーブル１３１に従ってノードＡに転送する。
【００６２】
ノードＡのＭＳＧルーティングテーブル１３１では、ノードＣとハッシュ空間「０００−１９９」が対応付けられている。このため、非配信ノードであるノードＡのＭＳＧ転送処理部１０２は、ノードＢからのサブスクライブＭＳＧを、ＭＳＧルーティングテーブル１３１に従ってノードＣに転送する。
【００６３】
ノードＣのＭＳＧ転送処理部１０２は、ノードＡからのサブスクライブＭＳＧを、上記と同様にノードＸに転送する。このようにして、サブスクライブＭＳＧは、点線で示されるように、新規のサブスクライバのノードＥからパブリッシャのノードＸまで転送される。
【００６４】
再び図４を参照すると、ＭＳＧ記録部１０４は、記録部の一例であり、非配信ノードにおいて、通信ポート１４が受信したサブスクライブＭＳＧのサブスクライバＩＤ及びハッシュ値をＭＳＧ情報テーブル１３２に記録する。ＭＳＧ情報テーブル１３２のサブスクライバＩＤは、当該ノードが、ＭＳＧ情報テーブル１３２の該当ハッシュ値について新規のサブスクライバとなる場合、ＭＳＧ生成部１０３により生成されたサブスクライブＭＳＧに追加される。
【００６５】
これにより、新規のサブスクライバは、サブスクライブＭＳＧを生成して送信したとき、そのサブスクライブＭＳＧを受信した既存のサブスクライバに、当該ノードにサブスクライブＭＳＧを転送した転送元の既存のサブスクライバのノードＩＤを通知することができる。このため、図３の配信ネットワークにおいて、互いにリンクした２つの既存のサブスクライバの間に新規のサブスクライバが追加される場合、新規のサブスクライバは、配信方向の下流側の既存のサブスクライバのノードＩＤを、サブスクライブＭＳＧに追加されたサブスクライバＩＤとして上流側の既存のサブスクライバに通知することができる。
【００６６】
例えば、図３において、既存のサブスクライバであるノードＥ，Ａの間に、非配信ノードＢが新規のサブスクライバとして配信ネットワークに加わる場合を例に挙げる。ノードＢのＭＳＧ記録部１０４は、事前に下流側のノードＥから受信したサブスクライブＭＳＧのサブスクライバＩＤ（ノードＥのＩＤ）をＭＳＧ情報テーブル１３２に記録する。そして、ノードＢが新規のサブスクライバとなるとき、ノードＢのＭＳＧ生成部１０３は、サブスクライブＭＳＧにＭＳＧ情報テーブル１３２のサブスクライバＩＤを追加して、上流側のノードＡに送信する。
【００６７】
このため、ノードＡは、配信ネットワークにおいて、下流側のノードＥとの間に新規のサブスクライバとしてノードＢが追加されると判断して、ノードＥへの配信データの転送を中断してノードＥにノードＢとの接続を要求することができる。したがって、ノードＥは、配信ネットワークにおける上流側の接続先をノードＡからノードＢに変更することができる。
【００６８】
このように、ＭＳＧ情報テーブル１３２は、非配信ノードが新規のサブスクライバとなる場合、配信ネットワークにおける下流側の既存のサブスクライバの接続先を上流側の既存のサブスクライバから当該ノードに変更するために用いられる。なお、以降の説明では、配信ネットワークにおける下流側の既存のサブスクライバのノードを「下流側ノード」と表記し上流側の既存のサブスクライバのノードを「上流側ノード」と表記する。さらに、ＭＳＧ生成部１０３がＭＳＧ情報テーブル１３２に基づいてサブスクライブＭＳＧに追加するサブスクライバＩＤを「下流ノード情報」と表記する。
【００６９】
再び図４を参照すると、配信データ転送処理部１０５は、第１転送処理部の一例であり、当該ノードがサブスクライバである場合、通信ポート１４が受信した配信データを、配信ルーティングテーブル１３３に従ってハッシュ値に応じた転送先ノードに転送する。配信ルーティングテーブル１３３は、配信テーブルの一例であり、データ経路登録部１０７によりハッシュ値に応じた配信データの転送先ノードが登録される。配信ルーティングテーブル１３３は、配信ネットワークにおけるルーティングテーブルである。
【００７０】
リンク確立部１０６は、当該ノードがサブスクライバまたはパブリッシャである場合、他のサブスクライバとのリンク確立の処理を行う。より具体的には、リンク確立部１０６は、リンク先となる他のノードＡ〜Ｈ，Ｘに対してリンク確立を要求し、また、他のノードＡ〜Ｈ，Ｘからのリンク確立の要求に応じる。これにより、配信ネットワークのノード間のリンクが構成される。なお、リンク確立手段としては、例えばＶＬＡＮ（Virtual LAN）やＭＰＬＳ（Multi-Protocol Label Switching ）のパスの設定処理が挙げられるが、これに限定されない。
【００７１】
データ経路登録部１０７は、登録部の一例であり、当該ノードが既存のサブスクライバまたはパブリッシャである場合、通信ポート１４が受信したサブスクライブＭＳＧに示されたサブスクライバＩＤを、サブスクライブＭＳＧに指定されたハッシュ値に応じた配信データの転送先ノードのＩＤと判断し配信ルーティングテーブル１３３に登録する。このため、データ経路登録部１０７は、サブスクライバＩＤが示す新規のサブスクライバを配信データの転送先とすることができる。
【００７２】
これにより、配信ネットワークにおける配信データの転送経路が構成され、配信ネットワークに加入していない非配信ノードの負荷が低減される。
【００７３】
ノード接続要求部１０８は、当該ノードが既存のサブスクライバまたはパブリッシャである場合、通信ポート１４が受信したサブスクライブＭＳＧに追加された下流側ノード情報に基づいて下流側ノードに対し新規のサブスクライバとの接続を要求する。より具体的には、ノード接続要求部１０８は、下流側ノード情報が示す下流側ノードに接続要求ＭＳＧを、通信ポート１４を介して送信する。接続要求ＭＳＧには、要求先である下流側ノードのＩＤと、接続先であるサブスクライブＭＳＧの送信元ノードのＩＤが含まれる。
【００７４】
図６は、ＭＳＧ情報テーブル１３２及び配信ルーティングテーブル１３３の例を示す図である。サブスクライブＭＳＧが、図５に示された経路に沿って転送されると、その経路上の非配信ノードＡ，Ｂ，Ｃでは、ＭＳＧ記録部１０４が、サブスクライブＭＳＧのハッシュ値及びサブスクライバＩＤをＭＳＧ情報テーブル１３２に記録する。なお、サブスクライバＩＤは下流側ノードＩＤとして記録される。
【００７５】
非配信ノードＢ，Ｆは、新規のサブスクライバであるノードＥからのサブスクライブＭＳＧを転送したため、ＭＳＧ記録部１０４が、ハッシュ値「１２３」を下流側ノードＥのＩＤに対応付けてＭＳＧ情報テーブル１３２に記録する。また、非配信ノードＣは、新規のサブスクライバであるノードＤ，ＥからのサブスクライブＭＳＧを転送したため、ＭＳＧ記録部１０４が、ハッシュ値「１２３」を下流側ノードＤ，ＥのＩＤに対応付けてＭＳＧ情報テーブル１３２に記録する。なお、ＭＳＧ情報テーブル１３２の使用例については後述する。
【００７６】
また、配信ルーティングテーブル１３３には、ハッシュ値、受信元ノードＩＤ、及び転送先ノードＩＤが互いに対応付けられて登録されている。受信元ノードＩＤは、当該ハッシュ値の配信データの受信元ノードの識別子であり、転送先ノードＩＤは、当該ハッシュ値の配信データの転送先ノードの識別子である。
【００７７】
新規のサブスクライバのノードＤにおいて、リンク確立部１０６は、サブスクライブＭＳＧを受信したパブリッシャのノードＸからの要求によりノードＸとリンクを確立する。データ経路登録部１０７は、そのリンクの情報に従って配信ルーティングテーブル１３３にハッシュ値「１２３」と受信元ノードＸを登録する。
【００７８】
また、パブリッシャのノードＸにおいて、リンク確立部１０６は、サブスクライブＭＳＧのサブスクライバＩＤに従って、その送信元であるノードＤにリンク確立を要求する。データ経路登録部１０７は、サブスクライブＭＳＧのサブスクライバＩＤに従って、配信ルーティングテーブル１３３にハッシュ値「１２３」と転送先ノードＤを登録する。
【００７９】
このように、ノードＸのデータ経路登録部１０７は、サブスクライブＭＳＧに示された配信データの要求元ノードＤを、サブスクライブＭＳＧに指定されたハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル１３３に登録する。このため、ノードＸの配信データ転送処理部１０５は、ハッシュ値「１２３」が指定された配信データを、点線で示されるように、配信ルーティングテーブル１３３に従ってサブスクライバのノードＤに転送する。これにより、非配信ノードＣは、配信データを転送する処理が省かれるため、データ転送の負荷が低減される。
【００８０】
また、新規のサブスクライバのノードＥにおいて、リンク確立部１０６は、サブスクライブＭＳＧを受信したパブリッシャのノードＸからの要求によりノードＸとリンクを確立する。データ経路登録部１０７は、そのリンクの情報に従って配信ルーティングテーブル１３３にハッシュ値「１２３」と受信元ノードＸを登録する。
【００８１】
また、パブリッシャのノードＸにおいて、リンク確立部１０６は、サブスクライブＭＳＧのサブスクライバＩＤに従って、その送信元であるノードＥにリンク確立を要求する。データ経路登録部１０７は、サブスクライブＭＳＧのサブスクライバＩＤに従って、配信ルーティングテーブル１３３にハッシュ値「１２３」と転送先ノードＥを登録する。
【００８２】
このように、ノードＸのデータ経路登録部１０７は、サブスクライブＭＳＧに示された配信データの要求元ノードＥを、サブスクライブＭＳＧに指定されたハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル１３３に登録する。このため、ノードＸの配信データ転送処理部１０５は、ハッシュ値「１２３」が指定された配信データを、点線で示されるように、配信ルーティングテーブル１３３に従ってサブスクライバのノードＥに転送する。これにより、非配信ノードＡ，Ｂ，Ｃは、配信データを転送する処理が省かれるため、データ転送の負荷が低減される。
【００８３】
次に、配信ネットワークに対する更なるサブスクライバの追加時の動作例を挙げる。以下の例では、図５及び図６に示された各ノードＡ〜Ｈ，Ｘの状態を前提とする。
【００８４】
図７は、サブスクライブＭＳＧの転送処理の一例を示す図である。図７において、図２と共通する構成には同一の符号を付し、その説明は省略する。
【００８５】
新規のサブスクライバであるノードＧにおいて、ＭＳＧ生成部１０３は、ハッシュ値「１２３」を指定したサブスクライブＭＳＧ（符号Ｇｃ参照）を生成する。ここで、サブスクライブＭＳＧのサブスクライバＩＤは、ノードＧのＩＤ（例えばＩＰアドレス）である。なお、ＭＳＧ生成部１０３は、ＭＳＧ情報テーブル１３２にハッシュ値「１２３」に対応する下流側ノードＩＤが登録されていないため、サブスクライブＭＳＧに下流側ノード情報を追加しない。
【００８６】
ＭＳＧ生成部１０３は、ＭＳＧルーティングテーブル１３１から、ハッシュ値「１２３」を含むハッシュ空間に対応するノードＩＤとして、ノードＦのＩＤを検索する。ＭＳＧ生成部１０３は、サブスクライブＭＳＧを通信ポート１４からノードＦに転送する。
【００８７】
ノードＦの動作制御部１００は、ノードＧからサブスクライブＭＳＧを受信したとき、配信ルーティングテーブル１３３にハッシュ値「１２３」に応じた転送先ノードＩＤが登録されていないことから、当該ノードが非配信ノードであると判断する。このため、動作制御部１００は、ＭＳＧ記録部１０４にサブスクライブＭＳＧのサブスクライバＩＤ及びハッシュ値の記録を指示し、また、ＭＳＧ転送処理部１０２にサブスクライブＭＳＧの転送を指示する。
【００８８】
ＭＳＧ記録部１０４は、サブスクライブＭＳＧからハッシュ値及びサブスクライバＩＤを取得する。ＭＳＧ記録部１０４は、ＭＳＧ情報テーブル１３２にハッシュ値「１２３」に対応するように、サブスクライバＩＤを下流側ノードＩＤとして登録する。これにより、ノードＦは、新規のサブスクライバとなる場合、下流側ノードＧとリンクを確立することができる。
【００８９】
また、ＭＳＧ転送処理部１０２は、ＭＳＧルーティングテーブル１３１から、ハッシュ値「１２３」を含むハッシュ空間に対応するノードＩＤとして、ノードＥのＩＤを検索する。ＭＳＧ生成部１０３は、サブスクライブＭＳＧを通信ポート１４からノードＥに転送する。
【００９０】
このように、ＭＳＧ転送処理部１０２は、サブスクライブＭＳＧを、そのハッシュ値に応じた転送先ノードが配信ルーティングテーブル１３３に登録されていない場合、ＭＳＧルーティングテーブル１３１に従ってそのハッシュ値に応じた転送先ノードＥに転送する。このため、サブスクライブＭＳＧは、新規のサブスクライバのノードＧから既存のサブスクライバのノードＥまで転送される。
【００９１】
ノードＥの動作制御部１００は、ノードＦからサブスクライブＭＳＧを受信したとき、配信ルーティングテーブル１３３にハッシュ値「１２３」に応じた転送先ノードＩＤが登録済みであることから、当該ノードがサブスクライバであると判断する。このため、動作制御部１００は、データ経路登録部１０７に、サブスクライブＭＳＧに基づいて転送先ノードを配信ルーティングテーブル１３３に登録するように指示し、リンク確立部１０６にノードＧとのリンク確立を指示する。
【００９２】
図８は、配信データの転送処理の一例を示す図である。図８において、図２と共通する構成には同一の符号を付し、その説明は省略する。
【００９３】
ノードＥのリンク確立部１０６は、サブスクライブＭＳＧのサブスクライバＩＤ（Ｇ）に従って、その送信元ノードＧとリンクを確立する。データ経路登録部１０７は、サブスクライブＭＳＧのサブスクライバＩＤを、ハッシュ値「１２３」に対応する転送先ノードとして配信ルーティングテーブル１３３に登録する（点線の丸参照）。これにより、配信データ転送処理部１０５は、ノードＸから受信した配信データを、点線で示されるように、配信ルーティングテーブル１３３に従って転送先ノードＧに転送する。
【００９４】
また、ノードＧでは、リンク確立部１０６はノードＥからの要求に従ってリンクを確立する。データ経路登録部１０７は、ノードＥとのリンク確立に従って、ノードＥのＩＤをハッシュ値「１２３」に対応する受信元ノードとして配信ルーティングテーブル１３３に登録する。これにより、ノードＧは、配信ルーティングテーブル１３３に従ってノードＥから配信データを受信する。
【００９５】
このように、ノードＥのデータ経路登録部１０７は、サブスクライブＭＳＧに示された配信データの要求元ノードＧを、サブスクライブＭＳＧに指定されたハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル１３３に登録する。このため、ノードＥの配信データ転送処理部１０５は、ハッシュ値「１２３」が指定された配信データを、配信ルーティングテーブル１３３に従ってノードＧに転送する。これにより、ノードＧからのサブスクライブＭＳＧを転送した非配信ノードＦは、配信データを転送する処理が省かれるため、データ転送の負荷が低減される。
【００９６】
次に、新規のサブスクライバを、ＭＳＧ情報テーブル１３２を用いて配信ネットワークに追加する処理の例を述べる。
【００９７】
図９は、サブスクライブＭＳＧの転送処理の他の例を示す図である。図９において、図２と共通する構成には同一の符号を付し、その説明は省略する。
【００９８】
ノードＡのＭＳＧ生成部１０３は、新規のサブスクライバとなるため、符号Ｇｄで示されるサブスクライブＭＳＧを生成し、ＭＳＧルーティングテーブル１３１に従って、ハッシュ値「１２３」に対応するノードＣに転送する。ＭＳＧ生成部１０３は、ＭＳＧ情報テーブル１３２を参照し、ハッシュ値「１２３」に対応する下流側ノードＩＤが登録されていることから、下流側ノード情報としてノードＥのＩＤをサブスクライブＭＳＧに追加する。なお、サブスクライブＭＳＧには、ハッシュ値「１２３」が指定され、サブスクライバＩＤとしてノードＡのＩＤが含まれている。
【００９９】
ノードＣのＭＳＧ転送処理部１０２は、当該ノードが非配信ノードであり、さらにサブスクライブＭＳＧのハッシュ値が管理対象であるため、ハッシュ値管理テーブル１３０に従って、ノードＡからのサブスクライブＭＳＧをノードＸに転送する。
【０１００】
ノードＸのノード接続要求部１０８は、ノードＣからのサブスクライブＭＳＧに下流側ノード情報が追加されているため、下流側ノード情報が示す下流側ノードＥに対し、新規のサブスクライバとなるノードＡとの接続を要求する。より具体的には、ノード接続要求部１０８は、ノードＡを指定した接続要求ＭＳＧを、一点鎖線で示されるように、通信ポート１４からノードＥに送信する。
【０１０１】
ノードＥのリンク確立部１０６は、接続要求ＭＳＧに応じてノードＡとリンクを確立する。また、ノードＥのデータ経路登録部１０７は、ノードＡとのリンク確立に従って、ハッシュ値「１２３」について配信ルーティングテーブル１３３の受信元ノードＩＤをノードＸのＩＤからノードＡのＩＤに更新する（点線の丸参照）。これにより、ノードＥは、ノードＡから配信データを受信することができる。
【０１０２】
このように、ノードＡのＭＳＧ生成部１０３は、ＭＳＧ記録部１０４が記録したハッシュ値を指定したサブスクライブＭＳＧを生成した場合、ＭＳＧ記録部１０４が記録した下流側ノードＥのＩＤを、下流側ノード情報として、生成したサブスクライブＭＳＧに追加して送信する。このため、下流側ノードＥは、下流側ノード情報に基づく接続要求ＭＳＧに応じてノードＡとリンクを確立し、ノードＡから配信データを受信することができる。
【０１０３】
また、ノードＸの動作制御部１００は、ノードＣからサブスクライブＭＳＧを受信したとき、配信ルーティングテーブル１３３にハッシュ値「１２３」に応じた転送先ノードＩＤが登録済みであることから、当該ノードがパブリッシャであると判断する。このため、動作制御部１００は、データ経路登録部１０７に、サブスクライブＭＳＧに基づいて転送先ノードを配信ルーティングテーブル１３３に登録するように指示し、リンク確立部１０６にノードＡとのリンク確立を指示する。
【０１０４】
図１０は、配信データの転送処理の他の例を示す図である。図１０において、図２と共通する構成には同一の符号を付し、その説明は省略する。
【０１０５】
ノードＸのリンク確立部１０６は、サブスクライブＭＳＧに下流側ノード情報が追加されているため、下流側ノード情報が示す下流側ノードＥのＩＤを配信ルーティングテーブル１３３から検索する。リンク確立部１０６は、下流側ノードＥのＩＤが配信ルーティングテーブル１３３に転送先ノードＩＤとして登録済み（図６参照）であるため、ノードＥとのリンクを切断して、ノードＡとリンクを確立する。つまり、リンク確立部１０６は、下流側ノード情報に従って、リンク先のノードを変更する。
【０１０６】
また、データ経路登録部１０７は、リンク確立部１０６と同様の検索を行った結果、下流側ノードＥのＩＤが配信ルーティングテーブル１３３に登録済みであるため、配信ルーティングテーブル１３３に登録された転送先ノードＩＤをノードＥのＩＤからノードＡのＩＤに更新する（点線の丸参照）。
【０１０７】
すなわち、データ経路登録部１０７は、サブスクライブＭＳＧに下流側ノードＩＤ（下流側ノード情報）が含まれる場合、配信ルーティングテーブル１３３に登録された転送先ノードのうち、下流側ノードＩＤに該当する転送先ノードＥを、サブスクライブＭＳＧのサブスクライバＩＤのノードＡに更新する。このため、データ経路登録部１０７は、配信ネットワークにノードＡが追加されたことに応じて、配信データの転送先ノードをノードＥからノードＡに変更することができる。なお、サブスクライブＭＳＧに追加された下流側ノード情報は、サブスクライバＩＤとは別のノードのＩＤの一例である。
【０１０８】
以上の処理によって、ノードＸは、配信データを新規のサブスクライバのノードＡに転送することができ、ノードＡは、配信データを既存のサブスクライバであるノードＥに転送することができる。また、ノードＥは、配信データをノードＧに転送する。このようにして、配信ネットワークに新規のサブスクライバが追加される。
【０１０９】
次に、ゲートウェイ装置１の各処理について述べる。
【０１１０】
図１１は、パブリッシャにおけるハッシュ値の登録処理の一例を示すフローチャートである。本処理は、例えば、社内ネットワークＮＷａ〜ＮＷｄから当該ノードに対して、トピック名を指定してハッシュ値の登録が要求された場合に実行される。
【０１１１】
ハッシュ値登録部１０１は、例えば所定のハッシュ関数によりトピック名からハッシュ値を算出する（ステップＳｔ１）。次に、ハッシュ値登録部１０１は、ＭＳＧルーティングテーブル１３１からハッシュ値を検索する（ステップＳｔ２）。より具体的には、ハッシュ値登録部１０１は、ハッシュ値に該当するハッシュ空間を検索する。
【０１１２】
次に、ハッシュ値登録部１０１は、ハッシュ値が当該ノードの管理対象であるか否かを判定する（ステップＳｔ３）。より具体的には、ハッシュ値登録部１０１は、ハッシュ値に該当するハッシュ空間が当該ノードのＩＤに対応付けられてＭＳＧルーティングテーブル１３１に登録されている場合、ハッシュ値が当該ノードの管理対象であると判定し、そうでない場合、ハッシュ値が当該ノードの管理対象ではないと判定する。
【０１１３】
ハッシュ値登録部１０１は、ハッシュ値が当該ノードの管理対象である場合（ステップＳｔ３のＹｅｓ）、ハッシュ値を当該ノードに対応付けてハッシュ値管理テーブル１３０に登録する（ステップＳｔ４）。
【０１１４】
また、ハッシュ値登録部１０１は、ハッシュ値が当該ノードの管理対象ではない場合（ステップＳｔ３のＮｏ）、登録要求ＭＳＧを生成する（ステップＳｔ５）。登録要求ＭＳＧには、サブスクライバＩＤとしての当該ノードのＩＤと、ハッシュ値とが含まれる。
【０１１５】
次に、ハッシュ値登録部１０１は、登録要求ＭＳＧをＭＳＧルーティングテーブル１３１に従って、ハッシュ値に応じた他のノードに送信する（ステップＳｔ６）。これにより、他のノードにおいても、上記と同様の処理を行うことができる。このようにして、パブリッシャにおけるハッシュ値の登録処理は実行される。
【０１１６】
図１２は、登録要求ＭＳＧによるハッシュ値の登録処理の一例を示すフローチャートである。本処理は例えば周期的に実行される。
【０１１７】
ハッシュ値登録部１０１は、通信ポート１４において登録要求ＭＳＧが受信されたか否かを判定する（ステップＳｔ１１）。ハッシュ値登録部１０１は、登録要求ＭＳＧが受信されていない場合（ステップＳｔ１１のＮｏ）、処理を終了する。ハッシュ値登録部１０１は、登録要求ＭＳＧが受信されている場合（ステップＳｔ１１のＹｅｓ）、ステップＳｔ２と同様に、ＭＳＧルーティングテーブル１３１からハッシュ値を検索する（ステップＳｔ１２）。
【０１１８】
次に、ハッシュ値登録部１０１は、ステップＳｔ３と同様に、ハッシュ値が当該ノードの管理対象であるか否かを判定する（ステップＳｔ１３）。
【０１１９】
ハッシュ値登録部１０１は、ハッシュ値が当該ノードの管理対象である場合（ステップＳｔ１３のＹｅｓ）、ハッシュ値を当該ノードに対応付けてハッシュ値管理テーブル１３０に登録する（ステップＳｔ１４）。これにより、ＭＳＧ転送処理部１０２は、管理対象のハッシュ値が指定されたサブスクライブＭＳＧが受信されたとき、ハッシュ値管理テーブル１３０に従って、サブスクライブＭＳＧをサブスクライバのノードに転送することができる。
【０１２０】
また、ハッシュ値登録部１０１は、ハッシュ値が当該ノードの管理対象ではない場合（ステップＳｔ１３のＮｏ）、登録要求ＭＳＧをＭＳＧルーティングテーブル１３１に従って、ハッシュ値に応じた他のノードに送信する（ステップＳｔ１５）。これにより、他のノードも、本処理と同様の処理を行うことができる。このようにして、登録要求ＭＳＧによるハッシュ値の登録処理は実行される。
【０１２１】
図１３は、サブスクライブＭＳＧ及び配信データの受信処理の一例を示すフローチャートである。本処理は例えば周期的に実行される。なお、本処理では、サブスクライブＭＳＧの受信処理を配信データの受信処理より優先させるため、サブスクライブＭＳＧ及び配信データの各受信判定が一連の処理により実行されるが、互いに独立した処理により実行されてもよい。
【０１２２】
動作制御部１００は、通信ポート１４においてサブスクライブＭＳＧが受信されたか否かを判定する（ステップＳｔ２１）。動作制御部１００は、サブスクライブＭＳＧが受信されている場合（ステップＳｔ２１のＹｅｓ）、サブスクライブＭＳＧからハッシュ値を取得する（ステップＳｔ２２）。
【０１２３】
次に、動作制御部１００は、ハッシュ値に基づいて当該ノードがパブリッシャ及びサブスクライバの一方であるか否かを判定する（ステップＳｔ２３）。より具体的には、動作制御部１００は、ハッシュ値が配信ルーティングテーブル１３３に登録されている場合、当該ノードがパブリッシャ及びサブスクライバの一方であると判定し、そうでない場合、当該ノードが非配信ノード（つまりパブリッシャ及びサブスクライバのどちらでもない）であると判定する。
【０１２４】
当該ノードがパブリッシャ及びサブスクライバの一方である場合（ステップＳｔ２３のＹｅｓ）、ノード接続要求部１０８は、サブスクライブＭＳＧに下流側ノード情報が追加されているか否かを判定する（ステップＳｔ２４）。ノード接続要求部１０８は、下流側ノード情報が追加されている場合（ステップＳｔ２４のＹｅｓ）、下流側ノード情報が示す下流側ノードに、サブスクライブＭＳＧの送信元ノード、つまりサブスクライバＩＤのノードとの接続を要求する（ステップＳｔ２５）。このとき、配信データ転送処理部１０５は、下流側ノードへの配信データの転送を中止し、ステップＳｔ２７の処理により転送先ノードがサブスクライブＭＳＧの送信元ノードに更新されたとき、そのノードへの転送を開始してもよい。
【０１２５】
次に、リンク確立部１０６は、下流側ノードとのリンクを切断し、サブスクライブＭＳＧの送信元ノードとリンクを確立する（ステップＳｔ２６）。次に、データ経路登録部１０７は、配信ルーティングテーブル１３３に登録された転送先ノードのうち、下流側ノードに該当する転送先ノードをサブスクライブＭＳＧの送信元ノードに更新する（ステップＳｔ２７）。これにより、配信データの転送先が、下流側ノードから送信元ノードに更新される。
【０１２６】
また、下流側ノード情報が追加されていない場合（ステップＳｔ２４のＮｏ）、リンク確立部１０６は、サブスクライブＭＳＧの送信元ノードとリンクを確立する（ステップＳｔ３２）。次に、データ経路登録部１０７は、サブスクライブＭＳＧの送信元ノード（つまり、配信データの要求元ノードを、サブスクライブＭＳＧのハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル１３３に登録する（ステップＳｔ３３）。これにより、配信データが、当該ノードから送信元ノードに転送される。
【０１２７】
また、当該ノードがパブリッシャ及びサブスクライバの何れでもない場合（ステップＳｔ２３のＮｏ）、つまり当該ノードが非配信ノードである場合、ＭＳＧ記録部１０４は、サブスクライブＭＳＧの情報、つまりサブスクライバＩＤ及びハッシュ値をＭＳＧ情報テーブル１３２に記録する（ステップＳｔ２８）。これにより、当該ノードは、新規のサブスクライバになる場合、下流側ノード情報を上流側ノードに通知することができる。
【０１２８】
次に、ＭＳＧ転送処理部１０２は、ハッシュ値管理テーブル１３０またはＭＳＧルーティングテーブル１３１に従って、サブスクライブＭＳＧを転送する（ステップＳｔ２９）。より具体的には、ＭＳＧ転送処理部１０２は、サブスクライブＭＳＧのハッシュ値からＭＳＧルーティングテーブル１３１に基づいて、ハッシュ値が管理対象であるか否かを判定し、管理対象である場合、ハッシュ値管理テーブル１３０を用い、管理対象ではない場合、ＭＳＧルーティングテーブル１３１を用いる。
【０１２９】
また、動作制御部１００は、サブスクライブＭＳＧが受信されていない場合（ステップＳｔ２１のＮｏ）、通信ポート１４において配信データが受信されているか否かを判定する（ステップＳｔ３０）。このように、動作制御部１００は、サブスクライブＭＳＧの受信判定の後に配信データの受信判定を行うため、サブスクライブＭＳＧの受信処理を配信データの受信処理より優先することができる。
【０１３０】
動作制御部１００は、配信データが受信されていない場合（ステップＳｔ３０のＮｏ）、処理を終了する。また、配信データが受信されている場合（ステップＳｔ３０のＹｅｓ）、配信データ転送処理部１０５は、配信データを、配信ルーティングテーブル１３３に従ってハッシュ値に応じた転送先ノードに転送する（ステップＳｔ３１）。このようにして、サブスクライブＭＳＧ及び配信データの受信処理は実行される。
【０１３１】
図１４は、接続要求ＭＳＧの受信処理の一例を示すフローチャートである。本処理は例えば周期的に実行される。
【０１３２】
リンク確立部１０６は、通信ポート１４において接続要求ＭＳＧが受信されているか否かを判定する（ステップＳｔ６１）。リンク確立部１０６は、接続要求ＭＳＧが受信されていない場合（ステップＳｔ６１のＮｏ）、処理を終了する。
【０１３３】
また、リンク確立部１０６は、接続要求ＭＳＧが受信されている場合（ステップＳｔ６１のＹｅｓ）、接続要求ＭＳＧに指定されたノードとリンクを確立する（ステップＳｔ６２）。次に、データ経路登録部１０７は、接続要求ＭＳＧに指定されたノードを、受信元ノードＩＤとして、該当ハッシュ値に対応するように配信ルーティングテーブル１３３に登録する（ステップＳｔ６３）。このようにして、接続要求ＭＳＧの受信処理は実行される。
【０１３４】
図１５は、サブスクライブＭＳＧの送信処理の一例を示すフローチャートである。本処理は、例えば社内ネットワークＮＷａ〜ＮＷｄからの要求に応じて、当該ノードが新規のサブスクライバとなる場合、実行される。
【０１３５】
ＭＳＧ生成部１０３は、ハッシュ値及びサブスクライバＩＤを含むサブスクライブＭＳＧを生成する（ステップＳｔ４２）。次に、ＭＳＧ生成部１０３は、ＭＳＧ情報テーブル１３２を参照することにより、当該ノードに下流側ノードが有るか否かを判定する（ステップＳｔ４３）。より具体的には、ＭＳＧ生成部１０３は、生成したサブスクライブＭＳＧのハッシュ値に該当する下流側ノードＩＤがＭＳＧ情報テーブル１３２に記録されているか否かを判定する。
【０１３６】
ＭＳＧ生成部１０３は、下流側ノードが無い場合（ステップＳｔ４３のＮｏ）、生成したサブスクライブＭＳＧをＭＳＧルーティングテーブル１３１に従って、ハッシュ値に応じた転送先ノードに送信する（ステップＳｔ５４）。次に、リンク確立部１０６は、サブスクライブＭＳＧを受信した上流側ノードからの要求に応じて、上流側ノードとリンクを確立する（ステップＳｔ５１）。次に、データ経路登録部１０７は、その上流側ノードのＩＤを、ハッシュ値に応じた受信元ノードに登録する（ステップＳｔ５２）。
【０１３７】
また、ＭＳＧ生成部１０３は、下流側ノードが有る場合（ステップＳｔ４３のＹｅｓ）、ＭＳＧ情報テーブル１３２に記録された下流側ノードＩＤから下流側ノード情報を生成する（ステップＳｔ４４）。次に、ＭＳＧ生成部１０３は、サブスクライブＭＳＧに下流側ノード情報を追加する（ステップＳｔ４５）。これにより、当該ノードは、上流側ノードに下流側ノード情報を通知することができる。
【０１３８】
次に、ＭＳＧ生成部１０３は、生成したサブスクライブＭＳＧをＭＳＧルーティングテーブル１３１に従って、ハッシュ値に応じた転送先ノードに送信する（ステップＳｔ４６）。次に、リンク確立部１０６は、通信ポート１４において上流側ノードからリンク確立要求が受信されているか否かを判定する（ステップＳｔ４７）。
【０１３９】
リンク確立部１０６は、リンク確立要求が受信されていない場合（ステップＳｔ４７のＮｏ）、再びステップＳｔ４７の処理を実行する。また、リンク確立部１０６は、リンク確立要求が受信されている場合（ステップＳｔ４７のＹｅｓ）、下流側ノードとリンクを確立する（ステップＳｔ４８）。このとき、下流側ノードは、接続要求ＭＳＧに従い当該ノードにリンク確立要求を送信する。
【０１４０】
次に、データ経路登録部１０７は、リンク先の下流側ノードのＩＤを、ハッシュ値に応じた転送先ノードとして配信ルーティングテーブル１３３に登録する（ステップＳｔ４９）。これにより、当該ノードは、下流側ノードに配信データを転送することができる。
【０１４１】
次に、ＭＳＧ記録部１０４は、リンク先の下流側ノードに該当する下流側ノードＩＤをＭＳＧ情報テーブル１３２から削除する（ステップＳｔ５０）。このようにして、サブスクライブＭＳＧの送信処理は実行される。
【０１４２】
上記の配信ネットワークにおいて、各ノードＡ〜Ｈ，Ｘは、配信データのＱｏＳ（Quality of Service）を考慮して配信データを配信してもよい。この場合、ＱｏＳを規定する通信品質の指標値の一例として品質値「０」〜「２」が用いられる。
【０１４３】
品質値「０」の配信データは、各ノードＡ〜Ｈ，Ｘから１回だけ送信され、送信先ノードに届くことが保証されない。品質値「１」の配信データは、送信先ノードＡ〜Ｈ，Ｘにおいて少なくとも１回受信され、重複して受信される可能性がある。品質値「２」の配信データは、送信先ノードＡ〜Ｈ，Ｘにおいて正確に１回だけ受信され、送信先ノードに届くことが保証される。すなわち、品質値「０」は最も低いＱｏＳを示し、品質値「２」は最も高いＱｏＳを示す。
【０１４４】
サブスクライバであるノードＡ〜Ｈには、送信することができる配信データの品質値が設定されている。このため、配信ネットワークにおいて、同一のトピック名の配信データでも、ノードＡ〜Ｈ，Ｘごとに扱える品質値が異なれば、別々の経路で転送される。なお、パブリッシャのノードＸは、何れの品質値の配信データも送信することができる。
【０１４５】
図１６は、他の実施例における配信ルーティングテーブル１３３を示す図である。図１６において、図２と共通する構成には同一の符号を付し、その説明は省略する。なお、本例の配信ルーティングテーブル１３３は、図８の例に基づく。
【０１４６】
配信ルーティングテーブル１３３には、ハッシュ値、品質値、受信元ノードＩＤ、及び転送先ノードＩＤが互いに対応付けられて登録されている。既存のサブスクライバであるノードＤ，Ｅ，Ｇには、送信できる配信データの品質値「０」が設定されている。このため、ノードＤ，Ｅ，Ｇの配信ルーティングテーブル１３３には、品質値「０」が設定されている。また、パブリッシャのノードＸは、送信できる配信データの品質値に制限がないが、配信ルーティングテーブル１３３には、配信データの送信先ノードの品質値「０」が設定される。
【０１４７】
以下に、品質値「２」が設定されたノードＦが、新規のサブスクライバとなる場合を例に挙げ、サブスクライブＭＳＧ及び配信データの転送処理を述べる。
【０１４８】
図１７は、他の実施例におけるサブスクライブＭＳＧの転送処理を示す図である。図１７において、図２と共通する構成には同一の符号を付し、その説明は省略する。点線は、サブスクライブＭＳＧの経路を示す。新規のサブスクライバとなるノードＦのＭＳＧ生成部１０３は、ハッシュ値「１２３」、品質値「２」、及びサブスクライバＩＤ「Ｆ」を含むサブスクライブＭＳＧ（符号Ｇｅ参照）を生成して、ノードＥに送信する。
【０１４９】
既存のサブスクライバであるノードＥの動作制御部１００は、サブスクライブＭＳＧの品質値「２」が、当該ノードに設定された品質値「０」より高いため、ＭＳＧ記録部１０４に情報の記録を指示し、ＭＳＧ転送処理部１０２にサブスクライブＭＳＧの転送を指示する。ＭＳＧ記録部１０４は、サブスクライブＭＳＧのハッシュ値、品質値、及びサブスクライバＩＤをＭＳＧ情報テーブル１３２に記録する。また、ＭＳＧ転送処理部１０２は、サブスクライブＭＳＧを、ＭＳＧルーティングテーブル１３１に従ってノードＢに転送する。
【０１５０】
ノードＢのＭＳＧ転送処理部１０２は、当該ノードが非配信ノードであるため、サブスクライブＭＳＧを、ＭＳＧルーティングテーブル１３１に従ってノードＡに転送し、ノードＡのＭＳＧ転送処理部１０２も、ノードＢと同様に、サブスクライブＭＳＧをノードＣに転送する。このとき、各ノードＡ，ＢのＭＳＧ記録部１０４は、ノードＥと同様にサブスクライブＭＳＧの情報をＭＳＧ情報テーブル１３２に記録する。
【０１５１】
ノードＣのＭＳＧ転送処理部１０２は、ハッシュ値「１２３」が管理対象であるため、サブスクライブＭＳＧを、ハッシュ値管理テーブル１３０に従ってノードＸに転送する。このとき、ノードＣのＭＳＧ記録部１０４は、サブスクライブＭＳＧの情報をＭＳＧ情報テーブル１３２に記録する。
【０１５２】
このように、サブスクライブＭＳＧは、ノードＦからノードＥ，Ｂ，Ａ，Ｃを経由してノードＸに転送される。このとき、ノードＥは、既存のサブスクライバであるが、設定された品質値がサブスクライブＭＳＧの品質値より低いため、ノードＥを配信ルーティングテーブル１３３に登録せずにサブスクライブＭＳＧを転送する。
【０１５３】
ノードＸのデータ経路登録部１０７は、当該ノードがパブリッシャであるため、サブスクライブＭＳＧのサブスクライバＩＤを、転送先ノードＩＤとしてハッシュ値及び品質値とともに配信ルーティングテーブル１３３に登録する。
【０１５４】
図１８は、他の実施例における配信データの転送処理を示す図である。図１８において、図２と共通する構成には同一の符号を付し、その説明は省略する。点線は、配信データの経路を示す。
【０１５５】
ノードＸの配信ルーティングテーブル１３３には、品質値ごとに転送先ノードＩＤが登録されている。より具体的には、配信ルーティングテーブル１３３には、品質値「０」に対応する転送先ノードＤ，ＥのＩＤが登録され、品質値「２」に対応する転送先ノードＦのＩＤが登録されている。
【０１５６】
このため、ノードＸの配信データ転送処理部１０５は、品質値「０」に従い配信データをノードＤ，Ｅに転送し、品質値「２」に従い配信データをノードＦに転送する。また、ノードＧの配信ルーティングテーブル１３３には、品質値「２」に対応する受信元ノードＸのＩＤが登録されている。したがって、ＱｏＳの異なる配信データの経路を配信ネットワーク上に構成することが可能である。
【０１５７】
次に、各ノードＡ〜Ｈ，Ｘの処理について述べる。
【０１５８】
図１９は、サブスクライブＭＳＧの送信処理の他の例を示すフローチャートである。図１９において、図１５と共通する処理には同一の符号を付し、その説明は省略する。
【０１５９】
本例において、ＭＳＧ情報テーブル１３２には、サブスクライブＭＳＧに指定された品質値が登録される。このため、ＭＳＧ生成部１０３は、ＭＳＧ情報テーブル１３２に下流側ノードＩＤが記録されている場合でも、ＭＳＧ情報テーブル１３２に記録された品質値に応じてサブスクライブＭＳＧに下流側ノード情報の追加の可否を決定する。
【０１６０】
ＭＳＧ生成部１０３は、下流側ノードが有る場合（ステップＳｔ４３のＹｅｓ）、ＭＳＧ情報テーブル１３２の品質値を、当該ノードに設定された品質値Ｒと比較する（ステップＳｔ４３ａ）。ＭＳＧ生成部１０３は、ＭＳＧ情報テーブル１３２の品質値が、当該ノードに設定された品質値Ｒ以下である場合（ステップＳｔ４３ａのＹｅｓ）、下流側ノード情報を生成し（ステップＳｔ４４）、サブスクライブＭＳＧに追加する（ステップＳｔ４５）。その後、ステップＳｔ４６以降の処理が実行される。
【０１６１】
したがって、当該ノードは、当該ノードに設定された品質値Ｒが、ＭＳＧ情報テーブル１３２の品質値以上であれば、下流側ノードに設定された品質値に従い配信データを送信することが可能であると判断し、下流側ノード情報を上流側ノードに通知することができる。
【０１６２】
また、ＭＳＧ生成部１０３は、ＭＳＧ情報テーブル１３２の品質値が、当該ノードに設定された品質値Ｒより高い場合（ステップＳｔ４３ａのＮｏ）、下流側ノード情報の生成及び追加を行わずに、サブスクライブＭＳＧをＭＳＧルーティングテーブル１３１に従って送信する（ステップＳｔ５４）。その後、ステップＳｔ５１，５２の処理が実行される。
【０１６３】
したがって、当該ノードは、当該ノードに設定された品質値Ｒが、ＭＳＧ情報テーブル１３２の品質値より低ければ、下流側ノードに設定された品質値に従い配信データを送信することが不可能であると判断し、下流側ノード情報の上流側ノードへの通知を中止できる。このようにして、サブスクライブＭＳＧの送信処理は実行される。
【０１６４】
図２０は、サブスクライブＭＳＧ及び配信データの受信処理の他の例を示すフローチャートである。図２０において、図１３と共通する処理には同一の符号を付し、その説明は省略する。
【０１６５】
動作制御部１００は、サブスクライブＭＳＧが受信されている場合（ステップＳｔ２１のＹｅｓ）、サブスクライブＭＳＧからハッシュ値及び品質値を取得する（ステップＳｔ２２ａ）。次に、動作制御部１００は、ハッシュ値に基づいて当該ノードがサブスクライバであるか否かを判定する（ステップＳｔ２３ａ）。
【０１６６】
動作制御部１００は、当該ノードがサブスクライバである場合（ステップＳｔ２３ａのＹｅｓ）、サブスクライブＭＳＧの品質値を、当該ノードに設定された品質値Ｒと比較する（ステップＳｔ２３ｂ）。サブスクライブＭＳＧの品質値が、当該ノードに設定された品質値Ｒ以下である場合（ステップＳｔ２３ｂのＹｅｓ）、ステップＳｔ２４以降の処理が実行される。この場合、データ経路登録部１０７は、サブスクライブＭＳＧの送信元ノードを配信ルーティングテーブル１３３に登録する。
【０１６７】
したがって、既存のサブスクライバのノードは、当該ノードに設定された品質値Ｒが、サブスクライブＭＳＧの品質値以上であれば、その品質値に従い配信データを送信することが可能であると判断し、配信ルーティングテーブル１３３の登録によりサブスクライブＭＳＧの送信元ノードへの配信データの転送を行うことができる。
【０１６８】
サブスクライブＭＳＧの品質値が、当該ノードに設定された品質値Ｒより高い場合（ステップＳｔ２３ｂのＮｏ）、ステップＳｔ２８，Ｓｔ２９の処理が実行される。この場合、配信ルーティングテーブル１３３の登録は行われない。
【０１６９】
したがって、既存のサブスクライバのノードは、当該ノードに設定された品質値Ｒが、サブスクライブＭＳＧの品質値より低ければ、その品質値に従い配信データを送信することが不可能であると判断し、サブスクライブＭＳＧの送信元ノードへの配信データの転送を行わない。
【０１７０】
また、動作制御部１００は、当該ノードがサブスクライバではない場合（ステップＳｔ２３ａのＮｏ）、当該ノードがパブリッシャであるか否かを判定する（ステップＳｔ２３ｃ）。当該ノードがパブリッシャである場合（ステップＳｔ２３ｃのＹｅｓ）、ステップＳｔ２４以降の処理が実行される。この場合、配信ルーティングテーブル１３３の登録は行われる。
【０１７１】
したがって、パブリッシャのノードは、サブスクライブＭＳＧの品質値によらず、サブスクライブＭＳＧの送信元ノードを配信ルーティングテーブル１３３に登録する。
【０１７２】
また、当該ノードがパブリッシャではない場合（ステップＳｔ２３ｃのＮｏ）、つまり、当該ノードが非配信ノードである場合、ステップＳｔ２８，Ｓｔ２９の処理が実行される。この場合、配信ルーティングテーブル１３３の登録は行われない。
【０１７３】
したがって、非配信ノードは、サブスクライブＭＳＧの品質値によらず、サブスクライブＭＳＧの送信元ノードを配信ルーティングテーブル１３３に登録しない。このようにして、サブスクライブＭＳＧ及び配信データの受信処理は実行される。
【０１７４】
このように、データ経路登録部１０７はサブスクライブＭＳＧに含まれる品質値と、当該ノードに設定された品質値Ｒとを比較し、その比較結果に応じてサブスクライブＭＳＧの送信元ノードを配信ルーティングテーブル１３３に登録する。このため、配信ネットワークにおいて、配信データの経路を品質値ごとに構成し、経路ごとのＱｏＳを実現することができる。
【０１７５】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【０１７６】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１）  トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第１記憶部と、
前記配信データを受信する第１受信部と、
前記第１受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第１転送処理部と、
前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第２受信部と、
前記第２受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有することを特徴とする通信装置。
（付記２）  前記トピック名に応じた前記要求メッセージの転送先ノードが登録されたメッセージテーブルを記憶する第２記憶部と、
前記第２受信部が受信した前記要求メッセージを、前記要求メッセージに指定された前記トピック名に応じた転送先ノードが前記配信テーブルに登録されていない場合、前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに転送する第２転送処理部とを有することを特徴とする付記１に記載の通信装置。
（付記３）  前記配信データの要求に応じて前記要求メッセージを生成する生成部と、
前記第２受信部が受信した前記要求メッセージの前記要求元ノード及び前記トピック名を記録する記録部とを有し、
前記生成部は、前記記録部が記録した前記トピック名を指定した前記要求メッセージを生成した場合、前記記録部が記録した前記要求元ノードの識別子を、前記生成した前記要求メッセージに追加し、前記要求メッセージを前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに送信することを特徴とする付記２に記載の通信装置。
（付記４）  前記登録部は、前記第２受信部が受信した前記要求メッセージに、前記要求メッセージの前記要求元ノードとは別のノードの識別子が含まれる場合、前記配信テーブルに登録された転送先ノードのうち、前記別のノードに該当する転送先ノードを前記要求元ノードに更新することを特徴とする付記１乃至３の何れかに記載の通信装置。
（付記５）  前記要求メッセージには、前記配信データの通信品質の指標値が含まれ、
前記登録部は、前記第２受信部が受信した前記要求メッセージに含まれる前記通信品質の指標値と所定値とを比較し、該比較結果に応じて前記要求元ノードを前記配信テーブルに登録することを特徴とする付記１乃至４の何れかに記載の通信装置。
（付記６）  トピック名に応じた配信データの転送先ノードが登録される配信テーブルを用い、
前記配信データを受信し、
前記受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送し、
前記トピック名を指定して前記配信データを要求する要求メッセージを受信し、
前記受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録することを特徴とする通信方法。
（付記７）  前記トピック名に応じた前記要求メッセージの転送先ノードが登録されたメッセージテーブルを用い、
前記受信した前記要求メッセージを、前記要求メッセージに指定された前記トピック名に応じた転送先ノードが前記配信テーブルに登録されていない場合、前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに転送することを特徴とする付記６に記載の通信方法。
（付記８）  前記配信データの要求に応じて前記要求メッセージを生成し、
前記受信した前記要求メッセージの前記要求元ノード及び前記トピック名を記録し、
前記記録した前記トピック名を指定した前記要求メッセージを生成した場合、前記記録した前記要求元ノードの識別子を、前記生成した前記要求メッセージに追加し、前記要求メッセージを前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに送信することを特徴とする付記７に記載の通信方法。
（付記９）  前記受信した前記要求メッセージに、前記要求メッセージの前記要求元ノードとは別のノードの識別子が含まれる場合、前記配信テーブルに登録された転送先ノードのうち、前記別のノードに該当する転送先ノードを前記要求元ノードに更新することを特徴とする付記６乃至８の何れかに記載の通信方法。
（付記１０）  前記要求メッセージには、前記配信データの通信品質の指標値が含まれ、
前記受信した前記要求メッセージに含まれる前記通信品質の指標値と所定値とを比較し、
該比較結果に応じて前記要求元ノードを前記配信テーブルに登録することを特徴とする付記６乃至９の何れかに記載の通信方法。
【符号の説明】
【０１７７】
１      ゲートウェイ装置
１３      ストレージメモリ
１４      通信ポート
１０２     メッセージ転送処理部
１０３     メッセージ生成部
１０４     メッセージ記録部
１０５     配信データ転送処理部
１０６     データ経路登録部
１３１     メッセージルーティングテーブル
１３３     配信ルーティングテーブル
【図１】
2019049950.tif 000003
【図２】
2019049950.tif 000004
【図３】
2019049950.tif 000005
【図４】
2019049950.tif 000006
【図５】
2019049950.tif 000007
【図６】
2019049950.tif 000008
【図７】
2019049950.tif 000009
【図８】
2019049950.tif 000010
【図９】
2019049950.tif 000011
【図１０】
2019049950.tif 000012
【図１１】
2019049950.tif 000013
【図１２】
2019049950.tif 000014
【図１３】
2019049950.tif 000015
【図１４】
2019049950.tif 000016
【図１５】
2019049950.tif 000017
【図１６】
2019049950.tif 000018
【図１７】
2019049950.tif 000019
【図１８】
2019049950.tif 000020
【図１９】
2019049950.tif 000021
【図２０】
2019049950.tif 000022