パケット送信装置、パケット送信方法、およびパケット送信プログラム
【課題】 パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置に関し、バースト問題の一層の緩和を図る。
【解決手段】 受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定し、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行なう。
【解決手段】 受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定し、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行なう。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置およびパケット送信方法、並びに演算処理装置内にパケット送信装置を構築するパケット送信プログラムに関する。
【背景技術】
【０００２】
例えば動画配信等のストリーミング配信における１つの問題としていわゆるバースト問題がある。すなわち、大量のパケットが短時間に配信されることによって中継装置（スイッチ、ルータ、コンバータなど）や送信先装置のバッファ（キュー）がオーバフローする。オーバフローしたパケットは廃棄され、その結果、例えば動画配信における再生画像が乱れるなどの障害が生じる。これをバースト問題と称する。
【０００３】
従来、このバースト問題の緩和のために、トラフィックシェービングと呼ばれる手法とトラフィックポリシングと呼ばれる手法が知られている。トラフィックシェービングは送信しようとしているパケットをバッファ（キュー）に一旦溜め込んでおき、一定の時間間隔でパケットを転送する方式である。また、トラフィックポリシングは、トラフィックが一定レート以上になるとパケットを破棄する方式である。
【０００４】
ここで、トラフィックシェービングは、アンダフロー（キューに溜め込まれたパケットの枯渇）が原因で一定時間間隔での送信ができなくなることを避けるために、大量のパケットを常にキューに溜め込んでおくように実装される。このため、トラフィックシェービングでは、キューに溜め込まれた大量のパケットに相当する時間分の遅延が常に発生した状態で送信を行なうことになる。さらにこのトラフィックシェービングでは、何らかの理由で送信が一定時間行なえなかった場合、キューに溜め込まれるパケットの数がさらに増加することになる。
【０００５】
一方、トラフィックポリシングでは、パケット廃棄が発生しやすい。このトラフィックポリシングでは、パケットがまとまって大量に破棄される可能性は小さいため、大きい画像乱れにはつながりにくいが、小規模なパケット破棄による小規模な画像乱れが発生しやすい。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１８６８８２号公報
【特許文献２】特開２００７−１３４４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本件のパケット送信装置、パケット送信方法、およびパケット送信プログラムの課題は、上記のバースト問題の一層の緩和を図ることにある。
【課題を解決するための手段】
【０００８】
本件開示のパケット送信装置は、パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置であって、パケット受信部と、経過時間判定部と、待ち処理部と、パケット送信部とを有する。
【０００９】
パケット受信部は、パケットを受信する。
【００１０】
また、経過時間判定部は、経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定する。ここで、受信したパケットを送信先装置に向けて送信したときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸとする。また、その最小のキューに収容されているパケットがその最小のキューから順次取り出される時間間隔をＴ１とする。さらに経過時間ｔは、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間をいう。
【００１１】
また、待ち処理部は、経過時間判定部により、経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、上記の未送信パケットの送信を待たせる処理を行なう。
【００１２】
さらに、パケット送信部は、上記未送信パケットを、経過時間判定部により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記現時刻に送信する。また、このパケット送信部は、上記未送信パケットを、経過時間判定部により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には待ち処理部により待たされた後に送信する。
【００１３】
また、本件開示のパケット送信方法は、上記のパケット送信装置で実行される処理を方法として捉えたものである。
【００１４】
さらに、本件開示のパケット送信プログラムは、プログラムを実行する演算処理装置内で実行され、その演算処理装置内に上記のパケット送信装置を構築するプログラムである。
【発明の効果】
【００１５】
本件開示のパケット送信装置等によれば、バースト問題の一層の緩和が図られる。
【図面の簡単な説明】
【００１６】
【図１】第１実施形態のパケット送信装置の機能ブロック図である。
【図２】第２実施形態を含む全体システムを示すブロック図である。
【図３】制御表の一例を示した図である。
【図４】配信サーバ中のドライバＢにおける送信処理を示すフローチャートである。
【図５】図４に示す送信処理のうちの「キューイングおよびストリーミング配信以外のパケット送信部」のフローチャートである。
【図６】図３の送信スレッド部の処理を示すフローチャートである。
【図７】送信間隔を調整することなく送信を行なった場合の例を示す図である。
【図８】トラフィックシェービングを適用した場合の例を示す図である。
【図９】時刻Ｚｍｓの時点における制御表を示した図である。
【図１０】図４〜図６に示す送信処理の具体例を示す図である
【図１１】この第１変形例における制御表の初期状態を示す図である。
【図１２】この第１変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」の処理内容を示したフローチャートである。
【図１３】図１２におけるポート番号自動識別処理（ステップ３１）のフローチャートである。
【図１４】第２変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」の処理内容を示した図である。
【図１５】第２実施形態の第３変形例を示す図である。
【図１６】第４変形例における制御表を示した図である。
【図１７】測定プログラムの配置位置を示した図である。
【図１８】Ｘ＋１個のパケットを時間間隔０で送信した場合を示す模式図である。
【図１９】Ｘ＋２個のパケットを時間間隔０で送信した場合を示す模式図である。
【図２０】パケットを送信時間間隔Ｔ１で送信したときの様子を示す図である。
【図２１】パケットを送信時間間隔０．９９・Ｔ１で送信したときの様子を示す図である。
【図２２】ＵＤＰを使用した場合の、測定プログラムおよびパケットロストプログラムの各動作位置を示した図である。
【図２３】ＵＤＰを使用した場合の、測定プログラムおよびパケットロストプログラムの各動作位置を示した図である。
【発明を実施するための形態】
【００１７】
以下、実施形態を説明する。
【００１８】
図１は、第１実施形態のパケット送信装置の機能ブロック図である。
【００１９】
この図１において、実線の矢印は送信データ（パケット）の流れを表わし、点線の矢印は、その他のデータ（制御情報）の流れを表わしている。
【００２０】
この図１に示すパケット送信装置１０は、パケット受信部１１、待ち処理部１２、およびパケット送信部１３を有する。
【００２１】
パケット受信部１１は、パケットを受信する。
【００２２】
待ち処理部１２は、後述する条件に合致する場合には、パケット受信部１１で受信したパケットをパケット送信部１３で直ちには送信させずに、その送信を延期させる待ち処理を行なう。
【００２３】
パケット送信部１３は、待ち処理部１２から渡されたパケットを送信先装置（図示せず）に向けて送信する。
【００２４】
また、この図１に示すパケット送信装置１０は、経過時間判定部１４を有する。この経過時間判定部１４では、待ち処理部１２に待ち処理を実行させるための条件判定を行なう。その条件判定の説明にあたり、ここでは以下の通りパラメータを定義する。
【００２５】
Ｘ：受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数。送信経路の具体例については、後述の第２実施形態で説明する。
【００２６】
Ｔ１：その最小のキューに収容されているパケットがその最小のキューから順次取り出される時間間隔
ｔ：直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間
Ｘ・Ｔ１：第１の閾値時間
経過時間判定部１４は、経過時間ｔと第１の閾値時間Ｘ・Ｔ１との大小を判定する。
【００２７】
そして待ち処理部１２は、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、パケット受信部１１から受け取った未送信パケットの送信を延期させる待ち処理を行なう。
【００２８】
さらにパケット送信部１３は、その未送信パケットを、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には待ち処理部１２による待ち処理を経ることなく送信する。すなわちこの場合、パケット送信部１３は未送信パケットを待ち処理部１２から直ちに受け取って送信する。また、このパケット送信部１３は、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には、未送信パケットを、待ち処理部１２による待ち処理を経た後に送信する。
【００２９】
ここで、さらにパラメータを定義する。
【００３０】
Ｔ：パケット受信部１１におけるパケット平均受信時間間隔
Ｔ２：Ｔ１＜Ｔ２＜Ｔを満たす時間間隔。例えばＴ２＝（Ｔ１＋Ｔ）／２
待ち処理部１２は、具体的には、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を、現在時刻から（第２の閾値時間Ｘ・Ｔ２−経過時間ｔ）の待ち時間だけ待たせる待ち処理を行なう。
【００３１】
図１に示すパケット送信装置１０は、さらに、制御表記憶部１５と制御表更新部１６を有する。制御表記憶部１５は制御表１５ａを記憶する記憶部である。この制御表１５ａには、直近の送信済パケットから数えてＸ−１個前の送信済パケットまでの、その直近の送信済パケットを含むＸ個の送信済パケットの各送信時刻が記録される。また、制御表更新部１６は、パケット送信部１３による未送信パケットの送信を受けて制御表中の送信時刻を更新する。
【００３２】
上記の経過時間判定部１４は、制御表１５ａを参照することによりＸ−１個前の送信済パケットの送信時刻を求めて経過時間ｔを算出し、その経過時間ｔと第１の閾値時間Ｘ・Ｔ１との大小を判定する。
【００３３】
ここで、パケットの送信先が複数存在するときは、制御表１５ａには、各送信先ごとの各領域に、各送信先に向けて送信された送信済パケットの各送信時刻が記録される。この場合、制御表更新部１６は、制御表１５ａ中の送信時刻をパケットの送信先ごとに更新する。
【００３４】
制御表１５ａに記録される送信先は、あらかじめ分かっているときは、その分かっている送信先が初期設定として制御表１５ａに記録される。あるいは、送信先があらかじめ不明な場合、制御表更新部１６にパケットの送信先を監視させ、新たな送信先に向けて送信されるパケットを検出したときに制御表１５ａにその新たな送信先に対応する領域を追加させる構成を採用してもよい。
【００３５】
制御表１５ａの具体例については、後述の第２実施形態で説明する。
【００３６】
図１に示すパケット送信装置１０はさらに、測定部１７と再送要求受信部１８を有する。再送要求受信部１８は、パケット送信部１３から送信先装置に向けて送信したパケットの再送要求を受信する受信部である。この再送要求受信部１８で再送要求を受信すると、再送要求があったことが測定部１７に通知される。
【００３７】
測定部１７は、以下の３つの役割りを担っている。
（１）パケット平均受信時間間隔Ｔを求める平均受信時間算出部としての役割り。
（２）収容可能パケット数Ｘを求める収容可能パケット数検出部としての役割り。
（３）時間間隔Ｔ１を求めるキュー取出し時間検出部としての役割り。
【００３８】
この測定部１７は、上記（１）のパケット平均受信時間間隔Ｔを求めるにあたっては、以下の処理を行なう。すなわち、この測定部１７は、パケット受信部１１において順次受信する複数のパケットの受信間隔の平均値を算出する。この算出された平均値が上記の平均受信時間間隔Ｔである。
【００３９】
また、測定部１７は、上記（２）の収容可能パケット数Ｘを求めるにあったては、以下の処理を行なう。すなわち、測定部１７は、パケット送信部１３に、複数個のパケットを送信先装置に向けてほぼ同時に送信する過程を、ほぼ同時に送信するパケットの個数を順次変更しながら繰り返させ、再送要求の発生を免れる最大パケット数を検出する。この再送要求の発生を免れる最大パケット数が送信先装置に向けてパケットを送信したときの送信経路上に存在するキューのうちの最小のキーの収容可能なパケット数Ｘである。
【００４０】
さらに、測定部１７は、上記（３）の時間間隔Ｔ１を求めるにあたっては、以下の処理を行なう。すなわち測定部１７は、パケット送信部１３に、複数個のパケットを所定の時間間隔で送信する過程を、パケットの個数および所定の時間間隔を変更しながら繰り返させて、パケットの個数を増やしても再送要求が検出されない最短の時間間隔を検出する。この最短の時間間隔が、上記の時間間隔Ｔ１である。
【００４１】
尚、この図１に示す第１実施形態では、測定部１７を備えてパケット平均受信時間間隔Ｔ、収容可能パケット数Ｘ、および時間間隔Ｔ１を求めているが、それらがあらかじめ分かっているシステムの場合は、この測定部１７は不要である。
【００４２】
測定部１７で求められた各値Ｔ、Ｘ、Ｔ１は、待ち処理部１２および経過時間判定部１４での上述の各処理や、制御表記憶部１５に記憶されている制御表１５ａに記録される送信時刻の数の指標として用いられる（制御表１５ａについては後述の第２実施形態を参照）。
【００４３】
ここでは、パケット送信装置１０について説明したが、このパケット送信装置１０で行われる処理をパケット送信方法として捉えることもできる。また、この図１のパケット送信装置１０を、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が搭載された演算処理装置内で実行されたときに、その演算処理装置内にパケット送信装置を構築するパケット送信プログラムとして捉えることもできる。
【００４４】
以上で第１実施形態の説明を終了し、次に第２実施形態を説明する。
【００４５】
図２は、本件の第２実施形態を含む全体システムを示すブロック図である。
【００４６】
ここでは、パケットは、コンテンツ２０（ここでは動画コンテンツとする）からエンコーダ２１に取り込まれ、そのエンコーダ２１から配信サーバ３０が受信するものとする。ここで、エンコーダ２１は、例えば多数のコンテンツを蓄積しておき、要求に応じたコンテンツを表わすパケットを要求先に向けてストリーム配信するコンテンツストレージ装置等を代表させて示したものである。
【００４７】
配信サーバ３０に到着したパケットは、アダプタＡで受信され、ドライバＡが受け取ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃａｌ）に渡され、さらにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃａｌ）に受け渡される。ここで、後述する態様によってはＴＣＰに代わりＵＤＰ（Ｕｓｅr Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を採用した場合に言及する。基本的にはＴＣＰとして説明する。
【００４８】
ＴＣＰは、ユニキャストの送信を行なうプロトコルである。したがって、１つのポート番号は１個の送信先装置に対応している。またＴＣＰでは、送信経路上でパケットロストがあるとパケットの再送処理が行なわれる。
【００４９】
一方ＵＤＰでは多くの場合マルチキャストでの送信が行なわれており、その場合１つのポート番号が複数の送信先装置に対応している。またＵＤＰではそのままでは再送処理は行われない。したがって送信元では、パケットロストを検出するとその結果を送り返すパケットロスト検出プログラムを送信先側に導入して初めてパケットロストがあったことを知ることができる。
【００５０】
配信サーバ３０のＴＣＰに受け渡されたパケットは、さらにアプリケーションプログラムを経由して今度は逆順を辿り、ＴＣＰ、ＩＰと進み、次にはドライバＢ、アダプタＢと進んで、配信サーバ３０から送信先装置（ここではクライアント端末５０＿１，５０＿２，・・・，５０＿ｎ．・・・のうちのいずれか）に向けて送信される。
【００５１】
配信サーバ３０から送信されたパケットは中継器Ａ４１，インターネット４２（または専用線でもよい）、およびいずれかの中継器Ｂ４３＿１，４３＿２，・・・を経由して、いずれかのクライアント端末５０＿１，５０＿２，・・・，５０＿ｎ，・・・で受信される。受信されたパケットはそのクライアント端末に接続された映像装置５１＿１，５１＿２，・・・，５１＿ｎ−１，５１＿ｎ，・・・により映像として可視化される。
【００５２】
ここで、配信サーバ３０は、図示しないＣＰＵやメモリ等、演算処理を行なうハードウェアを有する。
【００５３】
図２に示したドライバＡ、ＩＰ、ＴＣＰ（またはＵＤＰ）、およびアプリケーションは、そのハードウェア上で実行されるソフトウェアを表わしている。ここでは、説明の簡素化のため、それらのソフトウェアがＣＰＵで実行されることにより実現する機能を、ソフトウェア自体と区別せずに説明する。
【００５４】
以下では、本件の機能をドライバＢで実現した例について先ず説明し、その後、実現形態の異なる各種の例について説明する。
【００５５】
尚、以下の説明においても、Ｘ，Ｔ，Ｔ１，Ｔ２，ｔの各パラメータは前述の第１実施形態で説明した通りのものとする。Ｘ，Ｔ，Ｔ１は、ユーザがあらかじめ知っていてドライバＢのコンフィギュレーションプロパティ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｐｅｒｔｉｅｓ）などで指定したものが用いられる。あるいは後述する方法により求められ、ユーザあるいはアプリケーションにより指定されたものが用いられる。
【００５６】
図３は、制御表の一例を示した図である。
【００５７】
ここでは、送信先ポート番号や各種パラメータはユーザが既に知っていて、ドライバＢのプロパティ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｐｅｒｔｉｅｓ）などで指定されるものとする。あるいはアプリケーションが知っていてそのアプリケーションがドライバＢに指定するものであってもよい。
【００５８】
この図３に示す制御表中の「送信先ポート番号」は、上記の通りユーザ又はアプリケーションにより指定されたものである。この制御表は送信先ポート番号ごとに横一行の領域が設けられており、各送信先ポート番号ごとに以下に説明する値が記録される。また、ここでは、ドライバＢが、パケットを一時的に格納しておくキューを各送信先ポート番号ごとにメモリ（図示せず）上に作成するものとし、「キューのベースアドレス」には、そのメモリ上に作成されたキューの所在をあらわすアドレスが記録される。
【００５９】
また、「Ｘ−１個前のパケット番号」は、直近の送信済のパケットから数えてＸ−１個前の送信要済パケットのパケット番号である。ここでは、このパケット番号は０〜Ｘ−１で指定され、パケットを１つ送信するたびに０→１→・・・→Ｘ−１の順にインクリメントされ、（Ｘ−１）に達したら次は（０）に戻される。これら０，１，・・・，Ｘ−１は、この制御表内の時刻（０），時刻（１），・・・，時刻（Ｘ−１）にそれぞれ対応している。図３では、初期値として全て０が記録されている。
【００６０】
「直近のパケット番号」は、直近の送信済のパケットの番号である。この「直近パケット番号」についてもパケットを１つ送信するたびに０→１→・・・→Ｘ−１→０→・・・の順に循環的に更新される。図３には初期値として全てＸ−１が記録されている。
【００６１】
「時刻（０）」，「時刻（１）」，・・・，「時刻（Ｘ−１）」は、それぞれ、パケット番号０，１，・・・，Ｘ−１の送信済パケットの各送信時刻である。図３では初期値として全てＳが記録されている。この初期値Ｓは、パケット送受信を開始する時刻よりも時間的に十分に辿った時刻である。例えば図２の配信サーバ３０が起動した時刻を０としたとき、起動後数分はパケット送受信を開始しないであれば、Ｓ＝０でよい。
【００６２】
未送信のパケットを１個送信すると、「直近のパケット番号」に記録されているパケット番号に対応する時刻（直近のパケット番号）に現在時刻が記録され、「Ｘ−１個前のパケット番号」および「直近のパケット番号」に１が加えられる。ただし、１を加えた結果Ｘ−１がＸに値が変ったときは、そのパケット番号は０に戻される。
【００６３】
尚ここでは、収容可能なパケット数が最小のキューは、図２の中継器Ｂ４３＿１，４３＿２，・・・に存在し、かつ各中継器Ｂ４３＿１，４３＿２，・・・のキューの収容可能なパケット数は、いずれの中継器Ｂ４３＿１，４３＿２，・・・も同一の数Ｘであるとしている。
【００６４】
図４は、配信サーバ中のドライバＢにおける送信処理を示すフローチャートである。
【００６５】
ドライバＢではＩＰからの関数コールによりこの図４に示す送信処理が実行される。
【００６６】
この送信処理は、「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）と「送信スレッド部」（ステップＳ０２）とから成り立っている。
【００６７】
図５は、図４に示す送信処理のうちの「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）のフローチャートである。
【００６８】
この図５、およびそれ以降の図において「ＴＣＰ／ＵＤＰ」は、そのシステムでストリーム配信にＴＣＰが使用されていればＴＣＰを、ＵＤＰが使用されていればＵＤＰを意味するものとする。
【００６９】
ここでは先ず、今回送信しょうとしているパケットがここで対象としているＴＣＰ／ＵＤＰパケットであり、かつポート番号が制御表（図３参照）に含まれるポート番号であるか否かが判定される（ステップＳ１１）。
【００７０】
このステップＳ１１の条件を満たすパケットの場合は、そのパケットが送信待ちのパケットを並べておくキューに登録され（ステップＳ１２）、送信スレッドが起動していなければ送信スレッドが起動される（ステップＳ１３）。この送信スレッドは、図４に示す送信スレッド部（ステップＳ０２）の処理を行なうプログラムである。送信スレッド部（ステップＳ０２）の処理については後述する。
【００７１】
ステップＳ１１の条件を満足しない場合、すなわち、送信しようとするパケットがここでの制御対象としているＴＣＰ／ＵＤＰパケット以外のパケットである場合、および、ＴＣＰ／ＵＤＰパケットではあっても制御表に制御対象として登録されているポート番号以外のポート番号のパケットであった場合は、ステップＳ１４に進み、ここではそのまま、従来と同様のパケット送信処理が行なわれる。
【００７２】
以上の処理が、今回送信しようとしている全てのパケットについて繰り返される（ステップＳ１５）。
【００７３】
図６は、図４の送信スレッド部（ステップＳ０２）の処理を示すフローチャートである。
【００７４】
ここでは、初期には送信スレッドがスリープ状態にあるものとする。（ステップＳ２１）。
【００７５】
図５のステップＳ１５で起動をかけられると送信スレッドが動作を開始し、ステップＳ２２以下の処理が行われる。
【００７６】
ここでは先ずキューからパケットが１個取出される（ステップＳ２２）。次いで直近の送信済パケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの経過時間ｔが算出される（ステップＳ２２）。この経過時間ｔは、図３に示す制御表が参照され、
ｔ＝現在の時刻−時刻（Ｘ−１個前のパケット番号）
により算出される。
【００７７】
次に、この算出された経過時間ｔと、第１の閾値時間Ｘ・Ｔ１とが比較される（ステップＳ２４）。ｔ≦Ｘ・Ｔ１のときは待ちが必要と判断され、（Ｘ・Ｔ２−ｔ）の時間待つ（ステップＳ２５）。ｔ＞Ｘ・Ｔ１のときは、待ちは不要と判断され、ステップＳ２５はスキップされる。
【００７８】
次に、制御表（図３参照）の、時刻（直近のパケット番号）に送信時の現在時刻が記録され（ステップＳ２６）、それに続き、パケット送信処理が行われる（ステップＳ２７）。
【００７９】
さらに、制御表の、Ｘ−１個前のパケット番号、および直近のパケット番号に１が加えられる（ステップＳ２８）。１を加えた結果Ｘ−１よりも大きな値となったときは０に戻される。
【００８０】
ステップＳ２９では、キューに未送信のパケットが残ってるか否かが判定され、残っているときはステップＳ２２に戻り、残りの未送信パケットのうちの１個のパケットが取出されて、上記と同様の処理が繰り返される。
【００８１】
一方、ステップＳ２９において、キューに未送信パケットが残っていないと判定されたときはステップＳ２１に戻り、この送信スレッドはスリープ状態に戻る。
【００８２】
この図６に示す処理によれば、連続するＸ個のパケットの先頭から末尾までの間隔はＸ・Ｔ１より大きくなるため、このままのパケット間隔で中継器Ｂに到達すれば中継器Ｂのキューがオーバフローすることはない。
【００８３】
ここで、連続するＸ個のパケットの先頭から末尾までの間隔がＸ・Ｔ１より大きい場合、任意の１個のパケットが中継器Ｂに到達したときに中継器Ｂのキューに最低限１個の空きがあることを説明する。その１個のパケットよりもＸ−１個前のパケットは、少なくともＸ・Ｔ１の間隔が開いている。このため仮にＸ−１個前のパケットが中継器Ｂに到着したときにそのＸ−１個前のパケットが中継器Ｂのキューの末尾に登録されたとしても、今回のパケットが中継器Ｂに到着したときには、そのＸ−１個前のパケットはその中継器Ｂのキューの外に取り出されている。したがって任意の１個のパケットが中継器Ｂに到着したときには、中継器Ｂのキューに最低１個の空きが存在する。したがって、図６に示す処理によれば、中継器Ｂのキューでのオーバフローを避けることができる。
【００８４】
ここで図４〜図６に示す送信処理によるパケット送信例を比較例とともに具体的に説明する。
【００８５】
図７は、送信間隔を調整することなく送信を行なった場合の例を示す図である。この図７は本件に対する比較例に相当する。ここでは、この図７に示す比較例を第１比較例と称する。
【００８６】
この図７および後述する図８、図１０並びにそれらの図の説明で用いている記号は、以下の通り定義されるものとする。
【００８７】
Ｔ、Ｘ、Ｔ１、Ｔ２、ｔの意味は、第１実施形態の説明の通りとする。
【００８８】
ｍｓはミリ秒を表す。ここでは、Ｔ＝１０ｍｓ、中継器Ｂのキューが最小であってＸ＝８個、Ｔ１＝４ｍｓ、Ｔ２＝６ｍｓの場合を考える。
【００８９】
Ｑ１は、配信サーバ３０のＩＰのキューである。そのＱ１の欄に記載されている「なし」、「１」、「２」等は、そのＱ１に並んでいるパケットの数を表わしている。
【００９０】
Ｑ２は、配信サーバ中のドライバＢのキューである。そのＱ２の欄に記載されている、「なし」、「１００」（図８参照）等は、そのＱ２に並んでいるパケットの数を表している。ただし、このパケットの数は、Ｑ２から取り出された直後の、未送信のパケットを含んでいる。
【００９１】
時刻Ｚ＋１０−０ｍｓ、Ｚ＋２０−０ｍｓ（図７参照）等の−０ｍｓは、時刻Ｚ＋１０ｍｓ、Ｚ＋２０ｍｓ等よりもわずかに前の時刻であることを意味している。
【００９２】
また、時刻Ｚ＋１０＋０ｍｓ、Ｚ＋２０＋０ｍｓ（図８参照）等の＋０ｍｓは、時刻Ｚ＋１０ｍｓ、Ｚ＋２０ｍｓよりもわずかに後の時刻を意味している。
【００９３】
またここで登場するパケットは、送信先ポート番号がすべて同一（ここでは送信先ポート番号２８００１）であるとする。
【００９４】
時刻Ｚｍｓは、既に何パケットか送信された後の状態にある時刻である。
この時刻Ｚｍｓ以前は、パケットは１０ｍｓの等間隔で受信され、Ｑ１、Ｑ２を通過し、さらに、配信サーバ３０の外にもそのまま１０ｍｓの等間隔で送信されたものとする。時刻Ｚｍｓ以降も、Ｑ１には１０ｍｓの等間隔でパケット届いているものとする、尚パケットがＱ１に到着する時刻は、Ｚ＋１０−０ｍｓ、Ｚ＋２０−０ｍｓ等、Ｚ＋１０ｍｓ、Ｚ＋２０ｍｓ等よりもわずかに前の時刻であるとする。
【００９５】
そして、時刻Ｚ〜Ｚ＋１０ｍｓの間のどこか（例えば時刻Ｚ＋５ｍｓ）から時刻Ｚ＋１００−０ｍｓまでの間、ＣＰＵでは、パケットの送信とは無関係の、それよりも優先順位の高い何らかのソフトウェアが動作したために、ドライバＢでの送信処理にはＣＰＵが割り当てられず、送信処理が中断した状態にあったものと仮定する。
【００９６】
この場合、送信間隔を調整することなく送信を行なうと、図７に示す通りとなる。
【００９７】
すなわち、図７に示すように、時刻Ｚ＋１０−０ｍｓ〜時刻Ｚ＋１００−０ｍｓの間に到達したパケットは、送信処理が中断しているためＱ１に格納されたままとなる。時刻Ｚ＋１００−０ｍｓにＣＰＵに送信処理が割り当てられたことにより、時刻Ｚ＋１００＋０ｍｓには、Ｑ１に格納された１０個のパケットがほぼ同時に配信サーバ３０の外に送信される。
【００９８】
この場合、最小のキューを持つ中継器Ｂ（Ｘ＝８個）で１０−８＝２個のパケットが廃棄される結果となる。
【００９９】
図８は、トラフィックシェービングを適用した場合の例を示す図である。ここでも図７の場合と同じ条件が適用されている。
【０１００】
トラフィックシェービングは、前述のとおり、パケットをキューに一旦溜め込んでおき、等間隔の時間でパケットを送信する方式である。この図８に示す例では、Ｑ２に１００個のパケットが溜め込まれ、そのパケットが１０ｍｓ間隔で送信されている。また、同じ１０ｍｓ間隔で新たなパケットが到着している。
【０１０１】
この場合、図８に示すように、時刻Ｚ＋１０−０ｍｓ〜時刻Ｚ＋１００−０ｍｓの間に到達したパケットは、送信処理が中断しているためＱ１に格納されたままとなる。また送信処理が中断したため、Ｑ２に溜まっているパケットも溜まったままとなり、配信サーバ３０から外への送信も中断する。時刻Ｚ＋１００−０ｍｓに送信処理が再開されると、直後の時刻Ｚ＋１００＋０ｍｓに、時刻Ｚ＋１００−０ｍｓにＱ１に到着したパケットを含む、それまでＱ１に溜まっていた１０個のパケットがＱ２に移る。送信処理が再開されたことに伴い、その時刻Ｚ＋１００＋０ｍｓには、Ｑ２からパケットが１個取り出されて配信サーバ外に送信され、その後もＱ２からは１０ｍｓ間隔でパケットが取り出されて送信される。
【０１０２】
この場合、配信サーバ３０から送信された後の送信経路上ではパケットの廃棄は生じないが、パケット配信が中断したことによる映像の乱れが生じる可能性がある。またＱ２には、中断以前のパケット数よりも多い数のパケットが蓄えられ、その分、送信が全体としてさらに遅れることになる。
【０１０３】
次に図４〜図６に示す送信処理の具体例を説明する。
【０１０４】
図９は、時刻Ｚｍｓの時点における制御表を示した図である。ただしここでは、送信先ポート番号２８００１についてのみ示してある。
【０１０５】
また図１０は、図４〜図６に示す送信処理の具体例を示す図である。ここでも図７の場合と同じ条件が適用されている。
【０１０６】
時刻Ｚ−０ｍｓにＩＰに到達したパケットはドライバＢに直ちに転送される。ドライバＢでは、図４に示す「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）、すなわち図５のフローチャートが実行され、図５のステップＳ１１→ステップＳ１２と進んでドライバＢのキューＱ２に登録される。さらにステップＳ１５に進んで送信スレッドが起動される。
【０１０７】
すると、今度は、図６のステップＳ２１→ステップＳ２２→ステップＳ２３と進む。すなわち、ドライバＢの送信スレッドがスリープ状態から起動し（ステップ２１）、Ｑ２からパケットが取り出され（ステップＳ２２）、経過時間ｔが
ｔ＝現在の時刻−時刻（７個前のパケット番号）
＝Ｚｍｓ−時刻（１）の時刻
＝Ｚｍｓ−（Ｚ−７０ｍｓ）
＝７０ｍｓ
と、算出される（ステップＳ２３）。
【０１０８】
ここで、第１の閾値時間Ｘ・Ｔ１は、
Ｘ・Ｔ１＝８×４＝３２ｍｓ
であるので、
ｔ＝７０ｍｓ＞Ｘ・Ｔ１＝３２ｍｓ
であり、ステップＳ２４では「偽」（待ち不要）と判定される。すなわち、ここでは、ステップ２５の待ち処理は行われずに、制御表の、時刻（直近のパケット番号）＝時刻（０）に現在の時刻が記録されて（ステップＳ２６）Ｑ２から取り出したパケットが直ちに送信される（ステップＳ２７）。そして、制御表の、７個前のパケット番号、および直近のパケット番号に１が加えられて、それぞれ２、１となる（ステップＳ２８）。
【０１０９】
時刻Ｚ〜Ｚ＋１０ｍｓの間のどこか（例えば時刻Ｚ＋５ｍｓ）から時刻Ｚ＋１００−０ｍｓまでの間はドライバＢにはＣＰＵが割り当てられていなかったためパケットの送信処理が中断している。そのため、時刻Ｚ＋１００−０ｍｓの時点では、ＩＰのキューＱ１に１０個のパケットが溜まった状態となる。
【０１１０】
時刻Ｚ＋１０＋０ｍｓ時点では、ドライバＢにＣＰＵが再び割り当てられて送信処理が再開したため、ＩＰのキューＱ１に溜まっていた１０個のパケットがドライバＢに転送され、図４〜図６に示す送信処理が再開される。
【０１１１】
これら１０個のパケット全てについて図５のステップＳ１１の判定結果は「含まれる」であり、それら１０個のパケット全てがドライバＢのキューＱ２に登録され（ステップＳ１２）、ドライバＢの送信スレッドが起動される（ステップＳ１５）。
【０１１２】
図６のステップＳ２３で算出される経過時間ｔは、Ｑ２に登録された１０個のパケットのうちの１〜７個目のパケットに関し、
パケット番号１：ｔ＝Ｚ＋１００ｍｓ−時刻（２）＝Ｚ＋１００−（Ｚ−６０）＝１６０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号２：ｔ＝Ｚ＋１００ｍｓ−時刻（３）＝Ｚ＋１００−（Ｚ−５０）＝１５０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号３：ｔ＝Ｚ＋１００ｍｓ−時刻（４）＝Ｚ＋１００−（Ｚ−４０）＝１４０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号４：ｔ＝Ｚ＋１００ｍｓ−時刻（５）＝Ｚ＋１００−（Ｚ−３０）＝１３０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号５：ｔ＝Ｚ＋１００ｍｓ−時刻（６）＝Ｚ＋１００−（Ｚ−２０）＝１２０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号６：ｔ＝Ｚ＋１００ｍｓ−時刻（７）＝Ｘ＋１００−（Ｚ−１０）＝１１０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号７：ｔ＝Ｚ＋１００ｍｓ−時刻（０）＝Ｚ＋１００−Ｚ＝１００ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるためステップＳ２５における待ち処理はスキップされる。
【０１１３】
８個目のパケットについては、
パケット番号０：ｔ＝Ｚ＋１００ｍｓ−時刻（１）＝Ｚ＋１００−（Ｚ＋１００）＝０ｍｓ＜３２ｍｓ＝Ｘ・Ｔ１
であるため、
Ｘ・Ｔ２−ｔ＝８×６−０＝４８ｍｓ
の待ちが挿入される。
【０１１４】
この待ちを行なっている４８ｍｓの間の各時刻Ｚ＋１１０、Ｚ＋１２０、Ｚ＋１３０、Ｚ＋１４０ｍｓに、それぞれ１個づつ（合計４個）のパケットがドライバＢに到着し、それらのパケットは、図５の処理によりドライバＢのキューＱ２に登録される。
【０１１５】
時刻Ｚ＋１４８ｍｓに達した時点で、先ずは８個目のパケット（パケット番号０）が送信され、９個目、１０個目のパケット（パケット番号１，２）も、
パケット番号１：ｔ＝Ｚ＋１４８ｍｓ−時刻（２）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号２：ｔ＝Ｚ＋１４８ｍｓ−時刻（３）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため直ちに送信される。
【０１１６】
さらに、時刻Ｚ＋１００ｍｓ〜Ｚ＋１４８ｍｓの間に到着した４個のパケット（パケット番号３、４、５、６）についても、
パケット番号３：ｔ＝Ｚ＋１４８ｍｓ−時刻（４）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号４：ｔ＝Ｚ＋１４８ｍｓ−時刻（５）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号５：ｔ＝Ｚ＋１４８ｍｓ−時刻（６）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号６：ｔ＝Ｚ＋１４８ｍｓ−時刻（７）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため、時刻Ｚ＋１４８ｍｓの時点で直ちに送信される。
【０１１７】
時刻１５０ｍｓに到着したパケット（パケット番号７）は、
パケット番号７：ｔ＝Ｚ＋１５０ｍｓ−時刻（８）＝Ｚ＋１５０−（Ｚ＋１４８）＝２ｍｓ＜３２ｍｓ＝Ｘ・Ｔ１
であるため、
Ｘ・Ｔ２−ｔ＝８・６−２＝４６ｍｓ
の待ちが挿入される。ここで求めた４６ｍｓは時刻Ｚ＋１５０ｍｓからの間隔であるため、時刻Ｚ＋１４８ｍｓからの間隔は４８ｍｓとなる。つまり、Ｚ＋１５０ｍｓ＋４６ｍｓ＝Ｚ＋１９６ｍｓまでは送信を待つことになる。
【０１１８】
この待ちをしている間、時刻Ｚ＋１６０，Ｚ＋１７０，Ｚ＋１８０，Ｚ＋１９０ｍｓに各々１個のパケットがドライバＢに到着するが、Ｚ＋１５０ｍｓに到着したパケットが未送信であるため、ドライバのキュー（Ｑ２）でそのまま待つことになる。
【０１１９】
時刻１９６ｍｓに達したとき、まず１５０ｍｓの時点でに到着していたパケット（パケット番号６）が送信され、各時刻Ｚ＋１６０，Ｚ＋１７０，Ｚ＋１８０，Ｚ＋１９０ｍｓに到着していたパケットについても、
パケット番号０：ｔ＝Ｚ＋１９６ｍｓ−時刻（１）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞ ２ｍｓ＝Ｘ・Ｔ１
パケット番号１：ｔ＝Ｚ＋１９６ｍｓ−時刻（２）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号２：ｔ＝Ｚ＋１９６ｍｓ−時刻（３）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号３：ｔ＝Ｚ＋１９６ｍｓ−時刻（４）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため、直ちに送信される。
【０１２０】
時刻２００ｍｓに達したとき、パケットがドライバＢに１個到着するが、そのパケットは、
パケット番号４：ｔ＝Ｚ＋２００ｍｓ−時刻（５）＝Ｚ＋２００−（Ｚ＋１４８）＝５２ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため、直ちに送信される。
【０１２１】
これ以降、時刻Ｚ＋２１０ｍｓ，Ｚ＋２２０ｍｓ，Ｚ＋２３０ｍｓ…と１０ｍｓおきに到着するパケットについても、
ｔの値（現在時刻と７個前のパケットの送信時刻の差）が３２ｍｓより小さくなることはないため、いずれも直ちに送信される。
【０１２２】
この図１０に示すように、本実施形態によれば、パケットを配信サーバ内に大量に溜め込むことが避けられ、かつ配信サーバから外に送信されたパケットの廃棄も回避される。
【０１２３】
次に第２実施形態の各種変形例を説明する。
【０１２４】
上記の第２実施形態では、送信先ポート番号はユーザが既に知っているか又はアプリケーションが知っていることを前提としている。これに対し、以下の第１変形例では、ドライバがストリーミング配信用パケットを識別し、そのパケット自体からポート番号を自動認識する例である。ポート番号自動認識処理を行なう場合はユーザあるいはアプリケーションはストリーミング配信用パケットを識別するための条件を、ドライバＢにコンフィギュレーションプロパティ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｒｏｐｅｒｔｉｅｓ）などで通知しておく構成としてもよい。通知しておけば、その条件に合致したパケットが本件における処理の対象となる。特に通知がない場合は、ＴＣＰ／ＵＤＰであるか、それ以外のパケットであるかという点のみを判定し、ＴＣＰがストリーミング配信に使用されている場合はＴＣＰパケット全てが、ＵＤＰならばＵＤＰパケット全てが処理の対象となる。
【０１２５】
図１１は、この第１変形例における制御表の初期状態を示す図である。
【０１２６】
この第１変形例では、ドライバＢの起動時に、図１１に示すような制御表のフォーマットのみの制御表が作成される。送信ポート番号はドライバＢの動作開始後に自動認識されて各送信ポート番号ごとの領域が作成され、図３と同形式の制御表が形成される。
【０１２７】
この第１変形例においても、図４に示す送信処理が行われる。ただし、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）のアルゴリズムは前述の第２実施形態のアルゴリズム（図５参照）とは異なっている。
【０１２８】
図１２は、この第１変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）の処理内容を示したフローチャートである。
【０１２９】
この図１２における、各ステップＳ１１〜ステップ１５は、前述の第２実施形態においては図５の各ステップＳ１１〜ステップＳ１５とそれぞれ同一の処理内容であり、ここでの重複説明は省略する。
【０１３０】
ステップＳ３１ではポート番号自動認識処理が行われる。次いで、制御表にポート番号が追加されたか否かが判定され（ステップＳ３２）、ポート番号が追加されたときはステップＳ１２に進み、追加されなかったときはステップ１３に進む。
【０１３１】
図１３は、図１２におけるポート番号自動識別処理（ステップ３１）のフローチャートである。
【０１３２】
ここでは先ず、判定対象のパケットがストリーミング配信用パケットの条件に合致するか否かが判定される（ステップＳ３１１）。合致するときは、ステップＳ３１２に進み、制御表にそのパケットのポート番号の行が追加され、かつメモリ（図示せず）上にそのポート番号用のキューが１個生成される。さらに、そのキューのベースアドレスが制御表に追加され、Ｘ−１個前のパケット番号＝０、直近のパケット番号＝Ｘ−１、時刻（０）〜時刻（Ｘ−１）＝Ｓで初期化される（図３参照）。時刻Ｓは、図３での説明と同じく、送信開始よりも十分に辿った時刻である。
【０１３３】
図１３のステップＳ３１１で、ストリーミング配信用パケットの条件に合致しないと判定されると、制御表に追加することなくこのポート番号自動認識処理を通過する。
【０１３４】
この第１変形例によれば、ストリーミング配信用のパケットの送信先ポート番号が自動認識される。
【０１３５】
図１４は、第２変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）の処理内容を示した図である。
【０１３６】
この図１４におけるステップＳ１１〜ステップＳ１５も、図１２の場合と同様、図５におけるステップＳ１１〜ステップＳ１５とそれぞれ同一であり、重複説明は省略する。
【０１３７】
ステップＳ４１では、
ｔ＝現在の時刻−時刻（Ｘ−１個前のパケット番号）
が計算される。
【０１３８】
ステップＳ４２ではキューに既にパケットが存在するか否か、およびｔ≦Ｘ・Ｔ１を満足するか否かが判定される。キューに既にパケットが存在するときは、今回のパケットもキューに登録される（ステップＳ１２）、また、キューは空であってもｔ≦Ｘ・Ｔ１を満足するときは、この場合もステップＳ１２に進み、今回のパケットがキューに登録される。
【０１３９】
パケットが空であって、かつｔ＞Ｘ・Ｔ１のときは、待ち処理は不要であり、この第２変形例では今回のパケットをキューに登録することなく、パケット送信のための処理が行われる。すなわち、この場合、制御表の、時刻（直近のパケット番号）に現在時刻が記録され（ステップＳ４３）、パケット送信処理が行われ（ステップＳ４４）、さらに、制御表のＸ−１個前のパケット番号、および直近のパケット暗号にそれぞれ１が加えられる（ステップＳ４５）。１を加えた結果、Ｘ−１を超えた場合は、０に戻される。
【０１４０】
前述の第２実施形態の場合、送信待ちをせず直ちに送信可能な状態にあっても一旦はキューに登録する処理が行われ（図５のステップＳ１２参照）、その後、送信スレッドを経由して送信が行われる。このようにキューへの登録や送信スレッドを経由させると僅かではあっても遅れが発生することになる。この第２変形例の場合、待ちが必要な場合だけキューに登録し、待ちが不要な場合はキューに登録せずにそのまま送信される。このため第２変形例によれば、キューに登録することにより発生する遅延を防止することができる。
【０１４１】
上記の第２実施形態、第１変形例および第２変形例は、図２に示すシステムにおける配信サーバ３０のドライバで実施することを前提にしたものである。ただし本件の実施形態は、図２に示すシステムを考えた場合であっても、配信サーバ３０のドライバのみで実現可能なものではなく、他の要素上でも実現可能である。以下にその例を説明する。
【０１４２】
図１５は、第２実施形態の第３変形例を示す図である。
【０１４３】
この図１５において、実線の矢印は処理の流れを表わし、点線の矢印はデータの参照または書き込みを表わしている。
【０１４４】
この図１５に示す第３変形例は、前述の第２実施形態と同等の処理を図２の配信サーバ３０のアダプタＢで実施する例である。
【０１４５】
ここでも制御表６５が作成される。制御表については説明済みであり、ここでの重複説明は省略する。ドライバＢで実施する場合は、制御表は配信サーバ３０のメインメモリ上に作成されるが、アダプタで実施する場合は、制御表はアダプタ内のメモリに作成される。
【０１４６】
上記の第２実施形態においてユーザまたはアプリケーションからドライバに通知されていた情報（ポート番号、パラメータＸ、Ｔ、Ｔ１などの値）は、この第３変形例（アダプタでの実施）においては、ドライバに通知された後ドライバからさらにアダプタに通知される。このアダプタで実施する場合も、上述の第１変形例と同様、ポート番号自動認識処理を行なうことも可能である。
【０１４７】
アダプタＢは、送信用パケットをドライバＢから受け取り、中継器Ａ４１（図２参照）に向けて送信する。
【０１４８】
アダプタＢは、ドライバＢからパケットを受け取ると、先ずポート番号自動判定部６１において、今回受け取ったパケットが制御表６５に登録されているポート番号のパケットであるか否かが判定される。制御表６５には登録されていないポート番号のパケットであったときは、ここでの制御対象外のパケットであるので、キューイング部６２および待ち挿入部６３を何もせずに通過し、送信処理部６４によりそのまま送信される。このポート番号自動判定部６１における処理は前述の第２実施形態として説明した図５のステップＳ１１に相当する。また、制御表６５に登録されてないポート番号のパケットの送信処理は図５のステップＳ１３に相当する。
【０１４９】
ポート番号自動判定部６１で制御表６５に登録されているポート番号のパケットであると判定されると、そのパケットはキューイング部６２により、キュー６６に登録される（図５のステップＳ１２に相当する）。
【０１５０】
待ち挿入部６３は、制御表６５を参照して、キューに登録されたパケットの送信を待つ必要があるか否かを判定し、待つ必要があると判定した場合に計算で求めた時間だけ待った後に送信処理部６４に送信を指示する。一方、待ち挿入部６３は、パケットの送信を待つ必要がないと判定したときは送信処理部６４に対しパケットの送信を直ちに指示する。
【０１５１】
送信処理部６４は、待ち挿入部６３からの送信指示を受けキュー６６からパケットを取り出して中継器Ａに向けて送信する。
【０１５２】
待ち挿入部６３および送信処理部６４の処理は、前述の第２実施形態における図６に示す処理に相当する。ただし、図６の処理では、キューからパケットを取り出した後、必要に応じてパケットを待たせているが、図１５の場合は必要に応じて待ち時間を置いた後にキュー６５からパケットを取り出している点が異なっている。これはドライバとアダプタという実施箇所が異なっていることに起因するものではなく、いずれにおいても実施可能な変形例である。
【０１５３】
図１６は第４変形例における制御表を示した図である。
【０１５４】
ここでは前述の第２実施形態の機能を図２に示す配信サーバ３０のアプリケーションに搭載した例を説明する。
【０１５５】
アプリケーションにおいてもドライバと同様な処理が可能である。
【０１５６】
ただし、アプリケーションの１個のプロセス（またはスレッド）は、１個のＴＣＰポートまたはＵＤＰポートに対応している。このため、アプリケーションの各プロセス（またはスレッド）では複数のＴＣＰポートまたはＵＤＰポートを制御する必要はなく、制御表は図１６に示す例のように１つのポート番号のみの制御表となる。この制御表の各欄については図３で説明済みであり、ここでの説明は省略する。
【０１５７】
なお、アプリケーションで実施した場合、このアプリケーションでの実施を実効あるものにするためには、アプリケーションからドライバにデータが転送されるまでの、ＴＣＰ（またはＵＤＰ）層およびＩＰ層（図２参照）でバーストが発生しないことが前提条件となる。
【０１５８】
次に、図２の中継器Ａで実施した例を第５変形例として説明する。
【０１５９】
図２に示す中継器Ｂ又はクライアント端末上に最小のキューが存在する場合、第２実施形態や各変形例の機能を中継器Ａに組み込んで、バッファ（キュー）のオーバフローを防止することも可能である。
【０１６０】
ただし、中継器で実施した場合、パラメータＴ、Ｘ、Ｔ１などを自動的に求めるのは困難な場合が多い。その場合は、それらのパラメータ等をユーザが中継器に直接に指定する必要がある。
【０１６１】
以上で各種変形例の説明を終了し、以下では、パラメータＴ、Ｘ、Ｔ１の決定方法の各１例を説明する。
【０１６２】
パラメータＴ、Ｘ、Ｔ１は、ユーザがあらかじめ知っていればユーザがその値を指定すればよいが、必ずしも知っているとは限らない。そこでここでは、測定プログラムを組み込み、その測定プログラムによって、それらの値を求める方法について説明する。また、配信サーバ３０上のアプリケーション、ドライバ、アダプタであれば、以下に説明するようにして自動的に求められた各値を自動測定することも可能である。ただし上述の通り、中継器はその測定プログラムを組み込んで実行させるほどの能力を持たない場合が多い。
【０１６３】
ここでは、ＴＣＰが使用されることを前提にして説明する。ＵＤＰの場合は変更が必要であり、その変更点については後述する。
【０１６４】
図１７は、測定プログラムの配置位置を示した図である。
【０１６５】
ＴＣＰが使用される場合はユニキャストで送信され、１個のＴＣＰポート番号が１個のクライアント端末に対応している。測定プログラムは、図１７に示す通り、配信サーバのＴＣＰ／ＩＰとドライバとの間で動作する。
【０１６６】
図２に示すエンコーダ２１からストリーミング配信のパケットが送信されている状態において測定プログラムを起動すると、以下の（１）〜（５）の手順で、Ｔ、Ｘ、Ｔ１の各値がこの順に決定される。
【０１６７】
（１）Ｔを求める。
【０１６８】
測定プログラムで多数（例えば１００００個）のパケットの送信間隔の平均を求め、その値をＴとする。パケット同士の時間間隔に偏りが発生している可能性もあるが、多数の平均をとれば、本来のパケット間隔Ｔとほぼ一致する。
【０１６９】
（２）Ｘを求める。
【０１７０】
測定プログラムでＫ個のパケットを溜め込んだあと、Ｋ個のパケットをパケット同士の時間間隔０で送信する。この場合、伝送路上では、パケット同士の間隔は、微小な時間間隔（ＩＥＥＥ８０２．３規定されたＩｎｔｅｒ Ｐａｃｋｅｔ Ｇａｐ）以上となるが、ストリーミング配信でのパケット同士の時間間隔に比べれば無視できるほど小さい。
【０１７１】
Ｋは２から初めて、３，４，５，６，・・・と１ずつ大きくしていく。
【０１７２】
Ｋ個のパケットを送信した後、ＴＣＰによる再送が検出されなければ、Ｋ＋１個のパケットを時間間隔０で送信する。
【０１７３】
このようにして時間間隔０で送信するパケット数Ｋを増やしていき、ＴＣＰによる再送が検出されたところで、そのときのＫから２を引いた数（Ｋ−２）をＸとする。
【０１７４】
図１８は、Ｘ＋１個のパケットを時間間隔０で送信した場合を示す模式図である。
【０１７５】
配信サーバからＸ＋１個のパケットが同時に送信されたものとする。
【０１７６】
その場合、先頭の１個のパケットは最小のキューを持つ装置の処理部によりその最小のキューから直ちに取り出され、２個目〜Ｘ＋１個目のＸ個のパケットによりその最小のキューが一気に満杯の状態となる。
【０１７７】
ただし、この場合、オーバフローは発生しない。
【０１７８】
図１９は、Ｘ＋２個のパケットを時間間隔０で送信した場合を示す模式図である。
【０１７９】
配信サーバからＸ＋２個のパケットが同時に送信された場合、最後（Ｘ＋２個目）の１個のパケットがキューに入りきらずオーバフローが発生する。これはパケットロストとなり、ＴＣＰによる再送が発生する原因となる。
【０１８０】
したがって上記の通り、ＴＣＰによる再送が検出された時点で、その時のＫから２を引いた数（Ｋ−２）がＸとなる。
【０１８１】
（３）Ｔ１を求める。
【０１８２】
はじめに、測定プログラムでパケットをＸ＋２個のパケット溜め込んだあと、Ｘ＋２個のパケットをパケット同士の時間間隔Ｍで送信する。
【０１８３】
Ｍは１ミリ秒からはじめて、２ミリ秒、３ミリ秒、４ミリ秒・・・と１ミリ秒ずつ大きくしていく。
【０１８４】
Ｘ＋２個のパケットをＭミリ秒間隔で送信した後、ＴＣＰによる再送が検出されれば、再度Ｘ＋２個のパケットを溜め込んで、Ｍの値を１増やす。
【０１８５】
Ｍミリ秒間隔でパケットを送信した後、ＴＣＰによる再送が検出されなければ、その時のＭをＭ＿２とする。
【０１８６】
次に、測定プログラムでパケットをＸ＋３個のパケット溜め込んだあと、Ｘ＋３個のパケットをパケット同士の時間間隔Ｍで送信する。ＭはＭ＿２からはじめて、以降Ｘ＋２個の時と同様な処理を行って、ＴＣＰによる再送が検出されなくなったときのＭをＭ＿３とする。
【０１８７】
次に、測定プログラムでパケットをＸ＋４個のパケット溜め込んだあと、Ｘ＋４個のパケットをパケット同士の時間間隔Ｍで送信する。ＭはＭ＿３からはじめて、以降Ｘ＋２個の時と同様な処理を行って、ＴＣＰによる再送が検出されなくなったときのＭをＭ＿４とする。
【０１８８】
以降、同様な処理をＸ＋ｎ個（ｎ＝５、６・・・）のパケットを溜め込んで繰り返す。
【０１８９】
Ｍ＿ｎが増えないことが何回か（例えば４回）連続で検出された場合、そのＭ＿ｎをＴ１とする。例えば、Ｍ＿１００＝Ｍ＿１０１＝Ｍ＿１０２＝Ｍ＿１０３となった場合、その値をＴ１とする。
【０１９０】
なおこの例では最小の時間の刻みを１ミリ秒としたが、Ｔ１を更に高精度に求める場合１００マイクロ秒などとしても同様な方式でＴ１を求めることが可能である。
【０１９１】
上記の方法で求めたＴ１が、経路上のキューでパケット１個が処理される時間に相当することを図を用いて説明する。
【０１９２】
図２０は、パケットを送信時間間隔Ｔ１で送信したときの様子を示す図である。
【０１９３】
経路上の最小のキューは最初は空、かつその最小のキューを持つ装置の処理部で処理中のパケットもなかったという前提とする。
【０１９４】
この場合、１個前に受信したパケットについて次のパケットを受信する直前に処理部での処理が完了しているためキューにパケットが溜まることはなく、パケットを何個送信してもキューのオーバフローは発生しない。
【０１９５】
尚ここでは、キューは空である、という前提を置いて説明したが、パケットを送信時間間隔Ｔ１で送信する場合、キューに１個分でも空きがあればオーバフローは発生しない。
【０１９６】
図２１は、パケットを送信時間間隔０．９９・Ｔ１で送信したときの様子を示す図である。
【０１９７】
ここでも、経路上の最小のキューは最初は空、かつ、その最小のキューを持つ装置の処理部で処理中のパケットもなかったという前提とする。
【０１９８】
最初のパケットは、キューを素通りしてその装置の処理部で処理が行なわれる。
【０１９９】
２番目のパケットが送信された時点では、最初のパケットが処理部で未だ処理中のためキューに一旦溜まる。その２番目のパケットがキューに一旦溜まった後、０．０１・Ｔ１後に１番目のパケットの処理が完了し、２番目のパケットが処理部に移される。
【０２００】
３番目のパケットが送信された時点では、２番目のパケットが処理部で処理されている途中であり、キューに一旦溜まる。２番目のパケットの処理は、３番目のパケットがキューに溜まった後０．０２・Ｔ１後に完了し、キューに溜めていた３番目のパケットが処理部に移される。
【０２０１】
このようにして、１０１個目のパケットの送信まではキューにパケットが１個溜まる状況が続く。１０２個目〜２０１個目のパケットの送信ではキューにパケットが２個溜まる状況となる。同様にして２０２個目〜３０１個目の送信ではキューにパケットが３個溜まる状況となる。さらに同様にして、１００・（Ｘ−１）＋２〜１００・Ｘ＋１個目のパケットの送信ではキューにパケットがＸ個溜まる状況となり、パケットを１００・Ｘ＋２個送信するとキューがオーバフローする。ここでもキューは最初は空の状態にあることを前提としたが、キューに既にパケットが溜まっている状態では更に早い時点でオーバフローが発生する。
【０２０２】
このように、送信時間間隔がＴ１以上でパケットを送信すると最小のキューでのオーバフローが避けられ、Ｔ１よりも僅かでも短い時間間隔でパケットを送信すると最小のキューでオーバフローが発生する。
【０２０３】
したがって、上記（３）の方法により、最小のキューに収容されているパケットがその最小のキューから順次取り出される時間間隔Ｔ１が求められる。
【０２０４】
（４）表示または設定
上記（１）〜（３）により求められたＴ、Ｘ、Ｔ１は、ディスプレイ（図示せず）上に表示される。あるいは、これらの値Ｔ、Ｘ、Ｔ１は、測定プログラムによりアプリケーション、ドライバ、又はアダプタに自動設定される。
【０２０５】
（５）測定プログラム終了
測定プログラムの実行が終了する。測定プログラムは、起動した後、（１）〜（４）を行なえば自動的に終了する。
【０２０６】
以上の各パラメータＴ、Ｘ、Ｔ１の決定方法は、ストリーム配信にＴＣＰが使用されていることを前提とする求め方である。そこで次に、ＴＣＰに代わりＵＤＰが使用される場合のパラメータＴ、Ｘ、Ｔ１の決定方法を説明する。
【０２０７】
Ｔの決定方法については、ＴＣＰとＵＤＰで違いはなく、上記の（１）で説明した方法がそのまま採用可能である。
【０２０８】
ＵＤＰの場合は、ＴＣＰのように再送処理は存在しない。
【０２０９】
また、ＴＣＰはユニキャストの送信しかできないので、ポート番号は１個のクライアント端末に対応していたが、ＵＤＰでは多くの場合マルチキャストでの送信が行われており、その場合、ポート番号は複数のクライアント端末に対応している。
【０２１０】
ＵＤＰの場合は、そのポート番号が対応しているクライアント端末のどれか１台に、パケットロストを検出して送信元に通知するパケットロスト検出プログラムを導入する。パケットロスト検出プログラムがパケットロストを検出し、その結果を配信サーバ側に送り返すことで、上記の（２）、（３）と同様な方法で、Ｘ、Ｔ１を決定することができる。
【０２１１】
図２２、２３では、ＵＤＰを使用した場合の、測定プログラムおよびパケットロストプログラムの各動作位置を示した図である。
【０２１２】
図２２には、図２２（Ａ）に示すように測定プログラムが配信サーバのＵＤＰ／ＩＰとドライバとの間で動作し、図２２（Ｂ）に示すようにパケットロストプログラムがクライアント端末のＵＤＰ／ＩＰとドライバとの間で動作することが示されている。また図２３には、図２３（Ａ）に示すように、測定プログラムが配信サーバのアプリケーションとＵＤＰ／ＩＰとの間で動作し、パケットロストプログラムがクライアント端末のアプリケーションとＵＤＰ／ＩＰとの間で動作することが示されている。
【０２１３】
このように、測定プログラムおよびパケットロストプログラムは、図２２に示すようにＵＤＰ／ＩＰとドライバとの間で動作させてもよく、図２３に示すようにアプリケーションとＵＤＰ／ＩＰとの間で動作させてもよい。
【符号の説明】
【０２１４】
１０ パケット送信装置
１１ パケット受信部
１２ 待ち処理部
１３ パケット送信部
１４ 経過時間判定部
１５ 制御表記憶部
１５ａ 制御表
１６ 制御表更新部
１７ 測定部
１８ 再送要求受信部
２０ コンテンツ
２１ エンコーダ
３０ 配信サーバ
４１ 中継器Ａ
４２ インターネット
４３＿１，４３＿２ 中継器Ｂ
５０＿１，５０＿２，・・・，５０＿ｎ クライアント端末
５１＿１，５１＿２，・・・，５１＿ｎ 映像装置
６１ ポート番号自動判定部
６２ キューイング部
６３ 待ち挿入部
６４ 送信処理部
６５ 制御表
６６ キュー
【技術分野】
【０００１】
本件は、パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置およびパケット送信方法、並びに演算処理装置内にパケット送信装置を構築するパケット送信プログラムに関する。
【背景技術】
【０００２】
例えば動画配信等のストリーミング配信における１つの問題としていわゆるバースト問題がある。すなわち、大量のパケットが短時間に配信されることによって中継装置（スイッチ、ルータ、コンバータなど）や送信先装置のバッファ（キュー）がオーバフローする。オーバフローしたパケットは廃棄され、その結果、例えば動画配信における再生画像が乱れるなどの障害が生じる。これをバースト問題と称する。
【０００３】
従来、このバースト問題の緩和のために、トラフィックシェービングと呼ばれる手法とトラフィックポリシングと呼ばれる手法が知られている。トラフィックシェービングは送信しようとしているパケットをバッファ（キュー）に一旦溜め込んでおき、一定の時間間隔でパケットを転送する方式である。また、トラフィックポリシングは、トラフィックが一定レート以上になるとパケットを破棄する方式である。
【０００４】
ここで、トラフィックシェービングは、アンダフロー（キューに溜め込まれたパケットの枯渇）が原因で一定時間間隔での送信ができなくなることを避けるために、大量のパケットを常にキューに溜め込んでおくように実装される。このため、トラフィックシェービングでは、キューに溜め込まれた大量のパケットに相当する時間分の遅延が常に発生した状態で送信を行なうことになる。さらにこのトラフィックシェービングでは、何らかの理由で送信が一定時間行なえなかった場合、キューに溜め込まれるパケットの数がさらに増加することになる。
【０００５】
一方、トラフィックポリシングでは、パケット廃棄が発生しやすい。このトラフィックポリシングでは、パケットがまとまって大量に破棄される可能性は小さいため、大きい画像乱れにはつながりにくいが、小規模なパケット破棄による小規模な画像乱れが発生しやすい。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１８６８８２号公報
【特許文献２】特開２００７−１３４４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本件のパケット送信装置、パケット送信方法、およびパケット送信プログラムの課題は、上記のバースト問題の一層の緩和を図ることにある。
【課題を解決するための手段】
【０００８】
本件開示のパケット送信装置は、パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置であって、パケット受信部と、経過時間判定部と、待ち処理部と、パケット送信部とを有する。
【０００９】
パケット受信部は、パケットを受信する。
【００１０】
また、経過時間判定部は、経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定する。ここで、受信したパケットを送信先装置に向けて送信したときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸとする。また、その最小のキューに収容されているパケットがその最小のキューから順次取り出される時間間隔をＴ１とする。さらに経過時間ｔは、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間をいう。
【００１１】
また、待ち処理部は、経過時間判定部により、経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、上記の未送信パケットの送信を待たせる処理を行なう。
【００１２】
さらに、パケット送信部は、上記未送信パケットを、経過時間判定部により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記現時刻に送信する。また、このパケット送信部は、上記未送信パケットを、経過時間判定部により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には待ち処理部により待たされた後に送信する。
【００１３】
また、本件開示のパケット送信方法は、上記のパケット送信装置で実行される処理を方法として捉えたものである。
【００１４】
さらに、本件開示のパケット送信プログラムは、プログラムを実行する演算処理装置内で実行され、その演算処理装置内に上記のパケット送信装置を構築するプログラムである。
【発明の効果】
【００１５】
本件開示のパケット送信装置等によれば、バースト問題の一層の緩和が図られる。
【図面の簡単な説明】
【００１６】
【図１】第１実施形態のパケット送信装置の機能ブロック図である。
【図２】第２実施形態を含む全体システムを示すブロック図である。
【図３】制御表の一例を示した図である。
【図４】配信サーバ中のドライバＢにおける送信処理を示すフローチャートである。
【図５】図４に示す送信処理のうちの「キューイングおよびストリーミング配信以外のパケット送信部」のフローチャートである。
【図６】図３の送信スレッド部の処理を示すフローチャートである。
【図７】送信間隔を調整することなく送信を行なった場合の例を示す図である。
【図８】トラフィックシェービングを適用した場合の例を示す図である。
【図９】時刻Ｚｍｓの時点における制御表を示した図である。
【図１０】図４〜図６に示す送信処理の具体例を示す図である
【図１１】この第１変形例における制御表の初期状態を示す図である。
【図１２】この第１変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」の処理内容を示したフローチャートである。
【図１３】図１２におけるポート番号自動識別処理（ステップ３１）のフローチャートである。
【図１４】第２変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」の処理内容を示した図である。
【図１５】第２実施形態の第３変形例を示す図である。
【図１６】第４変形例における制御表を示した図である。
【図１７】測定プログラムの配置位置を示した図である。
【図１８】Ｘ＋１個のパケットを時間間隔０で送信した場合を示す模式図である。
【図１９】Ｘ＋２個のパケットを時間間隔０で送信した場合を示す模式図である。
【図２０】パケットを送信時間間隔Ｔ１で送信したときの様子を示す図である。
【図２１】パケットを送信時間間隔０．９９・Ｔ１で送信したときの様子を示す図である。
【図２２】ＵＤＰを使用した場合の、測定プログラムおよびパケットロストプログラムの各動作位置を示した図である。
【図２３】ＵＤＰを使用した場合の、測定プログラムおよびパケットロストプログラムの各動作位置を示した図である。
【発明を実施するための形態】
【００１７】
以下、実施形態を説明する。
【００１８】
図１は、第１実施形態のパケット送信装置の機能ブロック図である。
【００１９】
この図１において、実線の矢印は送信データ（パケット）の流れを表わし、点線の矢印は、その他のデータ（制御情報）の流れを表わしている。
【００２０】
この図１に示すパケット送信装置１０は、パケット受信部１１、待ち処理部１２、およびパケット送信部１３を有する。
【００２１】
パケット受信部１１は、パケットを受信する。
【００２２】
待ち処理部１２は、後述する条件に合致する場合には、パケット受信部１１で受信したパケットをパケット送信部１３で直ちには送信させずに、その送信を延期させる待ち処理を行なう。
【００２３】
パケット送信部１３は、待ち処理部１２から渡されたパケットを送信先装置（図示せず）に向けて送信する。
【００２４】
また、この図１に示すパケット送信装置１０は、経過時間判定部１４を有する。この経過時間判定部１４では、待ち処理部１２に待ち処理を実行させるための条件判定を行なう。その条件判定の説明にあたり、ここでは以下の通りパラメータを定義する。
【００２５】
Ｘ：受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数。送信経路の具体例については、後述の第２実施形態で説明する。
【００２６】
Ｔ１：その最小のキューに収容されているパケットがその最小のキューから順次取り出される時間間隔
ｔ：直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間
Ｘ・Ｔ１：第１の閾値時間
経過時間判定部１４は、経過時間ｔと第１の閾値時間Ｘ・Ｔ１との大小を判定する。
【００２７】
そして待ち処理部１２は、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、パケット受信部１１から受け取った未送信パケットの送信を延期させる待ち処理を行なう。
【００２８】
さらにパケット送信部１３は、その未送信パケットを、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には待ち処理部１２による待ち処理を経ることなく送信する。すなわちこの場合、パケット送信部１３は未送信パケットを待ち処理部１２から直ちに受け取って送信する。また、このパケット送信部１３は、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には、未送信パケットを、待ち処理部１２による待ち処理を経た後に送信する。
【００２９】
ここで、さらにパラメータを定義する。
【００３０】
Ｔ：パケット受信部１１におけるパケット平均受信時間間隔
Ｔ２：Ｔ１＜Ｔ２＜Ｔを満たす時間間隔。例えばＴ２＝（Ｔ１＋Ｔ）／２
待ち処理部１２は、具体的には、経過時間判定部１４により経過時間ｔが第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を、現在時刻から（第２の閾値時間Ｘ・Ｔ２−経過時間ｔ）の待ち時間だけ待たせる待ち処理を行なう。
【００３１】
図１に示すパケット送信装置１０は、さらに、制御表記憶部１５と制御表更新部１６を有する。制御表記憶部１５は制御表１５ａを記憶する記憶部である。この制御表１５ａには、直近の送信済パケットから数えてＸ−１個前の送信済パケットまでの、その直近の送信済パケットを含むＸ個の送信済パケットの各送信時刻が記録される。また、制御表更新部１６は、パケット送信部１３による未送信パケットの送信を受けて制御表中の送信時刻を更新する。
【００３２】
上記の経過時間判定部１４は、制御表１５ａを参照することによりＸ−１個前の送信済パケットの送信時刻を求めて経過時間ｔを算出し、その経過時間ｔと第１の閾値時間Ｘ・Ｔ１との大小を判定する。
【００３３】
ここで、パケットの送信先が複数存在するときは、制御表１５ａには、各送信先ごとの各領域に、各送信先に向けて送信された送信済パケットの各送信時刻が記録される。この場合、制御表更新部１６は、制御表１５ａ中の送信時刻をパケットの送信先ごとに更新する。
【００３４】
制御表１５ａに記録される送信先は、あらかじめ分かっているときは、その分かっている送信先が初期設定として制御表１５ａに記録される。あるいは、送信先があらかじめ不明な場合、制御表更新部１６にパケットの送信先を監視させ、新たな送信先に向けて送信されるパケットを検出したときに制御表１５ａにその新たな送信先に対応する領域を追加させる構成を採用してもよい。
【００３５】
制御表１５ａの具体例については、後述の第２実施形態で説明する。
【００３６】
図１に示すパケット送信装置１０はさらに、測定部１７と再送要求受信部１８を有する。再送要求受信部１８は、パケット送信部１３から送信先装置に向けて送信したパケットの再送要求を受信する受信部である。この再送要求受信部１８で再送要求を受信すると、再送要求があったことが測定部１７に通知される。
【００３７】
測定部１７は、以下の３つの役割りを担っている。
（１）パケット平均受信時間間隔Ｔを求める平均受信時間算出部としての役割り。
（２）収容可能パケット数Ｘを求める収容可能パケット数検出部としての役割り。
（３）時間間隔Ｔ１を求めるキュー取出し時間検出部としての役割り。
【００３８】
この測定部１７は、上記（１）のパケット平均受信時間間隔Ｔを求めるにあたっては、以下の処理を行なう。すなわち、この測定部１７は、パケット受信部１１において順次受信する複数のパケットの受信間隔の平均値を算出する。この算出された平均値が上記の平均受信時間間隔Ｔである。
【００３９】
また、測定部１７は、上記（２）の収容可能パケット数Ｘを求めるにあったては、以下の処理を行なう。すなわち、測定部１７は、パケット送信部１３に、複数個のパケットを送信先装置に向けてほぼ同時に送信する過程を、ほぼ同時に送信するパケットの個数を順次変更しながら繰り返させ、再送要求の発生を免れる最大パケット数を検出する。この再送要求の発生を免れる最大パケット数が送信先装置に向けてパケットを送信したときの送信経路上に存在するキューのうちの最小のキーの収容可能なパケット数Ｘである。
【００４０】
さらに、測定部１７は、上記（３）の時間間隔Ｔ１を求めるにあたっては、以下の処理を行なう。すなわち測定部１７は、パケット送信部１３に、複数個のパケットを所定の時間間隔で送信する過程を、パケットの個数および所定の時間間隔を変更しながら繰り返させて、パケットの個数を増やしても再送要求が検出されない最短の時間間隔を検出する。この最短の時間間隔が、上記の時間間隔Ｔ１である。
【００４１】
尚、この図１に示す第１実施形態では、測定部１７を備えてパケット平均受信時間間隔Ｔ、収容可能パケット数Ｘ、および時間間隔Ｔ１を求めているが、それらがあらかじめ分かっているシステムの場合は、この測定部１７は不要である。
【００４２】
測定部１７で求められた各値Ｔ、Ｘ、Ｔ１は、待ち処理部１２および経過時間判定部１４での上述の各処理や、制御表記憶部１５に記憶されている制御表１５ａに記録される送信時刻の数の指標として用いられる（制御表１５ａについては後述の第２実施形態を参照）。
【００４３】
ここでは、パケット送信装置１０について説明したが、このパケット送信装置１０で行われる処理をパケット送信方法として捉えることもできる。また、この図１のパケット送信装置１０を、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が搭載された演算処理装置内で実行されたときに、その演算処理装置内にパケット送信装置を構築するパケット送信プログラムとして捉えることもできる。
【００４４】
以上で第１実施形態の説明を終了し、次に第２実施形態を説明する。
【００４５】
図２は、本件の第２実施形態を含む全体システムを示すブロック図である。
【００４６】
ここでは、パケットは、コンテンツ２０（ここでは動画コンテンツとする）からエンコーダ２１に取り込まれ、そのエンコーダ２１から配信サーバ３０が受信するものとする。ここで、エンコーダ２１は、例えば多数のコンテンツを蓄積しておき、要求に応じたコンテンツを表わすパケットを要求先に向けてストリーム配信するコンテンツストレージ装置等を代表させて示したものである。
【００４７】
配信サーバ３０に到着したパケットは、アダプタＡで受信され、ドライバＡが受け取ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃａｌ）に渡され、さらにＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃａｌ）に受け渡される。ここで、後述する態様によってはＴＣＰに代わりＵＤＰ（Ｕｓｅr Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を採用した場合に言及する。基本的にはＴＣＰとして説明する。
【００４８】
ＴＣＰは、ユニキャストの送信を行なうプロトコルである。したがって、１つのポート番号は１個の送信先装置に対応している。またＴＣＰでは、送信経路上でパケットロストがあるとパケットの再送処理が行なわれる。
【００４９】
一方ＵＤＰでは多くの場合マルチキャストでの送信が行なわれており、その場合１つのポート番号が複数の送信先装置に対応している。またＵＤＰではそのままでは再送処理は行われない。したがって送信元では、パケットロストを検出するとその結果を送り返すパケットロスト検出プログラムを送信先側に導入して初めてパケットロストがあったことを知ることができる。
【００５０】
配信サーバ３０のＴＣＰに受け渡されたパケットは、さらにアプリケーションプログラムを経由して今度は逆順を辿り、ＴＣＰ、ＩＰと進み、次にはドライバＢ、アダプタＢと進んで、配信サーバ３０から送信先装置（ここではクライアント端末５０＿１，５０＿２，・・・，５０＿ｎ．・・・のうちのいずれか）に向けて送信される。
【００５１】
配信サーバ３０から送信されたパケットは中継器Ａ４１，インターネット４２（または専用線でもよい）、およびいずれかの中継器Ｂ４３＿１，４３＿２，・・・を経由して、いずれかのクライアント端末５０＿１，５０＿２，・・・，５０＿ｎ，・・・で受信される。受信されたパケットはそのクライアント端末に接続された映像装置５１＿１，５１＿２，・・・，５１＿ｎ−１，５１＿ｎ，・・・により映像として可視化される。
【００５２】
ここで、配信サーバ３０は、図示しないＣＰＵやメモリ等、演算処理を行なうハードウェアを有する。
【００５３】
図２に示したドライバＡ、ＩＰ、ＴＣＰ（またはＵＤＰ）、およびアプリケーションは、そのハードウェア上で実行されるソフトウェアを表わしている。ここでは、説明の簡素化のため、それらのソフトウェアがＣＰＵで実行されることにより実現する機能を、ソフトウェア自体と区別せずに説明する。
【００５４】
以下では、本件の機能をドライバＢで実現した例について先ず説明し、その後、実現形態の異なる各種の例について説明する。
【００５５】
尚、以下の説明においても、Ｘ，Ｔ，Ｔ１，Ｔ２，ｔの各パラメータは前述の第１実施形態で説明した通りのものとする。Ｘ，Ｔ，Ｔ１は、ユーザがあらかじめ知っていてドライバＢのコンフィギュレーションプロパティ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｐｅｒｔｉｅｓ）などで指定したものが用いられる。あるいは後述する方法により求められ、ユーザあるいはアプリケーションにより指定されたものが用いられる。
【００５６】
図３は、制御表の一例を示した図である。
【００５７】
ここでは、送信先ポート番号や各種パラメータはユーザが既に知っていて、ドライバＢのプロパティ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｐｅｒｔｉｅｓ）などで指定されるものとする。あるいはアプリケーションが知っていてそのアプリケーションがドライバＢに指定するものであってもよい。
【００５８】
この図３に示す制御表中の「送信先ポート番号」は、上記の通りユーザ又はアプリケーションにより指定されたものである。この制御表は送信先ポート番号ごとに横一行の領域が設けられており、各送信先ポート番号ごとに以下に説明する値が記録される。また、ここでは、ドライバＢが、パケットを一時的に格納しておくキューを各送信先ポート番号ごとにメモリ（図示せず）上に作成するものとし、「キューのベースアドレス」には、そのメモリ上に作成されたキューの所在をあらわすアドレスが記録される。
【００５９】
また、「Ｘ−１個前のパケット番号」は、直近の送信済のパケットから数えてＸ−１個前の送信要済パケットのパケット番号である。ここでは、このパケット番号は０〜Ｘ−１で指定され、パケットを１つ送信するたびに０→１→・・・→Ｘ−１の順にインクリメントされ、（Ｘ−１）に達したら次は（０）に戻される。これら０，１，・・・，Ｘ−１は、この制御表内の時刻（０），時刻（１），・・・，時刻（Ｘ−１）にそれぞれ対応している。図３では、初期値として全て０が記録されている。
【００６０】
「直近のパケット番号」は、直近の送信済のパケットの番号である。この「直近パケット番号」についてもパケットを１つ送信するたびに０→１→・・・→Ｘ−１→０→・・・の順に循環的に更新される。図３には初期値として全てＸ−１が記録されている。
【００６１】
「時刻（０）」，「時刻（１）」，・・・，「時刻（Ｘ−１）」は、それぞれ、パケット番号０，１，・・・，Ｘ−１の送信済パケットの各送信時刻である。図３では初期値として全てＳが記録されている。この初期値Ｓは、パケット送受信を開始する時刻よりも時間的に十分に辿った時刻である。例えば図２の配信サーバ３０が起動した時刻を０としたとき、起動後数分はパケット送受信を開始しないであれば、Ｓ＝０でよい。
【００６２】
未送信のパケットを１個送信すると、「直近のパケット番号」に記録されているパケット番号に対応する時刻（直近のパケット番号）に現在時刻が記録され、「Ｘ−１個前のパケット番号」および「直近のパケット番号」に１が加えられる。ただし、１を加えた結果Ｘ−１がＸに値が変ったときは、そのパケット番号は０に戻される。
【００６３】
尚ここでは、収容可能なパケット数が最小のキューは、図２の中継器Ｂ４３＿１，４３＿２，・・・に存在し、かつ各中継器Ｂ４３＿１，４３＿２，・・・のキューの収容可能なパケット数は、いずれの中継器Ｂ４３＿１，４３＿２，・・・も同一の数Ｘであるとしている。
【００６４】
図４は、配信サーバ中のドライバＢにおける送信処理を示すフローチャートである。
【００６５】
ドライバＢではＩＰからの関数コールによりこの図４に示す送信処理が実行される。
【００６６】
この送信処理は、「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）と「送信スレッド部」（ステップＳ０２）とから成り立っている。
【００６７】
図５は、図４に示す送信処理のうちの「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）のフローチャートである。
【００６８】
この図５、およびそれ以降の図において「ＴＣＰ／ＵＤＰ」は、そのシステムでストリーム配信にＴＣＰが使用されていればＴＣＰを、ＵＤＰが使用されていればＵＤＰを意味するものとする。
【００６９】
ここでは先ず、今回送信しょうとしているパケットがここで対象としているＴＣＰ／ＵＤＰパケットであり、かつポート番号が制御表（図３参照）に含まれるポート番号であるか否かが判定される（ステップＳ１１）。
【００７０】
このステップＳ１１の条件を満たすパケットの場合は、そのパケットが送信待ちのパケットを並べておくキューに登録され（ステップＳ１２）、送信スレッドが起動していなければ送信スレッドが起動される（ステップＳ１３）。この送信スレッドは、図４に示す送信スレッド部（ステップＳ０２）の処理を行なうプログラムである。送信スレッド部（ステップＳ０２）の処理については後述する。
【００７１】
ステップＳ１１の条件を満足しない場合、すなわち、送信しようとするパケットがここでの制御対象としているＴＣＰ／ＵＤＰパケット以外のパケットである場合、および、ＴＣＰ／ＵＤＰパケットではあっても制御表に制御対象として登録されているポート番号以外のポート番号のパケットであった場合は、ステップＳ１４に進み、ここではそのまま、従来と同様のパケット送信処理が行なわれる。
【００７２】
以上の処理が、今回送信しようとしている全てのパケットについて繰り返される（ステップＳ１５）。
【００７３】
図６は、図４の送信スレッド部（ステップＳ０２）の処理を示すフローチャートである。
【００７４】
ここでは、初期には送信スレッドがスリープ状態にあるものとする。（ステップＳ２１）。
【００７５】
図５のステップＳ１５で起動をかけられると送信スレッドが動作を開始し、ステップＳ２２以下の処理が行われる。
【００７６】
ここでは先ずキューからパケットが１個取出される（ステップＳ２２）。次いで直近の送信済パケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの経過時間ｔが算出される（ステップＳ２２）。この経過時間ｔは、図３に示す制御表が参照され、
ｔ＝現在の時刻−時刻（Ｘ−１個前のパケット番号）
により算出される。
【００７７】
次に、この算出された経過時間ｔと、第１の閾値時間Ｘ・Ｔ１とが比較される（ステップＳ２４）。ｔ≦Ｘ・Ｔ１のときは待ちが必要と判断され、（Ｘ・Ｔ２−ｔ）の時間待つ（ステップＳ２５）。ｔ＞Ｘ・Ｔ１のときは、待ちは不要と判断され、ステップＳ２５はスキップされる。
【００７８】
次に、制御表（図３参照）の、時刻（直近のパケット番号）に送信時の現在時刻が記録され（ステップＳ２６）、それに続き、パケット送信処理が行われる（ステップＳ２７）。
【００７９】
さらに、制御表の、Ｘ−１個前のパケット番号、および直近のパケット番号に１が加えられる（ステップＳ２８）。１を加えた結果Ｘ−１よりも大きな値となったときは０に戻される。
【００８０】
ステップＳ２９では、キューに未送信のパケットが残ってるか否かが判定され、残っているときはステップＳ２２に戻り、残りの未送信パケットのうちの１個のパケットが取出されて、上記と同様の処理が繰り返される。
【００８１】
一方、ステップＳ２９において、キューに未送信パケットが残っていないと判定されたときはステップＳ２１に戻り、この送信スレッドはスリープ状態に戻る。
【００８２】
この図６に示す処理によれば、連続するＸ個のパケットの先頭から末尾までの間隔はＸ・Ｔ１より大きくなるため、このままのパケット間隔で中継器Ｂに到達すれば中継器Ｂのキューがオーバフローすることはない。
【００８３】
ここで、連続するＸ個のパケットの先頭から末尾までの間隔がＸ・Ｔ１より大きい場合、任意の１個のパケットが中継器Ｂに到達したときに中継器Ｂのキューに最低限１個の空きがあることを説明する。その１個のパケットよりもＸ−１個前のパケットは、少なくともＸ・Ｔ１の間隔が開いている。このため仮にＸ−１個前のパケットが中継器Ｂに到着したときにそのＸ−１個前のパケットが中継器Ｂのキューの末尾に登録されたとしても、今回のパケットが中継器Ｂに到着したときには、そのＸ−１個前のパケットはその中継器Ｂのキューの外に取り出されている。したがって任意の１個のパケットが中継器Ｂに到着したときには、中継器Ｂのキューに最低１個の空きが存在する。したがって、図６に示す処理によれば、中継器Ｂのキューでのオーバフローを避けることができる。
【００８４】
ここで図４〜図６に示す送信処理によるパケット送信例を比較例とともに具体的に説明する。
【００８５】
図７は、送信間隔を調整することなく送信を行なった場合の例を示す図である。この図７は本件に対する比較例に相当する。ここでは、この図７に示す比較例を第１比較例と称する。
【００８６】
この図７および後述する図８、図１０並びにそれらの図の説明で用いている記号は、以下の通り定義されるものとする。
【００８７】
Ｔ、Ｘ、Ｔ１、Ｔ２、ｔの意味は、第１実施形態の説明の通りとする。
【００８８】
ｍｓはミリ秒を表す。ここでは、Ｔ＝１０ｍｓ、中継器Ｂのキューが最小であってＸ＝８個、Ｔ１＝４ｍｓ、Ｔ２＝６ｍｓの場合を考える。
【００８９】
Ｑ１は、配信サーバ３０のＩＰのキューである。そのＱ１の欄に記載されている「なし」、「１」、「２」等は、そのＱ１に並んでいるパケットの数を表わしている。
【００９０】
Ｑ２は、配信サーバ中のドライバＢのキューである。そのＱ２の欄に記載されている、「なし」、「１００」（図８参照）等は、そのＱ２に並んでいるパケットの数を表している。ただし、このパケットの数は、Ｑ２から取り出された直後の、未送信のパケットを含んでいる。
【００９１】
時刻Ｚ＋１０−０ｍｓ、Ｚ＋２０−０ｍｓ（図７参照）等の−０ｍｓは、時刻Ｚ＋１０ｍｓ、Ｚ＋２０ｍｓ等よりもわずかに前の時刻であることを意味している。
【００９２】
また、時刻Ｚ＋１０＋０ｍｓ、Ｚ＋２０＋０ｍｓ（図８参照）等の＋０ｍｓは、時刻Ｚ＋１０ｍｓ、Ｚ＋２０ｍｓよりもわずかに後の時刻を意味している。
【００９３】
またここで登場するパケットは、送信先ポート番号がすべて同一（ここでは送信先ポート番号２８００１）であるとする。
【００９４】
時刻Ｚｍｓは、既に何パケットか送信された後の状態にある時刻である。
この時刻Ｚｍｓ以前は、パケットは１０ｍｓの等間隔で受信され、Ｑ１、Ｑ２を通過し、さらに、配信サーバ３０の外にもそのまま１０ｍｓの等間隔で送信されたものとする。時刻Ｚｍｓ以降も、Ｑ１には１０ｍｓの等間隔でパケット届いているものとする、尚パケットがＱ１に到着する時刻は、Ｚ＋１０−０ｍｓ、Ｚ＋２０−０ｍｓ等、Ｚ＋１０ｍｓ、Ｚ＋２０ｍｓ等よりもわずかに前の時刻であるとする。
【００９５】
そして、時刻Ｚ〜Ｚ＋１０ｍｓの間のどこか（例えば時刻Ｚ＋５ｍｓ）から時刻Ｚ＋１００−０ｍｓまでの間、ＣＰＵでは、パケットの送信とは無関係の、それよりも優先順位の高い何らかのソフトウェアが動作したために、ドライバＢでの送信処理にはＣＰＵが割り当てられず、送信処理が中断した状態にあったものと仮定する。
【００９６】
この場合、送信間隔を調整することなく送信を行なうと、図７に示す通りとなる。
【００９７】
すなわち、図７に示すように、時刻Ｚ＋１０−０ｍｓ〜時刻Ｚ＋１００−０ｍｓの間に到達したパケットは、送信処理が中断しているためＱ１に格納されたままとなる。時刻Ｚ＋１００−０ｍｓにＣＰＵに送信処理が割り当てられたことにより、時刻Ｚ＋１００＋０ｍｓには、Ｑ１に格納された１０個のパケットがほぼ同時に配信サーバ３０の外に送信される。
【００９８】
この場合、最小のキューを持つ中継器Ｂ（Ｘ＝８個）で１０−８＝２個のパケットが廃棄される結果となる。
【００９９】
図８は、トラフィックシェービングを適用した場合の例を示す図である。ここでも図７の場合と同じ条件が適用されている。
【０１００】
トラフィックシェービングは、前述のとおり、パケットをキューに一旦溜め込んでおき、等間隔の時間でパケットを送信する方式である。この図８に示す例では、Ｑ２に１００個のパケットが溜め込まれ、そのパケットが１０ｍｓ間隔で送信されている。また、同じ１０ｍｓ間隔で新たなパケットが到着している。
【０１０１】
この場合、図８に示すように、時刻Ｚ＋１０−０ｍｓ〜時刻Ｚ＋１００−０ｍｓの間に到達したパケットは、送信処理が中断しているためＱ１に格納されたままとなる。また送信処理が中断したため、Ｑ２に溜まっているパケットも溜まったままとなり、配信サーバ３０から外への送信も中断する。時刻Ｚ＋１００−０ｍｓに送信処理が再開されると、直後の時刻Ｚ＋１００＋０ｍｓに、時刻Ｚ＋１００−０ｍｓにＱ１に到着したパケットを含む、それまでＱ１に溜まっていた１０個のパケットがＱ２に移る。送信処理が再開されたことに伴い、その時刻Ｚ＋１００＋０ｍｓには、Ｑ２からパケットが１個取り出されて配信サーバ外に送信され、その後もＱ２からは１０ｍｓ間隔でパケットが取り出されて送信される。
【０１０２】
この場合、配信サーバ３０から送信された後の送信経路上ではパケットの廃棄は生じないが、パケット配信が中断したことによる映像の乱れが生じる可能性がある。またＱ２には、中断以前のパケット数よりも多い数のパケットが蓄えられ、その分、送信が全体としてさらに遅れることになる。
【０１０３】
次に図４〜図６に示す送信処理の具体例を説明する。
【０１０４】
図９は、時刻Ｚｍｓの時点における制御表を示した図である。ただしここでは、送信先ポート番号２８００１についてのみ示してある。
【０１０５】
また図１０は、図４〜図６に示す送信処理の具体例を示す図である。ここでも図７の場合と同じ条件が適用されている。
【０１０６】
時刻Ｚ−０ｍｓにＩＰに到達したパケットはドライバＢに直ちに転送される。ドライバＢでは、図４に示す「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）、すなわち図５のフローチャートが実行され、図５のステップＳ１１→ステップＳ１２と進んでドライバＢのキューＱ２に登録される。さらにステップＳ１５に進んで送信スレッドが起動される。
【０１０７】
すると、今度は、図６のステップＳ２１→ステップＳ２２→ステップＳ２３と進む。すなわち、ドライバＢの送信スレッドがスリープ状態から起動し（ステップ２１）、Ｑ２からパケットが取り出され（ステップＳ２２）、経過時間ｔが
ｔ＝現在の時刻−時刻（７個前のパケット番号）
＝Ｚｍｓ−時刻（１）の時刻
＝Ｚｍｓ−（Ｚ−７０ｍｓ）
＝７０ｍｓ
と、算出される（ステップＳ２３）。
【０１０８】
ここで、第１の閾値時間Ｘ・Ｔ１は、
Ｘ・Ｔ１＝８×４＝３２ｍｓ
であるので、
ｔ＝７０ｍｓ＞Ｘ・Ｔ１＝３２ｍｓ
であり、ステップＳ２４では「偽」（待ち不要）と判定される。すなわち、ここでは、ステップ２５の待ち処理は行われずに、制御表の、時刻（直近のパケット番号）＝時刻（０）に現在の時刻が記録されて（ステップＳ２６）Ｑ２から取り出したパケットが直ちに送信される（ステップＳ２７）。そして、制御表の、７個前のパケット番号、および直近のパケット番号に１が加えられて、それぞれ２、１となる（ステップＳ２８）。
【０１０９】
時刻Ｚ〜Ｚ＋１０ｍｓの間のどこか（例えば時刻Ｚ＋５ｍｓ）から時刻Ｚ＋１００−０ｍｓまでの間はドライバＢにはＣＰＵが割り当てられていなかったためパケットの送信処理が中断している。そのため、時刻Ｚ＋１００−０ｍｓの時点では、ＩＰのキューＱ１に１０個のパケットが溜まった状態となる。
【０１１０】
時刻Ｚ＋１０＋０ｍｓ時点では、ドライバＢにＣＰＵが再び割り当てられて送信処理が再開したため、ＩＰのキューＱ１に溜まっていた１０個のパケットがドライバＢに転送され、図４〜図６に示す送信処理が再開される。
【０１１１】
これら１０個のパケット全てについて図５のステップＳ１１の判定結果は「含まれる」であり、それら１０個のパケット全てがドライバＢのキューＱ２に登録され（ステップＳ１２）、ドライバＢの送信スレッドが起動される（ステップＳ１５）。
【０１１２】
図６のステップＳ２３で算出される経過時間ｔは、Ｑ２に登録された１０個のパケットのうちの１〜７個目のパケットに関し、
パケット番号１：ｔ＝Ｚ＋１００ｍｓ−時刻（２）＝Ｚ＋１００−（Ｚ−６０）＝１６０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号２：ｔ＝Ｚ＋１００ｍｓ−時刻（３）＝Ｚ＋１００−（Ｚ−５０）＝１５０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号３：ｔ＝Ｚ＋１００ｍｓ−時刻（４）＝Ｚ＋１００−（Ｚ−４０）＝１４０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号４：ｔ＝Ｚ＋１００ｍｓ−時刻（５）＝Ｚ＋１００−（Ｚ−３０）＝１３０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号５：ｔ＝Ｚ＋１００ｍｓ−時刻（６）＝Ｚ＋１００−（Ｚ−２０）＝１２０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号６：ｔ＝Ｚ＋１００ｍｓ−時刻（７）＝Ｘ＋１００−（Ｚ−１０）＝１１０ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号７：ｔ＝Ｚ＋１００ｍｓ−時刻（０）＝Ｚ＋１００−Ｚ＝１００ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるためステップＳ２５における待ち処理はスキップされる。
【０１１３】
８個目のパケットについては、
パケット番号０：ｔ＝Ｚ＋１００ｍｓ−時刻（１）＝Ｚ＋１００−（Ｚ＋１００）＝０ｍｓ＜３２ｍｓ＝Ｘ・Ｔ１
であるため、
Ｘ・Ｔ２−ｔ＝８×６−０＝４８ｍｓ
の待ちが挿入される。
【０１１４】
この待ちを行なっている４８ｍｓの間の各時刻Ｚ＋１１０、Ｚ＋１２０、Ｚ＋１３０、Ｚ＋１４０ｍｓに、それぞれ１個づつ（合計４個）のパケットがドライバＢに到着し、それらのパケットは、図５の処理によりドライバＢのキューＱ２に登録される。
【０１１５】
時刻Ｚ＋１４８ｍｓに達した時点で、先ずは８個目のパケット（パケット番号０）が送信され、９個目、１０個目のパケット（パケット番号１，２）も、
パケット番号１：ｔ＝Ｚ＋１４８ｍｓ−時刻（２）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号２：ｔ＝Ｚ＋１４８ｍｓ−時刻（３）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため直ちに送信される。
【０１１６】
さらに、時刻Ｚ＋１００ｍｓ〜Ｚ＋１４８ｍｓの間に到着した４個のパケット（パケット番号３、４、５、６）についても、
パケット番号３：ｔ＝Ｚ＋１４８ｍｓ−時刻（４）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号４：ｔ＝Ｚ＋１４８ｍｓ−時刻（５）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号５：ｔ＝Ｚ＋１４８ｍｓ−時刻（６）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号６：ｔ＝Ｚ＋１４８ｍｓ−時刻（７）＝Ｚ＋１４８−（Ｚ＋１００）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため、時刻Ｚ＋１４８ｍｓの時点で直ちに送信される。
【０１１７】
時刻１５０ｍｓに到着したパケット（パケット番号７）は、
パケット番号７：ｔ＝Ｚ＋１５０ｍｓ−時刻（８）＝Ｚ＋１５０−（Ｚ＋１４８）＝２ｍｓ＜３２ｍｓ＝Ｘ・Ｔ１
であるため、
Ｘ・Ｔ２−ｔ＝８・６−２＝４６ｍｓ
の待ちが挿入される。ここで求めた４６ｍｓは時刻Ｚ＋１５０ｍｓからの間隔であるため、時刻Ｚ＋１４８ｍｓからの間隔は４８ｍｓとなる。つまり、Ｚ＋１５０ｍｓ＋４６ｍｓ＝Ｚ＋１９６ｍｓまでは送信を待つことになる。
【０１１８】
この待ちをしている間、時刻Ｚ＋１６０，Ｚ＋１７０，Ｚ＋１８０，Ｚ＋１９０ｍｓに各々１個のパケットがドライバＢに到着するが、Ｚ＋１５０ｍｓに到着したパケットが未送信であるため、ドライバのキュー（Ｑ２）でそのまま待つことになる。
【０１１９】
時刻１９６ｍｓに達したとき、まず１５０ｍｓの時点でに到着していたパケット（パケット番号６）が送信され、各時刻Ｚ＋１６０，Ｚ＋１７０，Ｚ＋１８０，Ｚ＋１９０ｍｓに到着していたパケットについても、
パケット番号０：ｔ＝Ｚ＋１９６ｍｓ−時刻（１）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞ ２ｍｓ＝Ｘ・Ｔ１
パケット番号１：ｔ＝Ｚ＋１９６ｍｓ−時刻（２）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号２：ｔ＝Ｚ＋１９６ｍｓ−時刻（３）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
パケット番号３：ｔ＝Ｚ＋１９６ｍｓ−時刻（４）＝Ｚ＋１９６−（Ｚ＋１４８）＝４８ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため、直ちに送信される。
【０１２０】
時刻２００ｍｓに達したとき、パケットがドライバＢに１個到着するが、そのパケットは、
パケット番号４：ｔ＝Ｚ＋２００ｍｓ−時刻（５）＝Ｚ＋２００−（Ｚ＋１４８）＝５２ｍｓ＞３２ｍｓ＝Ｘ・Ｔ１
であるため、直ちに送信される。
【０１２１】
これ以降、時刻Ｚ＋２１０ｍｓ，Ｚ＋２２０ｍｓ，Ｚ＋２３０ｍｓ…と１０ｍｓおきに到着するパケットについても、
ｔの値（現在時刻と７個前のパケットの送信時刻の差）が３２ｍｓより小さくなることはないため、いずれも直ちに送信される。
【０１２２】
この図１０に示すように、本実施形態によれば、パケットを配信サーバ内に大量に溜め込むことが避けられ、かつ配信サーバから外に送信されたパケットの廃棄も回避される。
【０１２３】
次に第２実施形態の各種変形例を説明する。
【０１２４】
上記の第２実施形態では、送信先ポート番号はユーザが既に知っているか又はアプリケーションが知っていることを前提としている。これに対し、以下の第１変形例では、ドライバがストリーミング配信用パケットを識別し、そのパケット自体からポート番号を自動認識する例である。ポート番号自動認識処理を行なう場合はユーザあるいはアプリケーションはストリーミング配信用パケットを識別するための条件を、ドライバＢにコンフィギュレーションプロパティ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｒｏｐｅｒｔｉｅｓ）などで通知しておく構成としてもよい。通知しておけば、その条件に合致したパケットが本件における処理の対象となる。特に通知がない場合は、ＴＣＰ／ＵＤＰであるか、それ以外のパケットであるかという点のみを判定し、ＴＣＰがストリーミング配信に使用されている場合はＴＣＰパケット全てが、ＵＤＰならばＵＤＰパケット全てが処理の対象となる。
【０１２５】
図１１は、この第１変形例における制御表の初期状態を示す図である。
【０１２６】
この第１変形例では、ドライバＢの起動時に、図１１に示すような制御表のフォーマットのみの制御表が作成される。送信ポート番号はドライバＢの動作開始後に自動認識されて各送信ポート番号ごとの領域が作成され、図３と同形式の制御表が形成される。
【０１２７】
この第１変形例においても、図４に示す送信処理が行われる。ただし、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）のアルゴリズムは前述の第２実施形態のアルゴリズム（図５参照）とは異なっている。
【０１２８】
図１２は、この第１変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）の処理内容を示したフローチャートである。
【０１２９】
この図１２における、各ステップＳ１１〜ステップ１５は、前述の第２実施形態においては図５の各ステップＳ１１〜ステップＳ１５とそれぞれ同一の処理内容であり、ここでの重複説明は省略する。
【０１３０】
ステップＳ３１ではポート番号自動認識処理が行われる。次いで、制御表にポート番号が追加されたか否かが判定され（ステップＳ３２）、ポート番号が追加されたときはステップＳ１２に進み、追加されなかったときはステップ１３に進む。
【０１３１】
図１３は、図１２におけるポート番号自動識別処理（ステップ３１）のフローチャートである。
【０１３２】
ここでは先ず、判定対象のパケットがストリーミング配信用パケットの条件に合致するか否かが判定される（ステップＳ３１１）。合致するときは、ステップＳ３１２に進み、制御表にそのパケットのポート番号の行が追加され、かつメモリ（図示せず）上にそのポート番号用のキューが１個生成される。さらに、そのキューのベースアドレスが制御表に追加され、Ｘ−１個前のパケット番号＝０、直近のパケット番号＝Ｘ−１、時刻（０）〜時刻（Ｘ−１）＝Ｓで初期化される（図３参照）。時刻Ｓは、図３での説明と同じく、送信開始よりも十分に辿った時刻である。
【０１３３】
図１３のステップＳ３１１で、ストリーミング配信用パケットの条件に合致しないと判定されると、制御表に追加することなくこのポート番号自動認識処理を通過する。
【０１３４】
この第１変形例によれば、ストリーミング配信用のパケットの送信先ポート番号が自動認識される。
【０１３５】
図１４は、第２変形例における、図４の中の「キューイングおよびストリーミング配信以外のパケット送信部」（ステップＳ０１）の処理内容を示した図である。
【０１３６】
この図１４におけるステップＳ１１〜ステップＳ１５も、図１２の場合と同様、図５におけるステップＳ１１〜ステップＳ１５とそれぞれ同一であり、重複説明は省略する。
【０１３７】
ステップＳ４１では、
ｔ＝現在の時刻−時刻（Ｘ−１個前のパケット番号）
が計算される。
【０１３８】
ステップＳ４２ではキューに既にパケットが存在するか否か、およびｔ≦Ｘ・Ｔ１を満足するか否かが判定される。キューに既にパケットが存在するときは、今回のパケットもキューに登録される（ステップＳ１２）、また、キューは空であってもｔ≦Ｘ・Ｔ１を満足するときは、この場合もステップＳ１２に進み、今回のパケットがキューに登録される。
【０１３９】
パケットが空であって、かつｔ＞Ｘ・Ｔ１のときは、待ち処理は不要であり、この第２変形例では今回のパケットをキューに登録することなく、パケット送信のための処理が行われる。すなわち、この場合、制御表の、時刻（直近のパケット番号）に現在時刻が記録され（ステップＳ４３）、パケット送信処理が行われ（ステップＳ４４）、さらに、制御表のＸ−１個前のパケット番号、および直近のパケット暗号にそれぞれ１が加えられる（ステップＳ４５）。１を加えた結果、Ｘ−１を超えた場合は、０に戻される。
【０１４０】
前述の第２実施形態の場合、送信待ちをせず直ちに送信可能な状態にあっても一旦はキューに登録する処理が行われ（図５のステップＳ１２参照）、その後、送信スレッドを経由して送信が行われる。このようにキューへの登録や送信スレッドを経由させると僅かではあっても遅れが発生することになる。この第２変形例の場合、待ちが必要な場合だけキューに登録し、待ちが不要な場合はキューに登録せずにそのまま送信される。このため第２変形例によれば、キューに登録することにより発生する遅延を防止することができる。
【０１４１】
上記の第２実施形態、第１変形例および第２変形例は、図２に示すシステムにおける配信サーバ３０のドライバで実施することを前提にしたものである。ただし本件の実施形態は、図２に示すシステムを考えた場合であっても、配信サーバ３０のドライバのみで実現可能なものではなく、他の要素上でも実現可能である。以下にその例を説明する。
【０１４２】
図１５は、第２実施形態の第３変形例を示す図である。
【０１４３】
この図１５において、実線の矢印は処理の流れを表わし、点線の矢印はデータの参照または書き込みを表わしている。
【０１４４】
この図１５に示す第３変形例は、前述の第２実施形態と同等の処理を図２の配信サーバ３０のアダプタＢで実施する例である。
【０１４５】
ここでも制御表６５が作成される。制御表については説明済みであり、ここでの重複説明は省略する。ドライバＢで実施する場合は、制御表は配信サーバ３０のメインメモリ上に作成されるが、アダプタで実施する場合は、制御表はアダプタ内のメモリに作成される。
【０１４６】
上記の第２実施形態においてユーザまたはアプリケーションからドライバに通知されていた情報（ポート番号、パラメータＸ、Ｔ、Ｔ１などの値）は、この第３変形例（アダプタでの実施）においては、ドライバに通知された後ドライバからさらにアダプタに通知される。このアダプタで実施する場合も、上述の第１変形例と同様、ポート番号自動認識処理を行なうことも可能である。
【０１４７】
アダプタＢは、送信用パケットをドライバＢから受け取り、中継器Ａ４１（図２参照）に向けて送信する。
【０１４８】
アダプタＢは、ドライバＢからパケットを受け取ると、先ずポート番号自動判定部６１において、今回受け取ったパケットが制御表６５に登録されているポート番号のパケットであるか否かが判定される。制御表６５には登録されていないポート番号のパケットであったときは、ここでの制御対象外のパケットであるので、キューイング部６２および待ち挿入部６３を何もせずに通過し、送信処理部６４によりそのまま送信される。このポート番号自動判定部６１における処理は前述の第２実施形態として説明した図５のステップＳ１１に相当する。また、制御表６５に登録されてないポート番号のパケットの送信処理は図５のステップＳ１３に相当する。
【０１４９】
ポート番号自動判定部６１で制御表６５に登録されているポート番号のパケットであると判定されると、そのパケットはキューイング部６２により、キュー６６に登録される（図５のステップＳ１２に相当する）。
【０１５０】
待ち挿入部６３は、制御表６５を参照して、キューに登録されたパケットの送信を待つ必要があるか否かを判定し、待つ必要があると判定した場合に計算で求めた時間だけ待った後に送信処理部６４に送信を指示する。一方、待ち挿入部６３は、パケットの送信を待つ必要がないと判定したときは送信処理部６４に対しパケットの送信を直ちに指示する。
【０１５１】
送信処理部６４は、待ち挿入部６３からの送信指示を受けキュー６６からパケットを取り出して中継器Ａに向けて送信する。
【０１５２】
待ち挿入部６３および送信処理部６４の処理は、前述の第２実施形態における図６に示す処理に相当する。ただし、図６の処理では、キューからパケットを取り出した後、必要に応じてパケットを待たせているが、図１５の場合は必要に応じて待ち時間を置いた後にキュー６５からパケットを取り出している点が異なっている。これはドライバとアダプタという実施箇所が異なっていることに起因するものではなく、いずれにおいても実施可能な変形例である。
【０１５３】
図１６は第４変形例における制御表を示した図である。
【０１５４】
ここでは前述の第２実施形態の機能を図２に示す配信サーバ３０のアプリケーションに搭載した例を説明する。
【０１５５】
アプリケーションにおいてもドライバと同様な処理が可能である。
【０１５６】
ただし、アプリケーションの１個のプロセス（またはスレッド）は、１個のＴＣＰポートまたはＵＤＰポートに対応している。このため、アプリケーションの各プロセス（またはスレッド）では複数のＴＣＰポートまたはＵＤＰポートを制御する必要はなく、制御表は図１６に示す例のように１つのポート番号のみの制御表となる。この制御表の各欄については図３で説明済みであり、ここでの説明は省略する。
【０１５７】
なお、アプリケーションで実施した場合、このアプリケーションでの実施を実効あるものにするためには、アプリケーションからドライバにデータが転送されるまでの、ＴＣＰ（またはＵＤＰ）層およびＩＰ層（図２参照）でバーストが発生しないことが前提条件となる。
【０１５８】
次に、図２の中継器Ａで実施した例を第５変形例として説明する。
【０１５９】
図２に示す中継器Ｂ又はクライアント端末上に最小のキューが存在する場合、第２実施形態や各変形例の機能を中継器Ａに組み込んで、バッファ（キュー）のオーバフローを防止することも可能である。
【０１６０】
ただし、中継器で実施した場合、パラメータＴ、Ｘ、Ｔ１などを自動的に求めるのは困難な場合が多い。その場合は、それらのパラメータ等をユーザが中継器に直接に指定する必要がある。
【０１６１】
以上で各種変形例の説明を終了し、以下では、パラメータＴ、Ｘ、Ｔ１の決定方法の各１例を説明する。
【０１６２】
パラメータＴ、Ｘ、Ｔ１は、ユーザがあらかじめ知っていればユーザがその値を指定すればよいが、必ずしも知っているとは限らない。そこでここでは、測定プログラムを組み込み、その測定プログラムによって、それらの値を求める方法について説明する。また、配信サーバ３０上のアプリケーション、ドライバ、アダプタであれば、以下に説明するようにして自動的に求められた各値を自動測定することも可能である。ただし上述の通り、中継器はその測定プログラムを組み込んで実行させるほどの能力を持たない場合が多い。
【０１６３】
ここでは、ＴＣＰが使用されることを前提にして説明する。ＵＤＰの場合は変更が必要であり、その変更点については後述する。
【０１６４】
図１７は、測定プログラムの配置位置を示した図である。
【０１６５】
ＴＣＰが使用される場合はユニキャストで送信され、１個のＴＣＰポート番号が１個のクライアント端末に対応している。測定プログラムは、図１７に示す通り、配信サーバのＴＣＰ／ＩＰとドライバとの間で動作する。
【０１６６】
図２に示すエンコーダ２１からストリーミング配信のパケットが送信されている状態において測定プログラムを起動すると、以下の（１）〜（５）の手順で、Ｔ、Ｘ、Ｔ１の各値がこの順に決定される。
【０１６７】
（１）Ｔを求める。
【０１６８】
測定プログラムで多数（例えば１００００個）のパケットの送信間隔の平均を求め、その値をＴとする。パケット同士の時間間隔に偏りが発生している可能性もあるが、多数の平均をとれば、本来のパケット間隔Ｔとほぼ一致する。
【０１６９】
（２）Ｘを求める。
【０１７０】
測定プログラムでＫ個のパケットを溜め込んだあと、Ｋ個のパケットをパケット同士の時間間隔０で送信する。この場合、伝送路上では、パケット同士の間隔は、微小な時間間隔（ＩＥＥＥ８０２．３規定されたＩｎｔｅｒ Ｐａｃｋｅｔ Ｇａｐ）以上となるが、ストリーミング配信でのパケット同士の時間間隔に比べれば無視できるほど小さい。
【０１７１】
Ｋは２から初めて、３，４，５，６，・・・と１ずつ大きくしていく。
【０１７２】
Ｋ個のパケットを送信した後、ＴＣＰによる再送が検出されなければ、Ｋ＋１個のパケットを時間間隔０で送信する。
【０１７３】
このようにして時間間隔０で送信するパケット数Ｋを増やしていき、ＴＣＰによる再送が検出されたところで、そのときのＫから２を引いた数（Ｋ−２）をＸとする。
【０１７４】
図１８は、Ｘ＋１個のパケットを時間間隔０で送信した場合を示す模式図である。
【０１７５】
配信サーバからＸ＋１個のパケットが同時に送信されたものとする。
【０１７６】
その場合、先頭の１個のパケットは最小のキューを持つ装置の処理部によりその最小のキューから直ちに取り出され、２個目〜Ｘ＋１個目のＸ個のパケットによりその最小のキューが一気に満杯の状態となる。
【０１７７】
ただし、この場合、オーバフローは発生しない。
【０１７８】
図１９は、Ｘ＋２個のパケットを時間間隔０で送信した場合を示す模式図である。
【０１７９】
配信サーバからＸ＋２個のパケットが同時に送信された場合、最後（Ｘ＋２個目）の１個のパケットがキューに入りきらずオーバフローが発生する。これはパケットロストとなり、ＴＣＰによる再送が発生する原因となる。
【０１８０】
したがって上記の通り、ＴＣＰによる再送が検出された時点で、その時のＫから２を引いた数（Ｋ−２）がＸとなる。
【０１８１】
（３）Ｔ１を求める。
【０１８２】
はじめに、測定プログラムでパケットをＸ＋２個のパケット溜め込んだあと、Ｘ＋２個のパケットをパケット同士の時間間隔Ｍで送信する。
【０１８３】
Ｍは１ミリ秒からはじめて、２ミリ秒、３ミリ秒、４ミリ秒・・・と１ミリ秒ずつ大きくしていく。
【０１８４】
Ｘ＋２個のパケットをＭミリ秒間隔で送信した後、ＴＣＰによる再送が検出されれば、再度Ｘ＋２個のパケットを溜め込んで、Ｍの値を１増やす。
【０１８５】
Ｍミリ秒間隔でパケットを送信した後、ＴＣＰによる再送が検出されなければ、その時のＭをＭ＿２とする。
【０１８６】
次に、測定プログラムでパケットをＸ＋３個のパケット溜め込んだあと、Ｘ＋３個のパケットをパケット同士の時間間隔Ｍで送信する。ＭはＭ＿２からはじめて、以降Ｘ＋２個の時と同様な処理を行って、ＴＣＰによる再送が検出されなくなったときのＭをＭ＿３とする。
【０１８７】
次に、測定プログラムでパケットをＸ＋４個のパケット溜め込んだあと、Ｘ＋４個のパケットをパケット同士の時間間隔Ｍで送信する。ＭはＭ＿３からはじめて、以降Ｘ＋２個の時と同様な処理を行って、ＴＣＰによる再送が検出されなくなったときのＭをＭ＿４とする。
【０１８８】
以降、同様な処理をＸ＋ｎ個（ｎ＝５、６・・・）のパケットを溜め込んで繰り返す。
【０１８９】
Ｍ＿ｎが増えないことが何回か（例えば４回）連続で検出された場合、そのＭ＿ｎをＴ１とする。例えば、Ｍ＿１００＝Ｍ＿１０１＝Ｍ＿１０２＝Ｍ＿１０３となった場合、その値をＴ１とする。
【０１９０】
なおこの例では最小の時間の刻みを１ミリ秒としたが、Ｔ１を更に高精度に求める場合１００マイクロ秒などとしても同様な方式でＴ１を求めることが可能である。
【０１９１】
上記の方法で求めたＴ１が、経路上のキューでパケット１個が処理される時間に相当することを図を用いて説明する。
【０１９２】
図２０は、パケットを送信時間間隔Ｔ１で送信したときの様子を示す図である。
【０１９３】
経路上の最小のキューは最初は空、かつその最小のキューを持つ装置の処理部で処理中のパケットもなかったという前提とする。
【０１９４】
この場合、１個前に受信したパケットについて次のパケットを受信する直前に処理部での処理が完了しているためキューにパケットが溜まることはなく、パケットを何個送信してもキューのオーバフローは発生しない。
【０１９５】
尚ここでは、キューは空である、という前提を置いて説明したが、パケットを送信時間間隔Ｔ１で送信する場合、キューに１個分でも空きがあればオーバフローは発生しない。
【０１９６】
図２１は、パケットを送信時間間隔０．９９・Ｔ１で送信したときの様子を示す図である。
【０１９７】
ここでも、経路上の最小のキューは最初は空、かつ、その最小のキューを持つ装置の処理部で処理中のパケットもなかったという前提とする。
【０１９８】
最初のパケットは、キューを素通りしてその装置の処理部で処理が行なわれる。
【０１９９】
２番目のパケットが送信された時点では、最初のパケットが処理部で未だ処理中のためキューに一旦溜まる。その２番目のパケットがキューに一旦溜まった後、０．０１・Ｔ１後に１番目のパケットの処理が完了し、２番目のパケットが処理部に移される。
【０２００】
３番目のパケットが送信された時点では、２番目のパケットが処理部で処理されている途中であり、キューに一旦溜まる。２番目のパケットの処理は、３番目のパケットがキューに溜まった後０．０２・Ｔ１後に完了し、キューに溜めていた３番目のパケットが処理部に移される。
【０２０１】
このようにして、１０１個目のパケットの送信まではキューにパケットが１個溜まる状況が続く。１０２個目〜２０１個目のパケットの送信ではキューにパケットが２個溜まる状況となる。同様にして２０２個目〜３０１個目の送信ではキューにパケットが３個溜まる状況となる。さらに同様にして、１００・（Ｘ−１）＋２〜１００・Ｘ＋１個目のパケットの送信ではキューにパケットがＸ個溜まる状況となり、パケットを１００・Ｘ＋２個送信するとキューがオーバフローする。ここでもキューは最初は空の状態にあることを前提としたが、キューに既にパケットが溜まっている状態では更に早い時点でオーバフローが発生する。
【０２０２】
このように、送信時間間隔がＴ１以上でパケットを送信すると最小のキューでのオーバフローが避けられ、Ｔ１よりも僅かでも短い時間間隔でパケットを送信すると最小のキューでオーバフローが発生する。
【０２０３】
したがって、上記（３）の方法により、最小のキューに収容されているパケットがその最小のキューから順次取り出される時間間隔Ｔ１が求められる。
【０２０４】
（４）表示または設定
上記（１）〜（３）により求められたＴ、Ｘ、Ｔ１は、ディスプレイ（図示せず）上に表示される。あるいは、これらの値Ｔ、Ｘ、Ｔ１は、測定プログラムによりアプリケーション、ドライバ、又はアダプタに自動設定される。
【０２０５】
（５）測定プログラム終了
測定プログラムの実行が終了する。測定プログラムは、起動した後、（１）〜（４）を行なえば自動的に終了する。
【０２０６】
以上の各パラメータＴ、Ｘ、Ｔ１の決定方法は、ストリーム配信にＴＣＰが使用されていることを前提とする求め方である。そこで次に、ＴＣＰに代わりＵＤＰが使用される場合のパラメータＴ、Ｘ、Ｔ１の決定方法を説明する。
【０２０７】
Ｔの決定方法については、ＴＣＰとＵＤＰで違いはなく、上記の（１）で説明した方法がそのまま採用可能である。
【０２０８】
ＵＤＰの場合は、ＴＣＰのように再送処理は存在しない。
【０２０９】
また、ＴＣＰはユニキャストの送信しかできないので、ポート番号は１個のクライアント端末に対応していたが、ＵＤＰでは多くの場合マルチキャストでの送信が行われており、その場合、ポート番号は複数のクライアント端末に対応している。
【０２１０】
ＵＤＰの場合は、そのポート番号が対応しているクライアント端末のどれか１台に、パケットロストを検出して送信元に通知するパケットロスト検出プログラムを導入する。パケットロスト検出プログラムがパケットロストを検出し、その結果を配信サーバ側に送り返すことで、上記の（２）、（３）と同様な方法で、Ｘ、Ｔ１を決定することができる。
【０２１１】
図２２、２３では、ＵＤＰを使用した場合の、測定プログラムおよびパケットロストプログラムの各動作位置を示した図である。
【０２１２】
図２２には、図２２（Ａ）に示すように測定プログラムが配信サーバのＵＤＰ／ＩＰとドライバとの間で動作し、図２２（Ｂ）に示すようにパケットロストプログラムがクライアント端末のＵＤＰ／ＩＰとドライバとの間で動作することが示されている。また図２３には、図２３（Ａ）に示すように、測定プログラムが配信サーバのアプリケーションとＵＤＰ／ＩＰとの間で動作し、パケットロストプログラムがクライアント端末のアプリケーションとＵＤＰ／ＩＰとの間で動作することが示されている。
【０２１３】
このように、測定プログラムおよびパケットロストプログラムは、図２２に示すようにＵＤＰ／ＩＰとドライバとの間で動作させてもよく、図２３に示すようにアプリケーションとＵＤＰ／ＩＰとの間で動作させてもよい。
【符号の説明】
【０２１４】
１０ パケット送信装置
１１ パケット受信部
１２ 待ち処理部
１３ パケット送信部
１４ 経過時間判定部
１５ 制御表記憶部
１５ａ 制御表
１６ 制御表更新部
１７ 測定部
１８ 再送要求受信部
２０ コンテンツ
２１ エンコーダ
３０ 配信サーバ
４１ 中継器Ａ
４２ インターネット
４３＿１，４３＿２ 中継器Ｂ
５０＿１，５０＿２，・・・，５０＿ｎ クライアント端末
５１＿１，５１＿２，・・・，５１＿ｎ 映像装置
６１ ポート番号自動判定部
６２ キューイング部
６３ 待ち挿入部
６４ 送信処理部
６５ 制御表
６６ キュー
【特許請求の範囲】
【請求項１】
パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置であって、
パケットを受信するパケット受信部と、
受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取り出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定する経過時間判定部と、
前記経過時間判定部により、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行なう待ち処理部と、
前記未送信パケットを、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記待ち処理部による待ち処理を経ることなく送信し、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には前記待ち処理部による待ち処理を経た後に送信するパケット送信部とを有することを特徴とするパケット送信装置。
【請求項２】
前記パケット受信部におけるパケット平均受信時間間隔をＴ、および時間間隔Ｔ２をＴ１＜Ｔ２＜Ｔとしたとき、前記待ち処理部は、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、前記未送信パケットの送信を、前記現在時刻から（第２の閾値時間Ｘ・Ｔ−経過時間ｔ）の待ち時間だけ待たせる待ち処理を行なうものであることを特徴とする請求項１記載のパケット送信装置。
【請求項３】
直近の送信済パケットから数えてＸ−１個前の送信済パケットまでの、該直近の送信済パケットを含むＸ個の送信済パケットの各送信時刻が記録される制御表を記憶する制御表記憶部と、
前記パケット送信部による未送信パケットの送信を受けて前記制御表中の送信時刻を更新する制御表更新部とを有し、
前記経過時間判定部は、前記制御表を参照することにより前記Ｘ−１個前の送信済パケットの送信時刻を求めて前記経過時間ｔを算出し、該経過時間ｔと前記第１の閾値時間Ｘ・Ｔ１との大小を判定するものであることを特徴とする請求項１又は２のパケット送信装置。
【請求項４】
前記制御表は、各送信先ごとの各欄に、該各送信先に向けて送信された送信済パケットの各送信時刻が記録される制御表であって、
前記制御表更新部は、前記制御表中の送信時刻をパケットの送信先ごとに更新するものであることを特徴とする請求項３記載のパケット送信装置。
【請求項５】
前記制御表更新部は、パケットの送信先を監視し、新たな送信先に向けて送信されるパケットを検出すると前記制御表に該新たな送信先に対応する領域を追加するものであることを特徴とする請求項４記載のパケット送信装置。
【請求項６】
前記パケット受信部において順次受信する複数のパケットの受信間隔の平均値を算出することにより前記平均受信時間間隔Ｔを求める平均受信時間間隔算出部を有することを特徴とする請求項２から５のうちいずれか１項記載のパケット送信装置。
【請求項７】
複数個のパケットを送信先装置に向けてほぼ同時に送信する過程を、ほぼ同時に送信するパケットの個数を順次変更しながら繰り返し、再送要求の発生を免れる最大パケット数を検出することにより、該送信先装置に向けてパケットを送信したときの送信経路上に存在するキューのうちの前記最小のキーの収容可能なパケット数Ｘを求める収容可能パケット数検出部を有することを特徴とする請求項１から６のうちいずれか１項記載のパケット送信装置。
【請求項８】
複数個のパケットを所定の時間間隔で送信する過程を、パケットの個数および該所定の時間間隔を変更しながら繰り返して、パケットの個数を増やしても再送要求が検出されない最短の時間間隔を検出することにより、前記時間間隔Ｔ１を求めるキュー取出し時間検出部を有することを特徴とする請求項１から７のうちいずれか１項記載のパケット送信装置。
【請求項９】
パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信方法であって、
パケットを受信し、
受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定し、
前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行ない、
前記未送信パケットを、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記待ち処理を経ることなく送信し、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には前記待ち処理を経た後に送信することを有することを特徴とするパケット送信方法。
【請求項１０】
プログラムを実行する演算処理装置内で実行され、該演算処理装置内に、パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置を構築するパケット送信プログラムであって、
前記演算処理装置内に、
パケットを受信するパケット受信部と、
受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定する経過時間判定部と、
前記経過時間判定部により、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行なう待ち処理部と、
前記未送信パケットを、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記待ち処理部による待ち処理を経ることなく送信し、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には前記待ち処理部による待ち処理を経た後に送信するパケット送信部とを有するパケット送信装置を構築することを特徴とするパケット送信プログラム。
【請求項１】
パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置であって、
パケットを受信するパケット受信部と、
受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取り出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定する経過時間判定部と、
前記経過時間判定部により、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行なう待ち処理部と、
前記未送信パケットを、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記待ち処理部による待ち処理を経ることなく送信し、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には前記待ち処理部による待ち処理を経た後に送信するパケット送信部とを有することを特徴とするパケット送信装置。
【請求項２】
前記パケット受信部におけるパケット平均受信時間間隔をＴ、および時間間隔Ｔ２をＴ１＜Ｔ２＜Ｔとしたとき、前記待ち処理部は、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、前記未送信パケットの送信を、前記現在時刻から（第２の閾値時間Ｘ・Ｔ−経過時間ｔ）の待ち時間だけ待たせる待ち処理を行なうものであることを特徴とする請求項１記載のパケット送信装置。
【請求項３】
直近の送信済パケットから数えてＸ−１個前の送信済パケットまでの、該直近の送信済パケットを含むＸ個の送信済パケットの各送信時刻が記録される制御表を記憶する制御表記憶部と、
前記パケット送信部による未送信パケットの送信を受けて前記制御表中の送信時刻を更新する制御表更新部とを有し、
前記経過時間判定部は、前記制御表を参照することにより前記Ｘ−１個前の送信済パケットの送信時刻を求めて前記経過時間ｔを算出し、該経過時間ｔと前記第１の閾値時間Ｘ・Ｔ１との大小を判定するものであることを特徴とする請求項１又は２のパケット送信装置。
【請求項４】
前記制御表は、各送信先ごとの各欄に、該各送信先に向けて送信された送信済パケットの各送信時刻が記録される制御表であって、
前記制御表更新部は、前記制御表中の送信時刻をパケットの送信先ごとに更新するものであることを特徴とする請求項３記載のパケット送信装置。
【請求項５】
前記制御表更新部は、パケットの送信先を監視し、新たな送信先に向けて送信されるパケットを検出すると前記制御表に該新たな送信先に対応する領域を追加するものであることを特徴とする請求項４記載のパケット送信装置。
【請求項６】
前記パケット受信部において順次受信する複数のパケットの受信間隔の平均値を算出することにより前記平均受信時間間隔Ｔを求める平均受信時間間隔算出部を有することを特徴とする請求項２から５のうちいずれか１項記載のパケット送信装置。
【請求項７】
複数個のパケットを送信先装置に向けてほぼ同時に送信する過程を、ほぼ同時に送信するパケットの個数を順次変更しながら繰り返し、再送要求の発生を免れる最大パケット数を検出することにより、該送信先装置に向けてパケットを送信したときの送信経路上に存在するキューのうちの前記最小のキーの収容可能なパケット数Ｘを求める収容可能パケット数検出部を有することを特徴とする請求項１から６のうちいずれか１項記載のパケット送信装置。
【請求項８】
複数個のパケットを所定の時間間隔で送信する過程を、パケットの個数および該所定の時間間隔を変更しながら繰り返して、パケットの個数を増やしても再送要求が検出されない最短の時間間隔を検出することにより、前記時間間隔Ｔ１を求めるキュー取出し時間検出部を有することを特徴とする請求項１から７のうちいずれか１項記載のパケット送信装置。
【請求項９】
パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信方法であって、
パケットを受信し、
受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定し、
前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行ない、
前記未送信パケットを、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記待ち処理を経ることなく送信し、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には前記待ち処理を経た後に送信することを有することを特徴とするパケット送信方法。
【請求項１０】
プログラムを実行する演算処理装置内で実行され、該演算処理装置内に、パケットを受信し受信したパケットを送信先装置に向けて送信するパケット送信装置を構築するパケット送信プログラムであって、
前記演算処理装置内に、
パケットを受信するパケット受信部と、
受信したパケットを送信先装置に向けて送信するときの送信経路上に存在する、送信されてきたパケットを一時的に収容しておくキューのうちの収容可能なパケットの数が最小のキューの収容可能なパケット数をＸ、該最小のキューに収容されているパケットが該最小のキューから順次取出される時間間隔をＴ１としたとき、直近の送信済のパケットから数えてＸ−１個前の送信済パケットの送信時刻から現在時刻までの間の経過時間ｔと、第１の閾値時間Ｘ・Ｔ１との大小を判定する経過時間判定部と、
前記経過時間判定部により、前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合に、未送信パケットの送信を延期させる待ち処理を行なう待ち処理部と、
前記未送信パケットを、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも大きいと判定された場合には前記待ち処理部による待ち処理を経ることなく送信し、前記経過時間判定部により前記経過時間ｔが前記第１の閾値時間Ｘ・Ｔ１よりも小さいと判定された場合には前記待ち処理部による待ち処理を経た後に送信するパケット送信部とを有するパケット送信装置を構築することを特徴とするパケット送信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１１−２５９３２９（Ｐ２０１１−２５９３２９Ａ）
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願番号】特願２０１０−１３３５１４（Ｐ２０１０−１３３５１４）
【出願日】平成２２年６月１１日（２０１０．６．１１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願日】平成２２年６月１１日（２０１０．６．１１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]