マルチキャスト配信システム
【課題】ネットワークで接続された複数のクライアントに対して、サーバーから高速かつ信頼性の高いマルチキャスト配信する。
【解決手段】サーバーは、データをパケット毎に代表識別情報を付加して送信し、クライアントは、サーバーから受信した前記代表識別情報により、自らが代表クライアントか否かを判断し、サーバーから正常にデータを受信した際に、自らが代表クライアントであると判定した場合にのみ、サーバーに肯定応答を送信する。
【解決手段】サーバーは、データをパケット毎に代表識別情報を付加して送信し、クライアントは、サーバーから受信した前記代表識別情報により、自らが代表クライアントか否かを判断し、サーバーから正常にデータを受信した際に、自らが代表クライアントであると判定した場合にのみ、サーバーに肯定応答を送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークで接続された複数のクライアントに対して、サーバーから高速かつ信頼性の高いマルチキャスト配信を行う技術に関するものである。
【背景技術】
【０００２】
従来、ネットワークで接続された複数のクライアントに同じデータを一括送信する場合、マルチキャスト配信にて行えば、配信先クライアント数が増えてもネットワーク負荷を上げることなく高速にデータ配信できるが、例えばＴＣＰ／ＩＰプロトコルのようにＡＣＫ・ＮＡＫ応答による受信確認をしないため、指定された全クライアントに対し全パケットが完全に配信処理が行われたか否かは不明であり、信頼性が低いという問題があった。
【０００３】
元来、インターネットプロトコルを用いたＩＰマルチキャストでは、ベストエフォート型のサービスが想定されており、データ転送時に誤ったパケットの再送は考慮されていなかった（「Ｈｏｓｔ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔ」ＩＥＴＦ ＲＦＣ１１１２、１９８９）。
【０００４】
このため、例えば、データを圧縮して配信する場合、ＭＰＥＧではフレーム間の差分をコード化することにより、変化が少ない場合に情報量を減らしているため、前の画像がデータ欠落により再生できないと、それを参照して作られる次の画像も再生できなくなることから、結局、マルチキャスト配信は行う事ができず、ＴＣＰ／ＩＰにて送信を行わざるを得なかった。また、ディスクイメージそのものを複数のクライアントにネットワークを介して配信する場合も、同様であり、欠落しては困るような重要なデータについては、結局、ＴＣＰ／ＩＰにて送信を行わざるを得なかった。
【０００５】
マルチキャスト配信を用いながらデータ欠落の有無を確認するには、全てのクライアントからのＡＣＫ応答による受信確認を行うため、受信側の数が増えると、送信側に戻るＡＣＫ応答の和が増え、送信側のシステムおよびその接続されるネットワークでＡＣＫが集中して溢れるという問題があった。
【０００６】
これらを解決するために、品質の悪い通信路においてもマルチキャスト配信の信頼性低下を防止でき、かつ、クライアント数が増えても、ＡＣＫに要する時間を短くしてデータ転送率の低下を防止することを目的とするものがある（例えば、特許文献１参照。）。具体的には、クライアント同士が相互に送受信可能なクライアント群でグループを構成し、各グループから事前に１クライアントを代表クライアントとして選出する。サーバーは、マルチキャスト配信で全クライアントに対してデータを送信し、各グループ内の代表のみがサーバーにＡＣＫを送信する。グループ内の他クライアントは自グループの代表がサーバーに送信するＡＣＫを監視する。代表が送信したＡＣＫと自身の状態から受信失敗と判断したら、各クライアントが直接サーバーにＮＡＫを送信する。サーバーはデータ送信後、各グループに対してポーリングを行う。ＮＡＫを受信したら、再送要求された番号のデータをマルチキャスト配信で再送する。再送後、そのグループの代表クライアントにポーリングする。ＡＣＫ受信後、一定時間ＮＡＫが返されなければ送信成功と判断して、次のグループにポーリングを行うというものである。
【特許文献１】特開平１１−４６１６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上述した特許文献１においては、クライアント自身が受信失敗を検出してサーバーにＮＡＫを送信しなければ、サーバーがそのクライアントに対する送信失敗を検出できないため、通信路の一時的な障害は検出できるが、通信路の障害が復旧しない場合やクライアント自体に問題が発生した場合には、サーバーがそのクライアントに対する送信失敗を検出できないという問題がある。また、同一グループに属するクライアント群はクライアント同士が相互に送受信可能でなければならないという制約がある。また、１グループ毎にポーリングして、且つその都度一定時間（Ｔ１）待たなければならないため、送達確認に最低でもグループ数×Ｔ１の時間が必要になり，データ転送効率が悪くなるという問題がある。また、クライアントをグループ化する必要があるため、例えば、データ転送の途中で、あるクライアント群あるいはある通信経路に障害が発生して復旧せず、そのクライアント群に対するデータ転送を継続できなくなったときには、グループの再構築をする必要があるという問題がある。
【０００８】
従って、本発明の目的は、より多様な構成に適用可能で、配信先クライアントが増えてもネットワーク負荷を上げることなく、確実にデータ送信を行うことができ、かつパケットロスした場合には、その部分のデータ再送信を行うことができる信頼性の高いマルチキャスト配信システムを提供することにある。
【課題を解決するための手段】
【０００９】
本発明は上記課題を解決するために、ネットワークを介して、サーバーと複数のクライアントとを接続し、サーバーから複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、サーバーは、データをパケット毎に代表クライアントが変わる代表クライアント選択値を付加して送信する送信手段を有し、クライアントは、サーバーから受信した代表クライアント選択値により、自らが代表クライアントか否かを判断する代表クライアント判定手段と、サーバーから正常にデータを受信した際に、代表クライアント判定手段により、自らが代表クライアントであると判定した場合にのみ、サーバーに肯定応答を送信する応答送信手段とを有するマルチキャスト配信システムを提供する。
【発明の効果】
【００１０】
本発明によると、配信先クライアントが増えてもネットワーク負荷を上げることなく、確実にデータ送信を行うことができ、かつパケットロスが生じた場合には、その部分のデータを再送信を行うことができるため、高信頼性のマルチキャスト配信が実現できる。さらに、どのクライアントに対する送信が成功し、どのクライアントに対する送信が失敗したのかにつき、サーバーが認識できるという効果がある。
【発明を実施するための最良の形態】
【００１１】
本発明の実施の形態を図１乃至図１９を用いて詳細に説明する。
【００１２】
（実施例）
図１は、本発明の実施の形態に係るマルチキャスト配信システムの構成を示す図である。図１に示すように、このマルチキャスト配信システムは、配信対象となるクライアントＰＣ１１〜ＰＣ２０と、これらのクライアントＰＣ１１〜ＰＣ２０とネットワーク２を介して接続されたサーバー３にて構成する。
【００１３】
サーバー３は、図２に示すように、代表クライアントとなる周期（以下、代表周期という）及びパケット連続送出数等の送信情報３０１と、この送信情報３０１を設定する送信情報設定手段３１と、配信データ３０３を読み出してパケットを作成し、送信済みキュー３０４に格納するパケット作成手段３２と、全対象クライアントとパケットを送受信する送受信手段３３と、送信パケットについて代表クライアント選択値（以下、ＲＩＤという）を決定する代表クライアント決定手段３４と、クライアントからの応答を受信した場合に、データ送信結果を判定する送信結果判定手段３５と、対象クライアントの管理情報ＤＢ３０２と、このクライアント管理情報ＤＢ３０２を作成・更新する管理情報ＤＢ作成更新手段３６とから構成される。なお、配信対象となる配信データ３０３は、ネットワーク２に接続されていれば、サーバー３外に存在してもよい。
【００１４】
クライアント４は、図３に示すように前記サーバー３とパケットを送受信する送受信手段４１と、前記サーバー３から予め送信された送信情報に基づき算出した自らの代表クライアント選択値（以下、ＣＲＩＤという）等の受信情報４０１と、受信したパケット内のパケット種別もしくはシーケンス番号等から、受信パケットの正当性を判定する受信データ正当性判定手段４２と、受信したパケット内のＲＩＤと受信情報４０１内のＣＲＩＤから自らが代表クライアントか否かを判定する代表クライアント判定手段４３と、前記サーバー３への応答パケットを作成するパケット作成手段４４と受信データ４０２としてデータを出力するデータ出力手段４５から構成される。なお、受信データ４０２は、クライアント４に接続されていれば、クライアント４外に格納するようにしてもよい。
【００１５】
図４（ａ）は、サーバー３の送信情報３０１のパラメータ内容を示す図であり、代表周期と連続パケット送出数、再送フラグ、ＷＡＫ応答フラグ、シーケンス番号にて構成する。代表周期と連続パケット送出数は、マルチキャスト配信を行う前に設定しておく値であり、例えば、代表周期として「５」、連続パケット送出数として「１０」等を設定する。再送フラグ、ＷＡＫ応答フラグ、シーケンス番号は、データ配信処理の際に更新される情報である。再送フラグは、クライアント側でパケットロスが生じ、再送要求を受けた際、もしくはサーバー３側でクライアント４からの応答パケット受信待ちでタイムアウトが発生した際に立てるフラグであり、ＷＡＫ応答フラグは、クライアント４側で受信データの出力が不可で、待ち要求を受けた際に立てるフラグであり、シーケンス番号は、現在の送信パケットのシーケンス番号であって初期値は１で、配信データ３０３から１送信パケット分読出すごとにカウントアップしていくものである。なお、本実施例では、代表周期を使用する例にて説明するが、必ずしも代表周期である必要はなく、例えばＩＰアドレス等の特定の値を送信してもよい。
【００１６】
図４（ｂ）は、サーバー３の管理情報ＤＢ３０２の構成を示す図であり、管理情報ＤＢ作成更新手段３６により、初期化処理にて格納されたクライアント識別子（以下、ＣＩＤという）に対応したクライアント毎のデータ送信結果が格納更新される。データ送信結果とは、例えば、初期状態がブランクであり、全代表クライアント４からのＡＣＫ応答を受信した場合は、全クライアントのデータ送信結果に「ＯＫ」が格納され、ＮＡＫ応答を受信もしくは、一定時間応答待ちをしたが応答がなかった場合は、該当するクライアント４のデータ送信結果に「ＮＧ」が格納される。
【００１７】
図４（ｃ）は、クライアント４の受信情報４０１のパラメータ内容を示す図であり、ＣＲＩＤと、受信待ちシーケンス番号にて構成する。ＣＲＩＤとは、後述するネゴシエーション処理時に設定されるもので、ＣＩＤをサーバー３から送信された代表周期で割った剰余値が設定される。例えば、ＣＩＤが「３０」、代表周期が「５」である場合には、ＣＲＩＤとして「０」が設定される。なお、ＣＲＩＤの設定方法は、サーバー３から代表周期の替わりに例えばＩＰアドレス等の特定の値が送信される場合は、その値とＣＩＤとの論理和をとる形にしてもよい。受信待ちシーケンス番号は、データ受信出力処理の際に更新される情報であり、初期値は１で、カウントアップしていくものである。
【００１８】
図５〜図８は、各処理において、サーバー３とクライアント４間で送受信されるパケットの構成例である。図５（ａ）は、ネゴシエーション処理時に、サーバー３からクライアント４へ送信されるパケット構成であり、制御パケットコード（０）、代表周期、連続パケット送出数、パケット種別（Ｒｅａｄｙ）にて構成する。図５（ｂ）は、ネゴシエーション処理時に、クライアント４からサーバー３へ応答送信されるパケット構成であり、制御パケットコード（０）、ＣＩＤ、パケット種別（ＡＣＫ）にて構成する。
【００１９】
図６（ａ）は、データ配信処理時に、サーバー３からクライアント４へ送信されるパケット構成であり、シーケンス番号（１〜）、ＲＩＤ、データにて構成する。ＲＩＤとは、０以上代表周期値未満の値であり、その初期値として、例えば「０」を決定する。サーバー３の代表クライアント決定手段３４では、連続パケット送出数個のパケット送信後にカウントアップし、カウントアップした値が、代表周期値と同値になった場合は、初期値に戻るという処理を繰り返す。図６（ｂ）は、データ配信処理時に、クライアント４からサーバー３に応答送信されるパケット構成であり、シーケンス番号（１〜）、ＣＩＤ、パケット種別（正常時：ＡＣＫ、異常時：ＮＡＫ、再送要求：ＲＥＳＥＮＤ、待ち要求：ＷＡＫ）にて構成する。
【００２０】
図７（ａ）は、データ配信終了処理時に、サーバー３からクライアント４へ、送信されるパケット構成であり、制御パケットコード（０）、パケット種別（ＥＮＤ）にて構成する。図７（ｂ）は、データ配信終了処理時に、クライアント４からサーバー３に応答送信されるパケット構成であり、制御パケットコード（０）、ＣＩＤ、パケット種別（ＡＣＫ）にて構成する。
【００２１】
図８（ａ）は、ＷＡＫ応答処理時に、サーバー３からクライアント４へ、送信されるパケット構成であり、制御パケットコード（０）、パケット種別（ＩＤＬＥ）にて構成する。
【００２２】
図９は、送信済キュー３０４の構造である。リングバッファ形式で、ＦＩＦＯキュー構造を持ち、少なくとも連続パケット送出数以上のバッファ数を有する。送信パケットを作成する毎に追加されていき、ＲＥＳＥＮＤ応答処理時に、送信済キュー３０４に存在する全てのパケットを再度クライアントにマルチキャスト配信する。
【００２３】
次に、本発明の一実施例であるマルチキャスト配信処理の流れを図１０〜図１８のフローチャートを参照しながら説明する。
【００２４】
配信者は、管理者ＰＣ５から、図１９に示すようなマルチキャスト配信ツールを起動し、配信対象クライアントの選択・設定及び配信対象データの指定を行う。更に連続パケット送出数を例えば「１０」、クライアントの台数から最適な代表周期、例えば、「５」と入力し、配信実行を選択する。
【００２５】
配信実行を受付けると、サーバー３及び全クライアント４は、図１０に示すネゴシエーション処理を開始する。まず、サーバー３の送信情報設定手段３１にて、送信情報３０１の代表周期に「５」、連続送出数「１０」が設定される（Ｓ１）。次に、選択した対象クライアントの管理情報ＤＢ３０２を作成・初期化し、リトライ回数をクリアする（Ｓ２）。
【００２６】
次に、一定リトライ回数を越えていないか否かを確認し、越えていなければ、サーバー３のパケット作成手段３２は、図５（ａ）に示すネゴシエーション処理パケットとして、制御パケットコード「０」、代表周期「５」、連続パケット送出数「１０」パケット種別「ＲＥＡＤＹ」を作成し、送受信手段３１にて全対象クライアント４に対してマルチキャスト配信を行う（Ｓ３）。
【００２７】
マルチキャスト配信を行うと、サーバー３は、全対象クライアント４からのネゴシエーション処理応答パケット（ＡＣＫ）応答受信待ちとなる（Ｓ４）。
【００２８】
一定時間内に、クライアント４からネゴシエーション処理応答パケット（ＡＣＫ）を受信すると、管理情報ＤＢ３０２の応答クライアントの送信結果に、「ＯＫ」を設定していく（Ｓ５）。
【００２９】
このようにして、全対象クライアント４からのネゴシエーション応答処理パケット（ＡＣＫ）受信を待った結果、一定リトライ回数内に、応答がないクライアントに対しては、管理情報ＤＢ３０２の対応するクライアントの送信結果に、「ＮＧ」を設定する（Ｓ６）。なお、一定リトライ回数を超えても、全対象クライアントからネゴシエーション応答処理パケット（ＡＣＫ）の受信がなく、全クライアントの送信結果が「ＮＧ」の場合は、ネットワーク上の問題等、他の問題があると判断し、マルチキャスト配信処理を異常終了する（Ｓ７）。
【００３０】
一方、クライアント４は、送受信手段４１により、サーバー３からパケットを受信すると（Ｃ１）、受信データ正当性判定手段４２にて、ネゴシエーション処理パケットであることを確認すると（Ｃ２）、パケット作成手段４４により、ネゴシエーション処理応答パケットとして、制御パケットコード「０」、ＣＩＤ、パケット種別「ＡＣＫ」を作成し、送受信手段４１にてサーバー３に送信する（Ｃ３）。
【００３１】
更に、代表クライアント判定手段４３により、ＣＩＤ、例えば「３０」を代表周期「５」で割った剰余値「０」をＣＲＩＤとし、さらに受信待ちシーケンス番号１を「１」に初期化して、受信情報４０１に設定する（Ｃ４）。
【００３２】
なお、受信データ正当性判定手段４２にて、ネゴシエーション処理パケットでないと判断した場合には（Ｃ２）、異常終了をする（Ｃ５）。
【００３３】
ネゴシエーション処理が完了すると、次にデータ配信処理を行う。サーバー３側のデータ配信処理の流れは、図１１のデータ配信処理のメインフローチャートと、メインフローチャートから分岐するフローチャートとして、図１２の送信パケット作成処理フローチャート、図１３の応答パケット受信処理フローチャート、この応答パケット受信フローチャートから分岐するフローチャートとして、図１４の受信パケット解析処理フローチャートを用いて説明する。
【００３４】
サーバー３では、管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントの送信結果を初期化する（Ｓ８）。その後、代表クライアント決定手段３４にて、ＲＩＤを決定する（Ｓ９）。ＲＩＤは、０以上代表周期値未満の値であり、その初期値として、例えば「０」を決定する。この値は、前述のとおり、サーバー３の代表クライアント決定手段３４では、連続パケット送出数個のパケット送信後にカウントアップし、カウントアップした値が、代表周期値と同値になった場合は、初期値に戻る。
【００３５】
次に、図１２に示す送信パケット作成処理（Ｓ１０）を行う。パケット作成手段３２は、再送フラグが立っていない場合には（Ｓ１０１）、配信データ３０３から送信パケット分を読み込み、シーケンス番号「１」、ＲＩＤ「０」にてパケットを作成する（Ｓ１０２）。配信データのパケット作成が終了すると、送信済みキュー３０４に送信パケットを保存する（Ｓ１０３）。なお、ＲＩＤは、連続パケット送出数が１０である場合には、１０個置きに存在するパケットに対してのみ付加される。
【００３６】
再送フラグが立っている場合には（Ｓ１０１）、送信済みキュー３０４に残存する全パケット再送が行われているかを確認し、再送されていなければ、送信済みキュー３０４から送信パケットを読み込み、既に全パケットが再送されている場合は（Ｓ１０４）、再送フラグをクリアし（Ｓ１０５）、シーケンス番号をカウントアップし（Ｓ１０６）、パケット作成を行う。
【００３７】
パケット作成処理を終了すると、次に配信データの送信が終了しているか否かを判断し、配信データが終了していなければ（Ｓ１１）、全対象クライアントに対してデータパケットをマルチキャスト配信する（Ｓ１２）。マルチキャスト配信を行うと、応答パケット受信処理を行う（Ｓ１３）。
【００３８】
次に、図１３、図１４に示すように、応答パケット受信処理を行う。一定時間内にパケットを受信すると（Ｓ１３１）、受信パケット解析処理を行う（Ｓ１３２）。受信パケット解析処理では、１パケット受信したのち、パケット種別がＡＣＫである場合は、管理情報ＤＢの応答クライアントの送信結果に「ＯＫ」を設定する（Ｓ１３２１）。パケット種別がＮＡＫである場合は、管理情報ＤＢの応答クライアントの送信結果に「ＮＧ」を設定する（Ｓ１３２２）。パケット種別が「ＲＥＳＥＮＤ」である場合は、管理情報ＤＢの応答クライアントの送信結果に「ＯＫ」を設定し、再送フラグを立てる（Ｓ１３２３）。パケット種別が「ＷＡＫ」である場合は、ＷＡＫ応答フラグを立てる（Ｓ１３２４）。
【００３９】
このようにして、全受信パケット解析処理が終了すると（Ｓ１３３）、次に、ＷＡＫ応答フラグが立っている場合は、ＩＤＬＥパケットを作成してマルチキャスト配信を行い（Ｓ１３４）、全代表クライアントのうち管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントからの応答があるまで、応答パケット受信処理を続ける（Ｓ１３５）。ＷＡＫ応答フラグが立っていない場合は、そのまま全代表クライアントからの応答があるまで、応答パケット受信処理を続ける（Ｓ１３５）。
【００４０】
次に、全代表クライアントのうち管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントからの応答があった場合、データ配信処理に戻る。または一定時間内に応答パケットの受信がない場合は再送フラグを立て（Ｓ１３６）、データ配信処理に戻る。
【００４１】
再送フラグが立っていない場合は（Ｓ１４）、シーケンス番号のカウントアップを行い（Ｓ１５）、再送フラグが立っている場合は、同じシーケンス番号のまま、データ配信処理を繰り返す。
【００４２】
データ配信処理が完了すると、サーバー３は、図１５に示すデータ配信終了処理（Ｓ１６）を行う。サーバー３の管理情報ＤＢの送信結果に「ＮＧ」が設定されていないクライアントの送信結果を初期化し、リトライ回数をクリアする（Ｓ１６１）。次に、一定リトライ回数を越えていないか否かを確認し（Ｓ１６２）、越えていなければ、サーバー３のパケット作成手段３２は、図７（ａ）に示す配信終了処理パケットとして、制御パケットコード「０」、パケット種別「ＥＮＤ」を作成し、全対象クライアントに対してマルチキャスト配信を行う（Ｓ１６３）。マルチキャスト配信を行うと、サーバー３は、送信した全クライアント４からの配信終了処理応答パケット（ＡＣＫ）応答受信待ちとなる（Ｓ１６４）。サーバー３は、一定時間内に、クライアント４から配信終了処理応答パケット（ＡＣＫ）を受信すると、管理情報ＤＢ３０２の応答クライアントの送信結果に、「ＯＫ」を設定していく（Ｓ１６５）。
【００４３】
このようにして、全対象クライアント４からの配信終了処理応答パケット（ＡＣＫ）を待った結果、全クライアントのうち管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントからの応答があれば、処理を終了する（Ｓ１６６）。また一定リトライ回数内に、応答がないクライアントに対しては、管理情報ＤＢ３０２の対応するクライアントの送信結果に、「ＮＧ」を設定し（Ｓ１６７）、処理を終了する（Ｓ１６６）。
【００４４】
次に、クライアント側のデータ受信処理の流れについて説明する。データ受信処理の流れは、図１６のクライアント４側データ受信処理のメインフローチャートと、メインフローチャートから分岐するフローチャートとして、図１７受信データ出力処理フローチャート、図１８の再送要求処理フローチャートを用いて説明する。
【００４５】
クライアント４は、ネゴシエーション処理を終了すると、パケット受信待ちとなる。送受信手段４１により、サーバー３からパケットを受信すると（Ｃ６）、受信データ正当性判定手段４２にて、パケットの確認を行い、データ配信終了処理パケットであることを確認すると（Ｃ７）、パケット作成手段４４により、配信終了処理応答パケットとして、制御パケットコード「０」、ＣＩＤ、パケット種別「ＡＣＫ」を作成し、送受信手段４１にてサーバー３に送信し（Ｃ８）、処理を終了する（Ｃ９）。
【００４６】
受信データ正当性判定手段４２にて、データ配信終了処理パケットでないことを確認すると（Ｃ７）、受信シーケンス番号と待ちシーケンス番号とを比較し（Ｃ１０）、同じ場合は、受信データの出力処理を行う（Ｃ１１）。
【００４７】
受信データ出力処理では、出力可能になるまで一定時間待ち状態となる（Ｃ１１１）。このとき、一定時間内に出力可能とならない場合は、代表クライアント判定手段４３により、受信パケットのＲＩＤがＣＲＩＤと同じであれば、自らが代表クライアントであると判断し（Ｃ１１２）、図６（ｂ）に示すように、シーケンス番号、ＣＩＤ、パケット種別（ＷＡＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１１３）、出力可能状態になるまで待ち状態となる（Ｃ１１１）。このとき、受信パケットのＲＩＤがＣＲＩＤと同じでなければ、代表クライアントでないと判断し（Ｃ１１２）、応答送信せずに出力可能になるまで待ち状態となる（Ｃ１１１）。
【００４８】
一定時間内に出力可能状態となると、受信データを出力する（Ｃ１１４）。このときエラーが発生した場合には、図６（ｂ）に示すように応答パケットとして、エラーの発生したシーケンス番号、ＣＩＤ、パケット種別（ＮＡＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１１５）、異常終了する。
【００４９】
受信データの出力が正常終了した場合には、待ちシーケンス番号のカウントアップを行い（Ｃ１２）、代表クライアント判定手段４３により、受信パケットのＲＩＤがＣＲＩＤと同じであれば、自らが代表クライアントであると判断し（Ｃ１３）、図６（ｂ）に示すように、シーケンス番号、ＣＩＤ、パケット種別（ＡＣＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１４）、パケット受信待ちとなる（Ｃ６）。
【００５０】
待ちシーケンス番号が受信シーケンス番号よりも小さい場合は（Ｃ１０）、パケットロスを検出したと判断し、再送要求処理を行う（Ｃ１５）。
【００５１】
再送要求処理では、図６（ｂ）に示すようにパケット作成手段４４により、応答パケットとして、シーケンス番号、ＣＩＤ、パケット種別（ＲＥＳＥＮＤ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１５１）、パケット受信待ちとなる（Ｃ１５２）。パケットを受信すると、受信シーケンス番号が、待ちシーケンス番号にα（クライアントが再送を要求してから、目的の再送データを受信するまでに破棄するデータパケット数の最大値）を加えた値よりも大きい場合（Ｃ１５３）、再送による復旧不可と判断し、図６（ｂ）に示すような応答パケットとして、シーケンス番号、ＣＩＤ、パケット種別（ＮＡＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１５４）、異常終了する。
【００５２】
受信シーケンス番号が、待ちシーケンス番号にα（クライアントが再送を要求してから、目的の再送データを受信するまでに破棄するデータパケット数の最大値）を加えた値と同じもしくは小さい場合は（Ｃ１５３）、再送による復旧可能と判断する。次に、代表クライアント判定手段４３により、受信パケットのＲＩＤがＣＲＩＤと同じであれば、自らが代表クライアントであると判断し（Ｃ１５５）、図６（ｂ）に示すように、シーケンス番号、ＣＩＤ、パケット種別（ＡＣＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１５６）、代表クライアントでないと判断した場合には（Ｃ１５５）、応答送信せずにパケット受信待ちを行う（Ｃ１５２）。
【００５３】
受信シーケンス番号が待ちシーケンス番号と同じになると（Ｃ１５７）、受信データ出力処理（Ｃ１１）を行う。受信データ出力処理については、通常のデータ受信処理と同様である。
【図面の簡単な説明】
【００５４】
【図１】本発明の実施の形態にかかるシステム構成図である。
【図２】本発明のサーバーの構成図である。
【図３】本発明の一実施形態に関わるクライアントの構成図である。
【図４】本発明の一実施形態に関わる送信情報、受信情報、管理情報ＤＢの構成図である。
【図５】本発明の一実施形態に関わるネゴシエーション処理のパケット構成図である。
【図６】本発明の一実施形態に関わるデータ配信処理のパケット構成図である。
【図７】本発明の一実施形態に関わる配信終了処理時のパケット構成図である。
【図８】本発明の一実施形態に関わる待ち要求応答処理時のパケット構成図である。
【図９】本発明の一実施形態に関わる送信済みキューの構成である。
【図１０】サーバー・クライアントのネゴシエーション処理に関するフローチャート。
【図１１】サーバー側のデータ配信処理に関するメインフローチャート。
【図１２】サーバー側データ配信処理（送信パケット作成）に関するフローチャート。
【図１３】サーバー側データ配信処理（応答パケット受信）に関するフローチャート。
【図１４】サーバー側データ配信処理（応答パケット受信−受信パケット解析）に関するフローチャート。
【図１５】サーバー側データ配信終了処理に関するフローチャート。
【図１６】クライアント側データ受信処理に関するメインフローチャート。
【図１７】クライアント側データ受信処理（受信データ出力）に関するフローチャート。
【図１８】クライアント側データ受信処理（再送要求）に関するフローチャート。
【図１９】画面表示例。
【符号の説明】
【００５５】
１・・・マルチキャスト配信システム、
２・・・ネットワーク、
３・・・サーバー、
３１・・・送信情報設定手段、
３２・・・パケット作成手段、
３３・・・送受信手段、
３４・・・代表クライアント決定手段、
３５・・・送信結果判定手段、
３６・・・管理情報ＤＢ作成更新手段、
３０１・・・送信情報、
３０２・・・管理情報ＤＢ、
３０３・・・配信データ、
３０４・・・送信済みキュー、
４・・・クライアント、
４１・・・送受信手段、
４２・・・受信データ正当性判定手段、
４３・・・代表クライアント判定手段、
４４・・・パケット作成手段、
４５・・・データ書き出し手段、
４０１・・・受信情報、
４０２・・・受信データ。
【技術分野】
【０００１】
本発明は、ネットワークで接続された複数のクライアントに対して、サーバーから高速かつ信頼性の高いマルチキャスト配信を行う技術に関するものである。
【背景技術】
【０００２】
従来、ネットワークで接続された複数のクライアントに同じデータを一括送信する場合、マルチキャスト配信にて行えば、配信先クライアント数が増えてもネットワーク負荷を上げることなく高速にデータ配信できるが、例えばＴＣＰ／ＩＰプロトコルのようにＡＣＫ・ＮＡＫ応答による受信確認をしないため、指定された全クライアントに対し全パケットが完全に配信処理が行われたか否かは不明であり、信頼性が低いという問題があった。
【０００３】
元来、インターネットプロトコルを用いたＩＰマルチキャストでは、ベストエフォート型のサービスが想定されており、データ転送時に誤ったパケットの再送は考慮されていなかった（「Ｈｏｓｔ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ ＩＰ Ｍｕｌｔｉｃａｓｔ」ＩＥＴＦ ＲＦＣ１１１２、１９８９）。
【０００４】
このため、例えば、データを圧縮して配信する場合、ＭＰＥＧではフレーム間の差分をコード化することにより、変化が少ない場合に情報量を減らしているため、前の画像がデータ欠落により再生できないと、それを参照して作られる次の画像も再生できなくなることから、結局、マルチキャスト配信は行う事ができず、ＴＣＰ／ＩＰにて送信を行わざるを得なかった。また、ディスクイメージそのものを複数のクライアントにネットワークを介して配信する場合も、同様であり、欠落しては困るような重要なデータについては、結局、ＴＣＰ／ＩＰにて送信を行わざるを得なかった。
【０００５】
マルチキャスト配信を用いながらデータ欠落の有無を確認するには、全てのクライアントからのＡＣＫ応答による受信確認を行うため、受信側の数が増えると、送信側に戻るＡＣＫ応答の和が増え、送信側のシステムおよびその接続されるネットワークでＡＣＫが集中して溢れるという問題があった。
【０００６】
これらを解決するために、品質の悪い通信路においてもマルチキャスト配信の信頼性低下を防止でき、かつ、クライアント数が増えても、ＡＣＫに要する時間を短くしてデータ転送率の低下を防止することを目的とするものがある（例えば、特許文献１参照。）。具体的には、クライアント同士が相互に送受信可能なクライアント群でグループを構成し、各グループから事前に１クライアントを代表クライアントとして選出する。サーバーは、マルチキャスト配信で全クライアントに対してデータを送信し、各グループ内の代表のみがサーバーにＡＣＫを送信する。グループ内の他クライアントは自グループの代表がサーバーに送信するＡＣＫを監視する。代表が送信したＡＣＫと自身の状態から受信失敗と判断したら、各クライアントが直接サーバーにＮＡＫを送信する。サーバーはデータ送信後、各グループに対してポーリングを行う。ＮＡＫを受信したら、再送要求された番号のデータをマルチキャスト配信で再送する。再送後、そのグループの代表クライアントにポーリングする。ＡＣＫ受信後、一定時間ＮＡＫが返されなければ送信成功と判断して、次のグループにポーリングを行うというものである。
【特許文献１】特開平１１−４６１６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上述した特許文献１においては、クライアント自身が受信失敗を検出してサーバーにＮＡＫを送信しなければ、サーバーがそのクライアントに対する送信失敗を検出できないため、通信路の一時的な障害は検出できるが、通信路の障害が復旧しない場合やクライアント自体に問題が発生した場合には、サーバーがそのクライアントに対する送信失敗を検出できないという問題がある。また、同一グループに属するクライアント群はクライアント同士が相互に送受信可能でなければならないという制約がある。また、１グループ毎にポーリングして、且つその都度一定時間（Ｔ１）待たなければならないため、送達確認に最低でもグループ数×Ｔ１の時間が必要になり，データ転送効率が悪くなるという問題がある。また、クライアントをグループ化する必要があるため、例えば、データ転送の途中で、あるクライアント群あるいはある通信経路に障害が発生して復旧せず、そのクライアント群に対するデータ転送を継続できなくなったときには、グループの再構築をする必要があるという問題がある。
【０００８】
従って、本発明の目的は、より多様な構成に適用可能で、配信先クライアントが増えてもネットワーク負荷を上げることなく、確実にデータ送信を行うことができ、かつパケットロスした場合には、その部分のデータ再送信を行うことができる信頼性の高いマルチキャスト配信システムを提供することにある。
【課題を解決するための手段】
【０００９】
本発明は上記課題を解決するために、ネットワークを介して、サーバーと複数のクライアントとを接続し、サーバーから複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、サーバーは、データをパケット毎に代表クライアントが変わる代表クライアント選択値を付加して送信する送信手段を有し、クライアントは、サーバーから受信した代表クライアント選択値により、自らが代表クライアントか否かを判断する代表クライアント判定手段と、サーバーから正常にデータを受信した際に、代表クライアント判定手段により、自らが代表クライアントであると判定した場合にのみ、サーバーに肯定応答を送信する応答送信手段とを有するマルチキャスト配信システムを提供する。
【発明の効果】
【００１０】
本発明によると、配信先クライアントが増えてもネットワーク負荷を上げることなく、確実にデータ送信を行うことができ、かつパケットロスが生じた場合には、その部分のデータを再送信を行うことができるため、高信頼性のマルチキャスト配信が実現できる。さらに、どのクライアントに対する送信が成功し、どのクライアントに対する送信が失敗したのかにつき、サーバーが認識できるという効果がある。
【発明を実施するための最良の形態】
【００１１】
本発明の実施の形態を図１乃至図１９を用いて詳細に説明する。
【００１２】
（実施例）
図１は、本発明の実施の形態に係るマルチキャスト配信システムの構成を示す図である。図１に示すように、このマルチキャスト配信システムは、配信対象となるクライアントＰＣ１１〜ＰＣ２０と、これらのクライアントＰＣ１１〜ＰＣ２０とネットワーク２を介して接続されたサーバー３にて構成する。
【００１３】
サーバー３は、図２に示すように、代表クライアントとなる周期（以下、代表周期という）及びパケット連続送出数等の送信情報３０１と、この送信情報３０１を設定する送信情報設定手段３１と、配信データ３０３を読み出してパケットを作成し、送信済みキュー３０４に格納するパケット作成手段３２と、全対象クライアントとパケットを送受信する送受信手段３３と、送信パケットについて代表クライアント選択値（以下、ＲＩＤという）を決定する代表クライアント決定手段３４と、クライアントからの応答を受信した場合に、データ送信結果を判定する送信結果判定手段３５と、対象クライアントの管理情報ＤＢ３０２と、このクライアント管理情報ＤＢ３０２を作成・更新する管理情報ＤＢ作成更新手段３６とから構成される。なお、配信対象となる配信データ３０３は、ネットワーク２に接続されていれば、サーバー３外に存在してもよい。
【００１４】
クライアント４は、図３に示すように前記サーバー３とパケットを送受信する送受信手段４１と、前記サーバー３から予め送信された送信情報に基づき算出した自らの代表クライアント選択値（以下、ＣＲＩＤという）等の受信情報４０１と、受信したパケット内のパケット種別もしくはシーケンス番号等から、受信パケットの正当性を判定する受信データ正当性判定手段４２と、受信したパケット内のＲＩＤと受信情報４０１内のＣＲＩＤから自らが代表クライアントか否かを判定する代表クライアント判定手段４３と、前記サーバー３への応答パケットを作成するパケット作成手段４４と受信データ４０２としてデータを出力するデータ出力手段４５から構成される。なお、受信データ４０２は、クライアント４に接続されていれば、クライアント４外に格納するようにしてもよい。
【００１５】
図４（ａ）は、サーバー３の送信情報３０１のパラメータ内容を示す図であり、代表周期と連続パケット送出数、再送フラグ、ＷＡＫ応答フラグ、シーケンス番号にて構成する。代表周期と連続パケット送出数は、マルチキャスト配信を行う前に設定しておく値であり、例えば、代表周期として「５」、連続パケット送出数として「１０」等を設定する。再送フラグ、ＷＡＫ応答フラグ、シーケンス番号は、データ配信処理の際に更新される情報である。再送フラグは、クライアント側でパケットロスが生じ、再送要求を受けた際、もしくはサーバー３側でクライアント４からの応答パケット受信待ちでタイムアウトが発生した際に立てるフラグであり、ＷＡＫ応答フラグは、クライアント４側で受信データの出力が不可で、待ち要求を受けた際に立てるフラグであり、シーケンス番号は、現在の送信パケットのシーケンス番号であって初期値は１で、配信データ３０３から１送信パケット分読出すごとにカウントアップしていくものである。なお、本実施例では、代表周期を使用する例にて説明するが、必ずしも代表周期である必要はなく、例えばＩＰアドレス等の特定の値を送信してもよい。
【００１６】
図４（ｂ）は、サーバー３の管理情報ＤＢ３０２の構成を示す図であり、管理情報ＤＢ作成更新手段３６により、初期化処理にて格納されたクライアント識別子（以下、ＣＩＤという）に対応したクライアント毎のデータ送信結果が格納更新される。データ送信結果とは、例えば、初期状態がブランクであり、全代表クライアント４からのＡＣＫ応答を受信した場合は、全クライアントのデータ送信結果に「ＯＫ」が格納され、ＮＡＫ応答を受信もしくは、一定時間応答待ちをしたが応答がなかった場合は、該当するクライアント４のデータ送信結果に「ＮＧ」が格納される。
【００１７】
図４（ｃ）は、クライアント４の受信情報４０１のパラメータ内容を示す図であり、ＣＲＩＤと、受信待ちシーケンス番号にて構成する。ＣＲＩＤとは、後述するネゴシエーション処理時に設定されるもので、ＣＩＤをサーバー３から送信された代表周期で割った剰余値が設定される。例えば、ＣＩＤが「３０」、代表周期が「５」である場合には、ＣＲＩＤとして「０」が設定される。なお、ＣＲＩＤの設定方法は、サーバー３から代表周期の替わりに例えばＩＰアドレス等の特定の値が送信される場合は、その値とＣＩＤとの論理和をとる形にしてもよい。受信待ちシーケンス番号は、データ受信出力処理の際に更新される情報であり、初期値は１で、カウントアップしていくものである。
【００１８】
図５〜図８は、各処理において、サーバー３とクライアント４間で送受信されるパケットの構成例である。図５（ａ）は、ネゴシエーション処理時に、サーバー３からクライアント４へ送信されるパケット構成であり、制御パケットコード（０）、代表周期、連続パケット送出数、パケット種別（Ｒｅａｄｙ）にて構成する。図５（ｂ）は、ネゴシエーション処理時に、クライアント４からサーバー３へ応答送信されるパケット構成であり、制御パケットコード（０）、ＣＩＤ、パケット種別（ＡＣＫ）にて構成する。
【００１９】
図６（ａ）は、データ配信処理時に、サーバー３からクライアント４へ送信されるパケット構成であり、シーケンス番号（１〜）、ＲＩＤ、データにて構成する。ＲＩＤとは、０以上代表周期値未満の値であり、その初期値として、例えば「０」を決定する。サーバー３の代表クライアント決定手段３４では、連続パケット送出数個のパケット送信後にカウントアップし、カウントアップした値が、代表周期値と同値になった場合は、初期値に戻るという処理を繰り返す。図６（ｂ）は、データ配信処理時に、クライアント４からサーバー３に応答送信されるパケット構成であり、シーケンス番号（１〜）、ＣＩＤ、パケット種別（正常時：ＡＣＫ、異常時：ＮＡＫ、再送要求：ＲＥＳＥＮＤ、待ち要求：ＷＡＫ）にて構成する。
【００２０】
図７（ａ）は、データ配信終了処理時に、サーバー３からクライアント４へ、送信されるパケット構成であり、制御パケットコード（０）、パケット種別（ＥＮＤ）にて構成する。図７（ｂ）は、データ配信終了処理時に、クライアント４からサーバー３に応答送信されるパケット構成であり、制御パケットコード（０）、ＣＩＤ、パケット種別（ＡＣＫ）にて構成する。
【００２１】
図８（ａ）は、ＷＡＫ応答処理時に、サーバー３からクライアント４へ、送信されるパケット構成であり、制御パケットコード（０）、パケット種別（ＩＤＬＥ）にて構成する。
【００２２】
図９は、送信済キュー３０４の構造である。リングバッファ形式で、ＦＩＦＯキュー構造を持ち、少なくとも連続パケット送出数以上のバッファ数を有する。送信パケットを作成する毎に追加されていき、ＲＥＳＥＮＤ応答処理時に、送信済キュー３０４に存在する全てのパケットを再度クライアントにマルチキャスト配信する。
【００２３】
次に、本発明の一実施例であるマルチキャスト配信処理の流れを図１０〜図１８のフローチャートを参照しながら説明する。
【００２４】
配信者は、管理者ＰＣ５から、図１９に示すようなマルチキャスト配信ツールを起動し、配信対象クライアントの選択・設定及び配信対象データの指定を行う。更に連続パケット送出数を例えば「１０」、クライアントの台数から最適な代表周期、例えば、「５」と入力し、配信実行を選択する。
【００２５】
配信実行を受付けると、サーバー３及び全クライアント４は、図１０に示すネゴシエーション処理を開始する。まず、サーバー３の送信情報設定手段３１にて、送信情報３０１の代表周期に「５」、連続送出数「１０」が設定される（Ｓ１）。次に、選択した対象クライアントの管理情報ＤＢ３０２を作成・初期化し、リトライ回数をクリアする（Ｓ２）。
【００２６】
次に、一定リトライ回数を越えていないか否かを確認し、越えていなければ、サーバー３のパケット作成手段３２は、図５（ａ）に示すネゴシエーション処理パケットとして、制御パケットコード「０」、代表周期「５」、連続パケット送出数「１０」パケット種別「ＲＥＡＤＹ」を作成し、送受信手段３１にて全対象クライアント４に対してマルチキャスト配信を行う（Ｓ３）。
【００２７】
マルチキャスト配信を行うと、サーバー３は、全対象クライアント４からのネゴシエーション処理応答パケット（ＡＣＫ）応答受信待ちとなる（Ｓ４）。
【００２８】
一定時間内に、クライアント４からネゴシエーション処理応答パケット（ＡＣＫ）を受信すると、管理情報ＤＢ３０２の応答クライアントの送信結果に、「ＯＫ」を設定していく（Ｓ５）。
【００２９】
このようにして、全対象クライアント４からのネゴシエーション応答処理パケット（ＡＣＫ）受信を待った結果、一定リトライ回数内に、応答がないクライアントに対しては、管理情報ＤＢ３０２の対応するクライアントの送信結果に、「ＮＧ」を設定する（Ｓ６）。なお、一定リトライ回数を超えても、全対象クライアントからネゴシエーション応答処理パケット（ＡＣＫ）の受信がなく、全クライアントの送信結果が「ＮＧ」の場合は、ネットワーク上の問題等、他の問題があると判断し、マルチキャスト配信処理を異常終了する（Ｓ７）。
【００３０】
一方、クライアント４は、送受信手段４１により、サーバー３からパケットを受信すると（Ｃ１）、受信データ正当性判定手段４２にて、ネゴシエーション処理パケットであることを確認すると（Ｃ２）、パケット作成手段４４により、ネゴシエーション処理応答パケットとして、制御パケットコード「０」、ＣＩＤ、パケット種別「ＡＣＫ」を作成し、送受信手段４１にてサーバー３に送信する（Ｃ３）。
【００３１】
更に、代表クライアント判定手段４３により、ＣＩＤ、例えば「３０」を代表周期「５」で割った剰余値「０」をＣＲＩＤとし、さらに受信待ちシーケンス番号１を「１」に初期化して、受信情報４０１に設定する（Ｃ４）。
【００３２】
なお、受信データ正当性判定手段４２にて、ネゴシエーション処理パケットでないと判断した場合には（Ｃ２）、異常終了をする（Ｃ５）。
【００３３】
ネゴシエーション処理が完了すると、次にデータ配信処理を行う。サーバー３側のデータ配信処理の流れは、図１１のデータ配信処理のメインフローチャートと、メインフローチャートから分岐するフローチャートとして、図１２の送信パケット作成処理フローチャート、図１３の応答パケット受信処理フローチャート、この応答パケット受信フローチャートから分岐するフローチャートとして、図１４の受信パケット解析処理フローチャートを用いて説明する。
【００３４】
サーバー３では、管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントの送信結果を初期化する（Ｓ８）。その後、代表クライアント決定手段３４にて、ＲＩＤを決定する（Ｓ９）。ＲＩＤは、０以上代表周期値未満の値であり、その初期値として、例えば「０」を決定する。この値は、前述のとおり、サーバー３の代表クライアント決定手段３４では、連続パケット送出数個のパケット送信後にカウントアップし、カウントアップした値が、代表周期値と同値になった場合は、初期値に戻る。
【００３５】
次に、図１２に示す送信パケット作成処理（Ｓ１０）を行う。パケット作成手段３２は、再送フラグが立っていない場合には（Ｓ１０１）、配信データ３０３から送信パケット分を読み込み、シーケンス番号「１」、ＲＩＤ「０」にてパケットを作成する（Ｓ１０２）。配信データのパケット作成が終了すると、送信済みキュー３０４に送信パケットを保存する（Ｓ１０３）。なお、ＲＩＤは、連続パケット送出数が１０である場合には、１０個置きに存在するパケットに対してのみ付加される。
【００３６】
再送フラグが立っている場合には（Ｓ１０１）、送信済みキュー３０４に残存する全パケット再送が行われているかを確認し、再送されていなければ、送信済みキュー３０４から送信パケットを読み込み、既に全パケットが再送されている場合は（Ｓ１０４）、再送フラグをクリアし（Ｓ１０５）、シーケンス番号をカウントアップし（Ｓ１０６）、パケット作成を行う。
【００３７】
パケット作成処理を終了すると、次に配信データの送信が終了しているか否かを判断し、配信データが終了していなければ（Ｓ１１）、全対象クライアントに対してデータパケットをマルチキャスト配信する（Ｓ１２）。マルチキャスト配信を行うと、応答パケット受信処理を行う（Ｓ１３）。
【００３８】
次に、図１３、図１４に示すように、応答パケット受信処理を行う。一定時間内にパケットを受信すると（Ｓ１３１）、受信パケット解析処理を行う（Ｓ１３２）。受信パケット解析処理では、１パケット受信したのち、パケット種別がＡＣＫである場合は、管理情報ＤＢの応答クライアントの送信結果に「ＯＫ」を設定する（Ｓ１３２１）。パケット種別がＮＡＫである場合は、管理情報ＤＢの応答クライアントの送信結果に「ＮＧ」を設定する（Ｓ１３２２）。パケット種別が「ＲＥＳＥＮＤ」である場合は、管理情報ＤＢの応答クライアントの送信結果に「ＯＫ」を設定し、再送フラグを立てる（Ｓ１３２３）。パケット種別が「ＷＡＫ」である場合は、ＷＡＫ応答フラグを立てる（Ｓ１３２４）。
【００３９】
このようにして、全受信パケット解析処理が終了すると（Ｓ１３３）、次に、ＷＡＫ応答フラグが立っている場合は、ＩＤＬＥパケットを作成してマルチキャスト配信を行い（Ｓ１３４）、全代表クライアントのうち管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントからの応答があるまで、応答パケット受信処理を続ける（Ｓ１３５）。ＷＡＫ応答フラグが立っていない場合は、そのまま全代表クライアントからの応答があるまで、応答パケット受信処理を続ける（Ｓ１３５）。
【００４０】
次に、全代表クライアントのうち管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントからの応答があった場合、データ配信処理に戻る。または一定時間内に応答パケットの受信がない場合は再送フラグを立て（Ｓ１３６）、データ配信処理に戻る。
【００４１】
再送フラグが立っていない場合は（Ｓ１４）、シーケンス番号のカウントアップを行い（Ｓ１５）、再送フラグが立っている場合は、同じシーケンス番号のまま、データ配信処理を繰り返す。
【００４２】
データ配信処理が完了すると、サーバー３は、図１５に示すデータ配信終了処理（Ｓ１６）を行う。サーバー３の管理情報ＤＢの送信結果に「ＮＧ」が設定されていないクライアントの送信結果を初期化し、リトライ回数をクリアする（Ｓ１６１）。次に、一定リトライ回数を越えていないか否かを確認し（Ｓ１６２）、越えていなければ、サーバー３のパケット作成手段３２は、図７（ａ）に示す配信終了処理パケットとして、制御パケットコード「０」、パケット種別「ＥＮＤ」を作成し、全対象クライアントに対してマルチキャスト配信を行う（Ｓ１６３）。マルチキャスト配信を行うと、サーバー３は、送信した全クライアント４からの配信終了処理応答パケット（ＡＣＫ）応答受信待ちとなる（Ｓ１６４）。サーバー３は、一定時間内に、クライアント４から配信終了処理応答パケット（ＡＣＫ）を受信すると、管理情報ＤＢ３０２の応答クライアントの送信結果に、「ＯＫ」を設定していく（Ｓ１６５）。
【００４３】
このようにして、全対象クライアント４からの配信終了処理応答パケット（ＡＣＫ）を待った結果、全クライアントのうち管理情報ＤＢ３０２の送信結果に「ＮＧ」が設定されていないクライアントからの応答があれば、処理を終了する（Ｓ１６６）。また一定リトライ回数内に、応答がないクライアントに対しては、管理情報ＤＢ３０２の対応するクライアントの送信結果に、「ＮＧ」を設定し（Ｓ１６７）、処理を終了する（Ｓ１６６）。
【００４４】
次に、クライアント側のデータ受信処理の流れについて説明する。データ受信処理の流れは、図１６のクライアント４側データ受信処理のメインフローチャートと、メインフローチャートから分岐するフローチャートとして、図１７受信データ出力処理フローチャート、図１８の再送要求処理フローチャートを用いて説明する。
【００４５】
クライアント４は、ネゴシエーション処理を終了すると、パケット受信待ちとなる。送受信手段４１により、サーバー３からパケットを受信すると（Ｃ６）、受信データ正当性判定手段４２にて、パケットの確認を行い、データ配信終了処理パケットであることを確認すると（Ｃ７）、パケット作成手段４４により、配信終了処理応答パケットとして、制御パケットコード「０」、ＣＩＤ、パケット種別「ＡＣＫ」を作成し、送受信手段４１にてサーバー３に送信し（Ｃ８）、処理を終了する（Ｃ９）。
【００４６】
受信データ正当性判定手段４２にて、データ配信終了処理パケットでないことを確認すると（Ｃ７）、受信シーケンス番号と待ちシーケンス番号とを比較し（Ｃ１０）、同じ場合は、受信データの出力処理を行う（Ｃ１１）。
【００４７】
受信データ出力処理では、出力可能になるまで一定時間待ち状態となる（Ｃ１１１）。このとき、一定時間内に出力可能とならない場合は、代表クライアント判定手段４３により、受信パケットのＲＩＤがＣＲＩＤと同じであれば、自らが代表クライアントであると判断し（Ｃ１１２）、図６（ｂ）に示すように、シーケンス番号、ＣＩＤ、パケット種別（ＷＡＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１１３）、出力可能状態になるまで待ち状態となる（Ｃ１１１）。このとき、受信パケットのＲＩＤがＣＲＩＤと同じでなければ、代表クライアントでないと判断し（Ｃ１１２）、応答送信せずに出力可能になるまで待ち状態となる（Ｃ１１１）。
【００４８】
一定時間内に出力可能状態となると、受信データを出力する（Ｃ１１４）。このときエラーが発生した場合には、図６（ｂ）に示すように応答パケットとして、エラーの発生したシーケンス番号、ＣＩＤ、パケット種別（ＮＡＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１１５）、異常終了する。
【００４９】
受信データの出力が正常終了した場合には、待ちシーケンス番号のカウントアップを行い（Ｃ１２）、代表クライアント判定手段４３により、受信パケットのＲＩＤがＣＲＩＤと同じであれば、自らが代表クライアントであると判断し（Ｃ１３）、図６（ｂ）に示すように、シーケンス番号、ＣＩＤ、パケット種別（ＡＣＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１４）、パケット受信待ちとなる（Ｃ６）。
【００５０】
待ちシーケンス番号が受信シーケンス番号よりも小さい場合は（Ｃ１０）、パケットロスを検出したと判断し、再送要求処理を行う（Ｃ１５）。
【００５１】
再送要求処理では、図６（ｂ）に示すようにパケット作成手段４４により、応答パケットとして、シーケンス番号、ＣＩＤ、パケット種別（ＲＥＳＥＮＤ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１５１）、パケット受信待ちとなる（Ｃ１５２）。パケットを受信すると、受信シーケンス番号が、待ちシーケンス番号にα（クライアントが再送を要求してから、目的の再送データを受信するまでに破棄するデータパケット数の最大値）を加えた値よりも大きい場合（Ｃ１５３）、再送による復旧不可と判断し、図６（ｂ）に示すような応答パケットとして、シーケンス番号、ＣＩＤ、パケット種別（ＮＡＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１５４）、異常終了する。
【００５２】
受信シーケンス番号が、待ちシーケンス番号にα（クライアントが再送を要求してから、目的の再送データを受信するまでに破棄するデータパケット数の最大値）を加えた値と同じもしくは小さい場合は（Ｃ１５３）、再送による復旧可能と判断する。次に、代表クライアント判定手段４３により、受信パケットのＲＩＤがＣＲＩＤと同じであれば、自らが代表クライアントであると判断し（Ｃ１５５）、図６（ｂ）に示すように、シーケンス番号、ＣＩＤ、パケット種別（ＡＣＫ）を作成し、送受信手段４１にてサーバー３に送信し（Ｃ１５６）、代表クライアントでないと判断した場合には（Ｃ１５５）、応答送信せずにパケット受信待ちを行う（Ｃ１５２）。
【００５３】
受信シーケンス番号が待ちシーケンス番号と同じになると（Ｃ１５７）、受信データ出力処理（Ｃ１１）を行う。受信データ出力処理については、通常のデータ受信処理と同様である。
【図面の簡単な説明】
【００５４】
【図１】本発明の実施の形態にかかるシステム構成図である。
【図２】本発明のサーバーの構成図である。
【図３】本発明の一実施形態に関わるクライアントの構成図である。
【図４】本発明の一実施形態に関わる送信情報、受信情報、管理情報ＤＢの構成図である。
【図５】本発明の一実施形態に関わるネゴシエーション処理のパケット構成図である。
【図６】本発明の一実施形態に関わるデータ配信処理のパケット構成図である。
【図７】本発明の一実施形態に関わる配信終了処理時のパケット構成図である。
【図８】本発明の一実施形態に関わる待ち要求応答処理時のパケット構成図である。
【図９】本発明の一実施形態に関わる送信済みキューの構成である。
【図１０】サーバー・クライアントのネゴシエーション処理に関するフローチャート。
【図１１】サーバー側のデータ配信処理に関するメインフローチャート。
【図１２】サーバー側データ配信処理（送信パケット作成）に関するフローチャート。
【図１３】サーバー側データ配信処理（応答パケット受信）に関するフローチャート。
【図１４】サーバー側データ配信処理（応答パケット受信−受信パケット解析）に関するフローチャート。
【図１５】サーバー側データ配信終了処理に関するフローチャート。
【図１６】クライアント側データ受信処理に関するメインフローチャート。
【図１７】クライアント側データ受信処理（受信データ出力）に関するフローチャート。
【図１８】クライアント側データ受信処理（再送要求）に関するフローチャート。
【図１９】画面表示例。
【符号の説明】
【００５５】
１・・・マルチキャスト配信システム、
２・・・ネットワーク、
３・・・サーバー、
３１・・・送信情報設定手段、
３２・・・パケット作成手段、
３３・・・送受信手段、
３４・・・代表クライアント決定手段、
３５・・・送信結果判定手段、
３６・・・管理情報ＤＢ作成更新手段、
３０１・・・送信情報、
３０２・・・管理情報ＤＢ、
３０３・・・配信データ、
３０４・・・送信済みキュー、
４・・・クライアント、
４１・・・送受信手段、
４２・・・受信データ正当性判定手段、
４３・・・代表クライアント判定手段、
４４・・・パケット作成手段、
４５・・・データ書き出し手段、
４０１・・・受信情報、
４０２・・・受信データ。
【特許請求の範囲】
【請求項１】
ネットワークを介して、サーバーと複数のクライアントとを接続し、前記サーバーから前記複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、
前記サーバーは、
前記データをパケット毎に代表クライアントが変わる代表クライアント選択値を付加して送信する送信手段を有し、
前記クライアントは、
前記サーバーから受信した前記代表クライアント選択値により、自らが代表クライアントか否かを判断する代表クライアント判定手段と、
前記サーバーから正常にデータを受信した際に、前記代表クライアント判定手段により、自らが代表クライアントであると判定した場合にのみ、前記サーバーに肯定応答を送信する応答送信手段と
を有することを特徴とするマルチキャスト配信システム。
【請求項２】
ネットワークを介して、サーバーと複数のクライアントとを接続し、前記サーバーから前記複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、
前記サーバーは、
前記クライアントが各々代表クライアントとなる代表周期値を設定する手段と、
前記クライアントを識別するクライアント識別情報を前記代表周期値で割った剰余値を前記各クライアント毎の代表クライアント選択値として設定し、各々前記クライアントに送信する手段と、
前記データを送信する際に、パケット毎に、初期値からカウントアップした前記代表周期値以下の値を代表クライアント選択値として付加して送信する送信手段と
を有し、
前記クライアントは、
前記サーバーからパケット毎に付加して受信した前記代表クライアント選択値と、前記クライアント毎の代表クライアント選択値により、自らが代表クライアントか否かを判断する代表クライアント判定手段と、
前記サーバーから正常にデータを受信した際に、前記代表クライアント判定手段により、自らが代表クライアントであると判定した場合にのみ、前記サーバーに肯定応答を送信する応答送信手段と
を有することを特徴とするマルチキャスト配信システム。
【請求項３】
前記データ送信手段は、連続送出数を設定し、連続送出数おきのパケットのみ代表クライアント選択値を付加して送信する
ことを特徴とする請求項１ないし２に記載のマルチキャスト配信システム。
【請求項４】
ネットワークを介して、サーバーと複数のクライアントとを接続し、前記サーバーから前記複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、
サーバー側のコンピュータに、
前記クライアントにマルチキャスト配信するための送信情報パケットを作成し、全クライアントに対してマルチキャスト配信する手順と、
このマルチキャスト配信に対する前記全クライアントからの肯定応答を受信し、この肯定応答を受信したクライアントのみをマルチキャスト配信対象クライアントとする手順と、
前記マルチキャスト配信対象クライアントのうちの一部もしくは全部が代表クライアントとなるための値であって、かつ、パケット毎に代表クライアントが変わるように代表クライアント選択値を決定し、この代表クライアント選択値を付加したデータパケットを作成する手順と、
前記作成したデータパケットを、前記マルチキャスト配信対象クライアントに対してマルチキャスト配信する手順と、
前記代表クライアントと判断される全代表クライアントからの肯定応答があった場合で、かつ再送要求応答がない場合には、前記マルチキャスト配信対象クライアントに対するマルチキャスト配信が正常に行われたと判断する手順と、
を実行させるためのマルチキャスト配信プログラム。
【請求項５】
前記データパケット作成手順は、連続送出数を設定し、連続送出数おきのパケットのみ代表クライアント選択値を付加して送信する
ことを特徴とする請求項４に記載のマルチキャスト配信プログラム。
【請求項１】
ネットワークを介して、サーバーと複数のクライアントとを接続し、前記サーバーから前記複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、
前記サーバーは、
前記データをパケット毎に代表クライアントが変わる代表クライアント選択値を付加して送信する送信手段を有し、
前記クライアントは、
前記サーバーから受信した前記代表クライアント選択値により、自らが代表クライアントか否かを判断する代表クライアント判定手段と、
前記サーバーから正常にデータを受信した際に、前記代表クライアント判定手段により、自らが代表クライアントであると判定した場合にのみ、前記サーバーに肯定応答を送信する応答送信手段と
を有することを特徴とするマルチキャスト配信システム。
【請求項２】
ネットワークを介して、サーバーと複数のクライアントとを接続し、前記サーバーから前記複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、
前記サーバーは、
前記クライアントが各々代表クライアントとなる代表周期値を設定する手段と、
前記クライアントを識別するクライアント識別情報を前記代表周期値で割った剰余値を前記各クライアント毎の代表クライアント選択値として設定し、各々前記クライアントに送信する手段と、
前記データを送信する際に、パケット毎に、初期値からカウントアップした前記代表周期値以下の値を代表クライアント選択値として付加して送信する送信手段と
を有し、
前記クライアントは、
前記サーバーからパケット毎に付加して受信した前記代表クライアント選択値と、前記クライアント毎の代表クライアント選択値により、自らが代表クライアントか否かを判断する代表クライアント判定手段と、
前記サーバーから正常にデータを受信した際に、前記代表クライアント判定手段により、自らが代表クライアントであると判定した場合にのみ、前記サーバーに肯定応答を送信する応答送信手段と
を有することを特徴とするマルチキャスト配信システム。
【請求項３】
前記データ送信手段は、連続送出数を設定し、連続送出数おきのパケットのみ代表クライアント選択値を付加して送信する
ことを特徴とする請求項１ないし２に記載のマルチキャスト配信システム。
【請求項４】
ネットワークを介して、サーバーと複数のクライアントとを接続し、前記サーバーから前記複数のクライアントに対してデータを一括送信するマルチキャスト配信システムにおいて、
サーバー側のコンピュータに、
前記クライアントにマルチキャスト配信するための送信情報パケットを作成し、全クライアントに対してマルチキャスト配信する手順と、
このマルチキャスト配信に対する前記全クライアントからの肯定応答を受信し、この肯定応答を受信したクライアントのみをマルチキャスト配信対象クライアントとする手順と、
前記マルチキャスト配信対象クライアントのうちの一部もしくは全部が代表クライアントとなるための値であって、かつ、パケット毎に代表クライアントが変わるように代表クライアント選択値を決定し、この代表クライアント選択値を付加したデータパケットを作成する手順と、
前記作成したデータパケットを、前記マルチキャスト配信対象クライアントに対してマルチキャスト配信する手順と、
前記代表クライアントと判断される全代表クライアントからの肯定応答があった場合で、かつ再送要求応答がない場合には、前記マルチキャスト配信対象クライアントに対するマルチキャスト配信が正常に行われたと判断する手順と、
を実行させるためのマルチキャスト配信プログラム。
【請求項５】
前記データパケット作成手順は、連続送出数を設定し、連続送出数おきのパケットのみ代表クライアント選択値を付加して送信する
ことを特徴とする請求項４に記載のマルチキャスト配信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００７−３１８８０２（Ｐ２００７−３１８８０２Ａ）
【公開日】平成１９年１２月６日（２００７．１２．６）
【国際特許分類】
【出願番号】特願２００７−２０４６５０（Ｐ２００７−２０４６５０）
【出願日】平成１９年８月６日（２００７．８．６）
【分割の表示】特願２００２−２７８２０６（Ｐ２００２−２７８２０６）の分割
【原出願日】平成１４年９月２４日（２００２．９．２４）
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成１９年１２月６日（２００７．１２．６）
【国際特許分類】
【出願日】平成１９年８月６日（２００７．８．６）
【分割の表示】特願２００２−２７８２０６（Ｐ２００２−２７８２０６）の分割
【原出願日】平成１４年９月２４日（２００２．９．２４）
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]