JP2013058056A - 配信システム、配信方法、及び配信プログラム - Google Patents

Abstract

【課題】本発明では、配信ノード間で転送するデータ量を削減できる配信技術を提供する。
【解決手段】制御ノードは、配信ノード間の接続情報と、配信ノードの負荷情報とに基づいて、複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、配信先の配信ノードに配信するデータの種別と、を配信ノード毎に決定し、決定した配信先の配信ノードを特定するノード情報と、決定したデータの種別を特定する種別情報とを、配信ノード毎に配布し、配信ノードは、制御ノードから配布されたノード情報と種別情報とを受信し、他の配信ノードから配信されたデータを受信した場合には、受信したデータから種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信することにより、上記課題の解決を図る。
【選択図】図１

Description

本発明は、配信ノードを用いて情報を配信する配信システムに関する。

リアルタイムなフィールドの情報、例えばユーザがいる場所周辺のセンサー情報（地震・雨など）を収集し配信する配信システムがある。このような配信システムでは、情報提供側では、誰が情報を使うのか事前には分からないことが多い。ユーザはデータを参照したいと思ったタイミングで随時配信システムに参加でき、ユーザの意思で配信してもらうセンサー情報の種類を変更できる必要がある。

このようなセンサー情報を参照するための仕組みとして、Publish/Subscribeの通信モデルが活用されている。Publish/Subscribeの通信モデルとは、あるトピック（たとえば「自宅」など）に対して、Subscribe（購読）登録しておくと、該当するトピックにイベントが起きたタイミング（たとえば「自宅の窓が開いた」など）でメッセージを配信する仕組みである。これにより、送信側と受信側がお互いに相手が誰でどこにいるかを意識する必要がなく、受信側は自分が必要とするメッセージのみを受け取ることができる。このPublish/Subscribeの仕組みを使うと、購読〜配信の処理は単一のユーザだけではなく、複数ユーザに対する同時配信も可能になる。

また、情報提供側は通信処理の負荷・電力消費上昇を抑えるため、定期的に採取するデータをある程度まとめて送るような渡し方が必要になる。
このように、このPublish/Subscribeの仕組みを使うと、複数のデータを同時に送りたい送信側（センサー側）と、必要なデータのみ受け取りたい受信側（ユーザ側）の仲介をすることが必要になる。そこで、以下の技術が考えられる。

第１の技術としては、データセンターのサーバに全てのデータを集約し、各ユーザに対して必要なデータのみを個別配送する方法が考えられる。
また、第２の技術としては、複数ユーザへの配送技術としてIP Routerによるマルチキャスト配送も考えられる。マルチキャスト配送は、パケット単位の中継処理である。マルチキャスト配送を用いると、センサー側が出すデータをそのまま全ユーザに配送することで、複数ノードで分散して収集・配送し遅延を短縮できる。なお、上記マルチキャスト配送に関連する技術としては、例えばMPLS（Multi-Protocol Label Switching）によるマルチキャスト配送に関する技術がある。

また、第３の技術として、次のものがある。端末は、ストリームデータをストリームサーバから受けて、そのストリームデータに係る視聴番組を視聴要求する。ストリームサーバは、その視聴要求した端末に対してストリームデータを送信する前に、当該視聴番組の共通情報を共通情報データベースにキャッシングすると共に、他の端末から同一の視聴番組の視聴要求を受ける。すると、ストリームサーバは、共通情報データベースの共通情報を先ず当該他の端末に送信してから、ストリームサーバから現に配信されているストリームデータを、送信中の端末に加えて他の端末にも送信する。

また、第４の技術として、次のものがある。管理サーバは、作成すべき複合コンテンツの内容に基づいて、複合コンテンツ作成のための指示情報を生成する。中間装置は、その指示情報に応じて、コンテンツサーバに対して、複合コンテンツ作成のために必要なコンテンツ部分の取り出しを指示する。各コンテンツサーバは、取り出しを指示されたコンテンツ部分に対応して、携帯端末用に符号化形式が変換された複合コンテンツ要素を取得して、中間装置に返信する。中間装置は、コンテンツサーバから返信された複合コンテンツ要素を、管理サーバからの指示情報をもとに時系列で組み合わせて、携帯端末向けの複合コンテンツとして作成する。管理サーバは、作成された複合コンテンツを携帯端末に対して配信する。

特開２００４−３２１１４号公報 特開２００２−２９０９５２号公報 特開２００５−２０５８８号公報 特表２００５−５０６７４４号公報 特開２００７−２３４０１４号公報

しかしながら、上記第１の技術では、データセンターへ全てのデータを集約してしまうと、負荷が１箇所に集中し、ネットワーク帯域やサーバ性能のボトルネック化を招くことが考えられる。

また、上記第２の技術では、マルチキャスト配送を行った場合は、センサーで取得されたデータがユーザ側にそのまま届くため、ユーザ側各々で、必要なデータを抜き出す（加工する）手間が必要になる。ネットワークに関しては、不要なデータも含めて宛先までデータが配送されるため、不必要にネットワークの帯域が浪費されてしまうおそれがある。

また、上記第３の技術では、途中参加したストリーム放送視聴者が存在すると、中継装置が、ストリームサーバに共通情報の要求を行うことなく、予めキャッシュした共通情報をその途中参加の視聴者に対して配信している。しかしながら、当該第３の技術でも、不要なデータも含めて宛先までデータが配送されるため、不必要にネットワークの帯域が浪費されてしまうおそれがある。

また、上記第４の技術では、セグメントの変換処理を行なっていた変換装置の負荷を、コンテンツサーバ側で上記処理を行うことにより、ネットワークの伝送量を減らし、処理負荷が変換装置に集中することを防ぎ、処理負荷を分散させている。しかしながら、上記第４の技術でも、コンテンツサーバ側に負荷が集中し、ネットワーク帯域やサーバ性能のボトルネック化を招くことが考えられる。

このように、配信ノード間で配信されるデータはそのまま加工されずに配信されるので、最終的に該データを受け取るユーザから見ると、不要なデータまでも配信される。その結果、ネットワーク負荷を高くしている。

そこで、本発明は、配信ノード間で転送するデータ量を削減できる配信技術を提供する。

配信システムでは、複数の配信ノードと、制御ノードとがネットワークを介して接続されている。制御ノードは、決定部、配布部を含む。決定部は、配信ノード間の接続状態を示す接続情報と、配信ノードにおける負荷情報とに基づいて、複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、配信先の配信ノードに配信するデータの種別と、を決定する。配布部は、決定した配信先の配信ノードを特定するノード情報と、決定したデータの種別を特定する種別情報とを、配信ノードに配布する。

配信ノードは、受信部、送信部を含む。受信部は、制御ノードから配布されたノード情報と種別情報とを受信する。送信部は、他の配信ノードから配信されたデータを受信した場合には、受信したデータから前記種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信する。

本発明によれば、配信ノード間で転送するデータ量を削減できる。

本実施形態における配信システムの機能ブロック図を示す。 第１の実施形態における配信システムの構成例を示す。 第１の実施形態におけるＸＭＬメッセージの一例を示す。 第１の実施形態における配信フロー例を示す。 第１の実施形態における制御ノード及び配信ノードの構成ブロックを示す。 第１の実施形態におけるユーザ情報テーブルの構成例を示す。 第１の実施形態におけるノード間接続テーブルの構成例を示す。 第１の実施形態におけるセンサー情報テーブルの構成例を示す。 第１の実施形態におけるノード状態テーブルの構成例を示す。 第１の実施形態における収容管理テーブルの構成例を示す。 第１の実施形態におけるリンク管理テーブルの構成例を示す。 第１の実施形態における中継定義テーブルの構成例を示す。 第１の実施形態における処理定義テーブルの構成例を示す。 第１の実施形態における制御ノードの全体フロー例を示す。 第１の実施形態における制御のノードの配信ノード決定処理（Ｓ１４）のフローを示す。 第１の実施形態における制御ノードのデータ追加処理（Ｓ１５）のフローを示す。 第１の実施形態における制御のノードのデータ削除処理のフローを示す。 第１の実施形態における制御ノードにより行われるデータ設定処理のフローを示す。 第１の実施形態における制御ノードからの配信定義受信時の配信ノードのフローを示す。 第１の実施形態におけるメッセージ受信時の配信ノードのフローを示す。 第２の実施形態における制御ノード及び配信ノードの構成ブロックを示す。 第２の実施形態における配信時刻管理テーブルの構成例を示す。 第２の実施形態における収納管理テーブルの構成例を示す。 第２の実施形態におけるリンク管理テーブルの構成例を示す。 第２の実施形態における制御のノードのデータ追加処理のフローを示す。 第２の実施形態における制御のノードのデータ削除処理のフローを示す。 第２の実施形態における制御ノードにより行われるデータ設定処理のフローを示す。 第３の実施形態における配信システムの構成例を示す。 第３の実施形態における制御ノード及び配信ノードの構成ブロックを示す。 第３の実施形態におけるノードグループテーブルの構成例を示す。 第３の実施形態におけるノード間接続テーブルの構成例を示す。 第３の実施形態における制御のノードの配信ノード決定処理（Ｓ１４）のフローを示す。 第４の実施形態における制御ノード及び配信ノードの構成ブロックを示す。 第４の実施形態におけるノード状態テーブルの構成例を示す。 第４の実施形態における負荷状態収集部５４の処理フローを示す。 第４の実施形態における負荷状態更新部５３の処理フローを示す。 第４の実施形態における制御ノードの全体フロー例を示す。 第４の実施形態における制御のノードの配信ノード決定処理（Ｓ１４）のフローを示す。 第５の実施形態の適用前の配信状態を説明する図である。 第５の実施形態の適用後の配信状態を説明する図である。 第５の実施形態における見直し処理のフローを示す。 第６の実施形態における配信ノード間の論理トポロジーを見直す処理フローを示す。 第６の実施形態における配信木見直し処理（Ｓ８１）の詳細フローを示す。 第７の実施形態における制御ノード及び配信ノードの構成ブロックを示す。 第７の実施形態における制御ノード・配信ノード管理テーブルの構成例を示す。 第７の実施形態における制御のノードのデータ追加処理のフローを示す。 第７の実施形態における制御のノードのデータ削除処理のフローを示す。 第７の実施形態における複数の制御ノード間のデータ追加のフローを示す。 第７の実施形態における複数の制御ノード間のデータ削除のフローを示す。 コンピュータのハードウェア環境の構成ブロック図である。

図１は、本発明の実施形態における配信システムの機能ブロック図を示す。本実施形態における配信システム１は、複数の配信ノード７と、制御ノード２とがネットワーク１３を介して接続されている。制御ノード２は、決定部３、配布部４を含む。

決定部３は、接続情報と、負荷情報とに基づいて、複数の配信ノード７のうち一の配信ノード７ａが次に配信する配信先の配信ノード７ｂと、配信先の配信ノード７ｂに配信するデータの種別とを配信ノード７毎に決定する。接続情報は、複数の配信ノード７間の接続状態を示す情報である。負荷情報は、複数の配信ノード７それぞれにおける負荷の状態を示す情報である。決定部３の一例として、処理決定部３２がある。

配布部４は、決定した配信先の配信ノードを特定するノード情報と、決定した配信データの種別を特定する種別情報とを、配信ノードに配布する。配布部４の一例として、定義配布部３３がある。

配信ノード７は、受信部８と、送信部９を含む。受信部８は、制御ノード２から配布されたノード情報と種別情報とを受信する。送信部９は、他の配信ノード７から配信されたデータを受信した場合には、受信したデータから、受信した種別情報が特定する種別のデータを選択する。送信部９は、選択した種別のデータを、受信したノード情報が特定する配信ノードに送信する。受信部の一例として、定義設定部４７がある。送信部９の一例として送信処理部４６がある。

このように構成することにより、配信ノードは、他の配信ノードから受信したデータのうち、ユーザが要求するデータのみを配信先の配信ノードに転送することにより、配信ノード間で転送するデータ量を削減できる。また、ユーザへは、ユーザが配信要求をした種別のデータしか配信されないので、ユーザが配信されたデータから必要なデータを抜き出すというユーザの手間を省くことができる。

また、制御ノード７は、さらに、要求受信部５を含む。要求受信部５は、いずれかの種別のデータ配信を要求する配信要求を、情報処理端末１２から受信する。要求受信部５の一例として、購読制御部３１がある。決定部３は、配信要求を受信した場合、情報処理端末１２に対してデータを配信可能な配信ノードの中から、負荷情報に応じて、端末配信ノード（情報処理端末１２に配信する配信ノード７）を決定する。

このように構成することにより、情報処理端末１２に対して配信可能な配信ノードの中から、負荷情報に応じて、情報処理端末１２に実際にデータを配信する配信ノード７を決定することができる。

また、決定部３は、配信ノード７がグループに分類されている場合、配信ノード７とグループとを関係付けたノードグループ情報から、予め前記情報処理端末に配信する配信ノードとして設定された該配信ノード（７、２３）が属するグループに属する配信ノードを抽出する。決定部３は、抽出した配信ノードの中から、負荷情報に応じて、情報処理端末１２に配信する配信ノード７である端末配信ノードを決定する。

このように構成することにより、複数の配信ノードのうち、予め前記情報処理端末に配信する配信ノードとして設定された配信ノードにデータを配信する配信ノードの中から、端末配信ノードを決定することができる。

また、決定部３は、グループから抽出した配信ノードのうち、配信要求の対象の種別のデータを送信または受信する配信ノードを端末配信ノードとして選択する。
このように構成することにより、あるグループに属する配信ノードの中から、配信要求の対象の種別のデータを送信または受信する配信ノードを優先的に端末配信ノードとして選択することができるので、無駄なフィルタ処理を行わなくてよい。

また、決定部３は、配信ノード７が受信したデータを複製した複製回数を負荷情報として計測する。決定部３は、複製回数に応じて、情報処理端末１２に対して配信可能な配信ノードの中から、端末配信ノードを決定する。

このように構成することにより、情報処理端末１２に対して配信可能な配信ノードの中から、複製回数に応じて、配信ノードを端末配信ノードとして決定することができる。
配信ノード７は、さらに、負荷情報通知部１０を含む。負荷情報通知部１０は、配信ノード７に設けられた演算装置の利用率を検出して、検出した演算装置の利用率を制御ノード２へ送信する。負荷情報通知部１０の一例として、負荷状態収集部５４がある。このとき、制御ノードは、さらに、負荷情報更新部１１を含む。負荷情報更新部１１は、配信ノード７から受信した演算装置の利用率を用いて、負荷情報を更新する。負荷情報更新部１１の一例として、負荷情報更新部５３がある。

このように構成することにより、情報処理端末１２に対して配信可能な配信ノードの中から、演算装置の利用率を用いて配信ノードを端末配信ノードとして決定することができる。

決定部３は、配信先のノード情報とデータの種別を特定する種別情報との配布後に、配信要求がされて決定した配信先の配信ノードと、その配信先の配信ノードに配信するデータの種別とを取得する。このとき、配布部４は、取得された配信先の配信ノードを特定するノード情報と、取得されたデータの種別を特定する種別情報とを、配信ノードに配布する。

このように構成することにより、ノード情報と種別情報とを配布した時刻以降に更新された配信先の配信ノードを特定するノード情報と、取得されたデータの種別を特定する種別情報（配信定義）のみを配信ノードに配信することができる。

決定部３は、受信された配信要求に含まれるデータ種別が多い配信要求を送信した情報処理端末に対する端末配信ノードを、配信木（データを配信するための配信経路であって木構造で表される）における最上位の配信ノードに決定する。

このように構成することにより、配信木を変更せずに、配信木における最上位の配信ノードを端末配信ノードとして決定することができる。それにより、ネットワーク上を流れるデータ量をより削減することが可能となる。

決定部３は、受信された配信要求のうち最も多くのデータ種別を含む配信要求の数を端末配信ノード毎に計測する。決定部３は、配信要求数が最も多く計測された端末配信ノードを、配信木（データを配信するための配信経路であって木構造で表される）のルートとして決定する。

このように構成することにより、配信ノード間の論理トポロジーを見直して、多くのユーザに対して、配信要求された多くのデータ種別を配信している配信ノードを配信木のルートにすることができるので、ネットワーク上を流れるトラフィックを削減できる。

制御ノードは、さらに、通信部を含む。通信部は、配信システムに、それぞれ複数の配信ノードを配下に持つ制御ノード２が複数存在する場合に、制御ノード間で通信を行う。いずれかの制御ノード２が配信要求を受信した場合、その配信要求を受信した制御ノードの決定部３は、次の処理を実行する。すなわち、その決定部３は、複数の配信ノード７間の接続情報と、複数の配信ノード７それぞれにおける負荷情報とに基づいて、複数の配信ノード７のうち一の配信ノードが次に配信する配信先の配信ノードを選択する。このとき、決定部３は、各制御ノードの配下の配信ノードを特定する情報に基づいて、選択した配信ノードがいずれかの制御ノードの配下の配信ノードであるかを判定する。選択した配信ノードがいずれの制御ノード配下の配信ノードでもないと判定された場合、通信部は、次の処理を行う。すなわち、通信部は、他の前記制御ノード配下の配信ノードのいずれから、配信要求をした情報処理装置に対する端末配信ノードへ配信要求の対象の種別のデータを送る旨を他の制御ノードに通知する。通信部６の一例として、制御ノード連携部５５がある。

このように構成することにより、制御ノードを並列に動作可能にすることで、システムが大規模化した場合にもデータの配信が可能となる。
本実施形態では、ユーザ各々での必要なデータを抜き出す加工処理の削減・無駄な情報転送の削減を実現するために、配信ノードと制御ノードを用いて、以下の処理を行う。以降、配信ノードと制御ノードを別装置として説明するが、物理的に、これらの装置が同一の装置（ノード）になっていてもよい。

本実施形態では、配信ノードは、センサーから送られるメッセージのうち、ユーザから配信要求のあったデータ種別だけを、ユーザの端末に届ける。メッセージは、例えば、レイヤ３（Ｌ３）ヘッダ、レイヤ４（Ｌ４）ヘッダ、レイヤ７（Ｌ７）プロトコルヘッダ、及びメッセージコンテンツを含む。

レイヤ３ヘッダの一例としては、ＩＰ（Internet Protocol）ヘッダがある。レイヤ４ヘッダの一例としては、ＴＣＰ（Transmission Control Protocol）ヘッダがある。レイヤ７プロトコルヘッダの一例としては、ＨＴＴＰ（HyperText Transfer Protocol）ヘッダがある。

例えばXML（Extensible Markup Language）で構成されたメッセージの場合、配信ノードは、ユーザから配信要求のあったデータ種別に対応する内容を特定するタグのみを配信対象とする。

本実施形態では、さらに、配信システムの状態に基づいて、配信ノードからユーザまでの配信経路を変える。これにより、１つの配信ノードにセンサー情報を集中させ、そのセンサー情報を集中させた配信ノードから配信するのではなく、ネットワークで分散してセンサー情報を配信可能にする。制御ノードは、ユーザからの購読依頼の受信を契機として、各配信ノードに対して配信定義の設定を行う。ここでは、制御ノードは、トポロジーの情報、購読依頼の内容および各配信ノードの負荷状態に基づいて、負荷が１点に集中しないよう、負荷が軽い配信ノードからユーザに対してデータをコピーさせるような配信定義を生成する。トポロジーの情報とは、センサーと配信ノードおよびユーザの位置関係に関する情報を言う。制御ノードは、各配信ノードに対して、生成した配信定義の設定を行う。

この配信定義の作り方には様々なバリエーションが考えられる。例えば、配信ノード間の繋がり（配信木）を固定としておき、ユーザにデータをコピーして渡す配信ノードのみを切り替える方法が考えられる。この場合、制御ノード側で配信ノードのコピー処理の内容、およびユーザの接続先となる配信ノードの決定を行う。

なお、ここでの制御ノード２はパーソナルコンピュータ（ＰＣ）のようなクライアント端末に限らず、センサー情報を必要とするアプリケーションソフトウェアであればどのような実施形態でも適用可能である。例えば、制御ノード２はデータセンター内のアプリケーションソフトウェアでも構わない。

本実施形態の適用により、多数のクライアントや多数のユーザが存在し、リアルタイムな情報の収集及び配信を行う配信システムにおいて、システムに対する負荷集中を防ぎつつ、各ユーザに必要な情報のみを届けることが可能になる。その結果、ユーザから見た応答性能の向上、ネットワーク上を流れるトラフィック量の削減を同時に実現することができる。

＜第１の実施形態＞
図２は、第１の実施形態における配信システムの構成例を示す。配信システム２０は、サーバ２１、制御ノード２２、配信ノード２３（２３−１〜２３−４）、センサー２４、ユーザ端末２５（２５−１，２５−２）を含む。サーバ２１、制御ノード２２、配信ノード２３（２３−１〜２３−４）、センサー２４、ユーザ端末２５（２５−１，２５−２）は、インターネット等のネットワークで接続されている。

本実施形態では、センサー２４が４種類のデータ（気温（Ｄ１）、湿度（Ｄ２）、雨量（Ｄ３）、風速（Ｄ４））を採取し、１つのＸＭＬメッセージとして定期的に近隣の配信ノード２３（図２ではノード２３−１）に対して送信する。センサ２４が送信するＸＭＬメッセージの例は、図３で示される。なお、ユーザは、センサー２４の発信する情報のうちの一部の情報が必要であるものとする。

本実施形態では、ユーザＵ１がトピックに含まれるデータ種別Ｄ１，Ｄ２のデータ、ユーザＵ２がデータ種別Ｄ１のデータのみを必要とし、サーバ２１が全てのデータ（D1〜D4）を必要としていることを前提とする。本実施形態において、これらのユーザＵ１の端末２５−１、ユーザＵ２の端末２５−２、サーバ２１はすべて配信先として扱われる。

以降、説明で配信ノード２３−１〜２３−４の識別子をそれぞれ、Node1〜Node4と表記する。
図３は、第１の実施形態におけるＸＭＬメッセージの一例を示す。図３のＸＭＬメッセージ２９では、ＨＴＴＰヘッダ等のプロトコルのヘッダを省略している。

ＸＭＬメッセージ２９は、ＸＭＬのバージョン情報２９−１、トピック２９−２、日時２９−３、データ種別関係情報２９−４１〜２９−４４を含む。データ種別関係情報２９−４１は、データ種別Ｄ１に関する情報であり、一例としてデータ種別Ｄ１と値２５．５を含む。データ種別関係情報２９−４２は、データ種別Ｄ２に関する情報であり、一例としてデータ種別Ｄ２と値４９を含む。データ種別関係情報２９−４３は、データ種別Ｄ３に関する情報であり、一例としてデータ種別Ｄ３と値０を含む。データ種別関係情報２９−４４は、データ種別Ｄ４に関する情報であり、一例としてデータ種別Ｄ４と値５を含む。

メッセージコンテンツの例として、ＳＯＡＰ（Simple Object Access Protocol）、ＲＥＳＴ（REpresentational State Transfer）命令、ＨＴＭＬ（HyperText Markup Language）文書などもある。

図４は、第１の実施形態における配信フロー例を示す。配信システム２０では、配信ツリー構築フェーズ（Ｓ１）、購読依頼受付フェーズ（Ｓ２）、設定フェーズ（Ｓ３）、データ配信フェーズ（Ｓ４）の４つのフェーズが含まれる。

配信ツリー構築フェーズ（Ｓ１）では、配信ノード間のつながりに関する配信ツリー構築情報が事前に定義されている。配信（ディストリビューション）ツリー構築情報の定義方法は、特に限定されず、例えば管理者が手動で配信ツリー構築情報を設定したり、マルチキャストルーティングプロトコル等を用いてディストリビューションツリーを構築してもよい。

購読依頼受付フェーズ（Ｓ２）では、制御ノード２２は、ユーザにより指定されたトピックに含まれるデータのうち、ユーザが必要なデータ種別を、ユーザ端末２５から受信する。また、制御ノード２２は、特定の配信ノード２３がボトルネックにならないように、現在の各配信ノード２３の負荷に応じてユーザ端末の接続先となる配信ノード２３を変える。

設定フェーズ（Ｓ３）では、制御ノード２２は、決定した配信ルートで、センサー２４からのデータを配信先に配信するように、各配信ノード２３への配信定義の設定を行う。
データ配信フェーズ（Ｓ４）では、Ｓ３で設定された配信定義に基づいて、配信ノード２３はそれぞれ、配信ノード間のつながりに関する情報（リンク情報）を用いて、ユーザが必要なデータ種別のデータのみを、そのリンク情報に設定された配信先に配送する。

図５は、第１の実施形態における制御ノード及び配信ノードの構成ブロックを示す。制御ノード２２は、ネットワーク上の情報処理装置である。制御ノード２２は、購読制御部３１、処理決定部３２、定義配布部３３、ユーザ情報テーブル３４、ノード間接続テーブル３５、センサー情報テーブル３６、ノード状態テーブル３７、収容管理テーブル３８、リンク管理テーブル３９を含む。

購読制御部３１は、ユーザ端末２５からの購読依頼を受信し、購読依頼の内容をユーザ情報テーブル３４に書き込む。処理決定部３２は、ユーザ情報テーブル３４、ノード間接続テーブル３５、センサー情報テーブル３６、ノード状態テーブル３７に登録された情報を用いて、中継定義テーブル４８及び処理定義テーブル４９の内容を生成する。

定義配布部３３は、収容管理テーブル３８及びリンク管理テーブル３９の内容を、配信ノードの中継定義テーブル４８及び処理定義テーブル４９のフォーマットに変換し、配布先の配信ノード２３−ｍに対して配布する。

ユーザ情報テーブル３４は、ユーザの購読依頼情報およびユーザの近隣の配信ノードを管理するテーブルである。なお、ユーザ近隣の配信ノードがどの配信ノードなのかは、ユーザからの申告や、配信ノードが送信してからユーザ端末が受信するまでにかかる時間（遅延時間）、物理ネットワークの情報等を利用して事前に設定されているものとする。ユーザ情報テーブル３４に設定されたユーザ近隣の配信ノード（近隣ノード）はユーザにデータを配信するノードを定義したものではなく、あくまでも地理的にユーザの近隣に位置する配信ノードを定義したものである。ユーザ端末に対するデータの配信は、実際には、処理決定部３２により決定された配信ノード（収容管理テーブル３８の収容ノード欄に記載された配信ノード）から配信される。近隣ノードを設定するのは、後述するように、その設定した近隣ノード及び該近隣ノードに隣接する配信ノードのうち、最も負荷の少ない配信ノードを検索する場合、その検索の始点を設定するためである。

ノード間接続テーブル３５は、配信ノード間の接続関係を管理するテーブルである。配信ノード間のつなぎ方や配信経路の構築については、管理者による手動設定、もしくはマルチキャストツリーの構築技術等の技術で決定されているものとする。

センサー情報テーブル３６は、センサー２４の近隣の配信ノードを管理するテーブルである。なお、センサー２４近隣の配信ノード２３がどの配信ノードなのかは、センサー２４の所有者からの申告や、センサー２４が送信してから配信ノードが受信するまでにかかる時間（遅延時間）、物理ネットワークの情報等を利用して事前に設定されているものとする。

ノード状態テーブル３７は、各配信ノードの中継処理にかかる負荷を管理するテーブルである。制御ノード２２は、ノード状態テーブル３７を用いて、最大処理性能と現在の処理状況を管理することで、各配信ノード２３の負荷を管理する。ノード状態テーブル３７は、各配信ノード２３のＣＰＵ利用率などを定期的に収集しても良いし、例えば定常的に配信データが発生する場合は配信ノード２３内の処理の回数を負荷として管理しても良い。本実施形態では後者の例として、１配信ノード当たりの１メッセージに対するコピー処理回数を負荷として管理する。

収容管理テーブル３８は、ユーザ端末を収容する配信ノード、即ち実際にユーザ端末２５にデータを配信する配信ノードを管理するテーブルである。ユーザ情報テーブル３４によって近隣の配信ノード２３を特定することができても、実際にユーザ端末２３に対してデータを直接渡すべき配信ノード２３と近隣の配信ノードとは異なる場合がある。そのため、制御ノード２２は、ユーザ情報テーブル３４とは別のテーブルを収容管理テーブル３８として準備して、実際にユーザ端末２５にデータを配信する配信ノードを管理する。また、制御ノード２２は、収容管理テーブル３８を用いて、どのデータをどのユーザに対して配信するのかも合わせて管理する。

リンク管理テーブル３９は、配信ノード間をつなぐ中継経路をリンクとして捉え、そのリンクごとに配信するデータ種別を管理するテーブルである。
配信ノード２３は、ネットワーク上の中継処理装置である。配信ノード２３は、受信処理部４１、トピック識別部４２、宛先決定部４３、コピー処理部４４、フィルタ処理部４５、送信処理部４６、定義設定部４７、中継定義テーブル４８、処理定義テーブル４９を含む。

受信処理部４１は、センサー２４もしくは隣接の配信ノード２３からパケットを受信し、その受信したパケットを組み立ててメッセージを構築する。トピック識別部４２は、構築したメッセージに含まれるトピックを識別する。

宛先決定部４３は、中継定義テーブル４８に従って、配信データの中継先をあて先として１つもしくは複数決定する。コピー処理部４４は、宛先決定部４３により決定した宛先の数に応じて、中継先に配信するメッセージをコピーする。

フィルタ処理部４５は、決定した宛先及び処理定義テーブル４９の内容に従い、宛先ごとに、配信するメッセージから必要のないデータ種別に関するＸＭＬタグを削除する（フィルタ処理）。送信処理部４６は、フィルタ処理されたメッセージをパケットに分解して、指定された宛先（例えば、他の配信ノード２３−ｎ、ユーザ端末２５、サーバ２１等）に対して、その分解したパケットを送信する。

定義設定部４７は、制御ノード２２から配布された配信定義に基づいて、中継定義テーブル４８及び処理定義テーブル４９の設定を行う。中継定義テーブル４８は、トピックごとに、配信すべき中継先ノード及び／またはユーザのグループを管理するテーブルである。処理定義テーブル４９は、トピック及び／または宛先ごとに、渡すべきデータ種別を管理するテーブルである。

図６は、第１の実施形態におけるユーザ情報テーブルの構成例を示す。ユーザ情報テーブル３４は、「ユーザＩＤ」３４−１、「トピック」３４−２、「データ種別」３４−３、「近隣ノード」３４−４のデータ項目を含む。「ユーザＩＤ」３４−１には、ユーザを識別する識別情報が格納される。「トピック」３４−２には、ユーザによる購読対象のトピックを識別する識別情報が格納される。「データ種別」３４−３には、ユーザが購読するデータの種別が格納される。「近隣ノード」３４−４には、ユーザ端末の近隣に設けられた配信ノードを識別する識別情報が格納される。

図７は、第１の実施形態におけるノード間接続テーブルの構成例を示す。ノード間接続テーブル３５は、「リンク」３５−１、「Ｆｒｏｍ」３５−２、「Ｔｏ」３５−３を含む。「リンク」３５−１には、配信ノード２３間のリンクを識別する識別情報が格納される。「Ｆｒｏｍ」３５−２には、リンクの接続元の配信ノード２３の識別情報またはアドレスが格納される。「Ｔｏ」３５−３には、リンクの接続先の配信ノードの識別情報またはアドレスが格納される。

図８は、第１の実施形態におけるセンサー情報テーブルの構成例を示す。センサー情報テーブル３６は、「センサーＩＤ」３６−１、「トピック」３６−２、「収容ノード３６−３」のデータ項目を含む。「センサーＩＤ」３６−１には、センサー２４を識別する識別情報が格納される。「トピック」３６−２には、対応するセンサーに関するトピックを識別する識別情報が格納される。「収容ノード」３６−３には、センサーＩＤに対応するセンサー２４を収納している配信ノード、つまりセンサー近隣の配信ノードの識別情報が格納される。

図９は、第１の実施形態におけるノード状態テーブルの構成例を示す。ノード状態テーブル３７は、「ノード」３７−１、「許容処理量」３７−２、「負荷量」３７−３のデータ項目を含む。「ノード」３７−１には、配信ノード２３を識別する識別情報が格納される。「許容処理量」３７−２には、配信ノード２３の最大処理性能の値が格納される。「負荷量」３７−３には、配信ノード２３の現在の処理量が格納される。

図１０は、第１の実施形態における収容管理テーブルの構成例を示す。収容管理テーブル３８は、「ユーザＩＤ」３８−１、「トピック」３８−２、「データ種別」３８−３、「収容ノード」３８−４のデータ項目を含む。「ユーザＩＤ」３８−１には、ユーザを識別する識別情報が格納される。「トピック」３８−２には、ユーザに対応するトピックを識別する識別情報が格納される。「データ種別」３８−３には、ユーザが購読するデータ種別が格納される。「収容ノード」３８−４には、ユーザ端末２５を収容している配信ノードを識別する識別情報が格納される。

図１１は、第１の実施形態におけるリンク管理テーブルの構成例を示す。リンク管理テーブル３９は、「リンク」３９−１、「Ｆｒｏｍ」３９−２、「Ｔｏ」３９−３、「トピック」３９−４、「データ種別」３９−５のデータ項目を含む。「リンク」３９−１には、配信ノード間のリンクを識別する識別情報が格納される。「Ｆｒｏｍ」３９−２には、リンクの接続元の配信ノードの識別情報またはアドレスが格納される。「Ｔｏ」３９−３には、リンクの接続先の配信ノードの識別情報またはアドレスが格納される。「トピック」３９−４には、リンクの接続先の配信ノードに対して送信するトピックを識別する識別情報が格納される。「データ種別」３９−５には、リンクの接続先の配信ノードに対して送信するデータ種別が格納される。

図１２は、第１の実施形態における中継定義テーブルの構成例を示す。中継定義テーブル４８は、「トピック」４８−１、「宛先」４８−２のデータ項目を含む。「トピック」４８−１には、トピックを識別する識別情報が格納される。「宛先」４８−２には、トピックごとの配信ノードからのデータの配信先を識別する識別情報またはアドレスが格納される。例えば、宛先＝「Node2」のエントリが中継先ノードへの中継に該当し、宛先＝「Server1」のエントリがユーザへの配信に該当する。たとえば、ユーザＵ２のユーザＩＤが「User2」である場合、ユーザＵ２にデータを配信する場合には宛先欄に「User2」がセットされる。

図１３は、第１の実施形態における処理定義テーブルの構成例を示す。処理定義テーブル４９は、「トピック」４９−１には、トピックを識別する識別情報が格納される。「中継先」４９−２には、トピックを配信する中継先を識別する識別情報またはアドレスが格納される。「データ種別」４９−３には、対応する中継先に配信されるデータ種別が格納される。

図１４は、第１の実施形態における制御ノードの全体フロー例を示す。本実施形態では、ユーザＵ１がトピック１の配信データＤ１及びＤ２を購読済みであるとする。また、ユーザＵ１が利用するユーザ端末２５−１は、センサー２４からの情報を配信ノード２３−１（Node1）から配信ノード２３−２（Node2）を経由して受信するものとする。また、サーバ２１は、トピック１の全てのデータ（Ｄ１〜Ｄ４）を購読済みであり、センサー２４からの情報を配信ノード２３−１から受信するものとする。このときに、ユーザＵ２が新たにトピック１のデータＤ１について購読依頼を行ったとする。

ユーザＵ２がユーザ端末２５−２を用いて、購読依頼を制御ノード２２に通知する。この際に、ユーザ端末２５−２からは、購読依頼と共に、ユーザ購読情報として、ユーザＵ２のユーザID（User2）、ユーザＵ２が購読依頼するデータ種別（D1）、ユーザ端末２５−２の隣接ノードの情報（配信ノード２３−４（Node4））を制御ノード２２に送信する。なお、制御ノード２２が、隣接ノードの情報を管理して、ユーザ端末２５−２から通知されるユーザID（User2）に基づいて、隣接ノードの情報を求めても良い。

購読制御部３１は、ユーザ端末２５−２から購読制御情報（購読依頼）を受信すると（Ｓ１１、Ｓ１２で「Ｙｅｓ」）、ユーザ情報テーブル３４にユーザ端末２５−２から受信したユーザ購読情報を追加する（Ｓ１３）。購読制御部３１は、処理決定部３２にユーザが増えたことを通知する。

次に、処理決定部３２は、配信ノード決定処理を行う（Ｓ１４）。配信ノード決定処理（Ｓ１４）では、ユーザ端末２５−２に実際に配信データを配信する配信ノードを決定する。Ｓ１４の処理については、図１５を用いて説明する。

処理決定部３２は、データ種別追加処理を行う（Ｓ１５）。データ種別追加処理（Ｓ１５）では、ユーザＵ２の必要とするデータ種別Ｄ１がＳ１４で決定した配信ノードまで配信されるように、リンク管理テーブル３９に、データ種別を追加する。その後、処理決定部３２は、データ種別についての配信定義情報を配布するように、定義配布部３３に依頼する。

定義配布部３３は、処理決定部３２からの配布依頼を受けて、各配信ノード２３に、配信定義情報を配布する（Ｓ１６）。
次に、購読解除の場合について説明する。ユーザ端末２５より購読解除するトピックを制御ノード２２に通知し、ユーザ情報テーブル３４から、その購読解除対象となるユーザ購読情報を削除する。それ以降の処理は購読依頼と同じである。以下に、購読解除について詳述する。

ユーザＵ２がユーザ端末２５−２を用いて、購読解除要求を制御ノード２２に通知する。この際に、ユーザ端末２５は、購読解除要求と共に、ユーザ購読解除情報として、ユーザＵ２のユーザID（User2）、購読を解除するデータ種別（D1）、ユーザ端末２５の隣接ノードの情報（配信ノード２３−４（Node4））を制御ノード２２に送信する。

購読制御部３１は、ユーザ端末２５−２から購読制御情報（購読解除要求）を受信すると（Ｓ１１、Ｓ１２で「Ｎｏ」）、ユーザ情報テーブル３４から、その購読解除情報に対応するエントリを削除する（Ｓ１７）。購読制御部３１は、処理決定部３２にユーザが減ったことを通知する。

処理決定部３２は、購読制御部３１からの購読解除情報を用いて、収容管理テーブルの「収容ノード」から、購読解除要求を通知したユーザ端末２５−２に配信データ尾を配信していた配信ノードの識別情報を取得する（Ｓ１８）。

処理決定部３２は、ノード状態テーブル３７において、Ｓ１８で取得した配信ノードの「負荷量」を所定値分減らす（Ｓ１９）。減らす値は、用いる「負荷量」がＣＰＵ利用率、メモリ利用率等、監視する負荷のいずれかであるかに応じて相違する。

処理決定部３２は、データ種別削除処理を行う（Ｓ２０）。データ種別削除処理（Ｓ２０）では、ユーザＵ２が購読解除したデータ種別が、購読解除したユーザ端末２５−２に配信データを配信する配信ノードまで不必要に配信されないように、リンク管理テーブル３９からデータ種別を削除する。その後、処理決定部３２は、データ種別についての配信定義情報を配布するように、定義配布部３３に依頼する。

定義配布部３３は、処理決定部３２からの配布依頼を受けて、各配信ノード２３に、配信定義情報を配布する（Ｓ１６）。

図１５は、第１の実施形態における制御のノードの配信ノード決定処理（Ｓ１４）のフローを示す。処理決定部３２は、購読制御部３１からの通知を契機に、ユーザ情報テーブル３４の該当するエントリ（User2，Topic1，D1，Node4）を読み出し、ユーザ端末２５−２の接続先の配信ノードの選択を行う（Ｓ１４−１）。

次に、処理決定部３２は、ノード状態テーブル３７を参照し、ユーザ購読情報に含まれるノード（Node4）の負荷量（例えば、Copy回数）が予め設定した閾値を超えているか否かを判定する（Ｓ１４−２）。ここで、予め設定した閾値とは、ノード状態テーブル３７の「許容処理量」に設定した値をいう。

Ｓ１４−２において、ユーザ購読情報に含まれるノード（Node4）の負荷量がその閾値を超えていない場合は（Ｓ１４−２で「Ｎｏ」）、そのノード（Node4）を選択する。
一方、ユーザ購読情報に含まれるノード（Node4）の負荷がその閾値を超えている場合（Ｓ１４−２で「Ｙｅｓ」）、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、ノード間接続テーブル３５を用いて、ユーザ購読情報に含まれる近隣ノード（Node4）に隣接するノードの中で負荷が閾値を越えていないノードを順に探索して、ノードを選択する（Ｓ１４−３）。

処理決定部３２は、Ｓ１４−１またはＳ１４−３で選択したノードのNode番号（Node4）、ユーザID（User2）、データ種別（D1）を収容管理テーブル３８に追加する（Ｓ１４−４）。

処理決定部３２は、ノード状態テーブル３５において、Ｓ１４−１またはＳ１４−３で選択したNode番号（Node4）に対応するエントリの負荷量を所定値分増やす（Ｓ１９）。「負荷量」がCopy回数の場合には、Node番号（Node4）に対応するエントリの負荷量に「１」を増やす。

図１６は、第１の実施形態における制御ノードのデータ追加処理（Ｓ１５）のフローを示す。処理決定部３２は、ノード間接続テーブル３５を読み出し、Ｓ１４で決定したノード（Node4）と、その決定したノードを接続先とする配信ノード（Node2）間のリンクを特定する。それから、処理決定部３２は、リンク管理テーブル３９を用いて、そのリンクに関して、ユーザ購読情報に含まれるデータ種別の配信データ（D1）が届くようになっているか確認する。

具体的には、処理決定部３２は、ノード間接続テーブル３５において、「To」の欄に設定されたノードがＳ１４で決定したノード（Node4）であるエントリを検索する。処理決定部３２は、その検索されたエントリのデータ項目「リンク」に格納されているリンクの識別情報（L3）、及び「From」に格納されているノードの識別情報（Node2）を取得する。処理決定部３２は、リンク管理テーブル３９から、取得したリンクの識別情報（L3）を含むエントリを取得する。処理決定部３２は、その取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）が格納されているか確認する（Ｓ１５−１）。その取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）が格納されている場合、すなわちＤａｔａ種別が不足していない場合（Ｓ１５−１で「Ｎｏ」）、D1がNode4へ届くことになるので、本フローは終了する。

リンク管理テーブル３９から取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）が格納されていない場合、すなわちＤａｔａ種別が不足している場合（Ｓ１５−１で「Ｙｅｓ」）、D1が収容ノード（Node4）へ届かないので、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、その取得したエントリのデータ項目「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）を格納する（Ｓ１５−２）。それから、処理決定部３２は、センサー２４に近いノードから順にD1が配信されるように、ノード間接続テーブル３５から、収容ノード（Node4）の上位ノード（リンクの接続元）を検索し（Ｓ１５−３）、Ｓ１５−１、Ｓ１５−２を繰り返す。本実施形態の場合、Node2まではデータ種別（Ｄ１）のデータが届いているため、リンク管理テーブル３９においてNode2からNode4へのリンクを示すエントリの、データ項目「データ種別」に「D1」を設定する。

処理決定部３２はリンク管理テーブル３９の更新が完了した時点で、定義配布部３３に配信定義を配信ノードに配信するように依頼する。

上記の方法は、購読依頼のあったユーザの追加に伴い、そのユーザのユーザ端末２５に、ユーザが必要とするデータ種別のデータを配信するものである。しかしながら、配信システム全体の最適化のために、定期的に全体の収容管理及びリンク管理を見直しても良い。この詳細は、第５及び第６の実施形態で説明する。

図１７は、第１の実施形態における制御のノードのデータ削除処理のフローを示す。処理決定部３２は、収容管理テーブル３８から、購読解除情報に含まれるユーザＩＤと一致するユーザＩＤを有するエントリを検索し、そのエントリのデータ項目「収容ノード」に格納されたノードの識別情報を取得する。処理決定部３２は、ノード間接続テーブル３５において、「To」＝その取得したノード「Node4」のエントリを検索する。処理決定部３２は、その検索されたエントリの「リンク」に格納されているリンクの識別情報（L3）、及び「From」に格納されているノードの識別情報（Node2）を取得する。処理決定部３２は、リンク管理テーブル３９から、取得したリンクの識別情報（L3）を含むエントリのデータ種別に「D1」が含まれている場合には、Ｄ１を削除する（Ｓ２０−１で「Ｙｅｓ」、Ｓ２０−２）。

処理決定部３２は、上位ノード（リンクの接続元）を検索し（Ｓ２０−３）、その上位ノードのリンク管理テーブル３９のエントリからデータ種別（Ｄ１）を削除する。処理決定部３２は、リンク管理テーブル３９の更新が完了した時点で、定義配布部３３に配信定義を配信ノード２３に配信するように依頼する。

図１８は、第１の実施形態における制御ノードにより行われるデータ設定処理のフローを示す。定義配布部３３は、処理決定部３２からの配信定義の配布依頼を受けて、収容管理テーブル３８の接続先Node、リンク管理テーブル３９のFrom欄のノードを選択する（Ｓ１６−１）。定義配布部３３は、その選択したノードに対して、収容管理テーブル３８及びリンク管理テーブルのエントリを配信定義として送信する（Ｓ１６−２）。定義配布部３３は、全ノードについてＳ１６−１〜Ｓ１６−２の処理を繰り返す（Ｓ１６−３）。

図１９は、第１の実施形態における制御ノードからの配信定義受信時の配信ノードのフローを示す。配信ノード２３の定義設定部４７は、制御ノード２２から配布された配信定義（収容管理テーブル３８及びリンク管理テーブル３９のエントリ）を受信する（Ｓ３１）。定義設定部４７は、その受信した配信定義を解析し、その解析した配信定義を中継定義テーブル４８及び処理定義テーブル４９に設定する（Ｓ３２）。

すなわち、Ｓ３２において、定義設定部４７は、制御ノード２２から配布された配信定義を解析し、収容管理テーブル３８の収容ノード及びUserIDを中継定義テーブル４８の宛先として登録する。例えば、配信ノード２３−１の場合には、Node2およびServer1が宛先として中継定義テーブル４８に登録される。なお、Node2およびServer1のアドレス情報については、制御ノード２２もしくは配信ノード２３に設定されており、アドレス解決可能な状態であるものとする。

また、Ｓ３２において、定義設定部４７は、収容管理テーブル３８のUserIDごとに定義されたデータ種別、及びリンク管理テーブル３９のToごとに定義されたデータ種別を、処理定義テーブル４９に登録する。例えば配信ノード２３−１では、Server1に対してD1，D2，D3，D4を転送し、Node2に対してD1，D2を転送するようにエントリが処理定義テーブル４９に登録される。

図２０は、第１の実施形態におけるメッセージ受信時の配信ノードのフローを示す。以下では、配信ノード２３−１を例に、図２０のフローを説明する。センサー２４は、配信ノード２３−１に対してD1〜D4を含むメッセージを送信する。

受信処理部４１は、そのメッセージを受信する（Ｓ４１）。トピック識別部４２は、その受信したメッセージを解析し、トピックの識別情報を取得する（Ｓ４２）。配信ノード２３−１の場合、トピック識別部４２は、トピック１に関するメッセージであることを識別する。

宛先決定部４３は、Ｓ４２で識別したトピックをキーとして、中継定義テーブル４８を検索し、そのキーを含むエントリの宛先情報を読み出し、宛先が決定する（Ｓ４３）。配信ノード２３−１の場合、宛先決定部４３は、Ｓ４２で識別したトピック１をキーとして、宛先がServer1及びNode2であることを読み出す。宛先決定部４３は、その読み出した宛先をコピー処理部４４に通知する。

コピー処理部４４は、通知された宛先数に応じて、受信したメッセージをコピーする（Ｓ４４）。配信ノード２３−１の場合、コピー処理部４４は、宛先決定部４３より通知された宛先が２つであることから、受信メッセージを複製してServer1宛及びNode2宛のメッセージを作成する。

フィルタ処理部４５は、処理定義テーブル４９に基づいて、受信したメッセージから、不要なＸＭＬタグを削除する（フィルタ処理）（Ｓ４５，Ｓ４６）。
配信ノード２３−１の場合、フィルタ処理部４５は、処理定義テーブル４９の内容を参照し、宛先がServer1のメッセージについてはそのまま転送する。一方、フィルタ処理部４５は、宛先がNode2のメッセージについては、データ種別D3，D4に関するＸＭＬタグを削除し、データ種別D1，D2に関するＸＭＬタグのみのメッセージを作成する。

送信処理部４６は、各々の宛先に、フィルタ処理部４５で処理されたメッセージを転送する（Ｓ４７）。
以降、各配信ノード２３で同様の処理を繰り返し、サーバ２１、ユーザ端末２５−１、ユーザ端末２５−２にそれぞれ必要なデータを届ける。

なお、コピー処理とフィルタ処理の順序には依存性はなく、同一のフィルタ処理を繰り返し行うことが分かっている場合は、処理効率を上げるためにフィルタ処理を先に行ってからコピー処理を行っても良い。

このように、ユーザ端末２５の近隣にある１以上の配信ノードから、負荷に余裕のある配信ノードを実際にユーザ端末２５に配信する配信ノードとして決定することができる。その決定した配信ノードから、既存のリンク関係に基づいて、そのユーザ端末２５が配信要求しているデータ種別のデータが到来している上位の配信ノードまで辿ることができる。そして、その上位の配信ノードから、その決定した配信ノードへそのデータ種別のデータを引き込むことができる。

本実施形態によれば、制御ノードは、ユーザの購読依頼の受信を契機として、トポロジーの情報（センサーと配信ノード及びユーザの位置関係）、購読依頼の内容及び各配信ノードの負荷状態に基づいて、中継処理の配信定義を生成する。そして、制御ノードは、各配信ノードに配信定義を設定するよう指示する。配信ノードは、制御ノードからの指示に従って、データのコピー、フィルタ、中継処理を行う。これにより、複数のユーザに対して必要なデータのみを分散配信することが可能となる。

＜第２の実施形態＞
本実施形態では、制御ノードが、前回配布した時刻以降に更新された配信定義のみを配信ノードに配信する場合の処理内容を説明する。なお、第２の実施形態において、第１の実施形態と同様な構成については、同一の符号を付し、その説明を省略する。

図２１は、第２の実施形態における制御ノード及び配信ノードの構成ブロックを示す。第２の実施形態の配信システム２０は、第１の実施形態の制御ノード２２において、配信時刻管理テーブル５１を追加したものである。また、収容管理テーブル３８ａには、収容管理テーブル３８にデータ項目「更新時刻」が追加されている。リンク管理テーブル３９ａには、リンク管理テーブル３９に、データ項目「更新時刻」が追加されている。

配信時刻管理テーブル５１は、前回配信を行った日時を保持する。
処理決定部３２は、第１の実施形態の機能に加え、現在の収納管理テーブル及びリンク管理テーブルのエントリと更新・追加・削除する内容を確認し、収容管理テーブル３８ａ及びリンク管理テーブル３９ａの更新時刻を変更する。なお、削除する場合は、処理決定部３２は、リンク管理テーブル３９ａのエントリを削除するのではなく、リンク管理テーブル３９ａのデータ種別欄を空欄にすることで削除処理とする。

定義配布部３３は、第１の実施形態の機能に加え、配信時刻管理テーブル５１より前回の配信時刻を読み出し、前回の配信時刻以降に更新された収容管理テーブル３８ａ及びリンク管理テーブル３９ａのエントリ（配信定義）のみを、配信ノード２３に配布する。また、定義配布部３３は、配信時刻管理テーブル５１の配信時刻を、配信定義を配信ノード２３に配布した日時で更新する。

図２２は、第２の実施形態における配信時刻管理テーブルの構成例を示す。配信時刻管理テーブル５１は、「トピック」５１−１、「配信時刻」５１−２のデータ項目を含む。「トピック」５１−１には、トピックの識別情報が格納される。「配信時刻」５１−２には、前回配信を行った日時が格納される。

図２３は、第２の実施形態における収納管理テーブルの構成例を示す。収納管理テーブル３８ａは、図１０の収納管理テーブル３８に、データ項目「更新時刻」３８−５を追加したものである。「配信時刻」３８−５には、当該エントリが追加または更新された日時が格納される。

図２４は、第２の実施形態におけるリンク管理テーブルの構成例を示す。リンク管理テーブル３９ａは、図１１のリンク管理テーブル３９に、データ項目「更新時刻」３９−６を追加したものである。「配信時刻」３９−６には、当該エントリが追加または更新された日時が格納される。

次に、第２の実施形態における制御ノードの処理フローについて説明する。第２の実施形態の制御ノードの処理フローは、第１の実施形態の処理（図１５−図１８）において、図１６−図１８の処理を一部変更したものである。これについて、図２５、図２６を用いて説明する。

図２５は、第２の実施形態における制御のノードのデータ追加処理のフローを示す。図２５は、図１６のＳ１５−２をＳ１５−１１に置き換えたものである。Ｓ１５−１１では、処理決定部３２は、センサー２４に近いノードから順にD1が配信されるように、ノード間接続テーブル３５から、上位ノード（リンクの接続元）を検索し、リンク管理テーブル３９のエントリ及びデータ種別を追加する。さらに、処理決定部３２は、収納管理テーブル３８ａ及びリンク管理テーブル３９ａの更新時刻を現在の時刻で更新する。

図２６は、第２の実施形態における制御のノードのデータ削除処理のフローを示す。図２６は、図１７のＳ２０−２をＳ２０−１１に置き換えたものである。処理決定部３２は、収容管理テーブル３８から、購読解除情報に含まれるユーザＩＤと一致するユーザＩＤを有するエントリを検索し、そのエントリのデータ項目「収容ノード」に格納されたノードの識別情報を取得する。処理決定部３２は、ノード間接続テーブル３５において、「To」＝その取得したノード「Node4」のエントリを検索する。処理決定部３２は、その検索されたエントリの「リンク」に格納されているリンクの識別情報、及び「From」に格納されているノードの識別情報を取得する。リンク管理テーブル３９ａにおいて、取得したリンクの識別情報（L3）を含むエントリのデータ種別に購読解除要求の対象であるデータ種別（D1）が含まれている場合には（Ｓ２０−１で「Ｙｅｓ」）、処理決定部３２は、そのエントリのデータ種別（D1）を削除する。さらに、処理決定部３２は、収納管理テーブル３８ａ及びリンク管理テーブル３９ａの更新時刻を現在の時刻で更新する（Ｓ２０−１１）。

図２７は、第２の実施形態における制御ノードにより行われるデータ設定処理のフローを示す。図２７は、図１８にＳ１６−１１を追加したものである。Ｓ１６−１１では、定義配布部３３は、配信時刻管理テーブル５１より前回の配信時刻を読み出す。定義配布部３３は、配信時刻管理テーブル５１より読み出した配信時刻と、収納管理テーブル３８ａ及びリンク管理テーブル３９ａの更新時刻とを比較する。定義配布部３３は、収納管理テーブル３８ａ及びリンク管理テーブル３９ａから、配信時刻管理テーブル５１より読み出した配信時刻以降に更新されたエントリを配布対象として抽出する。Ｓ１６−１１の処理の結果、抽出された配布対象がある場合（Ｓ１６−１１で「Ｙｅｓ」）、定義配布部３３は、その配布対象を配信定義（収納管理テーブル３８ａ及びリンク管理テーブル３９ａのエントリ）として、各配信ノードに送信する（Ｓ１６−２）。これ以降の処理は、図１８と同様である。

本実施形態によれば、処理決定部３２は、収容管理テーブル３８ａ及びリンク管理テーブル３９ａ内に更新時刻を書き込み可能にする。定義配布部３３は、エントリの更新時刻及び配信時刻管理を行う処理決定部３２と連携して、前回配信時との差分の配信定義を配信可能にする。

＜第３の実施形態＞
第３の実施形態では、複数の配信ノードのうち、配信要求をした情報処理装置の近隣にある一の配信ノードのグループに属する配信ノードから、その情報処理装置に実際に配信する配信ノードを選択することについて説明する。なお、第３の実施形態において、第１または第２の実施形態と同様な構成については、同一の符号を付し、その説明を省略する。

図２８は、第３の実施形態における配信システムの構成例を示す。例えば、図２８に示すように、エリアＡとエリアＢの拠点に配信ノードが分散配置されているとする。そして、エリア内の帯域は十分にあるが、エリアＡとエリアＢのエリア間の帯域が狭い場合を考える。

エリアＡ近隣のユーザにとって、エリアＡ内部であれば、どの配信ノードから配信されてもあまり違いはない。また、エリアＡ近隣のユーザは、エリアＢの近隣のノードからの配信はできる限り避けたいという状況が起こりうる。

そこで、本実施形態では、複数の配信ノードのうち、配信要求をした情報処理装置の近隣にある一の配信ノードのグループに属する配信ノードから、その情報処理装置に実際に配信する配信ノードを選択する。ここで、グループは、配信経路、通信環境等に応じて、設定されるものである。例えば、本実施形態では、グループ間の帯域は、所定の閾値より狭いものとする。なお、グループは、任意に設定することができる。

図２９は、第３の実施形態における制御ノード及び配信ノードの構成ブロックを示す。第３の実施形態の配信システム２０は、第１の実施形態の制御ノード２２において、ノードグループテーブル５２を追加したものである。また、配信ノードの中から優先的に所定のノードを選択できるように、ノード間接続テーブル３５ｂを用いる。

図３０は、第３の実施形態におけるノードグループテーブルの構成例を示す。ノードグループテーブル５２は、「グループ」５２−１、「ノード」５２−２のデータ項目を含む。「グループ」５２−１には、グループを識別する識別情報が格納される。「ノード」５２−２には、そのグループに属するノードを識別する識別情報が格納される。

図３１は、第３の実施形態におけるノード間接続テーブルの構成例を示す。ノード間接続テーブル３５ｂは、図７のノード間接続テーブル３５に、データ項目「グループ」３５−４を追加したものである。「グループ」３５−４には、「リンク」３５−１に格納されたリンクが属するグループを識別する識別情報が格納される。

処理決定部３２は、ノード間接続テーブル５２を用いて、配信ノード２３のグループの中から１つの配信ノードを選択する。このとき、処理決定部３２は、無駄なフィルタ処理を行わなくていいように、ノードグループテーブル５２を用いて、同じコピー対象のデータ種別を要求するユーザ端末を有するノードから優先的に選択する。

例えば、第１の実施形態の処理が終わった後、ユーザＵ３が新たにデータ種別Ｄ１，Ｄ２の購読依頼を行ったとする。このとき、例えば、ユーザＵ３のユーザ端末２５−３の近隣の配信ノードがNode1であるとする。また、図３０のノードグループテーブル５２に示すように、Node1，Node12，Node13が同一のグループであるとする。この場合、処理決定部３２は、ノードグループテーブル５２を参照して、Node1，Node2，Node3の中から配信ノードを決定する。

処理決定部３２は、新たに配信先となるユーザＵ３のユーザ端末２５−３の配信ノードを決定する際には、リンク管理テーブル３９を参照し、配信ノードが受信するデータ種別とユーザ端末２５−３に配信するデータ種別が同一であるノードを優先的に選ぶ。

リンク管理テーブル３９に配信ノードが受信するデータとユーザ端末２５−３に配信するデータが同一であるノードがない場合、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、収容管理テーブル３８を参照し、同一のデータ種別を配信しているユーザを収容している（送信する）配信ノードを優先的に選ぶ。

次に、第３の実施形態における制御ノードの処理フローについて説明する。第３の実施形態の制御ノードの処理フローは、第１の実施形態の処理（図１５−図１８）において、図１５の処理を変更したものである。これについて、図３２を用いて説明する。

図３２は、第３の実施形態における制御ノードの配信ノード決定処理（Ｓ１４）のフローを示す。処理決定部３２は、購読制御部３１からの通知を契機に、ユーザ情報テーブル３４の該当するエントリ（User2，Topic1，D1，Node4）を読み出し、ユーザ端末２５の接続先の配信ノードの選択を行う（Ｓ１４−１１）。

処理決定部３２は、ノードグループテーブル５２から、Ｓ１４−１１で選択した配信ノードのグループに属する配信ノードを読み出す（Ｓ１４−１２）。
処理決定部３２は、リンク管理テーブル３９を用いて、配信ノードが受信するデータ種別と購読依頼をしたユーザのユーザ端末２５に配信するデータ種別が同一であるノードがあるかを検索する（Ｓ１４−１３）。

Ｓ１４−１３での検索の結果、リンク管理テーブル３９に、配信ノード２３が受信するデータ種別と購読依頼をしたユーザのユーザ端末２５に配信するデータ種別が同一であるノードがある場合（Ｓ１４−１３で「Ｙｅｓ」）、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、その検索された配信ノードを選択する（Ｓ１４−１４）。

リンク管理テーブル３９に、配信ノードが受信するデータと購読依頼をしたユーザのユーザ端末２５に配信するデータが同一であるノードがない場合（Ｓ１４−１３で「Ｎｏ」）、処理決定部３２は、次の処理を実行する。すなわち、処理決定部３２は、収容管理テーブル３８を用いて、配信ノード２３が送信するデータ種別と購読依頼をしたユーザのユーザ端末２５に配信するデータ種別が同一であるノードがあるかを検索する（Ｓ１４−１５）。

Ｓ１４−１５での検索の結果、収容管理テーブル３８に、配信ノード２３が送信するデータ種別と購読依頼をしたユーザのユーザ端末２５に配信するデータ種別が同一であるノードがある場合、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、その検索された配信ノードを選択する（Ｓ１４−１６）。

Ｓ１４−１５での検索の結果、収容管理テーブル３８に、配信ノード２３が送信するデータ種別と購読依頼をしたユーザのユーザ端末２５に配信するデータ種別が同一であるノードがない場合、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、Ｓ１４−１２で読み出した配信ノードからランダムに１つを選択する（Ｓ１４−１７）。

処理決定部３２は、ノード状態テーブル３５を参照し、Ｓ１４−１４，Ｓ１４−１６、またはＳ１４−１７で選択された配信ノードの負荷量（例えば、Copy回数）が予め設定した閾値を超えているか否かを判定する（Ｓ１４−１８）。ここで、予め設定した閾値とは、ノード状態テーブル３７の「許容処理量」に設定した値をいう。

Ｓ１４−１８において、配信ノードの負荷量がその閾値を超えていると判定された場合（Ｓ１４−１８で「Ｙｅｓ」）、処理決定部３２は、次の処理を実行する。すなわち、処理決定部３２は、Ｓ１４−１４，Ｓ１４−１６、またはＳ１４−１７で選択された配信ノードのグループに属する全ての配信ノードの負荷量がその閾値を超えているか否かを判定する（Ｓ１４−１９）。その選択された配信ノードの属するグループの全てが配信ノードの負荷量がその閾値を超えていると判定された場合（Ｓ１４−１９で「Ｙｅｓ」）、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、ノードグループテーブル５２を参照して、当該グループに隣接する他のグループを選択し（Ｓ１４−２０）、Ｓ１４−１３の処理へ戻る。

その選択された配信ノードの属するグループの全てが配信ノードの負荷量がその閾値を超えていないと判定された場合（Ｓ１４−１９で「Ｎｏ」）、処理決定部３２は、Ｓ１４−１３の処理へ戻る。

Ｓ１４−１８において、配信ノードの負荷量がその閾値を超えていないと判定された場合（Ｓ１４−１８で「Ｎｏ」）、処理決定部３２は、選択したNode番号（Node4）、ユーザID（User2）、データ種別（D1）を収容管理テーブル３８に追加する（Ｓ１４−２１）。

処理決定部３２は、ノード状態テーブル３５において、Ｓ１４−１４、Ｓ１４−１６またはＳ１４−１７で選択したNode番号（Node4）に対応するエントリの負荷量を、所定値分、増やす（Ｓ１９）。増やす値は、「負荷量」がCopy回数の場合には、Node番号（Node4）に対応するエントリの負荷量に「＋１」だけ増やす。

本実施形態によれば、制御ノードは、複数の配信ノードのうち、配信要求をした情報処理装置の近隣にある一の配信ノードのグループに属する配信ノードから、その情報処理装置に実際に配信する配信ノードを選択する。また、同じデータ種別を要求している情報処理端末に送信している配信ノードから優先的に選択することができるので、無駄なフィルタ処理を行わなくてよい。

＜第４の実施形態＞
第１の実施形態では、コピー回数等の制御ノード側で把握できる情報に基づいて、負荷判断をしていた。それに対して、本実施形態では、各配信ノードから負荷情報を収集して、その情報をノードの状態として反映させることについて説明する。これにより、より正確な負荷情報に基づく処理が可能になる。なお、第４の実施形態において、第１〜第３の実施形態と同様な構成については、同一の符号を付し、その説明を省略する。

図３３は、第４の実施形態における制御ノード及び配信ノードの構成ブロックを示す。第４の実施形態の配信システム２０は、第１の実施形態の制御ノード２２に負荷状態更新部５３を追加し、配信ノード２３に負荷状態収集部５４を追加したものである。

負荷状態収集部５４は、配信ノード側のリソースを監視して制御ノード側に定期的にその監視結果を通知する。
負荷状態更新部５３は、配信ノードから通知された監視結果を受け取り、ノード状態テーブル３７を更新する。例えば配信ノードにより配信ノードのＣＰＵ負荷が監視される場合は、ノード状態テーブル３７のエントリ内容をＣＰＵの利用率にすればよい。

図３４は、第４の実施形態におけるノード状態テーブルの構成例を示す。ノード状態テーブル３７ｃは、「ノード」３７−１、「許容ＣＰＵ利用率」３７ｃ−２、「現ＣＰＵ利用率」３７ｃ−３のデータ項目を含む。「許容ＣＰＵ利用率」３７ｃ−２には、配信ノードの許容ＣＰＵ利用率が格納される。「現ＣＰＵ利用率」３７ｃ−３には、配信ノードから逐次送信されたその配信ノードのＣＰＵ利用率が格納される。

図３５は、第４の実施形態における負荷状態収集部５４の処理フローを示す。負荷状態収集部５４は、配信ノード２３側のリソース（ＣＰＵ利用率）を監視して、配信ノード２３の負荷情報を収集する（Ｓ５１）。負荷状態収集部５４は、収集した負荷情報（ノードの識別情報、ＣＰＵ利用率）を制御ノード２２へ送信する（Ｓ５２）。負荷状態収集部５４は、随時、Ｓ５１，Ｓ５２の処理を繰り返す。

図３６は、第４の実施形態における負荷状態更新部５３の処理フローを示す。負荷状態更新部５３は、配信ノード２３から送信された負荷情報を受信する（Ｓ６１）。負荷状態更新部５３は、その受信した負荷情報を用いて、ノード状態テーブル３７ｃの「現ＣＰＵリオ用率」３７ｃ−３の値を更新する。

図３７は、第４の実施形態における制御ノードの全体フロー例を示す。図３７は、図１４のフローからＳ１９の処理を削除したものなので、その説明を省略する。
図３８は、第４の実施形態における制御のノードの配信ノード決定処理（Ｓ１４）のフローを示す。図３８は、図１５のフローにおいて、Ｓ１４−２をＳ１４−２ａに置き換え、Ｓ１４−５の処理を削除したものである。

Ｓ１４−２ａにおいて、処理決定部３２は、ノード状態テーブル３７ｃを参照し、ユーザ購読情報に含まれるノード（Node4）の負荷量（現ＣＰＵ利用率）が予め設定した閾値を超えているか否かを判定する（Ｓ１４−２）。ここで、予め設定した閾値とは、ノード状態テーブル３７ｃの「許容ＣＰＵ利用率」に設定した値をいう。これ以降は、図１５と同様なので、その説明を省略する。

本実施形態によれば、制御ノードは、配信ノードの負荷量の判断処理において、配信ノードのＣＰＵ負荷状態を用いることができる。
なお、第４の実施形態では、監視の対象が配信ノードのＣＰＵ負荷であったが、これに限定されず、例えば、メモリの利用量など、リソースとして把握できる数値データであってもよい。

＜第５の実施形態＞
第５の実施形態では、ユーザ端末に実際に配信する配信ノードを見直す処理の説明をする。なお、第５の実施形態において、第１〜第４の実施形態と同様な構成については、同一の符号を付し、その説明を省略する。

図３９は、第５の実施形態の適用前の配信状態を説明する図である。図３９に示すように、配信ノード２３−１〜２３−６が配置されている。ユーザからの購読依頼を契機に、既に配信中のユーザに対する配信経路を変えずに、配信ノードの追加・削除を繰り返していくとする。すると、最適な配信ノードとは異なる配信ノードから、データ種別が配信されてしまう可能性がある。ここで、最適な配信ノードとは異なる配信ノードからデータ種別が配信されてしまう可能性とは、例えば１つのデータ種別だけが欲しいユーザＵ４，Ｕ５，Ｕ６と全データ種別が欲しいユーザＵ１，Ｕ２，Ｕ３が均等に全配信ノードに収容されている場合に起こりうる。この場合、図３９に示すように、全データ種別が欲しいユーザＵ１、Ｕ２，Ｕ３に引きずられて、配信ノード２３−１〜２３−６間の全ての通信において全データ種別を配信することになってしまう。

このような状態に陥った場合に、制御ノード２２は、最適な配信ノードから配信し直すように配信ノードの配信形態を見直す処理を実行する。例えば、ユーザから購読依頼を２０回受け取ると、１回配信ノードの配信形態を見直すような処理が考えられる。また、時刻の経過に応じて、例えば１時間ごとに定期的に配信ノードの配信形態を見直しても良い。

図４０は、第５の実施形態の適用後の配信状態を説明する図である。同一グループに所属するユーザ端末であれば、どの配信ノードからデータ種別を渡されても問題ないため、最適な配信ノードから配信されるように配信ノードの配信形態を設計する。例えば、上流のノードほど多いデータ種別を中継し、端末のノードほど少ないデータ種別を中継するようにする。

そこで、第５の実施形態では、図４１に示すように、第３の実施形態における同一グループの、より上流にあるノードから順に、より多いデータ種別が欲しいと希望するユーザを割当てるようなアルゴリズムを用いる。

第５の実施形態のシステム構成は、第３の実施形態（図２９）と同様である。また配信ノードのフローチャートのうち、第３の実施形態に追加された処理を図４１に示す。
図４１は、第５の実施形態における見直し処理のフローを示す。処理決定部３２は、ノードグループテーブル５２からいずれかのグループを選択する（Ｓ７１）。

処理決定部３２は、本フローの処理による見直し処理がまだされていないために配信ノード未決定で、かつユーザ情報テーブル３４から購読依頼情報の種別の多いユーザを選択する（Ｓ７２）。

処理決定部３２は、配信木のうち、負荷に余裕がある最上位ノードを配信元として選択する（Ｓ７３）。ここでは、処理決定部３２は、Ｓ７２で選択したユーザをキーとして、収納管理テーブル３８からそのユーザに対応する「収納ノード」を取得する。処理決定部３２は、ノード間接続テーブル３５を参照して、その取得した収納ノードの最上位のノートを検索する。処理決定部３２は、ノード状態テーブルを参照して、その最上位のノードの負荷量が予め設定された閾値を超えていないか判定する。ここで、予め設定した閾値とは、ノード状態テーブル３７の「許容処理量」に設定した値をいう。その最上位のノードの負荷量が予め設定された閾値を超えていないと判定した場合、処理決定部３２は、その最上位のノードを、Ｓ７２で選択したユーザに実際に配信する配信ノードとして選択する。

次に、処理決定部３２は、データ種別追加処理を行う（Ｓ７４）。Ｓ７４のデータ種別追加処理は、図１６で説明したＳ１５の処理と同様である。
処理決定部３２は、ユーザ情報テーブル３４に登録されたユーザのうち、Ｓ７１で選択したグループに属する全てのユーザについて、配信元が決定したか否かを判定する（Ｓ７５）。ユーザ情報テーブル３４に登録されたユーザのうち、Ｓ７１で選択したグループに属する全てのユーザについて配信元が決定していない場合（Ｓ７５で「Ｎｏ」）、処理決定部３２は、Ｓ７２の処理へ戻る。ユーザ情報テーブル３４に登録されたユーザのうち、Ｓ７１で選択したグループに属する全てのユーザについて、配信元が決定している場合（Ｓ７５で「Ｙｅｓ」）、処理決定部３２は、全グループに対して、Ｓ７１〜Ｓ７５の処理を行う。

第５の実施形態によれば、制御ノードは、配信ノード間のトポロジーを変更せずに、どのノードからどのユーザ端末にデータ種別を配信するかということを制御することで、配信システム全体で、ユーザの収容状態の見直しを行うことができる。このように、配信ノードの配信形態の再設定を行うことにより、ネットワーク上を流れるデータ量をより削減することが可能となる。

＜第６の実施形態＞
第５の実施形態では、ユーザ端末に実際に配信する配信ノードを見直すことはできるが、配信木自体の見直しについては行っていない。しかしながら、物理ネットワークの構成を考慮すると、購読するデータ種別が多いユーザが配信木の端末に固まっている場合、その配信ノードを配信木のルートにした方がネットワーク上を流れるトラフィックを削減できることになる。

そこで、第６の実施形態では、配信ノード間の論理トポロジーを見直す処理の説明をする。第６の実施形態のシステム構成は、第５の実施形態と同様である。なお、第６の実施形態において、第１〜第５の実施形態と同様な構成については、同一の符号を付し、その説明を省略する。

図４２は、第６の実施形態における配信ノード間の論理トポロジーを見直す処理フローを示す。図４２のフローは、図４１のフローに、配信木見直し処理（Ｓ８１）を追加したものである。図４２では、第５の実施形態における定期的な見直し処理の最初に、購読希望のデータ種別が多いユーザに物理的に近い配信ノードを配信木のルートとして、グループ内の配信木を見直す処理が追加されている。配信木見直し処理（Ｓ８１）の詳細については、図４３で説明する。

図４３は、第６の実施形態における配信木見直し処理（Ｓ８１）の詳細フローを示す。処理決定部３２は、ユーザ情報テーブル３４及び収容管理テーブル３８を参照して、購入しているデータ種別が最も多いエントリを抽出し、そのエントリを「収容ノード」３８−４毎にカウントする（Ｓ８１−１）。

次に、処理決定部３２は、上記カウントの結果、カウント数が最も多い「収容ノード」３８−４に格納されたノードを配信木のルートとして選択する（Ｓ８１−２）。
処理決定部３２は、その選択したノードをルートとして配信木を作成する（Ｓ８１−３）。その選択したノードをルートとして配信木を作成する場合、処理決定部３２は、例えば、マルチキャストルーティングプロトコル等を用いて、配信木（ディストリビューションツリー）の構築方法を用いてもよい。一例として、処理決定部３２は、その選択したノードをランデブーポイントとして、配信木を作成してもよい。ランデブーポイントとは、複数のマルチキャストグループがあってもひとつのディストリビューションツリーを共有して、マルチキャストデータのルーティングを行う場合の、ツリーを共有するために中心となる中継装置である。

本実施形態によれば、配信ノード間の論理トポロジーを見直して、配信要求されたデータ種別が多いユーザに配信している配信ノードを配信木のルートにすることができるので、ネットワーク上を流れるトラフィックを削減できる。

＜第７の実施形態＞
第７の実施形態では、配信システムが大規模化したときの対応を対象に説明する。なお、第７の実施形態において、第１〜第６の実施形態と同様な構成については、同一の符号を付し、その説明を省略する。

図４４は、第７の実施形態における制御ノード及び配信ノードの構成ブロックを示す。第７の実施形態の配信システム２０は、第１の実施形態の制御ノード２２において、制御ノード連携部５５、制御ノード・配信ノード管理テーブル５６を追加したものである。

配信ノード数が多数になり、単一の制御ノード２２だけでは制御できなくなった場合、制御ノードを複数台並べ、それらの制御ノードが並列して制御を行う。この場合、各制御ノードは、自身が管理する配信ノードを格納した制御ノード・配信ノード管理テーブル５６を有する。これにより、各制御ノード２２は、制御ノード・配信ノード管理テーブル５６に基づいて、自身が管理する複数の配信ノードを１つのドメイン（同一制御ノード配下の配信ノードグループ）として扱い、そのドメイン単位に配信制御を行う。

ユーザは、ユーザ端末２５を用いて、ユーザ端末２５自身が属するネットワークを管理する制御ノードに対して購読依頼を発行する。当該制御ノードは、その制御ノード配下の配信ノードの中から、ユーザ端末２５への配信ノードを決定する。

配信経路が複数の制御ノード配下の配信ノードをまたがる場合、配信するデータ種別の調整を制御ノード間で行う必要がある。そこで、制御ノード連携部５５は、配信経路が複数の制御ノード配下の配信ノードをまたがる場合、配信するデータ種別の調整を制御ノード間で行う。

データ種別の追加・削除処理において、自身の制御ノード配下よりもさらに上位ノードの配信データを変更する必要が生じた場合に、当該制御ノード連携部５５は、他の制御ノード２２−ｎに対して配信データ種別の追加・削除の依頼を行う。

配信データ種別の追加・削除依頼を受信した制御ノード２２−ｎは、その依頼の内容に基づいてデータ種別の追加・削除の処理と、変更があった内容を管理配下の配信ノードに設定する。

図４５は、第７の実施形態における制御ノード・配信ノード管理テーブルの構成例を示す。制御ノード・配信ノード管理テーブル５６は、「制御ノード」５６−１、「ノード」５６−２のデータ項目を含む。

「制御ノード」５６−１は、制御ノードを識別する識別情報が格納される。「ノード」５６−２は、「制御ノード」５６−１に格納された制御ノードが管理するノードを識別する識別情報が格納される。

次に、第７の実施形態における制御ノードの処理フローについて説明する。第７の実施形態の制御ノードの処理フローは、第１の実施形態の処理（図１５−図１８）において、図１６、図１７の処理を変更したものである。これについて、図４６、図４７を用いて説明する。なお、図４６、図４７は、当該制御ノード連携部５５が、他の制御ノード２２−ｎに対して配信データ種別の追加・削除の依頼を行う場合の処理である。

図４６は、第７の実施形態における制御のノードのデータ追加処理のフローを示す。図４６は、図１６のフローに、Ｓ１５−２１、Ｓ１５−２２の処理を追加したものである。なお、以下では、図１６で用いた例を用いて説明する。

処理決定部３２は、ノード間接続テーブル３５を読み出し、Ｓ１４−１またはＳ１４−３で選択したノード（収容ノード）（Node4）と、その収容ノードを接続先とする配信ノード（Node2）間のリンクを特定する。それから、処理決定部３２は、リンク管理テーブル３９を用いて、そのリンクに関して、ユーザ購読情報に含まれるデータ種別（D1）が届くようになっているか確認する。

具体的には、処理決定部３２は、ノード間接続テーブル３５において、「To」＝Ｓ１４で決定したノード（Node4）のエントリを検索する。処理決定部３２は、その検索されたエントリの「リンク」に格納されているリンクの識別情報（L3）、及び「From」に格納されているノードの識別情報（Node2）を取得する。処理決定部３２は、リンク管理テーブル３９から、取得したリンクの識別情報（L3）を含むエントリを取得する。処理決定部３２は、その取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）が格納されているか確認する（Ｓ１５−１）。その取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）が格納されている場合（Ｓ１５−１で「Ｎｏ」）、D1がNode4へ届くことになるので、本フローは終了する。

リンク管理テーブル３９から取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）が格納されていない場合（Ｓ１５−１で「Ｙｅｓ」）、D1が収容ノード（Node4）へ届かないので、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、リンク管理テーブル３９から取得したエントリの「データ種別」に、ユーザ購読情報に含まれるデータ種別（D1）を格納する（Ｓ１５−２）。それから、処理決定部３２は、センサー２４に近いノードから順にD1が配信されるように、ノード間接続テーブル３５から、収容ノード（Node4）の上位ノード（リンクの接続元）を検索する（Ｓ１５−３）。

処理決定部３２は、制御ノード・配信ノード管理テーブル５６を参照して、Ｓ１５−３で検索したノードが当該制御ノードの管理下にある配信ノードであるかを判定する（Ｓ１５−２１）。

Ｓ１５−３で検索したノードが当該制御ノードの管理下にある配信ノードである場合（Ｓ１５−２１で「Ｎｏ」）、処理決定部３２は、Ｓ１５−１の処理に戻る。
Ｓ１５−３で検索したノードが当該制御ノードの管理下にある配信ノードでない場合（Ｓ１５−２１で「Ｙｅｓ」）、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、制御ノード・配信ノード管理テーブル５６を参照して、その検索されたノードを管理する制御ノードを特定する。処理決定部３２は、制御ノード連携部５５に、その特定した制御ノードに対してリンク管理テーブル３９にデータ種別を追加するように依頼する（データ種別追加依頼）（Ｓ１５−２２）。

図４７は、第７の実施形態における制御のノードのデータ削除処理のフローを示す。図４７は、図１７のフローに、Ｓ２０−２１、Ｓ２０−２２の処理を追加したものである。なお、以下では、図１６で用いた例を用いて説明する。

処理決定部３２は、収容管理テーブル３８から、購読解除情報に含まれるユーザＩＤと一致するユーザＩＤを有するエントリを検索し、そのエントリのデータ項目「収容ノード」に格納されたノードの識別情報を取得する。処理決定部３２は、ノード間接続テーブル３５において、「To」＝その取得したノード「Node4」のエントリを検索する。処理決定部３２は、その検索されたエントリの「リンク」に格納されているリンクの識別情報（L3）、及び「From」に格納されているノードの識別情報（Node2）を取得する。処理決定部３２は、リンク管理テーブル３９から、取得したリンクの識別情報（L3）を含むエントリのデータ種別に「D1」が含まれている場合には、Ｄ１を削除する（Ｓ２０−１で「Ｙｅｓ」、Ｓ２０−２）。

処理決定部３２は、ノード間接続テーブル３５を参照し、購読解除情報に含まれるノード「Node4」の上位ノード（リンクの接続元）を検索する（Ｓ２０−３）。
処理決定部３２は、制御ノード・配信ノード管理テーブル５６を参照して、Ｓ２０−３で検索したノードが当該制御ノードの管理下にある配信ノードであるかを判定する（Ｓ２０−２１）。

Ｓ２０−３で検索したノードが当該制御ノードの管理下にある配信ノードである場合（Ｓ２０−２１で「Ｎｏ」）、処理決定部３２は、Ｓ２０−１の処理に戻る。
Ｓ２０−３で検索したノードが当該制御ノードの管理下にある配信ノードでない場合（Ｓ２０−２１で「Ｙｅｓ」）、処理決定部３２は、次の処理を行う。すなわち、処理決定部３２は、制御ノード・配信ノード管理テーブル５６を参照して、その検索されたノードを管理する制御ノードを特定する。制御ノード連携部５５は、その特定した制御ノードに対してリンク管理テーブル３９にデータ種別を削除するように依頼する（データ種別削除依頼）（Ｓ２０−２２）。

次に、制御ノード連携部５５から送信された、データ種別の追加・削除依頼を受信した制御ノード２２−ｎ側で行われる処理について説明する。
図４８は、第７の実施形態における複数の制御ノード間のデータ追加のフローを示す。制御ノード２２−ｎの制御ノード連携部５５は、制御ノード２２の制御ノード連携部５５から送信された、データ種別追加依頼を受信する（Ｓ９１）。

制御ノード２２−ｎの処理決定部３２は、データ種別追加処理を行う（Ｓ９２）。データ種別追加処理（Ｓ９２）は、図１４のＳ１５の処理と同様である。データ種別追加処理（Ｓ１５）では、ユーザの必要とするデータ種別がＳ１５−３で選択された配信ノードまで配信されるように、リンク管理テーブル３９に、データ種別を追加する。その後、制御ノード２２−ｎの処理決定部３２は、データ種別の配信定義情報を配布するように、制御ノード２２−ｎの定義配布部３３に依頼する。

制御ノード２２−ｎの定義配布部３３は、処理決定部３２からの配布依頼を受けて、制御ノード・配信ノード管理テーブル５６を参照して、自身の管理する各配信ノード２３に、配信定義情報を配布する（Ｓ９３）。配信定義配布処理（Ｓ９３）は、図１４のＳ１６の処理と同様である。

図４９は、第７の実施形態における複数の制御ノード間のデータ削除のフローを示す。制御ノード２２−ｎの制御ノード連携部５５は、制御ノード２２の制御ノード連携部５５から送信された、データ種別削除依頼を受信する（Ｓ１０１）。

制御ノード２２−ｎの処理決定部３２は、データ種別削除処理を行う（Ｓ１０２）。データ種別追加処理（Ｓ１０２）は、図１４のＳ１５の処理と同様である。データ種別削除処理（Ｓ１０２）では、購読解除したデータ種別が、購読解除したユーザ端末２５に実際に配信する配信ノードまで不必要に配信されないように、リンク管理テーブル３９からデータ種別を削除する。その後、処理決定部３２は、データ種別の配信定義情報を配布するように、定義配布部３３に依頼する。

定義配布部３３は、処理決定部３２からの配布依頼を受けて、各配信ノード２３に、配信定義情報を配布する（Ｓ１０３）。配信定義配布処理（Ｓ１０３）は、図１４のＳ１６の処理と同様である。

本実施形態によれば、制御ノード間で、各制御ノードは、ユーザからの購読依頼／購読解除依頼のあったデータ種別を配信可能／配信停止可能なノードがその制御ノードの配下ではない場合は、他の制御ノードに対して変更内容を伝え合うことができる。したがって、配信ノードをドメインに分離し、制御ノードを並列に動作可能にすることで、システムが大規模化した場合にもデータの配信が可能となる。

第１〜７の実施形態によれば、予め配送先で必要なデータ種別を各ノードに設定しておき、各ノードがデータを受信するとその設定情報に基づいて配送先で必要なデータ種別のみを転送することにより、配信ノード間で転送するデータ量を削減できる。

図５０は、コンピュータのハードウェア環境の構成ブロック図である。コンピュータ６０は、サーバ２１、制御ノード２２、配信ノード２３、またはユーザ端末２５である。コンピュータ６０は、ＣＰＵ６２、ＲＯＭ６３、ＲＡＭ６６、通信Ｉ／Ｆ６４、記憶装置６７、出力Ｉ／Ｆ６１、入力Ｉ／Ｆ６５、読み取り装置６８、バス６９、出力機器７１、入力機器７２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス６９には、ＣＰＵ６２、ＲＯＭ６３、ＲＡＭ６６、通信Ｉ／Ｆ６４、記憶装置６７、出力Ｉ／Ｆ６１、入力Ｉ／Ｆ６５、及び読み取り装置６８が接続されている。読み取り装置６８は、可搬型記録媒体を読み出す装置である。出力機器７１は、出力Ｉ／Ｆ６１に接続されている。入力機器７２は、入力Ｉ／Ｆ６５に接続にされている。

記憶装置６７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。コンピュータ６０が制御ノード２２の場合、記憶装置６７またはＲＯＭ６３には、制御ノード２２全体の動作を制御するプログラム及び本実施形態に係るプログラムが格納されている。ＣＰＵ６２は、記憶装置６７またはＲＯＭ６３から本実施形態に係るプログラムを読み込むことにより、購読制御部３１、処理決定部３２、定義配信部３３、負荷状態更新部５３、制御ノード連携部５５として機能する。

また、コンピュータ６０が制御ノード２２の場合、記憶装置６７またはＲＯＭ６３は、ユーザ情報テーブル３４、ノード間接続テーブル３５、センサー情報テーブル３６、ノード状態テーブル３７、収容管理テーブル３８、リンク管理テーブル３９を含む。また、記憶装置６７またはＲＯＭ６３は、配信時刻管理テーブル５１、ノードグループテーブル５２、制御ノード・配信ノード管理テーブル５６を含む。

コンピュータ６０が配信ノード２３の場合、記憶装置６７またはＲＯＭ６３には、配信ノード２３全体の動作を制御するプログラム及び本実施形態に係るプログラムが格納されている。ＣＰＵ６２は、記憶装置６７またはＲＯＭ６３から本実施形態に係るプログラムを読み込むことにより、受信処理部４１、トピック識別部４２、宛先決定部４３、コピー処理部４４、フィルタ処理部４５、送信処理部４６、定義設定部４７として機能する。ＣＰＵ６２は、記憶装置６７またはＲＯＭ６３から本実施形態に係るプログラムを読み込むことにより、さらに、負荷状態収集部５４として機能する。

また、コンピュータ６０が配信ノード２３の場合、記憶装置６７またはＲＯＭ６３は、中継定義テーブル４８、処理定義テーブル４９を含む。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク７０、および通信Ｉ／Ｆ６４を介して、例えば記憶装置６７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置６８にセットされて、ＣＰＵ６２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置６８によって読み取られる。

また、入力機器７２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサー、タブレットなどを用いることが可能である。また、出力機器７１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク７０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

上記実施形態に関し、更に以下の付記を開示する。
（付記１）
複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムにおいて、
前記制御ノードは、
前記配信ノード間の接続状態を示す接続情報と、前記配信ノードにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別と、を決定する決定部と、
決定した前記配信先の配信ノードを特定するノード情報と、決定した前記データの種別を特定する種別情報とを、配信ノードに配布する配布部とを、備え、
前記配信ノードは、
前記制御ノードから配布された前記ノード情報と前記種別情報とを受信する受信部と、
他の配信ノードから配信されたデータを受信した場合には、受信したデータから前記種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信する送信部、
を備える配信システム。
（付記２）
前記制御ノードは、さらに、
いずれかの種別のデータ配信を要求する配信要求を、情報処理端末から受信する要求受信部を備え、
前記決定部は、前記配信要求を受信した場合、前記情報処理端末に対して配信可能な配信ノードの中から、前記負荷情報に応じて、該情報処理端末にデータを配信する端末配信ノードを決定する、
ことを特徴とする付記１に記載の配信システム。
（付記３）
前記決定部は、前記配信ノードがグループに分類されている場合、配信ノードとグループとを関係付けたノードグループ情報から、予め前記情報処理端末に配信する配信ノードとして設定された該配信ノードが属するグループに属する配信ノードを抽出し、抽出した該配信ノードの中から前記端末配信ノードを決定する
ことを特徴とする付記２に記載の配信システム。
（付記４）
前記決定部は、前記配信ノードのうち、前記配信要求の対象の種別のデータを送信または受信する配信ノードを前記端末配信ノードとして選択する
ことを特徴とする付記２に記載の配信システム。
（付記５）
前記決定部は、前記配信ノードが受信したデータを複製した複製回数を前記負荷情報として計測し、前記複製回数に応じて、前記情報処理端末に対して配信可能な配信ノードの中から、前記端末配信ノードを決定する
ことを特徴とする付記２に記載の配信システム。
（付記６）
前記配信ノードは、さらに、
前記配信ノードに設けられた演算装置の利用率を検出して、該検出した演算装置の利用率を前記制御ノードへ送信する負荷情報通知部を備え、
前記制御ノードは、さらに、
前記配信ノードから受信した前記演算装置の利用率を用いて、前記負荷情報を更新する負荷情報更新部と、
を備えることを特徴とする付記１に記載の配信システム。
（付記７）
前記決定部は、前記配信先のノード情報と前記データの種別を特定する種別情報との配布後に、前記配信要求がされて決定した配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別とを取得し、
前記配布部は、取得された前記配信先の配信ノードを特定するノード情報と、取得された前記データの種別を特定する種別情報とを、前記配信ノードに配布する
ことを特徴とする付記１に記載の配信システム。
（付記８）
前記決定部は、受信された前記配信要求に含まれるデータ種別が多い配信要求を送信した情報処理端末に対する端末配信ノードを、データを配信するための配信経路であって木構造で表される配信木における最上位の配信ノードに決定する
ことを特徴とする付記２に記載の配信システム。
（付記９）
前記決定部は、受信された前記配信要求のうち最も多くのデータ種別を含む配信要求の数を前記端末配信ノード毎に計測し、該配信要求数が最も多く計測された端末配信ノードを、データを配信するための配信経路であって木構造で表される配信木のルートとして決定する
ことを特徴とする付記２に記載の配信システム。
（付記１０）
前記制御ノードは、さらに、
前記制御ノードが複数存在し、各制御ノードの配下に複数の配信ノードが存在する場合、他の制御ノードとの間で通信を行う通信部を備え、
いずれかの制御ノードが前記配信要求を受信した場合、前記配信要求を受信した制御ノードの決定部は、前記複数の配信ノード間の接続情報と、前記複数の配信ノードそれぞれにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードを選択し、各制御ノードの配下の配信ノードを特定する情報に基づいて、選択した配信ノードがいずれの制御ノードの配下の配信ノードであるかを判定し、
前記通信部は、前記選択した配信ノードがいずれの制御ノード配下の配信ノードでもないと判定された場合、他の制御ノード配下の配信ノードのいずれかから、前記配信要求をした情報処理装置に対する端末配信ノードへ前記配信要求の対象の種別のデータを送るように、前記他の制御ノードに通知する
ことを特徴とする付記２に記載の配信システム。
（付記１１）
複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムの配信方法において、
前記制御ノードは、
前記配信ノード間の接続状態を示す接続情報と、前記配信ノードにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別と、を決定し、
決定した前記配信先の配信ノードを特定するノード情報と、決定した前記データの種別を特定する種別情報とを、配信ノードに配布し、
前記配信ノードは、
前記制御ノードから配布された前記ノード情報と前記種別情報とを受信し、
他の配信ノードから配信されたデータを受信した場合には、受信したデータから前記種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信する、
ことを特徴とする配信方法。
（付記１２）
前記制御ノードは、さらに、
いずれかの種別のデータ配信を要求する配信要求を、情報処理端末から受信し、
前記配信要求を受信した場合、前記情報処理端末に対して配信可能な配信ノードの中から、前記負荷情報に応じて、該情報処理端末にデータを配信する端末配信ノードを決定する（Ｓ１４）、
ことを特徴とする付記１１に記載の配信方法。
（付記１３）
前記制御ノードは、前記配信ノードがグループに分類されている場合、配信ノードとグループとを関係付けたノードグループ情報から、予め前記情報処理端末に配信する配信ノードとして設定された該配信ノードが属するグループに属する配信ノードを抽出し、抽出した該配信ノードの中から前記端末配信ノードを決定する
ことを特徴とする付記１２に記載の配信方法。
（付記１４）
前記制御ノードは、前記配信ノードのうち、前記配信要求の対象の種別のデータを送信または受信する配信ノードを前記端末配信ノードとして選択する
ことを特徴とする付記１２に記載の配信方法。
（付記１５）
前記制御ノードは、前記配信ノードが受信したデータを、該配信ノードが複製した複製回数を前記負荷情報として計測し、前記複製回数に応じて、前記情報処理端末に対して配信可能な配信ノードの中から、前記端末配信ノードを決定する
ことを特徴とする付記１２に記載の配信方法。
（付記１６）
複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムの前記制御ノードに実行させる配信プログラムにおいて、
前記制御ノードに、
前記配信ノード間の接続状態を示す接続情報と、前記配信ノードにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別と、を決定し、
決定した前記配信先の配信ノードを特定するノード情報と、決定した前記データの種別を特定する種別情報とを、配信ノードに配布する
処理を実行させる配信プログラム。
（付記１７）
複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムの前記配信ノードに実行させる配信プログラムにおいて、
前記配信ノードに、
前記制御ノードから配布された配信先の配信ノードを特定するノード情報と、該配信先の配信ノードに配信するデータの種別を特定する種別情報とを受信し、
他の配信ノードから配信されたデータを受信した場合には、受信したデータから前記種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信する
処理を実行させる配信プログラム。
（付記１８）
前記制御ノードに、さらに、
いずれかの種別のデータ配信を要求する配信要求を、情報処理端末から受信し、
前記配信要求を受信した場合、前記情報処理端末に対して配信可能な配信ノードの中から、前記負荷情報に応じて、該情報処理端末に配信する端末配信ノードを決定する、
処理を実行させる付記１６に記載の配信プログラム。
（付記１９）
前記制御ノードは、
前記配信ノードがグループに分類されている場合、配信ノードとグループとを関係付けたノードグループ情報から、予め前記情報処理端末に配信する配信ノードとして設定された該配信ノードが属するグループに属する配信ノードを抽出し、抽出した該配信ノードの中から前記端末配信ノードを決定する
ことを特徴とする付記１８に記載の配信プログラム。

１ 配信システム
２ 制御ノード
３ 決定部
４ 配布部
５ 要求受信部
６ 通信部
７，７ａ，７ｂ 配信ノード
８ 受信部
９ 送信部
１０ 負荷情報通知部
１１ 負荷情報更新部
１２ 情報処理端末
１３ ネットワーク
２０ 配信システム
２１ サーバ
２２ 制御ノード
２３ 配信ノード
２４ センサー
３１ 購読制御部
３２ 処理決定部
３３ 定義配布部
３４ ユーザ情報テーブル
３５ ノード間接続テーブル
３６ センサー情報テーブル
３７ ノード状態テーブル
３８ 収容管理テーブル
３９ リンク管理テーブル
４１ 受信処理部
４２ トピック識別部
４３ 宛先決定部
４４ コピー処理部
４５ フィルタ処理部
４６ 送信処理部
４７ 定義設定部
４８ 中継定義テーブル
４９ 処理定義テーブル
５１ 配信時刻管理
５２ ノードグループテーブル
５３ 負荷状態更新部
５４ 負荷状態収集部
５５ 制御ノード連携部５５
５６ 制御ノード・配信ノード管理テーブル５６

Claims (7)

1. 複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムにおいて、
   前記制御ノードは、
   前記配信ノード間の接続状態を示す接続情報と、前記配信ノードにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別と、を決定する決定部と、
   決定した前記配信先の配信ノードを特定するノード情報と、決定した前記データの種別を特定する種別情報とを、配信ノードに配布する配布部とを、備え、
   前記配信ノードは、
   前記制御ノードから配布された前記ノード情報と前記種別情報とを受信する受信部と、
   他の配信ノードから配信されたデータを受信した場合には、受信したデータから前記種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信する送信部、
   を備える配信システム。
2. 前記制御ノードは、さらに、
   いずれかの種別のデータ配信を要求する配信要求を、情報処理端末から受信する要求受信部を備え、
   前記決定部は、前記配信要求を受信した場合、前記情報処理端末に対して配信可能な配信ノードの中から、前記負荷情報に応じて、該情報処理端末にデータを配信する端末配信ノードを決定する、
   ことを特徴とする請求項１に記載の配信システム。
3. 前記決定部は、前記配信ノードがグループに分類されている場合、配信ノードとグループとを関係付けたノードグループ情報から、予め前記情報処理端末に配信する配信ノードとして設定された該配信ノードが属するグループに属する配信ノードを抽出し、抽出した該配信ノードの中から前記端末配信ノードを決定する
   ことを特徴とする請求項２に記載の配信システム。
4. 前記決定部は、前記配信ノードのうち、前記配信要求の対象の種別のデータを送信または受信する配信ノードを前記端末配信ノードとして選択する
   ことを特徴とする請求項２に記載の配信システム。
5. 前記決定部は、前記配信ノードが受信したデータを複製した複製回数を前記負荷情報として計測し、前記複製回数に応じて、前記情報処理端末に対して配信可能な配信ノードの中から、前記端末配信ノードを決定する
   ことを特徴とする請求項２に記載の配信システム。
6. 複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムの配信方法において、
   前記制御ノードは、
   前記配信ノード間の接続状態を示す接続情報と、前記配信ノードにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別と、を決定し、
   決定した前記配信先の配信ノードを特定するノード情報と、決定した前記データの種別を特定する種別情報とを、配信ノードに配布し、
   前記配信ノードは、
   前記制御ノードから配布された前記ノード情報と前記種別情報とを受信し、
   他の配信ノードから配信されたデータを受信した場合には、受信したデータから前記種別情報が特定する種別のデータを選択し、選択した種別のデータを前記ノード情報が特定する配信ノードに送信する、
   ことを特徴とする配信方法。
7. 複数の配信ノードと、制御ノードとがネットワークを介して接続される配信システムの前記制御ノードに実行させる配信プログラムにおいて、
   前記制御ノードに、
   前記配信ノード間の接続状態を示す接続情報と、前記配信ノードにおける負荷情報とに基づいて、前記複数の配信ノードのうち一の配信ノードが次にデータを配信する配信先の配信ノードと、該配信先の配信ノードに配信するデータの種別と、を決定し、
   決定した前記配信先の配信ノードを特定するノード情報と、決定した前記データの種別を特定する種別情報とを、配信ノードに配布する
   処理を実行させる配信プログラム。