(57)【特許請求の範囲】
【請求項１】
トレントコンテンツメタデータ、即ちトレントコンテンツファイルサイズ、セグメント長、およびトレントコンテンツファイルのセグメントの量を、第１のクライアントで再構成する方法であって、
Ａ．前記トレントコンテンツファイルをダウンロードしている、トレントコンテンツメタファイルを入手している第２のクライアントからのトレント信号伝達からトレントコンテンツ識別子を取得するステップと、
Ｂ．前記第２のクライアントからの前記トレント信号伝達からトレントコンテンツファイルサイズを取得するステップと、
Ｃ．前記第２のクライアントからの前記トレント信号伝達からトラッカアドレスを取得するステップと、
Ｄ．前記トラッカからピアアドレスを取得するステップと、
Ｅ．前記ピアアドレスを介してピアと交信するステップと、
Ｆ．前記ピアからフルサイズセグメントの順次最小サイズブロックをダウンロードし、それにより前記セグメント長に関する情報が知られるステップと、
Ｇ．前記トレントコンテンツファイルサイズおよび前記セグメント長から前記セグメントの量を計算するステップと
を備えることを特徴とする、方法。
【請求項２】
前記ステップＥが前記ピアとハンドシェークすることを備え、それによって前記ピアのビットフィールドを検索し、前記ビットフィールド内の各ビットが前記トレントコンテンツファイルの対応するセグメントの可用性を表していることを特徴とする、請求項１に記載のトレントコンテンツメタデータを再構成する方法。
【請求項３】
−  前記ビットフィールドが複数のビットのセットを含むまで、または前記ビットフィールド内の第１のビットのみがセットされるまで、前記ステップＥおよび最終的には前記ステップＤもまた反復して繰り返し、
−  前記ビットフィールド内の第１のビットのみがセットされない限りセットされる前記ビットフィールド内の最後のビットとは異なるビットである、セットされる前記ビットフィールド内の前記ビットを選択し、
−  ブロック要求が拒否されるまで選択されたビットに対応するセグメントの最小サイズブロックのブロック要求を前記ピアに送信し、
−  送信されたブロック要求の数を数え、
−  最小サイズブロック長と前記ブロック要求の数を乗じて、それによって前記セグメント長を判定することと
を前記ステップＦが備えることを特徴とする、請求項２に記載のトレントコンテンツメタデータを再構成する方法。
【請求項４】
前記ステップＡが、ビットトレント信号伝達からの前記トレントコンテンツファイルを識別する固有トレント識別子またはインフォハッシュを取得することを備えることを特徴とする、請求項１に記載のトレントコンテンツメタデータを再構成する方法。
【請求項５】
−  ビットトレント信号伝達からダウンロードされたバイトの数および残されたバイトの数を取得し、
−  ダウンロードされたバイトの数および残されたバイトの数を合計することによって、トレントコンテンツファイルサイズを判定することと
を前記ステップＢが備えることを特徴とする、請求項１に記載のトレントコンテンツメタデータを再構成する方法。
【請求項６】
前記ステップＧが、前記セグメント長によって前記トレントコンテンツファイルサイズを除することによって前記セグメントの量を判定することを備えることを特徴とする、請求項１に記載のトレントコンテンツメタデータを再構成する方法。
【請求項７】
前記方法がさらに、Ｈ．前記トレントコンテンツファイルの１つまたは複数のセグメントをダウンロードおよびキャッシュするステップを備えることを特徴とする、請求項１に記載のトレントコンテンツメタデータを再構成する方法。
【請求項８】
プログラム可能な装置上で実行可能なプログラムであって、実行されると請求項１から７のいずれかに記載の方法を実行する命令を含むプログラム。
【請求項９】
請求項８に記載のプログラムを実行するようになされた、トレント情報再構成デバイス。
【請求項１０】
前記トレント情報再構成デバイスがビットトレントクライアント内に統合されることを特徴とする、請求項９に記載のトレント情報再構成デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概してピアツーピア通信に関し、より詳細には、その固定サイズ区分またはセグメントが１つまたは複数のピアに格納されるトレントコンテンツファイルをダウンロードすることおよびキャッシュすることに関する。トレントコンテンツファイルは、たとえば映画ファイル、音声ファイル、ソフトウェアファイルなどでもよい。ダウンロードすることおよびキャッシュすることは、そのダウンロードを実際に開始したものとは別のクライアントにトレントコンテンツファイルを格納することに関する。通常は、２つのダウンロードが進行していることになる：最新式機構による開始クライアントへの正規のダウンロードと、本発明によるキャッシングクライアントのための特定のダウンロードである。
【背景技術】
【０００２】
ビットトレントは、ビットトレントクライアントが、映画または歌などのトレントコンテンツファイルを再構成するために、１つまたは複数のピアからトレントコンテンツファイルの固定サイズセグメントをダウンロードすることを可能にする、ピアツーピア通信プロトコルである。ビットトレントクライアントは、そのビットトレントクライアントがトレントコンテンツファイルのセグメントを格納するピアのリストを保持するインターネットトラッカにそれを使って交信する、固有トレントコンテンツ識別子を必要とする。この固有トレントコンテンツ識別子は、トレントコンテンツメタファイル内で事前知識として公開される。ビットトレントクライアントは、インターネットトラッカからこれらのピアのＩＰアドレスを受信し、その結果として、全トレントコンテンツファイルをダウンロードし、再構成するために、これらのピアとセグメントの交換を開始することができる。そのビットトレントクライアントは、トレントコンテンツファイルサイズ、トレントコンテンツファイルが分割されたセグメントの数、および、最後のかかるセグメント以外のすべてについての固定長を必要とする。これらのメタデータはまた、トレントコンテンツメタファイル内で事前知識として公開される。
【０００３】
トレントコンテンツをダウンロードおよびキャッシュするための前述の知られている方法の欠点は、トレントコンテンツメタファイルが、トレントコンテンツファイルをダウンロードすることを望むすべてのクライアントに必ずしも使用可能でないことがあり、その結果として、トレントコンテンツメタファイルを入手できないクライアントには、トレントコンテンツファイルをダウンロードおよびキャッシュすることが可能ではないということである。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、トレントコンテンツメタファイルへのアクセスなしにトレントコンテンツファイルのダウンロードを可能にするために必要な欠落しているトレントコンテンツメタデータを再構成する方法およびデバイスを開示することである。
【課題を解決するための手段】
【０００５】
本発明によれば、前述の定義された目的が実現され、先行技術の欠点は、請求項１によって定義されるような欠落トレントコンテンツメタデータを再構成する方法によって克服され、方法は：
Ａ．クライアントからのトレント信号伝達からトレントコンテンツ識別子を取得するステップと、
Ｂ．前記クライアントからの前記トレント信号伝達からトレントコンテンツファイルサイズを取得するステップと、
Ｃ．前記クライアントからの前記トレント信号伝達からトラッカアドレスを取得するステップと、
Ｄ．トラッカからピアアドレスを取得するステップと、
Ｅ．そのピアアドレスを介してピアと交信するステップと、
Ｆ．セグメント長を判定するために、そのピアからフルサイズセグメントの順次最小サイズブロックをダウンロードするステップと、
Ｇ．トレントコンテンツファイルサイズおよびセグメント長からセグメントの量を計算するステップ。
【０００６】
実際に、本発明によれば、トレントコンテンツファイルをダウンロードおよびキャッシュすることを望むクライアントは、メタファイルへのアクセスで目標トレントコンテンツファイルをダウンロードしている別の標準クライアントからの信号伝達から、ビットトレントの場合のインフォハッシュなどのトレントコンテンツ識別子を取得する。しかし、本発明にしたがって動作するキャッシングクライアントは、メタファイルを入手できない。このキャッシングクライアントはさらに、インターネットトラッカから、目標トレントコンテンツファイルのフルサイズセグメントを保持するピアのＩＰアドレスを取得する必要がある。通常は、キャッシングクライアントは、単一の要求に応答して複数のピアアドレスを受信することになる。本発明にしたがって動作するキャッシングクライアントは、インターネットトラッカ（そのアドレスが標準クライアントからのトレント信号伝達から取得された）と交信し、目標トレントコンテンツファイルのセグメントを格納するピアのＩＰアドレスをそのインターネットトラッカから取得する。ピアが保証されたフルセグメントサイズをもたない単一のセグメントのみを含む場合、以下に説明されるように、ステップＤおよびＥが反復して繰り返されなければならないことがある。通常は、キャッシングクライアントは、ステップＤで１つの要求に応答して複数のピアアドレスを受信することになることにも留意されたい。ブロック要求が拒否されるまで、１６キロバイトブロックなどの最小サイズブロックを順次にダウンロードすることによって、クライアントは、セグメントのサイズを知ることができる。標準クライアントからのビットトレント信号伝達から、キャッシングクライアントはさらに、トレントコンテンツファイルサイズを取得する。最後の欠落パラメータ、そのトレントコンテンツファイル内のセグメントの量が、セグメントサイズおよびトレントコンテンツファイルサイズからキャッシングクライアント（および、以下に説明されるような、ビットフィールド長に対する最終的検証）によって判定されることができる。
【０００７】
請求項１によって定義される方法とは別に、本発明はまた、請求項１の方法を実行するためのソフトウェアを保持するキャリアまたはメモリデバイスなどの請求項８によって定義されるような対応するデバイスに関する。
【０００８】
１つまたは複数のトレントコンテンツメタファイルを入手せずにトレントコンテンツをキャッシュすることを望む任意のシステムは、本発明の利益を受けることができる。かかるシステムの一例は、請求項９によって示されるような、ビットトレントクライアントである。
【０００９】
請求項２によって定義されるように、さらに任意で、本発明による本方法のステップＥは、ピアとのハンドシェークを備えることができ、それによって、そのビットフィールド内の各ビットがトレントコンテンツファイルの対応するセグメントの可用性を表す、ピアのビットフィールドを検索する。
【００１０】
実際に、ビットトレントクライアントは、目標トレントコンテンツファイルと関連付けられたビットフィールドを受信するために、そのＩＰアドレスがインターネットトラッカから受信されたピアと交信することになる。このビットフィールドは、応答して受信され、（ビットフィールド長に対応する）セグメントの可能な最大数、およびトレントコンテンツファイルのどのセグメントがそのピアに格納されるかを示すことになる。ビットフィールドは通常は、トレントコンテンツファイル内に存在するセグメントと同数のビットを含む。ビットフィールド内では、対応するセグメントが使用可能およびピアからダウンロード可能なときにビットがセットされ（「１」または「真」）、対応するセグメントがピアで使用可能でないときにビットはセットされない（「ゼロ」または「偽」）。
【００１１】
請求項３によって定義されるように、さらに任意で、本発明による本方法のステップＦは：
−  ビットフィールドが複数のビットセットを含むまで、またはビットフィールド内の第１のビットのみがセットされるまで、ステップＥおよびついにはステップＤもまた反復して繰り返し、
−  ビットフィールド内の第１のビットのみがセットされない限りセットされるビットフィールド内の最後のビットとは異なるビットをセットされるビットフィールド内で選択し、
―  ブロック要求が拒否されるまで、選択されたビットに対応するセグメントの最小サイズブロックのブロック要求をピアに送信し、
―  送信されたブロック要求の数を数え、
―  ブロック要求の数を最小サイズブロック長と乗じて、それによってセグメント長を判定すること、を備えることができる。
【００１２】
実際に、キャッシングクライアントは、ビットフィールドから区分サイズ（またはセグメントサイズまたはセグメント長）を導出する必要がある。キャッシングクライアントは、それがセグメントの境界線に到達するまで、セグメントの小ブロックを順次にダウンロードすることになるが、ダウンロードされるセグメントがフルサイズセグメントであることを事前ニーズが保証する。通常は、トレントコンテンツファイルの最後のセグメントはフルサイズセグメントではないことになる。したがって、受信されたビットフィールド内の最後のセットビットは、フルサイズセグメントを表すまたは表さないことがあり、セグメント長を判定するためにキャッシングクライアントによって使用されることはできない。したがって、キャッシングクライアントは最後のセットビットとは異なる、ビットフィールド内のビットと対応するセグメントの小ブロックを順次にダウンロードすることになる。ビットフィールドが１セットビットのみを含む場合、クライアントはそのビットフィールドを破棄し、ステップＤおよびＥを繰り返すことによって、異なるピアとのハンドシェークを試みることになる。キャッシングクライアントがステップＤの前の実行で複数のピアアドレスを受信していた場合、そのキャッシングクライアントは他のピアのうちの１つと交信することを試みることができるので、ステップＤは繰り返される必要はない。例外的に、ビットフィールドが１セットビットのみを含み、このビットがビットフィールド内の第１のビットであるとき、キャッシングクライアントは、セグメント長を確立するために、斬進的ダウンロードのための第１のセグメントを選択することができる。キャッシングクライアントは、選択されたセグメントの最小サイズブロックの要求の送信を開始することになる。ブロック要求が拒否されるとき、これはセグメントの終わりを示す。拒否されなかった送信されたブロック要求の数を数え、この数を１６キロバイトなどの最小サイズブロックの長さと乗じることによって、キャッシングクライアントは、目標トレントコンテンツファイルのセグメント長を判定することができる。
【００１３】
また、請求項４によって定義されるように、本発明による本方法のステップＡは、ビットトレント信号伝達からトレントコンテンツファイルを識別する固有トレント識別子（インフォハッシュ）を取得することを備えることができる。
【００１４】
実際に、ビットトレントの場合、トレントコンテンツファイルを識別する固有トレント識別子（インフォハッシュ）は、メタファイルへのアクセスで目標トレントコンテンツファイルをダウンロードしている標準クライアントからのビットトレント信号伝達から取得されることができる。
【００１５】
請求項５によって定義される、本発明による本方法の別の任意選択の態様は、ステップＢが以下：
−  標準ビットトレントクライアントからのビットトレント信号伝達からダウンロードされたバイト数、および残されたバイト数を取得し、
−  ダウンロードされたバイト数および残されたバイト数を合計することによってトレントコンテンツファイルサイズを判定すること、を備えることができる。
【００１６】
さらに、ビットトレントの場合には、残されたバイトの数およびダウンロードされたバイトの数は、そのメタファイルへのアクセスでトレントコンテンツファイルをダウンロードしている別の標準クライアントからのビットトレント信号伝達から取得されることができる。これらの２つの数字は、一緒に合計されるときに、クライアントにトレントコンテンツファイルサイズの予測を与える。しかし、報告されたファイルサイズが疑わしい場合、クライアントは、ビットフィールド長、即ちステップＥまたはこのステップの反復でピアから受信される最大ビットフィールド長、および、ステップＦで判定されるようなセグメント長からファイルサイズを判定することを選ぶことができる。最後のセグメントは不完全なものであることがあるので、ビットフィールド長およびセグメントサイズの乗算は、実際のトレントコンテンツファイルサイズとは異なり得ることにここで留意されたい。
【００１７】
さらに任意で、請求項６によって定義されるように、本発明による本方法では、ステップＧは、セグメント長でトレントコンテンツファイルサイズを除することを介して、セグメントの量を判定することを備えることができる。
【００１８】
実際に、クライアントは、メタデータのその知識を完成するために、目標トレントコンテンツファイルを構成する区分の数またはセグメントの量をやはり導出しなければならない。ステップＣで判定されるセグメント長によってステップＥで判定されるファイルサイズを除することによって、クライアントは、セグメントの量を計算することができる。
【００１９】
請求項７によって示されるように、本発明によるトレントコンテンツメタデータを再構成する方法は、以下の任意選択のステップ：
Ｈ．トレントコンテンツファイルの１つまたは複数のセグメントをダウンロードし、キャッシュするステップ、で補完されることができる。
【００２０】
したがって、再構成されたメタデータのトレント識別子の知識、即ちトレントコンテンツファイルサイズ、セグメント長、およびセグメントの量、を使って、クライアントまたはキャッシングノードはトレントコンテンツファイルのダウンロードを開始し、それを部分的にまたは完全にキャッシュメモリに格納することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明によるトレントコンテンツメタファイルへのアクセスなしでトレントコンテンツメタデータを再構成する方法の一実施形態を説明する図である。
【発明を実施するための形態】
【００２２】
図１は、ビットトレントキャッシュクライアント１０１およびピア１０２、即ち映画ファイル「レイダース−失われたアーク」などのトレントコンテンツファイルのある特定のセグメントを格納する機械、を示す。ピア１０２はまたビットトレントプロトコルをサポートすると仮定する。キャッシュクライアント１０１およびピア１０２の両方がインターネット接続性をもち、キャッシュクライアント１０１は、メタファイルへのアクセスで目標映画ファイルをダウンロードしている別の標準クライアントからのビットトレント信号伝達からのインターネットトラッカからピア１０２のＩＰアドレスを取得済みである。
【００２３】
他方の標準クライアンからのビットトレント信号伝達から、キャッシュクライアント１０１はさらに、目標トレントコンテンツファイル、即ち映画「レイダース−失われたアーク」、を識別する固有トレント識別子（インフォハッシュ）と、その合計が期待トレントコンテンツファイルサイズを与える残されたバイトの量およびダウンロードされたバイトの量とを取得する。
【００２４】
キャッシュクライアント１０１は、ピア１０２と交信して、目標トレントコンテンツファイル、即ち映画「レイダース−失われたアーク」、に関連付けられたビットフィールドを受信する。これは、ピア１０２との第１のハンドシェークである。ビットフィールド１０３が、ピア１０２からの応答で受信される。
【００２５】
受信されたビットフィールド１０３から、キャッシュクライアント１０１は、セグメントサイズ、および目標トレントコンテンツファイルのセグメントの数を導出しなければならない。これは、以下のように行われる。キャッシュクライアント１０１は最初に、保証されたフルセグメントサイズをもつセグメントを見つけなければならない。ビットフィールド１０３内の最後のセットビットを除く任意のビットが、ピア１０２からダウンロードされることができる保証されたフルセグメントサイズをもつセグメントを表す。最後のセットビットは、フルセグメントサイズをもつセグメントを表すまたは表さないことがあり、したがって、セグメントサイズを判定するのに頼りにされることはできない。ビットフィールドがビットセットを１つのみもつ場合、およびこれが第１のビットではない場合、そのとき、キャッシュクライアント１０１は、そのビットフィールドからセグメントサイズを導出することはできない。かかる場合には、キャッシュクライアント１０１はそのビットフィールドを破棄し、異なるピアとのハンドシェークを試みることになる。図１では、ビットフィールド１０３は複数のセットビットを含むと仮定されている。キャッシュクライアント１０１は、ビット１０４などの最後のセットビットより前の任意のセットビットを選び、そのビットの数をトレントコンテンツファイルの対応するセグメントのダウンロードを開始するためのＩＤとする。キャッシュクライアント１０１は、それがビットフィールド１０３内の選択されたビット１０４に対応するセグメントに関心をもっていることを他方のピア１０２に知らせる。その後すぐにキャッシュクライアント１０１は、最小サイズブロック１０５、即ちブロック１０６のような１６キロバイトの後のブロック、の区分要求の送信を開始する。キャッシュクライアント１０１はまた、送信されたブロック要求の数を数え続ける。ブロック要求が拒否されると直ちに、これはセグメントの終わりを示す。キャッシュクライアント１０１はここで、ブロックサイズで乗じられた成功したブロック要求の数からセグメントサイズを計算することができる。キャッシュクライアント１０１は最後に、セグメントサイズによってファイルサイズを除することにより、または、ファイルサイズが信頼できない場合には、セグメントサイズで乗じられた最大ビットフィールド長から、セグメントの数を判定する。
【００２６】
前述の実施形態では、最初に報告されたファイルサイズが正しい、即ちキャッシュクライアント１０１にトレントコンテンツファイルをキャッシュすることを要求する最初のクライアントが正しいおよび完全な残されたバイトおよびダウンロードされたバイトの情報を提供すると仮定している。前述の実施形態のわずかな修正が、最初に報告されたファイルサイズが誤っている場合でも、（ほぼ完全な）トレントコンテンツのダウンロードを可能にする。別の代替実施形態では、フルサイズセグメントを保持するピアが交信され、その結果として本方法のステップＡおよびＢの反復を減らすまたは回避することになる可能性を増やすために、複数のピアが同時に交信されることができる。
【００２７】
本発明は特定の実施形態を参照して説明されているが、本発明は前述の例示的な実施形態の詳細に限定されず、本発明はその範囲を逸脱することなしにさまざまな変更および修正を加えて実施されることができることが当業者には明らかとなろう。したがって、本実施形態は、あらゆる点で例示的であり限定的でないものと見なされるべきであり、本発明の範囲は、前述の説明によってではなくて添付の特許請求の範囲によって示され、したがって、特許請求の範囲の同等の意味および範囲に含まれるすべての変更はそこに包含されるものとする。換言すれば、それは、基本的な基礎となる原理の範囲に含まれる、またその本質的な特性が本特許出願において特許請求される、任意のおよびすべての修正、変更または同等物を包含するものと考えられる。言葉「備えている」または「備える」は他の要素またはステップを排除せず、言葉「１つの」は複数性を排除せず、コンピュータシステム、プロセッサまたは別の統合ユニットなどの単一の要素が本特許請求の範囲に挙げられたいくつかの手段の機能を実行し得ることが、本特許出願の読者にはさらに理解されよう。本特許請求の範囲中の参照符号は、関連するそれぞれの請求項を制限するものとして解釈されないものとする。用語「第１の」、「第２の」、「第３の」、「ａ」、「ｂ」、「ｃ」などは、本明細書または本特許請求の範囲で使用されるとき、同様の要素またはステップを区別するために取り入れられ、必ずしも発生順または時系列で記述されない。同様に、「上部」、「下部」、「上」、「下」などの用語は、説明を目的として取り入れられ、必ずしも相対的な位置を示さない。そのように使用される用語は適当な状況下で置換え可能であり、本発明の実施形態は、他の順番であるいは１つまたは複数の前述のまたは図解されたものとは異なる方向で本発明にしたがって動作することができることが理解されよう。
【図１】
0005363593.tif 000002