JP2006025355A - ネットワークのリソース，サービス発見方法及び中継ノード装置 - Google Patents

Abstract

【課題】 本発明は、リソース，サービスの提供が停止したクローズドノードへのアクセス要求を同一リソース，サービスを提供している他ノードに転送でき、クローズドノードとなったことを各中継ノードに通知できるネットワークのリソース，サービス発見方法及び中継ノード装置を提供することを目的とする。
【解決手段】 任意ノードでリソース，サービスの提供が停止した場合、提供が停止したリソース，サービスの識別子に対し任意ノードのアドレスの他に別ノードのアドレスが登録された検索テーブルを持つ中継ノードにて、提供が停止したリソース，サービスに対するアクセス要求を、任意のノードから前記別ノード宛に振り替える。
【選択図】 図８

Description

本発明は、ネットワークのリソース，サービス発見方法及び中継ノード装置に関し、複数のノードが自ノードの有するリソース，サービスを提供するネットワークのリソース，サービス発見方法及び中継ノード装置ブリッジ装置に関する。

従来、インターネットはパーソナルコンピュータ（ＰＣ）やワークステーションを中心としたネットワークであったが、携帯電話を始めとした小型情報端末の進化や、今後のＩＣチップの普及に伴い、「どこでも、いつでも端末の形態を問わず、任意の端末と通信できる」、いわゆるユビキタス通信が次世代の通信形態として着目されている。

このように多様なノードが相互接続されているネットワークにおいては、それに接続されているノードが提供するリソースやサービスの種類も量も膨大となり、これを効率良く発見できる仕組みが重要となる。なお、本明細書及び特許請求の範囲では、リソースとは、 任意のノードがそのハードディスクやメモリ内に有する資源（例えば、ファイル）を意味し、サービスとは、ユーザの利益になるようにリソースを組み合わせた無形の提供物を意味する。

ユビキタス通信において、各ノードが有するリソースやサービスを発見する際の要件を以下に記す。

要件１は、任意のノードが有するリソースやサービスを発見できることである。従来はリソースやサービスを提供するノードと、それを享受するノードと役割分担が明確なサーバ／クライアントモデルが主流であった。従って、サービスやリソースを、サーバを対象に探す技術が普及した。例えば、従来のホームページ検索エンジンはｗｅｂサーバを対象としている。しかしユビキタス網においてはサーバ・クライアントモデルのように単純にノード間での役割分担を定義できない。このため、任意のノードが提供するリソースやサービスを発見できることが要件となる。

要件２は、ノード数に対してスケーラビリティがあることである。ユビキタス通信においては網に接続されているノードはＰＣに限らず、ＩＣチップなどを有するノードまでも対象となる。よってノード数に対してスケーラビリティのある手法が必要である。

要件３は、リソース，サービス発見処理時のネットワークの負荷が低いことである。ユビキタス通信でのノード数の膨大な増加と比例した網の帯域を提供することは困難である。よってリソース，サービス発見処理を行うときにネットワークへの負荷を抑えることが必要である。

要件４は、耐障害性があることである。ユビキタス通信においては、従来のサーバのように十分な信頼性を保証されたノードのみがリソースやサービスを提供しているとは限らない。従って、ネットワークへの接続やノードのＯＳなどが不安定なために長期的（何日も渡って）安定的にリソースやサービスを提供できないノードが存在することを前提とした手法であることが要件となる。

要件５は、同一リソース，サービスを提供するノードが複数あることに対応できることである。ユビキタス通信においては、複数のノードが同じサービスやリソースを提供することが想定できる。このため、同一リソース，サービスを提供するノード郡の中から任意のノードを選択してユーザに発見結果として提示できることが要件となる。

既存のリソース，サービスの発見技術を次のように分類する。

集中型は、任意のサーバが提供するサービスやリソースを、予め任意のノードが収集しデータベース化しておくことで網内のサービスやリソースの発見を提供する。一般に「検索サイト」や「サーチエンジン」と称されるノードが収集を行う。当該検索サイトは、ユーザが入力したキーワードからデータベースを検索し、当該キーワードに関連したサービスやリソースを公開しているノードを、ユーザに回答する。なお「集中型」はサービスやリソースを提供しているノードの登録の仕方で、「ロボット型」と「手動型」に分類が可能である。

ロボット型は、「ロボット」と呼ばれるプログラムを使って、サーバが自律的にインターネット上のリソース，サービス情報を収集する。

手動型は、ユーザや検索用サーバ管理者が当該サーバにリソース，サービスのロケーション識別子とそれに関連するキーワードを登録する。

分散型は、サービスやリソースをどのノードが有しているかの問い合わせ毎に網上のノードに問い合わせる。集中型のようにデータベースを有する必要がないことが特長である。 ＧｎｕｔｅｌｌａやＷｉｎＭＸ等の、いわゆるファイル共有アプリケーションで用いられることが多い手法である。任意のノードが提供するリソースやサービスを任意のノードから発見できるシステムであるため、Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ型（ＰｔｏＰ型）とも称される。

ハイブリッド型は、集中型と分散型の中間解であり、各ノード自身が公開するサービスやリソースについてノード間で定期的に交換する。ユビキタス網においてはリソースやサービスの提供対象はサーバだけに限らない。従って、集中型では先の要件１を満たすことが困難なため、以降は分散型とハイブリッド型に絞って議論を進めることとする。

標準化された分散型でのリソース，サービスの発見手順は今のところ存在しない。しかし多くの分散型のアプリケーションはＧｎｕｔｅｌｌａの手法に基づくため、以降ではＧｎｕｔｅｌｌａの動作例を示す。

Ｇｎｕｔｅｌｌａはインターネットを通じて個人間でファイルの交換を行うアプリケーションソフトである。よってＧｎｕｔｅｌｌａではリソース，サービスとはファイルを指すことになる。Ｇｎｕｔｅｌｌａのユーザはインターネットを通じて相互に接続され、互いに所有するファイルの中から、他のユーザと共有してもよいファイルのリストを公開する。Ｇｎｕｔｅｌｌａ上でファイル検索を行うと自ノード以外のノードが公開しているファイルから条件に合致するものが抽出され、ファイル検索を行ったノードは当該リソースを有するノードから直接、当該リソースをダウンロードすることができる。

分散型のリソース，サービスの発見手順について図１を用いて説明する。ファイルの発見要求であるクエリ（Ｑｕｅｒｙ）を接続しているホストに送ると、当該要求が隣ノード間で順次中継される。要求対象のファイルを有するホストがヒット応答を返すことで、ファイルの発見を実現する。

図１において、
（１）隣接ノードに対して、ファイルのクエリコマンドを送信する。
（２）このコマンドは順次中継される。
（３）ファイルを有するノードは、ヒット応答を返す。
（４）ヒット応答はクエリとは逆の経路を順にたどって、クエリの送信元のノードへ応答する。
（５）ヒット応答を返したノードのうちのいずれかとＴＣＰで接続する。
（６）ファイルの取得要求を送信する。
（７）ファイルの内容が送り返されてくる。

なお（２）において、無限にクエリが中継されてしまうことを防ぐために、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）と同様にＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）の概念があり、一定ノード数以上を転送されたクエリは廃棄される。

Ｇｎｕｔｅｌｌａでのリソース，サービス発見はクエリをバケツリレー的に同報することで実現する。このため以下の問題点がある。

問題１．検索を行うノード数が多い。リソース，サービスの検索を行うノードはクエリの経由毎にねずみ算式に増える。これはノード間で各々が提供するリソースやサービスについての情報を交換していないことに起因する。このためクエリを受信したノードが検索対象のリソース，サービスを有さない場合、当該クエリをどの隣接ノードへ転送すればよいかの情報がない。よって全隣接ノードへの同報が必要となり、要件２を満たさない。

問題２．網の帯域を不要に利用する。クエリが隣接ノード間で同報され、かつそれはノードを経由毎にねずみ算式に増える。しかし、クエリの送信元ノードが取得コマンドを送信するノード数は高々１つであり、それ以外のクエリ（例えば図１の右４つのノード中、下３つのノードに向かうクエリ）はネットワークの帯域を不要に消費している。このため、要件３を満たさない。

問題３．耐障害性についての仕組みを有していない。このため、要件４を満たさない。

ハイブリッド型はノード間で各々が提供するリソースやサービスについての情報を定期的に交換する点が特徴である。現状、標準化された手段がないため、米国）ＵＣＬＡ大が提唱するＦｌａｐｐｓ（Ｆｏｒｗａｒｄｉｎｇ Ｌａｙｅｒ ｆｏｒ Ａｐｐｌｉｃａｔｉｏｎ−ｌｅｖｅｌ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｓｅｒｖｉｃｅｓ）を例にハイブリッド型の動作例を示す。

ハイブリッド型では、ノードが公開するリソースやサービスに付けられた”名前”（ファイル名やＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ など）と当該ノードへの経路情報をノード間で交換する。この経路交換の結果に基づいて、各ノードは、クエリが要求する当該リソース，サービスを提供するノードへ当該クエリを転送する。

ハイブリッド型におけるリソース，サービス発見は、２つのフェーズから構成される。 第１は、リソースやサービスの識別子（以降、名前経路情報）を配布し交換するフェーズである。第２は、ノードからの要求に基づいて、リソース，サービスを発見するフェーズである。

図２は、名前経路情報の配布フェーズのフローチャートを示す。まず、前提とする環境について説明すると、ノードＢとノードＣがともに”ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”というファイル（リソース）を公開している。ノードＡ，Ｂ，Ｃ及び中継ノードはＩＰによりそれぞれ通信可能である。中継ノードはＰＣのような端末でも、ルータのようなネットワーク機器に付加機能を加えたものでもよい。ノード間の名前経路情報の交換は定期的に行うものとする。なお、図２以降のフローチャートでは、ノードＡのＩＰアドレスはＩＰ−Ａのように表記する。また、ノード間でやり取りされる名前経路情報は、宛先ＩＰ，発信ＩＰ，コマンド名，リソース名，次ポップＩＰの順に表記する。

図２において、
（１）ノードＣは、“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を公開していることを隣接ノード（中継ノード５）にフレームを送信して通知する（図中（１））。
（２）中継ノード５は受信したフレームのコマンド名から、”名前経路情報”であることを識別し、リソース名の文字列を予め設定された区切り文字（この場合”／”）毎に分解し、検索ツリーを作成する。その後、中継ノード５は自身を経由して、“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”に到達できること、即ち、任意のノードからのクエリを中継ノード５に転送すれば“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を公開しているノード（ノードＣ）に到達できることを隣接ノード（中継ノード４）に通知する（図中（２））。
（３）中継ノード４の処理は（２）と同様である（図中（３））。
（４）ノードＢも（１）同様に、“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を公開していることを隣接ノードである中継ノード６に通知する（図中（ａ））。また、中継ノード６は（２）と同様に検索用ツリーを作成後、中継ノード３に名前経路情報の通知を行う（図中（ｂ））。
（５）中継ノード３は、中継ノード４，６の双方から“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”に関する名前経路情報を受信する。この結果、図 ３ ２中に示すようなＩＰ−６とＩＰ−４を検索結果とする検索ツリーが中継ノード３内に作成される。検索結果としてＩＰ−６とＩＰ−４のいずれを選ぶかを、ここでは記載しない中継ノード３が有するアルゴリズム（例えば交互に選ばれるなど）で中継ノード３は決定する。
（６）以降、項２の処理の繰り返しにより、中継ノード２，１に名前経路情報が伝播される（図中（４），（５））。

以上により、ノードＢ，Ｃが公開するリソースの名前と経路情報が中継ノード間で交換できる。

次にリソース，サービスの発見フェーズのフローチャートを図３に示す。

図３において、
（１）ノードＡは、“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を有するノードの発見を依頼するクエリフレームをネットワークに送信する（図中（１））。
（２）中継ノード１は受信したフレームのコマンド名から、”クエリ”であることを識別し、リソース名の文字列を予め設定された区切り文字（この場合”／”）毎に分解し、検索用のツリーを分解したキー毎に順に検索する。
（３）検索結果の次ホップが中継ノード２であることから、中継ノード１は中継ノード２にクエリを転送する（図中（２））。
（４）中継ノード２は（２），（３）と同様の処理を行い、中継ノード３にクエリを転送する（図中（３））。
（５）中継ノード３は（２）と同様の処理を行う。この際、次ポップの中継ノードとして中継ノード４，６があるが、ここでは記載しない何らかのアルゴリズム（例えば、交互に選択するなど）により、中継ノード３はいずれかを選択する。ここでは中継ノード６を選択したと仮定し、（３）と同様の処理により、中継ノード６にクエリを転送する（図中（４））。
（６）中継ノード６は（２），（３）と同様の処理を行い、ノードＢにクエリを転送する（図中（５））。
（７）ノードＢは自身が発見対象のリソース“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を有していることから、”送信元ノードのＩＰ”のフィールドを識別し、ＩＰ−Ａ（ノードＡ）に向けてＴＣＰコネクションを張り、ファイル転送を開始する（図中（６））。

なお、特許文献１には、情報パケットを生成したノードに対して、自己の閉域アドレスと自己の広域アドレスとを対応付けた返信パケットを返信し、情報パケットを生成したノードが、受信した返信パケットの内容を自己のルーチングテーブルに含めることにより、広域アドレスによるルーチングテーブルを生成することが記載されている。

また、特許文献２には、受信フレームが宛先不明である場合、その宛先アドレス及び自中継装置のアドレスを用いて経路検索用フレームを生成し、経路検索用フレームに対して宛先が見つかった中継装置から返送される応答フレームが受信された場合、受信フレームを応答フレームの送信元に向けて送信することが記載されている。
特開平１０−７０５５２号公報 特開２００１−２０３７３９号公報

ハイブリッド型はノードが有するリソース，サービス情報（名前経路情報）を交換することで、分散化したリソース，サービスの発見手順を図る。このため、ノードのリソース，サービス提供に変化が生じた場合（例えば、リソース，サービスが提供不可能になった場合）、変化を通知する名前経路情報がネットワーク上の中継ノード郡に伝播されるまでの時間は安定したリソース，サービス発見手順を網が提供できない。

即ち、一部の中継ノードはリソース，サービスが提供されていないことを通知されており、他の中継ノードは通知されていないために、名前経路情報が網内で一貫していない状態が発生する。このようにネットワーク的に不安定な状態を以下、”アンステーブル状態”と称する。前述したようにノードの安定性が保証されないユビキタス通信においてはアンステーブル状態がしばしば発生するものと考えられる。

アンステーブル状態下のネットワークでは、既にリソース，サービスを提供していないノード（以下、”クローズドノード”と称する）向けにクエリフレームが配送され、リソース，サービスを提供するノードにクエリフレームが到達しない問題が生じる。以下、このようにリソース，サービスを提供しているノードに配送されないフレームを”不到フレーム”と称する。この問題を解決するためには以下のような課題である。

課題１．不到フレームをなくすことを目的として、網が自律的にクローズドノードへの経路を検地し、当該クローズドノードへのクエリフレームを他ノードに転送できることが必要となる。

課題２．アンステーブル状態を収束させることを目的として、任意のノードがクローズドノードとなったことを、定期的な名前経路交換を待たずに、各中継ノードに通知できることが必要となる。

本発明は、上記の点に鑑みなされたものであり、リソース，サービスの提供が停止したクローズドノードへのアクセス要求を同一リソース，サービスを提供している他ノードに転送でき、クローズドノードとなったことを各中継ノードに通知できるネットワークのリソース，サービス発見方法及び中継ノード装置を提供することを目的とする。

請求項１に記載の発明は、ネットワークを構成する複数のノードが自ノードの有するリソース，サービスを公開しており、前記リソース，サービスを識別する識別子と前記リソース，サービスを公開したノードのネットワーク上でのアドレスを前記ネットワークで中継を行う中継ノード間で交換して各中継ノードに検索テーブルを構築し、あるノードから前記識別子を用いて所望のリソース，サービスのアクセス要求を行うと、前記アクセス要求の識別子で各中継ノードの検索テーブルを検索して前記所望のリソース，サービスを公開しているノードにアクセスするネットワークのリソース，サービス発見方法において、
任意ノードでリソース，サービスの提供が停止した場合、前記提供が停止したリソース，サービスの識別子に対し前記任意ノードのアドレスの他に別ノードのアドレスが登録された検索テーブルを持つ中継ノードにて、前記提供が停止したリソース，サービスに対するアクセス要求を、前記任意のノードから前記別ノード宛に振り替えることにより、
リソース，サービスの提供が停止したクローズドノードへのアクセス要求を同一リソース，サービスを提供している他ノードに転送することができる。

請求項２に記載の発明は、請求項１記載のネットワークのリソース，サービス発見方法において、
前記任意ノードで提供が停止したリソース，サービスについての各中継ノードの検索テーブルの変更を、前記提供が停止したリソース，サービスに対するアクセス要求に付加して前記各中継ノードに通知することにより、定期的な識別子の交換を待たずに、クローズドノードとなったことを各中継ノードに通知することができる。

請求項３に記載の発明は、ネットワークを構成する複数のノードが自ノードの有するリソース，サービスを公開しており、前記リソース，サービスを識別する識別子と前記リソース，サービスを公開したノードのネットワーク上でのアドレスを前記ネットワークで中継を行う中継ノード間で交換して各中継ノードに検索テーブルを構築し、あるノードから前記識別子を用いて所望のリソース，サービスのアクセス要求を行うと、前記アクセス要求の識別子で各中継ノードの検索テーブルを検索して前記所望のリソース，サービスを公開しているノードにアクセスするネットワークの中継ノード装置において、
任意ノードでリソース，サービスの提供が停止したために前記アクセス要求で検索テーブルを検索して検索結果が得られなかったとき、前記アクセス要求を前記任意のノードから別ノード宛に振り替えるための差し戻し指示を転送するアクセス要求に書き込む差し戻しチェックフィールド更新手段と、
前記差し戻し指示のないアクセス要求の転送時に自中継ノードのアドレスを前記アクセス要求内にスタックするアドレススタック手段と、
受信した前記差し戻し指示のアクセス要求を転送元の中継ノードに差し戻すため前記アクセス要求内にスタックされている自中継ノードへの転送元の中継ノードのアドレスを抽出するスタックアドレス抽出手段を有することにより、
リソース，サービスの提供が停止したクローズドノードへのアクセス要求を同一リソース，サービスを提供している他ノードに転送することができる。

請求項４に記載の発明は、請求項３記載の中継ノード装置において、
前記差し戻し指示のアクセス要求の転送時に自ノードのアドレスを差し戻し元アドレスとして書き込む差し戻し元アドレス更新部を有し、
請求項５に記載の発明は、請求項４記載の中継ノード装置において、
前記検索テーブルから、受信した前記差し戻し指示のアクセス要求の前記差し戻し元アドレスを削除するテーブル制御手段を有することにより、定期的な識別子の交換を待たずに、クローズドノードとなったことを各中継ノードに通知することができる。

本発明によれば、リソース，サービスの提供が停止したクローズドノードへのアクセス要求を同一リソース，サービスを提供している他ノードに転送することができ、定期的な識別子の交換を待たずに、クローズドノードとなったことを各中継ノードに通知することができる。

以下、図面に基づいて本発明の実施形態について説明する。

図４は、本発明の実現イメージを示す。ここでは下記を前提とする。

前提１．ノード１がクローズドノードとなり、その結果、公開していた”ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”が非公開となる。

前提２．図４に示す時点では、ノードＣがクローズドノードになったことを通知する名前経路情報は中継ノードＢまで伝播されており、他のノードには、まだ伝播されていないため、アンステーブル状態にある。

実現案１では、図４において、不到フレームを受信した中継ノード４が、同一リソースを有する他のノード２への経路を有する中継装置Ａまで当該フレームを再転送する（以下、”差し戻し” と称する）ことで、不到フレームをクローズドノードであるノード１が提供していたリソース，サービスと同一のリソース，サービスを提供しているノード２を宛先として転送する。これにより、クローズドノードへのクエリフレームを他ノードに転送でき課題１を解決する。

また、実現案２では、この差し戻しフレームに名前経路変更の制御情報を付与することで、定期的な名前経路情報の交換に先立って中継ノードは、クローズドノードについての名前経路情報を自身の検索テーブルに反映する。これにより、任意のノードがクローズドノードとなったことを各中継ノードに通知でき課題２を解決する。

上記実現案１，２を実現するための要件を記す。

要件１．差し戻しフレームであることを中継ノードが識別できること（実現案１のため）。

要件２．差し戻しのための経路を、差し戻しフレームを受信した中継ノードに通知できること（実現案２のため）。例えば図４にて、差し戻しフレームを受信した中継ノード３では、中継ノード４から差し戻されたことがわかることである。

要件３．任意の中継ノードにおいて、当該ノードまでクエリが経由した中継ノードがわかること（実現案１のため）。これは、差し戻し時には中継ノードを逆順にたどるためである。

要件４．差し戻しフレームに対してクローズドノードへの経路を除いて検索ができること。（実現案１，２のため）これは、差し戻しフレームを差し戻してきた中継ノード以外の中継ノードに転送する必要があるためである。例えば、図４にて、差し戻されたフレームを中継ノード３は中継ノード４に転送しても再び差し戻しが発生し、ループが発生する。このため中継ノード３は差し戻してきた中継ノード４を選択肢から除いて経路を再検索する。その結果、中継ノード６が選択される。

上記の要件１を解決するため、ノード間で送受信するクエリフレーム（ＴＣＰ／ＩＰ）に、図５に示すように、差し戻しフレームであるか否かを示す差し戻しチェックフィールドＦ１を設ける。また、要件２を解決するため、前ホップの差し戻し中継ノードのＩＰアドレスを格納する差し戻し元ＩＰアドレスフィールドＦ２を設ける（本フィールドは差し戻しチェックフィールドが”１”で、差し戻しフレームを示している場合のみ有効）。中継ノードは本アドレスを検索ツリーから除外して検索を行う。

また、要件３を解決するため、フレームに経由ノードのＩＰアドレスを記録する領域として、経由ノードフィールドを付与する。経由ノードフィールドは、スタックしている中継ノード数を示す中継ノード数Ｆ３と、経由した中継ノード数分の経由ノードのＩＰアドレスがスタックされているアドレススタックＦ４である。

なお、ノード間で送受信するフレームには、図５に示すように、ＩＰヘッダ、コマンド識別（クエリまたは名前経路情報）、検索リソース文字列長、検索リソース文字列、送信元ＩＰアドレスが設けられている。これらの情報は従来のハイブリッド型のフレームにおいても設けられているフィールドである。

次に、各ノードの処理の詳細について説明する。

差し戻し前にクエリフレームを中継する中継ノードで行う処理について説明する。
（１）．任意の中継ノードは受信したフレームのコマンド名から、それが”クエリ”であることを識別する。
（２）．当該ノードはリソース名を予め決められた区切り文字（この場合”／”）毎に分解し、検索用のツリーを分解したキー毎に順に検索して、検索結果にヒットする。
（３）．当該ノードはクエリフレームを転送する際に図５に示す中継ノード数Ｆ３を”１”だけインクリメントする。
（４）．当該ノードは自ノードのＩＰアドレスを図５に示す中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックする。
（５）．当該ノードは自ノードのＩＰアドレスを発信元ＩＰアドレスとして、（２）の検索結果を宛先ＩＰアドレスとしてフレーム送信する。

差し戻しをする中継ノードで行う処理について説明する。
（１）．任意の中継ノードは受信したフレームのコマンド名から、それが”クエリ”であることを識別する。
（２）．当該ノードはリソース名を予め決められた区切り文字（この場合”／”）毎に分解し、検索用のツリーを分解したキー毎に順に検索し、検索結果に未ヒット。これが差し戻し処理のトリガとなる。
（３）．当該ノードは差し戻し元ＩＰアドレスフィールドＦ２に自ノードのＩＰアドレスを書き込む。
（４）．当該ノードはクエリフレームの差し戻しチェックフィールドＦ１を「差し戻し」を示す値”１”に更新する。
（５）．当該ノードは中継ノード数Ｆ３を”１”だけデクリメントする。
（６）．当該ノードは中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレスを宛先のＩＰアドレスとする。
（７）．当該ノードは自ノードのＩＰアドレスを発信元ＩＰアドレスとして、フレームを送信する。

差し戻しフレームを受信した中継ノードで行う処理について説明する。
（１）．任意の中継ノードは受信したフレームのコマンド名から、それが”クエリ”であることを識別する。
（２）．当該ノードは差し戻しフレームを受信した中継ノードは図５に示すフレーム内の検索リソース文字列が示す検索リソース名から、差し戻し元ＩＰアドレスフィールドＦ２が示すＩＰアドレスを除外して検索ツリーを再作成する。
（３）．当該ノードは再構成したツリーから、検索リソース文字列が示すリソース名を予め決められた区切り文字（この場合”／”）毎に分解し、検索用のツリーを分解したキー毎に順に検索する。
（４）．当該ノードは検索結果が得られた場合（例えば、図４の中継ノード３）、
（４Ａ）当該ノードは、差し戻しチェックフィールドＦ１の「差し戻し」の指示を解除する。

（４Ｂ）当該ノードは検索結果として得られたＩＰアドレスを宛先のＩＰアドレス、自ノードのＩＰアドレスを発信元のＩＰアドレスとして、フレームを送信する。
（５）．検索結果が得られなかった場合、中継ノード数Ｆ３が”１”以上かを確認する。そして、中継ノード数Ｆ３が０の場合は、自ノードがクエリフレームの送信ノードである。即ち、クエリフレームで要求したリソース，サービスをクローズドノード以外は公開していないため、クエリフレームの送信を要求したアプリケーション経由でユーザにリソース，サービスの発見に失敗したことを通知する。

中継ノード数Ｆ３が１以上の場合（例えば、図４の中継ノード４）、
（５Ａ）当該ノードは、差し戻し元ＩＰアドレスフィールドＦ２に自ノードのＩＰアドレスを書き込む。

（５Ｂ）当該ノードは、中継ノード数Ｆ３を”１”だけデクリメントする。

（５Ｃ）当該ノードは、中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレスを宛先のＩＰアドレスとする。

（５Ｄ）当該ノードは、自ノードのＩＰアドレスを発信元ＩＰアドレスとして、フレームを送信する。

図６，図７，図８は、差し戻し発生時のフレームのフローチャートを示す。なお、各図に、図４に示したフレームの各フィールドも併記する。ただし、コマンド種別は全て”クエリ”であり、検索リソース文字列は全て”ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”であるため、記載を省略する。

前提として、ノードＣがクローズドノードとなり、その結果、公開していた”ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”が非公開となる。図６に示す時点においては、ノードＣがクローズドノードになったことを示す名前経路情報は中継ノード５まで伝播されているが、他のノードにまでは伝播されておらず、アンステーブル状態にある。また、”ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”はノードＢとノードＣの双方が有する。クエリフレームはノードＡが送信する（ノードＡがリソース，サービスの発見を行う）。
（１）．ノードＡは、“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を有するノードの発見を依頼するクエリフレームをネットワークに送信する（図６中（１））。
（２）．中継ノード１は、受信したフレームのコマンド名から、それが”クエリ”であることを識別する。かつ、差し戻しチェックフィールドＦ１から差し戻しフレームではないことを識別する。
（３）．中継ノード１は、リソース名を予め決められた区切り文字（この場合”／”）毎に分解し、検索用のツリーを分解したキー毎に順に検索する。
（４）．検索結果の次ホップが中継ノード２であることから、中継ノード１は中継ノード数Ｆ３を”１”だけインクリメントし、中継ノード１を表わす「ＩＰ−１」を中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックして、中継ノード２にクエリフレームを転送する（図６中（２））。
（５）．中継ノード２は（２），（３），（４）と同様の処理を行い、中継ノード３にクエリフレームを転送する（図６中（３））。
（６）．中継ノード３は（２），（３），（４）と同様の処理を行う。この際、次ポップの中継ノードとして中継ノード４，６があるが、ここでは記載しない何らかのアルゴリズムによりそのうちのいずれか一つを検索結果とする。ここでは、中継ノード４が検索結果であると仮定し、中継ノード４にクエリフレームを転送する（図６中（４））。
（７）．中継ノード４は（２），（３），（４）と同様の処理を行い、中継ノード５にクエリフレームを転送する（図６中（５））。
（８）．中継ノード５は（２），（３）と同様の処理を行うが、ノードＣはリソース，サービスを提供しておらず、クローズドノードになっている。このため中継ノード５は検索結果を得られず、差し戻し処理が開始される。
（９）．中継ノード５は、クエリフレームの差し戻しチェックフィールドＦ１を「差し戻し」を示すように”１”に更新し、差し戻し元ＩＰアドレスフィールドＦ２に自ノードのＩＰアドレス「ＩＰ−５」を書き込み、かつ、中継ノード数Ｆ３が示す段数のアドレススタックＦ４のＩＰアドレスである「ＩＰ−４」を宛先のＩＰアドレス、自ノードのＩＰアドレスを発信元のＩＰアドレスとして、クエリフレームを転送する（図７中（６））。
（１０）．中継ノード４は、差し戻しチェックフィールドＦ１」が”１”であることから差し戻しフレームであることを識別する。受信したフレーム内の「検索リソース文字列」が示す検索リソース名から「差し戻し元ＩＰアドレスフィールドＦ２」が示すＩＰアドレス（ＩＰ−３）を除外して検索ツリーを再作成する。再構成したツリーに対して、項２項３の処理を行うが、検索結果が得られないため、差し戻し処理を継続する。
（１１）．中継ノード４は、中継ノード数Ｆ３が”１”以上であることを識別する。中継ノード数Ｆ３を”１”デクリメントする。中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレス「ＩＰ−３」を取得する。差し戻し元ＩＰアドレスフィールドＦ２に自ノードのＩＰアドレスである「ＩＰ−４」を書き込み、取得したＩＰアドレス「ＩＰ−３」にクエリフレームを転送する（図７中（７））。
（１２）．中継ノード３は、差し戻しチェックフィールドＦ１が”１”であることから差し戻しフレームであることを識別する。受信したフレーム内の検索リソース文字列が示す検索リソース名から差し戻し元ＩＰアドレスフィールドＦ２が示すＩＰアドレス「ＩＰ−３」を除外して検索ツリーを再作成する。再構成したツリーに対して、（２），（３）の処理を行い、検索結果として”ＩＰ−６”を得る。検索結果を得たことで差し戻し処理の終了の終了を決定する。
（１３）．中継ノード３は、差し戻しチェックフィールドＦ１の「差し戻し」指示を解除するために”０”に変更する。検索結果として得られたＩＰアドレス「ＩＰ−６」を宛先のＩＰアドレス、自ノードのＩＰアドレス「ＩＰ−３」を発信元のＩＰアドレスとして、クエリフレームを送信する（図８中（８））。
（１４）．中継ノード６は（２），（３），（４）と同様の処理を行い、ノードＢにクエリフレームを転送する（図８（９））。
（１５）．ノードＢは、（２），（３）の処理を行い、検索結果が自局のＩＰである（自身が発見対象のリソース“ｒｅｓｏｕｃｅ／ｍｕｓｉｃ／ｒｏｃｋ．ｍｐ３”を有している）ことから、”送信元ノードのＩＰ”フィールドのＩＰ−Ａ、つまりノードＡに向けてＴＣＰコネクションを張り、ファイル転送を開始する（図８中（１０））。

図９は、中継ノードの一実施形態のブロック図を示す。同図中、検索テーブルＤＢ１０は、リソース，サービス名から次の転送先ノードを検索するために使われるツリー情報を有するデータベースである。

検索テーブルＤＢ１０は、図１０の構成図に示すように、エントリ毎に独立の番号を示すフィールドであるエントリ番号（Ｎｏ．）と、本エントリの前に検索したエントリ番号である前エントリ番号を有する。これによって、ツリー構造を示すことが可能となる。また、エントリ番号毎に、検索時に使う文字列であってリソース，サービス名の一部を示す名前と、引き続き検索が必要（途中の枝）か、不要（末枝）かを示すツリー終了フラグ（”１”で終了、”０”で未終了を示す）、ツリー終了フラグが”１”のときに得られる次の転送先ノードとなり得るＩＰアドレスの数を示すＩＰアドレス数、ＩＰアドレス数で示された数分のＩＰアドレスが格納されるフィールドを有する。

また、区切り文字保持部１２には、リソース，サービス名の区切り文字が格納され、自局ＩＰアドレス保持部１４には、自局のＩＰアドレス（自ノードのＩＰアドレス）が格納される。上記の区切り文字，自局ＩＰアドレスは予めコンソールから入力されるものとする。

図９において、通信終端部１６は、ネットワークからの通信を電気的に終端する。ネットワークから受信したフレームはフィールド判定部１８に渡される。また、ＩＰフレーム作成部２０から渡されたフレームを電気的にネットワークへ送信する。

フレーム判定部１８は、通信終端部１６から渡されたフレームの図５に示すコマンド種別と、差し戻しチェックフィールドＦ１を識別し、次に処理を行う機能ブロックを決定して当該フレームを渡す。ここでは、コマンド種別＝クエリ、差し戻しチェックフィールドＦ１＝０（差し戻しフレームではない）の場合は当該フレームをテーブル検索部２２に渡す。コマンド種別＝クエリ、差し戻しチェックフィールドＦ１＝１（差し戻しフレーム）の場合は当該フレームを差し戻し元ＩＰアドレス抽出部２４に渡す。また、コマンド種別＝名前経路情報の場合（名前経路情報のフレーム）、差し戻しチェックフィールドＦ１の値に拘わらず名前経路設定部２８に当該フレームを渡す。

差し戻し元ＩＰアドレス抽出部２４は、フレーム判定部１８から渡されたフレームの差し戻し元ＩＰアドレスフィールドＦ２のＩＰアドレスを識別して、テーブル制御部２６にフレーム内の検索リソース文字列と、その検索結果となる差し戻し元ＩＰアドレスフィールドＦ２のＩＰアドレスを引数として、削除指示を出す。

これにより、テーブル制御部２６は検索テーブルＤＢ１０を検索し、当該文字列を検索した結果のツリー終了フラグ＝１のエントリのＩＰアドレスから、差し戻し元ＩＰアドレス抽出部２４より指示されたＩＰアドレスを削除し、ＩＰアドレス数のエントリを”１”だけデクリメントする。そして、テーブル更新の終了を差し戻し元ＩＰアドレス抽出部２４に通知する。差し戻し元ＩＰアドレス抽出部２４は、この通知を受けてテーブル検索部２２にフレームを渡す。

名前経路設定部２８は、フレーム判定部１８から供給される名前経路設定フレームに応じてテーブル制御部２６に対し検索テーブルＤＢ１０の構築時の追加／削除指示を行う。

テーブル制御部２６は、検索テーブルＤＢ１０の構築／再構築を行う。まず、区切り文字保持部１２にアクセスし、予め決められた区切り文字を取得し、フレーム内の検索リソース文字列を当該区切り文字毎に分解し、エントリ番号と前エントリ番号をキーにエントリをたどりながら検索テーブルＤＢ１０を検索する。その結果、以下のいずれかとなる。

差し戻し元ＩＰアドレス抽出部２４からの削除指示の場合、検索結果が得られたときは、検索テーブルＤＢ１０のツリー終了フラグ＝１のエントリのＩＰアドレスから、差し戻し元ＩＰアドレス抽出部２４より指示されたＩＰアドレスを削除し、ＩＰアドレス数のフィールドを”１”だけデクリメントする。そして、テーブル更新の終了を差し戻し元ＩＰアドレス抽出部２４に通知する。一方、検索結果が得られなかったときは、フィールドに対する処理は行わず、テーブル更新の終了を差し戻し元ＩＰアドレス抽出部２４に通知する。

名前経路設定部２８からの追加指示（テーブル構築時の処理）の場合、検索結果が得られたときは、ツリー終了フラグ＝１のエントリの”ＩＰアドレス”から、名前経路設定部２８から指示されたＩＰアドレスを追加し、ＩＰアドレス数のフィールドを”１”だけインクリメントし、名前経路設定部２８に通知する。一方、検索結果が得られないときは、エントリの追加処理を行う。検索テーブルＤＢ１０のエントリ番号を空き番号から新規に追加し、前エントリ番号に前にヒットしたエントリ番号フィールド値を書き込み、名前フィールドに検索文字列を書き込む。検索文字列が区切り文字で区切られた最後の文字列（例えばｒｏｃｋ．ｍｐ３）の場合、ツリー終了フラグに”１”を、ＩＰアドレス数に”１”を、ＩＰアドレス１にフレーム内の送信元ＩＰアドレスの値を書き込む。

テーブル検索部２２はフレーム判定部１８または差し戻し元ＩＰアドレス抽出部２４から渡されたクエリフレームから次に転送するノードのＩＰアドレスを抽出する。まず、区切り文字保持部１２にアクセスし、予め決められた区切り文字を取得する。次に、フレーム内の検索リソース文字列を当該区切り文字毎に分解し、検索テーブルＤＢ１０のエントリ番号と前エントリ番号をキーにエントリをたどりながら検索する。その結果、以下のいずれかとなる。

テーブルヒットの場合、つまり、検索テーブルＤＢ１０のツリー終了フラグ＝１のエントリからＩＰアドレスを得た場合、それを検索結果とする。なお、複数の検索結果が得られた場合、ここでは記載しない何らかのアルゴリズムによりそのうちのいずれか一つを検索結果とする。

そして、自局ＩＰアドレス保持部１４から自局のＩＰアドレスを得て、検索テーブルＤＢ１０から得られたＩＰアドレスと自局のＩＰアドレスを比較し、両ＩＰアドレスが異なる場合（他局の場合）、検索結果のＩＰアドレスをＩＰフレーム作成部２０がフレームを作成するときの宛先ＩＰアドレスとする。差し戻しチェックフィールド判定部Ｂ３０にフレームを渡す。両ＩＰアドレスが同じ場合（自局の場合）、クエリフレームが要求するリソース，サービスを自ノードが有しているＴＣＰセッションを発信元と張るためのアプリケーション３２に転送する。

テーブル未ヒットの場合、つまり、名前フィールドに合致するエントリがない場合、差し戻しチェックフィールド判定部Ａ３４にクエリフレームを渡す。

差し戻しチェックフィールド判定部Ａ３４は、テーブル検索部２２から渡されたフレームの差し戻しチェックフィールドＦ１の値を識別し、次に処理を行う機能ブロックを決定する。差し戻しチェックフィールドＦ１＝０のときは、差し戻し元ＩＰアドレスフィールド更新部３６にフレームを渡す。差し戻しチェックフィールドＦ１＝１のときは、中継ノード数＠経由ノードフィールド確認部３８にフレームを渡す。

差し戻しチェックフィールド判定部Ｂ３０は、テーブル検索部２２から渡されたフレームの差し戻しチェックフィールドＦ１の値を識別し、次に処理を行う機能ブロックを決定する。なお、決定のルールは差し戻しチェックフィールド判定部Ａ３４とは異なっている。差し戻しチェックフィールドＦ１＝０のときは、アドレススタック＠経由ノードフィールド制御部４０にフレームを渡す。差し戻しチェックフィールドＦ１＝１のときは、差し戻しチェックフィールド更新部４２にフレームを渡す。

中継ノード数＠経由ノードフィールド確認部３８は、経由ノードフィールド内の中継ノード数Ｆ３を識別する。識別結果によって動作は以下のようになる。中継ノード数Ｆ３＝０の場合、自ノードがクエリフレームの送信ノードである。これ以上の差し戻し先がないため、クエリフレームの送信要求を出したアプリケーション４４に通知する。中継ノード数Ｆ３＝１以上の場合、差し戻し元ＩＰアドレスフィールド更新部３６にフレームを渡す。

差し戻しチェックフィールド更新部４２は、差し戻しチェックフィールドＦ１の値を変更する。差し戻しチェックフィールドＦ１の値を０から１に変更してアドレススタック＠経由ノードフィールド制御部４０にフレームを渡す。また、差し戻しチェックフィールドＦ１の値を１から０に変更してＩＰフレーム作成部２０にフレームを渡す。

差し戻し元ＩＰアドレスフィールド更新部３６は、自局ＩＰアドレス保持部１４から自局のＩＰアドレスを獲得し、フレームの差し戻し元ＩＰアドレスフィールドＦ２を自局ＩＰアドレスに更新し、アドレススタック＠経由ノードフィールド制御部４０にフレームを渡す。

アドレススタック＠経由ノードフィールド制御部４０は、フレームの経由ノードフィールドに対して下記の処理を行う。差し戻しチェックフィールド判定部Ｂ３０からフレームが渡された場合、中継ノード数Ｆ３を”１”だけインクリメントし、自局ＩＰアドレス保持部１４から得た自ノードのＩＰアドレスを、中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックする。また、テーブル検索部２２で取得したＩＰアドレスを送信先ＩＰアドレスとしてＩＰフレーム作成部２０に通知し、ＩＰフレーム作成部２０にフレームを渡す。なお、経由アドレスフィールドから次転送先のＩＰアドレスは取得しない。

また、アドレススタック＠経由ノードフィールド制御部４０は、差し戻し元ＩＰアドレスフィールド更新部３６からフレームが渡された場合、中継ノード数Ｆ３を”１”だけデクリメントし、中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレスを取得する。そして、取得したＩＰアドレスを送信先ＩＰアドレスとしてＩＰフレーム作成部２０に通知し、ＩＰフレーム作成部２０にフレームを渡す。

また、アドレススタック＠経由ノードフィールド制御部４０は、差し戻しチェックフィールド更新部４２からフレームが渡された場合、中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレスを取得する。そして、取得したＩＰアドレスを送信先ＩＰアドレスとして、ＩＰフレーム作成部２０に通知し、ＩＰフレーム作成部２０にフレームを渡す。

ＩＰフレーム作成部２０は、送信元ＩＰアドレス及び送信先ＩＰアドレスを得てＩＰフレームの作成を行う。送信元ＩＰアドレスは自局ＩＰアドレス保持部１４から得る。送信先アドレスのパターンは以下の通りである。テーブル検索部２２で未ヒット時には、アドレススタック＠経由ノードフィールド制御部４０で獲得し経由ノードフィールドにスタックされていたＩＰアドレスを用いる。テーブル検索部２２でヒット時には、検索テーブルＤＢ１０で得たＩＰアドレスを用いる。

コンソール部４６は、区切り文字保持部１２と自局ＩＰアドレス保持部１４の設定を予め行うユーザの入出力を扱うインタフェースである。

図１１は、差し戻し前のクエリフレームを中継する中継ノードにおいてフレームが経由するブロックのフローチャートを示す。同図中、ステップＳ１１で通信終端部１６はネットワークからフレームを受信する。ステップＳ１２でフレーム判定部１８は受信フレームをクエリフレームと判定する。ステップＳ１３でテーブル検索部２２はテーブルヒット、かつ、他局と判定する。

次に、ステップＳ１４で差し戻しチェックフィールド判定部Ｂ３０は差し戻しチェックフィールドＦ１＝０と判定する。ステップＳ１５でアドレススタック＠経由ノードフィールド制御部４０は、フレームの中継ノード数Ｆ３を”１”だけインクリメントし、自ノードのＩＰアドレスを中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックし、テーブル検索部２２で取得したＩＰアドレスを送信先ＩＰアドレスとする。ステップＳ１６でＩＰフレーム作成部２０はＩＰフレームを作成して通信終端部１６からネットワークに送出する。

図１２は、差し戻しをする中継ノードにおいてフレームが経由するブロックのフローチャートを示す。同図中、ステップＳ２１で通信終端部１６はネットワークからフレームを受信する。ステップＳ２２でフレーム判定部１８は受信フレームをクエリフレームと判定する。ステップＳ２３でテーブル検索部２２はテーブル未ヒットと判定する。

次に、ステップＳ２４で差し戻しチェックフィールド判定部Ａ３４はフレームの差し戻しチェックフィールドＦ２＝０と判定する。ステップＳ２５で差し戻し元ＩＰアドレスフィールド更新部３６はフレームの差し戻し元ＩＰアドレスフィールドＦ２を自局ＩＰアドレスに更新する。ステップＳ２６で差し戻しチェックフィールド更新部４２は差し戻しチェックフィールドＦ１＝１に更新する。ステップＳ２７でアドレススタック＠経由ノードフィールド制御部４０は、中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレスを送信先ＩＰアドレスとする。ステップＳ２８でＩＰフレーム作成部２０はＩＰフレームを作成して通信終端部１６からネットワークに送出する。

図１３は、差し戻しフレームを受信した中継ノード（転送先が見つかった場合）においてフレームが経由するブロックのフローチャートを示す。同図中、ステップＳ３１で通信終端部１６はネットワークからフレームを受信する。ステップＳ３２でフレーム判定部１８は受信フレームを差し戻しクエリフレームと判定する。ステップＳ３３で差し戻しＩＰアドレス抽出部２４はフレームの差し戻し元ＩＰアドレスフィールドＦ２のＩＰアドレスを識別して削除指示を出す。ステップＳ３４でテーブル検索部２２はテーブルヒットかつ、他局と判定する。

次に、ステップＳ３５で差し戻しチェックフィールド判定部Ｂ３０は差し戻しチェックフィールドＦ１＝１と判定する。ステップＳ３６で差し戻しチェックフィールド更新部４２はフレームの差し戻しチェックフィールドＦ１＝０に更新する。ステップＳ３７でＩＰフレーム作成部２０はＩＰフレームを作成して通信終端部１６からネットワークに送出する。

図１４は、差し戻しフレームを受信した中継ノード（転送先が見つからない場合）においてフレームが経由するブロックのフローチャートを示す。同図中、ステップＳ４１で通信終端部１６はネットワークからフレームを受信する。ステップＳ４２でフレーム判定部１８は受信フレームを差し戻しクエリフレームと判定する。ステップＳ４３で差し戻しＩＰアドレス抽出部２４はフレームの差し戻し元ＩＰアドレスフィールドＦ２のＩＰアドレスを識別して削除指示を出す。ステップＳ４４でテーブル検索部２２はテーブル未ヒットと判定する。

次に、ステップＳ４５で差し戻しチェックフィールド判定部Ａ３４はフレームの差し戻しチェックフィールドＦ１＝１と判定する。ステップＳ４６で中継ノード数＠経由ノードフィールド確認部３８は中継ノード数Ｆ３＝１以上と判定する。ステップＳ４７で差し戻し元ＩＰアドレスフィールド更新部３６はフレームの差し戻し元ＩＰアドレスフィールドＦ２を自局ＩＰアドレスに更新する。ステップＳ４８でアドレススタック＠経由ノードフィールド制御部４０は中継ノード数Ｆ３を”１”だけデクリメントし、中継ノード数Ｆ３が示す段数のアドレススタックＦ４にスタックされているＩＰアドレスを取得してフレームの送信先ＩＰアドレスとする。ステップＳ４９でＩＰフレーム作成部２０はＩＰフレームを作成して通信終端部１６からネットワークに送出する。

図１５は、差し戻しフレームを受信した中継ノード（転送先が見つからず、クエリフレームの送信元まで差し戻された場合）においてフレームが経由するブロックのフローチャートを示す。同図中、ステップＳ５１で通信終端部１６はネットワークからフレームを受信する。ステップＳ５２でフレーム判定部１８は受信フレームを差し戻しクエリフレームと判定する。ステップＳ５３で差し戻しＩＰアドレス抽出部２４はフレームの差し戻し元ＩＰアドレスフィールドＦ２のＩＰアドレスを識別して削除指示を出す。ステップＳ５４でテーブル検索部２２はテーブルテーブル未ヒットと判定する。

次に、ステップＳ５５で差し戻しチェックフィールド判定部Ａ３４はフレームの差し戻しチェックフィールドＦ１＝１と判定する。ステップＳ５６で中継ノード数＠経由ノードフィールド確認部３８は中継ノード数Ｆ３＝０と判定する。ステップＳ５７で中継ノード数＠経由ノードフィールド確認部３８はクエリフレームの送信元アプリケーション４４に要求リソースが網上になく、クエリフレームが戻ってきた旨を通知する。

図１６は、クエリフレームを終端する中継ノードにおいてフレームが経由するブロックのフローチャートを示す。同図中、ステップＳ６１で通信終端部１６はネットワークからフレームを受信する。ステップＳ６２でフレーム判定部１８は受信フレームをクエリフレームと判定する。ステップＳ６３でテーブル検索部２２はテーブルヒットかつ、自局と判定する。ステップＳ６４でテーブル検索部２２はクエリフレームの受信先アプリケーションにクエリフレームを転送する。

なお、差し戻しチェックフィールド更新部４２が請求項または付記に記載の差し戻しチェックフィールド更新手段に対応し、アドレススタック＠経由ノードフィールド制御部４０がアドレススタック手段に対応し、差し戻し元ＩＰアドレス抽出部２４がスタックアドレス抽出手段に対応し、差し戻し元ＩＰアドレスフィールド更新部３６が差し戻し元アドレス更新部に対応し、テーブル制御部２６がテーブル制御手段に対応する。

ところで、広域アドレスと閉域アドレスの登録のみに着目している特許文献１のものでは、中継ノードによるデータフレームの差し戻しという概念及びそれに関連する技術がそもそも存在しない。また、特許文献２のものでは、宛先となるノードは一つであることを前提としており、中継ノードによる差し戻しという概念及びそれに関連する技術がそもそも存在しない。
（付記１）
ネットワークを構成する複数のノードが自ノードの有するリソース，サービスを公開しており、前記リソース，サービスを識別する識別子と前記リソース，サービスを公開したノードのネットワーク上でのアドレスを前記ネットワークで中継を行う中継ノード間で交換して各中継ノードに検索テーブルを構築し、あるノードから前記識別子を用いて所望のリソース，サービスのアクセス要求を行うと、前記アクセス要求の識別子で各中継ノードの検索テーブルを検索して前記所望のリソース，サービスを公開しているノードにアクセスするネットワークのリソース，サービス発見方法において、
任意ノードでリソース，サービスの提供が停止した場合、前記提供が停止したリソース，サービスの識別子に対し前記任意ノードのアドレスの他に別ノードのアドレスが登録された検索テーブルを持つ中継ノードにて、前記提供が停止したリソース，サービスに対するアクセス要求を、前記任意のノードから前記別ノード宛に振り替えることを特徴とするネットワークのリソース，サービス発見方法。
（付記２）
付記１記載のネットワークのリソース，サービス発見方法において、
前記任意ノードで提供が停止したリソース，サービスについての各中継ノードの検索テーブルの変更を、前記提供が停止したリソース，サービスに対するアクセス要求に付加して前記各中継ノードに通知することを特徴とするネットワークのリソース，サービス発見方法。
（付記３）
ネットワークを構成する複数のノードが自ノードの有するリソース，サービスを公開しており、前記リソース，サービスを識別する識別子と前記リソース，サービスを公開したノードのネットワーク上でのアドレスを前記ネットワークで中継を行う中継ノード間で交換して各中継ノードに検索テーブルを構築し、あるノードから前記識別子を用いて所望のリソース，サービスのアクセス要求を行うと、前記アクセス要求の識別子で各中継ノードの検索テーブルを検索して前記所望のリソース，サービスを公開しているノードにアクセスするネットワークの中継ノード装置において、
任意ノードでリソース，サービスの提供が停止したために前記アクセス要求で検索テーブルを検索して検索結果が得られなかったとき、前記アクセス要求を前記任意のノードから別ノード宛に振り替えるための差し戻し指示を転送するアクセス要求に書き込む差し戻しチェックフィールド更新手段と、
前記差し戻し指示のないアクセス要求の転送時に自中継ノードのアドレスを前記アクセス要求内にスタックするアドレススタック手段と、
受信した前記差し戻し指示のアクセス要求を転送元の中継ノードに差し戻すため前記アクセス要求内にスタックされている自中継ノードへの転送元の中継ノードのアドレスを抽出するスタックアドレス抽出手段を
有することを特徴とする中継ノード装置。
（付記４）
付記３記載の中継ノード装置において、
前記差し戻し指示のアクセス要求の転送時に自ノードのアドレスを差し戻し元アドレスとして書き込む差し戻し元アドレス更新部を
有することを特徴とする中継ノード装置。
（付記５）
付記４記載の中継ノード装置において、
前記検索テーブルから、受信した前記差し戻し指示のアクセス要求の前記差し戻し元アドレスを削除するテーブル制御手段を
有することを特徴とする中継ノード装置。
（付記６）
付記５記載の中継ノード装置において、
前記アクセス要求の識別子で各中継ノードの検索テーブルを検索するテーブル検索手段は、前記テーブル制御手段で前記差し戻し元アドレスが削除された後の検索テーブルを検索することを特徴とする中継ノード装置。
（付記７）
付記３乃至６のいずれか記載の中継ノード装置において、
前記スタックアドレス抽出手段は、前記アクセス要求内にスタックされている自中継ノードへの転送元の中継ノードのアドレスを抽出したのち、前記アクセス要求から抽出した中継ノードのアドレスを削除することを特徴とする中継ノード装置。

分散型のリソース，サービスの発見手順の一例を説明するための図である。 名前経路情報の配布フェーズのフローチャートを示す図である。 リソース，サービスの発見フェーズのフローチャートを示す図である。 本発明の実現イメージを示す図である。 本発明で用いるクエリフレームのフォーマットを示す図である。 本発明の差し戻し発生時のフレームのフローチャートである。 本発明の差し戻し発生時のフレームのフローチャートである。 本発明の差し戻し発生時のフレームのフローチャートである。 中継ノードの一実施形態のブロック図である。 検索テーブルＤＢの構成図である。 差し戻し前のクエリフレームを中継する中継ノードにおいてフレームが経由するブロックのフローチャートである。 差し戻しをする中継ノードにおいてフレームが経由するブロックのフローチャートである。 差し戻しフレームを受信した中継ノード（転送先が見つかった場合）においてフレームが経由するブロックのフローチャートである。 差し戻しフレームを受信した中継ノード（転送先が見つからない場合）においてフレームが経由するブロックのフローチャートである。 差し戻しフレームを受信した中継ノード（転送先が見つからず、クエリフレームの送信元まで差し戻された場合）においてフレームが経由するブロックのフローチャートである。 クエリフレームを終端する中継ノードにおいてフレームが経由するブロックのフローチャートである。

符号の説明

１０ 検索テーブルＤＢ
１２ 区切り文字保持部
１４ 自局ＩＰアドレス保持部
１６ 通信終端部
１８ フィールド判定部
２０ ＩＰフレーム作成部
２２ テーブル検索部
２４ 差し戻し元ＩＰアドレス抽出部
２６ テーブル制御部
２８ 名前経路設定部
３０ 差し戻しチェックフィールド判定部Ｂ
３２，４４ アプリケーション
３４ 差し戻しチェックフィールド判定部Ａ
３６ 差し戻し元ＩＰアドレスフィールド更新部
３８ 中継ノード数＠経由ノードフィールド確認部
４０ アドレススタック＠経由ノードフィールド制御部
４２ 差し戻しチェックフィールド更新部
４６ コンソール部

Claims (5)

1. ネットワークを構成する複数のノードが自ノードの有するリソース，サービスを公開しており、前記リソース，サービスを識別する識別子と前記リソース，サービスを公開したノードのネットワーク上でのアドレスを前記ネットワークで中継を行う中継ノード間で交換して各中継ノードに検索テーブルを構築し、あるノードから前記識別子を用いて所望のリソース，サービスのアクセス要求を行うと、前記アクセス要求の識別子で各中継ノードの検索テーブルを検索して前記所望のリソース，サービスを公開しているノードにアクセスするネットワークのリソース，サービス発見方法において、
   任意ノードでリソース，サービスの提供が停止した場合、前記提供が停止したリソース，サービスの識別子に対し前記任意ノードのアドレスの他に別ノードのアドレスが登録された検索テーブルを持つ中継ノードにて、前記提供が停止したリソース，サービスに対するアクセス要求を、前記任意のノードから前記別ノード宛に振り替えることを特徴とするネットワークのリソース，サービス発見方法。
2. 請求項１記載のネットワークのリソース，サービス発見方法において、
   前記任意ノードで提供が停止したリソース，サービスについての各中継ノードの検索テーブルの変更を、前記提供が停止したリソース，サービスに対するアクセス要求に付加して前記各中継ノードに通知することを特徴とするネットワークのリソース，サービス発見方法。
3. ネットワークを構成する複数のノードが自ノードの有するリソース，サービスを公開しており、前記リソース，サービスを識別する識別子と前記リソース，サービスを公開したノードのネットワーク上でのアドレスを前記ネットワークで中継を行う中継ノード間で交換して各中継ノードに検索テーブルを構築し、あるノードから前記識別子を用いて所望のリソース，サービスのアクセス要求を行うと、前記アクセス要求の識別子で各中継ノードの検索テーブルを検索して前記所望のリソース，サービスを公開しているノードにアクセスするネットワークの中継ノード装置において、
   任意ノードでリソース，サービスの提供が停止したために前記アクセス要求で検索テーブルを検索して検索結果が得られなかったとき、前記アクセス要求を前記任意のノードから別ノード宛に振り替えるための差し戻し指示を転送するアクセス要求に書き込む差し戻しチェックフィールド更新手段と、
   前記差し戻し指示のないアクセス要求の転送時に自中継ノードのアドレスを前記アクセス要求内にスタックするアドレススタック手段と、
   受信した前記差し戻し指示のアクセス要求を自中継ノードへの転送元の中継ノードに差し戻すため前記アクセス要求内にスタックされている転送元の中継ノードのアドレスを抽出するスタックアドレス抽出手段を
   有することを特徴とする中継ノード装置。
4. 請求項３記載の中継ノード装置において、
   前記差し戻し指示のアクセス要求の転送時に自ノードのアドレスを差し戻し元アドレスとして書き込む差し戻し元アドレス更新部を
   有することを特徴とする中継ノード装置。
5. 請求項４記載の中継ノード装置において、
   前記検索テーブルから、受信した前記差し戻し指示のアクセス要求の前記差し戻し元アドレスを削除するテーブル制御手段を
   有することを特徴とする中継ノード装置。
   

Images