JP2016066882A - 通信システム、ノード装置、ノードプログラム、および、通信プログラム - Google Patents

Abstract

【課題】Push型のデータ転送方式において予約メッセージの負荷分散を実現すること。【解決手段】ノード１０３などの各ノード装置は、発行メッセージのオブジェクトＩＤと、隣接ノードを次ホップとして対応づけて予約転送テーブル２１２に格納する予約転送テーブル作成部２０４と、発行転送テーブル２１１から発行メッセージを転送する次ホップを特定する発行転送テーブル検索部２０３と、予約メッセージのオブジェクトＩＤと、隣接ノードを次ホップとして対応づけて発行転送テーブル２１１に格納する発行転送テーブル作成部２０２と、予約転送テーブル２１２から予約メッセージを転送する次ホップを特定する予約転送テーブル検索部２０５と、を有する。【選択図】図２

Description

本発明は、通信システム、ノード装置、ノードプログラム、および、通信プログラムに関する。

データの送信端末からデータの受信端末までのデータ転送方式には、受信端末が明示的にデータの送信を要求する「Pull型」と、データの送信要求を毎回送信しなくてもデータを送信する「Push型」とに分類できる。
Pull型では、登録者端末（Registerer）が送信対象のデータを登録（Register）した後、各取得者端末（Retriever）が、登録されたデータをそれぞれ取得（Retrieve）する。
Push型では、予約者端末（Subscriber）がデータ送信を許可する旨の予約処理（Subscribe）を行った後、発行者端末（Publisher）が予約されたデータを、各予約者端末に発行（Publish）する。
ここで、予約する（Subscribe）とは、予約対象のデータを、自身あてに配信してもらうように、事前登録することである。

Pull型であっても、Push型であっても、データの送信側（上流側）からデータの受信側（下流側）までのデータの経路をルーティングする必要がある。よって、データの経路上の各ノードは、自身の隣の上流側のノードから転送されてきたデータを、自身の隣のどの下流側のノードに転送するかを、決定する必要がある。

そこで、各ノードがデータの転送先を決定するために、ネットワーク上の位置を示すＩＤ（IDentifier）を用いる必要がある。例えば、ＩＰ（Internet Protocol）ネットワークでは、位置ＩＤとして、ＩＰアドレスを用いて通信を行うノードの位置を特定する。そのＩＰアドレスを特定するための手がかりとして、所望のデータのＵＲＩ（Uniform Resource Identifier）から抽出されたホストＩＤなどが存在する。

ＤＮＳ（Domain Name System）は、ホストＩＤを検索キーとして、そのホストＩＤが示す位置ＩＤを特定するための名前解決サービスである。よって、端末は、ＤＮＳから通知されたＩＰアドレスを用いて、宛先のノードに対して通信を行う。
データ指向型ネットワーク（ＤＣＮ：Data-centric Network）は、データＩＤ（オブジェクトＩＤ）を用いて所望のオブジェクトまで、データ要求をルーティングするためのネットワークである。

非特許文献１には、階層型ＤＨＴ（Distributed Hash Table）によってホストＩＤから位置ＩＤへの変換を行うことで、ＤＣＮにおけるPull型の通信方式を実現する手法が記載されている。
非特許文献２には、Registerの際に経路情報を記録することで、Pull型の通信方式を実現する手法が記載されている。
非特許文献３には、Rendezvous SystemによってRendezvous IDから経路情報への変換を行うことでPush型の通信方式を実現する手法が記載されている。
特許文献１には、ネットワークが、プロバイダから消費者までのコンテンツのルーティングに責任を負うコンテンツセントリックネットワーク（ＣＣＮ）が記載されている（段落００１８など）。

特開２００９−２７８６２４号公報

Matteo D’Ambrosioなど著、「 D-6.2 Second NetInf Architecture Description」, The FP7 4WARD Project, January 14, 2010. Teemu Koponenなど著、「A Data-Oriented (and Beyond) Network Architecture」, SIGCOMM’07, August 2007. M. Ainなど著、「D2.3 Architecture Definition, Component Descriptions, and Requirements,」,Deliverable, PSIRP 7th FP EU-funded project, Feb. 2009.

Push型のデータ転送方式では、１つの登録されたデータに対して、多数の予約（Subscribe）が登録されることもある。よって、予約メッセージの送信頻度が高い場合、PublisherとSubscriberのマッチングを行うノード（以下、マッチングノード）に予約メッセージが集中するため、多大なトランザクション負荷が発生する。

そこで本発明は、前記した問題を解決し、Push型のデータ転送方式において予約メッセージの負荷分散を実現する。

前記課題を解決するために、本発明の通信システムは、
複数のノードがネットワークで接続されて構成される通信システムに用いられる前記複数のノードのうちの第１ノードが、オブジェクトの送信を要求するための発行メッセージを発行者端末から受信し、
前記第１ノードから前記複数のノードのうちの第２ノードまでの各ノードが、
前記発行メッセージの転送先である次ホップのノードを示す第１ルーティング情報が、自身の記憶手段に記録されており、
前記第１ルーティング情報から取得した次ホップに向けて、前記発行メッセージを転送する第１ルーティングを行うとともに、
前記第１ルーティングで転送する前記発行メッセージのオブジェクトＩＤと、その発行メッセージを自身に向けて転送した隣接ノードを次ホップとする第２ルーティング情報を自身の記憶手段に記録し、
前記複数のノードのうちの第３ノードが、前記オブジェクトの受信を要求するための予約メッセージを予約者端末から受信し、
前記第３ノードから前記第１ノードまでの各ノードが、
前記第２ルーティング情報から前記予約メッセージのオブジェクトＩＤを検索して取得した次ホップまたは事前に設定されているデフォルトの次ホップに向けて、前記予約メッセージを転送する第２ルーティングを行うとともに、
前記第２ルーティングで転送する前記予約メッセージのオブジェクトＩＤと、その予約メッセージを自身に向けて転送した隣接ノードを次ホップとする第３ルーティング情報を自身の記憶手段に記録し、
前記第１ノードが、前記オブジェクトの発行メッセージを発行者端末から再度受信し、
前記第１ノードから前記第３ノードまでの各ノードが、
前記第３ルーティング情報から前記再度受信した発行メッセージのオブジェクトＩＤを検索して取得した次ホップに向けて、前記再度受信した発行メッセージを転送する第３ルーティングを行うことを特徴とする。
その他の特徴は、後記する。

この本発明によれば、第２ルーティングにおいて、第２ルーティング情報を記録したノードによって、予約メッセージが発行者端末に向けて（第２ノードではなく、第１ノードに向けて）送信される。よって、予約メッセージは、第２ノードを経由せずに、第１ノードまで到達することができるので、第２ノードのトランザクション負荷を軽減できる。

なお、本発明は、後記する実施形態では以下のようにサポートされる。
第１ルーティングは、第１発行メッセージ（図２の矢印１９２）の経路に対応する。
第２ルーティングは、第２予約メッセージ（図２の矢印１９４，１９５）の経路に対応する。なお、矢印１９４で中断し、矢印１９５を省略してもよい。
第３ルーティングは、第３発行メッセージ（図２の矢印１９６）の経路に対応する。
第１ノードは、図２のノード１０２である。
第２ノードは、図２のノード１０６である。
第３ノードは、図２のノード１０９である。
第１ルーティング情報は、図１０（ａ）の発行転送テーブル２１１である。
第２ルーティング情報は、図１０（ｄ）の予約転送テーブル２１２（図１０（ｂ）から図１０（ｄ）へのエントリ追加分）である。
第３ルーティング情報は、図１１（ｂ）の発行転送テーブル２１１（図１０（ｃ）から図１１（ｂ）へのエントリ追加分）である。

本発明によれば、Push型のデータ転送方式において予約メッセージの負荷分散を実現できる。

本発明の一実施形態に関するPush型通信システムを示す構成図である。 本発明の一実施形態に関するPush型通信システムの通信経路を示す説明図である。 本発明の一実施形態に関するノード装置を示す構成図である。 本発明の一実施形態に関する発行転送テーブル２１１および発行メッセージを示す説明図（図４（ａ））と、予約転送テーブル２１２および予約メッセージを示す説明図（図４（ｂ））である。 本発明の一実施形態に関する第１予約メッセージのルーティング処理を示すシーケンス図である。 本発明の一実施形態に関する第１発行メッセージのルーティング処理を示すシーケンス図である。 本発明の一実施形態に関する第２発行メッセージのルーティング処理を示すシーケンス図である。 本発明の一実施形態に関する第２予約メッセージのルーティング処理を示すシーケンス図である。 本発明の一実施形態に関する第３発行メッセージのルーティング処理を示すシーケンス図である。 本発明の一実施形態に関する図５の処理実行前の発行転送テーブル２１１（図１０（ａ））と、図５の処理実行前の予約転送テーブル２１２（図１０（ｂ））と、図５の処理実行後の発行転送テーブル２１１（図１０（ｃ））と、図６の処理実行後の予約転送テーブル２１２（図１０（ｄ））である。 本発明の一実施形態に関する図７の処理実行後の予約転送テーブル２１２（図１１（ａ））と、図８の処理実行後の発行転送テーブル２１１（図１１（ｂ））と、図９の処理実行後の予約転送テーブル２１２（図１１（ｃ））である。 本発明の一実施形態に関するノード装置の処理を示すフローチャートである。

以下、本発明の一実施形態を、図面を参照して詳細に説明する。

図１は、Push型通信システムを示す構成図である。
Push型通信システムは、各ノード１０２〜１１３，１１５と、その各ノードに収容される各端末１０１，１１３，１１４とがネットワークで接続されて構成される。
オブジェクト１１２とは、映像データ、音楽データなどのマルチメディア形式のファイルから、Webページに代表されるテキストデータ、更にはセンサデータや機器状態の監視データなどのMachine-to-Machine（M2M）通信向けデータなど、データＩＤを用いてアクセスできるあらゆるデータを意味する。

端末１０１は、オブジェクト１１２を発行する発行者端末（Publisher）である。
端末１１３，１１４は、オブジェクト１１２を予約する予約者端末（Subscriber）である。
なお、Push型通信システムの各ノードや各端末は、それぞれＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を実現する。

各ノードは、ノード１０５を頂点とした階層型のトポロジで接続されている。図１では、同じ階層を示すために、ノード間を破線で区切っている。以下に示すように、階層番号が小さいほど上位の階層である。
第１階層（最上位）は、ノード１０５である。
第２階層は、ノード１０４，１０６，１１０である。
第３階層は、ノード１０３，１０７，１１１である。
第４階層（最下位）は、ノード１０２，１０９，１１５，１０８である。

以下、Push型通信システムをデータ指向型ネットワーク（ＤＣＮ：Data-centric Network）に適用した一例を説明する。ＤＣＮとは、オブジェクト１１２などのオブジェクトの識別子であるオブジェクトＩＤ（以下「oid」と略す）を用いて所望のオブジェクトまで、そのオブジェクトへのアクセスを転送するためのネットワークである。そのため、Push型通信システムでは、各ノード上のテーブル（詳細は後記）に、オブジェクト１１２の位置情報が分散して管理されている。
また、各ノードには、ノードＩＤ（nid）が付与されている。oidとnidとは、別々のＩＤ空間であり、別々のデータである。oidの階層表現については、後記する。

Push型通信システムでは、オブジェクト１１２へのアクセスを指示するために、以下のメッセージを用いる。
・発行メッセージは、端末１０１がオブジェクト１１２を予約者端末（端末１１３，１１４）に送信するためのメッセージパケットである。
・予約メッセージは、端末１１３，１１４がオブジェクト１１２を予約するためのメッセージパケットである。
なお、予約者端末が予約メッセージを用いて行う予約の内容については、発行メッセージを介して自身あてに配信されるオブジェクト（データ）を特定できるものであれば、以下に例示するように任意の内容としてもよい。
・メールマガジンなどの定期的に（複数回）配信されるオブジェクトの送信を事前登録するもの。
・配信日が不定期であるオブジェクトの送信を事前登録するもの。
・配信が１回だけであるオブジェクトの送信を事前登録するもの。
・エラーなどのイベント通知のように、所定の配信条件を満たすときにだけ送信されるオブジェクトの送信を事前登録するもの。この場合、予約をしたとしても、エラーが発生しなければ、オブジェクトは配信されない。

図２は、図１のPush型通信システムに対して、発行メッセージ（実線矢印）および予約メッセージ（破線矢印）の通信経路を付した説明図である。
破線矢印１９１は、第１予約メッセージの経路（端末１１４→nid=g→f→e）を示す（詳細は図５）。
実線矢印１９２は、第１発行メッセージの経路（端末１０１→nid=a→b→c→e）を示す（詳細は図６）。
実線矢印１９３は、第２発行メッセージの経路（nid=e→f→g→端末１１４）を示す（詳細は図７）。
破線矢印１９４は、第２予約メッセージの経路（端末１１３→nid=h→b）を示す（詳細は図８）。
破線矢印１９５は、第２予約メッセージの延長経路（nid=b→a→端末１０１）を示す。
実線矢印１９６は、第３発行メッセージの経路（nid=b→h→端末１１３）を示す（詳細は図９）。

図３は、ノード装置を示す構成図である。
ノード１０２をはじめとした各ノードは、制御処理部２００と、制御データ記憶部２１０と、データ転送部２２０と、データ記憶部２３０と、ネットワーク２５０に接続するための通信ＩＦ２４０と、を有する。なお、端末も、ノードの各構成要素を有していてもよい。

制御データ記憶部２１０は、発行メッセージを転送するための発行転送テーブル２１１と、予約メッセージを転送するための予約転送テーブル２１２と、オブジェクト１１２の格納先を特定するための格納データテーブル２１３とを有する。
データ転送部２２０は、データ送受信部２２１を有する。データ送受信部２２１は、各メッセージの送受信を制御する。
データ記憶部２３０は、データ格納部２３１を有する。データ格納部２３１には、オブジェクト１１２が格納される。
通信ＩＦ２４０は、ノード内の各構成要素と、他装置に接続するためのネットワーク２５０とを仲介するインタフェースである。

制御処理部２００は、ノード管理部２０１と、発行転送テーブル作成部２０２と、発行転送テーブル検索部２０３と、予約転送テーブル作成部２０４と、予約転送テーブル検索部２０５と、格納データテーブル検索部２０６とを有する。
ノード管理部２０１は、発行メッセージおよび予約メッセージの送信要否を判断する。
格納データテーブル検索部２０６は、格納データテーブル２１３の検索を行うことで、データ格納部２３１内のオブジェクトの格納先を特定する。なお、格納データテーブル２１３には、oidと、そのoidが示すオブジェクトのデータ格納部２３１内での格納先を示す情報（ファイル名やデータＩＤなど）とが対応づけて記録されている。

以下に示すように、予約メッセージの経路を逆流するように、発行メッセージの経路（発行転送テーブル２１１）が設定される。
発行転送テーブル作成部２０２は、受信した予約メッセージをもとに、発行転送テーブル２１１を作成する。
発行転送テーブル検索部２０３は、受信した発行メッセージを転送するために、発行転送テーブル２１１からnexthopを検索する。
同様に、発行メッセージの経路を逆流するように、予約メッセージの経路（予約転送テーブル２１２）が設定される。
予約転送テーブル作成部２０４は、受信した発行メッセージをもとに、予約転送テーブル２１２を作成する。
予約転送テーブル検索部２０５は、受信した予約メッセージを転送するために、予約転送テーブル２１２からnexthopを検索する。

図４では、ノード１０３（nid=b）に格納されている各種テーブルを説明する。
図４（ａ）の発行転送テーブル２１１には、検索対象となるoidごとに、その次ホップのノードＩＤ（nexthop nid）が記録されている。なお、複数の予約者端末が特定のオブジェクトＩＤに予約している場合は、次ホップは複数記録されることもある（例えば、２行目の「nexthop nid=c,h」）。なお、「c,h」の「,」とは、２つの要素（cとh）とを列挙するときの区切り文字である。
発行転送テーブル検索部２０３は、発行メッセージ（message_type=publish）のヘッダに含まれる「req_oid=a.b.c」と一致する発行転送テーブル２１１のレコードを検索し、そのレコードのnexthop nid（=h）を発行メッセージの転送先（次ホップ）とする。なお、「a.b.c」の「.」とは、１つの要素を構成する３つの階層の区切り文字である（詳細は、oidの階層表現として後記）。
また、図１で示したノードの階層構造をPush型通信システムに反映させるために、転送テーブル（発行転送テーブル２１１、予約転送テーブル２１２）において、転送先が発見できなかったときのデフォルト（default）の転送先（次ホップ）として、自身のノードからみた上位ノード（nid=bからはnid=c）が設定される。

図４（ｂ）の予約転送テーブル２１２には、検索対象となるoidごとに、その次ホップのノードＩＤ（nexthop nid）が記録されている。
予約転送テーブル検索部２０５は、予約メッセージ（message_type=subscribe）のヘッダに含まれる「req_oid=a.b.c」と一致する予約転送テーブル２１２のレコードを検索し、そのレコードのnexthop nid（=a）を発行メッセージの転送先（次ホップ）とする。
予約転送テーブル検索部２０５も、発行転送テーブル検索部２０３と同様に、デフォルト（default）の転送先は、自身のノードからみた上位ノード（nid=bからはnid=c）である。

なお、発行メッセージおよび予約メッセージのヘッダには、メッセージを転送する際に参照するための情報が記録されており、ペイロードにはオブジェクト１１２のデータが記録されている。
各メッセージを作成するノードまたは端末は、以下に例示するようなヘッダを付与する。
１行目の「message_type」は、メッセージの種類として、発行メッセージを示す「publish」、予約メッセージを示す「subscribe」のいずれかが格納される。
２行目の「req_oid」は、発行対象または予約対象のオブジェクトＩＤを示す。
さらに、図示を省略したが、メッセージの送信元（発行者端末または予約者端末）を示す情報や、自身のメッセージが通過したノードの順序を示す情報（nid=a,b,c,eなど）を、ヘッダに含めてもよい。

ここで、oidの階層表現について、説明する。oid（＝a.b.cなど）は、複数の要素（例えば、oidではａとｂとｃ）が区切り記号(例えば「．」)により接続されている。このような階層表現では、例えば、先頭（左）にいくほど上位の階層を示し、末尾（右）にいくほど下位の階層を示す。そして、階層表現のエントリでの一致判定処理では、以下の（１）〜（３）のいずれかの結果を得る。

（１）一致しない場合：検索キー「a.b.c」と、検索対象「d.e.f」とでは、最先頭のエントリ「ａとｄ」の時点で不一致である。よって、検索キーと検索対象とでは、データ内容が共通する部分が存在しないため、不一致（部分一致も完全一致もしない）となる。
（２）部分一致する場合：検索キー「a.b.c」と、検索対象「a.b」とでは、先頭からの部分「a.b」は一致するが、末尾の「ｃ」は不一致である。このように、検索キー「a.b.c」の先頭から抽出した一部「a.b」と、検索対象「a.b」とが一致するときに、部分一致すると表現する。なお、階層表現「a.b.c」のうちの先頭から抽出した一部「a.b」のことを、以下では「プレフィックス」と呼ぶ。
（３）完全一致する場合：検索キー「a.b.c」と、検索対象「a.b.c」とでは、先頭から末尾まで一致する。このような場合を完全一致すると呼ぶ。

なお、検索キー「a.b.c」に対して、第１検索対象「ａ」、第２検索対象「a.b」、第３検索対象「a.b.c」が同じ転送テーブルに存在するときには、検索キー「a.b.c」に対する一致箇所が多い検索対象を、優先的に採用する（いわゆる「最長一致ルール」）。この例では、検索キー「a.b.c」の検索結果は、第３検索対象の完全一致が最優先され、次に第２検索対象の部分一致、最後に第１検索対象の部分一致となる。

図５は、第１予約メッセージのルーティング処理を示すシーケンス図である。
Ｓ３０１において、端末１１４のノード管理部２０１は、オブジェクト１１２（oid＝a.b.c）の予約を要求すると判断する。この判断の契機は、ユーザの操作や端末のタイマ、外部要因のトリガなどによる。
Ｓ３０２において、端末１１４のノード管理部２０１は、Ｓ３０１で判断された予約メッセージ（message_type= subscribe、req_oid=a.b.c）を、データ送受信部２２１を介してノード１０８に送信する。
以下、各ノードにおいて、（手順１ａ）、（手順２ａ）、（手順３ａ）の順に行われる。

（手順１ａ）発行転送テーブル作成部２０２は、自身より１つ上流側の隣接ノード（または隣接端末）から受信した予約メッセージをもとに、自身の発行転送テーブル２１１を更新（新規追加エントリのまたは既存エントリの書き換え）する（図５ではＳ３０３，Ｓ３０６，Ｓ３０９の発行転送テーブル更新）。
更新するエントリの「oid」＝予約メッセージに含まれる「req_oid」である。
更新するエントリの「nexthop nid」＝予約メッセージを送信してきた自身より１つ上流側の隣接ノード（または隣接端末）のnidである。。例えば、Ｓ３０６では、ノード１０７（nid=f）内の発行転送テーブル２１１について、自身（nid=f）より１つ上流側の隣接ノード（nid=g）のnidが、更新するエントリの「nexthop nid」である。

（手順２ａ）予約転送テーブル検索部２０５は、（手順１ａ）の予約メッセージに含まれる「req_oid」から予約転送テーブル２１２を検索することで、自身より１つ下流側の隣接ノード（または隣接端末）への転送先（nexthop nid）を特定する（図５ではＳ３０４，Ｓ３０７，Ｓ３１０の予約転送テーブル検索）。
例えば、Ｓ３０７では、ノード１０７（nid=f）内の予約転送テーブル２１２からは現時点ではまだ（oid＝a.b.c）と完全一致も部分一致もしないので、自身のノード（nid=f）からみた上位ノード（nid=e）が、デフォルト（default）の転送先として特定される。
（手順３ａ）データ送受信部２２１は、（手順２ａ）で特定した転送先に対して、通信ＩＦ２４０を介して予約メッセージを転送する（図５ではＳ３０５，Ｓ３０８）。

図１０および図１１は、図２で示した各メッセージの処理時点での各テーブル（発行転送テーブル２１１、予約転送テーブル２１２）の内容を、ノードごとに区別して記載するスナップショット図である。
図５の処理を実行することで、発行転送テーブル２１１の内容が図１０（ａ）のものから図１０（ｃ）のものへと更新される（図示した太字は今回の更新箇所）。破線矢印１９１の経路に沿って、第１予約メッセージが通過する各ノードの発行転送テーブル２１１の内容が、それぞれ（手順１ａ）で示したように更新されている。例えば、ノード１０７（nid=f）内の発行転送テーブル２１１には、すでに存在していた「default」のエントリに加え、Ｓ３０６の（手順１ａ）により（oid＝a.b.c、nexthop nid＝g）のエントリが追加される（図１０（ｃ））。

一方、図５の処理は、予約メッセージの送信処理なので、予約転送テーブル２１２の内容は、図５の処理実行前の内容を示す図１０（ｂ）のものから変化しない。
さらに、（手順２ａ）のＳ３１０において、（手順３ａ）に移行せずに処理を終了する理由は、ノード１０６（nid=e）内の発行転送テーブル２１１に、自身をnexthop nidとする（oid＝a.b）のエントリ（oid＝a.b.cと部分一致するエントリ）が存在するためである（詳細は、後記の図１２のＳ１１５を参照）。

図６は、第１発行メッセージのルーティング処理を示すシーケンス図である。
Ｓ４０１において、端末１０１のノード管理部２０１は、オブジェクト１１２（oid＝a.b.c）の発行を要求すると判断する。この判断の契機は、ユーザの操作や端末のタイマ、外部要因のトリガなどによる。
Ｓ４０２において、端末１０１のノード管理部２０１は、Ｓ４０１で判断された発行メッセージ（message_type=publish、req_oid=a.b.c、オブジェクト１１２をペイロードに追加）を、データ送受信部２２１を介してノード１０２に送信する。
以下、各ノードにおいて、（手順１ｂ）、（手順２ｂ）、（手順３ｂ）の順に行われる。

（手順１ｂ）予約転送テーブル作成部２０４は、自身より１つ上流側の隣接ノード（または隣接端末）から受信した発行メッセージをもとに、自身の予約転送テーブル２１２を更新（新規追加エントリのまたは既存エントリの書き換え）する（図６ではＳ４０３，Ｓ４０６，Ｓ４０９，Ｓ４１２の予約転送テーブル更新）。
更新するエントリの「oid」＝発行メッセージに含まれる「req_oid」である。
更新するエントリの「nexthop nid」＝発行メッセージを送信してきた自身より１つ上流側の隣接ノード（または隣接端末）のnidである。。例えば、Ｓ４０６では、ノード１０３（nid=b）内の予約転送テーブル２１２について、自身（nid=b）より１つ上流側の隣接ノード（nid=a）のnidが、更新するエントリの「nexthop nid」である。

（手順２ｂ）発行転送テーブル検索部２０３は、（手順１ｂ）の発行メッセージに含まれる「req_oid」から発行転送テーブル２１１を検索することで、自身より１つ下流側の隣接ノード（または隣接端末）への転送先（nexthop nid）を特定する（図６ではＳ４０４，Ｓ４０７，Ｓ４１０，Ｓ４１３の発行転送テーブル検索）。
例えば、Ｓ４０７では、ノード１０３（nid=b）内の発行転送テーブル２１１からは現時点ではまだ（oid＝a.b.c）と完全一致も部分一致もしないので、自身のノード（nid=b）からみた上位ノード（nid=c）が、デフォルト（default）の転送先として特定される。
（手順３ｂ）データ送受信部２２１は、（手順２ｂ）で特定した転送先に対して、通信ＩＦ２４０を介して発行メッセージを転送する（図６ではＳ４０５，Ｓ４０８，Ｓ４１１）。

図１０（ｄ）は、図６の処理実行後の予約転送テーブル２１２を示す。図６の処理実行前である図１０（ｂ）と比較すると、第１発行メッセージの経路（端末１０１→nid=a→b→c→e、図２の実線矢印１９２）上の各ノードに対して、（手順１ｂ）による予約転送テーブル２１２の更新処理（oid＝a.b.cのエントリ追加処理）が行われている。

図７は、第２発行メッセージのルーティング処理を示すシーケンス図である。ノード１０６（nid=e）から端末１１４までの第２発行メッセージの経路上の各装置は、Ｓ４１１で受信した第１発行メッセージを第２発行メッセージとして、第１予約メッセージの経路（破線矢印１９１）を逆流するように、転送する。
（手順１ｂ）の予約転送テーブル２１２の更新処理は、Ｓ５０２，Ｓ５０５，Ｓ５０８である。
（手順２ｂ）の発行転送テーブル２１１の検索処理は、Ｓ５０３，Ｓ５０６，Ｓ５０９である。
（手順３ｂ）の発行メッセージの転送処理は、Ｓ５０１，Ｓ５０４，Ｓ５０７である。

図１１（ａ）は、図７の処理実行後の予約転送テーブル２１２を示す。図７の処理実行前である図１０（ｄ）と比較すると、第２発行メッセージの経路上であるnid=f,gの各ノードに対して、（手順１ｂ）による予約転送テーブル２１２の更新処理（oid＝a.b.cのエントリ追加処理）が行われている。

図８は、第２予約メッセージのルーティング処理を示すシーケンス図である。
Ｓ６０１において、Ｓ３０１と同様に、端末１１３のノード管理部２０１は、オブジェクト１１２（oid＝a.b.c）の予約を要求すると判断する。
そして、端末１１３からノード１０３（nid=b）までの第２予約メッセージの経路（破線矢印１９４）上の各装置は、Ｓ６０１で判断された第２予約メッセージを転送する。
（手順１ａ）の発行転送テーブル２１１の更新処理は、Ｓ６０３，Ｓ６０６の発行転送テーブル更新である。
（手順２ａ）の予約転送テーブル２１２の検索処理は、Ｓ６０４，Ｓ６０７の予約転送テーブル検索である。
（手順３ａ）の予約メッセージの転送処理は、Ｓ６０２，Ｓ６０５である。

なお、Ｓ６０７において、ノード１０３（nid=b）の予約転送テーブル検索部２０５は、予約転送テーブル２１２内にoid=a.b.cと完全一致するエントリが存在することにより、発行メッセージの転送処理を終了する（後記図１２のＳ１１３の中断処理）。
または、ノード１０３（nid=b）のデータ送受信部２２１は、完全一致するエントリが示す「nexthop nid」（ここでは、nid=a）へ、発行メッセージの転送処理を継続してもよい（後記図１２のＳ１１３の転送処理）。継続（延長）された第２予約メッセージの転送処理は、破線矢印１９５が示すように、発行者端末である端末１０１に届く。

図１１（ｂ）は、図８の処理実行後の発行転送テーブル２１１を示す。図８の処理実行前である図１０（ｃ）と比較すると、第２予約メッセージの経路上であるnid=a,b,hの各ノードに対して、（手順１ｂ）による発行転送テーブル２１１の更新処理（oid＝a.b.cのエントリ追加処理）が行われている。

図９は、第３発行メッセージのルーティング処理を示すシーケンス図である。
第３発行メッセージは、第１発行メッセージの途中（nid=b）から分岐して、実線矢印１９６の経路に従って、第２予約メッセージの送信者（予約者端末）である端末１１３まで届く。
Ｓ７０１〜Ｓ７０６は、Ｓ４０１〜Ｓ４０６と同じ処理（第１発行メッセージの分岐前）である。
Ｓ７０７において、ノード１０３（nid=b）の発行転送テーブル検索部２０３は、自身の発行転送テーブル２１１を参照して、第１発行メッセージの転送先が２つ（oid=defaultのときのnexthop nid=cと、oid=a.b.cのときのnexthop nid=h）存在するので、同じ発行メッセージを、nid=cに送信する第１発行メッセージと、nid=hに送信する第３発行メッセージとに分岐（コピー）させる。

以下、第３発行メッセージは、第２予約メッセージの経路を逆流するように、端末１１３まで届く。
（手順１ｂ）の予約転送テーブル２１２の更新処理は、Ｓ７０９である。
（手順２ｂ）の発行転送テーブル２１１の検索処理は、Ｓ７１０である。
（手順３ｂ）の発行メッセージの転送処理は、Ｓ７０８，Ｓ７１１である。

図１１（ｃ）は、図９の処理実行後の予約転送テーブル２１２を示す。図９の処理実行前である図１１（ａ）と比較すると、第３発行メッセージの経路上であるnid=hのノードに対して、（手順１ａ）による予約転送テーブル２１２の更新処理（oid＝a.b.cのエントリ追加処理）が行われている。

図１２は、各ノード装置の処理を示すフローチャートである。
する。
Ｓ１０１として、データ送受信部２２１は、要求メッセージを受信する。
Ｓ１０２として、ノード管理部２０１は、Ｓ１０１で受信した要求メッセージのタイプ（message_type）により、予約メッセージならＳ１１１に進み、発行メッセージならＳ１２１に進む。

Ｓ１１１として、発行転送テーブル作成部２０２は、Ｓ１０１の予約メッセージの転送元をnexthopとして発行転送テーブル２１１にエントリ追加する（手順１ａ）。
Ｓ１１２として、予約転送テーブル検索部２０５は、予約転送テーブル２１２から予約メッセージのoidと完全一致するエントリが存在するか否かを判定する。Ｓ１１２でＹｅｓならＳ１１３に進み、ＮｏならＳ１１４に進む。
Ｓ１１３として、データ送受信部２２１は、Ｓ１１２の完全一致するエントリのnexthopに対して、予約メッセージを転送する。または、データ送受信部２２１は、転送処理を中断し（実施せず）、処理を終了してもよい。

Ｓ１１４として、予約転送テーブル検索部２０５は、予約転送テーブル２１２から予約メッセージのoidと部分一致するエントリが存在するか否かを判定する。Ｓ１１４でＹｅｓならＳ１１５に進み、ＮｏならＳ１１７に進む。
Ｓ１１５として、予約転送テーブル検索部２０５は、Ｓ１１４で部分一致したエントリについて、自身がnexthopであるか否かを判定する。Ｓ１１５でＹｅｓなら処理を終了し、ＮｏならＳ１１６に進む。
Ｓ１１６として、データ送受信部２２１は、Ｓ１１４の部分一致するエントリのnexthopに対して、予約メッセージを転送する。
Ｓ１１７として、データ送受信部２２１は、defaultエントリのnexthopに対して、予約メッセージを転送する。

Ｓ１２１として、予約転送テーブル作成部２０４は、Ｓ１０１の発行メッセージの転送元をnexthopとして予約転送テーブル２１２にエントリ追加する（手順１ｂ）。
Ｓ１２２として、発行転送テーブル検索部２０３は、発行転送テーブル２１１から発行メッセージのoidと完全一致するエントリが存在するか否かを判定する。Ｓ１２２でＹｅｓならＳ１２３に進み、ＮｏならＳ１２４に進む。
Ｓ１２３として、データ送受信部２２１は、Ｓ１２２の完全一致するエントリのnexthopに対して、発行メッセージを転送し、Ｓ１２３へ進む。

Ｓ１２４として、発行転送テーブル検索部２０３は、発行転送テーブル２１１から発行メッセージのoidと部分一致するエントリが存在するか否かを判定する。Ｓ１２４でＹｅｓならＳ１２５に進み、ＮｏならＳ１２７に進む。
Ｓ１２５として、発行転送テーブル検索部２０３は、Ｓ１２４で部分一致したエントリについて、自身がnexthopであるか否かを判定する。Ｓ１２５でＹｅｓなら処理を終了し、ＮｏならＳ１２６に進む。
Ｓ１２６として、データ送受信部２２１は、Ｓ１２４の部分一致するエントリのnexthopに対して、発行メッセージを転送する。
Ｓ１２７として、データ送受信部２２１は、defaultエントリのnexthopに対して、発行メッセージを転送する。

以上説明した本実施形態では、発行メッセージをルーティングする際にルーティング情報を予約転送テーブル２１２に記録し、記録した予約転送テーブル２１２のルーティング情報に基づいて予約メッセージをルーティングすることを主な特徴とする。
これにより、発行メッセージと予約メッセージとをマッチングさせる方式に比べ、予約メッセージの経路がマッチングノードを経由せずに分散されるので、マッチングノードへの負荷集中によるPush型通信システムの性能劣化を抑制できる。

一方、従来のPush型の通信システムにおいて、予約メッセージの送信頻度が高い場合、マッチングノードに予約メッセージが集中するため、多大なトランザクション負荷が発生する。
例えば、非特許文献１では、Subscribeメッセージが階層型ＤＨＴ（Distributed Hash Table）の名前解決を行うノード（名前解決ノード）に到達することによってSubscriberの位置ＩＤが登録されるが、Subscribeメッセージの送信頻度が高い場合、この名前解決ノードのトランザクション負荷が大きくなる。
非特許文献２では、Subscribeメッセージは階層型トポロジの最上位にあるルートノードにSubscribeメッセージが集中し、トランザクション負荷が大きくなる。
非特許文献３では、Rendezvous SystemにSubscribeメッセージが集中し、トランザクション負荷が大きくなる。
特許文献１では、Subscribeによる経路情報の更新をノード間でブロードキャストなどを用いて交換するため、大量のトランザクションが発生し、負荷が大きくなる。

しかし、本実施形態では、ノード１０３（nid=b）において第１発行メッセージの経路に合流した第２予約メッセージは、第１予約メッセージと同じノード１０６（nid=e）に向かわずに、第２予約メッセージの転送を中断するか、発行者端末である端末１０１に向かうため、ノード１０６（nid=e）に対する予約メッセージの集中を抑制できる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。
また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段などは、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。
また、前記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）などの記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤカード、ＤＶＤ（Digital Versatile Disc）などの記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１０１ 端末（発行者端末）
１０２〜１１１，１１５ ノード
１１２ オブジェクト
１１３，１１４ 端末（予約者端末）
２００ 制御処理部
２０１ ノード管理部
２０２ 発行転送テーブル作成部
２０３ 発行転送テーブル検索部
２０４ 予約転送テーブル作成部
２０５ 予約転送テーブル検索部
２０６ 格納データテーブル検索部
２１０ 制御データ記憶部
２１１ 発行転送テーブル
２１２ 予約転送テーブル
２１３ 格納データテーブル
２２０ データ転送部
２２１ データ送受信部
２３０ データ記憶部
２３１ データ格納部
２４０ 通信ＩＦ
２５０ ネットワーク

Claims (10)

1. 複数のノードがネットワークで接続されて構成される通信システムに用いられる前記複数のノードのうちの第１ノードが、オブジェクトの送信を要求するための発行メッセージを発行者端末から受信し、
   前記第１ノードから前記複数のノードのうちの第２ノードまでの各ノードは、
   前記発行メッセージの転送先である次ホップのノードを示す第１ルーティング情報が、自身の記憶手段に記録されており、
   前記第１ルーティング情報から取得した次ホップに向けて、前記発行メッセージを転送する第１ルーティングを行うとともに、
   前記第１ルーティングで転送する前記発行メッセージのオブジェクトＩＤと、その発行メッセージを自身に向けて転送した隣接ノードを次ホップとする第２ルーティング情報を自身の記憶手段に記録し、
   前記複数のノードのうちの第３ノードが、前記オブジェクトの受信を要求するための予約メッセージを予約者端末から受信し、
   前記第３ノードから前記第１ノードまでの各ノードは、
   前記第２ルーティング情報から前記予約メッセージのオブジェクトＩＤを検索して取得した次ホップまたは事前に設定されているデフォルトの次ホップに向けて、前記予約メッセージを転送する第２ルーティングを行うとともに、
   前記第２ルーティングで転送する前記予約メッセージのオブジェクトＩＤと、その予約メッセージを自身に向けて転送した隣接ノードを次ホップとする第３ルーティング情報を自身の記憶手段に記録することを特徴とする
   通信システム。
2. 前記第１ノードが、前記オブジェクトの発行メッセージを発行者端末から再度受信し、
   前記第１ノードから前記第３ノードまでの各ノードは、
   前記第３ルーティング情報から前記再度受信した発行メッセージのオブジェクトＩＤを検索して取得した次ホップに向けて、前記再度受信した発行メッセージを転送する第３ルーティングを行うことを特徴とする
   請求項１に記載の通信システム。
3. 前記第２ルーティングを行う前記第３ノードから前記第１ノードまでのノードのうち、前記第２ルーティング情報から前記予約メッセージのオブジェクトＩＤを検索できたノードは、前記第２ルーティングを中断することを特徴とする
   請求項１または請求項２に記載の通信システム。
4. 前記第３ルーティングを行う前記第３ノードから前記第１ノードまでのノードのうち、前記第３ルーティング情報から複数の次ホップを検索したノードは、その検索した前記複数のノードそれぞれに対して、受信した受信した前記発行メッセージをコピーして転送することを特徴とする
   請求項２に記載の通信システム。
5. 複数のノードがネットワークで接続されて構成される通信システムに用いられ、
   オブジェクトの送信を要求するための発行メッセージのオブジェクトＩＤと、その発行メッセージの予約者端末に向かう転送先である次ホップとを対応づける発行転送テーブルと、
   前記オブジェクトの受信を要求するための予約メッセージのオブジェクトＩＤと、その予約メッセージの発行者端末に向かう転送先である次ホップとを対応づける予約転送テーブルとを記憶するための記憶手段と、
   受信した前記発行メッセージに対して、その発行メッセージのオブジェクトＩＤと、その発行メッセージを自身に向けて転送した隣接ノードを次ホップとして対応づけて前記予約転送テーブルに格納する予約転送テーブル作成部と、
   前記発行転送テーブルから前記発行メッセージのオブジェクトＩＤを検索して、前記発行メッセージを転送する次ホップを特定する発行転送テーブル検索部と、
   受信した前記予約メッセージに対して、その予約メッセージのオブジェクトＩＤと、その予約メッセージを自身に向けて転送した隣接ノードを次ホップとして対応づけて前記発行転送テーブルに格納する発行転送テーブル作成部と、
   前記予約転送テーブルから前記予約メッセージのオブジェクトＩＤを検索して、前記予約メッセージを転送する次ホップを特定する予約転送テーブル検索部と、を有することを特徴とする
   ノード装置。
6. 請求項５に記載のノード装置を、前記予約転送テーブル作成部と、前記発行転送テーブル検索部と、前記発行転送テーブル作成部と、前記予約転送テーブル検索部として機能させるための
   ノードプログラム。
7. 複数のノードがネットワークで接続されて構成される通信システムに用いられる前記複数のノードに読み込まれ、実行されることで、
   前記複数のノードのうちの第１ノードに、オブジェクトの送信を要求するための発行メッセージを発行者端末から受信させ、
   前記第１ノードから前記複数のノードのうちの第２ノードまでの各ノードに、
   前記発行メッセージの転送先である次ホップのノードを示す第１ルーティング情報を、自身の記憶手段に記録させ、
   前記第１ルーティング情報から取得した次ホップに向けて、前記発行メッセージを転送する第１ルーティングを行わせるとともに、
   前記第１ルーティングで転送する前記発行メッセージのオブジェクトＩＤと、その発行メッセージを自身に向けて転送した隣接ノードを次ホップとする第２ルーティング情報を自身の記憶手段に記録させ、
   前記複数のノードのうちの第３ノードに、前記オブジェクトの受信を要求するための予約メッセージを予約者端末から受信させ、
   前記第３ノードから前記第１ノードまでの各ノードに、
   前記第２ルーティング情報から前記予約メッセージのオブジェクトＩＤを検索して取得した次ホップまたは事前に設定されているデフォルトの次ホップに向けて、前記予約メッセージを転送する第２ルーティングを行わせるとともに、
   前記第２ルーティングで転送する前記予約メッセージのオブジェクトＩＤと、その予約メッセージを自身に向けて転送した隣接ノードを次ホップとする第３ルーティング情報を自身の記憶手段に記録させることを特徴とする
   通信プログラム。
8. 前記第１ノードに、前記オブジェクトの発行メッセージを発行者端末から再度受信させ、
   前記第１ノードから前記第３ノードまでの各ノードに、
   前記第３ルーティング情報から前記再度受信した発行メッセージのオブジェクトＩＤを検索して取得した次ホップに向けて、前記再度受信した発行メッセージを転送する第３ルーティングを行わせることを特徴とする
   請求項７に記載の通信プログラム。
9. 前記第２ルーティングを行う前記第３ノードから前記第１ノードまでのノードのうち、前記第２ルーティング情報から前記予約メッセージのオブジェクトＩＤを検索できたノードに、前記第２ルーティングを中断させることを特徴とする
   請求項７または請求項８に記載の通信プログラム。
10. 前記第３ルーティングを行う前記第３ノードから前記第１ノードまでのノードのうち、前記第３ルーティング情報から複数の次ホップを検索したノードに、その検索した前記複数のノードそれぞれに対して、受信した受信した前記発行メッセージをコピーして転送させることを特徴とする
    請求項８に記載の通信プログラム。

Images