JP2012510774A - Ｐ２ｐネットワークにおける適切なピアの選択 - Google Patents

Abstract

本発明は、ピアツーピアネットワークにおいてコンテンツダウンロードのために適切なピアＣＬ１−ＣＬ５を選択するための方法に関し、方法は、特定のコンテンツを有するピアのアドレスを要求することと、オペレータノードＭＯＮ４に要求されたアドレスを含む応答を受信することと、応答を修正することと、修正はオペレータノードが利用可能なオペレータプリファレンスに基づくことと、修正された応答を要求元のクライアントに送信することと、を含む。
【選択図】図１

Description

本発明は、コンテンツのダウンロードのためのピアツーピアネットワークにおいて適切なピアを選択するための方法及び構成に関する。

ブロードバンドの浸透によりもたらされる増加した帯域幅、並びに向上した端末のケイパビリティ、コンテンツ生成及びパブリッシングツールの利用可能性は、例えばユーチューブやポッドキャスティングなどのユーザにより製作されるコンテンツのインターネット上での利用可能性において格段に増大している。ＪｏｏｓｔやＢＢＣ ｉＰｌａｙｅｒなどのコンテンツアグリゲータは、合法的なオンラインコンテンツの定着したソースにもなりつつある。

ピアツーピア技術は、ユーザにより製作されるコンテンツを配信するための有望な技術とて、またコンテンツアグリゲータの好まれる技術として見出されてきた。例えば、ｉＰｌａｙｅｒは、ＩＭＰ Ｐ２Ｐクライアントを利用する。単にピアツーピアあるいは省略してＰ２Ｐとして言及されることの多いピアツーピアのアーキテクチャは、各ワークステーションが同等のケイパビリティと責任とを有するタイプのネットワークである。これは、いくつかのコンピュータが専ら他者にサービスを提供するというクライアント／サーバアーキテクチャとは異なる。Ｐ２Ｐネットワークは、効率的なコンテンツ配信のために、ネットワーク内の接続されたピア間で計算パワーを分散させ、例えば利用可能なネットワーク帯域幅など一体化したリソースを利用する。Ｐ２Ｐは、ソフトウェアアップグレード又はメディアファイルなどのマテリアルをダウンロードするための共通的なＰ２Ｐクライアントの使用を通じて情報及びファイルを転送するために他のユーザとリンクしているユーザを説明するための用語としてしばしば使用される。

Ｐ２Ｐクライアントを用いてコンテンツをダウンロードするとき、ダウンロード時間を減らし、Ｐ２Ｐネットワークの堅牢性を増大させるために、選択されたファイルの一片または塊が、いくつかのノードから同時に集められる。データチャンク（ｃｈｕｎｋｓ）をダウンロードするピアのセットは、Ｐ２Ｐネットワークにおけるピア間のゲートウェイとして機能する、いわゆるトラッカによって選択される。それは、ピアが何のデータの塊を持っているかについての情報を集め、その情報を要求しているピアに拡散する。トラッカは、ネットワーク上のどこに位置していてもよい。

インターネットにおける近年のトレンドは、コンテンツ配布ネットワークを構築するためにＰ２Ｐ技術を使用することである。商用システムの例は、CacheLogicのVelocixと、GridNetworksのGridcastingとを含む。ＵＫにおけるＢＢＣのIP playerと共に、これらのような近年のトレンドに基づけば、Ｐ２Ｐ技術が近い将来コンテンツプロバイダによりコンテンツを配布する安価な方法として用いられることが仮定される。いくつかのポイントにおいて、ネットワークオペレータは、コンテンツ配布、特にビデオ配布のためにＰ２Ｐを用いるようになるかもしれない。とにかくオペレータは、まず彼らのネットワーク中におけるＰ２Ｐトラフィックを管理する必要があるだろう。Ｐ２Ｐアプリケーションの過度のトラフィックのために、オペレータは、エンドユーザ体験を改善するためにピアによるトラフィックを低く保ちたいと思うだろう。これは、すでにインターネットベースで存在している方法を補完するオペレータ特有の技術及び構成を要求する。

トラッカアーキテクチャに基づいてＰ２Ｐシステムにおいて、クライアントがコンテンツを要求するとき、それは、所望のデータの塊を有するピアのアドレスを得るためにトラッカと接触する。トラッカは、いわゆるトラッカレスポンスによってデータを有するピアへのアドレスのリストを含むクライアントへ応答する。例えば、BitTorrentプロトコルにおいてトラッカレスポンスにおけるピアノリストは、もし利用可能なピアの数が５０以上である場合、デフォルト５０個ずつである。もし所望のコンテンツの塊を有するピアがもっと存在するときには、トラッカはランダムにレスポンスに含むピアを選択する。または、トラッカは、要求に応答するとき、ピア選択のためによりインテリジェントなメカニズムを実行することを選んでもよい。この選択は、例えば場所（locality）、ネットワーク計測などに基づいて実行されてもよい。全ては、トラッカの観点（viewpoint）に基づいている。

問題は、多くの位置情報及び他のオペレータ特有の情報が、集中型のインターネットベースのトラッカにとっていつも利用可能ではないことである。さらに、トラッカは、トラフィックをオペレータのすぐ近くに保つことのようなオペレータのニーズをいつも考慮しているとは限らないことである。同じタイプの問題が、もしＰ２ＰシステムがDistributed Hash Table DHTのようなアルゴリズムに基づく場合に表れる。

本発明は、Ｐ２Ｐトラフィック管理の問題に関する。本発明は、オペレータのディストリビューションネットワークに関する情報を利用することにより、コンテンツをダウンロードするためのピア選択の方法を改善することにフォーカスする。さらに、オペレータが提供するプレミアムＰ２Ｐサービスを利用する方法が提案される。プレミアムサービスは、エンドユーザが、オペレータにより追加サービスとして提供される管理されるネットワーク中の優先順位付けされたコネクション上でP2Pを用いてコンテンツにアクセスすることを可能にする。

Ｐ２Ｐトラフィック管理の問題は、コンテンツのダウンロードのために適切なピアを選択するための方法により解決される。方法は、
−特定されるコンテンツを処理するピアのアドレスを要求することと、
−要求されるアドレスを含む応答がオペレータノードに受信されることと、
−応答がノードにおいて修正され、修正は、オペレータノードにとって利用可能なオペレータプリファレンスに基づくことと、
−修正された応答は、要求元のクライアントに転送されることと、
を含む。

本発明は、コンテンツをダウンロードするピアをオペレータプリファレンスに基づいて選択するためのメカニズム及び技術を説明する。基本的に、方法は、例えばトラッカーレスポンス（応答とも呼ばれる）の、オペレータ特有の情報に基づいた修正を含む。或いは、例えばＤＨＴのようなＰ２Ｐシステムの場合において、それは他のピアからの応答を、オペレータ特有の情報に基づいてブロック又は修正することができる。一実施形態によれば、Ｐ２Ｐトラッカーは、要求されたコンテンツを処理するピアを見つけ出すために、探索メカニズムとして用いられる。トラッカーからの応答は、オペレータノード中において、要求元のクライアントに転送されるまえに修正される。接続は、修正された応答中に見つけられたクライアントへの接続は、要求元のクライアントにより確立される。

他の実施形態によれば、体系化されていないＰ２Ｐシステムは、要求されたコンテンツを処理するピアを探し出すための探索メカニズムとして用いられる。ピアからの応答は、要求元のクライアントを通り抜けるかもしれないし、又はブロックされるかもしれない。オペレータプリファレンスを満たさないピアのアドレスは、ブロックされ、そして後に用いられるためにキャッシュされてもよい。本実施形態において、要求元のクライアントは、クライアントへの接続を確立することができない。そしてそれは通り抜けさせられて、さらなる要求が要求されたコンテンツを処理するピアを見つけ出すために送信される。

しかしもう１つの実施形態は、修正がプレミアムノードの選択から追加的なアドレスをピアに利用するときに、適したピアを選択するための方法を示す。

本発明は、例えば場所に基づいて、クライアントにコンテンツをダウンロードさせるために、応答を修正することを可能にする。これは、ピアリングトラフィックを低減することができると同時に、エンドユーザ体験を改善する可能性を有する。これは、以下の利点を与える。
・加わっているピアがより近くなるためにより速いダウンロード
・オペレータ間におけるトラフィックの低減、そしてそれはピアリングコストを低減する
・オペレータのＰ２Ｐトラッカーレスポンス修正メカニズムを用いることないピアの後方互換性
・合法なトラフィックのインターセプトのために開放するＰ２Ｐモニターノード
・オペレータへ顧客にプレミアムＰ２Ｐネットワークを提供する可能性を与え、そのため収入のための新たな道を与える。

図１は、様々なアクセスネットワークを介してインターネットに接続される複数のクライアントを開示するブロック概略図である。セントラルＰ２Ｐトラッカーは、インターネット上に位置する。クライアントは、トラッカーとモニタリングノードを介して通信することができる。 図２は、Ｐ２Ｐトラッカーが探索メカニズムとして用いられるとき、適したピアを選択するための方法を示すシグナルシーケンス図を開示する。 図３は、非構造化（ｕｎｓｔｒｕｃｔｕｒｅｄ）Ｐ２Ｐシステムが探索メカニズムとして用いられるとき、適したピアを選択するための方法を示すシグナルシーケンス図を開示する。 図４は、Ｐ２Ｐモニタリングノードのブロック概略図を開示する。 図５は、Ｐ２Ｐトラッカーが探索メカニズムとして用いられ、修正が、プレミアムノードの選択から追加的なアドレスをピアに利用するとき、適したピアを選択するための方法を示すシグナルシーケンス図を開示する。 図６は、本発明の方法のいくつかの本質的なステップを描くフローチャートを開示する。

本発明は、添付の図面と共に、好ましい実施形態の支援と共により詳細について説明されるだろう。

図１は、例示的な実施形態に従って、様々なアクセスネットワークＡＮ１−ＡＮ３を介してインターネットに接続される複数のクライアントＣＬ１−ＣＬ５を含むピアツーピアＰ２Ｐネットワークを開示する。図は、とても単純化された例を開示し、クライアントの数は、実際にはもっと多い。クライアントＣＬ１−ＣＬ５は、例えば、携帯電話、コンピュータ、セットトップボックス、又はインターネットと情報を交換することのできる他のデバイスであってよい。アクセスネットワークＡＮ１−ＡＮ３は、例えば、通信ネットワーク、電話ネットワーク、インターネットサービスプロバイダなどであってよい。この実施形態において、第１のオペレータＯＰ１は、ＡＮ１−ＡＮ３にアクセス可能であり、第２のオペレータＯＰ２は、アクセスネットワークＡＮ１にアクセス可能である。ＣＬ１及びＣＬ２は、共にＯＰ１／ＡＮ３に属されており、ＣＬ３はＯＰ１／ＡＮ２に属されており、ＣＬ５はＯＰ２／ＡＮ１に、ＣＬ４はＯＰ１／ＡＮ１に属されている。オペレータＰ２Ｐモニターともまた呼ばれるオペレータノードＭＯＮ４は、ＡＮ１中に位置し、ＯＰ１の一部である。Ｐ２ＰモニターＭＯＮ５は、ＡＮ１中に位置し、ＯＰ２の一部であり、ＭＯＮ３は、ＡＮ２中に位置し、ＯＰ１の一部であり、ＭＯＮ１２は、ＡＮ３中に位置し、ＯＰ１の一部である。セントラルトラッカーＴは、インターネット中に位置する。トラッカーは、クライアントのためのディレクトリーサービスとして機能し、Ｐ２Ｐネットワーク中においてピアとも呼ばれる。Ｐ２Ｐトラッカーは、いかなるＰ２Ｐ探索メカニズム（例えばビットトレント（ＢｉｔＴｏｒｒｅｎｔ）トラッカーシステム）であってもよい。トラッカーは、ピアがどのようなデータの塊（ｃｈｕｎｋｓ）を持っているかの情報を集めて、要求するピアに情報を拡散する。図１中において、分散データベースＤＤＢが見られる。ＤＤＢは、分散的トラッカーとして機能する。これは、第１の実施形態が説明されるときにさらに説明されるだろう。この第１の実施形態において、コンテンツダウンロードのための適したピアの選択のための方法が示され、図２中においてより詳細に説明されるだろう。セントラルトラッカーＴは，特定のコンテンツを有するピアのアドレスのための要求１をここで受信する。トラッカーレスポンス２は、Ｐ２ＰモニターＭＯＮ４によってキャプチャーされる。本発明によれば、レスポンスは、ＭＯＮ４中において利用可能なオペレータプリファレンスに基づいて修正される。修正は、図１中において六角形のシンボル３と共に示される。修正されたレスポンスは、要求元のクライアントＣＬ４に送信される。

本発明の第１の実施形態に係る方法は、図２と共により詳細に説明されるだろう。図２は、シグナルシーケンス図であり、図１と共に先に簡潔に説明されたシグナリングポイントＣＬ４，ＭＯＮ４，Ｔ，ＣＬ１及びＣＬ３が開示される。方法の必須要件は、いくつかの手段によって例えば、当業者によく知られているビットトレントのようなトレントファイルをダウンロードすることによって、どのピアが所望のコンテンツを所有しているかの情報を有するトラッカーのアドレスを知っている要求元のクライアントである。方法は、下記のステップを含む。
・要求中で特定されるファイルのデータチャンクのための要求がクライアントＣＬ４からセントラルトラッカーＴに送信される１０。すなわち、Ｐ２Ｐネットワークの所望のコンテンツを探索するために、探索要求がクライアントＣＬ４によってＰ２Ｐトラッカーに送信される。
・トラッカーＴが、どのピアが要求されるデータチャンクを持っているかの情報を集める・この例において、ＩＰアドレス情報がトラッカーによってリストに集められる。
・トラッカーが、要求されるファイルのデータチャンクを持っているピアのリストと共に返答する。この単純化された例において、リストは、ＣＬ１，ＣＬ３，及びＣＬ５のＩＰアドレスを含む（図１参照）。レスポンスは、Ｐ２ＰトラッカーＴからＰ２ＰモニターＭＯＮ４を介して要求元のクライアントＣＬ４に送信される１１。レスポンスは、この実施形態において、応答とも呼ばれる。図２を参照せよ。
・本発明によれば、Ｐ２ＰモニターＭＯＮ４は、レスポンスをキャプチャーすることによってトラッカーレスポンスがＣＬ４に到達することを妨げる。
・ＭＯＮ４は、キャプチャーされたトラッカーレスポンスを、例えば場所、ネットワークトポロジ、及びネットワーク測定値に基づいて修正する。修正することは、Ｐ２Ｐモニターについて図４との関係で説明される記述中において後にさらに説明されるだろう。この実施形態において、オペレータポリシーは、通信が異なるオペレータネットワーク中に位置するピア間で妨害されることを要求する。オペレータプリファレンスは、ピア／クライアントＣＬ５のレスポンスからの除去をもたらす。なぜならば、要求元のクライアントＣＬ４はＯＰ１中に位置するのに、ＣＬ５はＯＰ２中に位置するためである。修正されるレスポンスは、ここではＣＬ１及びＣＬ３についてのＩＰアドレスのリストを含む。
・修正は、図２において六角形のシンボル１２と共に開示される。修正されるレスポンスは、この実施形態において、また修正された応答と呼ばれる。図２を参照せよ。
・レスポンスから除去されたＣＬ５についてのＩＰアドレスは、後に用いられる可能性のために、Ｐ２ＰモニターＭＯＮ４中に格納される。
・修正されるトラッカーレスポンスは、ＭＯＮ４から要求元のクライアントＣＬ４に送信される１３。
・要求元のクライアントＣＬ４は、データチャンクを読み出す１５ために、修正されるレスポンス中に見つけ出されるＣＬ１にクエリーを行う１４。
・要求元のクライアントＣＬ４は、データチャンクを読み出す１７ために、修正されるレスポンス中に見つけ出されるＣＬ３にクエリーを行う１６。

クライアントＣＬ４からセントラルトラッカーＴに送信された１０データチャンクのための要求は、ＯＰ１／ＡＮ１中の他のクライアントが同じデータチャンクを要求し、チャンクがすでにＰ２Ｐモニター中に格納されている場合には、後に用いられるためにＭＯＮ４によってインターセプトされるかもしれない。

もしクライアントが修正されるレスポンス中のリストからピアへの接続を確立できなかったとき、例えば、もしピアがＰ２Ｐネットワークを離れているとき、又はもし選択されたピアからのダウンロードスピードの合計が低すぎるとき、要求元のクライアントは、Ｐ２ＰトラッカーＴからその他のピアのセットを要求することができる。この要求もまた、ＭＯＮ４によってインターセプトされ得る。ピアのセットは、キャッシュされた／格納されたアドレス、すなわち、この例においては、修正オペレータポリシーと共に、ＣＬ５についてのアドレスを用いて、再構築されてもよい。もしキャッシュされたピアアドレスが十分になりときには、要求は、トラッカーにフォワードされ、上述のシーケンスが繰り返される。これは、第２の実施形態においてより詳しく説明される。要求元のクライアントがスタービングするのを防ぐために、オペレータポリシーは、ここで細かいところまで配慮されたものでなくてよい（ｌｅｓｓ ｐａｒｔｉｃｕｌａｒ）。

トラッカーを探索メカニズムとして用いることに代えて、分散ハッシュテーブルが用いられてもよい。Ｐ２Ｐシステムの中心的な部分の１つは、ディレクトリサービスである。基本的にディレクトリサービスは、特定のコンテンツを有するピアのＩＰアドレスを含むデータベースである。集中型のＰ２Ｐの実装において、このディレクトリは、トラッカーと呼ばれ（上述の通り）、分散化型のＰ２Ｐの実装において、これは、分散ハッシュテーブルＤＨＴと呼ばれる。トラッカーのケースのようにシングルノード中よりもむしろ、ＤＨＴにおいて、複数の分散データベースＤＤＢは、多くのピアに属し、従ってこれは分散データベースＤＤＢである。ＤＨＴアルゴリズムは、当業者によってよく知られている。第１の実施形態のこの変形例において、要求を要求元のクライアントからトラッカーに送信する代わりに、要求は、当業者に知られるＤＨＴの実装に従って、最も適したピアにフォワードされる。そして、トラッカーが所望のコンテンツと共にピアのＩＰアドレスのリストを返答するのに代えて、ＩＰアドレスを有する見つけられたピアは、返答してリストを運ぶだろう。Ｐ２Ｐモニタリングノードの動作は、Ｐ２Ｐトラッカーのケースと比較して似ている。

第１の実施形態において、トラッカー又は代替的にＤＨＴアルゴリズムは、どのピアがどのデータチャンクを有しているかの情報を集め、要求元のピアに情報を拡散するけれども、代わりの他の探索方法が実行されてもよい。これは、ここで第２の実施形態中に説明されるだろう。全てのＰ２ＰネットワークがＤＨＴ又はどのデータチャンクがどこに位置しているかの情報を有するセントラルトラッカーに基づいている訳ではない。他のＰ２Ｐ探索ソリューションは、コンテンツを探索するために、いわゆる非構造化Ｐ２ＰシステムＵＰＳを用いることである。非構造化Ｐ２Ｐシステムは、当業者によりよく知られている。ＵＰＳを用いるとき、データチャンクのための要求は、セントラルデータベースを通らなくてもよく、代わりにそれは応答可能なピアに直接送信される。コンテンツを有するピアは、ＵＰＳのようなＰ２Ｐの実装に従って応答し、直接要求元のピアに応えるだろう。Ｐ２Ｐ Ｍｏｎノード中の動作の方法は、Ｐ２Ｐトラッカーのケースと比較して似ている。しかしながら、下記のようにいくつかのマイナーな差異がある。

図３は、本発明の第２の実施形態を開示し、探索は、非構造化Ｐ２ＰシステムＵＰＳにより実行される。図３中において、トラッカーＴが除外されることを除いては、図１中に前に示されたように同じネットワーク構成を適用する。コンテンツを探索するために、セントラルトラッカーを用いることに代えて、図３中においてＵＰＳが用いられる。図中において、非構造化Ｐ２Ｐシステムに従った探索は、符号ＵＰＳのブロックで概略的に示される。本発明の第２の実施形態にかかる方法は、下記のステップを含む。
・要求中で特定されるファイルのデータチャンクのための要求が、この例において、クライアントＣＬ４からクライアントＣＬ１に送信される２０。
・要求されるコンテンツを有するクライアントの探索が開始する。探索は、受信される要求をＣＬ１から、Ｐ２Ｐネットワーク中の全てのピアが要求を受信するまで、順に要求を他のピアにフォワードするだろうネットワーク中の隣接ピアにフォワードすることにより実行される。まさに、どのように探索が実行されるかは、実装の問題である。
・要求されるコンテンツ、すなわち要求されるデータチャンクを有するクライアントは、要求元のクライアントＣＬ４に直接答える。この単純化された例において、クライアントＣＬ１，Ｃｌ３、及びＣＬ５は、１つずつそれらのＩＰアドレスをＣＬ４に送信する。レスポンス２１−２３は、Ｐ２ＰモニターＭＯＮ４を介して要求元のクライアントＣＬ４に送信される。レスポンス２１−２３は、ＭＯＮ４によって、受信され、いわゆる応答を共に構成する。図３を参照せよ。
・本発明に寄れば、Ｐ２ＰモニターＭＯＮ４は、応答２１−２３がＣＬ４に到達することを、それらをキャプチャーすることによって、阻害する。
・ＭＯＮ４は、オペレータポリシーに従って望まないピアから来る応答をブロックすることによって、又は所望の応答がＣＬ４を通るようにすることによって、応答を修正する。この実施形態において、オペレータポリシーは、もしコンテンツがオペレータネットワーク中のいくつかのアクセスネットワーク中に位置するとき、測定ツールが、どのアクセスネットワーク中のどのピアが要求元のクライアントを通るようにするかを予測するために用いられてよいことを要求する。この例において、オペレータプリファレンスは、クライアントＣＬ３及びＣＬ５から送信される応答２２及び２３がＣＬ４を通るようにされるとき、クライアントＣＬ１から送信される応答２１のブロッキングをもたらす。ＣＬ１からブロックされる応答は、後に用いられる可能性のためにキャッシュされる。ＭＯＮ４から１つずつ送出される応答２２及び２３は、いわゆる修正された応答を構成する。図３を参照せよ。応答の修正、すなわち、応答からの２１の除去は、図３中において、六角形のシンボル２４により開示される。
・要求元のクライアントＣＬ４は、データチャンクを読み出す２７ために、ＣＬ３にクエリーを行う２６。しかしながら、この例において、要求元のクライアントＣＬ４は、ＣＬ３に接続を確立することができなかった。これは、図３中において、クロスオーバーシンボル２８により示される。
・要求元のクライアントは、ＣＬ３との接続を確立することができたため、クライアントＣＬ４は、ＭＯＮ４によりキャプチャーされるであろう新たな探索要求２９を生成するだろう。
・ＭＯＮ４は、前にＣＬ１からの応答２１をキャッシュしているため、それは、ＣＬ４にフォワードされ得る。さもないと、ＣＬ４からの探索要求２９は、新たな探索のためのＵＰＳ中にフォワードされるだろう。
・この例において、探索要求は、フォワードされる。要求されるコンテンツを有するクライアントは、要求元のクライアントＣＬ４に直接答える。この例において、クライアントＣＬ２及びＣＬ５は、１つずつそれらのＩＰアドレスをＣＬ４に送信する。ＭＯＮ４により受信される応答は、共にいわゆる、さらなる応答を構成する。図３を参照せよ。さらなる応答は、ピアＣＬ２及びＣＬ５からの応答３０，３１を含み、Ｐ２ＰモニターＭＯＮ４を介して要求元のクライアントＣＬ４に対して送信される。
・Ｐ２ＰモニターＭＯＮ４は、さらなる応答中のレスポンスがＣＬ４に到達することを、それらをキャプチャーすることにより妨げる。
・ＭＯＮ４は、さらなる応答を修正する。このときＰ２Ｐモニターは、その選択についてそんなにアグレッシブでない。オペレータプリファレンスは、レスポンスの除去をもたらさない。さらに、前にキャッシュされたレスポンス２１は、修正されたさらなる応答中に挿入される。図３を参照せよ。修正されたさらなる応答は、ここで、クライアントＣＬ１，ＣＬ２，及びＣＬ５からのレスポンス２１，３０，３１を含み、ＭＯＮ４からＣＬ４に送信される。さらなる応答の修正は、図３中に六角形のシンボル３２により開示される。

図４は、図１−３を共に用いて本明細書中にて先に説明されたピアツーピアモニターＰ２Ｐ ＭＯＮ６０をより詳細に開示する。前の図面において、Ｐ２Ｐ ＭＯＮ３０は、例えばＭＯＮ４により示された。

Ｐ２Ｐ Ｍｏｎについての要求は、下記の通りである。
・Ｐ２Ｐモニターノードの位置は、変更可能である。しかし、それは、クライアントピアとトラッカーの間、（もしそのようなノードが存在するならば）他のピアと同様に、のトラフィックフローをキャプチャーできるべきである。
・ピアとトラッカーとの間の要求及びレスポンスのように、Ｐ２Ｐトラフィックを識別するためにＤｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎが有効化されるべきである。Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎは、検査ポイントを通過しながら、データ及び／又はパケットのヘッダ部を調べ、プロトコルコンプライアンスに適合しないもの、ウイルス、スパム、侵入、又は、パケットが通過してよいか、又は異なる送り先を経由すべきか、又は統計情報の収集の目的であるかを決定するための所定の基準を探索するコンピュータネットワークパケットフィルタリングの一つの形である。これは、（通常単にパケット分析と呼ばれる）単にパケットのヘッダ部分をチェックする浅いパケット分析とは対照的である。
・アクセスネットワーク中において、特定のピア／ＩＰアドレスが位置することは注意すべきである。
・Ｐ２Ｐ Ｍｏｎは、例えばＢＡＲＴのようなネットワークパフォーマンス計測ツールにより実現されてよい。ＢＡＲＴの態様は、次のようにいくつかの参考文献において刊行されている。
・S. Ekelin and M. Nilsson, “Continuous monitoring of available bandwidth over a network path”, 2^nd Swedish National Computer Networking Workshop, Karlstad, Sweden, November 23-24, 2004.
・S. Ekelin, M. Nilsson, E. Hartikainen, A. Johnsson, J.-E. Mangs, B. Melander and M. Bjorkman, “Real-time measurement of end-to-end available bandwidth using Kalman filtering,” in Proc. 10th IEEE/IFIP Network Operations and Management Symposium, 2006.
・E. Hartikainen and S. Ekelin, “Tuning the Temporal Characteristics of a Kalman-Filter Method for End-to-End Bandwidth Estimation,” in Proc. 4th IEEE/IFIP Workshop on End-to-End Monitoring Techniques and Services, 2006.
・E. Hartikainen and S. Ekelin, “Enhanced Network-State Estimation using Change Detection,” in Proc. 1st IEEE LCN Workshop on Network Measurements, 2006.
・それは、トラッカーレスポンス又は他のピアからのレスポンスを修正するどのような及び何の基準に基づいたオペレータポリシーを受信できるべきである。

この章は、実際のＰ２Ｐモニターノードの実際の分析（ａｎｏｔｏｍｙ）、又は、１つの共通の物理的ノード中の他の機能と共に位置することができる、Ｐ２Ｐモディファイア（ｍｏｄｉｆｉｅｒ）の機能について説明する。図４中において見られるように、Ｐ２Ｐモニター６０は、３つのメインブロック、すなわち、インターせぷションブロック、処理ブロック、及び再生ブロック、を有する。トラッカー又はピアからのレスポンスは、レシーバ６１に受信され、インターセプションブロックにフォワードされる。

インターセプションブロックは、トラッカー又は他のピアからのレスポンスメッセージの抽出／キャプチャリングに責任がある。これは、ディープパケットインスペクションＤＰＩを実装することにより実現される。ＤＰＩモジュール６２がインターセプションブロック中に開示される。追加的に、デクリプションがトラッカーからのトラフィックに適用されてもよい。レスポンスがトラフィックから抽出されると、他のモジュールがさらなるデータ処理を行うことができるように、それは解析される（ｐａｒｓｅｄ）。解析モジュール６３は、図中にインターセプションブロック中に開示される。解析は、問題になっているＰ２Ｐシステムに合わせて実行されるべきである。従って、例えば異なる特色のＢｉｔｔｏｒｅｎｔプロトコルの解析パターンは、互いに異なるだろう。異なるＰ２Ｐプロトコルの実装をどのように扱うかの詳細は、Ｐ２Ｐプロトコルパターンのデータベース６７中に格納される。

処理ブロックは、オペレータポリシーに従ってコンテンツを有するシーズ（ｓｅｅｄｓ）又はピアのリストの順序付けに責任がある。実装に応じて、それは存在するシードリストの順序付け、シーズのいくつかのアドレスの除去、又はコンテンツシーズの全く新しいアドレスの追加さえも実行する。フィルタリングモジュール６４及び挿入モジュール６５が図３中に処理ブロック中に見えるだろう。アドレスが除去されるケースにおいては、メモリモジュール７０は、除去されたアドレスを格納するだろう。除去されたアドレスは、要求元のクライアントがシーズの修正されたリストから紺ｔ年つを無事取得できないときに用いられてよい。要求元のクライアントがコンテンツスターベイションしないように、除去されたシーズのアドレスは、クライアントがコンテンツシーズを再要求するときに提供されてよい。もしＰ２Ｐシステムが、第２の実施形態が説明されたとき図３において示されたように、集中トラッカー又は非構造化Ｐ２Ｐシステムの代わりに、分散ハッシュテーブルＤＨＴ探索システムに基づくとき、処理ブロックが、他のピアからの応答を修正又はドロップすることもまたできることは明らかである。

再生ブロックは、この点においてオペレータポリシーに従ってシードアドレスによるトラッカーレスポンスの再構築に責任がある。再パッケージングモジュール６６が図４中において、再生モジュール中に開示される。エンクリプションは、追加的であり、もしイニシャルトラッカーレスポンスが暗号化されていたときに実行される。修正されたレスポンスは、Ｐ２Ｐ Ｍｏｎ６０から要求元のピアに送信機７１を介してフォワードされる。

オペレータポリシーホルダー６９は、オペレータポリシーインタフェース６８に接続される。様々な修正ポリシーがポリシーホルダー６９により保持されている。修正ポリシーの例は、
・トラッカーレスポンスからアドレスを削除することによる、又は、ＵＰＳのようなＰ２Ｐノードから応答をドロップすることによる、異なるオペレータネットワーク中に位置するピア間のハインダー（Ｈｉｎｄｅｒ）コミュニケーション。これは、オペレータ間におけるトラフィックを低減し、かくしてピアリングコストを低減するであろう。
・もしコンテンツが、１つのオペレータネットワーク中のいくつかのアクセスネットワーク中に位置するならば、Ｐ２Ｐ Ｍｏｎは、どのアクセスネットワーク中のどのピアがトラッカーレスポンス中を通るようにするか、またはＵＰＳのようなＰ２Ｐノードからの応答をフォワードするかを予測するために、計測ツール（例えば、ＲＴＴ又は利用可能な帯域を見積もる）を用いることができる。
・Ｐ２Ｐ Ｍｏｎはまた、プレミアムノードの選択肢から、又は例えば高いキャパシティ又は広い（そして合法な）コンテンツの選択肢と共に、プレミアムネットワークから、ピアに追加的なアドレスを提供することができる。そのようなアドレスは、課金Ｐ２Ｐカスタマーからのみアクセス可能であるべきである。これは、ネットワーク中における高い優先度のためのパケットのタグ付けと同様に、Ｐ２Ｐ Ｍｏｎ中にトールゲートの機能を必要とする。

アクセスネットワーク中においてＰ２Ｐトラフィックを優先付けして取り扱うために、追加的な分散Ｐ２Ｐタグ付け機能が実装されてもよい。このタグ付け機能は、Ｐ２Ｐ Ｍｏｎによるコントロール下にあり、アクセスネットワークを通じて、正しい優先付けを与えるために、特定のトラフィックを別にマークするために用いられてよい。これは、イーサネットポリシーのために、特定の８０２．１ｐ−ｂｉｔｓのプレミアム加入者のトラフィックをマークすることによってできる。これはまた、それが他のネットワークに向かうようにするために、Ｐ２Ｐタグ付け機能が特別なＶＬＡＮタグをトラフィック上に置くことができることを意味する。トラフィックを特定の８０２．１ｐ−ｂｉｔｓによりマークすることによって、全てのアクセスネットワークは、全てのネットワークを通して、ポリシー、アクセスノードから全ての経路にトラフィックをキューすることができる。８０２．１ｐ−ｂｉｔマーキングがオペレータ装置中において起こるために、このマーキングは、もちろんＤＣＳＰｂｉｔｓに必要に応じて変換され得る。他の変換スキーム（ＭＰＬＳ ＬＳＰｓその他）もまた可能である。Ｐ２Ｐタグ付け機能は、Ｐ２Ｐ Ｍｏｎ自身から分離された機能として理解されてもよい。タグ付け機能は、いかなる複雑なメカニズムも含まず、実装が容易な軽量な機能を意味される。Ｐ２Ｐ Ｍｏｎ、Ｐ２Ｐタグ付け機能、および加入者データベースへの接続を一体化することによって、非常に先進的なサービス及び新たな収入の流れが想定される。プレミアムコンテンツは、加入者だけのサービスであり、コンテンツサービスプロバイダは、プレミアムコンテンツに対する料金を得ることができる。これはまた、ＳＴＩＭ（Svenska Tonsattares Internationella Musikbyra）が提案する、ブロードバンドサービスの接続される、合法な、無償のファイルシェアリング税（ｔａｘ）のアイデアを広げる。Ｐ２Ｐ Ｍｏｎ及びプレミアムネットワークコネクションは、ファイルシェアリング税が提案されたときに未だ未解決である技術的問題を解決する１つの方法である。図５は、本発明の第３の実施形態に係るシグナルシーケンス図を開示し、修正がプレミアムノードの選択肢からピアへの追加的なアドレスを用いるときに、適切なピアを選択するための方法を示す。前の実施けち愛において開示及び説明されたエンティティを超えて、図５は、選択されたトラフィックのタグ付けに責任のあるアクセスノードＤＳＬＡＭを開示する。図５中において、Ｐ２Ｐネットワーク中のクライアントは、参照符号ＣＬ１−ＣＬ１０で示される。第３の実施形態に係る方法は、下記のステップを含む。
・第１の実施形態のように、要求元のクライアントＣＬ４は、セントラルトラッカーＴに要求４０を送信することによって、データチャンクを要求する。
・トラッカーＴは、要求されるデータチャンクを有するピアの情報を集める。
・トラッカーは、要求されたファイルのデータチャンクを有するピアのリストで応答する。リストは、ＣＬ１−ＣＬ５のＩＰアドレスを含む。レスポンス（又は応答）がＰ２ＰトラッカーＴｋａｒａＰ２ＰモニターＭＯＮ４を介して要求元のクライアントＣＬ４に対して送信される４１。
・Ｐ２ＰモニターＭＯＮ４は、トラッカーレスポンスがＣＬ４に到達することを、レスポンスをキャプチャーすることによって妨げる。
・ＭＯＮ４は、キャプチャーされたトラッカーレスポンスを、オペレータポリシーに基づいて修正する。しかしながら、この例示された実施形態中においては、要求元のクライアントは、優先付けされたクライアントであり、ＣＬ１０のためのプレミアムＩＰアドレスが修正された応答に加えられる。修正された応答は、ここで、ＣＬ１−ＣＬ５及びＣＬ１０についてのＩＰアドレスのリストを含む。修正は、図５中において、六角形のシンボル４２により開示される。
・修正されたトラッカーレスポンスは、ＭＯＮ４から要求元のクライアントＣＬ４に送信される４３。
・タグ付け命令が、この実施形態において、ＭＯＮ４からＤＳＬＡＭに送信される４４。これは、もしＣＬ１０へのアクセスが要求されたとき、ＤＳＬＡＭがＣＬ４からの要求にタグ付けすることを命令する。
・要求元のクライアントＣＬ４は、データチャンクを読み出すために、修正されたレスポンス中に見つけられるＣＬ１０にクエリーを出すことができる。ＣＬ４のタグ付けなしに、ＣＬ１０からコンテンツへの正しいアクセスは与えられなかっただろうことは特筆すべきである。

図６は、本発明の方法のいくつかの本質的なステップが描かれるフローチャートを開示する。フローチャートは、前に示された図面と共に、読まれるべきである。フローチャートは、下記のステップを含む。
−要求元のクライアントＣＬ４が、Ｐ２Ｐネットワークの所望のコンテンツを探索するために、探索要求を送信することによって、要求中において特定されるファイルのデータチャンクを有するピアのアドレスを要求する。このステップは、図６中においてブロック１０１と共に示される。
−オペレータノードＭＯＮ４が、所望のデータチャンクを有するピアのアドレスを含む応答を受信する。このステップは、図６中においてブロック１０２で示される。
−オペレータノードＭＯＮ４は、受信した応答を、例えば場所、ネットワークトポロジ、及びネットワーク計測値のような、オペレータプリファレンスに基づいて修正する。このステップは、図６中においてブロック１０３で示される。
−修正された応答が、要求元のクライアントＣＬ４にフォワードされる。このステップは、図６中においてブロック１０４で示される。

本発明を実施するために用いられ得るシステムが図１から図４に概略的に示される。列挙されたアイテムは、図中において、それぞれの要素として示される。本発明の実際の実装においては、しかしながら、それらは、デジタルコンピュータのような他の電気的デバイスの一体化したコンポーネントであってもよい。かくして、上述の動作は、プログラムストレージメディアを含む製品の品目で実施されてもよいソフトウェアで実装されてもよい。プログラムストレージメディアは、１又は複数のキャリア波、コンピュータディスク（磁気、又は光学（例えばＣＤ又はＤＶＤ又は両方）、不揮発性メモリ、テープ、システムメモリ、及びコンピュータハードドライブ中に具体化されるデータ信号を含む。

本発明のシステム及び方法は、例えば第３世代パートナーシッププロジェクト（３ＧＰＰ）、ユーロピアンテレコミュニケーションズスタンダードインスティテュート（ＥＴＳＩ）、アメリカンナショナルスタンダードインスティテュート（ＡＮＳＩ）又は他の標準的なテレコミュニケーションネットワークアーキテクチャのいずれかの上で実装されてよい。他の例としては、インスティテュートオブエレクトリカルアンドエレクトロニクスエンジニア（ＩＥＥＥ）又はインターネットエンジニアリングタスクフォース（ＩＥＴＦ）である。

本記述は、限定の目的のためではなく説明の目的のために、本発明の理解を提供するために、特定のコンポーネント、電気回路、技術など４つの特定の詳細を設定する。しかし、本発明が、これらの特定の詳細から逸脱しない他の実施形態において実施されてもよいことは、当業者にとって明らかである。他の霊では、よく知られた方法、装置、及び技術などの詳細な記述は、不必要な詳細によって記述が不明確にならないように省略される。それぞれの機能ブロックが１または複数の図に表される。当業者は、機能が分離したコンポーネント又はマルチ機能のハードウェアを用いて実装されてもよいことがわかるだろう。処理機能は、プログラムされたマイクロプロセッサ又は一般的な目的のコンピュータを用いて実装されてもよい。本発明は、上記の記述及び図面の実施形態に限定されず、請求項に示された範囲内で各種の変更ができる。

Claims (20)

1. コンテンツのダウンロードのためにピアツーピアネットワークにおいて適切なピア（ＣＬ１−ＣＬ５）を選択するための方法であって：
   特定されるコンテンツを処理しているピアのアドレスを要求することと；
   要求された前記アドレスを含む応答を、オペレータノード（ＭＯＮ４）へ受信することと；
   を含み、
   前記方法は、
   前記オペレータノードにとって利用可能なオペレータプリファレンスに基づいて、前記応答を修正することと；
   修正される前記応答を要求元のクライアントへ送信することと；
   を特徴とする、方法。
2. 集中型のトラッカ（Ｔ）が、アドレスについての前記要求を受信し、前記応答は、前記トラッカ（Ｔ）から前記オペレータノード（ＭＯＮ４）へ送信される、請求項１に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
3. 分散型のデータベース（ＤＤＢ）が、アドレスについての前記要求を受信し、前記応答は、前記データベース（ＤＤＢ）から前記オペレータノード（ＭＯＮ４）へ送信される、請求項１に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
4. 非構造化Ｐ２Ｐシステムが、要求された前記コンテンツを探索するために使用され、前記応答は、前記ピアツーピアネットワーク内のピア（ＣＬ１−ＣＬ５）から前記オペレータノード（ＭＯＮ４）へ送信される、請求項１に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
5. 修正された応答中には入っていない受信されるアドレスが遅延使用のためにキャッシュされる、請求項１〜４のいずれか１項に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
6. 前記要求元のクライアントは、ピアとの接続を受信される前記応答中において利用可能なアドレスを用いて確立しようとし、前記要求元のクライアントは、少なくとも１つのピアにより保持される前記コンテンツを利用することができず、
   前記方法は、前記特定されるコンテンツを処理するピアのアドレスをさらに要求することをさらに含む、
   請求項５に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
7. 遅延使用のためにキャッシュされ、少なくとも１つのアドレスを含むさらなる応答が前記要求元のクライアント（ＣＬ４）に送信される、請求項６に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
8. さらなる要求された前記アドレスを含むさらなる応答をオペレータノード（ＭＯＮ４）へ受信することと；
   前記オペレータノードにとって利用可能なオペレータプリファレンスに基づいて、前記さらなる応答を修正することと；
   修正された前記さらなる応答を前記要求元のクライアントに転送することと；
   をさらに含む、請求項６に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
9. 前記さらなる応答の修正は、遅延使用のためにキャッシュされた少なくとも１つのアドレスを含む、請求項８に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
10. 前記方法は、
    前記要求を前記オペレータノード（ＭＯＮ４）によってインターセプトする、又は取得すること；
    をさらに含む、請求項１〜９のいずれか１項に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
11. 修正は、異なるオペレータネットワーク中に位置するピア間のヒンダリングコミュニケーションを可能にする、請求項１〜１０のいずれか１項に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
12. 修正は、ピアが１つのオペレータネットワーク中のいくつかのアクセスネットワーク中に位置するときに、計測ツールを利用する、請求項１〜１１のいずれか１項に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
13. 修正は、プレミアムノードの選択のピアへの追加的なアドレスを利用する、請求項１〜１２のいずれか１項に記載の適切なピア（ＣＬ１−ＣＬ５）を選択するための方法。
14. アクセスネットワークを受信するトラフィック中における正確な優先順位付けを得るために、前記ピアツーピアネットワークから前記オペレータノード（ＭＯＮ４）に受信される特定のトラフィックがマークされる、請求項１〜１３のいずれか１項に記載の適切なピアを選択するための方法。
15. コンテンツのダウンロードのためにピアツーピアネットワークにおいて適切なピアを選択するためのノードであって：
    前記ノードは、
    要求されたコンテンツを保持するピアのアドレスを含む応答を受信する取得手段と；
    前記応答を修正し、修正は前記ノードにとって利用可能なオペレータプリファレンスに基づく処理手段と；
    修正された前記応答を要求元のクライアントに送信する手段と；
    を有する、ノード。
16. 前記ノードはさらに、
    要求を監視するインターセプション及び／又はキャプチャリング手段を有する、請求項１５に記載の、コンテンツのダウンロードのためにピアツーピアネットワークにおいて適切なピアを選択するためのノード。
17. ノードは、ネットワークパフォーマンスツールを利用可能である、請求項１５または１６のいずれかに記載の、コンテンツのダウンロードのためにピアツーピアネットワークにおいて適切なピアを選択するためのノード。
18. ノードは、受信された応答メッセージを解凍するために用いられるディープパケットインスペクションツールを利用可能である、請求項１５〜１７のいずれか１項に記載の、コンテンツのダウンロードのためにピアツーピアネットワークにおいて適切なピアを選択するためのノード。
19. ノードは、追加的に分配されるタグ付け機能を利用することにより、アクセスネットワークを受信しているトラフィックを通して正確な優先順位付けを得るために、特定のトラフィックをマークすることができる。
20. コンテンツのダウンロードのためにピアツーピアネットワークにおいて適切なピア（ＣＬ１−ＣＬ５）を選択するために具体化された、コンピュータが読み取り可能なコードを有するプログラム記憶媒体を含む製造項目であって：
    コンピュータに読み取り可能なプログラムコードは、
    特定されるコンテンツを処理しているピアのアドレスを要求するためのコンピュータに読み取り可能なプログラムコードと；
    要求された前記アドレスを含む応答をオペレータノード（ＭＯＮ４）に受信するためのコンピュータに読み取り可能なプログラムコードと；
    前記オペレータノードにとって利用可能なオペレータプリファレンスに基づいて、前記応答を修正するためのコンピュータに読み取り可能なプログラムコードと；
    修正された前記応答を要求元のクライアントに送信するためのコンピュータに読み取り可能なプログラムコードと；
    を含む、コンピュータに読み取り可能なプログラムコード。
    

Images