JP2006013911A - ストリームデータ転送方法、装置、プログラム、および記録媒体 - Google Patents

Abstract

【課題】 インターネット上で大規模なストリーム配信を行う状況で、高速、かつ効率的にパケットの再送を行う。
【解決手段】 ストリーム配信サーバ１００は、ストリームプロトコル処理部１１１にて生成したストリームパケットＳａのコピーをそのＵＤＰヘッダ情報Ｈａと共に再送用バッファ１１５に格納してから、パケットＳａにＵＤＰ処理部１１２にてＵＤＰヘッダを付与し、ＵＤＰパケットＵａは、ＩＰ処理部１１３にて、ＩＰフラグメントされ、ＩＰパケットＩａはＩａ１、Ｉａ２、Ｉｓ３に分割されクライアント２００へ送信される。クライアント２００は、届いたＩＰパケットＩａ１が分割されたＩＰパケットであることを判断し、該パケットの情報をリストに書き込み、ＩＰ処理部２２０へ渡す。同様に、ＩＰパケットＩａ３の情報もリストに書き込む。ＩＰパケットＩａ２が欠落したと判断し、再送要求をストリーム配信サーバ１００に送信する。
【選択図】 図３

Description

本発明は音声、映像を含むストリーム配信において、大規模・高速な放送サービスを実現するストリームデータ配信装置に関する。

従来、インターネット上でのストリーム配信を行う場合、一般的には、ストリームコンテンツの要求および設定を行うストリーム設定プロトコル、設定に基づいて、ストリームコンテンツを配信するストリーム配信プロトコル、および、配信中のストリームコンテンツパケットの配信状況や配信品質の通知、サーバ−クライアント間の接続性状態の通知を行うストリーム制御プロトコルが用いられる。ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で規定されるプロトコルとしては、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ：非特許文献１参照）、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ：非特許文献２参照）、および、ＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：非特許文献２参照）があげられる。また、これら以外のストリームプロトコルを用いてストリーム配信を行う際にも、上記機能を持ったストリームプロトコルが利用されている。例として、Ｍｉｃｒｏｓｏｆｔ社のＭＭＳプロトコル、Ｒｅａｌ Ｎｅｔｗｏｒｋ社のＲＤＴ、ＰＮＡプロトコルなどがあげられる。

いずれのストリームプロトコルにおいても、クライアントまでのネットワーク等でパケットが廃棄した際に、該パケットを再度サーバから送信させることで、欠落したパケットを回復させる、再送と呼ばれるメカニズムを有することが一般的である。この再送のメカニズムを説明する。クライアントが、ストリーム配信サーバからストリームパケット受信中に、あるパケットが、中継ネットワークでの廃棄などの原因により欠落した場合、クライアントは該パケットを受信できなかったことを認識し、ストリーム配信サーバに対して該パケットの再送を要求する再送要求メッセージを送信する。ストリーム配信サーバでは、該メッセージを受信して、内容を解析して、クライアントに対して、要求されたパケットを再送信する。

一般的に、ストリームデータはＩＰパケット上にＵＤＰパケット、またはＴＣＰパケットを載せ、該ＵＤＰパケットまたはＴＣＰパケットのペイロードにストリームプロトコルを載せ（例えばＲＴＰプロトコル）、その上に音声や映像データをエンコードした符号データを載せて転送している。各プロトコル処理部では、レイヤ毎に処理内容が規定されており、レイヤ毎にヘッダ上のプロトコル情報を読み出し、プロトコルデータ正常性チェック処理、状態変数の遷移処理、加減／減算など、全ての規定処理後、次のレイヤに係る処理を順じ進める形で行われる。

再送に関する処理は、トランスポートプロトコルにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：非特許文献３参照）を用いる場合、ＴＣＰ処理部にて行われ、次のレイヤのストリームプロトコル処理部では行われない。一方、ＵＤＰを用いる場合、ＵＤＰ処理部では再送に関する処理は行われず、次のレイヤのストリームプロトコル処理部にて行われる。
ＩＥＴＦ、ＲＦＣ２３２６ ＩＥＴＦ、ＲＦＣ１８８９ ＩＥＴＦ、ＲＦＣ７９３

ＴＣＰの場合、サーバがクライアントへ複数個のパケットを送信した後、クライアントから該パケットが届いたことを示す確認応答が送られてくるのを待ち、次のパケットを送信する。一方、ＵＤＰの場合、サーバはクライアントからの応答を待つことなく、パケットをクライアントへ送りつづける。また、ＴＣＰの場合、ＵＤＰには無い、コネクション確立処理、フロー制御処理、輻輳制御処理を行う。そのため、大規模なストリーム配信を行う場合、転送サーバにかかる負荷が軽く、高速にストリームパケットを送信することができるＵＤＰを用いる方が効率的である。

ところで、ストリームパケットを載せるＵＤＰパケットの長さは一般的に様々である。物理層では一度に転送することのできるデータの最大の長さ（ＭＴＵ：Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）が規定されている（例えばＥｔｈｅｒｎｅｔ（登録商標）は１５００ｂｙｔｅｓ）ため、ＩＰ処理部にてＩＰフラグメントと呼ばれるメカニズムが働く。このＩＰフラグメントと呼ばれるメカニズムについて説明する。ＵＤＰパケットをＩＰパケットのペイロードに載せた後、該ＩＰパケットの長さがＭＴＵを超過している場合、ＩＰ処理部にて、該ＩＰパケットを、長さがＭＴＵ以下の複数のＩＰパケットに分割して送信する。受信元に届くまでに通るルータのＩＰ処理部において、分割されたＩＰパケットの長さが転送先の物理層のＭＴＵを超過している場合は、さらに分割して転送し、受信元に届けられる。受信元のＩＰ処理部では、送信元から届いた複数のＩＰパケットを一つのＩＰパケットに再構築する。分割されたＩＰパケットが全て届いた場合は、次のレイヤの処理を行うが、中継ネットワークでの廃棄などの原因により、分割されたＩＰパケットのうち一つでも届かないＩＰパケットがある場合には、再構築できないため、分割されたＩＰパケット全てを廃棄する。

前述したように、トランスポートプロトコルにＵＤＰを用いるストリーム配信において、パケットの再送はストリームプロトコル処理部にて行われるため、再送されるパケットは、ストリームパケット、またはＵＤＰパケット単位となる。

図５は、この時のフローの一例を示す図である。ストリーム配信サーバは、ストリームプロトコル処理部にて生成したストリームパケットＳａに、ＵＤＰ処理部にてＵＤＰヘッダを付与し、該ＵＤＰパケットＵａをＩＰ処理部に渡した後、ＩＰ処理部にて、ＩＰフラグメントされ、ＩＰパケットＩａはＩａ１、Ｉａ２、Ｉａ３に分割されクライアントへ送信する。クライアントは、ＩＰ処理部にて、届いたＩＰパケットＩａ１が分割されたＩＰパケットであることを判断しバッファに格納する。同様に、ＩＰパケットＩａ３もバッファに格納する。ＩＰパケットＩａ２が中継ネットワークでの廃棄などの原因により欠落した場合、ＩＰパケットＩａ２はクライアントへ届かず、ＩＰパケットＩａを再構築することができない。クライアントのＩＰ処理部は、ＩＰパケットＩａ１が到着してからのある時間内に分割されたパケットが全て届かない場合、ＩＰパケットＩａを再構築できないと判断し、バッファに格納されているＩａに関するパケット全て（Ｉａ１、Ｉａ３）を廃棄する。Ｉａ以降でクライアントのＩＰ処理部に問題なく届いたＩＰパケットＩｂ１、Ｉｂ２、Ｉｂ３をＩＰ処理部、ＵＤＰ処理部で順次処理し、ストリームパケットＳｂとしてストリームプロトコル処理部に渡され、ストリームプロトコル処理部にて、ストリームパケットＳａが欠落したと判断し、再送要求をストリーム配信サーバに送信する。ストリーム配信サーバで、クライアントから送信された再送要求を、ストリームプロトコル処理部にて処理し、ストリームパケットＳａを再度クライアントへ送信する。

上述したように、従来の技術では、ＩＰフラグメントにより分割された複数のＩＰパケットがほとんどクライアントに届いた場合でも、分割された複数のＩＰパケットのうち一つでも届かないと、クライアントに届いている分割されたＩＰパケットを全て廃棄し、ストリーム配信サーバは、欠落した分割されたＩＰパケット分だけでなく、クライアントに届いていた分割されたＩＰパケットも含むＩＰパケット（分割される前のＩＰパケット）を再送するため、ネットワーク帯域を必要以上に多く使用することになり、ストリーム配信サーバの配信性能が制限される問題があった。また、再送判断、再送処理をストリームプロトコル処理部にて行っているため、欠落したストリームパケットの後にストリームパケットが届くまで再送判断ができず、再送処理はＵＤＰ処理とＩＰ処理を伴うため、再送されるまでの時間が必要以上にかかっていたという問題があった。

本発明の目的は、インターネット上で大規模なストリーム配信を行う状況で、効率的に、かつ高速にパケットの再送を行うことができるストリーム転送方法、装置、プログラム、および記録媒体を提供することにある。

ストリーム配信サーバが、ストリームパケット処理部にて処理したストリームパケットを、該ストリームパケットのＩＰ／ＵＤＰヘッダ情報と共に再送用バッファに格納し、さらに、ＩＰ処理部にて処理したＩＰパケットをクライアントに送信する前に、該パケットの識別子を該パケットに関連付けて格納する。ストリーム配信サーバは、クライアントから送られたＩＰパケットをＩＰ処理部へ渡す前に、該ＩＰパケットがＩＰパケット再送要求メッセージであるかどうかを判別し、再送要求メッセージである場合、該パケットをＩＰ処理部へは渡さず、ＩＰパケット再送要求メッセージを解析し、要求されたストリームパケットと必要に応じて該ストリームパケットのＵＤＰヘッダ情報を再送用バッファから読み出し、該パケットと該ＵＤＰヘッダ情報から、要求された再送パケットを生成し、クライアントへ送信する。

また、クライアントが、ストリーム配信サーバから送られたＩＰパケットをＩＰ処理部へ渡す前に、ＩＰフラグメントされたパケットであるかどうか判別し、ＩＰフラグメントされたパケットである場合、該パケットの情報をフラグメントパケットリストへ書き込んでから、該パケットをＩＰ処理部へ渡す。クライアントは、フラグメントパケットリストを監視し、フラグメントパケットの欠落を検知した場合、欠落パケットの再送を要求するＩＰパケット再送要求メッセージをストリーム配信サーバへ送信する。

なお、クライアントが、フラグメントパケットリストを監視し、フラグメントパケットを一つも欠落なく全て受け取った場合、該パケットの情報を全てフラグメントパケットリストから削除することもできる。

また、本発明のストリーム配信サーバは、ストリームパケット処理部にて処理したストリームパケットを該ストリームパケットのＩＰ／ＵＤＰヘッダ情報と共に再送用バッファに格納する手段と、ＩＰ処理部にて処理したＩＰパケットをクライアントに送信する前に、該パケットの識別子を抽出する手段と、該識別子を当該パケットに関連付けてバッファに格納する手段と、クライアントから送られたＩＰパケットを受信する手段と、該パケットがＩＰパケット再送要求メッセージであるかどうか判別する手段と、再送要求メッセージである場合、該パケットをＩＰ処理部へは渡さず、ＩＰパケット再送要求メッセージを解析する手段と、要求されたストリームパケットと、必要に応じて該ストリームパケットのＵＤＰヘッダ情報を再送用バッファから読み出す手段と、該パケットと該ＵＤＰヘッダ情報から要求された再送パケットを生成する手段と、生成された再送パケットをクライアントへ送信する手段を有する。

また、本発明のクライアントは、ストリーム配信サーバから送られたＩＰパケットを受信し、該パケットをＩＰ処理部へ渡す前に、ＩＰフラグメントされたパケットであるかどうか判別する手段と、該パケットがＩＰフラグメントされたパケットである場合、該パケットの情報をフラグメントパケットリストへ書き込む手段と、書き込んだ後に該パケットをＩＰ処理部へ渡す手段と、フラグメントパケットリストを監視し、フラグメントパケットの欠落があるかどうかを調べる手段と、フラグメントパケットの欠陥が検出されると、欠落パケットの再送を要求するＩＰパケット再送要求メッセージを生成する手段と、該ＩＰパケット再送要求メッセージをストリーム配信サーバへ送信する手段を有する。

なお、本発明のクライアントは、フラグメントパケットの欠落が検知されなかった場合、該パケットの情報を全てフラグメントパケットリストから削除する手段を有することもできる。

本発明により、ストリームパケットの送信元のサーバと、ストリームパケットの送信先のクライアント間において、ＩＰフラグメントにより分割された複数のＩＰパケットのうち、欠落したＩＰパケットのみを再送することができ、再送による余分な帯域の使用を防ぐことが可能となる。また、ストリームパケットの欠落の判断、再送処理を、ＩＰパケットプロトコル処理する前に実行することができるため、効率的、高速に再送を行うことが可能となる。また、再送用バッファをＯＳレイヤでなくアプリケーションレイヤにて持つことで容量の少ないＯＳレイヤのメモリを使用せずに済む。これは、インターネット上で大規模なストリーム配信を行う状況で、特に、配信レートの高いコンテンツを配信する場合、同時に多くのクライアントが接続するライブ配信において有効である。

本発明によれば、ＩＰフラグメントやパケットの欠落が起こりやすいインターネット上で大規模なストリーム配信を行う状況で、効率的に、高速にパケットの再送を行うことが可能となる。

次に、本発明の実施の形態について図面を参照して説明する。

図１は、本発明におけるストリーム配信サーバのブロック構成図である。

図１に示すように、ストリーム配信サーバ１００は、ストリームプロトコル処理部１１１、ＵＤＰ処理部１１２、ＩＰ処理部１１３、バッファ書き込み部１１４、再送用バッファ１１５、送信部１１６、受信部１１７、再送要求判別部１１８、再送要求解析部１１９、バッファ読み出し部１２０、再送パケット生成部１２１、識別子読み取り部１２２から構成され、送信部１１６、受信部１１７を通して、クライアント２００とストリームパケットを送受信する。

ストリームプロトコル処理部１１１は、ストリームプロトコル（例えば、ＲＴＰ）に音声や映像データをエンコードした符号データを載せたストリームパケットをＵＤＰ処理部１１２へ渡す。この時、ストリームプロトコル処理部１１１は、該ストリームパケット、および該ストリームパケットのＩＰ／ＵＤＰヘッダ情報をバッファ書き込み部１１４へ渡す。本実施形態においては、ストリームプロトコル処理部１１１が渡すＩＰ／ＵＤＰヘッダ情報は、パケットの送信先ＩＰアドレス、送信先ポート、送信元ポートとする。
ストリームパケットが渡されたＵＤＰ処理部１１２は、ＵＤＰヘッダを付与したＵＤＰパケットを、ＩＰプロトコルを処理するＩＰ処理部１１３へ渡し、ＩＰ処理部１１３にてＩＰヘッダが付与されたＩＰパケットを送信部１１６へ渡す前に、識別子読み取り部１２２にて該パケットの識別子を読み取り、該識別子をバッファ書き込み部１１４へ渡し、パケットを送信部１１６を通してクライアント２００へ送信する。

バッファ書き込み部１１４は、渡された識別子を再送用バッファ１１５の中で該当するパケットのＩＰ／ＵＤＰヘッダ情報に加える。本実施形態においては、識別子は、ＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドの値とし、再送用バッファ１１５へのＩＰ／ＵＤＰヘッダ情報とストリームパケットの格納方法とその格納例を図４に示す。また、本実施形態においては、バッファ書き込み部１１４が識別子を格納する際、再送用バッファ１１５から、ＩＰ／ＵＤＰヘッダ情報の識別子フィールドの値がまだ入力されていない箇所を、格納された順番で検索し、検索された時に、その一つ前のＩＰ／ＵＤＰヘッダ情報の識別子フィールドの値と、識別子読み取り部１２２から渡された識別子を比較し、両者が等しい場合には識別子を再送用バッファ１１５に書き込まずに廃棄する。両者が異なる場合には、次のＩＰ／ＵＤＰヘッダ情報の識別子フィールドに、識別子読み取り部１２２から渡された識別子を書き込む。

受信部１１７は、クライアント２００からＩＰパケットを受信し、再送要求判別部１１８へ渡す。

再送要求判別部１１８は、該ＩＰパケットがＩＰパケット再送要求メッセージであるかどうか判別し、ＩＰパケット再送要求メッセージである場合には、再送要求解析部１１９へ、ＩＰパケット再送要求メッセージ以外である場合には、ＩＰ処理部１１３へ該パケットを渡す。本実施形態においては、ＩＰパケット再送要求メッセージであるかどうかの判別判断に、ＩＰヘッダのＰｒｏｔｏｃｏｌフィールドを用い、Ｐｒｏｔｏｃｏｌフィールドの値が２００の場合に再送要求メッセージと判断し、２００以外の場合にはＩＰパケット再送要求メッセージ以外のパケットと判断する。また、本実施形態においては、ＩＰパケット再送要求メッセージの構成は表１に示す通りとし、要求識別子は再送を要求するＩＰパケットの識別子で、要求始点と要求終点は再送を要求するＩＰパケットのデータでそれぞれ元のＩＰデータの開始位置と終了位置とする。

再送要求解析部１１９は、再送要求判別部１１８から受け取ったパケットから、送信元ＩＰアドレス、要求識別子、要求始点、要求終点を取り出し、バッファ読み出し部１２０へ渡す。バッファ読み出し部１２０は、送信元ＩＰアドレス、要求識別子、要求始点、要求終点から、再送を要求するストリームパケットおよび該ストリームパケットのＩＰ／ＵＤＰヘッダ情報を再送用バッファ１１５から読み出し、再送パケット生成部１２１へ渡す。本実施形態においては、再送要求解析部１１９から渡された送信元ＩＰアドレスと要求識別子がそれぞれ再送用バッファ１１５の識別子フィールドと送信先ＩＰアドレスフィールドの値と一致した際のＩＰ／ＵＤＰヘッダ情報が要求されたＩＰ／ＵＤＰヘッダ情報、該ストリームパケットの（要求始点＋１）×８オクテット目から（要求終点＋１）×８−１オクテット目までが再送を要求されたストリームパケットとする。
再送パケット生成部１２１は、バッファ読み出し部１２０で読み出したストリームパケットにＵＤＰヘッダ、ＩＰヘッダをＩＰ／ＵＤＰヘッダ情報に従い付与し、送信部１１６を通してクライアント２００へ送信する。

図２は、クライアントのブロック構成図である。

図２に示すように、クライアント２００は、受信部２１１、フラグメントパケット判別部２１２、リスト書き込み部２１３、フラグメントパケットリスト２１４、リスト監視部２１５、再送要求部２１６、送信部２１７、リスト削除部２１８、ＩＰ処理部２１９、ＵＤＰ処理部２２０、ストリームプロトコル処理部２２１から構成され、送信部２１７、受信部２１１を通して、ストリーム配信サーバ１００とストリームパケットを送受信する。

フラグメントパケット判別部２１２は、ストリーム配信サーバ１００から受信部２１１を通してＩＰパケットを受け取り、該パケットがＩＰフラグメントにより分割されたパケットかどうか判別し、分割されたパケットである場合には、リスト書き込み部２１３へ、分割されたパケットでない場合には、ＩＰ処理部２１９へ該パケットを渡す。本実施形態においては、分割されたパケットであるかどうかの判別判断に、ＩＰヘッダのＦｌａｇｓフィールドとＦｌａｇｍｅｎｔ Ｏｆｆｓｅｔフィールドを用い、Ｆｌａｇｓフィールドの３ビット目の値（Ｍｏｒｅ Ｆｒａｇｍｅｎｔ）が１である場合、またはＦｌａｇｍｅｎｔ Ｏｆｆｓｅｔフィールドの値が０以外である場合に分割されたパケットであると判断し、それ以外の場合を分割されたパケットでないと判断する。

リスト書き込み部２１３は、フラグメントパケット判別部２１２から受け取ったＩＰパケットのフラグメントパケット情報をフラグメントパケットリスト２１４に書き込み、該パケットをＩＰ処理部２１９へ渡す。本実施形態においては、フラグメントパケット情報は表２に示す通りとし、開始位置、終了位置、フラグは、それぞれＩＰヘッダのＦｌａｇｍｅｎｔ Ｏｆｆｓｅｔフィールドの値、Ｆｌａｇｍｅｎｔ Ｏｆｆｓｅｔフィールドの値＋Ｔｏｔａｌ Ｌｅｎｇｔｈフィールドの値−Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈフィールドの値、Ｆｌａｇｓフィールドの３ビット目の値（Ｍｏｒｅ Ｆｒａｇｍｅｎｔ）とし、フラグメントパケットリスト２１４は表３に示す通りとし、識別子、送信元ＩＰアドレスは、それぞれＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドの値、Ｓｏｕｒｃｅ ＩＰ Ａｄｄｒｅｓｓフィールドの値とする。

また、本実施形態においては、リスト書き込み部２１３が、フラグメントパケット判別部２１２から受け取ったＩＰパケットのフラグメントパケット情報をフラグメントパケットリスト２１４に書き込む方法は次の（１）から（３）を順に行う。
（１） 識別子、送信元ＩＰアドレスがそれぞれＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドの値、Ｓｏｕｒｃｅ ＩＰ Ａｄｄｒｅｓｓフィールドの値と同じフラグメントパケットリストを検索し、もし無い場合には、識別子、送信元ＩＰアドレスをそれぞれＩＰヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎフィールドの値、Ｓｏｕｒｃｅ ＩＰ Ａｄｄｒｅｓｓフィールドの値とするフラグメントパケットリストを新たに作成する。
（２） 開始位置、終了位置、フラグをＩＰヘッダのＦｌａｇｍｅｎｔ Ｏｆｆｓｅｔフィールドの値、Ｆｌａｇｍｅｎｔ Ｏｆｆｓｅｔフィールドの値＋Ｔｏｔａｌ Ｌｅｎｇｔｈフィールドの値−Ｉｎｔｅｒｎｅｔ Ｈｅａｄｅｒ Ｌｅｎｇｔｈフィールドの値、Ｆｌａｇｓフィールドの３ビット目の値（Ｍｏｒｅ Ｆｒａｇｍｅｎｔ）とするフラグメントパケット情報を作成する。
（３） （２）で作成したフラグメントパケット情報を（１）で検索または作成したフラグメントパケットリストに追加する。この時、既に別のフラグメントパケット情報が存在する場合には、フラグメントパケット情報の開始位置が昇順となるように追加する。
リスト監視部２１５は、フラグメントパケットリスト２１４を監視し、ＩＰフラグメントにより分割されたパケットの欠落を検知した際に、該フラグメントパケットリストのコピーを再送要求部２１６へ渡す。本実施形態においては、最初のフラグメントパケット情報の開始位置が０でない場合、フラグメントパケット情報の終了位置と次のフラグメントパケット情報の開始位置が等しくない場合に、ＩＰフラグメントにより分割されたパケットの欠落があると判断する。

再送要求部２１６は、リスト監視部２１５から受け取ったフラグメントパケットリストよりＩＰパケット再送要求メッセージを生成する。本実施形態においては、前述した通り、ＩＰパケット再送要求メッセージの構成は表１に示す通りであり、最初のフラグメントパケット情報の開始位置が０でない場合は、要求始点と要求終点は、それぞれ０と最初のフラグメントパケット情報の開始位置とし、フラグメントパケット情報の終了位置と次のフラグメントパケット情報の開始位置が等しくない場合は、要求始点と要求終点は、それぞれフラグメントパケット情報の終了位置と次のフラグメントパケット情報の開始位置とする。また、再送識別子にはフラグメントパケットリストの識別子とし、Ｄｅｓｔｉｎａｔｉｏｎ ＩＰ Ａｄｄｒｅｓｓフィールドの値、Ｐｒｏｔｏｃｏｌフィールドの値をそれぞれフラグメントパケットリストの送信元ＩＰアドレス、２００とするＩＰヘッダを付与する。再送要求部２１６で生成されたＩＰパケット再送要求メッセージは送信部２１７を通してストリーム配信サーバ１００へ送信される。

リスト監視部２１５は、フラグメントパケットリスト２１４を監視し、ＩＰフラグメントにより分割されたパケットを全て受け取ったことを検知した際に、フラグメントパケットリスト２１４のコピーをリスト削除部２１８へ渡す。本実施形態においては、最初のフラグメントパケット情報の開始位置が０で、かつ、フラグメントパケット情報の終了位置と次のフラグメントパケット情報の開始位置が等しく、かつ、最後のフラグメントパケット情報のフラグが０である場合に、ＩＰフラグメントにより分割されたパケットを全て受け取ったと判断する。リスト削除部２１８は、リスト監視部２１５から受け取ったフラグメントパケットリストと同じフラグメントパケットリストを削除する。本実施形態においては、フラグメントパケットリストの識別子と送信元ＩＰアドレスがどちらもに同じフラグメントパケットリストを削除する。

図３は本実施形態における再送時のフローの一例を示す図である。ストリーム配信サーバ１００は、ストリームプロトコル処理部１１１にて生成されたストリームパケットＳａのコピーを該ストリームパケットのＵＤＰヘッダ情報Ｈａと共に再送用バッファ１１５に格納してから、該パケットＳａにＵＤＰ処理部１１２にてＵＤＰヘッダを付与し、該ＵＤＰパケットＵａがＩＰ処理部１１３に渡された後、ＩＰ処理部１１３にて、ＩＰフラグメントされ、ＩＰパケットＩａはＩａ１、Ｉａ２、Ｉｓ３に分割され、送信部１１６からクライアント２００へ送信する。クライアント２００は、本発明部（フラグメントパケット判別部２１２、リスト書き込み部２１３）にて、届いたＩＰパケットＩａ１が分割されたＩＰパケットであることを判断し、該パケットの情報をリストに書き込み、ＩＰ処理部２２０へ渡す。同様に、ＩＰパケットＩａ３の情報もリストに書き込む。本発明部（リスト監視部２１５、再送要求部２１６）にて、ＩＰパケットＩａ２が欠落したと判断し、再送要求をストリーム配信サーバ１００に送信する。ストリーム配信サーバ１００で、クライアント２００から送信された再送要求を、ＩＰ処理部１１３へ渡さずに、本発明部（再送要求判別部１１８〜再送パケット生成部１２１）にて、ストリームプロトコル処理部１１１にある再送用バッファ１１５から、要求されたストリームパケットＳａ２を取り出し、要求されたＩＰパケットＩａ２相深部１１６よりを再度クライアント２００へ送信する。

前記実施形態では、ストリーム配信サーバとクライアントで再送に関するやり取りをしているが、本発明に関わるストリーム配信サーバの機能と手段をストリーム中継サーバが具備し、ストリーム中継サーバとクライアントで再送に関するやり取りをする構成もあり得る。また、同様に、本発明に関わるクライアントの機能と手段をストリーム中継サーバが具備し、ストリーム配信サーバとストリーム中継サーバで再送に関するやり取りをする構成もあり得る。

また、前記実施形態では、ストリーム配信サーバは、本発明に関わるクライアントの機能と手段を具備していないが、本発明に関わるクライアントの機能と手段を、本発明に関わるストリーム配信サーバの機能と手段と共に具備する構成もあり得る。同様に、クライアントは、本発明に関わるストリーム配信サーバの機能と手段を具備していないが、本発明に関わるストリーム配信サーバの機能と手段を、本発明に関わるクライアントの機能と手段と共に具備する構成もあり得る。

また、前記実施形態では、ＩＰパケット再送要求メッセージの判別のために、ＩＰヘッダのＰｒｏｔｏｃｏｌフィールドを用いたが、代わりにＩＰヘッダのＯｐｔｉｏｎフィールド、またはＩＰデータフィードを用いることもあり得る。

また、前記実施形態では、ＩＰパケット再送要求メッセージの判別のために、ＩＰヘッダのＰｒｏｔｏｃｏｌフィールドの値を２００としたが、２００以外の値にすることも当然あり得る。

また、前記実施形態では、ＩＰパケット再送要求メッセージの構成は表１に示す通りとしたが、要求識別子、要求始点、要求終点が異なる順序である構成にすることもあり得る。

また、前記実施形態では、ＩＰパケット再送要求メッセージの構成は表１に示す通りとしたが、要求終点の変わりに再送を要求するＩＰパケットのデータ長とする構成も当然あり得る。

また、前記実施形態では、再送パケット生成部１２１がＩＰヘッダの生成手段について、特に明記していないところ、従来からあるＩＰ処理部にて行っているＩＰヘッダの生成手段を具備すればよい。

また、前記実施形態では、フラグメントパケットリスト２１４にてＩＰフラグメントにより分割された複数のパケットの受信状況を管理しているが、フラグメントパケットリスト２１４の代わりに、複数の分割されたパケットのコピーを格納するバッファで管理してもよい。

また、前記実施形態では、リスト監視部２１５にて、最初のフラグメントパケット情報の開始位置が０でない場合、フラグメントパケット情報の終了位置と次のフラグメントパケット情報の開始位置が等しくない場合に、ＩＰフラグメントにより分割されたパケットの欠落があると判断しているが、必要に応じて他の条件であっても、他の条件を追加してもよい。

また、前記実施形態では、クライアントでの本発明の対象パケットの設定手段について、特に明記していないところ、システムに応じた設定手段を具備すればよい。

なお、ストリーム配信サーバ１００、クライアント２００の機能は専用のハードウェアにより実現されるもの以外に、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間の間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含む。

本発明の一実施形態のストリーム配信サーバのブロック構成図である。 本発明の一実施形態のクライアントのブロック構成図である。 再送時の処理の流れを示す図である。 再送用バッファへのＩＰ／ＵＤＰヘッダ情報とストリームパケットの格納方法とその格納例を示す図である。 従来技術における再送時の処理の流れを示す図である。

符号の説明

１００ ストリーム配信サーバ
１１１ ストリームプロトコル処理部
１１２ ＵＤＰ処理部
１１３ ＩＰ処理部
１１５ 再送用バッファ
１１６ 送信部
１１７ 受信部
１１８ 再送要求判別部
１１９ 再送要求解析部
１２０ バッファ読み出し部
１２１ 再送パケット生成部
２００ クライアント
２１１ 受信部
２１２ フラグメントパケット判別部
２１３ リスト書き込み部
２１４ フラグメントパケットリスト
２１５ リスト監視部
２１６ 再送要求部
２１７ 送信部
２１８ リスト削除部
２１９ ＩＰ処理部
２２０ ＵＤＰ処理部
２２１ ストリームプロトコル処理部

Claims (8)

1. ストリーム配信サーバから、ストリーム中継サーバを介して、クライアントにストリームパケットを送出するストリーム配信ネットワークにおいて、
   ストリーム配信サーバまたはストリーム中継サーバにて、
   ストリームプロトコル処理後のストリームパケットのコピーおよび該ストリームパケットのＩＰ／ＵＤＰヘッダ情報をバッファに格納し、該パケットをＩＰ処理後、該パケットの識別子を抽出し、該パケットの識別子としてバッファに格納し、
   クライアントから送られたＩＰパケット再送メッセージをＩＰ処理せずに、クライアントから要求されたＩＰパケットを、ストリームパケットのコピーが格納されている再送用バッファから生成し、クライアントへ送信することを特徴とするストリーム転送方法。
2. ストリーム配信サーバから、ストリーム中継サーバを介して、クライアントにストリームパケットを送出するストリーム配信ネットワークにおいて、
   クライアントにて、
   ストリーム配信サーバまたはストリーム中継サーバから送られたＩＰパケットを、ＩＰ処理する前に、ＩＰフラグメントにより分割されたＩＰパケットであるかどうか判断し、分割されたＩＰパケットである場合、該パケットの情報をリストへ書き込んでから、ＩＰ処理し、
   前記リストを監視し、パケットの欠落を検知した場合、欠落したＩＰパケットの再送を要求するＩＰパケット再送要求メッセージを生成し、ストリーム配信サーバまたはストリーム中継サーバへ送信することを特徴とするストリーム転送方法。
3. 前記リストを監視し、ＩＰフラグメントにより分割された複数のＩＰパケットを全て受け取った場合、前記リストから該パケットの情報を削除する、請求項２に記載のストリーム転送方法。
4. ストリームパケットを、ストリーム中継サーバを介して、クライアントに送出するストリーム転送装置において、
   ストリームパケット処理部にて処理したストリームパケットを該ストリームパケットのＩＰ／ＵＤＰヘッダ情報と共に再送用バッファに格納する手段と、
   ＩＰ処理部にて処理したＩＰパケットをクライアントに送信する前に、該パケットの識別子を抽出する手段と、
   該識別子を該パケットに関連付けてバッファに格納する手段と、
   クライアントから送られたＩＰパケットを受信する手段と、
   該パケットがＩＰパケット再送要求メッセージであるかどうか判別する手段と、
   再送要求メッセージである場合、該パケットをＩＰ処理部へは渡さず、ＩＰパケット再送要求メッセージを解析する手段と、
   要求されたストリームパケットと、必要に応じて該ストリームパケットのＵＤＰヘッダ情報を前記再送用バッファから読み出す手段と、
   該パケットと該ＵＤＰヘッダ情報から要求された再送パケットを生成する手段と、
   生成された再送パケットをクライアントへ送信する手段を有するストリーム転送装置。
5. ストリーム配信サーバからストリーム中継サーバを介して、クライアントに送出されたストリームパケットを受信するストリーム転送装置において、
   ストリーム配信サーバから送られたＩＰパケットを受信し、該パケットをＩＰ処理部へ渡す前に、ＩＰフラグメントされたパケットであるかどうか判別する手段と、
   該パケットがＩＰフラグメントされたパケットである場合、該パケットの情報をフラグメントパケットリストへ書き込む手段と、
   前記フラグメントパケットリストを監視し、フラグメントパケットの欠落があるかどうかを調べる手段と、
   フラグメントパケットの欠落が検出されると、該欠落パケットの再送を要求するＩＰパケット再送要求メッセージを生成する手段と、
   該ＩＰパケット再送要求メッセージをストリーム配信サーバへ送信する手段を有するストリーム転送装置。
6. プラグメントパケットの欠落が検出されなかった場合、当該パケットの情報を全て前記フラグメントパケットリストから削除する手段をさらに有する、請求項５に記載のストリーム転送装置。
7. 請求項１から３のいずれかに記載のストリーム転送方法をコンピュータに実行させるためのプログラム。
8. 請求項７に記載のプログラムを記録した、コンピュータ読み取り可能な記録媒体。

Images