JP4203140B2 - ストリームデータ転送方法およびシステム - Google Patents
ストリームデータ転送方法およびシステム Download PDFInfo
- Publication number
- JP4203140B2 JP4203140B2 JP06991998A JP6991998A JP4203140B2 JP 4203140 B2 JP4203140 B2 JP 4203140B2 JP 06991998 A JP06991998 A JP 06991998A JP 6991998 A JP6991998 A JP 6991998A JP 4203140 B2 JP4203140 B2 JP 4203140B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- data
- client
- server
- 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.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、多数のコンピュータが接続されたコンピュータネットワークにおけるデータ転送方法およびシステムに関し、特に、時間的に連続するデータであるストリームデータの転送方法およびシステムに関するものである。
【０００２】
【従来の技術】
近年、コンピュータの能力の向上、コンピュータのネットワーク接続の一般化によって、コンピュータネットワークを介してストリームデータのリアルタイムな転送が要求されている。ここでストリームデータとは、映像、音声などの時間的に連続なデータをいう。このストリームデータは当然パケットに編集されてネットワーク上で転送されるが、このとき、パケットの所定数の集合体単位で扱う場合、あるいはそのような集合体単位に関係なく扱われる場合を問わずここではストリームデータという。
【０００３】
図１４は従来のストリームデータ転送システムの一例を示すものである。このシステムはデータを提供する側のサーバ５００と、データの提供を受ける側のクライアント５０８とよりなり、その間にネットワーク５０７が介在することになる。以下、図１４に基づいて従来のシステムについて、その動作とともに更に説明する。
【０００４】
サーバ５００は、以下のように構成される。すなわち、以下に説明するように、クライアント５０８側からストリームデータの転送開始要求が出されると、該要求はパケット受信部５０１を介して開始要求処理部５１６に渡され、該開始要求処理部５１６がレート制御部５０５を起動することになる。該レート制御部５０５はハードディスク等の補助記憶装置５０３よりストリームデータを読み出して、一旦送信バッファ５０４に蓄積する。
【０００５】
上記レート制御部５０５には、クライアント５０８の再生レートとネットワークの転送可能容量に応じて予め所定の送出レートが設定されおり、送信バッファ５０４に蓄積されたストリームデータは該レート制御部５０５の制御に基づいて上記所定の送出レートで読み出されてパケット送信部５０２に転送され、該パケット送信部５０２では該ストリームデータをパケットに組み込んでネットワーク５０７に送出することになる。
【０００６】
一方、クライアント５０８は以下のようになっている。すなわち、ネットワーク５０７より受信したデータパケットはパケット受信部５０９に受け取られ、ここでパケットが解かれて受信バッファ５１１に順次蓄積される。データ再生部５１２は上記のように受信バッファ５１１に蓄積されたデータを順次所定の再生レートで読み出して表示装置に渡すようになっている。
【０００７】
転送の開始を制御するために、クライアント５０８側に転送開始要求部５１７が備えられ、オペレータの指示に従って、この転送開始要求部５１７が転送開始要求を出す。この転送開始要求はパケット送信部５１０に渡され、ここで転送開始要求パケットに編集され、ネットワーク５０７を介してサーバ５００に転送される。これによって、サーバ５００の開始要求処理部５１６が上記したようにレート制御部５０５を起動してデータ転送が開始されることになる。
【０００８】
以上の動作を繰り返しサーバとクライアント間でストリームデータの転送が行われることになるが、一般にコンピュータネットワークは該ネットワークの状態によってある程度のパケット落ちが発生し、また、クライアントのコンピュータでの処理能力の不足、ストリームデータの再生レートの揺らぎ等で受信バッファのあふれが発生した場合にはデータ欠落が発生する。
【０００９】
そこで、上記従来のシステムにおいても、データが欠落した場合の補償をすることがなされている。
すなわち、まず、クライアント５０８の欠落率報告部５１３が受信バッファ５１１を常時監視するようにしておき、データ欠落が発生したときにデータ欠落率の報告をパケット送信部に渡す。ここで、サーバ５００のアドレスと送出レート変更要求パケットである旨の識別子と上記欠落率が載せられたレート変更要求パケットを作成し、ネットワークに送出する。
【００１０】
このように送出されたレート変更要求パケットはサーバ５００のパケット受信部５０１に受け取られ、ここで、レート変更要求パケットである旨の判別がなされてレート変更部５０６に渡される。このレート変更部５０６には、例えば上記レート変更要求パケットに含まれる上記クライアント５０８での欠落率に応じた送出レートがテーブルとして備えられており、レート変更部５０６は該テーブルを参照して新たな送出レートを決定し、該送出レートをレート制御部５０５に転送する。これによって、レート制御部５０５は送出レートを下げて（あるいは上げて）送信バッファ５０４からストリームデータを読み出しパケット送信部５０２に渡すことになる。
【００１１】
【発明が解決しようとする課題】
しかしながら、このような従来のストリームデータ転送システムでは、上記のようにクライアント５０８がデータの欠落を検出してからはじめてサーバ５００からの送出レートを下げるという手順で処理されているため、一旦欠落したデータの再生はできなくなり、更に、欠落が生じた状態のデータを再生した場合には画像の揺らぎが発生するという欠点を有していた。
【００１２】
尚、ストリームデータ以外の例えばテキストデータをサーバ５００からクライアント５０８に転送する方法として、図１５に示すような方法がある。すなわち、所定サイズ単位のデータ“Data”がサーバ５００からクライアント５０８に転送される毎に確認信号“Ack ”がクライアント５０８からサーバ５００に返えされ、該確認信号“Ack ”を受けてサーバ５００が新たなデータ“Data”を送出するようになっている。
【００１３】
この方法でストリームデータを転送すると、クライアント５０８はデータ抜けのデータを受け取ると確認信号“Ack ”を返さないことになり、サーバは次のデータ“Data”を送出できなくなる。この状態になると、例えば所定時間Ｔ0 が経過するまで次のデータは転送されないので、受信バッファ５１１にデータ欠乏が発生することになり、画像が止まったり、乱れたりする。
【００１４】
本発明は、上記従来のストリームデータ転送システムの欠点に鑑みて提案されたものであって、クライアントのバッファにデータ欠落を発生するする前にサーバからの送出レートを下げ、また、たとえクライアントのバッファにデータが欠落した場合であっても、該欠落データを再送することによって、より信頼性のあるストリームデータ転送方法及びシステムを提供することを目的とする。
【００１５】
更に、本発明は、サーバより複数のクライアントに同時に同一データを転送するマルチキャスト転送方式であっても、上記の目的を有効に達成することができるストリームデータ転送方法及びシステムを提供することを目的とするものである。
【００１６】
【課題を解決するための手段】
上記目的を達成するために本発明は以下の手段を採用している。先ず、本発明が適用されるストリームデータ転送システムは、以下のサーバ４００と、クライアント４７０を備えた構成となっている。上記サーバ４００は、記憶手段（図１上では補助記憶装置４０３と送信バッファ４０４）よりレート制御部４０５の制御に基づいて所定の送出レートで読み出したストリームデータをパケット送信部４０２でパケットに編集してネットワーク３００を介してクライアント４７０に転送するとともに、クライアント４７０よりの要求をパケット受信部４０１で受けて必要な処理をする。
【００１７】
また、上記クライアント４７０は、上記サーバ４００よりネットワーク３００を介して所定の送出レートで送出されるストリームデータをパケット受信部４１０で受信して受信バッファ４１２に一旦蓄積して再生するとともに、上記サーバ４００に対する必要な指示をパケット送信部４１１より送出する。
【００１８】
上記システムにおいて、本発明は上記受信バッファ４１２の空き状態に対応してクライアント４７０側よりレート変更要求を出し、該レート変更要求に基づいてサーバ４００側の送出レートを変更するようにする。
【００１９】
具体的には、クライアント４７０側にレート変更要求部４１３を備えて、受信バッファ４１２の空き容量を監視し、該空き容量に応じたレート変更要求を出すようにする。一方、サーバ４００側にレート変更要求処理部４１６を備えるようにして、上記のようにクライアント４７０側より出されるレート変更要求に基づいて、上記レート制御部４０５に設定された送出レートを更新する構成とする。
【００２０】
これによって、受信バッファ４１２よりのストリームデータのオーバーフローはなくなることになる。
また、上記パケット受信部４１０で受信されたストリームデータの欠落に対応してクライアント４７０側より出される再送要求に基づいて、サーバ４００側の記憶手段より該欠落データに対応するデータを送出するようにもする。
【００２１】
具体的には、クライアント４７０側に再送要求部４１４を備え、上記パケット受信部４１０が受信するデータ欠落を監視するとともに、該欠落データに対応するデータをサーバ４００に再送要求を出すようにする。一方、サーバ４００側に再送制御部４０７を備えて上記再送要求に基づいて、欠落データに対応するストリームデータの再送処理を行うようにする。
【００２２】
これによって、たとえデータ欠落が発生しても該欠落を補完できることになる。
本発明は、上記レート変更処理に必要な構成のみを単独で使用することもでき、また再送処理に係る構成も単独で使用することも可能であり、更に、上記２つの処理を併用する構成とすることも可能である。
【００２３】
ところで、同一のデータを同時に複数のクライアントに転送することができるマルチキャスト転送方式に上記の方法をそのまま適用すると、サーバは、該マルチキャストを構成する各クライアントからの複数の要求に対応しなければならいことになる。このことはサーバやネットワークの負荷を増大させることになるので、マルチキャスト転送方式に上記の方法をそのまま利用することはできない。
【００２４】
そこで、本発明は上記同一マルチキャストグループに属する特定のクライアント４１ａの受信バッファの空き状態に対応して該特定のクライアント４１ａよりレート変更要求を上記サーバ４００に出すとともに、該レート変更要求に基づいて上記サーバ４００の送出レートを変更するようにする。
【００２５】
具体的には、上記同一マルチキャストグループに属する特定のクライアント４１ａにレート変更要求部４１３を備え、上記受信バッファ４１２の空き容量を監視するとともに、該空き容量に対応したレート変更要求を上記サーバに出するようにする。一方、上記サーバ４００にレート変更要求処理部４０６を備えるようにして、クライアント４１ａ側より出される上記レート変更要求に対応して、上記レート制御部４０５に設定された送出レートを更新する構成とする。
【００２６】
これによって、サーバ４００とネットワーク３００の負荷上昇を抑えつつ、クライアントの受信バッファにおけるマルチキャストストリームデータのオーバフローをなくすことになる。
【００２７】
また、上記同一マルチキャストグループに属する特定のクライアント４１ａのパケット受信部４１０で受信されたデータの欠落に対応して該特定のクライアント４１ａより再送要求を上記サーバ４００に出すとともに、該再送要求に基づいて上記サーバ４００の記憶手段より該欠落データに対応するデータを送出するようにもできる。
【００２８】
具体的には、上記同一マルチキャストグループに属する特定のクライアント４１ａに再送要求部４１４を備え、また、上記サーバ４００に再送制御部４０７を備えた構成とする。この構成において、上記再送要求部４１４で、上記パケット受信部４１０が受信するデータ欠落を監視して、該欠落データに対応するデータを上記サーバ４００に再送要求を出すようにするとともに、上記再送制御部４０７で上記再送要求に基づいて、上記欠落データに対応するストリームデータの再送処理を行うようにしたものである。
【００２９】
これによって、たとえデータ欠落が発生しても、サーバとネットワークの負荷上昇を抑えつつ、該欠落を補完出来ることになる。
また、上記特定のクライアント４１ａより上記レート変更要求を上記サーバ４００および上記同一マルチキャストグループに属する全てのクライアントに発行するようにしておく。この状態で、他の特定のクライアントよりの上記特定のクライアントの発行したレート変更要求と同一のレート変更要求の発行（他の特定のクライアントが発行）をあらかじめ設定した所定時間だけ禁止する。あるいは上記サーバが複数のクライアントより同一の上記レート変更要求をあらかじめ設定した所定時間内に受信した場合、これらレート変更要求のうち一つを有効として、該レート変更要求に基づいてサーバの送出レートを変更するようにすることができる。
【００３０】
具体的には、図９に示すように上記特定のクライアント４１ａに、他の特定のクライアントから出されたレート変更要求と同一のレート変更要求の発行をあらかじめ設定した所定時間だけ禁止するレート変更要求抑制部４１５を備える。あるいは図１０に示すように上記サーバ４００に、該サーバが複数のクライアントより同一の上記レート変更要求をあらかじめ設定した所定時間内に受信した場合、これらレート変更要求のうち一つを有効とする同一レート変更要求処理部４０８を備える構成とする。
【００３１】
また、上記特定のクライアント４１ａより上記再送要求を上記サーバ４００および上記同一マルチキャストグループに属する全てのクライアントに発行するとともに、他の特定のクライアントより上記再送要求と同一の再送要求の発行をあらかじめ設定した所定時間だけ禁止するようにすることができる。あるいは上記サーバ４００が複数のクライアントより同一の上記再送要求をあらかじめ設定した所定時間内に受信した場合、これら再送要求のうち一つを有効として、該再送要求に基づいて上記サーバ４００の記憶手段より該欠落データに対応するデータを送出するようにすることができる。
【００３２】
具体的には、図９に示すように上記特定のクライアント４１ａに、他の特定のクライアントから出された再送要求と同一の再送要求の発行をあらかじめ設定した所定時間だけ禁止する再送要求抑制部４１６を備える。あるいは図１０に示すように上記サーバ４００に、該サーバ４００が複数のクライアントより同一の上記再送要求をあらかじめ設定した所定時間内に受信した場合、これら再送要求のうち一つを有効とする同一再送要求処理部４０９を備える構成とする。
【００３３】
上記の手順によって、上記サーバ４００およびネットワーク３００の負荷を抑えることができることになる。
また、ストリームデータ送信前に上記サーバ４００が、上記レート変更要求の送出可能な同一マルチキャストグループに属するクライアント全てより、該クライアントがレート変更要求を出す条件を得て、同一マルチキャストグループで共存困難な条件をもつクライアントに対しては、別のマルチキャストグループでデータを転送することも可能である。あるいはストリームデータ送信前に上記特定のクライアントが、上記レート変更要求の送出可能な同一マルチキャストグループに属する他のクライアント全てより、該他のクライアントがレート変更要求を出す条件を得て、当該他のクライアントが同一マルチキャストグループで共存困難な条件をもつ場合、別のマルチキャストグループとしてデータを受信することも可能である。
【００３４】
具体的には、図１１に示すように上記サーバ４００に送出先グループ分割制御部４１８を備えておき、同一マルチキャストグループで共存困難な条件をもつ上記クライアントに対しては、別のマルチキャストグループでデータを転送するよう制御する。また図１２に示すように上記特定のクライアントにグループ分割制御部４１９を備えておき、特定のクライアントが同一マルチキャストグループで共存困難な条件をもつ場合、別のマルチキャストグループでのデータの受信を行う。
【００３５】
よって、共存可能な条件をもつクライアントを同一のマルチキャストグループに属するようにし、それぞれのマルチキャストグループに対して別々のマルチキャストアドレスのもとでストリームデータを配信する。従って、より多くのクライアントに対するデータ転送の信頼性を向上することが出来る。
【００３６】
本発明は、上記レート変更処理に必要な構成のみを単独で使用することもでき、また再送処理に係る構成のみを単独で使用することも可能であり、更に、上記２つの処理を併用する構成とすることも可能である。
【００３７】
【実施の形態】
（実施の形態１）
図１は本発明のストリームデータ転送システムの１実施例を示すものであり、以下図１に基づいて本発明のシステムの構成についてその動作とともに説明する。
【００３８】
本システムはサーバ４００とクライアント４７０がネットワーク３００で結ばれている点は上記従来のシステムと全く同様である。
オペレータがキーボード、あるいはカーソル等の入力手段と画面を用いて特定のファイルの転送指示を出すと、クライアント４７０の転送開始要求部４８０が開始要求をパケット送信部４１１に通知し、これを受けて、パケット送信部４１１は図６(d) に示すように発信元アドレス▲１▼、送信先アドレス▲２▼、パケット種別識別子（転送開始要求）▲３▼、ファイルを特定する事項（ファイル名あるいはファイル番号）▲７▼、更に必要に応じて以下に説明する転送開始位置番号▲８▼を載せた転送要求パケットをネットワーク３００に送出する。
【００３９】
上記転送開始位置番号とは、後述するようにサーバ４００側のレート制御部４０５で生成され、パケット送信部４０２で送信されるデータパケットに付されるパケット番号とは別の当該データのファイル上の位置を示す番号であって、後述する再送処理に必要となる。すなわち、図４に示すように上記指定されたファイルＦを特定のバイト単位〔例えば１パケット相当のバイト数（例えば１Ｋｂ）〕で区切って形成したセクションに、順次割り振った番号（ｆのサフィックスを付して表している）の中の読み出し開始位置に相当する番号であって、ファイルの先頭から読み出すときは、該番号はもちろん０であるが、途中から読み出すときは該当位置に対応する番号を示すことになる。もっとも、オペレータは例えば先頭から読み出し開始位置に対応する迄の時間等オペレータの理解できる数値で当該転送開始位置を指定し、該数値を上記転送開始要求部４８０が上記のセクションの番号に変換することになる。もっとも、この位置番号は後述する再送処理をする場合には上記データパケットに載せる必要があるが、再送処理をしない場合には上記データパケットに載せる必要はないことになる。
【００４０】
このようにネットワーク３００に送出された転送要求パケットはサーバ４００のパケット受信部４０１に受け取られて、ここで上記パケット識別子▲３▼より転送要求パケットである旨の判断がなされ開始要求処理部４１７に転送される。これによって、開始要求処理部４１７では上記のように特定されたファイル名、ファイル番号等のファイルを特定する事項▲７▼、および転送開始位置番号▲８▼をレート制御部４０５に渡し、該レート制御部４０５を起動する。これによって、該レート制御部４０５は補助記憶装置４０３の上記転送開始位置番号▲８▼に対応するアドレスよりストリームデータを順次読み出して送信バッファ４０４に一旦蓄積する。
【００４１】
上記レート制御部４０５には、以下に説明するクライアント４７０の再生レートとネットワーク３００の伝送可能容量に依存して決定される送出レートが設定されており、上記のように送信バッファ４０４に蓄積されたストリームデータは該送信バッファ４０４から上記の送出レートで読み出されてパケット送信部４０２に転送される。パケット送信部４０２ではこのようにして得られたストリームデータを、データパケットに組み込んでネットワーク３００に送出する。このデータパケットには、図６(a) に示すように、発信元アドレス（サーバ４００のアドレス）▲１▼、受信先アドレス（クライアント４７０のアドレス）▲２▼、データパケットである旨のパケット識別子▲３▼、データサイズ▲４▼、パケットの順序を表すパケット番号▲５▼がヘッダ部に載せられ、実データがそれに続くようになっている。
【００４２】
尚、再送処理機能を持たせる場合には、上記パケット番号とは別にレート制御部４０５で形成されるファイル上の位置が特定出来る情報、例えば図４を用いて上記に説明したファイルを所定量のデータブロックで区切ったときのセクションの番号（位置番号）をパケットのヘッダに載せるようにする。ファイルを該ファイルの先頭から読み出すときであって、上記１セクションの容量単位が１パケットの容量単位と一致するときには上記パケット番号と当該位置番号は一致することになるが、両者の容量が異なるとき、あるいは上記のようにファイルの途中から読み出すときには一致しないことになる（図５参照）。
【００４３】
上記のようにネットワーク３００に送出されたデータパケットはクライアント４７０のパケット受信部４１０に受け取られ、ここでパケット種の識別子▲３▼よりデータパケットである旨の判別がなされるとともに、上記パケット番号とパケットサイズを参照して、受信バッファ４１２の所定のアドレスに書き込むようにする。
【００４４】
ここで、パケット受信部４１０は上記のようにサーバ４００側のパケット送信部４０２で付されたパケット番号▲５▼を管理しており、何らかの原因でパケット受信部４１０に順次到達するパケットのパケット番号が前後しても、当該パケット受信部４１０で順番が整理されるようになっている。
【００４５】
また、パケットの欠落なく転送されてきたストリームデータは、各パケット番号に対応して図５(a) に示すように受信バッファ４１２に隙間無く書き込まれるようになる。ところが、パケットに欠落があった場合には図５(b) に示すように、該欠落パケットのデータサイズだけ受信バッファ４１２上に空白をあけてストリームデータが書き込まれるようになる。尚、図５においてｐのサフィックスが付された番号はパケット番号であり、ｆのサフィックスが付された番号はファイル上の位置番号であり、後に説明するように、再送処理をする場合はクライアント４７０のパケット受信部４１０は、上記のようにパケット番号を管理するとともに、上記ファイル上の位置番号をも管理する機能をも持つようにする。
【００４６】
尚、図５においてパケット番号は０から順次インクリメントしているが、ファイル上の位置番号は途中から（３００番目から）始まっているいる例を示している。すなわち、ファイルを先頭からではなく、途中から読み出す場合に相当する。
【００４７】
このように受信バッファ４１２に書き込まれたデータはデータ再生部４９０により所定の再生レートで読み出されて再生されるようになっている。再生レートは画像種によっては時間的に変動することがあるが、上記送出レートと再生レートは均衡を保つように設定される必要があることはもちろんである。また、このとき受信バッファ４１２にデータがない状態でデータ再生部４９０が受信バッファ４１２をアクセスする状態を回避する必要があるところから、該受信バッファ４１２に一定量のデータが蓄積された状態から再生開始がなされるようにする。
【００４８】
以上の動作を繰り返すことによって、サーバとクライアント間でストリームデータの転送が行われることになるが、上記の処理はファイル上の位置を特定する情報（位置番号）に関する記述を除いて従来のシステムにおける手順と全く同じである。
【００４９】
上記において、サーバ４００側のパケット送信部４０２の送出レートとクライアント４７０側のデータ再生部４９０の再生レートが平衡している場合には、受信バッファ４１２の空きは一定に保たれることになる。ところが、クライアント４７０のコンピュータの処理能力の不足、ストリームデータの再生レートの揺らぎ等に起因して受信バッファ４１２の空き容量が減少する場合があり、この状態が継続すると、受信バッファ４１２がオーバフローになることになりデータ欠落が発生する。そこで、以下のようにサーバ４００側の送出レートを変更する処理を行う。
【００５０】
すなわち、クライアント４７０のレート変更要求部４１３は受信バッファ４１２の空き容量を常に監視しておき、受信バッファ４１２の空き容量が所定の設定値（例えば空き容量が２０％）より減ったことを検出したとき、送出レートを下げることを要求するレート変更要求を要求レートとともにパケット送信部４１１に通知する。このレート変更要求通知を受けたパケット送信部４１１は図６(b) に示すように、発信元アドレス（クライアント４７０のアドレス）▲１▼、送信先アドレス（サーバのアドレス）▲２▼、レート変更要求である旨のパケット識別子▲３▼、要求レート▲６▼を組み込んだレート変更要求パケットをネットワーク３００に送出する（図２、ステップＳ２１→Ｓ２２→Ｓ２５参照）。
【００５１】
サーバ４００のパケット受信部４０１はネットワーク３００から上記レート変更要求パケットを受け取り、その識別子からレート変更要求パケットである旨の判断をして、その内容をレート変更要求処理部４０６に渡す。これによってレート変更要求処理部４０６は新しい送出レートをレート制御部４０５に渡して送出レートを下げる要求を行い、レート制御部４０５は送出レートを下げて送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００５２】
このように、データパケットの送出レートを下げると、受信バッファ４１２の空き容量は次第に増えることになるが、この状況も、上記レート変更要求部４１３に監視されており、該空き容量が所定値（例えば８０％）以上に増加すると上記レート変更要求部４１３は送出レートを上げるレート変更要求をパケット送信部４１１に通知し、該通知を受けてパケット送信部４１１は上記と同様の処理を行いレート変更要求パケットを作成しネットワーク３００へ送信する（図２、ステップＳ２３→Ｓ２４→Ｓ２５参照）。
【００５３】
サーバ４００のパケット受信部４０１がネットワーク３００からパケットを受け取り、上記の送出レートを低くする場合のレート変更と同様、レート変更要求処理部４０６が要求された送出レートをレート制御部４０５に渡すことによって、該レート制御部４０５は増加された送出レートでの送出を行うことになる。
【００５４】
このように動作することによって、クライアント４７０の受信バッファ４１２がオーバフローする前にストリームデータの転送レートが下げられるためにデータの欠落が発生しなくなるとともに、クライアント４７０の受信バッファ４１２に蓄積されたストリームデータが欠乏する前にストリームデータの送出レートが上げられるため、ストリームデータが欠落なく受信バッファ４１２に蓄積されることになる。
【００５５】
尚、上記の例ではクライアント４７０側で送出レートを決定するようになっているが、クライアント４７０からはレート変更要求と受信バッファ４１２の空き容量（例えば％で表した空き容量）のみを出力し、実際の送出レートはサーバ４００側のレート変更要求処理部４０６で上記空き容量に対応する送出レートを決定してレート制御部４０５に設定するようにしてもよい。
【００５６】
また、上記の説明では受信バッファ４１２の空き容量が所定値以下になったときに送出レートを下げ、所定値以上になったときに送出レートを上げるようにしているが、別の方法として、受信バッファ４１２の空き容量が所定値以下（例えば２０％以下）になったときに送出レートを０にして、サーバ４００よりの送出をストップするようにし、所定値以上（例えば８０％以上）になったときに送出レートを所定の値に戻すようにしてもよい。
【００５７】
以上のように送出レートを調整しても、何らかの原因、例えばネットワーク３００の状況によってはデータパケットの欠落が発生することがあり、また、ノイズ等の外的な要因によってもデータパケットの欠落が発生することがある。
【００５８】
そこで、クライアント４７０の受信バッファ４１２に蓄積されるストリームデータに図５(b) に示すような欠落ができるか否かを、再送要求部４１４が検出するようになっている。現実には再送要求部４１４はパケット受信部４１０を常時監視しており、上記ファイル上の位置番号（図５上ｆのサフィックスが付されている）に欠落があったとき、その前後の位置番号より欠落パケットに対応する位置番号を算出する。このように算出された位置番号は、データの再送を要求する再送要求とともにパケット送信部４１１に通知される。
【００５９】
パケット送信部４１１では、上記再送要求を受けて発信元アドレス（クライアントのアドレス）▲１▼、送信先アドレス（サーバのアドレス）▲２▼、パケット種別識別子（再送要求）▲３▼、再送要求に係る位置番号▲９▼、および再送されるデータのサイズ▲４▼を載せた図６(c) に示す再送要求パケットをネットワーク３００に送出する（図３、ステップＳ３１→Ｓ３２→Ｓ３３参照）。
【００６０】
このようにネットワーク３００に送出された再送要求パケットは、サーバ４００のパケット受信部４０１に受け取られ、ここで、再送要求パケットである旨の判断がなされ、該パケットの内容が再送制御部４０７に通知される。これによって、再送制御部４０７は再送要求に含まれる位置番号に従って送信バッファ４０４から所定のサイズのストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００６１】
パケット送信部４０２は通常のデータ転送と同様、受け取ったデータを、図６(a) に示すデータパケットに組み込んでネットワーク３００へ送出する。
上記したように、パケット受信部４１０は受信バッファ４１２に蓄積されているデータに対応するパケット番号と上記ファイル上の位置番号を管理している。この状態で、パケット受信部４１０にデータパケットが受け取られると、当該パケットに付された上記ファイル上の位置番号より、格納すべき受信バッファ４１２上のアドレスを演算して、データが欠落したアドレスに挿入するようになっている。
【００６２】
このように動作することによって、ネットワークでのパケット落ちが発生した場合でも高速に再送を行うことができるためデータの欠落が発生しないことになる。
【００６３】
尚、上記の説明においては、ファイル上の位置が特定出来る情報として上記位置番号を用い、該位置番号をパケットのヘッダに載せる構成で説明を行っているが、これに代えてファイル上の位置が特定出来る情報としてストリームデータ内での時間を用い、該時間をパケットのヘッダに載せる構成とすることも可能である。
【００６４】
更に、上記のようなファイル上の位置が特定出来る情報をパケットのヘッダに載せる構成に代えて、上記再送制御部４０７において、転送対象のデータに対応するパケット番号と、該データのファイル上の位置が特定出来る情報とを管理することとし、上記クライアント４７０の再送要求部４１４が上記パケット番号を含む再送要求を行う構成とすることも可能である。
【００６５】
以上のように本実施例のデータ転送方法によれば、クライアントの処理能力の不足、ストリームデータの再生レートの揺らぎ等が発生してもデータの欠落が発生せず、さらにネットワークでのパケット落ちが発生した場合でもデータの欠落が発生せずにストリームデータを転送することができる。
【００６６】
（実施の形態２）
ところで、複数クライアントへ同一データを同時に転送する場合、マルチキャスト転送方式が使用されることがある。すなわち、一つのグループをあらかじめ定義し、転送対象となるクライアントをそのグループに登録しておくと、サーバは上記グループ宛にデータを送ることにより、登録されたクライアントすべてにデータを転送することが可能である。これによって、転送対象となるクライアントごとにサーバから個別にデータを転送する必要がなく、効率的に同一データを複数クライアントに転送出来ることになる。
【００６７】
ところが、上記の実施の形態をそのままマルチキャスト方式に適用すると、例えば特定のマルチキャストを構成する全てのクライアントがサーバに上記レート変更要求パケットや上記再送要求パケットを送る場合が発生する。このような場合、サーバやネットワークの負荷が過度に高くなり、別の障害例えばクライアント側のバッファにデータがなくなり、表示が途切れるといった現象の発生につながる可能性がある。
【００６８】
そこで本実施の形態は、マルチキャスト方式のシステムであっても、上記の実施の形態が有効に作動する構成を提案するものである。
図７は本発明のマルチキャストストリームデータ転送システムの一実施例を示すブロック図であり、以下図７に基づいて本発明のシステムの構成についてその動作とともに説明する。
【００６９】
図７において、マルチキャストグループはデータを提供する側のサーバ４００と、データの提供を受ける側でレート変更要求および再送要求機能の少なくとも一方を備えたクライアント（以下、要求クライアントという）４１ａと、同じくデータの提供を受ける側でレート変更要求および再送要求機能を備えないクライアント（以下、通常クライアントという）４２ａ、４２ｂ…とより構成され、上記サーバ４００と要求クライアント４１ａ、通常クライアント４２ａ、４２ｂ…の間にネットワーク３００が介在することになる。ただし、必要に応じて上記要求クライアントを複数とすることも可能である。
【００７０】
すなわち、上記要求クライアント４１ａには、図１に示したクライアント４７０と同様、レート変更要求部４１３および再送要求部４１４のいずれか少なくとも一方が備えられるが、通常クライアント４２ａ、４２ｂ…にはこれらは備えられない。
【００７１】
上記構成において、上記サーバ４００におけるオペレータ等によるデータ転送開始指示または要求クライアント４１ａからの転送開始要求等により、開始要求処理部４１７ではファイル名、ファイル番号等のファイルを特定する事項をレート制御部４０５に渡し、該レート制御部４０５を起動する。これによって、該レート制御部４０５は補助記憶装置４０３の特定されたファイルよりストリームデータを順次読み出して送信バッファ４０４に一旦蓄積する。
【００７２】
この後、要求クライアント４１ａとサーバ間でのデータ伝送が実行されるが、この手順は上記図１の説明において記述した内容と全く同じであるのでここでは説明を省略する。但し、この実施の形態はマルチキャスト方式に適用されているので、サーバからのストリームデータは要求クライアント４１ａだけでなく、上記通常クライアント４２ａ、４２ｂ…にも同時に転送されることになる。
【００７３】
要求クライアント４１ａの受信バッファ４１２の空き容量が所定値以下（所定値以上）になったときにレート変更要求を出す手順も、図２で説明した手順と同じであるので、ここでは説明を省略する。また、要求クライアント４１ａで受信したストリームデータに欠落が発生した場合に、再送要求をだす手順も上記図３で説明した手順と同じであるのでここでは説明を省略する。この実施の形態では、要求クライアント４１ａにのみレート変更要求部４１３、再送要求部４１４が備えられた構成となっているので、上記レート変更要求をだす権限、および、再送要求をだす権限は要求クライアント４１ａにのみに付与されていることになる。但し、上記レート変更要求が要求クライアント４１ａからだされると、マルチキャストを構成する全クライアントに対するデータ転送レートが変更されることになる。また、上記再送要求によって特定のデータパケットが再送されると、該パケットはマルチキャストを構成する全クライアントに受け取られることになる。
【００７４】
また、ここで使用されるデータパケット（図８(a) ）、レート変更要求パケット（図８(b) ）、再送要求パケット（図８(c) ）は図６に示す各パケットの内容と略同じであるが、送信先アドレスとして、マルチキャストアドレス（１つのマルチキャストを構成する複数のクライアントに共通のアドレス）が使用されることになる。
【００７５】
次に、図９は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図９に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００７６】
要求クライアント４１ｂのレート変更要求部４３３よりレート変更要求が出された場合、該レート変更要求通知を受けたパケット送信部４３１は、レート変更要求パケットをサーバ４００および同一マルチキャストグループでデータを受信している全てのクライアントに対して、図８(b) に示すように、発信元アドレス（要求クライアント４１ｂのアドレス）▲１▼、マルチキャストアドレス▲２▼、レート変更要求である旨のパケット識別子▲３▼、要求レート▲６▼を組み込んだレート変更要求パケットをネットワーク３００に送出する。
【００７７】
要求クライアント４１ａのパケット受信部４１１はネットワーク３００から上記レート変更要求パケットを受け取り、その識別子からレート変更要求パケットである旨の判断をして、該パケットの内容をレート変更要求抑制部４１５に通知する。これによって、該レート変更要求抑制部４１５では、上記レート変更要求と同一内容のレート変更要求を上記レート変更要求部４１３より発行しないようにあらかじめ設定した所定時間だけ禁止をかける。
【００７８】
尚、上記サーバ４００により受信された要求クライアント４１ｂからの上記レート変更要求パケットに基づく処理は上記実施例と同様である。また、要求クライアント４１ａのレート変更要求部４１３よりレート変更要求が出された場合も上記と同様である。また、上記レート変更要求パケットは通常クライアント４２９にも届くことになるが、該通常クライアント４２９はレート変更要求機能がないため、無視することとなる。
【００７９】
次に、要求クライアント４１ｂの再送要求部４３４より再送要求が出された場合、該再送要求通知を受けたパケット送信部４３１は、再送要求パケットをサーバ４００および同一マルチキャストグループでデータを受信している全てのクライアントに対して、図８(c) に示すように、発信元アドレス（要求クライアントのアドレス）▲１▼、マルチキャストアドレス▲２▼、パケット種別識別子（再送要求）▲３▼、再送要求に係る位置番号▲９▼、および再送されるデータのサイズ▲４▼を載せた再送要求パケットをネットワーク３００に送出する。
【００８０】
要求クライアント４１ａのパケット受信部４１０はネットワーク３００から上記再送要求パケットを受け取り、その識別子から再送要求パケットである旨の判断をして、その内容を再送要求制御部４１６に通知する。該再送要求制御部４１６では、上記再送要求の内容と同一の再送要求を上記再送要求部４３４より発行しないようにあらかじめ設定した所定時間だけ禁止をかける。
【００８１】
尚、上記サーバ４００に受信された要求クライアント４１ｂからの上記再送要求パケットに基づく処理は上記実施例と同様である。また、要求クライアント４１ａのレート変更要求部４１３よりレート変更要求が出された場合も上記と同様である。また、上記レート変更要求の場合と同様に、再送要求パケットは通常クライアント４２ａにも届くことになるが、該通常クライアント４２ａは再送要求機能がないため、無視することとなる。
【００８２】
以上のように、他の要求クライアントが既に送信したレート変更要求と同一内容のレート変更要求を発行しないこと、また他の要求クライアントが既に送信した再送要求と同一内容の再送要求レート変更要求を発行しないことにより、上記サーバ４００およびネットワーク３００の負荷を抑えることができる。
【００８３】
図１０は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図１０に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００８４】
要求クライアント４１ａ、４１ｂ…がレート変更要求パケットを送信した場合、サーバ４００のパケット受信部４０１はネットワーク３００から上記レート変更要求パケットを受け取り、その識別子からレート変更要求パケットである旨の判断をして、その内容を同一レート変更要求処理部４０８に通知する。該同一レート変更要求処理部４０８では、あらかじめ設定された所定時間内に通知を受けたレート変更要求のうち最初に受信したレート変更要求を有効にし、その内容をレート変更要求処理部４０６に渡す。
【００８５】
例えば、上記要求クライアント４１ａおよび要求クライアント４１ｂから、同一のレート変更要求を上記所定時間内に受けた場合（ここでは、上記要求クライアント４１ａからのレート変更要求が先であるとする）、上記要求クライアント４１ａからのレート変更要求を有効にし、その内容をレート変更要求処理部４０６に渡し、上記要求クライアント４１ｂからのレート変更要求は無効として扱う。これによってレート変更要求処理部４０６は上記要求クライアント４１ａからのレート変更要求に基づいて新しい送出レートをレート制御部４０５に渡して、レート制御部４０５は新しい送出レートにより送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００８６】
次に、上記要求クライアント４１ａ、４１ｂ…が再送要求パケットを送信した場合、サーバ４００のパケット受信部４０１はネットワーク３００から上記再送要求パケットを受け取り、その識別子から再送要求パケットである旨の判断をして、その内容を同一再送要求処理部４０９に通知する。該同一再送要求処理部４０９では、あらかじめ設定された所定時間内に通知を受けた再送要求のうち最初に受信した再送要求を有効にし、その内容を再送制御部４０７に渡す。
【００８７】
例えば、上記要求クライアント４１ａおよび要求クライアント４１ｂから、同一の再送要求を上記所定時間内に受けた場合（ここでは、上記要求クライアント４１ａからの再送要求が先であるとする）、上記要求クライアント４１ａからの再送要求を有効にし、その内容を再送要求処理部４０７に渡し、上記要求クライアント４１ｂからの再送要求は無効として扱う。これによって再送制御部４０７は上記要求クライアント４１ａからの再送要求に含まれる位置番号に従って送信バッファ４０４から所定のサイズのストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００８８】
以上のように、同一内容のレート変更要求を一つのレート変更要求として扱うこと、また同一内容の再送要求を一つの再送要求として扱うことにより、上記サーバ４００およびネットワーク３００の負荷を抑えることができる。
【００８９】
ところで、同一のマルチキャストグループに登録されたクライアントであっても、個々のクライアントの性能、例えばバッファ容量、バッファ処理速度等の違いにより同一のマルチキャストグループに共存困難なクライアントも存在することになる。このような場合であっても、上記実施例が有効に作動する構成を以下に説明する。
【００９０】
図１１は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図１１に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００９１】
上記サーバ４００におけるオペレータ等によるレート変更条件転送指示または要求クライアント４１ａ、４１ｂ…からの自発的な送信によって、要求クライアント４１ａ、４１ｂ…がレート変更要求を出す条件を通知するための条件通知パケットを送信する。ここで、該条件通知パケットで通知する上記レート変更要求を出す条件は、例えばバッファ容量、バッファ処理速度等である。次に、サーバ４００のパケット受信部４０１はネットワーク３００から上記条件通知パケットを受け取り、その識別子から条件通知パケットである旨の判断をして、その内容を送出先グループ分割制御部４１８に渡す。
【００９２】
該送出先グループ分割制御部４１８では、各要求クライアントから送信されたレート変更条件に基づいて各要求クライアントが現在属しているマルチキャストグループで共存可能か否かを判断する。一マルチキャストグループで共存困難な条件をもつ要求クライアントに対しては、別のマルチキャストグループでデータを転送するものとして、該別のマルチキャストグループでの送出レートをレート制御部４０５に通知する。
【００９３】
該レート制御部４０５は、同一マルチキャストグループで共存可能な条件をもつ要求クライアントに対しては、該マルチキャストグループの条件に適合する特定の送出レートによって、また上記別のマルチキャストグループに対しては、上記通知された別の送出レートによって、送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００９４】
図１２は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図１２に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００９５】
ストリームデータ送信前において、各要求クライアント４１ｂ…がレート変更要求を出す条件を通知するための条件通知パケットを送信する。ここで、該条件通知パケットで通知する上記レート変更要求を出す条件は、上記実施例と同様に例えばバッファ容量、バッファ処理速度等である。次に、要求クライアント４１ａのパケット受信部４１０はネットワーク３００から上記条件通知パケットを受け取り、その識別子から条件通知パケットである旨の判断をして、その内容をグループ分割制御部４１９に渡す。該グループ分割制御部４１９では、各要求クライアントから送信されたレート変更条件に基づいて当該要求クライアント４１ａが他の各要求クライアントと同一マルチキャストグループで共存困難な条件をもつと判断した場合、当該要求クライアント４１ａは別のマルチキャストグループでのデータ受信を行う。また、各要求クライアント４１ｂ…においても同様の処理がなされる。
【００９６】
ここで、各要求クライアント４１ａ…のうちあらかじめ設定された一つの要求クライアントが、上記別のマルチキャストグループにおいてもデータ受信を行う旨の通知を上記サーバ４００に行う。この通知を受けた上記サーバ４００の送出先グループ分割制御部４１８では、この通知に基づいて同一マルチキャストグループで共存困難な条件をもつ要求クライアントに対しては、別のマルチキャストグループでデータを転送するものとして、該別のマルチキャストグループでの送出レートをレート制御部４０５に通知する。該レート制御部４０５は同一マルチキャストグループで共存可能な条件をもつ要求クライアントに対しては通常の送出レートによって、上記別のマルチキャストグループに対しては上記通知された別の送出レートによって、送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００９７】
以上のように、共存可能な条件をもつ複数のクライアントを同一マルチキャストグループに属するようにし、それぞれのマルチキャストグループに対して別々のマルチキャストアドレスのもとでストリームデータを配信することによって、より多くのクライアントに対するデータ転送の信頼性を向上することが出来る。
【００９８】
以上、受信バッファに受け取られたストリームデータを再生する場合について説明のみしたが、このように受信バッファに受け取られたストリームデータは再生に供されるだけでなくハードディスク等の記憶手段に蓄積されることもあり得る。
【００９９】
尚、本願システムはハードウエア、ソフトウエアいずれでも実施することができる。ソフトウエアで実施する場合には、ハードディスク等の記憶手段Ｈ（例えば補助記憶装置５０３）にプログラムを組み込んで実施することになる。またここに組み込まれるプログラムは図１３に示すように、フロッピイディスクＭ１等の可搬媒体に書き込まれたプログラムをフロッピィディスクドライブＦＤを介してサーバ４００あるいはクライアント４７０の記憶手段Ｈに移植することができる。
【０１００】
【発明の効果】
以上の説明から明らかなように本発明によると、受信バッファ上でストリームデータのオーバフローがなくなるので、データの欠落が発生しないことになる。また、何らかの原因でたとえデータ欠落が発生しても欠落データを再送できるので該欠落が補完できることになる。
【０１０１】
また、複数のクライアントとサーバによって構成されるマルチキャスト方式であっても、本発明を適用できることになる。
【図面の簡単な説明】
【図１】本発明の一実施例のブロック図である。
【図２】本発明の動作手順を示すフロー図である。
【図３】本発明の動作手順を示すフロー図である。
【図４】ファイル上の位置番号を示す概念図である。
【図５】受信バッファのデータ配列を示す概念図である。
【図６】本発明に使用する各種のパケット構造を示す概念図である。
【図７】本発明の一実施例のブロック図である。
【図８】本発明に使用する各種のパケット構造を示す概念図である。
【図９】本発明の他の実施例のブロック図である。
【図１０】本発明の他の実施例のブロック図である。
【図１１】本発明の他の実施例のブロック図である。
【図１２】本発明の他の実施例のブロック図である。
【図１３】可搬媒体による本発明の実施形態を示す概念図である。
【図１４】従来例におけるストリームデータ転送方式のブロック図である。
【図１５】従来の方法によるトラブルの例を示す概念図である。
【符号の説明】
３００ ネットワーク
４００ サーバ
４０２ パケット送信部
４０３ 補助記憶装置
４０４ 送信バッファ
４０５ レート制御部
４０６ レート変更要求処理部
４０７ 再送制御部
４０８ 同一レート変更要求処理部
４０９ 同一再送要求処理部
４１ａ 特定のクライアント
４１０ パケット受信部
４１１ パケット送信部
４１２ 受信バッファ
４１３ レート変更要求部
４１４ 再送要求部
４１５ レート変更要求抑制部
４１６ 再送要求抑制部
４１８ 送出先グループ分割制御部
４１９ グループ分割制御部
４７０ クライアント
【発明の属する技術分野】
本発明は、多数のコンピュータが接続されたコンピュータネットワークにおけるデータ転送方法およびシステムに関し、特に、時間的に連続するデータであるストリームデータの転送方法およびシステムに関するものである。
【０００２】
【従来の技術】
近年、コンピュータの能力の向上、コンピュータのネットワーク接続の一般化によって、コンピュータネットワークを介してストリームデータのリアルタイムな転送が要求されている。ここでストリームデータとは、映像、音声などの時間的に連続なデータをいう。このストリームデータは当然パケットに編集されてネットワーク上で転送されるが、このとき、パケットの所定数の集合体単位で扱う場合、あるいはそのような集合体単位に関係なく扱われる場合を問わずここではストリームデータという。
【０００３】
図１４は従来のストリームデータ転送システムの一例を示すものである。このシステムはデータを提供する側のサーバ５００と、データの提供を受ける側のクライアント５０８とよりなり、その間にネットワーク５０７が介在することになる。以下、図１４に基づいて従来のシステムについて、その動作とともに更に説明する。
【０００４】
サーバ５００は、以下のように構成される。すなわち、以下に説明するように、クライアント５０８側からストリームデータの転送開始要求が出されると、該要求はパケット受信部５０１を介して開始要求処理部５１６に渡され、該開始要求処理部５１６がレート制御部５０５を起動することになる。該レート制御部５０５はハードディスク等の補助記憶装置５０３よりストリームデータを読み出して、一旦送信バッファ５０４に蓄積する。
【０００５】
上記レート制御部５０５には、クライアント５０８の再生レートとネットワークの転送可能容量に応じて予め所定の送出レートが設定されおり、送信バッファ５０４に蓄積されたストリームデータは該レート制御部５０５の制御に基づいて上記所定の送出レートで読み出されてパケット送信部５０２に転送され、該パケット送信部５０２では該ストリームデータをパケットに組み込んでネットワーク５０７に送出することになる。
【０００６】
一方、クライアント５０８は以下のようになっている。すなわち、ネットワーク５０７より受信したデータパケットはパケット受信部５０９に受け取られ、ここでパケットが解かれて受信バッファ５１１に順次蓄積される。データ再生部５１２は上記のように受信バッファ５１１に蓄積されたデータを順次所定の再生レートで読み出して表示装置に渡すようになっている。
【０００７】
転送の開始を制御するために、クライアント５０８側に転送開始要求部５１７が備えられ、オペレータの指示に従って、この転送開始要求部５１７が転送開始要求を出す。この転送開始要求はパケット送信部５１０に渡され、ここで転送開始要求パケットに編集され、ネットワーク５０７を介してサーバ５００に転送される。これによって、サーバ５００の開始要求処理部５１６が上記したようにレート制御部５０５を起動してデータ転送が開始されることになる。
【０００８】
以上の動作を繰り返しサーバとクライアント間でストリームデータの転送が行われることになるが、一般にコンピュータネットワークは該ネットワークの状態によってある程度のパケット落ちが発生し、また、クライアントのコンピュータでの処理能力の不足、ストリームデータの再生レートの揺らぎ等で受信バッファのあふれが発生した場合にはデータ欠落が発生する。
【０００９】
そこで、上記従来のシステムにおいても、データが欠落した場合の補償をすることがなされている。
すなわち、まず、クライアント５０８の欠落率報告部５１３が受信バッファ５１１を常時監視するようにしておき、データ欠落が発生したときにデータ欠落率の報告をパケット送信部に渡す。ここで、サーバ５００のアドレスと送出レート変更要求パケットである旨の識別子と上記欠落率が載せられたレート変更要求パケットを作成し、ネットワークに送出する。
【００１０】
このように送出されたレート変更要求パケットはサーバ５００のパケット受信部５０１に受け取られ、ここで、レート変更要求パケットである旨の判別がなされてレート変更部５０６に渡される。このレート変更部５０６には、例えば上記レート変更要求パケットに含まれる上記クライアント５０８での欠落率に応じた送出レートがテーブルとして備えられており、レート変更部５０６は該テーブルを参照して新たな送出レートを決定し、該送出レートをレート制御部５０５に転送する。これによって、レート制御部５０５は送出レートを下げて（あるいは上げて）送信バッファ５０４からストリームデータを読み出しパケット送信部５０２に渡すことになる。
【００１１】
【発明が解決しようとする課題】
しかしながら、このような従来のストリームデータ転送システムでは、上記のようにクライアント５０８がデータの欠落を検出してからはじめてサーバ５００からの送出レートを下げるという手順で処理されているため、一旦欠落したデータの再生はできなくなり、更に、欠落が生じた状態のデータを再生した場合には画像の揺らぎが発生するという欠点を有していた。
【００１２】
尚、ストリームデータ以外の例えばテキストデータをサーバ５００からクライアント５０８に転送する方法として、図１５に示すような方法がある。すなわち、所定サイズ単位のデータ“Data”がサーバ５００からクライアント５０８に転送される毎に確認信号“Ack ”がクライアント５０８からサーバ５００に返えされ、該確認信号“Ack ”を受けてサーバ５００が新たなデータ“Data”を送出するようになっている。
【００１３】
この方法でストリームデータを転送すると、クライアント５０８はデータ抜けのデータを受け取ると確認信号“Ack ”を返さないことになり、サーバは次のデータ“Data”を送出できなくなる。この状態になると、例えば所定時間Ｔ0 が経過するまで次のデータは転送されないので、受信バッファ５１１にデータ欠乏が発生することになり、画像が止まったり、乱れたりする。
【００１４】
本発明は、上記従来のストリームデータ転送システムの欠点に鑑みて提案されたものであって、クライアントのバッファにデータ欠落を発生するする前にサーバからの送出レートを下げ、また、たとえクライアントのバッファにデータが欠落した場合であっても、該欠落データを再送することによって、より信頼性のあるストリームデータ転送方法及びシステムを提供することを目的とする。
【００１５】
更に、本発明は、サーバより複数のクライアントに同時に同一データを転送するマルチキャスト転送方式であっても、上記の目的を有効に達成することができるストリームデータ転送方法及びシステムを提供することを目的とするものである。
【００１６】
【課題を解決するための手段】
上記目的を達成するために本発明は以下の手段を採用している。先ず、本発明が適用されるストリームデータ転送システムは、以下のサーバ４００と、クライアント４７０を備えた構成となっている。上記サーバ４００は、記憶手段（図１上では補助記憶装置４０３と送信バッファ４０４）よりレート制御部４０５の制御に基づいて所定の送出レートで読み出したストリームデータをパケット送信部４０２でパケットに編集してネットワーク３００を介してクライアント４７０に転送するとともに、クライアント４７０よりの要求をパケット受信部４０１で受けて必要な処理をする。
【００１７】
また、上記クライアント４７０は、上記サーバ４００よりネットワーク３００を介して所定の送出レートで送出されるストリームデータをパケット受信部４１０で受信して受信バッファ４１２に一旦蓄積して再生するとともに、上記サーバ４００に対する必要な指示をパケット送信部４１１より送出する。
【００１８】
上記システムにおいて、本発明は上記受信バッファ４１２の空き状態に対応してクライアント４７０側よりレート変更要求を出し、該レート変更要求に基づいてサーバ４００側の送出レートを変更するようにする。
【００１９】
具体的には、クライアント４７０側にレート変更要求部４１３を備えて、受信バッファ４１２の空き容量を監視し、該空き容量に応じたレート変更要求を出すようにする。一方、サーバ４００側にレート変更要求処理部４１６を備えるようにして、上記のようにクライアント４７０側より出されるレート変更要求に基づいて、上記レート制御部４０５に設定された送出レートを更新する構成とする。
【００２０】
これによって、受信バッファ４１２よりのストリームデータのオーバーフローはなくなることになる。
また、上記パケット受信部４１０で受信されたストリームデータの欠落に対応してクライアント４７０側より出される再送要求に基づいて、サーバ４００側の記憶手段より該欠落データに対応するデータを送出するようにもする。
【００２１】
具体的には、クライアント４７０側に再送要求部４１４を備え、上記パケット受信部４１０が受信するデータ欠落を監視するとともに、該欠落データに対応するデータをサーバ４００に再送要求を出すようにする。一方、サーバ４００側に再送制御部４０７を備えて上記再送要求に基づいて、欠落データに対応するストリームデータの再送処理を行うようにする。
【００２２】
これによって、たとえデータ欠落が発生しても該欠落を補完できることになる。
本発明は、上記レート変更処理に必要な構成のみを単独で使用することもでき、また再送処理に係る構成も単独で使用することも可能であり、更に、上記２つの処理を併用する構成とすることも可能である。
【００２３】
ところで、同一のデータを同時に複数のクライアントに転送することができるマルチキャスト転送方式に上記の方法をそのまま適用すると、サーバは、該マルチキャストを構成する各クライアントからの複数の要求に対応しなければならいことになる。このことはサーバやネットワークの負荷を増大させることになるので、マルチキャスト転送方式に上記の方法をそのまま利用することはできない。
【００２４】
そこで、本発明は上記同一マルチキャストグループに属する特定のクライアント４１ａの受信バッファの空き状態に対応して該特定のクライアント４１ａよりレート変更要求を上記サーバ４００に出すとともに、該レート変更要求に基づいて上記サーバ４００の送出レートを変更するようにする。
【００２５】
具体的には、上記同一マルチキャストグループに属する特定のクライアント４１ａにレート変更要求部４１３を備え、上記受信バッファ４１２の空き容量を監視するとともに、該空き容量に対応したレート変更要求を上記サーバに出するようにする。一方、上記サーバ４００にレート変更要求処理部４０６を備えるようにして、クライアント４１ａ側より出される上記レート変更要求に対応して、上記レート制御部４０５に設定された送出レートを更新する構成とする。
【００２６】
これによって、サーバ４００とネットワーク３００の負荷上昇を抑えつつ、クライアントの受信バッファにおけるマルチキャストストリームデータのオーバフローをなくすことになる。
【００２７】
また、上記同一マルチキャストグループに属する特定のクライアント４１ａのパケット受信部４１０で受信されたデータの欠落に対応して該特定のクライアント４１ａより再送要求を上記サーバ４００に出すとともに、該再送要求に基づいて上記サーバ４００の記憶手段より該欠落データに対応するデータを送出するようにもできる。
【００２８】
具体的には、上記同一マルチキャストグループに属する特定のクライアント４１ａに再送要求部４１４を備え、また、上記サーバ４００に再送制御部４０７を備えた構成とする。この構成において、上記再送要求部４１４で、上記パケット受信部４１０が受信するデータ欠落を監視して、該欠落データに対応するデータを上記サーバ４００に再送要求を出すようにするとともに、上記再送制御部４０７で上記再送要求に基づいて、上記欠落データに対応するストリームデータの再送処理を行うようにしたものである。
【００２９】
これによって、たとえデータ欠落が発生しても、サーバとネットワークの負荷上昇を抑えつつ、該欠落を補完出来ることになる。
また、上記特定のクライアント４１ａより上記レート変更要求を上記サーバ４００および上記同一マルチキャストグループに属する全てのクライアントに発行するようにしておく。この状態で、他の特定のクライアントよりの上記特定のクライアントの発行したレート変更要求と同一のレート変更要求の発行（他の特定のクライアントが発行）をあらかじめ設定した所定時間だけ禁止する。あるいは上記サーバが複数のクライアントより同一の上記レート変更要求をあらかじめ設定した所定時間内に受信した場合、これらレート変更要求のうち一つを有効として、該レート変更要求に基づいてサーバの送出レートを変更するようにすることができる。
【００３０】
具体的には、図９に示すように上記特定のクライアント４１ａに、他の特定のクライアントから出されたレート変更要求と同一のレート変更要求の発行をあらかじめ設定した所定時間だけ禁止するレート変更要求抑制部４１５を備える。あるいは図１０に示すように上記サーバ４００に、該サーバが複数のクライアントより同一の上記レート変更要求をあらかじめ設定した所定時間内に受信した場合、これらレート変更要求のうち一つを有効とする同一レート変更要求処理部４０８を備える構成とする。
【００３１】
また、上記特定のクライアント４１ａより上記再送要求を上記サーバ４００および上記同一マルチキャストグループに属する全てのクライアントに発行するとともに、他の特定のクライアントより上記再送要求と同一の再送要求の発行をあらかじめ設定した所定時間だけ禁止するようにすることができる。あるいは上記サーバ４００が複数のクライアントより同一の上記再送要求をあらかじめ設定した所定時間内に受信した場合、これら再送要求のうち一つを有効として、該再送要求に基づいて上記サーバ４００の記憶手段より該欠落データに対応するデータを送出するようにすることができる。
【００３２】
具体的には、図９に示すように上記特定のクライアント４１ａに、他の特定のクライアントから出された再送要求と同一の再送要求の発行をあらかじめ設定した所定時間だけ禁止する再送要求抑制部４１６を備える。あるいは図１０に示すように上記サーバ４００に、該サーバ４００が複数のクライアントより同一の上記再送要求をあらかじめ設定した所定時間内に受信した場合、これら再送要求のうち一つを有効とする同一再送要求処理部４０９を備える構成とする。
【００３３】
上記の手順によって、上記サーバ４００およびネットワーク３００の負荷を抑えることができることになる。
また、ストリームデータ送信前に上記サーバ４００が、上記レート変更要求の送出可能な同一マルチキャストグループに属するクライアント全てより、該クライアントがレート変更要求を出す条件を得て、同一マルチキャストグループで共存困難な条件をもつクライアントに対しては、別のマルチキャストグループでデータを転送することも可能である。あるいはストリームデータ送信前に上記特定のクライアントが、上記レート変更要求の送出可能な同一マルチキャストグループに属する他のクライアント全てより、該他のクライアントがレート変更要求を出す条件を得て、当該他のクライアントが同一マルチキャストグループで共存困難な条件をもつ場合、別のマルチキャストグループとしてデータを受信することも可能である。
【００３４】
具体的には、図１１に示すように上記サーバ４００に送出先グループ分割制御部４１８を備えておき、同一マルチキャストグループで共存困難な条件をもつ上記クライアントに対しては、別のマルチキャストグループでデータを転送するよう制御する。また図１２に示すように上記特定のクライアントにグループ分割制御部４１９を備えておき、特定のクライアントが同一マルチキャストグループで共存困難な条件をもつ場合、別のマルチキャストグループでのデータの受信を行う。
【００３５】
よって、共存可能な条件をもつクライアントを同一のマルチキャストグループに属するようにし、それぞれのマルチキャストグループに対して別々のマルチキャストアドレスのもとでストリームデータを配信する。従って、より多くのクライアントに対するデータ転送の信頼性を向上することが出来る。
【００３６】
本発明は、上記レート変更処理に必要な構成のみを単独で使用することもでき、また再送処理に係る構成のみを単独で使用することも可能であり、更に、上記２つの処理を併用する構成とすることも可能である。
【００３７】
【実施の形態】
（実施の形態１）
図１は本発明のストリームデータ転送システムの１実施例を示すものであり、以下図１に基づいて本発明のシステムの構成についてその動作とともに説明する。
【００３８】
本システムはサーバ４００とクライアント４７０がネットワーク３００で結ばれている点は上記従来のシステムと全く同様である。
オペレータがキーボード、あるいはカーソル等の入力手段と画面を用いて特定のファイルの転送指示を出すと、クライアント４７０の転送開始要求部４８０が開始要求をパケット送信部４１１に通知し、これを受けて、パケット送信部４１１は図６(d) に示すように発信元アドレス▲１▼、送信先アドレス▲２▼、パケット種別識別子（転送開始要求）▲３▼、ファイルを特定する事項（ファイル名あるいはファイル番号）▲７▼、更に必要に応じて以下に説明する転送開始位置番号▲８▼を載せた転送要求パケットをネットワーク３００に送出する。
【００３９】
上記転送開始位置番号とは、後述するようにサーバ４００側のレート制御部４０５で生成され、パケット送信部４０２で送信されるデータパケットに付されるパケット番号とは別の当該データのファイル上の位置を示す番号であって、後述する再送処理に必要となる。すなわち、図４に示すように上記指定されたファイルＦを特定のバイト単位〔例えば１パケット相当のバイト数（例えば１Ｋｂ）〕で区切って形成したセクションに、順次割り振った番号（ｆのサフィックスを付して表している）の中の読み出し開始位置に相当する番号であって、ファイルの先頭から読み出すときは、該番号はもちろん０であるが、途中から読み出すときは該当位置に対応する番号を示すことになる。もっとも、オペレータは例えば先頭から読み出し開始位置に対応する迄の時間等オペレータの理解できる数値で当該転送開始位置を指定し、該数値を上記転送開始要求部４８０が上記のセクションの番号に変換することになる。もっとも、この位置番号は後述する再送処理をする場合には上記データパケットに載せる必要があるが、再送処理をしない場合には上記データパケットに載せる必要はないことになる。
【００４０】
このようにネットワーク３００に送出された転送要求パケットはサーバ４００のパケット受信部４０１に受け取られて、ここで上記パケット識別子▲３▼より転送要求パケットである旨の判断がなされ開始要求処理部４１７に転送される。これによって、開始要求処理部４１７では上記のように特定されたファイル名、ファイル番号等のファイルを特定する事項▲７▼、および転送開始位置番号▲８▼をレート制御部４０５に渡し、該レート制御部４０５を起動する。これによって、該レート制御部４０５は補助記憶装置４０３の上記転送開始位置番号▲８▼に対応するアドレスよりストリームデータを順次読み出して送信バッファ４０４に一旦蓄積する。
【００４１】
上記レート制御部４０５には、以下に説明するクライアント４７０の再生レートとネットワーク３００の伝送可能容量に依存して決定される送出レートが設定されており、上記のように送信バッファ４０４に蓄積されたストリームデータは該送信バッファ４０４から上記の送出レートで読み出されてパケット送信部４０２に転送される。パケット送信部４０２ではこのようにして得られたストリームデータを、データパケットに組み込んでネットワーク３００に送出する。このデータパケットには、図６(a) に示すように、発信元アドレス（サーバ４００のアドレス）▲１▼、受信先アドレス（クライアント４７０のアドレス）▲２▼、データパケットである旨のパケット識別子▲３▼、データサイズ▲４▼、パケットの順序を表すパケット番号▲５▼がヘッダ部に載せられ、実データがそれに続くようになっている。
【００４２】
尚、再送処理機能を持たせる場合には、上記パケット番号とは別にレート制御部４０５で形成されるファイル上の位置が特定出来る情報、例えば図４を用いて上記に説明したファイルを所定量のデータブロックで区切ったときのセクションの番号（位置番号）をパケットのヘッダに載せるようにする。ファイルを該ファイルの先頭から読み出すときであって、上記１セクションの容量単位が１パケットの容量単位と一致するときには上記パケット番号と当該位置番号は一致することになるが、両者の容量が異なるとき、あるいは上記のようにファイルの途中から読み出すときには一致しないことになる（図５参照）。
【００４３】
上記のようにネットワーク３００に送出されたデータパケットはクライアント４７０のパケット受信部４１０に受け取られ、ここでパケット種の識別子▲３▼よりデータパケットである旨の判別がなされるとともに、上記パケット番号とパケットサイズを参照して、受信バッファ４１２の所定のアドレスに書き込むようにする。
【００４４】
ここで、パケット受信部４１０は上記のようにサーバ４００側のパケット送信部４０２で付されたパケット番号▲５▼を管理しており、何らかの原因でパケット受信部４１０に順次到達するパケットのパケット番号が前後しても、当該パケット受信部４１０で順番が整理されるようになっている。
【００４５】
また、パケットの欠落なく転送されてきたストリームデータは、各パケット番号に対応して図５(a) に示すように受信バッファ４１２に隙間無く書き込まれるようになる。ところが、パケットに欠落があった場合には図５(b) に示すように、該欠落パケットのデータサイズだけ受信バッファ４１２上に空白をあけてストリームデータが書き込まれるようになる。尚、図５においてｐのサフィックスが付された番号はパケット番号であり、ｆのサフィックスが付された番号はファイル上の位置番号であり、後に説明するように、再送処理をする場合はクライアント４７０のパケット受信部４１０は、上記のようにパケット番号を管理するとともに、上記ファイル上の位置番号をも管理する機能をも持つようにする。
【００４６】
尚、図５においてパケット番号は０から順次インクリメントしているが、ファイル上の位置番号は途中から（３００番目から）始まっているいる例を示している。すなわち、ファイルを先頭からではなく、途中から読み出す場合に相当する。
【００４７】
このように受信バッファ４１２に書き込まれたデータはデータ再生部４９０により所定の再生レートで読み出されて再生されるようになっている。再生レートは画像種によっては時間的に変動することがあるが、上記送出レートと再生レートは均衡を保つように設定される必要があることはもちろんである。また、このとき受信バッファ４１２にデータがない状態でデータ再生部４９０が受信バッファ４１２をアクセスする状態を回避する必要があるところから、該受信バッファ４１２に一定量のデータが蓄積された状態から再生開始がなされるようにする。
【００４８】
以上の動作を繰り返すことによって、サーバとクライアント間でストリームデータの転送が行われることになるが、上記の処理はファイル上の位置を特定する情報（位置番号）に関する記述を除いて従来のシステムにおける手順と全く同じである。
【００４９】
上記において、サーバ４００側のパケット送信部４０２の送出レートとクライアント４７０側のデータ再生部４９０の再生レートが平衡している場合には、受信バッファ４１２の空きは一定に保たれることになる。ところが、クライアント４７０のコンピュータの処理能力の不足、ストリームデータの再生レートの揺らぎ等に起因して受信バッファ４１２の空き容量が減少する場合があり、この状態が継続すると、受信バッファ４１２がオーバフローになることになりデータ欠落が発生する。そこで、以下のようにサーバ４００側の送出レートを変更する処理を行う。
【００５０】
すなわち、クライアント４７０のレート変更要求部４１３は受信バッファ４１２の空き容量を常に監視しておき、受信バッファ４１２の空き容量が所定の設定値（例えば空き容量が２０％）より減ったことを検出したとき、送出レートを下げることを要求するレート変更要求を要求レートとともにパケット送信部４１１に通知する。このレート変更要求通知を受けたパケット送信部４１１は図６(b) に示すように、発信元アドレス（クライアント４７０のアドレス）▲１▼、送信先アドレス（サーバのアドレス）▲２▼、レート変更要求である旨のパケット識別子▲３▼、要求レート▲６▼を組み込んだレート変更要求パケットをネットワーク３００に送出する（図２、ステップＳ２１→Ｓ２２→Ｓ２５参照）。
【００５１】
サーバ４００のパケット受信部４０１はネットワーク３００から上記レート変更要求パケットを受け取り、その識別子からレート変更要求パケットである旨の判断をして、その内容をレート変更要求処理部４０６に渡す。これによってレート変更要求処理部４０６は新しい送出レートをレート制御部４０５に渡して送出レートを下げる要求を行い、レート制御部４０５は送出レートを下げて送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００５２】
このように、データパケットの送出レートを下げると、受信バッファ４１２の空き容量は次第に増えることになるが、この状況も、上記レート変更要求部４１３に監視されており、該空き容量が所定値（例えば８０％）以上に増加すると上記レート変更要求部４１３は送出レートを上げるレート変更要求をパケット送信部４１１に通知し、該通知を受けてパケット送信部４１１は上記と同様の処理を行いレート変更要求パケットを作成しネットワーク３００へ送信する（図２、ステップＳ２３→Ｓ２４→Ｓ２５参照）。
【００５３】
サーバ４００のパケット受信部４０１がネットワーク３００からパケットを受け取り、上記の送出レートを低くする場合のレート変更と同様、レート変更要求処理部４０６が要求された送出レートをレート制御部４０５に渡すことによって、該レート制御部４０５は増加された送出レートでの送出を行うことになる。
【００５４】
このように動作することによって、クライアント４７０の受信バッファ４１２がオーバフローする前にストリームデータの転送レートが下げられるためにデータの欠落が発生しなくなるとともに、クライアント４７０の受信バッファ４１２に蓄積されたストリームデータが欠乏する前にストリームデータの送出レートが上げられるため、ストリームデータが欠落なく受信バッファ４１２に蓄積されることになる。
【００５５】
尚、上記の例ではクライアント４７０側で送出レートを決定するようになっているが、クライアント４７０からはレート変更要求と受信バッファ４１２の空き容量（例えば％で表した空き容量）のみを出力し、実際の送出レートはサーバ４００側のレート変更要求処理部４０６で上記空き容量に対応する送出レートを決定してレート制御部４０５に設定するようにしてもよい。
【００５６】
また、上記の説明では受信バッファ４１２の空き容量が所定値以下になったときに送出レートを下げ、所定値以上になったときに送出レートを上げるようにしているが、別の方法として、受信バッファ４１２の空き容量が所定値以下（例えば２０％以下）になったときに送出レートを０にして、サーバ４００よりの送出をストップするようにし、所定値以上（例えば８０％以上）になったときに送出レートを所定の値に戻すようにしてもよい。
【００５７】
以上のように送出レートを調整しても、何らかの原因、例えばネットワーク３００の状況によってはデータパケットの欠落が発生することがあり、また、ノイズ等の外的な要因によってもデータパケットの欠落が発生することがある。
【００５８】
そこで、クライアント４７０の受信バッファ４１２に蓄積されるストリームデータに図５(b) に示すような欠落ができるか否かを、再送要求部４１４が検出するようになっている。現実には再送要求部４１４はパケット受信部４１０を常時監視しており、上記ファイル上の位置番号（図５上ｆのサフィックスが付されている）に欠落があったとき、その前後の位置番号より欠落パケットに対応する位置番号を算出する。このように算出された位置番号は、データの再送を要求する再送要求とともにパケット送信部４１１に通知される。
【００５９】
パケット送信部４１１では、上記再送要求を受けて発信元アドレス（クライアントのアドレス）▲１▼、送信先アドレス（サーバのアドレス）▲２▼、パケット種別識別子（再送要求）▲３▼、再送要求に係る位置番号▲９▼、および再送されるデータのサイズ▲４▼を載せた図６(c) に示す再送要求パケットをネットワーク３００に送出する（図３、ステップＳ３１→Ｓ３２→Ｓ３３参照）。
【００６０】
このようにネットワーク３００に送出された再送要求パケットは、サーバ４００のパケット受信部４０１に受け取られ、ここで、再送要求パケットである旨の判断がなされ、該パケットの内容が再送制御部４０７に通知される。これによって、再送制御部４０７は再送要求に含まれる位置番号に従って送信バッファ４０４から所定のサイズのストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００６１】
パケット送信部４０２は通常のデータ転送と同様、受け取ったデータを、図６(a) に示すデータパケットに組み込んでネットワーク３００へ送出する。
上記したように、パケット受信部４１０は受信バッファ４１２に蓄積されているデータに対応するパケット番号と上記ファイル上の位置番号を管理している。この状態で、パケット受信部４１０にデータパケットが受け取られると、当該パケットに付された上記ファイル上の位置番号より、格納すべき受信バッファ４１２上のアドレスを演算して、データが欠落したアドレスに挿入するようになっている。
【００６２】
このように動作することによって、ネットワークでのパケット落ちが発生した場合でも高速に再送を行うことができるためデータの欠落が発生しないことになる。
【００６３】
尚、上記の説明においては、ファイル上の位置が特定出来る情報として上記位置番号を用い、該位置番号をパケットのヘッダに載せる構成で説明を行っているが、これに代えてファイル上の位置が特定出来る情報としてストリームデータ内での時間を用い、該時間をパケットのヘッダに載せる構成とすることも可能である。
【００６４】
更に、上記のようなファイル上の位置が特定出来る情報をパケットのヘッダに載せる構成に代えて、上記再送制御部４０７において、転送対象のデータに対応するパケット番号と、該データのファイル上の位置が特定出来る情報とを管理することとし、上記クライアント４７０の再送要求部４１４が上記パケット番号を含む再送要求を行う構成とすることも可能である。
【００６５】
以上のように本実施例のデータ転送方法によれば、クライアントの処理能力の不足、ストリームデータの再生レートの揺らぎ等が発生してもデータの欠落が発生せず、さらにネットワークでのパケット落ちが発生した場合でもデータの欠落が発生せずにストリームデータを転送することができる。
【００６６】
（実施の形態２）
ところで、複数クライアントへ同一データを同時に転送する場合、マルチキャスト転送方式が使用されることがある。すなわち、一つのグループをあらかじめ定義し、転送対象となるクライアントをそのグループに登録しておくと、サーバは上記グループ宛にデータを送ることにより、登録されたクライアントすべてにデータを転送することが可能である。これによって、転送対象となるクライアントごとにサーバから個別にデータを転送する必要がなく、効率的に同一データを複数クライアントに転送出来ることになる。
【００６７】
ところが、上記の実施の形態をそのままマルチキャスト方式に適用すると、例えば特定のマルチキャストを構成する全てのクライアントがサーバに上記レート変更要求パケットや上記再送要求パケットを送る場合が発生する。このような場合、サーバやネットワークの負荷が過度に高くなり、別の障害例えばクライアント側のバッファにデータがなくなり、表示が途切れるといった現象の発生につながる可能性がある。
【００６８】
そこで本実施の形態は、マルチキャスト方式のシステムであっても、上記の実施の形態が有効に作動する構成を提案するものである。
図７は本発明のマルチキャストストリームデータ転送システムの一実施例を示すブロック図であり、以下図７に基づいて本発明のシステムの構成についてその動作とともに説明する。
【００６９】
図７において、マルチキャストグループはデータを提供する側のサーバ４００と、データの提供を受ける側でレート変更要求および再送要求機能の少なくとも一方を備えたクライアント（以下、要求クライアントという）４１ａと、同じくデータの提供を受ける側でレート変更要求および再送要求機能を備えないクライアント（以下、通常クライアントという）４２ａ、４２ｂ…とより構成され、上記サーバ４００と要求クライアント４１ａ、通常クライアント４２ａ、４２ｂ…の間にネットワーク３００が介在することになる。ただし、必要に応じて上記要求クライアントを複数とすることも可能である。
【００７０】
すなわち、上記要求クライアント４１ａには、図１に示したクライアント４７０と同様、レート変更要求部４１３および再送要求部４１４のいずれか少なくとも一方が備えられるが、通常クライアント４２ａ、４２ｂ…にはこれらは備えられない。
【００７１】
上記構成において、上記サーバ４００におけるオペレータ等によるデータ転送開始指示または要求クライアント４１ａからの転送開始要求等により、開始要求処理部４１７ではファイル名、ファイル番号等のファイルを特定する事項をレート制御部４０５に渡し、該レート制御部４０５を起動する。これによって、該レート制御部４０５は補助記憶装置４０３の特定されたファイルよりストリームデータを順次読み出して送信バッファ４０４に一旦蓄積する。
【００７２】
この後、要求クライアント４１ａとサーバ間でのデータ伝送が実行されるが、この手順は上記図１の説明において記述した内容と全く同じであるのでここでは説明を省略する。但し、この実施の形態はマルチキャスト方式に適用されているので、サーバからのストリームデータは要求クライアント４１ａだけでなく、上記通常クライアント４２ａ、４２ｂ…にも同時に転送されることになる。
【００７３】
要求クライアント４１ａの受信バッファ４１２の空き容量が所定値以下（所定値以上）になったときにレート変更要求を出す手順も、図２で説明した手順と同じであるので、ここでは説明を省略する。また、要求クライアント４１ａで受信したストリームデータに欠落が発生した場合に、再送要求をだす手順も上記図３で説明した手順と同じであるのでここでは説明を省略する。この実施の形態では、要求クライアント４１ａにのみレート変更要求部４１３、再送要求部４１４が備えられた構成となっているので、上記レート変更要求をだす権限、および、再送要求をだす権限は要求クライアント４１ａにのみに付与されていることになる。但し、上記レート変更要求が要求クライアント４１ａからだされると、マルチキャストを構成する全クライアントに対するデータ転送レートが変更されることになる。また、上記再送要求によって特定のデータパケットが再送されると、該パケットはマルチキャストを構成する全クライアントに受け取られることになる。
【００７４】
また、ここで使用されるデータパケット（図８(a) ）、レート変更要求パケット（図８(b) ）、再送要求パケット（図８(c) ）は図６に示す各パケットの内容と略同じであるが、送信先アドレスとして、マルチキャストアドレス（１つのマルチキャストを構成する複数のクライアントに共通のアドレス）が使用されることになる。
【００７５】
次に、図９は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図９に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００７６】
要求クライアント４１ｂのレート変更要求部４３３よりレート変更要求が出された場合、該レート変更要求通知を受けたパケット送信部４３１は、レート変更要求パケットをサーバ４００および同一マルチキャストグループでデータを受信している全てのクライアントに対して、図８(b) に示すように、発信元アドレス（要求クライアント４１ｂのアドレス）▲１▼、マルチキャストアドレス▲２▼、レート変更要求である旨のパケット識別子▲３▼、要求レート▲６▼を組み込んだレート変更要求パケットをネットワーク３００に送出する。
【００７７】
要求クライアント４１ａのパケット受信部４１１はネットワーク３００から上記レート変更要求パケットを受け取り、その識別子からレート変更要求パケットである旨の判断をして、該パケットの内容をレート変更要求抑制部４１５に通知する。これによって、該レート変更要求抑制部４１５では、上記レート変更要求と同一内容のレート変更要求を上記レート変更要求部４１３より発行しないようにあらかじめ設定した所定時間だけ禁止をかける。
【００７８】
尚、上記サーバ４００により受信された要求クライアント４１ｂからの上記レート変更要求パケットに基づく処理は上記実施例と同様である。また、要求クライアント４１ａのレート変更要求部４１３よりレート変更要求が出された場合も上記と同様である。また、上記レート変更要求パケットは通常クライアント４２９にも届くことになるが、該通常クライアント４２９はレート変更要求機能がないため、無視することとなる。
【００７９】
次に、要求クライアント４１ｂの再送要求部４３４より再送要求が出された場合、該再送要求通知を受けたパケット送信部４３１は、再送要求パケットをサーバ４００および同一マルチキャストグループでデータを受信している全てのクライアントに対して、図８(c) に示すように、発信元アドレス（要求クライアントのアドレス）▲１▼、マルチキャストアドレス▲２▼、パケット種別識別子（再送要求）▲３▼、再送要求に係る位置番号▲９▼、および再送されるデータのサイズ▲４▼を載せた再送要求パケットをネットワーク３００に送出する。
【００８０】
要求クライアント４１ａのパケット受信部４１０はネットワーク３００から上記再送要求パケットを受け取り、その識別子から再送要求パケットである旨の判断をして、その内容を再送要求制御部４１６に通知する。該再送要求制御部４１６では、上記再送要求の内容と同一の再送要求を上記再送要求部４３４より発行しないようにあらかじめ設定した所定時間だけ禁止をかける。
【００８１】
尚、上記サーバ４００に受信された要求クライアント４１ｂからの上記再送要求パケットに基づく処理は上記実施例と同様である。また、要求クライアント４１ａのレート変更要求部４１３よりレート変更要求が出された場合も上記と同様である。また、上記レート変更要求の場合と同様に、再送要求パケットは通常クライアント４２ａにも届くことになるが、該通常クライアント４２ａは再送要求機能がないため、無視することとなる。
【００８２】
以上のように、他の要求クライアントが既に送信したレート変更要求と同一内容のレート変更要求を発行しないこと、また他の要求クライアントが既に送信した再送要求と同一内容の再送要求レート変更要求を発行しないことにより、上記サーバ４００およびネットワーク３００の負荷を抑えることができる。
【００８３】
図１０は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図１０に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００８４】
要求クライアント４１ａ、４１ｂ…がレート変更要求パケットを送信した場合、サーバ４００のパケット受信部４０１はネットワーク３００から上記レート変更要求パケットを受け取り、その識別子からレート変更要求パケットである旨の判断をして、その内容を同一レート変更要求処理部４０８に通知する。該同一レート変更要求処理部４０８では、あらかじめ設定された所定時間内に通知を受けたレート変更要求のうち最初に受信したレート変更要求を有効にし、その内容をレート変更要求処理部４０６に渡す。
【００８５】
例えば、上記要求クライアント４１ａおよび要求クライアント４１ｂから、同一のレート変更要求を上記所定時間内に受けた場合（ここでは、上記要求クライアント４１ａからのレート変更要求が先であるとする）、上記要求クライアント４１ａからのレート変更要求を有効にし、その内容をレート変更要求処理部４０６に渡し、上記要求クライアント４１ｂからのレート変更要求は無効として扱う。これによってレート変更要求処理部４０６は上記要求クライアント４１ａからのレート変更要求に基づいて新しい送出レートをレート制御部４０５に渡して、レート制御部４０５は新しい送出レートにより送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００８６】
次に、上記要求クライアント４１ａ、４１ｂ…が再送要求パケットを送信した場合、サーバ４００のパケット受信部４０１はネットワーク３００から上記再送要求パケットを受け取り、その識別子から再送要求パケットである旨の判断をして、その内容を同一再送要求処理部４０９に通知する。該同一再送要求処理部４０９では、あらかじめ設定された所定時間内に通知を受けた再送要求のうち最初に受信した再送要求を有効にし、その内容を再送制御部４０７に渡す。
【００８７】
例えば、上記要求クライアント４１ａおよび要求クライアント４１ｂから、同一の再送要求を上記所定時間内に受けた場合（ここでは、上記要求クライアント４１ａからの再送要求が先であるとする）、上記要求クライアント４１ａからの再送要求を有効にし、その内容を再送要求処理部４０７に渡し、上記要求クライアント４１ｂからの再送要求は無効として扱う。これによって再送制御部４０７は上記要求クライアント４１ａからの再送要求に含まれる位置番号に従って送信バッファ４０４から所定のサイズのストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００８８】
以上のように、同一内容のレート変更要求を一つのレート変更要求として扱うこと、また同一内容の再送要求を一つの再送要求として扱うことにより、上記サーバ４００およびネットワーク３００の負荷を抑えることができる。
【００８９】
ところで、同一のマルチキャストグループに登録されたクライアントであっても、個々のクライアントの性能、例えばバッファ容量、バッファ処理速度等の違いにより同一のマルチキャストグループに共存困難なクライアントも存在することになる。このような場合であっても、上記実施例が有効に作動する構成を以下に説明する。
【００９０】
図１１は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図１１に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００９１】
上記サーバ４００におけるオペレータ等によるレート変更条件転送指示または要求クライアント４１ａ、４１ｂ…からの自発的な送信によって、要求クライアント４１ａ、４１ｂ…がレート変更要求を出す条件を通知するための条件通知パケットを送信する。ここで、該条件通知パケットで通知する上記レート変更要求を出す条件は、例えばバッファ容量、バッファ処理速度等である。次に、サーバ４００のパケット受信部４０１はネットワーク３００から上記条件通知パケットを受け取り、その識別子から条件通知パケットである旨の判断をして、その内容を送出先グループ分割制御部４１８に渡す。
【００９２】
該送出先グループ分割制御部４１８では、各要求クライアントから送信されたレート変更条件に基づいて各要求クライアントが現在属しているマルチキャストグループで共存可能か否かを判断する。一マルチキャストグループで共存困難な条件をもつ要求クライアントに対しては、別のマルチキャストグループでデータを転送するものとして、該別のマルチキャストグループでの送出レートをレート制御部４０５に通知する。
【００９３】
該レート制御部４０５は、同一マルチキャストグループで共存可能な条件をもつ要求クライアントに対しては、該マルチキャストグループの条件に適合する特定の送出レートによって、また上記別のマルチキャストグループに対しては、上記通知された別の送出レートによって、送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００９４】
図１２は本発明のマルチキャストストリームデータ転送システムの他の実施例を示すブロック図であり、以下図１２に基づいてこのシステムの構成についてその動作とともに説明する。尚、上記実施例と同様の構成、動作については説明を省略する。
【００９５】
ストリームデータ送信前において、各要求クライアント４１ｂ…がレート変更要求を出す条件を通知するための条件通知パケットを送信する。ここで、該条件通知パケットで通知する上記レート変更要求を出す条件は、上記実施例と同様に例えばバッファ容量、バッファ処理速度等である。次に、要求クライアント４１ａのパケット受信部４１０はネットワーク３００から上記条件通知パケットを受け取り、その識別子から条件通知パケットである旨の判断をして、その内容をグループ分割制御部４１９に渡す。該グループ分割制御部４１９では、各要求クライアントから送信されたレート変更条件に基づいて当該要求クライアント４１ａが他の各要求クライアントと同一マルチキャストグループで共存困難な条件をもつと判断した場合、当該要求クライアント４１ａは別のマルチキャストグループでのデータ受信を行う。また、各要求クライアント４１ｂ…においても同様の処理がなされる。
【００９６】
ここで、各要求クライアント４１ａ…のうちあらかじめ設定された一つの要求クライアントが、上記別のマルチキャストグループにおいてもデータ受信を行う旨の通知を上記サーバ４００に行う。この通知を受けた上記サーバ４００の送出先グループ分割制御部４１８では、この通知に基づいて同一マルチキャストグループで共存困難な条件をもつ要求クライアントに対しては、別のマルチキャストグループでデータを転送するものとして、該別のマルチキャストグループでの送出レートをレート制御部４０５に通知する。該レート制御部４０５は同一マルチキャストグループで共存可能な条件をもつ要求クライアントに対しては通常の送出レートによって、上記別のマルチキャストグループに対しては上記通知された別の送出レートによって、送信バッファ４０４からストリームデータを読み出しパケット送信部４０２に渡すことになる。
【００９７】
以上のように、共存可能な条件をもつ複数のクライアントを同一マルチキャストグループに属するようにし、それぞれのマルチキャストグループに対して別々のマルチキャストアドレスのもとでストリームデータを配信することによって、より多くのクライアントに対するデータ転送の信頼性を向上することが出来る。
【００９８】
以上、受信バッファに受け取られたストリームデータを再生する場合について説明のみしたが、このように受信バッファに受け取られたストリームデータは再生に供されるだけでなくハードディスク等の記憶手段に蓄積されることもあり得る。
【００９９】
尚、本願システムはハードウエア、ソフトウエアいずれでも実施することができる。ソフトウエアで実施する場合には、ハードディスク等の記憶手段Ｈ（例えば補助記憶装置５０３）にプログラムを組み込んで実施することになる。またここに組み込まれるプログラムは図１３に示すように、フロッピイディスクＭ１等の可搬媒体に書き込まれたプログラムをフロッピィディスクドライブＦＤを介してサーバ４００あるいはクライアント４７０の記憶手段Ｈに移植することができる。
【０１００】
【発明の効果】
以上の説明から明らかなように本発明によると、受信バッファ上でストリームデータのオーバフローがなくなるので、データの欠落が発生しないことになる。また、何らかの原因でたとえデータ欠落が発生しても欠落データを再送できるので該欠落が補完できることになる。
【０１０１】
また、複数のクライアントとサーバによって構成されるマルチキャスト方式であっても、本発明を適用できることになる。
【図面の簡単な説明】
【図１】本発明の一実施例のブロック図である。
【図２】本発明の動作手順を示すフロー図である。
【図３】本発明の動作手順を示すフロー図である。
【図４】ファイル上の位置番号を示す概念図である。
【図５】受信バッファのデータ配列を示す概念図である。
【図６】本発明に使用する各種のパケット構造を示す概念図である。
【図７】本発明の一実施例のブロック図である。
【図８】本発明に使用する各種のパケット構造を示す概念図である。
【図９】本発明の他の実施例のブロック図である。
【図１０】本発明の他の実施例のブロック図である。
【図１１】本発明の他の実施例のブロック図である。
【図１２】本発明の他の実施例のブロック図である。
【図１３】可搬媒体による本発明の実施形態を示す概念図である。
【図１４】従来例におけるストリームデータ転送方式のブロック図である。
【図１５】従来の方法によるトラブルの例を示す概念図である。
【符号の説明】
３００ ネットワーク
４００ サーバ
４０２ パケット送信部
４０３ 補助記憶装置
４０４ 送信バッファ
４０５ レート制御部
４０６ レート変更要求処理部
４０７ 再送制御部
４０８ 同一レート変更要求処理部
４０９ 同一再送要求処理部
４１ａ 特定のクライアント
４１０ パケット受信部
４１１ パケット送信部
４１２ 受信バッファ
４１３ レート変更要求部
４１４ 再送要求部
４１５ レート変更要求抑制部
４１６ 再送要求抑制部
４１８ 送出先グループ分割制御部
４１９ グループ分割制御部
４７０ クライアント
Claims (6)
- サーバ側で、記憶手段よりストリームデータを所定の送出レートでネットワークを介して、同一マルチキャストグループに属する単一もしくは複数のクライアントに転送するとともに、クライアント側で、上記サーバより送出されるストリームデータをパケット受信部で受信して受信バッファに一旦蓄積するマルチキャストストリームデータ転送方法において、
上記同一マルチキャストグループに属する特定のクライアントのパケット受信部で受信されたデータの欠落に対応して該特定のクライアントより再送要求を上記サーバおよび上記同一マルチキャストグループに属する全てのクライアントに発行するとともに、
上記同一マルチキャストグループに属する他のクライアントより該再送要求と同一内容の再送要求の発行をあらかじめ設定した所定時間だけ禁止して、
該再送要求に基づいて上記サーバの記憶手段より該欠落データに対応するデータを送出する、
ことを特徴とする、マルチキャストストリームデータ転送方法。 - 上記サーバが複数のクライアントより同一内容の上記再送要求をあらかじめ設定した所定時間内に受信した場合、これら再送要求のうち一つを有効として、該再送要求に基づいて上記サーバの記憶手段より該欠落データに対応するデータを送出する、請求項１に記載のマルチキャストストリームデータ転送方法。
- サーバの記憶手段よりストリームデータを所定の送出レートでネットワークを介して受信する、同一マルチキャストグループに属する単一もしくは複数のクライアント装置において、
上記ストリームデータを受信して受信バッファに一旦蓄積するパケット受信部と、
上記パケット受信部で受信されたデータの欠落を監視し、該欠落データに対応するデータの再送要求を、上記サーバおよび上記同一マルチキャストグループに属する全てのクライアントに発行するパケット送信部と、
上記同一マルチキャストグループに属する他のクライアントからの再送要求を受信する上記パケット受信部と、
上記パケット受信部が再送要求を上記他のクライアントから受信した場合に、あらかじめ設定した所定時間内に該再送要求と同一内容の再送要求を発行することを禁止する再送要求制御部と、
を備えたことを特徴とする、クライアント装置。 - サーバ側で、記憶手段よりストリームデータを所定の送出レートでネットワークを介して、同一マルチキャストグループに属する単一もしくは複数のクライアントに転送するとともに、クライアント側で、上記サーバより送出されるストリームデータをパケット受信部で受信して受信バッファに一旦蓄積するマルチキャストストリームデータ転送システムにおいて、
上記サーバに：
上記クライアントのパケット受信部が受信したデータのデータ欠落の状態に基づいてクライアント側が出した再送要求に基づいて、欠落データに対応するデータの再送処理を行う再送制御部と、
上記同一マルチキャストグループに属する特定のクライアントに：
上記パケット受信部で受信されたデータの欠落を監視し、該欠落データの再送要求を上記サーバおよび上記同一マルチキャストグループに属する全てのクライアントに発行するパケット送信部と、
上記パケット受信部が再送要求を他のクライアントから受信した場合に、あらかじめ設定した所定時間内に該再送要求と同一内容の再送要求を発行することを禁止する再送要求制御部と、
を備えたことを特徴とする、マルチキャストストリームデータ転送システム。 - 上記サーバに、同一内容の再送要求を上記複数のクライアントからあらかじめ設定した所定時間内に受信した場合に、これら再送要求のうち一つを有効とする同一再送要求処理部を備える、請求項４に記載のマルチキャストストリームデータ転送システム。
- 上記請求項１に記載の各手順をプログラムとして記憶させた記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06991998A JP4203140B2 (ja) | 1997-03-25 | 1998-03-19 | ストリームデータ転送方法およびシステム |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP7111197 | 1997-03-25 | ||
| JP9-283858 | 1997-10-16 | ||
| JP9-71111 | 1997-10-16 | ||
| JP28385897 | 1997-10-16 | ||
| JP06991998A JP4203140B2 (ja) | 1997-03-25 | 1998-03-19 | ストリームデータ転送方法およびシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11184780A JPH11184780A (ja) | 1999-07-09 |
| JP4203140B2 true JP4203140B2 (ja) | 2008-12-24 |
Family
ID=27300182
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP06991998A Expired - Lifetime JP4203140B2 (ja) | 1997-03-25 | 1998-03-19 | ストリームデータ転送方法およびシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4203140B2 (ja) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20010093875A (ko) * | 2000-04-01 | 2001-10-31 | 이승룡 | 멀티미디어 스트리밍 환경에서 클라이언트 측에서 통합된푸시/풀 버퍼 관리 방법 |
| US6766376B2 (en) | 2000-09-12 | 2004-07-20 | Sn Acquisition, L.L.C | Streaming media buffering system |
| US7716358B2 (en) | 2000-09-12 | 2010-05-11 | Wag Acquisition, Llc | Streaming media buffering system |
| JP4025498B2 (ja) | 2000-10-18 | 2007-12-19 | 日本電気株式会社 | オブジェクトフィルタリング方法及びそれを用いたクライアント装置 |
| AU2002222097A1 (en) * | 2000-11-29 | 2002-06-11 | British Telecommunications Public Limited Company | Transmitting and receiving real-time data |
| JP2002217989A (ja) * | 2001-01-15 | 2002-08-02 | Mitsubishi Electric Corp | 多地点通信サービスユニット |
| JP3884920B2 (ja) | 2001-04-16 | 2007-02-21 | 株式会社日立製作所 | データ配送方法 |
| JP3885523B2 (ja) | 2001-06-20 | 2007-02-21 | 日本電気株式会社 | サーバ・クライアント型音声認識装置及び方法 |
| KR20030032414A (ko) * | 2001-10-18 | 2003-04-26 | 주식회사 엠씨글로벌 | 멀티미디어 데이터의 버퍼링 방법 |
| JP4786115B2 (ja) * | 2002-05-10 | 2011-10-05 | 株式会社日立製作所 | 計算機システム |
| US7418492B1 (en) * | 2002-06-20 | 2008-08-26 | P-Cube Ltd. | System and a method for testing network communication devices |
| CN100405350C (zh) * | 2003-04-24 | 2008-07-23 | 诺基亚有限公司 | 预设速率匹配信号通知的方法和装置 |
| JP4405306B2 (ja) | 2004-03-31 | 2010-01-27 | パナソニック株式会社 | コンテンツ送信装置およびコンテンツ再生装置 |
| US20050254508A1 (en) * | 2004-05-13 | 2005-11-17 | Nokia Corporation | Cooperation between packetized data bit-rate adaptation and data packet re-transmission |
| WO2006108434A1 (en) * | 2005-04-11 | 2006-10-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Technique for dynamically controlling data packet transmissions |
| JP5322518B2 (ja) * | 2008-07-08 | 2013-10-23 | キヤノン株式会社 | 通信方法 |
| JP2010197957A (ja) * | 2009-02-27 | 2010-09-09 | Seiko Epson Corp | 画像音声供給装置、画像音声出力装置、画像供給方法、画像音声出力方法、及びプログラム |
| CN102449600B (zh) * | 2009-03-06 | 2015-07-08 | 阿斯帕拉公司 | 用于i/o受驱速率自适应的方法和系统 |
| JP2013207375A (ja) * | 2012-03-27 | 2013-10-07 | Kddi Technology Corp | ストリーミングデータ伝送システム、ストリーミングデータの伝送方法およびプログラム |
| CN112005220A (zh) | 2018-04-27 | 2020-11-27 | 三菱电机株式会社 | 数据处理装置、监视方法及程序 |
| CN110515768B (zh) * | 2019-08-09 | 2021-10-15 | 苏州浪潮智能科技有限公司 | 备份数据的后台传输方法及装置 |
-
1998
- 1998-03-19 JP JP06991998A patent/JP4203140B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11184780A (ja) | 1999-07-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4203140B2 (ja) | ストリームデータ転送方法およびシステム | |
| KR100302263B1 (ko) | 스트림 데이터 전송방법 및 시스템 | |
| US7467221B2 (en) | Video server for video distribution system | |
| US7043558B2 (en) | Data communication apparatus and data communication method | |
| US7318107B1 (en) | System and method for automatic stream fail-over | |
| JP4709304B2 (ja) | 安価でスケーラブルなオープンアーキテクチャメディアサーバ | |
| US5878220A (en) | Method and apparatus for storing and transferring data on a network | |
| EP1533978B1 (en) | Data communication apparatus and data communication method | |
| JP3825099B2 (ja) | 映像データ転送方式およびビデオサーバ装置 | |
| US20030131068A1 (en) | Distributed storage system, storage device and method of copying data | |
| US20090083806A1 (en) | Media organization for distributed sending of media data | |
| KR100967700B1 (ko) | 피-투-피 방식의 주문형 비디오 서비스 시스템 | |
| JP2001024733A (ja) | データ伝送装置 | |
| JP2006060448A (ja) | スケーラブルマルチキャストコンテンツ配信システムと装置、およびそのレート制御方法と帯域配分方法、およびそのプログラムと記録媒体 | |
| US20020147827A1 (en) | Method, system and computer program product for streaming of data | |
| KR100521361B1 (ko) | 네트워크 환경에서의 파일 공동 전송 방법 | |
| JP2000172599A (ja) | マルチキャストストリームデータ転送方法およびシステム | |
| JP3706077B2 (ja) | ストリーム配信方法，ストリーム配信装置，ストリーム品質管理装置，ストリーム配信用プログラムおよびストリーム品質管理用プログラム | |
| JP2000339279A (ja) | 映像分散キャッシュ装置、及び映像収集再生装置 | |
| WO2002003704A1 (en) | System and method for fault tolerant stream splitting | |
| JP2002026942A (ja) | 情報配信／再生システム、情報配信／再生方法、記憶媒体 | |
| US20040080505A1 (en) | Moving picture file distributing device | |
| JPH0962624A (ja) | オンライントランザクションの処理方法および処理システム | |
| JP2000148710A (ja) | 動画像サーバシステム | |
| JP2000316132A (ja) | ビデオサーバ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041224 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041224 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080314 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080509 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080625 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080820 |
|
| 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: 20080917 |
|
| 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: 20081010 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4203140 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111017 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121017 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131017 Year of fee payment: 5 |
|
| S131 | Request for trust registration of transfer of right |
Free format text: JAPANESE INTERMEDIATE CODE: R313133 |
|
| SZ02 | Written request for trust registration |
Free format text: JAPANESE INTERMEDIATE CODE: R313Z02 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term | ||
| R154 | Certificate of patent or utility model (reissue) |
Free format text: JAPANESE INTERMEDIATE CODE: R154 |