(57)【要約】      （修正有）【課題】クライアントが、サーバから送信されたデータを受信できない場合でも、受信できなかったデータを他のクライアントから受信可能なシステム、プログラムおよび方法を提供する。【解決手段】情報処理装置ＳＶＲは、複数のクライアント群各々に含まれる複数のクライアントＣＬ１〜ＣＬｎの中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、ブロックデータを代表端末を特定する情報と共に、複数のクライアントに送信する。代表端末でないクライアントは、複数のブロックデータを受信して記憶部に記憶し、複数のブロックデータのうち第Ｎのブロックデータを受信できない場合、第Ｎのブロックデータを、自己が含まれるクライアント群および自己が含まれないクライアント群の代表端末に要求する。代表端末は複数のブロックデータを受信して記憶し、要求を受信すると、記憶部から読み出した第Ｎのブロックデータを要求した端末に送信する。【選択図】図２
2016092680.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末と、前記複数の端末に配信データを送信するサーバとを有する配信システムであって、
前記サーバは、
配信データを複数のブロックデータに分割し、
複数の端末群各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、
分割されたブロックデータを、代表端末を特定する情報と共に、前記複数の端末群各々に含まれる複数の端末に送信し、
前記複数の端末群各々に含まれる複数の端末各々は、
前記複数のブロックデータを受信して記憶部に記憶し、
複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できず、かつ、該端末が前記第Ｎブロックデータの代表端末として機能しない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、
該端末が前記第Ｎブロックデータの代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求した端末に送信する、
ことを特徴とする配信システム。
【請求項２】
請求項１において、
前記複数の端末群各々に含まれる複数の端末各々は、
前記要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータの一部のデータを前記要求した端末に送信し、
前記複数の代表端末から前記一部のデータを受信した端末として機能する場合、最初に受信した前記一部のデータを送信した代表端末に、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を要求し、
前記一部のデータ以外のデータの送信の要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を継続する
ことを特徴とする配信システム。
【請求項３】
複数の端末群各々に含まれる複数の端末と、該複数の端末に配信データを送信するサーバとを有する配信システムにおける、該複数の端末各々に実行させる配信プログラムであって、
前記複数の端末群各々に含まれる複数の端末各々に、
配信データが前記サーバによって分割された、複数のブロックデータを受信して記憶部に記憶し、
複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できず、かつ、該端末が前記サーバによって端末群毎かつ分割されたブロックデータ毎に決定された代表端末として機能しない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、
該端末が前記第Ｎブロックデータの代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求をした端末に送信する、処理を実行させる、
ことを特徴とする配信プログラム。 
【請求項４】
請求項３において、
前記複数の端末群各々に含まれる複数の端末各々に、
前記要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータの一部のデータを前記要求した端末に送信する、処理を実行させ、
前記複数の代表端末から前記一部のデータを受信した端末として機能する場合、最初に受信した前記一部のデータを送信した代表端末に、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を要求する処理を実行させ、
前記一部のデータ以外のデータの送信の要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を継続する、処理を実行させる、
ことを特徴とする配信プログラム。
【請求項５】
サーバに、
配信データを複数のブロックデータに分割し、
複数の端末群の各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、
分割されたブロックデータのうち第１のブロックデータを、代表端末を特定する情報と共に、前記複数の端末群の各々に含まれる複数の端末に送信し、
前記第１のブロックデータについての応答確認を前記端末群毎かつ分割されたブロックデータ毎に決定された代表端末から受信すると、前記第１のブロックデータの次の第２の前記ブロックデータを前記複数の端末群の各々に含まれる複数の端末に送信し、
前記代表端末を決定する処理の前に、端末群に含まれる端末数の差が最小になるように、前記複数の端末を端末群にグループ化し、グループ化された各端末をリストに登録して記憶部に記憶する処理を実行させ、
前記代表端末を決定する処理は、前記リストに登録された端末の中から、ラウンドロビン方式により、端末群毎かつ分割されたブロックデータ毎に代表端末を決定する
処理であることを特徴とする配信プログラム。
【請求項６】
請求項５において、
前記代表端末を決定する処理において、一つの端末群に含まれる複数の端末を複数のサブグループに分け、各サブグループに含まれる端末の数の差がゼロでない場合、端末数が最大であるサブグループに含まれる端末を、同じ第Ｎのブロックデータの代表端末と決定する 
処理を前記サーバに実行させることを特徴とする配信プログラム。
【請求項７】
複数の端末と、前記複数の端末に配信データを送信するサーバとを有する配信システムで実行される配信方法あって、
前記サーバは、
配信データを複数のブロックデータに分割し、
複数の端末群各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、
分割されたブロックデータを、代表端末を特定する情報と共に、前記複数の端末群各々に含まれる複数の端末に送信し、
前記複数の端末群各々に含まれる複数の端末各々は、
前記複数のブロックデータを受信して記憶部に記憶し、
前記代表端末でない端末として機能する場合、複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、
前記代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求した端末に送信する、
ことを特徴とする配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信システム、配信プログラム、および、配信方法に関する。
【背景技術】
【０００２】
情報処理システムにおいて、ギガバイト、テラバイト単位の大容量データを情報処理装置(以下、サーバと適宜記す)から複数のクライアント端末(以下、クライアントと適宜記す)に送信する処理が実行される。この送信処理において、サーバは、例えば、送信対象となる大容量データをブロック単位に分割する。以下、ブロック単位に分割されたデータをブロックデータと適宜記す。サーバは、複数のブロックデータを複数のクライアントに順次送信する。
【０００３】
かかる情報処理システムにおいて、例えば、サーバの負荷や、サーバとクライアント間のネットワークの負荷を軽減するため、サーバからクライアントに大容量データを効率的に送信することが好ましい。
【０００４】
サーバからクライアントに大容量データを効率的に送信する手法の一例として、サーバが、複数のブロックデータを複数のクライアントにマルチキャスト送信する手法が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−８５９３２号公報
【特許文献２】特開２０１３−１９７７７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
かかる情報処理システムにおいては、ブロックデータの受信に失敗したクライアントは、このブロックデータの再送をサーバに要求する。そのため、サーバは、再送用のブロックデータを記憶する記憶領域(キャッシュ領域とも呼ぶ)をメモリに確保する。サーバが、再送要求に応答するために、多数のブロックデータを記憶するキャッシュ領域をメモリに確保すると、メモリの記憶領域が圧迫される。
【０００７】
そこで、前記した手法において、複数のクライアントの各々は、異なるブロックデータを１つずつ一時的に記憶する。例えば、複数のクライアントが、第１〜第３のクライアントと想定する。そして、サーバは、第１、第２、第３のブロックデータを順次マルチキャスト送信する。
【０００８】
第１のクライアントは、第１のブロックデータを受信し一時的に記憶する。第２のクライアントは、第２のブロックデータを受信し一時的に記憶する。第３のクライアントは、第３のブロックデータを受信し一時的に記憶する。
【０００９】
そして、各クライアントは、一時的に記憶したブロックデータを全クライアントが受信した後、このブロックデータを削除する。以後、第４のブロックデータ以降についても、第１〜第３のクライアントの各々が、異なるブロックデータを一時的に記憶する。
【００１０】
クライアントは、ブロックデータの受信に失敗した場合、このブロックデータの送信を他のクライアントに要求する。この送信要求の対象となるブロックデータを一時的に記憶したクライアントは、このブロックデータを送信する。この送信要求を行ったクライアントは、送信されたブロックデータを受信する。
【００１１】
ここで、ブロックデータを一時的に記憶したクライアントが、サーバとの通信ができなくなった場合を想定する。以下、サーバとの通信ができなくなったかかるクライアントを停止クライアントと適宜記す。この想定においては、停止クライアントは、送信要求を受信できないので、この送信要求に応答して、一時的に記憶したブロックデータを送信できなくなる。
【００１２】
その結果、停止クライアントが一時的に記憶しているブロックデータの受信に失敗した別のクライアントは、このブロックデータの送信要求を停止クライアントに行っても、このブロックデータを受信できない。このように、前記した手法では、クライアントは、サーバから送信されたデータを確実に受信することが困難な場合が生じることがある。
【００１３】
本実施の形態の一つの側面は、クライアントが、サーバから送信されたデータを受信できない場合、受信できなかったデータを他のクライアントから受信することを目的とする。
【課題を解決するための手段】
【００１４】
本実施の形態の第１の側面は、複数の端末と、前記複数の端末に配信データを送信するサーバとを有する配信システムであって、前記サーバは、配信データを複数のブロックデータに分割し、複数の端末群各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、分割されたブロックデータを、代表端末を特定する情報と共に、前記複数の端末群各々に含まれる複数の端末に送信し、前記複数の端末群各々に含まれる複数の端末各々は、前記複数のブロックデータを受信して記憶部に記憶し、複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できず、かつ、該端末が前記第Ｎブロックデータの代表端末として機能しない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、該端末が前記第Ｎブロックデータの代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求した端末に送信する、ことを特徴とする配信システムである。
【発明の効果】
【００１５】
第１の側面によれば、クライアントが、サーバから送信されたデータを受信できない場合でも、受信できなかったデータを他のクライアントから確実に受信できる。
【図面の簡単な説明】
【００１６】
【図１】図１は、大容量データをサーバからクライアントに送信する処理を説明する関連図である。
【図２】図２は、本実施の形態における配信システムＳＹＳを説明する図である。
【図３】図３は、図２のサーバＳＶＲのハードウェアブロック図である。
【図４】図４は、図２のサーバＳＶＲのソフトウェアブロック図である。
【図５】図５は、図２のクライアントのハードウェアブロック図である。
【図６】図６は、図２のクライアントのソフトウェアブロック図である。
【図７】図７は、図２のサーバＳＶＲの処理の概略を説明するフロー図である。
【図８】図８は、属性情報リストＬＳＴ１を示す図である。
【図９】図９は、第１のグループのクライアントリストの図である。
【図１０】図１０は、第２のグループのクライアントリストの図である。
【図１１】図１１は、図７の送信データのマルチキャスト送信(Ｓ３)を説明するフロー図である。
【図１２】図１２は、ブロックデータの分割処理および送信処理(図１１のＳ３１、Ｓ３２)を説明する図である。
【図１３】図１３は、ブロックデータの送信順序、代表クライアントの決定について説明する図である。
【図１４】図１４は、クライアントＣＬのブロックデータ受信処理のフロー図である。
【図１５】図１５は、クライアントＣＬのブロックデータ送信処理のフロー図である。
【図１６】図１６は、図７のクライアントリストの調整(Ｓ７)を説明するフロー図である。
【図１７】図１７は、図９の受信不可の第２のクライアントＣＬ２の行に、代替クライアント(第４のクライアントＣＬ４)の行を移動したリストを示した図である。
【図１８】図１８は、図１０の受信不可の第６のクライアントＣＬ６の行に、代替クライアント(第４のクライアントＣＬ４)の行を移動したリストを示した図である。
【図１９】図１９は、図９の代替クライアント(第４のクライアントＣＬ４)の行を図９のクライアントリストＬＳＴ１ａから消去したリストを示した図である。
【図２０】図２０は、属性情報リストＬＳＴ２を示す図である。
【図２１】図２１は、第１のクライアントＣＬ１〜第４のクライアントＣＬ４のグループＧ１１のクライアントリストＬＳＴ２１ａの図である。
【図２２】図２２は、第５のクライアントＣＬ５〜第８のクライアントＣＬ８を含むグループＧ１２のクライアントリストＬＳＴ２１ｂの図である。
【図２３】図２３は、図２１のクライアントリストから受信不可の第２のクライアントＣＬ２が消去されたクライアントリストＬＳＴ２１ｃの図である。
【図２４】図２４は、図２２のクライアントリストの重複フラグ欄を更新したクライアントリストＬＳＴ２１ｄの図である。
【図２５】図２５は、図１３における各グループ間の同期をとる理由を説明する図である。
【発明を実施するための形態】
【００１７】
[大容量データの送信]
図１は、大容量データをサーバからクライアントに送信する処理を説明する関連図である。この大容量データは、例えば、サーバのハードディスクドライブのイメージファイルや、ソフトウェアのデータである。なお、以下の図の説明において、同じ要素については同一の符号を付して、一度した説明を省略する。
【００１８】
図１は、サーバ１０００と、第１のクライアント１００１〜第１００ｊ(ｊは３以上の整数)のクライアント１００ｊとを有する情報処理システム(以下、配信システムと適宜記す)を示す。
【００１９】
サーバ１０００、第１のクライアント１００１〜第１００ｊのクライアント１００ｊは、ネットワークＮＴ１に接続し、相互に通信できる。なお、ネットワークＮＴ１は、例えばＬＡＮ(Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ)である。図１を参照して、前記した手法(以下、前記手法と記す)を説明する。図１で説明する前記手法については、上記特許文献１に詳細に記載されている。
【００２０】
(マルチキャスト送信)
サーバ１０００は、自装置に記憶している大容量データを第１のクライアント１００１〜第１００ｊのクライアント１００ｊにマルチキャスト送信する。この送信の前に、サーバ１０００は、大容量データをブロック単位に分割し、第１〜第ｋ(ｋは２以上の整数)のブロックデータを作成する。ブロックデータのサイズは、例えば６４キロバイトである。
【００２１】
サーバ１０００は、第１のブロックデータを第１のクライアント１００１〜第１００ｊのクライアント１００ｊにマルチキャスト送信する。次に、サーバ１０００は、第２のブロックデータを第１のクライアント１００１〜第１００ｊのクライアント１００ｊにマルチキャスト送信する。同様に、サーバ１０００は、順次、第ｋのブロックデータまでを第１のクライアント１００１〜第１００ｊのクライアント１００ｊにマルチキャスト送信する。なお、ブロックデータを分割して送信するのは、クライアントのハードウェア資源(例えば、受信用メモリの容量)に制限があるため、大容量データを一括して受信できないからである。
【００２２】
(代表クライアントの決定)
前記手法により、第１のクライアント１００１〜第１００ｊのクライアント１００ｊの中から、第ｍ(ｍは１以上の整数)のブロックデータの代表クライアントがラウンドロビン方式により順次決定される。この代表クライアントは、第ｍのブロックデータを正常に受信したことを示す応答確認をサーバ１０００に行い、第ｍのブロックデータを自端末に一時的に記憶する。以下、データを一時的に記憶することをキャッシュと適宜記す。
【００２３】
代表クライアントの決定について具体的に説明する。以下、説明を簡単にするために、図１では、配信システムは、サーバ１０００と、第１のクライアント１００１〜第３のクライアント１００３とを有すると想定する。
【００２４】
前記手法においては、第１のクライアント１００１〜第３のクライアント１００３の中から、代表クライアントがラウンドロビン方式により順次決定される。
【００２５】
サーバ１０００は、第(３(ｍ-１)+１)のブロックデータの代表クライアントを第１のクライアントと決定する。なお、"３(ｍ-１)"は、"ｍ"から１を減算した値に"３"を乗算した値を示す。
【００２６】
サーバ１０００は、第(３(ｍ-１)+２)のブロックデータの代表クライアントを第２のクライアントと決定する。サーバ１０００は、第(３(ｍ-１)+３)のブロックデータの代表クライアントを第３のクライアントと決定する。
【００２７】
(サーバにおけるキャッシュ)
サーバ１０００は、かかる決定の後、または、かかる決定をしながら、順次、第ｋのブロックデータまでを第１のクライアント１００１〜第１００ｊのクライアント１００ｊにマルチキャスト送信する。サーバ１０００は、第ｍ(ｍは１以上の整数)のブロックデータの送信後、第ｍの代表クライアントから応答確認を受信すると、第(ｍ+１)のブロックデータの送信を行う。なお、"(ｍ+１)"は、"ｍ"に１を加算した値を示す。
【００２８】
サーバ１０００は、第ｍのブロックデータを送信する場合、第ｍのブロックデータの送信が完了するまで、第ｍのブロックデータの再送要求に応答するため、送信中の第ｍのブロックデータをメモリにキャッシュする。そして、サーバ１０００は、第ｍのブロックデータの応答確認を代表クライアントから受信すると、キャッシュした第ｍのブロックデータを削除する。
【００２９】
(代表クライアントの送信処理)
例えば、サーバ１０００が第１のブロックデータの送信を完了した後に、第３のクライアント１００３が、第１のブロックデータの受信に失敗したと想定する。第１のブロックデータの代表クライアントである第１のクライアント１００１は、第１のブロックデータの受信が成功し、サーバ１０００に応答確認を送信している。サーバ１０００は、この応答確認により、キャッシュした第１のブロックデータを削除している。
【００３０】
第３のクライアント１００３は、第１のブロックデータの受信に失敗しているので、第１のブロックデータの送信要求をマルチキャスト送信する。第１のクライアント１００１は、この送信要求を受信すると、キャッシュしている第１のブロックデータを第３のクライアント１００３に送信する。第３のクライアント１００３は、第１のクライアント１００１から送信されたブロックデータを受信する。
【００３１】
前記手法によれば、代表クライアントに応答確認を実行させることにより、サーバ１０００は、ブロックデータを送信した全てのクライアントからの応答確認を受信することがない。そのため、サーバ１０００において、応答確認の受信による処理負荷が削減される。
【００３２】
また、前記手法によれば、代表クライアントがブロックデータのキャッシュを実行しているので、サーバ１０００は、全てのブロックデータをメモリにキャッシュしなくてもよい。その結果、サーバ１０００は、メモリ領域を有効利用できる。
【００３３】
(クライアントの通信停止)
前記手法において、送信用のブロックデータをキャッシュしたクライアントが、配信システムとの通信を停止、または、通信ができなくなった場合を想定する。
【００３４】
クライアントが配信システムとの通信を停止する例としては、このクライアントが、サーバからデータを受信する処理をキャンセルした場合がある。また、クライアントが配信システムとの通信ができなくなる例としては、このクライアントとネットワークＮＴ１とを接続しているＬＡＮケーブルが断線した場合がある。
【００３５】
この想定においては、通信を停止または通信ができなくなったクライアントは、送信要求に応答して、キャッシュしたブロックデータを送信できない。そのため、通信を停止または通信ができなくなったクライアントがキャッシュしているブロックデータの受信に失敗したクライアントは、このブロックデータの送信要求を行っても、このブロックデータを受信できない。その結果、この送信要求を行ったクライアントは、サーバ１０００が送信する大容量データの全データを受信できなくなる。
【００３６】
このように、前記手法では、クライアントは、サーバから送信されたデータを確実に受信することが困難な場合が生じることがある。そこで、本実施の形態では、クライアントがサーバから送信されたデータを確実に受信する手法について説明する。かかる手法は、代表端クライアントが持つブロックデータのキャッシュ各々を分散させる。
【００３７】
[本実施の形態のシステム図]
図２は、本実施の形態における配信システムＳＹＳを説明する図である。図２は、サーバ(情報処理装置)ＳＶＲと、第１のクライアントＣＬ１〜第ｎ(ｎは６以上の整数)のクライアントＣＬｎとを有する配信システムＳＹＳを示す。クライアントは、端末とも呼ばれる。以下、サーバ(情報処理装置)ＳＶＲをサーバＳＶＲと適宜記す。
【００３８】
サーバＳＶＲ、第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎは、ネットワークＮＴ２に接続し、相互に通信する。この通信は、例えばＴＣＰ/ＩＰ(Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ/Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)規格に基づく通信である。なお、ネットワークＮＴ２は、例えばＬＡＮである。
【００３９】
図２の配信システムＳＹＳにおいては、サーバＳＶＲは、複数のクライアントが同じブロックデータをキャッシュできるようにクライアントを制御する。従って、ブロックデータをキャッシュしている１台のクライアントが、何らかの理由により、通信ができなくなっても、このブロックデータをキャッシュしているクライアントが、他のクライアントからのブロックデータの送信依頼に応答できる。
【００４０】
[サーバＳＶＲ]
図３、図４を参照し、サーバＳＶＲについて説明する。図３は、図２のサーバＳＶＲのハードウェアブロック図である。
【００４１】
サーバＳＶＲは、バスＢに接続された、ＣＰＵ(処理部)１０１と、ストレージ装置１０２と、ＲＡＭ(記憶部)１０３と、ＲＯＭ １０４と、通信装置１０５と、外部接続インターフェイス装置１０６とを有する。なお、ＣＰＵは"Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ"の略語、ＲＡＭは"Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ"の略語、ＲＯＭは、"Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ"の略語である。以下、ＣＰＵ(処理部)１０１をＣＰＵ１０１、ＲＡＭ(記憶部)１０３をＲＡＭ１０３と適宜記す。
【００４２】
ＣＰＵ１０１は、サーバＳＶＲを制御する中央演算処理装置である。ストレージ１０２は、大容量のデータを記憶可能な記憶装置であり、例えばハードディスクドライブ(ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ)や、ソリッドステートドライブ(ＳＳＤ:Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ)などの大容量記憶装置である。ストレージ１０２は、第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎに送信する送信データを記憶する送信データ記憶領域ＴＲ１を有する。ストレージ１０２は、他にも、例えば、配信ソフトＳＦ１の実行ファイルを記憶する。なお、配信ソフトは、配信プログラムとも呼ばれる。
【００４３】
ＲＡＭ１０３は、ＣＰＵ１０１が実行する処理や、配信ソフトＳＦ１が実行する各ステップにおいて生成(算出)されたデータなどを一時的に記憶する。ＲＡＭ１０３は、例えばＤＲＡＭ(Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ)などの半導体メモリである。配信ソフトＳＦ１は、データの配信(以下、送信と適宜記す)に関連する各種処理を実行する。
【００４４】
ＣＰＵ１０１は、サーバＳＶＲの起動時に、ストレージ１０２から配信ソフトＳＦ１の実行ファイルを読み出し、ＲＡＭ１０３に展開する。なお、この実行ファイルを外部記憶媒体ＭＤ１に記憶してもよい。図３では、ＣＰＵ１０１が配信ソフトＳＦ１をＲＡＭ１０３に展開している状態を模式的に示す。
【００４５】
ＲＡＭ１０３は、リスト記憶領域ＬＲと、ブロックデータ記憶領域ＢＲとを有する。リスト記憶領域ＬＲは、図８〜図１０で説明するリストを記憶する領域である。ブロックデータ記憶領域ＢＲは、図１２で説明するブロックデータを記憶する領域である。ＲＯＭ１０４は、各種設定情報を記憶する。通信装置１０５は、例えばＮＩＣ(Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ)を有し、ＬＡＮケーブルを介してネットワークＮＴ２に接続し通信する。
【００４６】
外部接続インターフェイス装置１０６は、外部の各種装置と接続するためのインターフェイスとして機能する装置である。外部接続インターフェイス装置１０６は、例えば、カードスロットや、ＵＳＢ(Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ)のポートを有する。外部接続インターフェイス装置１０６は、入力装置ＩＮＰ１、表示装置ＤＳＰ１、外部記憶媒体ＭＤ１と接続する。
【００４７】
入力装置ＩＮＰ１は、サーバＳＶＲに操作情報を入力する装置である。入力装置ＩＮＰ１は、例えば、キーボードや、マウスである。表示装置ＤＳＰ１は、サーバＳＶＲ１が出力する画像、文字などの各種情報を表示する装置である。表示装置ＤＳＰ１は、例えば、液晶ディスプレイである。
【００４８】
外部記憶媒体ＭＤ１は、ＵＳＢメモリなどの可搬型の不揮発性メモリである。なお、外部接続インターフェイス装置１０６を介して、記憶媒体に記憶されたデータを読み取る記憶媒体読み取り装置(図示しない)と接続する構成としても良い。この記憶媒体(記録媒体とも呼ばれる)は、例えば、ＣＤ-ＲＯＭ(Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ)、ＤＶＤ(Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ)などの可搬型記憶媒体である。
【００４９】
図４は、図２のサーバＳＶＲのソフトウェアブロック図である。配信ソフトＳＦ１は、主管理部１１、ネゴシエーション部１２、送信データ管理部１３、送受信部１４、リスト管理部１５を有する。
【００５０】
主管理部１１は、各種処理を実行すると共に、ネゴシエーション部１２、送信データ管理部１３、送受信部１４、リスト管理部１５を管理する。主管理部１１は、キャンセル要求を送信したクライアントを受信不可のクライアントとして検出する検出部としても機能する。
【００５１】
ネゴシエーション部１２は、第１のクライアントＣＬ１〜第ｎ(ｎは６以上の整数)のクライアントＣＬｎとのネゴシエーションを実行し、データを送信するクライアントを受け付ける。
【００５２】
送信データ管理部１３は、第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎに送信する送信データの管理処理を実行する。送信データ管理部１３は、例えば、送信データを分割する分割部として機能する。送受信部１４は、データの送受信を実行する。リスト管理部１５は、送信データを送信するクライアントに関する各種情報を含むリストを管理し、代表クライアント(代表端末)を決定する。リスト管理部１５は、例えば、クライアントの中から代表クライアントを決定する決定部として機能する。
【００５３】
[クライアント]
図５、図６を参照し、クライアントＣＬについて説明する。図５、図６に示すクライアントＣＬは、図２で説明した第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎである。図５は、図２のクライアントのハードウェアブロック図である。
【００５４】
クライアントＣＬは、バスＢに接続された、ＣＰＵ(処理部)２０１と、ストレージ装置２０２と、ＲＡＭ(記憶部)２０３と、ＲＯＭ２０４と、通信装置２０５と、外部接続インターフェイス装置２０６とを有する。以下、ＣＰＵ(処理部)２０１をＣＰＵ２０１、ＲＡＭ (記憶部)２０３をＲＡＭ２０３と適宜記す。
【００５５】
ＣＰＵ２０１は、クライアントＣＬを制御する中央演算処理装置である。ストレージ２０２は、大容量のデータを記憶可能な記憶装置であり、例えばハードディスクドライブや、ソリッドステートドライブなどの大容量記憶装置である。ストレージ２０２は、サーバＳＶＲから送信された送信データを記憶する送信データ記憶領域ＴＲ２を有する。ストレージ２０２は、例えば、処理ソフトＳＦ２の実行ファイルや、クライアントＣＬを一意に識別する識別子(クライアント識別子とも呼ぶ)を記憶する。この識別子は、本実施の形態では、クライアントＣＬの符号"ＣＬ"である。なお、処理ソフトＳＦ２は、配信プログラムとも呼ばれる。
【００５６】
ＲＡＭ２０３は、ＣＰＵ２０１が実行する処理や、処理ソフトＳＦ２が実行する各ステップにおいて生成されたデータなどを一時的に記憶する。ＲＡＭ２０３は、例えばＤＲＡＭなどの半導体メモリである。
【００５７】
ＣＰＵ２０１は、クライアントＣＬの起動時に、ストレージ２０２から処理ソフトＳＦ２の実行ファイルを読み出し、ＲＡＭ２０３に展開する。なお、この実行ファイルを外部記憶媒体ＭＤ２に記憶してもよい。図５では、ＣＰＵ２０１が処理ソフトＳＦ２をＲＡＭ２０３に展開している状態を模式的に示す。
【００５８】
ＲＡＭ２０３は、データキャッシュ領域ＤＣＲを有する。データキャッシュ領域ＤＣＲは、送信用(再送用とも呼ぶ)のブロックデータをキャッシュする領域である。ＲＯＭ２０４は、各種設定情報を記憶する。通信装置２０５は、例えばＮＩＣを有し、ネットワークＮＴ２と通信する。
【００５９】
外部接続インターフェイス装置２０６は、外部の各種装置と接続するためのインターフェイスとして機能する装置である。外部接続インターフェイス装置２０６は、例えば、カードスロットや、ＵＳＢのポートを有する。外部接続インターフェイス装置２０６は、入力装置ＩＮＰ２、表示装置ＤＳＰ２、外部記憶媒体ＭＤ２と接続する。
【００６０】
入力装置ＩＮＰ２は、クライアントＣＬに操作情報を入力する装置である。入力装置ＩＮＰ２は、例えば、キーボードや、マウスである。表示装置ＤＳＰ２は、クライアントＣＬが出力する画像、文字などの各種情報を表示する装置である。表示装置ＤＳＰ２は、例えば、液晶ディスプレイである。
【００６１】
外部記憶媒体ＭＤ２は、ＵＳＢメモリなどの可搬型の不揮発性メモリである。なお、外部接続インターフェイス装置２０６を介して、記憶媒体に記憶されたデータを読み取る記憶媒体読み取り装置(図示しない)と接続する構成としても良い。この記憶媒体は、例えば、ＣＤ-ＲＯＭ、ＤＶＤなどの可搬型記憶媒体である。
【００６２】
図６は、図２のクライアントのソフトウェアブロック図である。処理ソフトＳＦ２は、主管理部２１、接続処理部２２、送受信部２３、応答確認部２４を有する。主管理部２１は、各種処理を実行すると共に、接続処理部２２、送受信部２３、応答確認部２４を管理する。
【００６３】
接続処理部２２は、サーバＳＶＲとの接続処理を実行する。送受信部２３は、データの送受信を行う。応答確認部２４は、クライアントＣＬが、あるブロックデータの代表クライアントの場合、このブロックデータの受信が成功すると、サーバＳＶＲに応答確認信号(以下、応答確認と適宜記す)を送信する。
【００６４】
[サーバＳＶＲの処理の概略説明]
図７は、図２のサーバＳＶＲの処理の概略を説明するフロー図である。以下のフロー図の説明において、"Ｓｐ"(小文字のｐは、１以上の整数)は、ステップＳｐを示す。
【００６５】
ステップＳ１：サーバＳＶＲのネゴシエーション部１２は、図３のストレージ１０２の送信データ記憶領域ＴＲ１に記憶されている送信データ(以下、送信データＡＴＤと適宜記す)を受信するクライアントＣＬを、受け付ける。なお、送信データは、配信データとも呼ばれる。送信データＡＴＤを受信するクライアントＣＬは、図２の第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎである。なお、Ｓ１の詳細については、図８〜図１０で説明する。
【００６６】
ステップＳ２：サーバＳＶＲのリスト管理部１５は、Ｓ１で受け付けたクライアントを含むクライアントリストを作成(構築とも呼ぶ)し、代表クライアントを決定する。リスト管理部１５は、作成したクライアントリストを図３のＲＡＭ１０３のリスト記憶領域ＬＲに記憶する。なお、Ｓ２のクライアントリストの作成の詳細については、図８〜図１０で説明し、代表クライアントの決定の詳細については、図１３で説明する。
【００６７】
ステップＳ３：サーバＳＶＲの送受信部１４は、送信データＡＴＤを、Ｓ１で受け付けたクライアントにマルチキャスト送信する。サーバＳＶＲの送受信部１４は、送信データＡＴＤの送信において、送信データＡＴＤをブロック単位で分割したブロックデータをマルチキャスト送信する。送受信部１４は、マルチキャスト送信するブロックデータをＲＡＭ１０３のブロックデータ記憶領域ＢＲにキャッシュする。
【００６８】
そして、サーバＳＶＲの送受信部１４は、代表クライアントから応答確認を受信すると、次のブロックデータの送信を行い、次のデータをＲＡＭ１０３のブロックデータ記憶領域ＢＲにキャッシュする。ブロックデータ記憶領域ＢＲの記憶容量は、１つのブロックデータのサイズ(例えば６４キロバイト)に相当する。そのため、送受信部１４は、次のブロックデータをＲＡＭ１０３のブロックデータ記憶領域ＢＲに既に記憶されていているデータに上書き記憶する。
【００６９】
サーバＳＶＲの送受信部１４は、送信データＡＴＤの送信が終了すると、処理を終了する。一方、サーバＳＶＲは、応答確認を受信するまでに、このブロックデータの再送要求を受信すると、再送処理(Ｓ４)を実行する。また、サーバＳＶＲは、クライアントＣＬからのキャンセル要求を受信すると、Ｓ５を実行する。また、サーバＳＶＲは、ブロックデータの送信完了後、所定の時間(例えば、１０秒、３０秒、１分など)以内に代表クライアントからの応答確認を受信しないと、Ｓ６を実行する。
【００７０】
なお、Ｓ３の詳細については、図１１で説明する。
【００７１】
ステップＳ４：サーバＳＶＲの送受信部１４は、ＲＡＭ１０３のブロックデータ記憶領域ＢＲにキャッシュした再送用のブロックデータを、再度、第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎにマルチキャスト送信する。
【００７２】
ステップＳ５：主管理部１１は、キャンセル要求を行ったクライアントの消去処理を行う。Ｓ５の消去処理は、キャンセル処理とも呼ぶ。
【００７３】
ステップＳ６：主管理部１１は、通信不能なクライアントの消去処理を行う。通信不能なクライアントが代表クライアントの場合、通信不能なクライアントは、応答確認を送信できない。その結果、サーバＳＶＲの送受信部１４は、所定の時間内に、応答確認を受信することができなくなる。そこで、主管理部１１は、通信不能なクライアントの消去処理を行う。
【００７４】
ステップＳ７：リスト管理部１５は、図３のＲＡＭ１０３のリスト記憶領域ＬＲに記憶したクライアントリストを調整する。Ｓ４、Ｓ７の終了後、Ｓ３に移る。
【００７５】
[クライアントリストの作成]
図８〜図１０を参照して、図７のクライアントリスト作成(図７のＳ２)について説明する。まず、サーバＳＶＲのネゴシエーション部１２は、クライアントの受け付け処理(図７のＳ１)において、第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎの各々とユニキャストで通信する。そして、サーバＳＶＲのネゴシエーション部１２は、第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎに属性情報の送信を要求する(Ｓ１)。
【００７６】
この属性情報は、クライアントＣＬの識別子、ＩＰ(Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)アドレス、ＭＡＣ(Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ)アドレス、クライアントの名前を含む。
【００７７】
第１のクライアントＣＬ１〜第ｎのクライアントＣＬｎの接続処理部２２は、サーバＳＶＲからの属性情報の送信要求に応答して、例えばストレージ２０２に記憶されている属性情報をサーバＳＶＲに送信する。なお、以下の説明において、図２におけるクライアントは、第１のクライアントＣＬ１〜第７(ｎは７)のクライアントＣＬ７であるとする。すなわち、サーバＳＶＲは、第１のクライアントＣＬ１〜第７のクライアントＣＬ７に送信データＡＴＤをマルチキャスト送信する。
【００７８】
サーバＳＶＲのリスト管理部１５は、第１のクライアントＣＬ１〜第７のクライアントＣＬ７の各々から送信された属性情報を受信し、属性情報リストＬＳＴ１を作成する。
【００７９】
(属性情報の登録)
図８は、属性情報リストＬＳＴ１を示す図である。属性情報リストＬＳＴ１は、クライアント番号欄と、ＩＰアドレス欄と、ＭＡＣアドレス欄と、コンピュータ名欄とを有する。クライアント番号欄は、属性情報を送信したクライアントＣＬの識別子を登録する欄である。クライアントＣＬの識別子は、図２、図５で示したクライアントの符号(例えば、ＣＬ、ＣＬ１、ＣＬ２など)に該当する。
【００８０】
ＩＰアドレス欄は、クライアント番号欄に登録された識別子により識別されるクライアントＣＬに設定されているＩＰアドレスを登録する欄である。ＭＡＣアドレス欄は、クライアント番号欄に登録された識別子により識別されるクライアントＣＬの通信装置２０５に設定されているＭＡＣアドレスを登録する欄である。
【００８１】
コンピュータ名欄は、クライアント番号欄に登録された識別子により識別されるクライアントＣＬの名前(コンピュータ名と適宜記す)を登録する。
【００８２】
サーバＳＶＲのネゴシエーション部１２は、各クライアントとユニキャストで通信して、各クライアントの属性情報を受信する。リスト管理部１５は、各クライアントの属性情報を、属性情報リストＬＳＴ１として、ＲＡＭ１０３のリスト記憶領域ＬＲに記憶する。
【００８３】
サーバＳＶＲのネゴシエーション部１２は、例えば、第１のクライアントＣＬ１の属性情報を受信する。この属性情報は、第１のクライアントＣＬ１の識別子"ＣＬ１"、第１のクライアントＣＬ１に設定されているＩＰアドレス"１９２.１６８.１.１１"を含む。さらに、この属性情報は、第１のクライアントＣＬ１の通信装置２０５に設定されているＭＡＣアドレス" ＡＡ-ＢＢ-ＣＣ-ＤＤ-ＥＥ-１１"や、第１のクライアントＣＬ１のコンピュータ名"ＣＯＭＰ１"を含む。
【００８４】
次いで、リスト管理部１５は、図８の属性情報リストＬＳＴ１におけるクライアント番号欄の２行目に第１のクライアントＣＬ１の識別子"ＣＬ１"を登録する。そして、ネゴシエーション部１２は、図８のＩＰアドレス欄の２行目に第１のクライアントＣＬ１に設定されているＩＰアドレス"１９２.１６８.１.１１"を登録する。そして、ネゴシエーション部１２は、ＭＡＣアドレス欄の２行目に第１のクライアントＣＬ１の通信装置２０５に設定されているＭＡＣアドレス" ＡＡ-ＢＢ-ＣＣ-ＤＤ-ＥＥ-１１"を登録する。そして、ネゴシエーション部１２は、図８のコンピュータ名欄の２行目に第１のクライアントＣＬ１のコンピュータ名"ＣＯＭＰ１"を登録する。
【００８５】
ネゴシエーション部１２は、さらに、第２のクライアントＣＬ２〜第７のクライアントＣＬ７の属性情報を受信する。そして、リスト管理部１５は、第２のクライアントＣＬ２〜第７のクライアントＣＬ７の属性情報を、属性情報リストＬＳＴ１として、ＲＡＭ１０３のリスト記憶領域ＬＲに記憶する。
【００８６】
(クライアントのグループ化)
リスト管理部１５は、複数のクライアントが、同じブロックデータをキャッシュするため、図７のＳ１で受け付けた複数のクライアントを複数のグループに分割(グループ化とも呼ぶ)する。すなわち、リスト管理部１５は、この複数のクライアントを複数のクライアント群にグループ化する。リスト管理部１５は、グループ化において、各グループのクライアントの数が、各グループ間で均等になるように、すなわち、複数のクライアント群の各々に含まれるクライアントの数の差が最小になるように、複数のクライアント群にグループ化する。
【００８７】
例えば、第１のクライアントＣＬ１〜第７のクライアントＣＬ７を２つのグループに分割する第１の場合を想定する。リスト管理部１５は、第１の場合、クライアントの台数である"７"を、分割するグループの数"２"で除算する。そして、リスト管理部１５は、第１のグループのクライアント数を、この除算の商"３"と、剰余"１"との和"４"とする。リスト管理部１５は、第２のグループのクライアント数を、この除算の商"３"とする。
【００８８】
従って、リスト管理部１５は、第１の場合では、第１のクライアントＣＬ１〜第７のクライアントＣＬ７を、第１のグループ、第２のグループに分割する。第１のグループは、第１のクライアントＣＬ１〜第４のクライアントＣＬ４を含むグループである。第２のグループは、第５のクライアントＣＬ５〜第７のクライアントＣＬ７を含むグループである。
【００８９】
他にも、第１のクライアントＣＬ１〜第１１のクライアントＣＬ１１を３つのグループに分割する第２の場合を想定する。リスト管理部１５は、第２の場合、クライアントの台数である"１１"を、分割するグループの数"３"で除算する。そして、リスト管理部１５は、第１のグループのクライアント数を、この除算の商"３"と、剰余"２"の中の"１"との和"４"とする。リスト管理部１５は、第２のグループのクライアント数を、この除算の商"３"と、剰余"２"の中の"１"との和"４"とする。リスト管理部１５は、第３のグループのクライアント数を、この除算の商"３"とする。
【００９０】
従って、リスト管理部１５は、第２の場合では、第１のクライアントＣＬ１〜第１１のクライアントＣＬ１１を以下の第１１〜第１３のグループに分割する。
【００９１】
第１１のグループは、第１のクライアントＣＬ１〜第４のクライアントＣＬ４を含む。第１２のグループは、第５のクライアントＣＬ５〜第８のクライアントＣＬ８を含む。第１３のグループは、第９のクライアントＣＬ９〜第１１のクライアントＣＬ１１を含む。
【００９２】
(クライアントリスト)
リスト管理部１５は、各グループのクライアントに関する情報を含むクライアントリストを作成する(Ｓ２)。以下の説明は、前記した、第１のクライアントＣＬ１〜第７のクライアントＣＬ７を２つのグループに分割する第１の場合において、リスト管理部１５が、クライアントリストを作成する処理を例示する。
【００９３】
リスト管理部１５は、前記したように、第１のクライアントＣＬ１〜第７のクライアントＣＬ７を、第１、第２のグループに分割する。なお、第１のグループは、第１のクライアントＣＬ１〜第４のクライアントＣＬ４を含む。第２のグループは、第５のクライアントＣＬ５〜第７のクライアントＣＬ７を含む。
【００９４】
図９は、第１のグループのクライアントリストの図である。図１０は、第２のグループのクライアントリストの図である。
【００９５】
図９のクライアントリストＬＳＴ１ａ、図１０のクライアントリストＬＳＴ１ｂは、図８の属性情報リストＬＳＴ１で説明した、クライアント番号欄、ＩＰアドレス欄、ＭＡＣアドレス欄、コンピュータ名欄を有する。さらに、クライアントリストＬＳＴ１ａ、クライアントリストＬＳＴ１ｂは、応答ブロック番号欄、重複フラグ欄を有する。応答ブロック番号欄は、クライアント番号欄に登録された識別子(クライアント番号)のクライアントＣＬがキャッシュするブロックデータを識別する識別子(以下、番号と適宜記す)を登録する。
【００９６】
重複フラグ欄は、同一グループにおいて、クライアント番号欄に登録されたクライアント番号のクライアントＣＬ以外のクライアントＣＬｘが、このクライアントＣＬと同じブロックデータをキャッシュしている場合、このクライアントＣＬｘの番号を登録する。
【００９７】
同一グループにおいて、クライアント番号欄に登録された識別子(クライアント番号)のクライアントＣＬ以外のクライアントＣＬｘが、このクライアントＣＬと同じブロックデータをキャッシュしていない場合、重複フラグ欄には"０"が登録される。重複フラグ欄に登録されたクライアントの番号(クライアント番号)は、図２の各クライアントに付した符号に該当する。リスト管理部１５は、作成したクライアントリストをＲＡＭ１０３のリスト記憶領域ＬＲに記憶する。なお、応答ブロック番号欄、重複フラグ欄の内容については、図１１、図１３で説明する。
【００９８】
以上説明したように、リスト管理部１５は、代表クライアントを決定する処理の前に、以下の処理を行う。すなわち、リスト管理部１５は、送信データＡＴＤを受信する複数のクライアントを、複数のクライアント群の各々に含まれるクライアントの数の差が最小になるように、複数のクライアント群にグループ化する。そして、リスト管理部１５は、複数のクライアント群の各々に対応して、グループ化された各クライアントをリストに登録し、このリストを記憶部に記憶する。このリストは、例えば、図９のクライアントリストＬＳＴ１ａ、図１０のクライアントリストＬＳＴ１ｂである。また、この記憶部は、例えば、ＲＡＭ１０３でもよいし、ストレージ１０２にでもよい。
【００９９】
[マルチキャスト送信]
図１１〜図１３を参照して、図７の送信データのマルチキャスト送信(図７のＳ３)について説明する。図１１は、図７の送信データのマルチキャスト送信(Ｓ３)を説明するフロー図である。
【０１００】
ステップＳ３１:サーバＳＶＲの送信データ管理部１３は、ストレージ１０２の送信データ記憶領域ＴＲ１に記憶されている送信データＡＴＤを読み出し、送信データＡＴＤをブロック単位に分割し、複数のブロックデータを作成する。送信データ管理部１３は、作成したブロックデータを例えばストレージ１０２に記憶する。
【０１０１】
ステップＳ３２:送受信部１４は、未送信のブロックデータを、図７のＳ１で受け付けた複数のクライアントにマルチキャスト送信する。送受信部１４は、マルチキャスト送信したブロックデータの番号をＲＡＭ１０３に記憶する。送受信部１４は、例えば、第１のブロックデータＢＬ１をマルチキャスト送信した場合、第１のブロックデータＢＬ１の番号"１"(または番号"ＢＬ１")をＲＡＭ１０３に記憶する。なお、送受信部１４は、マルチキャスト送信において、図７のＳ１で受け付けた複数のクライアントのマルチキャストＩＰアドレスを利用してもよい。
【０１０２】
ステップＳ３３:送受信部１４は、代表クライアントからの応答確認の受信待ち状態、カレントブロックデータ(以下、カレントブロックと適宜記す)の送信依頼待ち状態に移行する。カレントブロックは、送受信部１４がマルチキャスト送信の継続中または完了したブロックデータであって、このブロックデータの代表クライアントからの応答確認を受信していないブロックデータである。
【０１０３】
応答確認を受信するまでにカレントブロックの再送依頼があった場合、再送処理(図７のＳ４)に進む。所定の時間を経過しても、代表クライアントからの応答確認を受信しない場合、応答確認を送信しない代表クライアントの消去処理(図７のＳ６)に進む。なお、サーバＳＶＲの送受信部１４により、クライアントＣＬからのキャンセル要求を受信すると、クライアントＣＬのキャンセル処理(図７のＳ５)に進む。
【０１０４】
ステップＳ３４:送受信部１４は、全てのブロックデータ(換言すれば、送信データＡＴＤ)の送信を終了したか判定する。全てのブロックデータの送信が終了した場合(Ｓ３４/ＹＥＳ)、送信データの送信を終了する(図７の終了)。全てのブロックデータの送信が終了しない場合(Ｓ３４/ＮＯ)、送信データの送信を継続する(Ｓ３２に移る)。
【０１０５】
(ブロックデータの分割)
図１２は、ブロックデータの分割処理および送信処理(図１１のＳ３１、Ｓ３２)を説明する図である。図１２(Ａ)は、送信データＡＴＤをブロックデータに分割した状態を模式的に示した図である。図１２(Ｂ)は、ブロックデータの一部を含む送信パケットを模式的に示した図である。
【０１０６】
送信データ管理部１３は、ストレージ１０２に記憶された送信データＡＴＤから複数のブロックデータを作成する。このブロックデータのサイズは、例えば３２キロバイトや６４キロバイトである。
【０１０７】
図１２(Ａ)において、送信データＡＴＤから第１のブロックデータＢＬ１〜第ｑ(ｑは３以上の整数)のブロックデータＢＬｑが作成された状態を模式的に示す。送信データ管理部１３は、各ブロックデータと、各ブロックデータを識別するブロックデータの番号(以下、ブロックデータ番号と適宜記す)とを対応付けてストレージ１０２に記憶する。
【０１０８】
(ブロックデータの送信)
送受信部１４は、第１のブロックデータＢＬ１を各クライアントにマルチキャスト送信し、次に、第２のブロックデータＢＬ２を各クライアントにマルチキャスト送信する。同様に、送受信部１４は、順次、第ｑのブロックデータＢＬｑまでを各クライアントにマルチキャスト送信する。送受信部１４は、このマルチキャスト送信において、代表クライアントからの応答確認を受信すると、次のブロックデータのマルチキャスト送信を行う。送受信部１４は、例えば、第１のブロックデータＢＬ１のマルチキャスト送信を行う。
【０１０９】
そして、送受信部１４は、第１のブロックデータＢＬ１についての応答確認を、各グループにおけるすべての代表クライアント(例えば、第１のクライアントＣＬ１、第５のクライアントＣＬ５)から受信する。すると、送受信部１４は、第１のブロックデータＢＬ１の次の第２のブロックデータＢＬ２を複数のクライアントにマルチキャスト送信する。
【０１１０】
送受信部１４は、ブロックデータの送信において、送信するブロックデータと、送信するブロックデータのブロックデータ番号とをストレージ１０２から読み出し、ＲＡＭ１０３のブロックデータ記憶領域ＢＲに記憶する。そして、送受信部１４は、このブロックデータをパケット単位で送信する。図１２(Ｂ)は、送受信部１４が送信するパケットＰＣＫを示す。図１２(Ｂ)に示すパケットＰＣＫは、ブロックデータの信号や制御データなどの各種データを含む信号を模式的に示している。
【０１１１】
パケットＰＣＫは、ブロックデータが更に分割されたデータを送信するためのパケットである。例えば、送受信部１４が、第１のブロックデータＢＬ１を送信する場合を想定する。第１のブロックデータＢＬ１のサイズは、例えば６４キロバイトである。
【０１１２】
送受信部１４は、第１のブロックデータＢＬ１を送信するにあたり、第１のブロックデータＢＬ１を例えば１キロバイト(１０２４バイト)単位で分割し、６４個のデータ(以下、分割ブロックデータと適宜記す)を作成し、ＲＡＭ１０３に記憶する。
【０１１３】
送受信部１４は、各分割ブロックデータを識別する分割ブロックデータ番号を、各ブロックデータに割り振る。そして、送受信部１４は、各分割ブロックデータと、各ブロックデータの分割ブロックデータ番号とを対応付けてＲＡＭ１０３に記憶する。
【０１１４】
送受信部１４は、各分割ブロックデータを含むパケットＰＣＫを作成し、ＲＡＭ１０３に記憶する。
【０１１５】
パケットＰＣＫは、制御データＣＴＲＬと、代表クライアント番号ＣＬＮＭと、ブロックデータ番号ＢＬＮＭと、分割ブロックデータ番号ＤＶＢＬＮＭと、分割ブロックデータＤＶとを有する。
【０１１６】
制御データＣＴＲＬは、パケットの各種制御データである。この各種制御データは、送信元のサーバＳＶＲのＩＰアドレス、ブロックデータの総数、分割ブロックデータの総数、ＣＲＣ(Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ)用のデータなどを含む。代表クライアント番号ＣＬＮＭは、パケットＰＣＫの分割ブロックデータＤＶを含むブロックデータをキャッシュする代表クライアントの番号を含む。
【０１１７】
分割ブロックデータ番号は、分割ブロックデータＤＶに割り振られた分割ブロックデータ番号を含む。分割ブロックデータＤＶは、送信対象の分割ブロックデータであり、いわゆるペイロードである。図１２では、第１のブロックデータＢＬ１における分割ブロックデータを点線で模式的に示している。
【０１１８】
送受信部１４は、第１のブロックデータＢＬ１を送信するにあたり、６４個の分割ブロックデータを各クライアントに１個ずつ順次マルチキャスト送信する。
【０１１９】
送受信部１４が、第ｓ(ｓは１〜ｑの整数)のブロックデータＢＬｓを各クライアントにマルチキャスト送信する場合を想定する。この場合、送受信部１４は、第ｓのブロックデータＢＬｓの第１の分割ブロックデータ〜第６４の分割ブロックデータを１つずつ含む６４個のパケットＰＣＫを作成し、ＲＡＭ１０３に記憶する。
【０１２０】
送受信部１４は、第ｓのブロックデータＢＬｓの第ｒ(ｒは１〜６４の整数)の分割ブロックデータのパケット(以下、第ｒのパケットと適宜記す)をマルチキャスト送信する。
【０１２１】
第ｒのパケットの代表クライアント番号ＣＬＮＭは、第ｓのブロックデータＢＬｓの代表クライアントの識別子を含む。この代表クライアントは、例えば、クライアントリストＬＳＴ１ａの第１のクライアントＣＬ１、クライアントリストＬＳＴ１ｂの第５のクライアントＣＬ５である。パケットＰＣＫに含まれる代表クライアント番号ＣＬＮＭは、代表クライアントを特定する情報の一例である。なお、代表クライアントについては、図１３で説明する。
【０１２２】
第ｒ(ｒは１〜６４の整数)のパケットの制御データＣＴＲＬは、送信データＡＴＤから作成されたブロックデータの総数(値"ｑ"(ｑは３以上の整数))や、分割ブロックデータの総数("６４")や、ＣＲＣ用のデータなどを含む。
【０１２３】
第ｒのパケットのブロックデータ番号ＢＬＮＭは、第ｓ(ｓは１以上の整数)のブロックデータのブロックデータ番号(例えば、番号"ｓ"または番号"ＢＬｓ")を含む。第ｒのパケットの分割ブロックデータ番号ＤＶＢＬＮＭは、第ｒの分割ブロックデータの分割ブロックデータ番号(例えば、番号"ｒ")を含む。第ｒのパケットの分割ブロックデータＤＶは、第ｒの分割ブロックデータを含む。
【０１２４】
送受信部１４は、第ｒのパケットを各クライアントリストにマルチキャスト送信し、この送信が終了すると、次のパケットである、第(ｒ+１)のパケットをマルチキャスト送信する。なお、"(ｒ+１)"は、"ｒ"に１を加算した値を示す。送受信部１４は、第ｓのブロックデータＢＬｓの全パケット(第１〜第６４のパケット)の送信が終了し、第ｓのブロックデータＢＬｓの複数の代表クライアント全てからの応答確認を受信すると、次のブロックデータの送信を行う。この次のブロックデータは、第ｓのブロックデータＢＬｓの次のブロックデータ、第(ｓ+１)のブロックデータＢＬ(ｓ+１)である。なお、"(ｓ+１)"は、"ｓ"に１を加算した値を示す。
【０１２５】
(代表クライアント)
次に、ブロックデータの送信順序、代表クライアントの決定、クライアントリストの更新について説明する。図１３は、ブロックデータの送信順序、代表クライアントの決定について説明する図である。
【０１２６】
図１３は、図９に示したクライアントリストＬＳＴ１ａのクライアントを含む第１のグループＧ１と、図１０に示したクライアントリストＬＳＴ１ｂのクライアントを含む第２のグループＧ２とを示す。第１のグループＧ１は、第１のクライアントＣＬ１〜第４のクライアントＣＬ４を含む。第２のグループＧ２は、第５のクライアントＣＬ５〜第７のクライアントＣＬ７を含む。
【０１２７】
図１３において、符号ＣＬ１〜符号ＣＬ７で示す四角の枠は、符号ＣＬ１〜符号ＣＬ７で示すクライアントを模式的に示す。この四角の枠内に、四角枠の符号で示すクライアントがキャッシュするブロックデータの符号を示す。また、矢印は、代表クライアントが順次決定される状態を模式的に示す。なお、あるブロックデータをキャッシュすると共に、このブロックデータの応答確認を行うクライアントが、このブロックデータの代表クライアントである。
【０１２８】
(各グループ間の同期)
リスト管理部１５は、異なるグループのクライアントが同じブロックデータをキャッシュできるように、各グループのクライアントの中からラウンドロビン方式により、代表クライアントを決定する。各グループのクライアントの中からラウンドロビン方式により代表クライアントを決定する場合、代表クライアントが一巡するタイミングを同じにする。
【０１２９】
具体的には、リスト管理部１５は、第(３ｔ+１)(ｔは０以上の整数)のブロックデータＢＬ(３ｔ+１)の代表クライアントを第１のクライアントＣＬ１、第５のクライアントＣＬ５と決定し、決定した旨をＲＡＭ１０３に記憶する。なお、"(３ｔ+１)"は、"３"と"ｔ"とを乗算し、乗算値に"１"を加算した値を示す。
【０１３０】
そして、リスト管理部１５は、第(３ｔ+２)のブロックデータＢＬ(３ｔ+２)の代表クライアントを第２のクライアントＣＬ２、第６のクライアントＣＬ６と決定し、決定した旨をＲＡＭ１０３に記憶する。なお、"(３ｔ+２)"は、"３"と"ｔ"とを乗算し、乗算値に"２"を加算した値を示す。
【０１３１】
そして、リスト管理部１５は、第(３ｔ+３)のブロックデータＢＬ(３ｔ+３)の代表クライアントを第３、第４のクライアントＣＬ３、ＣＬ４、第７のクライアントＣＬ７と決定し、決定した旨をＲＡＭ１０３に記憶する。なお、"(３ｔ+３)"は、"３"と"ｔ"とを乗算し、乗算値に"３"を加算した値を示す。
【０１３２】
ここで、リスト管理部１５が、第(３ｔ+３)のブロックデータＢＬ(３ｔ+３)の代表クライアントを、第１のグループＧ１において２つの第３、第４のクライアントＣＬ３、ＣＬ４と決定するのは、以下の理由である。すなわち、各グループにおいて代表クライアントが一巡するタイミングを同じにするためである。代表クライアントが一巡するタイミングが同じになることを各グループ間の同期を取ると適宜記す。この各グループ間の同期をとる理由については、図２５で説明する。
【０１３３】
代表クライアントの決定において、異なるグループのクライアントが同じ数の場合には、この各グループ間の同期をとることができる。図８〜図１０の例のように、異なるグループＧ１、Ｇ２で、クライアントの数が異なる場合、代表クライアントの決定において代表クライアントの重複処理が必要になる。
【０１３４】
リスト管理部１５は、この重複処理を実行する。この重複処理は、以下の第１〜第３の処理を含む。第１の処理は、一つのクライアント群に含まれる複数のクライアントを複数のサブグループに分ける。ここで、サブグループは、１つ以上のクライアントが含まれる。また、リスト管理部１５は、複数のグループにおけるサブグループの数が同じになるように、さらに、各サブグループに含まれるクライアントの数が均等になるように、一つのグループに含まれる複数のクライアントを複数のサブグループに分ける。
【０１３５】
第２の処理は、各サブグループに含まれるクライアントの数の差を算出する。第３の処理は、算出した差がゼロでない場合、クライアント数が最大であるサブグループに含まれるクライアントを、同じ第Ｎのブロックデータの代表クライアントと決定する。以下、同じ第Ｎのブロックデータの代表クライアントを重複クライアントと適宜記す。
【０１３６】
図１３の例で示すと、リスト管理部１５は、第１の処理として、グループＧ１とグループＧ２のそれぞれを３つのサブグループに分ける。グループＧ１において、1つ目のサブグループは、クライアントＣＬ１、２つ目のサブグループは、クライアントＣＬ２、３つ目のサブグループは、クライアントＣＬ３、ＣＬ４である。
【０１３７】
グループＧ２において、1つ目のサブグループは、クライアントＣＬ５、２つ目のサブグループは、クライアントＣＬ６、３つ目のサブグループは、クライアントＣＬ７である。
【０１３８】
リスト管理部１５は、第２の処理として、各サブグループに含まれるクライアントの数の差（０または１）を算出する。例えば、グループＧ１において、1つ目のサブグループ（クライアント数は１）と、２つ目のサブグループ（クライアント数は１）との差は０である。しかし、グループＧ１において、３つ目のサブグループ（クライアント数は２）と、２つ目のサブグループ（クライアント数は１）との差は１である。
【０１３９】
リスト管理部１５は、第３の処理として、クライアント数が最大である、グループＧ１において、３つ目のサブグループに含まれるクライアントを、同じ第Ｎのブロックデータの代表クライアントと決定する。この決定された代表クライアント（重複クライアント）は、前記の例では、第３のクライアントＣＬ３、第４のクライアントＣＬ４である。なお、リスト管理部１５は、重複クライアントを、例えば、最も多いクライアント数を含むグループのクライアントリストの最下段のクライアントと、その上段のクライアントとから決定する。
【０１４０】
以上説明したように、第(３ｔ+３)のブロックデータＢＬ(３ｔ+３)の代表クライアントが、第１のグループＧ１において２つの第３、第４のクライアントＣＬ３、ＣＬ４と決定される。ここで、送受信部１４が、第(３ｔ+３)のブロックデータＢＬ(３ｔ+３)の第ｒ(ｒは１〜６４の整数)の分割ブロックデータのパケット(第ｒのパケット)を送信する場合を想定する。
【０１４１】
この想定では、第ｒのパケットの代表クライアント番号ＣＬＮＭは、第３のクライアントＣＬ３、第４のクライアントＣＬ４、第７のクライアントＣＬ７のクライアント番号(例えば"ＣＬ３"、"ＣＬ４"、"ＣＬ７")を含むことになる。
【０１４２】
リスト管理部１５は、第１〜第３の処理が終了すると、同一グループにおいて同じブロックデータを複数のクライアントがキャッシュすることを示す情報をＲＡＭ１０３に記憶する。この情報の記憶として、リスト管理部１５は、重複クライアントを含むクライアントリストにこの情報を登録する。
【０１４３】
具体的には、リスト管理部１５は、重複クライアントＣＬ３、ＣＬ４を含むクライアントリストＬＳＴ１ａを特定する。リスト管理部１５は、クライアントリストＬＳＴ１ａにおける重複クライアントＣＬ４のクライアント番号"ＣＬ４"と重複フラグ欄とが交わるセルに、他の重複クライアントＣＬ３のクライアント番号"ＣＬ３"を登録する。次いで、リスト管理部１５は、クライアントリストＬＳＴ１ａにおける重複クライアントＣＬ３のクライアント番号"ＣＬ３"と重複フラグ欄とが交わるセルに、他の重複クライアントＣＬ４のクライアント番号"ＣＬ４"を登録する。
【０１４４】
リスト管理部１５は、図１３で説明したように、複数のリスト(ＬＳＴ１ａ、ＬＳＴ１ｂ)に登録されたクライアントの中から、ラウンドロビン方式により、クライアント群毎かつ分割されたブロックデータ毎に代表クライアントを決定する。
【０１４５】
リスト管理部１５は、代表クライアントの決定において、前記した重複処理を実行して、重複クライアントを決定する。
【０１４６】
(クライアントリストの更新)
サーバＳＶＲの送受信部１４は、図１２で説明したように、第ｓ(ｓは１〜ｑの整数)のブロックデータＢＬｓの第１〜第６４のパケットを順次マルチキャスト送信する。なお、送受信部１４は、第１〜第６４のパケットの代表クライアント番号ＣＬＮＭに代表クライアントの番号を含める。
【０１４７】
送受信部１４は、第ｓのブロックデータＢＬｓについての応答確認をすべての代表クライアントから受信すると、クライアントリストの更新を行う。送受信部１４は、クライアントリストＬＳＴ１ａ、ＬＳＴ１ｂにおける、第ｓのブロックデータＢＬｓの代表クライアントのクライアント番号が登録された行と、応答ブロック番号欄とが交わるセルに送信した第ｓのブロックデータＢＬｓの番号を上書き登録する。なお、第ｓのブロックデータＢＬｓの番号は、例えば、第ｓの番号"ｓ"である。
【０１４８】
例えば、送受信部１４は、第(３ｔ+１)のブロックデータＢＬ(３ｔ+１)のマルチキャスト送信が終了し、代表クライアントＣＬ１、ＣＬ５から応答確認を受信する。なお、"ｔ"は０以上の整数である。
【０１４９】
すると、送受信部１４は、図９のクライアントリストＬＳＴ１ａにおける、代表クライアントのクライアント番号"ＣＬ１"が登録された行と、応答ブロック番号欄とが交わるセルに送信したブロックデータの番号"(３ｔ+１)"を登録する。さらに、送受信部１４は、図１０のクライアントリストＬＳＴ１ｂにおける、代表クライアントのクライアント番号"ＣＬ５"が登録された行と、応答ブロック番号欄とが交わるセルに送信したブロックデータの番号"(３ｔ+１)"を登録する。
【０１５０】
送受信部１４は、第(３ｔ+２)のブロックデータＢＬ(３ｔ+２)のマルチキャスト送信が終了し、代表クライアントＣＬ２、ＣＬ６から応答確認を受信する。
【０１５１】
すると、送受信部１４は、図９のクライアントリストＬＳＴ１ａにおける、代表クライアントのクライアント番号"ＣＬ２"が登録された行と、応答ブロック番号欄とが交わるセルに送信したブロックデータの番号"(３ｔ+２)"を登録する。さらに、送受信部１４は、図１０のクライアントリストＬＳＴ１ｂにおける、代表クライアントのクライアント番号"ＣＬ６"が登録された行と、応答ブロック番号欄とが交わるセルに送信したブロックデータの番号"(３ｔ+２)"を登録する。
【０１５２】
送受信部１４は、第(３ｔ+３)のブロックデータＢＬ(３ｔ+３)のマルチキャスト送信が終了し、すべての代表クライアントＣＬ３、ＣＬ４、ＣＬ７から応答確認を受信する。
【０１５３】
すると、送受信部１４は、図１０のクライアントリストＬＳＴ１ｂにおける、代表クライアントのクライアント番号"ＣＬ３"、"ＣＬ４"が登録された行と、応答ブロック番号欄とが交わるセルに送信したブロックデータの番号"(３ｔ+３)"を登録する。さらに、送受信部１４は、図１０のクライアントリストＬＳＴ１ｂにおける、代表クライアントのクライアント番号"ＣＬ７"が登録された行と、応答ブロック番号欄とが交わるセルに送信したブロックデータの番号"(３ｔ+３)"を登録する。
【０１５４】
図９、図１０の例では、"ｔ"が０の場合における、応答ブロック番号欄の更新について図示している。図９、図１０において、クライアント番号ＣＬ１、ＣＬ５に対応する応答ブロック番号"１"が更新される。次いで、クライアント番号ＣＬ２、ＣＬ６に対応する応答ブロック番号"２"が更新される。次いで、クライアント番号ＣＬ３、ＣＬ４、ＣＬ７に対応する応答ブロック番号"３"が更新される。なお、クライアントリストにおいて、"…"は、以後の省略を示す。
【０１５５】
以上説明したように、サーバＳＶＲは、以下の処理を実行する。すなわち、サーバＳＶＲの送信データ管理部１３は、送信データＡＴＤ(図１２(Ａ)参照)を複数のブロックデータに分割する。リスト管理部１５は、複数のグループ(複数のクライアント群)の各々に含まれるクライアントの中から、クライアント群毎かつ分割されたブロックデータ毎に代表クライアントを決定する。
【０１５６】
送受信部１４は、第１のブロックデータを複数のクライアントに送信する。なお、この送信は、例えばマルチキャスト送信である。
【０１５７】
送受信部１４は、分割されたブロックデータを、代表クライアントを特定する情報と共に、複数のクライアント群各々に含まれる複数のクライアントに送信する。なお、この代表クライアントを特定する情報は、例えば、図１２(Ｂ)で説明したパケットＰＣＫに含まれる代表クライアント番号ＣＬＮＭである。
【０１５８】
送受信部１４は、第１のブロックデータについての応答確認を、クライアント群毎かつ分割されたブロックデータ毎に決定された代表クライアントから、受信すると、以下の送信処理を実行する。すなわち、送受信部１４は、第１のブロックデータの次の第２のブロックデータを複数のクライアント群の各々に含まれる複数のクライアントに送信する。
【０１５９】
[クライアントの処理]
次に、クライアントＣＬの処理について説明する。複数のクライアント群各々に含まれる複数のクライアント各々は、複数のブロックデータを受信して記憶部(例えば、図５のＲＡＭ２０３)に記憶する。そして、複数のクライアント各々は、複数のブロックデータのうち第Ｎ(大文字のＮは１以上の整数)のブロックデータを受信できず、かつ、このクライアントが第Ｎブロックデータの代表クライアントとして機能しない場合、以下の処理を実行する。すなわち、このクライアントは、この第Ｎのブロックデータを送信する要求を、以下の代表クライアントに要求する。この代表クライアントは、自己(換言すれば、代表クライアントでないクライアント)が含まれるクライアント群の代表クライアントと自己が含まれないクライアント群の代表クライアントである。
【０１６０】
クライアントが第Ｎブロックデータの代表クライアントとして機能する場合、この要求を受信すると、記憶部から読み出した第Ｎのブロックデータを要求したクライアントに送信する。以下、図４、図１４を参照して、クライアントＣＬの処理について詳細に説明する。
【０１６１】
（ブロックデータ受信処理）
図１４は、クライアントＣＬのブロックデータ受信処理のフロー図である。
【０１６２】
ステップＳ１０１:クライアントＣＬの送受信部２３は、サーバＳＶＲが送信したブロックデータを受信する。クライアントＣＬの送受信部２３は、ブロックデータに割り振られている番号の順にブロックデータを受信する。なお、この受信において、送受信部２３は、サーバＳＶＲから送信された送信パケットを受信している。
【０１６３】
ステップＳ１０２:送受信部２３は、ブロックデータを正常に受信したか判定する。ここで、送受信部２３は、第ｓのブロックデータＢＬｓ(ｓは１〜ｑ(ｑは３以上の整数))を正常受信した後に、第(ｓ+１)のブロックデータＢＬ(ｓ+１)を受信する。
【０１６４】
従って、送受信部２３は、第ｓのブロックデータＢＬｓを正常受信する前に、第ｓのブロックデータＢＬｓに後続するブロックデータを受信した場合、第ｓのブロックデータＢＬｓの送信依頼を行う。第ｓのブロックデータＢＬｓに後続するブロックデータは、ブロック番号が、"第ｓ"を超えるブロックデータであり、例えば、第(ｓ+１)のブロックデータＢＬ(ｓ+１)である。
【０１６５】
ブロックデータを正常に受信した場合（Ｓ１０２/ＹＥＳ）、Ｓ１０３に移る。ブロックデータを正常に受信しない場合（Ｓ１０２/ＮＯ）、Ｓ１０８に移る。
【０１６６】
ステップＳ１０３:送受信部２３は、受信したブロックデータをストレージ２０２の送信データ記憶領域ＴＲ２に記憶する。
【０１６７】
ステップＳ１０４:クライアントＣＬの送受信部２３は、自クライアントが代表クライアントか判定する。自クライアントが代表クライアントの場合（Ｓ１０４/ＹＥＳ）、Ｓ１０５に移る。自クライアントが代表クライアントでない場合（Ｓ１０４/ＮＯ）、Ｓ１０７に移る。
【０１６８】
ステップＳ１０５:代表クライアントの送受信部２３は、受信したブロックデータをＲＡＭ２０３のデータキャッシュ領域ＤＣＲに記憶する。データキャッシュ領域ＤＣＲに記憶されたブロックデータが、送信依頼に応答して送信されるブロックデータである。さらに、代表クライアントの送受信部２３は、受信したブロックデータの番号をＲＡＭ２０３に記憶する。なお、受信したブロックデータの番号は、図１２(Ｂ)のパケットＰＣＫのブロックデータ番号ＢＬＮＭに含まれている。
【０１６９】
ステップＳ１０６:代表クライアントの送受信部２３は、ブロックデータを正常に受信したことを示す応答確認をサーバＳＶＲに送信する。代表クライアントの送受信部２３は、この応答確認に、代表クライアントのストレージ２０２に記憶されているクライアント識別子と、正常に受信したブロックデータの番号を含める。なお、ブロックデータの番号は、パケットのブロックデータ番号ＢＬＮＭに含まれている。
【０１７０】
ステップＳ１０７:クライアントＣＬの送受信部２３は、全ブロックデータを受信したか判定する。クライアントＣＬの送受信部２３は、全ブロックデータを受信しない場合（Ｓ１０７/ＮＯ）、Ｓ１０１に移る。
【０１７１】
一方、クライアントＣＬの送受信部２３は、全ブロックデータを受信した場合（Ｓ１０７/ＹＥＳ）、受信処理を終了する。受信処理の終了後、主管理部２１は、全ブロックデータを結合してサーバＳＶＲの送信データＡＴＤとする。なお、受信処理を終了したクライアントＣＬは、受信処理の終了後も、ブロックデータの送信要求に対する応答処理を実行する。
【０１７２】
ステップＳ１０８:ブロックデータを正常受信できなかったクライアントＣＬの送受信部２３は、正常受信できなかったブロックデータの送信依頼を行う。送受信部２３は、正常受信できなかったブロックデータの番号を含めた送信依頼パケットをマルチキャスト送信する。なお、送受信部２３は、送信依頼パケットに、自端末のＩＰアドレスを含める。送受信部２３は、他にも、継続送信依頼を示す情報を含む送信依頼パケットに含めることがある。継続送信依頼については、図１５で説明する。
【０１７３】
（受信処理の具体例）
図１２、図１４を参照して、ブロックデータ受信処理の具体例を説明する。ここで、サーバＳＶＲは、送信データＡＴＤから第１のブロックデータＢＬ１〜第１００のブロックデータＢＬ１００を作成する。そして、サーバＳＶＲは、第１、第２のブロックデータＢＬ１、ＢＬ２のマルチキャスト送信が終了し、第３のブロックデータＢＬ３を第１のクライアントＣＬ１〜第７のクライアントＣＬ７にマルチキャスト送信する。また、サーバＳＶＲは、第３のクライアントＣＬ３、第４のクライアントＣＬ４、第７のクライアントＣＬ７を代表クライアントとして決定している。
【０１７４】
サーバＳＶＲの送信データ管理部１３は、第３のブロックデータＢＬ３を例えば６４個のブロックに分割し、６４個の分割ブロックデータを作成する。送信データ管理部１３は、第３のブロックデータＢＬ３について、６４個の分割ブロックデータをそれぞれ１つずつ含む６４個のパケットを作成する。
【０１７５】
送信データ管理部１３は、６４個のパケットの制御データＣＴＲＬに、ブロックデータの総数"１０００"、分割ブロックデータの総数"６４"を含める。さらに、送信データ管理部１３は、６４個のパケットの代表クライアント番号ＢＬＮＭに代表クライアントＣＬ３、ＣＬ４、ＣＬ７ のクライアント番号(例えば"ＣＬ３"、"ＣＬ４"、"ＣＬ７")を含める。以下、６４個のパケットをそれぞれ第１のパケット〜第６４のパケットと適宜記す。
【０１７６】
送信データ管理部１３は、第１のパケット〜第６４のパケットの各々の分割ブロックデータ番号ＤＶＢＬＮＭに番号"１"〜"６４"を１つずつ含める。例えば、送信データ管理部１３は、第１のパケットの分割ブロックデータ番号ＤＶＢＬＮＭに"１"を含める。
【０１７７】
サーバＳＶＲの送受信部１４は、第３のブロックデータについて、第１のパケット〜第６４のパケットを順次マルチキャスト送信する。
【０１７８】
第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、サーバＳＶＲが送信した第１のパケット〜第６４のパケットを順次受信し、受信したパケットをＲＡＭ２０３に記憶する（図１４のＳ１０１）。図１２(Ｂ)の例では、送受信部２３は、パケットＰＣＫを受信し、ＲＡＭ２０３に記憶する。送受信部２３は、パケットＰＣＫの受信が失敗した場合、サーバＳＶＲに否定応答(ＮＡＣＫ：Ｎｅｇａｔｉｖｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ)を送信する。サーバＳＶＲの送受信部１４は、否定応答を受信すると、この否定応答に応答して、パケットＰＣＫの再送を行う。
【０１７９】
第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、受信したパケットの制御データＣＴＲＬに含まれる分割ブロックデータの総数分のブロックデータを正常に受信したか判定する（Ｓ１０２）。
【０１８０】
前記具体例の場合、送受信部２３は、第１のパケット〜第６４のパケットを全て正常に受信すると、ブロックデータを正常に受信したと判定する（Ｓ１０２/ＹＥＳ）。なお、ブロックデータに含まれる分割ブロックデータの総数(換言すれば、ブロックデータに含まれるパケットの総数)は、受信したパケットの制御データＣＴＲＬに含まれている。さらに、分割ブロックデータの番号は、受信したパケットの分割ブロックデータ番号ＤＶＢＬＮＭに含まれている。従って、送受信部２３は、この分割ブロックデータの総数、分割ブロックデータ番号ＤＶＢＬＮＭを参照すれば、ブロックデータを正常に受信したかを判定できる。
【０１８１】
第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、受信したパケットの制御データＣＴＲＬに含まれる分割ブロックデータの総数分(例えば、６４個)のブロックデータを受信する。すると、第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、これらの分割ブロックデータを１つのブロックデータとしてストレージ２０２の送信データ記憶領域ＴＲ２に記憶する（Ｓ１０３）。
【０１８２】
第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、自クライアントが代表クライアントか判定する（Ｓ１０４）。送受信部２３は、自端末内のストレージ２０２に記憶されているクライアント識別子と、受信したパケットの代表クライアント番号ＣＬＮＭに含まれる番号とが一致している場合、自クライアントが代表クライアントと判定する（Ｓ１０４/ＹＥＳ）。一方、送受信部２３は、自端末内のストレージ２０２に記憶されているクライアント識別子と代表クライアント番号ＣＬＮＭに含まれる番号とが一致していない場合、自クライアントが代表クライアントでないと判定する（Ｓ１０４/ＮＯ）。
【０１８３】
前記具体例の場合、代表クライアント番号ＣＬＮＭには、"ＣＬ３"、"ＣＬ４"、"ＣＬ７"が含まれている。従って、第３のクライアントＣＬ３、第４のクライアントＣＬ４、第７のクライアントＣＬ７が代表クライアント（ＣＬ３、ＣＬ４、ＣＬ７）である。
【０１８４】
代表クライアント（ＣＬ３、ＣＬ４、ＣＬ７）の送受信部２３は、自クライアントが代表クライアントと判定する（Ｓ１０４/ＹＥＳ）。代表クライアント（ＣＬ３、ＣＬ４、ＣＬ７）の送受信部２３は、受信した第３のブロックデータＢＬ３をＲＡＭ２０３のデータキャッシュ領域ＤＣＲに記憶する（Ｓ１０５）。そして、代表クライアント（ＣＬ３、ＣＬ４、ＣＬ７）の送受信部２３は、第３のブロックデータＢＬ３を正常に受信したことを示す応答確認をサーバＳＶＲに送信する（Ｓ１０６）。この応答確認は、応答確認を送信した代表クライアントのクライアント識別子と、第３のブロックデータＢＬ３の番号を含む。代表クライアント（ＣＬ３、ＣＬ４、ＣＬ７）の送受信部２３は、自端末のＲＡＭ２０３に受信した第３のブロックデータＢＬ３の番号(例えば、番号"３"または番号"ＢＬ３")を記憶する。
【０１８５】
サーバＳＶＲの送受信部１４は、３つの代表クライアント（ＣＬ３、ＣＬ４、ＣＬ７）から送信された応答確認を受信すると、第３のブロックデータの次の第４のブロックデータＢＬ４をマルチキャスト送信する(図１１のＳ３２)。
【０１８６】
第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、１００個のブロックデータを全て受信した場合、全ブロックデータを受信したと判定する（Ｓ１０７/ＹＥＳ）。一方、第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、１００個のブロックデータを全て受信していない場合、全ブロックデータを受信していないと判定する（Ｓ１０７/ＮＯ）。
【０１８７】
さて、第１のクライアントＣＬ１〜第７のクライアントＣＬ７の送受信部２３は、第１のパケット〜第６４のパケットを全て正常に受信していない場合、ブロックデータを正常に受信したと判定しない（Ｓ１０２/ＮＯ）。
【０１８８】
ブロックデータを正常受信しなかったクライアントの送受信部２３は、正常受信できなかったブロックデータの番号を含む、ブロックデータの送信を依頼する旨を示す送信依頼パケットをマルチキャスト送信する(Ｓ１０８)。正常受信できなかったブロックデータの番号は、換言すれば、送信依頼の対象となるブロックデータの番号である。
【０１８９】
前記具体例では、第３のブロックデータＢＬ３を正常受信できなかったクライアントがあるとする。第３のブロックデータＢＬ３を正常受信できなかったクライアントの送受信部２３は、第３のブロックデータＢＬ３の番号"３"(または番号"ＢＬ３")を含む送信依頼パケットをマルチキャスト送信する(Ｓ１０８)。
【０１９０】
サーバＳＶＲの送受信部１４は、送信依頼パケットを受信すると、送信依頼パケットに含まれる送信依頼の対象となるブロックデータの番号が、カレントブロックの番号の場合、このカレントブロックを再度、マルチキャスト送信する。カレントブロックは、サーバＳＶＲのＲＡＭ１０３のブロックデータ記憶領域ＢＲに記憶されている。さらに、カレントブロックの番号はＲＡＭ１０３に記憶されている。
【０１９１】
ブロックデータを正常受信しなかったクライアントの送受信部２３は、再送されたブロックデータ（正常受信できなかったブロックデータ）を正常受信すると、応答確認をサーバＳＶＲに送信する。この正常受信は、図１４のＳ１０２で説明した。この応答確認は、以前、正常受信できなかったブロックデータの番号を含む。前記具体例では、第３のブロックデータＢＬ３の番号"３"を含む。
【０１９２】
サーバＳＶＲの送受信部１４は、応答確認を受信すると、カレントブロックの再送を終了し、記憶していたカレントブロックを削除する。
【０１９３】
さて、サーバＳＶＲがブロックデータを順次マルチキャスト送信している過程において、クライアントＣＬは、カレントブロックよりも以前に送信されたブロックデータの受信に失敗することがある。
【０１９４】
(クライアントＣＬのブロックデータ送信処理)
前記具体例において、サーバＳＶＲが、第３のブロックデータＢＬ３をマルチキャスト送信している場合を想定する。このとき、第１のクライアントＣＬ１、第５のクライアントＣＬ５は、自端末のＲＡＭ２０３のデータキャッシュ領域ＤＣＲに第１のブロックデータＢＬ１をキャッシュしている。
【０１９５】
そして、第２のクライアントＣＬ２、第６のクライアントＣＬ６は、自端末のＲＡＭ２０３のデータキャッシュ領域ＤＣＲに第２のブロックデータＢＬ２をキャッシュしている。
【０１９６】
そして、第１、第２、第４〜第７のクライアント(ＣＬ１、ＣＬ２、ＣＬ４〜ＣＬ７)は、第１のブロックデータＢＬ１、第２のブロックデータＢＬ２を正常受信し、自端末のストレージ２０２に記憶している。しかし、第３のクライアントＣＬ３は、第１のブロックデータＢＬ１を正常受信したが、第２のブロックデータＢＬ２を正常受信していないとする。
【０１９７】
なお、かかる事態が生じるのは、サーバＳＶＲは、あるブロックデータの代表クライアントから応答確認を受信すれば、このブロックデータの送信を終了するからである。例えば、特定のクライアントの通信速度が低下している場合を想定する。かかる場合、第２のブロックデータＢＬ２の代表クライアントが、第２のブロックデータＢＬ２のブロックデータの受信を終了しても、この特定のクライアントが、この第２のブロックデータＢＬ２の受信ができない場合がある。特に、特定のクライアントが、無線ＬＡＮ通信によりネットワークＮＴ２(図２参照)に接続している場合、無線環境の悪化により、かかる事態が生じる可能性が高くなる。
【０１９８】
ここで、クライアントＣＬは、図１４のＳ１０１で説明したように、第ｓのブロックデータＢＬｓ(ｓは１〜ｑ(ｑは３以上の整数))を正常受信した後に、第(ｓ+１)のブロックデータＢＬ(ｓ+１)を受信する。そこで、第ｓのブロックデータＢＬｓを正常受信できないクライアントは、第(ｓ+１)のブロックデータＢＬ(ｓ+１)を受信する前に、第ｓのブロックデータＢＬｓの送信依頼を要求する送信依頼パケットをマルチキャスト送信する(Ｓ１０８)。なお、このクラインは、正常受信できなかった第ｓのブロックデータＢＬｓの番号(例えば、番号"ｓ"、番号"ＢＬｓ")を送信依頼パケットに含める。
【０１９９】
前記の具体例では、第３のクライアントＣＬ３は、正常受信できていない第２のブロックデータＢＬ２の送信依頼を行う。サーバＳＶＲ２は、第２のブロックデータＢＬ２の次の第３のブロックデータＢＬ３のマルチキャスト送信をしているので、第２のブロックデータＢＬ２については再送用にキャッシュしていない。そこで、第２のブロックデータＢＬ２をキャッシュしている第２のクライアントＣＬ２、第６のクライアントＣＬ６が、第２のブロックデータＢＬ２の送信依頼に応答する。
【０２００】
（クライアントＣＬのブロックデータ送信処理）
図１５は、クライアントＣＬのブロックデータ送信処理のフロー図である。クライアントＣＬは、ブロックデータの受信中や、ブロックデータの受信終了後、ブロックデータ送信要求の依頼待ち状態にある。
【０２０１】
ステップＳ１１１:クライアントＣＬの送受信部２３は、送信依頼パケットの受信待ち状態において、送信依頼パケットを受信する。送受信部２３は、受信した送信依頼パケットをＲＡＭ２０３に記憶する。
【０２０２】
ステップＳ１１２:クライアントＣＬの主管理部２１は、受信した送信依頼パケットを解析し、キャッシュしたブロックデータの継続送信依頼か判定する。なお、継続送信依頼は、ブロックデータの更なる送信要求であり、詳細については、図１５の後に、詳しく説明する。継続送信依頼の場合(Ｓ１１２/ＹＥＳ)、Ｓ１１５に移る。継続送信依頼でない場合(Ｓ１１２/ＮＯ)、Ｓ１１３に移る。
【０２０３】
ステップＳ１１３: クライアントＣＬの主管理部２１は、受信した送信依頼パケットを解析し、キャッシュしたブロックデータの送信依頼か判定する。
【０２０４】
キャッシュしたブロックデータの送信依頼でない場合(Ｓ１１３/ＮＯ)、Ｓ１１１に移る。キャッシュしたブロックデータの送信依頼の場合(Ｓ１１３/ＹＥＳ)、Ｓ１１４に移る。
【０２０５】
以後、継続送信依頼と判定(Ｓ１１２/ＹＥＳ)したクライアントＣＬや、キャッシュしたブロックデータの送信依頼と判定(Ｓ１１３/ＹＥＳ)したクライアントＣＬを送信用クライアントと適宜記す。
【０２０６】
ステップＳ１１４:送信用クライアントの送受信部２３は、キャッシュしたブロックデータの一部のデータを送信する。この一部データは、例えば、キャッシュしたブロックデータの一部のデータを含む第１のパケットである。
【０２０７】
ステップＳ１１５: 送信用クライアントの送受信部２３は、更に送信要求を受信すると(Ｓ１１２/ＹＥＳ)、キャッシュしたブロックデータにおける一部のデータ(Ｓ１１４参照)以外のデータの送信を継続する。この一部のデータは、送信用クライアントにキャッシュされたブロックデータの一部のデータである。Ｓ１１４の例では、送受信部２３は、キャッシュしたブロックデータの第１のパケット以降のパケットを送信する。第１のパケット以降のパケットは、第１のパケットに後続する第２のパケット又は第２のパケット以降のパケットである。
【０２０８】
送信用クライアントの送受信部２３は、キャッシュしたブロックデータの送信が終了し、応答確認を受信すると、Ｓ１１１に戻る。
【０２０９】
（送信処理の具体例）
図１２、図１５を参照して、クライアントのブロックデータ送信処理の具体例を説明する。この具体例の説明では、図１５の説明の前で示した具体例を例示する。すなわち、第３のクライアントＣＬ３は、正常受信できていない第２のブロックデータＢＬ２の送信依頼を行う。
【０２１０】
第３のクライアントＣＬ３は、第２のブロックデータＢＬ２の番号を含む、ブロックデータ送信の開始を依頼する旨を示す送信依頼パケットをマルチキャスト送信する。
【０２１１】
クライアントＣＬの送受信部２３は、送信依頼パケットを受信しＲＡＭ２０３に記憶する(Ｓ１１１)。クライアントＣＬの送受信部２３は、受信した送信依頼パケットを解析する(Ｓ１１２)。ここで、受信した送信依頼パケットは、ブロックデータの再送の開始を依頼する送信依頼パケットなので、継続送信依頼ではないと判定する(Ｓ１１２/ＮＯ)。
【０２１２】
クライアントＣＬの主管理部２１は、受信した送信依頼パケットを解析し、キャッシュしたブロックデータの送信依頼か判定する(Ｓ１１３)。受信した送信依頼パケットは、第２のブロックデータＢＬ２の番号を含む、ブロックデータ再送の開始を依頼するものである。
【０２１３】
クライアントＣＬの主管理部２１は、この第２のブロックデータＢＬ２をＲＡＭ２０３のデータキャッシュ領域ＤＣＲに記憶しているか判定する(Ｓ１１３)。受信した送信依頼パケットには、再送対象のブロックデータの番号(例えば、番号"２"または番号"ＢＬ２")が含まれている。クライアントＣＬのＲＡＭ２０３データキャッシュ領域ＤＣＲには、キャッシュしているブロックデータと共に、このブロックデータの番号も記憶されている。
【０２１４】
そのため、クライアントＣＬの主管理部２１は、受信した送信依頼パケットに含まれている第２のブロックデータＢＬ２の番号"ＢＬ２"がＲＡＭ２０３に記憶されている場合、キャッシュしたブロックデータの送信依頼と判定する。
【０２１５】
前記したように、第２のブロックデータＢＬ２をキャッシュしている代表クライアントは、第２のクライアントＣＬ２と、第６のクライアントＣＬ６とである。
【０２１６】
従って、第２のクライアントＣＬ２、第６のクライアントＣＬ６の主管理部２１は、キャッシュしたブロックデータの送信依頼と判定し(Ｓ１１３/ＹＥＳ)、Ｓ１１４に移る。
【０２１７】
一方、第１、第３〜第５、第７のクライアント(ＣＬ１、ＣＬ３〜ＣＬ５、ＣＬ７)の主管理部２１は、キャッシュしたブロックデータの送信依頼と判定せず(Ｓ１１３/ＮＯ)、Ｓ１１１に移る。
【０２１８】
第２のクライアントＣＬ２、第６のクライアントＣＬ６の送受信部２３は、キャッシュした第２のブロックデータＢＬ２の第１のパケットを作成し、第１のパケットをマルチキャストする(Ｓ１１４)。なお、送受信部２３は、第１のパケットを、送信依頼パケットを送信した第３のクライアントＣＬ３にユニキャスト送信してもよい。
【０２１９】
第２のクライアントＣＬ２、第６のクライアントＣＬ６の送受信部２３は、サーバＳＶＲの送受信部１４のように、ブロックデータをパケット単位で送信する(図１２(Ｂ)参照)。
【０２２０】
例えば、送信用クライアント(ＣＬ２、ＣＬ６)の送受信部２３は、第２のブロックデータＢＬ２の送信において、第２のブロックデータＢＬ２を例えば１キロバイト単位で分割し、６４個の分割ブロックデータを作成し、ＲＡＭ２０３に記憶する。６４個の分割ブロックデータは、第１〜第６４の分割ブロックデータである。
【０２２１】
送信用クライアント(ＣＬ２、ＣＬ６)の送受信部２３は、各分割ブロックデータを識別する分割ブロックデータ番号を、各ブロックデータに割り振る。そして、送信用クライアント(ＣＬ２、ＣＬ６)の送受信部２３は、各分割ブロックデータと、各分割ブロックデータの分割ブロックデータ番号とを対応付けてＲＡＭ２０３に記憶する。
【０２２２】
送信用クライアント(ＣＬ２、ＣＬ６)の送受信部２３は、分割ブロックデータを含むパケットを作成し、ＲＡＭ２０３に記憶する。パケットは、制御データと、ブロックデータ番号と、分割ブロックデータ番号と、分割ブロックデータとを有する。
【０２２３】
制御データは、送信元のクライアントのＩＰアドレス、分割ブロックデータの総数(例えば、６４)を含む。ブロックデータ番号は、送信対象のブロックデータ(キャッシュしているブロックデータ)の番号を含む。分割ブロックデータ番号は、分割ブロックデータに割り振られた分割ブロックデータ番号を含む。分割ブロックデータは、送信対象の分割ブロックデータであり、いわゆるペイロードである。
【０２２４】
送信用クライアント(ＣＬ２、ＣＬ６)の送受信部２３は、第２のブロックデータＢＬ２を送信するにあたり、最初の分割ブロックデータである第１の分割ブロックデータを含む第１のパケットを送信する。この最初の分割ブロックデータは、例えば、キャッシュしているブロックデータの先頭アドレスで示されるブロックデータの一部(例えば、１キロバイト分)である。
【０２２５】
なお、このパケットの制御データは、分割ブロックデータの総数"６４"、分割ブロックデータ番号"１"を含む。
【０２２６】
送信用クライアント（ＣＬ２、ＣＬ６）の送受信部２３は、第２のブロックデータＢＬ２の第１のパケットをマルチキャスト送信する。
【０２２７】
すなわち、複数のクライアント群各々に含まれる複数のクライアント各々は、要求を受信した代表クライアントとして機能する場合、第Ｎのブロックデータの一部のデータを前記要求したクライアントに送信する。なお、この要求は、例えば、送信依頼パケットにより行われる。
【０２２８】
第２のブロックデータＢＬ２の再送の開始を依頼する旨を示す送信依頼パケットを送信した第３のクライアントＣＬ３の送受信部２３は、送信用クライアント（ＣＬ２、ＣＬ６）から送信された第２のブロックデータＢＬ２の第１のパケットを受信する。
【０２２９】
第３のクライアントＣＬ３の送受信部２３は、受信した第１のパケットをＲＡＭ２０３に記憶する。そして、送受信部２３は、最初に受信した第１のパケットの制御データに含まれる送信元ＩＰアドレスが設定されているクライアントに、第２のブロックデータＢＬ２の継続送信を依頼する旨を示す送信依頼パケットを送信する。最初に受信した第１のパケットの制御データに含まれる送信元ＩＰアドレスが設定されているクライアントは、第３のクライアントＣＬ３が最初に受信した一部のデータ(例えば、第１のパケット)を送信したクライアントである。
【０２３０】
第３のクライアントＣＬ３の送受信部２３は、例えば、第２のクライアントＣＬ２に、第２のブロックデータＢＬ２の継続送信を依頼する旨を示す送信依頼パケット（以下、継続送信依頼パケットと記す）を送信する。
【０２３１】
すなわち、複数のクライアント各々は、複数の代表クライアントから一部のデータを受信したクライアントとして機能する場合、以下の処理を実行する。すなわち、このクライアントは、最初に受信した一部のデータを送信した代表クライアントに、第Ｎのブロックデータにおける一部のデータ以外のデータの送信を要求する。この要求は、例えば、継続送信依頼パケットにより行われる。
【０２３２】
このように、最初に受信した第１のパケットの制御データに含まれる送信元ＩＰアドレスが設定されているクライアントに継続依頼を行う理由を説明する。この理由は、２つ以上の送信用クライアント（ＣＬ２、ＣＬ６）から第２のブロックデータＢＬ２が送信されるので、何れか１つの送信用クライアントから第２のブロックデータＢＬ２を受信するためである。すなわち、２つ以上の送信用クライアントが重複して、同じ再送用のブロックデータを継続して送信しないようにするためである。
【０２３３】
第２のクライアントＣＬ２の送受信部２３は、継続送信依頼パケットを受信し、ＲＡＭ２０３に記憶すると（Ｓ１１１）、受信した送信依頼パケットを解析する(Ｓ１１２)。ここで、受信した継続送信依頼パケットは、ブロックデータの送信の継続を依頼する継続送信依頼パケットなので、第２のクライアントＣＬ２の送受信部２３は、継続送信依頼と判定する(Ｓ１１２/ＹＥＳ)。
【０２３４】
第２のクライアントＣＬ２の送受信部２３は、第２〜第６４の分割ブロックデータをそれぞれ含む第２のパケット〜第６４のパケットを作成し、順次、第３のクライアントＣＬ３に送信する。すなわち、複数のクライアント群各々に含まれる複数のクライアント各々は、一部のデータ以外のデータの送信の要求を受信した代表クライアントとして機能する場合、第Ｎのブロックデータにおける一部のデータ以外のデータの送信を継続する。なお、第２のクライアントＣＬ２の送受信部２３は、第２のパケット〜第６４のパケットを順次マルチキャスト送信してもよい。
【０２３５】
送信依頼を行っていないクライアントの送受信部２３は、再送されたブロックデータのパケットを受信した場合、受信したパケットを破棄する。
【０２３６】
以上説明したように、本実施の形態のサーバは、同じブロックデータを、複数のグループの各々に属するクライアントにキャッシュさせている。すなわち、代表クライアントが持つブロックデータのキャッシュ各々を、クライアント群毎に分散させている。そのため、本実施の形態においては、他のクライアントからのブロックデータの送信依頼に応答できるクライアントが複数のグループの各々に少なくとも１台存在する。
【０２３７】
従って、ブロックデータをキャッシュしている第１のクライアントが、何らかの理由により、通信ができなくなっても、このブロックデータをキャッシュしている第２のクライアントが、他のクライアントからのブロックデータの送信依頼に応答できる。
【０２３８】
そのため、クライアントは、既にサーバがキャッシュしていないブロックデータの受信に失敗しても、他のクライアントにこのブロックデータの送信を依頼すれば、少なくとも１台のクライアントが、この依頼に応答する。その結果、このクライアントは、既にサーバがキャッシュしていないブロックデータの受信に失敗しても、改めて、このブロックデータを受信できる。すなわち、クライアントは、サーバから送信された送信データを他のクライアントから確実に受信することができる。
【０２３９】
さらに、図１で説明した前記手法では、全てのクライアントが１つのグループで管理され、全てのクライアントの中から、代表クライアントがラウンドロビン方式により順次決定されている。例えば、全てのクライアントの台数が７台である場合を想定する。この場合、前記手法では、第１〜第７のクライアントが、相互に異なるブロックデータをそれぞれキャッシュする。例えば、第１のクライアントが第１のブロックデータをキャッシュし、第７のクライアントが第７のブロックデータをキャッシュする。
【０２４０】
ここで、第７のクライアントは、第７のブロックデータを受信するまでに、第１〜第６のブロックデータを受信し自端末に記憶する必要がある。従って、第７のクライアントは、第１〜第６のブロックデータの受信が失敗した場合、かかるブロックデータの送信依頼を各クライアントに行うことがある。その結果、再送が発生する可能性があるデータ量は、"６"(=７-１)にブロックデータを乗算したデータ量になる。すなわち、前記手法では、再送が発生する可能性のあるデータ量は、"全クライアントの台数−１"にブロックデータ量を乗算したデータ量になることがある。
【０２４１】
本実施の形態では、複数のクライアントを複数のグループに分け、複数のグループの各々のクライアントの中から、複数のグループの各々を代表する代表クライアントがラウンドロビン方式により順次決定されている。本実施の形態のサーバＳＶＲは、第１〜第７のクライアントを、第１のグループＧ１(図１３参照)と、第２のグループＧ２(図１３参照)で管理している。そのため、再送が発生する可能性があるデータ量は、最大で、"３" (=４-１)にブロックデータを乗算したデータ量になることがある。
【０２４２】
すなわち、本実施の形態では、再送が発生する可能性のあるデータ量は、"グループに属するクライアントの最大台数−１"にブロックデータ量を乗算したデータ量になることがある。
【０２４３】
以上説明したように、サーバが、同じ数のクライアントにブロックデータを送信する場合、前記手法よりも本実施の形態の方が、再送が発生する可能性があるデータ量を少なくできる。その結果、本実施の形態によれば、ブロックデータの再送によるデータ通信量の増大を抑圧できる。
【０２４４】
特に、ネットワーク環境が劣化しているなど再送処理が発生しやすい環境では、再送要求が多発する。かかる環境下でも、本実施の形態によれば、再送が発生する可能性があるデータ量を少なくできる。また、クライアントの数が、多数(例えば、数百台、数千台)の場合には、前記手法では、再送が発生する可能性のあるデータ量が、多量になるが、本実施の形態では、このデータ量を抑制できる。
【０２４５】
[クライアントの消去処理、リスト調整処理]
次に、キャンセル要求を行ったクライアントの消去処理（図７のＳ５）、応答確認を送信しないクライアントの消去処理(図７のＳ６)について説明する。
【０２４６】
(キャンセル要求)
例えば、サーバＳＶＲから送信データＡＴＤを受信している何れかのクライアントＣＬが、この受信をキャンセルする場合がある。かかる場合、このクライアントは、送信データの受信を取り消す要求(以下、キャンセル要求と適宜記す) をサーバＳＶＲに送信する。このクライアントは、自クライアントの番号を含むキャンセル要求をサーバＳＶＲに送信する。
【０２４７】
サーバＳＶＲの送受信部１４は、キャンセル要求を受信すると、主管理部１１は、キャンセル要求を送信したクライアントを受信不可のクライアントとして検出する。次いで、１１は、キャンセル要求を行ったクライアントの消去処理を行う(Ｓ５)。例えば、主管理部１１は、ＲＡＭ１０３のリスト記憶領域ＬＲに記憶されたクライアントの中から、受信したキャンセル要求のクライアント番号を含む行を更新する更新指示をリスト管理部１５に行う。
【０２４８】
主管理部１１は、カレントブロックの応答確認が送受信部１４により受信された後、次のブロックデータが送受信部１４により送信される前に、この更新指示を行う。
【０２４９】
(応答確認の不送信)
また、サーバＳＶＲから送信データＡＴＤを受信しているクライアントが、何らかの原因で通信が不能になり、応答確認をサーバＳＶＲに送信できない場合がある。この原因とは、例えば、このクライアントが故障した場合や、このクライアントの通信装置２０５とネットワークＮＴ２(図２参照)とを接続しているＬＡＮケーブルが断線した場合である。以下、通信が不能になったクライアントを通信不能クライアントと適宜記す。
【０２５０】
送受信部１４は、ブロックデータを送信してから所定の時間内に、このブロックデータついての応答確認を代表クライアントから受信しなかった場合、この代表クライアントを受信不可のクライアントとして検出する。この受信不可のクライアントは、通信不能クライアントである。
【０２５１】
サーバＳＶＲの主管理部１１が決定した代表クライアントが、通信不能クライアントの場合、送受信部１４は、通信不能クライアントから応答確認を受信することができない。そのため、送受信部１４が、カレントブロックの送信が終了してから、所定の時間が経過しても、応答確認を受信できない場合、主管理部１１は、この通信不能クライアントの消去処理を行う(Ｓ６)。送信データ管理部１３は、カレントブロックの代表クライアントのクライアント番号をＲＡＭ１０３に記憶している。
【０２５２】
例えば、主管理部１１は、ＲＡＭ１０３のリスト記憶領域ＬＲに記憶されたクライアントの中から、通信不能クライアントのクライアント番号を含む行を更新する更新指示をリスト管理部１５に行う。
【０２５３】
[クライアントリストの調整]
リスト管理部１５は、主管理部１１から更新指示を受けると、クライアントリストの調整(図７のＳ７)を行う。以下の説明において、キャンセル要求を送信したクライアントや、通信不能クライアントを受信不可のクライアントと適宜記す。
【０２５４】
図１６は、図７のクライアントリストの調整(Ｓ７)を説明するフロー図である。
【０２５５】
ステップＳ７１: リスト管理部１５は、クライアントリストの重複フラグ欄から重複クライアントのクライアント番号を検出する。具体的には、リスト管理部１５は、重複フラグ欄において、"０"以外のクライアント番号を検出する。
【０２５６】
ステップＳ７２:リスト管理部１５は、クライアント番号を検出できたか判定する。検出できない場合(Ｓ７２/ＮＯ)、Ｓ７６に移る。検出できた場合(Ｓ７２/ＹＥＳ)、Ｓ７３に移る。
【０２５７】
ここで、リスト管理部１５は、１つのクライアントリストの重複フラグ欄に記憶された値（クライアント番号）が全て"０"の場合に、クライアント番号を検出できないと判定する(Ｓ７２/ＮＯ)。一方、リスト管理部１５は、１つのクライアントリストの重複フラグ欄に、"０"以外のクライアント番号が記憶されている場合に、クライアント番号を検出できたと判定する(Ｓ７２/ＹＥＳ)。
【０２５８】
ステップＳ７３:リスト管理部１５は、最初に検出したクライアント番号のクライアントを代替クライアントと決定し、代替クライアントに、受信不可のクライアントの代わりにブロックデータのキャッシュを実行させる。代替クライアントは、受信不可のクライアントの代わりにブロックデータのキャッシュを実行するクライアントである。換言すれば、リスト管理部１５は、代替クライアントに、受信不可のクライアントがキャッシュしているブロックデータを取得させる。
【０２５９】
ステップＳ７４: リスト管理部１５は、受信不可のクライアントと代替クライアントをクライアントリストに反映する。
【０２６０】
ステップＳ７５:リスト管理部１５は、複数のクライアントリストの各々におけるクライアントのクライアント番号(換言すれば、クライアント識別子)の総数が同じか判定する。このクライアントの番号の総数が同じ場合(Ｓ７５/ＹＥＳ)、クライアントリストの調整処理を終了する。このクライアントの番号の総数が異なる場合(Ｓ７５/ＮＯ)、Ｓ７８に移る。
【０２６１】
ステップＳ７６：リスト管理部１５は、受信不可のクライアントを含むクライアントリストの中から、カレントブロックの次のブロックデータの代表クライアントを代替クライアントと決定する。換言すれば、リスト管理部１５は、受信不可のクライアントと同じグループのクライアント群の中から、カレントブロックの次のブロックデータの代表クライアントを代替クライアントと決定する。
【０２６２】
そして、リスト管理部１５は、代替クライアントに、受信不可のクライアントの代わりにブロックデータのキャッシュを実行させる。
【０２６３】
ステップＳ７７：リスト管理部１５は、受信不可のクライアントを含むクライアントリストから受信不可のクライアントを消去し、代表クライアントの重複処理を実行する。
【０２６４】
ステップＳ７８:リスト管理部１５は、前記した代表クライアントの重複処理を実行する。
【０２６５】
(クライアントリストの調整の第１の具体例)
以下、図９、図１０、図１３、図１６、図１７を参照し、クライアントリストの調整の第１の具体例を説明する。
【０２６６】
サーバＳＶＲの送受信部１４は、図１３で説明したように、第１のブロックデータＢＬ１〜第ｑ(ｑは３以上の整数)のブロックデータをマルチキャスト送信する。送受信部１４は、このマルチキャスト送信において、例えば、第３のブロックデータＢＬ３を送信中に、第２のクライアントＣＬ２がキャンセル要求を実行したとする。この場合、第２のクライアントＣＬ２が受信不可のクライアントである。
【０２６７】
主管理部１１は、送信中のブロックデータ(カレントブロック)の応答確認を受信すると、図９、図１０のクライアントリストの中から、受信したキャンセル要求のクライアント番号を含む行を更新する更新指示をリスト管理部１５に行う。
【０２６８】
リスト管理部１５は、更新指示に応答し、クライアントリストの重複フラグ欄からクライアント番号を検出する(Ｓ７１)。具体的には、リスト管理部１５は、図９のクライアントリストＬＳＴ１ａの重複フラグ欄における最上部の行から重複フラグを検索する(Ｓ７１)。
【０２６９】
リスト管理部１５は、図９のクライアントリストＬＳＴ１ａの重複フラグ欄から、重複フラグ"ＣＬ４"を検索するので(Ｓ７２/ＹＥＳ)、Ｓ７３に移る。リスト管理部１５は、最初に検索したクライアント番号ＣＬ４の第４のクライアントＣＬ４に受信不可のクライアント(第２のクライアントＣＬ２)の代わりに、ブロックデータのキャッシュ処理を実行させる。具体的には、送受信部１４は、第２のクライアントＣＬ２がキャッシュするブロックデータの番号を含むキャッシュ指示パケットを第４のクライアントＣＬ４に送信する。第２のクライアントＣＬ２がキャッシュするブロックデータは、前記の例では、第２のブロックデータＢＬ２であり、この番号は、例えば"２"または"ＢＬ２"である。
【０２７０】
第４のクライアントＣＬ４の送受信部２３は、キャッシュ指示パケットを受信する。送受信部２３は、第２のクライアントＣＬ２がキャッシュする第２のブロックデータＢＬ２の番号"ＢＬ２"を含む、ブロックデータの送信を依頼する旨を示す送信依頼パケットをマルチキャスト送信する。なお、このマルチキャスト送信は、図１４のＳ１０８と同様の処理である。
【０２７１】
第２のブロックデータＢＬ２をキャッシュしている第６のクライアントＣＬ６は、図１５で説明したように、キャッシュした第２のブロックデータの送信処理を実行する。この送信処理により、第４のクライアントＣＬ４の送受信部２３は、第２のブロックデータＢＬ２を受信し、ＲＡＭ２０３のデータキャッシュ領域ＲＣＲに第２のブロックデータＢＬ２をキャッシュする。第４のクライアントＣＬ４の送受信部２３は、キャッシュ指示の対象となるブロックデータ(前記の例では、第２のブロックデータＢＬ２)よりも前のブロックデータを受信していない場合は、以下の処理を行う。すなわち、第４のクライアントＣＬ４の送受信部２３は、前記した送信依頼パケットを送信する前に、前記した前のブロックデータの送信依頼を行う。
【０２７２】
また、リスト管理部１５は、受信不可の第２のクライアントＣＬ２の行の内容を図９のクライアントリストＬＳＴ１ａから消去し、この行に、代替クライアント(第４のクライアントＣＬ４)の行の内容を追加する(Ｓ７４)。すなわち、リスト管理部１５は、受信不可の第２のクライアントＣＬ２の行に、代替クライアント(第４のクライアントＣＬ４)の行を移動する。
【０２７３】
図１７は、図９の受信不可の第２のクライアントＣＬ２の行に、代替クライアント(第４のクライアントＣＬ４)の行を移動したリストを示した図である。
【０２７４】
リスト管理部１５は、図１７の符号ＬＮ１に示すように、図９の受信不可の第２のクライアントＣＬ２の行に、第４のクライアントＣＬ４の行を移動する。リスト管理部１５は、Ｓ７４の処理により、図９のクライアントリストＬＳＴ１ａを、図１７のクライアントリストＬＳＴ１ｃに更新する。
【０２７５】
リスト管理部１５は、複数のクライアントリスト(ＬＳＴ１ｂ、ＬＳＴ１ｃ)の各々におけるクライアントの番号の総数が同じか判定する。図９、図１７の例では、クライアントリストＬＳＴ１ｃのクライアント番号の総数は"３"(ＣＬ１、ＣＬ３、ＣＬ４の３個)、クライアントリストＬＳＴ１ｂのクライアント番号の総数は"３"(ＣＬ５、ＣＬ６、ＣＬ７の３個)である。従って、リスト管理部１５は、複数のクライアントリスト(ＬＳＴ１ｂ、ＬＳＴ１ｃ)の各々におけるクライアントの番号の総数が同じと判定する(Ｓ７５/ＹＥＳ)。そして、リスト管理部１５は、クライアントリストの調整処理を終了する。
【０２７６】
以上説明したように、主管理部１１は、ブロックデータを受信しない受信不可のクライアントを検出する。すると、送受信部１４は、受信不可のクライアントが含まれる第１のグループに含まれる他のクライアントに、以下の指示を行う。すなわち、送受信部１４は、他のクライアントに、受信不可のクライアントが記憶しているブロックデータを送信するように第１のグループとは別の第２のグループの代表クライアントに依頼するように指示する。さらに、送受信部１４は、この他のクライアントに、この依頼に応答してこの２のグループの代表クライアントから送信された、ブロックデータを記憶するように指示する。送受信部１４は、これらの指示を、例えば、キャッシュ指示パケットにより行う。
【０２７７】
前記の具体例では、受信不可のクライアントは、第２のクライアントＣＬ２であり、受信不可のクライアントが含まれる第１のグループはグループＧ１である。第１のグループに含まれる他のクライアントは、第４のクライアントＣＬ４である。そして、別の第２のグループの代表クライアントは、第６のクライアントＣＬ６である。
【０２７８】
次いで、リスト管理部１５は、各グループに含まれる代表クライアントを登録しているリストにおいて、受信不可のクライアントが登録されている位置にこの他のクライアントを移動させて、他のクライアントを第１のグループの代表クライアントとする。前記の具体例では、リスト管理部１５は、図９のクライアントリストＬＳＴ１ａにおいて、受信不可の第２のクライアントＣＬ２が登録されている位置(図９の例では行)に、前記した１の代表クライアントＣＬ４を移動する。
【０２７９】
(クライアントリストの調整の第２の具体例)
以下、図９、図１０、図１３、図１６、図１８、図１９を参照し、クライアントリストの調整の第２の具体例を説明する。
【０２８０】
サーバＳＶＲの送受信部１４は、図１３で説明したように、第１のブロックデータＢＬ１〜第ｑ(ｑは３以上の整数)のブロックデータをマルチキャスト送信する。
【０２８１】
送受信部１４は、クライアントリストの調整の第１の具体例で説明したように、このマルチキャスト送信において、例えば、第３のブロックデータＢＬ３を送信中に、第６のクライアントＣＬ６がキャンセル要求を実行したとする。この場合、第６のクライアントＣＬ６が受信不可のクライアントである。
【０２８２】
主管理部１１は、クライアントリストの調整の第１の具体例で説明したように、更新指示をリスト管理部１５に行う。
【０２８３】
リスト管理部１５は、図９のクライアントリストＬＳＴ１ａの重複フラグ欄における最上部の行から重複フラグを検索する(Ｓ７１)。
【０２８４】
リスト管理部１５は、図９のクライアントリストＬＳＴ１ａの重複フラグ欄から、重複フラグ"ＣＬ４"を検索するので(Ｓ７２/ＹＥＳ)、Ｓ７３に移る。リスト管理部１５は、最初に検索したクライアント番号ＣＬ４の第４のクライアントＣＬ４に受信不可のクライアント(第６のクライアントＣＬ６)の代わりに、ブロックデータのキャッシュ処理を実行させる。具体的には、送受信部１４は、第６のクライアントＣＬ６がキャッシュするブロックデータの番号を含むキャッシュ指示パケットを第４のクライアントＣＬ４に送信する。第６のクライアントＣＬ６がキャッシュするブロックデータは、前記の例では、第２のブロックデータＢＬ２であり、この番号は、例えば"２"または"ＢＬ２"である。
【０２８５】
第４のクライアントＣＬ４の送受信部２３は、キャッシュ指示パケットを受信する。送受信部２３は、第６のクライアントＣＬ６がキャッシュする第２のブロックデータＢＬ２の番号"ＢＬ２"を含む、ブロックデータの送信を依頼する旨を示す送信依頼パケットをマルチキャスト送信する。なお、このマルチキャスト送信は、図１４のＳ１０８と同様の処理である。
【０２８６】
第２のブロックデータＢＬ２をキャッシュしている第２のクライアントＣＬ２は、図１５で説明したように、キャッシュした第２のブロックデータの送信処理を実行する。この送信処理により、第４のクライアントＣＬ４の送受信部２３は、第２のブロックデータＢＬ２を受信し、ＲＡＭ２０３のデータキャッシュ領域ＲＣＲに第２のブロックデータＢＬ２をキャッシュする。第４のクライアントＣＬ４の送受信部２３は、キャッシュ指示の対象となるブロックデータ(前記の例では、第２のブロックデータＢＬ２)よりも前のブロックデータを受信していない場合、前記前のブロックデータの送信依頼を行う。
【０２８７】
また、リスト管理部１５は、受信不可の第６のクライアントＣＬ６の行の内容を図１０のクライアントリストＬＳＴ１ｂから消去し、この行に、代替クライアント(第４のクライアントＣＬ４)の行の内容を追加する(Ｓ７４)。すなわち、リスト管理部１５は、受信不可の第６のクライアントＣＬ６の行に、代替クライアント(第４のクライアントＣＬ４)の行を移動する。
【０２８８】
図１８は、図１０の受信不可の第６のクライアントＣＬ６の行に、代替クライアント(第４のクライアントＣＬ４)の行を移動したリストを示した図である。
【０２８９】
リスト管理部１５は、図１８の符号ＬＮ２に示すように、図１０の受信不可の第６のクライアントＣＬ６の行に、第４のクライアントＣＬ４の行を移動する(Ｓ７４)。すなわち、リスト管理部１５は、図１０のクライアントリストＬＳＴ１ｂを、図１８のクライアントリストＬＳＴ１ｄに更新する(Ｓ７４)。
【０２９０】
さらに、リスト管理部１５は、代替クライアント(第４のクライアントＣＬ４)の行の内容を図９のクライアントリストＬＳＴ１ａから消去し、この行自体を消去する(Ｓ７４)。
【０２９１】
図１９は、図９の代替クライアント(第４のクライアントＣＬ４)の行を図９のクライアントリストＬＳＴ１ａから消去したリストを示した図である。
【０２９２】
リスト管理部１５は、図９のクライアントリストＬＳＴ１ａを、図１９のクライアントリストＬＳＴ１ｅに更新する(Ｓ７４)。なお、図１９のクライアントリストＬＳＴ１ｅにおいては、重複クライアントはない。そこで、リスト管理部１５は、第３のクライアントＣＬ３のクライアント番号ＣＬ３を含む行と、重複フラグ欄とを交わるセルに"０"を登録する。
【０２９３】
リスト管理部１５は、複数のクライアントリスト(ＬＳＴ１ｄ、ＬＳＴ１ｅ)の各々におけるクライアントの番号の総数が同じか判定する。図１８、図１９の例では、クライアントリストＬＳＴ１ｄのクライアント番号の総数は"３"(ＣＬ５、ＣＬ６、ＣＬ７の３個)、クライアントリストＬＳＴ１ｅのクライアント番号の総数は"３"(ＣＬ１、ＣＬ２、ＣＬ３の３個)である。従って、リスト管理部１５は、複数のクライアントリスト(ＬＳＴ１ｄ、ＬＳＴ１ｅ)の各々におけるクライアントの番号の総数が同じと判定する(Ｓ７５/ＹＥＳ)。そして、リスト管理部１５は、クライアントリストの調整処理を終了する。
【０２９４】
主管理部１１は、ブロックデータを受信しない受信不可のクライアントを検出する。すると、送受信部１４は、受信不可のクライアントが含まれる第１のグループとは異なる第２のグループに含まれる他のクライアントに、以下の指示を行う。すなわち、送受信部１４は、この他のクライアントに、受信不可のクライアントが記憶しているブロックデータを送信するように第２のグループの代表クライアントに依頼するように指示する。さらに、送受信部１４は、他のクライアントに、この依頼に応答して、第２のグループの代表クライアントから送信された、ブロックデータを記憶するように指示する。送受信部１４は、これらの指示を、キャッシュ指示パケットにより行う。
【０２９５】
前記の具体例では、受信不可のクライアントは、第６のクライアントＣＬ６であり、受信不可のクライアントが含まれる第１のグループは、グループＧ２であり、第１のグループとは異なる第２のグループは、グループＧ１である。そして、第２のグループに含まれる他のクライアントは、第４のクライアントＣＬ４であり、第２のグループの代表クライアントは、第２のクライアントＣＬ２である。
【０２９６】
リスト管理部１５は、各グループに含まれる代表クライアントを登録しているリストにおいて、受信不可のクライアントが登録されている位置に他のクライアントを移動させて、他のクライアントを第１のグループの代表クライアントとする。
【０２９７】
前記の具体例では、リスト管理部１５は、クライアントリストＬＳＴ１ａから第４のクライアントＣＬ４を削除する。そして、リスト管理部１５は、受信不可のクライアントＣＬ６が登録されている図１０のクライアントリストＬＳＴ１ｂにおいて、受信不可のクライアントＣＬ６が登録されている位置に他のクライアントＣＬ４を移動する。
【０２９８】
(クライアントリストの調整の第３の具体例)
図２０〜図２４を参照し、クライアントリストの調整の第３の具体例を説明する。以下の説明において、図２におけるクライアントは、第１のクライアントＣＬ１〜第８のクライアントＣＬ８であるとする。すなわち、サーバＳＶＲは、第１のクライアントＣＬ１〜第８のクライアントＣＬ８に送信データＡＴＤをマルチキャスト送信する。
【０２９９】
サーバＳＶＲのリスト管理部１５は、第１のクライアントＣＬ１〜第８のクライアントＣＬ８の各々から送信された属性情報を受信し、属性情報リストＬＳＴ２を作成する。
【０３００】
図２０は、属性情報リストＬＳＴ２を示す図である。属性情報リストＬＳＴ２は、図８の属性情報リストＬＳＴ１に、第８のクライアントＣＬ８の属性情報を追加した属性情報リストである。
【０３０１】
リスト管理部１５は、第１のクライアントＣＬ１〜第８のクライアントＣＬ８を２つのグループに分割し、各グループのクライアントを含むクライアントリストを作成する(図７のＳ２)。
【０３０２】
リスト管理部１５は、第１のクライアントＣＬ１〜第８のクライアントＣＬ８を、２つのグループに分割する。以下、２つのグループの中で、第１のグループをグループＧ１１と適宜記し、第２のグループをグループＧ１２と適宜記す。グループＧ１１は、第１のクライアントＣＬ１〜第４のクライアントＣＬ４を含むグループである。グループＧ１２は、第５のクライアントＣＬ５〜第８のクライアントＣＬ８を含むグループである。
【０３０３】
図２１は、第１のクライアントＣＬ１〜第４のクライアントＣＬ４のグループＧ１１のクライアントリストＬＳＴ２１ａの図である。図２２は、第５のクライアントＣＬ５〜第８のクライアントＣＬ８を含むグループＧ１２のクライアントリストＬＳＴ２１ｂの図である。
【０３０４】
ここで、２つのグループＧ１１、Ｇ１２の各々に含まれるクライアントの数("４")は、同数なので、リスト管理部１５は、代表クライアントの重複処理を実行しない。すなわち、図２１、図２２のクライアントリストにおける重複フラグ欄には、クライアント番号が登録されない。
【０３０５】
ここで、図１３で説明したように、リスト管理部１５は、異なるグループのクライアントが同じブロックデータをキャッシュできるように、各グループのクライアントの中からラウンドロビン方式により代表クライアントを決定する。
【０３０６】
具体的には、リスト管理部１５は、第(４ｔ+１)(ｔは０以上の整数)のブロックデータＢＬ(４ｔ+１)の代表クライアントを第１のクライアントＣＬ１、第５のクライアントＣＬ５と決定する。なお、"(４ｔ+１)"は、"４"と"ｔ"とを乗算し、乗算値に"１"を加算した値を示す。
【０３０７】
そして、リスト管理部１５は、第(４ｔ+２)のブロックデータＢＬ(４ｔ+２)の代表クライアントを第２のクライアントＣＬ２、第６のクライアントＣＬ６と決定する。なお、"(４ｔ+２)"は、"４"と"ｔ"とを乗算し、乗算値に"２"を加算した値を示す。
【０３０８】
そして、リスト管理部１５は、第(４ｔ+３)のブロックデータＢＬ(４ｔ+３)の代表クライアントを第３のクライアントＣＬ３、第７のクライアントＣＬ７と決定する。なお、"(４ｔ+３)"は、"４"と"ｔ"とを乗算し、乗算値に"３"を加算した値を示す。
【０３０９】
そして、リスト管理部１５は、第(４ｔ+４)のブロックデータＢＬ(４ｔ+４)の代表クライアントを第４のクライアントＣＬ４、第８のクライアントＣＬ８と決定する。なお、"(４ｔ+４)"は、"４"と"ｔ"とを乗算し、乗算値に"４"を加算した値を示す。
【０３１０】
サーバＳＶＲの送受信部１４は、図１３で説明したように、第１のブロックデータＢＬ１〜第ｑ(ｑは３以上の整数)のブロックデータをマルチキャスト送信する。すると、サーバＳＶＲの送受信部１４は、図９、図１０で説明したように、図２１、図２１のクライアントリストを更新する。
【０３１１】
図２１、図２２の例では、"ｔ"が０の場合における、応答ブロック番号欄の更新について図示している。図２１、図２２において、クライアント番号ＣＬ１、ＣＬ５に対応する応答ブロック番号"１"が更新される。次いで、クライアント番号ＣＬ２、ＣＬ６に対応する応答ブロック番号"２"が更新される。次いで、クライアント番号ＣＬ３、ＣＬ７に対応する応答ブロック番号"３"が更新される。次いで、クライアント番号ＣＬ４、ＣＬ８に対応する応答ブロック番号"４"が更新される。
【０３１２】
送受信部１４は、このマルチキャスト送信において、第２のブロックデータＢＬ２を送信中に、例えば第２のクライアントＣＬ２がキャンセル要求を実行したとする。この場合、第２のクライアントＣＬ２が受信不可のクライアントである。この場合、図７のＳ５の処理を経て、クライアントリストの調整処理(図１６のＳ７１以下)が実行される。
【０３１３】
主管理部１１は、送信中のブロックデータ(カレントブロック)の応答確認を受信すると、図２１、図２２のクライアントリストの中から、受信したキャンセル要求のクライアント番号を含む行を更新する更新指示をリスト管理部１５に行う。
【０３１４】
図２１、図２２で説明したように、図２１、図２２のクライアントリストの重複フラグ欄には、クライアント番号が登録されていない。従って、リスト管理部１５は、クライアント番号を検出できないと判定(Ｓ７２/ＮＯ)する。
【０３１５】
そして、リスト管理部１５は、受信不可の第２のクライアントＣＬ２を含むクライアントリストＬＳＴ２１ａの中から、カレントブロックの次のブロックデータの代表クライアントを代替クライアントと決定する(Ｓ７６)。なお、カレントブロックは、第２のブロックデーデータＢＬ２であり、次のブロックデータは、第３のブロックデータＢＬ３である。第３のブロックデータＢＬ３の代表クライアント(代替クライアント)は、第３のクライアントＣＬ３である。
【０３１６】
そして、リスト管理部１５は、第３のクライアントＣＬ３に、受信不可の第２のクライアントＣＬ２の代わりに第２のブロックデータＢＬ２のキャッシュを実行させる(Ｓ７６)。このキャッシュを実行させる処理については、クライアントリストの調整の第１の具体例で詳細に説明したので説明を省略する。
【０３１７】
リスト管理部１５は、受信不可の第２のクライアントＣＬ２を含むクライアントリストＬＳＴ２１ａ(図２１)から、受信不可の第２のクライアントＣＬ２を消去する(Ｓ７７)。
【０３１８】
図２３は、図２１のクライアントリストから受信不可の第２のクライアントＣＬ２が消去されたクライアントリストＬＳＴ２１ｃの図である。リスト管理部１５は、Ｓ７７の処理により、図２３のクライアントリストＬＳＴ２１ｃを作成する。
【０３１９】
次いで、リスト管理部１５は、代表クライアントの重複処理を実行する(Ｓ７７)。ここで、リスト管理部１５は、前記した重複処理の第１〜第３の処理を実行する。リスト管理部１５は、前記した重複処理の第１の処理として、グループＧ１とグループＧ２のそれぞれを３つのサブグループに分ける。グループＧ１において、1つ目のサブグループは、クライアントＣＬ１、２つ目のサブグループは、クライアントＣＬ３、３つ目のサブグループは、クライアントＣＬ４である。
【０３２０】
グループＧ２において、1つ目のサブグループは、クライアントＣＬ５、２つ目のサブグループは、クライアントＣＬ６、３つ目のサブグループは、クライアントＣＬ７、ＣＬ８である。
【０３２１】
リスト管理部１５は、第２の処理として、各サブグループに含まれるクライアントの数の差（０または１）を算出する。
【０３２２】
リスト管理部１５は、第３の処理として、クライアント数が最大である、グループＧ２において、３つ目のサブグループに含まれるクライアントを、同じ第Ｎのブロックデータの代表クライアントと決定する。この決定された代表クライアント（重複クライアント）は、前記の例では、第７のクライアントＣＬ７、第８のクライアントＣＬ８である。
【０３２３】
詳しくは、リスト管理部１５は、第３の処理として、図２２のクライアントリストＬＳＴ２１ｂにおいて、カレントブロックの次のブロックデータの代表クライアントを重複クライアントの中の１つのクライアントと決定する。さらに、リスト管理部１５は、決定済みの重複クライアントの次のクライアントを、重複クライアントの中の他の１つのクライアントとして決定する。
【０３２４】
前記の例では、カレントブロックは、第２のブロックデータＢＬ２であり、次のブロックデータは、第３のブロックデータＢＬ３である。そして、次のブロックデータＢＬ３の代表クライアントは、第７のクライアントＣＬ７である。従って、リスト管理部１５は、重複クライアントを、第７のクライアントＣＬ７と第７のクライアントＣＬ７の次のクライアントである第８のクライアントＣＬ８と決定する。
【０３２５】
なお、あるクライアントの次のクライアントは、クライアントリストにおいて、あるクライアントの下の行のクライアントを示す。クライアントリストにおいて、あるクライアントの行が最下段の場合、あるクライアントの次のクライアントは、このクライアントリストの最上段のクライアントを示す。リスト管理部１５は、図２２のクライアントリストＬＳＴ２１ｂの更新を実行する。
【０３２６】
図２４は、図２２のクライアントリストの重複フラグ欄を更新したクライアントリストＬＳＴ２１ｄの図である。
【０３２７】
リスト管理部１５は、図２４に示したように、クライアントリストＬＳＴ２１ｄにおける重複クライアントＣＬ７のクライアント番号"ＣＬ７"と重複フラグ欄とが交わるセルに、重複クライアントＣＬ８のクライアント番号"ＣＬ８"を登録する。次いで、リスト管理部１５は、クライアントリストＬＳＴ２１ｄにおける重複クライアントＣＬ８のクライアント番号"ＣＬ８"と重複フラグ欄とが交わるセルに、重複クライアントＣＬ７のクライアント番号"ＣＬ７"を登録する。そして、リスト管理部１５は、クライアントリストの調整処理を終了する。
【０３２８】
なお、前記した第１〜第３の具体例において、サーバが、ブロックデータの送信後、所定の時間内に、このブロックデータついての応答確認を代表クライアントから受信しなかった場合も、この代表クライアントが受信不可のクライアントとなる。
【０３２９】
本実施の形態によれば、ブロックデータをキャッシュしている１台のクライアントが、何らかの理由により、通信ができなくなっても、このブロックデータをキャッシュしているクライアントが、他のクライアントからのブロックデータの送信依頼に応答できる。
【０３３０】
また、サーバが、代表クライアントの決定や、クライアントリストの管理を行っている。そのため、クライアントは、通常のデータ受信、応答確認、送信依頼に応答してブロックデータを送信するだけでよく、クライアントにおける処理負荷を削減できる。
【０３３１】
[同期を取る理由の説明]
図２５は、図１３における各グループ間の同期をとる理由を説明する図である。図１３の四角枠、この枠内の文字については、図１３で説明したので省略する。かかる同期を取る理由は、同じブロックデータを複数のクライアントが記憶できなくなる期間をできるだけ短くするためである。
【０３３２】
図８〜図１０の例のように、異なるグループＧ１、Ｇ２で、クライアントの数が異なる場合において、各グループ間の同期をとらないと、サーバは、この同期を取るために実行される処理である代表クライアントの重複処理を実行しない。なお、図２５では、代表クライアントの重複処理を実行しないので、第１のクライアントＣＬ１〜第４のクライアントＣＬ４のグループを図１３とは異なる符号Ｇ１ａで示している。
【０３３３】
以下、図８〜図１０の例のように、異なるグループＧ１ａ、Ｇ２で、代表クライアントの重複処理が実行されない場合におけるサーバＳＶＲの動作を、図２５を参照して説明する。
【０３３４】
リスト管理部１５は、第１のブロックデータＢＬ１の代表クライアントを第１のクライアントＣＬ１、第５のクライアントＣＬ５と決定し、第２のブロックデータＢＬ２の代表クライアントを第２のクライアントＣＬ２、第６のクライアントＣＬ６と決定する。リスト管理部１５は、第３のブロックデータＢＬ３の代表クライアントを第３のクライアントＣＬ３、第７のクライアントＣＬ７と決定する。
【０３３５】
ここで、第３のクライアントＣＬ３は、第３のブロックデータＢＬ３の受信に成功し、第３のブロックデータＢＬ３を自端末に記憶している。このとき、少なくとも、第１のクライアントＣＬ１〜第３のクライアントＣＬ３は、第１のブロックデータＢＬ１〜第３のブロックデータＢＬ３を自端末に記憶している。ただし、例えば、第４のクライアントＣＬ４は、第１のブロックデータＢＬ１〜第３のブロックデータＢＬ３の受信が成功しないこともある。
【０３３６】
第３のクライアントＣＬ３は、第３のブロックデータＢＬ３に成功しサーバＳＶＲに応答確認を行う。サーバＳＶＲは、この応答確認を受信すると第４のブロックデータＢＬ４をマルチキャスト送信する。
【０３３７】
ここでは、リスト管理部１５は、第４のブロックデータＢＬ４の代表クライアントを第４のクライアントＣＬ４、第５のクライアントＣＬ５と決定する。第４のブロックデータＢＬ４の代表クライアントである第５のクライアントＣＬ５は、第４のブロックデータＢＬ４の受信に成功すると、第４のブロックデータＢＬ４をキャッシュする。このとき、第５のクライアントＣＬ５は、既にキャッシュしていた第１のブロックデータＢＬ１を削除し、第４のブロックデータＢＬ４をキャッシュする。この削除した時は、第１のブロックデータＢＬ１をキャッシュしているクライアントは、第１のクライアントＣＬ１だけである。
【０３３８】
このように、第１のブロックデータＢＬ１をキャッシュしているクライアントが、第１のクライアントＣＬ１だけのときに、第１のクライアントＣＬ１の通信機能が、何らかの理由で停止する。そして、第１のブロックデータＢＬ１の受信に失敗している第４のクライアントＣＬ４が、この削除の後、第１のブロックデータＢＬ１の送信要求を行う。
【０３３９】
しかし、第１のブロックデータＢＬ１をキャッシュしている第１のクライアントＣＬ１の通信機能は停止しているので、この送信要求を受信することができない。そのため、第４のクライアントＣＬ４は、ブロックデータを確実に受信できなくなる。かかる事態が生じるのは、同じブロックデータを複数のクライアントがキャッシュできなくなる状態が生じるからである。
【０３４０】
一方、各グループ間の同期をとれば、同じブロックデータを複数のクライアントがキャッシュできなくなる状態が生じることを抑制できる。すなわち、同じブロックデータを複数のクライアントが常にキャッシュしている。そのため、ブロックデータをキャッシュしている１台のクライアントが、何らかの理由により、通信ができなくなっても、このブロックデータをキャッシュしているクライアントが、他のクライアントからのブロックデータの送信依頼に応答できる。
【０３４１】
以上説明したように、各グループ間の同期を取る理由は、同じブロックデータを複数のクライアントが記憶できなくなる期間をできるだけ短くするためである。その結果、クライアントは、サーバから送信された送信データを確実に受信することができる。
【０３４２】
以上の実施の形態をまとめると、次の付記のとおりである。
【０３４３】
（付記１）
複数の端末と、前記複数の端末に配信データを送信するサーバとを有する配信システムであって、
前記サーバは、
配信データを複数のブロックデータに分割し、
複数の端末群各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、
分割されたブロックデータを、代表端末を特定する情報と共に、前記複数の端末群各々に含まれる複数の端末に送信し、
前記複数の端末群各々に含まれる複数の端末各々は、
前記複数のブロックデータを受信して記憶部に記憶し、
複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できず、かつ、該端末が前記第Ｎブロックデータの代表端末として機能しない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、
該端末が前記第Ｎブロックデータの代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求した端末に送信する、
ことを特徴とする配信システム。
【０３４４】
（付記２）
付記１において、
前記複数の端末群各々に含まれる複数の端末各々は、
前記要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータの一部のデータを前記要求した端末に送信し、
前記複数の代表端末から前記一部のデータを受信した端末として機能する場合、最初に受信した前記一部のデータを送信した代表端末に、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を要求し、
前記一部のデータ以外のデータの送信の要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を継続する
ことを特徴とする配信システム。
【０３４５】
（付記３）
複数の端末群各々に含まれる複数の端末と、該複数の端末に配信データを送信するサーバとを有する配信システムにおける、該複数の端末各々に実行させる配信プログラムであって、
前記複数の端末群各々に含まれる複数の端末各々に、
配信データが前記サーバによって分割された、複数のブロックデータを受信して記憶部に記憶し、
複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できず、かつ、該端末が前記サーバによって端末群毎かつ分割されたブロックデータ毎に決定された代表端末として機能しない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、
該端末が前記第Ｎブロックデータの代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求をした端末に送信する、処理を実行させる、
ことを特徴とする配信プログラム。 
【０３４６】
（付記４）
付記３において、
前記複数の端末群各々に含まれる複数の端末各々に、
前記要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータの一部のデータを前記要求した端末に送信する、処理を実行させ、
前記複数の代表端末から前記一部のデータを受信した端末として機能する場合、最初に受信した前記一部のデータを送信した代表端末に、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を要求する処理を実行させ、
前記一部のデータ以外のデータの送信の要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を継続する、処理を実行させる、
ことを特徴とする配信プログラム。
【０３４７】
（付記５）
サーバに、
配信データを複数のブロックデータに分割し、
複数の端末群の各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、
分割されたブロックデータのうち第１のブロックデータを、代表端末を特定する情報と共に、前記複数の端末群の各々に含まれる複数の端末に送信し、
前記第１のブロックデータについての応答確認を前記端末群毎かつ分割されたブロックデータ毎に決定された代表端末から受信すると、前記第１のブロックデータの次の第２の前記ブロックデータを前記複数の端末群の各々に含まれる複数の端末に送信し、
前記代表端末を決定する処理の前に、端末群に含まれる端末数の差が最小になるように、前記複数の端末を端末群にグループ化し、グループ化された各端末をリストに登録して記憶部に記憶する処理を実行させ、
前記代表端末を決定する処理は、前記リストに登録された端末の中から、ラウンドロビン方式により、端末群毎かつ分割されたブロックデータ毎に代表端末を決定する
処理であることを特徴とする配信プログラム。
【０３４８】
（付記６）
付記５において、
前記代表端末を決定する処理において、一つの端末群に含まれる複数の端末を複数のサブグループに分け、各サブグループに含まれる端末の数の差がゼロでない場合、端末数が最大であるサブグループに含まれる端末を、同じ第Ｎのブロックデータの代表端末と決定する 
処理を前記サーバに実行させることを特徴とする配信プログラム。
【０３４９】
（付記７）
付記６において、
前記ブロックデータを受信不可の端末を検出し、
前記受信不可の端末が含まれる第１の端末群に含まれる他の端末に、前記受信不可の端末が記憶しているブロックデータを送信するように前記第１の端末群とは別の第２の端末群の代表端末に依頼するように指示し、さらに、該他の端末に、該依頼に応答して該第２の端末群の代表端末から送信された、ブロックデータを記憶するように指示し、
各端末群に含まれる代表端末を登録しているリストにおいて、前記受信不可の端末が登録されている位置に前記他の端末を移動させて、該他の端末を前記第１の端末群の代表端末とする
処理を前記サーバに実行させることを特徴とする配信プログラム。
【０３５０】
（付記８）
付記６において、
前記ブロックデータを受信不可の前記端末を検出し、
前記受信不可の端末が含まれる第１の端末群とは異なる第２の端末群に含まれる他の端末に、前記受信不可の端末が記憶しているブロックデータを送信するように前記第２の端末群の代表端末に依頼するように指示し、さらに、該他の端末に、該依頼に応答して、該第２の端末群の代表端末から送信された、ブロックデータを記憶するように指示し、
各端末群に含まれる代表端末を登録しているリストにおいて、前記受信不可の端末が登録されている位置に前記他の端末を移動させて、該他の端末を前記第１の端末群の代表端末とする
処理を前記サーバコンピュータに実行させることを特徴とする配信プログラム。
【０３５１】
（付記９）
付記６において、
前記端末の数の差がゼロの場合に、前記ブロックデータを受信しない受信不可の前記端末を検出すると、前記受信不可の端末を含む前記リストから該受信不可の端末を削除し、
前記端末を削除した後、前記端末の数の差がゼロでない場合、一つの端末群に含まれる複数の端末を複数のサブグループに分け、各サブグループに含まれる端末の数の差がゼロでない場合、端末数が最大であるサブグループに含まれる端末を、同じ第Ｎのブロックデータの代表端末と決定する 
処理を前記サーバに実行させることを特徴とする配信プログラム。
【０３５２】
（付記１０）
付記７または８の何れか１において、
前記受信不可の端末を検出する処理において、配信データの受信を取り消す要求を受信した場合、該要求を送信した端末を前記受信不可の端末として検出する
処理を前記サーバに実行させることを特徴とする配信プログラム。
【０３５３】
（付記１１）
付記７または８の何れか１において、
前記受信不可の端末を検出する処理において、前記ブロックデータを送信してから所定の時間内に、該ブロックデータついての応答確認信号を前記代表端末から受信しなかった場合、該代表端末を前記受信不可の端末として検出する
処理を前記サーバに実行させることを特徴とする配信プログラム。
【０３５４】
（付記１２）
複数の端末と、前記複数の端末に配信データを送信するサーバとを有する配信システムで実行される配信方法あって、
前記サーバは、
配信データを複数のブロックデータに分割し、
複数の端末群各々に含まれる複数の端末の中から、端末群毎かつ分割されたブロックデータ毎に代表端末を決定し、
分割されたブロックデータを、代表端末を特定する情報と共に、前記複数の端末群各々に含まれる複数の端末に送信し、
前記複数の端末群各々に含まれる複数の端末各々は、
前記複数のブロックデータを受信して記憶部に記憶し、
前記代表端末でない端末として機能する場合、複数のブロックデータのうち第Ｎ（Ｎは１以上の整数）のブロックデータを受信できない場合、該第Ｎのブロックデータを送信する要求を、自己が含まれる端末群の代表端末と自己が含まれない端末群の代表端末に要求し、
前記代表端末として機能する場合、前記要求を受信すると、前記記憶部から読み出した前記第Ｎのブロックデータを前記要求した端末に送信する、
ことを特徴とする配信方法。
【０３５５】
（付記１３）
付記１２において、
前記複数の端末群各々に含まれる複数の端末各々は、
前記要求を受信した代表端末として機能する場合、前記第Ｎのブロックデータの一部のデータを前記要求した端末に送信し、
前記複数の代表端末から前記一部のデータを受信した端末として機能する場合、最初に受信した前記一部のデータを送信した端末に、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を要求し、
前記一部のデータ以外のデータの送信の要求を受信した端末として機能する場合、前記第Ｎのブロックデータにおける前記一部のデータ以外のデータの送信を継続する
ことを特徴とする配信方法。
【符号の説明】
【０３５６】
１０００…サーバ、ＮＴ１、ＮＴ２…ネットワーク、１０００〜１００ｊ…第１のクライアント〜第ｊのクライアント、ＳＶＲ…サーバ、ＣＬ１〜ＣＬｋ…第１のクライアント〜第ｋのクライアント、１０１…ＣＰＵ、１０２…ストレージ装置、１０３…ＲＡＭ、１０４…ＲＯＭ、１０５…通信装置、１０６…外部接続インターフェイス装置、ＩＮＰ１…入力装置、ＤＳＰ１…表示装置、ＭＤ１…外部記憶媒体、ＳＦ１…配信ソフト、１１…主管理部、１２…ネゴシエーション部、１３…送信データ管理部、１４…送受信部、１５…リスト管理部、２０１…ＣＰＵ、２０２…ストレージ装置、２０３…ＲＡＭ、２０４…ＲＯＭ、２０５…通信装置、２０６…外部接続インターフェイス装置、ＩＮＰ２…入力装置、ＤＳＰ２…表示装置、ＭＤ２…外部記憶媒体、ＳＦ２…処理ソフト、２１…主管理部、２２…接続処理部、２３…送受信部、２４…応答確認部。
【図１】
2016092680.tif 000003
【図２】
2016092680.tif 000004
【図３】
2016092680.tif 000005
【図４】
2016092680.tif 000006
【図５】
2016092680.tif 000007
【図６】
2016092680.tif 000008
【図７】
2016092680.tif 000009
【図８】
2016092680.tif 000010
【図９】
2016092680.tif 000011
【図１０】
2016092680.tif 000012
【図１１】
2016092680.tif 000013
【図１２】
2016092680.tif 000014
【図１３】
2016092680.tif 000015
【図１４】
2016092680.tif 000016
【図１５】
2016092680.tif 000017
【図１６】
2016092680.tif 000018
【図１７】
2016092680.tif 000019
【図１８】
2016092680.tif 000020
【図１９】
2016092680.tif 000021
【図２０】
2016092680.tif 000022
【図２１】
2016092680.tif 000023
【図２２】
2016092680.tif 000024
【図２３】
2016092680.tif 000025
【図２４】
2016092680.tif 000026
【図２５】
2016092680.tif 000027