JP4208920B2

JP4208920B2 - ＢｉｔＴｏｒｒｅｎｔプロトコルによるファイルのダウンロード方法

Info

Publication number: JP4208920B2
Application number: JP2006517880A
Authority: JP
Inventors: 雅博井筒; 邦彦仲田; 通雅須澤
Original assignee: 株式会社グリッド・ソリューションズ; 雅博井筒; 邦彦仲田; 通雅須澤
Priority date: 2005-01-28
Filing date: 2005-01-28
Publication date: 2009-01-14
Anticipated expiration: 2025-01-28
Also published as: JPWO2006080083A1; US7379967B2; WO2006080083A1; US20070028133A1

Description

この発明は、Ｐ２Ｐプロトコル（ピアツーピア、サーバを介さずクライアント同士が通信する方式）のひとつであるＢｉｔＴｏｒｒｅｎｔプロトコルの改良に関する。

＜従来の技術（１）＞
インターネットを用いた映像ファイルのデータ配信サービスが提供されている。このシステムを模式的に表現したものが図１であり、複数の配信サーバ１００からインターネット１０２を介してクライアントＰＣ（パソコン）１０１へ直接データを配信している。

図１のシステムでデータを配信するのためのプロトコルとして次のようなものが一般的である。
（１）ｈｔｔｐプロトコル（ｗｗｗサーバで利用されている形式）
（２）ｆｔｐプロトコル（ファイルサーバ等で利用されている形式）
（３）ｒｔｓｐプロトコル（リアルタイムストリーミングプロトコル。ストリーミング形式で利用されている形式。）

映像ファイルのサイズは非常に大きい。ギガバイトサイズのファイルになると、配信サーバの負荷と、ネットワーク回線の帯域消費が大きいため、従来の技術で同時に多数の人に配信するには莫大な設備投資とランニングコストを必要とする。

上記従来の技術（プロトコル）は、いずれもサーバとクライアントＰＣ（パソコン：視聴者、ユーザ）を直結するものであり、その間でサーバと回線のリソースを占有するため、ユーザ数に比例したコストがかかる。

＜従来の技術（２）＞
上記問題点を解消するために開発された一つの方式に「ＢｉｔＴｏｒｒｅｎｔプロトコル」という一種のＰ２Ｐプロトコル（ピアツーピア、サーバを介さずクライアント同士が通信する方式）がある。この方式の発想は、図２に示すように、スーパーシーダー（オリジン（原本）サーバともいわれる）１１０と呼ばれる原本ファイルを保有するサーバを起点に、バケツリレー式にファイルを渡していくというものである。各受信者はリーチャー１１１と呼ばれ、受信した部分からピースシーダーとして受信した部分を他のピアに配信していく。少なくとも一部のファイルを受信したクライアントは当該部分を配信する役目も果たし、ピースシーダーと呼ばれる。完全に受信のみのピアはリーチャーヒル１１２と呼ばれる。リーチャーヒル１１２は、図１のクライアントＰＣ１０１に相当するものであり、ピースシーダー（リーチャー）１１１は、図１のクライアントＰＣ１０１であるが他方配信サーバ１００にも相当する。ピースシーダー（リーチャー）１１１は、受信と同じ回数だけ送信すれば最後のクライアントまでピースが行き渡る。（以後、類似の方式を総称して「ＢｉｔＴｏｒｒｅｎｔ方式」と称することとする。また「バケツリレー式配信」を、以後「グリッド配信」と称することとする。）

ＢｉｔＴｏｒｒｅｎｔ方式に係るＵＲＬには「．ｔｏｒｒｅｎｔ」という拡張子がつけられている。この．ｔｏｒｒｅｎｔファイルをＢｉｔＴｏｒｒｅｎｔ対応ファイル共有ソフトに読み込ませるとファイル共有（ファイルのダウンロード・アップロード）が開始される。ファイルのダウンロード中であっても自分（クライアント）がいままでダウンロードした部分は要求に応じてアップロードされる。

理論的には、シーダーサーバ１１０はクライアント数によらず１回だけ配信すればすべてのクライアント１１１，１１２にファイルが行き渡るため、一つのファイルに関して言えばクライアント数によらずシーダーサーバ１１０の負荷がほぼ一定になるという利点がある。（実際には１回だけではなく複数の配信を複数のピアに対して行うことによりネットワーク全体の配信効率を向上させている）

図３にＢｉｔＴｏｒｒｅｎｔ方式のシステムの概要を示す。ＢｉｔＴｏｒｒｅｎｔ方式を実現するために、実際にはグリッド配信に参加するピア（クライアントＰＣ）Ｐのアドレスを登録管理するトラッカー１２０という中央制御サーバが存在する。トラッカーサーバ１２０は、各ピアＰからのネットワーク参加要求を受け付けてそのリクエストを発したピアＰのアドレス（ＩＰアドレス及びポート）の一覧を、当該ピアＰが欲しがっているファイルを一意に特定する識別子（ファイルＩＤ）ごとに作成する。当該一覧をアクティブピアテーブル１２０ａという（図４）。

図３のネットワーク１２１に参加するためには、先ず、ピアＰは、グリッド配信の接続先クライアントを知るために、トラッカーサーバ１２０に対して問い合わせ、接続先のピアＰのアドレスを知る事ができる。その際、問い合わせ元のピアＰのアドレス（ＩＰアドレス及びポート）、及び当該ピアＰが欲しがっているファイルを一意に特定する識別子（ファイルＩＤ）が、アクティブピアテーブル１２０ａに登録される。トラッカーサーバ１２０からの応答により接続先のアドレスを知ったピアＰは、対応するピアＰに接続し、以後は図２に示すようなピア同士でのバケツリレー的な通信（グリッド配信）が行われる。図３において太線はデータ通信を示し、細い線はアクティブピアテーブル１２０ａへの登録のためのトラッカーサーバ１２０との通信を示す。

ピアＰはクライアントＰＣであるが、同時にシーダー（シーダー又はピースシーダー）にもなる。すなわち、特定のファイルを１００％ダウンロードしたとき（ひとつのコンテンツのファイルＡとＢの２つからなるときはＡ又はＢを１００％ダウンロードしたとき）、クライアントＰＣはシーダーになり、そのようにアクティブピアテーブル１２０ａで管理される。図３のネットワーク１２１において各ノードはシーダーであるかどうか個々に異なるのでピアＰと表現している。ネットワーク１２１の各ピアＰは特定のファイルについてシーダーであるか、又は単なるクライアント（リーチャー）であるかどちらか一方である。その状態はファイルごとに異なり一定ではないが、アクティブピアテーブル１２０ａを参照することにより、特定のファイルについて、どのピアＰがシーダーであるかを知ることができる。

ＢｉｔＴｏｒｒｅｎｔ方式では、ネットワーク上に、原本ファイルを保持するピアが常に存在するとは限らないので、リーチャーがいる限りネットワーク上のどこかに「完全な原本を持った」シーダー（スーパーシーダー）が起動している必要がある。「完全な原本」を確保するためにはスーパーシーダーが少なくとも１台か、あるいは複数のピースシーダーを集めた結果が完全な原本になるのに十分な量のピースシーダーが起動している必要がある。ピースシーダーの起動数を保証することは不可能なので、実際にはひとつのファイル（コンテンツ）についてスーパーシーダーが常時１台必要となる。サービス提供業者はそのようなスーパーシーダーを用意しなければならない。

従って、スーパーシーダーの負荷は、ピア数（ユーザ数）ではなく原本ファイルの種類に比例して増大する（２種類のファイルを一人に配信するシーダーは、１種類のファイルを二人に配信するシーダーの約２倍の負荷がかかる）ことになる。このため、ＢｉｔＴｏｒｒｅｎｔ方式は少数の大型ファイルを配信するには向いているが、ファイル数が多くなるとスーパーシーダーの負荷が増えることになり、設備投資や運用コストの増大要因となっている。

本発明は上記課題を解決するためになされたもので、ＢｉｔＴｏｒｒｅｎｔ方式において、ファイル数が増えた際のスーパーシーダーの負荷を軽減する方法を提案する。

この発明に係るファイルのダウンロード方法は、少なくとも１つのクライアントと、予め記憶しているファイルを要求に応じて送信するスーパーシーダーと、少なくともクライアント及び／又はスーパーシーダーのアドレス、当該アドレスのコンピュータが記憶しているファイルを要求に応じて送信可能であるかどうかを示すシーダーフラグ及び記憶しているファイルを要求に応じて送信可能であるコンピュータの数を記憶するテーブルであってファイルごとに生成されるアクティブピアテーブルと、スーパーシーダーのアドレスを記憶するスーパーシーダーテーブルとを含むトラッカーと、を備えるコンピュータネットワークにおいてファイルをダウンロードする方法であって、
クライアントからトラッカーへイベント開始通知及びファイルのダウンロード希望通知を送る第１ステップと、
前記ダウンロード希望通知を受けて当該クライアントを前記ファイルに対応するアクティブピアテーブルに登録する第２ステップと、
前記アクティブピアテーブルで前記ファイルを送信可能なコンピュータの数が予め設定した所定の値ｍ以下であるとき、前記ファイルに対応するスーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索する第３ステップと、
トラッカーから前記第３ステップで検索されたスーパーシーダーへプロセス起動指示を送る第４ステップと、
前記プロセス起動指示を受けて当該スーパーシーダーでプロセスを起動する第５ステップと、
当該スーパーシーダーからトラッカーへシーディング開始通知を送る第６ステップと、
前記シーディング開始通知を受けて当該スーパーシーダーを前記アクティブピアテーブルに登録する第７ステップと、
前記アクティブピアテーブルに基づき当該スーパーシーダーから当該クライアントへ前記ファイルをダウンロードする第８ステップと、
クライアントからトラッカーへ受信完了通知を送る第９ステップと、
前記受信完了通知を受けて前記ファイルに対応するアクティブピアテーブルの当該クライアントのシーダーフラグをセットするとともに、前記ファイルを送信可能なコンピュータの数を更新する第１０ステップと、
前記ファイルを送信可能なコンピュータの数を予め定められた閾値ｎと比較する第１１ステップと、
前記ファイルを送信可能なコンピュータの数が閾値ｎを超えたときにプロセス停止要求を生成する第１２ステップと、
前記プロセス停止要求を前記アクティブピアテーブルに含まれるスーパーシーダーへ送る第１３ステップと、
前記プロセス停止要求を受けてスーパーシーダーでプロセスを停止する第１４ステップと、を備えるものである。

上記方法を実現するためのプログラムは、例えば、記録媒体に記録される。
記録媒体は、例えば、ＥＰＲＯＭデバイス、フラッシュメモリデバイス、フレキシブルディスク、ハードディスク、磁気テープ、光磁気ディスク、ＣＤ（ＣＤ−ＲＯＭ、Ｖｉｄｅｏ−ＣＤを含む）、ＤＶＤ（ＤＶＤ−Ｖｉｄｅｏ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭを含む）、ＲＯＭカートリッジ、バッテリバックアップ付きのＲＡＭメモリカートリッジ、フラッシュメモリカートリッジ、不揮発性ＲＡＭカートリッジ等を含む。

記録媒体とは、何等かの物理的手段により情報（主にデジタルデータ、プログラム）が記録されているものであって、コンピュータ、専用プロセッサ等の処理装置に所定の機能を行わせることができるものである。

＜用語の説明＞
ピア：Ｐ２Ｐネットワークを構成するコンピュータである。ひとつのピアがＰ２Ｐネットワークのノードになる。スーパーシーダー、ピースシーダー（リーチャー、リーチャーヒル）はそれぞれノードの種類である。なお、トラッカーはピアに含まれない。
サーバ：コンピュータネットワークにおいて、クライアントコンピュータに対し、自身の持っている機能やデータを提供するコンピュータのことである。サーバもピアとなり得る（例えばスーパーシーダー）。
クライアント：コンピュータネットワークにおいて、サーバコンピュータの提供する機能やデータを利用するコンピュータのことである。クライアントもピアとなり得る（例えば、ピースシーダー（リーチャー））。

本発明の実施の形態に係るＰ２Ｐネットワークを構成するクライアントは、上記のようなデータの受けるクライアントと同時に、ピースシーダーのようにサーバとして動作することがある。以下の説明において、ネットワークの構成を説明するときはピアという言葉を用い（例えば図３）、その機能について説明するときは、データ送信等のサービスを提供するピアをサーバ、スーパーシーダー又はシーダーという言葉で表現し、サービスを受けるピアをクライアントという言葉で表現する。

ＢｉｔＴｏｒｒｅｎｔ固有の用語について簡単に説明する。
（１）トレントファイル（ＴｏｒｒｅｎｔＦｉｌｅ）
ファイル情報やトラッカーのアドレス等が記載されているファイルである。ＢｉｔＴｏｒｒｅｎｔによるＰ２Ｐネットワークに参加する際に、最初に取得すべきものである。
（２）トラッカー（Ｔｒａｃｋｅｒ）
ファイルの持ち主を教えてくれる重要なコンピュータ（サーバ）である。ＢｉｔＴｏｒｒｅｎｔクライアントは、．ｔｏｒｒｅｎｔファイル内に記載されているトラッカーに接続し、ファイルの持ち主のアドレスを取得する。
（３）シーダー（Ｓｅｅｄｅｒ）
ダウンロード完了したクライアントのことで、アップロード可能なピアのことである。ＢｉｔＴｏｒｒｅｎｔでは、ファイルの一部をダウンロードしたクライアントも当該ダウンロード部分についてアップロード可能である。このようなピアのことをピースシーダーと呼ぶ。
（４）リーチャー（Ｌｅｅｃｈｅｒ）
まだダウンロードを完了していないクライアントのことである。

本発明の実施の形態に係るシステム／方法は、映画の映像ファイルのような大きなサイズの（いわゆる重い）ファイルのダウンロードサービスを提供するものである。従来、映像ファイルはストリーミング型で提供されているが、本発明の実施の形態に係るシステム／方法はダウンロード型で提供するものであり、ファイル配信サーバ・クライアントシステムである。本発明の実施の形態に係るシステム／方法で提供する映像ファイルは、例えば、ＷＭＶ９という形式の圧縮形式による、ビットレート（動画像データの時間あたり情報量）１．５Ｍｂｐｓ以上の画像ファイルである。

トラッカーサーバのアクティブピアテーブルを改良した改良版アクティブピアテーブル（図５参照）、および新規に考案したスーパーシーダーテーブル（図６参照）を、次のように定義する。

（１）改良版アクティブピアテーブルは、当該ファイルを保有しているか、または受信を希望しているピア（シーダーまたはリーチャー）の一覧である。各ピアは、トラッカーに対しバケツリレーの接続先のアドレスを問い合わせたとき、このテーブル内のピアを所定の方法（ランダム選択でもよい）で選択して、問い合わせのあったピアに回答することでグリッド配信ネットワーク（バケツリレーの輪）を広げていくように動作する。

（２）スーパーシーダーテーブルは、ファイルごとにスーパーシーダーのアドレスを対応づけた一覧である。スーパーシーダーにより提供されるファイルの種類はサービスＩＤ（ファイルの識別情報）で特定される。

図７〜図１０の説明図、及び、図１１〜図１３のフローチャートを参照して、本発明の実施の形態に係るシステム／方法を説明する。

先ず初期設定を行う（図１１のＳＴ０、ＳＣ０，ＳＣ１）。
初期状態ではアクティブピアテーブルは空である（図５）。
スーパーシーダーテーブルには、サービスＩＤごとにスーパーシーダーのアドレスを少なくとも１つ登録しておく。例としてサービスＩＤはＣｏｒｐ１、Ｃｏｒｐ２と定義し、Ｃｏｒｐ１のサービスではファイルＡ，Ｂを、Ｃｏｒｐ２のサービスではファイルＣ，Ｄを配信しているものとする（図６）。サービスＩＤは、原本ファイルの出典ごとに管理される。サービスＩＤは、原本ファイルの配信元（スーパーシーダー）を特定するためのＩＤである。

クライアントは、ファイルＡを持っていない状態で起動される。起動すると、トラッカーに対しイベント通知（セッションスタート）をするとともに（図１１のＳＣ２）、「サービスＩＤ＝Ｃｏｒｐ１、ファイルＡ」のダウンロードを希望している旨を、例えば次のように通知する（図１１のＳＣ３）。この通知は例えばＨＴＴＰ（Ｓ）プロトコルである。
ＧＥＴｈｔｔｐ：／／ｔｒａｃｋｅｒｓｅｒｖｅｒ／ｔｒａｃｋ．ｃｇｉ？ｅｖｅｎｔ＝ｓｅｓｓｉｏｎｓｔａｒｔ＆ＦＩＬＥ＝ファイルＡ＆サービスＩＤ＝Ｃｏｒｐ１＆Ｓｅｅｄｅｒ＝０
「＆サービスＩＤ＝Ｃｏｒｐ１＆Ｓｅｅｄｅｒ＝０」は本発明の実施の形態に係る新規な部分である。
ここで末尾につけたＳｅｅｄｅｒ＝０というフラグは、自己がファイルＡをまだ保持していないことを示す。サービスＩＤが１つしかない場合はサービスＩＤを省略してもよい。

これを受けたトラッカーは、クライアント１のＩＰアドレスとポート番号をＩＰパケットヘッダから読み取ってアクティブピアテーブルに次のように登録する（図７、図１１及び図１２のＳＴ１）。

Ｓｅｅｄｅｒフラグの合計値を調べる。Ｓｅｅｄｅｒフラグの合計値（ファイルを送信可能なコンピュータの数）が予め設定した所定の値ｍ（例えば２）より小さいとき、スーパーシーダーを起動する。例えば、Ｓｅｅｄｅｒフラグの合計値＝０つまりシーダーとなるべきピアが全く存在しない場合には当然にスーパーシーダーを起動する。なお、プログラムで所定の値ｍを変数として設定変更可能としてもよい。なぜなら、「ｍ＝１」のときには理論上はスーパーシーダーの起動は不要であるが、ネットワークの状況にもよるが、「Ｓｅｅｄｅｒフラグ＝１のピア」に送信要求が集中して過負荷になる可能性が想定され、そのためのバッファとしてシーダーが（ゼロに限らずとも）少ないときはスーパーシーダーの起動を行い、送信リクエストを分散させることが好ましいからである。
アクティブピアテーブルのＳｅｅｄｅｒフラグの合計値が０であるので（図１２のＳＴ２で＜ｍ）、トラッカーはスーパーシーダーの起動を行う。

具体的には図６のスーパーシーダーテーブルからサービスＩＤ＝Ｃｏｒｐ１となっているスーパーシーダーを探して、そのアドレスをスーパーシーダーテーブルから読み取る（図１１及び図１２のＳＴ３）。ここで、複数のスーパーシーダーが登録されているときは、ラウンドロビン（ｒｏｕｎｄ−ｒｏｂｉｎｓｃｈｅｄｕｌｉｎｇ：ユーザーのリストを繰り返し見通して，各ユーザーが順に中央処理装置を使う機会をえるようにするスケジューリング用アルゴリズム。例えば、前回の選択値を記憶しておき、順番に次の欄を選択していく）を行う。ここでは例として２００．０．０．２が選択されたとする。

つづいてトラッカーは、選択されたスーパーシーダーのアドレスに対し、ＨＴＴＰプロトコル等を用いて次のようなプロセス起動指示を行う（図１１及び図１２のＳＴ４）。
ＧＥＴｈｔｔｐ：／／２００．０．０．２／ｓｅｅｄｅｒ．ｃｇｉ？ｅｖｅｎｔ＝ｓｅｅｄｉｎｇｓｔａｒｔ＆ＦＩＬＥ＝ファイルＡ

これを受けたスーパーシーダーサーバ（２００．０．０．２）は、シーダーのプロセスを起動し（図１１のＳＳ１）、ファイルＡのシーディング（原本供給）を開始する。具体的には、先のクライアント１と同じ手順で、Ｓｅｅｄｅｒフラグを１としてトラッカーに要求を送る（図１１のＳＳ２）。
ＧＥＴｈｔｔｐ：／／ｔｒａｃｋｅｒｓｅｒｖｅｒ／ｔｒａｃｋ．ｃｇｉ？ｅｖｅｎｔ＝ｓｅｓｓｉｏｎｓｔａｒｔ＆サービスＩＤ＝Ｃｏｒｐ１＆ＦＩＬＥ＝ファイルＡ＆Ｓｅｅｄｅｒ＝１
サービスＩＤはスーパーシーダーごとにあらかじめ決めて設定しておけばよい。

これを受けたトラッカーは、アクティブピアテーブルに図８のように登録する。
これにより、ネットワーク上にはシーダーが存在するため、クライアント１は完全な原本を取得することができるようになる。

クライアント１が完全に受信を完了すると、クライアント１はトラッカーに対し、次のような受信完了通知を行う（図１１のＳＣ１０）。
ＧＥＴｈｔｔｐ：／／ｔｒａｃｋｅｒｓｅｒｖｅｒ／ｔｒａｃｋ．ｃｇｉ？ｅｖｅｎｔ＝ｓｅｓｓｉｏｎｃｏｍｐｌｅｔｅ＆サービスＩＤ＝Ｃｏｒｐ１＆ＦＩＬＥ＝ファイルＡ＆Ｓｅｅｄｅｒ＝１
末尾のＳｅｅｄｅｒ＝１は、自己が完全なファイルを持っていることを示している。

トラッカーはこれを受けてアクティブピアテーブルを図９のように更新する（図１１及び図１３のＳＴ１０）。

同様に続けていくと、いずれ受信を完了したピアが増えていき、Ｓｅｅｄｅｒフラグの合計値がある一定値ｎを超えるようになる（図１０）。ｎの値は、あらかじめトラッカーサーバに設定しておけばよい。

Ｓｅｅｄｅｒフラグの合計値が一定数以上あるということは、ネットワーク上に完全な原本ファイルを保有するシーダー（スーパーシーダーに限らず、一般のピースシーダーが受信完了したものも含まれる）が、スーパーシーダー以外にも存在することを示す。こうなるともうスーパーシーダーが無くても、任意のクライアントは完全な元本を他のシーダーから受信することができるので、スーパーシーダーは停止しても構わない。

従って、トラッカーはＳｅｅｄｅｒフラグの合計値がｎを超えると（図１３のＳＴ１１でＳｅｅｄｅｒフラグの合計値＞閾値ｎ）、起動済みのスーパーシーダーに対して次のようなプロセス停止要求を送る（図１１及び図１３のＳＴ１２）。
ＧＥＴｈｔｔｐ：／／２００．０．０．２／ｓｅｅｄｅｒ．ｃｇｉ？ＦＩＬＥ＝ファイルＡ＆ｅｖｅｎｔ＝ｓｅｅｄｉｎｇｓｔｏｐ

スーパーシーダーはこれを受信すると、ファイルＡのシーディングプロセスを停止する（図１１のＳＳ２０）。

また、スーパーシーダーは一定期間（例えば１２０秒）以上の間、どのクライアントからもファイルＡに関する送信要求がなければ、トラッカーからの指示がなくても自動的にファイルＡのシーディングプロセスを停止する。この際、トラッカーに対し、自己がシーディングを停止したことを次のように通知する（図１１のＳＳ２１）。
ＧＥＴｈｔｔｐ：／／ｔｒａｃｋｅｒｓｅｒｖｅｒ／ｔｒａｃｋ．ｃｇｉ？ｅｖｅｎｔ＝ｓｅｓｓｉｏｎｓｔｏｐ＆サービスＩＤ＝Ｃｏｒｐ１＆ＦＩＬＥ＝ファイルＡ＆Ｓｅｅｄｅｒ＝１

トラッカーは、シーダーあるいは任意のクライアントから「ｅｖｅｎｔ＝ｓｅｓｓｉｏｎｓｔｏｐ」を受けると、アクティブピアテーブルからそのピアを削除する。

本発明の実施の形態では、改良版アクティブピアテーブルにＳｅｅｄｅｒフラグを設け、その合計値が一定水準にあるかないかでスーパーシーダーの起動停止を行うことで、あるファイルＡの完全な原本を保有しているシーダーが、ネットワーク上に不足している場合にのみスーパーシーダーを動的に起動し、余剰になれば動的に停止することができるので、全体でみればスーパーシーダーの必要起動プロセス数を削減することができ、結果的にスーパーシーダーの負荷を削減することができる。

スーパーシーダーテーブルに複数のシーダーを登録しておき、それらをラウンドロビンすることで、別途の負荷分散装置を用いなくてもスーパーシーダーの負荷を複数のサーバーに分散することができる。

スーパーシーダーテーブルにサービスＩＤごとの識別子をもうけておき、サービスＩＤに対してそれぞれのスーパーシーダーのアドレスを登録しておくことで、サービスＩＤつまりコンテンツの供給者ごとにシーダーを動的に切り替えることができ、スーパーシーダーの物理的な所在地を世界中に分散させることができる。

本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

［図１］従来のファイルダウンロードの説明図である。
［図２］ＢｉｔＴｏｒｒｅｎｔプロトコルの説明図である。
［図３］ＢｉｔＴｏｒｒｅｎｔプロトコルによるＰ２Ｐネットワークの説明図である。
［図４］従来のＢｉｔＴｏｒｒｅｎｔプロトコルのアクティブピアテーブルの説明図である。
［図５］発明の実施の形態に係るアクティブピアテーブルの説明図である。
［図６］発明の実施の形態に係るスーパーシーダーテーブルの説明図である。
［図７］発明の実施の形態に係るプロトコルを説明するためのアクティブピアテーブルの一例である。
［図８］発明の実施の形態に係るプロトコルを説明するためのアクティブピアテーブルの一例である。
［図９］発明の実施の形態に係るプロトコルを説明するためのアクティブピアテーブルの一例である。
［図１０］発明の実施の形態に係るプロトコルを説明するためのアクティブピアテーブルの一例である。
［図１１］発明の実施の形態に係るファイルのダウンロード方法のフローチャートである。
［図１２］発明の実施の形態に係るトラッカーの処理方法のフローチャートである。
［図１３］発明の実施の形態に係るトラッカーの処理方法のフローチャートである。

Claims

少なくとも１つのクライアントと、予め記憶しているファイルを要求に応じて送信するスーパーシーダーと、少なくともクライアント及び／又はスーパーシーダーのアドレス、当該アドレスのコンピュータが記憶しているファイルを要求に応じて送信可能であるかどうかを示すシーダーフラグ及び記憶しているファイルを要求に応じて送信可能であるコンピュータの数を記憶するテーブルであってファイルごとに生成されるアクティブピアテーブルと、スーパーシーダーのアドレスを記憶するスーパーシーダーテーブルとを含むトラッカーと、を備えるコンピュータネットワークにおいてファイルをダウンロードする方法であって、
クライアントからトラッカーへイベント開始通知及びファイルのダウンロード希望通知を送る第１ステップと、
前記ダウンロード希望通知を受けて当該クライアントを前記ファイルに対応するアクティブピアテーブルに登録する第２ステップと、
前記アクティブピアテーブルで前記ファイルを送信可能なコンピュータの数が予め設定した所定の値ｍ以下であるとき、スーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索する第３ステップと、
トラッカーから前記第３ステップで検索されたスーパーシーダーへプロセス起動指示を送る第４ステップと、
前記プロセス起動指示を受けて当該スーパーシーダーでプロセスを起動する第５ステップと、
当該スーパーシーダーからトラッカーへシーディング開始通知を送る第６ステップと、
前記シーディング開始通知を受けて当該スーパーシーダーを前記アクティブピアテーブルに登録する第７ステップと、
前記アクティブピアテーブルに基づき当該スーパーシーダーから当該クライアントへ前記ファイルをダウンロードする第８ステップと、
クライアントからトラッカーへ受信完了通知を送る第９ステップと、
前記受信完了通知を受けて前記ファイルに対応するアクティブピアテーブルの当該クライアントのシーダーフラグをセットするとともに、前記ファイルを送信可能なコンピュータの数を更新する第１０ステップと、
前記ファイルを送信可能なコンピュータの数を予め定められた閾値ｎと比較する第１１ステップと、
前記ファイルを送信可能なコンピュータの数が閾値ｎを超えたときにプロセス停止要求を生成する第１２ステップと、
前記プロセス停止要求を前記アクティブピアテーブルに含まれるスーパーシーダーへ送る第１３ステップと、
前記プロセス停止要求を受けてスーパーシーダーでプロセスを停止する第１４ステップと、を備えるファイルのダウンロード方法。
当該スーパーシーダーからトラッカーへシーディング停止通知を送る第１５ステップと、
前記シーディング停止通知を受けて当該スーパーシーダーを前記アクティブピアテーブルから削除する第１６ステップと、を更に備える請求項１記載のファイルのダウンロード方法。
前記スーパーシーダーテーブルにスーパーシーダーが複数登録されているとき、前記第３ステップにおいて、複数のスーパーシーダーのアドレスをラウンドロビンスケジューリングに従い選択することを特徴とする請求項１記載のファイルのダウンロード方法。
前記スーパーシーダーテーブルは、スーパーシーダーのアドレスとともにスーパーシーダーが記憶しているファイルの識別情報を記憶しており、
前記第３ステップにおいて、前記識別情報に基づき前記ファイルに対応するスーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索することを特徴とする請求項１記載のファイルのダウンロード方法。
少なくともクライアント及び／又はスーパーシーダーのアドレス、当該アドレスのコンピュータが記憶しているファイルを要求に応じて送信可能であるかどうかを示すシーダーフラグ及び記憶しているファイルを要求に応じて送信可能であるコンピュータの数を記憶するテーブルであってファイルごとに生成されるアクティブピアテーブルと、予め記憶しているファイルを要求に応じて送信するスーパーシーダーのアドレスを記憶するスーパーシーダーテーブルとを用意し、
クライアントからファイルのダウンロード希望通知を受けて当該クライアントを前記ファイルに対応するアクティブピアテーブルに登録するステップと、
前記アクティブピアテーブルから前記ファイルを送信可能なコンピュータの数を取得するステップと、
前記コンピュータの数が予め設定した所定の値ｍ以下であるとき、スーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索するステップと、
検索されたスーパーシーダーへプロセス起動指示を送るステップと、
当該スーパーシーダーからシーディング開始通知を受けて当該スーパーシーダーを前記アクティブピアテーブルに登録するステップと、
前記クライアントから受信完了通知を受けて前記ファイルに対応するアクティブピアテーブルの当該クライアントのシーダーフラグをセットするとともに、前記ファイルを送信可能なコンピュータの数を更新するステップと、
前記コンピュータの数を予め定められた閾値ｎと比較するステップと、
前記コンピュータの数が閾値ｎを超えたときにプロセス停止要求を生成するステップと、
前記プロセス停止要求を前記アクティブピアテーブルに含まれるスーパーシーダーへ送るステップと、を備えるトラッカーサーバの処理方法。
前記スーパーシーダーテーブルにスーパーシーダーが複数登録されているとき、スーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索するステップにおいて、複数のスーパーシーダーのアドレスをラウンドロビンスケジューリングに従い選択することを特徴とする請求項５記載のトラッカーサーバの処理方法。
前記スーパーシーダーテーブルは、スーパーシーダーのアドレスとともにスーパーシーダーが記憶しているファイルの識別情報を記憶しており、
スーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索するステップにおいて、前記識別情報に基づき前記ファイルに対応するスーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索することを特徴とする請求項５記載のトラッカーサーバの処理方法。
ＢｉｔＴｏｒｒｅｎｔプロトコルのトラッカーサーバを構成するためのプログラムであって、コンピュータに、
少なくともクライアント及び／又はスーパーシーダーのアドレス、当該アドレスのコンピュータが記憶しているファイルを要求に応じて送信可能であるかどうかを示すシーダーフラグ及び記憶しているファイルを要求に応じて送信可能であるコンピュータの数を記憶するテーブルであってファイルごとに生成されるアクティブピアテーブルと、予め記憶しているファイルを要求に応じて送信するスーパーシーダーのアドレスを記憶するスーパーシーダーテーブルとを用意し、
クライアントからファイルのダウンロード希望通知を受けて当該クライアントを前記ファイルに対応するアクティブピアテーブルに登録するステップと、
前記アクティブピアテーブルから前記ファイルを送信可能なコンピュータの数を取得するステップと、
前記コンピュータの数が予め設定した所定の値ｍ以下であるとき、スーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索するステップと、
検索されたスーパーシーダーへプロセス起動指示を送るステップと、
当該スーパーシーダーからシーディング開始通知を受けて当該スーパーシーダーを前記アクティブピアテーブルに登録するステップと、
前記クライアントから受信完了通知を受けて前記ファイルに対応するアクティブピアテーブルの当該クライアントのシーダーフラグをセットするとともに、前記ファイルを送信可能なコンピュータの数を更新するステップと、
前記コンピュータの数を予め定められた閾値ｎと比較するステップと、
前記コンピュータの数が閾値ｎを超えたときにプロセス停止要求を生成するステップと、
前記プロセス停止要求を前記アクティブピアテーブルに含まれるスーパーシーダーへ送るステップと、を実行させるためのプログラム。
少なくともクライアント及び／又はスーパーシーダーのアドレス、当該アドレスのコンピュータが記憶しているファイルを要求に応じて送信可能であるかどうかを示すシーダーフラグ及び記憶しているファイルを要求に応じて送信可能であるコンピュータの数を記憶するテーブルであってファイルごとに生成されるアクティブピアテーブルと、予め記憶しているファイルを要求に応じて送信するスーパーシーダーのアドレスを記憶するスーパーシーダーテーブルと、処理部とを備え、
前記処理部は、
クライアントからファイルのダウンロード希望通知を受けて当該クライアントを前記ファイルに対応するアクティブピアテーブルに登録し、
前記アクティブピアテーブルから前記ファイルを送信可能なコンピュータの数を取得し、
前記コンピュータの数が予め設定した所定の値ｍ以下であるとき、スーパーシーダーのアドレスを前記スーパーシーダーテーブルから検索し、
検索されたスーパーシーダーへプロセス起動指示を送り、
当該スーパーシーダーからシーディング開始通知を受けて当該スーパーシーダーを前記アクティブピアテーブルに登録し、
前記クライアントから受信完了通知を受けて前記ファイルに対応するアクティブピアテーブルの当該クライアントのシーダーフラグをセットするとともに、前記ファイルを送信可能なコンピュータの数を更新し、
前記コンピュータの数を予め定められた閾値ｎと比較し、
前記コンピュータの数が閾値ｎを超えたときにプロセス停止要求を生成し、
前記プロセス停止要求を前記アクティブピアテーブルに含まれるスーパーシーダーへ送ることを特徴とするＢｉｔＴｏｒｒｅｎｔプロトコルのトラッカーサーバ。