(57)【特許請求の範囲】
【請求項１】
データベースを備えたサーバから、ネットワークを介してそのデータベースを利用する複数のクライアントにデータを配信する方法であって、
サーバは、クライアントから要求されたデータを複数のブロックに分割するとともにクライアントが順番通りにデータブロックを受け取れなかった場合でも再び元のファイルに構成できるようにするための再構成情報をデータブロックに付加し、先頭ブロックから順にデータベースからバッファに読み出して、バッファ上のデータブロックをクライアントに送信するものであり、その際、データをいくつのブロックに分割できるかを計算して最終ブロックが何番目か記憶し、クライアントに送信中のブロックが何番目か、及びクライアントに配信開始したブロックが何番目かクライアント毎に記憶し、第１のクライアントに配信している途中で第２のクライアントから同じデータについての配信要求が来た場合は、そのとき第１のクライアントに送信しているバッファ上のデータブロックから第２のクライアントに配信を開始し、その後、第１と第２のクライアントに並行して配信し、配信し終えたブロックが配信開始したブロックの１つ前のブロックか否かをクライアント毎に判定し、１つ前のブロックに至ったらそのクライアントを配信対象から除外するようにし、第１のクライアントに全ブロックを送信し終えたとき、第２のクライアントにすべてのブロックを送信していない場合は、再び先頭のブロックから順にデータベースから読み出して、残りのブロックを第２のクライアントに送信することを特徴とするデータ配信方法。
【請求項２】
データベースを備えたサーバと、ネットワークを介してそのデータベースを利用する複数のクライアントから成るデータ配信システムであって、
サーバは、配信するデータを複数のブロックに分割しするとともにクライアントが順番通りにデータブロックを受け取れなかった場合でも再び元のファイルに構成できるようにするための再構成情報をデータブロックに付加し、一連のブロックを先頭ブロックから順に最終ブロックへ、そして最終ブロックの次は先頭ブロックへと循環してデータベースからバッファにブロック単位に読み出し、そのバッファ上のデータブロックをクライアントに配信するようにし、その際、データをいくつのブロックに分割できるかを計算して最終ブロックが何番目か記憶し、クライアントに送信中のブロックが何番目か、及びクライアントに配信開始したブロックが何番目かクライアント毎に記憶し、第１のクライアントに配信している途中で第２のクライアントから同じデータについての配信要求が来た場合は、そのとき第１のクライアントに送信しているバッファ上のデータブロックから第２のクライアントに配信を開始し、その後、第１と第２のクライアントに並行して配信し、配信し終えたブロックが配信開始したブロックの１つ前のブロックか否かをクライアント毎に判定し、１つ前のブロックに至ったらそのクライアントを配信対象から除外するようにし、第１のクライアントに全ブロックを送信し終えたとき、第２のクライアントにすべてのブロックを送信していない場合は、再び先頭のブロックから順にデータベースから読み出して、残りのブロックを第２のクライアントに送信することを特徴とするデータ配信システム。
【請求項３】
データベースを備えたサーバから、ネットワークを介してそのデータベースを利用する複数のクライアントにデータを配信するようコンピュータを制御するプログラムであって、
サーバは、クライアントから要求されたデータを複数のブロックに分割し、先頭ブロックから順にデータベースからバッファに読み出し、クライアントが順番通りにデータブロックを受け取れなかった場合でも再び元のファイルに構成できるようにするための再構成情報をデータブロックに付加し、そのデータブロックをクライアントに送信し、その際、データをいくつのブロックに分割できるかを計算して最終ブロックが何番目か記憶し、クライアントに送信中のブロックが何番目か、及びクライアントに配信開始したブロックが何番目かクライアント毎に記憶し、第１のクライアントに配信している途中で第２のクライアントから同じデータについての配信要求が来た場合は、そのとき第１のクライアントに送信しているバッファ上のデータブロックから第２のクライアントに配信を開始し、その後、第１と第２のクライアントに並行して配信し、配信し終えたブロックが配信開始したブロックの１つ前のブロックか否かをクライアント毎に判定し、１つ前のブロックに至ったらそのクライアントを配信対象から除外するようにし、第１のクライアントに全ブロックを送信し終えたとき、第２のクライアントにすべてのブロックを送信していない場合は、再び先頭のブロックから順にデータベースから読み出して、残りのブロックを第２のクライアントに送信することを特徴とするデータ配信プログラムを記録した機械読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを利用したデータの配信技術に関する。
【０００２】
【従来の技術】
ＬＡＮを構成するクライアント／サーバシステムなどにおいて、ネットワークを利用してデータを配信する場合は、先ず、データを受けようとするクライアントがネットワークを介してサーバに接続し、データの配信を要求する。これに対し、サーバは、要求に合うデータをデータベースから個別に読み出し、配信していた。また、サーバにおいて、通常は、データベースから読み出したデータを一旦溜め込むキャッシュまたはバッファの大きさは、配信するデータベースのサイズより小さいので、データベースからの読み出しと送信を何度か繰り返して、１つのデータ配信を完了する。
【０００３】
【発明が解決しようとする課題】
多数のクライアントからデータ配信の要求が集中すると、サーバ側ではデータベースアクセスの負荷が増大する。このとき、第２のクライアントが要求するデータがたまたまキャッシュ上に存在すれば、直ちにそのデータを配信することができる。しかし、キャッシュの大きさをそれほど大きく取れないことや、多数のクライアントから時間的にばらばらに要求がくることなどにより、どうしてもデータベースアクセスが頻繁に発生する。そして、その結果、同時期にデータ配信を要求するクライアントの数にほぼ比例して、それぞれのクライアントに対するデータ配信の時間が長くなってしまう。これは同じデータベースに対して複数のクライアントから配信要求を受けた場合にも起こる問題である。
【０００４】
図３（ａ）に、同じデータベースに対して３つのクライアントから次々に配信要求が来た場合のタイミングチャートを示す。Ｃ１からＣ３はクライアントを表し、「Ａ」は配信要求の到着、「Ｒ」はデータベースアクセス、即ちデータベースからの読み出しを表す。そして、「Ｄ１」から「Ｄ４」が、その時点でバッファ上に分割して読み出されたデータブロックを表している。これはまた、それぞれのクライアントにとっては、配信されるデータブロックを表している。尚、ここでは、読み出しバッファが１つだけの最も単純な構成を想定し、為にデータベースは４回に分けて読み出される場合を例にする。
【０００５】
図から分るように、クライアントＣ１から配信要求が来ると、サーバはデータベースからデータブロックＤ１、Ｄ２、Ｄ３と読み出して、順にＣ１に向けて配信する。Ｄ３の配信中にクライアントＣ２から配信要求が来たので、クライアントＣ１に対するＤ４の配信の前に、クライアントＣ２に対するＤ１のデータベースアクセスが発生する。このとき、キャッシュ上にはＤ３があるが、利用されることはない。この結果、クライアントＣ１に対するＤ４の配信は待たされるので、それだけクライアントＣ１に対する配信時間は長くかかる。
【０００６】
さらに、クライアントＣ２への配信が終わらないうちに、クライアントＣ３からの配信要求が来たので、クライアントＣ２に対するＤ３の配信の前に、クライアントＣ３に対するＤ１のデータベースアクセスが発生する。このとき、キャッシュ上にＤ２があっても、やはり利用されることはない。以降は、クライアントＣ２とＣ３それぞれに対するデータベースアクセスが交互に発生してしまい、両クライアント共にデータの配信時間が長くなってしまう。図中の両矢印Ｔ１、Ｔ２、Ｔ３が、クライアントそれぞれの配信時間を示している。
【０００７】
【課題を解決するための手段】
本発明は、データベースを備えたサーバから、ネットワークを介してそのデータベースを利用する複数のクライアントにデータを配信する方法であって、サーバは、クライアントから要求されたデータを複数のブロックに分割するとともにクライアントが順番通りにデータブロックを受け取れなかった場合でも再び元のファイルに構成できるようにするための再構成情報をデータブロックに付加し、先頭ブロックから順にデータベースからバッファに読み出して、バッファ上のデータブロックをクライアントに送信するものであり、その際、データをいくつのブロックに分割できるかを計算して最終ブロックが何番目か記憶し、クライアントに送信中のブロックが何番目か、及びクライアントに配信開始したブロックが何番目かクライアント毎に記憶し、第１のクライアントに配信している途中で第２のクライアントから同じデータについての配信要求が来た場合は、そのとき第１のクライアントに送信しているバッファ上のデータブロックから第２のクライアントに配信を開始し、その後、第１と第２のクライアントに並行して配信し、配信し終えたブロックが配信開始したブロックの１つ前のブロックか否かをクライアント毎に判定し、１つ前のブロックに至ったらそのクライアントを配信対象から除外するようにし、第１のクライアントに全ブロックを送信し終えたとき、第２のクライアントにすべてのブロックを送信していない場合は、再び先頭のブロックから順にデータベースから読み出して、残りのブロックを第２のクライアントに送信することで、上記課題を解決するものである。
【０００８】
【実施例】
図１は、実施例のクライアント／サーバシステムの構成を示し、サーバからクライアントに向けてデータ配信するように、あらかじめプログラムされたコンピュータによってそれぞれ構成されている。１０はデータを配信する側のサーバであり、その内部にハードディスク等で構成したデータベース１１と、データベース読み出しの際にキャッシュとしても作用するバッファ１４と、クライアントからの要求を受けてデータを配信するファイル転送制御手段１３と、ヘッダ付加手段１２と、相手を指定してバッファ１４のデータを通信回線に送り出す送信手段１５とを有する。一方、２０はデータ配信を要求する側のクライアントであり、受信手段２１と、再構成手段２２と、ハードディスク等の記憶手段２３とを有する。そして、３０は通信回線である。尚、これは有線でも無線でも、また、ＬＡＮ、ＷＡＮ、インターネットなど、どのような構成でもよい。
【０００９】
サーバ１０は、クライアント２０からデータベース１１のデータ即ちファイルの配信要求を受けると、ファイル転送制御手段１３が先ず、当該ファイルのサイズと読み出しバッファ１４のサイズとから、いくつのデータブロックに分割して配信するか計算する。そして、ファイル全体の何番目のブロックかを示す情報を、ヘッダ付加手段１２によってそのデータブロックに付加する。これは、クライアント２０が順番通りにデータブロックを受け取れなかった場合でも、再び元のファイルに構成できるようにするための再構成情報である。そして、送信手段１５が、どのクライアントに送るかの宛先情報をそのデータブロックに付加して、通信回線３０に送り出す。尚、送信手段１５は、ハードウェアが備える複数の通信ポートにそれぞれ対応させて、複数のクライアントに並行してバッファ１４のデータを送ることができるようになっている。
【００１０】
一方、クライアント２０では、受信手段２１が自クライアント宛てのデータを受信し、記憶手段２３に記憶していく。そして、再構成手段２２は、受信したデータブロックのヘッダに含まれる再構成情報を参照し、元の順番通りにデータブロックを並べ替えるようにしている。こうして、元の順番通りに送られてこなかったデータブロックがあっても、再構成情報によって正しく元のファイルに戻すことができるものである。
【００１１】
サーバ１０は、複数のクライアントから相前後して配信要求を受けたとき、第２のクライアントが要求するファイルのデータブロックのどれかが、キャッシュ即ちバッファ１４上に既に読み出されて在るときは、それがファイルの先頭のデータブロックか否かに関係なく、第２のクライアントに配信し始めるようにしている。その為に、ファイル転送制御手段１３は、転送要求されたファイルがいくつのデータブロックに分けられるかを計算し、最終ブロックが何番目か、また、現在送信中のブロックが何番目か、そして、配信対象になっているクライアントそれぞれに配信開始したブロックが何番目であったか、を記憶する。その記憶内容の変化を、時刻を追って表にしたものを図４に示す。図では、配信開始ブロックをクライアントＣ１からＣ３について記憶しているが、配信対象となったクライアントに合わせてその都度、記憶場所を確保するようにしている。また、同じデータベースに対して、３つのクライアントから次々に配信要求が来た場合の実施例のタイミングチャートを、図３（ｂ）に示す。尚、図４は図３（ｂ）に対応している。
【００１２】
次に、実施例の動作を説明する。サーバ１０は、クライアントＣ１からファイルの配信要求を受け取ると、先ず、何ブロックに分けて送るかを計算し、最終ブロックと、Ｃ１に対する配信開始ブロックを決定して記憶する。そして、先頭データブロックＤ１をデータベース１１から読み出してＣ１に向けて送信する。従って、この時点では、図４からも分るように、配信開始ブロックと処理中ブロックは共にＤ１であり、最終ブロックはＤ４である。その後、当該ブロックの送信が終わった時刻ｔ１において、ファイル転送制御手段１３は、次に何番目のデータブロックを処理するか決定する。その手順を図２に示す。
【００１３】
ファイル転送制御手段１３は、先ず、配信し終えたデータブロックがそのファイルの最終ブロックか否かを判定する（ステップＳ１）。今回は最終ブロックではないので、次に、配信し終えたデータブロックが配信開始ブロックの１つ前のブロックか判定する（Ｓ６）。もしそうであれば、ぐるっと一回りして当該ファイルの全ブロックを送信したことになるので、そのクライアントを配信対象から外すのであるが、今回は、配信開始ブロックも処理中ブロックもＤ１なので、クライアントＣ１を対象から外すことはしない。そこで、次のブロック、即ちＤ２を処理中ブロックに設定する（Ｓ９）。この結果、データベース１１からはデータブロックＤ２がバッファ１４に読み出されて送信される。
【００１４】
続いて、ブロックＤ２の送信が終わった時刻ｔ２においても、Ｄ２は最終ブロックではなく（Ｓ１；Ｎｏ）、配信開始ブロックＤ１の１つ前でもないので（Ｓ６；Ｎｏ）、クライアントＣ１を対象から外すことなく、単に処理中ブロックをＤ３に進める（Ｓ９）だけとなる。そして、このＤ３の配信中に、クライアントＣ２からファイルの配信要求が来ている。ファイル転送制御手段１３は、先にＣ１が要求した同じファイルに対する配信要求であることを認識するので、現在、処理中ブロックに設定されているデータブロックＤ３を、クライアントＣ２にも配信するようにする。即ち、クライアントＣ２も配信対象とし、その配信開始ブロックＤ３を記憶しておいて、送信手段１５からはクライアントＣ１とＣ２に並行して、バッファ１４のデータブロックＤ３を配信する。
【００１５】
次に、ブロックＤ３の送信が終わった時刻ｔ３において、配信し終えたデータブロックがそのファイルの最終ブロックか否かを判定する（Ｓ１）が、今回もＤ３は最終ブロックではない。そこで、配信対象のすべてのクライアントについて、ステップＳ６のチェックを繰り返す。先ず、クライアントＣ１について、処理中ブロックが配信開始ブロックの１つ前か判定する。これは否であるので、クライアントＣ１は配信対象のままである。さらに、クライアントＣ２についても判定するが、配信開始ブロックがＤ３なので、クライアントＣ２も配信対象のままとし、最後に処理中ブロックをＤ４に設定する（Ｓ９）。この結果、データブロックＤ４がデータベース１１から読み出されて、クライアントＣ１とＣ２に並行して配信される。
【００１６】
そして、ブロックＤ４の送信が終わった時刻ｔ４においては、配信し終えたデータブロックがそのファイルの最終ブロックであると判定される。そこで、配信対象のすべてのクライアントについて、ステップＳ２のチェックを繰り返す。先ず、クライアントＣ１について、配信開始がファイルの先頭ブロック、即ちＤ１であったか判定する。図４にあるようにクライアントＣ１の配信開始ブロックはＤ１なので、ブロックを一巡してすべて配信したことになる。そこでクライアントＣ１を配信対象から外しておく（Ｓ３）。次に、クライアントＣ２について判定すると、こちらは配信開始ブロックがＤ３なので、配信対象からは外さない。最後に、処理対象のブロックを先頭ブロックＤ１に設定する（Ｓ５）。つまり、最終ブロックの次は先頭ブロックに戻すことで、一連のデータブロックを循環して、読み出しと送信を繰り返すのである。こうして、データベース１１からはデータブロックＤ１がバッファ１４に読み出されて、クライアントＣ２に送信されることになる。
【００１７】
さらに、時刻ｔ５では、ステップＳ１からＳ６に進むが、クライアントＣ２への配信は完了していない（Ｓ６；Ｎｏ）ので配信対象のままとし、処理中ブロックをＤ２に進めて（Ｓ９）配信する。
【００１８】
ここで、図３（ｂ）に示すように、このＤ２のＣ２への配信中に、クライアントＣ３からファイルの配信要求が来ると、ファイル転送制御手段１３は、現在、処理中ブロックに設定されているデータブロックＤ２を、クライアントＣ３にも配信する。即ち、クライアントＣ３を配信対象とし、その配信開始ブロックＤ２を記憶しておいて、送信手段１５からはクライアントＣ２とＣ３に向けて、バッファ１４のデータブロックＤ２を配信するのである。尚、このように、第２のクライアントへの送信が第１のそれより遅れて始まることもあるので、時刻ｔｎから時刻ｔ（ｎ＋１）までの時間は、多少伸び縮みするものである。
【００１９】
そして、時刻ｔ６に至って、ステップＳ６で、処理中ブロックＤ２がクライアントＣ２の配信開始ブロックの１つ前に一致し、同クライアントは配信対象から除外される（Ｓ７）。即ち、この時点でクライアントＣ２への配信は完了する。
一方、クライアントＣ３については、ステップＳ６の判定が成立しないので配信対象のままとなり、処理中ブロックは次のＤ３に設定される（Ｓ９）。
【００２０】
こうしてデータブロックＤ３がクライアントＣ３に送信され、さらにＤ４が送信された時刻ｔ８では、ステップＳ１からＳ２に進むが、クライアントＣ３の配信開始ブロックはＤ１ではないので、そのまま配信対象となり、処理中ブロックがＤ１に設定される（Ｓ５）。そして、そのＤ１を送信し終えた時刻ｔ９において、処理中ブロックがクライアントＣ３の配信開始ブロックの１つ前に一致し（Ｓ６；Ｙｅｓ）、同クライアントは配信対象から外されて配信が完了する。この結果、配信対象のクライアントがなくなって、すべての配信処理が終了する。
【００２１】
一方、クライアント２０の側では、受信するデータブロックは必ずしも順番通りではないので、データブロックのヘッダにある再構成情報により、再構成手段２２が正しく並べ替えてもとのファイルを再構成する。しかし、これは単純な作業であり、負荷とはならない。
【００２２】
このように、実施例では、データベース１１から読み出したデータブロックがファイルの先頭ブロックでなくても、サーバ１０はかまわずそれを要求したクライアント２２に配信する。そのため、バッファ１４のデータを有効に利用することができ、且つ、データベースアクセスが減って配信時間を大幅に短縮している。図３からも分るように、例えば、クライアントＣ２やＣ３に対する配信時間Ｔ２およびＴ３は、同図（ａ）に示した従来の方法に比べて、明らかに短くなっている。しかも、実施例では、クライアントＣ１乃至Ｃ３いずれの場合も、単独で配信したときの理想的な配信時間に遜色ない時間で、配信が完了している。これは、つまり、配信要求を出すタイミングに依存しないで、いつでも、どのクライアントにも、平均したほぼ理想に近い配信サービスができることを示している。
【００２３】
【発明の効果】
本発明によれば、データベースから読み出したバッファのデータを、有効に利用して同時に複数のクライアントに配信するので、データベースアクセスを大幅に減らすことができる。そして、ファイルを分割してそのデータブロックを途中からでも循環式に転送するようにし、受信したクライアント側で再構成するようにしたので、それぞれのクライアントに対する配信時間をほぼ理想的な時間に収めることができ、個々のクライアントに高水準の平均した配信サービスが可能になる。
【図面の簡単な説明】
【図１】実施例の構成を示すブロック図である。
【図２】実施例の動作を示すフローチャートである。
【図３】従来技術および実施例におけるタイミングチャートである。
【図４】実施例におけるサーバの記憶内容の変化を示す図である。
【符号の説明】
１０  サーバ    １１  データベース    １２  ヘッダ付加手段    １３  ファイル転送制御手段    １４  バッファ    １５  送信手段
２０  クライアント    ２１  受信手段    ２２  再構成手段    ２３  記憶手段
【図１】
0004623810.tif 000002
【図２】
0004623810.tif 000003
【図３】
0004623810.tif 000004
【図４】
0004623810.tif 000005