(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO2013103040
(43)【国際公開日】20130711
【発行日】20150511
(54)【発明の名称】データ指向型通信システム、ノード、および、データ転送方法
(51)【国際特許分類】
   H04L 12/701 20130101AFI20150414BHJP
   H04L 12/70 20130101ALI20150414BHJP
【FI】
   !H04L12/701
   !H04L12/70 B
【審査請求】有
【予備審査請求】未請求
【全頁数】36
【出願番号】2013552390
(21)【国際出願番号】JP2012076697
(22)【国際出願日】20121016
(31)【優先権主張番号】2012000590
(32)【優先日】20120105
(33)【優先権主張国】JP
(31)【優先権主張番号】2012160104
(32)【優先日】20120719
(33)【優先権主張国】JP
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IS,JP,KE,KG,KM,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US,UZ,VC
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成23年度 独立行政法人情報通信研究機構「新世代ネットワークを支えるネットワーク仮想化基盤技術の研究開発 課題ウ 新世代ネットワークアプリケーションの研究開発」委託研究、産業技術力強化法第19条の適用を受ける特許出願
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
【住所又は居所】東京都千代田区丸の内一丁目6番6号
(74)【代理人】
【識別番号】100064414
【弁理士】
【氏名又は名称】磯野 道造
(74)【代理人】
【識別番号】100111545
【弁理士】
【氏名又は名称】多田 悦夫
(72)【発明者】
【氏名】松原 大典
【住所又は居所】東京都千代田区丸の内一丁目6番6号 株式会社日立製作所内
(72)【発明者】
【氏名】藪▲崎▼ 仁史
【住所又は居所】東京都千代田区丸の内一丁目6番6号 株式会社日立製作所内
(72)【発明者】
【氏名】東村 邦彦
【住所又は居所】東京都千代田区丸の内一丁目6番6号 株式会社日立製作所内
(72)【発明者】
【氏名】武田 幸子
【住所又は居所】東京都千代田区丸の内一丁目6番6号 株式会社日立製作所内
【テーマコード(参考)】
5K030
【Fターム(参考)】
5K030HA08
5K030HC01
5K030HC20
5K030JT02
5K030JT09
5K030LB05
(57)【要約】
ノード(1)は、オブジェクト要求メッセージに転送先のロケーションIDが含まれているときには、その転送先のロケーションIDを検索キーとして、自身のロケーションID転送テーブル(13)を検索し、得られた次ホップのノード(1)へとオブジェクト要求メッセージを転送し、オブジェクト要求メッセージに転送先のロケーションIDが含まれていないときには、オブジェクト要求メッセージに含まれるオブジェクトIDを検索キーとして、自身のオブジェクトID転送テーブル(11)を検索し、検索結果としての次ホップへとオブジェクト要求メッセージを転送する。
【特許請求の範囲】
【請求項1】
複数のノードがネットワークで接続されて構成され、
前記複数のノードのうちの第1ノードが、端末からのオブジェクトを取得するための要求メッセージを受信し、
前記第1ノードから名前解決を行う前記複数のノードのうちの第2ノードまでの各ノードが、オブジェクトの識別子である階層化されたオブジェクトIDとルーティング情報とを用いて前記要求メッセージのルーティングを行い、
前記第2ノードが、名前解決情報を参照して、前記要求メッセージの前記オブジェクトIDからオブジェクトを保持する前記複数のノードのうちの第3ノードのロケーションIDへの変換を行い、
前記第2ノードから前記第3ノードまでの各ノードが、変換された前記ロケーションIDを用いて、前記要求メッセージのルーティングを行い、
前記第3ノードが、自身にてオブジェクトを取得し、
前記第3ノードから前記第1ノードまでの各ノードが、取得したオブジェクトを含む返送メッセージのルーティングを行うことで、前記端末が前記要求メッセージで要求したオブジェクトを、前記第1ノードから取得することを特徴とする
データ指向型通信システム。
【請求項2】
前記返送メッセージのルーティングを行う各ノードが、前記返送メッセージに含まれる前記オブジェクトIDの前記ルーティング情報を自身に記憶し、その記憶された前記ルーティング情報を用いて前記オブジェクトIDのルーティングを実行することを特徴とする
請求の範囲第1項に記載のデータ指向型通信システム。
【請求項3】
前記返送メッセージのルーティングを行う各ノードが、前記要求メッセージに含まれる経路情報に基づいて前記要求メッセージが経由するノードを識別し、経由するノードのうち経路を縮小できる短縮経路のノードを選択し、前記短縮経路のノードを前記ルーティング情報として自身に記憶することを特徴とする
請求の範囲第1項に記載のデータ指向型通信システム。
【請求項4】
前記第1ノードから前記第2ノードまでの各ノードは、オブジェクトの登録するための登録メッセージをルーティングするとともに、その前記登録メッセージの前記オブジェクトIDの前記ルーティング情報を自身に記憶し、
前記第2ノードは、前記登録メッセージの前記オブジェクトIDと、そのオブジェクトが登録されたノードの前記ロケーションIDとを前記名前解決情報として自身に記憶することを特徴とする
請求の範囲第1項に記載のデータ指向型通信システム。
【請求項5】
前記第2ノードは、新たな前記登録メッセージによる前記名前解決情報を自身に記憶する処理において、前記新たな登録メッセージに基づく前記名前解決情報の前記オブジェクトIDと、過去の前記登録メッセージに基づく前記名前解決情報の前記オブジェクトIDとが一致するときには、前記過去の登録メッセージの前記オブジェクトIDを含めて、前記過去の登録メッセージによって記憶された前記ルーティング情報を修正するための修正メッセージを発行し、
前記修正メッセージを受信した前記過去の登録メッセージの経路上の各ノードは、自身に記憶されている前記ルーティング情報のうちの、前記名前解決情報の前記オブジェクトIDが前記修正メッセージの前記オブジェクトIDと一致するエントリを修正することを特徴とする
請求の範囲第4項に記載のデータ指向型通信システム。
【請求項6】
前記第2ノードは、前記修正メッセージを送信した後に、その修正メッセージへのACKを受信した後に、前記送信した修正メッセージとは別の新たな修正メッセージを送信することを特徴とする
請求の範囲第5項に記載のデータ指向型通信システム。
【請求項7】
前記第2ノードは、前記修正メッセージを送信した後に、前記修正メッセージへのACKの受信に失敗したときは、前記登録メッセージへのACKとして、前記オブジェクトの登録失敗を通知することを特徴とする
請求の範囲第5項に記載のデータ指向型通信システム。
【請求項8】
前記修正メッセージを受信した前記過去の登録メッセージの経路上の各ノードは、前記オブジェクトIDが一致するエントリを、自身に格納されている前記ルーティング情報から削除する旨の修正処理を実行することを特徴とする
請求の範囲第5項ないし第7項のいずれか1項に記載のデータ指向型通信システム。
【請求項9】
前記修正メッセージを受信した前記過去の登録メッセージの経路上の各ノードは、前記オブジェクトIDが一致するエントリについて、自身に格納されている前記ルーティング情報の次ホップを、前記新たな登録メッセージにより前記名前解決情報を記憶した前記第2ノードへ向かうためのノードに更新する旨の修正処理を実行することを特徴とする
請求の範囲第5項ないし第7項のいずれか1項に記載のデータ指向型通信システム。
【請求項10】
各ノードが接続されて形成されるデータ指向型ネットワークにおいて、そのノード内に格納されるオブジェクトにアクセスするためのデータ指向型通信システムに用いられ、
前記各ノードの記憶手段には、
前記オブジェクトを識別するためのオブジェクトIDと、所定のノードへ向かう次ホップの前記ノードとを対応づけるオブジェクトID転送テーブルと、
転送先の前記ノードを示すロケーションIDと、その転送先の前記ノードへ向かう次ホップの前記ノードとを対応づけるロケーションID転送テーブルと、がそれぞれ記憶されており、
前記所定のノードは、前記オブジェクトIDから、そのオブジェクトが格納される前記ノードを示す前記ロケーションIDへの名前解決を実行する前記ノードであり、
前記オブジェクトIDが指定されており、そのオブジェクトを取得するためのオブジェクト要求メッセージを受信した前記ノードは、
前記オブジェクト要求メッセージに転送先の前記ロケーションIDが含まれているときには、その転送先の前記ロケーションIDを検索キーとして、自身の前記ロケーションID転送テーブルを検索し、得られた次ホップの前記ノードへと前記オブジェクト要求メッセージを転送し、
前記オブジェクト要求メッセージに転送先の前記ロケーションIDが含まれていないときには、前記オブジェクト要求メッセージに含まれる前記オブジェクトIDを検索キーとして、自身の前記オブジェクトID転送テーブルを検索し、
検索結果として自身が前記所定のノードであるときには、前記オブジェクトIDから、そのオブジェクトが格納される前記ノードを示す前記ロケーションIDへの名前解決を実行し、得られた前記ロケーションIDを前記オブジェクト要求メッセージに付加し、
検索結果として次ホップである他装置の前記ノードが存在するときには、その他装置の前記ノードへと前記オブジェクト要求メッセージを転送することを特徴とする
ノード。
【請求項11】
前記オブジェクト要求メッセージを受信した前記ノードのうちの、前記オブジェクト要求メッセージに含まれる転送先の前記ロケーションIDが自身である前記ノードは、自身の前記記憶手段から前記オブジェクト要求メッセージで指定された前記オブジェクトを読み込み、そのオブジェクトを含むオブジェクト返送メッセージを作成し、前記オブジェクト要求メッセージの送信元に向けて返送し、
前記オブジェクト返送メッセージを受信した前記各ノードは、受信した前記オブジェクト返送メッセージを前記オブジェクト要求メッセージの送信元に向けて転送するとともに、前記オブジェクト返送メッセージに含まれる前記オブジェクトの前記オブジェクトIDと、前記オブジェクト返送メッセージの受信元である前記ノードを次ホップとして対応づけて、前記オブジェクトID転送テーブルにエントリ追加することを特徴とする
請求の範囲第10項に記載のノード。
【請求項12】
前記オブジェクト返送メッセージを受信した前記各ノードは、前記オブジェクトID転送テーブルにエントリ追加する処理において、対応づける次ホップの前記ノードとして、前記オブジェクト返送メッセージの受信元の代わりに、そのオブジェクト返送メッセージの受信元よりも前記所定のノードに近い前記ノードであり、かつ、自身から直接接続されている前記ノードを、対応づける次ホップの前記ノードとすることを特徴とする
請求の範囲第11項に記載のノード。
【請求項13】
前記オブジェクト要求メッセージにより要求される前記オブジェクトを、前記ノード内に格納するためのオブジェクト登録メッセージを受信した前記各ノードは、
前記オブジェクト登録メッセージを前記所定のノードへ向かう次ホップの前記ノードへと転送するとともに、前記オブジェクト登録メッセージで登録対象となる前記オブジェクトの前記オブジェクトIDと、前記オブジェクト登録メッセージの転送先である次ホップとを対応づけて、自身の前記オブジェクトID転送テーブルに新規エントリとして追加することを特徴とする
請求の範囲第10項ないし第12項のいずれか1項に記載のノード。
【請求項14】
各ノードが接続されて形成されるデータ指向型ネットワークにおいて、そのノード内に格納されるオブジェクトにアクセスするためのデータ指向型通信システムにより実行され、
前記各ノードの記憶手段には、
前記オブジェクトを識別するためのオブジェクトIDと、所定のノードへ向かう次ホップの前記ノードとを対応づけるオブジェクトID転送テーブルと、
転送先の前記ノードを示すロケーションIDと、その転送先の前記ノードへ向かう次ホップの前記ノードとを対応づけるロケーションID転送テーブルと、がそれぞれ記憶されており、
前記所定のノードは、前記オブジェクトIDから、そのオブジェクトが格納される前記ノードを示す前記ロケーションIDへの名前解決を実行する前記ノードであり、
前記オブジェクトIDが指定されており、そのオブジェクトを取得するためのオブジェクト要求メッセージを受信した前記ノードは、
前記オブジェクト要求メッセージに転送先の前記ロケーションIDが含まれているときには、その転送先の前記ロケーションIDを検索キーとして、自身の前記ロケーションID転送テーブルを検索し、得られた次ホップの前記ノードへと前記オブジェクト要求メッセージを転送し、
前記オブジェクト要求メッセージに転送先の前記ロケーションIDが含まれていないときには、前記オブジェクト要求メッセージに含まれる前記オブジェクトIDを検索キーとして、自身の前記オブジェクトID転送テーブルを検索し、
検索結果として自身が前記所定のノードであるときには、前記オブジェクトIDから、そのオブジェクトが格納される前記ノードを示す前記ロケーションIDへの名前解決を実行し、得られた前記ロケーションIDを前記オブジェクト要求メッセージに付加し、
検索結果として次ホップである他装置の前記ノードが存在するときには、その他装置の前記ノードへと前記オブジェクト要求メッセージを転送することを特徴とする
データ転送方法。
【発明の詳細な説明】
【参照による取り込み】
【0001】
本出願は、2012年1月5日に出願された日本特許願第2012−590号の優先権、および、2012年7月19日に出願された日本特許願第2012−160104号の優先権を主張し、その内容を参照することにより本出願に取り込む。
【技術分野】
【0002】
本発明は、データ指向型通信システム、ノード、および、データ転送方法に関する。
【背景技術】
【0003】
IP(Internet Protocol)ネットワークでは、ネットワーク上の位置(location)を示す識別子であるIPアドレスを用いて通信を行うノードの位置を特定する。そのIPアドレスを特定するための手がかりとして、所望のデータのURI(Uniform Resource Identifier)から抽出されたホストID(Host Name)などが存在する。
【0004】
DNS(Domain Name System)は、ホストIDを検索キーとして、そのホストIDが示す位置IDを特定するための名前解決サービスである。よって、端末は、DNSから通知されたIPアドレスを用いて、宛先のノードに対して通信を行う。
【0005】
データ指向型ネットワーク(DCN:Data-centric Network)とは、データID(オブジェクトID)を用いて所望のオブジェクトまで、データ要求をルーティングするためのネットワークである。
ここでいうオブジェクトとは、映像データ、音楽データなどのマルチメディア形式のファイルから、Webページに代表されるテキストデータ、更にはセンサデータや機器状態の監視データなどのMachine-to-Machine(M2M)通信向けデータなど、ネットワークを経由してアクセスできるあらゆるデータを意味する。データID(オブジェクトID)はそのオブジェクトを示す識別子を意味する。
【0006】
従来のIPネットワークでは、前記のようにネットワーク上の位置を示す識別子であるIPアドレスを用いてルーティングを行うが、データ指向型ネットワークではデータIDを用いてルーティングする。IPアドレスはオブジェクトの位置が変わるごとに変化するが、データIDはオブジェクトの位置に依存しない。
【0007】
IPネットワークはDNSなどの名前解決サービスを利用してURIやホストIDからIPアドレスを特定した後にルーティングを行う必要があるが、データ指向型ネットワークではデータIDを指定すれば適切なオブジェクト(またはその複製)にルーティングが行われる。このため、データ指向型ネットワークはオブジェクトが移動したり、ネットワーク内にオブジェクトの複製が分散して配置される場合に、IPネットワークより効率的に通信ができる。
【0008】
非特許文献1には、オブジェクトIDを位置IDへマッピングするためのサービス(GNRS:Global Name Resolution Service)にアクセスする方式が、記載されている。
非特許文献2には、階層型DHT(Distributed Hash Table)によってホストIDから位置IDへの変換を行う方式が、記載されている。
【0009】
一方、名前解決をせずに、データIDそのものを位置IDとみなして通信を行う方式も提案されている。特許文献1では、データIDを用いたルーティング機能をネットワークが持つことで、位置IDを用いずに所望のオブジェクトを取得するネットワーク方式が述べられている。
【先行技術文献】
【特許文献】
【0010】
【特許文献1】特開2009−278624号公報
【非特許文献】
【0011】
【非特許文献1】Samuel C. Nelson, Gautam Bhanage, Dipankar Raychaudhuri, GSTAR: Generalized Storage-Aware Routing for MobilityFirst in the Future Mobile Internet, MobiArch’11, June 28, 2011.
【非特許文献2】Matteo D’Ambrosio, et al., D-6.2 Second NetInf Architecture Description, The FP7 4WARD Project, January 14, 2010.
【発明の概要】
【発明が解決しようとする課題】
【0012】
一方、データを保持する端末やデータ自身が頻繁に移動する場合も多い。例えば、センサや機器が無線アクセスを経由してネットワークに接続されて様々な情報を発信し、それらの情報をネットワークに接続された他の端末が取得・活用する場合がある。また、Webサーバなど端末がアクセスするホストも、サーバの仮想化技術などによって遠隔の場所に移動する場合もある。
【0013】
このように、名前解決の手がかり情報(ホストIDやデータIDなど)が変わらなくても、名前解決の結果である位置IDが時間経過により更新されると、ある時点での1回の名前解決を行って得た位置IDを使用できる期間が短期間になってしまう。
しかし、データの位置が時間経過により更新され続ける状況で、効率的にデータ通信を行う手法は、提案されていない。
【0014】
まず、非特許文献1や非特許文献2などの名前解決サービスを提供する方式では、名前解決をしてからデータ通信を開始するため、位置IDが更新される状況下では、毎回前準備として名前解決を行う必要があり、データ通信を開始するまで待たされてしまう。
【0015】
次に、特許文献1に記載されたデータIDそのものを位置IDとみなす方式では、たしかに、名前解決を行う前準備は不要になり、データ通信の開始時期は早まるものの、送信元から宛先への経路に位置する各ノードは、それぞれ宛先へ向かうための次ホップを示す転送テーブルのエントリを、データIDごとに用意する必要がある。よって、転送テーブルのエントリ数が膨大になってしまい、その転送テーブルの検索時間や更新時間がボトルネックとなり、データ通信性能が低下してしまう。
【0016】
そこで、本発明は、前記した問題を解決し、データの位置が時間経過により更新され続ける状況で、効率的にデータ通信を行うことを、主な目的とする。
【課題を解決するための手段】
【0017】
前記課題を解決するために、本発明は、複数のノードがネットワークで接続されて構成されるデータ指向型通信システムであって、
前記複数のノードのうちの第1ノードが、端末からのオブジェクトを取得するための要求メッセージを受信し、
前記第1ノードから名前解決を行う前記複数のノードのうちの第2ノードまでの各ノードが、階層化されたオブジェクトIDとルーティング情報とを用いて前記要求メッセージのルーティングを行い、
前記第2ノードが、名前解決情報を参照して、前記要求メッセージの前記オブジェクトIDからオブジェクトを保持する前記複数のノードのうちの第3ノードのロケーションIDへの変換を行い、
前記第2ノードから前記第3ノードまでの各ノードが、変換された前記ロケーションIDを用いて、前記要求メッセージのルーティングを行い、
前記第3ノードが、自身にてオブジェクトを取得し、
前記第3ノードから前記第1ノードまでの各ノードが、取得したオブジェクトを含む返送メッセージのルーティングを行うことで、前記端末が前記要求メッセージで要求したオブジェクトを、前記第1ノードから取得することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【0018】
本発明によれば、データの位置が時間経過により更新され続ける状況で、効率的にデータ通信を行うことができる。
【図面の簡単な説明】
【0019】
【図1】本発明の一実施形態に関するデータ指向型通信システムを示す構成図である。
【図2】本発明の一実施形態に関するデータ指向型通信システム上に流れるメッセージのフォーマットを示す説明図である。
【図3】本発明の一実施形態に関するデータ指向型通信システムの各ノードを示す構成図である。
【図4】本発明の一実施形態に関するオブジェクト要求メッセージの送信処理(下位から上位へ)を示すフローチャートである。
【図5】本発明の一実施形態に関するオブジェクト要求メッセージの送信処理(上位から下位へ)を示すフローチャートである。
【図6】本発明の一実施形態に関するオブジェクト要求メッセージの各ノードにおける処理を示すフローチャートである。
【図7】本発明の一実施形態に関するオブジェクト要求メッセージの各テーブルにおける処理を示す説明図である。
【図8】本発明の一実施形態に関するオブジェクト返送メッセージの送信処理(下位から上位へ)を示すフローチャートである。
【図9】本発明の一実施形態に関するオブジェクト返送メッセージの送信処理(上位から下位へ)を示すフローチャートである。
【図10】本発明の一実施形態に関するオブジェクト返送メッセージの各ノードにおける処理を示すフローチャートである。
【図11】本発明の一実施形態に関するオブジェクト返送メッセージの各テーブルにおける処理を示す説明図である。
【図12】本発明の一実施形態に関するデータ指向型通信システムを示す構成図である。
【図13】本発明の一実施形態に関するオブジェクト登録メッセージの送信処理(下位から上位へ)を示すフローチャートである。
【図14】本発明の一実施形態に関するオブジェクト登録メッセージの送信処理(上位から下位へ)を示すフローチャートである。
【図15】本発明の一実施形態に関するオブジェクト登録メッセージの各ノードにおける処理を示すフローチャートである。
【図16】本発明の一実施形態に関するオブジェクト登録メッセージの各テーブルにおける処理を示す説明図である。
【図17】本発明の一実施形態に関するオブジェクト要求メッセージの各ノードにおける処理の別形態を示すフローチャートである。
【図18】本発明の一実施形態に関するデータ指向型通信システム(2つのデータ位置の説明用)を示す構成図である。
【図19】本発明の一実施形態に関する図18のシステムにおける旧位置のオブジェクト登録を示す構成図である。
【図20】本発明の一実施形態に関する図18のシステムにおける新位置のオブジェクト登録を示す構成図である。
【図21】本発明の一実施形態に関する図18のシステムにおける2つの位置のオブジェクト要求を示す構成図である。
【図22】本発明の一実施形態に関する図21の新位置のオブジェクト要求処理を示すフローチャートである。
【図23】本発明の一実施形態に関する図21の新位置のオブジェクト返送処理を示すフローチャートである。
【図24】本発明の一実施形態に関する図21の旧位置のオブジェクト要求処理を示すフローチャートである。
【図25】本発明の一実施形態に関する図21の旧位置のオブジェクト返送処理を示すフローチャートである。
【図26】本発明の一実施形態に関する図20のオブジェクト登録後の経路修正を示す構成図である。
【図27】本発明の一実施形態に関する図26の経路修正処理を示すフローチャートである。
【図28】本発明の一実施形態に関する図26の経路修正処理における名前解決ノードの処理を示すフローチャートである。
【図29】本発明の一実施形態に関する図26の経路修正後のオブジェクト要求を示す構成図である。
【図30】本発明の一実施形態に関する図18のシステムにおける図26とは別の経路修正を示す構成図である。
【図31】本発明の一実施形態に関する図18のシステムにおける図26とは別の経路修正を示す構成図である。
【発明を実施するための形態】
【0020】
以下、本発明の一実施形態を、図面を参照して詳細に説明する。
【0021】
図1は、データ指向型通信システムを示す構成図である。データ指向型通信システムに用いられるデータ指向型ネットワーク(DCN:Data-centric Network)とは、オブジェクトID(以下「oid」と略す)を用いて所望のオブジェクトまで、そのオブジェクトへのアクセスを転送するためのネットワークである。そのため、データ指向型通信システムでは、複数のノード1(1a〜1g)上にオブジェクトの位置情報が分散して管理されている。
ここで、oidと他のid(ノードIDを示すnid,ロケーションIDを示すlidなど)とは、別々のID空間であり、別々のデータである。oidの階層表現については、後記する。
なお、特許請求の範囲では、ノード1aを第1ノードとし、ノード1fを第2ノードとし、ノード1gを第3ノードとする。
【0022】
データ指向型通信システムの各装置は、それぞれCPU(Central Processing Unit)とメモリとハードディスク(記憶手段)とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、CPUが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【0023】
データ指向型通信システムは、各ノード1と、ノード1aに収容される端末2aと、ノード1gに収容される端末2bとがネットワークで接続されて構成される。各端末2(2a,2b)は、ノード1に対してオブジェクト9へのアクセスを指示する。オブジェクト9へのアクセスを指示するためのメッセージとして、以下の3種類が挙げられる。
・オブジェクト要求メッセージは、端末2がオブジェクト9の内容をノード1から読み込むための要求を示すメッセージパケットである。
・オブジェクト返送メッセージは、オブジェクト要求メッセージへの返答として、オブジェクト9の内容を含んだメッセージであり、オブジェクト要求メッセージの送信元である端末2に対して返送される。
・オブジェクト登録メッセージは、端末2がオブジェクト9の内容をノード1へ書き込むための要求を示すメッセージパケットである(図12以降で説明)。
【0024】
各ノード1には、ノードID(nid)が付与されている。以下、本実施形態では、ノード1の符号末尾(例えば、ノード1aの「a」)を、ノードIDの「a」と同じにしている。
ここで、nidと他のid(oid,lidなど)とは、別々のID空間であり、別々のデータである。
ノード1は、ノード1dを頂点とした階層型のトポロジで接続されており、図1では、上側が上位ノードで下側が下位ノードである。例えば、ノード1dは、ノード1cおよびノード1eの親(上位ノード)である。ノード1c,1eは、それぞれノード1b,1fの上位ノードである。ノード1b,1fは、それぞれノード1a,1gの上位ノードである。
【0025】
ノード1の階層構造をデータ指向型通信システムに反映させるために、図3で後記する転送テーブル(オブジェクトID転送テーブル11、ロケーションID転送テーブル13)において、転送先が発見できなかったときのデフォルトの転送先(次ホップ)として、自身のノード1からみた上位ノードが設定される。
【0026】
ノード1は、端末2aからのオブジェクト要求メッセージを以下の(手順1)〜(手順3)の順に扱う。
(手順1)各ノード1(1a→1b→1c→1d→1e→1f)は、オブジェクト要求メッセージ内の宛先に指定されたオブジェクトIDを用いて、次ホップのノード1へとオブジェクト要求メッセージを転送する。このように、オブジェクトIDを用いた転送を「oid転送」とし、図1では実線矢印でその転送経路を示す。
(手順2)名前解決を行うノード1fは、オブジェクトID(=a.b.c)からオブジェクトを保持するノード1gの位置ID(ロケーションID、以下「lid」と略す)への変換(=d.e.f.g)を行う。
ここで、lidと他のid(nid,oidなど)とは、別々のID空間であり、別々のデータである。
lidはIPアドレスのような既存のIDや、IPアドレスとは異なるデータ指向型ネットワークに特有なIDを含む。データ指向型ネットワークに特有のlidの階層表現の例については、後記する。
そして、ノード1fは、オブジェクト要求メッセージの宛先である位置ID(=d.e.f.g)を用いて、次ホップのノード1gへとオブジェクト要求メッセージを転送する。このように、位置IDを用いた転送を「lid転送」とし、図1では破線矢印でその転送経路を示す。
(手順3)ノード1gは、自身の記憶手段からオブジェクト要求メッセージで指定されたオブジェクト9を取得する。
【0027】
ノード1は、端末2aへのオブジェクト返送メッセージを以下の(手順4)〜(手順6)の順に扱う。
(手順4)ノード1gは、オブジェクト要求メッセージで指定されたオブジェクト9を含むオブジェクト返送メッセージを作成する。このオブジェクト返送メッセージの宛先は、オブジェクト要求メッセージの送信元の端末2aである。そして、ノード1gは、オブジェクト返送メッセージの宛先である端末2aの位置IDを用いて、次ホップのノード1fへとオブジェクト返送メッセージを転送する。
(手順5)各ノード1(1f→1e→1c→1b→1a)は、受信したオブジェクト返送メッセージの宛先である端末2aの位置IDを用いて、次ホップの各ノード1へとオブジェクト返送メッセージを転送する。ここで、各ノード1は、オブジェクト返送メッセージの転送処理に併せて、オブジェクト返送メッセージのオブジェクトID(=a.b.c)の転送先(例えば、ノード1aからみた転送先であるノード1b)を、自身の転送テーブルへと記憶する。
(手順6)端末2aは、ノード1aからオブジェクト返送メッセージを受信することで、(手順1)のオブジェクト要求メッセージに係わるオブジェクト9を取得することができる。
【0028】
図2は、データ指向型通信システム上に流れるメッセージのフォーマットを示す説明図である。メッセージヘッダ601にはノードがメッセージを転送する際に参照するための情報が記録されている。ペイロード602にはオブジェクトのデータが記録されている。
【0029】
メッセージヘッダ601は、以下の通りである。
1行目の「message_type」は、メッセージの種類として、オブジェクト要求メッセージを示す「retrieve」、オブジェクト返送メッセージを示す「return」、および、オブジェクト登録メッセージを示す「register」のいずれかが格納される。
【0030】
2,3行目の「req」から始まる行は、メッセージの要求先(宛先)を示す。「req_oid」は宛先のオブジェクトIDを示し、「req_lid」は宛先の位置IDを示す。
ここで、「req_lid」が「null(値なし)」であるとは、ノード1fにより名前解決が行われる前の状態を示すので、「req_oid」を検索キーとするoid転送が各ノード1により行われる。一方、「req_lid」に値が代入されているときには、名前解決が行われた後の状態を示すので、「req_lid」を検索キーとするlid転送が各ノード1により行われる。
【0031】
4,5行目の「src」から始まる行は、メッセージの送信元を示す。
6行目の「route_info_nid」は、自身のメッセージが通過したノード1の順序を示す。図2では、各ノード1(1a→1b→1c→1d→1e→1f)を順に通過している。
【0032】
メッセージを作成するノード1または端末2は、メッセージヘッダ601の1,2,4,5行目を付与する。名前解決するノード1fは、メッセージヘッダ601の3行目を付与する。各ノード1は、メッセージヘッダ601の6行目に、自身のノードIDを追加する。
【0033】
ここで、oidおよびlidの階層表現について、説明する。oid(=a.b.cなど)や、lid(=d.e.f.g)は、複数の要素(例えば、oidではa,b,c)が先頭から順に「.」を区切りとして接続されている。このような「.」を区切りとする階層表現では、先頭(左)にいくほど上位の階層を示し、末尾(右)にいくほど下位の階層を示す。そして、階層表現のエントリでの一致判定処理では、以下のいずれかの結果を得る。
【0034】
一致しない場合:検索キー「a.b.c」と、検索対象「d.e.f」とでは、最先頭のエントリ「aとd」の時点で不一致である。よって、検索キーと検索対象とでは、データ内容が共通する部分が存在しないため、不一致(ヒットしない)となる。
【0035】
部分一致する場合:検索キー「a.b.c」と、検索対象「a.b」とでは、先頭からの部分「a.b」は一致するが、末尾の「c」は不一致である。このように、検索キー「a.b.c」の先頭から抽出した一部「a.b」と、検索対象「a.b」とが一致するときに、部分一致する(ヒットする)と表現する。なお、階層表現「a.b.c」のうちの先頭から抽出した一部「a.b」のことを、以下では「プレフィックス」と呼ぶ。
【0036】
完全一致する場合:検索キー「a.b.c」と、検索対象「a.b.c」とでは、先頭から末尾まで一致する。このような場合を完全一致する(ヒットする)と呼ぶ。
【0037】
なお、検索キー「a.b.c」に対して、第1検索対象「a」、第2検索対象「a.b」、第3検索対象「a.b.c」が同じ転送テーブルに存在するときには、検索キー「a.b.c」に対する一致箇所が多い検索対象を、優先的にヒットさせる(いわゆる「最長一致ルール」)。この例では、検索キー「a.b.c」の検索結果は、第3検索対象の完全一致が最優先され、次に第2検索対象の部分一致、最後に第1検索対象の部分一致となる。
【0038】
図3は、データ指向型通信システムの各ノードを示す構成図である。ノード1は、制御データ記憶部10と、データ転送部20と、データ記憶部30と、ネットワーク50に接続するための通信IF40と、制御処理部60とを有する。なお、端末2も、図3に示すノード1の各構成要素(ノード管理部61など)を有していてもよい。
【0039】
制御データ記憶部10は、オブジェクトID転送テーブル11と、名前解決テーブル12と、ロケーションID転送テーブル13と、格納データテーブル14とを有する。これらの各テーブルの詳細は、図7で後記する。
データ転送部20は、データ送受信部21を有する。データ送受信部21は、各メッセージの送受信を制御する。
データ記憶部30は、データ格納部31を有する。データ格納部31は、オブジェクト9を格納する。例えば、図1では、ノード1gがオブジェクト9を格納する。
通信IF40は、ノード1内の各構成要素と、他装置に接続するためのネットワーク50とを仲介するインタフェースである。
【0040】
制御処理部60は、ノード管理部61と、オブジェクトID転送テーブル作成部62と、オブジェクトID転送テーブル検索部63と、ロケーションID転送テーブル作成部64と、ロケーションID転送テーブル検索部65と、名前解決テーブル作成部66と、名前解決テーブル検索部67と、格納データテーブル検索部68とを有する。
【0041】
オブジェクトID転送テーブル作成部62およびオブジェクトID転送テーブル検索部63は、オブジェクトID転送テーブル11の作成および検索を行う。
ロケーションID転送テーブル作成部64およびロケーションID転送テーブル検索部65は、ロケーションID転送テーブル13の作成および検索を行う。
名前解決テーブル作成部66および名前解決テーブル検索部67は、名前解決テーブル12の作成および検索を行う。
格納データテーブル検索部68は、格納データテーブル14の検索を行うことで、データ格納部31内のオブジェクト9の格納先を特定する。
【0042】
図4は、オブジェクト要求メッセージの送信処理(下位から上位へ)を示すフローチャートである。
S101において、端末2aのノード管理部61は、オブジェクト「oid=a.b.c」を要求すると判断する。この判断の契機は、ユーザの操作や端末のタイマ、外部要因のトリガなどによる。
S102において、端末2aのノード管理部61は、データ送受信部21を介してオブジェクト要求メッセージ(名前解決用)をノード1aに送信する。ノード1aは、データ送受信部21を介してオブジェクト要求メッセージを受信する。
【0043】
S103において、ノード1aのオブジェクトID転送テーブル検索部63は、受信したオブジェクト要求メッセージのオブジェクトIDを検索キーとして、オブジェクトID転送テーブル11を検索する。検索の結果、オブジェクトIDがヒットしなかった場合は、次ホップを「default」として設定された上位ノード(ここでは、ノード1b)とする。
S104において、ノード1aは、ノード1bにオブジェクト要求メッセージ(名前解決用)を送信する。S105〜S109も同様に、各ノード1は、オブジェクトID転送テーブル11の検索処理と上位ノードへの転送処理を繰り返す。
【0044】
図5は、図4の続きとして、オブジェクト要求メッセージの送信処理(上位から下位へ)を示すフローチャートである。
S111において、ノード1dのオブジェクトID転送テーブル検索部63は、S109での検索の結果、オブジェクトIDのプレフィックス(a.b.cのうちの先頭の「a」)がヒット(部分一致)し、その検索結果として次ホップのID(nid=e)を得る。ノード1dは、ノード1eに対しオブジェクト要求メッセージ(名前解決用)を送信する。
S112,S113でも、S111と同様に、プレフィックス「a」が部分一致する。ノード1eは、検索結果として次ホップのID(nid=f)を取得し、そのノード1fへとオブジェクト要求メッセージを転送する。
【0045】
S114において、ノード1fのオブジェクトID転送テーブル検索部63は、オブジェクトID転送テーブル11を検索した結果、オブジェクトIDが完全一致でヒットする。このように、完全一致でヒットしたノード1fが、名前解決を担当する。
S115において、ノード1fの名前解決テーブル検索部67は、オブジェクトIDを検索キーとして名前解決テーブル12を検索し、検索結果としてロケーションID(lid=d.e.f.g)を得る。
S116において、ノード1fのロケーションID転送テーブル検索部65は、S115で得たロケーションID(lid=d.e.f.g)を検索キーとして、ロケーションID転送テーブル13を検索し、次ホップのID(nid=g)を得る。
【0046】
S117において、ノード1fは、S116で得た次ホップであるノード1gに対して、オブジェクト要求メッセージ(名前解決用)から生成した、オブジェクト要求メッセージ(オブジェクト取得用)を送信する。
つまり、端末2aは、名前解決用のメッセージと、オブジェクト取得用のメッセージとを2つ送信する必要が無く、データ指向型通信システムのノード1において、名前解決用のメッセージからオブジェクト取得用のメッセージへと変換される。これにより、名前解決の応答を待つ前準備の期間を短縮できる。
【0047】
S118において、ノード1gの格納データテーブル検索部68は、受信したオブジェクト要求メッセージの「oid=a.b.c」を検索キーとして、格納データテーブル14を検索し、格納データID(図1では、store_id=100)を得る。格納データIDとは、データ格納部31におけるオブジェクトのIDである。データ送受信部21は、格納データIDを指定して、データ格納部31から要求されたオブジェクト9を読み込む。
そして、データ送受信部21は、読み込んだオブジェクト9をペイロード602へと格納し、メッセージヘッダ601内の送信元(「src」から始まる行)と宛先(「req」から始まる行)のIDを入れ替えることにより、オブジェクト返送メッセージを作成する。
【0048】
図6は、オブジェクト要求メッセージの各ノードにおける処理を示すフローチャートである。以下の説明では、オブジェクトIDとは、受信したオブジェクト要求メッセージに含まれているものを指す。
S181において、オブジェクトID転送テーブル検索部63は、オブジェクトIDを検索キーとして、オブジェクトID転送テーブル11を検索する。
S182において、オブジェクトID転送テーブル検索部63は、S181の検索でヒットするプレフィックスがある場合(図1ならnid=d,e,fが該当)はS183へ進み、ない場合(図1ならnid=a,b,cが該当)はS187へ進む。
S183において、オブジェクトID転送テーブル検索部63は、S181の検索のヒットが完全一致の場合(図1ならnid=fが該当)はS184へ進み、部分一致の場合(図1ならnid=d,eが該当)はS188へ進む。
【0049】
S184において、名前解決テーブル検索部67は、オブジェクトIDを検索キーとして、名前解決テーブル12を検索し、オブジェクトIDに対するロケーションIDを得る。
S185において、ロケーションID転送テーブル検索部65は、S184で得たロケーションIDを検索キーとしてロケーションID転送テーブル13を検索し、次ホップのIDを得る。
S186において、データ送受信部21は、S185で得た次ホップのIDを宛先として、オブジェクト要求メッセージを送信する。
【0050】
S187において、データ送受信部21は、オブジェクトID転送テーブル11で「default」と記載された上位ノードにオブジェクト要求メッセージを送信する。
S188において、データ送受信部21は、部分一致したエントリに対応する次ホップへ、オブジェクト要求メッセージを送信する。
【0051】
図7は、オブジェクト要求メッセージの各テーブルにおける処理を示す説明図である。なお、図7の各テーブルの列要素を示す符号の末尾には、そのテーブルが収容されるノード1のnidが付加される。例えば、nid=aのオブジェクトID転送テーブル11のoid列なら、oidを示す「711」にnidを示す「a」が付加される。一方、図7の各構成要素は、その性質や機能はどのノード1に格納されているものでも同等であり、その格納されるデータだけが異なるので、以下の図7の各構成要素の説明では、列要素を示す符号の末尾のnidを適宜省略する。
オブジェクトID転送テーブル11は、検索キーの検索対象列であるoid711(例えば、711a)と、その検索結果である次ホップを示すnexthop_nid712(例えば、712a)とが対応づけて記録されている。
【0052】
ここで、データIDそのものを位置IDとみなして通信を行う特許文献1との相違点を説明する。本実施形態のオブジェクトID転送テーブル11と、特許文献1の転送テーブルとで、検索キーをデータID(オブジェクトID)とする点では、共通する。
一方、次ホップを示すnexthop_nid712の意味が、両方式で異なる。転送テーブルの検索結果として、本実施形態のオブジェクトID転送テーブル11では、検索キーのオブジェクトIDの名前解決を行うノード1へ向かう次ホップであるが、特許文献1の転送テーブルでは、検索キーのオブジェクトIDを格納するノードへ向かう次ホップである。
【0053】
よって、オブジェクト9の位置が頻繁に変更される状況下では、特許文献1の転送テーブルは、多くのオブジェクトそれぞれについての最新のデータ位置を頻繁に更新し続ける必要があり、転送テーブルの保存容量や処理負荷が大きくなってしまう。一方、本実施形態のオブジェクトID転送テーブル11では、オブジェクト9の位置が頻繁に変更されたとしても、名前解決を行うノード1の位置はほとんど変更されないので、転送テーブルの保存容量や処理負荷を小さくすることができる。
【0054】
名前解決テーブル12は、検索キーの検索対象列であるoid721と、その検索結果である名前解決の結果を示すlid722とが対応づけて記録されている。
ロケーションID転送テーブル13は、検索キーの検索対象列であるlid731と、その検索結果である次ホップを示すnexthop_nid732とが対応づけて記録されている。
格納データテーブル14は、検索キーの検索対象列であるoid741と、その検索結果であるデータ記憶部30内での記録箇所を示すstore_id742とが対応づけて記録されている。
なお、「default」とは、検索キーの検索対象がヒットしなかったときの既定の(デフォルトの)転送先を示すエントリであり、図1で説明した上位のノード1に該当する。
【0055】
ここで、図7に記載された実線矢印は、各テーブルの参照された順序を示す。
S103で、ノード1aのオブジェクトID転送テーブル11の「default」が参照される。
S107で、ノード1cのオブジェクトID転送テーブル11の「default」が参照される。
S109で、ノード1dのオブジェクトID転送テーブル11の「a」が参照される。
S115で、ノード1fの名前解決テーブル12の「a.b.c」が参照される。
S116で、ノード1fのロケーションID転送テーブル13の「d.e.f.g」が参照される。
S118で、ノード1gの格納データテーブル14の「a.b.c」が参照される。
【0056】
なお、各転送テーブル作成部(オブジェクトID転送テーブル作成部62、ロケーションID転送テーブル作成部64)は、作成対象の各転送テーブル(オブジェクトID転送テーブル11、ロケーションID転送テーブル13)内のエントリについて、複数のエントリを1つのエントリへと集約することで、エントリ数を削減させてもよい。集約可能な複数のエントリとは、例えば、以下の2条件をともに満たしたものである。
(条件1)複数のエントリ間で、プレフィックスが同じである。
(条件2)複数のエントリ間で、次ホップが同じである。
【0057】
図8,図9は、オブジェクト返送メッセージの送信処理を示すフローチャートである。図8は、図5の続きの処理である。
S201において、ノード1gは、ノード1fにオブジェクト返送メッセージ(S118で作成されたもの)を送信する。
【0058】
S202において、ノード1fのオブジェクトID転送テーブル作成部62は、自身のオブジェクトID転送テーブル11を更新する。
更新内容のエントリのoid711は、オブジェクト返送メッセージのオブジェクトID(ペイロード602に格納されているオブジェクト9のoid)である。
更新内容のエントリのnexthop_nid712は、オブジェクト返送メッセージの受信元ノード(次ホップとして隣接するノード1)のID(nid=g)である。
【0059】
既にオブジェクトID転送テーブル11内に更新内容のoid711が存在するときには、そのエントリのnexthop_nid712だけを上書き更新し、oid711が存在しないときには、新たに更新内容のエントリを作成して、オブジェクトID転送テーブル11に追加する。
これにより、同じオブジェクト9が再度要求されたときに、オブジェクトID転送テーブル11にそのオブジェクトのエントリが存在するので、オブジェクト要求メッセージを適切に転送できるルートが確立される。
【0060】
S203において、ノード1fのロケーションID転送テーブル検索部65は、オブジェクト返送メッセージのロケーションIDを検索キーとしてロケーションID転送テーブル13を検索し、検索結果として次ホップのID(nid=e)を得る。
S204において、ノード1fは、S203で得た次ホップであるノード1eに対して、オブジェクト返送メッセージを送信する。
S205〜S209や、図9のS211〜S220も同様に、オブジェクトID転送テーブル11の更新処理(S202相当)、ロケーションID転送テーブル13での次ホップの検索処理(S203相当)、および、検索された次ホップへのオブジェクト返送メッセージの送信処理(S204相当)を行う。
S221において、端末2aは、ノード1aからオブジェクト9を取得する。
【0061】
ここで、S202で説明した更新内容のエントリのnexthop_nid712について、受信元ノードとする代わりに、短縮経路のノード1を選択してもよい。
短縮経路のノード1とは、同じ宛先へと向かう経路候補のうちのホップ数を少なくできる経路であり、例えば、図1では、短縮経路なしの<ノード1c→ノード1d→ノード1e>よりも、短縮経路ありの<ノード1c→ノード1e>のほうが、ホップ数が少なくて済む。
【0062】
以下、短縮経路のノード1の取得方法を説明する。
S212において、ノード1cのオブジェクトID転送テーブル作成部62は、メッセージヘッダ601から6行目の「route_info_nid」を読み込む。「route_info_nid」には、通過したノード1の順序リスト<a,b,c,d,e,f>が記載されている(図2参照)。
ノード1cは、受信元ノード「nid=d」よりも先にあるノードで、かつ、自身に隣接している(図1で直接接続されている)ノード「nid=e」を発見すると、そのノード「nid=e」を短縮経路のノード1としてnexthop_nid712に採用する。
【0063】
図10は、オブジェクト返送メッセージの各ノードにおける処理を示すフローチャートである。
S281において、オブジェクトID転送テーブル作成部62は、S202で説明したように、オブジェクト返送メッセージのオブジェクトIDのエントリをもとに、自身のオブジェクトID転送テーブル11を更新する。
S282において、ロケーションID転送テーブル検索部65は、オブジェクト返送メッセージのロケーションIDを検索キーとして、ロケーションID転送テーブル13を検索し、次ホップのIDを得る。
S283において、S282で得た次ホップのIDを宛先として、オブジェクト返送メッセージを送信する。
【0064】
図11は、オブジェクト返送メッセージの各テーブルにおける処理を示す説明図である。図7の6つのテーブルのうち、オブジェクト返送メッセージの送信に伴って更新されたオブジェクトID転送テーブル11を3つ例示している(他のオブジェクトID転送テーブル11も更新されているが、図示を省略する)。
S202で説明したように、各オブジェクトID転送テーブル11には、oid711=「a.b.c」とするエントリがそれぞれ新規追加されている(図11の矢印が示すエントリ、矢印は更新順序を示す)。
さらに、ノード1cのオブジェクトID転送テーブル11には、oid711=「a.b」とするエントリも追加されているが、このエントリは、短縮経路のノード1を採用したエントリであり、オブジェクトID「a.b.c」のプレフィックス「a.b」と対応づけている。
【0065】
図12は、データ指向型通信システムを示す構成図である。例として、端末2aがノード1aに対してオブジェクト9(oid=a.b.d)を登録する旨のオブジェクト登録メッセージを、ノード1aからノード1fまで転送する処理について、以下の図13〜図16で説明する。
オブジェクト登録メッセージは、登録されるオブジェクトのoid「a.b.d」を、経由する各ノード1のオブジェクトID転送テーブル11に記憶させつつ、名前解決を行うノード1fまで転送される。そして、ノード1fは、オブジェクトIDとオブジェクトが登録されたノード1aの位置ID「d.e.f.a」を名前解決テーブル12に記憶する。
【0066】
図13,図14は、オブジェクト登録メッセージの送信処理を示すフローチャートである。
S301において、端末2aのノード管理部61は、オブジェクト「oid=a.b.d」の登録を行うと判断する。この判断の契機は、例えば、ユーザの操作や端末のタイマ、外部要因のトリガなどが発生したことによる。
S302において、端末2aのノード管理部61は、データ送受信部21を介して、オブジェクト登録メッセージ(名前解決用)をノード1aに送信する。ノード1aは、データ送受信部21を介してオブジェクト登録メッセージを受信し、その登録先が自身であることを認識すると、オブジェクト登録メッセージのペイロード602から読み出したオブジェクト9をデータ格納部31に格納するとともに、その格納位置を格納データテーブル14に登録する。
【0067】
S303において、ノード1aのオブジェクトID転送テーブル検索部63は、S302で受信したオブジェクト登録メッセージのオブジェクトIDを検索キーとして、オブジェクトID転送テーブル11を検索する。検索した結果、オブジェクトIDがヒットしないので、次ホップを上位ノードであるノード1bとする。
S304において、ノード1aは、S303で特定した次ホップであるノード1bに、オブジェクト登録メッセージを送信する。
【0068】
S305において、ノード1bのオブジェクトID転送テーブル作成部62は、S202と同様に、オブジェクトID転送テーブル11を更新する。
S307〜S312、および、図15のS321,S322において、オブジェクトID転送テーブル11の検索処理(S303相当)、次ホップへのオブジェクト登録メッセージの送信処理(S304相当)、および、オブジェクトID転送テーブル11の更新処理(S305相当)を、同様に繰り返す。
【0069】
S323において、ノード1fのオブジェクトID転送テーブル検索部63は、S303と同様に、「oid=a.b.d」を検索キーとして、オブジェクトID転送テーブル11を検索する。検索の結果、ノード1fのオブジェクトID転送テーブル11には、oid721f=「a.b.d」である完全一致のエントリは存在しないものの、プレフィックス「a.b」が共通であるoid721f=「a.b.c」のエントリが存在するため(図7参照)、完全一致とみなす。つまり、完全一致とみなしたノード1fを、名前解決を行うノード1とする。
【0070】
S324において、ノード1fの名前解決テーブル作成部66は、名前解決テーブル12において、lid731f=ノード1aの位置ID「d.e.f.a」とし、nexthop_nid732f=ノード1eとする新エントリを作成して、その新エントリを名前解決テーブル12に反映する。ここで、反映とは、lid731f=「d.e.f.a」のエントリが既に存在していれば、nexthop_nid732fだけを書き換え、エントリが存在していなければ、新エントリを名前解決テーブル12に新規追加する処理である。
【0071】
図15は、オブジェクト登録メッセージの各ノードにおける処理を示すフローチャートである。
S381において、オブジェクトID転送テーブル作成部62は、S202(S305)と同様に、オブジェクトID転送テーブル11を更新する。
S382において、オブジェクトID転送テーブル検索部63は、オブジェクト登録メッセージのオブジェクトIDを検索キーとしてオブジェクトID転送テーブル11を検索し、その検索結果として次ホップを得る。
S383において、データ送受信部21は、S382で取得した次ホップのIDを宛先として、オブジェクト登録メッセージを送信する。
【0072】
図16は、オブジェクト登録メッセージの各テーブルにおける処理を示す説明図である。この図16での矢印は、オブジェクト登録メッセージによる登録後に、その登録されたオブジェクト9を要求するためのオブジェクト要求メッセージが到着したときに参照される各テーブルの順序を示す。
【0073】
まず、ノード1aのオブジェクトID転送テーブル11内のoid711a=「a.b.d」が参照される(ノード1bのオブジェクトID転送テーブル11は、図示省略)。次に、ノード1cのオブジェクトID転送テーブル11内のoid711c=「a.b.d」が参照される。そして、ノード1fのオブジェクトID転送テーブル11内のoid711f=「a.b.d」が参照され、nexthop_nid712fが「local」なので、ノード1f自身が名前解決を担当するノード1であることがわかる。
【0074】
ノード1fの名前解決テーブル検索部67は、名前解決テーブル12のoid721f=「a.b.d」から、lid722f=「d.e.f.a」を得る。さらに、ノード1fのロケーションID転送テーブル検索部65は、lid731f=「d.e.f.a」からnexthop_nid732f=「e」を得る。
そして、lid=「d.e.f.a」によるlid転送を経て、ノード1aの格納データテーブル14のoid741a=「a.b.d」からstore_id742a=300が特定され、ノード1aのデータ格納部31内の300番のアドレスからオブジェクト9が読み込まれる。
【0075】
以上説明した本実施形態では、図1の実線矢印で示すようにオブジェクトIDを用いたoid転送で名前解決するノード1fまでオブジェクト要求メッセージを転送するとともに、ノード1fから先は、図1の破線矢印で示すようにロケーションIDを用いたlid転送でオブジェクト要求メッセージを転送する、つまり、同じデータ指向型通信システム内でoid転送とlid転送とを併用する形態である。
【0076】
そして、本実施形態では、端末2は、オブジェクト要求メッセージを1回送信するだけで、名前解決と、その名前解決されたオブジェクト要求メッセージによる宛先への転送とが実現できる(S117の説明を参照)。つまり、端末2は、オブジェクト要求メッセージにおいて、ホストIDから位置IDの変換(名前解決)を明示的に要求しなくても、移動するオブジェクトに対し、データIDを指定するだけで所望のオブジェクトをオブジェクト返送メッセージから取得することができる。
なお、名前解決を担当するノード1(図1では、ノード1f)の特定方法として、S183などで説明したようにoidの完全一致をするノード1とする代わりに、図16のオブジェクトID転送テーブル11のnexthop_nid712fで示したように、oidの次ホップが「local」であるノード1としてもよい。
さらに、図17に示すように、oidが完全一致をするノード1(S183,Yes)、かつ、次ホップが「local」であるノード1(S183b,Yes)というAND条件を満たすノード1を、名前解決を担当するノード1(以下、「名前解決ノード」と呼ぶ)としてもよい。
図17は、図6と比較すると、2つの処理(S183b,S187b)が追加されている。S187bは、S188と同様に、自身が名前解決を担当するノード1ではないので、次ホップの転送先ノード1へオブジェクト要求を転送する処理である。
【0077】
一方、非特許文献1や非特許文献2などの方式では、名前解決の応答をクライアント側(端末側)が受ける必要があるため、端末側に名前解決を要求するための機能を実装する負担がかかるとともに、サーバ側(DNSなどのサービス提供側)にもサービスを管理および維持するためのコストがかかる。
また、名前解決をしてからデータ通信を開始するため、名前解決を行う前準備の期間にデータ通信の待ち時間(遅延)が発生するとともに、名前解決を実行するための制御用パケットのトラフィックによるネットワーク効率の低下も発生する。とくに、非特許文献2の方式では、通信を行う度にホストIDから位置IDに変換する要求がDHT内を渡り歩くため、過剰に遅延とトラフィックが発生する。
【0078】
さらに、本実施形態では、オブジェクト返送メッセージやオブジェクト登録メッセージを各ノード1が転送するときに、その転送処理に併せて、オブジェクトIDを各ノード1の転送テーブルに登録する処理を行う(S202,S305などを参照)。これにより、頻繁に位置が変更されるオブジェクト9であっても、その最新の位置情報をすぐに転送テーブルに反映させることができる。
【0079】
一方、名前解決の変換結果をDNSサーバに向かう途中のノードにキャッシュすることで、DNSサーバの負荷を軽減する従来の方式では、キャッシュデータが最新の位置情報を反映していないことも多いため、頻繁に位置が変更されるオブジェクト9の実際の位置を特定することが困難となってしまう。
つまり、通信相手のホストが物理的に移動した場合には、ホスト名が同じでもそのIPアドレスが変更されてしまうので、名前解決の変換結果が変更されてしまう。よって、キャッシュされた古い変換結果と、ホスト移動後の新しい変換結果とが異なるものとなってしまう。
【0080】
以上説明した本実施形態により、オブジェクト9の位置が変更されても、その最新の位置情報の登録先が変更前と同じノード1であるときには、オブジェクト要求メッセージの送信先は、その登録先ノード1のままである。よって、オブジェクト要求メッセージのoid転送の経路(オブジェクトID転送テーブル11のエントリ)は変更しなくてもよい。
一方、オブジェクト9の位置が変更され、かつ、その最新の位置情報の登録先が変更前とは別のノード1であるときには、オブジェクト要求メッセージのoid転送の経路を、新たな登録先のノード1へと誘導する必要がある。
【0081】
そのため、以下では、「経路修正メッセージ」という新たなメッセージを定義する(詳細は、後記の図26などで説明)。経路修正メッセージは、オブジェクトID転送テーブル11のエントリを修正するためのメッセージである。以下、経路修正メッセージをもとに、オブジェクト9の最新位置が登録されている名前解決のノード1へのオブジェクト要求メッセージの誘導を実現する方法を詳細に説明する。
【0082】
図18は、データ指向型通信システム(2つのデータ位置の説明用)を示す構成図である。図1のデータ指向型通信システムと比較すると、2つのノード(nid=hのノード1hと、nid=iのノード1i)が追加され、端末2が4台(端末2a〜2d)になっている。
さらに、図18の2つのオブジェクト9(9a,9b)は、同じoid(=a.b.c)のオブジェクトであり、ノード1a(旧位置)内にオブジェクト9aとして格納された後、ノード1g(新位置)内のオブジェクト9bに格納される。なお、オブジェクト9aの旧位置の名前解決ノードは、ノード1bであり、オブジェクト9aの新位置の名前解決ノードは、ノード1fである。
特許請求の範囲の「第1ノード」は、端末2dを収容するノード1gである。
特許請求の範囲の「第2ノード」は、名前解決ノード(ノード1b、ノード1f)である。
特許請求の範囲の「第3ノード」は、データ収容ノード(ノード1a、ノード1g)である。
【0083】
ここで、オブジェクト9aからオブジェクト9bへの移動処理を実現するためには、本来は、オブジェクト9bの格納後に、オブジェクト9aを消去する必要がある。しかし、以下の説明では、オブジェクト9bの格納後にも、オブジェクト9aが存続する状態をもとに、不具合が発生してしまう事例とその対策について説明する。
【0084】
図19は、図18のシステムにおける旧位置のオブジェクト登録を示す構成図である。オブジェクト9aのオブジェクト登録メッセージは、端末2dから送信されて、ノード1g→ノード1f→ノード1e→ノード1cを順に中継し、旧位置として名前解決ノードであるノード1bに登録され、オブジェクト9そのものは、旧位置であるノード1aに格納される。
【0085】
オブジェクト登録メッセージが中継される各途中のノード1(ノード1g→ノード1f→ノード1e→ノード1c)のオブジェクトID転送テーブル11は、それぞれ更新される(具体的な更新処理は、図13のS305などを参照)。つまり、各途中のノード1は、自身のオブジェクトID転送テーブル11のoid711にオブジェクト9aのoid(=a.b.c)を書き込み、自身のオブジェクトID転送テーブル11のnexthop_nid712にノード1aへ向かう隣接ノードを書き込む。
なお、以下の説明では、オブジェクトID転送テーブル11のnexthop_nid712の内容を、ノード内に「next_oid」と表記する。また、ロケーションID転送テーブル13のnexthop_nid731の内容を、ノード内に「next_lid」と表記する。
【0086】
図20は、図18のシステムにおける新位置のオブジェクト登録を示す構成図である。オブジェクト9bのオブジェクト登録メッセージは、端末2dから送信されて、ノード1gを中継し、新位置として名前解決ノードであるノード1fに登録され、オブジェクト9そのものは、新位置であるノード1gに格納される。
【0087】
ここで、オブジェクト登録メッセージが通過するノード1f,1gは、自身のオブジェクトID転送テーブル11の内容を、新しい名前解決ノードがノード1fであるように更新できる(具体的な更新処理は、図13のS305などを参照)。一方、図20のオブジェクト登録メッセージが通過しないノード1e,1c,1bは、自身のオブジェクトID転送テーブル11の内容が、古い名前解決ノードであるノード1bのままである。
【0088】
図21は、図18のシステムにおける2つの位置のオブジェクト要求を示す構成図である。オブジェクト9aからオブジェクト9bへのコピー処理が行われた後に、オブジェクト9bのデータ内容が変更された結果、オブジェクト9aとオブジェクト9bとのデータ内容が相違する状態が発生する。
【0089】
図21の左側は、端末2bが、旧位置のオブジェクト9aに対して、オブジェクト要求メッセージを送信してしまう例を示す。端末2bからのオブジェクト要求メッセージは、ノード1h→ノード1b(名前解決ノード)→ノード1aの順に通過する。これにより、端末2bは、古いデータ内容のオブジェクト9aを取得してしまうので、望ましくない。
オブジェクト9aを取得してしまう要因は、図20の新しいオブジェクト登録メッセージが通過しないノード1e,1c,1bに、図19で示した古いオブジェクト登録メッセージによる影響が残ったままになっているためである。
【0090】
図21の右側は、端末2cが、新位置のオブジェクト9bに対して、オブジェクト要求メッセージを送信できる例を示す。端末2cからのオブジェクト要求メッセージは、ノード1i→ノード1f(名前解決ノード)→ノード1gの順に通過する。これにより、端末2cは、新しいデータ内容のオブジェクト9bを取得できる。
【0091】
図22は、図21の右側(新位置のオブジェクト要求処理)を示すフローチャートである。このフローチャートは、図4,5で示したオブジェクト要求処理と同じ処理で、ノード1の位置が変更されているだけである。
S401において、端末2cは、S101と同様に、オブジェクト「oid=a.b.c」を要求すると判断する。
S402において、端末2cは、S102と同様に、オブジェクト要求メッセージ(名前解決用)を隣接する次ホップのノード1iに送信する。
【0092】
オブジェクト要求メッセージ(名前解決用)の経路上に位置するノード1iは、以下の手順を行う。
(手順1)S102と同様に、前段の装置からオブジェクト要求メッセージ(名前解決用)を受信する(S402)。
(手順2)S103と同様に、自身のオブジェクトID転送テーブル11を検索し、オブジェクト要求メッセージの転送先を決定する(S403)。
(手順3)S104と同様に、決定した転送先である後段の装置へ、オブジェクト要求メッセージを送信する(S404)。
【0093】
オブジェクト要求メッセージ(名前解決用)の名前解決ノードであるノード1fは、以下の手順を行う。
(手順1)S113と同様に、前段の装置からオブジェクト要求メッセージ(名前解決用)を受信する(S404)。
(手順2)S114と同様に、自身のオブジェクトID転送テーブル11を検索し、オブジェクト要求メッセージの名前解決ノードを自身であると決定する(S405)。
(手順3)S115と同様に、名前解決テーブル12を検索し、オブジェクト9のロケーションIDを得る(S406)。
(手順4)S116と同様に、ロケーションID転送テーブル13を検索し、オブジェクト要求メッセージのlid転送における次ホップを得る(S407)。
(手順5)S117と同様に、ロケーションID転送テーブル13から得た次ホップ(後段の装置)へ、オブジェクト要求メッセージ(名前解決用)から生成した、オブジェクト要求メッセージ(オブジェクト取得用)を送信する(S408)。
【0094】
オブジェクト要求メッセージが要求するオブジェクト9を自身に格納するノード1gは、以下の手順を行う。
(手順1)S117と同様に、前段の装置からオブジェクト要求メッセージ(オブジェクト取得用)を受信する(S408)。
(手順2)S118と同様に、自身の格納データテーブル14を検索し、格納データIDを得て、データ格納部31から要求されたオブジェクト9を読み込む(S409)。そして、読み込んだオブジェクト9をもとに、オブジェクト返送メッセージを作成する。
【0095】
図23は、図21の右側(新位置のオブジェクト返送処理)を示すフローチャートである。このフローチャートは、図8,9で示したオブジェクト返送処理と同じ処理で、ノード1の位置が変更されているだけである。
S421において、ノード1gは、S201と同様に、S118で作成されたオブジェクト返送メッセージを隣接する次ホップのノード1fに送信する。
【0096】
オブジェクト返送メッセージの経路上に位置する各ノード1は、以下の手順を行う。
(手順1)S201と同様に、前段の装置からオブジェクト返送メッセージを受信する(ノード1fならS421,ノード1iならS424)。
(手順2)S202と同様に、自身のオブジェクトID転送テーブル11を更新する(S422,S425)。
(手順3)S203と同様に、自身のロケーションID転送テーブル13を検索し、検索結果として次ホップを得る(S423,S426)。
(手順4)S204と同様に、(手順3)で得た次ホップ(後段の装置)へ、オブジェクト返送メッセージを送信する(S424,S427)。
【0097】
オブジェクト返送メッセージの送信先である(オブジェクト要求メッセージの送信元である)端末2cは、以下の手順を行う。
(手順1)S220と同様に、前段の装置からオブジェクト返送メッセージを受信する(S427)。
(手順2)S221と同様に、受信したオブジェクト返送メッセージ内のオブジェクト9を取得する。このオブジェクト9は、新位置のオブジェクト9bである(S428)。
【0098】
図24は、図21の左側(旧位置のオブジェクト要求処理)を示すフローチャートである。この図24の処理は、図22の処理と同じであり、その処理の動作主体だけが以下のように変更されている。
(図22の端末2c)→(図24の端末2b)
(図22のノード1i)→(図24のノード1h)
(図22のノード1f)→(図24のノード1b)
(図22のノード1g)→(図24のノード1a)
そして、図22の処理符号(例えば、S401)に40を足した符号が、図24の処理符号(例えば、S441)に対応する。
【0099】
図25は、図21の左側(旧位置のオブジェクト返送処理)を示すフローチャートである。この図25の処理は、図23の処理と同じであり、その処理の動作主体の変更や、符号の変更(符号+40)は、図24と同じルールである。
ここで、S428に対応するS468として、端末2bは、旧位置のオブジェクト9aを取得してしまっている(図21で説明)。
【0100】
図26は、図20のオブジェクト登録後の経路修正を示す構成図である。
端末2dは、図20で説明したように、「oid=a.b.c」のオブジェクト9bを登録するためのオブジェクト登録メッセージを、ノード1gを経由して、登録先の名前解決ノードであるノード1fに送信する。このオブジェクト登録メッセージが通過する各ノード1では、次ホップへの送信処理(S304相当の処理)に加えて、自身のオブジェクトID転送テーブル11の更新処理(S305相当の処理)を実行する。この更新処理により、図21の右側で示したように、新位置へのオブジェクト要求が実現できる。
【0101】
名前解決ノードであるノード1fは、S324相当の処理で、自身の名前解決テーブル12の更新において、新規登録ではなく既存エントリへの書き換えが発生した場合は、ノード1fは古い経路情報の修正が必要となると判断する。古い経路情報とは、図20の新しいオブジェクト登録メッセージが通過しないノード1e,1c,1b内のオブジェクトID転送テーブル11のエントリである。そして、修正の判断を受け、ノード1fは、古い経路経由で経路修正メッセージを送信する。
ここでは、経路修正メッセージの送信先をオブジェクト9aを格納するノード1aのlidとし、ロケーションID転送テーブル13を参照したlid転送を用いることにする。
【0102】
図27は、図26の経路修正処理(経路修正メッセージの処理)を示すフローチャートである。
【0103】
S501において、ノード1fは、図26の説明で示したように、古い経路情報の修正が必要か否かを判断する。修正が不要なら(S501,No)、S530へ処理を進める。修正が必要なら(S501,Yes)、古いオブジェクト9aの「oid=a.b.c」と、格納先の「lid=d.c.b.a(ノード1aのアドレス)」とを含む経路修正メッセージを作成する。
【0104】
そして、ノード1fは、ロケーションID転送テーブル13から経路修正メッセージのlidに対応する次ホップをノード1eとして検索し、そのノード1eに対して、経路修正メッセージを送信する(S502)。なお、図27のフローチャートでは、経路修正メッセージを「オブジェクト登録(経路修正)」と表記している。これは、経路修正メッセージが、図26のオブジェクト登録メッセージから派生したメッセージであるためである。
【0105】
以下、経路修正メッセージを転送する各ノード1(ノード1e→ノード1c→ノード1b)の処理手順を説明する。
(手順1)ノード1は、前段の装置から経路修正メッセージを受信する(ノード1eならS502,ノード1cならS505,ノード1bならS508)。
(手順2)ノード1のオブジェクトID転送テーブル作成部62は、経路修正メッセージ内のoidを検索キーとして自身のオブジェクトID転送テーブル11を検索し、検索結果として得たエントリを修正することで、オブジェクトID転送テーブル11を更新する(S503,S506,S509)。
ここで、エントリの修正とは、エントリのレコードを削除してもよいし、エントリのレコードの次ホップのノード1を、オブジェクト9aの名前解決ノード(ノード1b)からオブジェクト9bの名前解決ノード(ノード1f)へ向かう次ホップへと変更してもよい。後記する図29の例では、エントリの修正として、各ノード1は、次ホップの変更処理を行っている。
【0106】
(手順3)ノード1のロケーションID転送テーブル検索部65は、経路修正メッセージ内のlidを検索キーとしてロケーションID転送テーブル13を検索し、検索結果として次ホップのノード1のIDを得る(S504,S507,S510)。
(手順4)ノード1は、(手順3)で得た後段の装置である次ホップのノード1へ、経路修正メッセージを送信する(S505,S508,S511)。
【0107】
そして、経路修正メッセージは、オブジェクト9aを格納するノード1aへと送信され、ノード1aは、その経路修正メッセージへの返事(ACK)を、経路修正メッセージの送信者であるノード1fに送信する(S520)。
ノード1fは、経路修正メッセージが送信不要(S501,No)と判断したとき、または経路修正メッセージへのACKを受信した(S520)ときに、その経路修正メッセージの派生元であるオブジェクト登録メッセージへのACKを、オブジェクト登録メッセージの送信元である端末2に返信する(S530)。
【0108】
図28は、図26の経路修正処理における名前解決ノード(ノード1f)の処理を示すフローチャートである。このフローチャートは、オブジェクト登録メッセージが到着するたびに、別のプロセスを新規に起動して実行される。
なお、このフローチャートは、図14で説明したノード1fの処理(S321〜S324)を拡張したものであるので、既に説明したノード1fの処理(S321〜S324)の詳細説明は、省略する。
【0109】
ノード1fは、オブジェクト登録(名前解決)を受信すると(S321)、オブジェクトID転送テーブル11を更新し(S322)、オブジェクトID転送テーブル11を検索する(S323)。
【0110】
ここで、ノード1fは、自身が管理する経路修正メッセージを同時に複数個発生させないためのロック処理を実行する。このロック処理では、ある経路修正メッセージを発行すると、その経路修正メッセージへのACKを受信するまで、別の経路修正メッセージの発行を待機させる。
よって、ノード1fは、現在がロック中であるときには(S331,Yes)、既に前の経路修正メッセージが発行された後なので、その前の経路修正メッセージのロック解除(S345)を待ってから、処理をS324へ進める。S324では、ノード1fは、名前解決テーブル12を更新する。
なお、前の経路修正メッセージのロック解除(S345)と、現在の経路修正メッセージのロック解除待ち(S331,Yes)とは、それぞれ別のプロセスで並行に動作しているので、ロック解除待ちが永遠に続く(デッドロック)ことはない。
【0111】
S332では、ノード1fは、古い経路情報の修正が必要か否かを判断する(S501と同じ)。修正が不要なら(S332,No)、ノード1fは、オブジェクト登録メッセージへのACKを端末2に返信して(図27のS530)、処理を終了する。そして、ノード1fは、次の経路修正メッセージをロックしてから(S333)、今の経路修正メッセージを送信する(S341,S502と同様)。
【0112】
ノード1fは、今の経路修正メッセージへのACKを受信したか否かを、例えば、S341の送信時刻を起点として所定時間待つことにより、判断する(S342)。
ノード1fは、ACKを受信できたら(S342,Yes)、S530のオブジェクト登録メッセージへのACKとして、登録成功のACKを返信する(S343)。
ノード1fは、ACKを受信できなかったら(S342,No)、S530のオブジェクト登録メッセージへのACKとして、登録失敗のACKを返信する(S344)。
そして、ノード1fは、次の経路修正メッセージへのロック(S333)を解除する(S345)。
【0113】
図29は、図26の経路修正メッセージの送信後のオブジェクト要求を示す構成図である。図26〜図28で説明した経路修正メッセージによって、ノード1e,1c,1b内のオブジェクトID転送テーブル11のエントリは、古い名前解決ノードであるノード1bへ向かう次ホップから、新しい名前解決ノードであるノード1fへ向かう次ホップへと修正されている。
【0114】
例えば、ノード1bのnext_oidは、ノード1fへ向かうための次ホップであるノード1cへと修正される。そのため、図21と比較すると、端末2bからのオブジェクト要求メッセージは、中継点のノード1bで、ノード1aに向かわずに、ノード1cへと向かう。
つまり、どの端末2(端末2a〜端末2d)からオブジェクト要求メッセージを発行しても、その宛先はノード1fへと届くように、各ノード1内のオブジェクトID転送テーブル11が修正される。
【0115】
図30は、図18のシステムにおける図26とは別の経路修正を示す構成図である。図26,図27の古い経路情報の修正判定処理(S501)では、一例として、名前解決テーブル12内のデータ更新(新規登録ではなく既存エントリへの書き換えが発生した場合)をもとに、修正要否を判定していた。
【0116】
一方、同じノード1fが、新旧両方のエントリを有していない場合も存在する。図30では、旧位置のオブジェクト登録メッセージが端末2a→ノード1a→ノード1bの順に通過し(S601)、新位置のオブジェクト登録メッセージが端末2d→ノード1g→ノード1fの順に通過する(S603)例を示す。この場合、ノード1fは、旧位置のオブジェクト登録メッセージが通過する経路上に位置していないので、旧位置のオブジェクト9aのエントリ(旧エントリ)を知らない。よって、既存エントリへの書き換えの発生も検知できないので、経路修正メッセージを送信することが困難である。
【0117】
そこで、名前解決ノードであるノード1b、ノード1f間で、自身の持つエントリをお互いに交換するため、ノード1bは、S601で自身に登録されたオブジェクト9aについて、その登録された旨(旧位置の通知)をノード1fに通知する(S602)。
このS602の通知メッセージにより、ノード1fは、ノード1b内の登録内容を知ることができるので、既存エントリへの書き換えの発生も検知できるようになる。具体的には、ノード1fの名前解決テーブル検索部67は、自身の名前解決テーブル12内のエントリと、ノード1bから通知された名前解決テーブル12内のエントリとを照合し、同じoidのエントリが双方の名前解決テーブル12に存在するときには、既存エントリへの書き換えとして検知する。
【0118】
そして、ノード1fは、図26では、自身を起点とした経路修正メッセージをlid転送で送信していたが、その送信処理に代えて、旧エントリを有するノード1bに対して、経路修正メッセージの送信を依頼するための通知(経路修正の通知)を行う(S604)。
通知を受けたノード1bは、自身を起点とした経路修正メッセージをoid転送でS601のオブジェクト登録メッセージとは逆方向に送信する(S605)。これにより、S601のオブジェクト登録メッセージの経路上に登録された古いエントリは、S605の経路修正メッセージによる新しいエントリによって修正(上書き)される。
【0119】
図31は、図30とは別の経路修正メッセージの送信依頼の形態である。図30の経路修正の通知(S604)が、図31の経路修正の通知(S604b)へと置き換わっている。つまり、ノード1fは、オブジェクト登録メッセージの送信元である端末2aに対して、経路修正メッセージの送信を依頼する。
これにより、S601のオブジェクト登録メッセージと、S605bの経路修正メッセージとが始点から終点まで同じ経路をたどることができるので、その経路に沿って旧エントリが新エントリへと修正される。
【0120】
なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。
また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段などは、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。
また、前記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
【0121】
各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、SSD(Solid State Drive)などの記録装置、または、IC(Integrated Circuit)カード、SDカード、DVDなどの記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【0122】
1 ノード
2 端末
9 オブジェクト
10 制御データ記憶部
11 オブジェクトID転送テーブル
12 名前解決テーブル
13 ロケーションID転送テーブル
14 格納データテーブル
20 データ転送部
21 データ送受信部
30 データ記憶部
31 データ格納部
40 通信IF
50 ネットワーク
60 制御処理部
61 ノード管理部
62 オブジェクトID転送テーブル作成部
63 オブジェクトID転送テーブル検索部
64 ロケーションID転送テーブル作成部
65 ロケーションID転送テーブル検索部
66 名前解決テーブル作成部
67 名前解決テーブル検索部
68 格納データテーブル検索部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【国際調査報告】