JP4675290B2 - マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法 - Google Patents
マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法 Download PDFInfo
- Publication number
- JP4675290B2 JP4675290B2 JP2006184625A JP2006184625A JP4675290B2 JP 4675290 B2 JP4675290 B2 JP 4675290B2 JP 2006184625 A JP2006184625 A JP 2006184625A JP 2006184625 A JP2006184625 A JP 2006184625A JP 4675290 B2 JP4675290 B2 JP 4675290B2
- Authority
- JP
- Japan
- Prior art keywords
- storage
- multimedia data
- buffer
- queue
- request
- 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.)
- Active
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
決められたレートで読み出す機能を実現する従来の方式として、以下の2方式が知られている。
方式1.タイムスロット方式(非特許文献1参照)
方式2.キューイング方式(特許文献1参照)
まず、方式1のタイムスロット方式について説明する。タイムスロット方式の概念図を図1に示す。
このタイムスロット方式の特微は、図1に示すように、一定時間T0を1周期と設定し、その1周期を複数のタイムスロットS1〜S4に分割する。そして、端末A1向けのマルチメディアデータをタイムスロットS1の間、端末A2向けのマルチメディアデータをタイムスロットS2の間でストレージから読み出す。これを1周期ごとに繰り返し実行する。
例えば、一定時間T0を1秒、端末A向けのマルチメディアデータの送信レートを1Mバイト/秒とすれば、タイムスロットS1の間で1Mバイトを読み出せば、端末Aへ送信するデータが枯渇せずにQoSを確保することが出来る。
そして、この処理を1周期ごとに実行することによって、端末へ送信するデータが枯渇することなくQoSを確保することが出来る。
このキューイング方式(方式2)は、様々なレートの映像を無駄なく扱うことが出来るという利点がある。
また、タイムスロット方式(方式1)は、複数のストレージを並べ、かつ、先頭のデータを欠落させることによって、応答時間を早くすることが出来るメリットがある(非特許文献2)。
テレビジョン学会誌 Vo1.48,No.3,pp.287-294:"多重読み取り可能なビデオオンデマンドシステム"
(1)レート混在時の問題
(2)レスポンスの問題
第1の問題は、方式1のタイムスロット方式のみに起こる問題である。
タイムスロット方式の場合、1周期を固定数のタイムスロットに分割して、ストレージからの読み出し処理を行うため、最初に想定したレート以外で使用した場合、無駄な空き時間を作ることになる。つまり、従来技術で記載した例のように、秒当たり1Mバイトのレートで送信できるように、1周期を1秒として、1タイムスロットで1Mバイトのデータを読むことが出来るようにタイムスロットを設定したシステムを考える。
このシステムを利用して、1秒当たり、0.1Mバイトのマルチメディアデータを送ろうとすると、0.9Mバイト分、無駄な空き時間を作り、本来の送信能力を発揮することが不可能となる。
その無駄をさけるため、タイムスロットを細分化して、複数のタイムスロットを1つのスロットとして扱う方法も提案されているが(非特許文献3参照)、送信するマルチメディアデータの送信レートを制限しない限り、この無駄な空き時間を完全に無くすことは不可能である。
第2の課題は、方式2のキューイング方式のみに起こる問題である。
キューイング方式の場合、任意のレートのマルチメディアデータに対応可能である。その反面、新しく到着した送信リクエストをキューの最後で処理する必要がある。キューの途中で処理してしまうと、この時点で受け付けていた端末への読み出しが中断されてしまうため、送信データがなくなり、端末でデータが途切れることとなる。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
同図において、1はマルチメディアデータを受信して再生する端末、2はマルチメディアデータを送信するサーバ(本発明のマルチメディア蓄積配信サーバ)、3はマルチメディアデータが格納されたストレージ、4はネットワークである。21は一時的にその情報を格納する複数のバッファ、22はネットワークインタフェースカードである。バッファ21は送信する端末毎に複数用意する。
マルチメディアデータは、ストレージ3から、バッファ21に読み出され、ネットワークインタフェースカード22を通じて、ネットワーク4を経由して端末1に送信される。
本発明による解決手段を説明する前に、ストレージの特性と固定周期の設定の仕方について説明する。
一般的に利用されているHDD等の円盤型のメディアを採用したストレージにデータを格納する場合、円盤の外周と内周で角度あたりの記録密度が異なるため、読み出しにかかる時間が異なる。また、円盤上の不良セクタやトラックをまたがって連続した領域に記録する場合、ストレージからの読み出し時間が遅くなることがある。
読み出しと書き込みを混在させて実行するには、読み出しまたは書き込みにかかる最悪時間で1周期あたりのタイムスロット数を決定する。
PC等で多く利用されているATA規格のHDDでは、外周側に対して内周側の読み出し速度は約1/2(非特許文献4参照)であり、1周期のうち半分が空き時間となってしまう可能性がある。
本発明は、この空き時間を有効活用し、読み出し可能なマルチメディアデータを先読みし、新規リクエストが到着した時に、十分に先読みされていればその読み出しを中断し、新規リクエストの読み出しを優先的に実行出来るようにすることによって、新規リクエストの応答時間を改善する手段を提供する。
従来のキューイング方式の場合、次の周期が来るまで読み出しは中止され、次の周期までの間が空き時間となるが、本発明では、この空き時間を有効活用し、次の周期を待たずにリクエストを通常キュー23から取り出し、ストレージ3から次のマルチメディアデータの読み出しを行う。その場合、送信レートよりもストレージ3からの読み出し速度が早くなるため、その速度差を吸収するためバッファ21を利用する。もし、全てのバッファ21が一杯になっていれば、読み出し処理は実行しない。
さらに、本発明では、新規リクエストに対する応答時間を短縮するために以下の手順を行う。まず、新規のリクエストが到着したかどうかのフラグ24を用意し、新規リクエストが到着した場合、そのフラグ24をセットする。
そして、通常キュー23の最後にリクエストを投入する。通常キュー23からリクエストを取り出し、読み出し処理を実行する場合に、読み出し済みのマルチメディアデータが格納されており、かつ、送信が完了されていないバッファ21の数を計数し、その数が閾値以上あれば、この周期での読み出しを中止する。
以上の処理により、新規リクエスト時の読み出し処理を、実質上早く行うことが出来る。
前述のフラグ24の代わりに、新規リクエストを入れるリクエストキュー(以降、新規キュー)25を別途用意し、新規リクエストが到着したらその新規キュー25に入れる。通常キュー23を処理するときに、新規キュー25をフラグと同様に参照することも出来る。
本発明では、さらに、次の通常キュー23の処理開始前に、データが格納されているバッファ21の数の少ない順に通常キュー23の中のリクエストの並べ替えを行い、マルチメディアデータのバッファ中に少ないリクエストを先に行うことが可能となり、閾値をより小さく設定することが出来、少ないバッファ数で送信データが枯渇することによる端末側でのデータの途切れを防ぐことが出来る。
ストレージ3に蓄積された任意のマルチメディア情報を、複数の端末1からのリクエストに応じてストレージ3から読み出し、決められた送信レートで送信するマルチメディア蓄積配信サーバに対して、本発明を適用することにより、送信レートの異なるマルチメディアデータを数多くの端末1に効率良く多重して送信すると同時に、新規リクエスト時の応答時間を短縮できる効果がある。
本発明によれば、任意のレートのマルチメディアデータを無駄なく扱え、かつ、応答時間を出来るだけ早くすることが可能となる。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
[実施例1]
図4は、本発明の実施例のマルチメディアサーバを使用したマルチメディアデータ配信システムの概略構成を示すブロック図である。
同図において、1はリクエストを発する再生端末(以降、端末と称する。)、2はマルチメディアサーバ(以降、サーバと称する。)(本発明のマルチメディア蓄積配信サーバ)、3はマルチメディアデータ(以降、データと称する。)を格納するストレージ、4は端末1とサーバ2とを接続し、リクエストとデータを送受信するためのネットワークである。
端末1からのリクエストは、ネットワーク経由でサーバ2に送られ、同様に、データはネットワーク経由でサーバ2から端末1へ送信される。端末1では、受信したマルチメディアデータを表示する。
5はリクエストを発し、マルチメディアデータをサーバに送信するための蓄積端末である。蓄積端末5には、端末内にマルチメディアデータを取り込むため機材を接続することが出来る。
本実施例では、リクエストを発する端末1と、データを受信(または送信)する端末は同一としたが、別であっても構わない。また、端末ではなく、図4に示すように、他のマルチメディアサーバ2を端末1の代わりに接続してもよい。
サーバ2内には、ストレージ3との接続を行うホストバスインタフェース(以降、単に、HBAと称する。)51、ストレージ3から読み出したデータを格納するバッファメモリ(以降、単に、バッファと称する)52、リクエストの順番を格納するリクエストキュー(以降、単に、通常キューと称する。)53、ネットワークインタフェースカード(以降、単に、NICと称する。)54、演算装置55、新規にリクエストが到着したかどうかを示すフラグ(以降、単に、フラグと称する。)56を備えている。
図5に示すように、バッファ52は、接続可能な端末毎に複数用意し、各バッファには、バッファ中に有効なデータが入っているかどうかを示すフラグ(以降、単に、バッファフラグと称する。)521を用意する。
本実施例では、演算装置55を使用して、図6ないし8に示す3つの処理を並行して行う。
図6に示す第1の処理は、ストレージ3へのアクセス処理であり、以下のように動作する。
サーバは、通常キュー53に登録されているリクエストを先頭から順番に読み出す(ステップ60)。そして、フラグ56が設定されているかどうかを判定する(ステップ61)。
ステップ61において、フラグ56が設定されていれば、読み出したリクエストに対応する端末用のバッファ52のバッファフラグ521を調べ、ストレージ3からのデータが格納され、かつ、端末への送信が完了していないバッファ数(未送信バッファ数)を計測し(ステップ62)、未送信バッファ数が予め設定した閾値を超えているか否かを判断する(ステップ63)。
ステップ63において、未送信バッファ数が予め設定した閾値を超えていれば、ステップ70に進み、ステップ63において、未送信バッファ数が予め設定した閾値を超えていなければ、HBA51を通じてストレージ3からの読み出し処理を実行し(ステップ64)、データを格納したバッファのバッファフラグ521をセットし(ステップ65)、ステップ70に進む。
なお、前述の閾値は、事前の評価によりアンダーフローを起こさないように決めることは可能である。
ステップ67において、空バッファが無い場合は、ステップ70に進み、ステップ67において、空きバッファがある場合は、HBA51を通じてストレージ3からの読み出し処理を実行し(ステップ68)、データを格納したバッファのバッファフラグ521をセットし(ステップ65)、ステップ70に進む。
ステップ70では、通常キュー中の最後のリクエストか否かを判定することにより、通常キュー23に登録されている全てのリクエストの処理を実行し、それらの処理が完了した時点で、フラグ56が設定されていれば、それをクリアし(ステップ71)、再び、通常キュー23の先頭から順にリクエストを読み出し、前述の処理を順に実行する。
端末1からのリクエストの到着を待ち(ステップ73)、端末1からリクエストが到着した場合、リクエストの種別を判定する(ステップ74)。
ステップ74での判定結果、そのリクエストが新規再生リクエストであった場合、その時点で通常キュー53の最後にこのリクエストを追加し(ステップ75)、さらに、フラグ56をセットする(ステップ76)。
ステップ74での判定結果、そのリクエストが再生終了のリクエストであった場合、通常キュー23から該当するリクエストを削除する(ステップ77)。
一定時間間隔で、先頭のバッファ52のバッファフラグ521を判定し(ステップ80)、ステップ80での判定結果、フラグが未セットであれば、先頭のバッファ52のバッファフラグ521がセットされるのを待つ。
ステップ80での判定結果、フラグがセット済みであれば、バッファフラグ521がセットされている先頭のバッファ中のデータからパケットを生成し(ステップ81)、NIC54を通じてネットワーク4へ送信する(ステップ82)。
次に、バッファ内の全データを送信したか否かを判定し(ステップ83)、ステップ83での判定結果、未送信データがあれば、前述のステップ80ないしステップ83を繰り返す。
また、ステップ83での判定結果、未送信データがなければ、バッファフラグ521をクリアし、次にバッファを先頭に変更し(ステップ84)、再度、前述の処理を繰り返す。
新規リクエストを受け付けたときに、通常キュー内のリクエストが処理されている間や、終了による削除を実行している間に、通常キュー内のリクエストの一貫性を保持するため、通常キュー53に追加することが出来ない場合がある。この場合、新規リクエストが追加出来ずに待たされることになる。
このような場合でも、別に新規キュー57が用意されているためリクエストの追加が即時に実行出来るためレスポンスの悪化を抑止する効果がある。
その新規キュー57にリクエストが登録されているかどうかを判定することによって、フラグ56を使用する代わりに新規リクエストが到着したかどうかを判定することが出来る。そして、通常キュー23の処理が完了した後、新規キュー57を通常キュー23に接続し、処理を継続する。
バッファメモリ52、通常キュー53、フラグ56、新規キュー57は、それぞれ別なハードウェア上に実装する必要はなく、同一の物理メモリを論理的に分割して実装してもよい。さらに、第1の処理、第2の処理、第3の処理を異なるプロセス(または、スレッドやタスク)として実装することにより、一般的なパーソナルコンピュータやワークステーションなどに簡単に実装することが出来る。
図9に示す1周期(T1)において、新規リクエストフラグ56は未セット(OFF)、通常キュー53に格納されるリクエストの順番は、端末A、端末B、端末Dとし、さらに、端末A、端末B、端末Dのそれぞれのバッファは空きがあるとする。
この場合、図9に示すように、1周期(T1)内では、端末A向けのデータ、端末B向けのデータ、端末D向けのデータが、それぞれストレージ3から読み出される。
この1周期(T1)内の、端末D向けのデータを読み出している最中に、図9に示すように、端末Cから新規の再生要求のリクエストが到着したとする。
この時、次の1周期(T2)において、新規リクエストフラグ56はセット(ON)、通常キュー53に格納されるリクエストの順番は、端末A、端末B、端末D、端末Cとなる。
この場合、図9に示すように、1周期(T2)内では、端末A向けの未送信データ、および端末B向けの未送信データが閾値以下であるので、端末A向けのデータ、および端末B向けのデータはストレージ3から読み出されるが、端末D向けの未送信データが閾値を超えるので、端末D向けのデータのストレージ3から読み出しが実行されず、端末C向けのデータがストレージ3から読み出される。
周期(T2)の後の1周期(T3)において、新規リクエストフラグ56は未セット(OFF)、通常キュー53に格納されるリクエストの順番は、端末A、端末B、端末D、端末Cとなる。
この場合、図9に示すように、1周期(T3)内では、端末Aのバッファ、端末Dのバッファ、および端末Cのバッファは、それぞれ空きがあるので、端末A向けのデータ、端末D向けのデータ、および端末C向けのデータはストレージ3から読み出されるが、端末Bのバッファは空きがないので、端末B向けのデータの読み出しは実行されない。
なお、図9から分かるように、本実施例では、1周期の時間は、各周期毎に一定の時間ではなく、各周期毎に異なっている。
本発明では、ストレージ3からの読み出し処理とストレージ3への書き込み処理を混在して行うことが出来る。その場合の実施例を以下に示す。
まず、端末1は、新規にリクエストをサーバに送信するときにこのリクエストが読み出しか書き込みかどうかを識別する情報(以降、リクエスト情報と称する。)を付加して送信する。そして、サーバ2は、そのリクエストに応じて、以下に示す第1、第2、第3の処理を実行する。
まず、第2の処理(リクエスト受信処理)について説明する。
サーバ2は、端未1からリクエスト情報の入ったリクエストを受信したときに、これが読み出しの要求か書き込みの要求かを判定し、この要求をリクエスト情報とともに、通常キュー53に格納し、フラグ56をセットする。
次に、第3の処理について説明する。
蓄積の場合はデータを送信する代わりに蓄積端末5から送られてきたパケット化された映像を、元のマルチメディアデータに復元し、それをバッファ52に格納し、バッファフラグ521をセットする。
まず、サーバ2は、通常キュー53からリクエストを取り出し(ステップ90)、リクエストに付属するリクエスト情報を読み出し、このリクエストで要求された処理が読み出しか、または、書き込みであるかどうかを判定する(ステップ91)。
ステップ91での判定結果が読み出しの場合は、フラグ56が設定されているかどうかを判定する(ステップ92)。
ステップ92において、フラグ56が設定されていれば、読み出したリクエストに対応する端末用のバッファ52のバッファフラグ521を調べ、ストレージ3からのデータが格納され、かつ、端末への送信が完了していないバッファ数(未送信バッファ数)を計測し(ステップ93)、未送信バッファ数が予め設定した閾値を超えているか否かを判断する(ステップ94)。
ステップ94において、未送信バッファ数が予め設定した閾値を超えていれば、ステップ101に進み、ステップ94において、未送信バッファ数が予め設定した閾値を超えていなければ、HBA51を通じてストレージ3からの読み出し処理を実行し(ステップ95)、データを格納したバッファのバッファフラグ521をセットし(ステップ96)、ステップ101に進む。
ステップ98において、空バッファが無い場合は、ステップ101に進み、ステップ98において、空きバッファがある場合は、HBA51を通じてストレージ3からの読み出し処理を実行し(ステップ99)、データを格納したバッファのバッファフラグ521をセットし(ステップ100)、ステップ101に進む。
ステップ101では、通常キュー中の最後のリクエストか否かを判定することにより、通常キュー23に登録されている全てのリクエストの処理を実行し、それらの処理が完了した時点で、フラグ56が設定されていれば、それをクリア(ステップ102)し、再び、通常キュー23の先頭から順にリクエストを読み出し、前述の処理を順に実行する。
ステップ103において、フラグ56が設定されていれば、この端末からのリクエストの処理に使用可能なバッファフラグ521のセットされていないバッファ数(未受信バッファ数)を計測し(ステップ104)、未受信バッファ数が閾値を超えているか否かを判定する(ステップ105)。
ステップ105での判定結果、未受信バッファ数が閾値を超えている場合は、ステップ101に進み、ストレージ3への書き込みをスキップし、次のリクエストの処理に移行する。
ステップ105での判定結果、未受信バッファ数が閾値を超えていない場合、ストレージ3への書き込みを行い(ステップ106)、バッファフラグ521をクリアする(ステップ107)。
ステップ109での判定結果、受信済みデータが格納されたバッファ52がない場合は、ステップ101に進み、ステップ109での判定結果、受信済みデータが格納されたバッファ52がある場合は、バッファフラグ521のセットされているバッファ中で最初に受信したマルチメディアデータが格納されているバッファ内のデータをストレージ3に書き込み(ステップ110)、そのバッファ52のバッファフラグ521をクリアする(ステップ111)。
前述した通り、この例では、新規キュー57を利用していないが、読み出しのみの場合と同様に、新規キュー57も利用することが可能である。
この図11に示す例では、ストレージエリアネットワーク6を用いて複数のストレージ3と接続しているが、複数のHBA51をサーバ内に実装して複数のストレージ3を接続することももちろん可能である。サーバ内では、図6または図10に示した第1の処理をストレージ毎に独立に動作させる。
さらに、図12に示すように、バッファ52とバッファフラグ521を、端末、ストレージ毎に用意する。
図12に示す例では、ストレージ1(3)からの読み出し処理(第1の処理)実行時には、ストレージ1(3)から読み出したデータを、図12の1、5、9、13のバッファ52に順番に格納していく。
このように、複数のストレージに分割して格納することによって、応答時間の改善と実質的なストレージへのアクセス速度の向上を同時に実現することが出来る。
さらに、本実施例では、通常キュー内のリクエストの処理を最後まで実行した後、通常キュー53に格納されているリクエストのリクエスト情報に応じて、未送信バッファ数または未受信バッファ数をリクエスト毎に計数する。
そして、その数が少ないものの順に、通常キュー内のリクエストの並べ替えを行うことも出来る。この操作により、送信の場合は送信可能なデータの少ないリクエストに対するストレージ3へのアクセスが優先されるため、送信データが枯渇する、所謂、アンダーフローの状態になることを予防することが出来る。
また、蓄債の場合は、受信バッファの少ないものが優先されるため、受信バッファが枯渇することによる受信出来ない状態、所謂、オーバーフロー状態を予防することが出来る。
この場合、リクエストを発する端末を通信サーバモジュールと置き換えるだけでよい。
以上説明したように、本実施例によれば、任意のレートのマルチメディアデータを無駄なく扱え、かつ、応答時間を出来るだけ早くすることが可能となるので、複数の任意の映像を同時に蓄積送信した場合でも、応答時間を向上することができ、よりよいサービスをユーザに提供することが可能となる。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
2 マルチメディアサーバ
3 ストレージ
4 ネットワーク
5 蓄積端末
6 ストレージエリアネットワーク
21,52 バッファメモリ
22,54 ネットワークインタフェースカード
23,25,53,57 リクエストキュー
24,56 フラグ
51 ホストバスインタフェース
54 ネットワークインタフェースカード
55 演算装置
521 バッファフラグ
Claims (12)
- 複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバにおいて、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグと、
前記フラグがセットされているか否かを判定し新規リクエストが到着したか否かを判定する判定手段と、
前記ストレージから読み出され、かつ、前記バッファから未送信である未送信バッファ数を計数する計数手段1と、
前記判定手段で新規リクエストが到着していると判定された場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行する手段とを備えることを特徴とするマルチメディア蓄積配信サーバ。 - 複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバにおいて、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグと、
前記フラグがセットされているか否かを判定し新規リクエストが到着したか否かを判定する判定手段と、
前記バッファの中で、前記端末から受信したマルチメディアデータを格納することができる未受信バッファ数を計数する計数手段2と、
前記判定手段で新規リクエストが到着していると判定された場合に、前記計数された前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行する手段とを備えることを特徴を有するマルチメディア蓄積配信サーバ。 - 前記リクエストが送信リクエストである場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行し、
前記リクエストが受信リクエストである場合、前記計数された前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行することを特徴とする請求項1または請求項2に記載のマルチメディア蓄積配信サーバ。 - 前記ストレージは、複数に分割されていることを特徴とする請求項1ないし請求項3のいずれか1項に記載のマルチメディア蓄積配信サーバ。
- 前記マルチメディアデータを、前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶するキューと、
前記キューから順にリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行い、前記キューから全てのリクエストの処理が完了した際に、前記未受信バッファ数または前記未送信バッファ数を計数して、その数に基づき前記キュー内に格納されているリクエストの順序を入れ替える手段とを備えることを特徴とする請求項1ないし請求項4のいずれか1項に記載のマルチメディア蓄積配信サーバ。 - 前記マルチメディアデータを、前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶する第1のキューと、
新規にリクエストが到着したことを示すフラグに代えて、リクエストを格納する第2のキューとを備え、
前記判定手段は、前記フラグがセットされているか否かを判定する代わりに前記第2のキューにリクエストが格納されているかどうかを判定して新規リクエストが到着したか否かを判定し、
前記第1のキューから順にリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行い、前記第1のキューに格納されているリクエストを全て処理した後、前記第1のキューと前記第2のキューを連結する手段とを備えることを特徴とする請求項1ないし請求項4のいずれか1項に記載のマルチメディア蓄積配信サーバ。 - 複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバであって、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグとを備えるマルチメディア蓄積配信サーバにおけるマルチメディアデータ多重読出し書込み方法において、
前記端末から新規にリクエストが到着したことを示すフラグをセットするステップと、
前記フラグがセットされているかどうかを判定し新規リクエストが到着したか否かを判定する判定ステップと、
前記ストレージから読み出され未送信である前記マルチメディアデータが格納されている未送信バッファ数を計数するステップと、
前記判定ステップにおいて新規リクエストが到着していると判定された場合に、前記未送信バッファ数に基づき、前記ストレージから前記マルチメディアデータの読み出しを実行するステップとを備えることを特徴とするマルチメディアデータ多重読出し書込み方法。 - 複数のマルチメディアデータを複数の端末に対して同時に送受信するマルチメディア蓄積配信サーバであって、
前記複数のマルチメディアデータを保存するストレージと、
前記マルチメディアデータを前記端末に対して送受信する際に前記マルチメディアデータを一時的に保存するバッファと、
新規にリクエストが到着したことを示すフラグとを備えるマルチメディア蓄積配信サーバにおけるマルチメディアデータ多重読出し書込み方法において、
前記端末から新規にリクエストが到着したことを示すフラグをセットするステップと、
前記フラグがセットされているかどうかを判定し新規リクエストが到着したか否かを判定する判定ステップと、
前記端末から受信したマルチメディアデータを格納することが可能な未受信バッファ数を計数するステップと、
前記判定ステップにおいて新規リクエストが到着していると判定された場合に、前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行するステップとを備えることを特徴とするマルチメディアデータ多重読出し書込み方法。 - 前記リクエストが送信リクエストである場合に、前記計数された前記未送信バッファ数に基づき、前記ストレージから前記バッファへの読出しを実行し、
前記リクエストが受信リクエストである場合、前記計数された前記未受信バッファ数に基づき、前記バッファから前記ストレージへの書き出しを実行することを特徴とする請求項7または請求項8に記載のマルチメディアデータ多重読出し書込み方法。 - 前記ストレージは、複数に分割されていることを特徴とする請求項7ないし請求項9のいずれか1項に記載のマルチメディアデータ多重読出し書込み方法。
- マルチメディアデータを前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶するキューを備え、
前記キューから順にリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行うステップと、
前記キューから全てのリクエストの処理が完了した際に、前記未受信バッファ数または前記未送信バッファ数を計数して、その数に基づき前記キュー内に格納されているリクエストの順序を入れ替えるステップとを備えることを特徴とする請求項7ないし請求項10のいずれか1項に記載のマルチメディアデータ多重読出し書込み方法。 - 前記マルチメディアデータを、前記ストレージと前記バッファとの間で転送するリクエストの順序を記憶するキューと、
新規にリクエストが到着したことを示すフラグに代えて、リクエストを格納する第2のキューとを備え、
前記判定ステップは、前記フラグを判定する代わりに前記第2のキューにリクエストが格納されているかどうかを判定して新規するリクエストが到着したか否かを判定し、
前記第1のキューからリクエストを取り出し、前記ストレージと前記バッファとの間で該当するマルチメディアデータの転送を行うステップと、
前記第1のキューに格納されているリクエストを全て処理した後、前記第1のキューと前記第2のキューを連結するステップを備えることを特徴とする請求項7ないし請求項10のいずれか1項に記載のマルチメディアデータ多重読出し書込み方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006184625A JP4675290B2 (ja) | 2006-07-04 | 2006-07-04 | マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006184625A JP4675290B2 (ja) | 2006-07-04 | 2006-07-04 | マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2008017033A JP2008017033A (ja) | 2008-01-24 |
JP4675290B2 true JP4675290B2 (ja) | 2011-04-20 |
Family
ID=39073659
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006184625A Active JP4675290B2 (ja) | 2006-07-04 | 2006-07-04 | マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4675290B2 (ja) |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101006727B (zh) * | 2005-05-18 | 2010-05-19 | 日本电信电话株式会社 | 分布式多媒体服务器系统和多媒体信息发布方法 |
-
2006
- 2006-07-04 JP JP2006184625A patent/JP4675290B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2008017033A (ja) | 2008-01-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3617089B2 (ja) | 映像蓄積配送装置及び映像蓄積配送システム | |
KR100231220B1 (ko) | 다수의 디스크상에 저장된 스트라이프들로 분할되어 있는 데이타 유닛들중 요청된 데이타 유닛을 검색하는 방법 및 장치(A disk access method for delivering multimedia and video information on ctemand over wide area networks) | |
CA2701621C (en) | Modular storage server architecture with dynamic data management | |
US7730238B1 (en) | Buffer management method and system with two thresholds | |
US9391857B2 (en) | Scheduling requests for data transfers in a multi-device storage system | |
US20120324160A1 (en) | Method for data access, message receiving parser and system | |
JP2950223B2 (ja) | データ読出装置 | |
US20090013104A1 (en) | Storage system providing stream-oriented performance assurance | |
JP3190813B2 (ja) | 配信システム | |
JPH11119923A (ja) | データアクセス制御装置及びデータアクセス制御プログラムを記録した媒体 | |
CA2444438A1 (en) | System and method for retrieving and storing multimedia data | |
US7587549B1 (en) | Buffer management method and system with access grant based on queue score | |
JP2003525486A (ja) | 有限要求リオーダを用いるディスク・スケジューリング・システム | |
CN102521279A (zh) | 一种流媒体文件播放方法、系统及播放器 | |
JP2013539566A (ja) | コンピュータシステム及び当該コンピュータシステムを動作させる方法 | |
JP4675290B2 (ja) | マルチメディア蓄積配信サーバ、および、マルチメディアデータ多重読出し書込み方法 | |
CN116107635A (zh) | 命令分发器、命令分发方法、调度器、芯片、板卡、设备 | |
WO2009033971A1 (en) | System and method for splitting data and data control information | |
JP2005508114A (ja) | 家庭用ビデオ・サーバのための受入れ制御システム | |
Le Moal et al. | A real-time file system for constrained quality of service applications | |
KR20110088287A (ko) | 스토리지 액세스 스케줄링을 이용한 고성능 주문형 비디오 장치 | |
KR20100020679A (ko) | 스토리지 접근 스케줄링 기술을 이용한 고성능 주문형비디오 장치 | |
JP3416498B2 (ja) | サーバ装置およびその制御方法並びにサーバ装置制御プログラムを記録した記録媒体 | |
JP2009064189A (ja) | ファイル書込みシステムおよび方法 | |
JPH10275418A (ja) | マルチメディアサーバおよびマルチメディアオンデマンドシステムならびにマルチメディア情報の配信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20071212 |
|
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: 20110125 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110125 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140204 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4675290 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
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 |