(57)【特許請求の範囲】
【請求項１】
ファイル共有アプリケーションに対するインデックス・サーバ・サポートを提供する方法であって、
（ａ）ネットワーク内で相互接続されたインデックス・サーバの階層構造を調査するステップを有し、
前記ステップ（ａ）が、
特定の要求側クライアントにおいて、インデックス・サーバの前記階層構造を調査するための初期の調査要求を生成し且つ当該初期の調査要求をインデックス・サーバの前記階層構造内で高レベルにある既知のリモート・インデックス・サーバに向けて送信し、
前記特定の要求側クライアントと前記リモート・インデックス・サーバとの間に配置された特定の中間インデックス・サーバにおいて、送信された前記初期の調査要求を遮断し、
前記初期の調査要求を遮断した前記特定の中間インデックス・サーバの識別情報を前記特定の要求側クライアントに通知し、
前記特定の要求側クライアントにおいて、前記特定の中間インデックス・サーバの前記識別情報を受信したことに応答して、前記特定の中間インデックス・サーバを今後のファイル照会要求の宛先として登録することを含み、
（ｂ）インデックス・サーバの前記階層構造をさらに調査するステップを有し、
前記ステップ（ｂ）が、
前記特定の中間インデックス・サーバにおいて、インデックス・サーバの前記階層構造をさらに調査するための新しい調査要求を生成し且つ当該新しい調査要求を前記リモート・インデックス・サーバに向けて送信し、
前記特定の中間インデックス・サーバと前記リモート・インデックス・サーバとの間に配置された追加の中間インデックス・サーバにおいて、送信された前記新しい調査要求を遮断し、
前記新しい調査要求を遮断した前記追加の中間インデックス・サーバの識別情報を前記特定の中間インデックス・サーバに通知し、
前記特定の中間インデックス・サーバにおいて、前記追加の中間インデックス・サーバの前記識別情報を受信したことに応答して、前記追加の中間インデックス・サーバを前記特定の中間インデックス・サーバの親インデックス・サーバとして登録し、
前記追加の中間インデックス・サーバにおいて、前記新しい調査要求を遮断したことに応答して、前記特定の中間インデックス・サーバを前記追加の中間インデックス・サーバの子インデックス・サーバとして登録することを含み、
（ｃ）ファイルを照会する前記ネットワーク内の要求側クライアントのうち前記特定の要求側クライアントを除く追加の要求側クライアントごとに、前記ステップ（ａ）を反復するステップと、
（ｄ）前記リモート・インデックス・サーバが親インデックス・サーバとして識別されるまで、前記ネットワーク内の中間インデックス・サーバのうち、前記特定の中間インデックス・サーバを除く追加の中間インデックス・サーバごとに、前記ステップ（ｂ）を反復するステップと、
（ｅ）前記特定の要求側クライアントにおいて、前記ファイル共有アプリケーションの下でファイルを照会するためのファイル照会要求を生成し且つ当該ファイル照会要求を前記今後のファイル照会要求の宛先として登録された前記特定の中間インデックス・サーバに向けて送信し、
前記特定の中間インデックス・サーバにおいて、そのインデックス内で前記要求されたファイルを見つけられるか否かを決定し、
そうでない場合は、前記特定の中間インデックス・サーバの親インデックス・サーバに対し前記要求されたファイルを見つけるように要求することにより、当該親インデックス・サーバから、前記特定の中間インデックス・サーバを除く、当該親インデックス・サーバのすべての子インデックス・サーバに前記ファイル照会要求を転送させ、
前記親インデックス・サーバの任意の子インデックス・サーバにおいて、そのインデックス内で前記要求されたファイルを見つけられるか否かを決定し、
前記要求されたファイルが見つかった場合は、当該ファイルを前記特定の要求側クライアントに戻すステップとを有する方法。
【請求項２】
前記リモート・インデックス・サーバが、インデックス・サーバの前記階層構造内でトップ・レベルにあるルート・インデックス・サーバである、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイル共有アプリケーションに対するインデックス・サーバ・サポートを提供する方法に関する。
【背景技術】
【０００２】
ファイル共有とは、エンドユーザが非常に大規模なリポジトリを作成するためにストレージをプールすることができる手段である。エンドユーザのコンピュータ・デバイス、すなわち一般には記憶容量およびネットワーク・アクセスを提供する電子デバイスは、ファイル共有アプリケーションを実行する際に、他のエンドユーザのコンピュータ・デバイスにその格納されたデータのすべてまたは一部を提供するためのデータ・サーバとして働くことができる。同時に、こうしたコンピュータ・デバイスは他のエンドユーザのコンピュータ・デバイスからのファイルを照会し、接続されたエンドユーザのコンピュータ・デバイスを横切って格納された大規模なデータ・リポジトリへのアクセスを獲得することができる。したがってこのファイル共有アーキテクチャは、専用サーバ・コンピュータのみがコンピュータ・クライアントにアクセスするためのデータを提供する一般的なクライアント／サーバ・システムとは異なる。
【０００３】
それでもなお、ファイル共有アプリケーションを実行するコンピュータ・デバイスは、ファイル共有アプリケーションに対するクライアントであるというその特性によって、以下ではクライアントとも呼ばれる。一般にファイル共有アプリケーションは、ユーザ／コンピュータ・デバイスがファイルの場所を学習し、そのコピーを要求する際の手段が様々である。
【０００４】
ファイル共有アプリケーションの一形態では、中央インデックスが中央インデックス・サーバ上に維持される。このインデックスは、現在どのユーザがアクティブであり、彼らが現在何のファイルを所有しているかを示す。こうした中央インデックスを備えたファイル共有アプリケーションが生み出す規模の節約度は、提供しなければならないストレージおよび帯域幅に関して莫大である。
【０００５】
有効性および回復力の理由で、インデックスは複数のサーバにまたがって分配することができる。各サーバはインデックス全体の一部であるインデックスを維持する。時に、こうしたインデックス・サーバは、情報の関連部分それ自体を所有していない場合に、他のどのインデックス・サーバにアドレス指定するかの参照を有する。こうした１つのインデックス・サーバから他のインデックス・サーバへのリンクは、さらなる情報に関してアドレス指定するための既知のインデックス・サーバが、要求側インデックス・サーバから離れた場所に位置するインデックス・サーバである可能性があること、および同じく要求側クライアントとは物理的に世界の別の場所に位置するクライアントに関する情報を提供する可能性があることから、必ずしも即時ファイル転送を提供するものではない。たとえこうした遠くのリモート・インデックス・サーバが要求された情報を提供し、ダウンロードのために照会されたファイルを与える遠くのリモート・クライアント・アドレスを提供する場合であっても、要求側およびサービス提供側クライアントが互いに遠く離れた場所に位置するため、こうしたダウンロードは長時間かかり、多くのネットワーク・リソースを要求することになる。
【０００６】
米国特許第５９４１９５６号は、複数のコンピュータが複数のコネクタ側のネットワークに接続され、コネクタに対応する複数のアドレス変換装置が提供される、ネットワーク・システムを開示している。各アドレス変換装置では、各アドレス変換装置に対応するネットワーク上の固定アドレスが格納される一方で、各アドレス変換装置に対応する１つのコネクタ側で接続された１つのコンピュータのコンピュータ・アドレスが獲得および格納される。次に、コンピュータ・アドレスで表して与えられた当該１つのコンピュータからネットワークへ伝送されるメッセージに含まれるソース・アドレスが格納済み固定アドレスに変換される一方で、固定アドレスで表して与えられたネットワークから当該１つのコンピュータへ伝送されるメッセージに含まれる宛先アドレスが当該格納済みコンピュータ・アドレスに変換される。
【０００７】
インターネット上の  http://www.itmcenter.com/vendors/radware.htmで検索され２００２年１１月２６日にアクセスされた製品発表では、旧式のクライアント／サーバ・ネットワーク・トポロジ向けのインテリジェント・ロード・バランシングと近接性ベースの地理的宛先変更とを管理する、Ｗｅｂサーバが示されている。ネットワーク・トラフィックは、ネットワークの近接性および実際のロードに従って、サイト間で宛先変更することができる。
【０００８】
インターネット上のhttp://www.newarchitectmag.com/archives/2001/03/francisco/で検索され、２００２年１１月２６日にアクセスされた、モン・フランシスコによる「コンテンツ送達ネットワーク」では、コンテンツ要求を最も適切な場所に向けて送るワイド・エリア・トラフィック・マネージャについて記載している。
【０００９】
インターネット上のhttp://www-106.ibm.com/developerworks/library/webcachinga.htmlで検索され、２００２年１１月２６日付けでアクセスされた、１９９９年９月ローン・ショーによる「Ｗｅｂキャッシュを使用したネットワーク・トラフィックの削減」では、Ｗｅｂページに対するすべての個々の要求を集約し、それらのプロキシとして起点サイトに単一の要求を送信する、Ｗｅｂキャッシュを示している。キャッシュはそのコンテンツのコピーを受け取ると、さらなるコピーを作成してそれらを要求側ユーザに渡す。
【特許文献１】米国特許第５９４１９５６号
【非特許文献１】インターネット上の  http://www.itmcenter.com/vendors/radware.htmで検索され２００２年１１月２６日にアクセスされた製品発表
【非特許文献２】インターネット上のhttp://www.newarchitectmag.com/archives/2001/03/francisco/で検索され、２００２年１１月２６日にアクセスされた、モン・フランシスコによる「コンテンツ送達ネットワーク」
【非特許文献３】インターネット上のhttp://www-106.ibm.com/developerworks/library/webcachinga.htmlで検索され、２００２年１１月２６日付けでアクセスされた、１９９９年９月ローン・ショーによる「Ｗｅｂキャッシュを使用したネットワーク・トラフィックの削減」
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、クライアントが、使用可能な要求されたファイルを有する近くにある他のクライアントから要求されたファイルを取得できるようにする機構を提供することが高く評価される。
【課題を解決するための手段】
【００１１】
本発明の一態様に従って、ファイル共有アプリケーションに対してインデックス・サーバ・サポートを提供するための方法が提供される。ネットワーク内でインデックス・サーバの階層構造を調査するための要求が処理される。リモート・インデックス・サーバに向けて送られる調査要求は遮断される。調査要求の発信者には、遮断を行ったインデックス・サーバの識別情報が通知される。
【００１２】
この方法は、好ましくは、ネットワーク内でファイル共有アプリケーションをサポートするインデックス・サーバによって実行される。
【００１３】
ファイル共有アプリケーションは、通常、コンピュータ・デバイスがデータまたはサービスのサーバおよびクライアントとして動作できるようにするものである。ネットワークを介して他のコンピュータ・デバイスに接続されたコンピュータ・デバイスは、他のリモート・コンピュータ・デバイスにダウンロードのためのファイルの選択を与える。これとは反対に、このコンピュータ・デバイスは、ファイルの使用可能性およびダウンロードを他のコンピュータ・デバイスに要求することができる。周知のクライアント／サーバ・システムとは異なり、ファイル共有アプリケーションのクライアントは、必ずしも既知のデータ・サーバからデータを検索することなく、他のアクティブ・クライアント上に格納されたデータにアクセスすることができる。こうしたファイル共有はアプリケーションによって管理される。既知のファイル共有アプリケーションは、たとえばＧｎｕｔｅｌｌａなどである。
【００１４】
コンピュータ・デバイスは初期にはどこでファイルを探せばよいかがわからないため、ファイル照会クライアント向けのサポートを提供するネットワークをまたがってインストールされたインデックス・サーバが存在する場合がある。インデックス・サーバは、通常、どのクライアントに関するどの情報サービスまたはファイルを検索できるかに関する情報を提供するインデックスを維持する。インデックスは、１つまたは複数のファイルをファイル共有クライアントにマッピングすることができる。マッピングできるのは、現在ダウンロードに使用できるファイルのみである。現在使用可能であるということは、好ましくは、コンピュータ・デバイスがそのリポジトリ内にファイルを格納しており、かつこのファイルへのアクセスを許可しているということだけでなく、それぞれのファイルを即時にダウンロードするために現在アクティブであるということを示す。しかしながらインデックスは、ファイル共有クライアントをファイルまたはサービスにマッピングする準備を整えておくこともできる。インデックスは、一般に、「どこで何を探すか」に関する情報を提供することができる。この種の情報は、提案されたものとは異なる方法で構築または定義されている場合がある。様々なインデックス・サーバには、オーバラップするかまたは部分的に重複する情報が含まれる可能性がある。様々なインデックス・サーバのインデックスがまとまって、使用可能なすべての情報を含むインデックス全体を表す。
【００１５】
特定のファイル共有アプリケーションに対して１つの中央インデックス・サーバ上に１つの中央インデックスを提供する代わりに、本発明の一態様に従って、いくつかのインデックス・サーバを含む基礎となるネットワーク構造を提供し、したがってネットワーク内に分散インデックス・テーブルを提供することが好ましい。こうしたインデックス・サーバは、通常、たとえばインデックス・サーバが関与している数の限定されたコンピュータ・デバイス上でどのデータ・ファイルが使用可能であるかなど、そのインデックス内の情報の選択のみを提供する。
【００１６】
本発明にとって核となるのは、ネットワーク構造の階層を調査する要求がネットワークを介して送られることである。
【００１７】
好ましくはこうした要求の発信者は、ファイルを探す場合に、好ましくはさらなる情報に関してどのインデックス・サーバにアドレス指定するかの調査を希望するエンドユーザのコンピュータ・デバイスである。今後の要求のためにこうした調査されたインデックス・サーバをアドレス指定することがクライアントの意図でない場合、たとえばすべてのクライアントの要求がたとえそれ以外の場所にアドレス指定されている場合であっても、それ自体に宛先変更するなどによって、インデックス・サーバ自体が今後の要求のためにスマートなサポートを確立することができる。
【００１８】
こうした要求の発信者は、特に子または親のインデックス・サーバの場合、インデックス・サーバの階層内で他のインデックス・サーバを探しているインデックス・サーバである場合もある。具体的に言えば、インデックス・サーバが要求された情報をクライアントに提供できない場合、このインデックス・サーバがこのクライアントの要求を、おそらく要求された情報を提供することができる他のインデックス・サーバに転送することが好ましい。
【００１９】
こうした初期の調査要求の宛先は、インデックス・サーバ階層の頂部を構築する周知のルート・インデックス・サーバとするか、または他の既知のインデックス・サーバ、好ましくはインデックス・サーバ階層内で高位のインデックス・サーバである既知の中央インデックス・サーバとすることができる。
【００２０】
インデックス・サーバは、それに対するアクセス権を有するネットワーク・トラフィックを監視する。
監視中のインデックス・サーバにはアドレス指定されていないが、他のインデックス・サーバに向けて送られた調査要求が監視される場合は必ず、この要求は遮断される。一般に、調査要求などのメッセージは、ルータ、ゲートウェイ、および他のネットワーク機器を介してネットワークを横切って最短経路を通って宛先へと転送されるものであるため、こうしたメッセージが検出された場合は必ず、遮断を行ったインデックス・サーバの場所が、調査要求の宛先よりもネットワーク・ホップで表して要求の発信者に近いという強力なヒントである。
【００２１】
調査要求が上記の方法で遮断された場合、遮断された要求の発信者が抽出され、遮断を行ったインデックス・サーバの識別情報を開示する通知がこの発信者に送られる。したがって調査要求の発信者には、発信者と宛先の間に他のインデックス・サーバが配置されていることが通知される。
【００２２】
この通知は、発信者によって、遮断を行ったインデックス・サーバに対して他の要求をアドレス指定するようにというアドバイスとして解釈されるか、または、今後すべての要求をこの特定のインデックス・サーバに向けて送るようにという厳しい規則とみなされる可能性がある。具体的に言えば、その後、ファイルまたは他のコンテンツの照会要求に関する照会要求が、調査された中間インデックス・サーバにアドレス指定される可能性がある。
【００２３】
遮断を行ったインデックス・サーバは、好ましくはそれ自体のアドレスを送ることによって、その識別情報を調査要求の発信者に開示する。加えて、このインデックス・サーバを一意のものとし、さらに要求の発信者が知っている他のすべてのインデックス・サーバと区別できるようにするために、このアドレスをインデックス・サーバの名前または他の追加のインデックス・サーバの特徴に接続することも追加可能である。代替の実施形態では、遮断を行ったインデックス・サーバのアドレスは要求の発信者に送られるが、たとえばルート・インデックス・サーバの名前などの調査要求の宛先にリンクされる。このプロセスが「マスカレード」と呼ばれる。これは、今後の調査要求ならびに照会または他の要求をいったん決定されたルート・インデックス・サーバ識別情報に依然として送信することが可能であり、この識別情報が現在遮断を行ったインデックス・サーバにリンクされているため、メッセージの発信者がそのソフトウェアを変更せずにこの新しい通信プロトコルの下に参加できるようにするものである。
【００２４】
遮断された要求は中間のインデックス・サーバによってドロップされるため、その宛先には転送されない。遮断された要求は、遮断された調査要求に応答して、発信者に通知される前または後にドロップすることができる。
【００２５】
インデックス・サーバに対してこの方法を実行すること、またはこの方法を実行するインデックス・サーバを提供することによって、ファイル共有クライアントは、これまでクライアントは知らなかったが、クライアントにより近いかまたは最も近い場所にあるインデックス・サーバである可能性があり、したがってファイルの転送時間およびネットワーク・リソースを節約するために今後要求を送る魅力がある可能性がある、近くのインデックス・サーバからの通知を喚起することができる。
【００２６】
本発明は、インデックス・サーバの階層構造が望ましい場合はいつでも調査可能であり、インデックス・サーバ上で実施されるプロトコルの形のリソースをほとんど必要としないため、ネットワーク内の様々な場所での非常に柔軟なインデックス・サーバのインストールまたは取り外しをサポートする。
【００２７】
本発明は、クライアントおよびインデックス・サーバが、どのインデックス・サーバを最も良くアドレス指定するかを自己編成することができるため、ファイル共有アプリケーションに自律性を追加するものである。インデックス・サーバは、新しいネットワーク・トポロジに適合するように自己管理することができる。
【００２８】
好ましい実施形態では、遮断された要求がドロップされるため、その宛先には転送されない。その後、遮断を行ったインデックス・サーバは調査メッセージを介して完全なコントロールを得る。別の方法として、遮断された要求をその宛先に転送することができる。その後、宛先への要求の経路上により多くのインデックス・サーバがある場合、要求側クライアントは調査要求に対する複数の回答を受け取ることができる。様々なインデックス・サーバから識別情報メッセージを受け取った後、クライアントは他の手段を使用してどれが最も近いかを判定すること、またはこれらのさらなる通信のうちの１つを選択すること、あるいはその両方が可能である。
【００２９】
本発明のこの態様の好ましい実施形態では、遮断を行ったインデックス・サーバの識別情報は、調査要求の発信者だけでなく、調査要求が最初にアドレス指定されたリモート・インデックス・サーバにも通知される。これは、リモート・インデックス・サーバに、遮断を行ったインデックス・サーバが子インデックス・サーバであることを認識させるのに役立つ。インデックス・サーバ階層で表すと、子インデックス・サーバは親インデックス・サーバよりも少なくとも１レベル下にある。
【００３０】
遮断を行ったインデックス・サーバの識別情報は、たとえば他の要求を子インデックス・サーバとして遮断を行ったインデックス・サーバに向けて送るために、好ましくはリモート・インデックス・サーバ上に格納される。
【００３１】
リモート・インデックス・サーバは、好ましくは通知に応答して遮断を行ったインデックス・サーバに調査要求を送ることができる。こうした調査要求は、遮断を行ったインデックス・サーバとリモート・インデックス・サーバとの間に配置された追加のインデックス・サーバを開示するのに役立つ可能性がある。
【００３２】
好ましい実施形態では、インデックス・サーバそれ自体が親インデックス・サーバに対して上記で説明した動作を示す。インデックス・サーバは、遮断を行ったインデックス・サーバとしてその識別情報を開示する通知がリモート・インデックス・サーバから受け取られた場合、リモート・インデックス・サーバを子インデックス・サーバとして登録する。この特徴は、インデックス・サーバがその環境内の階層レベルを認識するのに役立つ。こうした通知に応答して、インデックス・サーバが今後の照会要求または他の要求をこの登録された子インデックス・サーバに送信または転送することが好ましい。
【００３３】
好ましいことに、リモート・インデックス・サーバに向けて送られる調査要求が遮断されるだけでなく、調査要求は「定期的に」受信者としてこのインデックス・サーバに向けて送られることが容認される。最も近いインデックス・サーバがそのクライアントあるいは子または親のインデックス・サーバに知られていないとは限らないため、調査要求は必ずしも遮断を喚起するわけではないが、その宛先に定期的に伝送することができる。これに応じて、受信側インデックス・サーバは発信者に通知する。
【００３４】
他の好ましい実施形態では、インデックス・サーバは親インデックス・サーバを調査する対策を講じる。したがって、インデックス・サーバは既知のインデックス・サーバに調査要求を送信し、この要求に応答して通知を受信する。
【００３５】
好ましいことに、既知のインデックス・サーバが受信された通知の発信者である場合、既知のインデックス・サーバは親インデックス・サーバとして登録される。
【００３６】
受信された通知の発信者が既知のインデックス・サーバでなく、遮断を行ったインデックス・サーバである場合、受信された通知の発信者は親インデックス・サーバとしても登録可能である。
【００３７】
既知のインデックス・サーバでない受信された通知の発信者を即時に登録する代わりに、新しい調査要求が送信され、今度は受信された通知の発信者に向けて送られる。この新しい調査メッセージに応答してさらなる通知が予測され、この更なる通知が評価される。好ましいことに、このさらなる通知の発信者は親インデックス・サーバとして登録される。しかしながら、このさらなる通知の発信者が新しい調査要求の受信者ではなく、他の遮断を行ったインデックス・サーバである場合、最も近いインデックス・サーバが検出される限り、新しい調査要求はこの遮断を行ったインデックス・サーバなどに送られる場合がある。
【００３８】
親インデックス・サーバ構造を調査する提案された方法は、子インデックス・サーバ構造を調査するために適用することも可能である。調査要求は、何か存在すればパスされるインデックス・サーバによって遮断されるように、既知の下位インデックス・サーバまたは既知のクライアントにアドレス指定することができる。
【００３９】
ネットワーク・トポロジは変化する可能性があり、インデックス・サーバは追加または除去される可能性があるため、親または子インデックス・サーバの調査は、定期的に、たとえば１日ごとに開始されることが好ましい。
【００４０】
調査要求を処理することに加えて、提案された方法または対応するインデックス・サーバあるいはその両方は、好ましくはファイル共有アプリケーションの一部としてファイルを照会するための要求を処理する。照会またはコンテンツ要求に応答して、照会されたファイルを提供することができる登録済みクライアントを見つけるために、インデックス・サーバのインデックスが検索される。通常、このクライアント・アドレスが照会側クライアントに戻される。
【００４１】
照会されたファイルがインデックスに登録されているクライアントに割り振られていない場合、照会は登録済みの子インデックス・サーバに転送される。別の方法として、対応する要求が登録済みの子インデックス・サーバに伝送される。これによって要求側のクライアントを満足させることが可能であり、子インデックス・サーバが親インデックス・サーバに近いことが概して示されるため、アドレス指定された子インデックス・サーバに登録された近くのクライアントからのファイルを提供することができる。
【００４２】
照会されたファイルがインデックスに登録されているクライアントに割り振られていない場合、照会は登録済みの親インデックス・サーバに転送される。別の方法として、対応する要求が登録済みの親インデックス・サーバに伝送される。この実施形態は、照会されたインデックス・サーバがいずれの子インデックス・サーバも認識していない場合、または子インデックス・サーバ内の検索が失敗した場合に好ましい。
【００４３】
以下で紹介される好ましい実施形態の多くによれば、要求を管理するために制御論理がメッセージを送信している。これは制御論理が第１にメッセージを送信することに決めるものと解釈されなければならない一方で、メッセージの物理的伝送は、制御論理によって制御されるかまたは制御論理から転送用のメッセージを受信しているインターフェースによって開始される。
【００４４】
好ましい一実施形態では、インデックス・サーバをスタンド・アロン型電子デバイスとして実施することができる。この実施形態では、データ・パケットの形の調査要求を遮断するために、インデックス・サーバが特定のネットワーク回線にアクセスするための手段を有する。インデックス・サーバの一部としてのフィルタ・ユニットは、遮断を処理することができる。フィルタ・ユニットは、ＴＣＰメッセージのポート・フィールドをチェックすることによって、ファイル共有アプリケーションに関連することを何らかの形で示すメッセージをフィルタリングする。フィルタ・ユニットは、ネットワーク・プロセッサ上で実施されるパケット・フィルタリング論理として具体化することができる。制御ユニットは、フィルタリングされたすべてのファイル共有メッセージの調査要求を抽出することができる。他のファイル共有要求の中から調査要求を検出することも、フィルタ・ユニットによって実施することができる。別の方法として、調査要求はフィルタ・ユニットを使用して検出することもできる。
【００４５】
特に好ましい実施形態では、インデックス・サーバはルータに関連付けられる。インデックス・サーバは、ルータからのネットワーク・トラフィックを、あるいはたとえすでにフィルタリングされたネットワーク・トラフィックであっても、受信または迂回させる別のユニットとすることができる。好ましくは、インデックス・サーバはアクセスおよび低レベル通信（パケット）処理にルータを使用する。上記で示したインデックス・サーバの機能は、ルータの機能と共に１つの単一のインデックス・サーバ／ルータ・ユニットにまとめて実施することもできる。即時アクセスが認められ、パケットはルータを介して主に最短経路で発信者から宛先へと導かれるため、インデックス・サーバをルータに接続することは有利であり、その結果、インデックス・サーバをルータに割り振ることは、クライアントと他のインデックス・サーバとの間のインデックス・サーバの場所を少なくとも大まかに決定することである。
【００４９】
本発明の異なるすべての態様および実施形態の利点は、前述の本発明の方法およびその実施形態の利点に付随するものである。
【００５０】
本発明およびその実施形態は、本発明に従った現時点で好ましいが例示的な実施形態についての以下の詳細な説明を添付の図面と併せて参照することによって、より完全に理解されるであろう。
【００５１】
異なる図面が、同様のまたは均一のコンテンツを備えた要素を表す同一の参照番号を含む場合がある。
【発明を実施するための最良の形態】
【００５２】
図１は、本発明の一実施形態に従ったインデックス・サーバを含むネットワークを示す概略図である。図１は、階層構造を認識しているクライアントおよびインデックス・サーバを含む、確立されたネットワークを示す。階層構造は、図２から４および対応する仕様に従って調査される。
【００５３】
図１では、移動電話、ＰＤＡ、ラップトップ、または他のデバイスを含むコンピュータ・デバイスとして実現可能なクライアントＣ１０〜Ｃ１２、Ｃ２０〜Ｃ２２、Ｃ３０〜Ｃ３２が、ファイル共有デバイスでは典型的なようにネットワークの「縁部」に配置される。これらはネットワークへのアクセスを有するが、Ｗｅｂサーバからデータを検索するためだけではなく、使用可能な他のクライアント上にファイルを格納させ、次にネットワークの「縁部」にある他のクライアントが使用可能な示されたクライアント上にファイルを格納させる、ファイル共有アプリケーションを実行するためでもある。
【００５４】
ルータＲＴ１〜ＲＴ６は、ネットワークを介してその宛先にトラフィックを転送するために構成される。
【００５５】
たとえば特定のファイル共有アプリケーションの中核情報をホストする、ルート・サーバＲが導入される。ルート・サーバ・アドレスは、たとえばファイル共有アプリケーションに関与するためにファイル共有ソフトウェアをダウンロードするためなど、クライアントが最初にルート・サーバにアクセスする場合に、クライアント側で格納することができる。
【００５６】
いくつかのインデックス・サーバＩ１〜Ｉ４が提供され、そのそれぞれが特定のルータＲＴ２からＲＴ５に結合される。しかしながらインデックス・サーバは通常、ネットワークをまたがってルータの密度を示さないため、すなわちＲＴ１およびＲＴ６など、すべてのルータがインデックス・サーバに結合されるというわけではない。
【００５７】
図１からわかるように、クライアントＣｘｙとルート・サーバＲとの間のインデックス・ルータのセットアップは、ツリー状に編成される。したがって、「ネットワーク距離」の意味で互いに近いすべてのクライアントＣｘｙが、同じインデックス・サーバに登録している。図１によれば、クライアントＣ１０、Ｃ１１、Ｃ１２に最も近いインデックス・サーバはインデックス・サーバＩ１であり、クライアントＣ２０、Ｃ２１、Ｃ２２に最も近いインデックス・サーバはインデックス・サーバＩ２である、と言う具合である。加えて、インデックス・サーバは好ましくはクライアントと最も近いそれらの共用可能ファイルとに関する情報を提供する。したがって、インデックスそれ自体は複数のインデックス・サーバにまたがって分配される。たとえばインデックス・サーバＩ１は、好ましくはクライアントＣ１０〜Ｃ１２に関する情報を含むインデックスを維持する。したがってインデックスの分配は、対応するファイルが常駐する場所に強く関連付けられる。
【００５８】
コンテンツ／ファイルを照会するための要求は、第１にこのローカル範囲内で処理される。インデックス・サーバそれ自体は、階層内の相対的近さがネットワーク近さに対応するように、階層にまとめられる。
【００５９】
図１に従ってクライアントＣ１０がネットワーク内のファイルを要求する場合、クライアントＣ１０はインデックス・サーバＩ１が最も近いインデックス・サーバであると認識しているため、第１のインデックス・サーバＩ１が問い合わせられる。インデックス・サーバＩ１がそのインデックス内でこのファイルを見つけられない場合、すなわちクライアントＣ１１またはＣ１２のいずれもこのファイルを提供していない場合、すべての子インデックス・サーバ、すなわち図１によればインデックス・サーバＩ２に問い合わせることになる。インデックス・サーバＩ２のインデックスでもこのファイルが見つからない場合、インデックス・サーバＩ１はその親インデックス・サーバＩ４に問い合わせて、これが、要求側インデックス・サーバであるＩ１を除くすべての子インデックス・サーバにこの要求を転送することになる。ファイルが見つかるまで、またはファイルが存在しないと判定されるまで、これが続けられる。ファイルが見つかった場合、ファイルの最も近いインスタンスがクライアントＣ１０に戻される。
【００６０】
図１に従ったこうした階層に関する近さを自己編成する方法について、図２から４を使って説明する。
【００６１】
図２、３、４はそれぞれ、本発明の一実施形態に従って、図１に従ったネットワークにおいてインデックス・サーバの階層構造を調査する方法を示す図である。
【００６２】
これらの図で使用される矢印は、ネットワークをまたがって送られるメッセージを示す。各矢印には、メッセージのタイプとそれに続くメッセージの発信者、およびコロンの後にメッセージの受信者（宛先）とを示すタグがラベル付けされている。
【００６３】
クライアントは活動化されると、それ自体の場所に最も近いインデックス・サーバの調査を試行する。こうしたインデックス・サーバは、既知のインデックス・サーバに向けて送られる調査要求によって検出することができる。この調査要求が渡されるインデックス・サーバは、おそらく少なくとも既知のインデックス・サーバよりもクライアントに近い。したがって図１によれば、監視された場合にこうした調査要求を遮断するために、本発明の一態様に従ってすべてのインデックス・サーバＩ１〜Ｉ４に制御論理が提供される。
【００６４】
図２から見ていくと、地理的近さに基づいてインデックス・サーバ階層を自己編成するための第１のステップが導入される。クライアントＣ１０が活動化され、クライアントＣ１０がアドレスを知っているルート・サーバＲに調査要求ＩＲを送信する。この調査要求ＩＲは、ルート・インデックス・サーバＲへの経路上にあるインデックス・サーバを喚起する（ｐｒｏｖｏｋｅ  ｅｘｃｌａｍａｔｉｏｎｓ）ものであるため、「ルート・サーバＲと対話する場合は誰と対話しなければならないか」または「どのようにしてルート・サーバＲに到達すべきであるか」という調査内容を伴うメッセージとして解釈することができる。
【００６５】
このクライアントＣ１０からの調査要求ＩＲはルータＲＴ１からルータＲＴ２に向けて送られ、トラフィックがルータＲＴ２からインデックス・サーバＩ１へと迂回しているため、インデックス・サーバＩ１へと転送される。インデックス・サーバＩ１は、以前にはクライアントＣ１０に認識されていなかったものである。インデックス・サーバＩ１は、ルート・サーバＲに向けて送られた調査要求ＩＲを遮断しており、この要求をドロップする。調査要求ＩＲが遮断されたことに応答して、インデックス・サーバＩ１はその識別情報を開示する通知ＮＴをクライアントＣ１０に送信する。この通知ＮＴは、「ルート・サーバＲと対話するためには、インデックス・サーバＩ１と対話しなければならない」という内容を有するものとも解釈できる。クライアントＣ１０は、この識別情報を、このファイル共有アプリケーションの下でファイルを探す場合にアドレス指定するインデックス・サーバとして格納している。
【００６６】
インデックス・サーバＩ１を最も近いインデックス・サーバとして即時に登録する代わりに、クライアントＣ１０は、クライアントＣ１０とインデックス・サーバＩ１との間に他のインデックス・サーバが配置されているかどうかをチェックするためにインデックス・サーバＩ１に対して新しい調査要求を発行することができる。これは、初期にルート・クライアントＲへの調査メッセージが、よりローカルな宛先にアドレス指定されたメッセージが取るであろう経路とは別の経路を取った場合に可能である。
【００６７】
クライアントＣ１０、Ｃ１１、Ｃ１２のすべてが、それ相応に処理される調査要求ＩＲを伝送すると考えられる。
【００６８】
インデックス・サーバＩ１は、同じ方法でその親インデックス・サーバを調査する。調査要求ＩＲは、インデックス・サーバＩ１から既知のルート・インデックス・サーバＲに向けて送られ、インデックス・サーバＩ４によって遮断される。インデックス・サーバＩ４は遮断された要求をドロップし、その識別情報をインデックス・サーバＩ１に通知する。その後インデックス・サーバＩ１は、新しい別の調査要求を上記で述べた理由でインデックス・サーバＩ４に向けて送るか、またはインデックス・サーバＩ４を親インデックス・サーバとして即時に登録することができる。図２には、インデックス・サーバＩ１に関連してテーブルが示されており、このリストでは親インデックス・サーバＰｘにインデックス・サーバＩ４が掲載され、これまでのところ子インデックス・サーバはないため子インデックス・サーバＣｘは掲載されていない。
【００６９】
インデックス・サーバＩ４は、同じ方法でその親インデックス・サーバを調査する。調査要求ＩＲは、インデックス・サーバＩ４から既知のルート・インデックス・サーバＲに向けて送られる。インデックス・サーバＩ４とルート・インデックス・サーバＲとの間には中間インデックス・サーバがないため、インデックス・サーバＲはどのようなネットワーク・トラフィックの遮断もなしに、ただし正規の受信者としてこの調査要求を受信し、その識別情報を承認する通知ＮＴをインデックス・サーバＩ４に返送する。このようにしてインデックス・サーバＩ４は、ルート・インデックス・サーバＲを対応するインデックスにおける親インデックス・サーバとして登録する。加えてインデックス・サーバＩ４は、インデックス・サーバＩ１によって送信された調査要求を遮断したことから、または図２の破線矢印で示されたＩ１からの別の通知によって、子インデックス・サーバＩ１を認識する。インデックス・サーバＩ１は、その子インデックス・サーバの存在もルート・インデックス・サーバＲに示すことができる。
【００７０】
これまでに図２に関連して説明した自己編成プロセスは、クライアントＣ１０〜Ｃ１２が最も近いインデックス・サーバを調査することで始まったが、ほとんどのアプリケーションでは、インデックス・サーバは最初に、好ましくはネットワーク状態において修正があればこれを考慮に入れるために定期的に、階層構造を調査することになる。クライアントは、クライアントそれ自体が活動化されるか、またはクライアント上のファイル共有アプリケーションが活動化された後に、最も近いインデックス・サーバを調査することになる。
【００７１】
図３は、インデックス・サーバＩ２が親インデックス・サーバとしてインデックス・サーバＩ１を検出する間に、クライアントＣ２０〜Ｃ２２がそれらの親インデックス・サーバＩ２を調査する方法を示す図である。インデックス・サーバＩ１はすでに親インデックス・サーバＩ４を認識している（図２）。したがって、実際にはインデックス・サーバＩ１に関してそれ以上の調査を行う必要がない。
【００７２】
図４は、インデックス・サーバＩ３が親インデックス・サーバとしてインデックス・サーバＩ４を検出している間に、クライアントＣ３０〜Ｃ３２がそれらの親インデックス・サーバＩ３を調査する方法を示す図である。インデックス・サーバＩ４はすでにルート・インデックス・サーバＲを認識している（図２）。したがって、実際にはインデックス・サーバＩ４に関してそれ以上の調査を行う必要がない。
【００７３】
クライアントはそれらの親インデックス・サーバを調査した場合、通常、この親インデックス・サーバに向けてコンテンツ照会を送る。しかしながら代替の実施形態では、それぞれのクライアントからのコンテンツ要求は依然としてたとえば既知のルート・サーバに向けて送られる。その後このトラフィックは遮断され、親サーバから対応するルータに対してそのように実行するようにというアドバイスがあるため、代わりに親サーバに向けて送られる。この実施形態は、インデックス・サーバがルータに結合されている場合に特に好ましい。その後、たとえばファイル共有要求に関してルート・サーバがデフォルト時のアドレスである場合、クライアントが宛先を修正する必要はない。
【００７４】
宛先変更コマンドは、ＯＳＰＦまたはＳＮＭＰなどの標準プロトコルを使用して実施することができる。インデックス・サーバそれ自体がネットワーク回線へのアクセスを有する場合、インデックス・サーバそれ自体がすべてのデータ・パケットを転送し、関連するデータ・パケットを抽出することができる。
【００７５】
初期化プロトコルはＵＤＰを使用して実行されることが好ましい。この場合、調査要求および対応する回答通知はＵＤＰデータグラムとして送信される。
【００７６】
既存のインデックスに基づくファイル共有プロトコルはＨＴＴＰ／ＴＣＰを使用することが可能であり、この場合、本発明に従うインデックス・サーバはＴＣＰ  ＳＹＮメッセージを遮断して、クライアントに対するルート・インデックス・サーバとしてＴＣＰ接続マスカレードを作成し、その後インデックス・サーバの専用アドレスへのＨＴＴＰ宛先変更を使用してクライアントを宛先変更することができる。
【図面の簡単な説明】
【００７７】
【図１】本発明の一実施形態に従ったインデックス・サーバを含むネットワークを示す概略図である。
【図２】本発明の一実施形態に従って、図１に従ったネットワークにおいてインデックス・サーバの階層構造を調査する方法を示す図である。
【図３】本発明の一実施形態に従って、図１に従ったネットワークにおいてインデックス・サーバの階層構造を調査する方法を示す図である。
【図４】本発明の一実施形態に従って、図１に従ったネットワークにおいてインデックス・サーバの階層構造を調査する方法を示す図である。
【図１】
0004437956.tif 000002
【図２】
0004437956.tif 000003
【図３】
0004437956.tif 000004
【図４】
0004437956.tif 000005