(57)【要約】【課題】  ピアツーピアネットワークにおいて効率的なファイル転送技法により、ネットワークを通じて実質的にリアルタイムのファイル共有を促進する。【解決手段】  ネットワークのノードがクライアントおよびサーバの両方として働き、ネットワークにおけるファイル転送負担は、ノード全体にわたって公平に分配され、ファイル頒布プロセスができるだけ迅速に実行されることを保証する。ファイルを所有または受信する各ノードがそのファイルの所有を公示し、他のノードがそこからファイルを獲得できるようにする。一実施形態では、ノードが特定ノードからダウンロードによりファイルを受信すると同時に、同じファイルをアップロードにより別のノードに提供してもよい。世代識別子がファイルの各コピーに関連づけられ、それぞれファイルの一部のみを有する２つのノードが互いにそのファイルの残りの部分を抽出しようとしないようにする。【選択図】  図５
2004185618.tif 000002
【特許請求の範囲】
【請求項１】
発信側ノード、少なくとも１つの受信側ノード、および隣接ノードを含む複数のノードを有するピアツーピアネットワークにおけるノード間でファイルを転送する方法であって、前記受信側ノードは、前記隣接ノードへの直接ピアツーピア接続および前記発信側ノードへの間接ピアツーピア接続を有し、前記方法は、
前記発信側ノードにより所有されるファイルに対応する前記発信側ノードにより送信されたメタデータを前記受信側ノードで受信すること、
前記隣接ノードが前記発信側ノードにより所有される前記ファイルを抽出したという通知を前記隣接ノードから前記受信側ノードで受信すること、および
前記メタデータに基づいて前記隣接ノードから前記発信側ノードにより所有される前記ファイルを取得するか否かを前記受信側ノードで決定すること
を備えたことを特徴とする方法。
【請求項２】
前記受信側ノードで前記ファイルを抽出すると決定した場合、前記隣接ノードから前記受信側ノードへ前記ファイルを抽出することをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記メタデータは、前記ピアツーピアネットワークを通じて進行中の実質的にリアルタイムのグループ対話に対する前記ファイルの現在の有益性に基づいて、前記ファイルに関連付けられた優先順位を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記隣接ノードから前記ファイルを抽出することは、
前記ファイルに対する要求を前記隣接ノードへ送信すること、および
前記ファイルのストリーミングアップロードを前記受信側ノードで前記隣接ノードから受信すること
を含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記受信側ノードが前記ファイルの前記ストリーミングアップロードを受信し始めた後、前記受信側ノードが前記ファイルを所有しているという通知を、前記ピアツーピアネットワーク内の他のノードへブロードキャストすることをさらに備えたことを特徴とする請求項４に記載の方法。
【請求項６】
前記受信側ノードが前記ファイルを所有しているという前記通知は、世代識別子を含み、該世代識別子は、前記受信側ノードから入手可能なファイルコピーを前記発信側ノードから入手可能なファイルコピーから区別することを特徴とする請求項５に記載の方法。
【請求項７】
前記受信側ノードが前記ファイルの前記ストリーミングアップロードを受信することを終了した後、前記受信側ノードが前記ファイルを所有しているという第２通知をブロードキャストすることをさらに備え、該第２通知は、第２世代識別子を含み、該第２世代識別子は、前記受信側ノードから入手可能なファイルコピーを前記発信側ノードから入手可能なファイルコピーから区別しないことを特徴とする請求項６に記載の方法。
【請求項８】
前記メタデータに基づいて前記隣接ノードから前記発信側ノードにより所有される前記ファイルを抽出するか否かを前記受信側ノードで決定することは、前記メタデータに基づいて、前記発信側ノードにより所有される前記ファイルに対応するローカルファイルが前記受信側ノードに存在することを判定し、それにより前記隣接ノードから前記ファイルを抽出しないことを決定することをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項９】
前記発信側ノードにより所有される前記ファイルは、オーディオファイルであることを特徴とする請求項３に記載の方法。
【請求項１０】
進行中の実質的にリアルタイムのグループ対話に対する前記ファイルの前記現在の有益性は、オーディオプレイリストにおける前記ファイルのレベルに基づいて決定され、前記プレイリストにおける現在再生しているレベルは、前記プレイリストにおける現在再生していないレベルより高い優先順位に関連付けられることを特徴とする請求項９に記載の方法。
【請求項１１】
請求項１に記載の方法を実行するためのコンピュータ実行可能命令をその上に有することを特徴とするコンピュータ読取り可能媒体。
【請求項１２】
発信側ノード、少なくとも１つの受信側ノード、ならびに第１および第２隣接ノードを含む複数のノードを有するピアツーピアネットワークにおけるノード間でファイルを転送する方法であって、前記受信側ノードは、前記第１および第２隣接ノードへの直接ピアツーピア接続および前記発信側ノードへの間接ピアツーピア接続を有し、前記方法は、
前記第１隣接ノードが第１ファイルを供給することができるという通知を前記第１隣接ノードから前記受信側ノードで受信することであって、前記受信側ノードは、前記第１ファイルに関連付けられた第１メタデータを有し、該第１メタデータは、第１優先順位を含むこと、
前記受信側ノードから前記第２隣接ノードへ第２ファイルをアップロードする要求を前記第２隣接ノードから前記受信側ノードで受信することであって、前記受信側ノードは、前記第２ファイルに関連付けられた第２メタデータを有し、該第２メタデータは、第２優先順位を含むこと、
前記第１および第２優先順位のいずれがより高い優先順位レベルに対応するかを判定すること、および
前記第１優先順位が前記第２優先順位よりも高い優先順位レベルに対応する場合には、前記第１隣接ノードから前記第１ファイルを抽出し、そうでない場合には、前記第２隣接ノードに前記第２ファイルをアップロードすること
を備えたことを特徴とする方法。
【請求項１３】
前記受信側ノードが前記第１ファイルを受信し始めた後、前記受信側ノードが前記第１ファイルを供給することができるという第１通知をブロードキャストすることをさらに備え、該第１通知は、第１世代識別子を含み、該第１世代識別子は、前記受信側ノードから入手可能な第１ファイルコピーを前記第１隣接ノードから入手可能な第１ファイルコピーから区別することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記第１隣接ノードから入手可能な前記第１ファイルコピーは、第２世代識別子に関連づけられ、該第２世代識別子は、前記第１隣接ノードから入手可能な前記第１ファイルコピーを前記発信側ノードから入手可能な第１ファイルコピーから区別することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記受信側ノードが前記第１ファイルを受信することを終了した後、前記受信側ノードが前記第１ファイルを供給することができるという第２通知をブロードキャストすることをさらに備え、該第２通知は、第２世代識別子を含み、該第２世代識別子は、前記受信側ノードから入手可能な前記第１ファイルコピーを前記第１隣接ノードから入手可能な前記第１ファイルコピーから区別しないことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記第１および第２ファイルは、オーディオファイルであることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記第１および第２優先順位は、オーディオプレイリストにおけるそれぞれのファイルのレベルに基づいており、該プレイリストにおける現在再生しているレベルは、前記プレイリストにおける現在再生していないレベルより高い優先順位に関連付けられることを特徴とする請求項９に記載の方法。
【請求項１８】
請求項１２に記載の方法を実行するためのコンピュータ実行可能命令をその上に有することを特徴とするコンピュータ読取り可能媒体。
【請求項１９】
受信側ノードならびに第１および第２隣接ノードを含む複数のノードを有するピアツーピアネットワークにおけるノード間でファイルを転送する方法であって、前記受信側ノードは、前記第１および第２隣接ノードへの直接ピアツーピア接続を有し、
第１世代識別子を有する所望のファイルの一部を供給側ノードから前記受信側ノードで受信し、前記第１世代識別子より大きい第２世代識別子を所望のファイルの一部に割り当てること、
前記第１隣接ノードが前記所望のファイルを供給することができるという第１通知を前記第１隣接ノードから前記受信側ノードで受信することであって、前記第１通知は、第１隣接コピー世代識別子を含むこと、
前記第２隣接ノードが前記所望のファイルを供給することができるという第２通知を前記第２隣接ノードから前記受信側ノードで受信することであって、前記第２通知は、第２隣接コピー世代識別子を含むこと、
前記第１および第２隣接コピー世代識別子に基づいて前記第１隣接ノードおよび前記第２隣接ノードのいずれから前記所望のファイルの残りの部分を抽出すべきかを決定すること
を備えたことを特徴とする方法。
【請求項２０】
請求項１９に記載の方法を実行するためのコンピュータ実行可能命令をその上に有することを特徴とするコンピュータ読取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、ネットワークを通じてのグループ接続に関し、より詳細には、ピアツーピアネットワークにおけるファイル転送に関する。
【背景技術】
【０００２】
ピアツーピアネットワークが数および人気において拡大し、新規なアプリケーションに遭遇するにつれて、現在のピアツーピア技術の短所が目立つようになっている。また、ＰＣコンピューティングパワーの増大は、ピアツーピア接続において使用するために利用可能な帯域が、それに伴って実質的に増大していないことと対比すると、これらの欠点を強調している。
【０００３】
例えば、ピアツーピアネットワークにおけるファイル転送のための既存の技法および方法は、しばしば不便で著しく低速であり、ネットワークを通じての情報の迅速な共有を阻害している。ピアツーピアシステムがリアルタイムのグループ対話機能のために使用されている場合、ファイル転送におけるあらゆる実質的遅延は、接続が切れている感じを生じる可能性があり、たぶんリアルタイムの対話は、ユーザにとってより誇張した、ダイナミックでない対話に感じられ始める。したがって、できる限りいつでも、ファイル転送を高速化することが重要である。
【０００４】
現在のピアツーピアファイル転送プロトコルが低速である１つの主要な理由は、ファイル転送負荷が、ピアツーピアノード間で配分される方法にある。例えば、１つの典型的な転送技法では、グループで共有すべきファイルを有するノードが、パラレルまたはシリアルにそのファイルをアップロードすることによって、全てのグループメンバにそのファイルを単に散布する。これは、散布側ノードに相当の帯域および計算量の不利益を課する。何故ならば、ノードは、対象物を受け取る各要求者すなわち各ノードに供給しなければならず、ほぼ一斉にまたは同時にそれを行わなければならないからである。結果として、グループ全体に対するファイル転送速度は、散布側ノードの計算能力および接続速度によって限定される。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
十分な転送速度を提供するピアツーピアファイル転送メカニズムにより、ピアツーピアネットワークを用いた実質的にリアルタイムのグループ対話が、ファイル転送遅延による過度の中断なしに行われるようにする必要がある。
【課題を解決するための手段】
【０００６】
本発明は、ピアツーピアネットワークにおいて効率的にファイルを転送するシステム、方法、およびアーキテクチャに関する。本システムは、実質的にリアルタイムのファイル共有を促進するように適応し、特にオンライングループ対話環境において有益である。本発明の一実施形態では、ピアツーピアネットワークの多数のノードが、クライアントおよびサーバの両方として働き、ファイル情報を受信することおよび受信した情報を他のノードに送信することの両方を行う。ファイル転送の負荷は、本発明の一実施形態では、ネットワークのノード全体に渡りより均一に配分され、典型的には、どのノードも不相応なファイル転送負荷を負うことがないようにする。これは、ファイルができるだけ迅速にネットワーク内のあらゆるノードに転送されることを保証する際に有益である。
【０００７】
本発明の一実施形態では、ファイル頒布は、ファイルメタデータの公開によって開始される。メタデータを受信した後、各ノードは、関連するファイルを受信することを望んでいるか否かを判定する。そのファイルを受信することを所望している場合、関連する１または複数のノードは、プルモデルを利用して、それぞれの隣接ノードに対してファイルコンテンツを要求する。本発明の一実施形態では、ファイルを有している、または受信する各ノードは、そのファイルを所有していることを公示して、他のノードがこれらの二次ソースからファイルを獲得することができる。本発明の一実施形態では、ノードが特定のノードからストリーミングダウンロードによりファイルを受信し、実質的に同時に別のノードへ同じファイルをアップロードにより供給してもよい。この実施形態では、好ましくは、それぞれファイルの同一部分を有する２つのノードが、ファイルの残りの部分を互いに取得しようとしないように、世代識別子（a generation identifier）を使用する。
【０００８】
本発明のその他の特徴および利点は、添付図面を参照して以下に記載される例示的実施形態の詳細な説明から明らかとなるであろう。
【０００９】
添付の特許請求の範囲は本発明の特徴を詳細に記載しているが、本発明は、その目的および利点とともに、以下の詳細な説明および添付図面から最も良く理解されるであろう。
【発明を実施するための最良の形態】
【００１０】
図面において、同じ参照番号は同じ要素を指す。以下、本発明を、コンピューティング環境との関連で説明する。本発明を実施するために必要ではないが、本発明は、パーソナルコンピュータ（ＰＣ）によって実行されるプログラムモジュール等のコンピュータ実行可能命令によって実施されるものとして説明される。一般的に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。
【００１１】
本発明は、ＰＣ以外のコンピュータシステム構成で実施されてもよい。例えば、本発明は、ハンドヘルドデバイス、移動電話機、マルチプロセッサシステム、マイクロプロセッサ方式の、またはプログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等で実現されてもよい。本発明は、分散コンピューティング環境で実施されてもよい。このとき、タスクは、通信ネットワークを通じてリンクされるリモート処理デバイスによって実行される。分散コンピューティング環境において、プログラムモジュールは、ローカルおよびリモートの両方のメモリストレージデバイスに位置してもよい。
【００１２】
したがって、本発明の以下の詳細な説明は、従来のＰＣ２０のような例示的な汎用コンピューティングデバイスとの関連で記載されるが、本発明は上記で示唆したような多くのタイプのコンピューティング環境に組み込まれてもよいことが理解されるであろう。
【００１３】
本発明を詳細に説明する前に、本発明の実施形態が実施され得るコンピューティング環境を図１に関連して説明する。ＰＣ２０は、処理ユニット２１、システムメモリ２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット２１に結合するシステムバス２３を含む。システムバス２３は、メモリバスまたはメモリコントローラ、ペリフェラルバス、および種々のバスアーキテクチャのいずれかを用いたローカルバスを含む数種のバス構成のいずれでもよい。システムメモリは、読み出し専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動中等にＰＣ２０内の要素間で情報を転送するために役立つ基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２６が、ＲＯＭ２４に格納されている。ＰＣ２０はさらに、ハードディスク６０を読み書きするためのハードディスクドライブ２７、リムーバブル磁気ディスク２９を読み書きするための磁気ディスクドライブ２８、およびＣＤ−ＲＯＭ等の光媒体のようなリムーバブル光ディスク３１を読み書きするための光ディスクドライブ３０を含む。
【００１４】
ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ディスクドライブインタフェース３４によってシステムバス２３に接続される。ドライブおよびそれらに関連するコンピュータ読取り可能媒体は、ＰＣ２０のためのコンピュータ読取り可能命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性ストレージを提供する。本明細書に記載される例示的環境は、１または複数のハードディスク６０、リムーバブル磁気ディスク２９、およびリムーバブル光ディスク３１を使用しているが、当業者には理解されるように、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ、読み出し専用メモリ等の、コンピューティングデバイスがアクセス可能なデータを格納することのできる他のタイプのコンピュータ読取り可能媒体もまた、例示的オペレーティング環境で使用してもよい。
【００１５】
オペレーティングシステム３５、１または複数のアプリケーションプログラム３６、他のプログラムモジュール３７、およびプログラムデータ３８を含めて、いくつかのプログラムモジュールが、ハードディスク６０、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納されてもよい。ユーザは、キーボード４０およびポインティングデバイス４２のような入力デバイスを通じてＰＣ２０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等があり得る。これらおよびその他の入力デバイスはしばしば、システムバスに結合しているシリアルポートインタフェース４６を通じて処理ユニット２１に接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースによって接続されてもよい。モニタ４７または他のタイプの表示デバイスもまた、ビデオアダプタ４８のようなインタフェース経由でシステムバス２３に接続される。モニタに加えて、ＰＣは通常、スピーカやプリンタのような他の周辺出力デバイス（図示せず）を含む。
【００１６】
ＰＣ２０は、リモートコンピュータ４９のような１または複数のリモートコンピュータへの固定的または一時的な論理接続を用いたネットワーク環境で動作する。リモートコンピュータ４９は一般的に、別のＰＣ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス等の普通のネットワークノード、または本明細書の他の箇所で言及されているような他のデバイスタイプでもよい。リモートコンピュータ４９は、典型的には、ＰＣ２０に関して上記で説明した要素の多くまたはすべてを含むが、そのような必要はなく、メモリストレージデバイス５０のみが図１に示されている。図１に描かれている論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットで一般的である。
【００１７】
ＬＡＮネットワーキング環境で使用される場合、ＰＣ２０は、ネットワークインタフェースすなわちアダプタ５３を通じてローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用される場合、ＰＣ２０は、典型的には、ＷＡＮ５２を通じて通信を確立するためのモデム５４等の手段を含む。モデム５４は、内蔵でも外付けでもよいが、シリアルポートインタフェース４６経由でシステムバス２３に接続される。本発明の一実施形態の一実施例では、標準モデムが使用されてもよいが、約１２０ｋｂｐｓから１．５Ｍｂｐｓまたはそれ以上の容量を有するブロードバンド接続が、一般により良いパフォーマンスをもたらすであろう。ＰＣ２０に関連して描かれているプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納されてもよい。理解されるように、図示されているネットワーク接続は例示であり、コンピュータ間に通信リンクを確立する他の手段を使用してもよい。さらに、本発明は特定のネットワークタイプに限定されることを意図していない。有線または無線、固定的または一時的、回線交換、パケット交換または他のネットワークアーキテクチャのいずれかを問わず、本発明を実施するためにいかなるネットワークタイプを使用してもよい。
【００１８】
以下の説明では、特に断りのない限り、本発明は、ＰＣ２０のような１または複数のコンピューティングデバイスによって実行されるオペレーションの作用およびシンボリック表現に関して説明される。したがって、理解されるように、「コンピュータにより実行される」と言及される、このような作用およびオペレーションは、構造化された形式でデータを表現する電気信号を、コンピュータの処理ユニットが操作することを含む。この操作は、データを変換し、またはデータをコンピュータのメモリシステム内の位置に保持し、当業者により十分に理解される方法でコンピュータのオペレーションを再構成または変更する。データが保持されるデータ構造は、データのフォーマットによって規定される特定の性質を有するメモリの物理的位置である。しかし、本発明は上記の文脈で説明されているが、それに限定することを意図するものではなく、当業者には理解されるように、以下で説明する種々の作用およびオペレーションはハードウェアで実施してもよい。
【００１９】
本発明の一実施形態により使用可能な例示的なピアツーピアネットワーク２０１を概略的に図２に示す。典型的には、本発明を用いたピアツーピアネットワークは、約２〜１０個のノードを含むであろうが、より大きいネットワークも同様に本発明を実施するために使用されてもよい。ピアツーピアネットワークのノードＡ〜Ｇの間の両頭矢印線は、ピアツーピアネットワーク接続を表す。したがって、例えば図示した構成において、ノードＡはノードＢに直接接続されているが、ノードＣには間接的に（すなわち、単一のリンク経由ではなく）接続されている。各ピアツーピア接続は、実際にはいくつかの物理的および／または論理的な下位の接続を含んでもよく、例えば、ピアツーピアネットワークが載っている下位ネットワークに関連していてもよい。なお、ピアツーピアネットワークノードは、一般的にコンピュータであろうが、その必要はないことに留意されたい。むしろ、適当なネットワーキングファシリティを有するいかなるタイプのデバイスも、ユーザの機器の選択に応じて使用することができる。
【００２０】
ピアツーピアネットワークのパフォーマンスを向上させるため、グループ内の各コンピュータは、データベースに「共通ファイル」を格納し、このデータベースをグループ内の他のメンバのデータベースとともに最新に保つようにしてもよい。このデータベースは、様々な方法で最新に保つことができる。一実施態様では、特定のコンピュータがデータベースを変更した時にはいつでも、上記の接続経由でピアツーピアネットワーク内の他のコンピュータにその変更を伝達することができる。別法として、グループ内のコンピュータは、ある一定期間が経過した後に、データベースのより新しいバージョンについて、自己と論理接続のあるコンピュータをポーリングして、自己のデータベースを自動的に更新することができる。ピアツーピア技術は一般的に、中央サーバからの独立性と、しばしば良好な資源利用率とを含むいくつかの利点を有するが、本発明においては、データストレージのため、または特定のピアツーピアノードグループまたは特定のオフラインメンバの状態を保持するために、１または複数のノードに接続された中央サーバまたはファシリティ（図示せず）を利用してもよい。
【００２１】
ピアツーピアネットワーク２０１は、既存のピアツーピア技術を用いて構築することができる。例えば、一般的に、ノードは、既存のノードの１つへの接続を確立することによってネットワーク２０１に接続する。ここで、この新しいノードは、既存のノードに他の接続およびノードがあればそれを評価し、それら他のノードの一部または全部に接続するか、またはどのノードにも接続しないかを選択することによって、既存のノードの（他のノードへの）接続に「ピギーバック」してもよい。接続する側のノードは一般的に、既存のノードの接続に基づく追加的接続を作成するかどうかを決定する際に、新たな接続のコストを、新たな接続の有益な属性と対比して考慮に入れる。当業者には理解されるように、ピアツーピアネットワークの各ノードは、当該ノードが情報を有しているネットワークの部分の瞬間的な状態の記録を保持して、当業者に理解されるように、所与の時刻における関連するネットワークメンバシップ部分およびステータスを追跡する。実際にピアツーピアネットワークを形成するのは、種々のノードに関するこれらの種々のレコードの集合である。何故ならば、ノード間の接続は、実際には固定結線されておらず、ほとんどの場合、回線交換ではなくパケット交換であるという意味で一時的だからである。
【００２２】
本発明の一態様によれば、ファイル配布が、ノードＡなどのピアツーピアネットワークのノードによって開始される。以下でさらに詳細に説明するように、ファイルデータは、ネットワークを通じて適当な受信側ノードへ流れるが、転送技法はネットワーク全体で比較的均一に転送コストを分散させる。特に、図３のフローチャート３０１を参照すれば理解されるように、ステップ３０３において、配布側ノードは、当該ファイルに関連付けられたメタデータを公開する。メタデータはファイルデータではなく、ファイル自体に関する情報と、他のファイルと比較しての優先順位などのファイルのコンテクストとを表す。メタデータは、好ましくは、通常のピアツーピアレコードフラッディング技法により最小限の帯域幅の使用により、既存の接続経由ですべてのノードへ容易にフラッディングを行うために十分に小さい。この技法によれば、データがネットワークのすべてのノードに到達するまで、すべての受信側ノードは、順次メタデータを転送する。なお、ノードが、例えば異なるノードへの異なる接続を通って、重複するメタデータを受信した場合、ノードは、重複する情報を転送せずに単に廃棄し、最初に受信したメタデータのコピーのみを転送することに留意されたい。
【００２３】
本発明の一実施形態では、メタデータは、ファイル名、ファイルサイズ、配布特性のセット、有効期限情報、および公開側のアプリケーションまたはモジュールが提供することを望むモジュール固有の情報を含む。さらに、メタデータは、作成日および／または変更日、所有者、作成者、優先順位等などの他の適当な情報を含むことができる。メタデータ内のファイル名は，単にファイルにリンクされた識別子である。ファイル名は、絶対的に一意的である必要はないが、好ましくは、該当ファイル以外のネットワーク２０１のいかなるノード上のいかなるファイルとも同一視される可能性がないほど十分に具体的な識別子である。音楽ファイルの場合、ファイル名は、適当なＭＰ３のＩＤ３タグを含むことができる。ファイルサイズ情報は、どのくらいの量のデータがファイルに含まれるかの指標を提供し、好ましくは、転送時に圧縮が使用される場合には、圧縮時のファイルのサイズに関して与えられる。配布特性のセットは、随意に、ファイルがどのように配布されるべきかについてのヒントまたは示唆を提供する。最後に、有効期限情報は、ファイルが転送後に各受信側ノードのメモリから削除されるべき時刻を指定する。なお、以下でさらに詳細に説明するように、最初のメタデータ公開は、発信側ノードが提供ファイルを有するという宣言を含むかもしれないが、他のあらゆるノードは、そのファイルの少なくとも一部を実際に有するまでこの宣言をしないことに留意されたい。
【００２４】
ステップ３０３において、公開側ノードがメタデータを送信し、ピアツーピアネットワークのすべてのノードがメタデータを受信した後、ステップ３０５において、それぞれのメタデータ受信側ノードは、ファイルを要求するかどうかを決定する。ノードは、ファイルを要求するいくつかの理由のうちのいずれかを有する可能性がある。例えば、グループオーディオ体験モジュールのようなオンラインリアルタイムグループ対話モジュールがファイルメタデータ公開を開始し、受信側ノードが同種のモジュールを起動した場合、受信側ノードは、同様に提供ファイルを要求することを望むであろう。
【００２５】
さらに、本発明の一実施形態では、ノードはそのローカルファイルを検索して、既に関連ファイルのコピーを有しているか否かを判定し、別のノードに対してダウンロードを要求するのではなくそのコピーを使用する。ローカルコピーが公示されたコピーと「同一」であるかどうかの判定は、多くの因子に基づくことができる。例えば、オーディオファイルの場合、同一性はファイル名、制作したアーティスト等の団体、および演奏時間のような特性の一致から推論してもよい。しかし、本発明のもう１つの実施形態では、このローカルに調達されるファイルは、公示ファイルに対する他のノードの要求を供給するためには使用されない。その理由は、ローカルに調達されるコピーと公示されたコピーの間には相違があるかもしれないからである。この相違は、ローカルな調達側ノードでは明らかであることもないこともあるが、別のノードによるダウンロードの間にソースの切替があると、ダウンロードにおける連続性を妨げるかもしれないからである。このような相違は、ファイルを縮小するために使用された正確な圧縮技法や（例えば、同一ファイルが異なる方法で圧縮されて異なる最終バージョンが生成された場合）、ファイルを作成するために使用された基礎データ（例えば、ファイルが同じ歌の異なるレコーディングに関連する場合）に存在するかもしれない。これに関連してローカルファイルを使用するかどうかの決定を、使用されるファイル同一性の基準に関連付けてもよい。
【００２６】
受信側ノードがファイルを要求することに決定した場合、ステップ３０７において、受信側ノードは、そのいずれかの直接隣接するノードがそのファイルを有していると宣言しているか否かを判定するためのチェックを行う。１または複数の隣接ノードがそのファイルを有していると宣言している場合、これは、それらのノードがそのファイルの少なくとも一部を有していることを意味する場合、ステップ３０９において、当該ノードは、どの隣接ノードに対してファイルを要求するかを決定する。この決定は、例えばノードの計算および接続特性（以前に測定されたファイル転送パフォーマンス、速度、信頼性等）を含むいくつの因子に基づいてもよい。
【００２７】
複数のノードがファイルの部分を受信してその所有を公示しているかもしれないので、理論的には、これらのノードに対する関連する供給側が問題に遭遇している場合、ノードは、互いにファイルを獲得しようと試みるかもしれない。これは、いずれのノードもファイル全体を所有していないので、デッドロックが生じるであろう。この問題を多少とも解決するため、好ましくは、ファイルを所有していることを公示する各ノードは、そのファイルの世代番号も公示する。ファイル全体を有しているまたは獲得するノードは、そのバージョンを世代０ファイルとして公示することができる。世代０ソースから獲得している部分コピーを公示するノードは、そのバージョンを世代１として公示する。一般的に各ノードは、それが同時にダウンロードしているバージョンよりも１だけ大きい世代を有するとして、そのバージョンを公示する。あるソースノードがファイル全体のコピーのダウンロードを完了すると、公示したその世代を０にデクリメントする。このデクリメントは、そのノードがアップロードを直接的または間接的に供給しているノードのチェインを通って流れる。したがって、公示されたファイルバージョンに関連する世代番号は、どのノードからファイルを獲得するかを決定するために本発明の一実施形態において使用可能なもう１つの因子であり、より低い世代が一般的に要求され、要求側の世代に等しい世代は、典型的には受け入れられない。
【００２８】
ただ１つの隣接ノードがファイルの所有を宣言し、適当なバージョンを有している場合、ステップ３０９は当該要求側ノードについては省略される。ステップ３１１において、要求側ノードは、ファイルを所有している選択された隣接ノードに対してファイルを要求し、ファイルの受信を開始する。
【００２９】
本発明の一実施形態では、要求側ノードは、ファイルの受信を開始した後、その所有を他のノードに公示することができる。この理由は、要求側ノードは、既に受信したファイルの部分を、その供給側からほぼ同一のまたはそれ以上のレートで同時にファイルを受信し続けながら、提供することができるからである。これはほとんどの場合、ファイル配布の待ち時間をわずかに減少させるように作用する。というのは、ノードは、ファイルの所有を公示してファイルを他のノードに提供する前に、ファイル受信の完了を待機しなくてもよいからである。したがって、ステップ３１３において、要求側ノードは、当該ファイルを所有しているという通知をその隣接ノードへ送信する。ステップ３１５において、当該ノードは、ファイルに対する受信されたあらゆる要求を供給する。最後に、プロセスはノード３１９で終了する。
【００３０】
ステップ３０５で、当該ノードがファイルを所有することを望まないと判定された場合、プロセスはステップ３１７に進み、当該ノードのいずれかの隣接ノードが、当該ノードに求められていないファイル要求を送信したか否かが判定される。ファイル配布は、一般的に上記のように要求のみに基づいているため、ファイルを要求するノードが、自発的にファイルを獲得し公示する隣接ノードを有していないことになる可能性がある。したがって、およそ１ファイル分のダウンロード時間など適当な時間待機した後、ノードは、その隣接ノードの１つへ、その隣接ノードが当該ファイルを抽出し供給するように促す、求められていないファイル要求を送信してもよい。本発明の一実施形態では、各ピアツーピアアプリケーションまたはモジュールは、同一のアプリケーションまたはモジュールを実行しているノードのみから、または主としてそのようなノードからなる特定のピアツーピアネットワークに関連している。したがって、本実施形態では、各ノードがそのファイルを有することを望む可能性が高いので、求められていない要求を使用することが必要となる可能性は小さい。
【００３１】
ステップ３１７において、当該ノードのどの隣接ノードも、当該ノードに求められていないファイル要求を送信していないと判定された場合、プロセスはステップ３１９で終了する。これに対して、ステップ３１７において、当該ノードの１または複数の隣接ノードが、当該ノードに求められていないファイル要求を送信したと判定された場合、プロセスはステップ３０７および論理的に後続するステップに進む。なお、本発明の一実施形態では、当該ノード自身がファイルを獲得するために求められていないファイル要求を行うことを必要とするかもしれないことに留意されたい。
【００３２】
上記ではあまり詳細に説明していないが、ノードがアップロードおよび／またはダウンロードのために複数のファイル間で選択を行う状況、および／または特定のノードについてアップロードのタスクとダウンロードのタスクの間で選択が行われる状況が存在する。これらの状況について、図４の一般化されたフローチャート４０１に関してさらに詳細に説明する。図４に提示されている状況は、複数のアップロードおよびダウンロード機会の同時利用可能性を含んでいる。理解されるように、多くの場合にこのような複数の機会は存在せず、そのような状況では、フローチャート４０１の一部のステップは、適宜省略してもよい。
【００３３】
ステップ４０３において、特定のノードが２つ以上の特定ファイルをアップロードする要求を受信するとともに、２つ以上の他のファイルがそのノードへのアップロードのために利用可能であることの公示も受信する。当該ノードが無制限のアップロードおよびダウンロード容量を有し、すべてのこのような作業の同時実行（すなわち、実質的に同時に、または少なくとも重なり合う時間間隔中に）が、いずれの作業を低速にすることも遅延させることもなく遂行可能である場合、好ましくは、すべてのこのようなアップロードおよびダウンロードは、同時に処理される。しかし、より典型的には、ノードおよび／またはネットワークの資源が制限され、他のダウンロードまたはアップロードが提供されていない時にのみ最も高速なダウンロードまたはアップロードが達成される場合には、一般的に、どの作業（アップロードまたはダウンロード）およびファイルにサービスするかについての選択を行うことによってのみ、できるだけ高速なダウンロードまたはアップロードが行われることになる。理解されるように、ある種のブロードバンド技術の場合のように、アップロードチャネルとダウンロードチャネルが完全に分離している場合、各チャネルに対する優先順位付けを、図４に示すように協調的にではなく別々に遂行することが可能である。
【００３４】
ステップ４０５において、可能性のあるファイルアップロードおよびダウンロード作業は、優先順位付けされる。特に各ファイルは、好ましくは、例えばメタデータにより、その現在の重要度を表す数値的優先順位に関連づけられる。優先順位は、例えば、オーディオプレイリスト内のファイルの相対的順序を表してもよく、プレイリストが変化するにつれて変化してもよい。１または複数の関連するファイル優先順位がアップロードまたはダウンロード中に変化する範囲、どのファイルが現在アップロードまたはダウンロードに好ましいファイルであるかに影響を及ぼす範囲に対して、ターゲットファイルを途中で切り替え、以前に優先されていたファイルの転送未完部分は、可能性のある将来の転送再開のために格納されてもよい。ファイルのアップロードチャネルとダウンロードチャネルが相互に影響しないように完全に別個になっている場合、優先順位付けは、好ましくは、チャネルごとに行われる。すなわち、すべての可能性のあるファイルダウンロードが相互に優先順位付けされ、すべての可能性のあるファイルアップロードが相互に優先順位付けされる。さらに当業者には理解されるように、記載した技法は、複数の独立のアップロードチャネルおよび／または複数の独立のダウンロードチャネルに対応するように容易に変更することが可能である。
【００３５】
ステップ４０７において、最高優先順位のファイル転送が提供される。独立のアップロートおよびダウンロードチャネルの場合、最高優先順位のファイルアップロードが供給され、最高優先順位のダウンロードも供給される。ここでも留意されるべきであるが、ファイル優先順位は、ファイル転送中に変化してもよく、それにより上記のように、現在供給されているファイルよりも別のファイルの方がアップロードまたはダウンロードについて高い優先順位を有することになるかもしれない。最後に、ステップ４０９においてプロセスは終了する。
【００３６】
図５は、本発明の一実施形態により使用可能なクライアント／サーバアーキテクチャを概略的に示している。特に、本発明の種々の実施形態によるピアツーピアネットワークでは、多くのノードがクライアントおよびサーバの両方として動作するが、理解されるように、１または複数のノードがクライアントとしてのみ、またはサーバとしてのみ動作してもよい。例示的なノードクライアント／サーバアーキテクチャ５０１は、クライアントファシリティ５０３およびサーバファシリティ５０５の両方を有する。クライアントファシリティ５０３は、所望のファイルがあればそれを要求してそれを受信することを担当する。さらに詳細には、クライアントファシリティ５０３は、好ましくは、例えば公示されているファイルのような特定のファイルを別のノードから獲得することを求める要求を、例えばモジュールまたはアプリケーションから受信するクライアントインタフェース５０７を含む。このような要求を、優先順位キュー５１１内に優先順位付けしてキューイングしてもよい。ここで、ノード接続インタフェース５１３を使用して、要求を実行し、割り当てられた要求優先順位に基づいて適当な時に所望のファイルを獲得する。
【００３７】
ノードのサーバファシリティ５０５は、好ましくは、例えばそのノード上の別のモジュールまたはアプリケーションからファイルデータを受信するファイルインタフェース５１５を含む。ファイル情報は、例えば、64k Windows Media（登録商標）Audio（ＷＭＡ）フォーマットへと圧縮されてもよく、またはバルクアップロードのための一体的フォーマットであっても、ストリーミングアップロードのためのストリーミングフォーマットであってもよい。明確にするため、「Publish File」（ファイル公開）インタフェースおよび「Publish Stream」（ストリーム公開）インタフェースという２個のインタフェースがインタフェース５１５内に示されている。後者はサーバ部分５０５によるファイルのストリーム公開を容易にするために使用される一方、前者は上記のようなファイル全体の一体的公開を容易にするために使用される。インタフェース５１５で受信されるファイルデータは、一時的格納のためにサーバキャッシュ５１７に送信されるが、サーバ優先順位キュー５１９内で他の未了アップロードとの関係で並べ替えてもよい。好ましくは、最高優先順位のファイルがファイルインタフェース５１５で最初に受信されるが、優先順位は、インタフェース５１５でのファイルデータの受信中に変化し得る。最後に、ファイルデータは、適当な優先順位でノード接続インタフェース５１３で利用可能となる。理解されるように、クライアントファシリティ５０３が別のノードからファイルデータの受信を行い、サーバファシリティがその同じデータをさらに別のノードへアップロードすることになるような場合には、アップロードのためのファイルデータは、別法として、ノード接続インタフェース５１３からもたらされてもよい。この場合、到来するファイルデータは、クライアント優先順位キューおよびサーバ優先順位キューの両方に格納されてもよい。
【００３８】
以上、理解されるように、ピアツーピアネットワークで使用するためのコンテンツブロードキャスト転送の新規な手段について説明した。本発明の原理を適用し得る多くの可能な実施形態を考慮すれば、図面との関連で本明細書に記載した実施形態は単なる例示であり、本発明の範囲を限定するものと解釈すべきでないことが認識されるべきである。例えば、当業者には認識されるように、ソフトウェアとして示されている例示した実施形態の要素はハードウェアとして実施してもよく、そしてその逆も成り立ち、また、例示した実施形態は、本発明の精神から逸脱することなく構成および細部において変更可能である。したがって、本明細書に記載されている発明は、添付の特許請求の範囲およびその均等物の範囲内に入る可能性のあるすべてのそのような実施形態を想定している。
【図面の簡単な説明】
【００３９】
【図１】本発明の一実施形態を実施するために使用可能な例示的コンピュータシステムを一般的に示す概略図である。
【図２】本発明の一実施形態によるファイル転送を容易にするための例示的ピアツーピアネットワークを示す概略図である。
【図３】本発明の一実施形態によるピアツーピアネットワークで使用するためのファイル頒布および取得のプロセスを示すフローチャートである。
【図４】本発明の一実施形態によるピアツーピアネットワークで使用するためのファイル転送優先順位付け技法を示すフローチャートである。
【図５】本発明の一実施形態によるノードクライアント／サーバアーキテクチャを示す概略図である。
【符号の説明】
【００４０】
２０１  ピアツーピアネットワーク
５０１  ノードクライアント／サーバアーキテクチャ
５０３  クライアントファシリティ
５０５  サーバファシリティ
５０７  クライアントインタフェース
５１１  優先順位キュー
５１３  ノード接続インタフェース
５１５  ファイルインタフェース
５１７  サーバキャッシュ
５１９  サーバ優先順位キュー
【図１】
2004185618.tif 000003
【図２】
2004185618.tif 000004
【図３】
2004185618.tif 000005
【図４】
2004185618.tif 000006
【図５】
2004185618.tif 000007
【外国語明細書】
2004185618.tif 000008
2004185618.tif 000009
2004185618.tif 000010
2004185618.tif 000011
2004185618.tif 000012
2004185618.tif 000013
2004185618.tif 000014
2004185618.tif 000015
2004185618.tif 000016
2004185618.tif 000017
2004185618.tif 000018
2004185618.tif 000019
2004185618.tif 000020
2004185618.tif 000021
2004185618.tif 000022
2004185618.tif 000023
2004185618.tif 000024
2004185618.tif 000025
2004185618.tif 000026
2004185618.tif 000027
2004185618.tif 000028
2004185618.tif 000029
2004185618.tif 000030
2004185618.tif 000031
2004185618.tif 000032
2004185618.tif 000033
2004185618.tif 000034
2004185618.tif 000035
2004185618.tif 000036
2004185618.tif 000037