JP2004064284A

JP2004064284A - Ｐ２ｐネットワークのトラヒック制御方法及び装置並びにプログラム及び記録媒体

Info

Publication number: JP2004064284A
Application number: JP2002218065A
Authority: JP
Inventors: Masato Uchida; 内田　真人; Shinya Nogami; 能上　慎也
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2002-07-26
Filing date: 2002-07-26
Publication date: 2004-02-26
Anticipated expiration: 2022-07-26
Also published as: JP3806072B2

Abstract

【課題】本発明はＧｎｕｔｅｌｌａのようなアプリケーションプログラムによるトラヒックが流れるＰ２Ｐネットワークにおいて、管理用のサーバを設置することなくトラヒックの集中を抑制することが可能なＰ２Ｐネットワークのトラヒック制御方法及び装置並びにプログラムを提供することを目的とする。
【解決手段】複数の端末が接続され全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するためのＰ２Ｐネットワークのトラヒック制御方法であって、各端末が、他の端末からのファイル検索要求に対して自端末の検索結果のヒット状況を監視し、前記ヒット状況に応じて各端末が自律分散的にトラヒックを制御することを特徴とするＰ２Ｐネットワークのトラヒック制御方法。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、Ｐ２Ｐ（ピア・ツー・ピア）型のネットワークに用いられるＰ２Ｐネットワークのトラヒック制御方法及び装置並びにプログラムに関する。
【０００２】
【従来の技術】
最近注目を集めているＰ２Ｐ型のネットワークは、従来のクライアント・サーバ（Ｃ／Ｓ）型のネットワークとは異なり、特定のサーバに頼ることなくコンピュータ資源やサービスをシステム間で直接共有する。
例えば、端末同士の間で音楽などのファイルを交換するためのＰ２Ｐ型のネットワークを構成するプログラムとして、従来より「Ｎａｐｓｔｅｒ」が知られている。しかし、「Ｎａｐｓｔｅｒ」のようなネットワークにおいては、ファイル検索の機能を備えるサーバが接続され、各端末はサーバの制御により動作する。従って、このネットワークではトラヒックはサーバによって集中的に制御される。
【０００３】
つまり、「Ｎａｐｓｔｅｒ」のようなネットワークは純粋なＰ２Ｐネットワークではなく、管理用のサーバを設けることが不可欠である。
一方、管理用のサーバが不要な純粋なＰ２Ｐネットワークの代表例として、「Ｇｎｕｔｅｌｌａ」と呼ばれるソフトウェアを用いたネットワークが知られている。「Ｇｎｕｔｅｌｌａ」のようなネットワークにおいては、各端末はサーバントと呼ばれ、ファイル検索などの機能を備えている。
【０００４】
【発明が解決しようとする課題】
「Ｇｎｕｔｅｌｌａ」のようなＰ２Ｐネットワークにおいては、ネットワーク全体を管理するサーバが存在しないので、集中的にトラヒックの制御を行うことができない。
このため、特定の端末などにトラヒックが集中してネットワーク上で輻輳が発生し、効率的なファイル転送ができなくなる可能性がある。
【０００５】
本発明は、「Ｇｎｕｔｅｌｌａ」のようなアプリケーションプログラムによるトラヒックが流れるＰ２Ｐネットワークにおいて、管理用のサーバを設置することなくトラヒックの集中を抑制することが可能なＰ２Ｐネットワークのトラヒック制御方法及び装置並びにプログラムを提供することを目的とする。
【０００６】
【課題を解決するための手段】
請求項１は、複数の端末が接続され、全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するためのＰ２Ｐネットワークのトラヒック制御方法であって、各端末が、他の端末からのファイル検索要求に対する自端末の検索結果のヒット状況を監視し、前記ヒット状況に応じて各端末が自律分散的にトラヒックを制御することを特徴とする。
【０００７】
「Ｇｎｕｔｅｌｌａ」のようなＰ２Ｐネットワークにおいては、例えば第１の端末はそれが必要とするファイルについて、ネットワークを介して第２の端末に検索を要求する。目的のファイルが第２の端末に存在する場合には、検索にヒットする。その場合、第１の端末からのダウンロード要求に対して第２の端末は目的のファイルを送信する。
【０００８】
従って、例えば第２の端末上で検索のヒット率が高くなると、ファイル転送などの頻度が高くなり、第２の端末を通るトラヒックが増大する。
請求項１においては、検索結果のヒット状況に応じて各端末が自律分散的にトラヒックを制御するので、ある端末あるいはネットワーク上の特定位置にトラヒックが集中するのを抑制することができる。従って、トラヒックを制御するためのサーバを設ける必要がない。
【０００９】
請求項２は、請求項１のＰ２Ｐネットワークのトラヒック制御方法において、他の端末からのファイル検索要求に対する自端末の検索結果について、各端末がファイル毎にヒット数を管理し、各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から他の端末に対して転送し、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した他の端末を利用してファイルの送信を行うことを特徴とする。
【００１０】
請求項２においては、例えば第２の端末上で検索のヒット率が増大した場合、ヒット率の大きいファイルが、例えば第３の端末に転送される。従って、ヒット率の大きいファイルのダウンロードを第１の端末が要求した場合には、第２の端末の代わりに同じファイルを取得した第３の端末から第１の端末に対してファイルを送信することができる。
【００１１】
すなわち、第２の端末と第３の端末とが協調的に連携することにより、第２の端末を通るトラヒックの一部を、第３の端末を通る経路に分散させることができる。
請求項３は、請求項１のＰ２Ｐネットワークのトラヒック制御方法において、ネットワークに所定のキャッシュサーバが接続されている場合には、各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から前記キャッシュサーバに対して転送し、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得したキャッシュサーバを利用してファイルの送信を行うことを特徴とする。
【００１２】
請求項３においては、例えば第２の端末上で検索のヒット率が増大した場合、ヒット率の大きいファイルが、キャッシュサーバに転送される。従って、ヒット率の大きいファイルのダウンロードを第１の端末が要求した場合には、第２の端末の代わりに同じファイルを取得したキャッシュサーバから第１の端末に対してファイルを送信することができる。
【００１３】
すなわち、第２の端末とキャッシュサーバとが協調的に連携することにより、第２の端末を通るトラヒックの一部を、キャッシュサーバを通る経路にに分散させることができる。
請求項４は、請求項１のＰ２Ｐネットワークのトラヒック制御方法において、各端末が、自端末からファイルをダウンロードした他の端末とそれが取得したファイルとの対応関係を履歴情報として保持し、各端末におけるファイルのヒット数が所定以上に増加した場合に、前記履歴情報を参照して該当する同一のファイルを保持する他の端末を連携端末として決定し、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した前記連携端末を利用してファイルの送信を行うことを特徴とする。
【００１４】
請求項４においては、各端末に履歴情報が保持される。この履歴情報を参照することにより、自端末から特定のファイルを既にダウンロードした他の端末（連携端末）を特定することができる。
従って、ヒット率の大きいファイルのダウンロードを第１の端末が要求した場合には、第２の端末の代わりに同じファイルを既にダウンロードした連携端末から第１の端末に対してファイルを送信することができる。
【００１５】
すなわち、第２の端末と連携端末とが協調的に連携することにより、第２の端末を通るトラヒックの一部を、連携端末を通る経路に分散させることができる。請求項５は、複数の端末が接続され、全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するためのＰ２Ｐネットワークのトラヒック制御装置であって、各端末において他の端末からのファイル検索要求に対する自端末の検索結果のヒット状況を監視するヒット状況監視手段と、前記ヒット状況監視手段が検出したヒット状況に応じて、各端末が自律分散的にトラヒックを制御するためのトラヒック制御手段とを設けたことを特徴とする。
【００１６】
請求項５においては、請求項１と同様な制御を実現できる。
請求項６は、請求項５のＰ２Ｐネットワークのトラヒック制御装置において、他の端末からのファイル検索要求に対する自端末の検索結果について、ファイル毎にヒット数を管理するヒット数管理手段と、各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から他の端末に対して転送するファイルアップロード手段とを更に設け、前記トラヒック制御手段は少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した他の端末を利用してファイルの送信を行うことを特徴とする。
【００１７】
請求項６においては、請求項２と同様な制御を実現できる。
請求項７は、請求項５のＰ２Ｐネットワークのトラヒック制御装置において、ネットワークに所定のキャッシュサーバが接続されている場合に、各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から前記キャッシュサーバに対して転送するファイルアップロード手段を更に設け、前記トラヒック制御手段は、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得したキャッシュサーバを利用してファイルの送信を行うことを特徴とする。
【００１８】
請求項７においては、請求項３と同様な制御を実現できる。
請求項８は、請求項５のＰ２Ｐネットワークのトラヒック制御装置において、各端末に、自端末からファイルをダウンロードした他の端末とそれが取得したファイルとの対応関係を履歴情報として保持する履歴情報保持手段と、各端末におけるファイルのヒット数が所定以上に増加した場合に、前記履歴情報を参照して該当する同一のファイルを保持する他の端末を連携端末として決定する連携端末決定手段とを更に設け、前記トラヒック制御手段は、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した前記連携端末を利用してファイルの送信を行うことを特徴とする。
【００１９】
請求項８においては、請求項４と同様な制御を実現できる。
請求項９は、請求項５のＰ２Ｐネットワークのトラヒック制御装置において、自律分散制御を実現するプログラム並びに各端末における検索ヒット状況及びダウンロード状況の少なくとも一方を含むトラヒック情報をネットワークに流通させるための情報流通手段を更に設けたことを特徴とする。
【００２０】
請求項９においては、プログラムやトラヒック情報をネットワーク上の各端末の間で流通させることができる。従って、より効率的なトラヒック制御が可能になる。
請求項１０は、複数の端末が接続され、全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するための、各端末上のコンピュータで実行可能なプログラムであって、各端末において他の端末からのファイル検索要求に対する自端末の検索結果のヒット状況を監視するヒット状況監視手順と、前記ヒット状況監視手段が検出したヒット状況に応じて、各端末が自律分散的にトラヒックを制御するためのトラヒック制御手順とを設けたことを特徴とする。
【００２１】
請求項１０のプログラムを各端末上のコンピュータで実行することにより、請求項１と同様の制御が実現する。
請求項１１は、請求項１０のプログラムにおいて、他の端末からのファイル検索要求に対する自端末の検索結果について、ファイル毎にヒット数を管理するヒット数管理手順と、各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から他の端末に対して転送するファイルアップロード手順とを更に設け、前記トラヒック制御手順では少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した他の端末を利用してファイルの送信を行うことを特徴とする。
【００２２】
請求項１１のプログラムを各端末上のコンピュータで実行することにより、請求項２と同様の制御が実現する。
請求項１２は、請求項１０のプログラムにおいて、ネットワークに所定のキャッシュサーバが接続されている場合に、各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から前記キャッシュサーバに対して転送するファイルアップロード手順を更に設け、前記トラヒック制御手順では、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得したキャッシュサーバを利用してファイルの送信を行うことを特徴とする。
【００２３】
請求項１２のプログラムを各端末上のコンピュータで実行することにより、請求項３と同様の制御が実現する。
請求項１３は、請求項１０のプログラムにおいて、各端末に、自端末からファイルをダウンロードした他の端末とそれが取得したファイルとの対応関係を履歴情報として保持する履歴情報保持手順と、各端末におけるファイルのヒット数が所定以上に増加した場合に、前記履歴情報を参照して該当する同一のファイルを保持する他の端末を連携端末として決定する連携端末決定手順とを更に設け、前記トラヒック制御手順では、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した前記連携端末を利用してファイルの送信を行うことを特徴とする。
【００２４】
請求項１３のプログラムを各端末上のコンピュータで実行することにより、請求項４と同様の制御が実現する。
請求項１４は、請求項１０，請求項１１，請求項１２及び請求項１３のいずれかのプログラムを記録したコンピュータで読み取り可能な記録媒体である。
【００２５】
請求項１４の記録媒体から読み出したプログラムを各端末上のコンピュータで実行することにより、請求項１〜請求項４と同様の制御が実現する。
【００２６】
【発明の実施の形態】
（第１の実施の形態）
本発明のＰ２Ｐネットワークのトラヒック制御方法及び装置並びにプログラム及び記録媒体の１つの実施の形態について、図１，図２及び図７を参照して説明する。この形態は、請求項１，請求項２，請求項５，請求項６，請求項９，請求項１０，請求項１１及び請求項１４に対応する。
【００２７】
図１はこの形態の端末の動作を示すフローチャートである。図２はこの形態の端末の主要部の構成を示すブロック図である。図７はシステム全体の構成例を示すブロック図である。
この形態では、請求項５のヒット状況監視手段は検索ヒット状況監視部１２に対応し、請求項５のトラヒック制御手段はファイルアップロード処理部１５及び連携ダウンロード要求処理部１６に対応する。また、請求項６のヒット数管理手段及びファイルアップロード手段は、高ヒットファイル検索部１４及びファイルアップロード処理部１５に対応する。また、請求項９の情報流通手段はサポートセンタ１００に対応する。
【００２８】
この形態では、例えば図７に示すように、複数の端末（Ｐ２Ｐ端末５０）がネットワーク（例えばインターネット）を介して互いに接続され、各端末が「Ｇｕｎｔｅｌｌａ」型のアプリケーションプログラムを搭載し、Ｐ２Ｐネットワークが形成されている場合を想定している。また、この例ではキャッシュサーバがネットワーク上に存在しない場合を想定している。
【００２９】
図７に示すサポートセンタ１００においては、制御プログラムの作成やトラヒック情報の集計を行う。Ｐ２Ｐネットワークに接続された各Ｐ２Ｐ端末５０は、サポートセンタ１００のサーバから制御プログラムをダウンロードしたり、Ｐ２Ｐネットワーク内の検索ヒット状況やダウンロード状況などのトラヒック情報を閲覧することができる。なお、サポートセンタ１００を省略することもできる。
【００３０】
この形態では、各端末は図２に示すように検索処理部１１，検索ヒット状況監視部１２，閾値超過監視部１３，高ヒットファイル検索部１４，ファイルアップロード処理部１５，連携ダウンロード要求処理部１６，検索結果ＤＢ（データベース）１７及び通信インタフェース１８を備えている。
なお、これらの各構成要素は、専用のハードウェアを用いて構成することもできるし、各機能を実現するプログラムとそれを実行する制御用のコンピュータとで構成することもできる。
【００３１】
検索処理部１１は、その端末上に保持されている多数のファイルの中から、他の端末から検索要求された条件に適合する目的のファイルの検索を行う。この検索の結果、一致するファイルが見つかったかどうかを表すヒット数が、ファイル毎に検索結果ＤＢ１７に書き込まれ保持される。
また、検索ヒット状況監視部１２は、検索処理部１１における全ての検索要求に対する単位時間あたりの検索ヒット数ｈを監視する。
【００３２】
閾値超過監視部１３は、検索ヒット状況監視部１２の検出した検索ヒット数ｈを予め定めた閾値ｓと比較する。比較の結果、検索ヒット数ｈが閾値ｓを超過すると閾値超過監視部１３は高ヒットファイル検索部１４に対して所定の指示を与える。
高ヒットファイル検索部１４は、閾値超過監視部１３からの指示を受けると、検索結果ＤＢ１７の内容を参照して各ファイルの検索ヒット数（トータルのヒット数又は単位時間あたりのヒット数）を調べ、検索ヒット数の大きい１つ以上のファイルを選択する。
【００３３】
ファイルアップロード処理部１５は、高ヒットファイル検索部１４が選択した検索ヒット数の大きいファイルを、他の端末に向けて転送（アップロード）する。転送先の他の端末については、次のようにして決定する。
転送先の候補としてｎ個の他の端末を予め決定しその情報を自端末上に保持しておく。そして、ｎ個の他の端末の中からｍ個の端末を選択し（ｎ≧ｍ）転送先とする。
【００３４】
また、ｎ個の端末の中からｍ個の端末を選択する方法については、例えば公知のラウンドロビンやランダム選択の技術を用いればよい。
連携ダウンロード要求処理部１６は、ファイル検索要求元である他の端末（検索要求発出端末）が必要とする特定のファイルについて、ファイル検索要求元からのファイルダウンロード要求を処理する。
【００３５】
すなわち、要求元の端末に対して目的のファイルを転送する。但し、ファイルの転送元は自端末とは限らない。つまり、目的のファイルはファイルアップロード処理部１５が事前にアップロードを行った他の端末（連携端末）上にも存在するので、自端末は利用可能な連携端末と協調及び連携してファイルダウンロード要求を処理する。これにより、ファイルのダウンロードに伴って発生するトラヒックを他の連携端末に分散させることができる。
【００３６】
図２に示す端末の動作（自端末における動作）の概略は図１に示すとおりである。
図１のステップＳ１１では、検索ヒット状況監視部１２の制御により自端末における検索ヒット状況を監視する。
ステップＳ１２では、閾値超過監視部１３の制御により、単位時間あたりの検索ヒット数ｈと予め定めた閾値ｓとを比較する。そして（ｈ＞ｓ）になった場合には次のステップＳ１３に進む。
【００３７】
ステップＳ１３では、高ヒットファイル検索部１４の制御により検索ヒット数が多いファイルを選択し、選択したファイルをファイルアップロード処理部１５の制御により他の端末にアップロード（転送）する。
ステップＳ１４では、連携ダウンロード要求処理部１６の制御により、他の端末からのダウンロード要求を処理し、ダウンロードを要求されたファイルをアップロードした他の連携端末と連携して、目的のファイルを要求元の端末に転送する。
【００３８】
例えば、自端末の他に１つの連携端末が利用できる場合には、該当するファイルを前記連携端末にアップロードした後で、自端末と前記連携端末とがそれぞれ（ｆ／２）個の検索要求発出端末からのダウンロード要求の処理を担当する（ｆ：目的のファイルに対する検索ヒット数）。これにより、自端末と前記連携端末との２台が連携してダウンロード要求を分散処理することができる。
【００３９】
（第２の実施の形態）
本発明のＰ２Ｐネットワークのトラヒック制御方法及び装置並びにプログラム及び記録媒体のもう１つの実施の形態について、図３及び図４を参照して説明する。この形態は、請求項３，請求項７及び請求項１２に対応する。
図３はこの形態の端末の動作を示すフローチャートである。図４はこの形態の端末の主要部の構成を示すブロック図である。この形態は、第１の実施の形態の変形例である。また、図４において第１の実施の形態と対応する要素は同一の符号を付けて示してある。第１の実施の形態と同じ部分については以下の説明を省略する。
【００４０】
この形態では、請求項７のファイルアップロード手段及びトラヒック制御手段は、それぞれファイルアップロード処理部２１及び連携ダウンロード要求処理部２２に対応する。
この形態では、ネットワーク上のある場所にｎ個のキャッシュサーバが予め分散的に配置されている場合を想定している。従って、この形態ではキャッシュサーバも利用する。なお、キャッシュサーバは端末に代わってファイルを転送するための機能を備えるが、ネットワークを制御するような機能は含まれていない。
【００４１】
この形態の各端末は、図４に示すように検索処理部１１，検索ヒット状況監視部１２，閾値超過監視部１３，高ヒットファイル検索部１４，検索結果ＤＢ１７，通信インタフェース１８，ファイルアップロード処理部２１及び連携ダウンロード要求処理部２２を備えている。
ファイルアップロード処理部２１は、前述のように（ｈ＞ｓ）になった場合に、高ヒットファイル検索部１４が選択した検索ヒット数の大きいファイルを、ｍ個のキャッシュサーバに対して転送（アップロード）する。転送先のキャッシュサーバについては、次のようにして決定する。
【００４２】
ｎ個のキャッシュサーバのアドレスなどの情報は自端末上に予め保持しておく。そして、ｎ個のキャッシュサーバの中からｍ個の端末を選択し（ｎ≧ｍ）転送先とする。
また、ｎ個のキャッシュサーバの中からｍ個のキャッシュサーバを選択する方法については、例えば公知のラウンドロビン，やランダム選択，低負荷サーバ選択（各キャッシュサーバとの情報のやりとりが必要）などの技術を用いればよい。
【００４３】
連携ダウンロード要求処理部２２は、ファイル検索要求元である他の端末が必要とする特定のファイルについて、ファイル検索要求元からのファイルダウンロード要求を処理する。
すなわち、要求元の端末に対して目的のファイルを転送する。但し、ファイルの転送元は自端末とは限らない。つまり、目的のファイルはファイルアップロード処理部２１が事前にアップロードを行った特定のキャッシュサーバ上にも存在するので、自端末は利用可能なキャッシュサーバと協調及び連携してファイルダウンロード要求を処理する。これにより、ファイルのダウンロードに伴って発生するトラヒックをキャッシュサーバに分散させることができる。
【００４４】
図４に示す端末の動作（自端末における動作）の概略は図３に示すとおりである。
図３のステップＳ２１では、検索ヒット状況監視部１２の制御により自端末における検索ヒット状況を監視する。
ステップＳ２２では、閾値超過監視部１３の制御により、単位時間あたりの検索ヒット数ｈと予め定めた閾値ｓとを比較する。そして（ｈ＞ｓ）になった場合には次のステップＳ２３に進む。
【００４５】
ステップＳ２３では、高ヒットファイル検索部１４の制御により検索ヒット数が多いファイルを選択し、選択したファイルをファイルアップロード処理部２１の制御によりｍ個のキャッシュサーバにアップロード（転送）する。
ステップＳ２４では、連携ダウンロード要求処理部２２の制御により、他の端末からのダウンロード要求を処理し、ダウンロードを要求されたファイルをアップロードしたキャッシュサーバと連携して、目的のファイルを要求元の端末に転送する。
【００４６】
（第３の実施の形態）
本発明のＰ２Ｐネットワークのトラヒック制御方法及び装置並びにプログラム及び記録媒体のもう１つの実施の形態について、図５及び図６を参照して説明する。この形態は、請求項４，請求項８及び請求項１３に対応する。
図５はこの形態の端末の動作を示すフローチャートである。図６はこの形態の端末の主要部の構成を示すブロック図である。この形態は、第１の実施の形態の変形例である。また、図６において第１の実施の形態と対応する要素は同一の符号を付けて示してある。第１の実施の形態と同じ部分については以下の説明を省略する。
【００４７】
この形態では、請求項８の履歴情報保持手段，連携端末決定手段及びトラヒック制御手段は、それぞれダウンロード履歴ＤＢ３３，ダウンロード済み端末検索部３１及び連携ダウンロード要求処理部３４に対応する。
【００４８】
第１の実施の形態では、自端末の決定した連携端末に対してファイルのアップロードを行っているが、この形態ではダウンロードの履歴を管理することにより既に目的のファイルを取得した連携可能な他の端末を把握している。そのため、連携端末に対してファイルのアップロードを行う必要はない。
この形態の各端末は、図６に示すように、検索処理部１１，検索ヒット状況監視部１２，閾値超過監視部１３，高ヒットファイル検索部１４，検索結果ＤＢ１７，通信インタフェース１８，ダウンロード済み端末検索部３１，問い合わせ処理部３２，ダウンロード履歴ＤＢ３３及び連携ダウンロード要求処理部３４を備えている。
【００４９】
ダウンロード履歴ＤＢ３３は、連携ダウンロード要求処理部３４の動作を監視し、他の端末からの要求に応じたファイルダウンロードの履歴を記憶する。すなわち、ダウンロード履歴ＤＢ３３はファイルを特定する情報，それをダウンロードした端末を特定する情報，日時などを互いに対応付けて履歴として保持する。ダウンロード済み端末検索部３１は、閾値超過監視部１３が（ｈ＞ｓ）の状態を検出した場合に、高ヒットファイル検索部１４を用いて検索ヒット数が大きいファイルを検出するとともに、ダウンロード履歴ＤＢ３３の内容を参照し、該当するファイルを既にダウンロードした連携可能な他の端末（連携候補端末）を特定する。
【００５０】
問い合わせ処理部３２は、ダウンロード済み端末検索部３１が特定した各連携候補端末に対して、連携動作の可否を問い合わせる。そして、この問い合わせに対して連携を許可した端末を連携端末に決定する。
連携ダウンロード要求処理部３４は、他の端末からのファイルダウンロード要求に対して、問い合わせ処理部３２の決定した連携端末と連携して処理を行う。すなわち、自端末及び複数の連携端末のいずれか１つが要求元に対して目的のファイルを転送する。これにより、ファイルダウンロードに伴って発生するトラヒックが分散される。
【００５１】
図６に示す端末の動作（自端末における動作）の概略は図５に示すとおりである。
図５のステップＳ３１では、検索ヒット状況監視部１２の制御により自端末における検索ヒット状況を監視する。また、連携ダウンロード要求処理部３４は他の端末からのダウンロード要求を監視する。
【００５２】
ステップＳ３２では、閾値超過監視部１３の制御により、単位時間あたりの検索ヒット数ｈと予め定めた閾値ｓとを比較する。そして（ｈ＞ｓ）になった場合には次のステップＳ３３に進む。
ステップＳ３３では、高ヒットファイル検索部１４の制御により検索ヒット数が多いファイルを選択するとともに、選択したファイルについてダウンロード履歴ＤＢ３３の内容を参照し、該当するファイルをダウンロードして既に取得している他の端末（連携候補端末）の有無を調べる。
【００５３】
連携候補端末が存在する場合には、ステップＳ３４に進み、各連携候補端末に対して、ダウンロード要求処理の割り当て可否を問い合わせる。ｎ個の連携候補端末が存在する場合には、（ｈ／（ｎ＋１））個の要求を割り当ててよいかを各連携候補端末に問い合わせる。
なお、問い合わせを受ける端末は、初期状態ではダウンロード要求処理の割り当てを受け入れる（了承する）ように動作する。但し、何らかの理由で了承できない端末においては、問い合わせに対して拒否の通知を返す。
【００５４】
問い合わせに対して拒否された場合には、その端末に割り当てを予定していた処理分は自端末で処理することになる。
問い合わせに対して端末が了承した場合には、ステップＳ３４からＳ３７に進み、了承した端末すなわち連携端末と自端末とで連携して、連携ダウンロード要求処理部３４の制御により、他の端末からのファイルダウンロード要求を処理する。
【００５５】
ステップＳ３５では、ダウンロードの履歴をダウンロード履歴ＤＢ３３に追加する。また、ファイルダウンロード要求に対して他の端末と連携せずに通常のダウンロード処理を行う。
ステップＳ３６では、連携端末と連携してダウンロードした場合の履歴も含めてダウンロード履歴ＤＢ３３に履歴を追加する。
【００５６】
ステップＳ３８では、それまでの処理の結果を考慮して、閾値ｓや各端末への割当数を見直す。
なお、この例では各端末が保持するダウンロードの履歴に基づいて連携候補端末を特定しているが、検索がヒットしたことを表す情報の履歴を用いて連携候補端末を特定することも可能である。
【００５７】
【発明の効果】
本発明によれば、ネットワーク全体を集中的に管理するサーバを用いることなく各端末の制御によってトラヒックを分散させることができる。従って、Ｇｎｕｔｅｌｌａ型のＰ２Ｐアプリケーションに対してもトラヒックを制御することが可能になる。
【図面の簡単な説明】
【図１】第１の実施の形態の端末の動作を示すフローチャートである。
【図２】第１の実施の形態の端末の主要部の構成を示すブロック図である。
【図３】第２の実施の形態の端末の動作を示すフローチャートである。
【図４】第２の実施の形態の端末の主要部の構成を示すブロック図である。
【図５】第３の実施の形態の端末の動作を示すフローチャートである。
【図６】第３の実施の形態の端末の主要部の構成を示すブロック図である。
【図７】システム全体の構成例を示すブロック図である。
【符号の説明】
１１　検索処理部
１２　検索ヒット状況監視部
１３　閾値超過監視部
１４　高ヒットファイル検索部
１５　ファイルアップロード処理部
１６　連携ダウンロード要求処理部
１７　検索結果ＤＢ
１８　通信インタフェース
２１　ファイルアップロード処理部
２２　連携ダウンロード要求処理部
３１　ダウンロード済み端末検索部
３２　問い合わせ処理部
３３　ダウンロード履歴ＤＢ
３４　連携ダウンロード要求処理部
５０　Ｐ２Ｐ端末
１００　サポートセンタ

Claims

複数の端末が接続され、全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するためのＰ２Ｐネットワークのトラヒック制御方法であって、
各端末が、他の端末からのファイル検索要求に対する自端末の検索結果のヒット状況を監視し、前記ヒット状況に応じて各端末が自律分散的にトラヒックを制御する
ことを特徴とするＰ２Ｐネットワークのトラヒック制御方法。
請求項１のＰ２Ｐネットワークのトラヒック制御方法において、
他の端末からのファイル検索要求に対する自端末の検索結果について、各端末がファイル毎にヒット数を管理し、
各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から他の端末に対して転送し、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した他の端末を利用してファイルの送信を行う
ことを特徴とするＰ２Ｐネットワークのトラヒック制御方法。
請求項１のＰ２Ｐネットワークのトラヒック制御方法において、
ネットワークに所定のキャッシュサーバが接続されている場合には、
各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から前記キャッシュサーバに対して転送し、
少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得したキャッシュサーバを利用してファイルの送信を行う
ことを特徴とするＰ２Ｐネットワークのトラヒック制御方法。
請求項１のＰ２Ｐネットワークのトラヒック制御方法において、
各端末が、自端末からファイルをダウンロードした他の端末とそれが取得したファイルとの対応関係を履歴情報として保持し、
各端末におけるファイルのヒット数が所定以上に増加した場合に、前記履歴情報を参照して該当する同一のファイルを保持する他の端末を連携端末として決定し、
少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した前記連携端末を利用してファイルの送信を行う
ことを特徴とするＰ２Ｐネットワークのトラヒック制御方法。
複数の端末が接続され、全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するためのＰ２Ｐネットワークのトラヒック制御装置であって、
各端末において他の端末からのファイル検索要求に対する自端末の検索結果のヒット状況を監視するヒット状況監視手段と、
前記ヒット状況監視手段が検出したヒット状況に応じて、各端末が自律分散的にトラヒックを制御するためのトラヒック制御手段と
を設けたことを特徴とするＰ２Ｐネットワークのトラヒック制御装置。
請求項５のＰ２Ｐネットワークのトラヒック制御装置において、
他の端末からのファイル検索要求に対する自端末の検索結果について、ファイル毎にヒット数を管理するヒット数管理手段と、
各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から他の端末に対して転送するファイルアップロード手段と
を更に設け、前記トラヒック制御手段は少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した他の端末を利用してファイルの送信を行う
ことを特徴とするＰ２Ｐネットワークのトラヒック制御装置。
請求項５のＰ２Ｐネットワークのトラヒック制御装置において、
ネットワークに所定のキャッシュサーバが接続されている場合に、
各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から前記キャッシュサーバに対して転送するファイルアップロード手段を更に設け、
前記トラヒック制御手段は、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得したキャッシュサーバを利用してファイルの送信を行う
ことを特徴とするＰ２Ｐネットワークのトラヒック制御装置。
請求項５のＰ２Ｐネットワークのトラヒック制御装置において、
各端末に、自端末からファイルをダウンロードした他の端末とそれが取得したファイルとの対応関係を履歴情報として保持する履歴情報保持手段と、
各端末におけるファイルのヒット数が所定以上に増加した場合に、前記履歴情報を参照して該当する同一のファイルを保持する他の端末を連携端末として決定する連携端末決定手段と
を更に設け、前記トラヒック制御手段は、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した前記連携端末を利用してファイルの送信を行う
ことを特徴とするＰ２Ｐネットワークのトラヒック制御装置。
請求項５のＰ２Ｐネットワークのトラヒック制御装置において、
自律分散制御を実現するプログラム並びに各端末における検索ヒット状況及びダウンロード状況の少なくとも一方を含むトラヒック情報をネットワークに流通させるための情報流通手段
を更に設けたことを特徴とするＰ２Ｐネットワークのトラヒック制御装置。
複数の端末が接続され、全体のトラヒックを集中的に管理するサーバを持たないＰ２Ｐネットワークにおいて、Ｐ２Ｐアプリケーションに対するトラヒックを制御するための、各端末上のコンピュータで実行可能なプログラムであって、
各端末において他の端末からのファイル検索要求に対する自端末の検索結果のヒット状況を監視するヒット状況監視手順と、
前記ヒット状況監視手段が検出したヒット状況に応じて、各端末が自律分散的にトラヒックを制御するためのトラヒック制御手順と
を設けたことを特徴とするプログラム。
請求項１０のプログラムにおいて、
他の端末からのファイル検索要求に対する自端末の検索結果について、ファイル毎にヒット数を管理するヒット数管理手順と、
各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から他の端末に対して転送するファイルアップロード手順と
を更に設け、前記トラヒック制御手順では少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した他の端末を利用してファイルの送信を行う
ことを特徴とするプログラム。
請求項１０のプログラムにおいて、
ネットワークに所定のキャッシュサーバが接続されている場合に、
各端末が保持するファイルに対するヒット数が所定以上に増加した場合に、ヒット数が所定以上の１つ以上のファイルを自端末から前記キャッシュサーバに対して転送するファイルアップロード手順を更に設け、
前記トラヒック制御手順では、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得したキャッシュサーバを利用してファイルの送信を行う
ことを特徴とするプログラム。
請求項１０のプログラムにおいて、
各端末に、自端末からファイルをダウンロードした他の端末とそれが取得したファイルとの対応関係を履歴情報として保持する履歴情報保持手順と、
各端末におけるファイルのヒット数が所定以上に増加した場合に、前記履歴情報を参照して該当する同一のファイルを保持する他の端末を連携端末として決定する連携端末決定手順と
を更に設け、前記トラヒック制御手順では、少なくとも一部のファイルダウンロード要求に対しては、自端末のファイルを既に取得した前記連携端末を利用してファイルの送信を行う
ことを特徴とするプログラム。
請求項１０，請求項１１，請求項１２及び請求項１３のいずれかのプログラムを記録したコンピュータで読み取り可能な記録媒体。