JP4933666B2

JP4933666B2 - データストリーム転送用のパケット内で利用可能な空間を計算する方法及び装置

Info

Publication number: JP4933666B2
Application number: JP2011024438A
Authority: JP
Inventors: マゼフレデリック; ナッソーエリック
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2010-02-09
Filing date: 2011-02-07
Publication date: 2012-05-16
Anticipated expiration: 2031-02-07
Also published as: FR2956271A1; FR2956271B1; JP2011193445A; US8792368B2; US20110194439A1

Description

優先権出願の参照
本願の請求項は、２０１０年２月９日に出願されたフランス国特許出願第１０５０８９２号の優先権を有し、参照することによって本明細書に組み込まれる。

本発明の分野
本発明は、データストリーム転送用のパケットで利用可能な空間を計算する方法及びデバイスに関するものである。本発明は、特に、ペイロードデータ、特に、マルチメディアデータのパケット形成（「パケット化」）に適用し、より詳しくは、ペイロードデータをネットワークパケット内に配置するために、そのネットワークパケットで利用可能な空間を計算することに適用する。

本発明の技術分野は、パケット通信用のネットワーク、及びインターネットあるいは、ＩＰ（「インターネットプロトコル」）タイプのローカルネットワーク群のようなネットワーク内でのマルチメディアデータ（オーディオ、ビデオ、テキスト）の転送用のネットワークの技術分野である。

インターネットあるいはＬＡＮ（「ローカルエリアネットワーク」に対する頭字語）を介するマルチメディアデータストリームの送信の状況では、マルチメディアデータサーバは、１つ以上のデータストリーム（ビデオタイプ、オーディオタイプ、テキストタイプ、例えば、サブタイトル等）を１つ以上のクライアントへ同時に配信しなければならない。これらのクライアントは、それらのデータを受信して、その受信に応じてデータをプログレッシブに活用する。例えば、クライアントは、ビデオを表示して、そのビデオを受信しながらプログレシッブにオーディオを再生する。これは、「マルチメディアストリーミング」と呼ばれる。

一般的には、これらのマルチメディアストリーム（ビデオ、オーディオ、テキスト）を構築するデータは記憶することができ、また、場合によっては、前もって、データサーバ（例えば、マルチメディアハードディスク）において圧縮することができ、あるいは、一方で、キャプチャされ、かつ場合によっては、ストリーミングしながら圧縮することができる（例えば、ネットワークカメラの場合）。これらのデータは、いくつかの部分のペイロードデータに分割され、これらのペイロードデータは、可変数のヘッダ群あるいは拡張群を追加することによってパケット化される。これらのヘッダ群と拡張群は、特に、様々なプロトコルレイヤあるいは使用される様々なサービスとに関連づけられているチェック情報を含んでいる。そして、これらは、ネットワーク群を介して受信先へ転送することができるパケットを形成する。マルチメディアデータストリーム群の転送に適合されているプロトコルの例には、ＵＤＰ／ＩＰプロトコル群（「ユーザデータグラムプロトコル」に対する頭字語であるＵＤＰ）におけるＲＴＰ（「リアルタイム転送プロトコル」に対する頭字語）がある。

効率性のために、下位のプロトコルレイヤ群によるパケットのフラグメンテーションを防止しながら、これらのＲＴＰネットワークパケット群は、一般的には、物理ネットワーク上で使用される転送プロトコルによって設定される最大有効サイズを有している。例えば、「イーサネット（登録商標）」タイプのネットワークにおいては、パケットの最大有効サイズは、一般的には１５００バイトに制限される。この最大有効サイズは、ペイロードデータと、様々なプロトコルレイヤによって要求されるデータヘッダのセットとの間で共有される。例えば、追加のＵＤＰ／ＩＰヘッダ群の後には、ＲＴＰパケットは１４７２バイトに制限される。

アプリケーションの観点からは、ネットワークの有効レートを最大化するためには、ネットワークパケット内の最大許容空間を占有するように、ペイロードデータを分割することが重要である。マルチメディアストリームをペイロードデータに分割することは、エンコーディングの時、あるいはパケット化の時のどちらかで動的に適合させることができる。エンコーダでの適合は、例えば、画像部分群（「スライス群」）のサイズ、あるいはオーディオ部分群（「サンプル群」）のサイズを変更することによって、ストリーミングしながら、圧縮が実行される場合に可能である。後者が同一のネットワークパケット（例えば、「Ｈ．２６４」パケット化によるものとしての）に、ペイロードデータのいくつかの部分をフラグメント化するあるいは組み合わせることを可能にする場合に、パケット化の時の適合が可能である。

これらのデータが一旦分割されると、当業者には周知の技術によって、ペイロードデータをバッファメモリの正規の位置に直接配置するとともに、その位置から続けてすべてのヘッダを追加することを可能にする十分な空間をバッファメモリの開始位置で残している。これらのヘッダは、ペイロードをコピーしたりあるいは移動することなく、様々なプロトコルレイヤによってプログレシッブに追加される。この技術は、メモリリソースとプロセッサリソースの観点からは有効である。

ペイロードデータに対するネットワークパケットで利用可能なサイズを判定することは課題となっており、また、バッファメモリに配置すべきデータをスタートする位置を判定することも課題となっている。

また、サーバは、いくつかのクライアントに同時に同一のマルチメディアデータストリームを送信することができる。例えば、マルチ−ユニキャストでは、異なるユニキャスト通信が、各クライアントとサーバとの間で確立される。各ネットワークパケットは、続けてクライアントのそれぞれに送信される。その場合、ペイロードデータの同一の項目が、いくつかの異なるクライアントに送信され、また、ヘッダのみが各クライアントに適合される。ペイロードデータのサイズを判定するために、メモリ内を移動させることなく、すべてのクライアントに送信されるべきペイロードデータの項目について、クライアントのそれぞれのヘッダ制約が順番に考慮される。

また、各クライアントは、様々なサービス（輻輳制御サービス、例えば、再送信メカニズムあるいはデータ冗長性メカニズムのいずれか一方に基づく送信誤り訂正サービス）の使用をネゴシエートすることができる。これらのサービスは、オリジナルデータストリームに従属するデータサブストリームの作成を要求することができる（例えば、オリジナルデータストリームに加えて、再送信データストリームあるいは冗長データストリーム）。これらのサービスは、また、オリジナルデータストリームあるいはデータサブストリーム、あるいはそれらの両方に同時に、ヘッダ形成時に補助的な情報の追加を要求することができる。例えば、再送信の場合、メインストリームからパケットの損失がある場合、損失したパケットは、関係のあるストリーム（サブストリームとして指定されることになる）で再送信されなければならない。ＲＴＰによる再送信メカニズムを記載するＲＦＣ４５８８（「ＲＴＰ再送信ペイロードフォーマット」、ＩＥＴＦ、ＲＦＣ４５８８、２００６年７月）に記載されるように、２つの補助バイトのヘッダが、損失したオリジナルパケットのシーケンス数を記述するために、オリジナルペイロードデータに追加されなければならない。つまり、マルチメディアデータを複数の部分に分割する時点で、このような可能性を提供する必要がある。逆の場合には、マルチメディアデータの項目は、ネットワークパケット内の空間の欠如によって再送信することができない場合があるという可能性がある。

また、この補助的な情報のいくつかは、あるストリームから別のサブストリームへの永続的な特性を提供することができる。即ち、これは、オリジナルストリームと関連するサブストリームとの両方で繰り返されなければならず、あるいは、一方で、局所的な特性（ストリームに従属する）を有する場合がある。この２つ目の場合では、１つのストリームからサブストリームへのその永続的な特性が繰り返される必要はない。これらの制約も、ペイロードデータに対して利用可能なサイズを判定するために考慮されなければならず、そうすることで、それらは、フラグメンテーションあるいはメモリコピーを要求することなく、ストリームとサブストリームをすべてのクライアントへ送信することができる。

それぞれのクライアントによって使用される様々なサービスに対して適切となるように、また、メモリとプロセッサリソースに関して、最も効率的な方法ですべてのクライアントへ送信することを可能にするために、バッファメモリ群に配置するペイロードデータの最適サイズを任意の時間に判定することは特に複雑となる。

論文「プロトコルスタック設計に対するドライバベースの方法」（１９９９年、７月、エレクトニックエンジニアリングタイムズインディア（ｗｗｗ.ｅｅｔｉｎｄｉａ．ｃｏ．ｉｎ）発行、マイクロウェアシステム社、カートシュバデラー）が知られている。これは、ネットワークプロトコルスタックを設計することを可能にしながら、その効率性を改善する方法を記載している。これは、ネットワークサービスモジュールが、プロトコルスタックを構築するモジュール群それぞれに問い合わせることによって、ネットワークパケットのヘッダとトレーラ（trailer）に追加される情報の最大サイズを判定することを提案している。これは、作成時と、プロトコルスタックのそれぞれの変化時に、この動作を実行する。つまり、アプリケーションがメッセージ（例えば、「ハローワールド（hello world）」）を送信する場合、ネットワークサービス群のモジュールは、２つのバッファメモリを直接割り当てることができ、この２つのバッファメモリは、プロトコルスタックを構築するモジュール群のそれぞれによってパケットヘッダとパケットトレーラーそれぞれに追加される情報のすべてを含めるために十分に大きいものである。これらのモジュール群のすべてがしなければならないことは、任意の新規のメモリ割当あるいはコピーを行うことなく、これらのバッファメモリにこれらの情報を追加することである。この論文に記載される方法は、様々なタイプのヘッダ（永続的なあるいは局所的な）で、同一のペイロードデータのセットに対して、データサブストリームの存在あるいはいくつかの受信先の存在を管理することができないことを記述している。

２００３年５月のＭｏｂｉＳｙｓ２００３の議事録で発行された記事「８ビットアーキテクチャ用の完全ＴＣＰ／ＩＰ」（アダムデュンケルススウェーデンコンピュータ科学学会）も知られている。この文献には、コードサイズとメモリ消費に関して、８ビットハードウェアプラットホームと１６ビットハードウェアプラットホームで動作するように適合されている２つのＴＣＰ／ＩＰプロトコルスタックの実装を記載している。これは、特に、セクション５で、メモリの管理とバッファメモリ群の管理とを、数キロバイトのＲＡＭだけで済ませるようにするためにどのようにして最適化されるかについて記載している。特に、
−ネットワークパケット群は、固定サイズのバッファメモリに配置される。

このサイズは、コンパイル時の構成設定オプションによって判定される。

−バッファメモリ群は、ペイロードデータの前にパケットヘッダ情報を追加することができるＴＣＰ／ＩＰプロトコルスタックに対して十分な空間を含んでいて、このペイロードデータは、後のコピーを防止するためにバッファメモリの正規の位置に直接配置される。

−各バッファメモリは、リファレンスカウンタを含んでいる。これは、バッファメモリに対する新規のリファレンスがモジュールによって作成される毎にインクリメントされ、そのリファレンスが解放される毎にデクリメントされる。バッファメモリが一旦解放だけなされると、自身のリファレンスカウンタは値「０」に到達することになる。こうして、リファレンスカウンタは、バッファメモリからのコピーの回数を制限することを可能にする。

この実装では、様々な受信先、あるいはデータサブストリーム群の存在によって実際にアクティベートされるサービスに依存してサイズが変化するヘッダ群を管理することができない。

米国特許出願２００９／００２８１４２号「ネットアーク内のデータコンテンツのストリーミング」（ブレインケー．シュミット等による、２００７年７月）も知られている。これには、データストリーム群の生成にサマリー情報が含んでいる場合の符号化データストリーム群を送信するためのシステムを記載している。サマリー情報は、データ自身の補完として、ネットワークパケットのそれぞれに関連づけられる。次に、このサマリー情報は、ネットワークパケットの受信先に、少なくとも一部の受信パケットを、それらを完全に復号することなく処理することを可能にする。このサマリー情報は固定サイズであり、また、ＲＴＰヘッダとペイロードデータとの間に配置される１つ以上のヘッダの形式で、パケットのそれぞれに挿入される。ネットワークパケットで利用可能な空間は、サマリー情報のサイズ（例えば、８８バイトの固定サイズ）よりも少ないＲＴＰヘッダ（１２バイト）のサイズよりも更に少ないＵＤＰネットワークパケットの最大サイズ（１４７２バイト）であるペイロードデータに対して評価される。このシステムは、ネットワークパケットで利用可能となるペイロードデータのサイズを、様々な受信先あるいはデータサブストリームの存在によって実際にアクティベートされるサービス群に従って動的に管理することはできない。

本発明は、これらの欠点を解消することを目的とする。

結局のところ、第１の態様に従えば、本発明は、データストリーム転送用のパケットに利用可能な空間を計算する方法に関するものである。この方法は、
データストリーム転送用のパケットで利用可能な空間を計算する方法であって、
データストリームマネージャの各モジュールの要件であって、前記モジュールによって使用されるプロトコル及びサービスの少なくとも一方によって要求される少なくとも２つのタイプの、ヘッダデータ及び拡張のデータの少なくとも一方のデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップと、
異なるタイプのデータに対する空間要件を組み合わせるための異なるルールと、前記異なるタイプのデータに対する空間要件群の組み合わせの総和を使用することによって、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップと、
データストリーム転送に対して前記利用可能な空間を判定するために、前記パケットの空間と、前記パケットにおける前記最大空間要件との差分を計算するステップと
を備える。

本発明は、ネットワークパケットの生成において、ペイロードデータに追加される、様々なタイプの追加情報を管理することを可能にする。これには、例えば、永続性タイプあるいはストリーム従属タイプのペイロードヘッダ群、永続性タイプあるいは純粋なデータ従属タイプの基本的なＲＴＰヘッダ拡張群、及び固定サイズのヘッダ群（例えば、基本的なＲＴＰヘッダ群）がある。

本発明の実行によって、データストリームからのデータ、例えば、ペイロードデータは、決してデュプリケート／コピーされることはない。これは、たとえそれらのペイロードデータがいくかの受信先（マルチ−ユニキャストの場合）に送信される場合でも、あるいはたとえそれらのペイロードデータが同一のクライアントへ複数回送信されるものである場合でも、決してデュプリケート／コピーされることはない。つまり、システムは、より少ないメモリリソースとより少なくプロセッサリソースを消費する。

特定の特徴に従えば、本発明の方法は、
イベントを検出するステップであって、
前記データストリームを送信するためのネットワークにおける前記データストリームの受信クライアントへの到着、
前記ネットワークからの前記データストリームの受信クライアントからの発信、
前記データストリームマネージャの少なくとも１つのモジュールのアクティベーション、
前記データストリームマネージャの少なくとも１つのモジュールのデアクティベーション
のうちからのイベントを検出するステップと、
前記イベントに関与するデータストリームマネージャであって、前記要件群を判定するステップと前記計算するステップとを実行するデータストリームマネージャを判定するステップと
を更に備える。

つまり、ネットワークパケットにおけるデータストリームのデータに対して利用可能なサイズは常に最適となる。これは、クライアントがシステムへ接続する毎に、あるいはシステムから切断する毎に、また、クライアント群の１つによるサービスのアクティベーションあるいはデアクティベーション毎に、再評価される。

特定の特徴に従えば、前記少なくとも２つのタイプのデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップにおいて、前記タイプには、少なくとも１つの永続性拡張タイプと、少なくとも１つのデータストリーム従属拡張タイプを含んでいる。

特定の特徴に従えば、前記少なくとも２つのタイプのデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定するステップにおいて、前記タイプには、
少なくとも以下のタイプ群の１つと、
永続性ＲＴＰヘッダ拡張（ＰＨＥ）、
永続性ペイロードデータ拡張、
少なくとも以下のタイプ群の１つと、
データストリーム従属ＲＴＰヘッダ拡張（ＳＤＨＥ）、
データストリーム従属ペイロードデータ拡張（ＳＤＰＥ）
を含んでいる。

特定の特徴に従えば、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップにおいて、
永続性拡張タイプの空間要件群の組み合わせに対して、要件追加動作が実行され、
データストリーム従属タイプの空間要件群の組み合わせに対して、最大要件値抽出動作が実行される。

特定の特徴に従えば、前記各モジュールの要件を判定するステップにおいて、前記モジュールが前記データストリームのサブストリームのソースである場合、前記パケットの前記空間要件は、前記サブストリームの少なくとも２つのタイプのデータに対して判定される。

特定の特徴に従えば、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定するステップにおいて、前記データストリームの前記サブストリームのすべてに対して、各タイプのデータに対する前記サブストリームに対する要件群の最大値を抽出する動作が実行される。

特定の特徴に従えば、前記各モジュールの要件Ｒに合致する前記パケットにおける最大空間要件を判定するステップにおいて、前記データストリームマネージャＳと、前記データストリームマネージャによって承継されるサブストリーム群Ｓjを構成するモジュール群Ｍiのセットに対して以下の方程式群が実行されるものであって、
前記永続性ヘッダ拡張群ＰＨＥに対して、

が実行され、
前記データストリーム従属ヘッダ拡張群ＳＤＨＥに対して、

が実行され、
前記永続性ペイロードデータ拡張群ＰＰＥに対して、

が実行され、
前記データストリーム従属ペイロードデータ拡張群ＳＤＰＥに対して、

が実行され、
そして、総合要件Ｒ^E（Ｓ）を、以下の方程式で

計算し、
ここで、「Ｅ」は、拡張情報のタイプ、つまり、ＰＨＥ、ＳＤＨＥ、ＰＰＥ、あるいはＳＤＰＥのタイプの１つを示していて、Ｏ^Eは、以下のものを伴う、タイプＥに依存する演算式である
Ｏ^SDHEとＯ^SDPEは、演算式「ｍａｘ」に対応し、これは、値のペアの最大値を抽出する演算
Ｏ^PHEとＯ^PPEは、演算式「＋」に対応し、これは、値のペアの値を追加する演算
を伴う。

特定の特徴に従えば、本発明の方法は、前記差分を計算するステップの結果を示すことによって、考慮される前記データストリームのソースにリンクされているバッファメモリファクトリーでパケット空間を予約するステップと、前記バッファメモリファクトリーによって、予約空間に対するリクエスト群の最大値を計算して、前記データストリームからの新規のデータを新規のバッファメモリに配置するためのリクエストに応じて、前記バッファメモリの開始における予約空間に対するリクエスト群の最大値の関数として、前記データストリームからのデータを配置することができる位置からスタートするポインタを用いて、バッファメモリを与えるステップとを更に備える。

特定の特徴に従えば、本発明の方法は、前記データストリームのデータの各項目に対して、
前記ポインタの後に、前記バッファメモリに前記項目のデータを書き込むステップと、
前記項目のデータの受信先への各送信に対して、前記送信に関連付けられている前記データストリームマネージャの各モジュールに対してヘッダデータ及び拡張データの少なくとも一方のデータを書き込むステップと
を備える。

つまり、異なる受信先へ送信されるべきペイロードデータは、再送信リクエストに応答する時点ではあるいは誤り訂正データを追加する時点で、コピーされない、あるいは移動されない。

この方法は、つまり、前記２つのタイプの一方に従って、ヘッダデータ及び拡張データの少なくとも一方と、前記データストリームからのデータを含む第１のパケットを送信するステップを更に備え、また、場合によっては、前記２つのタイプの他方に従って、ヘッダデータ及び拡張データの少なくとも一方と、前記データストリームからのデータを含む第２のパケットを送信するステップを更に備える。

特定の特徴に従えば、本発明の方法は、ＲＴＰ（「リアルタイム転送プロトコル」）に従う前記データストリームからのデータを送信するステップを更に備える。

第２の態様に従えば、本発明は、データストリーム転送用のパケットで利用可能な空間を計算するデバイスに関するものである。このデバイスは、
データストリームマネージャの各モジュールの要件であって、前記モジュールによって使用されるプロトコル及びサービスの少なくとも一方によって要求される少なくとも２つのタイプの、ヘッダデータ及び拡張のデータの少なくとも一方のデータに対する前記パケットにおける空間に対する、前記各モジュールの要件を判定する手段と、
異なるタイプのデータに対する空間要件を組み合わせるための異なるルールと、前記異なるタイプのデータに対する空間要件群の組み合わせの総和を使用することによって、前記各モジュールの要件のすべてに合致する前記パケットにおける最大空間要件を判定する手段と、
データストリーム転送に対して前記利用可能な空間を判定するために、前記パケットの空間と、前記パケットにおける前記最大空間要件との差分を計算する手段と
を備える。

第３の態様に従えば、本発明は、コンピュータシステムにロードされるコンピュータプログラムに関するものであり、このコンピュータプログラムは、上述のような、本発明の方法の実行を可能にする命令群を含んでいる。

第４の態様に従えば、本発明は、コンピュータあるいはマイクロプロセッサによって読取可能な情報搬送媒体に関するものであり、これは、リムーバルであろうとなかろうと、上述の本発明の方法の実行をコンピュータプログラムに可能にさせる命令群を記憶する。

このデバイス、このプログラム、及びこの情報搬送媒体それぞれの、利点、目的及び特徴は、本発明の方法の目的及び特徴と同様であるので、ここでは、再度説明しない。

本発明の他の利点、目的及び特徴は、添付の図面とともに以下の説明から明らかになるであろう。尚、この説明は、限定するものではなく説明の目的で与えられるものである。
本発明を使用する場合の図である。本発明のデバイスの特定の実施形態を示すブロック図である。本発明の方法の特定の実施形態を実現するためのバッファメモリの内容を示す図である。図３に提示される内容に対して追加されているペイロードデータ拡張を含むバッファメモリの内容を示す図である。図４に提示される内容と比べて別の追加内容を含むバッファメモリの内容を示す図である。ＲＴＰヘッダの追加によってパケットをファイナライジングするためのバッファメモリの内容を示す図である。処理モジュールにリンクする、かつデータストリームマネージャの第１の例を示す図である。処理モジュールにリンクする、データストリームマネージャの第２の例を示す図である。データストリームに対して予約されている空間の最大サイズを計算するための、本発明によって提供される方法の第１の特定実施形態で実行されるステップ群のフロー図である。バッファファクトリーによってペイロードデータの最大サイズを計算するために実行されるステップ群のフロー図である。本発明のデバイスの特定の実施形態を示す図である。

明細書の全体において、以下の定義を使用する。

「バッファメモリ」：用語「バッファ」によって共通に示されるバッファメモリは、特に、同一のレートで動作しない機器の項目群の２つの処理の間において、一時的にデータを記憶するために使用されるランダムアクセスメモリあるいはディスクの領域である。

「パケット化」：転送するためのビットストリームをパケットにグルーピングする動作。一定数の情報の項目群が、例えば、どのパケットに属し、かつどこにアドレス指定されているかを示すために、ヘッダの形態で追加される。

「ＲＦＣ」（「requests for comment（コメントのリクエスト）」の頭字語）：文字どおり、これは、コメントのリクエストであり、より一般的には、インターネットの技術的知識を文書化している通し番号の電子文書である。いくつかのＲＦＣは規格になっていて、逆に、すべてのインターネット規格はＲＦＣからなる。

概要としては、各イベント時（クライアントからの発信時／クライアントへの到着時、あるいはクライアントによるサービスのアクティベーション時／デアクティベーション時）、イベントに関係するデータストリームマネージャのそれぞれは最大空間を判定する。この最大空間は、使用されるプロトコル群及びサービス群によって要求されるヘッダ群と拡張群を配置するためのネットワークパケットを要求するものである。このことについて、データストリームマネージャを構築するモジュールのそれぞれは問い合わせられ、そして、自身をいくつかのタイプに区別する、自身のメモリ空間要件を通知する。ペイロードデータのパケット化において、各モジュールは、以下のタイプに対応する拡張情報を追加することができる。

−永続的なＲＴＰヘッダ拡張（ＰＨＥ）
−データストリームに従属するＲＴＰヘッダ拡張（ＳＤＨＥ）
−永続的なペイロードデータ拡張（ＰＰＥ）
−データストリーム従属ペイロードデータ拡張（ＳＤＰＥ）
モジュール自身がサブストリームの基点である場合、そのモジュールは、再帰的に、そのサブストリームにリンクされているメモリ空間に対する要件群を判定する。

データストリームマネージャを構築するモジュール群のそれぞれによって表現される様々なタイプのメモリ要件は組み合わせされ、そして、最大予約メモリ空間が全体としてデータストリームマネージャに対して判定される。この組み合わせによる特定の動作群は、ここでは、組み合わせる情報のタイプに依存する。

次に、データストリームマネージャは、自身の予約空間要件を、ペイロードデータのソースにリンクされている「バッファファクトリー」を用いて記録する。このバッファファクトリーは、データストリームマネージャ群のそれぞれのメモリ空間予約リクエスト群のリストを保持する。このデータストリームマネージャ群はそのリストにリンクされていて、そのメモリ空間予約リクエスト群の最大値を計算する。エンコーダあるいはパケッタイザが、新規のペイロードデータをバッファメモリに配置するために、バッファファクトリーから新規のバッファメモリをリクエストする場合、バッファファクトリーは、エンコーダあるいはパケッタイザに、ペイロードデータソースにリンクされているデータストリームマネージャのすべてに対してバッファメモリの開始で予約される空間の最大値を考慮して配置することができるペイロードデータからスタートする位置のポインタを用いて、バッファメモリを与える。

図１に示されるように、本発明を使用する場合、送信機デバイスあるいはサーバ１０はペイロードデータ１４のパケット１６を、同一のマルチメディアデータストリーム１４から、データ通信ネットワーク１５を介して、いくつかの受信機デバイスあるいはクライアント１１、１２及び１３へ送信する。例えば、サーバ１０は、カメラによってキャプチャされるマルチメディアストリーム（ビデオ及びオーディオの少なくとも一方）を再送信することができる。通信ネットワーク１５は、例えば、無線ネットワーク（例えば、ＷｉＦｉ／８０２．１１ａ／ｂ／ｇ／ｎ）、あるいはローカルイーサネットネットワーク、あるいは、インターネットのような長距離ネットワークである。

ペイロードデータ１４は、ＲＴＰ（「リアルタイム転送プロトコル」）のようなデータのリアルタイム送信に適合されているプロトコル群を使用して送信される。このプロトコルは、典型的には、ＵＤＰ／ＩＰプロトコルを介して実現される。また、受信機デバイスは、例えば、ＲＴＣＰ制御プロトコルを使用して、送信機デバイスへフィードバック情報を提供することができる。このＲＴＣＰ制御プロトコルは、場合によっては、ＡＶＰＦプロファイル（ＡＶＰＦは、「フィードバック付きオーディオ−ビジュアルプロファイル（Audio-Visual Profile with Feedbacks）」の頭字語であり、ＲＦＣ４５８５（「リアルタイム転送制御プロトコル（ＲＴＣＰ）ベースのフィードバック（ＲＴＰ／ＡＶＰＦ）用拡張ＲＴＰプロファイル」、ＩＥＴＦ、ＲＦＣ４５８５、２００６年７月）に記載されている）を使用して拡張される。

各ネットワークパケット１６は、ペイロードデータ１４とプロトコルヘッダ群を含んでいて、また、場合によっては、これらのプロトコルヘッダ群の拡張群及びペイロードデータに対する拡張群の少なくとも一方を含んでいる。このペイロードデータに対する拡張群は、サーバ−クライアントのペアそれぞれによって実現されるサービス群に依存する。例えば、クライアント１３は、ＲＦＣ４５８８（「ＲＴＰ再送信ペイロードフォーマット」、ＩＥＴＦ、ＲＦＣ４５８８、２００６年７月）に記載される再送信サービス（ＲＴＸ）を使用する。ネットワークパケットが損失すると、ペイロードデータは、クライアントのリクエストで再送信することができる。この場合、ＲＦＣに従えば、ペイロードデータを含むパケットは、また、通常のヘッダに加えて、対応する損失したパケットのシーケンス番号を含む２バイトのペイロードデータに対する小拡張を備えている。

別の例では、クライアント１２は、ＲＦＣ５１０９（「汎用前方誤り訂正用ＲＴＰペイロードフォーマット」、ＩＥＴＦ、ＲＦＣ５１０９、２００７年１２月）に記載される誤り訂正サービス群（あるいは前方誤り訂正による「ＦＥＣ」）を使用するとともに、ＴＦＲＣ（「ＴＣＰフレンドリーレート制御（ＴＦＲＣ：TCP Friendly Rate Control）：プロトコル仕様」、ＩＥＴＦ、ＲＦＣ５３４８、２００８年７月）のような輻輳制御（ＣＣ）サービスを使用する。再送信サービスに対しては、誤り訂正サービス（ＦＥＣ）は、パケット群に対して更なる冗長情報の追加を要求し、また、輻輳制御サービスは、ＲＴＰヘッダ群の追加の拡張を要求すること場合がある。つまり、クライアント群のそれぞれに送信されるペイロードデータの同一の項目に対しては、ネットワークパケット１６は、ヘッダ群と、可変サイズの拡張群を含む場合がある。

以下の状況は、ストリーミングしながら符号化されるビデオストリームを送信する場合が考慮されるが、事前に符号化されるビデオストリームあるいはオーディオストリームを送信する場合も、完全に同様の方法で当業者によって取り扱うことができる（事前符号化データの場合では、図２を参照して説明されるエンコーダ２１１は、事前符号化データに読み換えることができる）。図２では、ブロック図は、マルチメディアストリームサーバ１０を記載している。

一般的には、送信対象のロー（生）データ（画像フレーム群）２０は、ソースブロック２１によって処理される。ソースブロック２１は、一連のバッファメモリ２１４に配置されることになるペイロードデータを取得するために、ローデータを処理するタスクを有している。バッファメモリ２１４のそれぞれは、異なる「ＩＰアドレス／ポート番号」の組み合わせによって識別されるネットワーク受信先に対応するデータストリームマネージャ２３、２４、２５及び２７（それぞれ、クライアント１１、クライアント１２及びクライアント１３で示されている）を介して連続的に処理される。これは、ユニキャストＩＰアドレス、及びマルチキャストＩＰアドレスの少なくとも一方の場合であり得る。

各データストリームマネージャは、追加情報をヘッダ群に追加することによって、場合によっては、通信ネットワーク１５によって、自身の受信先に送信されるパケットに対してペイロードデータ拡張情報を順番に追加することによって、バッファメモリ２１４からのペイロードデータを有効なＲＴＰパケットに変換するタスクを有している。データストリームマネージャによって演算することが可能となる前に、バッファメモリ２１４の内容は、特定のデータストリームマネージャに対するバッファメモリ２１４の内容を記述するタスクが与えられる、仮想ＲＴＰパケット（例えば、２２、２２’、２２”、あるいは２８）を記述するオブジェクトとメモリ内で関連づけられる。

仮想ＲＴＰパケット２２、２２’、２２”、及び２８は、特に、ペイロードデータの位置を指定し、かつ、バッファメモリ２１４に存在するペイロードデータに対する一定のヘッダ群及び拡張群の位置を指定する、バッファメモリ２１４へのポインタ群を含んでいる。各データストリームマネージャは、１つ以上の処理モジュール群（例えば、２３１、２４１、２４２、２４３、２５１、２５２及び２７１）によって構成される。各処理モジュール（あるいはハンドラ）に対して、追加のデータヘッダ群を追加することによってバッファメモリ２１４の内容に補完的な追加を行うことができる、あるいは、後の使用のために、仮想ＲＴＰパケット（２２、２２’、２２”、あるいは２８）へのリファレンス（かつ、関連するバッファメモリ２１４への拡張による）を保持することができる。

処理モジュールには、特定の処理モジュール、ＲＴＰモジュール２３１、２４２、２５１及び２７１が存在する。この特定の処理モジュールは、バッファメモリ２１４の内容にＲＴＰプロトコルヘッダを追加することによってＲＴＰパケットをファイナライズし、かつ通信ネットワーク１５を介して、自身の受信先に、メモリに形成されているそのＲＴＰパケットを送信するタスクが与えられる。

より詳細には、ソースブロック２１は、エンコーダ２１１、符号化フォーマットに適合されているパケッタイザ２１２、及びバッファメモリ「ファクトリー」２１３によって構築されている。データ２０は、例えば、ビデオカメラのようなキャプチャ周辺機器から得られる画像フレーム群で構成される。これらのデータは、キャプチャ周辺機器のサンプリング周波数に対応する周波数で供給される。これらの画像フレーム群はエンコーダ２１１によってビデオ圧縮フォーマット、例えば、ＭＰＥＧ４あるいはＨ．２６４／ＡＶＣに符号化される。パケッタイザ２１２は、ペイロードデータの一部を形成するために符号化されているデータを分割すること、及び再構成することの少なくとも一方を実行する。このペイロードデータは、ネットワークパケット群で送信されるように構成されている。符号化データのパケット化は、ＭＰＥＧ４フォーマットに対する、「ＭＰＥＧ−４オーディオ／ビジュアルストリーム群用ＲＴＰペイロードフォーマット」、ＩＥＴＦ、２０００年１１月に記載される、あるいは「Ｈ．２６４フォーマットに対する、「Ｈ．２６４ビデオ用のＲＴＰペイロードフォーマット」、ＩＥＴＦ、ＲＦＣ３９８４、２００５年２月に記載されるように実行することができる。

エンコーダ２１１及びパケッタイザ２１２の少なくとも一方は、ネットワークパケット内のペイロードデータに対して利用可能な最大サイズを把握するために、バッファメモリファクトリー２１３に問い合わせる。そのリプライでは、エンコーダ２１１及びパケッタイザ２１２は、ペイロードデータのサイズを取得するように符号化及びパケット化の少なくとも一方を適合する。このペイロードデータのサイズは、取り得る最大サイズに最も近いものである。例えば、符号化は、画像部分群（「スライス群」）あるいは量子化ステップサイズを変更することによって構成されてもよい。パケット化は、パケット化モードが許容する場合には、画像部分群をフラグメントすることによって、あるいは組み合わせることによって構成されてもよい。

エンコーダ／パケッタイザのペアによって生成されるペイロードデータは、バッファメモリ２１４に配置される。このバッファメモリ２１４は、エンコーダ２１１のリクエスト、あるいはパケッタイザ２１２のリクエストで、バッファメモリファクトリー２１３によって前もって割り当てられる。

バッファメモリファクトリー２１３は、ソース２１にリンクしているデータストリームマネージャ群（例えば、２３、２４及び２５）のそれぞれに対するメモリ空間の予約に対するリクエストのすべてを継続的に保持する。バッファメモリファクトリー２１３は、ネットワークパケット群の開始で予約されなければならない最大メモリ空間を判定する。この情報を用いて、ペイロードデータは、バッファメモリ２１４内の正しい位置に直接配置される。バッファメモリ開始地点２１４（図２の破線）での空き空間は、各処理モジュールに、メモリ内のペイロードデータをコピーあるいは移動することなく、ヘッダ情報及び拡張情報を連続的に追加することを可能にする。

ここで、ペイロードデータの同一の項目が、クライアント１１、１２及び１３に送信されると仮定する。これに対して、バッファメモリ２１４は、データストリームマネージャ２３、２４及び２５のそれぞれによって連続的に取り扱われる。データストリームマネージャ群のそれぞれに対して、異なる仮想「ＲＴＰパケット」オブジェクト２２、２２’及び２２”が作成される。これらのオブジェクトは、特に、自身の内容を指定することを可能にする、バッファメモリ２１４に対するいくつかのポインタを含んでいる。

−バッファメモリの開始に対するポインタ
−ペイロードデータの位置に対するポインタ
−ヘッダ拡張群の位置に対するポインタ
最初は、ＲＴＰパケット２２、２２’、２２”それぞれの少なくとも２つのポインタは等しく、また、ソース２１によって配置されるように、バッファメモリ２１４内のペイロードデータの位置を指定する。

各データストリームマネージャ２３、２４及び２５は、少なくとも１つの処理モジュールから構成される。これらの処理モジュールは、バッファメモリ２１４と、関連する仮想「ＲＴＰパケット」オブジェクト（２２、２２’あるいは２２”）を処理するタスクが与えられる。各データストリームマネージャ２３、２４、２５は、継続的に同一のバッファメモリ２１４を操作する（この操作は、データストリームマネージャのそれぞれによって再度書き込まれるペイロードデータの前の破線の領域に対して可能となる）。つまり、ペイロードデータは、自身がいくつかのクライアントへ送信される場合に、メモリ内でコピーされない、あるいは移動されない。

例えば、クライアント１１に関連するデータストリームマネージャ２３は、１つのＲＴＰ処理モジュール２３１だけを構成している。このＲＴＰ処理モジュールは、仮想ＲＴＰパケット２２のポインタ群を使用して、バッファメモリ２１４内のペイロードデータの前に１２バイトＲＴＰヘッダを配置するタスクを行い、そして、それによってメモリ内に形成されたパケットを通信ネットワーク１５を介して送信する。ネットワークを介して送信した後、仮想ＲＴＰパケット２２は破棄することができる。

次に、バッファメモリ２１４からの同一のペイロードデータは、データストリームマネージャ２４を使用してクライアント１２へ送信される。クライアント１２に関連づけられているデータストリームマネージャ２４は、例えば、３つのモジュールを構成する。それは、輻輳制御モジュール２４１、ＲＴＰモジュール２４２（同様のモジュール２３１）、及びデータ冗長性に基づく誤り訂正モジュール２４３（あるいは「前方誤り訂正」による「ＦＥＣ」）。この例では、輻輳制御モジュール２４１は、パケットに対する（例えば、ラウンドトリップ時間（あるいは「ＲＴＴ」）を計算することができる）ＲＴＰヘッダ群への拡張群の形式で、バッファメモリ２１４に追加の情報を挿入することができる。この情報は、ペイロードデータの前に配置され、そして、結果として、仮想ＲＴＰパケット２２”のポインタが再配置される。

仮想ＲＴＰパケット２２’とバッファメモリ２１４は、次に、ＲＴＰモジュール２４２によって処理される。このＲＴＰモジュール２４２は、バッファメモリ２１４内のＲＴＰパケットをファイナライズし、かつそれを通信ネットワーク１５を介して送信する。仮想ＲＴＰパケット２２’とバッファメモリ２１４は、次に、ＦＥＣモジュール２４３によって処理される。ＦＥＣモジュール２４３は、新規の冗長パケットを計算することができるようになる前に、いくつかのＲＴＰパケットを記憶しなければならない。つまり、ＦＥＣモジュール２４３は、仮想ＲＴＰパケット２２’へのリファレンスを保持する。ここで、仮想パケット２２’によって指示される、バッファメモリ２１４のペイロードデータだけが、冗長パケットを計算するために利用することができることに注意されたい。モジュール２４１と２４２によってバッファメモリ２１４に配置されるヘッダ情報と拡張群は、他のデータストリームマネージャ群によって同一のペイロードデータの送信において上書きされることは免れない。

必要がある場合、モジュール２４２によって最初に送信する時と同様に、モジュール２４３によって参照される仮想パケット２２’は、ヘッダ群と拡張群とを再生成するために十分な情報を保持する。

データストリームマネージャ２４による処理後、バッファメモリ２１４は、最終的には、クライアント１３へ送信される自身のコンテンツに対して、順番にデータストリームマネージャ２５によって処理される。新規の仮想ＲＴＰパケット２２”が割り当てられる。この仮想ＲＴＰパケット２２”は、バッファメモリ２１４を参照する。クライアント１３に関連付けられているデータストリームマネージャ２５は、ここでは、２つのモジュールから構成される。これは：ＲＴＰモジュール２５１（モジュール２３１及び２４２と同様）と、再送信に基づく誤り訂正モジュール２５２（「ＲＴＸ」）である。ＦＥＣモジュール２４３に対しては、ＲＴＸモジュール２５２は、ＲＴＰパケット２２”へのリファレンスを保持する。特に、クライアントのリクエストでネットワークを介して再送信することができる所定の時間の間、ＲＴＰパケット２２”へのリファレンスを保持する。

ＲＴＸモジュール２５２は、上述のデータストリームマネージャ内の処理モジュールと、また、再送信されるパケット群を送信するためのＲＴＰパケット群の新規のソース２６との両方として動作する。ＲＴＸ処理モジュール２５２とＲＴＸソース２６は、２つの態様の同一のＲＴＸモジュールである。サーバ１０が、再送信用のリクエストをクライアント１３から受信すると、この再送信用のリクエストは、ＲＴＸソース２６へ送信される。ＲＴＸソース２６は、ＲＴＰパケット２２”に対するＲＴＸモジュール２５２とそれに関係するバッファメモリ２１４に記憶される、再送信用のリクエストに対応するパケットを検索する。パケットが検出される場合、再送信パケットを記述することになる新規の仮想ＲＴＰパケット２８を割り当てる。新規の仮想ＲＴＰパケット２８は、同一のバッファメモリ２１４をオリジナルの仮想ＲＴＰパケット２２”として参照する。

つまり、ペイロードデータは、再送信リクエストに応答する時点では、コピーされない、あるいは移動されない。ヘッダ群と拡張群に対応する破線の部分だけが、再送信データストリームマネージャ２７によるパケットの送信時に再度書き込まれる。ＲＴＸソース２６に関連付けられているこのデータストリームマネージャ２７は、他のデータストリームマネージャ２３、２４、２５と同様の方法で動作する。ここでは、このデータストリームマネージャ２７は、ＲＴＰ処理モジュール２７１からなる。ＲＴＰ処理モジュール２７１は、ペイロードデータの前にＲＴＰヘッダ群を配置し、そうすることで、形成されるネットワークパケットをクライアント１３へ送信する。

ここで、ＦＥＣ処理モジュール２４３は、データのソース自身であり、これは、オリジナルのＲＴＰパケット２２’から生成されるＦＥＣ冗長パケット群の送信に対してＲＴＸモジュール２５２に対して説明されるものと同様のものであることに注意されたい。このＦＥＣ冗長ソースは、明瞭にするために（図７及び図８におけるＦＥＣソースの表現を参照）、図２には示されてない。

更に、クライアント向けに専用となる追加の情報とヘッダ群を配置するための、バッファメモリ２１４内のヘッダゾーンの再書込は、各データストリームとサブストリームが連続的に処理されるという事実によって可能であることに注意されたい。

図３は、新規のネットワークパケットの送信用のバッファメモリファクトリーによって割り当てられる、バッファメモリ２１４の内容を記載している。

本発明を実現するために採用されるバッファメモリは、いくつかの部分によって構成されるメモリの連続するブロックであることが好ましい。バッファメモリの先頭には、リファレンスカウンタ３１がある。このリファレンスカウンタ３１は、バッファメモリが別のオブジェクトによって参照される毎にインクリメントされる。この別のオブジェクトは、例えば、ＲＴＰ仮想パケット、処理モジュールあるいはデータソースがある。このリファレンスカウンタ３１は、オブジェクトがバッファメモリへのリファレンスを破棄する毎にデクリメントされる。リファレンスカウンタ３１は値「０」を保持する場合、即ち、システムの任意のオブジェクトによってこれ以上参照されることはない場合、バッファメモリへの割当が解消される。

リファレンスカウンタ３１の後には、予約空間３２が配置される。これは、ヘッダ及び拡張情報の少なくとも一方をペイロードデータに追加するための様々な処理モジュールによって使用することができ、そうすることで、ネットワークを介して転送することができるデータパケットを製造する。この予約空間の最大サイズの計算については後述する。

この予約空間３２の後に、エンコーダ−パケッタイザのペアによって取得されるペイロードデータを配置するために利用できるゾーン３３が配置される。ゾーン３３に実際に配置されるペイロードデータのサイズは、ゾーン３３のサイズ以下である。

バッファメモリファクトリーによってバッファメモリが割り当てられると、そのバッファメモリファクトリーは、ソースに関連付けられている様々なデータストリームマネージャによってなされる予約リクエスト群の最大値となる、予約空間３２のサイズを判定する。残りの空間は、ペイロードデータに割り当てられ、そして、ゾーン３３を構成する。バッファメモリファクトリーは、エンコーダ／パケッタイザに対して、様々なゾーンに定義することができるいくつかのポインタに割り当てられるバッファメモリを生み出す。

−予約空間の開始を指定するバッファメモリへのポインタ
−ペイロードデータを配置することができる開始位置を指定するペイロードデータへのポインタ
−ペイロードデータへのポインタとして同一位置に最初に配置されるＲＴＰヘッダ拡張群へのポインタ
バッファメモリの全体サイズは、ネットワークを介して一回で（あるいは「最大送信ユニット」に対する「ＭＴＵ」で）再送信する（フラグメンテーションなしで）ことができるパケットの最大サイズ（バイト）に、リファレンスカウンタ３１のサイズを足したサイズに対応する。

図４は、追加のペイロードデータ拡張を記載している。処理モジュールあるいはソースがペイロードデータ拡張４１をバッファメモリに追加する場合、追加情報のサイズはペイロードデータポインタから差し引かれ、追加の情報がそのポインタによって指定される位置に配置される。つまり、予約空間３２の部分は、ペイロードデータ拡張を記憶するために使用される。ＲＴＰヘッダ拡張群へのポインタは、また、ペイロードデータへのポインタとして、同一の位置を指示するために更新される。

処理モジュール群は、ＲＴＰヘッダと取り得るそのＲＴＰヘッダへの拡張群を挿入することができる前に、バッファメモリに挿入されるべきペイロードデータの拡張に対して、順番にデータストリームマネージャで連続的にリンクされてなければならない。処理モジュールが、様々なタイプの情報、例えば、ペイロードデータへの拡張と、ＲＴＰヘッダへの拡張をバッファメモリに挿入する場合、処理モジュールは、処理チェーン内の様々な位置に存在することができる。

ペイロードデータへの拡張の例には、ＯＳＮ（「オリジナルシーケンス番号（original sequence number）」）再送信ヘッダがある。これは、ＲＦＣ４５８８セクション４（「ＲＴＰ再送信ペイロードフォーマット」、ＩＥＴＦ、ＲＦＣ４５８８、２００６年７月）で記載されるように、パケットを送信しなければならない場合に、オリジナルペイロードデータの前のＲＴＸソースによって配置されなければならない。別の例には、ＲＦＣ５１０９セクション７（「汎用前方誤り訂正用のＲＴＰペイロードフォーマット」、ＩＥＴＦ、ＲＦＣ５１０９、２００７年１２月）に記載される、ＦＥＣヘッダとＦＥＣレベルヘッダがある。

２つのタイプの拡張として、ペイロードデータ拡張群とＲＴＰヘッダへの拡張に区別されることに注意されたい。１つ目は、図４を参照して説明され、一方で、２つ目は図５及び図６を参照して説明される。ＲＴＰヘッダへの拡張群の追加は、２つのフェーズで実行される。第１フェーズは、図５に示され、ＲＴＰヘッダ自身への拡張の配置からなり、第２フェーズは、図６に示され、ＲＴＰヘッダへの追加された拡張群を記述する専用ヘッダを追加すること、場合によっては、パディングとからなる。

図５は、処理モジュールによる、ＲＴＰヘッダ拡張要素の追加を表している。各モジュールは、ＲＴＰヘッダへの追加情報を追加することができる。例えば、サーバ１０によって提案されるあるサービス群の使用は、各ネットワークパケットで追加情報を送信することを必要とする場合がある。これは、例えば、ＴＦＲＣ輻輳制御サービスを用いる場合である。このＴＦＲＣ輻輳制御サービスは、文献「ＴＣＰフレンドリーレート制御によるＲＴＰ」、ＩＥＴＦ、draft-ietf-avt-tfrc-profile-10、２００７年７月に記載されている。この場合、この情報は、ＲＦＣ３５５０（「ＲＴＰ：リアルタイムアプリケーション群用の転送プロトコル」、ＩＥＴＦ、ＲＦＣ３５５０、２００３年７月）のセクション５．３．１によって定義されるように、ＲＴＰヘッダへの拡張を追加することができる。ＲＴＰヘッダにいくつかの拡張を配置することを可能にするために、様々なＲＴＰヘッダの拡張群（ここでは、「ＲＴＰヘッダ拡張要素群」と呼ぶ）が、ＲＦＣ５２８５（「ＲＴＰヘッダ拡張群用の汎用メカニズム」、ＩＥＴＦ、ＲＦＣ５２８５、２００８年７月）に従って構成される。これは、ＲＦＣ３５５０の目的の範囲内で、ＲＴＰヘッダ拡張を形成するために、パケット内で、いくつかのＲＴＰヘッダ拡張要素がどのように関連付けられるかを定義する。

図５及び図６は、追加のＲＴＰヘッダ拡張要素群を記載している。図６に示される、ＲＴＰヘッダ拡張は、一連のＲＴＰ拡張要素群６４に続いて、場合によっては、メモリ内のデータのアライメントを保証するためのいくつかのパディングバイトＰ６３を伴って、その前に、拡張ヘッダ（フィールドＩＤ６１とフィールドＬ６２からなる）からなる。いくつかの実施形態では、各処理モジュールは、ＲＴＰヘッダへ追加データを追加することができる。このため、図５に示されるように、この処理モジュールは、追加する要素のサイズを、ＲＴＰヘッダ拡張群へのポインタから差し引き、それによって、取得されるアドレスに新規の要素を配置する。ＲＦＣ５２８５に従えば、この要素は、ローカル識別子５１と、長さ表示５２と、追加データ５３からなる。

ペイロードデータの拡張後、かつネットワークを介して送信するためのＲＴＰパケットをファイナライズするＲＴＰモジュールによる処理前に、ＲＴＰヘッダ拡張要素群のすべてがバッファメモリに挿入される。

図６は、ＲＴＰ処理モジュールによってファイナライズされるネットワークパケットを記載している。

ＲＴＰヘッダ拡張要素群が従前に追加されている場合に（つまり、ペイロードデータへのポインタとＲＴＰヘッダ拡張群へのポインタ間の差分がゼロでない場合）、ＲＴＰ処理モジュールは、ヘッダ拡張要素群の総和は３２の倍数であること（これは、ＲＦＣ３５５０セクション５．３．１に記載されるＲＴＰパケット化の制約である）をまず第一に判定することによってＲＴＰパケットをファイナライズする。この判定がこの場合に該当しない場合、ＲＴＰ処理モジュールは、パッディングバイト６３を、ＲＴＰヘッダ拡張要素群６４の前に追加する。次に、ＲＴＰ処理モジュールは、ＲＴＰ拡張要素群の長さの表示６２と、識別子６１からなるＲＴＰ拡張群のヘッダを追加する。ＲＦＣ５２８５に従う、１バイトサイズのＲＴＰヘッダへの拡張要素群の場合、識別子６１は、例えば、「０ｘＢＥＤＥ」となる。ＲＴＰ処理モジュールは、次に、ＲＴＰヘッダ６５に追加することによってパケットをファイナライズする。

ＲＴＰヘッダ６４への拡張要素群がない場合、つまり、ＲＴＰヘッダ拡張群へのポインタ群と、ペイロードデータへのポインタ群が等しい場合、ＲＴＰ処理モジュールは、ペイロードデータへのポインタの前にＲＴＰヘッダ６５を追加する。

そのようにして形成されたパケットが、ネットワーク１５を介して送信される。

図７は、データストリームマネージャの第１の例と、処理モジュールのリンク状態の第１の例を示している。図７は、同一の受信クライアントに対して宛先とされているいくつかのデータストリーム群７１、７２及び７３を表していて、かつ追加データの「永続性」あるいは「ストリーム従属性」の概念と、データストリーム群の間の承継の概念とを導入している。データストリーム群７１、７２及び７３は「従属タイプ」であり、これは、データストリーム７１を処理するＦＥＣ処理モジュール７１４が、データストリーム７２に対するＦＥＣソース７２１自身であるからである。データストリーム７２を管理する再送信モジュール７２４ＲＴＸは、データストリーム７３に対するＲＴＸソース７３１自身である。このスキーマに従えば、データストリーム７１から到来するネットワークパケット群は、データストリーム７２から到来するＦＥＣパケット群によるネットワーク上のパケット損失から保護される。このデータストリーム７２自身は、データストリーム７３から到来する再送信パケット群によって保護される。ストリーム群との間の従属性にマークを付けることは、データストリーム７２が、データストリーム７１のデータの「サブストリーム」であると言える。同様に、データストリーム７３は、データストリーム７２からデータのサブストリームである。

一般的には、処理モジュールが別のデータストリームに対するソース自身である場合、それは、処理モジュールにリンクしているデータストリームに関連するデータサブストリームであると言える。つまり、処理モジュールは、関連するデータサブストリームから、予約空間の制約を承継する。

ここで、このスキームに従えば、データストリームマネージャのそれぞれは、輻輳制御サービス７１２、７２２及び７３２をそれぞれ使用する。同様に、各データストリームマネージャは、ＲＴＰモジュール７１３、７２３及び７３３をそれぞれ備える。

このようなスキームでは、自身のネットワークパケットを送信することを可能にするために、各データストリームとサブストリーム７１、７２及び７３に対して、順番にデータストリーム７１のソース７１１によって生成されるペイロードデータの最大サイズの判定がなされる。ここで、この判定は、一旦ネットワークパケット群がソース７１１によって生成されて、かつバッファメモリに配置されると、データストリームをコピーするあるいは移動することなく、また、パケット群（各パケットは、最大で１つのＭＴＵと等しくなる）のフラグメンテーションなしで、なされる。

これのため、各処理モジュールは、様々なタイプの予約に従って、また、追加情報のタイプ、ペイロードデータへの拡張のタイプ、あるいはＲＴＰヘッダへの拡張のタイプに従って、さらに、追加情報の追加が従属ストリーム群の間（つまり、１つのデータストリームとデータサブストリームの間）で永続性の性質であるか否かに従って、予約空間に対する自身の最大の要件群を判定する。

また、処理モジュールによってデータストリームに追加される追加情報がデータサブストリーム内で繰り返されなければならないか、あるいは追加情報だけを処理モジュールにリンクしているデータストリームに適用するかを区別する問題がある。

例えば、図７を参照すると、輻輳制御モジュール７１２がＴＦＲＣタイプである場合、追加情報をＲＴＰヘッダ拡張で追加しなければならない。この追加情報は、例えば、パケットが送信された日時、あるいはパケットに対するラウンドトリップタイム（ＲＴＴ）の評価値である。この情報は、データストリーム専用である。つまり、この情報は正規のサブストリームで繰り返す必要はない。従って、これは、「データストリーム従属」タイプと言える。

一方、データストリーム７２は、データストリーム７１のオリジナルパケット群からＦＥＣパケット群を作成し送信することによって、データストリーム７１によって生成されるネットワークパケットを保護する。これに対して、ＦＥＣパケット群は、とりわけ、ＦＥＣヘッダをペイロードデータあるいは等価物を追加することによって、処理モジュール７１４／ＦＥＣソース７２１によって生成される。また、ＦＥＣデータストリーム７２は、再送信データストリーム７３によって自身が保護される。これに対して、再送信パケット群は、ＲＴＸ処理モジュール７２４によって保存されるＦＥＣパケット群に基づいて、ＲＴＸソース７３１によって生成される。これは、再送信パケット群が、同時に、ペイロードデータの等価物と、ペイロードデータのＦＥＣヘッダとを統合すると言える。このＦＥＣヘッダは、「永続性」タイプである。

これは、ＦＥＣソース７２１によって追加されるヘッダ群と、ＲＴＸソース７３１は、付加的特性があるとことに注意されたい。この付加的特性は、ストリーム７３によって再送信されるパケットは、同時に、データストリーム７１のオリジナルのペイロードデータの等価物、データストリーム７２のペイロードデータのＦＥＣヘッダ、データストリーム７３のペイロードデータのＲＴＸヘッダ、及び輻輳制御サービスに対するＲＴＰヘッダへの拡張を統合する。

以下の様々なタイプの予約が区別される。

−永続性ＲＴＰヘッダ拡張群（あるいは「永続性ヘッダ拡張」からのＰＨＥ群）
−ストリーム従属ＲＴＰヘッダ拡張群（あるいはストリーム従属ヘッダ拡張からのＳＨＤＥ群）
−永続性ペイロードデータ拡張群（あるいは「永続性ペイロード拡張」からのＰＰＥ群）
−ストリーム従属ペイロードデータ拡張群（あるいは、ストリーム従属ペイロード拡張からのＳＰＤＥ群）
図８は、データストリームの第２の例と、処理モジュールのリンク状態の第２の例を示している。ここで、データストリーム８１、８２及び８３は、同一の受信クライアントに向けられている。このスキームに従えば、データストリーム８１からのネットワークパケット群は、データサブストリーム８２から到来するＦＥＣパケット群と、データサブストリーム８３から到来するＲＴＸ再送信パケット群との両方によって保護することができる。

また、データストリーム８１、サブストリーム８２及び８３のそれぞれは、輻輳制御サービス８１２、８２２及び８３２をそれぞれ使用する。

データストリームマネージャ８１は、ソース８１１からデータを受信し、そして、輻輳制御モジュール８１２、ＲＴＰモジュール８１３、ＦＥＣモジュール８１４及び再送信モジュール８１５を備える。データストリームマネージャ８２は、輻輳制御モジュール８２２及びＲＴＰモジュール８２３を備える。データストリームマネージャ８３は、輻輳制御モジュール８３２とＲＴＰモジュール８３３を備える。図７で示される場合と比較して、ＦＥＣソース８２１あるいはＲＴＸソース８３１によって追加されるペイロードデータヘッダ群は、付加的特性ではない。

図９は、少なくとも１つのサブストリームを備える場合があるデータストリームを転送するためのデータストリームマネージャによって、バッファメモリに予約される空間の最大サイズを計算するためのステップ群のフロー図を示している。

データストリームマネージャによる予約リクエストは、以下のイベント群のそれぞれで再評価される。

−クライアントが、システムに接続すること、
−クライアントが、システムから切断すること、
−クライアントが、サービスをアクティベートすること、あるいは
−クライアントが、サービスをデアクティベートすること。

データストリームマネージャによって要求される予約空間のサイズを判定するために、ＰＨＥ、ＳＤＨＥ、ＰＰＥ及びＳＤＰＥのタイプ群に従う予約要件群が、ステップ９１で、第１モジュールによって開始する各処理モジュールに対して判定されなければならない。予約要件群のこの判定は、後述する。

ステップ９２で、処理モジュールが、少なくとも１つのサブストリームに対するデータのソース自身であるかが判定される。そうである場合、ステップ９３で、処理モジュールは、ＰＨＥ、ＳＤＨＥ、ＰＰＥ及びＳＤＰＥのタイプ群に従って、各サブストリームの予約要件群を判定する。これらの予約要件群は、「承継されたもの」と言える。

そうでない場合、あるいはステップ９３の後、ステップ９４で、データストリームマネージャは、データストリームマネージャの最終処理モジュールの予約要件が判定されているかを判定する。そうでない場合、データストリームマネージャの新規の処理モジュールを処理するために、ステップ９１に戻る。

最終モジュールが処理される場合、ステップ９５で、データストリームマネージャ（「Ｓ」で示される）は、以下の方程式に従って、（Ｍiで示される）ものを構成する処理モジュール群（processing modules）と（「Ｓj」で示される）ものを承継するサブストリーム群（Substreams）を考慮に入れることによって、自身の予約要件群（「Ｒ」で示される）を判定する。

これらの方程式群は、演算式群の形式で表現することができ、この演算式群は、拡張情報のタイプに依存する。データストリームマネージャＳに対して、所与のタイプの拡張情報Ｅを記憶するために要求される予約空間「Ｒ^E（Ｓ）」は、モジュールＭiによって予約される空間の関数として表現することができる。このモジュールＭiは、（Ｒ^E（Ｍi））で示されるものと、サブストリームＳjによって予約される空間を構成する。サブストリームＳjは、方程式（５）の形式で、（Ｒ^E（Ｓj））で示されるものを承継する。

つまり、方程式（１）から（４）は、単一方程式Ｒ^E（Ｓ）の形式で表現され、ここで「Ｅ」は拡張情報のタイプ、つまり、ＰＨＥ、ＳＤＨＥ、ＰＰＥ、あるいはＳＤＰＥのタイプの１つを示している。Ｏ^Eは、以下のものを伴う、タイプＥに依存する演算式を示している。

Ｏ^SDHEとＯ^SDPEは、演算式「ｍａｘ」に対応し、これは、値のペアの最大値を抽出する。

Ｏ^PHEとＯ^PPEは、演算式「＋」に対応し、これは、値のペアの値を追加する。

Ｒ^E（Ｍi）は、データストリームマネージャＳのＭiで示される処理モジュール群の１つによって、予約Ｅのタイプに対する予約空間を表している。Ｒ^E（Ｓj）は、データストリームマネージャＳのＳjで示されるデータストリーム群の１つによって予約Ｅのタイプに対する予約空間を表している。

様々なタイプの予約要件群がデータストリームに対して一旦判定されると、ステップ９６で、以下の演算式で使用して、データストリームＳに対して予約される全体空間「ＥＲ」のサイズの判定がなされる。

ＥＲ（Ｓ）＝align₃₂（Ｒ^PHE（Ｓ）＋Ｒ^SDHE（Ｓ）＋ＨＤＲ）＋Ｒ^PPE（Ｓ）＋Ｒ^SDPE（Ｓ）
ここで、「ＨＤＲ」は、ＲＦＣ５２８５で定義される、ＲＴＰヘッダ拡張群のヘッダのサイズである。図６において、ＲＴＰヘッダ６５と「align₃₂（ｘ）」は、３２ビットの倍数、実用上では、４バイト以上の倍数で、値ｘのアライメントを表していて、これは、値ｘがバイトで表現されるからである。

ステップ９７で、データストリームマネージャは、次に、計算される予約空間に対する自身の要件を、リンクされているソースのバッファメモリファクトリーに記録する。

ここで、データストリームマネージャは、「０」に等しい予約リクエストを送信することによって、バッファメモリファクトリーからのデータストリームを事前に記録することができることに注意されたい。

図１０は、バッファメモリファクトリーによって実行される、ペイロードデータの最大サイズの計算に対するステップ群のフロー図を表している。つまり、図１０は、ステップ１０１で、データストリームマネージャからの予約に対するリクエストの受信において、バッファメモリファクトリーによって実行されるステップ群を詳細に示している。ステップ１０２で、予約に対するリクエストが「０」であるかどうかが判定される。

そうである場合、ステップ１０３で、データストリームと予約に対する自身のリクエストが、予約リクエスト群のリストに追加される。そうでなければ、ステップ１０４で、データストリームは、予約リクエスト群のリストから削除される。

ステップ１０３あるいはステップ１０４の一方の後、メモリファクトリーは、リンクしているデータストリームマネージャ群のそれぞれの予約のすべてを有することになる。ステップ１０５で、バッファメモリファクトリーは、すべてのデータストリームマネージャによって送信することが可能となるペイロードデータの最大サイズを、ＭＴＵである、ネットワーク上（フラグメンテーションなしで）を一度に送信することができるパケットの最大サイズ（バイト単位）から、予約リクエスト群の最大値を差し引くことによって判定する。

図１１に示される本発明のデバイスの実施形態は、例えば、装置１２０上に基づいている。この装置１２０は、例えば、マイクロコンピュータ、ワークステーション、パーソナルデジタルアシスタント、移動電話、ネットワーク動画カメラ、静止画カメラ、テレビ、カムコーダ、あるいは、より一般的には、無線あるいは有線ネットワーク１１０と接続することができる通信インタフェースで提供される任意の周辺機器（移動体であろうとなかろうと）がある。装置１２０は、様々な周辺デバイスに接続することができる。これには、例えば、入力／出力カード（不図示）に接続されていて、かつ装置１２０にマルチメディアデータを提供する、デジタル動画カメラ１２１（あるいはスキャナ、あるいは任意の他の画像取得手段あるいは画像記憶手段）がある。

装置１２０は、以下のものが接続される通信バス１３１を備える。

−中央処理ユニット１３２（マイクロプロセッサ）（図２では「ＣＰＵ」で示される）
−リードオンリーメモリ１３３、リムーバルであろうとなかろうと、本発明の方法を実行することができ、かつプロセッサあるいはコンピュータによって読取可能な命令群を実行可能なプログラム群を記憶する。

−ランダムアクセスメモリ１３４、これは、起動後、本発明の方法を実現する実行可能コードを含むとともに、その方法を実現するために必要な変数値群及びパラメータ群を記録するように構成されているレジスタ群を含んでいる。

− − 通信インタフェース１３５、通信ネットワーク１１０に接続され、この通信インタフェース１３５は、データを送受信するように構成されている。

オプションとしては、装置１２０は、以下のものを有することができる。

−オーディオデータの場合、入力／出力カード（不図示）、これはマイクロフォン１２４に接続される。

−スクリーン１２５は、ユーザとのグラフィカルユーザインタフェースとしてデータを表示し、かつ／および、提供するためのものである。このユーザは、キーボード１２６と、補助的なものであろうとなかろうと、ポインティングデバイスのような任意の他の手段とを使用して、プログラム群と対話することができる。このポインティングデバイスには、例えば、マウス、オプティカルスタイラス、あるいはタッチスクリーン（不図示）がある。

−ハードディスク１３６あるいは記憶メモリ、これには、例えば、コンパクトフラッシュ（登録商標）カードがあり、これは、本発明の実現において使用されるあるいは生成されるプログラム群及びデータを記憶することができる。

−ディスクドライブ（あるいは任意の他のリムーバルデータ媒体）１３７、これは、ディスク１２２を受け付け、それに、本発明に従って、処理されたあるいは処理されるべきデータを読み取りあるいは書き込むように構成されている。

通信バス１３１は、装置１２０に含まれる、あるいはそれに接続される様々な要素群との間の通信及びインターオペペラビリティを提供する。通信バス１３１の表現は限定されるものではなく、また、特に、中央処理ユニット１３２は、装置１２０の任意の要素と命令群を直接通信することができる、あるいは装置１２０の別の要素の手段によって命令群を通信することができる。

ディスク１２２は、任意の情報搬送媒体、例えば、書込可能であろうとなかろうと、コンパクトディスク（ＣＤ−ＲＯＭ）、ＺＩＰディスク、あるいはメモリカードがある。一般的には、デバイスに組み込まれているあるいは組み込まれていない情報記憶手段であって、マイクロコンピュータあるいはマイクロプロセッサによって読み取ることができ、また、場合によっては、リムーバルであっても良い情報記憶手段は、本発明の方法の実施を許容する命令群を実行する１つ以上のプログラムを記憶するように構成されている。

装置１２０によって、本発明の方法の実行を可能にする実行可能コードは、同様に、リードオンリーメモリ１３３、ハードディスク１３６、あるいはディスク１２２のようなリムーバルデジタル記憶媒体に記憶されても良い。変形例に従えば、プログラムの実行可能コードは、インタフェース１３５を介する通信ネットワーク１１０の中継によって受信され、それを実行する前に、装置１２０の記憶手段の１つに記憶される。

中央処理ユニット１３２は、プログラムあるいはプログラム群のソフトウェアコード部分の命令の実行を制御し、かつ指示する。起動時には、非揮発性メモリ、例えば、ハードディスク１３６あるいはリードオンリーメモリ１３３に記憶されている、プログラムあるいはプログラム群は、ランダムアクセスメモリ１３４（ＲＡＭ）に送信される。これらの非揮発性媒体は、本発明に従うプログラムあるいはプログラム群の実行可能コードを含むとともに、本発明を実現するために必要な変数群及びパラメータ群を記憶するためのレジスタ群を含んでいる。

ここで、本発明に従うデバイスを含む装置１２０は、プログラムされた装置とすることもできることに注意されたい。この装置１２０は、例えば、特定用途集積回路（あるいは「ＡＳＩＣ」）に固定されているコンピュータプログラムあるいはプログラム群のコードを含んでいる。

上述の説明を読むことで、本発明は、ネットワークパケットの生成においてペイロードデータに追加することになる様々なタイプの追加情報を管理することを可能にすることが理解されるべきである。このネットワークパケットには、例えば、永続性タイプあるいはデータストリーム従属タイプのペイロードデータのヘッダ群（「ペイロードヘッダ」）、永続性タイプあるいは純粋なデータ従属タイプの基本的なＲＴＰヘッダ拡張群、及び固定サイズのヘッダ群（例えば、基本的なＲＴＰヘッダ群）がある。

また、ネットワークパケットにおけるペイロードデータに対して利用可能なサイズは常に最適となる。これは、クライアントがシステムへ接続する毎に、あるいはシステムから切断する毎に、また、クライアント群の１つによるサービスのアクティベーションあるいはデアクティベーション毎に、再評価される。

そして、ペイロードデータは、決してデュプリケート／コピーされることはない。これは、たとえペイロードデータがいくかの受信先（マルチキャストの場合）に送信される場合でも、あるいはそれらが同一のクライアントへ複数回送信されるものである場合でも、決してデュプリケート／コピーされることはない。つまり、システムは、より少ないメモリリソースとプロセッサリソースを消費する。

Claims

ビデオデータに基づくデータパケットであって、ヘッダ部とペイロード部を含むデータパケットを複数のクライアントへ送信可能なサーバによるデータパケットの送信方法であって、
前記複数のクライアントに送信するデータパケットのサイズを決定する第１の決定工程と、
前記データパケットのヘッダ部のサイズに関わるサービスであって前記ビデオデータに基づくデータパケットの送信先である前記複数のクライアントのうち少なくとも１つに対して提供中のサービスを判別する判別工程と、
前記ビデオデータに基づくデータパケットを第１のクライアントと第２のクライアントに送信する場合であって、前記ビデオデータに基づく前記データパケットに第１のサイズのヘッダ部を含めるべき第１のサービスを前記第１のクライアントに提供中で、前記ビデオデータに基づく前記データパケットに第２のサイズのヘッダ部を含めるべき第２のサービスを前記第２のクライアントに提供中であると前記判別工程で判別された場合、前記第１のサイズよりも大きい前記第２のサイズと、前記第１の決定工程で決定されたデータパケットのサイズとに基づいて、前記第１及び第２のクライアントへ送信するデータパケットのペイロード部のサイズを決定する第２の決定工程と、
前記第２の決定工程で決定されたサイズのペイロード部の前記データパケットを前記第１及び第２のクライアントへ送信すべきデータパケットとして生成する生成工程と、
前記生成工程で生成されたデータパケットを前記第１及び第２のクライアントへ送信する送信工程と
を有することを特徴とする送信方法。
前記第２の決定工程は、前記第２のクライアントに提供中のサービスが変更されると、当該変更後の前記第２のクライアントに提供中のサービスと、前記第１のクライアントに提供中のサービスとに基づいて前記第１及び第２のクライアントへのデータパケットのペイロード部のサイズを決定する
ことを特徴とする請求項１に記載の送信方法。
前記第２の決定工程は、前記ビデオデータに基づくデータパケットを前記第１及び第２のクライアントに送信しているときに、さらに第３のクライアントに送信することになった場合、前記第１及び第２及び第３のクライアントに提供中のサービスに応じたヘッダ部のサイズに基づいてペイロード部のサイズを決定する
ことを特徴とする請求項１に記載の送信方法。
前記第２の決定工程は、前記ビデオデータに基づくデータパケットの送信先である前記第１及び第２のクライアントのうち、前記第２のクライアントへのネットワーク接続が切断された場合、前記第１のクライアントに提供中のサービスに応じたヘッダ部のサイズに基づいてペイロード部のサイズを決定する
ことを特徴とする請求項１に記載の送信方法。
ビデオデータに基づくデータパケットであって、ヘッダ部とペイロード部を含むデータパケットを複数のクライアントへ送信可能なサーバであって、
前記複数のクライアントに送信するデータパケットのサイズを決定する第１の決定手段と、
前記データパケットのヘッダ部のサイズに関わるサービスであって前記ビデオデータに基づくデータパケットの送信先である前記複数のクライアントのうち少なくとも１つに対して提供中のサービスを判別する判別手段と、
前記ビデオデータに基づくデータパケットを第１のクライアントと第２のクライアントに送信する場合であって、前記ビデオデータに基づく前記データパケットに第１のサイズのヘッダ部を含めるべき第１のサービスを前記第１のクライアントに提供中で、前記ビデオデータに基づく前記データパケットに第２のサイズのヘッダ部を含めるべき第２のサービスを前記第２のクライアントに提供中であると前記判別手段で判別された場合、前記第１のサイズよりも大きい前記第２のサイズと、前記第１の決定手段で決定されたデータパケットのサイズとに基づいて、前記第１及び第２のクライアントへ送信するデータパケットのペイロード部のサイズを決定する第２の決定手段と、
前記第２の決定手段で決定されたサイズのペイロード部の前記データパケットを前記第１及び第２のクライアントへ送信すべきデータパケットとして生成する生成手段と、
前記生成手段で生成されたデータパケットを前記第１及び第２のクライアントへ送信する送信手段と
を有することを特徴とするサーバ。
ビデオデータに基づくデータパケットであって、ヘッダ部とペイロード部を含むデータパケットを複数のクライアントへ送信可能なコンピュータに、
前記複数のクライアントに送信するデータパケットのサイズを決定する第１の決定手順と、
前記データパケットのヘッダ部のサイズに関わるサービスであって前記ビデオデータに基づくデータパケットの送信先である前記複数のクライアントのうち少なくとも１つに対して提供中のサービスを判別する判別手順と、
前記ビデオデータに基づくデータパケットを第１のクライアントと第２のクライアントに送信する場合であって、前記ビデオデータに基づく前記データパケットに第１のサイズのヘッダ部を含めるべき第１のサービスを前記第１のクライアントに提供中で、前記ビデオデータに基づく前記データパケットに第２のサイズのヘッダ部を含めるべき第２のサービスを前記第２のクライアントに提供中であると前記判別手順で判別された場合、前記第１のサイズよりも大きい前記第２のサイズと、前記第１の決定手順で決定されたデータパケットのサイズとに基づいて、前記第１及び第２のクライアントへ送信するデータパケットのペイロード部のサイズを決定する第２の決定手順と、
前記第２の決定手順で決定されたサイズのペイロード部の前記データパケットを前記第１及び第２のクライアントへ送信すべきデータパケットとして生成する生成手順と、
前記生成手順で生成されたデータパケットを前記第１及び第２のクライアントへ送信する送信手順と
を実行させることを特徴とするプログラム。