JPH1127648A - ビデオファイル配信方式 - Google Patents

Abstract

(57)【要約】 【課題】 コントロールサーバがクライアントから受け
取るビデオファイル配信要求の処理を分散することで、
ビデオファイル配信サービスが停止することを防ぎ、ク
ライアントへのサービス提供を円滑に行うことを目的と
する。 【解決手段】 ビデオファイルを配信するための複数の
ビデオサーバと、配信されたビデオファイルを受信して
再生する複数のクライアントと、クライアントからのビ
デオファイル配信要求に基づいて配信元となるビデオサ
ーバを決定する複数のコントロールサーバがネットワー
クで接続されたマルチメディアサーバシステムにおい
て、クライアントがコントロールサーバを優先順位付け
したコントロールサーバテーブルを保持し、このテーブ
ルに基づいて配信要求を送出するコントロールサーバを
決定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ビデオファイルを
リアルタイムで配信するビデオファイルの配信方式に関
し、中でも特に、ビデオファイル配信サーバの負荷を分
散することにより、配信サービスを円滑に行うことを目
的としたビデオファイルの配信処理方式に関するもので
ある。

【０００２】

【従来の技術】図１０は、従来例におけるマルチメディ
アサーバシステムの構成を示す図である。図では、複数
台のビデオサーバ、１台のコントロールサーバ、複数台
のクライアントから構成されるマルチメディアサーバシ
ステムにおいて、ビデオサーバが２台、クライアントが
３台からなる場合を示している。また、図において、１
０、１１はビデオサーバ、２０はコントロールサーバ、
３０、３１、３２はクライアントを示している。また、
４は、ビデオサーバ、コントロールサーバ、クライアン
トを相互に接続するＥｔｈｅｒｎｅｔのようなネットワ
ーク媒体である。

【０００３】次に、動作について説明する。クライアン
ト３０がビデオファイルの配信を要求する場合、その配
信要求はシステム内に１台だけ存在するコントロールサ
ーバ２０に対して行っていた。配信要求を受け取ったコ
ントロールサーバ２０は、コントロールサーバが保持し
ているビデオサーバ決定機構を利用して、ビデオサーバ
の負荷が分散するように配信元となるビデオサーバを決
定する。ここで、配信元となるビデオサーバが、ビデオ
サーバ１０に決定されたとして説明する。配信元ビデオ
サーバの決定後の処理には、次の２種類の方法がある。
一つは、決定したビデオサーバ１０に対してコントロー
ルサーバ２０が要求を出し、ビデオサーバ１０からクラ
イアント３０に対してビデオファイルを配信する方法で
ある。もう一つは、コントロールサーバ２０がクライア
ント３０に対して配信元がビデオサーバ１０となったこ
とを通知し、それを受け取ったクライアント３０が通知
されたビデオサーバ１０に対して配信要求を出し、最終
的にビデオサーバ１０が配信を開始するという方法であ
る。

【０００４】

【発明が解決しようとする課題】従来のマルチメディア
サーバシステムは以上のようにして構成されていたの
で、クライアントのすべての配信要求は、コントロール
サーバに集中することになる。そのため、コントロール
サーバが停止するなどして、クライアントからの配信要
求を処理出来ない状態になると、ビデオサーバ自身はビ
デオファイル配信が可能な状態にあっても、マルチメデ
ィアサーバシステム全体としては配信サービスが停止し
てしまうという問題点があった。また、クライアント数
が増加して配信要求が増加すると、ビデオサーバはビデ
オファイル配信をすぐに開始できる状態にあったとして
も、コントロールサーバの配信要求処理の負荷が増加し
て、クライアントがビデオファイル配信サービスの提供
を受けるまでの待ち時間が長くなってしまうという問題
点があった。

【０００５】この発明は上記のような問題点を解決する
ためになされたもので、複数台のビデオサーバ、コント
ロールサーバ、複数台のクライアントがネットワークに
より接続されているマルチメディアサーバシステムにお
いて、コントロールサーバがクライアントから受け取る
ビデオファイル配信要求の処理を分散することにより、
ビデオファイル配信サービスが停止することを防ぎ、ク
ライアントへのサービス提供を円滑に行うビデオファイ
ルの配信負荷の分散方式を提供することを目的とする。

【０００６】

【課題を解決するための手段】第１の発明に係わるビデ
オファイル配信方式は、ビデオファイルを配信するため
の複数のビデオサーバと、配信されたビデオファイルを
受信して再生する複数のクライアントと、クライアント
からのビデオファイル配信要求に基づいて配信元となる
ビデオサーバを決定する複数のコントロールサーバがネ
ットワークで接続されたマルチメディアサーバシステム
において、クライアントはコントロールサーバを優先順
位付けしたコントロールサーバテーブルを保持し、該テ
ーブルに基づいて配信要求を送出するコントロールサー
バを決定するようにしたものである。

【０００７】第２の発明は第１の発明に係わるビデオフ
ァイル配信方式において、各クライアントがシステムに
追加される際に、複数のコントロールサーバのうち一台
のコントロールサーバを記憶しておき、クライアントが
起動された時点で上記の記憶されたコントロールサーバ
からコントロールサーバテーブルを取得するようにした
ものである。

【０００８】第３の発明は第１の発明に係わるビデオフ
ァイル配信方式において、コントロールサーバテーブル
が、各クライアント毎に優先度の異なるコントロールサ
ーバテーブルを保持するようにしたものである。

【０００９】第４の発明は第３の発明に係わるビデオフ
ァイル配信方式において、各クライアントがシステムに
追加される際に、複数のコントロールサーバのうち一台
のコントロールサーバを記憶しておき、クライアントが
起動された時点で上記の記憶されたコントロールサーバ
から各クライアント毎に優先度の異なるコントロールサ
ーバテーブルを取得するようにしたものである。

【００１０】第５の発明は第３の発明に係わるビデオフ
ァイル配信方式において、各クライアントがシステムに
追加される際に、複数のコントロールサーバのうち一台
のコントロールサーバを記憶しておき、クライアントが
起動された時点で上記の記憶されたコントロールサーバ
の負荷の履歴情報に基づいて動的に生成されたコントロ
ールサーバテーブルを取得するようにしたものである。

【００１１】第６の発明に係わるビデオファイル配信方
式は、ビデオファイルを配信するための複数のビデオサ
ーバと、配信されたビデオファイルを受信して再生する
複数のクライアントと、クライアントからのビデオファ
イル配信要求に基づいて配信元となるビデオサーバを決
定する複数のコントロールサーバがネットワークで接続
されたマルチメディアサーバシステムにおいて、クライ
アントは配信要求を上記全てのコントロールサーバに対
して同報通信し、応答のあったコントロールサーバから
１台を選択して配信処理を行うようにしたものである。

【００１２】第７の発明は第６の発明に係わるビデオフ
ァイル配信方式において、コントロールサーバは該サー
バ間で優先権を設定し、優先権を保持しているコントロ
ールサーバのみがクライアントに対して応答するように
したものである。

【００１３】

【発明の実施の形態】

実施の形態１．本発明の第１の実施形態について、図１
乃至図３に基づいて説明する。図１は、本発明における
リアルタイムビデオファイル配信システムのシステム構
成の一例を表すブロック図である。図において、１０、
１１はビデオサーバ、２０、２１はコントロールサー
バ、３０乃至３２はクライアント、４はネットワークで
ある。ビデオサーバ、コントロールサーバ、クライアン
トはそれぞれ、システム上に複数台存在する。ビデオサ
ーバ１０と１１は、クライアント３０、３１、３２に対
して、リアルタイムにビデオファイルを配信する機能を
有する装置である。コントロールサーバ２０、２１は、
システム内に存在するビデオサーバ１０、１１から、ク
ライアントにビデオファイルを配信するためのビデオサ
ーバを選択する機能を有し、システム管理を行う装置で
ある。クライアント３０、３１、３２は、ビデオサーバ
１０と１１から配信するビデオファイルを受信し、再生
するための装置である。ネットワーク４は、ビデオサー
バ１０、１１、コントロールサーバ２０、２１、クライ
アント３０、３１、３２を接続しているＥｔｈｅｒｎｅ
ｔ等の媒体である。クライアント３０、３１、３２は、
コントロールサーバ２０、２１のいずれかに、ビデオフ
ァイル配信要求を行う。配信要求を受け取ったコントロ
ールサーバは、コントロールサーバが備えるビデオサー
バの負荷分散を実現するビデオサーバ決定機構を利用し
て、配信元となるビデオサーバを決定する。ここで、配
信元となるビデオサーバが、ビデオサーバ１０に決定し
たとして説明する。配信元ビデオサーバの決定後の処理
には、２種類の方法がある。一つは、決定したビデオサ
ーバ１０に対し、コントロールサーバ２０が要求を出
し、ビデオサーバ１０からクライアント３０に対してビ
デオファイルを配信する方法である。もう一つは、コン
トロールサーバ２０がクライアント３０に対して配信元
がビデオサーバ１０となったことを通知し、それを受け
取ったクライアント３０が通知されたビデオサーバ１０
に対して配信要求を出し、最終的にビデオサーバ１０が
配信を開始するという方法である。本実施形態では、ビ
デオサーバとクライアントは何台接続されていても良
い。一方、コントロールサーバは、２台以上接続されて
いる必要がある。また、ビデオサーバ、コントロールサ
ーバ、クライアントが相互に通信することが可能であれ
ば、ネットワークの接続形態は問わない。

【００１４】図２は、クライアント３０、３１、３２が
サービスを要求するコントロールサーバを決定する際に
使用するコントロールサーバテーブルの一例である。優
先度５１は、クライアントがビデオファイルの配信要求
を行うコントロールサーバの順序をあらわしている。コ
ントロールサーバ名５２は、優先度５１に対応するコン
トロールサーバ名を表わしており、システム内に存在す
る各コントロールサーバを一意に識別するための識別子
が記録されている。コントロールサーバ名５２には、シ
ステム内にある全てのコントロールサーバの識別子が一
覧されている。尚、各クライアントは同一のコントロー
ルサーバテーブルを保持している。

【００１５】図３は、クライアント３０、３１、３２
が、ビデオファイルの配信要求を行うコントロールサー
バを決定するためのフローチャートである。

【００１６】次に、フローチャートに基づいて動作につ
いて説明する。クライアント３０は、リアルタイムビデ
オファイル配信サービスの要求をユーザから受取る（ス
テップＦ１０１）。クライアント３０は、コントロール
サーバテーブルを調べ、最も高い優先度５１に対応する
コントロールサーバ名５２を選択し（ステップＦ１０
２）、ここで選択したコントロールサーバに対してビデ
オファイル配信を要求する（ステップＦ１０３）。ステ
ップＦ１０３で行った要求に対して、ステップＦ１０２
で選択したコントロールサーバが応答した場合（ステッ
プＦ１０４）には、引き続きクライアント３０と応答し
たコントロールサーバ間で配信処理が継続する（ステッ
プＦ１０５）。ステップＦ１０５では、コントロールサ
ーバがビデオサーバの負荷を考慮してビデオファイル配
信元となるビデオサーバを決定し、クライアント３０に
決定したビデオサーバ名を通知する。通知を受けたクラ
イアント３０は、指定されたビデオサーバに対してビデ
オファイル配信開始の要求を通知し、通知を受けたビデ
オサーバがビデオファイルの配信を開始する。配信開始
を確認したクライアントはステップＦ１０３で配信を要
求したコントロールサーバに対して配信が開始したこと
を通知し、配信開始の通知を受けたコントロールサーバ
は、ビデオファイル配信要求の処理結果を他のコントロ
ールサーバに対して通知する、という処理手順をとる。

【００１７】一方、ステップＦ１０４で応答がなかった
場合、コントロールサーバテーブルをもとに、現在の優
先度が最下位の優先度であるかどうかを調べる（ステッ
プＦ１０６）。優先度が最下位でない場合には、現在の
優先度よりも一つ優先度が低いコントロールサーバ名を
コントロールサーバテーブルから求め（ステップＦ１０
７）、選択したコントロールサーバに対してビデオファ
イル配信を要求する（ステップＦ１０３）。

【００１８】ステップＦ１０６で現在の優先度が最下位
であった場合には、ユーザに対して配信リクエストに応
じられない旨のエラーメッセージを返す（ステップＦ１
０８）。

【００１９】クライアント３０、３１、３２は、要求し
たビデオファイルの配信が終了するまで、配信要求を送
信したコントロールサーバ名を、配信要求の内容と関連
付けて保持しておき、配信要求を行ったビデオファイル
に対する操作に関しては、保持しているコントロールサ
ーバ名を使用することで、その都度コントロールサーバ
テーブルを検索することはしない。また、配信要求を行
ったビデオファイルがクローズされた時点で、そのビデ
オファイルに関連付けて保持しているコントロールサー
バ名を破棄する。

【００２０】コントロールサーバは、クライアントから
のビデオファイル配信要求を受理した場合には、そのビ
デオファイルがクローズされた時点で、他のコントロー
ルサーバに対して、配信が終了した旨を示す配信終了通
知を送信する。

【００２１】クライアント３０、３１、３２が保持する
コントロールサーバテーブルは、クライアントがシステ
ムに追加された際に設定されて、ファイルの形式で蓄積
され、検索の際にファイルから必要な情報を取得する
か、またはクライアント起動時にファイルからメモリへ
読み込むようにして、クライアントで保持される。

【００２２】あるいは、クライアント３０、３１、３２
がシステムに追加された際に、システム内にあるコント
ロールサーバのうち一台のコントロールサーバのみが識
別可能なように設定され、クライアントが起動された際
に識別可能なコントロールサーバに対してコントロール
サーバテーブル取得要求を出し、要求を受けたコントロ
ールサーバはコントロールサーバが保持している最新の
コントロールサーバテーブルを要求したクライアントに
対し送信し、クライアントは送信されたコントロールサ
ーバを受取り、起動中保持するようにしてもよい。

【００２３】以上のように、クライアントからのリクエ
ストを受け付けるコントロールサーバを複数台設け、コ
ントロールサーバテーブルに基づいてクライアントがビ
デオファイル配信要求を出すコントロールサーバを決定
し、配信要求を出すようにしたので、仮に一部のコント
ロールサーバが配信要求を受け付けることが出来ないよ
うな場合においても、クライアントからの配信要求処理
が可能となり、ビデオファイル配信サービスが停止する
虞がなくなる。

【００２４】実施の形態２．本発明の第２の実施形態に
ついて、図４に基づいて説明する。本実施形態は、図１
に示すシステム構成において、各クライアントは図２と
同様のコントロールサーバテーブルを持ち、クライアン
トのリクエスト処理は図３に従って実行するが、実施の
形態１とは異なり各クライアント毎に異なる優先順位付
けがなされたコントロールサーバテーブルを持つように
したものである。

【００２５】図４は、コントロールサーバ２０、２１
が、ビデオファイルの配信要求をクライアント３０、３
１、３２から受取った時の処理を示すフローチャートで
ある。

【００２６】次に、動作について説明する。コントロー
ルサーバは、クライアントからの配信要求を受信すると
（ステップＦ２０１）、起動してからの経過時間ｔｉ
が、他のコントロールサーバに配信要求処理通知を送信
するのに必要な時間を基準に設定された不応時間ｔｓの
２倍より大きいかどうかを判定する（ステップＦ２０
２）。２倍以上であったならば、最後にクライアントの
配信要求を受理してからの経過時間ｔｒが、不応時間ｔ
ｓよりも大きいかどうかを判定する（ステップＦ２０
３）。大きい場合には、最後に他のコントロールサーバ
から配信要求処理通知を受取ってからの経過時間ｔｃ
が、不応時間ｔｓの２倍より大きいかを判定する（ステ
ップＦ２０４）。大きい場合には、要求を受けた配信を
受理した場合に配信元となるビデオサーバの配信状態
が、ビデオサーバ毎に設定されている最大配信能力を超
えるかどうかを判定する（ステップＦ２０５）。

【００２７】ステップＦ２０２、Ｆ２０３、Ｆ２０４
で、条件が満たされない場合には、それぞれの条件を満
たすまで待機する（ステップＦ２０６、Ｆ２０７、Ｆ２
０８）。

【００２８】ステップＦ２０５で、配信要求受理後のビ
デオサーバの配信状態が最大配信能力を超えない場合に
は、コントロールサーバはクライアントに対し配信要求
を受理した旨の応答を行い、配信処理を継続する（ステ
ップＦ２０９）。配信開始に必要な処理が終了した時点
で、コントロールサーバは、他のコントロールサーバに
対して配信要求処理通知を送信する（ステップＦ２１
０）。

【００２９】一方、ステップＦ２０５で、配信要求受理
後のビデオサーバの配信状態が最大配信能力を超える場
合には、コントロールサーバはクライアントに対して配
信要求に応えられない旨を応答し、リクエスト処理を終
了する（ステップＦ２１１）。

【００３０】クライアント３０、３１、３２は、要求し
たビデオファイルの配信が終了するまで、配信要求を送
信したコントロールサーバ名を、配信要求の内容と関連
付けて保持しておき、配信要求を行ったビデオファイル
に対する操作に関しては、保持しているコントロールサ
ーバ名を使用することで、その都度コントロールサーバ
テーブルを検索することはしない。また、配信要求を行
ったビデオファイルがクローズされた時点で、そのビデ
オファイルに関連付けて保持しているコントロールサー
バ名を破棄する。

【００３１】コントロールサーバは、クライアントから
のビデオファイル配信要求を受理した場合には、そのビ
デオファイルがクローズされた時点で、他のコントロー
ルサーバに対して、配信が終了したことを示す配信終了
通知を送信する。

【００３２】各ビデオサーバの最大配信能力を示す値
は、コントロールサーバ間で送受される配信要求処理通
知、配信終了通知が遅延した場合に備えて、実際にビデ
オサーバが処理可能である配信能力よりも低い値に設定
しておく。

【００３３】クライアント３０、３１、３２が持つコン
トロールサーバテーブルは、クライアントをシステムに
接続した際に設定されてファイルの形式で蓄積され、検
索の際にファイルから必要な情報を取得するか、あるい
はクライアント起動時にファイルからメモリへ読み込む
ようにして、クライアントで保持される。

【００３４】あるいは、クライアント３０、３１、３２
は、システムに接続される際に、システム内にあるコン
トロールサーバのうち、一台のコントロールサーバのみ
が識別可能なように設定され、クライアントが起動した
際に識別可能なコントロールサーバに対し、コントロー
ルサーバテーブル取得の要求を出す。そして、要求を受
けたコントロールサーバは、コントロールサーバが保持
しているコントロールサーバテーブルを要求元のクライ
アントに対し送信し、クライアントは送信されたコント
ロールサーバを受取り、起動中保持しておくようにして
もよい。

【００３５】あるいは、クライアント３０、３１、３２
は、システムに接続される際に、システム内にあるコン
トロールサーバのうち、一台のコントロールサーバのみ
が識別可能なように設定され、クライアントが起動した
際に識別可能なコントロールサーバに対してコントロー
ルサーバテーブル取得の要求を出す。そして、要求を受
けたコントロールサーバは、その時のシステム内のビデ
オサーバの状態を元に、またはそれまでのコントロール
サーバの負荷状態の履歴情報に基づいて動的に生成した
コントロールサーバテーブルを、要求を出したクライア
ントに対し送信し、クライアントは送信されたコントロ
ールサーバを受取り、起動中保持するようにしてもよ
い。

【００３６】以上のように、クライアントからのリクエ
ストを受け付けるコントロールサーバを複数台設け、コ
ントロールサーバテーブルに基づいてクライアントがビ
デオファイル配信要求を出すコントロールサーバを決定
し、配信要求を出すようにしたので、仮に一部のコント
ロールサーバが配信処理を受け付けることが出来ないよ
うな場合においても、クライアントからの配信要求が処
理可能となり、ビデオファイル配信サービスが停止する
虞がなくなる。

【００３７】また、各クライアントが異なった優先順位
付けがされたコントロールサーバテーブルを保持するよ
うにしたので、クライアントの配信要求が複数台のコン
トロールサーバに分散して行われることになり、各コン
トロールサーバのリクエスト処理負荷を軽減することが
出来る。

【００３８】実施の形態３．本発明の第３の実施形態に
ついて、図５、図６に基づいて説明する。本実施形態
は、図１に示すシステム構成において、各クライアント
が１つの宛先に対してメッセージを送信した時にシステ
ム内の全てのコントロールサーバが受信して、同報処理
機能を実現するようにしたものである。

【００３９】図５は、クライアント３０、３１、３２
が、ビデオファイルの配信要求を行うコントロールサー
バを決定するためのフローチャートである。

【００４０】図６は、コントロールサーバ２０、２１
が、ビデオファイルの配信要求をクライアント３０、３
１、３２から受信した時の処理を示すフローチャートで
ある。

【００４１】次に、クライアントの動作について図５を
用いて説明する。クライアントは、リアルタイムビデオ
ファイル配信サービスの要求をユーザから受取ると（ス
テップＦ３０１）、全てのコントロールサーバが受信す
ることのできるコントロールサーバ同報用のアドレスを
使用して、全てのコントロールサーバに対して配信要求
を送信する（ステップＦ３０２）。一定期間、この要求
に対するコントロールサーバからの応答を待ち、応答の
有無を判定する（ステップＦ３０３）。応答があった場
合には、受信した応答内容が受理可能であるという応答
か否かを判定する（ステップＦ３０４）。 応答がなか
った場合には、ユーザに対して配信リクエストに応じら
れない旨のエラーメッセージを返す（ステップＦ３０
５）。

【００４２】ステップＦ３０４で受信した応答内容が受
理可能であった場合には、最初に受信した応答の送信元
であるコントロールサーバを以後の処理を依頼するコン
トロールサーバとして定め、このコントロールサーバが
担当になったことを示す担当依頼通知を、全てのコント
ロールサーバに対して同報する（ステップＦ３０６）。
引き続き、担当として定めたコントロールサーバとの間
で配信処理を継続する（ステップＦ３０７）。ステップ
Ｆ３０７では、コントロールサーバがビデオサーバの負
荷を考慮してビデオファイル配信元となるビデオサーバ
を決定し、クライアントに対して決定したビデオサーバ
名を通知する。通知を受けたクライアントは、指定され
たビデオサーバに対してビデオファイル配信開始の要求
を通知し、通知を受けたビデオサーバがビデオファイル
の配信を開始する、という処理手順をとる。

【００４３】ステップＦ３０４で、受取った応答が受理
不可能である旨の場合には、受理可能なコントロールサ
ーバがなかったことを示す担当依頼通知を全てのコント
ロールサーバに対して同報し（ステップＦ３０８）、ユ
ーザに対して配信リクエストに応じられないというエラ
ーメッセージを返す（ステップＦ３０５）。

【００４４】クライアント３０、３１、３２は、要求し
たビデオファイルの配信が終了するまで、配信処理担当
となったコントロールサーバ名を配信要求の内容と関連
付けて保持しておき、配信要求を行ったビデオファイル
に対する操作に関しては、コントロールサーバ名を保持
しているコントロールサーバに通知する。配信要求を行
ったビデオファイルがクローズする際には、全てのコン
トロールサーバに対して、配信が終了したことを示す配
信終了通知を同報する。

【００４５】配信要求を行ったビデオファイルをクロー
ズする際には、クライアントの代わりに、要求処理を行
っていたコントロールサーバが全てのコントロールサー
バに対して、配信が終了したことを示す配信終了通知を
同報してもよい。

【００４６】次に、コントロールサーバの動作について
図６を用いて説明する。コントロールサーバはクライア
ントからの配信要求を受信すると（ステップＦ４０
１）、要求を受けた配信を受理した場合に配信元となる
ビデオサーバの配信状態がビデオサーバ毎に設定されて
いる最大配信能力を超えるかどうかを判定する（ステッ
プＦ４０２）。

【００４７】ステップＦ４０２で、最大配信能力を超え
ない場合には、配信要求が受理可能であることをクライ
アントに対して応答し（ステップＦ４０３）、待機す
る。クライアントから担当依頼通知が送られてきたら
（ステップＦ４０４）、通知に記載されている担当コン
トロールサーバが自分であるかどうかを判定する（ステ
ップＦ４０５）。

【００４８】ステップＦ４０５で、担当となった旨の担
当依頼通知を受取った場合には、クライアントの間でリ
クエスト処理を継続して行う（ステップＦ４０６）。ス
テップＦ４０６では、コントロールサーバはビデオサー
バの負荷を考慮してビデオファイル配信元となるビデオ
サーバを決定し、クライアントに決定したビデオサーバ
名を通知する。通知を受けたクライアントが、指定され
たビデオサーバに対してビデオファイル配信開始の要求
を通知し、通知を受けたビデオサーバがビデオファイル
の配信を開始するといった処理を実行する。

【００４９】一方、担当でない旨の通知を受取った場合
（ステップＦ４０４、Ｆ４０５）には、他のコントロー
ルサーバが担当になったかどうかを判定する（ステップ
Ｆ４０７）。他のコントロールサーバが担当とならなか
った場合には、ビデオサーバに対して状態情報を問い合
わせる（ステップＦ４０８）。

【００５０】ステップＦ４０２で、最大配信能力を超え
る場合には、配信要求が受理出来ないことをクライアン
トに対して応答し（ステップＦ４０９）、待機する。ク
ライアントから担当依頼通知が送られてきたら（ステッ
プＦ４１０）、担当になったコントロールサーバがある
かどうかを判定し（ステップＦ４１１）、担当になった
コントロールサーバが存在する場合には、ビデオサーバ
に対して状態情報を問い合わせる（ステップＦ４０
８）。

【００５１】以上のように、クライアントからのリクエ
ストを受け付けるコントロールサーバを複数台設け、ク
ライアントがシステム内のコントロールサーバに対して
ビデオファイル配信要求を同報し、要求に応じられるコ
ントロールサーバが応答することによって、仮に一部の
コントロールサーバが配信処理を受け付けることが出来
ないような場合においても、クライアントからの配信要
求が処理可能となり、ビデオファイル配信サービスの停
止を回避することができる。

【００５２】また、各クライアントは同報用のアドレス
を通じてコントロールサーバと通信するため、ビデオフ
ァイル配信要求に先立って、個々のコントロールサーバ
のアドレスを把握しておく必要がないため、システムへ
のクライアントの追加削除、コントロールサーバの追加
削除の手間を軽減することが出来る。

【００５３】また、クライアントの配信要求が複数台の
コントロールサーバに分散して行われることになり、各
コントロールサーバのリクエスト処理負荷を軽減するこ
とが出来る。

【００５４】実施の形態４．本発明の第４の実施形態に
ついて、図７乃至図９に基づいて説明する。本実施形態
は図１に示すシステム構成において、各クライアントが
１つの宛先に対してメッセージを送信した時にシステム
内の全てのコントロールサーバが受信可能な同報機能を
有し、各コントロールサーバはシステム内のコントロー
ルサーバ間で優先権と呼ばれるクライアントからの配信
要求を処理すべきであるという証を循環するために、次
に優先権を渡すべきコントロールサーバ名を保持するよ
うにしたものである。

【００５５】図７は、クライアント３０、３１、３２
が、ビデオファイルの配信要求を行うコントロールサー
バを決定するためのフローチャートである。

【００５６】図８、図９は、コントロールサーバ２０、
２１が、ビデオファイルの配信要求をクライアント３
０、３１、３２から受取った時の処理を示すフローチャ
ートである。

【００５７】まず、クライアントの動作について、図７
を用いて説明する。クライアントは、リアルタイムビデ
オファイル配信サービスの要求をユーザから受取ると
（ステップＦ５０１）、全てのコントロールサーバが受
信可能なコントロールサーバ同報用のアドレスを使用し
て、全てのコントロールサーバに対して配信要求を送信
する（ステップＦ５０２）。一定期間、この要求に対す
るコントロールサーバからの応答を待ち、応答の有無を
判定する（ステップＦ５０３）。応答があった場合、受
取った応答が受理可能である旨の応答かどうかを判定す
る（ステップＦ５０４）。受理されなかった場合には、
ユーザに対して配信リクエストに応じられないというエ
ラーメッセージを返す（ステップＦ５０５）。

【００５８】ステップＦ５０４で、受取った応答が受理
可能を示す応答であった場合には、応答の送信元である
コントロールサーバとの間で配信処理を継続する（ステ
ップＦ５０６）。ステップＦ５０６で、コントロールサ
ーバがビデオサーバの負荷を考慮してビデオファイルの
配信元となるビデオサーバを決定し、クライアントに対
して決定したビデオサーバ名を通知する。通知を受けた
クライアントは、指定されたビデオサーバに対してビデ
オファイル配信開始の要求を通知し、通知を受けたビデ
オサーバがビデオファイルの配信を開始する、という処
理手順をとる。

【００５９】一方、ステップＦ５０３で、応答がなかっ
た場合には、配信要求を再度同報する（ステップＦ５０
７）。一定期間、この要求に対するコントロールサーバ
からの応答を待ち、応答があったかどうかを判定する
（ステップＦ５０８）。応答があった場合、最初に応答
があったコントロールサーバに対して、優先権授与通知
を送信する（ステップＦ５０９）。以後の処理は、ステ
ップＦ５０３で応答があったと判定された場合の処理と
同様である。

【００６０】ステップＦ５０８で、応答がなかった場合
には、ユーザに対して配信リクエストに応じられない旨
のエラーメッセージを返す（ステップＦ５０５）。

【００６１】次に、コントロールサーバの動作につい
て、図８、図９を用いて説明する。コントロールサーバ
は、クライアントからの配信要求を受信すると（ステッ
プＦ６０１）、以前受信したことのある配信要求である
か否かを、配信要求内に含まれる、システム内のクライ
アントを一意に決定するクライアント識別子、配信要求
を一意に決定する配信要求識別子をもとに判定する（ス
テップＦ６０２）。以前に受信したことのない配信要求
である場合、自分が優先権を持っているかどうかを判定
し（ステップＦ６０３）、優先権を持っていない場合に
は、再びクライアントから配信要求が送信されてくるま
で待機する。

【００６２】ステップＦ６０３で、優先権を持っている
場合には、要求を受けた配信を受理した場合に配信元と
なるビデオサーバの配信状態が、ビデオサーバ毎に設定
されている最大配信能力を超えるかどうかを判定する
（ステップＦ６０４）。

【００６３】ステップＦ６０４で、最大配信能力を超え
ない場合には、次に優先権を渡すことになっているコン
トロールサーバがシステム内でクライアントからの配信
要求を処理できる状態になっているかどうかを確認し
（ステップＦ６０５）、処理可能な状態の場合には、そ
のコントロールサーバに優先権を渡し（Ｆ６０６ステッ
プ）、クライアントに対し受理可能である旨を応答し、
クライアントとの間でリクエスト処理を継続して行う
（ステップＦ６０７）。ステップＦ６０７では、コント
ロールサーバはビデオサーバの負荷を考慮してビデオフ
ァイルの配信元となるビデオサーバを決定し、クライア
ントに決定したビデオサーバ名を通知する。通知を受け
たクライアントは、指定されたビデオサーバに対してビ
デオファイル配信開始の要求を通知し、通知を受けたビ
デオサーバがビデオファイルの配信を開始するといった
処理手順を実行する。

【００６４】ステップＦ６０５で、優先権を渡すことに
なっているコントロールサーバが処理可能な状態にない
場合には、ビデオサーバに対して状態情報を問い合わせ
（ステップＦ６０８）、クライアントに対し受理可能で
あることを応答し、クライアントとの間でリクエスト処
理を継続して行う（ステップＦ６０７）。

【００６５】ステップＦ６０４で、最大配信能力を超え
る場合には、配信要求が受理出来ない旨をクライアント
に対して応答し（ステップＦ６０９）、次に優先権を渡
すことになっているコントロールサーバがシステム内で
クライアントからの配信要求を処理できる状態になって
いるかどうかを確認し（ステップＦ６１０）、処理可能
な状態の場合には、そのコントロールサーバに優先権を
渡す（ステップＦ６１１）。

【００６６】ステップＦ６１０で、処理可能な状態にな
い場合には、ビデオサーバに対して状態情報を問い合わ
せる（ステップＦ６１２）。

【００６７】ステップＦ６０２において、以前に受信し
たことのある配信要求の場合には、配信要求を受理した
場合に配信元となるビデオサーバの配信状態が、ビデオ
サーバ毎に設定されている最大配信能力を超えるかどう
かを判定する（ステップＦ７０１）。最大配信能力を超
えない場合には、クライアントに対し受理可能である旨
を応答し（ステップＦ７０２）、待機する。

【００６８】待機中にクライアントから優先権授与通知
を受信した場合には（ステップＦ７０３）、自分が優先
権を保持するように設定し（ステップＦ７０４）、クラ
イアントとの間でリクエスト処理を継続して行う（ステ
ップＦ７０５）。優先権授与通知を受信しなかった場合
には終了する。

【００６９】ステップＦ７０１で、最大配信能力を超え
る場合には、配信要求を受理出来ない旨をクライアント
に対して応答する（ステップＦ７０６）。ステップＦ７
０７では、クライアントから優先権授与通知を待ち、受
信した場合には自分が優先権を持つように設定して（ス
テップＦ７０８）、終了し、またクライアントからの優
先権授与通知を受信しなかった場合には、そのまま終了
する。

【００７０】また、システム内にあるコントロールサー
バのうちの１台をプライムのコントロールサーバとして
定めておき、システムの起動時には、そのコントロール
サーバが優先権を持つようにする。

【００７１】あるいは、起動時には設定せず、クライア
ントとの配信要求を処理する中で（ステップＦ７０４、
Ｆ７０８）、設定するようにしてもよい。

【００７２】以上のように、クライアントからのリクエ
ストを受け付けるコントロールサーバを複数台設け、ク
ライアントがコントロールサーバに対してビデオファイ
ル配信要求を同報し、要求に応じられるコントロールサ
ーバが応答することによって、仮に一部のコントロール
サーバが配信処理を受け付けることが出来ないような場
合においても、クライアントからの配信要求を処理可能
となり、ビデオファイル配信サービスが停止することが
なくなる。

【００７３】また、各クライアントは同報用のアドレス
を通じてコントロールサーバと通信するため、ビデオフ
ァイル配信要求に先立って、個々のコントロールサーバ
のアドレスを把握しておく必要がないため、システムへ
のクライアントの追加削除、コントロールサーバの追加
削除の手間を軽減することが出来る。

【００７４】また、コントロールサーバ間で授受する優
先権を設定することで、特定のコントロールサーバに対
するクライアントからの配信要求処理が集中することを
防ぐことができる。

【００７５】

【発明の効果】以上のように、この発明によれば、コン
トロールサーバを複数台設け、コントロールサーバテー
ブルに基づいてビデオファイル配信要求を送出するよう
にしたので、安定したビデオファイル配信サービスを提
供できるという効果がある。

【００７６】また、この発明によれば、クライアントが
起動時に最新のコントロールサーバテーブルを自動的に
取得するようにしたので、システム構成変更にも柔軟に
対応することができるという効果がある。

【００７７】また、この発明によれば、各クライアント
は、配信要求をシステム内のコントロールサーバに分散
して送信するため、各コントロールサーバの負荷が軽減
し、ビデオファイル配信サービスを受けるまでの待ち時
間を軽減することが出来るという効果がある。

【００７８】さらに、この発明によれば、クライアント
が起動時にコントロールサーバの負荷の履歴情報に基づ
いて動的に生成されたコントロールサーバテーブルを取
得するようにしたので、特定のコントロールサーバへの
負荷の偏りを軽減することが出来るという効果がある。

【図面の簡単な説明】

【図１】 本発明のシステム構成を示す図である。

【図２】 本発明の第１の実施形態におけるコントロー
ルサーバテーブルを示す図である。

【図３】 本発明の第１の実施形態におけるクライアン
トがコントロールサーバを決定するためのフローチャー
ト図である。

【図４】 本発明の第２の実施形態におけるコントロー
ルサーバがクライアントから受取った配信要求を処理す
るためのフローチャート図である。

【図５】 本発明の第３の実施形態におけるクライアン
トがコントロールサーバを決定するためのフローチャー
ト図である。

【図６】 本発明の第３の実施形態におけるコントロー
ルサーバがクライアントから受取った配信要求を処理す
るためのフローチャート図である。

【図７】 本発明の第４の実施形態におけるクライアン
トがコントロールサーバを決定するためのフローチャー
ト図である。

【図８】 本発明の第４の実施形態におけるコントロー
ルサーバがクライアントから受取った配信要求を処理す
るためのフローチャート図である。

【図９】 本発明の第４の実施形態におけるコントロー
ルサーバがクライアントから受取った配信要求を処理す
るためのフローチャート図である。

【図１０】 従来のマルチメディアサーバシステムの構
成例を示す図である。

【符号の説明】

４ ネットワーク、１０、１１ ビデオサーバ、２０、
２１ コントロールサーバ、３０、３１、３２ クライ
アント、５１ 優先度記述部、５２ コントロールサー
バ名記述部。

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ビデオファイルを配信するための複数の
   ビデオサーバと、配信されたビデオファイルを受信して
   再生する複数のクライアントと、クライアントからのビ
   デオファイル配信要求に基づいて配信元となるビデオサ
   ーバを決定する複数のコントロールサーバがネットワー
   クで接続されたマルチメディアサーバシステムにおい
   て、 上記クライアントはコントロールサーバを優先順位付け
   したコントロールサーバテーブルを保持し、該テーブル
   に基づいて配信要求を送出するコントロールサーバを決
   定するようにしたことを特徴とするビデオファイル配信
   方式。
2. 【請求項２】 各クライアントはシステムに追加される
   際に、複数のコントロールサーバのうち一台のコントロ
   ールサーバを記憶しておき、クライアントが起動された
   時点で上記の記憶されたコントロールサーバからコント
   ロールサーバテーブルを取得するようにしたことを特徴
   とする請求項１記載のビデオファイル配信方式。
3. 【請求項３】 上記コントロールサーバテーブルは、各
   クライアント毎に優先度の異なるコントロールサーバテ
   ーブルを保持するようにしたことを特徴とする請求項１
   記載のビデオファイル配信方式。
4. 【請求項４】 各クライアントはシステムに追加される
   際に、複数のコントロールサーバのうち一台のコントロ
   ールサーバを記憶しておき、クライアントが起動された
   時点で上記の記憶されたコントロールサーバから各クラ
   イアント毎に優先度の異なるコントロールサーバテーブ
   ルを取得するようにしたことを特徴とする請求項３記載
   のビデオファイル配信方式。
5. 【請求項５】 各クライアントはシステムに追加される
   際に、複数のコントロールサーバのうち一台のコントロ
   ールサーバを記憶しておき、クライアントが起動された
   時点で上記の記憶されたコントロールサーバの負荷の履
   歴情報に基づいて動的に生成されたコントロールサーバ
   テーブルを取得するようにしたことを特徴とする請求項
   ３記載のビデオファイル配信方式。
6. 【請求項６】 ビデオファイルを配信するための複数の
   ビデオサーバと、配信されたビデオファイルを受信して
   再生する複数のクライアントと、クライアントからのビ
   デオファイル配信要求に基づいて配信元となるビデオサ
   ーバを決定する複数のコントロールサーバがネットワー
   クで接続されたマルチメディアサーバシステムにおい
   て、 上記クライアントは配信要求を上記全てのコントロール
   サーバに対して同報通信し、 応答のあったコントロールサーバから１台を選択して配
   信処理を行うようにしたことを特徴とするビデオファイ
   ル配信方式。
7. 【請求項７】 上記コントロールサーバは該サーバ間で
   優先権を設定し、優先権を保持しているコントロールサ
   ーバのみがクライアントに対して応答するよにしたこと
   を特徴とする請求項６記載のビデオファイル配信方式。