JP2009157575A - ネットワーク端末及びコンピュータプログラム - Google Patents

ネットワーク端末及びコンピュータプログラム Download PDF

Info

Publication number
JP2009157575A
JP2009157575A JP2007334078A JP2007334078A JP2009157575A JP 2009157575 A JP2009157575 A JP 2009157575A JP 2007334078 A JP2007334078 A JP 2007334078A JP 2007334078 A JP2007334078 A JP 2007334078A JP 2009157575 A JP2009157575 A JP 2009157575A
Authority
JP
Japan
Prior art keywords
node
information
data
address
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007334078A
Other languages
English (en)
Inventor
Atsushi Tagami
敦士 田上
Teruyuki Hasegawa
輝之 長谷川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2007334078A priority Critical patent/JP2009157575A/ja
Publication of JP2009157575A publication Critical patent/JP2009157575A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】リソースが小さくてもアドレス情報の検索処理スピードに影響を与えることなくP2Pネットワークのアプリケーションを利用可能とする。
【解決手段】リソースの小さいネットワーク端末が、P2Pネットワーク内の他のノードに対して自己のアドレス情報をルーティング情報として通知しないように制御を行う制御手段を備える。
【選択図】図6

Description

本発明は、ピアツーピア・ネットワークのノードとして用いられるネットワーク端末及び該ネットワーク端末のコンピュータプログラムに関する。
近年、ピアツーピア・ネットワークを利用した様々なアプリケーション(ファイル共有やインターネット電話等)が普及してきている。ピアツーピア(Peer to Peer;以下、P2Pと略す)は多数のネットワーク端末(ノード)が対等の立場で接続されたネットワークの形態であり、P2Pネットワークを構成する各ノードは、ネットワークの管理をするサーバを介在させることなく相互に通信を行う。
P2Pネットワークにおいて、あるノードAがあるデータXを他のノードBから取得する際の通信手順を簡単に説明する。どのノードがどんなデータを所有しているかの情報は、P2Pネットワークに参加している各ノードが分散して管理する分散ハッシュテーブルに記述されている。ノードAは、目的のデータXを特定する情報として例えばデータXのファイル名をハッシュしてハッシュ値を計算する。このハッシュ値から、データXに関する情報が記述された分散ハッシュテーブルを管理しているノード(ノードPとする)がどれであるかを知ることができる。ノードAは、目的のデータXを所有しているノードBのアドレス情報に対する問い合わせを、自分のルーティングテーブルを参照してノードPに近いノードへ送る(アドレス情報の検索)。この問い合わせを受けたノードは、自分がノードPであればノードBのアドレス情報をノードAへ返し、自分がノードPでなければ、自分のルーティングテーブルを参照してよりノードPに近いノードへノードAからの問い合わせを転送する。こうして問い合わせが繰り返し転送され、最終的に、ノードPが持っているノードBのアドレス情報がノードAによって取得されることとなる。ノードAは、このようにして検索されたノードBのアドレス情報を用いて、ノードBからデータXを取得することができる。
Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan (2001). "Chord: A scalable peer-to-peer lookup service for internet applications". ACM SIGCOMM Computer Communication Review 31 (4): 149 - 160.
ところで、P2Pネットワークに参加しているノード即ちネットワーク端末には、通信速度やCPU処理速度が高速(リソースが大きい)なものと低速(リソースが小さい)なものとが混在することがある(リソースが大きいネットワーク端末の例として、ブロードバンド回線に接続されたパソコンがあり、リソースが小さいネットワーク端末の例として、携帯電話端末(インターネット接続機能を有する)がある)。このような状況では、ノードが目的のデータを所有しているノードのアドレス情報を検索する際、アドレス情報の問い合わせが転送される経路上にリソースの小さいノードが存在していると、アドレス情報の検索の処理が遅くなってしまうという問題がある。
なお、この問題に対応するための方法として、従来、P2Pネットワークの構造を、スーパーノードと呼ばれるリソースの大きいノードの下にリソースの小さいノードをぶら下げた階層構造とする方法が知られている。しかしながら、この方法では、スーパーノードに障害が発生した場合に、そのスーパーノードにぶら下がっている全てのノードに影響が及んでしまい、また、スーパーノードの負荷が大きくなってしまう、ということが問題になる。
本発明は上記の点に鑑みてなされたものであり、その目的は、リソースが小さくてもアドレス情報の検索処理スピードに影響を与えることなくP2Pネットワークのアプリケーションを利用することが可能なネットワーク端末、及び該ネットワーク端末のコンピュータプログラムを提供することにある。
本発明は上記の課題を解決するためになされたものであり、ピアツーピア・ネットワーク内の他のノードからルーティング情報を取得して自己のルーティングテーブルを生成するルーティングテーブル生成手段と、前記生成したルーティングテーブルに記述されているノードを介して、目的データを所有しているデータ所有ノードのアドレス情報を取得するアドレス取得手段と、前記取得したアドレス情報を用いて前記データ所有ノードから前記目的データを取得するデータ取得手段と、を備えたネットワーク端末において、ピアツーピア・ネットワーク内の他のノードに対して自己のアドレス情報をルーティング情報として通知しないように制御を行う第1の制御手段を備えることを特徴とする。
また、本発明は、上記のネットワーク端末において、目的データを特定するデータ特定情報と該目的データを所有しているデータ所有ノードを特定するノード特定情報とを対応付けた第1テーブル、及び、前記ノード特定情報と該ノード特定情報で特定されるデータ所有ノードのアドレス情報とを対応付けた第2テーブルが前記ピアツーピア・ネットワークのノードにより管理され、前記第1テーブルを保持するノードに自己が所有する目的データのデータ特定情報と自己のノード特定情報とを送信し、前記第2テーブルを保持するノードに自己のノード特定情報と自己のアドレス情報とを送信するように制御を行う第2の制御手段を備えることを特徴とする。
また、本発明は、上記のネットワーク端末において、前記第2テーブルは、前記ノード特定情報に対応付けて、前記アドレス情報に加えて該データ所有ノードの状態を示すノード状態情報を記述したものであり、前記第2の制御手段は、前記第2テーブルを保持するノードに自己のノード特定情報と自己のアドレス情報と自己のノード状態情報とを送信するように制御を行うことを特徴とする。
また、本発明は、上記のネットワーク端末において、前記アドレス取得手段は、目的データを特定するデータ特定情報が記述された前記第1テーブルを保持するノードから、該データ特定情報と対応するノード特定情報を取得する第1取得手段と、前記取得したノード特定情報が記述された前記第2テーブルを保持するノードから、該ノード特定情報と対応するアドレス情報を取得する第2取得手段と、からなることを特徴とする。
また、本発明は、上記のネットワーク端末において、前記第2取得手段は、前記第1取得手段により取得したノード特定情報が記述された第2テーブルを保持するノードから、該ノード特定情報と対応するアドレス情報及びノード状態情報を取得し、前記データ取得手段は、前記取得したノード状態情報に基づいて選択したデータ所有ノードから目的データを取得することを特徴とする。
また、本発明は、ピアツーピア・ネットワーク内の他のノードからルーティング情報を取得して自己のルーティングテーブルを生成し、前記生成したルーティングテーブルに記述されているノードを介して、目的データを所有しているデータ所有ノードのアドレス情報を取得し、前記取得したアドレス情報を用いて前記データ所有ノードから前記目的データを取得するネットワーク端末のコンピュータに、ピアツーピア・ネットワーク内の他のノードに対して自己のアドレス情報をルーティング情報として通知しないように制御を行うステップを実行させるコンピュータプログラムである。
本発明によれば、ネットワーク端末(リソースの小さいネットワーク端末であるとする)のアドレス情報がルーティング情報として他のノードに通知されないので、当該ネットワーク端末が他のノードのルーティングテーブルに掲載されることはなく、各ノードがデータ所有ノードのアドレス情報を取得する際にリソースの小さいノードを介した検索が行われないこととなる。これにより、アドレス情報の検索処理スピードが低下することを防ぐことができる。また、当該ネットワーク端末自体は、ルーティングテーブル生成手段とアドレス取得手段とデータ取得手段とを用いて目的データを取得することができる。
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
(第1の実施形態)
図1は、本発明の一実施形態によるネットワーク端末が適用されるピアツーピア・ネットワーク(P2Pネットワーク)を示す図である。P2Pネットワークに参加する各ノードNには、ノード固有の識別ID(例えばIPアドレスやMACアドレス等)を所定のハッシュ関数でハッシュした値がノードIDとして付与される。本実施形態では、ノードを管理する分散ハッシュテーブルとしてChordを用いる。Chordは、ハッシュ関数に例えばSHA−1(Secure Hash Algorithm 1)を使用してノードIDを2160ビットのハッシュ空間にマッピングするが、図1では簡単化のため、ハッシュ空間が2ビットであるとし、ノードIDが0から15までの16通りであるとしている。
図1のP2Pネットワークは、通信速度やCPU処理速度が高速なノード即ちリソースの大きいノードである、ブロードバンド回線に接続されたパソコンと、通信速度やCPU処理速度が低速なノード即ちリソースの小さいノードである、インターネット接続機能を有する携帯電話端末と、からなるものである。図1において、P2Pネットワークに実際に参加しているノードは、二重丸で示したノードID0,2,6,9,11,13,14の各ノードである(それぞれを以下ではノード0,ノード2,ノード6,…のように記す)。
図1のChordによるP2Pネットワークでは、P2Pネットワーク内のノードが所有しているデータに関する情報が、次のようにして複数のノードにより分散管理される。即ち、ノードが所有するデータを特定する情報、例えばそのデータのファイル名をハッシュしてハッシュ値を求める。このハッシュ値は0から15までのいずれかの値をとる。各ノードは、データのハッシュ値が「自分の1つ前のノードID+1」から「自分のノードID」までの範囲にあるデータに関する情報を、分散ハッシュテーブルにより管理する。図1の例では、ノード6はハッシュ値が3から6までのデータに関する情報を管理し、ノード9はハッシュ値が7から9までのデータに関する情報を管理することになる。例えば、「バラ」というファイル名のデータに関する情報は、ファイル名「バラ」のハッシュ値が3であるとすると、ノード6によって管理される。
図2は、ノード6とノード9が持つ分散ハッシュテーブルの一例をそれぞれ示したものである。分散ハッシュテーブルは、ハッシュ値と、ファイル名をハッシュすると当該ハッシュ値になるデータに関する情報と、が対応付けられて記述されたテーブルである。本実施形態では、「データに関する情報」は当該データを所有するノードのアドレス情報、例えばIPアドレスである。図2の例では、ノード6の分散ハッシュテーブルには、ハッシュ値が3であるファイル名「バラ」のデータを所有するノード13のIPアドレス「mmm.mmm.mmm.mmm」と、ハッシュ値が5であるファイル名「ヒマワリ」のデータを所有するノード2のIPアドレス「bbb.bbb.bbb.bbb」と、が記述されており、また、ノード9の分散ハッシュテーブルには、ハッシュ値が8であるファイル名「チューリップ」のデータを所有するノード2のIPアドレス「bbb.bbb.bbb.bbb」が記述されている。
このようにしてP2Pネットワーク内のノードが所有しているデータに関する情報が分散ハッシュテーブルを用いて管理されているので、例えば、ノード9がファイル名「バラ」のデータを取得するには、ファイル名「バラ」をハッシュしてハッシュ値3を求め、このハッシュ値3を担当するノード6から目的のデータを所有しているノード13のIPアドレス「mmm.mmm.mmm.mmm」を取得して、取得したIPアドレスを用いてノード13からファイル名「バラ」のデータを取得する、という手順を実行すればよい。
ここで、Chordを用いたP2Pネットワークでは、上記のようにあるノードが目的のデータを所有しているノードのIPアドレスを取得する際に、各ノードは次のようなルーティングテーブルを利用してルーティングを実施、つまり必要なIPアドレスを検索する。即ち、各ノードは、次式
next(Z),但しZ=(自分のノードID+2) mod 2 …(1)
を満たすノードについてのルーティング情報(ノードIDとIPアドレスの組)をルーティングテーブルとして持っている。ここで、next()はノードIDの数値が大きくなる方向で次に存在するノードのノードIDを与える関数、iは0≦i<mを満たす整数、mはハッシュ空間の大きさを2ビットとしたときのm、A mod BはAをBで割った余り、をそれぞれ意味する。各ノードは、自分が持つこのようなルーティングテーブルの中から、知りたいIPアドレスを管理しているノードのノードIDを超えずにそのノードIDに一番近いノードIDを有するノードを選び、選んだノードに対して当該IPアドレスの問い合わせを行う。この問い合わせを各ノードが順次転送していくことで、知りたいIPアドレスを管理しているノードに辿り着くことができる。
具体例で説明する。図3及び図4は、図1のP2Pネットワークにおいて、それぞれノード9とノード2が持つルーティングテーブルを示したものである。ノード9については、Z=10,11,13,1であるので、next(Z)=11,13,2となる。つまり、ノード9はノード11,13,及び2のルーティング情報をルーティングテーブルとして持つ。また、ノード2については、Z=3,4,6,10であるので、next(Z)=6,11となる。つまり、ノード2はノード6及び11のルーティング情報をルーティングテーブルとして持つ。
したがって、ノード9がノード6にIPアドレスを問い合わせる際のルーティング手順は図5のようになる。図5において、ノード9は、自分のルーティングテーブル(図3)からノード6に一番近いノードであるノード2を選んで、ノード2へIPアドレスの問い合わせを送信する。この問い合わせを受け取ったノード2は、自分のルーティングテーブル(図4)からノード6に一番近いノード、つまりノード6を選んで、ノード6へIPアドレスの問い合わせを送信する。これにより、ノード6から、問い合わせされたノード13のIPアドレスがノード9へ送信され、必要なIPアドレスの検索が完了する。ノード9は、こうして検索されたIPアドレスを用いて、ノード13からファイル名「バラ」のデータを取得することができる。
さて、上述したP2Pネットワークにおいて、通常、新たにノードがP2Pネットワークに参加する際には、当該新たに参加するノードが他のノードと同様P2Pネットワークのノードとして機能することができるように、ルーティングテーブルや分散ハッシュテーブルの更新が行われる(後述の図6参照)。
しかし、本発明に係るネットワーク端末は、P2Pネットワークに参加する際に、自分のアドレス情報をP2Pネットワーク内の他のノードにルーティング情報として通知しないように制御を行う。これにより、当該ネットワーク端末はP2Pネットワーク内のどのノードのルーティングテーブルにも掲載されることがないこととなる。したがって、当該ネットワーク端末がリソースの小さいネットワーク端末(例えば携帯電話端末)であるとすると、あるノードがIPアドレスの検索をする際にリソースの小さいノードを介した検索が行われることがないので、リソースの小さいノードがボトルネックとなって検索の処理が遅延してしまうことを防ぐことができる。
本発明に係るネットワーク端末がP2Pネットワークに参加する際の動作を、図6に示すフローチャートに沿って説明する。
まず、ネットワーク端末は、IPアドレスやMACアドレス等の固有の識別IDをハッシュ関数でハッシュし、自分のノードIDを求める(ステップS101)。ここでは、ノードIDが「4」と計算されたとする。ネットワーク端末(ノード4)は、既にP2Pネットワークに参加しているいずれか1つのノード(このノードのアドレス情報を知っているものとする)を介してルーティング情報を収集し、自分のルーティングテーブルを生成する(ステップS102)。具体的には、収集したルーティング情報を基に、上式(1)に従ってnext(Z)=6,9,13を計算し、ノード6,9,及び13のルーティング情報を記述したルーティングテーブルを生成する。
ネットワーク端末(ノード4)は、次に、自分が携帯電話端末(リソースの小さいノード)であるか否かを判断する(ステップS103)。例えば、ネットワーク端末(ノード4)はメモリに自分のノードの種別(携帯電話端末であるかパソコンであるか等)を表す情報を記憶しておき、この情報を読み出すことによって上記判断を行う。なお、ノードの種別を表す情報に代えて、P2Pネットワークへの接続方式によって変わる通信速度の情報に基づいて、自分がリソースの小さいノードであるか否かを判断するようにしてもよい。
自分が携帯電話端末ではない場合、ネットワーク端末(ノード4)は、他のノードに対して自分のノードIDとIPアドレスをルーティング情報として通知する(ステップS104)。ノード4であるネットワーク端末のルーティング情報が通知されることにより、例えばノード2については上式(1)はnext(Z)=4,6,11となるので、ノード2のルーティングテーブルは、新たに参加するノード4のルーティング情報が含まれるように更新される。
続いてネットワーク端末(ノード4)は、P2Pネットワークへ参加したことにより自分が分散ハッシュテーブルとして管理すべき情報を、現在当該情報を管理しているノードから引き継ぐ(ステップS105)。具体的に、ノード4が管理すべき情報は、現在ノード6が管理しているハッシュ値が3から4までのデータに関する情報であるので、ノード4は、これらの情報をノード6から受け取って、分散ハッシュテーブルとして管理を行う。また、このとき、ノード6の分散ハッシュテーブルは、ハッシュ値が3から4に該当する情報が削除されるように更新される。
一方、自分が携帯電話端末である場合、ネットワーク端末(ノード4)は、上記のステップS104及びステップS105を実行しない。このため、ノード4のルーティング情報は他のいずれのノードのルーティングテーブルにも掲載されないこととなり、また、ノード4は分散ハッシュテーブルを全く管理しないこととなる。
次に、上記のようにノード4が新たにP2Pネットワークに参加した後におけるIPアドレスの検索動作を具体的に説明する。図7は、ノード11がファイル名「チューリップ」のデータを取得する際にIPアドレスを問い合わせるルーティング手順を示したものである。ここで、ノード11のルーティングテーブルには、ノード4の参加前においてはノード13,0,及び6が掲載されている(式(1)より)。また、ファイル名「チューリップ」のデータに関する情報は、ノード9により管理されている(図2参照)
まずノード4が携帯電話端末ではなかった場合(図7(A))、上述したステップS104に従って、ノード11のルーティングテーブルは、ノード4がP2Pネットワークへ参加したことによってノード13,0,及び4が掲載されるように更新される。よって、ノード11は、目的のデータのファイル名「チューリップ」のハッシュ値が8であるので、ノード4へIPアドレスの問い合わせを送信する。この問い合わせを受信したノード4は、上述したステップS101で生成したルーティングテーブルに従って、IPアドレスの問い合わせをノード6へ転送する。ノード6は、自分のルーティングテーブル(ノード9,11,及び14が掲載されている)に従ってノード9へIPアドレスの問い合わせを渡す。これによりノード9からファイル名「チューリップ」のデータを所有しているノードのIPアドレス(ノード2のIPアドレス「bbb.bbb.bbb.bbb」)がノード11へ送信される。このように、IPアドレスの問い合わせはノード11→ノード4→ノード6→ノード9という経路で送られるが、新たにP2Pネットワークに参加したノード4はリソースが大きいので、遅延等は生じない。
一方ノード4が携帯電話端末であった場合(図7(B))、ノード11のルーティングテーブルは更新されないので、ノード11は、IPアドレスの問い合わせをノード6へ送信する。この問い合わせを受信したノード6は、上記の場合と同様に自分のルーティングテーブルに従ってノード9へIPアドレスの問い合わせを渡す。このように、IPアドレスの問い合わせは、ノード11→ノード6→ノード9という経路で送られる。したがって、新たにP2Pネットワークに参加したリソースの小さいノード4を経ないこととなるため、この場合も、IPアドレスの検索に遅延等が生じることがない。
(第2の実施形態)
次に、本発明の第2の実施形態を説明する。
本実施形態では、P2Pネットワーク内のノードが所有しているデータに関する情報を、第1の分散ハッシュテーブルと第2の分散ハッシュテーブルとによって管理する。第1の分散ハッシュテーブルは、ハッシュ値と、ファイル名をハッシュすると当該ハッシュ値になるデータを所有するノードのノードIDと、が対応付けられて記述されたテーブルである。第2の分散ハッシュテーブルは、ノードIDのハッシュ値と、当該ノードIDのノードのアドレス情報と、が対応付けられて記述されたテーブルである。なお、第2の分散ハッシュテーブルは、ノードIDのハッシュ値ではなく、ノードID自体と当該ノードIDのノードのアドレス情報とを対応付けて記述したテーブルとしてもよい。
図8は、第1の分散ハッシュテーブルと第2の分散ハッシュテーブルの一例を示したものである。図8の例では、ノード6についての第1の分散ハッシュテーブルと、ノード11についての第2の分散ハッシュテーブルとを示している。ノード6の第1の分散ハッシュテーブルには、ハッシュ値が3であるファイル名「バラ」のデータを所有するノード13のノードID「13」と、ハッシュ値が5であるファイル名「ヒマワリ」のデータを所有するノード2のノードID「2」と、が記述されている。ノード11の第2の分散ハッシュテーブルには、ノードID「13」のハッシュ値(このハッシュ値を10とする)に対応させて、当該ノードIDを有するノード13のIPアドレス「mmm.mmm.mmm.mmm」が記述されている。
このような第1及び第2の分散ハッシュテーブルを用いて、例えばノード9がファイル名「バラ」のデータを取得するには、次の2段階の手順をとる。まず第1段階として、ノード9は、ファイル名「バラ」をハッシュしてハッシュ値3を求め、このハッシュ値3を図8の第1の分散ハッシュテーブルにより管理するノード6から、目的のデータを所有しているノード13のノードID「13」を取得する。次に第2段階として、ノード9は、取得したノードID「13」をハッシュしてハッシュ値10を求め、このハッシュ値10を図8の第2の分散ハッシュテーブルにより管理するノード11から、ノード13のIPアドレス「mmm.mmm.mmm.mmm」を取得する。これにより、ノード9は、取得したIPアドレスを用いてノード13からファイル名「バラ」のデータを取得することができる。
ここで、本実施形態において、あるノードが目的のデータを所有しているノードのIPアドレスを上記の第1及び第2段階に従って取得する際、各段階で必要なノードIDとIPアドレスを検索するルーティングの手順は、前述した第1の実施形態と同じであり、前述の式(1)に基づくルーティングテーブルを用いる。図9は、上記の第1及び第2段階それぞれのルーティング手順を示したものである。
図9(A)の第1段階では、ノード9は、自分のルーティングテーブル(図3)からノード6に一番近いノードであるノード2を選んで、ノード2へノードIDの問い合わせを送信する。この問い合わせを受け取ったノード2は、自分のルーティングテーブル(図4)からノード6に一番近いノード、つまりノード6を選んで、ノード6へノードIDの問い合わせを送信する。これにより、ノード6から、問い合わせされたノード13のノードIDがノード9へ送信され、必要なノードIDの検索が完了する。
図9(B)の第2段階では、ノード9は、自分のルーティングテーブル(図3)からノード11に一番近いノード、つまりノード11を選んで、ノード11へIPアドレスの問い合わせを送信する。これにより、ノード11から、問い合わせされたノード13のIPアドレスがノード9へ送信され、必要なIPアドレスの検索が完了する。ノード9は、こうして検索されたIPアドレスを用いて、ノード13からファイル名「バラ」のデータを取得することができる。
上述した第1及び第2の分散ハッシュテーブルを構築するため、ネットワーク端末は、P2Pネットワークに参加して自分が所有するデータを他のノードと共有する際に、当該データのファイル名のハッシュ値を担当するノードに当該ハッシュ値と自分のノードIDとを送信し(送信されたハッシュ値とノードIDは対応付けられて第1の分散ハッシュテーブルに記述される)、自分のノードIDのハッシュ値を担当するノードに当該ハッシュ値と自分のIPアドレスとを送信する(送信されたハッシュ値とIPアドレスは対応付けられて第2の分散ハッシュテーブルに記述される)。IPアドレスが変更された際には、再度あらためて、自分のノードIDのハッシュ値を担当するノードに当該ハッシュ値と変更後の自分のIPアドレスとを送信する。これにより、例えばネットワーク端末が携帯電話端末であり、電波状況の悪化により回線が一時切断されその後再接続されたような場合に、再接続の前後でIPアドレスが変化したとしても、そのネットワーク端末が所有しているデータを他のノードがアクセスして取得することが可能である。
(第3の実施形態)
次に、本発明の第3の実施形態を説明する。
本実施形態では、前述した第2の分散ハッシュテーブルに、ノードIDのハッシュ値と対応付けて、当該ノードIDのノードのアドレス情報に加えて更に当該ノードの状態に関する情報を記述する。図10は、本実施形態における第1及び第2の分散ハッシュテーブルの一例を示したものである。図10の例では、ノード6についての第1の分散ハッシュテーブルと、ノード11についての第2の分散ハッシュテーブルと、ノード0についての第2の分散ハッシュテーブルとを示しており、「ノードの状態に関する情報」として回線品質情報と更新日時情報を用いている。
ノード6の第1の分散ハッシュテーブルには、ハッシュ値が3であるファイル名「バラ」のデータを所有している2つのノード、ノード13とノード2のそれぞれのノードID「13」及び「2」が記述されている。ノード11の第2の分散ハッシュテーブルには、ノードID「13」のハッシュ値(このハッシュ値を10とする)に対応させて、当該ノードIDを有するノード13のIPアドレス「mmm.mmm.mmm.mmm」と、当該ノード13の回線品質情報と、更新日時情報と、が記述されている。また、ノード0の第2の分散ハッシュテーブルには、ノードID「2」のハッシュ値(このハッシュ値を15とする)に対応させて、当該ノードIDを有するノード2のIPアドレス「bbb.bbb.bbb.bbb」と、当該ノード2の回線品質情報と、更新日時情報と、が記述されている。更新日時情報は、当該ノードについてIPアドレスと回線品質情報とを更新した日時を表すものである。
本実施形態のネットワーク端末は、P2Pネットワークに参加して自分が所有するデータを他のノードと共有する際に、当該データのファイル名のハッシュ値を担当するノードに当該ハッシュ値と自分のノードIDとを送信(第2の実施形態と同様)し、自分のノードIDのハッシュ値を担当するノードに対しては、当該ハッシュ値と自分のIPアドレスと回線品質情報とを送信する(送信されたハッシュ値とIPアドレスと回線品質情報が第2の分散ハッシュテーブルに記述される際に更新日時情報も記述される)。自分のIPアドレスと回線品質情報の送信は、例えば10分おき等、定期的に行うようにすることが好ましい。
このような第2の分散ハッシュテーブルを用いて、例えばノード9がファイル名「バラ」のデータを取得する手順は、第2の実施形態と同様の第1及び第2段階に従う。
即ち、第1段階では、ノード9は、ファイル名「バラ」をハッシュしてハッシュ値3を求め、このハッシュ値3を図10の第1の分散ハッシュテーブルにより管理するノード6から、目的のデータを所有しているノード13及びノード2のノードID「13」,「2」を取得する。
第2段階では、ノード9は、第1段階で取得したノードID「13」をハッシュしてハッシュ値10を求め、このハッシュ値10を図10の第2の分散ハッシュテーブルにより管理するノード11から、ノード13のIPアドレス「mmm.mmm.mmm.mmm」と回線品質情報と更新日時情報とを取得するとともに、同じく第1段階で取得したノードID「2」をハッシュしてハッシュ値15を求め、このハッシュ値15を図10の第2の分散ハッシュテーブルにより管理するノード0から、ノード2のIPアドレス「bbb.bbb.bbb.bbb」と回線品質情報と更新日時情報とを取得する。
そして、ノード9は、このようにして求めたファイル名「バラ」のデータを所有するノード13とノード2という2つのノードのうち、それぞれの回線品質情報や更新日時情報を適宜考慮していずれかを選択し、選択したノードからそのIPアドレスを用いてファイル名「バラ」のデータを取得する。なお、回線品質が良好で更新日時が新しいノードを選択することが好ましい。このように同じデータを所有するノードが複数ある場合に、ノードの状態を考慮して最適なノードからデータを取得することが可能である。
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
例えば、分散ハッシュテーブルとしてChordを用いる実施形態を説明したが、本発明は分散ハッシュテーブルの種類を特に限定するものではない。また、ルーティング手順も上述した式(1)に基づくルーティングテーブルを用いるものに限定されず、例えば、各ノードが隣り合ったノードのルーティング情報をルーティングテーブルとして持ち、順次隣のノードへIPアドレス等の問い合わせを転送するというルーティング手順としてもよい。
また、本発明においてネットワーク端末は、P2Pネットワークに参加できる通信機能を有する端末を意味し、携帯電話端末の他、例えばPHS(Personal Handyphone System)端末やPDA(Personal Digital Assistants)端末、パソコン(ダイヤルアップ接続の場合等)などを含むものとする。また、これらネットワーク端末は、CPU等の処理装置とROM等の記憶装置を備えるものであり、上記説明した各機能を実現するためのコンピュータプログラムをROM等に記憶させておき、CPU等がこのコンピュータプログラムを読み出して実行することによって、本発明に係るネットワーク端末を構成するようにしてもよい。
また、本発明はP2Pネットワークにおいて、ファイル共有やインターネット電話に限られずその他のアプリケーションにも広く適用可能であることは言うまでもない。
本発明の一実施形態によるネットワーク端末が適用されるP2Pネットワークを示す図である。 第1の実施形態においてノード6とノード9が持つ分散ハッシュテーブルの一例を示した図である。 第1の実施形態においてノード9が持つルーティングテーブルを示した図である。 第1の実施形態においてノード2が持つルーティングテーブルを示した図である。 第1の実施形態においてノード9がノード6にIPアドレスを問い合わせる際のルーティング手順を示した図である。 ネットワーク端末がP2Pネットワークに参加する際の動作を示すフローチャートである。 第1の実施形態において、ノード4が新たにP2Pネットワークに参加した後にノード11がIPアドレスを問い合わせるルーティング手順を示した図である。 第2の実施形態において第1の分散ハッシュテーブルと第2の分散ハッシュテーブルの一例を示した図である。 第2の実施形態においてノード9がノードIDとIPアドレスを問い合わせる際のルーティング手順を示した図である。 第3の実施形態において第1の分散ハッシュテーブルと第2の分散ハッシュテーブルの一例を示した図である。
符号の説明
N…ノード(ネットワーク端末)

Claims (6)

  1. ピアツーピア・ネットワーク内の他のノードからルーティング情報を取得して自己のルーティングテーブルを生成するルーティングテーブル生成手段と、
    前記生成したルーティングテーブルに記述されているノードを介して、目的データを所有しているデータ所有ノードのアドレス情報を取得するアドレス取得手段と、
    前記取得したアドレス情報を用いて前記データ所有ノードから前記目的データを取得するデータ取得手段と、を備えたネットワーク端末において、
    ピアツーピア・ネットワーク内の他のノードに対して自己のアドレス情報をルーティング情報として通知しないように制御を行う第1の制御手段を備えることを特徴とするネットワーク端末。
  2. 目的データを特定するデータ特定情報と該目的データを所有しているデータ所有ノードを特定するノード特定情報とを対応付けた第1テーブル、及び、前記ノード特定情報と該ノード特定情報で特定されるデータ所有ノードのアドレス情報とを対応付けた第2テーブルが前記ピアツーピア・ネットワークのノードにより管理され、
    前記第1テーブルを保持するノードに自己が所有する目的データのデータ特定情報と自己のノード特定情報とを送信し、前記第2テーブルを保持するノードに自己のノード特定情報と自己のアドレス情報とを送信するように制御を行う第2の制御手段を備えることを特徴とする請求項1に記載のネットワーク端末。
  3. 前記第2テーブルは、前記ノード特定情報に対応付けて、前記アドレス情報に加えて該データ所有ノードの状態を示すノード状態情報を記述したものであり、
    前記第2の制御手段は、前記第2テーブルを保持するノードに自己のノード特定情報と自己のアドレス情報と自己のノード状態情報とを送信するように制御を行う
    ことを特徴とする請求項2に記載のネットワーク端末。
  4. 前記アドレス取得手段は、
    目的データを特定するデータ特定情報が記述された前記第1テーブルを保持するノードから、該データ特定情報と対応するノード特定情報を取得する第1取得手段と、
    前記取得したノード特定情報が記述された前記第2テーブルを保持するノードから、該ノード特定情報と対応するアドレス情報を取得する第2取得手段と、からなる
    ことを特徴とする請求項2または請求項3に記載のネットワーク端末。
  5. 前記第2取得手段は、前記第1取得手段により取得したノード特定情報が記述された第2テーブルを保持するノードから、該ノード特定情報と対応するアドレス情報及びノード状態情報を取得し、
    前記データ取得手段は、前記取得したノード状態情報に基づいて選択したデータ所有ノードから目的データを取得する
    ことを特徴とする請求項4に記載のネットワーク端末。
  6. ピアツーピア・ネットワーク内の他のノードからルーティング情報を取得して自己のルーティングテーブルを生成し、前記生成したルーティングテーブルに記述されているノードを介して、目的データを所有しているデータ所有ノードのアドレス情報を取得し、前記取得したアドレス情報を用いて前記データ所有ノードから前記目的データを取得するネットワーク端末のコンピュータに、
    ピアツーピア・ネットワーク内の他のノードに対して自己のアドレス情報をルーティング情報として通知しないように制御を行うステップを実行させるコンピュータプログラム。
JP2007334078A 2007-12-26 2007-12-26 ネットワーク端末及びコンピュータプログラム Pending JP2009157575A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007334078A JP2009157575A (ja) 2007-12-26 2007-12-26 ネットワーク端末及びコンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007334078A JP2009157575A (ja) 2007-12-26 2007-12-26 ネットワーク端末及びコンピュータプログラム

Publications (1)

Publication Number Publication Date
JP2009157575A true JP2009157575A (ja) 2009-07-16

Family

ID=40961549

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007334078A Pending JP2009157575A (ja) 2007-12-26 2007-12-26 ネットワーク端末及びコンピュータプログラム

Country Status (1)

Country Link
JP (1) JP2009157575A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013508878A (ja) * 2009-10-27 2013-03-07 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 共起セレンディピティレコメンダ
JP2015512231A (ja) * 2012-03-15 2015-04-23 アルカテル−ルーセント 高速かつ大規模な最長プレフィックスマッチングのための方法およびシステム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013508878A (ja) * 2009-10-27 2013-03-07 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 共起セレンディピティレコメンダ
JP2015512231A (ja) * 2012-03-15 2015-04-23 アルカテル−ルーセント 高速かつ大規模な最長プレフィックスマッチングのための方法およびシステム
US9729669B2 (en) 2012-03-15 2017-08-08 Alcatel Lucent Method and system for fast and large-scale longest prefix matching

Similar Documents

Publication Publication Date Title
JP6047229B2 (ja) 情報中心ネットワークにおける名前ベースの近隣探索及びマルチホップサービス探索
US7978631B1 (en) Method and apparatus for encoding and mapping of virtual addresses for clusters
JP5049344B2 (ja) ランデブーフェデレーション内の近傍域間通信
US20070230468A1 (en) Method to support mobile devices in a peer-to-peer network
US8898266B2 (en) Apparatus and method for setting role based on capability of terminal
TWI584194B (zh) 在一服務導向架構(soa)網路中尋求服務之技術
KR20090034829A (ko) 랑데뷰 연합 내에서의 근접지간 통신을 위한 방법, 컴퓨터 판독가능 매체 및 컴퓨터 프로그램 제품
JP2009543447A5 (ja)
JP2008011448A (ja) アドホックネットワーク、ノード、経路制御方法、及び経路制御プログラム
WO2011049491A1 (en) Method and arrangement for locating services in a peer-to-peer network
Shah et al. MANET adaptive structured P2P overlay
JP4472001B2 (ja) ゾーンベースのピアツーピア通信
Bertier et al. D2HT: the best of both worlds, Integrating RPS and DHT
JP4533923B2 (ja) 階層型ピアツーピアシステムにおける負荷バランシング機能を有するスーパーピア及び該スーパーピアを動作させる方法
JP2009230369A (ja) 共有データの同期方法、共有データを同期するためのプログラム、および共有データを同期して保持可能なネットワークシステム
EP2375692B1 (en) Apparatus and method for registering node and searching for floating internet protocol address using distributed network
JP2009157575A (ja) ネットワーク端末及びコンピュータプログラム
JP5440574B2 (ja) ノード装置、情報通信方法及びプログラム
Maddali et al. A Comprehensive Study of Some Recent Proximity Awareness Models and Common-Interest Architectural Formulations among P2P Systems
Pethalakshmi et al. Geo-chord: Geographical location based chord protocol in grid computing
Chae et al. Fast discovery scheme using DHT-like overlay network for a large-scale DDS
KR101613688B1 (ko) 노드 간 삼각관계를 이용한 피어 투 피어 소셜 네트워킹 서비스 제공방법
US11481359B2 (en) Parallel distributed ledger construction
KR100872170B1 (ko) P2p 네트워크 다중 라우팅 방법
JP2006221457A (ja) Pure型P2P通信におけるレプリケーション制御を行うサーバントとそのレプリケーション制御方法およびプログラム