JP2010533321A - ピアツーピア・ライブストリーミングのための待ち行列に基づく適応型チャンク・スケジューリング - Google Patents

Abstract

ピアからメッセージを受信し、受信メッセージを分類し、分類されたメッセージを該分類に基づいて複数の待ち行列の１つに格納し、分類されたメッセージが格納された待ち行列の優先順位に基づいてメッセージへの応答を生成し、ピアツーピア・ネットワーク内の全ピアにコンテンツを送信するピアツーピア・ネットワークにおけるコンテンツ配信スケジューリング方法及び装置が開示される。また、コンテンツソースサーバ及びピアの１つからメッセージ及びコンテンツの一方を受信し、受信メッセージを分類し、分類されたメッセージを該分類に基づいて複数の待ち行列の１つに格納し、受信コンテンツを格納し、分類されたメッセージが格納された待ち行列の優先順位に基づいてメッセージへの応答を生成し、ピアツーピア・ネットワーク内の他の全ピアにコンテンツを送信するピアツーピア・ネットワークにおけるコンテンツ配信スケジューリング方法及び装置が開示される。

Description

本発明は、ピアツーピア・ネットワークにおいてコンテンツの配信を計画することに関し、特に、ピアツーピア・ネットワークにおいてライブストリーミング速度を最大化する、待ち行列（キュー）ベースのスケジューリング方法及び装置に関する。

これまでの取り組みにより、ピアツーピア（Ｐ２Ｐ）ライブストリーミングシステムにおける最大のビデオストリーミング速度は、ビデオソースサーバの容量、システム内のピア数、及び全てのピアの集合的なアップロード能力によって決定されることが示されている。

従来技術に係る集中型スケジューリング方法においては調整役（コーディネータ）がシステムを管理する。コーディネータはピアのアップロード能力及びソースのアップロード能力に関する情報を集める。そして、コーディネータは、集中型スケジューリング方法に基づいて、ソースから個々のピアの各々への伝送速度を計算する。

高いストリーミング速度を達成できることが、Ｐ２Ｐライブストリーミングにとって望ましい。ストリーミング速度が高いほど、システムがより良好な品質でブロードキャストを行うことが可能になる。より高いストリーミングはまた、固定ビットレート（constant bit rate；ＣＢＲ）のビデオがブロードキャストされるとき、ピアの揺れ動き及びネットワークの混雑によって引き起こされる帯域幅変動を吸収する一層大きいクッション（衝撃を和らげるもの）を提供する。高ストリーミング速度を達成する上で鍵となるのは、より良好にリソースを活用することである。

Ｐ２Ｐネットワークに参入する新たなピア、欠落コンテンツの復元、及び更なるコンテンツの要求に対処するための優先順位付け方式を含んだ、Ｐ２Ｐネットワークにおいてコンテンツ配信をスケジューリングする方法及び装置を有することが有利となる。

本発明は、コンテンツのＰ２Ｐライブストリーミングシステム用の、待ち行列に基づくスケジューリング方法を提供することを目的とする。ここで用いられるように、コンテンツはビデオ、オーディオ、又は何らかのその他のマルチメディア型データ／情報とし得る。ここで用いられるように、“／”は同一あるいは同様の構成要素の別名を表す。本発明に係る待ち行列ベースのスケジューリング方法は、集中型コーディネータを用いることなく、最大のストリーミング速度を達成する。

理想的には、Ｐ２Ｐシステム／ネットワークにおいて、ピアはその他のピアと情報を交換し、局所的（ローカル）に決定を行うのみである。故に、理想的には、中央のコーディネータは必要とされず、全体的（グローバル）な情報は収集されない。また、実際に利用可能なアップロード能力は時間とともに変化する。このことは、中央のコーディネータが各ピアのアップロード能力を継続的に監視し、個々のピアへのサブストリーム速度を継続的に再計算することを必要とする。従って、分散型のスケジューリング方法が望ましい。困難なのは、依然としてシステムの全体最適、すなわち、最大ストリーミング速度を達成することが可能な分散型（ローカル）スケジューリング方法をどのように設計するかである。

本発明に係る待ち行列ベースのスケジューリング方法において、各ピアは、サーバから直接的に取得したコンテンツをシステム内のその他全てのピアにアップロードする。ピアはピアツーピア・システム内のノードである。全てのピアのアップロード能力の利用率を１００％に近付けるため、相異なるピアがサーバから相異なるコンテンツをダウンロードし、ピアがコンテンツソースサーバからコンテンツをダウンロードする速度は、そのアップロード能力に比例する。ピアは、コンピュータ／プロセッサ、ノート型コンピュータ、携帯情報端末、移動式端末、又は例えばセットトップボックス等の再生装置を含むノードとし得る。コンテンツソースサーバは、ここではソースやサーバとも称され、ピアツーピア・システム／ネットワーク内のピアにコンテンツを供給する如何なる装置又はシステムをも含む。

ここでは、用語“アップロード”は、活動中のノードから離れ行く流れを指し示すように使用される。ただし、この活動中のノードというのは、ピアツーピア・ネットワーク内のサーバ又は複数のピアのうちの１つとし得る。対応して、ここでは、用語“ダウンロード”は、活動中のノードに向かう流れを指し示すように使用される。ただし、この活動中のノードというのは、ピアツーピア・ネットワーク内のサーバ又は複数のピアのうちの１つとし得る。

本発明は、ピア及びソースが、ソースとピアとの間で交換される情報に基づいて決定を行うローカルなスケジューリング方法を実行する分散型スケジューリング方法に関する。中央コーディネータは必要とされず、グローバル情報も収集される必要がない。本発明に係る待ち行列ベースの分散型スケジューリング方法は、Ｐ２Ｐライブストリーミングシステムにおけるストリーミング速度の理論的な上限値を達成することができる。

ピアからのメッセージを受信することと、受信したメッセージを分類することと、分類されたメッセージを、該分類に基づいて、複数の待ち行列のうちの１つに格納することと、分類されたメッセージが格納された待ち行列の優先順位に基づいて、メッセージへの応答を生成することと、ピアツーピア・ネットワーク内の全てのピアにコンテンツを送信することとを含む、ピアツーピア・ネットワークにおいてコンテンツ配信をスケジューリングする方法及び装置が開示される。また、コンテンツソースサーバ及びピアのうちの１つから、メッセージ及びコンテンツのうちの一方を受信することと、受信したメッセージを分類することと、分類されたメッセージを、該分類に基づいて、複数の待ち行列のうちの１つに格納することと、受信したコンテンツを格納することと、分類されたメッセージが格納された待ち行列の優先順位に基づいて、メッセージへの応答を生成することと、ピアツーピア・ネットワーク内のその他全てのピアにコンテンツを送信することとを含む、ピアツーピア・ネットワークにおいてコンテンツ配信をスケジューリングする方法及び装置が開示される。

本発明は、以下の詳細な説明を添付の図面に関連付けて読むことにより十分に理解される。図面はここで簡単に説明する以下の図を含む。
従来技術に係るスケジューリング方法において、データの相異なる部分が３つの異種ノード間でどのようにスケジューリングされるかの一例を示す図である。 １つのソースサーバ及び３つのピアを有する、待ち行列ベースのチャンク・スケジューリングを用いるピアツーピア・ストリーミングシステムを示す図である。 本発明原理に従った待ち行列ベースのスケジューリング方法におけるピアの待ち行列モデルを示す図である。 本発明原理に従った待ち行列ベースのスケジューリング方法のサーバ側の待ち行列モデルを示す図である。 本発明原理に従ったピア転送待ち行列モデルの信号閾値を示す図である。 本発明原理に従ったコンテンツソースサーバのアーキテクチャを例示する図である。 本発明原理に従った４つの待ち行列を有する典型的な出力ユニットを示す図である。 本発明原理に従ったピアのアーキテクチャを示す図である。 本発明原理に従ったピア側の出力ユニットの構造を示す図である。 本発明原理に従ったピア内の再生バッファを示す図である。 本発明原理に従った、ピアがＰ２Ｐネットワークに参入する典型的な一手法を示すフローチャートである。 図１１Ｂとともに、コンテンツソースサーバの観点から本発明に係る待ち行列ベースのスケジューリング方法を示すフローチャートである。 図１１Ａとともに、コンテンツソースサーバの観点から本発明に係る待ち行列ベースのスケジューリング方法を示すフローチャートである。 図１２Ｂとともに、ピア／ノードの観点から本発明に係る待ち行列ベースのスケジューリング方法を示すフローチャートである。 図１２Ａとともに、ピア／ノードの観点から本発明に係る待ち行列ベースのスケジューリング方法を示すフローチャートである。

従来技術において、既知のアップロード能力を有するコンテンツソースサーバ及び一組のピアを仮定すると、最大のストリーミング速度ｒ^ｍａｘは次の公式：

に支配されることが示されている。ただし、ｕ_ｓはコンテンツソースサーバのアップロード能力であり、ｕ_ｉはピアｉのアップロード能力であり、ｎ個のピアがシステム内に存在する。従来技術は、上述のストリーミング速度の最大値／上限を達成することができる集中型スケジューリング方法を提案している。従来技術に係るスケジューリング方法は、システムを管理するコーディネータを有する集中型の手法を用いる。コーディネータは、各ピアのアップロード能力及びコンテンツソースのアップロード能力に関する情報を収集する。そして、コーディネータは、集中型スケジューリング方法に基づいて、コンテンツソースから個々のピアへの伝送速度を計算する。各ピアは受信したストリーミングコンテンツの一部をその他全てのピアに中継する。

本発明を関連付けて筋道を通すため、先ず、コンテンツソースからピアへのストリーミング速度をどのように計算するかを説明する。その後、本発明に係る待ち行列ベースのスケジューリング方法を説明する。本発明に係る待ち行列ベースのスケジューリング方法は、中央のコーディネータを必要とせずして最大のストリーミング速度を達成することができる。

Ｐ２Ｐシステムにおける最大ストリーミング速度は等式（１）に支配される。等式の右辺の第２項である

は、ピア当たりの平均アップロード能力である。集中型スケジューリング方法は、コンテンツソースのアップロード能力とピア当たりの平均アップロード能力との間の関係に基づいて異なる振る舞いをする。

２つの典型的なケース／状況を考える。第１のケースにおいて、コンテンツソースサーバのアップロード能力はピアのアップロード能力の平均値より小さく、第２のケースにおいて、コンテンツソースサーバのアップロード能力はピアのアップロード能力の平均値より遙かに大きい。第１の状況においてコンテンツソースサーバはリソース不足であり、第２の状況においてコンテンツソースサーバのリソースは豊富（リソースリッチ）である。

ケース１：

最大のストリーミング速度はｒ^ｍａｘ＝ｕ_ｓである。コンテンツストリームは、ｉ番目のサブストリームが、

の速度を有するｎ個のサブストリーム（各ピアに対し１つのサブストリーム）に分割される。なお、ｎ個のサブストリームを総計した速度は最大ストリーミング速度に等しい。すなわち、

である。

コーディネータはサーバにｉ番目のサブストリームをｉ番目のピアに送信するよう要求する。また、（ｎ−１）ｓ_ｉ≦ｕ_ｉであるため、ｉ番目のピアはこのサブストリームをその他のｎ−１個のピアの各々に送信する。故に、各ピアは１つのサブストリームをサーバから直接的に受信するとともに、その他のｎ−１個のピアからｎ−１個の更なるサブストリームを受信する。ピアｉがストリーム全体（ｎ個全てのサブストリーム）を受信する合計速度は、

である。従って、最大速度ｒ^ｍａｘ＝ｕ_ｓを担保することができる。

ケース２：

ここで、

である。コンテンツストリームは、ｉ＝１，２，・・・，ｎ＋１として、ｉ番目のサブストリームが速度ｓ_ｉ＝ｕ_ｉ／（ｎ−１）を有し且つ（ｎ＋１）番目のサブストリームが速度

を有するｎ＋１個のサブストリームに分割される。

明らかなように、全てのｉ＝１，２，・・・，ｎ＋１に対し、ｓ_ｉ≧０である。この場合、サーバは、ｉ番目のサブストリームと（ｎ＋１）番目のサブストリームとの２つのサブストリームを各ピアｉに送信する。サーバがこれを行うことができるのは、

であるからである。また、ピアｉは、ｉ番目のサブストリームの複製をｎ−１個のその他のピアの各々にストリーミングする。各ピアがこれを行うことができるのは、（ｎ−１）ｓ_ｉ＝ｕ_ｉであるからである。ピアｉがストリーム全体（ｎ個全てのサブストリーム）を受信する合計速度は、

である。従って、最大速度

を担保することができる。

図１Ａは、従来技術に係るスケジューリング方法において、データの相異なる部分が３つの異種ノード間でどのようにスケジューリングされるかの一例を示している。このシステムには３つのピアが存在する。サーバは６の能力を有する。ａ、ｂ及びｃのアップロード能力は、それぞれ、２、４及び６である。全てのピアが十分なダウンロード能力を有すると仮定すると、このシステムにおいて対応され得る最大のコンテンツライブストリーミング速度は６である。この速度を達成するため、サーバはコンテンツの塊（チャンク）群を６からなる複数のグループに分割する。ピアａは各グループからの１つのチャンクをその他のピアの各々にアップロードすることを担い、ｂ及びｃは、それぞれ、各グループ内の２個及び３個のチャンクをその他のピアの各々にアップロードすることを担う。斯くして、全てのピアの総計ダウンロード速度は、サーバのダウンロード能力である６という最大速度になる。このようなスケジューリング方法を実現するため、中央のコーディネータは、アップロード能力情報を収集して該スケジューリング方法を実行することを要求される。また、各ピアは接続を維持し、システム内のその他全てのピアとコンテンツを交換する必要がある。さらに、サーバは、ビデオストリームを、ピアごとに異なる速度を有する複数のサブストリームに分割する必要がある。

次に、本発明に係る待ち行列ベースのスケジューリング方法を説明する。集中型コーディネータを用いることなく最大ストリーミング速度を達成することができる。本発明に係る分散化されたスケジューリング方法は、待ち行列に基づく適応型チャンク・スケジューリング方法である。

理想的には、Ｐ２Ｐシステムにおいて、ピアはその他のピアと情報を交換し、ローカルに決定を行うのみである。故に、理想的には、中央のコーディネータは必要とされず、グローバルな情報は収集されない。また、実際に利用可能なアップロード能力は時間とともに変化する。このことは、中央のコーディネータが各ピアのアップロード能力を継続的に監視し、個々のピアへのサブストリーム速度を継続的に再計算することを必要とする。従って、分散型のスケジューリング方法が望ましい。困難なのは、依然としてシステムの全体最適、すなわち、最大ストリーミング速度を達成することが可能な分散型（ローカル）スケジューリング方法をどのように設計するかである。本発明に係る待ち行列ベースの分散型スケジューリング方法はこの目的に適うものである。

図１Ｂは、１つのソースサーバ及び３つのピアを有する、待ち行列ベースのチャンク・スケジューリングを用いるピアツーピア・ストリーミングシステムを示している。各ピアは、転送キューを含む幾つかの待ち行列を管理する。次に、ピアａを例にとり、信号及びデータの流れを説明する。ステップ／活動を囲み数字で指し示す。ピアａの待ち行列が空（エンプティ）になる（閾値を下回る）と常に、ピアａからサーバに‘プル（pull）’信号が送信される（ステップ１）。サーバは、３つのデータチャンクをピアａに返送することによって‘プル’信号に応答する（ステップ２）。これらのチャンクはピアａの転送キューに格納され（ステップ３）、ピアｂ及びピアｃに中継／転送／送信される（ステップ４）。サーバがその‘プル’信号キュー上の全ての‘プル’信号への応答を済ませたとき、サーバは１つの複製データチャンクを全てのピアに転送／送信する（ステップ５）。これらのデータチャンクはピアの転送キューに格納されず、更に中継されることもない。

図２は、本発明に係る待ち行列ベースのスケジューリング方法におけるピアの待ち行列モデルを示している。ピアは、ソースサーバ及びその他のピアからの全ての受信ストリーミングコンテンツを格納する再生バッファを管理する。異なるノードからの受信コンテンツは、再生バッファ内で再生順に集められる。ピアのメディアプレーヤは、このバッファからのコンテンツをレンダリング／表示する。同時に、ピアは、その他全てのピアにコンテンツを転送するために使用される転送キューを管理する。受信コンテンツは、Ｆマークを付されたコンテンツとＮＦマークを付されたコンテンツとの２つの種類に分割される。Ｆ（転送）は、その他のピアに中継／転送されるべきコンテンツを表す。ＮＦ（非転送）は、そのピアのみを対象とし、転送することが要求されないコンテンツを指し示す。隣接ピアによって転送されたコンテンツは常にＮＦとしてマークを付与される。ソースサーバから受信したコンテンツは、Ｆ又はＮＦの何れかとしてマークを付与され得る。ＮＦコンテンツはフィルタリングされて除外される。Ｆコンテンツは転送キューに格納され、その他のピアに転送されることになる。ピアのアップロード能力を完全に活用するため、ピアの転送キューはエンプティにならないように保たれるべきである。転送キューがエンプティになるときは常に、より多くのコンテンツを要求するために信号がソースサーバに送られる。ここでは、これを‘プル’信号と称する。次に、コンテンツソースサーバにおいてコンテンツにマークを付与するための規則を説明する。

図３は、本発明に係る待ち行列ベースのスケジューリング方法のサーバ側の待ち行列モデルを例示している。ソースサーバは、コンテンツキューと信号キューという２つの待ち行列を有する。コンテンツキューは、Ｆマークを付されたコンテンツ発送部と転送発送部という２つの発送部を有するマルチサーバ待ち行列である。起動される発送部は‘プル’信号キューの制御／状態に依存する。具体的には、信号キュー内に‘プル’信号が存在する場合、コンテンツバッファからコンテンツの小さい塊（チャンク）が取り出される。このコンテンツチャンクはＦとしてマーク付けされ、Ｆマークを付されたコンテンツ発送部によって、‘プル’信号を発したピアに発送される。その後、その‘プル’信号は‘プル’信号キューから除去される。信号キューがエンプティである場合、サーバはコンテンツバッファからコンテンツの小さいチャンクを取り出し、そのコンテンツチャンクを発送すべく転送キューに置く。転送発送部はそのチャンクをＮＦとしてマーク付けし、それをシステム内の全てのピアに送信する。

次に、本発明に係る待ち行列ベースのデータチャンクスケジューリング方法の最適性を示す。すなわち、ピア側及びサーバ側の双方の待ち行列ベースのスケジューリング方法は、等式（１）によって示されたシステムの最大Ｐ２Ｐライブストリーミング速度を達成する。

定理：ピアとサーバとの間での信号伝搬遅延は無視でき、且つデータコンテンツは任意の小さい量にて送信されることができると仮定すると、上述の待ち行列ベースの分散型スケジューリングアルゴリズムは、そのシステム内で可能な最大のストリーミング速度を達成する。

証明：コンテンツが小さいチャンクに分割されることを想定する。コンテンツソースサーバは、‘プル’信号にサービスを提供する度に１つのチャンクを送出する。ピアは、該ピアの転送キューがエンプティになるとき常に、サーバに対して‘プル’信号を発する。δはチャンクのサイズを表すとする。

ピアｉにおいて、１つのデータチャンクを全てのピアに転送するのに（ｎ−１）δ／ｕ_ｉの時間を要する。‘プル’信号がピアｉによって発せられる最大速度をｒ_ｉとする。従って、ｒ_ｉ＝ｕ_ｉ／（ｎ−１）δである。

サーバによって受信される‘プル’信号の最大総計速度ｒは、

である。１つの‘プル’信号にサービス提供するのにサーバのδ／ｕ_ｓ時間を要する。従って、サーバが受け入れることが可能な最大‘プル’信号速度はｕ_ｓ／δである。ここで、以下の２つの状況／ケースを考える。

ケース１：

この状況において、サーバは最大‘プル’信号速度に対処することができない。故に、サーバ側の信号キューは決してエンプティではなく、Ｆマーク付きコンテンツをピアに送信するためにサーバの帯域幅全体が使用される。対照的に、ピアの転送キューは、ソースサーバからの新たなデータコンテンツを待つ間、アイドリング状態になる。各ピアは（サーバから受信した）Ｆマーク付きコンテンツをその他全てのピアに中継するのに十分なアップロード帯域幅を有するので、ピアは、サーバによって送出されたコンテンツを最大速度で受信する。

対応可能なストリーミング速度はサーバのアップロード能力に等しい。条件：

は、

すなわち、上述のサーバがリソース不足である状況に等価である。従って、ストリーミング速度は等式（１）に一致し、最大ストリーミング速度が到達される。

ケース２：

この状況において、サーバは、‘プル’信号に最大速度でサービス提供するアップロード能力を有する。‘プル’信号キューがエンプティである期間中、サーバは複製のＮＦマーク付きコンテンツを全てのピアに送信する。Ｆマーク付きコンテンツを提供するために使用されるアップロード能力の量は、

である。

ＮＦマーク付きコンテンツを提供するために使用されるサーバのアップロード帯域幅は、故に、

である。個々のピアの各々において、サーバからのＮＦマーク付きコンテンツを受信する速度は、

である。システム内にｎ個のピアが存在するので、それらのピアで対応可能なストリーミング速度：

である。条件：

は、

すなわち、上述のサーバがリソースリッチである状況に等価である。この場合も、ストリーミング速度は等式（１）に示された上限に到達する。

なお、総計の‘プル’信号到達速度がサーバのサービス速度より低い場合であるケース２において、ピアは‘プル’信号を発した直後にＦマーク付きコンテンツを受信すると仮定されている。この仮定は、‘プル’信号が如何なる待ち行列遅延にも遭遇せず、コンテンツソースサーバによって直ちにサービス提供されることができる場合においてのみ正しい。これは、（ｉ）如何なる２つの‘プル’信号も厳密なる同一時刻に到着せず、且つ（ｉｉ）‘プル’信号が次の到来‘プル’信号の到着前にサービス提供されることができることを意味する。仮定（ｉ）は待ち行列理論において広く用いられており、Ｐ２Ｐシステムはピアが‘プル’信号を生成することに関して分散型のシステムであるので妥当である。２つの‘プル’信号が厳密なる同一時刻に到着する確率は低い。仮定（ｉｉ）は、データが任意の小さい量で送信され得ること、すなわち、データチャンクのサイズδが任意に小さくされ得ることを意味する。実際には、データ伝送に伴うオーバヘッドを低減するために、データチャンクのサイズは制限される。

次に、上述の方式を実際に実現する際の実装上の検討事項を説明する。ここでは、本発明に係る待ち行列ベースのデータチャンクスケジューリング方法を用いるコンテンツソースサーバ及びピアのアーキテクチャを、チャンクサイズ、ネットワークの混雑及びピアの揺れ動きの影響を含む実際の実装上の検討事項に目を向けて説明する。

最適性の証明においては、チャンクサイズは任意に小さくでき且つ伝搬遅延は無視できると仮定した。実際には、チャンクサイズは、プロトコルヘッダによって生ずる過剰な伝送オーバヘッドを回避するため、桁にしてキロバイトのオーダーである。伝搬遅延は桁にして１０ｍｓから１００ｍｓのオーダーである。従って、本発明に係る待ち行列ベースのスケジューリング方法が最大ストリーミング速度の近くまで達成することを可能にするには、ピアによる‘プル’信号の発信タイミングを調整し、コンテンツソースサーバにて提供されるＦマーク付きチャンクの数を増大させることが必要である。

サーバ側において、要求ピアからの‘プル’信号に応答して、Ｋ個のＦマーク付きチャンクが１つのバッチとして送信される（Ｆマーク付きコンテンツキューを介する）。Ｋの値が大きいほど、‘プル’信号の頻度を低減させ、故に、信号伝達のオーバヘッドを低減させることになる。しかしながら、これはピアの始動遅延を増大させる。‘プル’信号キューがエンプティであるとき、サーバの転送キューは一度に１つのチャンクをシステム内の全てのピアに転送する。新たな‘プル’信号の到着は、転送キューの活動を阻止し、Ｆマーク付きコンテンツキューが直ちにＫ個のチャンクを提供する。

ここで図４を参照するに、ピア側において、ピアは転送キューの閾値Ｔ_ｉを設定する。このキュー内のコンテンツチャンクの数がＴ_ｉ以下であるとき、‘プル’信号が発せられる。Ｆマーク付きコンテンツをサーバから取り出すのには上記伝搬遅延の少なくとも２倍を要する。転送キューが完全にエンプティになる前に‘プル’信号を発することにより、アップロード能力を無駄にすることが回避される。

次に、Ｔ_ｉの値を適切に設定する方法を検討する。Ｔ_ｉ個のチャンクを有する転送キューをエンプティにする時間（ｔ_ｉ ^{ｅｍｐｔｙ}）は、ｔ_ｉ ^{ｅｍｐｔｙ}＝（ｎ−１）Ｔ_ｉδ／ｕ_ｉである。一方、ピアｉが‘プル’信号を発した後にＫ個のチャンクを受信するのに、ｔ_ｉ ^{ｒｅｃｅｉｖｅ}＝２ｔ_ｓｉ＋Ｋδ／ｕ_ｓ＋ｔ_ｑを要する。ただし、ｔ_ｓｉはコンテンツソースサーバとピアｉとの間での伝搬遅延であり、Ｋδ／ｕ_ｓはサーバがＫ個のチャンクを送信するのに要する時間であり、ｔ_ｑはサーバの‘プル’信号キューにおける‘プル’信号から見た待ち行列遅延である。転送キューが完全に排出された状態になる前にチャンクを受信するためには、ｔ_ｉ ^{ｅｍｐｔｙ}≧ｔ_ｉ ^{ｒｅｃｅｉｖｅ}である。これは、
Ｔ_ｉ≧（２ｔ_ｓｉ＋Ｋδ／ｕ_ｓ＋ｔ_ｑ）ｕ_ｉ／（ｎ−１）δ （２）
をもたらす。

サーバ側の‘プル’信号キューで被る待ち行列遅延ｔ_ｑを除いて、全ての量が既知である。コンテンツソースサーバがボトルネックである（コンテンツソースサーバがリソース不足である）ケース１において、サーバが常にビジーである限り、Ｔ_ｉの選択はストリーミング速度に影響を及ぼさないことになる。ケース２においては、信号キューのサービス速度が‘プル’信号速度より速いため、ｔ_ｑは非常に小さい。故に、ｔ_ｑはゼロに設定することができ、すなわち、
Ｔ_ｉ≧（２ｔ_ｓｉ＋Ｋδ／ｕ_ｓ）ｕ_ｉ／（ｎ−１）δ （３）
となる。

次に、ピアの始動遅延を計算する。始動遅延をτで表す。ピアがＴ_ｉ個のマーク付きチャンクで満杯の待ち行列を有すると仮定すると、チャンクをその他全てのピアに送信するのに、
Ｔ_ｉδ（ｎ−１）／ｕ_ｉ＝２ｔ_ｓｉ＋Ｋδ／ｕ_ｓ （４）
を要する。なお、この待ち行列を一掃するために要する時間は全てのピアで同一である。この時間中、ピアはその他のピアからの格納されたチャンクを受信することができる。従って、始動遅延はτ＝２ｔ_ｓｉ＋Ｋδ／ｕ_ｓである。

コンテンツソースサーバは、ピアからの‘プル’信号に応答し、ＮＦマーク付きコンテンツをピアへと積極的に押し出す。コンテンツソースサーバはブートストラップ・ノードでもある。ブートストラップ・ノードとして、コンテンツソースサーバはまた、ピア情報（例えば、ピアｉｄ、ＩＰアドレス、ポート番号など）を管理し、入来する新たなピアからのピアリストの要求に応答する。

図５は、コンテンツソースサーバのアーキテクチャを例示している。待ち行列ベースの適応型Ｐ２Ｐライブストリーミングにおいて、サーバ及び全てのピアは、全二重通信制御プロトコル（ＴＣＰ）接続を用いて完全に接続される。ピアとの接続を監視するために‘選択呼び出し’機構（又は、コンテンツを監視する、あるいは監視し得る何らかの等価な手段）を用いて、サーバは、受信データを格納する一組の入力バッファを管理する。サーバ側における到来メッセージには、管理メッセージ、‘プル’信号、及び欠落チャンク復元要求という３つの種類が存在する。従って、これらのメッセージのそれぞれに対応する３つの独立した待ち行列が形成される。これらのメッセージを処理することの出力が遠隔ピアに送信される必要がある場合、該出力は送信されるべく、ピアごとの出力ユニット上に置かれる。

データ送信処理を取り扱うために各宛先ピアに対して１つの出力ユニットが存在する。図６は、所与／特定のピアに対して、管理メッセージキュー、Ｆマーク付きコンテンツキュー、ＮＦマーク付きコンテンツキュー、及び欠落チャンク復元キューという４つの待ち行列を典型的な出力ユニットを示している。管理メッセージキューは管理要求への応答を格納する。管理要求の一例は、新たなピアがまさにＰ２Ｐシステムに参入したときにピアリストを要求するものである。サーバは、ピアリストを返送することによって応答する。Ｆ／ＮＦマーク付きコンテンツキューは、このピアに向けられたＦ／ＮＦマーク付きコンテンツを格納する。そして、チャンク復元キューはこのピアによって要求された欠落チャンクを格納する。

トラフィックの種類に優先順位を付けるため、異なる種類のトラフィックには異なる待ち行列が使用される。具体的には、管理メッセージは最高の優先順位を有し、Ｆマーク付きコンテンツ及びＮＦマーク付きコンテンツがそれに続く。復元チャンクの優先順位は設計上の要求に基づいて調整され得る。管理メッセージはシステムがスムースに作動するために重要であるので最高の優先順位を有する。例えば、管理メッセージに最高の優先順位を与えることにより、新たなピアがシステムに参入するための遅延が短縮される。新たなピアがＰ２Ｐシステムに参入するためにコンテンツソースサーバに要求を発するとき、ピアリストがこの新／参入ピアに迅速に送信され得る。また、管理メッセージは典型的に、コンテンツメッセージと比較してサイズが小さい。最高の優先順位を管理メッセージに与えることにより、全体的な平均遅延が短縮される。コンテンツソースサーバは、各‘プル’信号にＫ個のＦマーク付きチャンクで応答する。Ｆマーク付きチャンクは更に、受信ピアによってその他のピアに中継される。コンテンツソースサーバは、‘プル’信号キューがエンプティであるとき、全てのピアにＮＦマーク付きチャンクを送出する。ＮＦマーク付きチャンクは宛先ピアのみによって使用され、更には中継されない。故に、Ｆマーク付きチャンクを遅滞なく供給することは、ピアのアップロード能力の利用率を向上させ、全体的なＰ２Ｐシステムのライブストリーミング速度を増大させる。復元チャンクの検索及び供給は、欠落チャンクは表示品質に有意に影響を及ぼすため、ＮＦマーク付きチャンクの送達より高い優先順位であるべきである。復元チャンクを転送することの優先順位がＦマーク付きチャンクのそれより高く設定される場合、表示品質はシステム効率より優先的な取扱を受ける。対照的に、Ｆマーク付きチャンクの方が高い優先順位を受け取る場合には、システム効率の方が高い優先順位を与えられる。選択される優先順位付け方式はシステムの設計目標に依存する。

別々の待ち行列を用いる他の１つの理由は、ネットワーク内の帯域幅の揺らぎ及び混雑に対処することである。数多くのＰ２Ｐの研究者によって、サーバ／ピアのアップロード能力がボトルネックであると見なされている。ＰｌａｎｅｔＮｅｔ上での最近の実験において、一部のピアが混雑によって有意に低速化され得ることが観察されている。全てのピアが同一の待ち行列を共有する場合、最も低速のピアへのアップロードが残りのピアへのアップロードを妨害することになる。サーバのアップロード帯域幅が浪費されることになる。これは、入力キュー型のスイッチ設計における、混雑した出力ポート宛てのパケットによって入力キューが詰まってしまうというヘッド・オブ・ライン（head-of-line）ブロッキング問題に似ている。このスイッチング問題は、相異なる出力ポート宛てのパケットを相異なる仮想出力キューに配分することによって解決された。故に、相異なるピアに別々の待ち行列を用いることによって、同様の解決策が採用される。別々の待ち行列により、低速のピアによって引き起こされる非効率な妨害が回避される。別々の待ち行列はまた、待ち行列に入れられたコンテンツの量の一層正確な推定を可能にする。これは、何時に‘プル’信号を発するべきかをピアが決定することにとって重要である。

次に図７を参照するに、ピアのアーキテクチャが示されている。ここで説明するＰ２Ｐシステム内のピアのアーキテクチャは、コンテンツソースサーバのそれと同様である。サーバ及び全てのピアは、全二重ＴＣＰ接続で完全に接続される。ピアは受信したチャンクを再生バッファに格納する。サーバからの管理メッセージ（例えば、ピアのリスト）又はその他のピアからの管理メッセージ（欠落チャンク復元メッセージ）は管理メッセージキューに格納される。チャンク処理モジュールがＮＦマーク付きチャンクをフィルタリングして除外する。Ｆマーク付きチャンクはその他全てのピアの出力ユニット内に複製される。

図８は、ピア側の出力ユニットの構造を示している。該出力ユニットは、管理メッセージキュー、転送キュー及び復元チャンクキューという３つの待ち行列を有する。転送キュー内のチャンクはＮＦとしてマークを付され、受信したピアにおいて更には中継されない。‘プル’信号の発信するものはこの出力ユニットを監視し、何時に‘プル’信号をコンテンツソースサーバに発するべきかを決定するための、式（２）にて上述した、待ち行列の閾値を決定する。式（２）に従って‘プル’信号の閾値を計算するとき、基礎となる前提は、遠隔ピアは単一のキューを用いてラウンドロビン的に扱われるというものである。実際には、ネットワーク内の帯域幅の揺らぎ及び混雑により、１つの宛先ピアの低速化が処理全体に影響を及ぼす。従って、ピア当たり１つの待ち行列設計が使用される。転送キューのサイズの平均値が式（２）に用いられる。或るピアが常に低速接続を被る場合、一部のチャンクは強制的に切り捨てられ得る。ピアはこの欠落を回復するべく欠落チャンク復元機構を用いなければならない。

ピアの揺れ動き及びネットワークの混雑はチャンクの欠落を引き起こすことがある。例えばノード又は接続の故障などの突然のピアの離脱は、ピアの出力ユニット内に依然としてバッファリングされているチャンクを再スケジューリングするための時間をシステムに残していかない。一部の宛先へのネットワーク経路が混雑している場合、送信されることを待っているチャンクは出力ユニット内で待ち行列をオーバーフローさせることがあり、それにより、受信端におけるチャンクの欠落をもたらし得る。本発明に係る欠落チャンク復元方式は、ピアが表示品質の低下を回避するように欠落チャンクを復元することを可能にする。

図９を参照するに、再生バッファが示されている。各ピアは、サーバ又はその他のピアから受信したビデオチャンクを格納するために再生バッファを管理する。再生バッファは、再生ウィンドウ、復元ウィンドウ及びダウンロードウィンドウという３つのウィンドウを管理する。再生ウィンドウ、復元ウィンドウ及びダウンロードウィンドウのサイズ（チャンク数の単位）を、それぞれ、Ｗ_ｐ、Ｗ_ｒ及びＷ_ｄで表す。再生ウィンドウからのコンテンツはメディアプレーヤによってレンダリング／表示される。復元ウィンドウ内の欠落チャンクは後述の方法を用いて復元される。そして、ダウンロードウィンドウ内のチャンクは、サーバとその他のピアとの間で引き出されたり押し出されたりする。ダウンロードウィンドウのサイズＷ_ｄは、以下のように見積もることができる：

ただし、Ｒは等式（１）に示されたシステムのストリーミング速度であり、τは始動遅延である。この等式の第１項は、全てのピアにおける格納された全てのＦマーク付きチャンクの合計である。第２項は、サーバによって送出されたＮＦマーク付きチャンクの数である。ダウンロードウィンドウのサイズは始動遅延の関数である。直観的に、ダウンロードウィンドウ内の全てのチャンクを受信するには始動遅延の時間を要する。ダウンロードウィンドウ内のチャンクは、各ピアの出力ユニットから並行して送出されるので、バラバラの順序で到着する。このことは、始動遅延時間が少なくともτであることの説明となる。実際には、始動遅延は、再生ウィンドウ及び復元ウィンドウにより導入される時間を受け入れるように増大されなければならない。

欠落チャンクを復元するために経験則が用いられる。ピアが上品に立ち去る場合、サーバに通知され、出力ユニット内で待機しているＦマーク付きチャンクはその他のピアに割り当てられる。復元ウィンドウに入ってくる欠落チャンクは以下のようにして復元される。先ず、復元ウィンドウは更に４つのサブウィンドウに分割される。欠落チャンクが再生ウィンドウに時間的に最も近いウィンドウ内にある場合、ピアはチャンク復元メッセージをソースサーバに直接的に送信する。これらのチャンクは至急必要とされ、あるいは、これらのチャンクが時間内に受信されないとコンテンツ品質に影響が及ぶからである。その他のピアからのその他３つのサブウィンドウ内の欠落チャンクを復元することが試みられる。ピアは、ピアリストから３つの復元ピアをランダムに選択し、各ウィンドウに１つを関連付ける。復元チャンクを必要とするピアは、チャンク復元メッセージを対応する復元ピアに送信する。復元ピアをランダムに選択することにより、復元作業の負荷が全てのピアに等しく分散される。

図１０は、ピアがＰ２Ｐネットワークに参入する典型的な一手法を示すフローチャートである。段階１００５にて、新／参入ピアはコンテンツソースサーバに連絡し、Ｐ２Ｐシステム／ネットワークに参入するための許可を要求する。参入ピアの要求及びコンテンツソースサーバによる参入ピアの受理を受けて、コンテンツソースサーバは参入ピアに、ネットワーク内の全てのピアの一覧であるピアリストを送信する。ピアリストはまた、参入ピアがネットワーク内のその他のピアとの接続を構築するために必要とする何らかのその他の情報を含む。段階１０１０にて、参入ピアはコンテンツソースサーバからのピアリストを受信する。段階１０１５にて、参入ピアはネットワーク／システム内のその他のピア／ノードの全てとの接続を構築する。接続が構築されると、段階１０２０にて、参入ピアはコンテンツの受信を開始するためにコンテンツソースサーバに‘プル’信号を発する。段階１０２５にて、参入ピアはコンテンツを受信し、受信コンテンツを再生バッファに格納する。段階１０３０にて、新たなピアは、十分なコンテンツが受信された後、再生バッファから受信コンテンツのレンダリング／表示を開始する。

図１１Ａ及び１１Ｂはともに、コンテンツソースサーバの観点から本発明に係る待ち行列ベースのスケジューリング方法を示すフローチャートである。段階１１０５にて、コンテンツソースサーバはＰ２Ｐネットワーク／システム内のピアからの到来メッセージを受信する。そして、段階１１１０にて、コンテンツソースサーバは受信メッセージを分類し、それを３つの待ち行列のうちの１つに格納する。３つの待ち行列とは、メッセージ（ＭＳＧ）キュー、復元要求キュー及びプル信号キューのことである。ＭＳＧキューは管理メッセージ用である。復元要求キューは欠落コンテンツチャンク復元要求のためのものである。プル信号キューは‘プル’信号用である。段階１１１５にて、ＭＳＧキュー内の次の管理メッセージに対して応答が生成され、生成された応答が対応するピア（この管理メッセージ要求を発したピア）用の出力ユニットに格納される。段階１１２０にて、ＭＳＧキューがエンプティであるかを決定するための検査が実行される。ＭＳＧキューがエンプティでない場合、段階１１１５が繰り返される。ＭＳＧキューがエンプティである場合、コンテンツソースサーバは段階１１２５へと進み、プル信号キューから次のメッセージを除去し、Ｋ個のＦマーク付きコンテンツチャンクを該‘プル’信号を発したピアの出力ユニットに位置付け且つ格納することによって応答する。段階１１３０にて、プル信号キューがエンプティであるかを決定するための検査が実行される。プル信号キューがエンプティでない場合、段階１１２５が繰り返される。プル信号キューがエンプティである場合、コンテンツソースサーバは段階１１３５へと進み、復元要求キューから次のメッセージを除去し、要求された欠落コンテンツチャンクの位置を特定し且つ該欠落コンテンツチャンク復元メッセージを発したピアの出力ユニットに格納することによって応答する。段階１１４０にて、復元要求キューがエンプティであるかを決定するための検査が実行される。復元要求キューがエンプティでない場合、段階１１３５が繰り返される。復元要求キューがエンプティである場合、段階１１４５にて、コンテンツソースサーバは、ＮＦマーク付きコンテンツチャンクを除去し、該ＮＦマーク付きコンテンツチャンクを全てのピアの出力ユニットに格納する。そして、本発明に係る待ち行列ベースのスケジューリング方法は、この方法全体を再び実行することに進む。これは、Ｐ２Ｐネットワークが存在しなくなるまで続けられる。

図１２Ａ及び１２Ｂはともに、ピア／ノードの観点から本発明に係る待ち行列ベースのスケジューリング方法を示すフローチャートである。段階１２０５にて、ピアはＰ２Ｐネットワーク／システム内のサーバ又はその他のピアからの到来メッセージを受信する。そして、段階１２１０にて、ピアは受信メッセージを分類し、それを３つの場所のうちの１つに格納する。３つの場所とは、メッセージ（ＭＳＧ）キュー、復元要求キュー及び転送キューのことである。ＭＳＧキューは管理メッセージ用である。復元要求キューは欠落コンテンツチャンク復元要求のためのものである。転送キューは、該ピアが発した‘プル’信号の結果として該ピアが受信したコンテンツであって、ネットワーク内のその他のピアに転送されるべきコンテンツのためのものである。如何なる受信コンテンツも再生バッファ内に適切な位置で配置される。段階１２１５にて、ＭＳＧキュー内の次の管理メッセージに対して応答が生成され、生成された応答が対応するピア（この管理メッセージ要求を発したピア）用の出力ユニットに格納される。段階１２２０にて、ＭＳＧキューがエンプティであるかを決定するための検査が実行される。ＭＳＧキューがエンプティでない場合、段階１２１５が繰り返される。ＭＳＧキューがエンプティである場合、ピアは段階１２２５へと進み、要求された欠落コンテンツチャンクの位置を特定し、且つこの復元要求メッセージを発したピアの出力ユニットに格納する。段階１２３０にて、復元要求キューがエンプティであるかを決定するための検査が実行される。復元要求キューがエンプティでない場合、段階１２２５が繰り返される。復元要求キューがエンプティである場合、ピアは段階１２３５へと進み、Ｆマーク付きコンテンツチャンクの位置特定／検索を行い、且つそれを発送のために全てのピアの出力ユニットの転送キューに格納する。段階１２４０にて、‘プル’信号の発信者が該ピアによって管理される全ての出力ユニットにわたる平均キューサイズを演算／計算する。段階１２４５にて、平均キューサイズが閾値Ｔ_ｉ以下であるかを決定するための検査が実行される。平均キューサイズがＴ_ｉ以下である場合、段階１２５０にて、新たな‘プル’信号が生成され、コンテンツソースサーバの出力ユニット上に置かれる。平均キューサイズが閾値Ｔ_ｉより大きい場合、本発明に係る（ピアに関する）待ち行列ベースのスケジューリング方法は、この方法全体を再び実行することに進む。これは、Ｐ２Ｐネットワークが存在しなくなるまで、又は該ピアが自発的に、あるいは該ピア若しくは１つ以上の接続の故障によりネットワークを退出する／立ち去るまで続けられる。

理解されるように、本発明は、ハードウェア、ソフトウェア、ファームウェア、特殊用途プロセッサ、又はそれらの組み合わせ、の様々な形態にて実装され得る。好ましくは、本発明はハードウェアとソフトウェアとの組み合わせとして実装される。また、ソフトウェアは好ましくは、プログラム記憶装置上に明白に具現化されたアプリケーションプログラムとして実装される。アプリケーションプログラムは、如何なる好適なアーキテクチャを有する機械にアップロードされて該機械によって実行されてもよい。この機械は好ましくは、例えば１つ以上の中央演算処理ユニット（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）及び入力／出力（Ｉ／Ｏ）インタフェース等のハードウェアを有するコンピュータプラットフォーム上に実装される。このコンピュータプラットフォームはまた、オペレーティングシステム及びマイクロ命令コードを含む。ここで説明した様々な処理及び機能は、マイクロ命令コードの部分、又はオペレーティングシステムを介して実行されるアプリケーションプログラムの部分（又はこれらの組み合わせ）の何れであってもよい。さらに、このコンピュータプラットフォームに、例えば更なるデータ記憶装置や印刷装置などの様々なその他の周辺装置が接続されてもよい。

やはり理解されるように、添付図面に描かれた構成システム要素及び方法段階は好ましくはソフトウェアにて実装されるので、システム要素（又はプロセス段階）間の実際の接続は、本発明がプログラムされる方法に応じて異なったものとなり得る。当業者は、ここでの教示を与えられることにより、本発明のこれら及び同様の実装例又は構成例に想到することができるであろう。

Claims (34)

1. ピアツーピア・ネットワークにおいてコンテンツ配信をスケジューリングする方法であって：
   ピアからのメッセージを受信する段階；
   受信したメッセージを分類する段階；
   分類されたメッセージを、該分類に基づいて、複数の待ち行列のうちの１つに格納する段階；
   前記分類されたメッセージが格納された待ち行列の優先順位に基づいて、メッセージへの応答を生成する段階；及び
   前記ピアツーピア・ネットワーク内の全てのピアにコンテンツを送信する段階；
   を有する方法。
2. 少なくとも３つの待ち行列が存在する請求項１に記載の方法。
3. 前記待ち行列は、第１の待ち行列、第２の待ち行列、及び第３の待ち行列を含む、請求項２に記載の方法。
4. 前記第１の待ち行列内のメッセージは前記ピアツーピア・ネットワークに参入するための要求を含み、且つ前記第１の待ち行列は最高の優先順位の待ち行列である、請求項３に記載の方法。
5. 前記ピアツーピア・ネットワークに参入するための要求への応答は、参入しようとするピアに、前記ピアツーピア・ネットワーク内の既存のピアに関するピアリスト及び連絡先を送信することを含む、請求項４に記載の方法。
6. 前記第２の待ち行列内のメッセージは更なるコンテンツの要求を含み、且つ該更なるコンテンツの要求への応答は、要求された更なるコンテンツを送信することを含む、請求項３に記載の方法。
7. 前記第３の待ち行列内のメッセージは欠落コンテンツを復元するための要求を含み、且つ該欠落コンテンツを復元するための要求への応答は、要求された欠落コンテンツを送信することを含む、請求項３に記載の方法。
8. 前記第２の待ち行列の優先順位及び前記第３の待ち行列の優先順位は、設計上の要求に基づく、請求項３に記載の方法。
9. ピアツーピア・ネットワークにおいてコンテンツ配信をスケジューリングする装置であって：
   ピアからのメッセージを受信する手段；
   受信したメッセージを分類する手段；
   分類されたメッセージを、該分類に基づいて、複数の待ち行列のうちの１つに格納する手段；
   前記分類されたメッセージが格納された待ち行列の優先順位に基づいて、メッセージへの応答を生成する手段；及び
   前記ピアツーピア・ネットワーク内の全てのピアにコンテンツを送信する手段；
   を有する装置。
10. 少なくとも３つの待ち行列が存在する請求項９に記載の装置。
11. 前記待ち行列は、第１の待ち行列、第２の待ち行列、及び第３の待ち行列を含む、請求項１０に記載の装置。
12. 前記第１の待ち行列内のメッセージは前記ピアツーピア・ネットワークに参入するための要求を含み、且つ前記第１の待ち行列は最高の優先順位の待ち行列である、請求項１１に記載の装置。
13. 前記ピアツーピア・ネットワークに参入するための要求への応答は、参入しようとするピアに、前記ピアツーピア・ネットワーク内の既存のピアに関するピアリスト及び連絡先を送信する手段を含む、請求項１２に記載の装置。
14. 前記第２の待ち行列内のメッセージは更なるコンテンツの要求を含み、且つ該更なるコンテンツの要求への応答は、要求された更なるコンテンツを送信する手段を含む、請求項１１に記載の装置。
15. 前記第３の待ち行列内のメッセージは欠落コンテンツを復元するための要求を含み、且つ該欠落コンテンツを復元するための要求への応答は、要求された欠落コンテンツを送信する手段を含む、請求項１１に記載の装置。
16. 前記第２の待ち行列の優先順位及び前記第３の待ち行列の優先順位は、設計上の要求に基づく、請求項１１に記載の装置。
17. ピアツーピア・ネットワークにおいてコンテンツ配信をスケジューリングする方法であって：
    コンテンツソースサーバ及びピアのうちの１つから、メッセージ及びコンテンツのうちの一方を受信する段階；
    受信したメッセージを分類する段階；
    分類されたメッセージを、該分類に基づいて、複数の待ち行列のうちの１つに格納する段階；
    受信したコンテンツを格納する段階；
    前記分類されたメッセージが格納された待ち行列の優先順位に基づいて、メッセージへの応答を生成する段階；及び
    前記ピアツーピア・ネットワーク内のその他全てのピアにコンテンツを送信する段階；
    を有する方法。
18. 少なくとも３つの待ち行列が存在する請求項１７に記載の方法。
19. 前記待ち行列は第１の待ち行列及び第２の待ち行列を含む、請求項１８に記載の方法。
20. 前記第１の待ち行列内のメッセージは、前記ピアツーピア・ネットワーク内の既存のピアに関するピアリスト及び連絡先を含み、且つ前記第１の待ち行列は最高の優先順位の待ち行列である、請求項１９に記載の方法。
21. 前記ピアリスト及び前記連絡先への応答は、前記ピアツーピア・ネットワーク内の既存のピアとの接続を構築することを含む、請求項２０に記載の方法。
22. 前記第２の待ち行列内のメッセージは欠落コンテンツを復元するための要求を含み、前記第２の待ち行列は前記第１の待ち行列より低い優先順位の待ち行列であり、且つ前記欠落コンテンツを復元するための要求への応答は、要求された欠落コンテンツを送信することを含む、請求項１９に記載の方法。
23. 前記ピアツーピア・ネットワーク内のその他のピアに転送されるべきコンテンツを第３の待ち行列に格納する段階を更に有し、前記第３の待ち行列は最低の優先順位を有する、請求項１９に記載の方法。
24. 平均待ち行列サイズを決定する段階；
    前記平均待ち行列サイズが閾値以下であるかを決定する段階；及び
    前記平均待ち行列サイズが前記閾値以下である場合に、更なるコンテンツが必要であることを指し示す信号メッセージを生成し、該信号メッセージをコンテンツソースサーバに送信する段階；
    を更に有する請求項１７に記載の方法。
25. 前記格納されたコンテンツを表示する段階、を更に有する請求項１７に記載の方法。
26. ピアツーピア・ネットワークにおいてコンテンツ配信をスケジューリングする装置であって：
    コンテンツソースサーバ及びピアのうちの１つから、メッセージ及びコンテンツのうちの一方を受信する手段；
    受信したメッセージを分類する手段；
    分類されたメッセージを、該分類に基づいて、複数の待ち行列のうちの１つに格納する手段；
    受信したコンテンツを格納する手段；
    前記分類されたメッセージが格納された待ち行列の優先順位に基づいて、メッセージへの応答を生成する手段；及び
    前記ピアツーピア・ネットワーク内のその他全てのピアにコンテンツを送信する手段；
    を有する装置。
27. 少なくとも３つの待ち行列が存在する請求項２６に記載の装置。
28. 前記待ち行列は第１の待ち行列及び第２の待ち行列を含む、請求項２７に記載の装置。
29. 前記第１の待ち行列内のメッセージは、前記ピアツーピア・ネットワーク内の既存のピアに関するピアリスト及び連絡先を含み、且つ前記第１の待ち行列は最高の優先順位の待ち行列である、請求項２８に記載の装置。
30. 前記ピアリスト及び前記連絡先への応答は、前記ピアツーピア・ネットワーク内の既存のピアとの接続を構築する手段を含む、請求項２９に記載の装置。
31. 前記第２の待ち行列内のメッセージは欠落コンテンツを復元するための要求を含み、前記第２の待ち行列は前記第１の待ち行列より低い優先順位の待ち行列であり、且つ前記欠落コンテンツを復元するための要求への応答は、要求された欠落コンテンツを送信する手段を含む、請求項２８に記載の装置。
32. 前記ピアツーピア・ネットワーク内のその他のピアに転送されるべきコンテンツを第３の待ち行列に格納する手段を更に有し、前記第３の待ち行列は最低の優先順位を有する、請求項２８に記載の装置。
33. 平均待ち行列サイズを決定する手段；
    前記平均待ち行列サイズが閾値以下であるかを決定する手段；及び
    前記平均待ち行列サイズが前記閾値以下である場合に、更なるコンテンツが必要であることを指し示す信号メッセージを生成し、該信号メッセージをコンテンツソースサーバに送信する手段；
    を更に有する請求項２６に記載の装置。
34. 前記格納されたコンテンツを表示する手段、を更に有する請求項２６に記載の装置。

Images