(57)【要約】【課題】ダウンロードリストを用いて、複数台のサーバに対して複数のセッションを張る事、および、サーバ台数が増える事で負荷分散をする事が出来ないという支障が生じる事を無くす事が可能な、高速なダウンロード方法を、複数台のサーバを利用する事で提供する。【解決手段】同一のコンテンツを配信する各サーバ１０３の状況を把握した管理サーバ１０１を設置するシステムにおいて、クライアント１０２からのダウンロード要求に対して、管理サーバ１０１が最適なダウンロード方法（ダウンロードリスト）を管理サーバ１０１のダウンロードリスト記述装置で記述して、それをクライアント１０２に送信し、クライアント１０２がダウンロードリストに従ってダウンロードを要求する。【選択図】　　　図１
2004126912.tif 000002
【特許請求の範囲】
【請求項１】
同一のコンテンツを配信する２つ以上のサーバと、該サーバの状況を把握した管理サーバを設置するシステムからのダウンロード方法において、クライアント端末から、該管理サーバに対してダウンロード要求があると、該管理サーバが最適なダウンロードリストを上記クライアント端末に送信し、該クライアント端末が上記ダウンロードリストに従って、２つ以上の配信サーバに対し、ダウンロードを要求することを特徴とするダウンロード方法。
【請求項２】
同一のコンテンツを配信する複数のサーバを管理する管理サーバ内のダウンロードリスト記述装置であって、クライアント端末とのデータの送受信に使用されるデータ送受信部と、配信に用いるサーバ状態を把握するサーバ状態把握部と、ダウンロードリストの記述ポリシーに基づいてダウンロードリストを構成するダウンロードリスト構成部とを有することを特徴とするダウンロード記述装置。
【請求項３】
ダウンロードを記述するダウンロード記述装置の記述方法であって、ダウンロードリストの記述ポリシーに従って、最初にダウンロードに用いるセッション数をきめておき、利用可能なサーバに均等にセッションを振り分けることを特徴とするリストの記述方法。
【請求項４】
ダウンロードを記述するダウンロード記述装置の記述方法であって、ダウンロードリストの記述ポリシーに従って、最初にダウンロードに用いるセッション数を決めておき、各セッションが均一なサイズのデータを取得し、利用可能な各サーバの合計セッション数を等しくすることを特徴とするリストの記述方法。
【請求項５】
ダウンロードを記述するダウンロード記述装置の記述方法であって、ダウンロードリストの記述ポリシーに従って、最初にダウンロードに用いるサーバ数を決めておき、それらのセッションについて、各サーバのセッション数、すなわち、クライアントからの同時アクセス数に応じて、各セッションのダウンロードサイズを決定することを特徴とするリストの記述方法。
【請求項６】
ダウンロードを記述するダウンロード記述装置の記述方法であって、ダウンロードリストの記述ポリシーに従って、サーバのキャッシュメモリ上に残っているデータを収拾するようにリストを記述し、足りない部分のデータを他の全ての利用可能なサーバに均等に振り分けることを特徴とするリストの記述方法。
【請求項７】
ダウンロードを記述するダウンロード記述装置の記述方法であって、ダウンロードリストの記述ポリシーに従って、サーバのキャッシュメモリ上に残っているデータを収拾するようにリストを記述し、キャッシュだけでは足りないデータを利用可能なサーバから収集し、この際に、利用可能な全サーバの各アクセス数、すなわち同時接続クライアント数が等しくなるようにアクセスリストを記述することを特徴とするリストの記述方法。
【請求項８】
管理サーバのコンピュータに、最初にダウンロードに用いるセッション数を決める処理、各セッションが均一なサイズのデータを取得する処理、及び、利用可能なサーバに均等にセッションを振り分ける処理か、あるいは、利用可能な各サーバの合計セッション数を等しくする処理を実行させるためのプログラム。
【請求項９】
管理サーバのコンピュータに、最初にダウンロードに用いるサーバ数を決める処理、各サーバにセッションを一本づつ張り、そして各サーバのセッション数に応じて、各セッションのダウンロードサイズを決定する処理を実行させるためのプログラム。
【請求項１０】
管理サーバのコンピュータに、サーバのキャッシュメモリ上に残っているデータを収拾するようにリストを記述する処理、及び、足りない部分データを他の全ての利用可能なサーバに均等に振り分ける処理か、あるいは、キャッシュだけでは足りないデータを利用可能なサーバから収集し、この際に、利用可能な全サーバの各アクセス数を等しくする処理を実行させるためのプログラム。
【請求項１１】
管理サーバのコンピュータに、請求項８から１０までに記された各処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンテンツ配信を複数台のサーバを用いて行う場合の、高機能なダウンロード方法と、それに用いるリスト記述装置と方法およびそのプログラムに関する。
【０００２】
【従来の技術】
従来までの技術では、複数台のサーバを用いてコンテンツ配信を行う際には、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）ラウンドロビン、ロードバランサという二つの技術が用いられてきた。ＤＮＳラウンドロビンは、複数のサーバを同じ名前で運用し、名前解決の際にそれぞれのＩＰアドレスを交互に返す事で、複数のサーバに接続を振り分ける機能を持つことを特徴とする。一方、ロードバランサは閉域ネットワークにおいて、接続を振り分ける機能を持つことを特徴とする。
【０００３】
ＤＮＳラウンドロビンを用いた場合には、複数本のセッションを利用する事が出来ないという問題点が存在する。既存のＴＣＰでは、遅延時間が無視できない環境においては、一本のセッションではスループットが出ない。
【０００４】
ロードバランサーを用いた場合には、ロードバランサーでセッションをいったん集約するので、ロードバランサ自体がボトルネックとなりやすく、多くのサーバを使った負荷分散をすることが出来ない（つまり、スケーラビリティーがない）。
【０００５】
【発明が解決しようとする課題】
本発明の目的は、従来の技術における上述のような問題を解消し、ダウンロードに必要な時間を複数台のサーバを利用する事の高速化によって減少させる分割ダウンロード方法と、それを用いるリスト記述装置、方法およびそのプログラムを提供することにある。
【０００６】
【課題を解決するための手段】
本発明に係る分割ダウンロード方式では、管理サーバがクライアントにダウンロードリストを送信し、クライアントがそのリストを利用してダウンロードを行うという点を特徴とする。
【０００７】
具体的には、同一のコンテンツを配信する各サーバの状況を把握した管理サーバを設置し、クライアントからのダウンロード要求に対して、管理サーバが最適なダウンロード方法（ダウンロードリスト）をクライアントに送信し、クライアントがダウンロードリストに従ってダウンロードを要求することを特徴とする。
【０００８】
本発明では、ダウンロードリストを用いて、複数台のサーバに対して複数のセッションを張る事が可能なので、スループットという点で判断すると、ＤＮＳロビンよりも有利である。加えて、本発明ではＤＮＳラウンドロビンでは不可能な、請求項５や６に示す高機能な処理も可能となる。
【０００９】
本発明を用いた場合には、管理サーバはダウンロードするリストをクライアントに返すという処理を行うだけなので、サーバ台数が増える事で支障が生じる事は無い。それゆえに、ロードバランサーを用いた場合よりも多くのサーバを利用可能である。それに加えて、ロードバランサーを用いた場合には、サーバを１ヵ所に集めて運用しなければならないが（閉域分散にのみ対応）、本発明はダウンロードリストで広域な分散を指定する事で、広域分散も可能である。本発明は、閉域、広域両方の環境に対応可能である。
【００１０】
【発明の実施の形態】
以下、本発明の実施の形態を、各図面に基づいて、詳細に説明する。
【００１１】
請求項１を具現化したものが図１である。本分割ダウンロード方法を手順を追って説明する。
【００１２】
（システム構成）
図１は本発明の実施例を示すサーバシステムの構成図である。１０１は管理サーバ、１０２はクライアント、１０３はサーバである。図の手順１では、クライアント１０２からのダウンロード要求を管理サーバ１０１に伝える。ここで伝えられる情報とは、従来のダウンロードに必要な情報である、サーバ名とそのサーバ上のコンテンツ名である。具体例を挙げると、ｓｅｒｖｅｒ１という名前のｃｏｎｔｅｎｔｓ１というコンテンツをダウンロードしようとした時には、ｈｔｔｐ：／／ｓｅｒｖｅｒ１／ｃｏｎｔｅｎｔｓ１というアドレスを記述する。現在一般的に使われているアドレス標記そのままの情報である。
【００１３】
手順２では、手順１で送信された情報を基に、管理サーバ１０１が最適なダウンロードリストを作成し、クライアント１０２に送信する。このダウンロードリストの作り方が、請求項の３から７までに記載した内容である。
【００１４】
ここで、ダウンロードリストについて説明する。ダウンロードリストとは、管理サーバの発行するコンテンツを保持するサーバ名、コンテンツ名、ダウンロードする部分の３つの情報から構成されているものであり、ＨＴＴＰプロトコルを理解するクライアントであれば、このリストに従ってコンテンツのダウンロードを行う事が可能である。
【００１５】
ダウンロードリストの具体例を示す。ここではｃｏｎｔｅｎｔｓ１を持つサーバが、ｓｅｒｖｅｒ１、ｓｅｒｖｅｒ２、ｓｅｒｖｅｒ３であり、管理サーバ１０１がコンテンツを均等に分割してダウンロードするポリシー（請求項３を参照）で運用されているとする。ここで、クライアントから、管理サーバに対してｃｏｎｔｅｎｔｓ１の配信要求が来たとき、管理サーバは、下記の内容のダウンロードリストをクライアント１０２に返す。
【００１６】
2004126912.tif 000003
【００１７】
手順３では、クライアント１０２が与えられたダウンロードリストを用いて実際のファイルのダウンロードを要求する。その後、クライアント１０２が、分割してダウンロードしたファイルを結合する事により、コンテンツのダウンロードが完了する。
【００１８】
次に、請求項２に対応した実施例を、図２に記す。
【００１９】
（ダウンロード記述装置）
図２は、ダウンロードリスト記述装置の具体例を示す図である。２００はダウンロード記述装置、２０１は、ダウンロードリスト記述装置の中のダウンロードリスト構成部、２０２は同じく、データ送受信部、２０３も同じく、サーバ状態把握部である。
【００２０】
２０１は、図１の管理サーバ１０１におけるダウンロードリスト記述装置であり、その装置２００には、データ送受信部２０２と、サーバ状態把握部２０３と、ダウンロードリスト構成部２０１を有する。
【００２１】
データ送受信部２０２は、クライアント１０２とのデータの送受信に使用される。
サーバ状態把握部２０２は、配信に用いるサーバ１０３の状態（配置しているコンテンツ、現在のセッション数、各サーバリソースの使用量、キャッシュメモリの状態）を把握する。
ダウンロードリスト構成部２０１では、ダウンロードリストの記述ポリシーに基づいてダウンロードリストを構成する。構成の際に必要な情報は、サーバ状態把握部２０３から取得する。
【００２２】
請求項３に対応した実施例を、図３に記す。
【００２３】
（ダウンロードリスト例）
図２のダウンロードリスト構成部２０１で用いるダウンロードリストの記述ポリシー、およびダウンロードリストの記述方法に関して、以下に記す。まず、ダウンロードリストは管理サーバが一括管理し、これを発行する。その発行の際の動作は次の通りである。
利用するセッション数を設定（誰が行っても良い）→
コンテンツを利用セッション数で分割する（データの先頭から均等に）→
分割した各データを利用可能なサーバにラウンドロビンで割り当てる。
【００２４】
つまり、まず最初に、ダウンロードに用いるセッション数を決めておき、各セッションが均一なサイズのデータを取得し、利用可能なサーバに均等にセッションを振り分けるように、管理サーバがダウンロードリストを記述する。こうする事で、より多くのサーバを利用する事になり、サーバの負荷を分散する事が可能となる。
【００２５】
図３では、セッション数５本、サーバ台数５台の時のダウンロードリスト例を示す。
【００２６】
図３の説明をする。まず、ダウンロードの対象となるコンテンツを５つのセッションに分割し（０−ａ、ａ−ａ２、ａ２−ａ３、ａ３−ａ４、ａ４−ａ５の５つのセッション）、それぞれを別々のサーバに請け負わせる事で負荷分散し処理させるリストである。そしてクライアント１０２は、このリストを元にダウンロードを要求する。
【００２７】
請求項４に対応する実施例を、図４に記す。
【００２８】
図４は、本発明のダウンロードリスト構成部で用いるダウンロードリストの記述ポリシーを示す図である。図４におけるダウンロードリストの記述方法に関して、以下に記す。上述同様に、この記述は、管理サーバが一括管理して、記述を実行する。
利用するセッション数を設定（誰が行っても良い）→コンテンツを利用セッション数で分割する（データの先頭から均等に）→分割した各データをそれぞれのサーバの合計セッション数が等しくなるように各サーバに振り分ける。ここで、等しくなるようにとは各サーバの同時セッション数の差が最も少なくなるようにという意味である。
【００２９】
つまり、まず最初に、ダウンロードに用いるセッション数を決めておき、各セッションが均一なサイズのデータを取得し、利用可能な各サーバの合計セッション数（同時接続クライアント数）が等しくなるように、管理サーバがダウンロードリストを記述する。ダウンロードリストをこのように記述する事で、サーバの負荷を均一に保つことが可能となり、サーバリソースを有効に活用する事が可能となる。
【００３０】
図４に、セッション数３本、サーバ５台（既に他の配信を行っている。）の場合の例を記す。
【００３１】
図４の説明をする。まず、ダウンロードの対象となるコンテンツを、３つのセッションに分割する（０−ａ、ａ−ａ２、ａ２−ａ３の３つのセッション）。そしてその３つのセッションを、現在の各サーバの使用状況によって、それらが均等の負荷配分となるように振り分ける。つまり、図４では、サーバー２、４はまだセッションを請け負うだけの余裕があるから上述のセッションを割り振り、その他のサーバは一杯であるから、今回はセッションの割り振りを見送ることにするということである。要するに、各サーバの配信状況を、セッション数の３に統一することに近づけるように（今回では全て３に統一された場合）、ダウンロードするコンテンツのセッションを割り振るということである。
【００３２】
請求項５に対応した実施例を、図５に記す。
【００３３】
図５は、本発明のダウンロードリスト構成部で用いるダウンロードリストの記述ポリシーを示す図である。まず、最初に、ダウンロードに用いるサーバ台数を決めて各サーバに一本づつセッションを張る。各セッションでダウンロードするデータ量を、各サーバのセッション数（同時アクセスするクライアント数）で決定する。各セッションのデータ量の決め方は、各サーバのセッション数の逆数が配信に用いる全サーバのセッション数の逆数の合計に占める割合から決定する。管理サーバによって一括管理する事で、ダウンロードリストをこのように記述する。これによって、セッション数の多いサーバのサービス時間を短くし、セッション数の少ないサーバのサービス時間が長くなる。よって、利用するサーバのセッション数を等しくする効果（すなわち負荷を等しくする効果）が期待される。
【００３４】
上記の一具体例を、図５に示す。
【００３５】
図５の説明をする。ダウンロードするコンテンツを、現在の各サーバの利用状況を示す配信中の数の逆数を使った比率で、サーバ数に分割する。つまり、各サーバの配信中の数が少ないと、その数の逆数も大きくなるので、その分だけコンテンツを分割した場合の割り振り割合も大きくするというものである。サーバの配信中の数が多いと、逆数も小さくなり、その分だけをコンテンツの分割割合にしようとするという具合になる。つまり、各サーバの配信状況が、サーバ１が１本、サーバ２が３本、サーバ３が４本とすると、その逆数の１／１、１／３、１／４の比率が、それぞれ、コンテンツが分割される場合の割合となる。つまり、サーバ１にはコンテンツの全体の１２／１９を、サーバ２にはコンテンツ全体の４／１９を、サーバ３にはコンテンツ全体の３／１９を割り振ることになる。こうすることで、配信が少ないサーバには多くのコンテンツの割合が振り分けられ、配信が多い場合には少ない割合となる。つまり、図５は、配信数の逆数を巧く利用することによって、余裕のあるサーバには多くのコンテンツの割合を、そうでないサーバには少ない割合のコンテンツを割り振るということを説明する図である。
【００３６】
請求項６に対応した実施例を、図６に記す。
【００３７】
図６は、本発明のダウンロードリスト構成部で用いるダウンロードリストの記述ポリシーを示す図である。６０１はｓｅｒｖｅｒ１上のコンテンツＸ、６０２はｓｅｒｖｅｒ２上のコンテンツＸ、６０３はｓｅｒｖｅｒ３上のコンテンツＸ、６０４は管理サーバ上のコンテンツＸである。このダウンロードリストの記述ポリシーでは、サーバのキャッシュメモリの内容を考慮する。
【００３８】
コンテンツ配信において、ディスクへのアクセスの頻発が発生した場合に、ディスクがシステムのボトルネックとなる可能性が高い。しかしながら、既存の複数サーバへの接続の振り分けの方法では、キャッシュを有効に活用する事が考慮されておらず、コンテンツ配信において、性能を十分に発揮できるとは言い難い。以上の背景によって、本発明では、キャッシュメモリを導入することにする。
【００３９】
まず最初に、サーバのキャッシュメモリ（ソフトウェアキャッシング）について、説明を加える。
【００４０】
サーバにおいてはディスクから一度読み出したデータをメモリ上のキャッシュ領域に保存しておく。これらのデータはディスクから新しいデータがキャッシュに読み込まれる事によって、キャッシュ領域から削除されるまでキャッシュ領域上に残り続ける。大容量のコンテンツを配信するサーバにおいては、ディスクからの読み出し部分がボトルネックとなりやすく、キャッシュ上のデータを有効に活用する事で、性能の向上が図れる。
【００４１】
図６は、本発明の具体的な配信手順を示す図である。管理サーバが各サーバにおいて、コンテンツのどの部分がキャッシングされているかを把握する。そのデータを元に、配信コンテンツデータのうちで、どこかのサーバ上のメモリにキャッシュされている部分があれば、そのサーバからキャッシュされている部分をダウンロードする。コンテンツ全体がキャッシュされていれば、キャッシュ部分を集めるだけでダウンロードは完了する。
【００４２】
そうでない場合、すなわちキャッシュされている部分だけでは不足する場合は、残りの部分を利用可能なサーバに均等に振り分ける。なお、コンテンツの一部分を複数のサーバが重複してキャッシュしている場合が存在するが、その時はより大きな塊でダウンロード可能なサーバを選択してダウンロードを行う。このように、管理サーバによってダウンロードリストを記述する事で、キャッシュを利用したより高速な配信が可能となる。
【００４３】
図６に、請求項６の具体例を示す。
【００４４】
図６の説明をする。ｓｅｒｖｅｒ１、２、３上のそれぞれのコンテンツＸの黒い部分がキャッシュされている部分であり、それにあたる管理サーバ上のダウンロードするコンテンツ部分はそのそれぞれに割り振る。つまり下の数字の３、１、２、３、１、２という具合に、ダウンロードするコンテンツを各サーバに割り振る。そして残った部分は、上の数字の１、２、３、１、２という具合に、各サーバで均等になるように分散させ、配信させる。
【００４５】
請求項７に対応する実施例を、図７に記す。
【００４６】
（ダウンロード手順のフローチャート）
図６についての上記の方法とほぼ同じであるが、キャッシュデータだけでは足りない場合のデータ配信方法が異なる。
【００４７】
図７の場合は、足りない部分を全サーバのセッション数（クライアントからの同時アクセス数）が等しくなるように、残りの部分の配信を割り当てる。（足りない部分を請求項３の方式を用いてダウンロードする。）
【００４８】
上記した、請求項６と７の場合のフロー図を、図７に示す。
【００４９】
図７の説明をする。ステップ７００で本フロー図をスタートさせる。ステップ７０１でキャッシュされているデータをダウンロードリストに追加させ、次のステップ７０２で、そのキャッシュデータのみでダウンロードすることが可能かどうか判定する。イエスの場合は、そこで本フロー図を終了させる。ノーの場合には、まず、請求項６にあたる場合には、ステップ７０３で、残りの部分（図６の白い箇所）を利用可能なサーバに対してラウンドロビンで振り分ける。そしてそうでない場合には、つまり、請求項７の場合には、ステップ７０４で残りの部分（図６の白い箇所）を利用可能なサーバに対して各サーバのセッション数の差が少なくなるように振り分ける。
【００５０】
≪実験例≫
発明した方法の有効性を検証する為に、本発明を用いた場合とそうでない場合の性能比較を行った。ここでは、性能尺度として、クライアントのダウンロード速度（スループット）を用いた。
【００５１】
実験条件を図８に、実験結果を図９に示す。また、実験条件の詳細を以下に記す。
【００５２】
図８の説明をする。８０１はダウンロードを要求するクライアントである。８０２は本システムをまとめる役目のＳｕｍｍｉｔ２４である。８０４は、ダウンロードの配信を行う配信サーバである。これは複数、存在する。８０３はその各配信サーバを統一管理する管理サーバである。
【００５３】
実験条件に関して、検証実験の条件は以下の通りである。
【００５４】
コンテンツ：１ＧＢのコンテンツを８個各サーバに配置（各サーバのコンテンツは同じ）
背景負荷：配信サーバに相互のコンテンツ配信を行わせた。（各サーバが２０本相互配信）
2004126912.tif 000004
上記条件で実験を行った。なお、請求項３および４を用いる場合には分割セッション数を事前に決めなくてはならないが、今回の検討では分割セッション数は１０本に設定した。各条件でコンテンツ配信を３００秒間行い（同じ実験の１０回繰り返す）、その平均値を示した。なお、スループットの測定はクライアント側で行った。
【００５５】
ネットワーク条件
クライアントとスイッチの間を１０００Ｂａｓｅ―ＳＸで接続、スイッチと各配信サーバの間を１００Ｂａｓｅ−Ｔのイーサネット（登録商標）で接続した。
【００５６】
ハードウェア条件
クライアント：
ＣＰＵ：Ｐｅｎｔｉｕｍ（登録商標）ＩＩＩ　１ＧＨｚ（＊２）、
メモリ：ＳＤＲＡＭ５１２ＭＢ、
ＨＤＤ：ＩＤＥ７２００回転　８０ＧＢ、
ＯＳ：Ｌｉｎｕｘ（ｋｅｒｎｅｌ　２．４．１８）
配信サーバ
ＣＰＵ：Ｐｅｎｔｉｕｍ（登録商標）ＩＩＩ　１ＧＨｚ、
メモリ：ＳＤＲＡＭ２５６ＭＢ、
ＨＤＤ：ＩＤＥ７２００回転　６０ＧＢ、
ＯＳ：Ｌｉｎｕｘ（ｋｅｒｎｅｌ　２．４．１８）、
サーバプログラム：Ａｐａｃｈｅ―１．３．２４
【００５７】
図９の結果より、今回実験を行った条件においては、本発明は有効に作用する事が分かる。
【００５８】
上述の実施形態において、その処理を行うプログラムをアプリケーションソフトとして、ＣＤ−ＲＯＭ等の記録媒体に格納しておいてもよい。このようにすれば、ＣＤ−ＲＯＭ等の可搬型記録媒体にプログラム等を格納して売買したり、携帯することができるようになる。
【００５９】
【発明の効果】
以上のように本発明によれば、最適なダウンロードリストを管理サーバにおけるダウンロードリスト記述装置によって記述し、それに従って複数台のサーバを利用する事で、より高速なダウンロードを可能とすることができた。
【００６０】
請求項３から７に述べたように、本発明で設けるダウンロードリストをいろいろ工夫する事で、様々な処理が可能となりうるという効果がある。
従来の技術のロードバランサでは管理サーバがボトルネックとなりやすいが、本発明では、管理サーバは、ダウンロードリストを返す処理を行うだけなので負荷を低くする効果がある。
ダウンロードリストを用いる事で広域な分散を指定する事で、サーバを一箇所に集めなくてもよく、広域分散も可能となるという効果がある。
また、サーバ側には特別な作り込みは一切必要なく、低コストであるという効果がある。
【図面の簡単な説明】
【図１】本発明のサーバシステムの構成図である。
【図２】本発明におけるダウンロードリスト記述装置の具体例図である。
【図３】請求項３に対応する、セッション数５本、サーバ台数５台の時のダウンロードリスト例図である。
【図４】請求項４に対応する、セッション数３本、サーバ５台（既に他の配信を行っている。）の場合のダウンロードリスト例図である。
【図５】請求項５に対応する、利用するサーバのセッション数を等しくする効果がある、ダウンロードリストの具体例図である。
【図６】請求項６に対応する、キャッシュを利用したより高速な配信が可能となる、ダウンロードリスト例図である。
【図７】請求項６と７をまとめたダウンロードリストの記述手順のフロー図である。
【図８】本発明の有効性を検証するための実験の実験条件図である。
【図９】本発明の有効性を検証する実験の結果図である。
【符号の説明】
１０１　管理サーバ
１０２　クライアント
１０３　サーバ
２００　ダウンロードリスト記述装置
２０１　ダウンロードリスト構成部
２０２　データ送受信部
２０３　サーバ状態把握部
６０１　Ｓｅｒｖｅｒ１上のコンテンツＸ
６０２　Ｓｅｒｖｅｒ２上のコンテンツＸ
６０３　Ｓｅｒｖｅｒ３上のコンテンツＸ
６０４　管理サーバ上のコンテンツＸ
８０１　クライアント
８０２　Ｓｕｍｍｉｔ２４
８０３　管理サーバ
８０４　配信サーバ
【図１】
2004126912.tif 000005
【図２】
2004126912.tif 000006
【図３】
2004126912.tif 000007
【図４】
2004126912.tif 000008
【図５】
2004126912.tif 000009
【図６】
2004126912.tif 000010
【図７】
2004126912.tif 000011
【図８】
2004126912.tif 000012
【図９】
2004126912.tif 000013