JP3725401B2 - アクセス振り分け方法、装置、及び記録媒体 - Google Patents
アクセス振り分け方法、装置、及び記録媒体 Download PDFInfo
- Publication number
- JP3725401B2 JP3725401B2 JP2000131369A JP2000131369A JP3725401B2 JP 3725401 B2 JP3725401 B2 JP 3725401B2 JP 2000131369 A JP2000131369 A JP 2000131369A JP 2000131369 A JP2000131369 A JP 2000131369A JP 3725401 B2 JP3725401 B2 JP 3725401B2
- Authority
- JP
- Japan
- Prior art keywords
- user terminal
- stream server
- stream
- isp
- connections
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上のコンテンツへのアクセスを振り分ける技術に関する。
【０００２】
【従来の技術】
近年、インターネット上でデータストリームを送信して番組を配信するインターネット放送が普及してきている。一般的に、ユーザはストリームサーバにアクセスすることによってインターネット放送を受信する。インターネット放送では、一時に多くのユーザが同一の番組の受信を希望することがあり、そのような場合に備え、インターネット放送提供側は複数のストリームサーバを複数拠点に設置することが多い。
【０００３】
また、インターネット放送に限らず、データダウンロードのためのＦＴＰサーバを負荷分散のために複数拠点に設置すること等が一般的に行われている。
【０００４】
従来の技術においては、ユーザがどのサーバからサービスを受けるかどうかを、例えばＷＷＷブラウザ画面上でサーバの拠点を選択することによって決定していた。
【０００５】
【発明が解決しようとする課題】
しかしながら、従来の技術によると、特定のサーバにアクセスが集中し、アクセスが多い場合にはそのサーバが過負荷となり、ユーザに十分なサービスが提供できないという問題点がある。また、サーバの同時アクセス数にライセンス数等の制限が設けられている場合には、そのライセンス数に達した後にアクセスしたユーザはサービスを受けられない。
【０００６】
また、特定のサーバからのデータストリームが集中することによってインターネットの輻輳をもたらし、一般のユーザに迷惑をかける恐れがある。更に、ユーザと、そのユーザがたまたま選択したサーバ間の経路がデータ伝送のために十分な容量をもたない場合には、インターネット放送を十分に視聴できなかったり、データダウンロードに長時間かかったりする等の問題点がある。
【０００７】
本発明は上記の点に鑑みてなされたものであり、ユーザからのアクセスを適切にコンテンツサーバに振り分ける方法、装置、記録媒体を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成するために本発明は次のように構成される。
【０００９】
請求項１に記載の発明は、 ネットワーク上の複数の場所にあるストリームサーバのうち特定の場所にあるストリームサーバにユーザ端末からのアクセスを振り分けるアクセス振り分け装置が実行する方法であって、前記アクセス振り分け装置が、前記ユーザ端末にコンテンツ選択画面を表示するステップと、前記アクセス振り分け装置が、ユーザがコンテンツを選択することによって前記ユーザ端末から送信されたリクエストデータから前記ユーザ端末の属するＩＳＰの識別子を取得するステップと、前記アクセス振り分け装置が、前記ユーザ端末のアクセス先となるストリームサーバの場所を前記ユーザ端末に通知する通知ステップとを有し、前記アクセス振り分け装置は、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの累積アクセス総数を所定の時間間隔で記録しておき、前記ユーザ端末からのリクエストデータを受けた時点で、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの当該時点の累積アクセス総数から、予め定めた１コネクション当たりのコネクション継続想定時間前の累積アクセス総数を引くことによりみなしコネクション数を求め、前記通知ステップにおいて、前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が予め定めた閾値を超えない場合に、前記ユーザ端末のアクセス先となるストリームサーバの場所として前記ユーザ端末の属するＩＳＰのストリームサーバの場所を前記ユーザ端末に通知し、前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が前記予め定めた閾値を超えた場合に、各ＩＳＰのストリームサーバ毎に、予め定められた最大コネクション数からみなしコネクション数を引いた値を求め、その値が最大となるストリームサーバの場所を前記ユーザ端末に通知することを特徴とする方法である。なお、ストリームサーバのことをコンテンツサーバとも呼ぶ。
【００１０】
本発明によれば、ほとんどの場合にユーザ端末からネットワーク的に近いコンテンツサーバにアクセスできるので、ネットワーク的に遠いコンテンツサーバにアクセスした場合のようにコンテンツデータが多数の回線区間を流れることがなくなり、ネットワークの混雑を削減することができる。また、コンテンツがコンテンツサーバからユーザ端末に流れる際にネットワークの混雑に遭遇する機会が削減されるので、ユーザは高速にコンテンツを取得でき、また、コンテンツがストリーム番組である場合には、高品質の番組を視聴できる。更に、特定のコンテンツサーバにアクセスが集中することも回避できる。
【００１３】
また、本発明によれば、アクセスしようとするストリームサーバの既存コネクション数がライセンス数上限に近い場合であっても、他のストリームサーバに振り分けるので、ユーザは待たずにコンテンツを取得できる。また、ストリームサーバの負荷分散を図ることができ、結果として、より多くのユーザにサービスを提供することが可能となる。
【００１４】
また、本発明によれば、コネクション継続時間を予め定め、それを同時コネクション数の算定に用いることとしたため、実際にユーザのコネクション時間を調べなくてもコネクション数を算定でき、容易かつ高速に処理を行うことが可能となる。ここで、コネクション継続時間は、例えば、経験上得た値を用いることができる。また、コンテンツの種類によってコネクション継続時間を設定により変更してもよい。
【００１５】
なお、ユーザ端末とコンテンツサーバ間のホップ数を求め、該ホップ数が所定の値より小さいコンテンツサーバの場所をユーザ端末に通知するステップを有するようにしてもよい。
【００１６】
本発明によれば、ホップ数の小さいコンテンツサーバに振り分けることができ、ユーザ端末からネットワーク的に近いコンテンツサーバにアクセスできるので、ネットワークの混雑が削減され、また、ユーザは高品質のサービスを受けることができる。
【００１７】
また、ユーザ端末からコンテンツサーバまでのネットワークの回線区間毎の帯域を求め、回線区間毎に該帯域に応じて重み付けをし、重み付けされた回線区間の和が所定の値より小さいコンテンツサーバの場所をユーザ端末に通知するステップを有するようにしてもよい。
【００２０】
請求項２に記載の発明は、請求項１の記載において、前記特定の場所にあるコンテンツサーバは１つ又は複数であり、複数である場合に、前記アクセス振り分け装置は、ラウンドロビンを用いて１つのコンテンツサーバを選択する。本発明によれば、特定の場所にあるコンテンツサーバ内の負荷分散を行うことができる。
請求項３〜請求項４に記載された発明は、本発明の方法の実施に適した装置であり、上記と同様の作用効果を奏する。請求項５〜請求項６に記載された発明は、本発明の方法の実施に適したプログラムを記録した記録媒体であり、そのプログラムをコンピュータ上で実行することによって上記と同様の作用効果を奏する。請求項７〜請求項８に記載された発明は、本発明の方法の実施に適したシステムであり、上記と同様の作用効果を奏する。
【００２１】
【発明の実施の形態】
図１は、本発明の一実施例におけるアクセス振り分けシステムの構成図である。本発明のアクセス振り分けシステムは、ユーザからのアクセスの振り分けを行う分散コントロールセンタ１、ユーザにストリーム（コンテンツともいう）を提供するストリームサーバ３、ユーザ端末５を有し、これらはインターネット７に接続される。なお、本実施例においてストリームサーバはスプリッタ又はコンテンツサーバともいう。また、本明細書において、単一のストリームサーバやコンテンツサーバが複数台集まってグループを形成する場合にも、そのグループを単にストリームサーバ、コンテンツサーバということがある。
【００２２】
分散コントロールセンタ１は、本実施例では複数台の分散コントロール装置９を有し、ユーザからのアクセスをハブ１１が各分散コントロール装置に振り分ける。これにより、分散コントロールセンタ内での負荷分散が図られる。なお、各分散コントロール装置が１台の場合にはハブは無くても良い。分散コントロール装置９はＷＷＷサーバ機能を有し、また、後述する負荷分散プログラム１３、スプリッタグループテーブル１５を有する。ストリームサーバ３は各ＩＳＰ（インターネットサービスプロバイダ）に設けら、各ＩＳＰではアクセス数に応じて複数のストリームサーバが設けられる。なお、本実施例では各ＩＳＰにおけるストリームサーバ全体をスプリッタグループという。ユーザ端末５は、ＷＷＷブラウザ１７及びストリーム再生プログラム１９を有し、本実施例では、分散コントロールセンタ１へのアクセスにはＷＷＷブラウザ１７が用いられ、ストリームの再生にはストリーム再生プログラム１９が用いられる。
【００２３】
分散コントロール装置としては一般的なコンピュータを用いることができ、その構成を図２に示す。本コンピュータは、処理を実行するＣＰＵ２１、プログラムやデータを記憶するメモリ２２、メモリ２２またはＣＰＵ２１で使用するプログラムやデータを蓄積するハードディスク２３、データを表示するディスプレイ２４、データまたは命令を入力するキーボード２５、ＣＤ−ＲＯＭドライブ２６、ネットワークを介して他のコンピュータシステム等と通信を行うための通信処理装置２７から構成される。本発明のアクセス振り分けを実行するプログラムはＣＤ−ＲＯＭドライブ２６を経由して、ハードディスク２３にロードされ、プログラムが起動されると、ＣＰＵ２１により実行される。本発明のアクセス振り分けを実行するプログラムは、コンピュータにプレインストールしてもよいし、ネットワークを介してロードすることもできる。
【００２４】
本実施例では、ストリームサーバは同時接続可能なライセンス数の上限を有している。また、ライセンス数上限はストリームサーバが送信するストリームの総数のみを制限し、１台のサーバで複数のコンテンツを送信する場合の各コンテンツのストリーム数を制限することはできない。ライセンス数が可変とすることもできる。
【００２５】
まず、図１に示したシステムの動作の概要を説明する。
【００２６】
ストリーム放送視聴を希望するユーザは分散コントロール装置９にアクセスを行う。分散コントロール装置９がユーザからのアクセスを受けると、負荷分散プログラム１３がスプリッタグループテーブル１５を参照し、どのストリームサーバ（スプリッタ）がアクセスしたユーザに近いかを計算する。そして、現在のストリームサーバのアクセス状況等を計算し、どのストリームサーバに接続させればよいかを決定し、ユーザのＷＷＷブラウザにその結果を返す。ユーザのブラウザはその結果を受け取り、その結果に示されたストリームサーバに対してアクセスを実行し、そこからストリーム放送を受ける。
【００２７】
どのストリームサーバ（スプリッタ）がアクセスしたユーザに近いかどうかは、本実施例では、ユーザ端末の属するＩＳＰで判断する。すなわち、ユーザ端末の属するＩＳＰを調べ、そのＩＳＰにあるストリームサーバに原則としてアクセスさせる。ＨＴＴＰプロトコルにおいてＩＳＰを識別するドメイン名を取得することは容易に行うことができる。このようにユーザ端末の属するＩＳＰと同一ＩＳＰからストリームデータを受信することによって、インターネットにおけるネットワーク負荷の増大を抑えることができる。また、一般的にＩＳＰを同一とすることによってストリームが通過すべき経路を短くできるので、ユーザは高い品質のストリームを受信することができる。
【００２８】
ここで、上記のストリームサーバが混雑し、設定したアクセス数の上限に達している場合には、他のＩＳＰのストリームサーバにアクセスさせる。すなわち、分散コントロール装置は、ストリームサーバ（スプリッタグループ）毎にアクセス状況を記録しておき、今現在あるストリームサーバには何人のユーザがいるかを計算しながら、ストリームサーバの負荷を均等にするようにユーザを適切なストリームサーバに誘導するようコントロールする。このアルゴリズムについては後述する。
【００２９】
次に、図３を用いてユーザ端末５、分散コントロール装置９、ストリームサーバ３間のデータシーケンスについて説明する。
【００３０】
まず、ユーザ端末が分散コントロール装置にアクセスすることによって、分散コントロール装置は番組選択画面をＷＷＷブラウザに送信する（ステップ１）。その画面データはコンテンツ識別子を含む。ユーザが番組選択画面で番組及びデータ転送速度を選択すると、その番組に対応したコンテンツ識別子が分散コントロール装置にＨＴＴＰリクエストとして送信される（ステップ２）。図４に番組選択画面の例を示し、図５には、図４の画面を表示させるためのＨＴＭＬ表記を示す。なお、図４の例は、既に番組が決定しており、速度を選択させる画面である。また、図６にはコンテンツ識別子の例を示している。
【００３１】
分散コントロール装置は、ＨＴＴＰリクエストを受信すると、コンテンツ識別子に含まれる情報を引数としてＣＧＩ（Common Gateway Interface）を動作させる。図６に示す例ではａｂｃｄと６４を引数としてＣＧＩが動作する。
【００３２】
ＣＧＩによって、コンテンツ識別子取得、ＲＡＭファイル決定、ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数取得、重み計算、送出スプリッタ決定、ＵＲＬ決定、ＵＲＬの送信を行う。それぞれの処理については後述する。ここで、ＲＡＭファイルとは、一般にはメタファイルといい、ユーザ端末のＷＷＷブラウザにヘルパアプリケーション（本実施例ではストリーム再生プログラム）を起動させ、ヘルパアプリケーションにコンテンツへのアクセスをさせるファイルである。
【００３３】
ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数とは、ユーザがどのＩＳＰを使用してアクセスしているかを識別する識別子である。例えば、ＡＢＣというプロバイダを使っている場合には、ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数はＡＢＣ．ｎｅ．ｊｐ等の識別子を含む。ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数を取得することによりユーザがどのＩＳＰを使用しているかを知ることができる。
【００３４】
重み計算とは、各ＩＳＰに設置されたストリームサーバの中で、どのストリームサーバが空いているかを計算する。上記の使用ＩＳＰ及びサーバの空き状況を勘案して、ユーザを誘導するストリームサーバのアドレスが決定され、そのアドレスからメタファイルＵＲＬを決定する。そして、そのメタファイルＵＲＬをユーザに返す（ステップ３）。
【００３５】
メタファイルＵＲＬは、Ｌｏｃａｔｉｏｎタグに含めてユーザ送信され、ＷＷＷブラウザでリダイレクトし、ＷＷＷブラウザからメタファイルＵＲＬにメタファイルの要求を行う（ステップ４）。メタファイルはユーザがサービスを受けるストリームサーバが記述されている。なお、メタファイルを置く場所はインターネット上であれば特に制限はない。また、リダイレクトさせず、ユーザにメタファイルＵＲＬを表示し、ユーザがそれをクリックすることによってメタファイルＵＲＬを取得することもできる。
【００３６】
ユーザ端末がメタファイルを受信すると（ステップ５）、ストリーム再生プログラムが起動され（ステップ６）、コンテンツの要求（本実施例ではＰＮＭリクエスト）をメタファイルに含まれていたストリームサーバのＵＲＬに向って送信する（ステップ７）。その要求を受信したストリームサーバ側は、応答（ＰＮＭ．ＲＥＳ）を返し（ステップ８）、その結果、ストリームデータがそのユーザ端末に配信される。
【００３７】
以下、アクセス振り分けのために分散コントロール装置が行う処理について説明する。下記のロジックは複数台の分散コントロール装置上で機能するものであり、その台数を多重度Ｗとしている。複数台の分散コントロール装置を使用することによって多数のアクセスを処理することができる。
【００３８】
図７は、アクセス振り分けのロジックにおいて使用されるパラメータを示す図である。分散コントロール装置は、各コンテンツ毎にこれらのパラメータを管理する。
【００３９】
スプリッタグループＰiはスプリッタ（ストリームサーバ）の属するＩＳＰを示す。アクセス数Ｎiは、各スプリッタグループに対してどれだけのアクセスがあったかを管理する数値である。例えば、あるユーザからＰ２のスプリッタグループにあるストリームサーバにアクセスがあった場合、Ｎ２が１だけインクリメントされる。コネクション数閾値ＣＴｉは、該当のスプリッタグループにユーザを接続させるか否かを判定するために用いられる閾値である。スプリッタ数Ｓiは各スプリッタグループ内に配置されているスプリッタ（ストリームサーバ）の数である。最大コネクション数Ｃiは、該当スプリッタグループが供給できるコネクション数の最大値である。Ｍを１スプリッタ当たりの最大同時コネクション数とすると、Ｃi＝Ｍ・Ｓiである。なお、最大コネクション数に対するコネクション数の余裕度がα（０＜α＜１）であり、ＣＴｉ＝αＣiである。
【００４０】
また、１スプリッタ当たりのライセンス数上限をＬとし、１コネクション当たりのライフタイムをΔＴとする。１コネクション当たりのライフタイムとは、１コネクションが継続すると想定される時間であり、通常５分〜１０分の値をとる。この数値は、ユーザが１つの番組を見続けるのは５分〜１０分であるということを意味する。
【００４１】
次に、アクセス振り分け処理について図８のフローチャートを用いて説明する。
【００４２】
フローチャートで示した処理の前提として、分散コントロール装置は、Δｔ（通常は１分）置きにスプリッタグループ毎にアクセスのあった絶対時刻のタイムスタンプと、そのときまでの累計アクセス数を記録する。本実施例では、保持するデータ量を少なくするという観点から、常に一定時間分ΔＴのデータしか残さないようにしている。すなわち、現在からΔＴ時間過去より前のデータは消去する。
【００４３】
あるスプリッタグループＰｋについてアクセス要求があると（ステップ１１）、すなわち、Ｐｋに対応するＩＳＰのユーザがアクセスすると、全てのｉ（１≦ｉ≦ｎ）について、すなわち、全てのスプリッタグループについて、みなしコネクション数を求める（ステップ１２）。
【００４４】
具体的には、現時点からΔＴ過去にさかのぼり、現時点までのアクセス総数Ｎi（Ｔ）からΔＴ前のアクセス総数Ｎi（Ｔ−ΔＴ）を引いて現在のみなしコネクション数Ｃi ‘とする。すなわち、Ｃi ‘＝Ｎi（Ｔ）−Ｎi（Ｔ−ΔＴ）である。ΔＴの定義から、ΔＴより近い時間の過去であればユーザはその番組を見ていると考えられるが、ΔＴより遠い過去であればもうその番組をみていないと考えられる。従って、Ｃi ‘を現在の見なしコネクション数とすることができる。
【００４５】
なお、閑散期等のため、ΔＴ前が記録されていなかった場合、現在に近い側に遡ってＮi（Ｔ−ｓ・Δｔ）（１≦ｓ≦ｍ）を調べ、Ｃi ‘＝Ｎi（Ｔ）−Ｎi（Ｔ−ｓ・Δｔ）とする。
【００４６】
次に、アクセスのあったスプリッタグループＰｋの見なしコネクション数Ｃｋ ‘が閾値ＣＴｋを越えるかどうかを調べる（ステップ１３）。見なしコネクション数Ｃｋ ‘が閾値ＣＴｋを越えないないときはそのままそのスプリッタグループにユーザを接続させる（ステップ１４）。すなわち、ストリームサーバのグループに余裕があると考えられるので、そのグループのうちのどれかのストリームサーバに接続させる。スプリッタグループに複数のストリームサーバが存在する場合に、どのサーバに接続させるかはラウンドロビン方式を用いる。これにより、アクセスの均一化を図ることができる。
【００４７】
Ｃｋ ‘が閾値ＣＴｋを超えたときは、まず、全てのｉについて、すなわち全てのスプリッタグループについて見なし空きコネクション数Ｅｉ＝Ｃｋ−Ｃｋ ‘を算出する（ステップ１５）。見なし空きコネクション数Ｅｉチェックすることによって、どのストリームサーバが空いているかの評価が行われる。
【００４８】
ステップ１６にて、全ての見なし空きコネクション数Ｅｉが負の値かどうかを調べる。全ての見なし空きコネクション数Ｅｉが負であれば、全てのストリームサーバについてライセンス数の上限を超えていると判断し、ｂｕｓｙメッセージを表示して、このユーザはストリームサーバに誘導しない（ステップ１７）。
【００４９】
正の値がある場合、正の見なし空きコネクション数Ｅｉ同士で比較し（ステップ１８）、最大値を有するスプリッタグループに接続させる（ステップ１９）。すなわち、Ｅｉが最大であることは最も空いていることを意味し、そのストリームサーバのグループにユーザを誘導することによって、ユーザに確実にサービスを提供でき、ストリームサーバへの負荷集中を避けることができる。
【００５０】
その後、振り分けられたスプリッタグループのアクセスカウンタを１増やす。次に、上記の処理について図９〜図１４を用いてより詳細に説明する。以下で説明する処理は、図３のステップ２で分散コントロール装置がコンテンツ識別子を受信し、ステップ３でメタファイルＵＲＬを返すに至るまでの処理である。
【００５１】
まず、ステップ２１〜２６にてユーザが指定したコンテンツと帯域に対応したメタファイルを取得する。なお、ＱＵＥＲＹ＿ＳＴＲＩＮＧにはコネクション識別子に含まれるコンテンツ名称と帯域が記述される。ステップ２４及びステップ２５で使用されるコンテンツテーブルの例を図１０に示す。図１０は各テーブルの構成及びそれらの関係を示しており、コンテンツテーブルはコンテンツ名と帯域とからなる。他のテーブルについては追って説明する。
【００５２】
ステップ２７〜２８にてＲＥＭＯＴＥ＿ＨＯＳＴを取得する。なお、ＲＥＭＯＴＥ＿ＨＯＳＴには前述したようにアクセスしたユーザが使用するプロバイダの識別子が含まれる。ステップ２９にてＲＥＭＯＴＥ＿ＨＯＳＴに対応するスプリッタグループをスプリッタグループテーブルで確認し、ステップ３０にて、そのスプリッタグループに対応したＩＳＰのユーザからアクセスがあった旨のインデックスを設定する（そのスプリッタグループをＪ＝１に設定）。なお、本実施例では、原則として、スプリッタグループテーブルに登録されたあるスプリッタグループに対応したＩＳＰのユーザからアクセスがあった場合には、そのスプリッタグループにユーザを接続させることとしているので、あるスプリッタグループに対応したＩＳＰのユーザから分散コントロールセンタにアクセスがあった場合、そのスプリッタグループにアクセスがあったという表現を用いる場合がある。図１０に示すように、スプリッタグループテーブルは、グループ名と、それに対応するドメイン名及び対応メタファイルＵＲＬからなる。
【００５３】
次に、ステップ３１〜ステップ４０にて、見なしコネクション数を計算する。ここでの平均接続時間が前述したΔＴである。なお、ステップ３９、４０は、閑散期等のため、ΔＴ前が記録されていなかった場合における処理である。ステップ３４におけるＮＬはスプリッタ（ストリームサーバ）当たりのライセンス総数であり、ＮＬ×スプリッタ数を分散コントロール装置多重数で除算することによって、分散コントロール装置１台あたりのスプリッタグループに対する振り分け数が求められる。なお、図９〜図１４に示すフローチャートにおいては、数をＮ、カウンタ値をＣで表す。例えば、ＮＳＰ，Ｊ＝１はＪ＝１と設定したスプリッタグループのスプリッタの数であり、ＮＬはスプリッタ１台当たりのライセンス数上限値であり、ＣＴ１’ , Ｊ＝１は最終（最新）のカウンタ値である。
【００５４】
ステップ３５で参照するカウンタテーブルの例は図１０に示されている。Δｔ間隔時間毎のアクセス総数（カウンタ数値）からなる。このカウンタテーブルはスプリッタグループ毎に存在する。
【００５５】
ステップ４１で、ライセンス使用率と見なし空きコネクション数を計算する。ステップ４２で、ライセンス使用率が使用率閾値より大きいかどうかをチェックする。
【００５６】
図９において、ステップ２７又はステップ２９で“いいえ”の場合、スプリッタグループテーブルに登録されたグループとは別のＩＳＰのユーザと判断し、図１１に示した処理を行う。
【００５７】
ステップ４３にて、スプリッタテーブルの最初のスプリッタグループを、Ｊ＝１に設定する。これは、アクセスしたユーザに対応するＩＳＰがテーブル内にない場合、原則としてテーブルの最初のスプリッタグループをアクセス先とすることとしたものである。ステップ４３〜ステップ５４は、図９のステップ３１〜ステップ４１の処理と同様である。なお、ステップ５４では、ステップ５１と異なりライセンス使用率の計算は行わない。
【００５８】
ステップ５４の後、もしくは、図９のステップ４２でライセンス使用率が使用率閾値より大きい場合、図１２に示した処理を行う。すなわち、図１２に示す処理は、スプリッタグループとして分散コントロール装置に登録されていないＩＳＰのユーザからのアクセスがあった場合、又は、指定スプリッタグループが混雑している場合に行われる処理である。
【００５９】
まず、ステップ５５〜ステップ６６の処理にて、全てのスプリッタグループについて見なし空きコネクション数を求める。なお、ＮＩはスプリッタグループの数である。続いて、ステップ６７にて見なし空きコネクション数が最大であるスプリッタグループを特定する（スプリッタグループインデックスをJ=ｋに設定する）。
【００６０】
次に図１３に示す処理を行う。ステップ６８にて、上記特定されたスプリッタグループにおけるストリームサーバ数が１か複数かを調べ、１であれば当該スプリッタグループの対応メタファイルＵＲＬを送信し（ステップ６９）、複数であればラウンドロビンで選択したサーバの対応メタファイルＵＲＬを送信する（ステップ７０）。その後、ステップ７１〜ステップ７５にて、現在時刻における当該スプリッタグループに対応するアクセスカウンタを１増加させ（ステップ７１、７２）、一定時間以前の時刻とカウンタ値を消去する（ステップ７３〜ステップ７５）。
【００６１】
図９におけるステップ４２で使用率が使用率閾値以下である場合には、図１４の処理を行う。図１４に示す処理は図１２に示した処理と同様であるので説明は省略する。
【００６２】
図１５はコンテンツテーブルの管理を行うための画面表示例である。識別番号をクリックすることによって、新規のコンテンツ名、そのコンテンツ提供のための帯域を入力することができ、入力によってコンテンツがコンテンツテーブルに登録される。
【００６３】
図１６はスプリッタグループテーブルの管理を行うための画面表示例である。グループ名、グループに対応したドメイン（要求先ドメイン）及びメタファイルＵＲＬを設定する。アクセスしたユーザの属するドメインが要求先ドメインの中に存在すれば、原則としてその要求先ドメインが属するグループのストリームサーバに接続される。その要求先ドメインが属するグループのストリームサーバが混雑している場合には、上述したアルゴリズムで別の接続先が選択される。また、サーバ当たりのライセンス数上限、分散コントロール装置の多重度、最大コネクション数に対する閾値、平均コネクション時間（ΔＴ）を設定することができる。
【００６４】
これまでに説明した実施例では、ユーザの属するドメイン名及びΔＴを用いたコネクション数の管理によってユーザのアクセス振り分けを行うが、コンテンツが流れるネットワークの状態を振り分け判断の要素として用いることも可能である。
【００６５】
例えば、ユーザからストリームサーバまでのホップ数（経由ルータ数）を判断の要素に加え、ホップ数の少ないストリームサーバを選択することとしてもよい。ホップ数による判断は、ドメイン名による振り分けの代りに行ってもよいし、ドメイン名による振り分けに加えた判断要素としてもよい。ホップ数は種々の方法で取得することができる。
【００６６】
また、ユーザ端末からコンテンツサーバまでのネットワークにおける回線区間の帯域を重み因子として考慮することもできる。例えば、ある回線区間（ルータ-ルータ間）の帯域が少なければその区間は他より大きな値で重み付けする等の方法で重み付けし、重み付けされた回線区間の総和をメトリック値として振り分けの判断に使用することができる。
【００６７】
本発明の振り分け方法はストリーミングに限らず適用できる。特に、ＦＴＰ等、データダウンロードに用いられるアプリケーションのように、ある程度コネクション時間が保たれるアプリケーションに効果的に適用できる。ＦＴＰの場合、ＦＴＰサーバに同時接続の上限を設定する場合も多く、その数をストリームサーバのライセンス数と同様に処理することにより、アクセス振り分けが可能となり、負荷分散が可能となる。また、ＦＴＰの場合には、端末側においてストリーミング再生プログラム立ち上げのような処理は行う必要が無く、ブラウザのみでデータ受信が可能である。従って、図３のシーケンス図において、例えば、ステップ３で目的データのＵＲＬを含ませ、ステップ４でＦＴＰサーバにデータを要求し、ステップ５でデータ取得を開始することができる。
【００６８】
また、ライセンス数を設定によって可変とし、スプリッタ１台当たりのコネクション数を増加させ、アクセスの増大に対応することも可能である。また、上記の実施例では見なし接続時間ΔＴを用いて接続数を把握したが、コンテンツサーバに分散コントロール装置がアクセスして、コンテンツサーバの負荷を取得し、振り分けに使用することもできる。すなわち、負荷の高いコンテンツサーバにはユーザを誘導しないようにする。更に、見なし接続時間ΔＴを用いず、ユーザがコネクションを終了した旨の情報を取得し、それによりコネクション数を把握して、振り分けを行うことも可能である。
【００６９】
また、ドメイン名による振り分けを行わずに、同時コネクション数で振り分けを行うようにすることもできる。複数のコネクションサーバがネットワーク的に近くにある場合における、負荷分散に効果的である。
【００７０】
更に、本発明は、ネットワーク上の複数のコンテンツサーバのうちどのサーバにアクセスするかを決定する場面であれば、インターネットに限らずどのようなネットワークにも適用できる。
【００７１】
本発明は、上記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。
【００７２】
【発明の効果】
上述したように、本発明によれば、ネットワーク的に近いサーバにユーザをアクセスさせることが可能となり、ネットワーク内の混雑の発生を抑え、なおかつ、ユーザに高品質のサービスを提供することが可能となる。
【００７３】
また、コンテンツサーバにコネクション数の制限がある場合に、コネクション数の上限に達したコンテンツサーバへのアクセスを回避し、空きコネクション数に余裕のあるコンテンツサーバに接続させることが可能となるので、コンテンツサーバ間の負荷分散、及び、より多くのユーザへのサービス提供が可能となる。
【図面の簡単な説明】
【図１】本発明の一実施例におけるアクセス振り分けシステムの構成図である。
【図２】コンピュータの構成図である。
【図３】ユーザ端末、分散コントロール装置、ストリームサーバ間のデータシーケンスを示す図である。
【図４】番組選択画面の例を示す図である。
【図５】図４の画面を表示させるためのＨＴＭＬ表記である。
【図６】コンテンツ識別子の例を示す図である。
【図７】アクセス振り分けのロジックにおいて使用されるパラメータを示す図である。
【図８】アクセス振り分け処理を示すフローチャートである。
【図９】アクセス振り分け処理を詳細に示すフローチャートである。
【図１０】テーブル構成を示す図である。
【図１１】アクセス振り分け処理を詳細に示すフローチャートである。
【図１２】アクセス振り分け処理を詳細に示すフローチャートである。
【図１３】アクセス振り分け処理を詳細に示すフローチャートである。
【図１４】アクセス振り分け処理を詳細に示すフローチャートである。
【図１５】コンテンツテーブルの管理を行うための画面表示例である。
【図１６】スプリッタグループテーブルの管理を行うための画面表示例である。
【符号の説明】
１ 分散コントロールセンタ
３ ストリームサーバ
５ ユーザ端末
７ インターネット
９ 分散コントロール装置
１１ ハブ
１３ 負荷分散プログラム
１５ スプリッタグループテーブル
１７ ＷＷＷブラウザ
１９ ストリーム再生プログラム
２１ ＣＰＵ
２２ メモリ
２３ ハードディスク
２４ ディスプレイ
２５ キーボード
２６ ＣＤ−ＲＯＭドライブ
２７ 通信処理装置
【発明の属する技術分野】
本発明は、ネットワーク上のコンテンツへのアクセスを振り分ける技術に関する。
【０００２】
【従来の技術】
近年、インターネット上でデータストリームを送信して番組を配信するインターネット放送が普及してきている。一般的に、ユーザはストリームサーバにアクセスすることによってインターネット放送を受信する。インターネット放送では、一時に多くのユーザが同一の番組の受信を希望することがあり、そのような場合に備え、インターネット放送提供側は複数のストリームサーバを複数拠点に設置することが多い。
【０００３】
また、インターネット放送に限らず、データダウンロードのためのＦＴＰサーバを負荷分散のために複数拠点に設置すること等が一般的に行われている。
【０００４】
従来の技術においては、ユーザがどのサーバからサービスを受けるかどうかを、例えばＷＷＷブラウザ画面上でサーバの拠点を選択することによって決定していた。
【０００５】
【発明が解決しようとする課題】
しかしながら、従来の技術によると、特定のサーバにアクセスが集中し、アクセスが多い場合にはそのサーバが過負荷となり、ユーザに十分なサービスが提供できないという問題点がある。また、サーバの同時アクセス数にライセンス数等の制限が設けられている場合には、そのライセンス数に達した後にアクセスしたユーザはサービスを受けられない。
【０００６】
また、特定のサーバからのデータストリームが集中することによってインターネットの輻輳をもたらし、一般のユーザに迷惑をかける恐れがある。更に、ユーザと、そのユーザがたまたま選択したサーバ間の経路がデータ伝送のために十分な容量をもたない場合には、インターネット放送を十分に視聴できなかったり、データダウンロードに長時間かかったりする等の問題点がある。
【０００７】
本発明は上記の点に鑑みてなされたものであり、ユーザからのアクセスを適切にコンテンツサーバに振り分ける方法、装置、記録媒体を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成するために本発明は次のように構成される。
【０００９】
請求項１に記載の発明は、 ネットワーク上の複数の場所にあるストリームサーバのうち特定の場所にあるストリームサーバにユーザ端末からのアクセスを振り分けるアクセス振り分け装置が実行する方法であって、前記アクセス振り分け装置が、前記ユーザ端末にコンテンツ選択画面を表示するステップと、前記アクセス振り分け装置が、ユーザがコンテンツを選択することによって前記ユーザ端末から送信されたリクエストデータから前記ユーザ端末の属するＩＳＰの識別子を取得するステップと、前記アクセス振り分け装置が、前記ユーザ端末のアクセス先となるストリームサーバの場所を前記ユーザ端末に通知する通知ステップとを有し、前記アクセス振り分け装置は、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの累積アクセス総数を所定の時間間隔で記録しておき、前記ユーザ端末からのリクエストデータを受けた時点で、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの当該時点の累積アクセス総数から、予め定めた１コネクション当たりのコネクション継続想定時間前の累積アクセス総数を引くことによりみなしコネクション数を求め、前記通知ステップにおいて、前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が予め定めた閾値を超えない場合に、前記ユーザ端末のアクセス先となるストリームサーバの場所として前記ユーザ端末の属するＩＳＰのストリームサーバの場所を前記ユーザ端末に通知し、前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が前記予め定めた閾値を超えた場合に、各ＩＳＰのストリームサーバ毎に、予め定められた最大コネクション数からみなしコネクション数を引いた値を求め、その値が最大となるストリームサーバの場所を前記ユーザ端末に通知することを特徴とする方法である。なお、ストリームサーバのことをコンテンツサーバとも呼ぶ。
【００１０】
本発明によれば、ほとんどの場合にユーザ端末からネットワーク的に近いコンテンツサーバにアクセスできるので、ネットワーク的に遠いコンテンツサーバにアクセスした場合のようにコンテンツデータが多数の回線区間を流れることがなくなり、ネットワークの混雑を削減することができる。また、コンテンツがコンテンツサーバからユーザ端末に流れる際にネットワークの混雑に遭遇する機会が削減されるので、ユーザは高速にコンテンツを取得でき、また、コンテンツがストリーム番組である場合には、高品質の番組を視聴できる。更に、特定のコンテンツサーバにアクセスが集中することも回避できる。
【００１３】
また、本発明によれば、アクセスしようとするストリームサーバの既存コネクション数がライセンス数上限に近い場合であっても、他のストリームサーバに振り分けるので、ユーザは待たずにコンテンツを取得できる。また、ストリームサーバの負荷分散を図ることができ、結果として、より多くのユーザにサービスを提供することが可能となる。
【００１４】
また、本発明によれば、コネクション継続時間を予め定め、それを同時コネクション数の算定に用いることとしたため、実際にユーザのコネクション時間を調べなくてもコネクション数を算定でき、容易かつ高速に処理を行うことが可能となる。ここで、コネクション継続時間は、例えば、経験上得た値を用いることができる。また、コンテンツの種類によってコネクション継続時間を設定により変更してもよい。
【００１５】
なお、ユーザ端末とコンテンツサーバ間のホップ数を求め、該ホップ数が所定の値より小さいコンテンツサーバの場所をユーザ端末に通知するステップを有するようにしてもよい。
【００１６】
本発明によれば、ホップ数の小さいコンテンツサーバに振り分けることができ、ユーザ端末からネットワーク的に近いコンテンツサーバにアクセスできるので、ネットワークの混雑が削減され、また、ユーザは高品質のサービスを受けることができる。
【００１７】
また、ユーザ端末からコンテンツサーバまでのネットワークの回線区間毎の帯域を求め、回線区間毎に該帯域に応じて重み付けをし、重み付けされた回線区間の和が所定の値より小さいコンテンツサーバの場所をユーザ端末に通知するステップを有するようにしてもよい。
【００２０】
請求項２に記載の発明は、請求項１の記載において、前記特定の場所にあるコンテンツサーバは１つ又は複数であり、複数である場合に、前記アクセス振り分け装置は、ラウンドロビンを用いて１つのコンテンツサーバを選択する。本発明によれば、特定の場所にあるコンテンツサーバ内の負荷分散を行うことができる。
請求項３〜請求項４に記載された発明は、本発明の方法の実施に適した装置であり、上記と同様の作用効果を奏する。請求項５〜請求項６に記載された発明は、本発明の方法の実施に適したプログラムを記録した記録媒体であり、そのプログラムをコンピュータ上で実行することによって上記と同様の作用効果を奏する。請求項７〜請求項８に記載された発明は、本発明の方法の実施に適したシステムであり、上記と同様の作用効果を奏する。
【００２１】
【発明の実施の形態】
図１は、本発明の一実施例におけるアクセス振り分けシステムの構成図である。本発明のアクセス振り分けシステムは、ユーザからのアクセスの振り分けを行う分散コントロールセンタ１、ユーザにストリーム（コンテンツともいう）を提供するストリームサーバ３、ユーザ端末５を有し、これらはインターネット７に接続される。なお、本実施例においてストリームサーバはスプリッタ又はコンテンツサーバともいう。また、本明細書において、単一のストリームサーバやコンテンツサーバが複数台集まってグループを形成する場合にも、そのグループを単にストリームサーバ、コンテンツサーバということがある。
【００２２】
分散コントロールセンタ１は、本実施例では複数台の分散コントロール装置９を有し、ユーザからのアクセスをハブ１１が各分散コントロール装置に振り分ける。これにより、分散コントロールセンタ内での負荷分散が図られる。なお、各分散コントロール装置が１台の場合にはハブは無くても良い。分散コントロール装置９はＷＷＷサーバ機能を有し、また、後述する負荷分散プログラム１３、スプリッタグループテーブル１５を有する。ストリームサーバ３は各ＩＳＰ（インターネットサービスプロバイダ）に設けら、各ＩＳＰではアクセス数に応じて複数のストリームサーバが設けられる。なお、本実施例では各ＩＳＰにおけるストリームサーバ全体をスプリッタグループという。ユーザ端末５は、ＷＷＷブラウザ１７及びストリーム再生プログラム１９を有し、本実施例では、分散コントロールセンタ１へのアクセスにはＷＷＷブラウザ１７が用いられ、ストリームの再生にはストリーム再生プログラム１９が用いられる。
【００２３】
分散コントロール装置としては一般的なコンピュータを用いることができ、その構成を図２に示す。本コンピュータは、処理を実行するＣＰＵ２１、プログラムやデータを記憶するメモリ２２、メモリ２２またはＣＰＵ２１で使用するプログラムやデータを蓄積するハードディスク２３、データを表示するディスプレイ２４、データまたは命令を入力するキーボード２５、ＣＤ−ＲＯＭドライブ２６、ネットワークを介して他のコンピュータシステム等と通信を行うための通信処理装置２７から構成される。本発明のアクセス振り分けを実行するプログラムはＣＤ−ＲＯＭドライブ２６を経由して、ハードディスク２３にロードされ、プログラムが起動されると、ＣＰＵ２１により実行される。本発明のアクセス振り分けを実行するプログラムは、コンピュータにプレインストールしてもよいし、ネットワークを介してロードすることもできる。
【００２４】
本実施例では、ストリームサーバは同時接続可能なライセンス数の上限を有している。また、ライセンス数上限はストリームサーバが送信するストリームの総数のみを制限し、１台のサーバで複数のコンテンツを送信する場合の各コンテンツのストリーム数を制限することはできない。ライセンス数が可変とすることもできる。
【００２５】
まず、図１に示したシステムの動作の概要を説明する。
【００２６】
ストリーム放送視聴を希望するユーザは分散コントロール装置９にアクセスを行う。分散コントロール装置９がユーザからのアクセスを受けると、負荷分散プログラム１３がスプリッタグループテーブル１５を参照し、どのストリームサーバ（スプリッタ）がアクセスしたユーザに近いかを計算する。そして、現在のストリームサーバのアクセス状況等を計算し、どのストリームサーバに接続させればよいかを決定し、ユーザのＷＷＷブラウザにその結果を返す。ユーザのブラウザはその結果を受け取り、その結果に示されたストリームサーバに対してアクセスを実行し、そこからストリーム放送を受ける。
【００２７】
どのストリームサーバ（スプリッタ）がアクセスしたユーザに近いかどうかは、本実施例では、ユーザ端末の属するＩＳＰで判断する。すなわち、ユーザ端末の属するＩＳＰを調べ、そのＩＳＰにあるストリームサーバに原則としてアクセスさせる。ＨＴＴＰプロトコルにおいてＩＳＰを識別するドメイン名を取得することは容易に行うことができる。このようにユーザ端末の属するＩＳＰと同一ＩＳＰからストリームデータを受信することによって、インターネットにおけるネットワーク負荷の増大を抑えることができる。また、一般的にＩＳＰを同一とすることによってストリームが通過すべき経路を短くできるので、ユーザは高い品質のストリームを受信することができる。
【００２８】
ここで、上記のストリームサーバが混雑し、設定したアクセス数の上限に達している場合には、他のＩＳＰのストリームサーバにアクセスさせる。すなわち、分散コントロール装置は、ストリームサーバ（スプリッタグループ）毎にアクセス状況を記録しておき、今現在あるストリームサーバには何人のユーザがいるかを計算しながら、ストリームサーバの負荷を均等にするようにユーザを適切なストリームサーバに誘導するようコントロールする。このアルゴリズムについては後述する。
【００２９】
次に、図３を用いてユーザ端末５、分散コントロール装置９、ストリームサーバ３間のデータシーケンスについて説明する。
【００３０】
まず、ユーザ端末が分散コントロール装置にアクセスすることによって、分散コントロール装置は番組選択画面をＷＷＷブラウザに送信する（ステップ１）。その画面データはコンテンツ識別子を含む。ユーザが番組選択画面で番組及びデータ転送速度を選択すると、その番組に対応したコンテンツ識別子が分散コントロール装置にＨＴＴＰリクエストとして送信される（ステップ２）。図４に番組選択画面の例を示し、図５には、図４の画面を表示させるためのＨＴＭＬ表記を示す。なお、図４の例は、既に番組が決定しており、速度を選択させる画面である。また、図６にはコンテンツ識別子の例を示している。
【００３１】
分散コントロール装置は、ＨＴＴＰリクエストを受信すると、コンテンツ識別子に含まれる情報を引数としてＣＧＩ（Common Gateway Interface）を動作させる。図６に示す例ではａｂｃｄと６４を引数としてＣＧＩが動作する。
【００３２】
ＣＧＩによって、コンテンツ識別子取得、ＲＡＭファイル決定、ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数取得、重み計算、送出スプリッタ決定、ＵＲＬ決定、ＵＲＬの送信を行う。それぞれの処理については後述する。ここで、ＲＡＭファイルとは、一般にはメタファイルといい、ユーザ端末のＷＷＷブラウザにヘルパアプリケーション（本実施例ではストリーム再生プログラム）を起動させ、ヘルパアプリケーションにコンテンツへのアクセスをさせるファイルである。
【００３３】
ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数とは、ユーザがどのＩＳＰを使用してアクセスしているかを識別する識別子である。例えば、ＡＢＣというプロバイダを使っている場合には、ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数はＡＢＣ．ｎｅ．ｊｐ等の識別子を含む。ＲＥＭＯＴＥ＿ＨＯＳＴ環境変数を取得することによりユーザがどのＩＳＰを使用しているかを知ることができる。
【００３４】
重み計算とは、各ＩＳＰに設置されたストリームサーバの中で、どのストリームサーバが空いているかを計算する。上記の使用ＩＳＰ及びサーバの空き状況を勘案して、ユーザを誘導するストリームサーバのアドレスが決定され、そのアドレスからメタファイルＵＲＬを決定する。そして、そのメタファイルＵＲＬをユーザに返す（ステップ３）。
【００３５】
メタファイルＵＲＬは、Ｌｏｃａｔｉｏｎタグに含めてユーザ送信され、ＷＷＷブラウザでリダイレクトし、ＷＷＷブラウザからメタファイルＵＲＬにメタファイルの要求を行う（ステップ４）。メタファイルはユーザがサービスを受けるストリームサーバが記述されている。なお、メタファイルを置く場所はインターネット上であれば特に制限はない。また、リダイレクトさせず、ユーザにメタファイルＵＲＬを表示し、ユーザがそれをクリックすることによってメタファイルＵＲＬを取得することもできる。
【００３６】
ユーザ端末がメタファイルを受信すると（ステップ５）、ストリーム再生プログラムが起動され（ステップ６）、コンテンツの要求（本実施例ではＰＮＭリクエスト）をメタファイルに含まれていたストリームサーバのＵＲＬに向って送信する（ステップ７）。その要求を受信したストリームサーバ側は、応答（ＰＮＭ．ＲＥＳ）を返し（ステップ８）、その結果、ストリームデータがそのユーザ端末に配信される。
【００３７】
以下、アクセス振り分けのために分散コントロール装置が行う処理について説明する。下記のロジックは複数台の分散コントロール装置上で機能するものであり、その台数を多重度Ｗとしている。複数台の分散コントロール装置を使用することによって多数のアクセスを処理することができる。
【００３８】
図７は、アクセス振り分けのロジックにおいて使用されるパラメータを示す図である。分散コントロール装置は、各コンテンツ毎にこれらのパラメータを管理する。
【００３９】
スプリッタグループＰiはスプリッタ（ストリームサーバ）の属するＩＳＰを示す。アクセス数Ｎiは、各スプリッタグループに対してどれだけのアクセスがあったかを管理する数値である。例えば、あるユーザからＰ２のスプリッタグループにあるストリームサーバにアクセスがあった場合、Ｎ２が１だけインクリメントされる。コネクション数閾値ＣＴｉは、該当のスプリッタグループにユーザを接続させるか否かを判定するために用いられる閾値である。スプリッタ数Ｓiは各スプリッタグループ内に配置されているスプリッタ（ストリームサーバ）の数である。最大コネクション数Ｃiは、該当スプリッタグループが供給できるコネクション数の最大値である。Ｍを１スプリッタ当たりの最大同時コネクション数とすると、Ｃi＝Ｍ・Ｓiである。なお、最大コネクション数に対するコネクション数の余裕度がα（０＜α＜１）であり、ＣＴｉ＝αＣiである。
【００４０】
また、１スプリッタ当たりのライセンス数上限をＬとし、１コネクション当たりのライフタイムをΔＴとする。１コネクション当たりのライフタイムとは、１コネクションが継続すると想定される時間であり、通常５分〜１０分の値をとる。この数値は、ユーザが１つの番組を見続けるのは５分〜１０分であるということを意味する。
【００４１】
次に、アクセス振り分け処理について図８のフローチャートを用いて説明する。
【００４２】
フローチャートで示した処理の前提として、分散コントロール装置は、Δｔ（通常は１分）置きにスプリッタグループ毎にアクセスのあった絶対時刻のタイムスタンプと、そのときまでの累計アクセス数を記録する。本実施例では、保持するデータ量を少なくするという観点から、常に一定時間分ΔＴのデータしか残さないようにしている。すなわち、現在からΔＴ時間過去より前のデータは消去する。
【００４３】
あるスプリッタグループＰｋについてアクセス要求があると（ステップ１１）、すなわち、Ｐｋに対応するＩＳＰのユーザがアクセスすると、全てのｉ（１≦ｉ≦ｎ）について、すなわち、全てのスプリッタグループについて、みなしコネクション数を求める（ステップ１２）。
【００４４】
具体的には、現時点からΔＴ過去にさかのぼり、現時点までのアクセス総数Ｎi（Ｔ）からΔＴ前のアクセス総数Ｎi（Ｔ−ΔＴ）を引いて現在のみなしコネクション数Ｃi ‘とする。すなわち、Ｃi ‘＝Ｎi（Ｔ）−Ｎi（Ｔ−ΔＴ）である。ΔＴの定義から、ΔＴより近い時間の過去であればユーザはその番組を見ていると考えられるが、ΔＴより遠い過去であればもうその番組をみていないと考えられる。従って、Ｃi ‘を現在の見なしコネクション数とすることができる。
【００４５】
なお、閑散期等のため、ΔＴ前が記録されていなかった場合、現在に近い側に遡ってＮi（Ｔ−ｓ・Δｔ）（１≦ｓ≦ｍ）を調べ、Ｃi ‘＝Ｎi（Ｔ）−Ｎi（Ｔ−ｓ・Δｔ）とする。
【００４６】
次に、アクセスのあったスプリッタグループＰｋの見なしコネクション数Ｃｋ ‘が閾値ＣＴｋを越えるかどうかを調べる（ステップ１３）。見なしコネクション数Ｃｋ ‘が閾値ＣＴｋを越えないないときはそのままそのスプリッタグループにユーザを接続させる（ステップ１４）。すなわち、ストリームサーバのグループに余裕があると考えられるので、そのグループのうちのどれかのストリームサーバに接続させる。スプリッタグループに複数のストリームサーバが存在する場合に、どのサーバに接続させるかはラウンドロビン方式を用いる。これにより、アクセスの均一化を図ることができる。
【００４７】
Ｃｋ ‘が閾値ＣＴｋを超えたときは、まず、全てのｉについて、すなわち全てのスプリッタグループについて見なし空きコネクション数Ｅｉ＝Ｃｋ−Ｃｋ ‘を算出する（ステップ１５）。見なし空きコネクション数Ｅｉチェックすることによって、どのストリームサーバが空いているかの評価が行われる。
【００４８】
ステップ１６にて、全ての見なし空きコネクション数Ｅｉが負の値かどうかを調べる。全ての見なし空きコネクション数Ｅｉが負であれば、全てのストリームサーバについてライセンス数の上限を超えていると判断し、ｂｕｓｙメッセージを表示して、このユーザはストリームサーバに誘導しない（ステップ１７）。
【００４９】
正の値がある場合、正の見なし空きコネクション数Ｅｉ同士で比較し（ステップ１８）、最大値を有するスプリッタグループに接続させる（ステップ１９）。すなわち、Ｅｉが最大であることは最も空いていることを意味し、そのストリームサーバのグループにユーザを誘導することによって、ユーザに確実にサービスを提供でき、ストリームサーバへの負荷集中を避けることができる。
【００５０】
その後、振り分けられたスプリッタグループのアクセスカウンタを１増やす。次に、上記の処理について図９〜図１４を用いてより詳細に説明する。以下で説明する処理は、図３のステップ２で分散コントロール装置がコンテンツ識別子を受信し、ステップ３でメタファイルＵＲＬを返すに至るまでの処理である。
【００５１】
まず、ステップ２１〜２６にてユーザが指定したコンテンツと帯域に対応したメタファイルを取得する。なお、ＱＵＥＲＹ＿ＳＴＲＩＮＧにはコネクション識別子に含まれるコンテンツ名称と帯域が記述される。ステップ２４及びステップ２５で使用されるコンテンツテーブルの例を図１０に示す。図１０は各テーブルの構成及びそれらの関係を示しており、コンテンツテーブルはコンテンツ名と帯域とからなる。他のテーブルについては追って説明する。
【００５２】
ステップ２７〜２８にてＲＥＭＯＴＥ＿ＨＯＳＴを取得する。なお、ＲＥＭＯＴＥ＿ＨＯＳＴには前述したようにアクセスしたユーザが使用するプロバイダの識別子が含まれる。ステップ２９にてＲＥＭＯＴＥ＿ＨＯＳＴに対応するスプリッタグループをスプリッタグループテーブルで確認し、ステップ３０にて、そのスプリッタグループに対応したＩＳＰのユーザからアクセスがあった旨のインデックスを設定する（そのスプリッタグループをＪ＝１に設定）。なお、本実施例では、原則として、スプリッタグループテーブルに登録されたあるスプリッタグループに対応したＩＳＰのユーザからアクセスがあった場合には、そのスプリッタグループにユーザを接続させることとしているので、あるスプリッタグループに対応したＩＳＰのユーザから分散コントロールセンタにアクセスがあった場合、そのスプリッタグループにアクセスがあったという表現を用いる場合がある。図１０に示すように、スプリッタグループテーブルは、グループ名と、それに対応するドメイン名及び対応メタファイルＵＲＬからなる。
【００５３】
次に、ステップ３１〜ステップ４０にて、見なしコネクション数を計算する。ここでの平均接続時間が前述したΔＴである。なお、ステップ３９、４０は、閑散期等のため、ΔＴ前が記録されていなかった場合における処理である。ステップ３４におけるＮＬはスプリッタ（ストリームサーバ）当たりのライセンス総数であり、ＮＬ×スプリッタ数を分散コントロール装置多重数で除算することによって、分散コントロール装置１台あたりのスプリッタグループに対する振り分け数が求められる。なお、図９〜図１４に示すフローチャートにおいては、数をＮ、カウンタ値をＣで表す。例えば、ＮＳＰ，Ｊ＝１はＪ＝１と設定したスプリッタグループのスプリッタの数であり、ＮＬはスプリッタ１台当たりのライセンス数上限値であり、ＣＴ１’ , Ｊ＝１は最終（最新）のカウンタ値である。
【００５４】
ステップ３５で参照するカウンタテーブルの例は図１０に示されている。Δｔ間隔時間毎のアクセス総数（カウンタ数値）からなる。このカウンタテーブルはスプリッタグループ毎に存在する。
【００５５】
ステップ４１で、ライセンス使用率と見なし空きコネクション数を計算する。ステップ４２で、ライセンス使用率が使用率閾値より大きいかどうかをチェックする。
【００５６】
図９において、ステップ２７又はステップ２９で“いいえ”の場合、スプリッタグループテーブルに登録されたグループとは別のＩＳＰのユーザと判断し、図１１に示した処理を行う。
【００５７】
ステップ４３にて、スプリッタテーブルの最初のスプリッタグループを、Ｊ＝１に設定する。これは、アクセスしたユーザに対応するＩＳＰがテーブル内にない場合、原則としてテーブルの最初のスプリッタグループをアクセス先とすることとしたものである。ステップ４３〜ステップ５４は、図９のステップ３１〜ステップ４１の処理と同様である。なお、ステップ５４では、ステップ５１と異なりライセンス使用率の計算は行わない。
【００５８】
ステップ５４の後、もしくは、図９のステップ４２でライセンス使用率が使用率閾値より大きい場合、図１２に示した処理を行う。すなわち、図１２に示す処理は、スプリッタグループとして分散コントロール装置に登録されていないＩＳＰのユーザからのアクセスがあった場合、又は、指定スプリッタグループが混雑している場合に行われる処理である。
【００５９】
まず、ステップ５５〜ステップ６６の処理にて、全てのスプリッタグループについて見なし空きコネクション数を求める。なお、ＮＩはスプリッタグループの数である。続いて、ステップ６７にて見なし空きコネクション数が最大であるスプリッタグループを特定する（スプリッタグループインデックスをJ=ｋに設定する）。
【００６０】
次に図１３に示す処理を行う。ステップ６８にて、上記特定されたスプリッタグループにおけるストリームサーバ数が１か複数かを調べ、１であれば当該スプリッタグループの対応メタファイルＵＲＬを送信し（ステップ６９）、複数であればラウンドロビンで選択したサーバの対応メタファイルＵＲＬを送信する（ステップ７０）。その後、ステップ７１〜ステップ７５にて、現在時刻における当該スプリッタグループに対応するアクセスカウンタを１増加させ（ステップ７１、７２）、一定時間以前の時刻とカウンタ値を消去する（ステップ７３〜ステップ７５）。
【００６１】
図９におけるステップ４２で使用率が使用率閾値以下である場合には、図１４の処理を行う。図１４に示す処理は図１２に示した処理と同様であるので説明は省略する。
【００６２】
図１５はコンテンツテーブルの管理を行うための画面表示例である。識別番号をクリックすることによって、新規のコンテンツ名、そのコンテンツ提供のための帯域を入力することができ、入力によってコンテンツがコンテンツテーブルに登録される。
【００６３】
図１６はスプリッタグループテーブルの管理を行うための画面表示例である。グループ名、グループに対応したドメイン（要求先ドメイン）及びメタファイルＵＲＬを設定する。アクセスしたユーザの属するドメインが要求先ドメインの中に存在すれば、原則としてその要求先ドメインが属するグループのストリームサーバに接続される。その要求先ドメインが属するグループのストリームサーバが混雑している場合には、上述したアルゴリズムで別の接続先が選択される。また、サーバ当たりのライセンス数上限、分散コントロール装置の多重度、最大コネクション数に対する閾値、平均コネクション時間（ΔＴ）を設定することができる。
【００６４】
これまでに説明した実施例では、ユーザの属するドメイン名及びΔＴを用いたコネクション数の管理によってユーザのアクセス振り分けを行うが、コンテンツが流れるネットワークの状態を振り分け判断の要素として用いることも可能である。
【００６５】
例えば、ユーザからストリームサーバまでのホップ数（経由ルータ数）を判断の要素に加え、ホップ数の少ないストリームサーバを選択することとしてもよい。ホップ数による判断は、ドメイン名による振り分けの代りに行ってもよいし、ドメイン名による振り分けに加えた判断要素としてもよい。ホップ数は種々の方法で取得することができる。
【００６６】
また、ユーザ端末からコンテンツサーバまでのネットワークにおける回線区間の帯域を重み因子として考慮することもできる。例えば、ある回線区間（ルータ-ルータ間）の帯域が少なければその区間は他より大きな値で重み付けする等の方法で重み付けし、重み付けされた回線区間の総和をメトリック値として振り分けの判断に使用することができる。
【００６７】
本発明の振り分け方法はストリーミングに限らず適用できる。特に、ＦＴＰ等、データダウンロードに用いられるアプリケーションのように、ある程度コネクション時間が保たれるアプリケーションに効果的に適用できる。ＦＴＰの場合、ＦＴＰサーバに同時接続の上限を設定する場合も多く、その数をストリームサーバのライセンス数と同様に処理することにより、アクセス振り分けが可能となり、負荷分散が可能となる。また、ＦＴＰの場合には、端末側においてストリーミング再生プログラム立ち上げのような処理は行う必要が無く、ブラウザのみでデータ受信が可能である。従って、図３のシーケンス図において、例えば、ステップ３で目的データのＵＲＬを含ませ、ステップ４でＦＴＰサーバにデータを要求し、ステップ５でデータ取得を開始することができる。
【００６８】
また、ライセンス数を設定によって可変とし、スプリッタ１台当たりのコネクション数を増加させ、アクセスの増大に対応することも可能である。また、上記の実施例では見なし接続時間ΔＴを用いて接続数を把握したが、コンテンツサーバに分散コントロール装置がアクセスして、コンテンツサーバの負荷を取得し、振り分けに使用することもできる。すなわち、負荷の高いコンテンツサーバにはユーザを誘導しないようにする。更に、見なし接続時間ΔＴを用いず、ユーザがコネクションを終了した旨の情報を取得し、それによりコネクション数を把握して、振り分けを行うことも可能である。
【００６９】
また、ドメイン名による振り分けを行わずに、同時コネクション数で振り分けを行うようにすることもできる。複数のコネクションサーバがネットワーク的に近くにある場合における、負荷分散に効果的である。
【００７０】
更に、本発明は、ネットワーク上の複数のコンテンツサーバのうちどのサーバにアクセスするかを決定する場面であれば、インターネットに限らずどのようなネットワークにも適用できる。
【００７１】
本発明は、上記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。
【００７２】
【発明の効果】
上述したように、本発明によれば、ネットワーク的に近いサーバにユーザをアクセスさせることが可能となり、ネットワーク内の混雑の発生を抑え、なおかつ、ユーザに高品質のサービスを提供することが可能となる。
【００７３】
また、コンテンツサーバにコネクション数の制限がある場合に、コネクション数の上限に達したコンテンツサーバへのアクセスを回避し、空きコネクション数に余裕のあるコンテンツサーバに接続させることが可能となるので、コンテンツサーバ間の負荷分散、及び、より多くのユーザへのサービス提供が可能となる。
【図面の簡単な説明】
【図１】本発明の一実施例におけるアクセス振り分けシステムの構成図である。
【図２】コンピュータの構成図である。
【図３】ユーザ端末、分散コントロール装置、ストリームサーバ間のデータシーケンスを示す図である。
【図４】番組選択画面の例を示す図である。
【図５】図４の画面を表示させるためのＨＴＭＬ表記である。
【図６】コンテンツ識別子の例を示す図である。
【図７】アクセス振り分けのロジックにおいて使用されるパラメータを示す図である。
【図８】アクセス振り分け処理を示すフローチャートである。
【図９】アクセス振り分け処理を詳細に示すフローチャートである。
【図１０】テーブル構成を示す図である。
【図１１】アクセス振り分け処理を詳細に示すフローチャートである。
【図１２】アクセス振り分け処理を詳細に示すフローチャートである。
【図１３】アクセス振り分け処理を詳細に示すフローチャートである。
【図１４】アクセス振り分け処理を詳細に示すフローチャートである。
【図１５】コンテンツテーブルの管理を行うための画面表示例である。
【図１６】スプリッタグループテーブルの管理を行うための画面表示例である。
【符号の説明】
１ 分散コントロールセンタ
３ ストリームサーバ
５ ユーザ端末
７ インターネット
９ 分散コントロール装置
１１ ハブ
１３ 負荷分散プログラム
１５ スプリッタグループテーブル
１７ ＷＷＷブラウザ
１９ ストリーム再生プログラム
２１ ＣＰＵ
２２ メモリ
２３ ハードディスク
２４ ディスプレイ
２５ キーボード
２６ ＣＤ−ＲＯＭドライブ
２７ 通信処理装置
Claims (8)
- ネットワーク上の複数の場所にあるストリームサーバのうち特定の場所にあるストリームサーバにユーザ端末からのアクセスを振り分けるアクセス振り分け装置が実行する方法であって、
前記アクセス振り分け装置が、前記ユーザ端末にコンテンツ選択画面を表示するステップと、
前記アクセス振り分け装置が、ユーザがコンテンツを選択することによって前記ユーザ端末から送信されたリクエストデータから前記ユーザ端末の属するＩＳＰの識別子を取得するステップと、
前記アクセス振り分け装置が、前記ユーザ端末のアクセス先となるストリームサーバの場所を前記ユーザ端末に通知する通知ステップとを有し、
前記アクセス振り分け装置は、
各ＩＳＰのストリームサーバ毎に、ストリームサーバへの累積アクセス総数を所定の時間間隔で記録しておき、前記ユーザ端末からのリクエストデータを受けた時点で、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの当該時点の累積アクセス総数から、予め定めた１コネクション当たりのコネクション継続想定時間前の累積アクセス総数を引くことによりみなしコネクション数を求め、
前記通知ステップにおいて、前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が予め定めた閾値を超えない場合に、前記ユーザ端末のアクセス先となるストリームサーバの場所として前記ユーザ端末の属するＩＳＰのストリームサーバの場所を前記ユーザ端末に通知し、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が前記予め定めた閾値を超えた場合に、各ＩＳＰのストリームサーバ毎に、予め定められた最大コネクション数からみなしコネクション数を引いた値を求め、その値が最大となるストリームサーバの場所を前記ユーザ端末に通知することを特徴とする方法。 - 前記特定の場所にあるストリームサーバは１つ又は複数であり、複数である場合に、前記アクセス振り分け装置は、ラウンドロビンを用いて１つのストリームサーバを選択する請求項１に記載の方法。
- ネットワーク上の複数の場所にあるストリームサーバのうち特定の場所にあるストリームサーバにユーザ端末からのアクセスを振り分けるアクセス振り分け装置であって、
前記ユーザ端末にコンテンツ選択画面を表示する手段と、
ユーザがコンテンツを選択することによって前記ユーザ端末から送信されたリクエストデータから前記ユーザ端末の属するＩＳＰの識別子を取得する手段と、
前記ユーザ端末のアクセス先となるストリームサーバの場所を前記ユーザ端末に通知する通知手段とを有し、
前記通知手段は、
各ＩＳＰのストリームサーバ毎に、ストリームサーバへの累積アクセス総数を所定の時間間隔で記録しておき、前記アクセス振り分け装置が前記ユーザ端末からのリクエストデータを受けた時点で、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの当該時点の累積アクセス総数から、予め定めた１コネクション当たりのコネクション継続想定時間前の累積アクセス総数を引くことによりみなしコネクション数を求め、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が予め定めた閾値を超えない場合に、前記ユーザ端末のアクセス先となるストリームサーバの場所として前記ユーザ端末の属するＩＳＰのストリームサーバの場所を前記ユーザ端末に通知し、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が前記予め定めた閾値を超えた場合に、各ＩＳＰのストリームサーバ毎に、予め定められた最大コネクション数からみなしコネクション数を引いた値を求め、その値が最大となるストリームサーバの場所を前記ユーザ端末に通知することを特徴とするアクセス振り分け装置。 - 前記特定の場所にあるストリームサーバは１つ又は複数であり、複数である場合に、前記通知手段は、ラウンドロビンを用いて１つのストリームサーバを選択する請求項３に記載のアクセス振り分け装置。
- ネットワーク上の複数の場所にあるストリームサーバのうち特定の場所にあるストリームサーバにユーザ端末からのアクセスを振り分ける処理をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記プログラムは、前記コンピュータを、
前記ユーザ端末にコンテンツ選択画面を表示する手段、
ユーザがコンテンツを選択することによって前記ユーザ端末から送信されたリクエストデータから前記ユーザ端末の属するＩＳＰの識別子を取得する手段、
前記ユーザ端末のアクセス先となるストリームサーバの場所を前記ユーザ端末に通知する通知手段として機能させるためのプログラムであり、
前記通知手段は、
各ＩＳＰのストリームサーバ毎に、ストリームサーバへの累積アクセス総数を所定の時間間隔で記録しておき、前記コンピュータが前記ユーザ端末からのリクエストデータを受けた時点で、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの当該時点の累積アクセス総数から、予め定めた１コネクション当たりのコネクション継続想定時間前の累積アクセス総数を引くことによりみなしコネクション数を求め、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が予め定めた閾値を超えない場合に、前記ユーザ端末のアクセス先となるストリームサーバの場所として前記ユーザ端末の属するＩＳＰのストリームサーバの場所を前記ユーザ端末に通知し、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が前記予め定めた閾値を超えた場合に、各ＩＳＰのストリームサーバ毎に、予め定められた最大コネクション数からみなしコネクション数を引いた値を求め、その値が最大となるストリームサーバの場所を前記ユーザ端末に通知することを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。 - 前記特定の場所にあるストリームサーバは１つ又は複数であり、複数である場合に、前記通知手段は、ラウンドロビンを用いて１つのストリームサーバを選択する請求項５に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
- ネットワーク上の複数の場所にあるストリームサーバと、それらストリームサーバのうち特定の場所にあるストリームサーバにユーザ端末からのアクセスを振り分けるアクセス振り分け装置とを有するアクセス振り分けシステムであって、
前記アクセス振り分け装置は、
前記ユーザ端末にコンテンツ選択画面を表示する手段と、
ユーザがコンテンツを選択することによって前記ユーザ端末から送信されたリクエストデータから前記ユーザ端末の属するドメインを取得する手段と、
前記ユーザ端末のアクセス先となるストリームサーバの場所を前記ユーザ端末に通知する通知手段とを有し、
前記通知手段は、
各ＩＳＰのストリームサーバ毎に、ストリームサーバへの累積アクセス総数を所定の時間間隔で記録しておき、前記アクセス振り分け装置が前記ユーザ端末からのリクエストデータを受けた時点で、各ＩＳＰのストリームサーバ毎に、ストリームサーバへの当該時点の累積アクセス総数から、予め定めた１コネクション当たりのコネクション継続想定時間前の累積アクセス総数を引くことによりみなしコネクション数を求め、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が予め定めた閾値を超えない場合に、前記ユーザ端末のアクセス先となるストリームサーバの場所として前記ユーザ端末の属するＩＳＰのストリームサーバの場所を前記ユーザ端末に通知し、
前記ユーザ端末の属するＩＳＰのストリームサーバのみなしコネクション数が前記予め 定めた閾値を超えた場合に、各ＩＳＰのストリームサーバ毎に、予め定められた最大コネクション数からみなしコネクション数を引いた値を求め、その値が最大となるストリームサーバの場所を前記ユーザ端末に通知することを特徴とするアクセス振り分けシステム。 - 前記特定の場所にあるストリームサーバは１つ又は複数であり、複数である場合に、前記アクセス振り分け装置はラウンドロビンを用いて１つのストリームサーバを選択する請求項７に記載のアクセス振り分けシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000131369A JP3725401B2 (ja) | 2000-04-28 | 2000-04-28 | アクセス振り分け方法、装置、及び記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000131369A JP3725401B2 (ja) | 2000-04-28 | 2000-04-28 | アクセス振り分け方法、装置、及び記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001312435A JP2001312435A (ja) | 2001-11-09 |
| JP3725401B2 true JP3725401B2 (ja) | 2005-12-14 |
Family
ID=18640279
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000131369A Expired - Fee Related JP3725401B2 (ja) | 2000-04-28 | 2000-04-28 | アクセス振り分け方法、装置、及び記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3725401B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050262253A1 (en) * | 2004-04-16 | 2005-11-24 | Qiang Li | Method and apparatus for a loosely coupled, scalable distributed multimedia streaming system |
| JP4688436B2 (ja) * | 2004-05-20 | 2011-05-25 | 株式会社日立製作所 | コンテンツ配信制御サーバの制御方法、コンテンツ暗号化サーバの制御方法、クライアント装置の制御方法、ライセンスサーバの制御方法、公開情報管理サーバの制御方法、クライアント装置、及びプログラム |
| JP5287342B2 (ja) * | 2009-02-25 | 2013-09-11 | 日本電気株式会社 | ジョブ管理装置、ジョブ管理方法及びジョブ管理システム |
| JP2012191373A (ja) * | 2011-03-10 | 2012-10-04 | Hitachi Ltd | 接続先ｌｎｓの接続状況に基づき、ｌｎｓに対する接続要求を振り分けるｌａｃ装置及びその接続先選択方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3709895B2 (ja) * | 1995-04-06 | 2005-10-26 | ソニー株式会社 | ミラーサイト情報サーバおよびミラーサイト情報提供方法 |
| JP2798009B2 (ja) * | 1995-07-21 | 1998-09-17 | 日本電気株式会社 | 回線負荷制御方法および制御システム |
| JP2962203B2 (ja) * | 1995-09-28 | 1999-10-12 | 日本電気株式会社 | オンライン情報処理システムにおける負荷分散方法 |
| JPH10307783A (ja) * | 1997-05-07 | 1998-11-17 | N T T Data:Kk | サイトアクセス制御システム及び記録媒体 |
| JP3369445B2 (ja) * | 1997-09-22 | 2003-01-20 | 富士通株式会社 | ネットワークサービスサーバ負荷調整装置、方法および記録媒体 |
| JPH11338836A (ja) * | 1998-05-25 | 1999-12-10 | Nippon Telegr & Teleph Corp <Ntt> | コンピュータネットワークの負荷分散システム |
| JP2000029813A (ja) * | 1998-07-14 | 2000-01-28 | Hitachi Ltd | サーバ選択システム |
-
2000
- 2000-04-28 JP JP2000131369A patent/JP3725401B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001312435A (ja) | 2001-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10154074B1 (en) | Remediation of the impact of detected synchronized data requests in a content delivery network | |
| KR101432303B1 (ko) | 대역 요구 장치, 클라이언트 기기, 대역 요구 방법 및 기록 매체 | |
| EP2704402B1 (en) | Method and node for distributing electronic content in a content distribution network | |
| US9549043B1 (en) | Allocating resources in a content delivery environment | |
| US6502125B1 (en) | System and method for optimized storage and retrieval of data on a distributed computer network | |
| EP0966715B1 (en) | System and method for selection and retrieval of diverse types of video data on a computer network | |
| US9071655B2 (en) | Managing access to digital content sources | |
| AU714865B2 (en) | System and method for optimized storage and retrieval of data on a distributed computer network | |
| JP2002506543A (ja) | 分散型コンピュータネットワーク上のデータ配信のサーバ側最適化のためのシステムおよび方法 | |
| JP2003223378A (ja) | コンテンツデリバリネットワークサービス方法及びシステム | |
| JP2002091843A (ja) | サーバ選択装置、サーバ選択方法、及びサーバ選択プログラムを記録した記録媒体 | |
| KR20060057525A (ko) | 데이터 제공자를 선택하는 시스템 및 방법 | |
| JP2012533938A (ja) | デジタルコンテンツ配布システム及び方法 | |
| JP2003186776A (ja) | 輻輳制御システム | |
| CN110417676A (zh) | 一种调度方法、装置和调度网络 | |
| CN101146114A (zh) | 一种流媒体服务器负荷分担方法及其系统 | |
| CN110445723A (zh) | 一种网络数据调度方法及边缘节点 | |
| CN106302230A (zh) | 一种数据传输方法及装置 | |
| JP3725401B2 (ja) | アクセス振り分け方法、装置、及び記録媒体 | |
| JP3964751B2 (ja) | ネットワーク品質推定制御方式 | |
| JP4309321B2 (ja) | ネットワークシステムの運用管理方法及びストレージ装置 | |
| JP2005182702A (ja) | Ｉｐネットワークにおけるアクセス制御方式 | |
| WO2007109074A2 (en) | Dynamic server configuration for managing high volume traffic | |
| JP5045227B2 (ja) | コンテンツの配信システム及び方法 | |
| JP2003242065A (ja) | コンテンツ選択、コンテンツ要求受付制御、輻輳制御方法およびコンテンツ管理装置、網リソース管理サーバ装置、ポータルサーバ装置、エッジ装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040203 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040402 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050628 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050829 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050920 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050921 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees | ||
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |