(57)【要約】【課題】マルチキャスト配信方法において、配信にかかる時間をユニキャストと同等の時間で配信可能とする技術を提供する。【解決手段】サーバが、クライアントからの配信要求の順番を記録する。サーバが、既存のマスタークライアントへの配信を終了した後、マスタークライアントとなるクライアントを前記記録された順番により配信要求が届いたクライアント順に選ぶ。サーバは、以上の方法によりマスタークライアントを選び、複数のクライアントに対してマルチキャスト配信を行う。具体的には、サーバがクライアントからのｏｐｅｎパケットを予約としてキューに入れ（ステップ３）、既存の送信完了後、キューの先頭から予約パケットを取り出し、取り出したクライアントにマスタークライアントになってもらうべく要求パケットを送信する（ステップ４）。【選択図】        図４
2006005871.tif 000002
【特許請求の範囲】
【請求項１】
サーバが複数のクライアントに対して同時に同じデータを配信するマルチキャスト配信方法であって、
サーバが、クライアントからの配信要求の順番を記録するステップと、
サーバが、既存のマスタークライアントへの配信を終了した後、マスタークライアントとなるクライアントを前記記録された順番により配信要求が届いたクライアント順に選ぶステップと、
を含むマルチキャスト配信方法。
【請求項２】
マルチキャスト配信プロトコルであるｍＴＦＴＰ（multicast Trivial File Transfer Protocol）において、マスタークライアントとなるクライアントを配信要求が届いたクライアント順に選ぶ請求項１に記載のマルチキャスト配信方法。
【請求項３】
配信要求パケットをキューに入れることによって配信要求の順番を記録するステップと、
前記キューから先頭の配信要求パケットを取り出し、取り出した前記配信要求パケットに書かれたアドレスに対してマスタークライアントになるべく要求パケットを送信するステップと、
を含む請求項１または２に記載のマルチキャスト配信方法。
【請求項４】
複数のクライアントに対して同時に同じデータを配信するマルチキャスト配信を行うサーバであって、
クライアントからの配信要求の順番を記録する手段と、
既存のマスタークライアントへの配信を終了した後、マスタークライアントとなるクライアントを前記記録された順番により配信要求が届いたクライアント順に選ぶ手段と、
を備えるサーバ。
【請求項５】
マルチキャスト配信プロトコルであるｍＴＦＴＰ（multicast Trivial File Transfer Protocol）において、マスタークライアントとなるクライアントを配信要求が届いたクライアント順に選ぶ請求項４に記載のサーバ。
【請求項６】
配信要求パケットをキューに入れることによって配信要求の順番を記録する手段と、
前記キューから先頭の配信要求パケットを取り出し、取り出した前記配信要求パケットに書かれたアドレスに対してマスタークライアントになるべく要求パケットを送信する手段と、
を備える請求項４または５に記載のサーバ。
【請求項７】
請求項４ないし６のうちいずれか１項に記載の各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャスト配信技術に関し、特に、複数クライアントが同じデータを要求する際に、パケットの送信順序を制御することで途中でマルチキャストに参加したクライアントにおいてもユニキャストと同等の受信時間でデータ全体の受信を可能とするマルチキャスト配信技術に関する。
【背景技術】
【０００２】
マルチキャスト技術は広範囲に渡るが、大きくアプリケーションソフトウェアやトランスポートプロトコル、ルーティング方法等に分類される。本発明はパケットやフレームの伝送方法に関するものであり、利用される範囲がデータリンク層からトランスポート層なので、従来の技術としてはトランスポートプロトコルに関連する。以上の理由から、従来の技術としてトランスポートプロトコルに関するものを記述する。マルチキャスト技術のトランスポートプロトコルとして上げられるものは、“ＡＦＤＰ（Adaptive File Distribution Protocol）”、“ＬＢＲＭ（Log-Based Receiver-Reliable Multicast）”、“ＬＧＭＰ（Log Group Multicast Protocol”、“ＭＦＴＰ（Multicast File Transfer Protocol）”、“ｍＴＦＴＰ（multicast Trivial File Transfer Protocol）”、“ＭＴＰ−２（Multicast Transport Protocol Version 2）”、“ＲＡＭＰ（Reliable Adaptive Multicast Protocol）”、“ＲＢＰ(Reliable Broadcast Protocol)”、“ＲＭＰ（Reliable Multicast Protocol）”、“ＲＭＴＰ（Reliable Multicast Transport Protocol）”、“ＲＭＴＰ−Ｊ(Reliable Multicast Transport Protocol)”、“ＳＣＥ（Single Connector Emulation）”、“ＳＲＭ（Scalable Reliable Multicast）”、“ＴＭＴＰ（Tree-Based Multicast Transport Protocol）”、“ＸＴＰ（Express Transport Protocol）”である。この中で、本発明と類似するのは、ｍＴＦＴＰであり、他のプロトコルは関連しない。また、過去の特許を調査した結果でも本発明の類似特許は存在しない。本発明は、ｍＴＦＴＰが採用している配信方法に後述する方法を加えることで、詳細は後述するが、クライアントの待ち時間を短縮するものである。以下に従来の技術としてｍＴＦＴＰが採用している配信方法の説明を行う。
【０００３】
ｍＴＦＴＰが採用している方法は、サーバ、クライアント方式であり、クライアントは、“マスタークライアント”と“一般クライアント”が存在する。マスタークライアントとは、クライアントを代表してサーバとやり取りするもので、実際にサーバからデータを受信すると応答を行うクライアントのことである。一般クライアントとは、マルチキャストで配信されるサーバとマスタークライアントとの通信をマルチキャストで受信し自分に必要なデータを蓄え、足りない部分は後で要求するクライアントである。マスタークライアントは、一般のクライアントの中から選出される。選出方法は以下の通りである。
（１）クライアントがデータを受信したい場合、サーバと他のクライアントの通信が存在しないか確認するため一定時間（ｍＴＦＴＰでは、“MTFTP_TRANSMISSION_START_DELAY”と定義される）、他のマスタークライアントからのresponseパケットを受信しないか確認する。他のマスタークライアントからのresponseパケットを受信しなければマスターとなり通信を開始する（このときデータは先頭から受け取ることができる）。他の通信が存在すれば、その通信を傍受しバッファに蓄える（このときデータは途中からになるので、足りない分は後で要求する）。
（２）２つ以上のクライアントが同時刻に要求を出した場合、先に到着したクライアントがマスターとなる。
（３）既存のマスターのデータ受信が完了した場合は、データの途中から受信を開始していた場合、まだ受信していない部分があるクライアント同士の競争となり、（２）と同様、先に到着したクライアントがマスターとなる。
【０００４】
以下に簡単な例として図１を用い、ｍＴＦＴＰの配信方法の説明を行う。クライアントはＡ、Ｂ、Ｃ、Ｄの４台だとする。各クライアントが要求するデータのデータ長は１０パケットとし、１単位時間（これをclockとする）に１パケット受信できるものとする。図１はクライアントがＡ、Ｂ、Ｃ、Ｄの順に到着した場合の上記配信方法の１例を示すものである。
［１］クライアントＡが到着し、他に通信をしているクライアントが存在しないのでマスターになる。
［２］４clockでクライアントＢが到着、マスタークライアントＡの受信データをクライアントＢも受信開始。
［３］８clockでクライアントＣが到着、マスタークライアントＡの受信データをクライアントＣも受信開始。
［４］マスタークライアントＡが終了（受信に要した時間：１０clock）。
［５］クライントＢ、Ｃにはデータを受信していない部分が存在するので、次のマスターになるべくサーバに要求。図ではクライアントＢがマスターになったとする。
［６］１３clockでクライアントＤ到着。
［７］マスタークライアントＢのデータをクライアントＤも受信開始。
［８］マスタークライアントＢが終了（受信に要した時間：１０clock）。
［９］クライアントＣ、Ｄのサーバへの要求の到着が早いものが次のマスターに決定、図１ではクライアントＤがマスタークライアントになったとする。
［１０］マスタークライアントＤの受信開始。
［１１］クライアントＣは受信済みデータなのでそのまま（待ち時間の発生）。
［１２］クライアントＣ（受信に要した時間：１２clock）で受信終了。
［１３］マスタークライアントＤ（受信に要した時間：１０clock）で受信終了。
従って、クライアントＣの終了には１２clockの時間がかかることが分かる。
【０００５】
【非特許文献１】“Intel Preboot Execution Environment＜draft-henry-remote-boot-protocol-00.txt＞、M Henry et al., Jun 24, 1999
【非特許文献２】“マスタリングＴＣＰ／ＩＰ  ＩＰマルチキャスト編”、Dave Kosiur著、苅田幸雄監訳、オーム社、１９９９年１１月
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来の技術では、サーバに配信要求するクライアント数（到着率）が増加した場合、クライアントは受け取りたい部分を受け取れない時間（待ち時間）が発生するため、受信を長い間完了できないクライアントが発生する。実際に、ユニキャストの場合４４秒で完了する通信が、到着率が大きい時にどうなるかは図２で示される。図２において、縦軸は存在率（％）で示し、横軸は受信完了までにかかった時間を示す。図２から分かるように、従来の方式では受信時間が非常にかかるクライアントが（例えば８０秒付近で受信完了するクライアント）が存在することが分かる。本発明の目的は、マルチキャスト配信方法において、配信にかかる時間をユニキャストと同等の時間で配信可能とする技術を提供することである。本発明では、図２に示されるような受信完了時間が延びるクライアントを排除して、全てのクライアントがユニキャストと同等の時間で完了するようにパケットの配信を制御する。図３は、後述する本発明の実施形態の方法で配信した場合の受信完了時間とその存在率である。
【課題を解決するための手段】
【０００７】
本発明は、サーバが複数のクライアントに対して同時に同じデータを配信するマルチキャスト配信方法であって、サーバが、クライアントからの配信要求の順番を記録するステップと、サーバが、既存のマスタークライアントへの配信を終了した後、マスタークライアントとなるクライアントを前記記録された順番により配信要求が届いたクライアント順に選ぶステップと、を含むことを特徴とする。また、本発明は、前記配信方法であって、マルチキャスト配信プロトコルであるｍＴＦＴＰ（multicast Trivial File Transfer Protocol）において、マスタークライアントとなるクライアントを配信要求が届いたクライアント順に選ぶことを特徴とする。また、本発明は、前記配信方法であって、配信要求パケットをキューに入れることによって配信要求の順番を記録するステップと、前記キューから先頭の配信要求パケットを取り出し、取り出した前記配信要求パケットに書かれたアドレスに対してマスタークライアントになるべく要求パケットを送信するステップと、を含む。さらに、本発明は、複数のクライアントに対して同時に同じデータを配信するマルチキャスト配信を行うサーバであって、クライアントからの配信要求の順番を記録する手段と、既存のマスタークライアントへの配信を終了した後、マスタークライアントとなるクライアントを前記記録された順番により配信要求が届いたクライアント順に選ぶ手段と、を備えることを特徴とする。また、本発明は前記サーバであって、マルチキャスト配信プロトコルであるｍＴＦＴＰ（multicast Trivial File Transfer Protocol）において、マスタークライアントとなるクライアントを配信要求が届いたクライアント順に選ぶことを特徴とする。また、本発明は、前記サーバであって、配信要求パケットをキューに入れることによって配信要求の順番を記録する手段と、前記キューから先頭の配信要求パケットを取り出し、取り出した前記配信要求パケットに書かれたアドレスに対してマスタークライアントになるべく要求パケットを送信する手段と、備えることを特徴とする。さらに、本発明は、前記各手段としてコンピュータを機能させるためのプログラムであることを特徴とする。
【発明の効果】
【０００８】
本発明はマルチキャスト配信において、配信にかかる時間をユニキャストと同等の時間で配信可能とする技術であり、さらに、マスタークライアントが変わるたびにパケットの配信順序がより先頭の方から選ばれることにより、例えば、先頭パケットが集まれば、起動可能となる（受信しながら起動できる）ディスクレスブートシステムや、（受信しながら再生できる）ストリーミングシステムなどにおいて特に有効な配信方法である。
【発明を実施するための最良の形態】
【０００９】
従来の方式では、クライアントは既に受け取っているデータを受信することがあり（従来の技術の項で説明済）、このとき待ち時間が発生していた。本発明の実施形態は、マルチキャスト配信方法においてマスタークライアントの選択方法を改良したものであり、後述する方法でマスタークライアントを選択すれば各クライアントは既に受け取っているデータを受け取ることが無くなるのでユニキャストと同等の時間で受信を完了することができる。本実施形態におけるマスタークライアントの選択方法は、クライアントはresponseパケットの存在を確認して通信が存在すれば勝手にネットワークを流れるトラヒックを受信するのではなく、受信したい場合、一旦サーバに配信要求を送り、サーバは届いた配信要求を記録し、既存のマスタークライアントの配信が完了すると、要求が届いた順に、各クライアントをマスタークライアントにする。このようにマスタークライアントを選択し、マスタークライアントの要求通りの順序でデータを配信すれば、先に到着したクライアントが受け取っていない部分は、後に到着したクライアントも必ず受け取ってないので、図３に示すように受信データの重複が無くなり、配信時間をユニキャストと同等の時間で配信することが可能となる。図３は本発明の実施形態における受信完了時間と分布を示した図であり、ユニキャストの場合４４秒で完了する通信が、本実施形態のマルチキャスト配信方法においては全てのクライアントについて４４秒で配信されることが示されている。
【００１０】
例として図４を用いて本発明の実施形態の配信方法の説明を行う。図１と同様に、クライアントはＡ、Ｂ、Ｃ、Ｄの４台だとする。各クライアントが要求するデータのデータ長は１０パケットとし、１単位時間（これをclockとする）に１パケット受信できるものとする。図４はクライアントがＡ、Ｂ、Ｃ、Ｄの順に到着した場合の本発明の実施形態の配信方法の１例を示すものである。
［１］クライアントＡが到着し、他に通信をしているクライアントが存在しないのでマスターになる。
［２］４clock目でクライアントＢは、マスタークライアントＡの受信データをクライアントＢも受信開始。
［３］８clock目でクライアントＣが到着、マスタークライアントＡの受信データをクライアントＣも受信開始。
［４］マスタークライアントＡが受信終了（受信に要した時間：１０clock）。
［５］クライアントＢがクライアントＣよりも先に到着していたのでクライアントＢがマスターになる。
［６］１３clockでクライアントＤ到着。
［７］マスタークライアントＢのデータをクライアントＤも受信開始。
［８］マスタークライアントＢが受信終了（受信に要した時間：１０clock）。
［９］クライアントＣがクライアントＤよりも先に到着していたのでクライアントＣがマスタークライアントになる。
［１０］１７clock目でクライアントＣの受信終了（受信に要した時間：１０clock）
［１１］１８clock目でクライアントＤがマスターになり、２２clock目でクライアントＤで受信終了（受信に要した時間：１０clock）。
以上より、各クライアントの受信に要する時間は１０clockとなる。
【００１１】
上記のメカニズムではなく、クライアントが存在している間、データを最初から最後まで（図４の例ではシーケンス番号１から１０まで）繰り返してサーバから流す方法も考えられるが、この場合、先頭のデータが最後に送られる可能性もあり、より長いキュー長（バッファ量）が必要であり、さらに、先頭データから処理を行うようなアプリケーションにおいては不利である。本発明の実施形態の配信方法においてはマスターになった時点で、マスタークライアントが受け取ってないデータは、先頭の方から要求されるので、より先頭のデータから、各クライアント受信可能であり、省バッファ化および先頭から処理を行うようなアプリケーションにおいて有利である。
【００１２】
図５は、本発明の一実施形態であるサーバとクライアントの接続構成図である。図５の様に本実施形態のシステムは、データを配信するためのサーバ１、データを受信するためのクライアント２（クライアント２−１〜２−４）で構成される。クライアント２は、ここではクライアント２−１〜２−４の４台を想定するが、４台に限定されるものではない。ネットワークは、ルータやハブなどのネットワーク機器で構成されるものとする。本発明は、データリンク層以上のものであり、ネットワーク構成に依存しないが、説明のためネットワーク内でＩＰの転送を行うルータ３（ルータ３−１〜３−５）によって構成されるとする。なお同図は、サーバ１は１装置、クライアント２は４装置、ルータ３は５装置であるが、その数は１以上であればよい。それぞれの機器間の接続に利用されるネットワークは、アナログ回線、光ケーブル、電話網（ＩＳＤＮ、ＡＤＳＬ）などの通信手段を利用する。また、本実施形態では、既存のＩＰマルチキャスト技術を利用する。これは、マルチキャスト専用のＩＰアドレスを使えば、マルチキャストに参加しているクライアントに配布される技術である。マルチキャストグループへの登録は、従来の技術通りであり、クライアントは利用するマルチキャストＩＰアドレスを知っているものとする。本実施例は、下記を想定する。プロトコルスタックは、ｍＴＦＴＰに準拠して、Ｌ１（レイヤ１）、Ｌ２（レイヤ２）、ＩＰ、ＵＤＰの上にあるものとし、メッセージはＴＦＴＰのメッセージを利用する。但し、これは説明のためであり、これに限定されるものではない。
【００１３】
クライアント２の動作を図６のフローチャートを元に説明を行う。以下、図５のクライアント２−１が受信を行うとして説明する。
（１）まず、クライアント２−１は、欲しいファイルに関して、他のクライアントがサーバ１と通信をしているかどうか確認する（ステップ１）。通信があるかどうかは、マルチキャストＩＰアドレスに流れるメッセージ（パケット）をモニタすれば確認できる。
（２）クライアント２−１は、他のクライアントが通信中でかつ、自分がデータを受信したい場合（ステップ１で有の場合）、予約パケット（openパケット）をサーバに送信する（ステップ２）。サーバのところで後述するが、サーバはこの予約パケットをキューに入れ、マスタークライアントを選択する際に、キューの先頭にあるクライアントを取り出し、次のマスタークライアントになってもらうべくクライアントに要求パケットを送信する。
（３）他のクライアントの通信が無ければ（ステップ１で無の場合）、通常のＴＦＴＰと同様に、クライアント２−１がマスタークライアントになりopenパケットを送信しサーバ１へ配信を要求する（ステップ７）。
（４）ステップ１で他の通信が有った場合、ステップ２でopenパケットをサーバに送った後、クライアント２−１は他のマスタークライアントが要求している分のデータを受け取る（ステップ３）。
（５）他のマスタークライアント要求分のデータの受信を完了する（ステップ４）。
（６）全てのデータが揃っているかどうかを判断し（ステップ５）、全てのデータが揃えば受信を終了する（ステップ５でＹｅｓの場合）。
（７）揃わなければ（ステップ５でＮｏの場合）、サーバ１からマスタークライアントになるべく要求（request）パケットが届くか確認し（ステップ６）、届かずに、データの配信が始まれば、他のクライアントがマスタークライアントになったということで（ステップ６で無の場合）、データの受信を開始する（ステップ３）。
（８）サーバ１からマスタークライアントになるべく要求パケットが届いた場合（ステップ６で有の場合）、当該クライアント２−１は、マスタークライアントになり、サーバ１へ配信要求（openパケット）を行い（ステップ７）、データを受信する（ステップ８）。
（９）マスタークライアントになるべく要求がない場合（ステップ６で無の場合）は、ステップ３〜ステップ６を繰り返す。
【００１４】
サーバ１の動作を図７のフローチャートを元に説明を行う。
（１）まず、サーバ１は、クライアント２−１からのopenパケットを受信する（ステップ１）。
（２）openパケットの受信があれば、既存の通信が存在するか確認する（ステップ２）。
（３）既存の通信が有れば（ステップ２で有の場合）、openパケットを予約としてキューに入れる（ステップ３）。
（４）既存の通信が無ければ（ステップ２で無の場合）、新規通信を開始するため、クライアント２−１にマスタークライアントになってもらうべく、要求パケット（Requestパケット）を送信する（ステップ７）。
（５）ステップ３の後、既存の通信が完了した場合、キューから先頭のopenパケットを取り出し（これには、送信元のＩＰアドレスが書かれているので予約を送ったクライアントのＩＰアドレスが分かる）、そのopenパケットを送信したクライアントに対してマスタークライアントになるべく要求（Request）パケットを送る（ステップ４）。
（６）サーバ１がマスタークライアントになるよう要求したクライアントからのopenパケットであれば、そのクライアントをマスタークライアントとし通信を開始する（ステップ５）。
（７）そのマスタークライアントへの送信が完了する（ステップ６）。
（８）ステップ１〜ステップ６をキュー内のクライアントが無くなるまで繰り返す。
【００１５】
上記のメカニズムにより、時刻的に先にデータの受信の必要性が発生したクライアントからマスターにすることが可能となる。このようにして選ばれたマスタークライアントが要求するパケットの配信順序は、マルチキャストにおいてユニキャストと同等の配信時間を達成することが可能になる。
【００１６】
以上説明したように、本実施形態のマルチキャスト配信方法は、複数クライアントが同じデータを要求する際に、パケットの送信順序を制御することで、途中でマルチキャストに参加したクライアントにおいてもユニキャストと同等の受信時間でデータ全体の受信を可能とするものである。また、マルチキャスト配信プロトコルであるｍＴＦＴＰ（multicast Trivial File Transfer Protocol）においてマスターとなるクライアントを、受信を行いたいクライアント順に選ぶことで、ユニキャスト同等の受信時間でデータ全体の受信を可能とするものである。
【００１７】
本実施形態においては、サーバはクライアントからの配信要求パケット（openパケット）自体をキューに入れて配信要求の順番を記録しているが、その他の方法でクライアントからの配信要求の順番を記録するようにしてもよい。その場合、配信要求の順番と共に配信先（例えばＩＰアドレス）を記録する。また、本実施形態のクライアントとして、一般に使われているクライアントを使用することができるが、本実施形態のマルチキャスト配信方法専用に作成したクライアント、例えば、予約のための専用のパケットを配信要求パケットとして送信できるようにしたクライアントを使用してもよい。その場合は、サーバはそのパケットをキューに入れる、あるいはそのパケットの情報を使って順番と配信先を記録することになる。
【００１８】
図６、図７のフローチャートに基づいてプログラムを作成し、そのプログラムをコンピュータの記憶装置に格納して、前記実施形態のサーバおよびクライアントを構成することができる。
【００１９】
以上、本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００２０】
【図１】従来の技術の配信方法（配信順序とマスターの選択）を示す図である。
【図２】従来の技術の受信完了時間と分布を示す図である。
【図３】本発明の実施形態の受信完了時間と分布を示す図である。
【図４】本発明の実施形態の配信方法（配信順序とマスターの選択）を示す図である。
【図５】本発明の実施形態の構成図である。
【図６】本発明の実施形態のクライアントの動作を示す図（フローチャート）である。
【図７】本発明の実施形態のサーバの動作を示す図（フローチャート）である。
【符号の説明】
【００２１】
１…サーバ、２（２−１〜２−４）…クライアント、３（３−１〜３−５）…ルータ
【図１】
2006005871.tif 000003
【図２】
2006005871.tif 000004
【図３】
2006005871.tif 000005
【図４】
2006005871.tif 000006
【図５】
2006005871.tif 000007
【図６】
2006005871.tif 000008
【図７】
2006005871.tif 000009