JP2005333374A - ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム - Google Patents

ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム Download PDF

Info

Publication number
JP2005333374A
JP2005333374A JP2004149416A JP2004149416A JP2005333374A JP 2005333374 A JP2005333374 A JP 2005333374A JP 2004149416 A JP2004149416 A JP 2004149416A JP 2004149416 A JP2004149416 A JP 2004149416A JP 2005333374 A JP2005333374 A JP 2005333374A
Authority
JP
Japan
Prior art keywords
domain
name
computer
information
search
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
JP2004149416A
Other languages
English (en)
Inventor
Yusuke Doi
井 裕 介 土
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.)
Toshiba Corp
Original Assignee
Toshiba 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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2004149416A priority Critical patent/JP2005333374A/ja
Priority to US11/129,433 priority patent/US20060047786A1/en
Publication of JP2005333374A publication Critical patent/JP2005333374A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/742—Route cache; Operation thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】 多数の検索要求を高速に処理する。
【解決手段】 本発明のネットワーク検索システムは、ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、ドメイン名空間における一部のドメインを受け持つアクセス装置であって、前記ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、前記計算機の少なくとも１つに対して、前記名前解決依頼に基づく検索を指示して検索結果を受け取り、受け取った前記検索結果を前記名前解決依頼に対する応答として送出するアクセス装置と、前記アクセス装置に対して前記ドメインの名を含むドメイン名の名前解決を依頼し、前記依頼に対する応答として、前記アクセス装置から前記検索結果を受け取る利用者側装置と、を備える。
【選択図】 図１

Description

本発明は、ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラムに関する。
木構造のドメイン名空間を管理するドメイン名システム（DNS）がインターネット等で広く用いられている。このDNSは、ゾーンを管理するDNSサーバが論理的にツリー状に接続されたものである。利用者は、このDNSに問い合わせることで、指定のドメイン名に対応付けられた情報を取得できる。
より詳しくは、ドメイン名に対応付けられた情報を取得するためには、DNSに対してDNS問い合わせを反復的に行って、ドメイン名に含まれるゾーンを管理するDNSサーバを特定し、特定されたDNSサーバから、ドメイン名に対応付けられた情報を取得するのが一般的である。
しかし、このようなDNSでは、例えば、あるゾーンを管理するDNSサーバに対して、多くの情報を登録（多くのレコードを登録）した場合、検索に多くの時間がかかってしまう。また、世界中から多くのDNS問い合わせがこのDNSサーバに集中した場合などは、処理遅延の問題はさらに大きくなる。
特開２００３−３１８９４２公報
本発明は、上記問題点に鑑みてされたものであり、その目的は、多くの検索要求を高速に処理できるネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラムを提供することにある。
本発明のネットワーク検索システムは、ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、ドメイン名空間における一部のドメインを受け持つアクセス装置であって、前記ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、前記計算機の少なくとも１つに対して、前記名前解決依頼に基づく検索を指示して検索結果を受け取り、受け取った前記検索結果を前記名前解決依頼に対する応答として送出するアクセス装置と、前記アクセス装置に対して前記ドメインの名を含むドメイン名の名前解決を依頼し、前記依頼に対する応答として、前記アクセス装置から前記検索結果を受け取る利用者側装置と、を備える。
本発明のネットワーク検索システムは、ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、ドメイン名空間における一部のドメインを受け持ち、前記ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、前記計算機の少なくともいずれかの所在情報を前記名前解決依頼に対する応答として送出するブリッジ装置と、前記ブリッジ装置に対して前記ドメインの名を含むドメイン名の名前解決依頼を行って前記ブリッジ装置から前記計算機の所在情報を取得し、取得した前記計算機の所在情報に対応する前記計算機に対して検索を指示し、検索結果を取得する利用者側装置と、を備える。
本発明のネットワーク検索システムは、ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、各前記計算機に対応して配置され、ドメイン名空間の一部である第１ドメインを受け持つ変換装置であって、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、対応する前記計算機に対して前記名前解決依頼に基づく検索を指示して検索結果を受け取り、受け取った前記検索結果を前記名前解決依頼に対する応答として送出する変換装置と、前記変換装置を管理し、前記第１ドメインよりも上階層の第２ドメインの管理を受け持つブリッジ装置であって、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取った場合には、前記変換装置の少なくともいずれかの所在情報を、名前解決のための委任先として、前記名前解決依頼の送出元に通知するブリッジ装置と、前記ブリッジ装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って前記名前解決のための委任先としての前記変換装置の所在情報を取得し、前記変換装置の所在情報に対応する前記変換装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って、前記名前解決依頼の応答として前記変換装置から検索結果を取得する利用者側装置と、を備える。
本発明の情報検索方法は、ネットワーク上に配置された複数の計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する情報検索方法であって、ドメイン名空間における一部のドメインを受け持つブリッジ装置が、前記ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する検出ステップと、前記ブリッジ装置が、前記計算機の少なくともいずれかを選択する選択ステップと、前記検出ステップで前記名前解決依頼を受け取ったことを検出した場合は、前記選択ステップによって選択された前記計算機の所在情報を、前記名前解決依頼の送出元に通知する通知ステップと、利用者側装置が前記ブリッジ装置に対して前記ドメインの名を含むドメイン名の名前解決依頼を行って前記ブリッジ装置から前記計算機の所在情報を取得する第１取得ステップと、前記利用者側装置が、取得した前記計算機の所在情報に対応する前記計算機に対して検索を指示し、検索結果を取得する第２取得ステップと、を備える。
本発明の情報検索方法は、ネットワーク上に配置された複数の計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する情報検索方法であって、各前記計算機に対応して配置され、ドメイン名空間の一部である第１ドメインを受け持つ変換装置が、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する第１検出ステップと、前記第１検出ステップによって前記名前解決依頼を受け取ったことを検出した場合は、前記変換装置が、対応する前記計算機に対して前記名前解決依頼に基づく検索を指示して検索結果を受け取る受取ステップと、前記変換装置が、受け取った前記検索結果を前記名前解決依頼に対する応答として送出する送出ステップと、前記変換装置を管理し、前記第１ドメインよりも上階層の第２ドメインの管理を受け持つブリッジ装置が、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する第２検出ステップと、前記ブリッジ装置が、前記変換装置の少なくともいずれかを選択する選択ステップと、前記第２検出ステップによって前記名前解決依頼を受け取ったことを検出した場合は、前記ブリッジ装置が、前記選択ステップによって選択された前記変換装置の所在情報を、名前解決のための委任先として、前記名前解決依頼の送出元に通知する通知ステップと、利用者側装置が、前記ブリッジ装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って前記名前解決のための委任先としての前記変換装置の所在情報を取得する第１取得ステップと、前記利用者側装置が、前記変換装置の所在情報に対応する前記変換装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って前記名前解決依頼の応答として前記変換装置から検索結果を取得する第２取得ステップと、を備える。
本発明のブリッジ装置は、ネットワーク上のドメイン名空間における一部のドメインを受け持つブリッジ装置であって、ネットワーク上に配置された複数の計算機であって、前記複数の計算機のいずれかがある情報の検索を指示された場合に、分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する前記複数の計算機を管理する管理部と、前記ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する検出部と、前記検出部によって前記名前解決依頼を受け取ったことを検出した場合に、予め与えられた規則に従って前記管理部によって選択された前記計算機の所在情報を、前記名前解決依頼に対する応答として送出する応答部と、を備える。
本発明のプログラムは、ネットワーク上のドメイン名空間における一部のドメインを受け持つ装置で実行するプログラムであって、ネットワーク上に配置された複数の計算機であって、前記複数の計算機のいずれかがある情報の検索を指示された場合に、分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する前記複数の計算機の少なくともいずれかを、予め与えられた規則に従って選択する選択ステップと、前記ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する検出ステップと、前記検出ステップによって前記名前解決依頼を受け取ったことを検出した場合に、前記選択ステップによって選択された前記計算機の所在情報を、前記名前解決依頼に対する応答として送出する応答ステップと、を備える。
本発明により、多くの検索要求を高速に処理できる。
本実施の形態は、Chordアルゴリズムに代表される分散ハッシュアルゴリズムに従って検索処理を行う分散ハッシュテーブル（DHT）ネットワークを、既存のインターネット等で用いられているドメイン名システム（DNS）に接続することにより、利用者側の装置から、既存のDNSを介してDHTネットワークを利用可能にすることを特徴とする。
DHTの参考文献としては、例えば分散ハッシュアルゴリズムの代表例であるChordの文献（Ion Stoica, Robert Morris, David Karger, M.Frans Kaashoek, and Hari Balakrishnan, Chord:A Scalable Peer-to-peer Lookup Service for Internet Applications, ACM SIGCOMM 2001）がある。また、DNSの参考文献としては例えばRFC1034およびRFC1035がある。
ここで、DHTネットワークの特性について述べると以下の通りである。
DHTネットワークでは、DHTネットワークを構成する各計算機において検索指示を受け付け可能であり、ある計算機が検索指示を受けると各計算機が協働して検索処理を行う。つまりDHTネットワークでは、特定の計算機に通信及び権限が集中しない。各計算機に負荷が分散されるので、多数の検索要求を高速に処理できる。また、耐故障性が高く、漸進的な計算機の導入が可能である。つまり、全体の処理量が増加した場合などは、その都度計算機を追加すればよい。言い換えると、DHTネットワークでは、DHTネットワークの設計に当たり、予め負荷が集中する箇所を特定してその箇所の耐性を高めるといった事前設計を行う必要性は低い。
また、DHTネットワークでは、DHTネットワークを構成する計算機の台数が増加すると、台数の増加に比例してDHTネットワークの容量（処理速度・記憶容量等）は大きくなるが、これに対しDHTネットワークにおける通信及び遠隔呼び出し手続き（あるコンピュータからネットワーク経由で別のコンピュータに処理を依頼する方法の一つ）の増加等は緩やかである。従って、DHTネットワークは、計算機の追加により、その性能を容易に拡張できる。
本実施の形態では、以上のような特性を有するDHTネットワークを、既存のDNSを介して利用することで、多数の検索を高速に処理でき、耐久性及び拡張性の高いネットワーク検索システムを実現する。
図１は、本発明の実施の形態に従ったネットワーク検索システムの構成を概略的に示す図である。
図１のDNS１０は、木構造のドメイン名空間を管理するもので、論理的にツリー状に接続されたDNSサーバ群を有する。図１には、そのDNSサーバ群の一部、DNSサーバ１２〜１４が示される。DNSサーバ１２は、ルートドメインの管理を委任され、DNSサーバ１３は、comドメインの管理を委任され、DNSサーバ１４はexample.comドメインの管理を委任されている。
スタブリゾルバ１８は、クライアント装置１９からドメイン名のDNS問い合わせを受け取り、DNS１０及び後述のアクセス装置１５にDNS問合わせすることにより、このドメイン名に対応する情報をDHTネットワーク１６から取得して、クライアント装置１９に返す。DNS問い合わせは、例えば名前解決依頼に対応する。
DHTネットワーク１６は、分散ハッシュアルゴリズムに従って検索処理を実行する複数の計算機１７を備える。DHTネットワーク１６の空間は、ｎビットからなるID空間である。DHTネットワーク１６のID空間は、木構造を有するDNSのドメイン名空間と異なり、特定の階層構造を有さない。DHTネットワーク１６に参加する各計算機１７にはそれぞれｎビットのIDが割り当てられる。また、各計算機１７はそれぞれ、ｎビットのIDと情報とを対応づけたデータベースを管理する。各計算機１７はそれぞれ所定の範囲のIDを管理する。DHTネットワーク１６における任意の計算機１７は、検索情報に基づく検索指示を受け取ると、例えば、受け取った検索情報を所定のハッシュ関数（例えばSHA1）に入力してハッシュ値（ID）（SHA1を用いた場合は１６０ビットの一意な値）を得、その後、各計算機１７による協調動作により、このIDをデータベースにおいて管理する計算機１７が特定される。特定された計算機１７は、このIDに対応する情報をデータベースから検索し、検索した計算機あるいは検索情報を受け取った計算機は、検索された情報を、検索結果として返す。
アクセス装置１５は、スタブリゾルバ１８がDNS１０を介してDHTネットワーク１６へアクセスすることを実現する。つまり、全世界的に共通であるDNS１０のドメイン名空間から、DHTネットワーク１６のID空間を利用可能にする。このためには、DNS１０のドメイン名空間の一部を、DHTネットワーク１６のID空間のために割り当てる必要がある。具体的には、階層構造を有さないDHTネットワーク１６のID空間全てを、DNS１０のドメイン名空間の単一階層、つまり単一のドメインに収容する。
より詳細には、図１に示すように、DNS１０の一部空間（本例ではdht.example.comとする）に対する権限をアクセス装置１５に委譲する（アクセス装置１５のドメイン名はns.dht.example.comとする）。権限を委譲するには、NSリソースレコードを用いて、上位のDNSサーバ、例えばDNSサーバ１４（example.comドメインを管理）に委譲の旨を記述する。具体的に、dht.example.comドメイン以下のDNS問い合わせを、アクセス装置１５に向けるには、以下のようなリソースレコードの組み合わせを、DNSサーバ１４に登録する。アクセス装置を複数、配置した場合は各アクセス装置についてリソースレコードの組合せを登録する。
dht.example.com. IN NS ns.dht.example.com
ns.dht.example.com IN A（アクセス装置１５に割り当てられたIPv4アドレス）
ns.dht.example.com IN AAAA（アクセス装置１５に割り当てられたIPv６アドレス）
この登録により、アクセス装置１５に対してdht.example.comドメインに対する権限が委譲される。従って、dht.example.comドメインを含むドメイン名に対する全てのDNS問い合わせはアクセス装置１５に向かう。つまり、dht.example.comドメイン以下のDNS問い合わせはアクセス装置１５によって解釈される。
アクセス装置１５は、自身の管理するドメインを含むドメイン名のDNS問い合わせをスタブリゾルバ１８から受け取ると、受け取ったDNS問い合わせに基づき、DHTネットワークへの検索情報を生成する。アクセス装置１５は、生成した検索情報に基づく検索指示を、DHTネットワーク１６におけるいずれかの計算機１７に渡す。後述する所定の手法を用いて計算機１７を選択してもよい。アクセス装置１５は、DHTネットワーク１６による検索結果を受け取り、受け取った検索結果を、スタブリゾルバ１８からのDNS問い合わせに対する応答として、DNSプロトコルに従ったメッセージ形式を用いて返す。スタブリゾルバ１８は、検索結果を、クライアント装置１９からのDNS問い合わせに対する応答として返す。
次に、本ネットワーク検索システムによる動作例について説明する。
クライアント装置１９が、ユーザ等により入力されたドメイン名、例えば1234.dht.example.comに対するDNS問い合わせをスタブリゾルバ１８に依頼する（S1）。
スタブリゾルバ１８は、DNSサーバ１２〜１４に必要に応じて順次、反復的にDNS問い合わせを行って、DNSサーバ１４から、dht.example.comドメインに対する権限がアクセス装置１５に委譲された旨を取得する（S2〜S4）。これに基づき、スタブリゾルバ１８は、次にアクセス装置１５に対してDNS問い合わせを行う（S5）。
アクセス装置１５は、スタブリゾルバ１８からのDNS問い合わせに基づき、DHTネットワーク１６への検索情報を生成する。例えば、アクセス装置１５は、問い合わせに係るドメイン名1234.dht.example.comのうち1234を検索情報として抽出する。つまり、この場合、アクセス装置１５は、自身が管理するレベルのドメイン名dhtより下位レベルのドメイン名1234を検索情報として抽出する（S6）。アクセス装置１５は、抽出した検索情報を、DHTネットワーク１６におけるいずれかの計算機１７に送出する（S6）。
計算機１７は、受け取った検索情報（1234）のハッシュ値（ID）を求め、各計算機１７による協調動作により、このIDを管理する計算機１７が特定される（S7）。特定された計算機１７は、このIDに対応付けられた情報（例えばURL、IPアドレス）を自身のデータベースから検索し、この計算機１７又は検索情報を受け取った計算機１７は、検索結果をアクセス装置１５に返す（S7）。
アクセス装置１５は、受け取った検索結果を、スタブリゾルバ１８からのDNS問い合わせに対する応答として、スタブリゾルバ１８に返す（S8）。
スタブリゾルバ１８は、受け取った検索結果を、クライアント装置１９からの問い合わせに対する応答として、クライアント装置１９に返す（S9）。この後、クライアント装置１９は、例えば、検索結果がURLである場合は、このURLを割り当てられた装置（図示せず）にアクセスして、所望の情報（例えばシリアル番号1234を有する製品についての情報）を取得する。
図２は、本発明の別の実施の形態に従ったネットワーク検索システムの基本的な構成を示す図である。
上述した実施の形態では、アクセス装置１５がDHTネットワーク１６への検索指示及び検索結果の受け取りを行う必要があったため、多数のDNS問い合わせがアクセス装置１５に寄せられた場合は、アクセス装置１５がボトルネックになって全体処理が遅くなる問題が生じ得る。本実施の形態ではかかる問題を解決しようとするものである。以下本実施の形態について詳しく説明する。
図２に示すように、ブリッジ装置２１は、DNS１０のドメイン名空間のうち、特定のドメイン（第１ドメイン）（本例ではdht.example.comとする）の管理を委任されている。このdht.example.comドメインよりも上位のドメインを管理するDNSサーバ、例えばDNSサーバ１４には、dht.example.comドメインに対する権限をブリッジ装置２１に委譲するリソースレコードが登録される。ブリッジ装置を複数設けた場合は、これらブリッジ装置群に対して権限委譲を行う。以下、ブリッジ装置２１についてさらに詳しく説明する。
図３は、ブリッジ装置２１の構成を示すブロック図である。
図３に示すように、ブリッジ装置２１におけるDNS問い合わせ受け付け部３０は、DNSサーバ１４から転送されたスタブリゾルバ２５からのDNS問い合わせ（例えば123456.q.dht.example.comのDNS問い合わせ）を受け付ける。
TTL決定部３４は、DNS問い合わせ受け付け部３０においてDNS問い合わせがあった場合は、予め設定された定数、あるいは後述する手法を用いて、TTL（Time to Live:有効期限）を決定し、DNS応答合成部３３に出力する。
ブリッジ装置２１におけるDHT権限委譲機構３１は、DNS問い合わせ受け付け部３０においてDNS問い合わせがあった場合は、第１ドメイン（dht.example.com）以下のドメイン（第２ドメイン）（本例ではq.dht.example.comとする）（図２参照）についての権限委譲を、DHTネットワーク２２を構成する、所定の手法（後述）により選択した計算機２３に対して行う。DHT権限委譲機構３１についてさらに詳しく説明すると以下の通りである。
DHT権限委譲機構３１におけるノード集合管理部３２は、随時DHTネットワーク２２にアクセスして、DHTネットワーク２２に参加している計算機の情報（IPアドレス等）を収集して、計算機のリスト（例えばIPアドレスのリスト）を生成する。
ノード集合管理部３２は、DNS問い合わせ受け付け部３０においてDNS問い合わせがあった場合は、生成した計算機のリストに基づき、所定の手法により計算機を選択する。より詳しくは、適切な数の計算機を、適切な方法によって選択する。
ここで、「適切な数」とは、例えば、DNS問い合わせ応答に用いられるUDPデータグラムに搭載可能な数である。仮に５１２バイトのデータグラムにIPv4アドレスとIPv6アドレスとを対にして搭載する場合、５〜１０になると予測される。
「適切な方法」とは、例えば、ランダムに選択する、計算機の負荷状態に応じて選択する、問い合わせ元（スタブリゾルバ２５）のIPアドレスとネットワーク経路的に近傍の計算機を選択する、これらの組み合わせにより選択するなどがある。これについては後でさらに詳しく述べる。
DHT権限委譲機構３１は、上述の所定の手法により選択した単一又は複数の計算機の情報（例えばIPアドレス）を、DNS応答合成部３３に出力する。
DHTネットワーク２２における計算機２３の集合は常に変化し、不確定であることに対応して、ノード集合管理部３２は、DHTネットワーク２２から計算機が離脱したことを検知した場合は、その計算機についての情報を消去する。
DHT権限委譲機構３１におけるDNS応答合成部３３は、DNS問い合わせ受け付け部３０においてDNS問い合わせがあった場合は、ノード集合管理部３２によって選択された各計算機２３のそれぞれに対して第２ドメイン（q.dht.example.com）の権限を委譲することを示すリソースレコードを生成する。具体的には、選択された各計算機２３に対してそれぞれドメイン名を生成した上、NSリソースレコード及びグルーA/AAAAレコード（DNSレコード）を生成する。以下に、一例として、IPv４アドレス1.2.3.4を有する計算機について生成されたDNSレコードを示す。なお、このDNSレコードの記述はBIND準拠とする。
q.dht.example.com. 6435 IN NS 1-2-3-4.n.q.dht.example.com
1-2-3-4.n.q.example.com. 6435 IN A 1.2.3.4
但し、6435はTTL決定部３４によって決定されたTTLである。1.2.3.4.n.q.dht.example.comは、このIPv4アドレスに基づき生成されたドメイン名である。1.2.3.4は、選択された計算機のIPv4アドレスである。
応答送信部３５は、DNS応答合成部３３により生成されたDNSレコードを含むメッセージを、DNS問い合わせ元（スタブリゾルバ２５）に送出する。スタブリゾルバ２５は、このメッセージ内のDNSレコードにより、権限の委譲を確認する。スタブリゾルバ２５は、メッセージに含まれるIPアドレス（メッセージ内に複数のIPアドレスが含まれる場合はその中から選択した１つのIPアドレス）を有する計算機に対して、DNS問い合わせ（例えば123456.q.dht.example.comのDNS問い合わせ）を行う。
以上から分かるように、ブリッジ装置２１は、スタブリゾルバ２５からDNS問い合わせを受け取ると、第２ドメイン（q.dht.example.com）の権限委譲を、所定の手法により選択した計算機２３に対して行う。従って、権限の委譲先は各計算機に適度に分散され、よって、スタブリゾルバ２５から計算機へのDNS問い合わせは、特定の計算機に集中しない。
図２に戻って、DHTネットワーク２２の各計算機２３は、それぞれ、スタブリゾルバ２５からのDNS問い合わせを、DHT問い合わせに変換する変換装置（図４の符号４１参照）を備える。この変換装置は、図１のアクセス装置１５とほぼ同等の機能を有する。より詳しくは、変換装置は、スタブリゾルバ２５からDNS問い合わせを受けたら、このDNS問い合わせに基づいて、検索情報を生成し、DHTネットワーク２２は、この検索情報を用いて検索を行う。検索結果を抽出した計算機における変換装置又はDNS問い合わせを受けた変換装置は、検索結果をDNS問い合わせ応答として、問い合わせ元（スタブリゾルバ２５）に返す。
例えば、ある計算機２３における変換装置が、123456.q.dht.example.comのDNS問い合わせをスタブリゾルバ２５から受けた場合、この計算機２３における変換装置は、123456.q.dht.example.com から、123456を検索情報として抽出し、この計算機２３は、この検索情報のハッシュ値（ID）を求める。DHTネットワーク２２は、このハッシュ値を管理する計算機を特定し、特定された計算機は、このハッシュ値に対応付けられた情報（例えばURL、IPアドレス）を検索する。この計算機における変換装置又はDNS問い合わせを受けた計算機における変換装置は、検索結果をDNS問い合わせ応答として、問い合わせ元（スタブリゾルバ２５）に返す。
ここで、スタブリゾルバ２５は、図２に示すように、検索結果をTTLに示される期間だけ記憶するキャッシュ機構２６を備える。従って、ブリッジ装置２１は、TTL値を制御することで、変換装置やブリッジ装置２１の負荷を制御できる。例えば、TTLを長くすれば同一のスタブリゾルバが１つの変換装置を直接に長い時間使用するため、つまり、世界中に存在する各スタブリゾルバが、それぞれ異なる変換装置を直接に長時間利用するため、ブリッジ装置２１の負荷が低減される。TTLの詳細な制御方法については後述する。
以下では、上述した図２のネットワーク検索システムの応用例について説明する。
以下の応用例では、物品に割り当てられたEPCコード（Electronic Product Code）等のコード（物品番号）を元に、その物品の情報を格納した装置にアクセスするための符号（例えばURL（Uniform Resource Locator）やNAPTR（Naming Authority Pointer）等）をDHTネットワークから取得するケースを考える。
まず、DHTネットワークへの符号の登録方法について簡単に説明する。
物品の生産者や流通者は、物品情報を管理するための共通基盤として、DHTネットワークを使用するとする。例えば生産者は、DHTネットワークに対して、物品の生産に関する情報を格納した装置にアクセスするための符号を登録する。また、流通者は、物品の流通に関する情報を格納した装置にアクセスするための符号をDHTネットワークに登録する。より具体的には以下の例に示すようにして符号を登録する。
即ち、物品の物品番号に対するハッシュ値（ID）をキーとして、符号、タイムスタンプ、公開鍵のハッシュ値、及び符号とタイムスタンプと公開鍵のハッシュ値との組に対する秘密鍵による署名（第１署名）を、DHTネットワークの計算機に登録する。登録される計算機は例えば、ハッシュ値（ID）に応じて自動的に決定される。即ち、各計算機はそれぞれ所定の範囲のIDを管理し、登録対象となるIDは、そのIDを管理する計算機に登録される。なお、物品番号に代えて、物品番号と符号の種類（例えば“URL”“NAPTR”）との組み合わせをキーとする方法など、登録に当たっては種々の方法を用いることができる。
また、公開鍵のハッシュ値をキーとして、公開鍵、及び秘密鍵による公開鍵への署名（第２署名）も、計算機に登録する。これにより 例えば、物品番号に対するハッシュ値をキーとして検索を行った際、検索されたデータに含まれる公開鍵のハッシュ値をキーとして再度、検索を行い、再度の検索で得られたデータに含まれる公開鍵を用いて、最初の検索で得られた第１署名を復号することで、最初の検索で得られたデータの正当性を検証できる。
次に、図２のネットワーク検索システムの応用例（第１及び第２の応用例）として、一般の利用者が、物品番号等を元に、DHTネットワークから対応する符号を取得して、取得した符号に基づいて物品情報を格納した装置へアクセスする場合を具体的に説明する。
図４は、図２のネットワーク検索システムの第１の応用例を示す図である。
本例では、リーダ装置が、物品から物品番号を読み取って読み取られた物品番号を用いてドメイン名を生成し、クライアント装置がこのドメイン名のDNS問い合わせを行う。クライアント装置は、DNS問い合わせに対する応答としてNAPTRレコード（例えばURI,SIPアドレス、電子メールアドレス）を取得し、取得したNAPTRレコードを用いて、このNAPTRレコードを利用したサービスを提供するサーバにアクセスする。このような仕組み自体は、ENUMを用いたサービス等において一般的であるが、本例では、DNSを介してDHTネットワークを透過的に使用して、NAPTRレコードを取得することに特徴がある。以下、本例について詳しく説明する。
リーダ装置４３におけるリーダI/F４４は、物品から物品番号を読み取る。リーダI/F４４は、例えばバーコード読み取り機、無線タグリーダ等である。
リーダ装置４３における参照名合成部４５は、読み取られた物品番号を用いてドメイン名（参照名）を生成する。例えば、物品番号123456に対して、以下のような参照名を生成する。
123456.q.dht.example.com
リーダ装置４３は、Bluetooth、シリアルケーブルによる通信など、任意の手段を用いて、生成した参照名をクライアント装置４２におけるNAPTRアプリ部４６に渡す（S21）。
NAPTRアプリ部４６は、受け取った参照名をDNSリゾルバ４７に渡し（S22）、DNSリゾルバ４７は、この参照名のDNS問い合わせをスタブリゾルバ２５に対して行う（S23）。
スタブリゾルバ２５は、DNSリゾルバ４７からの問い合わせを受けて、この参照名のDNS問い合わせをDNS１０（図２参照）に対して繰り返し行い（反復的問い合わせを行い）、例えばexample.comドメインを管理するDNSサーバ１４から、dht.example.comドメインの権限を委譲されたブリッジ装置２１のIPアドレス等を取得する。そして、スタブリゾルバ２５は、反復的問い合わせの続きとして、権限委譲先であるブリッジ装置２１に対してDNS問い合わせを行う（S24）。
ブリッジ装置２１は、スタブリゾルバ２５からのDNS問い合わせを受けると、冗長度パラメータによって決定された数（適正数）の計算機を適正な方法によって選択し、q.dht.example.comドメインの権限を選択された各計算機に委譲するDNSコードを生成する。
即ち、まず、ブリッジ装置２１は、選択された各計算機に対して、ドメイン名を生成する。例えば、選択された計算機、より詳細には選択された計算機における変換装置が1.2.3.4というIPアドレスを有していた場合、このIPアドレスからドメイン名1-2-3-4.n.q.dht.example.comを生成する。IPアドレスがIPv6アドレスの場合は、適当なダイジェスト関数を用いて、1-2-3-4に相当する部分を圧縮してもよい。
次いで、ブリッジ装置２１は、予め設定された定数、あるいは後述する手法を用いて、TTLを算出する。
ブリッジ装置２１は、生成したドメイン名及び算出したTTLを用いて、以下の例に示すNSリソースレコード及びグルーA/AAAAレコード（DNSレコード）を、選択された各計算機について、生成する。
q.dht.example.com. 6435 IN NS 1-2-3-4.n.q.dht.example.com
1-2-3-4.n.q.dht.example.com. 6435 IN A 1.2.3.4
ブリッジ装置２１は、生成した各計算機のDNSレコードをスタブリゾルバ２５に対して、DNS問い合わせの応答として返す（S25）。
応答を受けたスタブリゾルバ２５は、応答に含まれる計算機を１つ選択し、その計算機における変換装置４１に対し、さらに上述の参照名（123456.q.dht.example.com）のDNS問い合わせを続行する（S26）。
DNS問い合わせを受けた変換装置４１は、参照名から物品番号123456を抽出し、次いで、この変換装置４１を含む計算機は、ハッシュ関数を用いてこの物品番号123456のハッシュ値を求める。DHTネットワーク２２は、このハッシュ値をキーとして検索を行って、このハッシュ値を有する計算機を特定する。特定された計算機は、このハッシュ値をキーとして、このハッシュ値に対応づけられたNAPTRレコードを自身のデータベースから検索する。検索した計算機における変換装置４１又はDNS問い合わせを受けた計算機における変換装置４１は、検索されたNAPTRレコードを、DNSプロトコルに従った応答メッセージ形式を用いて、問い合わせ元であるスタブリゾルバ２５に返す（S27）。
応答を受けたスタブリゾルバ２５は、DNSリゾルバ４７に対して、DNS問い合わせに対する応答として、NAPTRレコードを返す（S28）。
DNSリゾルバ４７は、受け取ったNAPTRレコードをNAPTRアプリ部４６に渡す（S29）。
NAPTRアプリ部４は、受け取ったNAPTRレコードを用いて、NAPTRレコードを利用したサービスを提供するサーバ４８にアクセスする。
図５は、図２のネットワーク検索システムの第２の応用例を示す図である。
本例では、リーダ装置により物品から読み取った物品番号に基づき、この物品番号に対応するURLを、DNS及びDHTネットワークを利用して取得し、このURLを用いてWebサーバにアクセスする場合を説明する。以下本例について詳しく説明する。
リーダ装置５１におけるURL合成部５３は、リーダI/F４４で読み取られた物品番号を用いて、別途定められた符号化方式に従って、URLを生成する。このようにして生成されたURLを参照URLと称する。
参照URLは、第２ドメイン（q.dht.example.com）以下に属するWWWサーバ名、別途定められたポート番号、動作識別子(後述)、パラメータ（後述）及び物品番号によって構成される。例えば物品番号123456789に対して、リーダ装置５１は、以下のような参照URLを生成する。
http://www.q.dht.example.com:14996/Item?itemID=123456789
リーダ装置５１は、生成した参照URLを、クライアント装置５３におけるブラウザ５４に渡す（S41）。
ブラウザ５４は、受け取った参照URLをDNSリゾルバ４７に渡し（S42）、DNSリゾルバ４７は、受け取った参照URLにおけるドメイン名www.q.dht.example.comのDNS問い合わせを、スタブリゾルバ２５に対して行う（S43）。
スタブリゾルバ２５は、DNSリゾルバ４７のDNS問い合わせを受けて、この参照URLのDNS問い合わせを繰り返し行い（反復的問い合わせを行い）、例えばexample.comドメインを管理するDNSサーバ１４（図２参照）から、dht.example.comドメインの権限を委譲されたブリッジ装置２１のIPアドレス等を取得する。そして、スタブリゾルバ２５は、権限委譲先であるブリッジ装置２１に対して反復的問い合わせの続きを行う（S44）。
ブリッジ装置２１は、スタブリゾルバ２５からのDNS問い合わせを受けると、冗長度パラメータによって決定された数（適正な数）の計算機を適正な方法により選択し、選択した計算機に対してq.dht.example.comドメインの権限を委譲するDNSコードを生成する。
即ち、ブリッジ装置２１は、選択された各計算機に対してそれぞれドメイン名を生成する。また、ブリッジ装置２１は、前述と同様にして、TTLを算出する。ブリッジ装置２１は、生成したドメイン名及び算出したTTLを用いて各計算機についてDNSレコードを生成する。
ブリッジ装置２１は、生成した各計算機のDNSレコードをスタブリゾルバ２５に対してDNS問い合わせの応答として返す（S45）。
応答を受けたスタブリゾルバ２５は、応答に含まれるDNSレコードに基づいて、q.dht.example.comドメインの権限を委譲された計算機を１つ選択し、その計算機における変換装置に対し、さらにDNS問い合わせ（www.q.dht.example.comのDNS問い合わせ）を続行する（S46）。
ここで、DHTネットワーク22の各計算機における変換装置５７には、ドメイン名www.q.dht.example.comに関してAレコードが設定されており、このドメイン名に対応するIPアドレスとして自身のIPv4アドレス及びIPv6アドレスが設定されている。従って、スタブリゾルバ２５からドメイン名www.q.dht.example.comのDNS問い合わせを受けた計算機における変換装置５７は、このDNS問い合わせに対して、自身のIPv4アドレス及びIPv6アドレスを返す（S47）。
応答を受けたスタブリゾルバ２５は、DNSリゾルバ４７に対して、DNS問い合わせに対する応答として、受け取ったIPv4アドレス及びIPv6アドレスを返す（S48）。
DNSリゾルバ４７は、取得したIPv4アドレス及びIPv6アドレスをブラウザ５４に渡す（S49）。
ブラウザ５４は、IPv4アドレス及びIPv6アドレスのいずれかを用いて、IPv4アドレス及びIPv6アドレスを有する変換装置５７の定められたポート番号（14996）に向けてHTTP要求http://www.q.dht.example.com:14996/Item?itemID=123456789を行う（S50）。なお、www.q.dht.example.com にはステップS49によって返されたIPv4アドレスあるいはIPv6アドレスが内部的に代入される。その結果、ブラウザ５４は対応する変換装置の定められたポート番号に対して、HTTPによりアクセスを行う結果となる。
ここで、本応用例では、DHTネットワーク22の各計算機における変換装置５７に、HTTPプログラムが格納され、各変換装置５７は、HTTPサーバとしても動作する。従って、HTTP要求を受けた変換装置５７は、HTTP要求における要求文字列（/Item?itemID=123456789）を解釈し、これに対応した処理を行う。
より詳しくは、要求文字列には、要求する動作の種類を示す識別子Item（ここではURLを取得する動作とする）と、物品番号（物品番号を示すパラメータitemIDの値）とが含まれ、従って、変換装置５７は、物品番号（123456789）に基づく符号（URL）の検索を、本変換装置５７を含む計算機に対して指示する。
指示を受けた計算機は、物品番号のハッシュ値を求め、DHTネットワーク５５は、このハッシュ値を管理する計算機を特定し、特定された計算機は、このハッシュ値に対応するURLを検索する。検索した計算機における変換装置５７又は検索の指示を受けた変換装置５７は、HTTPのリダイレクション機能（別のURLにリダイレクトすることを指示する機能）を用いて、クライアント装置５３におけるブラウザ５４に、検索されたURLを通知する（S51）。
URLの通知を受けたブラウザ５４は、DNS１０を用いてそのURLに対応するIPアドレスを取得した後、そのIPアドレスを有する、例えば物品番号123456789に関する物品情報を格納したWebサーバ５８にアクセスする（S52）。
以上のように、利用者は、物品から読み取った物品番号を参照URLに符号化するリーダ装置を用いることで、クライアント装置におけるソフトウェアを改変せずに、DNS及びDHTネットワークを利用して、物品番号に対応した、物品情報を格納したURLを取得できる。つまり、DHTネットワークの特性（規模拡張性及び非集中性）を損なうことなく、透過的にDNS空間からDHT空間を利用して、所望の符号を高速に取得できる。
ところで、先においては、図３を用いて説明したように、ブリッジ装置２１におけるノード集合管理部３２は、計算機の参加状態が動的に変化するDHTネットワークを探索して計算機のリストを生成し、DHS権限委譲機構３１（図３参照）による権限委譲処理の際には、適切な数の計算機を適切な方法によって選択し、選択された計算機の情報をDNS応答合成部３３に渡すことを述べた。そこで、以下では、計算機を選択する具体的な手法についてその一例を説明する。
分散ハッシュアルゴリズムとしてDHTネットワークにおける各計算機が直列に接続される（隣接する計算機が２つである）アルゴリズム（例えばChord）が用いられる場合は、ノード集合管理部３２が、DHTネットワークを探索して既知の計算機に隣接する計算機の情報を順次取得し、DNS権限委譲機構３１（図３参照）による権限委譲処理の際には、計算機の情報を、取得した順にDNS応答合成部３３に渡す方法が考えられる。以下この方法についてさらに詳細に説明する。
図６は、この方法を実行する際におけるノード集合管理部３２の動作を説明する図である。
ノード集合管理部３２は、取得した計算機の情報を格納するノード待ち行列６１を有する。ブリッジ装置２１の起動時には、ノード集合管理部３２は、DHTネットワークを探索して、既知の計算機に隣接する計算機を順次取得して、ノード待ち行列６１に格納する。ノード待ち行列６１は、最小値（MIN）、最大値（MAX）及び冗長度パラメータ値を有する。これらの値がノード集合管理部３２の処理を決定づける。
より詳しくは、ノード集合管理部３２は、ノード待ち行列６１内における計算機の情報数が、最大値になるまで、既知の計算機の隣接計算機を順次探索して、探索した計算機の情報をノード待ち行列６１に格納する。DHT権限委譲機構３１による権限委譲処理の際には、ノード集合管理部３２は、冗長度パラメータ値に相当する数の計算機の情報をノード待ち行列６１から取り出し、DNS応答合成部３３に渡す。ノード集合管理部３２は、ノード待ち行列６１の長さが最小値を下回った場合は、計算機の探索を優先する。つまり、DHT権限委譲機構３１による権限委譲処理時に、ノード待ち行列６１の長さが最小値を下回った場合は、ノード集合管理部３２は、計算機の探索が完了するまで、計算機の情報をDNS応答合成部３３に渡すのを待機する。
なお、分散ハッシュアルゴリズムとして、ある計算機に隣接する計算機が３つ以上存在するTapestryのようなアルゴリズムを用いる場合は、ノード集合管理部３２は、恣意的な方法で計算機を選択する方法が考えられる。
また、ノード集合管理部３２によって選択される計算機と、選択された計算機に対してDNS問い合わせを行うスタブリゾルバ２５とは距離的に近いことが好ましい。そこで、ノード集合管理部３２に対してインターネットプロトコルレベルの経路表を備えさせ、ノード集合管理部３２は、ノード待ち行列６１の中から距離的にスタブリゾルバ２５に最も近いと予測されるIPアドレスを有する計算機を選択する方法も考えられる。
次に、TTL決定部３４（図３参照）によるTTLの決定方法についてその具体例を説明する。
ここでは、TTL決定部３４が、DHTネットワークを構成する各計算機の負荷と、ブリッジ装置２１の負荷とに基づいて、TTL値を動的に決定する例を説明する。
前述したように、第２ドメイン（q.dht.example.com）に対するNSリソースレコードにはTTLを設定可能である（上述した例ではTTL値として6435を設定した）。本例では以下の２つの方針に従って、TTL値を制御する。
１．変換装置が存在する計算機の負荷が高い場合は、TTLを短くして変換装置の負荷をあまり増やさないようにし、逆に負荷が低い場合は、TTLを長くして変換装置としての働きを長く求める。
２．ブリッジ装置２１の負荷が高い場合は、TTLを長くして、再問い合わせの発生頻度を下げる。逆に、ブリッジ装置２１の負荷が低い場合は、TTLを短くして再問い合わせの発生頻度を上げ、これにより検索処理の負荷を各計算機に効率的に分散する。
以上の２つの方針を実現するため、TTL値を決定する関数の引数として、
Ltn：該当する変換装置の負荷
Lbn：ブリッジ装置の負荷
を用いる。
TTL決定部３４は、この関数を用いてTTL値を決定してDNS応答合成部３３に渡し、DNS応答合成部３３は、受け取ったTTL値を、NSリソースレコードのTTL値として用いる。
以下に、TTL値を決定する関数の一例を示す。
fttl(Ltn, Lbn)=cTTL+bTTL*(1.0-Ltn)*Lbn ・・・（式１）
但し、Ltn及びLbnは、0.0（無負荷）〜1.0（過負荷）に正規化されているものとする。cTTLは最低のTTLを規定する定数であり、過剰な再問い合わせを防ぐ機能を有する。cTTLとしては例えば300秒を用いる。一方、bTTLは最大のTTLを決定づける定数である。該当する変換装置の負荷が無負荷で、ブリッジ装置が過負荷の場合、（式１）により、TTL値は、cTTL+bTTLとなり、例えばこの値が604800秒（一週間）となるように、bTTLを決定する。
Ltnとしては、例えば、一定時間のうち、処理に要した時間すなわち問い合わせを受けてから検索結果を返すまでの時間の合計の占める比率を採用し、計算機の自己申告を用いる。実際に比率を求める際には、例えば、比率を算出するための処理時間の積算を１分毎に行い、１分毎の比率を求め、１分毎の比率を直前１０分に渡って加重平均を取る等の方法がある。この他、計算機への問い合わせ数は計算機のDHT-ID空間における担当領域のサイズに比例するとの仮定により、計算機の担当領域のサイズに基づいてLtnを決定してもよい。
Lbnとしては、例えば、一定時間のうち、ノード待ち行列の長さが最大値となっている時間の合計の占める比率を採用する。これにより、例えば、算出された比率が所定の第１基準値を下回っている場合は、問い合わせの速度が計算機の探索速度に比べて非常に高いとして過負荷、一方比率が所定の第２基準値を上回っている場合は、問い合わせの速度が計算機の探索速度に比べて非常に小さいとして無負荷などとできる。当然、探索処理や、問い合わせの対応に要した処理に要した時間を基準にLbnを求めても良く、この際も、Ltnの算出と同様、加重平均手法を用いても良い。
以上に説明した計算機の選択手法及びTTLの算出方法は、組み合わせて用いることも可能である。
以上に説明した、本実施の形態では、分散ハッシュアルゴリズムとして、主としてChordを例としたが、他のアルゴリズム、例えばTapestryやCAN等も用いることができる。
本発明の実施の形態に従ったネットワーク検索システムの構成を示す図である。 本発明の別の実施の形態に従ったネットワーク検索システムの基本的な構成を示す図である。 ブリッジ装置の構成を示す図である。 図２のネットワーク検索システムの第１応用例を示す図である。 図２のネットワーク検索システムの第２応用例を示す図である。 ノード集合管理部の動作を説明する図である。
符号の説明
１０ DNS(ドメイン名システム)
１２〜１４ DNSサーバ
１５ アクセス装置
１６、２２、５５ DHTネットワーク
１７、２３、５６ 計算機
１８、２５ スタブリゾルバ
１９、２４ クライアント装置
２６ キャッシュ機構
３０ DNS応答問い合わせ受け付け部
３１ DHT権限委譲機構
３２ ノード集合管理部
３３ DNS応答合成部
３４ TTL決定部
３５ 応答送信部
４１、５７ 変換装置
４３ リーダ装置
４４ リーダI/F
４５ 参照名合成部
４６ NAPTRアプリ部
４７ DNSリゾルバ
４８ サーバ
５３ URL合成部
５４ ブラウザ
５６ ブラウザ
５８ Webサーバ
６１ 待ち行列

Claims (21)

  1. ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、
    ドメイン名空間における一部のドメインを受け持つアクセス装置であって、前記ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、前記計算機の少なくとも１つに対して、前記名前解決依頼に基づく検索を指示して検索結果を受け取り、受け取った前記検索結果を前記名前解決依頼に対する応答として送出するアクセス装置と、
    前記アクセス装置に対して前記ドメインの名を含むドメイン名の名前解決を依頼し、前記依頼に対する応答として、前記アクセス装置から前記検索結果を受け取る利用者側装置と、
    を備えたネットワーク検索システム。
  2. ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、
    ドメイン名空間における一部のドメインを受け持ち、前記ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、前記計算機の少なくともいずれかの所在情報を前記名前解決依頼に対する応答として送出するブリッジ装置と、
    前記ブリッジ装置に対して前記ドメインの名を含むドメイン名の名前解決依頼を行って前記ブリッジ装置から前記計算機の所在情報を取得し、取得した前記計算機の所在情報に対応する前記計算機に対して検索を指示し、検索結果を取得する利用者側装置と、
    を備えたネットワーク検索システム。
  3. 前記ブリッジ装置は、前記計算機の所在情報の有効期間を定める有効期間情報を生成し、生成した前記有効期間情報を前記計算機の所在情報と共に前記利用者側装置に送出し、
    前記利用者側装置は、取得済みの有効期間内の所在情報がある場合には、該所在情報に対応する計算機に検索を指示する、
    ことを特徴とする請求項２に記載のネットワーク検索システム。
  4. 前記ブリッジ装置は、前記計算機の負荷状態に応じた前記有効期間情報を生成することを特徴とする請求項３に記載のネットワーク検索システム。
  5. 前記ブリッジ装置は、前記ブリッジ装置の負荷状態に応じた前記有効期間情報を生成することを特徴とする請求項３又は４に記載のネットワーク検索システム。
  6. ネットワーク上に配置された複数の計算機を有し、前記計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索するネットワーク検索システムであって、
    各前記計算機に対応して配置され、ドメイン名空間の一部である第１ドメインを受け持つ変換装置であって、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取った場合は、対応する前記計算機に対して前記名前解決依頼に基づく検索を指示して検索結果を受け取り、受け取った前記検索結果を前記名前解決依頼に対する応答として送出する変換装置と、
    前記変換装置を管理し、前記第１ドメインよりも上階層の第２ドメインの管理を受け持つブリッジ装置であって、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取った場合には、前記変換装置の少なくともいずれかの所在情報を、名前解決のための委任先として、前記名前解決依頼の送出元に通知するブリッジ装置と、
    前記ブリッジ装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って前記名前解決のための委任先としての前記変換装置の所在情報を取得し、前記変換装置の所在情報に対応する前記変換装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って、前記名前解決依頼の応答として前記変換装置から検索結果を取得する利用者側装置と、
    を備えたネットワーク検索システム。
  7. 前記ブリッジ装置は、前記変換装置の所在情報の有効期間を定める有効期間情報を生成し、生成した前記有効期間情報を前記変換装置の所在情報と共に前記利用者側装置に送出し、
    前記利用者側装置は、取得済みの有効期間内の所在情報がある場合には、該所在情報に対応する変換装置に名前解決依頼を行う、
    ことを特徴とする請求項６に記載のネットワーク検索システム。
  8. 前記ブリッジ装置は、前記変換装置に対応する前記計算機の負荷状態に応じた前記有効期間情報を生成することを特徴とする請求項７に記載のネットワーク検索システム。
  9. 前記ブリッジ装置は、前記ブリッジ装置の負荷状態に応じた前記有効期間情報を生成することを特徴とする請求項７又は８に記載のネットワーク検索システム。
  10. ネットワーク上に配置された複数の計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する情報検索方法であって、
    ドメイン名空間における一部のドメインを受け持つブリッジ装置が、前記ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する検出ステップと、
    前記ブリッジ装置が、前記計算機の少なくともいずれかを選択する選択ステップと、
    前記検出ステップで前記名前解決依頼を受け取ったことを検出した場合は、前記選択ステップによって選択された前記計算機の所在情報を、前記名前解決依頼の送出元に通知する通知ステップと、
    利用者側装置が前記ブリッジ装置に対して前記ドメインの名を含むドメイン名の名前解決依頼を行って前記ブリッジ装置から前記計算機の所在情報を取得する第１取得ステップと、
    前記利用者側装置が、取得した前記計算機の所在情報に対応する前記計算機に対して検索を指示し、検索結果を取得する第２取得ステップと、
    を備えた情報検索方法。
  11. ネットワーク上に配置された複数の計算機のいずれかがある情報の検索を指示された場合に、前記複数の計算機が分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する情報検索方法であって、
    各前記計算機に対応して配置され、ドメイン名空間の一部である第１ドメインを受け持つ変換装置が、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する第１検出ステップと、
    前記第１検出ステップによって前記名前解決依頼を受け取ったことを検出した場合は、前記変換装置が、対応する前記計算機に対して前記名前解決依頼に基づく検索を指示して検索結果を受け取る受取ステップと、
    前記変換装置が、受け取った前記検索結果を前記名前解決依頼に対する応答として送出する送出ステップと、
    前記変換装置を管理し、前記第１ドメインよりも上階層の第２ドメインの管理を受け持つブリッジ装置が、前記第１ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する第２検出ステップと、
    前記ブリッジ装置が、前記変換装置の少なくともいずれかを選択する選択ステップと、
    前記第２検出ステップによって前記名前解決依頼を受け取ったことを検出した場合は、前記ブリッジ装置が、前記選択ステップによって選択された前記変換装置の所在情報を、名前解決のための委任先として、前記名前解決依頼の送出元に通知する通知ステップと、
    利用者側装置が、前記ブリッジ装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って前記名前解決のための委任先としての前記変換装置の所在情報を取得する第１取得ステップと、
    前記利用者側装置が、前記変換装置の所在情報に対応する前記変換装置に対して前記第１ドメインの名を含むドメイン名の名前解決依頼を行って前記名前解決依頼の応答として前記変換装置から検索結果を取得する第２取得ステップと、
    を備えた情報検索方法。
  12. ネットワーク上のドメイン名空間における一部のドメインを受け持つブリッジ装置であって、
    ネットワーク上に配置された複数の計算機であって、前記複数の計算機のいずれかがある情報の検索を指示された場合に、分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する前記複数の計算機を管理する管理部と、
    前記ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する検出部と、
    前記検出部によって前記名前解決依頼を受け取ったことを検出した場合に、予め与えられた規則に従って前記管理部によって選択された前記計算機の所在情報を、前記名前解決依頼に対する応答として送出する応答部と、
    を備えたブリッジ装置。
  13. 前記応答部は、選択された前記計算機の所在情報を、名前解決のための委任先として送出することを特徴とする請求項１２に記載のブリッジ装置。
  14. 前記ブリッジ装置は、前記計算機の所在情報の有効期間を定める有効期間情報を生成する有効期間情報生成部をさらに備え、
    前記応答部は、生成された前記有効期間情報を前記計算機の所在情報と共に送出する
    ことを特徴とする請求項１２又は１３に記載のブリッジ装置。
  15. 前記管理部は、前記計算機の負荷状態を算出し、
    前記有効期間情報生成部は、算出された前記計算機の負荷状態に応じて前記有効期間情報を生成することを特徴とする請求項１４に記載のブリッジ装置。
  16. 前記ブリッジ装置の負荷状態を算出する負荷状態算出部をさらに備え、
    前記有効期間情報生成部は、算出された前記ブリッジ装置の負荷状態に応じて前記有効期間情報を生成することを特徴とする請求項１４又は１５に記載のブリッジ装置。
  17. ネットワーク上のドメイン名空間における一部のドメインを受け持つ装置で実行するプログラムであって、
    ネットワーク上に配置された複数の計算機であって、前記複数の計算機のいずれかがある情報の検索を指示された場合に、分散ハッシュテーブルを利用した所定の分散ハッシュアルゴリズムに従って該情報について検索する前記複数の計算機の少なくともいずれかを、予め与えられた規則に従って選択する選択ステップと、
    前記ドメインの名を含むドメイン名の名前解決依頼を受け取ったことを検出する検出ステップと、
    前記検出ステップによって前記名前解決依頼を受け取ったことを検出した場合に、前記選択ステップによって選択された前記計算機の所在情報を、前記名前解決依頼に対する応答として送出する応答ステップと、
    を備えたプログラム。
  18. 前記応答ステップは、選択された前記計算機の所在情報を、名前解決のための委任先として送出することを特徴とする請求項１７に記載のプログラム。
  19. 前記計算機の所在情報の有効期間を定める有効期間情報を生成する有効期間情報生成ステップをさらに備え、
    前記応答ステップは、生成された前記有効期間情報を前記計算機の所在情報と共に送出する
    ことを特徴とする請求項１７又は１8に記載のプログラム。
  20. 前記計算機の負荷状態を算出する計算機負荷算出ステップをさらに備え、
    前記有効期間情報生成ステップは、算出された前記計算機の負荷状態に応じて前記有効期間情報を生成することを特徴とする請求項１９に記載のプログラム。
  21. 前記ブリッジ装置の負荷状態を算出するブリッジ負荷算出ステップをさらに備え、
    前記有効期間情報生成ステップは、算出された前記ブリッジ装置の負荷状態に応じて前記有効期間情報を生成することを特徴とする請求項１９又は２０に記載のプログラム。
JP2004149416A 2004-05-19 2004-05-19 ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム Pending JP2005333374A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004149416A JP2005333374A (ja) 2004-05-19 2004-05-19 ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム
US11/129,433 US20060047786A1 (en) 2004-05-19 2005-05-16 Network retrieval system, information retrieval method, bridge device and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004149416A JP2005333374A (ja) 2004-05-19 2004-05-19 ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム

Publications (1)

Publication Number Publication Date
JP2005333374A true JP2005333374A (ja) 2005-12-02

Family

ID=35487727

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004149416A Pending JP2005333374A (ja) 2004-05-19 2004-05-19 ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム

Country Status (2)

Country Link
US (1) US20060047786A1 (ja)
JP (1) JP2005333374A (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009194883A (ja) * 2008-02-18 2009-08-27 Nippon Telegraph & Telephone West Corp 名前解決要求装置、名前解決中継装置、名前解決方法
JP2009194884A (ja) * 2008-02-18 2009-08-27 Nippon Telegraph & Telephone West Corp 名前解決システム、名前解決中継装置、通信装置、名前解決方法
JP2010515133A (ja) * 2007-04-19 2010-05-06 ▲ホア▼▲ウェイ▼技術有限公司 コンテンツを公表するための方法及びシステム、コンテンツを検索するための方法及びシステム
JP2012078902A (ja) * 2010-09-30 2012-04-19 Brother Ind Ltd 情報処理装置、情報処理方法及び情報処理プログラム
JP2013051566A (ja) * 2011-08-31 2013-03-14 Brother Ind Ltd ノード装置、情報通信方法及びプログラム
JP2014143573A (ja) * 2013-01-24 2014-08-07 Nippon Telegr & Teleph Corp <Ntt> アドレス解決システム及び方法
US20220231985A1 (en) * 2011-05-12 2022-07-21 Jeffrey Alan Rapaport Contextually-based automatic service offerings to users of machine system

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100714114B1 (ko) * 2005-12-09 2007-05-02 한국전자통신연구원 Ｕｒｉ를 획득하기 위한 클라이언트, 기록매체 및 그 방법
US7836016B2 (en) * 2006-01-13 2010-11-16 International Business Machines Corporation Method and apparatus for disseminating new content notifications in peer-to-peer networks
WO2007138228A2 (fr) * 2006-05-31 2007-12-06 France Telecom Procede, dispositif et systeme de nommage, procede et terminal d'acces a une ressource, procede de reponse a une interrogation et serveur de resolution
US8375141B2 (en) * 2006-09-29 2013-02-12 Microsoft Corporation Infrastructure to disseminate queries and provide query results
US8756340B2 (en) 2007-12-20 2014-06-17 Yahoo! Inc. DNS wildcard beaconing to determine client location and resolver load for global traffic load balancing
WO2010076536A2 (fr) * 2008-12-30 2010-07-08 France Telecom Procède de traitement de requêtes émises par un client
CN102045413B (zh) * 2011-01-24 2013-01-02 北京邮电大学 经过dht扩展的dns映射系统及其实现dns安全的方法
US9088415B2 (en) * 2011-08-03 2015-07-21 Cisco Technology, Inc. Authentication of cache DNS server responses

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128666A (en) * 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US6178451B1 (en) * 1998-11-03 2001-01-23 Telcordia Technologies, Inc. Computer network size growth forecasting method and system
US20010049741A1 (en) * 1999-06-18 2001-12-06 Bryan D. Skene Method and system for balancing load distribution on a wide area network
CA2333495A1 (en) * 2000-01-31 2001-07-31 Telecommunications Research Laboratory Internet protocol-based computer network service
US6834050B1 (en) * 2000-03-10 2004-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Packet core function and method of selecting a packet data service node/foreign agent in a packet data network
US7454523B2 (en) * 2001-03-16 2008-11-18 Intel Corporation Geographic location determination including inspection of network address
US7065587B2 (en) * 2001-04-02 2006-06-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith
JP4647825B2 (ja) * 2001-04-27 2011-03-09 富士通セミコンダクター株式会社 パケット送受信システム、ホスト、および、プログラム
US7299351B2 (en) * 2001-09-19 2007-11-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US20030074461A1 (en) * 2001-10-09 2003-04-17 I-Dns.Net International Pte. Ltd. Method of mapping names or identifiers to telecommunications network resource locations
US7263560B2 (en) * 2002-08-30 2007-08-28 Sun Microsystems, Inc. Decentralized peer-to-peer advertisement
US7613796B2 (en) * 2002-09-11 2009-11-03 Microsoft Corporation System and method for creating improved overlay network with an efficient distributed data structure
US7480915B2 (en) * 2002-10-03 2009-01-20 Nokia Corporation WV-IMS relay and interoperability methods

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010515133A (ja) * 2007-04-19 2010-05-06 ▲ホア▼▲ウェイ▼技術有限公司 コンテンツを公表するための方法及びシステム、コンテンツを検索するための方法及びシステム
JP2012094192A (ja) * 2007-04-19 2012-05-17 ▲ホア▼▲ウェイ▼技術有限公司 コンテンツを公表するための方法及びシステム、コンテンツを検索するための方法及びシステム
JP2009194883A (ja) * 2008-02-18 2009-08-27 Nippon Telegraph & Telephone West Corp 名前解決要求装置、名前解決中継装置、名前解決方法
JP2009194884A (ja) * 2008-02-18 2009-08-27 Nippon Telegraph & Telephone West Corp 名前解決システム、名前解決中継装置、通信装置、名前解決方法
JP2012078902A (ja) * 2010-09-30 2012-04-19 Brother Ind Ltd 情報処理装置、情報処理方法及び情報処理プログラム
US20220231985A1 (en) * 2011-05-12 2022-07-21 Jeffrey Alan Rapaport Contextually-based automatic service offerings to users of machine system
US11539657B2 (en) * 2011-05-12 2022-12-27 Jeffrey Alan Rapaport Contextually-based automatic grouped content recommendations to users of a social networking system
US11805091B1 (en) * 2011-05-12 2023-10-31 Jeffrey Alan Rapaport Social topical context adaptive network hosted system
JP2013051566A (ja) * 2011-08-31 2013-03-14 Brother Ind Ltd ノード装置、情報通信方法及びプログラム
US8799508B2 (en) 2011-08-31 2014-08-05 Brother Kogyo Kabushiki Kaisha Node device, information communication method and computer readable recording medium
JP2014143573A (ja) * 2013-01-24 2014-08-07 Nippon Telegr & Teleph Corp <Ntt> アドレス解決システム及び方法

Also Published As

Publication number Publication date
US20060047786A1 (en) 2006-03-02

Similar Documents

Publication Publication Date Title
US11451472B2 (en) Request routing based on class
US11632420B2 (en) Point of presence management in request routing
JP5404766B2 (ja) ルーティングをリクエストするための方法とシステム
US20060047786A1 (en) Network retrieval system, information retrieval method, bridge device and program
JP6146950B2 (ja) ネットワークコンピューティングコンポーネントを使用してルーティングをリクエストする方法およびシステム
CA2741895C (en) Request routing and updating routing information utilizing client location information
US9525659B1 (en) Request routing utilizing point of presence load information
US9497259B1 (en) Point of presence management in request routing
US9787775B1 (en) Point of presence management in request routing
US8234403B2 (en) Updating routing information based on client location
JP2001175561A (ja) ドメインネームシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050905

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070501

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070522

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070704

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070921