JP4680860B2 - データ通信方法 - Google Patents

Description

本発明は、データ通信方法に関し、特に、サーバから複数のクライアントに大容量のデータを複数のブロックデータに分割してマルチキャスト通信により送信するデータ通信方法に関する。

サーバクライアントシステムにおいて、大容量のデータをサーバからクライアントへ送信する場合、クライアントのハードウエアの制限から、１個のデータが複数のブロック（ブロックデータ）に分割されて送信される。

このようなサーバクライアントシステムにおいては、サーバの負担を軽減し、ネットワークの負荷を軽減するために、効率的なシステムを構築することが提案されている（特許文献１及び２参照）。即ち、サーバは、各々のブロックデータをマルチキャスト通信により送信する。所定のクライアントは、受信したブロックデータをキャッシュ（保存）して、他のクライアントからの要求に応じて、キャッシュしたブロックデータを当該他のクライアントに提供する。
特表２００５−５１８１２０号公報 特開２０００−０８９９９６号公報

本発明者の検討によれば、サーバからマルチキャスト通信により送信されたブロックデータを受信する場合、クライアントの性能の差に起因して、クライアントにおけるブロックデータの処理時間が異なり、ブロックデータの受信におけるズレが発生する。従って、全クライアントを同期させるため、図１３（Ａ）に示すように、ブロックデータの受信処理の終了の都度、各々のクライアント１２１〜１２３からサーバ１０１へ応答確認（Ａｃｋ又はＮａｃｋ）を送信する必要がある。しかし、この場合、１個のサーバ１０１が全クライアント１２１〜１２３からの応答確認を処理するため、サーバ１０１における処理の遅延が発生する。また、クライアント１２１〜１２３における処理の遅延を考慮して、サーバ１０１が、送信したデータをキャッシュ（保存）しておく必要がある。しかし、この場合、サーバ１０１が、現在送信しているブロックデータをキャッシュすることで、全てのクライアント１２１〜１２３に対する再送処理を行うことができるが、サーバ１０１のパフォーマンスは低下する。また、クライアントの数が多い場合、サーバ１０１の受信性能にも依存はするものの、サーバ１０１のパフォーマンスは低下する。

そこで、全てのクライアント１２１〜１２３との間で応答確認を行うのではなく、図１３（Ｂ）に示すように、全てのクライアント１２１〜１２３を代表する１個のクライアント（代表クライアント）１２１だけと応答確認することが考えられる。しかし、この場合、１個の代表クライアント１２１に応答確認の処理が集中する。また、応答確認を行っても、代表クライアント１２１以外のクライアント１２２及び１２３がデータ処理を終了した保証がない。更に、このために、遅延が発生したクライアントに対応するために、サーバ１０１が、全てのブロックデータを保存する必要があり、全てのブロックデータに対応する数のデータバッファ１１５を備えなければならない。

本発明は、データ通信システムのパフォーマンスを低下させること無く、サーバから複数のクライアントに大容量のデータを複数のブロックデータに分割してマルチキャスト通信により確実に送信することができるデータ通信方法を提供することを目的とする。

本発明のデータ通信方法は、サーバが複数のクライアントに対してマルチキャスト通信により複数のブロックデータからなるデータを送信するデータ通信方法である。本発明のデータ通信方法において、前記サーバが、前記複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を送信する代表クライアントを、前記複数のクライアントに所定の順番に割り当てる。前記サーバが、前記複数のブロックデータの中のブロックデータを、これに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する。前記代表クライアントが、前記応答確認を前記サーバに送信する。前記サーバが、前記代表クライアントからの応答確認を受信した場合に、前記複数のブロックデータの中の前記ブロックデータの後続のブロックデータを、これに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する。前記代表クライアントが、自己が対応するブロックデータを、他のクライアントへの再送信のためにキャッシュし、前記キャッシュしたブロックデータを、当該代表クライアントが再度代表クライアントであることを示す情報を受信した後に、廃棄する。

好ましくは、本発明の一実施態様において、前記サーバが、前記データの送信の開始に先立って、前記複数のクライアントとの通信に基づいて、前記データを受信する前記複数のクライアントを登録するクライアントリストを作成する。前記サーバが、前記複数のブロックデータの各々について、前記代表クライアントを、前記クライアントリストに基づいて、その登録の順番にラウンドロビンにより割り当てる。

好ましくは、本発明の一実施態様において、前記代表クライアントが、前記複数のブロックデータの中の前記ブロックデータに先行するブロックデータの全てについて、当該代表クライアントが正常に受信していることを確認して、これに基づいて、前記応答確認を前記サーバに送信する。

本発明のデータ通信方法によれば、サーバが、複数のブロックデータの各々についての代表クライアント（応答確認クライアント）を、複数のクライアントに所定の順番に割り当てる。この上で、サーバが、ブロックデータとこれに割り当てられた代表クライアントを示す情報とを、マルチキャスト通信により複数のクライアントに送信し、代表クライアントからの応答確認を受信した場合に、後続のブロックデータとこれに割り当てられた代表クライアントを示す情報とをマルチキャスト通信により複数のクライアントに送信する。これにより、ブロックデータ毎に代表クライアントが変更されるので、１個の代表クライアントに、応答確認の処理が集中することを防止することができる。また、代表クライアントは割り当てられたブロックデータを必ず受信しているので、ブロックデータ毎に代表クライアントを変更することと併せて、複数のブロックデータが複数の代表クライアントのいずれかに存在することを保証することができる。従って、サーバが全てのブロックデータをキャッシュしておく必要が無いので、サーバの負担を無くすことができる。また、代表クライアントが、キャッシュしたブロックデータを、自己が代表クライアントであることを示す情報を再度受信した後に廃棄する。これにより、代表クライアントが、当該保持したブロックデータについて、他のクライアントからの再送要求を処理することができ、再送処理の負担を均等に分散することができる。

本発明の一実施態様によれば、複数のブロックデータの各々について、代表クライアントを、複数のクライアントを登録するクライアントリストの登録の順番にラウンドロビンにより割り当てる。これにより、複数のクライアントに所定の順番で固定的かつ均等に代表クライアントを割り当てることができる。

本発明の一実施態様によれば、代表クライアントが、自己が対応するブロックデータを保持する。これにより、代表クライアントが所定のブロックデータを保持することを保証することができる。また、複数のブロックデータが複数のクライアントに均等に存在するようにすることができる。

本発明の一実施態様によれば、代表クライアントが、自己が保持すべきブロックデータに先行するブロックデータの全てについて、正常に受信していることを確認した上で、応答確認をサーバに送信する。これにより、代表クライアントが、先頭のブロックデータから自己が保持すべきブロックデータまでのブロックデータを、必ず保持していることを保証することができる。従って、当該代表クライアントが、他のクライアントからの再送要求を処理することができる。

図１は、本発明のデータ通信システムの一例を示す構成図であり、図２は、本発明のデータ通信システムの構成を説明する説明図である。

図１のデータ通信システムは、サーバクライアントモデルによるコンピュータシステム（サーバクライアントシステム）であって、サーバ１と、複数のクライアント２（２１〜２３）と、これらの間を接続するネットワーク３とからなる。ネットワーク３は、例えばインターネット、ＬＡＮ（Local Area Network）等からなり、マルチキャスト通信又はユニキャスト通信を行う。

サーバ１は、マルチキャスト通信によりデータを送信するデータ送信元サーバ（コンピュータ）である。サーバ１は必要に応じてユニキャスト通信を行う。サーバ１は、ネゴシエーション処理部１１と、応答クライアント決定処理部１２と、送受信処理部１３と、クライアントリスト１４と、データバッファ１５とを備える。

クライアント２１は、マルチキャスト通信によりデータを受信するデータ受信クライアント（コンピュータ）である。クライアント２１は必要に応じてユニキャスト通信を行う。クライアント２１は、接続要求処理部２１１と、応答確認処理部２１２と、送受信処理部２１３と、データキャッシュ２１４とを備える。他の複数のクライアント２２及び２３も、クライアント２１と同様である。

以上の各処理部１１〜１３及び２１１〜２１３は、各々、サーバ１又はクライアント２であるコンピュータにおいて、その主メモリ（図示せず）上に存在する当該処理プログラムを、そのＣＰＵ（図示せず）で実行することにより実現される。

サーバ１において、ネゴシエーション処理部１１は、データの送信の開始に先立って、ネゴシエーション処理を行う。ネゴシエーション処理は、サーバ１からマルチキャスト通信によりデータを受信するクライアント２を、予めサーバ１に登録する処理である。

具体的には、ネゴシエーション処理部１１は、データ転送開始が指示されるまで、図２（Ａ）に示すように、マルチキャスト通信に対するクライアント２の接続要求処理部２１１からの接続要求を受け付ける。当該データを受信したいクライアント２は、接続要求処理部２１１により、当該接続要求をサーバ１に送信する。ネゴシエーション処理部１１は、接続要求を受信した全てのクライアント２との通信に基づいて、これらについてのクライアントリスト１４を作成する。

クライアントリスト１４は、図２（Ｂ）に示すように、マルチキャスト通信によるデータを受信する複数のクライアント２を登録するリストである。クライアントリスト１４は、例えばクライアント（名）毎に、当該クライアント（名）に対応して、そのＩＰアドレス等を格納（登録）する。登録の順番は、サーバ１への前記接続要求が受け付けられた順番である。

送受信処理部１３は、データの送信の開始に先立って、図２（Ｃ）に示すように、当該送信対象であるデータを、複数のブロックデータに分割する。ブロックデータの大きさは、例えば固定長とされる。例えば、１個のデータ（本来のデータ）が、当該データ内でユニークなブロックデータ番号（以下、ブロック番号）１〜Ｚまでのブロックデータに分割される。ブロック番号（Ｎ−１）のブロックデータをブロックデータ（Ｎ−１）という。ブロックデータ（Ｎ−１）を、単にブロック（Ｎ−１）と表す。

なお、ブロックデータも複数のよりサイズの小さいデータ（以下、単位データ）に分割される。実際の送信は、この単位データ毎に行われる。単位データには、当該ブロックデータ内でユニークなデータ番号が付与される。

１個のデータは、例えばメモリ（図示せず）に格納される。送受信処理部１３は、図２（Ｃ）に示すように、当該データの送信すべき１個のブロックデータをメモリから取り出して、データバッファ１５に格納する。従って、データバッファ１５は、送受信処理部１３が現在送信中のブロックデータのみを格納する。これにより、サーバ１は、現在送信中のブロックデータのみをキャッシュすれば良いので、データバッファ１５は１個のみで良く、そのサイズも小さくて良い。

応答クライアント決定処理部（以下、決定処理部）１２は、データの送信の開始に先立って、前記データの分割に基づいて、複数のブロックデータの各々について、代表クライアント２（としての処理）を割り当てる。これにより、代表クライアント２がブロックデータ毎に変更される。代表クライアント２は、当該ブロックデータを受信した際に応答確認Ａｃｋを送信するクライアント（応答確認クライアント）である。

代表クライアント２は、複数のクライアント２に対して、所定の順番に割り当てられる。この割り当ての順番は、１個のデータを送信する間（１回のセッションの間）は固定とされる。この割り当ての順番は、セッション毎に割り当てすべきクライアントの数が変化し、データ毎にブロックデータの数が変化するので、セッション毎及びデータ毎に変更される。

具体的には、決定処理部１２は、複数のブロックデータの各々について、代表クライアント２を、クライアントリスト１４に基づいて、その登録の順番にラウンドロビンにより割り当てる。ここで、ラウンドロビンとは、所定の順で、繰り返し（周期的に）、順番を割り当てることを言う。

例えば、図２（Ｂ）のクライアントリスト１４に基づいて、登録の順番が第１位のクライアント＃１であるクライアント２１に、ブロック（Ｎ−１）についての代表クライアント２が割り当てられるとする。この場合、ラウンドロビンにより、クライアント＃２であるクライアント２２にはブロック（Ｎ）が、クライアント＃３であるクライアント２３にはブロック（Ｎ＋１）が、各々、割り当てられる。このように代表クライアント２の割り当てが１周する（ラウンドする）と、再度、クライアント＃１であるクライアント２１に、ブロック（Ｎ＋２）についての代表クライアントが割り当てられる（図３〜図６参照）。これにより、複数のクライアント２に対して、代表クライアント２が均等にかつ固定的な順番で割り当てられ、ブロックデータ毎に定められた順番で（クライアントリスト１４に従って）ラウンドロビンにより変更される。

送受信処理部１３は、複数のクライアント２に対して、マルチキャスト通信により、複数のブロックデータからなるデータを送信する。実際には、送受信処理部１３は、当該ブロックデータをマルチキャストＩＰに送信する。複数のクライアント２は、クライアントリスト１４に予め登録されたクライアント２に限られる。具体的には、送受信処理部１３は、複数のブロックデータの中の１個のブロックデータ（第１の又は先行ブロックデータ）を、複数のクライアントの中の当該ブロックデータに割り当てられた代表クライアント（第１の代表クライアント）２を示す情報と共に、送信する。代表クライアント２を示す情報は、当該ブロックデータを含むパケット（データパケット）のヘッダにおいて、所定の位置に格納される。

一方、クライアント２において、送受信処理部２１３は、マルチキャスト通信により送信されたブロックデータを受信する。実際には、送受信処理部２１３は、マルチキャストＩＰへ送信されたブロックデータ（のパケット、以下同じ）を受信して解析し、これがマルチキャストＩＰに向けたパケットであることを知り、例えばメモリ（図示せず）に格納する。

送受信処理部２１３は、当該ブロックデータを正常に受信したか否かを検査して、受信に失敗した場合、再送要求Ｒｅｓｅｎｄ（を含むパケット、以下同じ）を送信する。この再送要求Ｒｅｓｅｎｄはマルチキャスト通信により送信される。再送要求Ｒｅｓｅｎｄは、応答確認Ａｃｋとは異なり、例えばブロックデータの中の単位データの受信に失敗した場合（例えば、欠落した場合又はエラーを含む場合）に送信される。

再送要求Ｒｅｓｅｎｄは、必ずマルチキャスト通信により送信される。これは、クライアント２は、当該再送要求Ｒｅｓｅｎｄの対象であるブロックデータを、他のどのクライアント２が保持しているかを知ることができないためである。

サーバ１において、送受信処理部１３は、現在送信中のブロックデータに対する再送要求Ｒｅｓｅｎｄを、クライアント２から受信する。この時点では、当該ブロックデータは、サーバ１のデータバッファ１５にキャッシュされている。従って、送受信処理部１３は、現在送信中のブロックデータについて、再送データをマルチキャスト通信により再送信する。サーバ１が再送信するのは、現在送信中のブロックデータのみについてである。再送データは、再送要求Ｒｅｓｅｎｄに対する応答ＲｅｓｅｎｄＤａｔａ（を含むパケット、以下同じ）として送信される。

応答ＲｅｓｅｎｄＤａｔａは、マルチキャスト通信により送信される。これは、当該ブロックデータに対する再送要求Ｒｅｓｅｎｄが重なった場合、応答ＲｅｓｅｎｄＤａｔａの送信を１回のみとすることができるからである。なお、応答ＲｅｓｅｎｄＤａｔａをユニキャスト通信により送信するようにしても良い。

一方、サーバ１（送受信処理部１３）が既に送信済みのブロックデータについては、複数のクライアント２のいずれかから、再送データがマルチキャスト通信により再送信される。サーバ１が当該ブロックデータを再送信することは無い。この時点では、当該ブロックデータは、サーバ１のデータバッファ１５には存在しない。

サーバ１において、送受信処理部１３は、１個のブロックデータの送信を終了すると、当該ブロックデータに対応する代表クライアント２との間で、応答確認Ａｃｋ又はＮａｃｋ（以下、単に応答確認Ａｃｋ）の送受信を行う。応答確認Ａｃｋ又はＮａｃｋは、各々、当該データ（ブロックデータ）の受信に成功した（正常に受信した）こと又は受信に失敗したことを示す情報（を含むパケット、以下同じ）である。代表クライアント２から当該ブロックデータについての応答確認Ａｃｋを受信すると、送受信処理部１３は、当該ブロックデータの送信を終了し、次のブロックデータの送信を行う。応答確認Ｎａｃｋを受信すると、送受信処理部１３は、当該ブロックデータを応答確認Ｎａｃｋに記載されたブロック内のデータ番号から再送信する。

当該クライアント２が代表クライアント２である場合、その応答確認処理部２１２は、当該代表クライアント２が対応する（応答確認すべき）ブロックデータに先行するブロックデータ（先行ブロックデータ）について、当該代表クライアント２が正常に受信していることを確認して、これに基づいて、応答確認Ａｃｋをサーバ１に送信する。これにより、サーバ１から送信されたブロックデータは、代表クライアント２においては確実に受信されていることが保証される。

応答確認Ａｃｋは、クライアント２がサーバ１のＩＰアドレスを知っているので、サーバ１へのユニキャスト通信により送信される。これにより、サーバ１に応答確認Ａｃｋが確実に送信される。なお、応答確認Ａｃｋをマルチキャスト通信により送信するようにしても良い。

サーバ１において、送受信処理部１３が、代表クライアント２からの応答確認Ａｃｋを受信した場合、当該代表クライアント２の対応するブロックデータに続く（の後続の）ブロックデータ（第２の又は後続ブロックデータ）を、これに割り当てられた代表クライアント（第２の代表クライアント）２を示す情報と共に、マルチキャスト通信により複数のクライアント２に送信する。

代表クライアント２は、再送信用のデータキャッシュ２１４を備え、自己が対応するブロックデータを、他のクライアント２に再送信するためにキャッシュする。即ち、当該クライアント２が代表クライアント２である場合、その送受信処理部２１３は、そのデータキャッシュ２１４に、当該クライアント２１がキャッシュ（保持）すべきブロックデータを格納する。データキャッシュ２１４が格納するブロックデータは、当該クライアント２１が応答確認Ａｃｋをサーバ１に送信すべきブロックデータである。従って、サーバ１はデータのキャッシュを持つ必要が無く、また、現在送信中の代表クライアント２に対してのみ再送するだけで、システム全体のデータが保証される。代表クライアント２は、前記キャッシュしたブロックデータを、当該代表クライアント２が再度代表クライアント２であることを示す情報を受信した後に、廃棄する。

代表クライアント２において、送受信処理部２１３は、応答確認Ａｃｋの送信に先立って、複数のクライアント２における他のクライアント２に対して、当該ブロックデータに先行するブロックデータの中で正常に受信していないブロックデータについての再送要求Ｒｅｓｅｎｄを送信し、前記他のクライアント２から前記正常に受信していないブロックデータを受信する。

一方、（代表）クライアント２が、複数のクライアント２における他のクライアント２から、前記キャッシュしたブロックデータについての再送要求Ｒｅｓｅｎｄを受信した場合、当該ブロックデータを、マルチキャスト通信により又はユニキャスト通信により送信する。即ち、クライアント２は、受信したパケットが再送要求Ｒｅｓｅｎｄであり、かつ、自己が代表クライアント２として応答確認Ａｃｋの送受信を行ったブロックデータである場合、その再送要求Ｒｅｓｅｎｄに対しての応答を行う。

サーバ１において、送受信処理部１３が、全てのブロックデータの送信を終了した後に、データの送信の終了を示すデータ転送終了を、マルチキャスト通信により複数のクライアント２に送信する。実際には、図２（Ｃ）に示すように、データ転送終了のパケットが送信される。なお、この送信は、任意のブロックデータの送信が終了した時点で行うことができる。

データ転送終了のパケットを受信した複数のクライアント２は、各々、複数のブロックデータの全てについて正常に受信していることを確認して、データ転送終了に対する応答確認Ａｃｋをサーバ１に送信する。即ち、全てのブロックデータ番号のデータ受信が終了している場合は、サーバ１に対して応答確認Ａｃｋを送信する。データ転送終了に対する応答確認Ａｃｋは、全てのクライアント２がマルチキャスト通信により又はユニキャスト通信により行う。全てのブロック番号のブロックデータの受信を終了していない場合、マルチキャスト通信により再送要求Ｒｅｓｅｎｄを送信する。

送受信処理部１３は、全てのクライアント２からデータ転送終了に対する応答確認Ａｃｋを受信した場合、更に、当該通信の終了を示す通信終了（のパケット）を、全ての（複数の）クライアント２に送信する。全てのクライアント２は、各々、通信終了のパケットを受信するまで、通信（セッション）を保持して、他のクライアント２からの再送要求Ｒｅｓｅｎｄの受信に備える。

以上のように、全てのクライアント２が、サーバ１との応答確認Ａｃｋの送受信を行い、その後サーバ１からの指示で通信を終了する。即ち、代表クライアント２との間でのみ実行していた応答確認Ａｃｋが、データ転送終了についてのみ、全クライアント２との間で行われる。これにより、全てのクライアント２において、全てのブロックデータの受信及び整合性を保証することができる。

以下、図３〜図８を参照して、本発明のデータ通信システムにおけるデータ送信について具体的に説明する。図３、図４、図５及び図６は、本発明のデータ通信システムにおけるデータ通信の説明図であり、各々、ブロック（Ｎ−１）、ブロック（Ｎ）、ブロック（Ｎ＋１）及びブロック（Ｎ＋２）の送信について示す。図７及び図８は、本発明のデータ通信システムにおけるデータの状態の説明図である。

図３に示すように、このデータ通信システムにおいて、１個のサーバ１と３個のクライアント２１〜２３がネットワーク３に接続されている。サーバ１がＩＰアドレス「Ａ．Ｂ．Ｃ．Ｄ」を有し、クライアント２１、２２及び２３が、各々、ＩＰアドレス「Ａ．Ｂ．Ｃ．Ｅ」「Ａ．Ｂ．Ｃ．Ｆ」及び「Ａ．Ｂ．Ｃ．Ｇ」を有する。ネットワーク３は、マルチキャストＩＰアドレスを有する。

３個のクライアント２１、２２及び２３は、サーバ１のクライアントリスト１４に、この順に登録されている。従って、３個のクライアント２１、２２及び２３は、各々、クライアント番号＃１、＃２及び＃３を割り当てられ、従って、この順に代表クライアントとして動作する。

マルチキャスト通信により送信すべきデータが、前述の図２（Ｃ）に示すように、ブロック番号１〜Ｚまでのブロックデータに分割される。サーバ１は、現在、ブロック（Ｎ−１）を、マルチキャスト通信により送信中である（マルチキャストＩＰアドレスに送信している）。ブロック（Ｎ−１）についての（即ち、現時点での）代表クライアントは、クライアント＃１である。

図３において、現時点での代表クライアント＃１は、自己が応答確認Ａｃｋを送信すべきブロック（Ｎ−１）のキャッシュを行う。これにより、ブロック（Ｎ−１）が代表クライアント＃１に保存される。その際、代表クライアント＃１は、自己が応答確認Ａｃｋを送信すべきブロック（Ｎ−１）までのブロックデータは、当該代表クライアント＃１において、全て正常に受信していることを確認する。

サーバ１は、１個の代表クライアント＃１にだけデータを転送しているに等しく、応答確認Ａｃｋも１個の代表クライアント＃１だけから取得する（図４〜図６においても同じ）。応答確認Ａｃｋの受信により、サーバ１は、この時点での送信対象であるブロック（Ｎ−１）の送信を終了する。クライアント＃１〜＃３は、各々、ブロック（Ｎ−１）を受信する。

クライアント＃１は、ブロック（Ｎ−１）の処理をした後、次回に自己が再度代表クライアントとなるまで、ブロック（Ｎ−１）に対する他のクライアント＃２又は＃３からの再送処理Ｒｅｓｅｎｄに応答して、当該データを送付する。クライアント＃１では、ブロック（Ｎ−１）が確実に受信されていることが保証される。

次に、図３の処理に続けて、図４に示すように、サーバ１は、送信対象のブロックデータを変更する。即ち、ブロック（Ｎ−１）に代えて、新たにブロック（Ｎ）がマルチキャスト通信により送信される。サーバ１は、ブロックデータの変更に伴って、代表クライアントも変更する。即ち、クライアント＃１に代えて、新たにクライアント＃２が代表クライアントとされる。

図４において、代表クライアント２をクライアント＃２に変更して送信処理が行われる。クライアント＃２も、クライアント＃１と同様に、ブロック（Ｎ）のキャッシュを行う。クライアント＃３でブロック（Ｎ−１）の受信の失敗が発生した場合、クライアント＃１に対して（正確には、マルチキャストＩＰに対して）、データの再送を要求する。クライアント＃１は、ブロック（Ｎ−１）を保持しているので、再送することができる。

この時、クライアント＃３でブロック（Ｎ−１）の中の受信に失敗した場合、クライアント＃３はマルチキャストＩＰに対して、ブロック（Ｎ−１）の再送要求Ｒｅｓｅｎｄを送信する。ブロック（Ｎ−１）はクライアント＃１が保持しているので、クライアント＃１は、再送要求Ｒｅｓｅｎｄに対する応答ＲｅｓｅｎｄＤａｔａとして、ブロック（Ｎ−１）をクライアント＃３に送信する。これにより、クライアント＃３における受信の失敗を回復することができる。この時、サーバ１はクライアント＃３からの再送要求Ｒｅｓｅｎｄに対応しない。一方、クライアント＃２は、サーバ１に対して応答確認Ａｃｋを送信する。これにより、クライアント＃２により、ブロック（Ｎ）までのデータを確実に受信していることが保証される。

以上のように、サーバ１は、この時点での送信対象であるブロック（Ｎ）のマルチキャスト通信による送信を終了する。クライアント＃１〜＃３は、各々、ブロック（Ｎ）を受信する。代表クライアント＃２は、自己が応答確認Ａｃｋを送信すべきブロック（Ｎ）までの正常な受信を確認して、その後、サーバ１にブロック（Ｎ）の応答確認Ａｃｋを送信する。

次に、図４の処理に続けて、図５に示すように、サーバ１は、送信対象のブロックデータを変更する。即ち、ブロック（Ｎ）に代えて、新たにブロック（Ｎ＋１）がマルチキャスト通信により送信される。サーバ１は、ブロックデータの変更に伴って、代表クライアントも変更する。即ち、クライアント＃２に代えて、新たにクライアント＃３が代表クライアントとされる。

図５において、代表クライアントをクライアント＃３に変更して送信処理が行われる。クライアント＃３も、クライアント＃１及び＃２と同様に、ブロック（Ｎ＋１）のキャッシュを行う。

この時、クライアント＃１でブロック（Ｎ）の受信を失敗した場合、クライアント＃１は、マルチキャストＩＰに対してブロック（Ｎ）の再送要求Ｒｅｓｅｎｄを送付する。ブロック（Ｎ）はクライアント＃２によってキャッシュされているので、クライアント＃２は、ブロック（Ｎ）を再送する。これにより、クライアント＃１はブロック（Ｎ）の受信失敗を回復することができる。

また、クライアント＃３がブロック（Ｎ＋１）の応答確認Ａｃｋの送受信を行うことで、クライアント＃３にブロック（Ｎ＋１）までのブロックデータが確実に保持されていることが保証される。

以上のように、サーバ１は、この時点での送信対象であるブロック（Ｎ＋１）のマルチキャスト通信による送信を終了する。クライアント＃１〜＃３は、各々、ブロック（Ｎ＋１）を受信する。代表クライアント＃３は、自己が応答確認Ａｃｋを送信すべきブロック（Ｎ＋１）までの正常な受信を確認して、その後、サーバ１にブロック（Ｎ＋１）の応答確認Ａｃｋを送信する。

次に、図５の処理に続けて、図６に示すように、サーバ１は、送信対象のブロックデータを変更する。即ち、ブロック（Ｎ＋１）に代えて、新たにブロック（Ｎ＋２）がマルチキャスト通信により送信される。サーバ１は、ブロックデータの変更に伴って、代表クライアントも変更する。即ち、クライアント＃３に代えて、新たにクライアント＃１が、再度、代表クライアントとされる。

図６において、ブロック（Ｎ＋２）は、クライアントリスト１４におけるラウンドロビンに従って、再度、クライアント＃１により応答確認され、キャッシュされる。クライアント＃１は、前述の場合と同様に、ブロック（Ｎ＋２）についての処理を実行する。

クライアント＃１がブロック（Ｎ＋２）を送信しているということは、これに先立って、サーバ１がブロック（Ｎ＋１）の応答確認Ａｃｋを必ず受信している。従って、その時点で、他のクライアント＃２及び＃３は、ブロック（Ｎ−１）からブロック（Ｎ＋１）までの全てのブロックデータを確実に受信している。従って、クライアント＃１は、先の応答確認Ａｃｋの対象であったブロック（Ｎ−１）を破棄することができる。

即ち、クライアント＃２及びクライアント＃３は、ブロック（Ｎ）及びブロック（Ｎ＋１）の応答確認Ａｃｋを送信しているので、必ずブロック（Ｎ−１）を受信していることが保証されている。よって、クライアント＃１はブロック（Ｎ−１）を破棄することができる。従って、厳密には、この時点でブロック（Ｎ−１）の処理が全て終了したことになる。このように、代表クライアント２が一巡した（ラウンドした）場合、当該一巡した範囲内で、クライアント２が受信しているブロックデータ（Ｎ−１）、（Ｎ）及び（Ｎ＋１）については、全てのクライアント２にデータが受信されている。

以上をまとめると、図７及び図８に示すようになる。即ち、図７において、サーバ１は、現在、ブロック（Ｎ＋１）を送信中であり、クライアント２３が代表クライアント２である。他のクライアント２１及び２２は、マルチキャストにより同じブロック（Ｎ＋１）を受信中（取得中）である。サーバ１がブロック（Ｎ＋１）を送信しているので、これに先立って、サーバ１はブロック（Ｎ）についての応答確認Ａｃｋを受信している。他のブロックデータについても同様である。従って、ブロック（Ｎ）までのブロックデータは、必ずいずれかのクライアント２に正常に受信され、存在することが保証されている。

次に、図８において、サーバ１がブロック（Ｎ＋２）を送信する。これに伴って、代表クライアント２がクライアント２１となる。代表クライアント２１は、代表クライアント２が一巡するまでの間のデータを正常に受信している。従って、代表クライアント２１は、ブロック（Ｎ−１）からブロック（Ｎ＋１）までのブロックデータを確実に受信している。このように、代表クライアント２が一巡した（ラウンドした）場合、一巡した範囲内に送信されたブロックデータは、全てのクライアント２において受信されていることを保証することができる。

この状態で、代表クライアント２１がブロック（Ｎ＋２）の受信に失敗すると、その再送要求Ｒｅｓｅｎｄを受信したサーバ１が、ブロック（Ｎ＋２）を再送信する。他のクライアント２２及び２３がブロック（Ｎ＋２）の受信に失敗すると、再送要求Ｒｅｓｅｎｄを受信した代表クライアント２１が、ブロック（Ｎ＋２）を再送信する。

また、例えば、クライアント２１がブロック（Ｎ）の受信に失敗しているとする。この場合、クライアント２１は、ブロック（Ｎ）の再送要求Ｒｅｓｅｎｄを送信する。これを受信したブロック（Ｎ）についての代表クライアント２２が、ブロック（Ｎ）を再送信する。即ち、応答ＲｅｓｅｎｄＤａｔａを送信する。

このように、代表クライアント２がデータのキャッシュを行い、その代表クライアント２をラウンドロビンで順次交代させることにより、サーバ１にキャッシュを持つことなく、処理を確実に行うことが可能となる。また、クライアント２におけるデータの受信の失敗に対応することができ、クライアント２の数が数１００〜数１０００であっても、マルチキャスト通信により同時に行うことができ、システムのパフォーマンスの低下を招くことが無い。

図９は、本発明のデータ通信システムにおけるサーバ１とクライアントとの間のネゴシエーション処理フローである。

サーバ１が、クライアント２からの接続要求待ちの状態にある（ステップＳ１１）。この状態のサーバ１に対して、クライアント２が、接続要求を送信し（ステップＳ１２）、データの転送待ちの状態となる（ステップＳ１３）。サーバ１は、データの転送を開始する指示が入力されると（ステップＳ１４）、その時点で、クライアント２からの接続要求の受信を終了して、クライアントリスト１４を作成して、これに基づいて、代表クライアント２を決定し、当該データの転送を開始する（ステップＳ１５）。

図１０は、本発明のデータ通信システムにおけるサーバ１の実行する送信処理フローである。

サーバ１は、図９の処理に続けて、ブロックデータの送信を開始し、送信すべき当該ブロックデータ内のデータ番号を判断（確認）して（ステップＳ２１）、当該データ番号のデータを含むパケット（データパケット）をマルチキャスト通信により送信する（ステップＳ２２）。この送信中に、サーバ１は、クライアント２からのパケットを受信すると（ステップＳ２３）、当該パケットがブロックデータの終了を示すパケット（転送終了パケット）か否かを調べる（ステップＳ２４）。当該パケットが転送終了パケットでない（再送要求Ｒｅｓｅｎｄを含むパケットである）場合、サーバ１はステップＳ２１以下を繰り返す。

当該パケットが終了パケットである場合、サーバ１は、代表クライアント２との間での応答確認Ａｃｋの送受信を行って、これに基づいて、代表クライアント２への当該ブロックデータの再送が必要か否かを調べる（ステップＳ２５）。再送が必要である場合、サーバ１は、ステップＳ２１以下を繰り返す。再送が必要でない場合、サーバ１は、当該ブロックデータの送信を終了する。

図１１は、本発明のデータ通信システムにおけるクライアントの実行する受信処理フローである。図１１は、サーバが実行する図１０の処理に対応するクライアントの実行する処理である。

ブロックデータの受信を開始したクライアント２は、サーバ１からのパケットを受信すると（ステップＳ３１）、当該パケットが再送要求パケットかデータパケットか否かを調べる（ステップＳ３２）。当該パケットが再送要求パケットである場合、クライアント２は、自己が取得しているブロックデータを再送し（ステップＳ３３）、ステップＳ３１以下を繰り返す。

当該パケットがデータパケットである場合、クライアント２は、当該取得中のブロックデータの確認を行って（ステップＳ３４）、処理を継続するか、再送が必要か、又は、ブロックデータの終了か否かを調べる（ステップＳ３５）。処理を継続する場合、クライアント２は、ステップＳ３１以下を繰り返す。再送が必要である場合、クライアント２は、再送要求Ｒｅｓｅｎｄを送信し（ステップＳ３６）、ステップＳ３１以下を繰り返す。ブロックデータの終了である場合、クライアント２は、自己が代表クライアントである場合、サーバ１との間で応答確認Ａｃｋの送受信を行って（ステップＳ３７）、ブロックデータの受信を終了する。なお、当該クライアント２が代表クライアントでない場合、ステップＳ３７は省略される。

図１２は、本発明のデータ通信システムにおけるクライアントの実行する終了処理フローである。

ブロックデータの受信を開始したクライアント２は、サーバ１からのパケットを受信すると（ステップＳ４１）、当該パケットが再送要求パケット、データ転送終了パケット又は通信終了パケットのいずれであるかを調べる（ステップＳ４２）。当該パケットが再送要求パケットである場合、クライアント２は、自己が取得しているブロックデータを再送し（ステップＳ４３）、ステップＳ４１以下を繰り返す。

当該パケットがデータ転送終了パケットである場合、クライアント２は、当該取得中のブロックデータの確認を行って（ステップＳ４４）、再送が必要か、又は、ブロックデータの終了のいずれであるかを調べる（ステップＳ４５）。処理を継続する場合、クライアント２は、ステップＳ４１以下を繰り返す。再送が必要である場合、クライアント２は、再送要求Ｒｅｓｅｎｄを送信し（ステップＳ４６）、ステップＳ４１以下を繰り返す。データ転送終了パケットである場合、クライアント２は、自己が代表クライアントであるか否かに拘らず、サーバ１との間で応答確認Ａｃｋの送受信を行って（ステップＳ４７）、ステップＳ４１以下を繰り返す。従って、この応答確認Ａｃｋは全てのクライアント２が実行する。

ステップＳ４２において、当該パケットが通信終了パケットである場合、クライアント２は、ブロックデータの受信のためのマルチキャスト通信を終了する。

クライアント２の実行する図１２の処理に対応するサーバ１が実行する処理は、その図示を省略する。簡単に説明すると、図１２から判るように、サーバ１は、最後のブロックデータの送信後に、データ転送終了パケットをマルチキャスト通信により送信し、このデータ転送終了パケットに対する応答確認Ａｃｋを全てのクライアントとの間で行った後、通信終了パケットをマルチキャスト通信により送信する。

以上から判るように、本発明の実施形態の特徴が以下のように把握される。

（付記１） サーバが複数のクライアントに対してマルチキャスト通信により複数のブロックデータからなるデータを送信するデータ通信方法において、
前記サーバが、前記複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を送信する代表クライアントを、前記複数のクライアントに所定の順番に割り当て、
前記サーバが、前記複数のブロックデータの中のブロックデータを、これに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信し、
前記代表クライアントが、前記応答確認を前記サーバに送信し、
前記サーバが、前記代表クライアントからの応答確認を受信した場合に、前記複数のブロックデータの中の前記ブロックデータの後続のブロックデータを、これに割り当てられた前記複数のクライアントの中の新たな代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する
ことを特徴とするデータ通信方法。

（付記２）前記代表クライアントが、マルチキャスト通信により又はユニキャスト通信により、前記応答確認を前記サーバに送信する
ことを特徴とする付記１記載のデータ通信方法。

（付記３）前記サーバが、前記データの送信の開始に先立って、前記データを前記複数のブロックデータに分割し、これに基づいて、前記複数のブロックデータの各々に前記代表クライアントを割り当てる
ことを特徴とする付記１記載のデータ通信方法。

（付記４） 前記サーバが、前記データの送信の開始に先立って、前記複数のクライアントとの通信に基づいて、前記データを受信する前記複数のクライアントを登録するクライアントリストを作成し、
前記サーバが、前記複数のブロックデータの各々について、前記代表クライアントを、前記クライアントリストに基づいて、その登録の順番にラウンドロビンにより割り当てる
ことを特徴とする付記１記載のデータ通信方法。

（付記５） 前記代表クライアントが、自己が対応するブロックデータを、他のクライアントへの再送信のためにキャッシュする
ことを特徴とする付記４記載のデータ通信方法。

（付記６） 前記代表クライアントが、前記キャッシュしたブロックデータを、当該代表クライアントが再度代表クライアントであることを示す情報を受信した後に、廃棄する
ことを特徴とする付記５記載のデータ通信方法。

（付記７） 前記代表クライアントが、前記複数のクライアントの中の他のクライアントから、前記キャッシュしたブロックデータについての再送要求を受信した場合、前記ブロックデータを、マルチキャスト通信により又はユニキャスト通信により送信する
ことを特徴とする付記６記載のデータ通信方法。

（付記８） 前記代表クライアントが、前記複数のブロックデータの中の前記ブロックデータに先行するブロックデータの全てについて、当該代表クライアントが正常に受信していることを確認して、これに基づいて、前記応答確認を前記サーバに送信する
ことを特徴とする付記５記載のデータ通信方法。

（付記９） 前記代表クライアントが、前記応答確認の送信に先立って、前記複数のクライアントの中の他のクライアントに対して、前記ブロックデータに先行するブロックデータの中で正常に受信していないブロックデータについての再送要求を送信し、前記他のクライアントから前記正常に受信していないブロックデータを受信する
ことを特徴とする付記５記載のデータ通信方法。

（付記１０） 前記代表クライアントが、前記再送要求を、マルチキャスト通信により送信する
ことを特徴とする付記９記載のデータ通信方法。

（付記１１） 前記他のクライアントが、前記正常に受信していないブロックデータを、マルチキャスト通信により又はユニキャスト通信により送信する
ことを特徴とする付記１０記載のデータ通信方法。

（付記１２） 前記サーバが、前記複数のブロックデータの送信を終了した後に、前記データの送信の終了を示すデータ転送終了を、前記複数のクライアントに送信し、
前記複数のクライアントが、各々、前記複数のブロックデータの全てについて正常に受信していることを確認して、マルチキャスト通信により又はユニキャスト通信により、前記データ転送終了に対する応答確認を前記サーバに送信する
ことを特徴とする付記１記載のデータ通信方法。

（付記１３） 前記サーバが、前記複数のクライアントから前記データ転送終了に対する応答確認を受信した場合、当該通信の終了を示す通信終了を、前記複数のクライアントに送信する
ことを特徴とする付記１２記載のデータ通信方法。

（付記１４） データを構成する複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を送信する代表クライアントを、ラウンドロビンにより割り当てる応答クライアント決定処理部と、
ブロックデータを、これに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信し、前記代表クライアントからの前記応答確認を受信した場合に、前記ブロックデータの後続のブロックデータを、これに割り当てられた前記複数のクライアントの中の新たな代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する送受信処理部とを備える
ことを特徴とするデータ通信装置。

（付記１５） サーバと、複数のクライアントと、これらの間を接続するネットワークとからなるデータ通信システムにおける前記サーバを実現するプログラムであって、
データを構成する複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を送信する代表クライアントを、ラウンドロビンにより割り当てる処理手順と、
ブロックデータを、これに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する処理手順と、
前記代表クライアントからの前記応答確認を受信した場合に、前記ブロックデータの後続のブロックデータを、これに割り当てられた前記複数のクライアントの中の新たな代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する処理手順とを、コンピュータに実行させる
ことを特徴とするプログラム。

(付記１６) 複数のクライアントに対してマルチキャスト通信により複数のブロックデータからなるデータを送信するサーバにおけるデータ通信方法において、
前記複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を前記サーバに対して送信する代表クライアントを、前記複数のクライアントに所定の順番に割り当て、
前記ブロックデータのいずれかに割り当てられた代表クライアントを示す情報を、前記ブロックデータに付加してマルチキャスト通信により前記複数のクライアントに送信し、
前記代表クライアントからの応答確認を受信した場合に、当該応答確認に対応するブロックデータの後続のブロックデータを、これに割り当てられた新たな代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信する
ことを特徴とするデータ通信方法。

(付記１７) サーバからマルチキャスト通信によりブロックデータを受信するクライアントにおけるデータ通信方法において、
前記サーバが、前記複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を送信する代表クライアントを、前記複数のクライアントに所定の順番に割り当て、
前記サーバから受信したブロックデータ中に、自身を識別する情報が付加されているか否かを判定し、
前記ブロックデータ中に、自身を識別する情報が付加されている場合には、前記受信したブロックデータに対する応答確認を前記サーバに送信する
ことを特徴とするデータ通信方法。

以上、説明したように、本発明によれば、データ通信方法において、１個の代表クライアントに応答確認の処理が集中することを防止し、複数のブロックデータが複数の代表クライアントのいずれかに存在することを保証することができる。従って、複数のクライアントに所定の順番で固定的かつ均等に代表クライアントを割り当てることができる。また、代表クライアントが、先頭のブロックデータから自己が保持すべきブロックデータまでのブロックデータを、必ず保持していることを保証することができる。更に、代表クライアントが、当該保持したブロックデータについて、他のクライアントからの再送要求を処理することができ、また、再送処理の負担を複数のクライアントに均等に分散することができる。

一方、サーバは、送信中のブロックデータのみをキャッシュしておくのみで良く、全てのブロックデータをキャッシュしておく必要が無いので、これについてのサーバの負担を無くすことができる。また、サーバは、送信済みのブロックデータについては再送処理をする必要がないので、これについてのサーバの負担を無くすことができる。

また、以上から、クライアントの数が増加した場合でも、これにより通信速度が低下することを防止することができる。また、サーバ１が、複数の通信セッションを実行した場合でも、これにより通信速度が低下することを防止することができる。これにより、高速で信頼性の高い大規模なデータ通信を実現することができる。

本発明のデータ通信システムの構成の一例を示す構成図である。 本発明のデータ通信システムの構成を説明する説明図である。 本発明のデータ通信システムにおけるデータ通信の説明図である。 本発明のデータ通信システムにおけるデータ通信の説明図である。 本発明のデータ通信システムにおけるデータ通信の説明図である。 本発明のデータ通信システムにおけるデータ通信の説明図である。 本発明のデータ通信システムにおけるデータの状態の説明図である。 本発明のデータ通信システムにおけるデータの状態の説明図である。 本発明のデータ通信システムにおけるサーバとクライアントとの間のネゴシエーション処理フローである。 本発明のデータ通信システムにおけるサーバの実行する送信処理フローである。 本発明のデータ通信システムにおけるクライアントの実行する受信処理フローである。 本発明のデータ通信システムにおけるクライアントの実行する終了処理フローである。 本発明の背景となったデータ通信システムの構成を示す構成図である。

符号の説明

１ サーバ
２（２１〜２３） クライアント
３ ネットワーク
１１ ネゴシエーション処理部
１２ 応答クライアント決定処理部
１３ 送受信処理部
１４ クライアントリスト
１５ データバッファ
２１１ 接続要求処理部
２１２ 応答確認処理部
２１３ 送受信処理部
２１４ データキャッシュ

Claims (3)

1. サーバが複数のクライアントに対してマルチキャスト通信により複数のブロックデータからなるデータを送信するデータ通信方法において、
   前記サーバが、前記複数のブロックデータの各々について、当該ブロックデータを受信した際に応答確認を送信する代表クライアントを、前記複数のクライアントに所定の順番に割り当て、
   前記サーバが、前記複数のブロックデータの中のブロックデータを、前記複数のブロックデータの中の前記ブロックデータに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信し、
   前記代表クライアントが、前記応答確認を前記サーバに送信し、
   前記サーバが、前記代表クライアントからの応答確認を受信した場合に、前記複数のブロックデータの中の前記ブロックデータの後続のブロックデータを、前記後続のブロックデータに割り当てられた前記複数のクライアントの中の代表クライアントを示す情報と共に、マルチキャスト通信により前記複数のクライアントに送信し、
   前記代表クライアントが、自己が対応するブロックデータを、他のクライアントへの再送信のためにキャッシュし、前記キャッシュしたブロックデータを、当該代表クライアントが再度代表クライアントであることを示す情報を受信した後に、廃棄する
   ことを特徴とするデータ通信方法。
2. 前記サーバが、前記データの送信の開始に先立って、前記複数のクライアントとの通信に基づいて、前記データを受信する前記複数のクライアントを登録するクライアントリストを作成し、
   前記サーバが、前記複数のブロックデータの各々について、前記代表クライアントを、前記クライアントリストに基づいて、前記クライアントリストにおける前記複数のクライアントの登録の順番にラウンドロビンにより、前記複数のクライアントに割り当てる
   ことを特徴とする請求項１に記載のデータ通信方法。
3. 前記代表クライアントが、前記複数のブロックデータの中の前記ブロックデータに先行するブロックデータの全てについて、当該代表クライアントが正常に受信していることを確認して、前記確認に基づいて、前記応答確認を前記サーバに送信する
   ことを特徴とする請求項１に記載のデータ通信方法。

Images