トップ :: H 電気 :: H04 電気通信技術




【発明の名称】 マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法
【発明者】 【氏名】君山 博之

【氏名】小倉 毅

【氏名】川野 哲生

【氏名】清水 健司

【氏名】丸山 充

【氏名】釘本 健司

【氏名】三宅 茂樹

【氏名】岡田 敦
【要約】 【課題】任意のレートのマルチメディアデータを無駄なく扱え、かつ、応答時間を出来るだけ早くする。

【構成】複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバにおいて、前記複数のマルチメディアデータを保存するストレージ（３）と、前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファ（２１）と、新規にリクエストが到着したことを示すフラグ（２４）と、前記フラグがセットされているか否かを判定し新規リクエストが到着したか否かを判定する判定手段と、前記ストレージから読み出され、かつ、前記バッファから未送信である未送信バッファ数を計数する計数手段１と、前記判定手段で新規リクエストが到着していると判定された場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行する手段とを備える。
【特許請求の範囲】
【請求項１】
複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバにおいて、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグと、
前記フラグがセットされているか否かを判定し新規リクエストが到着したか否かを判定する判定手段と、
前記ストレージから読み出され、かつ、前記バッファから未送信である未送信バッファ数を計数する計数手段１と、
前記判定手段で新規リクエストが到着していると判定された場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行する手段とを備えることを特徴とするマルチメディア蓄積配信サーバ。
【請求項２】
複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバにおいて、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグと、
前記フラグがセットされているか否かを判定し新規リクエストが到着したか否かを判定する判定手段と、
前記バッファの中で、前記端末から受信したマルチメディアデータを格納することができる未受信バッファ数を計数する計数手段２と、
前記判定手段で新規リクエストが到着していると判定された場合に、前記計数された前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行する手段とを備えることを特徴を有するマルチメディア蓄積配信サーバ。
【請求項３】
前記リクエストが送信リクエストである場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行し、
前記リクエストが受信リクエストである場合、前記計数された前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行することを特徴とする請求項１または請求項２に記載のマルチメディア蓄積配信サーバ。
【請求項４】
前記ストレージは、複数に分割されていることを特徴とする請求項１ないし請求項３のいずれか１項に記載のマルチメディア蓄積配信サーバ。
【請求項５】
前記マルチメディアデータを、前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶するキューと、
前記キューから順にリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行い、前記キューから全てのリクエストの処理が完了した際に、前記未受信バッファ数または前記未送信バッファ数を計数して、その数に基づき前記キュー内に格納されているリクエストの順序を入れ替える手段とを備えることを特徴とする請求項１ないし請求項４のいずれか１項に記載のマルチメディア蓄積配信サーバ。
【請求項６】
前記マルチメディアデータを、前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶する第１のキューと、
新規にリクエストが到着したことを示すフラグに代えて、リクエストを格納する第２のキューとを備え、
前記判定手段は、前記フラグがセットされているか否かを判定する代わりに前記第２のキューにリクエストが格納されているかどうかを判定して新規リクエストが到着したか否かを判定し、
前記第１のキューから順にリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行い、前記第１のキューに格納されているリクエストを全て処理した後、前記第１のキューと前記第２のキューを連結する手段とを備えることを特徴とする請求項１ないし請求項４のいずれか１項に記載のマルチメディア蓄積配信サーバ。
【請求項７】
複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバであって、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグとを備えるマルチメディア蓄積配信サーバにおけるマルチメディアデータ多重読出し書込み方法において、
前記端末から新規にリクエストが到着したことを示すフラグをセットするステップと、
前記フラグがセットされているかどうかを判定し新規リクエストが到着したか否かを判定する判定ステップと、
前記ストレージから読み出され未送信である前記マルチメディアデータが格納されている未送信バッファ数を計数するステップと、
前記判定ステップにおいて新規リクエストが到着していると判定された場合に、前記未送信バッファ数に基づき、前記ストレージから前記マルチメディアデータの読み出しを実行するステップとを備えることを特徴とするマルチメディアデータ多重読出し書込み方法。
【請求項８】
複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバであって、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグとを備えるマルチメディア蓄積配信サーバにおけるマルチメディアデータ多重読出し書込み方法において、
前記端末から新規にリクエストが到着したことを示すフラグをセットするステップと、
前記フラグがセットされているかどうかを判定し新規リクエストが到着したか否かを判定する判定ステップと、
前記端末から受信したマルチメディアデータを格納することが可能な未受信バッファ数を計数するステップと、
前記判定ステップにおいて新規リクエストが到着していると判定された場合に、前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行するステップとを備えることを特徴とするマルチメディアデータ多重読出し書込み方法。
【請求項９】
前記リクエストが送信リクエストである場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行し、
前記リクエストが受信リクエストである場合、前記計数された前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行することを特徴とする請求項７または請求項８に記載のマルチメディアデータ多重読出し書込み方法。
【請求項１０】
前記ストレージは、複数に分割されていることを特徴とする請求項７ないし請求項９のいずれか１項に記載のマルチメディアデータ多重読出し書込み方法。
【請求項１１】
マルチメディアデータを前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶するキューを備え、
前記キューから順にリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行うステップと、
前記キューから全てのリクエストの処理が完了した際に、前記未受信バッファ数または前記未送信バッファ数を計数して、その数に基づき前記キュー内に格納されているリクエストの順序を入れ替えるステップとを備えることを特徴とする請求項７ないし請求項１０のいずれか１項に記載のマルチメディアデータ多重読出し書込み方法。
【請求項１２】
前記マルチメディアデータを、前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶するキューと、
新規にリクエストが到着したことを示すフラグに代えて、リクエストを格納する第２のキューとを備え、
前記判定ステップは、前記フラグを判定する代わりに前記第２のキューにリクエストが格納されているかどうかを判定して新規するリクエストが到着したか否かを判定し、
前記第１のキューからリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行うステップと、
前記第１のキューに格納されているリクエストを全て処理した後、前記第１のキューと前記第２のキューを連結するステップを備えることを特徴とする請求項７ないし請求項１０のいずれか１項に記載のマルチメディアデータ多重読出し書込み方法。
【発明の詳細な説明】【技術分野】
【０００１】
本発明は、マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法に係り、特に、ストレージに蓄積されている任意のマルチメディアデータを、複数の端末に対し同時に決められたレートで連続的に送信、および、決められたレートで連続的に送信されている複数のマルチメディアデータを同時に受信し、ストレージに蓄債するマルチメディア蓄積配信サーバに適用して有効な技術に関する。
【背景技術】
【０００２】
複数の端末へネットワーク等を使って映像や音声などのマルチメディアデータを決められた送信レートで連続的に配信するサーバには、そのマルチメディアデータのＱｏＳ（Quality of service）を確保するため、マルチメディアデータが蓄積されているストレージ（または、蓄債装置）から、決められたレートで読み出す機能が必要である。もし、ストレージからの読み出しが間に合わなければ、端末へ送信するデータがなくなり映像や音声が途切れることになる。
決められたレートで読み出す機能を実現する従来の方式として、以下の２方式が知られている。
方式１．タイムスロット方式（非特許文献１参照）
方式２．キューイング方式（特許文献１参照）
まず、方式１のタイムスロット方式について説明する。タイムスロット方式の概念図を図１に示す。
このタイムスロット方式の特微は、図１に示すように、一定時間Ｔ０を１周期と設定し、その１周期を複数のタイムスロットＳ１〜Ｓ４に分割する。そして、端末Ａ１向けのマルチメディアデータをタイムスロットＳ１の間、端末Ａ２向けのマルチメディアデータをタイムスロットＳ２の間でストレージから読み出す。これを１周期ごとに繰り返し実行する。
例えば、一定時間Ｔ０を１秒、端末Ａ向けのマルチメディアデータの送信レートを１Ｍバイト／秒とすれば、タイムスロットＳ１の間で１Ｍバイトを読み出せば、端末Ａへ送信するデータが枯渇せずにＱｏＳを確保することが出来る。
【０００３】
次に、方式２のキューイング方式の概念図を図２に示す。タイムスロット方式と同様に一定時間Ｔ０を１周期と設定する。さらに、このキューイング方式の場合は、タイムスロットは設けずに端末Ａ１向けのマルチメディアデータを読み出し、次に端末Ａ２向けのマルチメディアデータを連続的に読み出していく。
そして、この処理を１周期ごとに実行することによって、端末へ送信するデータが枯渇することなくＱｏＳを確保することが出来る。
このキューイング方式（方式２）は、様々なレートの映像を無駄なく扱うことが出来るという利点がある。
また、タイムスロット方式（方式１）は、複数のストレージを並べ、かつ、先頭のデータを欠落させることによって、応答時間を早くすることが出来るメリットがある（非特許文献２）。
【０００４】
なお、本願発明に関連する先行技術文献としては以下のものがある。
【非特許文献１】テレビジョン学会誌 Vo1.48,No.3,pp.287-294：“多重読み取り可能なビデオオンデマンドシステム”
【特許文献１】特許第３４４７９７２号
【非特許文献２】電子情報通信学会論文誌 Vol.J79-D-II,No.10,pp.1686-1695：“高速応答ビデオサーバ向きの２層ディスクアレー方式”
【非特許文献３】Proc.IS&T and SPIE Electronic Imaging '97 Vol.3228,pp.147-157:“Distributed video server using new striping technique”
【非特許文献４】日経WinPC No.138（2006年2月号）P.43
【特許文献２】特許第３４６１２７８号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前述したこれらの方式１および方式２には、以下に示す問題がある。
（１）レート混在時の問題
（２）レスポンスの問題
第１の問題は、方式１のタイムスロット方式のみに起こる問題である。
タイムスロット方式の場合、１周期を固定数のタイムスロットに分割して、ストレージからの読み出し処理を行うため、最初に想定したレート以外で使用した場合、無駄な空き時間を作ることになる。つまり、従来技術で記載した例のように、秒当たり１Ｍバイトのレートで送信できるように、１周期を１秒として、１タイムスロットで１Ｍバイトのデータを読むことが出来るようにタイムスロットを設定したシステムを考える。
このシステムを利用して、１秒当たり、０．１Ｍバイトのマルチメディアデータを送ろうとすると、０．９Ｍバイト分、無駄な空き時間を作り、本来の送信能力を発揮することが不可能となる。
その無駄をさけるため、タイムスロットを細分化して、複数のタイムスロットを１つのスロットとして扱う方法も提案されているが（非特許文献３参照）、送信するマルチメディアデータの送信レートを制限しない限り、この無駄な空き時間を完全に無くすことは不可能である。
第２の課題は、方式２のキューイング方式のみに起こる問題である。
キューイング方式の場合、任意のレートのマルチメディアデータに対応可能である。その反面、新しく到着した送信リクエストをキューの最後で処理する必要がある。キューの途中で処理してしまうと、この時点で受け付けていた端末への読み出しが中断されてしまうため、送信データがなくなり、端末でデータが途切れることとなる。
【０００６】
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法において、任意のレートのマルチメディアデータを無駄なく扱え、かつ、応答時間を出来るだけ早くするための技術を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【課題を解決するための手段】
【０００７】
本発明の概略システム構成を図３に示す。
同図において、１はマルチメディアデータを受信して再生する端末、２はマルチメディアデータを送信するサーバ（本発明のマルチメディア蓄積配信サーバ）、３はマルチメディアデータが格納されたストレージ、４はネットワークである。２１は一時的にその情報を格納する複数のバッファ、２２はネットワークインタフェースカードである。バッファ２１は送信する端末毎に複数用意する。
マルチメディアデータは、ストレージ３から、バッファ２１に読み出され、ネットワークインタフェースカード２２を通じて、ネットワーク４を経由して端末１に送信される。
本発明による解決手段を説明する前に、ストレージの特性と固定周期の設定の仕方について説明する。
一般的に利用されているＨＤＤ等の円盤型のメディアを採用したストレージにデータを格納する場合、円盤の外周と内周で角度あたりの記録密度が異なるため、読み出しにかかる時間が異なる。また、円盤上の不良セクタやトラックをまたがって連続した領域に記録する場合、ストレージからの読み出し時間が遅くなることがある。
【０００８】
そのため、固定周期で遅滞なくストレージからの読み出しを実行するには、ストレージからの読み出しにかかる最悪時間を計算で求め、その値から１周期中のタイムスロット数を決定する。上記の例は読み出しの場合であるが、書き込みの場合も同様である。
読み出しと書き込みを混在させて実行するには、読み出しまたは書き込みにかかる最悪時間で１周期あたりのタイムスロット数を決定する。
ＰＣ等で多く利用されているＡＴＡ規格のＨＤＤでは、外周側に対して内周側の読み出し速度は約１／２（非特許文献４参照）であり、１周期のうち半分が空き時間となってしまう可能性がある。
本発明は、この空き時間を有効活用し、読み出し可能なマルチメディアデータを先読みし、新規リクエストが到着した時に、十分に先読みされていればその読み出しを中断し、新規リクエストの読み出しを優先的に実行出来るようにすることによって、新規リクエストの応答時間を改善する手段を提供する。
【０００９】
そこで、本発明では、従来技術のキューイング方式のように、リクエストを格納するキュー（以下、通常キュー）２３にリクエストを投入し、通常キュー２３の中に格納されている順に、ストレージ３からの読み出しを実行する方式を採用する。
従来のキューイング方式の場合、次の周期が来るまで読み出しは中止され、次の周期までの間が空き時間となるが、本発明では、この空き時間を有効活用し、次の周期を待たずにリクエストを通常キュー２３から取り出し、ストレージ３から次のマルチメディアデータの読み出しを行う。その場合、送信レートよりもストレージ３からの読み出し速度が早くなるため、その速度差を吸収するためバッファ２１を利用する。もし、全てのバッファ２１が一杯になっていれば、読み出し処理は実行しない。
さらに、本発明では、新規リクエストに対する応答時間を短縮するために以下の手順を行う。まず、新規のリクエストが到着したかどうかのフラグ２４を用意し、新規リクエストが到着した場合、そのフラグ２４をセットする。
そして、通常キュー２３の最後にリクエストを投入する。通常キュー２３からリクエストを取り出し、読み出し処理を実行する場合に、読み出し済みのマルチメディアデータが格納されており、かつ、送信が完了されていないバッファ２１の数を計数し、その数が閾値以上あれば、この周期での読み出しを中止する。
以上の処理により、新規リクエスト時の読み出し処理を、実質上早く行うことが出来る。
【００１０】
また、蓄積の場合は次のように処理する。フラグ２４がセットされている場合、ネットワーク４からの受信するためのバッファのうちストレージ３への書き込みが完了しデータ受信可能なバッファ２１の数を計数し、その数が閾値以上であった場合、ストレージ３への書き込み処理をスキップし、新規リクエストの処理を優先させ、応答時間を改善することが出来る。
前述のフラグ２４の代わりに、新規リクエストを入れるリクエストキュー（以降、新規キュー）２５を別途用意し、新規リクエストが到着したらその新規キュー２５に入れる。通常キュー２３を処理するときに、新規キュー２５をフラグと同様に参照することも出来る。
本発明では、さらに、次の通常キュー２３の処理開始前に、データが格納されているバッファ２１の数の少ない順に通常キュー２３の中のリクエストの並べ替えを行い、マルチメディアデータのバッファ中に少ないリクエストを先に行うことが可能となり、閾値をより小さく設定することが出来、少ないバッファ数で送信データが枯渇することによる端末側でのデータの途切れを防ぐことが出来る。
【００１１】
［作用］
ストレージ３に蓄積された任意のマルチメディア情報を、複数の端末１からのリクエストに応じてストレージ３から読み出し、決められた送信レートで送信するマルチメディア蓄積配信サーバに対して、本発明を適用することにより、送信レートの異なるマルチメディアデータを数多くの端末１に効率良く多重して送信すると同時に、新規リクエスト時の応答時間を短縮できる効果がある。
【発明の効果】
【００１２】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、任意のレートのマルチメディアデータを無駄なく扱え、かつ、応答時間を出来るだけ早くすることが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
［実施例１］
図４は、本発明の実施例のマルチメディアサーバを使用したマルチメディアデータ配信システムの概略構成を示すブロック図である。
同図において、１はリクエストを発する再生端末（以降、端末と称する。）、２はマルチメディアサーバ（以降、サーバと称する。）（本発明のマルチメディア蓄積配信サーバ）、３はマルチメディアデータ（以降、データと称する。）を格納するストレージ、４は端末１とサーバ２とを接続し、リクエストとデータを送受信するためのネットワークである。
端末１からのリクエストは、ネットワーク経由でサーバ２に送られ、同様に、データはネットワーク経由でサーバ２から端末１へ送信される。端末１では、受信したマルチメディアデータを表示する。
５はリクエストを発し、マルチメディアデータをサーバに送信するための蓄積端末である。蓄積端末５には、端末内にマルチメディアデータを取り込むため機材を接続することが出来る。
本実施例では、リクエストを発する端末１と、データを受信（または送信）する端末は同一としたが、別であっても構わない。また、端末ではなく、図４に示すように、他のマルチメディアサーバ２を端末１の代わりに接続してもよい。
【００１４】
図５は、図４に示すサーバ２の概略構成を示すブロック図である。
サーバ２内には、ストレージ３との接続を行うホストバスインタフェース（以降、単に、ＨＢＡと称する。）５１、ストレージ３から読み出したデータを格納するバッファメモリ（以降、単に、バッファと称する）５２、リクエストの順番を格納するリクエストキュー（以降、単に、通常キューと称する。）５３、ネットワークインタフェースカード（以降、単に、ＮＩＣと称する。）５４、演算装置５５、新規にリクエストが到着したかどうかを示すフラグ（以降、単に、フラグと称する。）５６を備えている。
図５に示すように、バッファ５２は、接続可能な端末毎に複数用意し、各バッファには、バッファ中に有効なデータが入っているかどうかを示すフラグ（以降、単に、バッファフラグと称する。）５２１を用意する。
【００１５】
前述のシステムを用いた場合の、本実施例のデータ配信方法について説明する。
本実施例では、演算装置５５を使用して、図６ないし８に示す３つの処理を並行して行う。
図６に示す第１の処理は、ストレージ３へのアクセス処理であり、以下のように動作する。
サーバは、通常キュー５３に登録されているリクエストを先頭から順番に読み出す（ステップ６０）。そして、フラグ５６が設定されているかどうかを判定する（ステップ６１）。
ステップ６１において、フラグ５６が設定されていれば、読み出したリクエストに対応する端末用のバッファ５２のバッファフラグ５２１を調べ、ストレージ３からのデータが格納され、かつ、端末への送信が完了していないバッファ数（未送信バッファ数）を計測し（ステップ６２）、未送信バッファ数が予め設定した閾値を超えているか否かを判断する（ステップ６３）。
ステップ６３において、未送信バッファ数が予め設定した閾値を超えていれば、ステップ７０に進み、ステップ６３において、未送信バッファ数が予め設定した閾値を超えていなければ、ＨＢＡ５１を通じてストレージ３からの読み出し処理を実行し（ステップ６４）、データを格納したバッファのバッファフラグ５２１をセットし（ステップ６５）、ステップ７０に進む。
なお、前述の閾値は、事前の評価によりアンダーフローを起こさないように決めることは可能である。
【００１６】
また、ステップ６１において、フラグ５６が設定されていない場合は、バッファフラグ５２１を調べ、空きバッファ数を計測し（ステップ６６）、空きバッファがあるかどうかを判定する（ステップ６７）。
ステップ６７において、空バッファが無い場合は、ステップ７０に進み、ステップ６７において、空きバッファがある場合は、ＨＢＡ５１を通じてストレージ３からの読み出し処理を実行し（ステップ６８）、データを格納したバッファのバッファフラグ５２１をセットし（ステップ６５）、ステップ７０に進む。
ステップ７０では、通常キュー中の最後のリクエストか否かを判定することにより、通常キュー２３に登録されている全てのリクエストの処理を実行し、それらの処理が完了した時点で、フラグ５６が設定されていれば、それをクリアし（ステップ７１）、再び、通常キュー２３の先頭から順にリクエストを読み出し、前述の処理を順に実行する。
【００１７】
図７に示す第２の処理は、リクエスト受信処理であり、以下のように動作する。
端末１からのリクエストの到着を待ち（ステップ７３）、端末１からリクエストが到着した場合、リクエストの種別を判定する（ステップ７４）。
ステップ７４での判定結果、そのリクエストが新規再生リクエストであった場合、その時点で通常キュー５３の最後にこのリクエストを追加し（ステップ７５）、さらに、フラグ５６をセットする（ステップ７６）。
ステップ７４での判定結果、そのリクエストが再生終了のリクエストであった場合、通常キュー２３から該当するリクエストを削除する（ステップ７７）。
【００１８】
図８に示す第３の処理はデータ送信処理であり、以下のように動作する。なお、データ送信処理は、データ毎に決められた送信レートでデータを送信する処理である。
一定時間間隔で、先頭のバッファ５２のバッファフラグ５２１を判定し（ステップ８０）、ステップ８０での判定結果、フラグが未セットであれば、先頭のバッファ５２のバッファフラグ５２１がセットされるのを待つ。
ステップ８０での判定結果、フラグがセット済みであれば、バッファフラグ５２１がセットされている先頭のバッファ中のデータからパケットを生成し（ステップ８１）、ＮＩＣ５４を通じてネットワーク４へ送信する（ステップ８２）。
次に、バッファ内の全データを送信したか否かを判定し（ステップ８３）、ステップ８３での判定結果、未送信データがあれば、前述のステップ８０ないしステップ８３を繰り返す。
また、ステップ８３での判定結果、未送信データがなければ、バッファフラグ５２１をクリアし、次にバッファを先頭に変更し（ステップ８４）、再度、前述の処理を繰り返す。
【００１９】
なお、本実施例において、通常キュー２３とは、別のリクエストを格納するキュー（以降、新規キューと称する。）５７を用意し、そこに新規リクエストを追加することが出来る。
新規リクエストを受け付けたときに、通常キュー内のリクエストが処理されている間や、終了による削除を実行している間に、通常キュー内のリクエストの一貫性を保持するため、通常キュー５３に追加することが出来ない場合がある。この場合、新規リクエストが追加出来ずに待たされることになる。
このような場合でも、別に新規キュー５７が用意されているためリクエストの追加が即時に実行出来るためレスポンスの悪化を抑止する効果がある。
その新規キュー５７にリクエストが登録されているかどうかを判定することによって、フラグ５６を使用する代わりに新規リクエストが到着したかどうかを判定することが出来る。そして、通常キュー２３の処理が完了した後、新規キュー５７を通常キュー２３に接続し、処理を継続する。
バッファメモリ５２、通常キュー５３、フラグ５６、新規キュー５７は、それぞれ別なハードウェア上に実装する必要はなく、同一の物理メモリを論理的に分割して実装してもよい。さらに、第１の処理、第２の処理、第３の処理を異なるプロセス（または、スレッドやタスク）として実装することにより、一般的なパーソナルコンピュータやワークステーションなどに簡単に実装することが出来る。
【００２０】
図９は、本実施例のストレージ読み出しのタイムチャートの一例を示す図である。
図９に示す１周期（Ｔ１）において、新規リクエストフラグ５６は未セット（ＯＦＦ）、通常キュー５３に格納されるリクエストの順番は、端末Ａ、端末Ｂ、端末Ｄとし、さらに、端末Ａ、端末Ｂ、端末Ｄのそれぞれのバッファは空きがあるとする。
この場合、図９に示すように、１周期（Ｔ１）内では、端末Ａ向けのデータ、端末Ｂ向けのデータ、端末Ｄ向けのデータが、それぞれストレージ３から読み出される。
この１周期（Ｔ１）内の、端末Ｄ向けのデータを読み出している最中に、図９に示すように、端末Ｃから新規の再生要求のリクエストが到着したとする。
この時、次の１周期（Ｔ２）において、新規リクエストフラグ５６はセット（ＯＮ）、通常キュー５３に格納されるリクエストの順番は、端末Ａ、端末Ｂ、端末Ｄ、端末Ｃとなる。
この場合、図９に示すように、１周期（Ｔ２）内では、端末Ａ向けの未送信データ、および端末Ｂ向けの未送信データが閾値以下であるので、端末Ａ向けのデータ、および端末Ｂ向けのデータはストレージ３から読み出されるが、端末Ｄ向けの未送信データが閾値を超えるので、端末Ｄ向けのデータのストレージ３から読み出しが実行されず、端末Ｃ向けのデータがストレージ３から読み出される。
周期（Ｔ２）の後の１周期（Ｔ３）において、新規リクエストフラグ５６は未セット（ＯＦＦ）、通常キュー５３に格納されるリクエストの順番は、端末Ａ、端末Ｂ、端末Ｄ、端末Ｃとなる。
この場合、図９に示すように、１周期（Ｔ３）内では、端末Ａのバッファ、端末Ｄのバッファ、および端末Ｃのバッファは、それぞれ空きがあるので、端末Ａ向けのデータ、端末Ｄ向けのデータ、および端末Ｃ向けのデータはストレージ３から読み出されるが、端末Ｂのバッファは空きがないので、端末Ｂ向けのデータの読み出しは実行されない。
なお、図９から分かるように、本実施例では、１周期の時間は、各周期毎に一定の時間ではなく、各周期毎に異なっている。
【００２１】
［実施例２］
本発明では、ストレージ３からの読み出し処理とストレージ３への書き込み処理を混在して行うことが出来る。その場合の実施例を以下に示す。
まず、端末１は、新規にリクエストをサーバに送信するときにこのリクエストが読み出しか書き込みかどうかを識別する情報（以降、リクエスト情報と称する。）を付加して送信する。そして、サーバ２は、そのリクエストに応じて、以下に示す第１、第２、第３の処理を実行する。
まず、第２の処理（リクエスト受信処理）について説明する。
サーバ２は、端未１からリクエスト情報の入ったリクエストを受信したときに、これが読み出しの要求か書き込みの要求かを判定し、この要求をリクエスト情報とともに、通常キュー５３に格納し、フラグ５６をセットする。
次に、第３の処理について説明する。
蓄積の場合はデータを送信する代わりに蓄積端末５から送られてきたパケット化された映像を、元のマルチメディアデータに復元し、それをバッファ５２に格納し、バッファフラグ５２１をセットする。
【００２２】
最後に、第１の処理について説明する。この処理の概略フロー例を図１０Ａ、図１０Ｂに示す。ここで説明する例では、新規キュー５７を使用せずに、フラグ５６を使用する例を示す。
まず、サーバ２は、通常キュー５３からリクエストを取り出し（ステップ９０）、リクエストに付属するリクエスト情報を読み出し、このリクエストで要求された処理が読み出しか、または、書き込みであるかどうかを判定する（ステップ９１）。
ステップ９１での判定結果が読み出しの場合は、フラグ５６が設定されているかどうかを判定する（ステップ９２）。
ステップ９２において、フラグ５６が設定されていれば、読み出したリクエストに対応する端末用のバッファ５２のバッファフラグ５２１を調べ、ストレージ３からのデータが格納され、かつ、端末への送信が完了していないバッファ数（未送信バッファ数）を計測し（ステップ９３）、未送信バッファ数が予め設定した閾値を超えているか否かを判断する（ステップ９４）。
ステップ９４において、未送信バッファ数が予め設定した閾値を超えていれば、ステップ１０１に進み、ステップ９４において、未送信バッファ数が予め設定した閾値を超えていなければ、ＨＢＡ５１を通じてストレージ３からの読み出し処理を実行し（ステップ９５）、データを格納したバッファのバッファフラグ５２１をセットし（ステップ９６）、ステップ１０１に進む。
【００２３】
また、ステップ９２において、フラグ５６が設定されていない場合は、バッファフラグ５２１を調べ、空きバッファ数を計測し（ステップ９７）、空きバッファがあるかどうかを判定する（ステップ９８）。
ステップ９８において、空バッファが無い場合は、ステップ１０１に進み、ステップ９８において、空きバッファがある場合は、ＨＢＡ５１を通じてストレージ３からの読み出し処理を実行し（ステップ９９）、データを格納したバッファのバッファフラグ５２１をセットし（ステップ１００）、ステップ１０１に進む。
ステップ１０１では、通常キュー中の最後のリクエストか否かを判定することにより、通常キュー２３に登録されている全てのリクエストの処理を実行し、それらの処理が完了した時点で、フラグ５６が設定されていれば、それをクリア（ステップ１０２）し、再び、通常キュー２３の先頭から順にリクエストを読み出し、前述の処理を順に実行する。
【００２４】
ステップ９１での判定結果が書き込みの場合は、フラグ５６が設定されているかどうかを判定し（ステップ１０３）、新規リクエストが到着したかどうかを判定する。
ステップ１０３において、フラグ５６が設定されていれば、この端末からのリクエストの処理に使用可能なバッファフラグ５２１のセットされていないバッファ数（未受信バッファ数）を計測し（ステップ１０４）、未受信バッファ数が閾値を超えているか否かを判定する（ステップ１０５）。
ステップ１０５での判定結果、未受信バッファ数が閾値を超えている場合は、ステップ１０１に進み、ストレージ３への書き込みをスキップし、次のリクエストの処理に移行する。
ステップ１０５での判定結果、未受信バッファ数が閾値を超えていない場合、ストレージ３への書き込みを行い（ステップ１０６）、バッファフラグ５２１をクリアする（ステップ１０７）。
【００２５】
ステップ１０３において、フラグ５６が設定されていなければ、バッファフラグ５２１を検査し（ステップ１０８）、受信済みデータが格納されたバッファ５２があるか否かを判定する（ステップ１０９）。
ステップ１０９での判定結果、受信済みデータが格納されたバッファ５２がない場合は、ステップ１０１に進み、ステップ１０９での判定結果、受信済みデータが格納されたバッファ５２がある場合は、バッファフラグ５２１のセットされているバッファ中で最初に受信したマルチメディアデータが格納されているバッファ内のデータをストレージ３に書き込み（ステップ１１０）、そのバッファ５２のバッファフラグ５２１をクリアする（ステップ１１１）。
前述した通り、この例では、新規キュー５７を利用していないが、読み出しのみの場合と同様に、新規キュー５７も利用することが可能である。
【００２６】
また、前述の例では、ストレージ３が１台であったが、図１１に示すように、複数台のストレージ３を用いてマルチメディアデータを分割（ストライピング）して格納することも可能である。
この図１１に示す例では、ストレージエリアネットワーク６を用いて複数のストレージ３と接続しているが、複数のＨＢＡ５１をサーバ内に実装して複数のストレージ３を接続することももちろん可能である。サーバ内では、図６または図１０に示した第１の処理をストレージ毎に独立に動作させる。
さらに、図１２に示すように、バッファ５２とバッファフラグ５２１を、端末、ストレージ毎に用意する。
図１２に示す例では、ストレージ１（３）からの読み出し処理（第１の処理）実行時には、ストレージ１（３）から読み出したデータを、図１２の１、５、９、１３のバッファ５２に順番に格納していく。
【００２７】
データの送信時には、バッファ１、２、３、４の順番に、バッファ５２からデータを読み出しネットワーク４に送り出していく。
このように、複数のストレージに分割して格納することによって、応答時間の改善と実質的なストレージへのアクセス速度の向上を同時に実現することが出来る。
さらに、本実施例では、通常キュー内のリクエストの処理を最後まで実行した後、通常キュー５３に格納されているリクエストのリクエスト情報に応じて、未送信バッファ数または未受信バッファ数をリクエスト毎に計数する。
そして、その数が少ないものの順に、通常キュー内のリクエストの並べ替えを行うことも出来る。この操作により、送信の場合は送信可能なデータの少ないリクエストに対するストレージ３へのアクセスが優先されるため、送信データが枯渇する、所謂、アンダーフローの状態になることを予防することが出来る。
また、蓄債の場合は、受信バッファの少ないものが優先されるため、受信バッファが枯渇することによる受信出来ない状態、所謂、オーバーフロー状態を予防することが出来る。
【００２８】
なお、前述の説明では、１つのサーバ２で、ストレージ３へのアクセスと端末との送受信を行うサーバを例に説明をしたが、特許文献２に示されているようなストレージアクセスを行うサーバモジュール（蓄積サーバモジュール）と、端末との送受信を行うサーバモジュール（通信サーバモジュール）が内部ネットワークで結合された分散型サーバシステムの、蓄債サーバモジュールにも適用可能である。
この場合、リクエストを発する端末を通信サーバモジュールと置き換えるだけでよい。
以上説明したように、本実施例によれば、任意のレートのマルチメディアデータを無駄なく扱え、かつ、応答時間を出来るだけ早くすることが可能となるので、複数の任意の映像を同時に蓄積送信した場合でも、応答時間を向上することができ、よりよいサービスをユーザに提供することが可能となる。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００２９】
【図１】タイムスロット方式のマルチメディアデータ配信方法を説明するための概念図である。
【図２】キューイング方式のマルチメディアデータ配信方法を説明するための概念図である。
【図３】本発明のマルチメディアサーバを使用したマルチメディアデータ配信システムの概略構成を示すブロック図である。
【図４】本発明の実施例１のマルチメディアサーバを使用したマルチメディアデータ配信システムの概略構成を示すブロック図である。
【図５】図４に示すマルチメディアサーバの概略構成を示すブロック図である。
【図６】本発明の実施例１のマルチメディアサーバのストレージへのアクセス処理の処理手順を示すフローチャートである。
【図７】本発明の実施例１のマルチメディアサーバのリクエスト受信処理の処理手順を示すフローチャートである。
【図８】本発明の実施例１のマルチメディアサーバのデータ送信処理の処理手順を示すフローチャートである。
【図９】本発明の実施例１のストレージ読み出しのタイムチャートの一例を示す図である。
【図１０Ａ】本発明の実施例２のマルチメディアサーバのリクエスト受信処理の処理手順を示すフローチャートである。
【図１０Ｂ】本発明の実施例２のマルチメディアサーバのリクエスト受信処理の処理手順を示すフローチャートである。
【図１１】本発明の各実施例のマルチメディアサーバの変形例として、複数のストレージを使用するマルチメディアサーバを使用したマルチメディアデータ配信システムの概略構成を示すブロック図である。
【図１２】図１１に示すマルチメディアサーバの概略構成を示すブロック図である。
【符号の説明】
【００３０】
１ 再生端末
２ マルチメディアサーバ
３ ストレージ
４ ネットワーク
５ 蓄積端末
６ ストレージエリアネットワーク
２１，５２ バッファメモリ
２２，５４ ネットワークインタフェースカード
２３，２５，５３，５７ リクエストキュー
２４，５６ フラグ
５１ ホストバスインタフェース
５４ ネットワークインタフェースカード
５５ 演算装置
５２１ バッファフラグ
【出願人】 【識別番号】０００００４２２６
【氏名又は名称】日本電信電話株式会社
【出願日】 平成１８年７月４日（２００６．７．４）
【代理人】 【識別番号】１０００８３５５２
【弁理士】
【氏名又は名称】秋田 収喜

【識別番号】１００１０３７４６
【弁理士】
【氏名又は名称】近野 恵一

【識別番号】１００１１９７０３
【弁理士】
【氏名又は名称】井上 雅夫
【公開番号】 特開２００８−１７０３３（Ｐ２００８−１７０３３Ａ）
【公開日】 平成２０年１月２４日（２００８．１．２４）
【出願番号】 特願２００６−１８４６２５（Ｐ２００６−１８４６２５）