JP3579335B2 - ストリーム配信装置 - Google Patents
ストリーム配信装置 Download PDFInfo
- Publication number
- JP3579335B2 JP3579335B2 JP2000252288A JP2000252288A JP3579335B2 JP 3579335 B2 JP3579335 B2 JP 3579335B2 JP 2000252288 A JP2000252288 A JP 2000252288A JP 2000252288 A JP2000252288 A JP 2000252288A JP 3579335 B2 JP3579335 B2 JP 3579335B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- stream
- distribution
- address
- copy
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ストリームサーバの送信する１または複数のストリーム放送のパケットを受信し、該パケットをコピー後、１または複数のクライアントへ放送配信するストリーム配信装置に関する。
【０００２】
【従来の技術】
従来、インターネット上に設置されたストリーム配信装置としては、Ｒｅａｌ Ｎｅｔｗｏｒｋｓ社などのスプリッタ製品が代表的である。これは、汎用パソコンや汎用ワークステーションなどの汎用プロセッサ上で動作し、ストリームサーバから受信した１本のストリームデータを１または複数のクライアントに対してコピー配信するものである。
【０００３】
従来のストリーム放送の制御を行うストリーミングプロトコルでは、放送コンテンツ毎に、UDPポート番号に対応させてストリーム配信が行われていた。UDPポート番号は、クライアント、スプリッタ、サーバなどの配信機器の接続構成により、下流の機器が受信ポート番号を決定する方式となっているため、サーバ→スプリッタ→クライアントという構成でストリーム配信を行う場合は、スプリッタ側でUDPポート番号を変換する機能を持っていた。
【０００４】
【発明が解決しようとする課題】
上述した従来のスプリッタは、汎用プロセッサの通信機能をベースとした技術であった。一般的に、ストリームデータはIPパケット上にUDPパケットのペイロードにストリーム転送プロトコル（例えばIETF RFC１８８９で規定されたRTPプロトコル）を載せ、その上に音声や映像データをエンコードした符号データを載せて転送していた。したがって、汎用プロセッサのOSが提供する、IPパケットプロトコル解析機能、UDPパケットプロトコル解析機能を利用して処理されていた。
各プロトコル解析機能は、レイヤ毎に処理内容が規定されている。よって、レイヤ毎にヘッダ上のプロトコル情報を読み出し、プロトコルデータ正常性チェック処理、状態変数の遷移処理、加算／減算処理など、全ての規定処理を実行後、次のレイヤに係る処理を順次進める形で行われていた。このため、レイヤ毎にプロトコル解析処理をするためのメモリオペレーションがオーバヘッドとなり高速化処理に向いていなかった。
【０００５】
一方、ストリームパケットの転送に特化した処理を想定すると、主な処理はサーバからの受信ＵＤＰポート番号、受信ＩＰアドレスをクライアント宛の送信ＵＤＰポート番号、送信ＩＰアドレスに書き換え後、ＵＤＰパケットとＩＰヘッダのチェックサム再計算を行っていた。この場合、ＩＰアドレスやＵＤＰポート番号の読み出し、書き込み以外に他プロトコルパラメタ分析処理も併せて実行させてしまう分だけオーバヘッドが大きくなった。さらに、チェックサム計算処理は、ＵＤＰペイロードデータ全体に対して１６ビットづつメモリ読出し／演算処理を繰り返すために、長いパケットほど計算時間が長くなってしまった。しかしながら、チェックサムの再計算は、受信時点でのパケットのチェックサム計算値から、ＩＰアドレス、ＵＤＰポート番号を書き換えた部分の差分だけを計算すればよい。
【０００６】
以上述べたように、従来のストリーム配信装置は、汎用プロセッサが提供する通信機能がレイヤ毎に動作するためのオーバヘッド、処理機能が汎用化されているために必要以上の処理を実行しなければならない。このため、ストリーム配信を高速・大容量化するためには、最適な機能構成とはなっていない。
【０００７】
本発明の目的は、プロトコルレイヤ毎の処理オーバヘッド削減、チェックサムのフル計算の排除により処理を最小限とし、高速・大容量なストリーム配信装置を提供することである。
【０００８】
【課題を解決するための手段】
本発明においては、まずストリームパケットを受信すると、１つのパケットの先頭部に位置するヘッダ情報から、ストリーム配信に必要最低限なヘッダ情報をプロトコルレイヤを区別せずに抽出する。その情報からコンテンツを識別する。また、コンテンツ毎に配付先の宛先情報（配信情報）をテーブル（コピー配布表）に登録しておき、受信したパケットのヘッダ情報から、送信すべきパケットのヘッダ情報へ変換する手段を持つ。
【０００９】
すなわち、コピー配布表を参照して、送信宛先のクライアント毎に定められた配信情報を求め、該配信情報を元に受信パケットの複製とヘッダ書き換えを行い、一時退避したチェックサム値と書き換え後のヘッダ情報部分の差分を元に再計算した結果を新たなチェックサム値として送信パケットに設定し、当該クライアントへ送信する処理をコピー配布表に登録された全クライアント分の処理が終了するまで繰り返す。
【００１０】
この場合、抽出するプロトコル情報は受信パケットのＩＰアドレスおよびＵＤＰ
ポート番号、コピー配布表のデータ内容はコンテンツに対するコピー数、送信ＩＰアドレス、送信ポート番号、チェックサム差分値でもよい。
【００１１】
本発明におけるチェックサム値の計算は、受信パケットと送信パケットのヘッダ情報が既知であるため、パケット受信の都度再計算するのではなく、受信ヘッダ情報と配布すべき送信ヘッダ情報からあらかじめ計算しておく。
【００１２】
本発明によれば、まず、ストリームデータを転送するパケットのプロトコルレイヤ毎に処理を分けるのではなく、パケットの受信処理、送信処理を実行する。また、全プロトコルデータを処理するのではなく、特定のプロトコルデータに限定した処理（ヘッダ書き換え）を実行するため、１パケット当たりの処理量を削減することができる。
【００１３】
さらに、送信パケットのチェックサム値の再計算は、コピー配布表により変換すべき送り先のアドレス、ポート番号が既知であるため、事前に差分情報を計算しておき、パケット受信および送信の際に、その差分情報により残りの演算のみを実行することにより、さらに１パケット当たりの処理量を削減することができる。
【００１４】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００１５】
図１に示すように、本発明のストリーム配信装置１はストリームサーバ２から受信回線３を介してストリームコンテンツを受信し、またコピー後のストリームコンテンツを送信回線４１、４２、・・・、４ｎを介してクライアント５１、５２、・・・、５ｎに配信する。
【００１６】
この場合、受信したパケットのIPソースアドレスはストリームサーバ２、IPデスティネーションアドレスはストリーム配信装置１、送信するパケットのIPソースアドレスはストリーム配信装置１、IPデスティネーションアドレスはクライアント（５1〜５nのうちの一つ）をそれぞれ指して転送する。また、ポート番号は、デスティネーションポート番号のみをストリーム配信装置１にて付け替え、ソースポート番号はそのまま転送することとする。以上により、ストリーム配信装置１がパケットを受け渡す際には、チェックサム以外にIPソースアドレス、IPデスティネーションアドレス、デスティネーションポート番号の付け替え処理が発生する。
【００１７】
ストリーム配信装置１は、図２に示すように、受信回路１１と書込処理部１２とパケットバッファ１３とコピー制御部１４とコンテンツ識別子検索テーブル１５と要求バッファ１６とデータ設定部１７とコピー配信制御テーブル１８（コピー配布表）とコピー処理部１９とコピー処理バッファ２０と読出処理部２１と送信回路２２を有している。
【００１８】
受信回路１１は、パケットのＭＡＣレイヤ以下を終端し、パケット受信を後段の書込処理部１２へ通知する。
【００１９】
書込処理部１２は、パケット受信通知後、受信回路１１で受信したパケットをパケットバッファ１３へ転送するとともに、書き込んだバッファの先頭番地とバッファ長をコピー制御部１４へ通知する。
【００２０】
パケットバッファ１３は、受信パケットを格納しておくバッファである。
【００２１】
コピー制御部１４は、書込処理部１２から通知されたバッファ番地、バッファ長を元にパケットバッファ１３へアクセスし、当該パケットのＩＰアドレスとＵＤＰポート番号を取り出すとともに、該情報をキーとしてコンテンツ識別子検索テーブル１５にアクセスし、受信パケットの運ぶストリームのコンテンツ識別子を求める。このコンテンツ識別子とバッファ番地、バッファ長を要求バッファ１６に入力することにより、後段のコピー処理を依頼する。
【００２２】
コンテンツ識別子検索テーブル１５は、表１に示すように、受信ＵＤＰデスティネーションポート番号、受信ＩＰソースアドレス、コンテンツ識別子を構成要素に持ち、受信情報からコンテンツ識別子を割り出すために使用される。
【００２３】
【表１】
【００２４】
要求バッファ１６は、コピー処理要求をコンテンツ識別子、バッファ番地、バッファ長としてエントリーし、コピー処理部１９により読み出されるバッファである。
【００２５】
データ設定部１７は、配信に先立ち、表１および表２のテーブルを事前に作成、維持、管理する。コピー配信制御テーブル１８（表２）には、コンテンツ識別子、コピー数、送信デスティネーションポート番号、送信ＩＰデスティネーションアドレス、チェックサム差分計算値がそれぞれ設定される。
【００２６】
【表２】
【００２７】
なお、ここでコピー数とは、コンテンツ毎に配信するクライアントの数を示す。
【００２８】
また、チェックサム差分計算値とは、受信パケットのＩＰアドレス、ＵＤＰポート番号、配信するパケットのＩＰアドレス、ＵＤＰポート番号から、チェックサム再計算時の一部の計算値であり、ＩＰヘッダチェックサムとＵＤＰチェックサムを計算するための差分計算値を持つ。
【００２９】
本実施形態においては、チェックサム差分計算値は、以下のように求める。計算に用いる変数を以下のように定義する。
【００３０】
受信パケットのIPソースアドレスSA1
受信パケットのIPデスティネーションアドレスをDA1
受信パケットのソースポート番号をSP1
受信パケットのデスティネーションポート番号をDP1
受信パケットのプロトコル識別子をPROT1
受信パケットのUDPデータグラム長をLEN1
送信パケットのIPソースアドレスSA2
送信パケットのIPデスティネーションアドレスをDA2
送信パケットのソースポート番号をSP2
送信パケットのデスティネーションポート番号をDP2
送信パケットのプロトコル識別子をPROT2
送信パケットのUDPデータグラム長をLEN2
よって、チェックサム差分情報は、受信パケットの変数の和を引いて、送信パケットの変数の和を加えればよい。よって、式（１）のようになる。
【００３１】
ＳＡ２＋ＤＡ２＋ＳＰ２＋ＤＰ２＋ＰＲＯＴ２＋ＬＥＮ２ −（ＳＡ１＋ＤＡ１＋ＳＰ１＋ＤＰ１＋ＰＲＯＴ１＋ＬＥＮ１）・・・・・・（１）
ここで、ＩＰヘッダのプロトコル識別子、ＵＤＰデータグラムのＬｅｎｇｔｈ、ＵＤＰソースポート番号は変化がないものとすると、式（１）は式（２）のように簡略化できる。
【００３２】
ＳＡ２＋ＤＡ２＋ＤＰ２−（ＳＡ１＋ＤＡ１＋ＤＰ１）・・・・・（２）
さらに、本実施形態では、ＤＡ１とＳＡ２が同じＩＰアドレスを指すため、両変数は相殺される。したがって、
ＤＡ２＋ＤＰ２−（ＳＡ１＋ ＤＰ１）・・・・・（３）
をチェックサム差分計算値として用いる。この計算結果は、表２に示した。
【００３３】
本実施形態においては、式（３）を使った例により説明したが、ストリームサーバやクライアントの条件により、ＵＤＰソースポート番号や、ＩＰアドレスをストリーム配信装置１で書き換える場合もある。その場合には、式（１）により計算することができる。
【００３４】
コピー処理部１９は、要求バッファ１６を検索し、要求が存在する場合に、当該要求を取り出す。まず、コンテンツ識別子をキーとしてコピー配信制御テーブル１８から送信デスティネーションポート番号、送信デスティネーションＩＰアドレス、コピー数、チェックサム差分計算値を引く。また、バッファ番地とバッファ長により、受信済みのパケットをパケットバッファ１３からコピー処理バッファ２０に読み出す。
【００３５】
次に、コピー処理部１９は、ＩＰヘッダチェックサム値を、ＩＰヘッダのＩＰアドレス受信値、ＩＰアドレス送信値とＩＰヘッダのチェックサム差分計算値から演算する。また、ＵＤＰチェックサム値は、ＩＰアドレスの受信値、送信値、ＵＤＰポート番号の送信値、受信値とＵＤＰチェックサム差分計算値から演算する。
【００３６】
さらに、コピー処理部１９は、ＩＰアドレス、ＵＤＰポート番号に関し、送信値を設定するとともに、計算済みのＩＰヘッダチェックサム値、ＵＤＰパケットチェックサム値を設定する。これにより、送信すべき１パケット分のＩＰヘッダおよびＵＤＰヘッダがクライアント用に設定され、当該パケットは、読出処理部２１により受信回路２２へ送られ、最終的にクライアントへ到着する。
【００３７】
コピー処理部１９は、これらの一連の処理をクライアント毎に実行し、全クライアント分の処理が完了した時点で、要求バッファ１６を確認することを繰り返す。
【００３８】
【発明の効果】
以上説明したように本発明によれば、受信パケットから送信パケットへの変換処理において、特定の処理（ヘッダ書き換え）に限定すること、さらには計算負荷が大きなチェックサム値の再計算においても、通信前に差分計算値を持っており、これと正味の変更点により演算するため、計算量を大幅に削減でき、したがって、汎用プロセッサベースの従来技術に比べ、高速化・大容量化が図れる。これにより、従来よりも多くのクライアントに対して同時にストリーム放送を提供し、さらには従来よりもより広帯域のストリーム放送をクライアントに対して提供することができる。両方の場合は、通信プロセッサはハード価格は同じで処理容量を増加し、映像品質を向上させることが可能なため、経済的でかつ高品質な映像ストリーム放送サービスを大規模に提供することが可能となる。
【図面の簡単な説明】
【図１】本発明のストリーム配信装置の接続図である。
【図２】ストリーム配信装置の構成図である。
【符号の説明】
１ ストリーム配信装置
２ ストリームサーバ
３ 受信回線
４１〜４ｎ 送信回線
５１〜５ｎ クライアント
１１ 受信回路
１２ 書込処理部
１３ パケットバッファ
１４ コピー制御部
１５ コンテンツ識別子検索テーブル
１６ 要求バッファ
１７ データ設定部
１８ コピー配信制御テーブル
１９ コピー処理部
２０ コピー処理バッファ
２１ 読出処理部
２２ 送信回路
【発明の属する技術分野】
本発明は、ストリームサーバの送信する１または複数のストリーム放送のパケットを受信し、該パケットをコピー後、１または複数のクライアントへ放送配信するストリーム配信装置に関する。
【０００２】
【従来の技術】
従来、インターネット上に設置されたストリーム配信装置としては、Ｒｅａｌ Ｎｅｔｗｏｒｋｓ社などのスプリッタ製品が代表的である。これは、汎用パソコンや汎用ワークステーションなどの汎用プロセッサ上で動作し、ストリームサーバから受信した１本のストリームデータを１または複数のクライアントに対してコピー配信するものである。
【０００３】
従来のストリーム放送の制御を行うストリーミングプロトコルでは、放送コンテンツ毎に、UDPポート番号に対応させてストリーム配信が行われていた。UDPポート番号は、クライアント、スプリッタ、サーバなどの配信機器の接続構成により、下流の機器が受信ポート番号を決定する方式となっているため、サーバ→スプリッタ→クライアントという構成でストリーム配信を行う場合は、スプリッタ側でUDPポート番号を変換する機能を持っていた。
【０００４】
【発明が解決しようとする課題】
上述した従来のスプリッタは、汎用プロセッサの通信機能をベースとした技術であった。一般的に、ストリームデータはIPパケット上にUDPパケットのペイロードにストリーム転送プロトコル（例えばIETF RFC１８８９で規定されたRTPプロトコル）を載せ、その上に音声や映像データをエンコードした符号データを載せて転送していた。したがって、汎用プロセッサのOSが提供する、IPパケットプロトコル解析機能、UDPパケットプロトコル解析機能を利用して処理されていた。
各プロトコル解析機能は、レイヤ毎に処理内容が規定されている。よって、レイヤ毎にヘッダ上のプロトコル情報を読み出し、プロトコルデータ正常性チェック処理、状態変数の遷移処理、加算／減算処理など、全ての規定処理を実行後、次のレイヤに係る処理を順次進める形で行われていた。このため、レイヤ毎にプロトコル解析処理をするためのメモリオペレーションがオーバヘッドとなり高速化処理に向いていなかった。
【０００５】
一方、ストリームパケットの転送に特化した処理を想定すると、主な処理はサーバからの受信ＵＤＰポート番号、受信ＩＰアドレスをクライアント宛の送信ＵＤＰポート番号、送信ＩＰアドレスに書き換え後、ＵＤＰパケットとＩＰヘッダのチェックサム再計算を行っていた。この場合、ＩＰアドレスやＵＤＰポート番号の読み出し、書き込み以外に他プロトコルパラメタ分析処理も併せて実行させてしまう分だけオーバヘッドが大きくなった。さらに、チェックサム計算処理は、ＵＤＰペイロードデータ全体に対して１６ビットづつメモリ読出し／演算処理を繰り返すために、長いパケットほど計算時間が長くなってしまった。しかしながら、チェックサムの再計算は、受信時点でのパケットのチェックサム計算値から、ＩＰアドレス、ＵＤＰポート番号を書き換えた部分の差分だけを計算すればよい。
【０００６】
以上述べたように、従来のストリーム配信装置は、汎用プロセッサが提供する通信機能がレイヤ毎に動作するためのオーバヘッド、処理機能が汎用化されているために必要以上の処理を実行しなければならない。このため、ストリーム配信を高速・大容量化するためには、最適な機能構成とはなっていない。
【０００７】
本発明の目的は、プロトコルレイヤ毎の処理オーバヘッド削減、チェックサムのフル計算の排除により処理を最小限とし、高速・大容量なストリーム配信装置を提供することである。
【０００８】
【課題を解決するための手段】
本発明においては、まずストリームパケットを受信すると、１つのパケットの先頭部に位置するヘッダ情報から、ストリーム配信に必要最低限なヘッダ情報をプロトコルレイヤを区別せずに抽出する。その情報からコンテンツを識別する。また、コンテンツ毎に配付先の宛先情報（配信情報）をテーブル（コピー配布表）に登録しておき、受信したパケットのヘッダ情報から、送信すべきパケットのヘッダ情報へ変換する手段を持つ。
【０００９】
すなわち、コピー配布表を参照して、送信宛先のクライアント毎に定められた配信情報を求め、該配信情報を元に受信パケットの複製とヘッダ書き換えを行い、一時退避したチェックサム値と書き換え後のヘッダ情報部分の差分を元に再計算した結果を新たなチェックサム値として送信パケットに設定し、当該クライアントへ送信する処理をコピー配布表に登録された全クライアント分の処理が終了するまで繰り返す。
【００１０】
この場合、抽出するプロトコル情報は受信パケットのＩＰアドレスおよびＵＤＰ
ポート番号、コピー配布表のデータ内容はコンテンツに対するコピー数、送信ＩＰアドレス、送信ポート番号、チェックサム差分値でもよい。
【００１１】
本発明におけるチェックサム値の計算は、受信パケットと送信パケットのヘッダ情報が既知であるため、パケット受信の都度再計算するのではなく、受信ヘッダ情報と配布すべき送信ヘッダ情報からあらかじめ計算しておく。
【００１２】
本発明によれば、まず、ストリームデータを転送するパケットのプロトコルレイヤ毎に処理を分けるのではなく、パケットの受信処理、送信処理を実行する。また、全プロトコルデータを処理するのではなく、特定のプロトコルデータに限定した処理（ヘッダ書き換え）を実行するため、１パケット当たりの処理量を削減することができる。
【００１３】
さらに、送信パケットのチェックサム値の再計算は、コピー配布表により変換すべき送り先のアドレス、ポート番号が既知であるため、事前に差分情報を計算しておき、パケット受信および送信の際に、その差分情報により残りの演算のみを実行することにより、さらに１パケット当たりの処理量を削減することができる。
【００１４】
【発明の実施の形態】
次に、本発明の実施の形態について図面を参照して説明する。
【００１５】
図１に示すように、本発明のストリーム配信装置１はストリームサーバ２から受信回線３を介してストリームコンテンツを受信し、またコピー後のストリームコンテンツを送信回線４１、４２、・・・、４ｎを介してクライアント５１、５２、・・・、５ｎに配信する。
【００１６】
この場合、受信したパケットのIPソースアドレスはストリームサーバ２、IPデスティネーションアドレスはストリーム配信装置１、送信するパケットのIPソースアドレスはストリーム配信装置１、IPデスティネーションアドレスはクライアント（５1〜５nのうちの一つ）をそれぞれ指して転送する。また、ポート番号は、デスティネーションポート番号のみをストリーム配信装置１にて付け替え、ソースポート番号はそのまま転送することとする。以上により、ストリーム配信装置１がパケットを受け渡す際には、チェックサム以外にIPソースアドレス、IPデスティネーションアドレス、デスティネーションポート番号の付け替え処理が発生する。
【００１７】
ストリーム配信装置１は、図２に示すように、受信回路１１と書込処理部１２とパケットバッファ１３とコピー制御部１４とコンテンツ識別子検索テーブル１５と要求バッファ１６とデータ設定部１７とコピー配信制御テーブル１８（コピー配布表）とコピー処理部１９とコピー処理バッファ２０と読出処理部２１と送信回路２２を有している。
【００１８】
受信回路１１は、パケットのＭＡＣレイヤ以下を終端し、パケット受信を後段の書込処理部１２へ通知する。
【００１９】
書込処理部１２は、パケット受信通知後、受信回路１１で受信したパケットをパケットバッファ１３へ転送するとともに、書き込んだバッファの先頭番地とバッファ長をコピー制御部１４へ通知する。
【００２０】
パケットバッファ１３は、受信パケットを格納しておくバッファである。
【００２１】
コピー制御部１４は、書込処理部１２から通知されたバッファ番地、バッファ長を元にパケットバッファ１３へアクセスし、当該パケットのＩＰアドレスとＵＤＰポート番号を取り出すとともに、該情報をキーとしてコンテンツ識別子検索テーブル１５にアクセスし、受信パケットの運ぶストリームのコンテンツ識別子を求める。このコンテンツ識別子とバッファ番地、バッファ長を要求バッファ１６に入力することにより、後段のコピー処理を依頼する。
【００２２】
コンテンツ識別子検索テーブル１５は、表１に示すように、受信ＵＤＰデスティネーションポート番号、受信ＩＰソースアドレス、コンテンツ識別子を構成要素に持ち、受信情報からコンテンツ識別子を割り出すために使用される。
【００２３】
【表１】
要求バッファ１６は、コピー処理要求をコンテンツ識別子、バッファ番地、バッファ長としてエントリーし、コピー処理部１９により読み出されるバッファである。
【００２５】
データ設定部１７は、配信に先立ち、表１および表２のテーブルを事前に作成、維持、管理する。コピー配信制御テーブル１８（表２）には、コンテンツ識別子、コピー数、送信デスティネーションポート番号、送信ＩＰデスティネーションアドレス、チェックサム差分計算値がそれぞれ設定される。
【００２６】
【表２】
なお、ここでコピー数とは、コンテンツ毎に配信するクライアントの数を示す。
【００２８】
また、チェックサム差分計算値とは、受信パケットのＩＰアドレス、ＵＤＰポート番号、配信するパケットのＩＰアドレス、ＵＤＰポート番号から、チェックサム再計算時の一部の計算値であり、ＩＰヘッダチェックサムとＵＤＰチェックサムを計算するための差分計算値を持つ。
【００２９】
本実施形態においては、チェックサム差分計算値は、以下のように求める。計算に用いる変数を以下のように定義する。
【００３０】
受信パケットのIPソースアドレスSA1
受信パケットのIPデスティネーションアドレスをDA1
受信パケットのソースポート番号をSP1
受信パケットのデスティネーションポート番号をDP1
受信パケットのプロトコル識別子をPROT1
受信パケットのUDPデータグラム長をLEN1
送信パケットのIPソースアドレスSA2
送信パケットのIPデスティネーションアドレスをDA2
送信パケットのソースポート番号をSP2
送信パケットのデスティネーションポート番号をDP2
送信パケットのプロトコル識別子をPROT2
送信パケットのUDPデータグラム長をLEN2
よって、チェックサム差分情報は、受信パケットの変数の和を引いて、送信パケットの変数の和を加えればよい。よって、式（１）のようになる。
【００３１】
ＳＡ２＋ＤＡ２＋ＳＰ２＋ＤＰ２＋ＰＲＯＴ２＋ＬＥＮ２ −（ＳＡ１＋ＤＡ１＋ＳＰ１＋ＤＰ１＋ＰＲＯＴ１＋ＬＥＮ１）・・・・・・（１）
ここで、ＩＰヘッダのプロトコル識別子、ＵＤＰデータグラムのＬｅｎｇｔｈ、ＵＤＰソースポート番号は変化がないものとすると、式（１）は式（２）のように簡略化できる。
【００３２】
ＳＡ２＋ＤＡ２＋ＤＰ２−（ＳＡ１＋ＤＡ１＋ＤＰ１）・・・・・（２）
さらに、本実施形態では、ＤＡ１とＳＡ２が同じＩＰアドレスを指すため、両変数は相殺される。したがって、
ＤＡ２＋ＤＰ２−（ＳＡ１＋ ＤＰ１）・・・・・（３）
をチェックサム差分計算値として用いる。この計算結果は、表２に示した。
【００３３】
本実施形態においては、式（３）を使った例により説明したが、ストリームサーバやクライアントの条件により、ＵＤＰソースポート番号や、ＩＰアドレスをストリーム配信装置１で書き換える場合もある。その場合には、式（１）により計算することができる。
【００３４】
コピー処理部１９は、要求バッファ１６を検索し、要求が存在する場合に、当該要求を取り出す。まず、コンテンツ識別子をキーとしてコピー配信制御テーブル１８から送信デスティネーションポート番号、送信デスティネーションＩＰアドレス、コピー数、チェックサム差分計算値を引く。また、バッファ番地とバッファ長により、受信済みのパケットをパケットバッファ１３からコピー処理バッファ２０に読み出す。
【００３５】
次に、コピー処理部１９は、ＩＰヘッダチェックサム値を、ＩＰヘッダのＩＰアドレス受信値、ＩＰアドレス送信値とＩＰヘッダのチェックサム差分計算値から演算する。また、ＵＤＰチェックサム値は、ＩＰアドレスの受信値、送信値、ＵＤＰポート番号の送信値、受信値とＵＤＰチェックサム差分計算値から演算する。
【００３６】
さらに、コピー処理部１９は、ＩＰアドレス、ＵＤＰポート番号に関し、送信値を設定するとともに、計算済みのＩＰヘッダチェックサム値、ＵＤＰパケットチェックサム値を設定する。これにより、送信すべき１パケット分のＩＰヘッダおよびＵＤＰヘッダがクライアント用に設定され、当該パケットは、読出処理部２１により受信回路２２へ送られ、最終的にクライアントへ到着する。
【００３７】
コピー処理部１９は、これらの一連の処理をクライアント毎に実行し、全クライアント分の処理が完了した時点で、要求バッファ１６を確認することを繰り返す。
【００３８】
【発明の効果】
以上説明したように本発明によれば、受信パケットから送信パケットへの変換処理において、特定の処理（ヘッダ書き換え）に限定すること、さらには計算負荷が大きなチェックサム値の再計算においても、通信前に差分計算値を持っており、これと正味の変更点により演算するため、計算量を大幅に削減でき、したがって、汎用プロセッサベースの従来技術に比べ、高速化・大容量化が図れる。これにより、従来よりも多くのクライアントに対して同時にストリーム放送を提供し、さらには従来よりもより広帯域のストリーム放送をクライアントに対して提供することができる。両方の場合は、通信プロセッサはハード価格は同じで処理容量を増加し、映像品質を向上させることが可能なため、経済的でかつ高品質な映像ストリーム放送サービスを大規模に提供することが可能となる。
【図面の簡単な説明】
【図１】本発明のストリーム配信装置の接続図である。
【図２】ストリーム配信装置の構成図である。
【符号の説明】
１ ストリーム配信装置
２ ストリームサーバ
３ 受信回線
４１〜４ｎ 送信回線
５１〜５ｎ クライアント
１１ 受信回路
１２ 書込処理部
１３ パケットバッファ
１４ コピー制御部
１５ コンテンツ識別子検索テーブル
１６ 要求バッファ
１７ データ設定部
１８ コピー配信制御テーブル
１９ コピー処理部
２０ コピー処理バッファ
２１ 読出処理部
２２ 送信回路
Claims (3)
- ストリームサーバの送信する１または複数のストリーム放送のパケットを受信し、該パケットをコピー後、１または複数のクライアントへ放送配信するストリーム配信装置において、
ストリーム放送の配信に先立って作成され、ストリームサーバから受信するパケットのデスティネーションポート番号とソースＩＰアドレスとコンテンツ識別子から構成されるコンテンツ識別子検索テーブルと、
受信したパケットのヘッダ情報のデスティネーションポート番号とソースＩＰアドレスから前記コンテンツ識別子検索テーブルを参照して当該パケットが運ぶコンテンツを識別する手段と、
受信したパケットヘッダのチェックサム値およびチェックサム値の計算に必要な当該ヘッダ内のプロトコルデータを一時退避させる手段と、
コンテンツ毎に配信すべきクライアント宛の配信情報を登録したコピー配布表と、
前記コピー配布表を参照して、送信宛先のクライアント毎に定められた配信情報を求め、該配信情報を元に前記受信パケットの複製と、ＩＰアドレスとポート番号の付け替えに特定したヘッダ書き換えを行い、一時退避した前記チェックサム値と書き換え後のヘッダ情報部分の差分を元に再計算した結果を新たなチェックサム値として送信パケットに設定し、当該クライアントへ送信する処理を前記コピー配布表に登録された全クライアント分の処理が終了するまで繰り返す制御手段を有することを特徴とするストリーム配信装置。 - 受信パケットのヘッダ情報と前記コピー配布表に記載された配信情報からチェックサム値の差分値を事前に計算しておき、前記制御手段は受信パケットのチェックサム値と前記差分値の演算により、送信パケットのチェックサム値を計算する、請求項１記載のストリーム配信装置。
- コンテンツ毎に配信すべきクライアントの配信情報が、コピー数、ポート番号、ＩＰアドレス、チェックサム差分値により構成される、請求項１または２記載のストリーム配信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000252288A JP3579335B2 (ja) | 2000-08-23 | 2000-08-23 | ストリーム配信装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000252288A JP3579335B2 (ja) | 2000-08-23 | 2000-08-23 | ストリーム配信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002064487A JP2002064487A (ja) | 2002-02-28 |
| JP3579335B2 true JP3579335B2 (ja) | 2004-10-20 |
Family
ID=18741552
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000252288A Expired - Lifetime JP3579335B2 (ja) | 2000-08-23 | 2000-08-23 | ストリーム配信装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3579335B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2009145294A1 (ja) * | 2008-05-30 | 2011-10-13 | 日本電気株式会社 | サーバ装置と通信方法ならびにプログラム |
| CN102047676A (zh) * | 2008-05-30 | 2011-05-04 | 日本电气株式会社 | 服务器装置和通信方法以及程序 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04288745A (ja) * | 1991-02-22 | 1992-10-13 | Mitsubishi Electric Corp | 通信装置 |
| JPH10242962A (ja) * | 1997-02-25 | 1998-09-11 | Nippon Telegr & Teleph Corp <Ntt> | インターネット上のマルチキャストゲートウェイ通信方法及びシステム |
| JPH11150566A (ja) * | 1997-11-14 | 1999-06-02 | Hitachi Ltd | インタネットワーク装置 |
| JP3656418B2 (ja) * | 1998-07-15 | 2005-06-08 | 富士ゼロックス株式会社 | ゲートウェイ装置及びマルチキャストパケット中継プログラムを記録したコンピュータ読み取り可能な記録媒体 |
-
2000
- 2000-08-23 JP JP2000252288A patent/JP3579335B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002064487A (ja) | 2002-02-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6449656B1 (en) | Storing a frame header | |
| US7447775B1 (en) | Methods and apparatus for supporting transmission of streaming data | |
| USRE45070E1 (en) | Receive processing with network protocol bypass | |
| US7433958B2 (en) | Packet relay processing apparatus | |
| US7197035B2 (en) | Packet transfer apparatus having network address translation circuit which enables high-speed address translation during packet reception processing | |
| KR100782945B1 (ko) | 네트워크에서 데이터 스트림 전송을 관리하는 방법 | |
| US20030208600A1 (en) | System and method for managing persistent connections in HTTP | |
| US7079501B2 (en) | Method and system for efficiently delivering content to multiple requesters | |
| JP2004350188A (ja) | データ転送装置及びプログラム | |
| US20220385598A1 (en) | Direct data placement | |
| JP2003124977A (ja) | チェックサムの書換装置 | |
| US7899924B2 (en) | Flexible streaming hardware | |
| CN102857547B (zh) | 分布式缓存的方法及设备 | |
| US7660906B1 (en) | Data delivery system and method | |
| JP3579335B2 (ja) | ストリーム配信装置 | |
| US8539111B2 (en) | Port switch | |
| JP3558978B2 (ja) | ストリーム配信装置および方法および記録媒体 | |
| CN101064671A (zh) | 一种基于p2p技术的网络视频信号的处理方法 | |
| EP1497741A1 (en) | Optimized digital media delivery engine | |
| US7532644B1 (en) | Method and system for associating multiple payload buffers with multidata message | |
| JP2003348126A (ja) | 通信パケット処理装置とシステムおよび方法 | |
| JP2002199015A (ja) | ネットワークデータサーバ | |
| TWI313988B (en) | Routing apparatus with offloading agent | |
| JP4063120B2 (ja) | パケット伝送装置 | |
| JP2003298648A (ja) | パケットログ記録装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040225 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040426 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040430 |
|
| 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: 20040713 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040715 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 3579335 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080723 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080723 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090723 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090723 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100723 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100723 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110723 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120723 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130723 Year of fee payment: 9 |
|
| 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 |
|
| EXPY | Cancellation because of completion of term |