JP6101622B2 - 情報配信システム及び情報配信方法 - Google Patents

Description

この発明は、多数の機器が接続されたネットワークにおいて、パブリッシャ（publisher）が送信したメッセージをサブスクライバ（subscriber）へ届けるサービスを提供する情報配信システム及びこのシステムで用いられる情報配信方法に関する。

多数の機器が接続されたネットワークにおいて、各機器がトピックと呼ばれる論理的なチャネルを指定することで非同期的に通信を行なう形態は「トピックベースpub/sub」と呼ばれる。トピックベースpub/subを構成する機器群は、パブリッシャ及びサブスクライバという２種類の役割のいずれか（または両方）を担う。トピックベースpub/sub とは、パブリッシャがトピックを指定してメッセージを送信すると、同じトピックを指定して事前に受信登録しているサブスクライバに届く仕組みである。

トピックベースpub/subにおいては、パブリッシャが送信したメッセージに付与されているトピックと、サブスクライバによって受信登録されているトピックとのマッチングを行い、メッセージを適切に配送する仕組みが必要となる。一般的には、パブリッシャやサブスクライバとなる機器群の他に単一のサーバを用意し、サーバが上記の処理を行う。しかしながら、サーバに負荷が集中し、スケーラビリティに欠けるという問題がある。

そのため、近年ではサーバを用いずに、パブリッシャやサブスクライバとなる機器群の協調動作によってトピックのマッチングとメッセージの配送を実現する分散トピックベースpub/subが注目されている。分散トピックベースpub/subでは、各機器が他の機器との間に論理的なリンクを張ってオーバレイネットワークを形成する。送信されたメッセージは、オーバレイネットワーク上のノード（機器）間で転送を繰り返してサブスクライバであるノードへと届けられる。

分散トピックベースpub/subでは、系全体の情報（トピックが何種類存在し、それぞれのサブスクライバは誰なのか、等）を持つサーバを置く必要がなく、各ノードが系全体の情報の一部のみを少しずつ分担して保持する。そのため、スケーラビリティに優れる。

分散トピックベースpub/subを実現するため、従来は分散ハッシュテーブル（ＤＨＴ）を用いたScribeという手法が使われていた。

ＤＨＴの中核となる技術は「あるノードがキーを指定して探索を行うと、そのキーのハッシュ値を担当するノードが一意に定まり、クエリが届く」という仕組み（key-based routing）である。すなわち、ＤＨＴにおいて複数のノードから同一のキーで探索を実行すると、どのノードのクエリも同一のノードへと辿り着く。そのノードを頂点として、各ノードからの探索経路を逆向きに辿ると、木構造と見做すことができる。

このことから、サブスクライバは、トピック名をキーとしてＤＨＴ上で探索を行い、探索経路上の各ノードで探索クエリの転送元を子ノード、転送先を親ノードとして記録することで、サブスクライバを葉ノードとする木構造が完成する。

パブリッシャも、トピック名をキーとして探索することで、上記木構造の根ノードを発見することができる。パブリッシャは、この根ノードのＩＰアドレスをキャッシュしておく。パブリッシャがメッセージを送信する際は、当該根ノードへメッセージを送信する。以降各ノードが子ノードへとメッセージを転送することで、全てのサブスクライバへメッセージが届く。

http://research.microsoft.com/en-us/um/people/antr/PAST/pastry.pdf http://research.microsoft.com/en-us/um/people/antr/PAST/scribe.pdf http://oceanstore.cs.berkeley.edu/publications/papers/pdf/iptps03-api.pdf

しかしながら、従来の技術には、以下に示す２つの課題が存在する。

１つ目は、配送経路長の長さである。ＤＨＴにおける探索経路の長さ（クエリが転送される回数）は、一般的に全ノード数nに対しO(logn)であるから、従来技術による分散トピックベースpub/subにおけるメッセージの配送経路長もO(logn)となる。トピックに参加しているノード数に関係なくこの配送経路長が必要となるため、例えばサブスクライバが１ノードのみのトピックであっても何回もの転送を経る必要がある。そのため、ネットワーク資源の消費及びメッセージ到達遅延の観点で望ましくない。

２つ目は、各ノードが無関係なトピックの中継を担わされる点である。トピック毎の送信頻度に差がある場合、送信頻度の高いトピックの木構造に組み込まれたノードは、自身が送信頻度の低いトピックにしか参加していなくても、高頻度にメッセージの中継を担う必要がある。例えば、「1日1回の温度情報を得るために映像ストリームの転送をし続ける」といった状況が生じ得ることになり、これは負荷配分の公平性の観点から望ましくない。

本発明は、上記事情に着目してなされたもので、その目的は、配送経路長を抑えることが可能であり、かつ、各ノードが無関係なトピックに関する情報の中継を担うことが不要な情報配信システム及びこのシステムで用いられる情報配信方法を提供することにある。

本発明は、上記目的を達成するために、以下のような手段を講じている。

本発明の第１の態様は、複数の通信機器がネットワークに接続されてなる情報配信システムにおいて、前記通信機器に含まれるノードは、トピックを識別可能なキーを生成するキー生成部と、前記キーと、他のノードから通知される前記他のノードについてのキーとを参照し、Multi-key Skip Graphにおける経路表を構築するＭＫＳＧ経路表維持管理部と、前記経路表に従い、メッセージを送信するパブリッシュ転送部とを備える。
第１の態様によれば、情報配信システムは、転送に係る通信機器数を減らすことが可能となると共に、トピック毎の配送ツリーをトピックへの参加ノードのみで構築することが可能となる。

また、第２の態様では、前記キー生成部は、前記トピックを識別可能な名称に、サブスクライバ及びパブリッシャを含むノード種別を識別可能な名称を付して前記キーを生成し、前記ＭＫＳＧ経路表維持管理部は、前記生成したキーを参照し、前記経路表において、前記サブスクライバ同士が前記トピック毎に隣接するサブスクライバゾーンと、前記パブリッシャ同士が前記トピック毎に隣接するパブリッシャゾーンとを形成する。そして、前記ノードは、前記経路表に基づき、自ノードが、前記サブスクライバゾーンと境界を接するパブリッシャであるランデブーポイントに該当するか否かを判定するランデブーポイント判定部と、自ノードが前記ランデブーポイントである場合、前記経路表に基づき、対象となるキーが割り当てられたサブスクライバの存在／不在を検出するサブスクライバ存在／不在検出部とを備える。
第２の態様によれば、情報配信システムは、各ノードが局所的な情報のみを保持する状況下において、分散pub/subが備えるべきスケーラビリティを損なわずに、トピック毎にサブスクライバの存在／不在を検出することが可能となる。

また、第３の態様では、前記ノードは、前記サブスクライバが不在の状態において、前記サブスクライバ存在／不在検出部により前記サブスクライバの存在が新たに検出される場合、パブリッシュ開始信号を前記パブリッシュゾーンへ発信し、前記サブスクライバが存在する状態において、前記サブスクライバ存在／不在検出部により前記サブスクライバの不在が新たに検出される場合、パブリッシュ停止信号を前記パブリッシュゾーンへ発信するパブリッシュ開始／停止信号転送部を備える。
第３の態様によれば、情報配信システムは、サブスクライバの不在時に、メッセージの配信を停止させることが可能となる。

また、第４の態様では、前記ノードは、パブリッシャとして新たにメッセージの配信に参加する際、自ノードの状態を、前記Multi-key Skip Graphにおいて隣接するパブリッシャの状態に従って決定するパブリッシャ初期状態判定部を備える。
第４の態様によれば、新たにメッセージ配信に参加するパブリッシャは、参加直後からメッセージの配信開始／停止に対応することが可能となる。

また、第５の態様では、前記ノードは、他のパブリッシャから配信されるメッセージを受信した際に、自ノードが前記ランデブーポイントであり、かつ、メッセージの配信を停止する状態にある場合、不整合が発生したと判断する不整合検出部と、前記不整合が検出されると、配信を停止させる旨の不整合是正信号を前記他のパブリッシャへ送信する不整合是正信号転送部とを備える。
第５の態様によれば、情報配信システムは、サブスクライバが不在にも関わらず、メッセージを配信するパブリッシャが存在する場合、このパブリッシャにメッセージの配信を停止させることが可能となる。

また、第６の態様では、前記ノードは、自ノードがメッセージの配信を停止する状態にある場合、前記Multi-key Skip Graphにおいて隣接するパブリッシャに対して動作の状態を問い合わせるパブリッシュ状態確認部と、自ノードの状態と、前記隣接するパブリッシャの状態とに齟齬がある場合、不整合が発生したと判断する不整合検出部と、自ノードが前記ランデブーポイントでない場合、第１の不整合是正信号を前記ランデブーポイントへ送信し、自ノードが前記ランデブーポイントである場合、他のパブリッシャから送信される第１の不整合是正信号に応じ、前記サブスクライバ存在／不在検出部により前記サブスクライバの存在を確認した後、メッセージの配信を開始させる旨の第２の不整合是正信号を前記パブリッシャゾーンへ送信する不整合是正信号転送部とを備える。
第６の態様によれば、情報配信システムは、サブスクライバが存在するにも関わらず、配信を停止しているパブリッシャが存在する場合、このパブリッシャにメッセージの配信を開始させることが可能となる。

すなわちこの発明によれば、配送経路長を抑えることができ、かつ、各ノードが無関係なトピックに関する情報の中継を担うことが不要な情報配信システム及び情報配信方法を提供することができる。

第１の実施形態に係る情報配信システムの構成を示す図である。 図１に示すパブリッシャの機能構成を示すブロック図である。 第１の実施形態に係るMulti-key Skip Graphを示す図である。 図３に示すMulti-key Skip Graphにおける経路表を示す図である。 第２の実施形態に係るパブリッシャの機能構成を示すブロック図である。 トピック名をキーとして用いた際のリストを示す図である。 トピック名にノード種別を識別可能な接尾辞を付したキーを利用した際のリストを示す図である。 図５に示すＭＫＳＧ経路表維持管理部により構築されるMulti-key Skip Graphを示す図である。 図５に示すＭＫＳＧ経路表維持管理部により構築されるMulti-key Skip Graphにおけるランデブーポイントを示す図である。 図５に示すパブリッシュ開始／停止信号転送部がパブリッシュ停止信号を送信することで、パブリッシャに配信を停止させる際の図である。 図５に示すパブリッシュ開始／停止信号転送部６７がパブリッシュ開始信号を送信することで、パブリッシャに配信を開始させる際の図である。 メッセージ配信に、新たなパブリッシャが参加することを示す図である。 サブスクライバの不在時にメッセージが送信される不整合を示す図である。 図１３に示す不整合に対する対応を示す図である。 サブスクライバの存在時にメッセージの送信が停止されてしまう不整合を示す図である。 図１５に示す不整合に対する対応を示す図である。 ノードがメッセージ配信に参加する際の動作を示すフローチャートである。 図１７に示すフローチャートにおいて動作する構成要素を示す図である。 サブスクライバの不在を検知し、パブリッシャによるメッセージの送信を停止する際の動作を示すシーケンス図である。 図１９に示すシーケンスにおいて動作する構成要素を示す図である。 サブスクライバの存在を検知し、パブリッシャ及びパブリッシャによるメッセージの送信を開始する際の動作を示すシーケンス図である。 図２１に示すシーケンスにおいて動作する構成要素を示す図である。 サブスクライバ不在時の不整合を解消する際の動作を示すシーケンス図である。 図２３に示すシーケンスにおいて動作する構成要素を示す図である。 サブスクライバ存在時の不整合を解消する際の動作を示すシーケンス図である。 図２５に示すシーケンスにおいて動作する構成要素を示す図である。

以下、図面を参照してこの発明に係わる実施形態を説明する。
（第１の実施形態）
図１は、第１の実施形態に係る情報配信システムの構成を示す模式図である。図１において、ネットワークには複数の通信機器が接続される。通信機器は、パブリッシャ及びサブスクライバの役割のいずれか、又は、両方を担う。図１では、トピックＴ_１を配信するパブリッシャ１０、トピックＴ_１の受信登録をしているサブスクライバ２０，３０、トピックＴ_２を配信するパブリッシャ４０及びトピックＴ_２の受信登録をしているサブスクライバ５０を例に記載している。

図２は、図１に示すパブリッシャ１０の機能構成を示すブロック図である。なお、パブリッシャ及びサブスクライバは、通信機器が担う役割であるため、パブリッシャ１０，４０及びサブスクライバ２０，３０，５０の構成はそれぞれ同様なものとする。

図２に示すパブリッシャ１０は、キー生成部１１、ＭＫＳＧ（Multi-Key Skip Graph）経路表維持管理部１２及びパブリッシュ転送部１３を具備する。

キー生成部１１は、Multi-key Skip Graphを構築するため、自ノードに対して１つ以上のキーを生成する。このとき、キーは、例えば、トピックを識別可能な名称であるとする。Multi-key Skip Graphとは、データ構造であるskip listをＰ２Ｐネットワークに適用したオーバレイネットワークであり、このオーバレイネットワークを、通信機器毎に保持する複数のキーと１対１に対応させた仮想的なノードにより構築したものである。以下では、仮想的なノードを仮想ノードと称する。

ＭＫＳＧ経路表維持管理部１２は、キー生成部１１で生成されたキーと、他のパブリッシャ及び／又はサブスクライバに設けられるＭＫＳＧ経路表維持管理部１２から通知される他のノードについてのキーとを参照し、Multi-key Skip Graphにおける経路表の構築、更新及び保管を担う。

図３は、第１の実施形態に係るMulti-key Skip Graphの例を示す図である。図３では、トピック名をｔ_０，ｔ_１，…として、このトピック名をキーとしてMulti-key Skip Graphを構築している。トピックｔ_ｉに関する配送経路長は、トピックｔ_ｉが割り当てられたパブリッシャ数とサブスクライバ数との合計をｍ（全通信機器数ｎ＞合計値ｍ）とすると、O(logm)となる。これは、全通信機器数をｎとしたときの配送経路長O(logn)よりも小さい値となる。

パブリッシュ転送部１３は、ＭＫＳＧ経路表維持管理部１２で保管される経路表に従い、メッセージを送信する。

図４は、図３に示すMulti-key Skip Graphにおける経路表の例を示す図である。トピックｔ_ｉの配信に携わるノードは、図４に示すように、トピックｔ_ｉがキーとして割り当てられた通信機器のみである。このため、トピックｔ_ｉに関係のない通信機器がトピックｔ_ｉについてのメッセージを転送することがなくなる。

以上のように、第１の実施形態では、キー生成部１１は、各トピック名をキーとして生成する。そして、ＭＫＳＧ経路表維持管理部１２は、パブリッシャの役割又はサブスクライバの役割が割り当てられたノードに対し、生成されたキーを参照してMulti-key Skip Graphを構築するようにしている。すなわち、情報配信システムは、分散トピックベースpub/subにおいて、Multi-key Skip Graphを構築するようにしている。これにより、情報配信システムは、キーであるトピックを指定して、メッセージのマルチキャストを実現することが可能となる。すなわち、情報配信システムは、転送に係る通信機器数を減らすことが可能となる。また、情報配信システムは、トピック毎の配送ツリーをトピックへの参加ノードのみで構築することが可能となる。

したがって、第１の実施形態に係る情報配信システムによれば、配送経路長を抑えることができ、かつ、無関係なトピックに関する情報の中継を避けることができる。
なお、Multi-key Skip Graphを用いてトピック名をキーとすることで、トピック毎の配送はそのトピックのパブリッシャにも届く。そのため、第１の実施形態に係る情報配信システムでは、根ノードにおいて子孫ノードとの情報交換によりサブスクライバの不在を検出すれば、検出した情報をパブリッシャへ通知することが可能である。
（第２の実施形態）
図５は、第２の実施形態に係るパブリッシャ６０の機能構成を示すブロック図である。なお、パブリッシャ及びサブスクライバは、通信機器が担う役割であるため、パブリッシャ及びサブスクライバの構成はそれぞれ同様なものとする。

図５に示すパブリッシャ６０は、キー生成部６１、ＭＫＳＧ経路表維持管理部６２、パブリッシャ初期状態判定部６３、パブリッシャ状態管理部６４、ランデブーポイント判定部６５、サブスクライバ存在／不在検出部６６、パブリッシュ開始／停止信号転送部６７、パブリッシュ転送部６８、パブリッシュ状態確認部６９、不整合検出部６１０及び不整合是正信号転送部６１１を具備する。

キー生成部６１は、Multi-key Skip Graphを構築するため、自ノードに対して１つ以上のキーを生成する。このとき、キー生成部６１は、各トピック名にパブリッシャ及びサブスクライバを識別可能な名称を付したものをキーとして用いる。パブリッシャ及びサブスクライバを識別可能な名称とは、例えば、パブリッシャとサブスクライバとで異なる予約語による接尾辞である。例えば、トピックｔ_ｉのサブスクライバの接尾辞には「＿１」を付してキーを「ｔ_ｉ＿１」とし、パブリッシャの接尾辞には「＿２」を付してキーを「ｔ_ｉ＿２」とする、というようにルールを決めておく。これにより、トピック名をキーとしてノード間の順序を定めることに加え、パブリッシャとサブスクライバとの間にキー（トピック名）よりも低いプライオリティで順序関係を持たせることが可能となる。

ＭＫＳＧ経路表維持管理部６２は、キー生成部６１で生成されたキーと、他のパブリッシャ及び／又はサブスクライバに設けられるＭＫＳＧ経路表維持管理部６２から通知される他のノードについてのキーとを参照し、Multi-key Skip Graphにおける経路表の構築、更新及び保管を担う。

トピック名をキーとして用いるのみの場合、図６で示すように、トピック名毎にノードがMulti-key Skip Graph上で隣接する。そのため、各トピックをノードのグループとみなすと、グループ単位でソートされている形となり、グループ内の順序は不定である。

一方、トピック名にノード種別（パブリッシャ又はサブスクライバ）を識別可能な接尾辞を付した場合、図７に示すように、グループ単位でソートされた上で、さらにグループ内でノード種別によってソートされている形となる。図７において、各トピックを表す箱の内部で、パブリッシャを示す白丸同士と、サブスクライバを示す黒丸同士とが必ずそれぞれ隣接する。

これにより、Multi-key Skip Graph上でトピック毎にサブスクライバ同士、又は、パブリッシャ同士が隣接する配置となる。以下では、サブスクライバが隣接する領域をサブスクライバゾーンと称し、パブリッシャが隣接する領域をパブリッシャゾーンと称する。図８は、図５に示すＭＫＳＧ経路表維持管理部６２により構築されるMulti-key Skip Graphの例を示す図である。

また、搭載されるノードがトピック毎のメッセージ配信にパブリッシャとして新たに参加する場合、ＭＫＳＧ経路表維持管理部６２は、双方向リンクを形成するために通信を行うノードにパブリッシャが存在するかを判断する。通信するノードにパブリッシャが存在する場合、ＭＫＳＧ経路表維持管理部６２は、そのパブリッシャが送信を停止しているか否かの情報を、そのパブリッシャに搭載されるＭＫＳＧ経路表維持管理部６２から取得する。隣接するパブリッシャが送信を停止しているか否かの情報を、以下では初期状態情報と称する。ＭＫＳＧ経路表維持管理部６２は、取得した初期状態情報をパブリッシャ初期状態判定部６３へ出力する。

また、ＭＫＳＧ経路表維持管理部６２は、隣接するノードが変化した際、Multi-key Skip Graphについての経路表をランデブーポイント判定部６５へ出力する。

なお、パブリッシャであると同時にサブスクライバでもある場合、ＭＫＳＧ経路表維持管理部６２は、サブスクライバとしてのキー「ｔ_ｉ＿１」のみをMulti-key Skip Graphに挿入する。その上で、同一トピックのサブスクライバゾーンを対象としてメッセージの配信を実行し続ける。これにより、ノードは、自身を含め当該トピックについて存在するサブスクライバのみへデータを送信することとなる。

このようなノードは、自身が存在する限り、パブリッシャもサブスクライバも存在する状況となる。そのため、下記に示すように、サブスクライバの不在を検知したり、サブスクライバの不在を他のパブリッシャへ通知したり、あるいは他のパブリッシャからサブスクライバの不在を通知されたりといった処理が不要となる。

ランデブーポイント判定部６５は、ＭＫＳＧ経路表維持管理部６２から供給される経路表に基づき、自ノードがランデブーポイントに該当するか否かを判定する。ここで、ランデブーポイントとは、サブスクライバゾーンと境界を接するパブリッシャノードである。図９は、図５に示すＭＫＳＧ経路表維持管理部６２により構築されるMulti-key Skip Graphにおけるランデブーポイントを示す図である。

サブスクライバ存在／不在検出部６６は、自ノードがランデブーポイントである際に、ＭＫＳＧ経路表維持管理部６２から供給される経路表に基づき、対象となるキーが割り当てられたサブスクライバが存在するか否かを判定する。サブスクライバ存在／不在検出部６６は、判定結果をパブリッシュ開始／停止信号転送部６７へ出力する。

各トピックについて、パブリッシャが１つ以上存在する場合、サブスクライバの存在／不在を認知可能なノードが必ず存在することが保証される。この理由は以下である。なお、この説明において、各ノードは左右２つの隣接ノードを持つこととする。また、「隣接」とはMulti-key Skip Graphのレベル0における双方向リスト上の隣接を意味するものとする。

ノードＸの左隣接ノードをＸ_Ｌとし、右隣接ノードをＸ_Ｒとすると、これらノードのキーの大小関係はＸ_Ｌ≦Ｘ≦Ｘ_Ｒとなる。各ノードが隣接ノードについて持つ情報は、隣接ノードのキー、及び、これらキーと自身のキーとの大小関係である。また、サブスクライバゾーンと、パブリッシャゾーンとの順序関係は予め定義されているため、パブリッシャゾーンの下端又は上端のどちらが同一のキーが割り当てられたサブスクライバゾーンと接するかを各ノードは知っている。本説明では、パブリッシャゾーンの下端がサブスクライバゾーンと接するものとする。

あるキーが割り当てられたパブリッシャが１つ以上存在する場合、パブリッシャゾーンが存在すること、及び、パブリッシャゾーンに唯一つの下端点が存在することは自明である。各ノードは、自ノードが下端点か否かを判断することができる。すなわち、パブリッシャであるノードXは、Ｘ_Ｌ＜Ｘであるとき、パブリッシャゾーンの下端点である。

本実施形態において、各トピックのサブスクライバゾーンと、パブリッシャゾーンとは、必ず隣接する。すなわち、相隣接するサブスクライバゾーン及びパブリッシャゾーン以外の場所に、同一のキーが割り当てられたサブスクライバ及びパブリッシャが配置されることは無い。

したがって、サブスクライバが１つ以上存在する場合は、それらの中の１つが必ず、パブリッシャゾーンの下端点であるノードの左隣接ノードである。サブスクライバが存在しない場合は、異なるキーが割り当てられたノードが必ず、パブリッシャゾーンの下端点であるノードの左隣接ノードとなる。以上のことより、パブリッシャが１つ以上存在するとき、パブリッシャゾーンの下端点であるノードが唯一つ存在し、このノードのサブスクライバ存在／不在検出部６６は、自身の左隣接ノードが同一のキーが割り当てられたサブスクライバであるか否かを見ることで、サブスクライバの存在／不在を判断する。

なお、複数のパブリッシャが存在する場合には、ランデブーポイント以外のノードでもサブスクライバの出現（不在→存在への変化）を検出が可能となる場合が存在する。具体的には、自ノードがパブリッシュ停止状態であるときに、新たに出現したサブスクライバノードがMulti-key Skip Graphのレベル１以上の双方向リストにおいて偶然隣接する可能性がある。その場合、新たに出現したサブスクライバノードと、レベル１以上の双方向リストにおいて隣接するパブリッシャノードのサブスクライバ存在／不在検出部６６は、サブスクライバが存在すると判断することが可能である。

一方、サブスクライバの消滅（存在→不在への変化）をランデブーポイント以外のパブリッシャノードが検出することは不可能である。Multi-key Skip Graphにおいて，レベル1以上の双方向リストでは各ノードがどのノードと隣接する（＝リンクを張る）かは乱数に基づいて決まる。そのため、自身の経路表にサブスクライバが存在しないときに「サブスクライバは存在するが自身の経路表には無いこと」と、「サブスクライバは存在せず自身の経路表にも無いこと」とを判断することが不可能となる。なお、レベル0のリストでは全てのノードが連結されているため、ランデブーポイントはレベル0における隣接ノードを見ることでサブスクライバの存在／不在を断言することが可能となっている。

パブリッシュ開始／停止信号転送部６７は、サブスクライバ存在／不在検出部６６から通知される、対象となるキーが割り当てられたサブスクライバが存在するか否かの判定結果に基づき、パブリッシュ開始信号又はパブリッシュ停止信号を発信する。パブリッシュ開始信号とは、パブリッシャにメッセージの配信を開始させる信号である。パブリッシュ停止信号とは、パブリッシャにメッセージの配信を停止させる信号である。また、パブリッシュ開始／停止信号転送部６７は、他のノードから送信されるパブリッシュ開始信号又はパブリッシュ停止信号を受信した場合、受信した信号を他のノードへ転送する。また、パブリッシュ開始／停止信号転送部６７は、他のノードから送信されるパブリッシュ開始信号又はパブリッシュ停止信号を受信した場合、受信した信号についての情報をパブリッシャ状態管理部６４へ通知する。

例えば、あるトピックについて、ランデブーポイントに搭載されるサブスクライバ存在／不在検出部６６により、サブスクライバが全て離脱してサブスクライバ数が０となったことが検出されると、ランデブーポイントのパブリッシュ開始／停止信号転送部６７は、パブリッシュゾーンに対してパブリッシュ停止信号をマルチキャストする。マルチキャストは、Multi-key Skip Graphの範囲検索機構をそのまま用いることで実現可能である。図１０は、図５に示すパブリッシュ開始／停止信号転送部６７がパブリッシュ停止信号を送信することで、パブリッシャに配信を停止させる際の模式図を示す。

また、ランデブーポイントに搭載されるサブスクライバ存在／不在検出部６６により、サブスクライバが不在のトピックに新たにサブスクライバが加入されたことが検出されると、ランデブーポイントのパブリッシュ開始／停止信号転送部６７は、パブリッシュゾーンに対してパブリッシュ開始信号をマルチキャストする。図１１は、図５に示すパブリッシュ開始／停止信号転送部６７がパブリッシュ開始信号を送信することで、パブリッシャに配信を開始させる際の模式図を示す。

パブリッシャ初期状態判定部６３は、搭載されるノードがトピック毎のメッセージ配信にパブリッシャとして新たに参加する場合、ＭＫＳＧ経路表維持管理部６２から出力される初期状態情報に基づき、初期状態としてパブリッシュ開始及びパブリッシュ停止のいずれの状態を選択すべきかを判定する。 パブリッシャ初期状態判定部６３は、判定結果をパブリッシャ状態管理部６４へ通知する。

図１２は、あるトピックについてのメッセージ配信に、新たなパブリッシャが参加する場合の模式図を示す。パブリッシャは、参加直後からメッセージの配信を行なうか否かを判断する必要がある。参加するトピックメッセージ配信に既にパブリッシャが存在する場合、新規パブリッシャは、Multi-key Skip Graphへのノード挿入処理の過程で少なくとも１つの既存パブリッシャとメッセージのやり取りを行う。そこで、既存パブリッシャは、新規パブリッシャへ送信するメッセージに、自ノードがパブリッシュ停止中か否かの情報を上乗せし、メッセージを送信する。パブリッシャ初期状態判定部６３は、既存パブリッシャがパブリッシュ停止の状態である場合、自ノードをパブリッシュ停止状態とし、既存パブリッシャがパブリッシュ開始の状態である場合、自ノードをパブリッシュ開始状態とする。

なお、既存のパブリッシャが存在しない場合、新規パブリッシャ自身がランデブーポイントとなるため、ランデブーポイント判定部６５、サブスクライバ存在／不在検出部６６及びパブリッシュ開始／停止信号転送部６７により、挿入完了後にパブリッシュを開始するか否かを判断する。

パブリッシャ状態管理部６４は、自ノードについてパブリッシュ開始／パブリッシュ停止についての状態情報を管理する。パブリッシャ状態管理部６４は、各部からの通知に基づいて状態情報を更新する。パブリッシャ状態管理部６４は、状態情報がパブリッシュ停止になった場合、パブリッシュ停止になった旨をパブリッシュ転送部６８へ通知する。パブリッシャ状態管理部６４は、状態情報がパブリッシュ開始になった場合、パブリッシュ開始になった旨をパブリッシュ状態確認部６９へ通知する。また、パブリッシャ状態管理部６４は、不整合検出部６１０及びパブリッシュ状態確認部６９からの要求に応じて状態情報を提示する。

パブリッシュ転送部６８は、自ノードで発生したメッセージを送信する。

また、パブリッシュ転送部６８は、他のノードから送信されたメッセージを受信する。パブリッシュ転送部６８は、受信したメッセージを隣接するパブリッシャ及び／又はサブスクライバへ転送する。パブリッシャ状態管理部６４からパブリッシュ停止である旨の通知を受けた場合、パブリッシュ転送部６８は、メッセージの配信を停止する。

パブリッシュ転送部６８がランデブーポイントに搭載されている場合、パブリッシュ転送部６８は、他のノードから送信されたメッセージを受信した旨を、不整合検出部６１０へ通知する。

パブリッシュ状態確認部６９は、パブリッシュ停止状態にある場合、Multi-key Skip Graphのレベル０リストにおいて隣接するパブリッシャへパブリッシュの状態を所定の周期で問い合わせる。パブリッシュ状態確認部６９は、隣接ノードから応答される問合結果を、不整合検出部６１０へ出力する。パブリッシュ状態確認部６９は、パブリッシャ状態管理部６４からパブリッシュ開始である旨の通知を受信した場合、隣接パブリッシャへの問合せを停止する。

また、パブリッシュ状態確認部６９は、隣接するパブリッシャからパブリッシュの状態の問い合わせを受ける。問い合わせを受けた場合、パブリッシュ状態確認部６９は、パブリッシャ状態管理部６４から状態情報を引き出し、問合せの要求元へ応答信号を送信する。

不整合検出部６１０は、パブリッシュ転送部６８から、メッセージを受信した旨の通知を受けた場合、メッセージ配信の不整合が生じているか否かを判断する。この処理は、急なノードの離脱により生じる、図１３に示す不整合に対応するためのものである。図１３は、サブスクライバの不在時にメッセージが送信される不整合を示す図である。

図１３に示す不整合は、ランデブーポイントでは発生することはなく、その他のパブリッシャノードにおいて発生の可能性がある。図１３に示す不整合は、ランデブーポイントのパブリッシュ開始／停止信号転送部６７から送信されるパブリッシュ開始信号／パブリッシュ停止信号が不達となった場合（転送経路上のノードが急に離脱した場合）に発生するからである。したがって、通知の発信元であるランデブーポイント自身に対し、パブリッシュ開始信号及びパブリッシュ停止信号が不達となることは起こり得ない。

なお、ランデブーポイント自身が急に離脱した場合、新たにランデブーポイントとなるノードに搭載されるＭＫＳＧ経路表維持管理部６２は、Multi-key Skip Graphのアルゴリズムに沿って経路表を更新する。新たにランデブーポイントとなったパブリッシャは、経路表が更新されたタイミングで、サブスクライバの存在／不在をチェックする。これにより、ランデブーポイント自身が急に離脱した場合であっても、不整合の発生を容易に防ぐことが可能となる。

ランデブーポイント以外のパブリッシャがサブスクライバ不在時にメッセージを送信した場合、そのメッセージは、図１４に示すように、必ずランデブーポイントを経由する。ランデブーポイントに搭載されるパブリッシュ転送部６８は、隣接するパブリッシャからのメッセージを受信した場合、受信した旨を自ノードに搭載される不整合検出部６１０へ出力する。不整合検出部６１０は、パブリッシュ転送部６８からメッセージを受信した旨の通知を受けた場合、ランデブーポイント判定部６５による自ノードがランデブーポイントであるとの判断と、パブリッシャ状態管理部６４から読み出される状態情報とに基づき、不整合を検出する。不整合検出部６１０は、状態情報により自ノードがパブリッシュ停止状態にあると管理されている場合、不整合が発生したと判断する。不整合検出部６１０は、検出結果を不整合是正信号転送部６１１へ出力する。不整合是正信号転送部６１１は、不整合検出部６１０から検出結果を受け取ると、メッセージの送り元のパブリッシャへ不整合是正信号を送信する。このとき、不整合是正信号は、パブリッシュを停止させる信号である。

メッセージの送り元のパブリッシャに搭載される不整合是正信号転送部６１１は、ランデブーポイントからの不整合是正信号を受信すると、パブリッシュを停止させる旨をパブリッシャ状態管理部６４へ通知する。

また、不整合検出部６１０は、隣接するパブリッシャから定期的に通知されるパブリッシャの状態情報に基づいてメッセージ配信の不整合が生じているか否かを判断する。この処理は、急なノードの離脱により生じる、図１５に示す不整合に対応するためのものである。図１５は、サブスクライバの存在時にメッセージの送信が停止されてしまう不整合を示す図である。
図１５に示す不整合は、図１３に示す不整合と同様に、ランデブーポイントでは発生することはなく、その他のパブリッシャノードにおいて発生の可能性がある。

パブリッシャに搭載されるパブリッシュ状態確認部６９は、自ノードがパブリッシュを停止している際に、図１６で示すように、Multi-key Skip Graphのレベル０リストにおける隣接ノードに対し、パブリッシュ停止状態であるか否かを定期的に問い合わせる。隣接ノードに搭載されるパブリッシュ状態確認部６９は、問合せに対する応答信号を、問合せ元のノードへ送信する。不整合検出部６１０は、応答信号と、自ノードの状態とを比較し、自ノードと隣接ノードとの間でパブリッシュの状態に齟齬がないかを確認することで、不整合を検出する。不整合検出部６１０は、自ノードがパブリッシュ停止状態にある一方で、隣接ノードがパブリッシュ開始状態にある場合、不整合が発生したと判断する。不整合検出部６１０は、検出結果を不整合是正信号転送部６１１へ出力する。不整合是正信号転送部６１１は、不整合検出部６１０から検出結果を受け取ると、ランデブーポイントへ不整合是正信号を送信する。このとき、不整合是正信号は、全てのパブリッシャへパブリッシュを開始する指示の送信を要求する信号である。

ランデブーポイントに搭載される不整合是正信号転送部６１１は、パブリッシャから不整合是正信号を受信すると、サブスクライバ存在／不在検出部６６により、サブスクライバの存在を確認する。サブスクライバが存在する場合、不整合是正信号転送部６１１は、全てのパブリッシャへ不整合是正信号を送信する。このとき、不整合是正信号は、パブリッシュを開始させる信号である。

ランデブーポイントから不整合是正信号を受信したパブリッシャは、パブリッシュを開始させる旨をパブリッシャ状態管理部６４へ通知する。

次に、以上のように構成される情報配信システムの動作を詳細に説明する。

図１７は、第２の実施形態における情報配信システムにおいて、ノードＡがメッセージ配信に参加する際の動作を示すフローチャートである。また、図１８は、図１７に示すフローを実行する際に動作する構成要素を示す図である。

まず、ノードＡは、トピックＴ及びノードの役割を指定する。役割は「サブスクライバ」、「パブリッシャ」及び「サブスクライバかつパブリッシャ」のいずれかである。ノードＡに搭載されるキー生成部６１は、トピック及び役割からキーを生成する。キー生成部６１は、役割が「サブスクライバ」であるか否かを判断する（ステップＳ１７１）。サブスクライバである場合（ステップＳ１７１のＹｅｓ）、キー生成部６１は、トピックＴに接尾辞「１」を付したキー「Ｔ＿１」を生成する（ステップＳ１７２）。サブスクライバではない場合（ステップＳ１７１のＮｏ）、キー生成部６１は、トピックＴに接尾辞「２」を付したキー「Ｔ＿２」を生成する（ステップＳ１７３）。これにより、役割が「サブスクライバ」又は「サブスクライバかつパブリッシャ」の場合、キー「Ｔ＿１」が付され、役割が「パブリッシャ」の場合、キー「Ｔ＿２」が付されることとなる。

ＭＫＳＧ経路表維持管理部６２は、Multi-key Skip Graphを用い、仮想ノードＡ_１の挿入箇所を探索する（ステップＳ１７４）。このとき、ノードＡが他のトピックに既に参加している場合、ＭＫＳＧ経路表維持管理部６２は、自身の仮想ノードＡ_２を起点として探索を行う。一方、ノードＡがどのトピックにも参加していない場合、ＭＫＳＧ経路表維持管理部６２は、例えば、トピックとは無関係な仮想ノードＢ_１〜Ｅ_１を全てのノードＢ〜Ｅが予め挿入しておくことで、仮想ノードＢ_１〜Ｅ_１を起点とした探索を行えるようにしておいても良い。また、ノードＡがどのトピックにも参加していない場合、ＭＫＳＧ経路表維持管理部６２は、既にMulti-key Skip Graph上に仮想ノードを挿入済みのノードの情報を何らかの方法で入手し、そのノードを起点として探索を行っても良い。
続いて、ＭＫＳＧ経路表維持管理部６２は、仮想ノードＡ_１のキーが「Ｔ＿１」であるか否かを判断する（ステップＳ１７５）。仮想ノードＡ_１のキーが「Ｔ＿１」である場合（ステップＳ１７５のＹｅｓ）、ＭＫＳＧ経路表維持管理部６２は、Multi-key Skip Graphのアルゴリズムに沿って、仮想ノードＡ_１の挿入処理を実施する（ステップＳ１７６）。仮想ノードＡ_１のキーが「Ｔ＿２」である場合（ステップＳ１７５のＮｏ）、ＭＫＳＧ経路表維持管理部６２は、Multi-key Skip Graphのアルゴリズムに沿って、仮想ノードＡ_１の挿入処理を実施する（ステップＳ１７７）。

ステップＳ１７６にて挿入処理を実行した後、ノードＡは、役割に応じた処理を開始する。すなわち、パブリッシュ転送部６８は、役割が「サブスクライバかつパブリッシャ」であるか否かを判断する（ステップＳ１７８）。役割が「サブスクライバかつパブリッシャ」である場合（ステップＳ１７８のＹｅｓ）、パブリッシュ転送部６８は、メッセージの配信を開始する（ステップＳ１７９）。役割が「サブスクライバ」である場合（ステップＳ１７８のＮｏ）、ノードＡは、メッセージが配信されるまで待機する（ステップＳ１７１０）。

ステップＳ１７７にて挿入処理を実行した後、ＭＫＳＧ経路表維持管理部６２は、双方向リンクを形成するために通信を行うノードにキー「Ｔ＿２」が割り当てられたパブリッシャが存在するかを判断する（ステップＳ１７１１）。双方向リンクを形成するために通信を行うノードにキー「Ｔ＿２」が割り当てられたパブリッシャが存在する場合（ステップＳ１７１１のＹｅｓ）、ＭＫＳＧ経路表維持管理部６２は、そのパブリッシャから初期状態情報を取得する（ステップＳ１７１２）。パブリッシャ初期状態判定部６３は、ＭＫＳＧ経路表維持管理部６２で取得された初期状態情報に基づき、初期状態としてパブリッシュ開始状態とするか否かを判断する（ステップＳ１７１３）。パブリッシュ開始状態とする場合（ステップＳ１７１３のＹｅｓ）、パブリッシャ状態管理部６４は、パブリッシャの状態をパブリッシュ開始状態とする（ステップＳ１７１４）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４におけるパブリッシュ開始状態に基づき、メッセージの配信を開始する（ステップＳ１７１５）。

初期状態としてパブリッシュ停止状態とする場合（ステップＳ１７１３のＮｏ）、パブリッシャ状態管理部６４は、パブリッシャの状態をパブリッシュ停止状態とする（ステップＳ１７１６）。ノードＡは、パブリッシュ開始信号があるまでメッセージの配信を停止する（ステップＳ１７１７）。

ステップＳ１７１１において、双方向リンクを形成するために通信を行うノードにキー「Ｔ＿２」が割り当てられたパブリッシャが存在しない場合（ステップＳ１７１１のＮｏ）、ランデブーポイント判定部６５は、自ノードがランデブーポイントに該当すると判定する（ステップＳ１７１８）。サブスクライバ存在／不在検出部６６は、レベル０における隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在するか否かを判断する（ステップＳ１７１９）。レベル０における隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在する場合（ステップＳ１７１９のＹｅｓ）、パブリッシュ開始／停止信号転送部６７は、パブリッシャ状態管理部６４へパブリッシャの状態がパブリッシュ開始状態である旨を通知する（ステップＳ１７２０）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４におけるパブリッシュ開始状態に基づき、メッセージの配信を開始する（ステップＳ１７２１）。

キー「Ｔ＿１」が割り当てられたサブスクライバが隣接しない場合（ステップＳ１７１９のＮｏ）、パブリッシュ開始／停止信号転送部６７は、パブリッシャ状態管理部６４へパブリッシャの状態がパブリッシュ停止状態である旨を通知する（ステップＳ１７２２）。ノードＡは、パブリッシュ開始信号があるまでメッセージの配信を停止する（ステップＳ１７２３）。

図１９は、第２の実施形態における情報配信システムにおいて、サブスクライバＳ１の不在を検知し、パブリッシャＰ１及びパブリッシャＰ２によるメッセージの送信を停止する際の動作を示すシーケンス図である。また、図２０は、図１９に示すシーケンスを実行する際に動作する構成要素を示す図である。

まず、サブスクライバＳ１は、トピックＴのメッセージ配信についての登録を解除する（シーケンスＳ１９１）。サブスクライバＳ１のＭＫＳＧ経路表維持管理部６２は、Multi-key Skip Graphを用い、サブスクライバＳ１の離脱処理を実施する（シーケンスＳ１９２）。ＭＫＳＧ経路表維持管理部６２は、サブスクライバＳ１の離脱によるリンクの張り替えを、サブスクライバＳ１と隣接するパブリッシャＰ１のＭＫＳＧ経路表維持管理部６２へ通知する（シーケンスＳ１９３）。

パブリッシャＰ１のＭＫＳＧ経路表維持管理部６２は、サブスクライバＳ１から通知される情報に基づいて経路表を更新する（シーケンスＳ１９４）。パブリッシャＰ１のランデブーポイント判定部６５は、自ノードがランデブーポイントに該当すると判定する（シーケンスＳ１９５）。サブスクライバ存在／不在検出部６６は、レベル０における自身の隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在する状態から存在しない状態になったか否かを判断する（シーケンスＳ１９６）。キー「Ｔ＿１」が割り当てられたノードが存在する状態のままである場合（シーケンスＳ１９６のＮｏ）、パブリッシュ開始／停止信号転送部６７は、処理を終了させる。キー「Ｔ＿１」が割り当てられたノードが存在する状態から存在しない状態になった場合（シーケンスＳ１９６のＹｅｓ）、パブリッシュ開始／停止信号転送部６７は、パブリッシャ状態管理部６４へパブリッシャの状態がパブリッシュ停止状態となる旨を通知すると共に（ステップＳ１９７）、パブリッシュ停止信号をキー「Ｔ＿２」が割り当てられたノードへマルチキャストする（ステップＳ１９８）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４で管理されるパブリッシュ停止状態に基づき、メッセージの配信を停止する（ステップＳ１９９）。

パブリッシャＰ２は、ランデブーポイントであるパブリッシャＰ１からマルチキャストされるパブリッシュ停止信号を、パブリッシュ開始／停止信号転送部６７により受信する。パブリッシュ開始／停止信号転送部６７は、パブリッシャＰ２の状態がパブリッシュ停止状態となったことを、パブリッシャ状態管理部６４へ通知する（シーケンスＳ１９１０）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４で管理されるパブリッシュ停止状態に基づき、メッセージの配信を停止する（ステップＳ１９１１）。

図２１は、第２の実施形態における情報配信システムにおいて、サブスクライバＳ１の存在を検知し、パブリッシャＰ１及びパブリッシャＰ２によるメッセージの送信を開始する際の動作を示すシーケンス図である。また、図２２は、図２１に示すシーケンスを実行する際に動作する構成要素を示す図である。

まず、サブスクライバＳ１は、トピックＴについてのメッセージが配信されるように受信登録を行う（シーケンスＳ２１１）。サブスクライバＳ１のＭＫＳＧ経路表維持管理部６２は、Multi-key Skip Graphを用い、サブスクライバＳ１の挿入処理を実施する（シーケンスＳ２１２）。ＭＫＳＧ経路表維持管理部６２は、サブスクライバＳ１の挿入によるリンクの張り替えを、サブスクライバＳ１と隣接するパブリッシャＰ１のＭＫＳＧ経路表維持管理部６２へ通知する（シーケンスＳ２１３）。

パブリッシャＰ１のＭＫＳＧ経路表維持管理部６２は、サブスクライバＳ１から通知される情報に基づいて経路表を更新する（シーケンスＳ２１４）。パブリッシャＰ１のランデブーポイント判定部６５は、自ノードがランデブーポイントに該当すると判定する（シーケンスＳ２１５）。サブスクライバ存在／不在検出部６６は、レベル０における自身の隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在しない状態から存在する状態になったか否かを判断する（シーケンスＳ２１６）。キー「Ｔ＿１」が割り当てられたノードが存在しない状態のままである場合（シーケンスＳ２１６のＮｏ）、パブリッシュ開始／停止信号転送部６７は、処理を終了させる。キー「Ｔ＿１」が割り当てられたノードが存在しない状態から存在する状態になった場合（シーケンスＳ２１６のＹｅｓ）、パブリッシュ開始／停止信号転送部６７は、パブリッシャ状態管理部６４へパブリッシャの状態がパブリッシュ開始状態となる旨を通知すると共に（ステップＳ２１７）、パブリッシュ開始信号をキー「Ｔ＿２」が割り当てられたノードへマルチキャストする（ステップＳ２１８）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４で管理されるパブリッシュ開始状態に基づき、メッセージの配信を開始する（ステップＳ２１９）。

パブリッシャＰ２は、ランデブーポイントであるパブリッシャＰ１からマルチキャストされるパブリッシュ開始信号を、パブリッシュ開始／停止信号転送部６７により受信する。パブリッシュ開始／停止信号転送部６７は、パブリッシャＰ２の状態がパブリッシュ開始状態となったことを、パブリッシャ状態管理部６４へ通知する（シーケンスＳ２１１０）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４で管理されるパブリッシュ開始状態に基づき、メッセージの配信を開始する（ステップＳ２１１１）。

図２３は、第２の実施形態における情報配信システムにおいて、サブスクライバ不在時の不整合を解消する際の動作を示すシーケンス図である。また、図２４は、図２３に示すシーケンスを実行する際に動作する構成要素を示す図である。

まず、パブリッシャＰ１は、トピックＴについてのメッセージを配信する（シーケンスＳ２３１）。

パブリッシャＰ２は、パブリッシュ転送部６８により、パブリッシャＰ１からのメッセージを受信する（シーケンスＳ２３２）。パブリッシャＰ２のランデブーポイント判定部６５は、自ノードがランデブーポイントに該当すると判定する（シーケンスＳ２３３）。不整合検出部６１０は、パブリッシャ状態管理部６４から状態情報を読み出し（シーケンスＳ２３４）、自ノードの状態がパブリッシュ停止状態であるか否かを判断する（シーケンスＳ２３５）。自ノードの状態がパブリッシュ停止状態である場合（シーケンスＳ２３５のＹｅｓ）、不整合検出部６１０は、不整合が発生したと判断し（シーケンスＳ２３６）、不整合是正信号転送部６１１に、パブリッシュを停止させる旨の不整合是正信号をパブリッシャＰ１へ送信させる（シーケンスＳ２３７）。自ノードの状態がパブリッシュ開始状態である場合（シーケンスＳ２３５のＮｏ）、不整合検出部６１０は、処理を終了させる。

パブリッシャＰ１の不整合是正信号転送部６１１は、ランデブーポイントからの不整合是正信号を受信すると、パブリッシュを停止させる旨をパブリッシャ状態管理部６４へ通知する（シーケンスＳ２３８）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４で管理されるパブリッシュ停止状態に基づき、メッセージの配信を停止する（ステップＳ２３９）。

図２５は、第２の実施形態における情報配信システムにおいて、サブスクライバ存在時の不整合を解消する際の動作を示すシーケンス図である。また、図２６は、図２５に示すシーケンスを実行する際に動作する構成要素を示す図である。

まず、トピックＴについてのメッセージ配信に参加し、かつ、メッセージの配信を停止しているパブリッシャＰ１は、パブリッシュ状態確認部６９により、Multi-key Skip Graphのレベル0における隣接ノードのうちキー「Ｔ＿２」が付されたノードに対し、パブリッシュ停止状態か否かの問い合わせを定期的に実施する（シーケンスＳ２５１）。

パブリッシャＰ２は、パブリッシュ状態確認部６９により、パブリッシャＰ１から送信される問合せを受信する（シーケンスＳ２５２）。パブリッシュ状態確認部６９は、パブリッシャ状態管理部６４から状態情報を読み出し（シーケンスＳ２５３）、問合せに対する応答信号を、パブリッシャＰ１へ送信する（シーケンスＳ２５４）。

パブリッシャＰ１における不整合検出部６１０は、自ノードの状態がパブリッシュ停止状態であるのに対し、応答信号により示されるパブリッシャＰ２の状態がパブリッシュ開始状態である場合、パブリッシャＰ１及びパブリッシャＰ２間の不整合を検出する（シーケンスＳ２５５）。不整合検出部６１０は、パブリッシュを開始させる指示の全てのパブリッシャへの通知を要求する旨の不整合是正信号を、不整合是正信号転送部６１１にパブリッシャＰ３へ送信させる（シーケンスＳ２５６）。

パブリッシャＰ３は、パブリッシャＰ２から不整合是正信号を受信すると、ランデブーポイント判定部６５により、自ノードがランデブーポイントであると判定する（シーケンスＳ２５７）。サブスクライバ存在／不在検出部６６は、レベル０における隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在するか否かを判断する（シーケンスＳ２５８）。レベル０における隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在する場合（シーケンスＳ２５８のＹｅｓ）、不整合検出部６１０は、不整合が発生したと判断し（シーケンスＳ２５９）、不整合是正信号転送部６１１に、パブリッシュを開始させる信号である不整合是正信号を全てのパブリッシャへ送信させる（シーケンスＳ２５１０）。レベル０における隣接ノードにキー「Ｔ＿１」が割り当てられたノードが存在しない場合（シーケンスＳ２５８のＮｏ）、不整合検出部６１０は、処理を終了させる。

パブリッシャＰ１の不整合是正信号転送部６１１は、パブリッシャＰ３からの不整合是正信号を受信し、パブリッシャ状態管理部６４へパブリッシャの状態がパブリッシュ開始状態である旨を通知する（シーケンスＳ２５１１）。パブリッシュ転送部６８は、パブリッシャ状態管理部６４におけるパブリッシュ開始状態に基づき、メッセージの配信を開始する（シーケンスＳ２５１２）。

以上のように、第２の実施形態では、キー生成部６１は、各トピック名をキーとして生成する。そして、ＭＫＳＧ経路表維持管理部６２は、パブリッシャの役割又はサブスクライバの役割が割り当てられたノードに対し、生成されたキーを参照してMulti-key Skip Graphを構築するようにしている。すなわち、情報配信システムは、分散トピックベースpub/subにおいて、Multi-key Skip Graphを構築するようにしている。これにより、情報配信システムは、キーであるトピックを指定して、メッセージのマルチキャストを実現することが可能となる。すなわち、情報配信システムは、転送に係る通信機器数を減らすことが可能となる。また、情報配信システムは、トピック毎の配送ツリーをトピックへの参加ノードのみで構築することが可能となる。

したがって、第２の実施形態に係る情報配信システムによれば、配送経路長を抑えることができ、かつ、無関係なトピックに関する情報の中継を避けることができる。
また、従来の技術では、以下に示す課題も存在する。すなわち、従来の技術では、サブスクライバの不在時にメッセージの配信を停止できない。そのため、パブリッシャは、サブスクライバの不在を検知する術が無いため、サブスクライバの存在／不在に関わらず、まずはメッセージを根ノードに送る必要がある。送信頻度が高いトピックの場合、サブスクライバが不在にも関わらずメッセージが送信され続けるのはネットワーク資源の浪費となり望ましくない。

また、根ノードにおいて子ノードの存在／不在からサブスクライバの不在を検出可能であるが、根ノードに全パブリッシャへのリンクを持たせると負荷が集中してしまうため、スケーラビリティが失われてしまう。

そこで、第２の実施形態では、キー生成部６１は、各トピック名にパブリッシャとサブスクライバとで異なる予約語を接尾辞として付したものをキーとして生成する。ＭＫＳＧ経路表維持管理部６２は、生成されたキーを参照し、Multi-key Skip Graph上でトピック毎にサブスクライバ同士、又は、パブリッシャ同士が隣接するようにノードを配置する。そして、サブスクライバゾーンと境界を接するパブリッシャノードであるランデブーポイントに搭載されるサブスクライバ存在／不在検出部６６は、サブスクライバの存在／不在を検出するようにしている。これにより、情報配信システムは、各ノードが局所的な情報のみを保持する状況下において、分散pub/subが備えるべきスケーラビリティを損なわずに、トピック毎にサブスクライバの存在／不在を検出することが可能となる。

また、第２の実施形態では、ランデブーポイントに搭載されるパブリッシュ開始／停止信号転送部６７は、サブスクライバ存在／不在検出部６６で検出されたサブスクライバの存在／不在に基づき、パブリッシュ開始信号又はパブリッシュ停止信号を、トピックに係る全てのパブリッシャへ送信する。これにより、情報配信システムは、サブスクライバの不在時に、メッセージの配信を停止させることが可能となる。

また、第２の実施形態では、パブリッシャ初期状態判定部６３は、自ノードがパブリッシャとしてメッセージ配信に新たに参加する場合、隣接されるパブリッシャの状態に基づき、パブリッシュ開始及びパブリッシュ停止のいずれかを初期状態として選択するようにしている。これにより、新たにメッセージ配信に参加するパブリッシャは、参加直後からメッセージの配信開始／停止に対応することが可能となる。

また、第２の実施形態では、不整合検出部６１０は、パブリッシュ転送部６８からメッセージを受信した旨の通知を受けた際に、自ノードがランデブーポイントであり、かつ、パブリッシュ停止状態にある場合、不整合が発生したと判断する。そして、不整合是正信号転送部６１１は、不整合が検出されると、配信を停止させる旨の不整合是正信号を、メッセージの送り元へ送信するようにしている。これにより、情報配信システムは、サブスクライバが不在にも関わらず、メッセージを配信するパブリッシャが存在する場合、このパブリッシャにメッセージの配信を停止させることが可能となる。

また、第２の実施形態では、パブリッシュ状態確認部６９は、自ノードがパブリッシュを停止している場合、隣接ノードに対してパブリッシュ停止状態であるか否かを定期的に問い合わせる。そして、不整合検出部６１０は、隣接ノードがパブリッシュ開始状態である場合、不整合を検出する。そして、ランデブーポイントに搭載される不整合是正信号転送部６１１は、隣接ノードにて不整合が生じている場合、メッセージの配信を開始する旨の不整合是正信号を他のパブリッシャへ送信するようにしている。これにより、情報配信システムは、サブスクライバが存在するにも関わらず、配信を停止しているパブリッシャが存在する場合、このパブリッシャにメッセージの配信を開始させることが可能となる。

なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

また、本発明の情報配信システムは、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

１０，４０，６０…パブリッシャ、１１…キー生成部、１２…ＭＫＳＧ経路表維持管理部、１３…パブリッシュ転送部、２０，３０，５０…サブスクライバ、６１…キー生成部、６２…ＭＫＳＧ経路表維持管理部、６３…パブリッシャ初期状態判定部、６４…パブリッシャ状態管理部、６５…ランデブーポイント判定部、６６…サブスクライバ存在／不在検出部、６７…パブリッシュ開始／停止信号転送部、６８…パブリッシュ転送部、６９…パブリッシュ状態確認部、６１０…不整合検出部、６１１…不整合是正信号転送部

Claims (6)

1. 複数の通信機器がネットワークに接続されてなる情報配信システムにおいて、
   前記通信機器に含まれるノードは、
   トピックを識別可能な名称に、サブスクライバ及びパブリッシャを含むノード種別を識別可能な名称を付してキーを生成するキー生成部と、
   前記キーと、他のノードから通知される前記他のノードについてのキーとを参照し、前記サブスクライバ同士が前記トピック毎に隣接するサブスクライバゾーンと、前記パブリッシャ同士が前記トピック毎に隣接するパブリッシャゾーンとが形成された、Multi-key Skip Graphにおける経路表を構築するＭＫＳＧ経路表維持管理部と、
   前記経路表に基づき、自ノードが、前記サブスクライバゾーンと境界を接するパブリッシャであるランデブーポイントに該当するか否かを判定するランデブーポイント判定部と、
   自ノードが前記ランデブーポイントである場合、前記経路表に基づき、対象となるキーが割り当てられたサブスクライバの存在／不在を検出するサブスクライバ存在／不在検出部と、
   前記経路表に従い、メッセージを送信するパブリッシュ転送部と
   を備える情報配信システム。
2. 前記ノードは、
   前記サブスクライバが不在の状態において、前記サブスクライバ存在／不在検出部により前記サブスクライバの存在が新たに検出される場合、パブリッシュ開始信号を前記パブリッシャゾーンへ発信し、前記サブスクライバが存在する状態において、前記サブスクライバ存在／不在検出部により前記サブスクライバの不在が新たに検出される場合、パブリッシュ停止信号を前記パブリッシャゾーンへ発信するパブリッシュ開始／停止信号転送部を備える請求項１記載の情報配信システム。
3. 前記ノードは、
   パブリッシャとして新たにメッセージの配信に参加する際、自ノードの状態を、前記Multi-key Skip Graphにおいて隣接するパブリッシャの状態に従って決定するパブリッシャ初期状態判定部を備える請求項１又は２記載の情報配信システム。
4. 前記ノードは、
   他のパブリッシャから配信されるメッセージを受信した際に、自ノードが前記ランデブーポイントであり、かつ、メッセージの配信を停止する状態にある場合、不整合が発生したと判断する不整合検出部と、
   前記不整合が検出されると、配信を停止させる旨の不整合是正信号を前記他のパブリッシャへ送信する不整合是正信号転送部と
   を備える請求項１乃至３のいずれかに記載の情報配信システム。
5. 前記ノードは、
   自ノードがメッセージの配信を停止する状態にある場合、前記Multi-key Skip Graphにおいて隣接するパブリッシャに対して動作の状態を問い合わせるパブリッシュ状態確認部と、
   自ノードの状態と、前記隣接するパブリッシャの状態とに齟齬がある場合、不整合が発生したと判断する不整合検出部と、
   自ノードが前記ランデブーポイントでない場合、第１の不整合是正信号を前記ランデブーポイントへ送信し、自ノードが前記ランデブーポイントである場合、他のパブリッシャから送信される第１の不整合是正信号に応じ、前記サブスクライバ存在／不在検出部により前記サブスクライバの存在を確認した後、メッセージの配信を開始させる旨の第２の不整合是正信号を前記パブリッシャゾーンへ送信する不整合是正信号転送部と
   を備える請求項１乃至３のいずれかに記載の情報配信システム。
6. 複数の通信機器がネットワークに接続されてなる情報配信システムで用いられる情報配信方法において、
   前記通信機器に含まれるノード毎に、トピックを識別可能な名称に、サブスクライバ及びパブリッシャを含むノード種別を識別可能な名称を付したキーを生成し、
   前記キーと、他のノードから通知される前記他のノードについてのキーとを参照し、前記サブスクライバ同士が前記トピック毎に隣接するサブスクライバゾーンと、前記パブリッシャ同士が前記トピック毎に隣接するパブリッシャゾーンとが形成された、Multi-key Skip Graphにおける経路表を構築し、
   前記経路表に基づき、自ノードが、前記サブスクライバゾーンと境界を接するパブリッシャであるランデブーポイントに該当するか否かを判定し、
   自ノードが前記ランデブーポイントである場合、前記経路表に基づき、対象となるキーが割り当てられたサブスクライバの存在／不在を検出し、
   前記経路表に従い、メッセージを送信する情報配信方法。

Images