JP2009512279A - ストリーミングと制御処理に異なる素子を用いたメディアデータ処理 - Google Patents

Abstract

ハードウエアでアクセラレートされたストリーミング装置であり、特に、制御パケットから部分的に決定され、ストリームコンテンツのパケットに関連したヘッダを変更したり、補足したりするために使用される、アドレッシング及び取り扱い基準を用いて、ソースと目的地の間で一つ以上のストリームのデータパケットを方向付ける、ＲＴＰリアルタイムプロトコルストリーミングに関する装置である。プログラムされた制御処理装置はＲＴＣＰ又はＲＴＳＰフォーマットの制御パケットに反応し、ＲＴＰパケットの取り扱い又は方向を変えることが出来る。制御処理装置は、ハードウエアアクセラレータにアクセス可能なメモリ内に新しいアドレッシング及び取り扱いに関する基準につていのデータを格納し、該メモリは、同時に多数の進行中のストリームに関する基準を格納するように構成される。コンテンツパケットが到着すると、ネットワークアクセラレータにより、制御処理装置による演算の必要なく、パケットのアドレッシング及び取り扱い基準がメモリから見いだされ、適用される。ネットワークアクセラレータは、ストリームが継続する限り、与えられたストリームのパケットに基準を、繰り返し適用し続けるように運転され、高いデータ伝送速度のパイプラインとして運転することが出来る。処理装置は、ネットワークアクセラレータによって行なわれることとなる反復的な処理から解放されるので、必要ならば高い演算能力を用いて、多様な方法で基準を変更するようにプログラムすることが可能である。

Description

[関連出願のクロスリファレンス]
本出願は、２００５年１０月７日出願の、米国仮特許出願第６０／７２４，４６２、２００５年１０月７日出願の、米国仮特許出願第６０／７２４，４６３、２００５年１０月７日出願の、米国仮特許出願第６０／７２４，４６４、２００５年１０月７日出願の、米国仮特許出願第６０／７２４，７２２、２００５年１０月７日出願の、米国仮特許出願第６０／７２５，０６０、及び２００５年１０月７日出願の、米国仮特許出願第６０／７２４，５７３の利益を要求するものである。これらの出願はここで、参照することで、全体が明示的に組み込まれることとなる。

[発明の背景]
本発明は、リアルタイムデータ転送装置及び方法に係わり、デジタルビデオ処理センタや娯楽システムにおいて、ＲＴＰストリーミングを用いた会議システム又は他の応用に関する。本発明はまた、制御プロセッサのプログラムにより、ソースと行き先の間の転送結合が開始され、停止されまた時々変更される、パケットデータ転送処理に一般的に適用可能である。

本発明の装置及び方法は、多様な記録、再生及び処理機能を提供することが出来、そこではコンテンツ及び制御情報が、データを格納し、提示し、処理する機能的な素子との間で遣り取りされる。発明の観点に基づくと、データ転送速度に関して特に要求される反復されるデータ処理転送機能は、コンピュータ的には複雑なものではない。例えば、ネットワーク接続された格納素子から又は格納素子に対するデータパケットの繰り返されるルーティングは、コンピュータ的に複雑ではあるが比較的に低頻度な制御処理やアドレッシングステップのような機能からは離れて扱われる。好ましい装置においては、ハードウエア装置を構成するアクセラレータが制御処理装置とネットワーク接続されたデータ格納装置間のデータ通信に使用される。アクセラレータは転送機能を実質的な目的としており、これにより、処理装置に、変化する要求に幅広く最適な方法で応答することを確保しつつ、高いデータ処理速度を達成している。

一般的に、異なる可能性を有するデータフォーマットを用いて異なる可能性を有する装置で情報交換が可能となるとが都合がよい。異なる装置及びデータフォーマットを高いデータ転送速度で用いつつ、データ処理システム内での汎用性を持たせる必要性から設計的な挑戦が生じている。産業規格が一定のデータ形式のフォーマットを決定している。規格は、アドレッシング及び信号技術、データ貯蔵及び復旧、通信、その他に関するものである。規格は、複合的なレベルで適用される。例えば、パケット送信規格又はプロトコルは、ビデオエンコード規格などに基づいてエンコードされたビデオデータをトランスポートする際に使用される。

ソースから目的地の間で伝達されたパケットデータは、よく、データフォーマット変換、演算、バッファリング及び同様な処理及び／又は格納ステップなどの中間処理ステップの対象となる。並列サーバ及び端末装置を有するデータ処理システムにおいては、演算負荷の一部はデータフォーマット及びリフォーマットに関連する動作に繋がっている。負荷の一部はデータソースと目的地間のアドレッシング及び切り替えであり、ユーザの選択など状況に対応した変更処理でもあり得る。

使用可能なデータ処理及び通信機能のいくつかは繰り返しの多い処理であり、そこではシーケンシャルなデータパケットが、ソースから目的地まで、全く同じ伝達方法で処理される。これらの機能は、データパイプライン構成を合理化し、単純化して速度を最大化する利益を生じさせる。

他のデータ処理及び通信機能はより管理的であり、計算型に重きがある。例えば、データフローパスを再構成してソースと目的地ノードとの間で加え、除去し又は切替え、又は機能を切替える際に、制御プロセッサは、一つ一つのパケットに対して反復的にアドレスなどを調整するほかに、他の多様なステップを実施する。これらの機能は多様性を有するが、プログラム的及び計算的な複雑性を持つ。

スピードに関して合理化し、単純化する目的は、計算的な複雑性をもたらすことに対して、勿論、矛盾した設計上の目標である。計算的なパワーの必要性に対して、速度及びデータ容量についての並行的な要請を最適化し、早くて多用途な装置を提供することは、重要である。本発明はデータ転送に必要なある機能を、グループに細分化する。比較的単純で高速な、典型的な反復機能は、ハードウエア、即ちハードウエアネットワークアクセラレータに部分的に、また全体的に導入することが出来るアクセラレータ素子に使用される。比較的複雑で順応性のある計算的な機能は制御プロセッサに使用され、実質的にソフトウエアにより実施される。こうした機能の中で、制御プロセッサは、連続するパケットの伝送を含む特定の処理の間、反復的に使用される宛先情報などの条件及び要素をハードウエアネットワークアクセラレータにセットアップし格納する。

好適な実施例では、本発明はリアルタイムプロトコル（ＲＴＰ）パケットストリーミングに関して説明される。パケットソースと目的地タイプの好適なグループは検討され、娯楽や遠隔会議に関するビデオデータ処理に適用することが出来るが、潜在的には警備上のモニタ、ゲームシステム及びその他の用途も含むものである。伝達経路は有線又は無線、及び企業又は公共ネットワークを含むことが出来る。再生用端末は、オーディオ及びビデオ娯楽システム、コンピュータワークステーション、固定又は携帯装置で構成することが出来る。データはネットワークサービスを使用しながら格納され、処理される。好適な通信システムはローカル及びワイドエリアネットワーク、ケーブル及び遠距離通信会社のネットワーク、その他を含むものである。

オーディオ及びビデオデータに関連して、リアルタイムプロトコル（“ＲＴＰ”、“リアルタイム伝送プロトコル”としても知られている）は、パケット化されたオーディオ及び／又は画像及び動画データをデータ通信ネットワーク上で、リアルタイムデータ速度で移動させるのに適している。オーディオ及びビデオデータのリアルタイム又はリアルレートでの再生は、コンテンツの停止及び開始を避ける一方で、バッファに格納する必要性を最小限にすることが望ましい。遠隔会議や同様な通信の用途においては、パケット化されたデータの収集、処理、伝送及び読み出しは、顔を合わせた形のリアルタイム会議及び会話を矛盾しない、遅滞のないまた欠落のないものとすべきである。

ＲＴＰリアルタイムプロトコルは、オーディオ及びビデオを含むリアルタイムデータを能率的に取り扱うことを容易にするものである。それはインターネット電話などの相互サービスは勿論、メディアオンデマンドにも使用することができる。それは、オーディオ及びビデオを、多様なソース及び目的地に、また、多様なソース及び目的地から導くために使用して、同時処理を伴うプレゼンテーション及び／又は記録を可能とする。

データが取り扱われる方法は、制御及びアドレッシング機能を使用して、例えば特定のソース、目的地及び参加者を含んだ接続を開始し、また終了するなどにより、時々変更することが出来る。このように、ＲＴＰは内容を伝送するためのデータ内容部、及び、スタート、ストップ及びアドレッシングを含む、データを取り扱う方法を変えることに関する制御部分を含む。ＲＴＰの制御部分は、リアルタイムコントロール部ということで“ＲＴＣＰ”と呼ばれる。

ＲＴＰのデータ部分は薄い又はすっきりとしたプロトコルであり、連続的なメディア（例えば、オーディオ及びビデオ）の伝送などのリアルタイム特性を持った用途をサポートするために使用される。このサポートは、タイミングの生成、喪失の検出または回復、セキュリティ、内容の確認及び同様な機能を含むものであり、それらは繰り返しが多く、メディア内容の伝送に伴って実質的に連続して生じる。

ＲＴＣインターネットなどの通信ネットワーク内で、あらゆる大きさのグループのリアルタイム会議をサポートする。これにはソースの確認及びマルチキャストからユニキャスト翻訳及びオーディオ及びビデオブリッジのようなゲートウエイをサポートすることを含む。ＲＴＣは、異なるメディアのストリームを同期させるサポート及びマルチキャストグループへ受信者からのサービス品質のフィードバックを提供する。

ＲＴＰ及びＲＴＣＰは上記したタイプのデータ伝送を容易にするように特に作られたプロトコルであるが、与えられたネットワーク構成内では、ＲＴＰ及びＲＴＣＰプロトコルはより高位又は低位のプロトコル及び規格と関連するかもしれない。より高位の場合、例えば、ＲＴＰ及びＲＴＣＰプロトコルは、ビデオ会議システム又はビューアンドストア（view-and-store）又はデータを扱う他の技術で活用されるために使用されるかもしれない。より低位又はよりベーシックなレベルでは、ＲＴＰ及びＲＴＣＰデータ伝送に使用されるパケットは、実際には異なるパケット伝送メッセージプロトコルに基づいて伝送されるかもしれない。例としては、伝送制御プロトコル（ＴＣＰ又はインターネットでは、ＴＣＰ／ＩＰ）及びユーザデータグラムプロトコル（ＵＤＰ）である。

ＴＣＰ及びＵＤＰプロトコルは共にパケット伝送に関するものであるが、それらはパケットの基準及びエラーチェッキング、ロストパケットに対する感度及びその他の点に関して実質的に異なる特性を有する。伝送中に二通りの接続が維持され、また全ての関連するパケットが伝送され、受信側で組み立てられるまで、該接続は維持され、多分、失われた又は損傷を受けたパケットを再度得るようにリトライすることもある、そうしたことを保証するために、一般的にＴＣＰはそうしたプロトコルの性質を使用する。ＵＤＰは、一般的には、パケット伝送行為を扱うが、パケットを送り及び受取り、全ての必要なパケットが送られ及び受け取られることを保証するまでの運用である。テレビ会議画像のストリーミングのような、いくつかのアプリケーションでは、中間で脱落したパケットに対してそれほど神経質ではない。しかし、仮にパケットが脱落したとしても、ストリーミングが可能な限りとぎれることなく続くことが重要である。

より高位及びより低位のプロトコルの幅広い範囲を使用しリアルタイム伝送が可能な技術が開発され、その構成が、異なるプロトコルが異なる方向で十分利点を得ることが出来るとすることが望ましい。通信に利用できる資源及び演算に利用できる資源及び状況に敏感な切替え及び決定することが、最適化されるように処理を構成することが、高いパフォーマンス又は高い要求システムにおいて特に有効である。

[要約]
本発明の観点は、明確で同時に運転される伝送データ経路と制御データ経路を有するデータ処理装置を用いて、ビデオ及び類似した連続的なストリームデータ処理を提供するものであり、そこでは、二つのデータ経路が、スループット力及び処理力がそれぞれに分離して構成された別個に協働するリソースを用いて、データスループットに集中した機能とデータ処理に集中した機能を別個に取り扱う。

特に、リアルタイムプロトコル（ＲＴＰ）に関連するリソースの集中した処理の一部を分割することで、メディアサーバにより行なわれる処理を容易化し、高速化し、割り当てられた一部の処理に関しては最適化された処理装置及びスイッチング装置によって取り扱う、方法及び装置を提供することである。速度に基づいて分割された機能は、データパイプラインの特性を持った装置に割り当てられる。計算型負荷は、ＲＴＰセッションを制御し、データ通信パイプライン内のストリーミングデータの移動に余り関わることのない計算側を取り扱う、一つ以上の中央処理装置に割り当てられる。

ある実施例は、中央処理装置の制御の下で送り、又受け取った選択されたパケット内のヘッダデータを繰り返し置き換えるハードウエアインターフェースを用いることに関する方法である。中央処理装置は、特定のアドレスへルート付けるなど、ある方法で取り扱うための、ある判明した属性を持ったパケットについて調整するような、基準を設定することが出来る。この基準は、ハードウエアインターフェース素子を制御するために中央処理装置に格納される。ハードウエア素子は、伝送データにその結果を組み込む。これは、連続的な各パケットヘッダのヘッダデータ値を、制御処理装置に起因する結果のデータとして生成されるか、制御処理装置から読み出される形で受け取ったデータと差し替えること含むものである。

ハードウエアインターフェース素子は、実質的な管理を受けることなく、高いデータ伝送速度で、ＲＴＰパケットのストリーミングを、オーディオビジュアルプレゼンテーション装置及びストレージ装置に接続されたネットワークなどの目的地とソースの間で制御することが出来る。こうして、ハードウエアインターフェース素子はデータの取り扱いを高速化することが出来る。また、同時に、制御処理装置は、ハードウエアアクセラレータにより達成されている、あるヘッダ値を明確な置換値に置換するよりも、より演算型に集中した機能に向けたものにその注意を向けることが出来る。

アドレスされたデータパケットの伝送に基づいたデータストリーミング装置においては、装置がローカルな又はワイドエリアのネットワークを含むものであろうと無かろうと、反復されるストリーミング機能に関連するデータパケットを搬送する同じデータパスが、該データストリーミングを管理するために必要な、計算型が要求される機能に関連する、制御及びアドレッシングパケットもまた運んでいる。本発明によると、連想メモリ（ＣＡＭ）ファイルが保持され、ハードウエアアクセラレータが、あるアドレスを持った多数の現在維持されているパケットキューと、該連想メモリ（ＣＡＭ）ファイルにより関連付けられている。ＳＥＴＵＰ要求が受け取られ、新たなエンドポイントに向けた新しいストリーミング接続が開始される際には、ＣＡＭファイルには、適合する入力が無い。ハードウエアアクセラレータは、関連するヘッダ値を提供する、即ち、ＲＥＣＯＲＤ又はＳＥＮＤメッセージを予想して、連想メモリ（ＣＡＭ）内に項目（入り口）を生成する。新しいエンドポイントに関連したヘッダ値は、制御処理装置には既知のものであるが、該処理装置は連想メモリ（ＣＡＭ）内に新しいパケットキューをセットアップすることで、新しいエンドポイントへのルートを設立することだけが必要となる。これで、ハードウエアアクセラレータは、入ってくるパケットに関するパケットキューの項目（入り口）を見つけ、必要な値を差し替え、該パケットをその目的地に向けて通過させる自動機械として動作することが可能となる。

設立された待ち行列（キュー）の項目（entry）を持ったＲＴＳＰ又はＳＥＮＤメッセージが受け取られると、外に出されるヘッダ値を決定する責任は、トラフィックマネージャ及び中央処理装置とのデータ通信において、ハードウエアアクセラレータにある。接続は、高いデータ転送率と共に、運転中、完了するまで、又は中央処理装置が必要な新しい制御や動作、例えば、プログラムの何らかの機能に従ってストリームのエンドポイントを決定するようなこと、を開始するまで、維持することが出来る。機能は、多くの又は全ての機能を含んでおり、さもなければ、制御装置は各通過パケットをどのように取り扱うかをプログラムのソフトウエアルーチンを介して決定する必要がある。こうした機能は、ソースと目的地との間のパケットのルーティイング、中間処理ステップを挿入すること、同時に二つ以上の目的地にパケットをルーティイングすること、例えば、再生中の記録などを含む。

特定のヘッダ値を格納された値に置換する連想メモリの技術は、比較的機械的なものであり、素早く行なうことが出来る。ある種のＲＴＰ機能、例えば、ＲＴＰ終了ルーチンなどは、複数のパケットを巻き込むものであり、１対１の交換ではないので、また、多分、格納された値に基づいて置き換るよりは複雑な条件付きのステップがあることから、幾分か複雑であり、ハードウエアでは自由に扱えないことがある。

一方、ストリームのスループット要求は厳格である。このスループットに合わせるために、従来は、プログラム実行中の計算型負荷とヘッダ値の置換の両方を実行するに必要な、極めて高速で、計算能力のある中央処理装置が必要であった。中央処理装置が置換値と基準を提供した後にヘッダ値の置換を扱うためにハードウエアアクセラレータを用いることが本発明の観点である。

一旦、パケット待ち行列（キュー）の項目（entry）が設定されると、ストリーム中の各パケットは最初にネットワークアクセラレータ、即ち、ハードウエアで実質的に実行される高速ユニットに入る。アクセラレータは、連想メモリＣＡＭの接続テーブル内の情報とパケットを照合し、層３（レイヤ３）及び層４（レイヤ４）を除去し（例えば）、新しいローカルヘッダを挿入する。今や、潜在的に変わったローカルヘッダ、ＲＴＰヘッダ及びＲＴＰペイロードを含んだパケットは、トラフィックマネージャを通して、その目的地、例えば、ＲＥＣＯＲＤ運転中のアドレスされたディスクへ書き込まれるたり、再生中の何らかの他のアドレス又はプレゼンテーション装置へ送られる形で、送られ、一度に二つ以上のそうした運転を行なう。

本発明の方法の利点は、入ってくるＲＴＰトラフィックを扱うことが出来、最終的にソフトウエアで制御できる点である。仮に、新しい異なるＲＴＰペイロードタイプが使用されるようになり、また、知られたペイロードタイプの定義が変わっても、それらをサポートすることがストリーマにより行なうことが出来る。加えて、パーソナルビデオ記録（ＰＶＲ）において特に望まれていた機能である、記録中の遅延再生（Delayed-view-while-recording）をとても効率的にサポートすることが出来る。

本発明の技術の欠点は、ＲＴＰローカルヘッダフォーマットでオブジェクトを格納すると、該オブジェクトがＨＴＴＰ伝送にとってアクセスが出来なくなることであり、また、ある状況では、効果を取り消すための操作が必要となることである。しかし、ｎｏｎ−ＲＴＰクライントに直ちに利用可能なオブジェクトを作る為に直ちに、又はリソースが利用可能となったとき、及び／又はオブジェクトの要求が生じた時に、ホスト処理装置の適当なソフトウエアルーチンをオリジナルのメディアオブジェクトを再構成する為に使用することが出来る。

これらの及び他の目的及び観点は、好適な実施例の以下の議論により明らかとなる。

[図面の簡単な説明]
図面に本発明の好適で、例示的であり限定的ではない実施例を示す。しかし、排他的な権利が要求されている発明の範囲を決定するためには、添付したクレームを参照すべきである。図面は、以下のようなものである。

図１は、本発明による、ソースから目的地へのデータ伝送関係（例えば、サーバからクライアント）を示すブロック図であり、ＲＴＰデータコンテンツ成分は、ＲＴＳＰ及び／又はＲＴＣＰ制御信号を扱う中央処理装置などの制御ポイントの周囲を回って伝送される。

図２は、本発明によるストリーミング制御装置を示すブロック図である。

図３は、ＲＴＰヘッダの成分値を示す図表である。

図４は、ローカルアドレスヘッダを有する、前に付加されたＲＴＰヘッダを示すデータ図表である。

図５は、連想メモリを用いて中央処理装置から最初に得た値を何度も適用する、データフロー及びデータ成分を示すブロック図である。

図６は、データストリーミング接続のセットアップを実行し、該接続を維持する機能を示す理論フローチャートである。

図７は、本発明のパケットデータ取り扱い装置を含むように構成された娯楽システム“ＨＮＡＳ”の構成要素を示すブロック図である。

図８は、異なったオフセットを持ったプロトコルが連結される時に適用することの出来るヘッダーオフセットの付加及び、パケットの宛先が該オフセットで決定される方法を示すものである。

図９は、好ましい装置に基づく連想メモリの多段接続を示す回路構成図である。

図１０は、本発明の運用によりデータパケットに適用される、ローカルヘッダの配置を示す、データ図表である。

[好適な実施例の詳細な記述]
リアルタイムプロトコル又はＲＴＰは、リアルタイムデータ、例えば、マルチキャスト又はユニキャストネットワークサービス上のオーディオ、ビデオ又はシミュレーションデータのような、リアルタイムデータ伝送用に適した、端末同士のネットワーク伝送機能を提供する。

ＲＴＰはリソースリザベーションをアドレスしないし、ＲＴＰプロトコルレベルでの接続の維持及びパケットのロストなどの保証など、リアルタイムサービスにおけるサービスの質を保証することはない。データ伝送制御、即ちＲＴＰは、セッション制御（即ち、ソースから目的地までのＲＴＰ伝送）及び全体のプレゼンテーション制御プロトコル（ＲＴＳＰ）などに使用することの出来る制御プロトコル（ＲＴＣＰ）により改良される。

ＲＴＣＰ及びＲＴＳＰ制御プロトコルは、伝送経路を構築し、又は分解する際、例えば一方向（再生）又は他の方向（記録）への伝送を開始するとき、一時停止などの時に伝達される信号パケットを含む。コンテンツデータパケットは、なんらかの同期基準を持ったリアルタイムで出来る限り連続的な流れである必要がある。コンテンツパケットはＲＴＣＰ及びＲＴＳＴパケットとして同時に伝送されるが、これら３つの各プロトコルのパケットは異なってアドレッシングされた論理接続又はソケットを使用する。

ＲＴＳＣ／ＲＴＳＰ制御及びＲＴＰデータストリーミングプロトコルは共に、大きなマルチキャストネットワークに対して大きさの変更が可能なツールを供給する。ＲＴＰ及びＲＴＣＰは基本的な伝送及びネットワーク層とは独立した形で設計されており、従って多様な互換可能なそうした層を使用することが出来る。該プロトコルは、望むならば、ＲＴＰレベルの受信中継器やミキサの使用をサポートする。

ＲＴＰ制御（ＲＴＣＰ）は、サービスの質をモニタすることが出来、進行しているセッションにおいて、参加者についての情報を運ぶことが出来る。参加者の情報は、例えば、明確なメンバーシップ制御及び機構がない、“緩やかに制御された”セッションにとって十分であるが、使用されているアプリケーションが、通常ＲＴＳＰセッション制御プロトコルの領域である、認証やコミュニケーションを要求することがある。

ソースと目的地間を流れるＲＴＰデータ内容パケットは、リアルタイムで、目的地のアドレスに向けて単に通過してゆく。パケットがリアルタイムで通過するので、受信装置ではメモリにバッファする必要はほとんどない。いくつかの理由から、通常、送出装置は一時ファイルを生成する必要がない。ＨＴＴＰオブジェクト伝送などの、いくつかの他のプロトコルとは異なり、ＲＴＰはメディア特定ヘッダを有するオブジェクトを分解する。ＲＴＰ受信機は、リトライ信号送出機能を持つよりもむしろパケットロスを回復するように構成されている。ＲＴＰ伝送は、ＴＣＰ／ＩＰの無接続プロトコルを使用することが出来る。通常、ＲＴＰ伝送は、ＲＴＰデータをユーザデータグラムプロトコル（ＵＤＰ）パケット伝送することで行なわれ、通常、各ＵＤＰパケットが一つのＲＴＰパケットを構成する必要はない。

一つのＲＴＰパケットは、該パケットがＲＴＰであることを示す固定ヘッダを有している。それは、パケット順序番号、タイムスタンプ、同期ソース（ＳＳＲＣ）識別子、コントリビューティング（寄与）ソース（ＣＳＲＣ）識別子の潜在的な空席リスト及びペイロードデータである。ペイロードデータは、オーディオサンプル又は圧縮されたビデオデータなどの、データの値に与えられた数を含む。

個別のリアルタイムデータコンテンツパケット（ＲＴＰ）に対して制御（ＲＴＣＰ）及び／又はセッション制御（ＲＴＳＰ）パケットを使用するシステムは、全ての３タイプ又はパケットが同じデータ経路上で送られ、受け取られるが、周波数と機能の点でやや相違する。ネットワークに接続された娯楽システム、ビデオ会議システム、ネットワークに接続されたメモリ装置などの、受信装置内に処理装置を設けることが出来、該処理装置をプログラムしてＲＴＰパケットとＲＴＣＰ又はＲＴＳＰ制御パケットを適宜区別することが出来る。データパケットはそれらの目的地へ向けて通過され、制御パケット処理装置により他のプログラムされた機能を達成すべく、また情報の伝達を達成すべく使用される。そうしたシステムでは、速度を保持すべく、中央処理装置では、ＲＴＰデータパケットをリアルタイムで通過させるために高いデータ転送速度で運転する必要がある。処理装置は、また、潜在的に必要な制御工程を取り扱うために必要な、計算的な複雑性及びプログラミングを持つ必要がある。処理装置は早くしかも能力のあるものである必要がある。しかし、こうしたことはあまり比較されることはないが、処理装置の計算における複雑性は、単にＲＴＰパケットを通過させる時には使用されず、また、処理装置の高いデータ転送能力も計算制御を行なうためには不要である。

本発明の観点は、中央処理装置（処理装置）の演算能力がＲＴＰデータを通過させるルーチンを扱うことから決定されることがないように、特別なケースのセッション処理からも離れた、一般的に、定常状態のＲＴＰセッションの取り扱いとは無関係な、ＲＴＰデータと信号データに対する別個のデータパスを供給することである。この区分化は、異なる入力及び出力プロトコル、装置、アドレス及び機能などの、より高い及び／又は低いアプリケーション層で、多数のサポートされたプロトコルの複雑性を取り扱うために、データストリーミング用のハードウエアスイッチング装置及び中央処理装置を用いて達成することが出来るパフォーマンス上のメリットがあるために、都合がよい。

図１は、サーバ（即ち、ストリーミングデータのソース）及びクライアント（目的地）間に配置された制御ポイントを有する簡単なネットワーク環境を示す。各相互接続はＲＴＰストリーミングをサポートする多様なパケットタイプでラベルが貼られている。主題となる発明は制御ポイントを含む構成に広汎に適用することが出来、メッセージヘッダのフィールドを、既に述べたハードウエアアクセラレータを用いてリプレースする技術を用いることで、少なくとも部分的に制御ポイントでの処理の必要性を回避する。

図２は、制御ポイントがネットワーク上でパケットソース（サーバと表示）に接続された中央処理装置で表された、例示的な状況を示す。この構成においては、中央処理装置は、従来通り、パケットを一つ以上の目的地、即ちトラフィックマネージャ／アービタへ、パケットソースからのパケットのストリーム中で確認されたパケットを、本実施例においてディスクメモリ及びその制御装置として表示された、ネットワークに接続された格納素子のような、一つ以上のアドレス可能な目的地、又は読み出し装置などに向けて方向付ける形で通過させなければならない。

発明の観点に基づくと、パケットデータは、まずネットワークアクセラレータの形のインターフェース装置により取り扱われる。パケットの取り扱いを制御するために、入ってくるストリーム状態のＲＴＰパケット内のヘッダ値を置換するように設定されたネットワークアクセラレータは、有ったとしても最小限の計算的な複雑性を有する、高いスループットの装置として実現される。特に、値は制御装置によりネットワークアクセラレータの連想メモリ内にセットされる。この値は、パケットを格納装置又は読み出し又は他のローカルな目的地に伝送する、ローカルアドレス値で、ヘッダ値を直接置き換えることが出来る。または、ハードウエアアクセラレータは、制御装置によりパケットを、効果的に信号経路を分割し、ある内容の二つ以上のコピーを二つの目的地へ導くなど、どこか他の方向に伝送するように管理されることも可能である。

この目的のために、ハードウエアアクセラレータの連想メモリは、ストリームの処理が開始された時点で個々のストリームに対応した、一連のアドレス、ヘッダ値、フラグなどをロードしたテーブルを形成する。追加のパケットがリアルタイムで到着すると、ハードウエアアクセラレータが連想メモリ内の対応する情報に、関連するストリームに関するテーブル項目を探し出すことでアクセスし、該パケットのヘッダ値を連想メモリ内にロードされた値から生成されたヘッダ値又は該連想メモリ内にロードされた値の中から見つけたヘッダ値と置き換える。連想メモリ内の値の一部は、例えばユーザコマンドを実行するなど、制御処理装置内で生じている値である。連想メモリ内の該値の一部は、制御処理装置から独立したハードウエア処理装置の運転により生成することも出来る。例えば、ハードウエア処理装置は、ＵＤＰパケットの損失を回復するために、又はスイッチング機能を円滑に行なうためなど、ある条件の下でシークエンスナンバーを加算したり、タイムスタンプ情報を調整したりする計数器又は加算器を持つことが出来る。

この例における特定のソース及び目的地の存在は代表的な例である。本発明は、多かれ少なかれ基部又は末端となることが出来、また図に示すようにデータ通信で接続された、多様な潜在的なソース及び潜在的な目的地を有する状況に適用することが出来、その潜在的なソース及び潜在的な目的地は、そうした二つの存在間で、一方向、又は逆方向又は両方向に通過するパケットのソース又は目的地として、与えられた時間、機能することが出来る。この特別な例では、コンテンツ信号が再生装置で示されそして同時に記録される状況でパケットの通過が行なわれる。他の実施例では、データの流れは、データが記録されるが再生されない、又は再生されるが記録されない形で、セットアップされる。他の特定のソース及び目的地素子を用いることが出来る。同じ流入パケットは、一つのソースから二つ以上の目的地へ伝送することが出来る。また、二つ以上のソースからの内容が、例えば、ピクチャー・イン・ピクチャー図として調整された格納装置又は再生装置を指定したり、例えばテレビ会議時に、同時サイド・バイ・サイドディスプレイを指定したりすることが可能である。これらの及び他の同様な適用が本発明に基づいて簡単に行なうことが出来る。

データの流れは三つの主なタイプに分類される。即ち、全体の表示制御のためのＲＴＳＰパケット、個々のセッションを制御するＲＴＣＰパケットそしてデータ内容伝送のためのＲＴＰパケットである。

ＲＴＳＰは一つ以上の並行的表示又はデータ転送を制御するために使用されるアプリケーション層プロトコルである。単一のＲＴＳＰ接続はいくつかのＲＴＰオブジェクトの転送を、同時に及び／又は連続的に制御することが出来る。ビデオ会議装置においては、例えば多数の場所がある場合、双方向伝送が各場所の組間で発生する。ＲＴＳＰの文法は、ＨＴＴＰ／１．１のそれに似ているが、メディア伝送に特有の取り決めがある。セッションを規定する主要なＲＴＳＰコマンドは以下のようなものである。
・ＳＥＴＵＰ：サーバにストリームのリソースを割り当て、ＲＴＳＰセッションを開始する。
・ＰＬＡＹ及びＲＥＣＯＲＤ：ソースからのＳＥＴＵＰを介して割り当てられたストリーム上で目的地へのデータ伝送を開始する。
・ＰＡＵＳＥ：サーバリソースを解放することなくストリームを一時的に停止する。
・ＴＥＡＲＤＯＷＮ：ストリームに関連したリソースを解放する。ＲＴＳＰセッションはサーバ上で終了する。

制御ポイントがＲＴＳＰ ＳＥＴＵＰ要求を使用してオブジェクトの伝送を要求した場合、それはサーバ及びクライアントに、オブジェクト識別、ソース及び目的地のＩＰアドレス、プロトコルポート及び使用すべき伝送レベルプロトコル（一般的に、ＲＴＰ及びＴＣＰ又はＵＤＰ）などのオブジェクト伝送の詳細を含む要求を送る。こうしてＲＴＳＰ要求はクライアントとサーバへのセッションを記述する。ある場合には、該要求は、特にオブジェクトのオーディオ又はビデオ成分のような、利用可能なオブジェクトの一部のためのものであり得る。

全ての必要なＳＥＴＵＰ要求が為され、認識されると、制御ポイントは、伝送の方向に応じてＰＬＡＹ又はＲＥＣＯＲＤ要求を出す。該要求は、配達されるべきオブジェクトの一定の範囲、オブジェクトの通常の再生時間及び再生を始める現地時間を指定することが出来る。

再生が完了すると、あたかもＰＡＵＳＥコマンドが出力されたかのように、表示は一時的に休止される。ＰＡＵＳＥコマンドが出力されると、ストリームが停止されるべきタイムスタンプが記録され、サーバ（クライアント）は、引き続いてＰＬＡＹ（ＲＥＣＯＲＤ）要求が出力されるまでデータの配達を止める。

ＴＥＡＲＤＯＷＮ要求が出力されると、特定のストリームに関するデータの配達が停止され、全ての関連するセッションリソースは解放される。

ＲＴＳＰコマンドは、ＲＴＰ／ＵＤＰ又はＲＴＰ／ＴＣＰが伝送に使用すべき帯域外伝送（転送）セッションを規定することが出来る。“帯域外”伝送とは、二つ以上の異なる伝送又は接続経路を意味する。この場合のＲＴＳＰトラフィックは一つ以上の接続であり、また、ＲＴＰデータの実際の転送を実行するために、異なる接続がＲＴＳＰにより規定される。

ＲＴＰパケットはＴＣＰ上を搬送することが出来る。これは、ＵＤＰ伝送は、維持された接続を要求せず、喪失パケットに鈍感であり及び／又は、ＴＣＰのように喪失パケットの検出及び復旧を試みないことから、一般的に言って非効率的である。ＵＤＰ伝送プロトコルは、オーディオ又はビデオデータサンプル値などのパケットのリアルタイム伝送に適している。そうした値は、それぞれはそれほど重要ではないが、大容量での伝送が必要となる。ＴＣＰはＵＤＰとは、接続が確立している点で異なり、例えば、再伝送を試みてパケット損失を回復することを試みるなど、該プロトコルは信頼性を重要視している。これらの点は、ＲＴＰを必要とするＵＤＰよりもより矛盾しないものである。この開示は、一般的にＵＤＰがＲＴＰ伝送に使用されると想定している。しかし、本開示は好ましいＵＤＰ伝送に限らず、そのかわりＴＣＰの他のプロトコルもまた含む。

サーバがＲＴＰを用いて配達すべきオブジェクトの要求を受けると、オブジェクトは一般的にその本体のフォーマットからパケット化が可能なフォーマットに変換される。多数の“コメント要求（ＲＦＣ）”のメッセージスレッドが、前述のパケット化可能なデータに関連した問題を解決するために産業界において展開され、例えば,多様なメディアタイプに関する関連ＲＦＣを含む、多数の“コメント要求（ＲＦＣ）”のメッセージスレッドが、インターネットエンジニアリングタスクフォース（Internet Engineering Task Force）(ietf.org)によってオンラインアクセス可能に維持されている。

各メディアオブジェクトタイプは、通常、関連するＲＦＣで示された標準仕様に基づいて、各オブジェクトタイプでヘッダーフォーマットを変える形で、幾分か異なった形でパケット化される。該相違は、異なる用途を持ったデータを取り扱う際に遭遇する問題と異なるオブジェクトに起因するものである。

図３は、共通のＲＴＰヘッダーのフォーマットを示すもので、例えば、ＲＦＣ３５５０／３５５１で定められたものである。ヘッダー部分の略語は、以下のようなものである。

“Ｖ”はバーションナンバーを示すもので、現在のバージョンは２である。ＲＴＰフォーマットであるパケットを独自に示す固有のものはヘッダー内には無いが、このヘッダー位置のバージョンナンバー“２”の表示は一つのインジケータである。

“Ｐ”は、ペイロードの最後に無視すべき何らかの付け足し（パディング）が有るか否かを示す値で、有る場合には、付け足しの長さ。付け足し値の最後のバイトは付け足しバイトの全長を示す。

“Ｘ”は、拡張ヘッダーが存在するか否かを示す値。

“ＣＣ”は、このヘッダー内で確認されたコントリビューティングソース（貢献ソース）の総数。

“Ｍ”は、マーカビットである。このビットの実行は、ペイロードタイプに独特のものである。

“ＰＴ”はペイロードタイプを示す。即ち、伝達されるべきオブジェクトのタイプを示す。とりわけ、ペイロードタイプ識別子は、受信器にどのようにしてＲＴＰストリームを終わらせるかを決定させることが出来る。

“シーケンスナンバ”は、伝送されるＲＴＰパケットの数のカウント。これは、伝送されたバイトの数を示すためにシーケンスナンバを使用する、ＴＣＰとは異なるものである。ＲＴＰシーケンスナンバは、伝送されたＲＴＰパケットの数、即ち、パケットインデックスである。

“タイムスタンプ”は、ペイロードタイプに依存するフィールド値である。通常、タイムスタンプは、送られたパケットの時間的な見出しであり、ある時には、受信機に、パケットの内容を記録又は再生する際のタイミング状態を適合させる参考となる。

“ＳＳＲＣ ＩＤ”は、伝送されるべきデータのソースを示す。

“ＣＲＳＣ ＩＤ”は、ミキサーやトランスレータなどの、伝送されるべきデータを処理した、何らかのコントリビューティング（貢献）ソース又はソースを示す。複数の貢献ソースが存在し得るし、また、ＳＳＲＣ ＩＤで示されたオリジナルソース以外には無い場合もある。上記したように、ヘッダーのＣＣの値は貢献ソースの総数を示している。該数は、貢献ソースの識別子の確認された数、それ自体を処理し、該ヘッダに続く内容に先駆けたインデックスとすることができる。

もし、Ｘビットがセットされていると、ＲＴＰヘッダーの後に拡張ヘッダーが有る。拡張ヘッダーの仕様及び性質は、ペイロードタイプに従属する。ペイロード独特のサブヘッダーは通常、パケット損失が改善されるような方法で、規定され、ある程度の周期的な発生には耐えることが出来る。ＭＰＥＧ２などの、あるフォーマットにおいては、ビデオ及びオーディオエンコード情報を有する多数の複雑なサブヘッダーが、メインのＲＴＰヘッダーの後に続く。

ペイロードが図３に示したパケット最後のサブヘッダーの後に続く。本体のメディアオブジェクトに対するペイロードの関係も、対応するペイロードタイプを記述する基準により決定されている。本来のオブジェクトと一連のＲＴＰパケットのペイロードとの間にはしばしば、１対１の対応が無い。これに影響する多様な要素があるが、例えば、ＲＴＰパケットペイロードシーケンスと本来のオブジェクトに含まれるバイトのシーケンスの間の相違に関する状況のいくつかの例がある。
・与えられたフレームについて、オーディオ及びビデオ情報を同期させる必要
・ＲＴＰペイロード内のデータブロックのインターリービング
・重要なデータ素子に関するリピートパケット
・オーディオ／ビデオの多重分離
・又は１．１．３ＲＴＣＰ

与えられたＲＴＰセッションがアクティブな間、周期的に、該セッションに関する制御情報が、ＲＴＣＰを用いた別の接続で交換される（ＵＤＰの場合、ＲＴＰセッションは偶数番号の目的地ポートを使用するが、ＲＴＣＰ情報は、次のより高い奇数番号の目的地ポート上で伝送される）。ＲＴＣＰはデータ分配の品質に関するフィードバックを供給することを含む多様な機能を有し、それはネットワークの問題がローカルなものか、グローバルなものかを決定するうで、サーバにとって有益であり、特にＩＰマルチキャスト伝送の場合に有効である。ＲＴＣＰは、ＲＴＰソースに関する、永続的な伝送レベル識別子（a persistent transport-level identifier）である、ＣＮＡＭＥを運ぶ機能も有する。コンフリクト又はプログラムの再スタートはＳＳＲＣ ＩＤＳの移動が生じるので、受信器は各参加者の軌跡を保持するためにＣＮＡＭＥを要求する。ＣＮＡＭＥは、多様なＲＴＰセッションから多数の関連するストリームを同期させるために使用することも出来る（例えば、オーディオとビデオを同期させる）。

伝送の全ての参加者はＲＴＣＰパケットを送るように要求される。セッションにおける参加者の数が増加すると、それぞれにより送られるパケットの数は、都合良く減少させられる。各参加者にそのＴＲＣＰパケットを他の全ての参加者へ送るようにすることで、各参加者は参加者の数を常に把握することが出来る。この数は、今度は制御パケットが送られる速度を演算するために使用される。ＲＴＣＰはユーザインタフェースで表示される参加者情報のような最小限のセッション制御情報を伝送するために使用することが出来る。

これらのタスクを達成するために、ＲＴＣＰパケットは以下のカテゴリー又はフォーマットのうちのひとつに分類される。
・ＳＲ：送信者レポート、アクティブな送信者である参加者からの伝送及び受信の統計用
・ＲＲ：受信者レポート：アクティブでない送信者である参加者からの受信の統計及び、ＳＲと組み合わせて、３１ソース以上について報告しているアクティブな送信者用
・ＳＤＥＳ：ＣＮＡＭＥを含む、送信元記述事項
・ＢＹＥ：参加の終了を示す
・ＰＰ：アプリケーションの特別な機能

ＲＴＰのように、ＲＴＣＰパケットのぞれぞれのフォームは共通ヘッダで始まり、可変長のサブヘッダーが続く。多数のＲＴＣＰパケットは連結されて結合されたＲＴＣＰパケットとすることが出来、それはより下層のプロトコルの単一パケットで一緒に送ることが出来る。

本発明の観点は、ハードウエアのみの又はソフトウエアのみによる解決法を提供する代りに、ハイブリッドなハードウエア及びソフトウエアによる解決法を提供することで、総合的なＲＴＳＰ／ＲＴＰの解決法の改良である。全てをハードウエアで解決する手法は、全ての制御状況のシナリオを提供するために、極めて複雑化する。反対に、そうした複雑さを扱うことの出来る処理装置及びコーディングを備えたソフトウエアのみの解決法も、十分に開発されてはいない。与えられたストリームが処理中となった後の殆どの処理に関しては、与えられたストリームに続くパケットを、それまでのパケットと同じ方法で取り扱いを継続する処理の多くは、反復が多く、コンピュータ的なパワーが要求されない演算を用いて取り扱われる。

本発明の有利な実施例に基づくと、大規模にセットアップされ、潜在的には複雑であるが有能なソフトウエアプログラムを実行する制御装置により設計された制御手順がハイブリッドな解決方法として提供される。しかし、メディアオブジェクトを使用し、そしてソフトウエアにより生成されるファイルをサポートする伝送を加速するために、専門化されたハードウエアが使用される。

演算が比較的複雑であることと、演算頻度が少ないことから、主として制御ステップに関するＲＴＳＰ及びＲＴＣＰ機能は、中央処理装置内でそれに過大な負荷を掛けることなくソフトウエアにより実施される。一方、ＲＴＰは、メディアストリーム内でそれぞれの入ってくる及び出てゆくパケットを、リアルタイムデータ速度で順番に、又は殆ど順番に処理することが要求され、本発明によるハードウエアによる加速の利益が要求される。

ストリーミング機能の特定の一部、即ち、ＲＴＰコンテンツのオフロードを行なうハードウエアによりＲＴＳＰ／ＲＴＰを利用する、運転の一例についてここで述べる。この機能はパーソナルビデオレコーダ（ＰＶＲ）で広く使用され、エンドポイントからＲＴＰの規格化されたデータを受入れ、即座に又、任意の時間の経過後に、該同じＲＴＰの規格化されたデータを、同じ又は異なるエンドポイントに送ることとして説明することが出来る。これは、該エンドポイントが一時的なものであったり、変化したり、切り替わったりする（例えば、ユーザの選択により）ような機能の特性を有する。該エンドポイントの特別な性質は記述した本発明の運転にとって必須なものではない。エンドポイントは、ビデオカメラや再生受信器などの始まりとなる又は最終的な表示装置であったり、圧縮／解凍又はフォーマット変換装置であったり、又はこれらとストリーム内のパケットデータ信号が目指しているか、出発している他の素子との組み合わせであったりする。

図２に示すように、メディアストリームは３つの主要なアーキテクチャー上の存在を有しており、それは、即ち中央処理装置、トラフィックマネージャ／アービタ、及びネットワークプロトコル又はハードウエアアクセラレータである。これらの構成は、その物理的実施例により変わりまた、回路と制御工程の条件により、より簡単になったり、複雑になったりする。特定の回路素子は多かれ少なかれハードウエア的に配線される形で、回路は実施されるので、こうした素子のある機能は、本発明に基づくＲＴＳＰ／ＲＴＰトラフィックに関連する形で、規定される。

中央処理装置はシステム処理を支配する。ネットワークプロトコルアクセラレータ又は“ハードウエアアクセラレータ“はリソースが集約されてはいるが、多分反復又は繰り返しの多い処理タスクを取り扱う。こうしてハードウエアアクセラレータは、高周波数で複雑性の低い演算を行なうことから中央処理装置を助ける。入ってくるＲＴＰパケットのヘッダ（図３に示す）により部分的に提供され、またストリームをセットアップする際に制御装置３９により設定される値により部分的に提供される情報に基づいて、図４に示すローカルヘッダがパケット２２のＲＴＰヘッダの前に付加される（図４に示す）。こうしてデータの流れは、連想メモリを用いて、プルグラム的な影響を受けたローカルなアドレスを置き換え付与されたヘッダーフィールドにより、各パケットは制御装置３９を通過させる必要なく、図５のブロック図に示すように進行する。

ネットワークハードウエアアクセラレータは、連想メモリ（ＣＡＭ）又は、少なくとも現在進行中のこれらのストリームに対して、該メモリ内で相互参照される値のテーブルを有している。連想メモリはハードウエアアクセラレータとの接続のための接続パラメータを格納しており、それは少なくとも装置全体として使用可能な接続のセットを含むものである。ハードウエアアクセラレータは、入ってくるパケットが連想メモリ内に格納されたメッセージ待ち行列（キュー）情報に既に設定されたストリームと関連しているか否かを決定することの出来る回路を有する。もし、メッセージ待ち行列（キュー）の項目が有った場合、ハードウエアアクセラレータは該メッセージ待ち行列（キュー）の項目により既に決定された方法で、入ってくるパケットを取り扱う。もし、メッセージ待ち行列（キュー）の項目が無かった場合、該パケットが加速されたストリームの一部となるのならば、ハードウエアアクセラレータは中央処理装置に対して新しいメッセージ待ち行列（キュー）の項目を設定するように任せる。該パケットの取り扱い方法には、パケットのヘッダ値をローカルアドレスに置き換えること、特別の状況に対処するためにヘッダ値を改訂すること、異なるレベルのプロトコルに関連した値に変更することなどを含んでいる。

トラフィックマネージャ／アービタは、入ってくる及び出てゆくネットワークトラフィックの管理の他、メモリ及びディスクアクセスアービトレーションを提供する。それは多様なハードウエア的にアクセラレートされた接続及び中央処理装置の入力及び出力に割り当てることの出来る待ち行列（キュー）の数を管理する。

本発明の方法は、図４のデータの流れを示すブロック図及び図６のフローチャートに示される。メディアストリーマ装置は、エンドポイントからＲＴＰパケットのストリームを受け取ると、リアルタイムパケットの速度を維持するために、十分な効率と速度で、そしてデータ取り扱いに関する要求における変更と互換性のある十分に適用可能な柔軟性でもって、データを処理するように実行されなければならない。例えば、ＲＴＰペイロードタイプ、ソース及び目的地を動的に変える幅広いアレイを含む、エンドポイント又は中間素子と新しいソース／目的地との関係を呼び出したり、遮断したりするような変更である。

ＲＴＳＰ及びＲＴＣＰの演算はめったに起こらないので、中央処理装置でソフトウエアが走っている最中でも適切に実行することが出来る、たとえ、該プログラムが複雑であっても、データ内容に関するペースを維持することに関する問題は生じない。従って、これらの機能は、中央処理装置でソフトウエアが走っている最中に実行されることが望ましい。

一方、ＲＴＰの安定状態のストリーミングは、パケットの繰り返しの多い取り扱いである。例えば、ストリーム中の全てのパケットを、ストリームがアクティブである間、一時的に割り当てることの出来る特定の目的地に方向付けることなどである。この機能は、ネットワークアクセラレータ及びトラフィックマネージャ／アービタの専用のハードウエア内で取り扱われる。

しかし、複数のストリームが同時にアクティブになることがある。与えられたストリームに関してパケットを矛盾無く取り扱うためには、連想メモリは該ストリームに適用可能な、目的地アドレスやロストパケットシーケンスナンバ等の、１セットの値を持っている必要がある。ハードウエア処理装置は、連想メモリを経由して関連するパケットデータ値が参照された、ストリーム確認情報を保持するレジスタを持っている。比較処理（それはゲート演算や単純な演算を含む）により、ハードウエアアクセラレータは入ってくるパケット上の識別情報と連想メモリ内の項目を比較し、一致したパケットについての情報を出力に出す。この処理は、例えば、ヘッダアドレス情報などのパケットヘッダの値を、該パケットが関連しているストリームについての、連想メモリから読み出したローカルアドレス情報と置き換えるために使用される。

値の置き換えは、図６のフローチャートに概略を示すように、単純で繰り返しの多い処理である。もし、次のパケットが現在のストリーム中の一部で遭遇した場合、現在のストリームは待ち行列（キュー）項目を持っている。ストリーム確認情報（例えば、アドレス情報）は待ち行列（キュー）、即ち、連想メモリ内の項目と比較される。もし、項目が見つからなかった場合、処理装置は信号を出し、適当な待ち行列（キュー）の項目値を決定し、それらをハードウエアアクセラレータの連想メモリ内に格納するようにプログラムされた処理装置により、項目が設定される（処理装置の機能は、波線による箱内に示す）。引き続く更なる処理に中に、ハードウエアアクセラレータは受け取った次のパケットに関する項目を決定し、オリジナルのヘッダ値を連想メモリからの値に置き換え、ストリームの終わりまで続ける。その後すぐ、そのストリーム確認情報についての連想メモリ内の待ち行列（キュー）の項目から離れる。ストリーミング装置は、リソースを用いた新しい接続をサポートする準備が整い、解放される。

ソフトウエア処理は、例えばユーザ入力選択を扱う特定の処理を開始し、停止し、その処理間で切替えることが出来るアプリケーションプログラムインターフェース（ＡＰＩ）を介した、ハードウエア素子によるインターフェースを含む中央処理装置により実行される。ＡＰＩは、ハードウエアユニット（レジスタへの読み書き、ハードウエア待ち行列（キュー）へのアクセスなど）と中央処理装置間の直接的なインターフェースを隠す。

好適な例では、個人ビデオ記録（ＰＶＲ）装置の機能性は以下のように実行される。なお、この記述は限定的な例ではないものと理解されるべきである。

中央処理装置のプログラム中で走っているＲＴＳＰ機能は、パケットデータのソース又は目的地であるエンドポイントから受け取るべきＳＥＴＵＰコマンドをモニタしている。ＲＴＳＰ−ＳＥＴＵＰ要求からなるパケットがネットワークアクセラレータに受け取られると、そこで確認されたストリームは、ＣＡＭの参照テーブル内の項目を参照しない。ネットワークアクセラレータはそれらを適当なトラフィックマネージャの待ち行列（キュー）（中央処理装置に入ってくるトラフィックに関連する待ち行列（キュー））に割り当てる。一旦、ＲＴＳＰ処理が完全なＳＥＴＵＰメッセージを受け取ると、ＣＡＭ参照パラメータ（ソース及び、目的地のＩＰアドレス及びポート、伝送プロトコル）がＳＥＴＵＰメッセージ（全体又は部分）から決定される。ＣＡＭテーブルの接続テーブル項目はＲＴＰセッションに関して設定される。

ＲＴＳＰは次いで、関連するエンドポイントからの引き続くＲＥＣＯＲＤ要求を待つ。ＲＴＳＰ−ＲＥＣＯＲＤメッセージを受けると（受けたとき）、ＳＥＴＵＰメッセージのパスと同じ経路で、それはネットワークアクセラレータからトラフィックマネージャ、中央処理装置へ通過する。ＲＥＣＯＲＤメッセージは、記録すべきストリームの（時間）幅を含んでいる。この時点でセッションは確立したものと考えることが出来、ネットワークアクセラレータはデータを受け取る準備が出来る。中央処理装置は時間幅を基にしたオブジェクトザイスを出力し（時間幅が規定されていない場合には、最大値が出力される）、利用可能な待ち行列（キュー）識別子ＱＩＤがスケジューリングの為にトラフィックマネージャに出力される。これにより、ハードウエアアクセラレータは、ストリームが変化することなく続く限り、ヘッダ値を単に置き換えることでパケットを処理することができる。

例えば、もし、ローカルな記憶装置が、入ってくるストリームの記録を開始したりすると、ＣＡＭテーブル項目が終わらせられたり、修正されることで変化が生じ、再生装置へストリームを指向させている項目が変更され、パケットもまたディスク制御装置へ送られる。逆に、ストリームとエンドポイントをローカルな記憶装置で関連付ける他の項目が加わることも有る。

ＲＴＰ終了ルーチン、状況により変化する切替え処理及び類似した計算が強化された機能は、相対的に単純なハードウエア内で実行するには余りにも複雑である。リアルタイムでのストリーミングデータパケットの時間的なプレッシャーは、また、余りにも厳しく、広汎なプログラムを扱う中央処理装置は入ってくるトラフィックを常に（即ち、プログラムの実行中に）タイムリーに効率的に扱うことは出来ない。本発明は、ストリーム中の各パケットがネットワークアクセラレータにより受け取られるところで、代わりの方法を実行する。それは、接続テーブル内でパケットを照合し、レイヤ３及び４ヘッダを取り除き、ローカルヘッダを適用し、ローカルヘッダ、ＲＴＰヘッダ及びＲＴＰペイロード付きの各パケットを書き込み用のトラフィックマネージャに、ローカルディスク等の目的地に送るものである。

入ってくるパケットのフォーマットは、パケットの全長に関する値及び他の必要なフラグを含む３２ビット長からなる、ローカルヘッダ（Local Header）である。これらのフィールドは各ＲＴＰパケットの境界を規定し、該パケットがディスクに格納された後に有用なものとして残る。オブジェクトがこのフォーマットで格納される一方で、格納されたパケットは受領通知のため起源となるエンドポイントへ逆配達するためにスケジューリングされるか、ネットワーク上の他のエンドポイントにルート付けられる。トラフィックマネージャは、各パケットについてローカルヘッダ（Local
Header）からレングス（Length）フィールドを抽出し、伝送サイズとして使用するなど、オブジェクトのパケットを一つずつ読むことが出来なければならない。トラフィックマネージャはデータのレングス（Length）バイトをネットワークアクセラレータに送り、待ち行列（キュー）を次のパケットの始まりに進める。

パケットがトラフィックマネージャから受け取られると、ネットワークアクセラレータはローカルヘッダを取り除き、相殺するものを加える。この相殺するものは、最初は中央処理装置で決定され、関連する伝送用に連想メモリ（ＣＡＭ）内のフィールドとして格納され、ハードウエアアクセラレータにより外に出てゆくパケットのＲＴＰヘッダ内に配置される、シーケンスナンバ（Sequence Number）フィールドを決定するのに使用される。これは、ＲＦＣ３５５０に規定されたように、ランダムＩＳＳの規定を可能とする。

外に出てゆくタイムスタンプは同様な方法で調整される。これは、ＲＦＣ３５５０で規定されたように、ランダムＩＴＳの規定を可能とする。

レイヤ３及びレイヤ４ヘッダは外に出てゆくパケットのヘッダ内に似たような構成で配置されている。外に出てゆくパケットはＭＡＣ／ＰＨＹブロックに送られる。

この方法の一つの利点は、入ってくるＲＴＰトラフィックがソフトウエアで管理することが出来ることである。多様な異なるＲＴＰペイロードタイプが使用されるようになり、また、恐らく定義が異なっているので、それらのサポートは、創意に富むストリーミング装置により維持が可能となる。更に、記録中に遅れて見る（delayed-view-while-recording）のＰＶＲ機能性がサポートされる。

欠点としては、オブジェクトがＲＴＰヘッダーフォーマットで格納されている間、ＨＴＴＰ伝送でのアクセスが出来ないことである。ＲＴＰでないクライアントに対して直ぐに、又は必要なリソースが利用可能となるまで延期された形の再構築によって全てのクライアントに対して利用可能にするために、ホスト中央処理装置上のソフトウエアがオリジナルメディアオブジェクトを再構築するために使用される。

図７に、好適な実施例を示す。本発明は、ディスクアレイ制御装置を有するデータ処理システム内に導入されている。この制御装置は格納管理を行なうことが出来、消費者の電子デジタルメディア利用又は通信及びテレビ会議などの似たような特徴を持った利用に対して貢献することができる。娯楽の利用においては、本制御装置はホームネットワークと、デジタルメディア（オーディオ、ビデオ、イメージ）を格納するハードディスク装置（ＨＤＤｓ）によって一般的に例示される、データ貯蔵装置のアレイ間のインターフェースを提供する。

装置は好ましくは、ホームネットワーク又は他のローカルエリアネットワーク（ＬＡＮ）に対するインターフェースとして、統合型１０／１００／１０００イーサネットＭＡＣポートを有している。ＵＳＢ周辺装置アタッチメントポートは、メディア入力装置（フラッシュカードなど）に又は外部ワイヤレスＬＡＮアダプタを追加することでホームネットワークに接続することが出来る。

好ましいデータ取り扱いシステムは、より上層のプロトコルアクセラレーションエンジン（ＩＰ／ＴＣＰ、ＩＰ／ＵＤＰ用）及びセッションアゥエアトラフィクマネージャを介して、メディアアーカイブにハイパフォーマンスなシェアアクセスを行なう多数の層及び機能を有する。セッションアゥエアトラフィックマネージャは、中央処理装置として、ここで述べたＲＴＰストリーミングを管理することに加えて、実際のメディアセッションに基づいて、ネットワーク帯域、メモリ帯域及びディスクアレイ帯域などの共有資源を割り当てることが出来る。例えば、ビデオセッションは、イメージブラウジングセッションよりもより多くの資源が割り当てられる。更に、帯域は、時間に敏感なメディアセッションに関してはその帯域が保証される形で割り当てられ、また、メディアセッションの大量アップロードやマルチＰＣバックアップアプリケーションなどの、時間に敏感でないアプリケーションには、ベストエフォートとしての帯域が割り当てられる。

データ取り扱いシステムは、関連するハードディスクの重複アレイ（ＲＡＩＤ）に対する高いパフォーマンスストリーミングを含む。ストリーミング−ＲＡＩＤブロックは、エラー防御に関する冗長性を持ち、単一ＨＤＤの欠点に対してアーカイブに格納されたメディアを保護する。ＨＤＤは、シリアルＡＴＡディスクとすることが出来る。例えば、８個のＳＡＴＡディスクを有し、６４までの同時双方向ストリーミングをトラフィックマネージャ／アービタブロックを介して取り扱うことの出来るシステムなどである。

データ取り扱いシステムは本発明の多様で潜在的な態様の例であり、図７に示す全体のデータ取り扱いシステムは概要だけを述べたものである。装置内には、受信パスと伝送パスの、二つの別のデータパスが有ある。“受信パス”は、他の外部装置からシステムへ方向付けられたトラフィックフローと考えられ、“伝送”パスは、ソースから有る地点へのパス、及び与えられたストリームの文脈内での、それぞれの目的地へ向けたパスであり、データフローの反対の方向である。

上層処理装置（ＵＬＰ）はギガビットイーサネット制御装置（ＧＥＣ）又は周辺トラフィック制御装置（ＰＴＣ）への又はからのデータ通信と接続されており、ＰＴＣはパケット化されていないデータ伝送のためにトラフィックマネージャ／アービタに対し直接のインターフェースとなっている。パケット伝送は、ここで述べるように取り扱われる。

受信データパスでは、通常、ＧＥＣ又はＰＴＣブロックが物理インターフェース、例えばより大きなネットへ／からのイーサネットパケットを受け取る。ＧＥＣは、パケットの完全性やマルチキャストフィルタリング等、多様なイーサネットプロトコルに関連するチェックを行なう。パケットは、更なる処理のためにＵＬＰのブロックへ通過させられる。

ＵＬＰはアドレスから抽出された第２，３及び４層のヘッダーフィールドを解析する。接続探索は該アドレスに基づいて行なわれる。探索結果を用いて、ＵＬＰは受け取ったパケットを送るか否かを決定する。既に確立された接続からの到着パケットは、ＴＭＡによって使用されるトラフィック待ち行列（キュー）目的の予め定義された待ち行列（キュー）ＩＤ（ＱＩＤ）が付される。未知の接続からのパケットはアプリケーション処理装置（ＡＡＰ）による更なる調査が要求される。パケットは特別なＱＩＤが付され、ＡＡＰに運ばれる。ＡＡＰ通過後の到着パケットの最終目的地は、パケットがメディアコンテンツを持っているときには、格納用ハードディスクとなり、パケットが制御メッセージを持っていた時、またＡＡＰにより認識出来ないパケットの時は、更なる調査のためにＡＡＰとなる。そこで、新しい待ち行列（キュー）ＩＤを設定することとなる。上記したどのような場合でも、パケットはＴＭＡブロックに送られる。

ＴＭＡは到着したトラフィックを共用メモリに格納する。メディアセッションの伝送の場合には、入ってくるオブジェクトデータはメモリに格納され、ディスク格納のためにＲＡＩＤデコーダ及びエンコーダ（ＲＤＥ）ブロックに伝送される。ＴＭＡは適当な制御情報をＲＤＥに送って格納処理を管理する。ＡＡＰ調査のために充てられた制御トラフィックも共用メモリに格納され、ＡＡＰはメモリ内のパケットを読むためにアクセスされる。ＡＡＰは、このメカニズムを順序が狂った形で受け取ったパケットを再配列する為にも使用する。共用メモリ及びディスクの一部に、ＡＡＰ用のプログラム指示及びデータが含まれている。ＴＭＡは、ディスクからメモリ及びメモリからディスクへの制御情報を伝送することでメモリとディスクへのアクセスを管理する。ＴＭＡはまた、ＡＡＰに、現在のパケットストリームからデータを引き出させたり、またパケットストリームへデータを挿入させたりすることも出来る。

伝送データパスでは、ＴＭＡがディスクからのオブジェクト検索要求を管理するが、当該要求は、必要に応じて処理のためアプリケーション処理装置を経由して、又はそのままネットワークインターフェースに送られる。メディアプレイバック要求をアプリケーション処理装置から受け取ると、ＴＭＡはＭＤＣとＲＤＥブロックを介してディスクから伝送されたデータを受取り、メモリに格納する。そしてＴＭＡは該データを、要求された帯域及びメディアタイプに基いてＵＬＰブロックに登録する。ＵＬＰでは、外に出される各パケットについて、イーサネット及びＬ３／Ｌ４ヘッダーで該データをカプセル化する。パケットはそこで、指定された行く先ポートについてのＧＥＣ又はＰＴＣブロックに送られる。

受信データパス上の入ってくるパケットについては、ネットワークアクセラレータの接続探索機能部が、アドレス生成、ＣＡＭテーブル探索及び接続テーブル探索機能ブロックを含むことが出来る。ＣＡＭの探索アドレスは、入ってくるパケットのヘッダから抽出した情報の結果として一部が形成される。抽出されるべきヘッダーフィールドの詳細は使用されるトラフィックプロトコルに依存する。形成されるべきアドレスは唯一の接続を表すものでなければならない。例えば、ＩＰ Ｖ４及びＴＣＰ／ＵＤＰプロトコルで運ばれる最もポピュラーなインターネットトラフィックでは、ソースＩＰアドレス、目的地のＩＰアドレス、ＴＣＰ／ＵＤＰソースポート番号、ＴＣＰ／ＵＤＰ目的地ポート番号及びプロトコルタイプ（パケットのヘッダからの所謂“５組”）が唯一の接続を規定する。仮にパケットが異なるトラフィックプロトコル（ＩＰ Ｖ６のような）の場合、他のフィールドが接続を決定するために使用されてもよい。多数のプロトコルが使用されるところでは、フラグ、識別コードなどの適当な制御を参照することが出来、それによりシステムを“プロトコルを知っている”階層とする。例えば、処理は３つのステージに分割することが出来、各ステージはサポートされたプロトコルのレベルに対応している。第１のステージは、ヘッダの構文解析処理中に抽出されたフィールドから、Ｌ３プロトコルのバーション番号をチェックし、アドレス生成処理内のステップとして到着パケットに関する情報バッファ項目に格納することが出来る。アドレス生成処理の第２及び第３のステージは、複合ハードウエアテーブルが用いられる。各段階のテーブル項目数は、該テーブルが入るステージ及び各ステージでサポートされる異なるプロトコルの数に依存する。各テーブルの項目は、常に連想メモリ項目及び位置ナンバーレジスタを構成する。各位置レジスタは常に一組のオフセットサイズのフィールドを構成する。各ＣＡＭ項目は、対応する位置レジスタについての特定のプロトコル値を格納している。オフセットは、パケットのヘッダの最初から抽出されるべきフィールドまでの、スキップすべきバイト数を規定している。同じアドレスが、ＣＡＭフィールド及び位置レジスタへのアクセスに使用される。

特定のプロトコルレベルのヘッダ長は固定でないこともある。例えば、ＴＣＰ及びＩＰのヘッダ長は“オプションフィールド”により変化する。外側のレベルのプロトコルからの潜在的な可変ヘッダ長は、内側のレベルのプロトコルの位置を、内側のレベルのヘッダ長それ自体を含めて、相対的に動かしてしまう。変わるヘッダ長に適応するために、プロトコルヘッダ長フィールドは、長さフィールドを含むこれらのレベルについてのアドレス検索処理の一部として抽出が可能である。また、いくつかのプロトコル（ＩＰ Ｖ６及びＵＤＰなど）はヘッダ内に長さフィールドを持たない場合もある。その場合、ヘッダ長は抽出されず、与えられた接続中に固定ヘッダ長をセットし、保持するような他の技術を使用することが出来る。

アドレス生成処理を図８に図式的に示す。アドレス生成処理の間、パケットはバッファされ、プロトコルの第１レベル（例えば、ＩＰプロトコルのバーション番号）が確認され、パケットインフォメーションテーブルに格納される。パケットインフォメーションメモリには与えられた時間に多数の項目が有り、パケットインフォメーションメモリの先頭の項目は最初にアクセスされる。ヘッダ長（例えば、ＩＰヘッダ長）は、該ヘッダ長が存在していれば、パケットインフォメーションテーブルから抽出される。第１ステージから抽出されたプロトコルタイプコードは、第２ステージプロトコル値を見つける場所に影響する。

ＣＡＭはプロトコルとオフセットの全ての可能な組み合わせをサポートする。決定された第１のオフセットサイズ値は、プロトコルの第２のレベル（例えば、この例のＩＰプロトコルに関するプロトコルフィールド）の抽出に繋がる。ＣＡＭの数で１対１に対応する位置番号レジスタ項目は、各ステージで入力される。第２ステージには、各項目において、二組の位置レジスタがある。もしあるならば、ヘッダ長フィールド（例えば、ＩＰヘッダ長）が、位置レジスタの第２の組に規定されたオフセットに基づいて、パケットヘッダから抽出される。

第３ステージのフィールド抽出処理は、第２ステージのそれと似ている。しかし、第３ステージのＣＡＭアクセスは、第１及び第２ステージなどから抽出されたプロトコルタイプの連鎖を反映しなければならない。８つのフィールドから値を抽出するためにいまや８組のオフセットサイズフィールドがある。プロトコルタイプの値を考慮して各項目から抽出された多数のフィールドは項目を確認する為に使用され、値は互いに連鎖して最終的なアドレスを形成する。

バッファ又はアドレス生成レジスタ及び連想メモリ内でアクセスされるフィールドは、ネットワークアクセラレータにより取り扱われる。ＵＬＰの制御処理装置は、ＣＡＭ内の要求された値のアドレスを決定するための探索アドレスを構築するために必要な値を読むだけである。もし、アドレス生成処理中にＣＡＭの探索ミスが有ると、処理は強制終了することが出来、入ってくるパケットにはエラーフラグが付される。

もし、各ステージで抽出されたプロトコルフィールドが異なるプロトコル用の異なった長さを有する場合、固定のオフセットサイズを得るために項目を付加することも出来る。固定長のＣＡＭ探索を可能とするために、使用していないビットパッドメモリを固定ザイスとなるまでアドレスすることが出来る。

アドレス生成レジスタの大きさを要約することが出来る。第２ステージは二つのレジスタ入力、二つのＣＡＭ入力、及び各メッセージ待ち行列（キュー）項目についての一組の位置レジスタを有する。第３ステージは八つのレジスタ入力、八つのＣＡＭ入力、及び八組の位置レジスタを有する。各位置レジスタは１６ビットで構成され、１０ビットはオフセットを表し（５１２バイトをカバー）、６ビットはサイズ用である（６４ニブルを表す）。

アドレス生成セクションで生成された値は、接続が確立された時、即ち、特定のソースと目的地点間の特定のデータ伝送の接続の開始を伝えるパケットが到着した時、以前に格納された情報と共に、制御処理装置（即ち、アプリケーション処理装置）により使用される。制御処理装置は連想メモリ（ＣＡＭ）に入力を与える。ＣＡＭ内で各入力は唯一の接続を決定する。

システムがイニシャライズされた時（即ち、伝送接続が確立される前）、ＣＡＭには項目が無い。従って、最初のパケットが到着した時点では、アドレス項目は、ＣＡＭ内に一致するアドレス情報を見いだすことは出来ない。そして、パケットは一応、ＣＡＭ探索ミスと見なされる。この場合、特別待ち行列（キュー）ＩＤ（ＱＩＤ）が制御処理装置（即ち。アプリケーション処理装置ＡＡＰ）に備えられたメモリ位置で該パケットに割り当てられる。

ＡＡＰは、到着パケットを分析した上で、接続をセットアップする必要があるかどうかを決定する。ＣＡＭには自由な項目を設置することが出来る（即ち、同時にサポートすることの出来る、６４の可能なストリームの内の一つ）。自由に設定されたアドレスは、新しいストリームについての接続テーブルをセットアップするために使用される。ＡＡＰは接続アドレスをＣＡＭの自由項目に書き込み、そして同じアドレスを持って後に到着したパケットはＣＡＭ内の該項目と一致する。これにより、後に到着したパケットは、前述したネットワークアクセラレータ機能により処理されるので、後に到着したパケットについては、ＡＡＰの注意を必要とすることなく処理することが出来る。

到着したパケットがＣＡＭ内の項目を有する既存接続と一致することが分かると（ＣＡＭヒット）、一致したＣＡＭ項目のアドレスが接続テーブル情報、ＱＩＤ及び他の情報を探索するために使用される。本実施例では、６４の接続をサポートするために、６４のＣＡＭ項目がある。各ＣＡＭ項目には２５６ビットまで割り当てられている。勿論、他の構成でも可能である。

占有されたＣＡＭ項目と自由なＣＡＭ項目は共に、制御処理装置ＡＡＰによりアクセスすることが可能である。制御処理装置ＡＡＰは、ＣＡＭ項目のセットアップ、テアダウン及びリサイクルを実行することが出来る。

ＣＡＭ装置それ自体は、一般的にレジスタ及びゲート装置を有する形で多様な方法で設置すること出来る。レジスタ及びゲート装置は、アドレッシング入力として使用すべき入力データ値の少なくとも一部で、メモリから対応した出力データ値を抽出することを可能とする。ランダムアクセスメモリ装置は、一般的に特定のメモリアドレス、メモリ位置に対応する入力値をそれぞれアドレッシングすることで、データを格納及び検索することが出来る。多数のアドレッシングビットが多数のメモリ位置に対応する。メモリ項目の数が大きくはないところで、メモリ内で与えられた項目を見いだすために必要な時間は、メモリ内に格納されたデータの内容の一部とのデジタル的な比較（それ自体はむしろメモリアドレスを特定する）を可能とするハードウエアゲート装置により低減することが出来る。こうしてアクセスされるメモリを、連想メモリ（ＣＡＭ）と称し、前述したタイプの用途に利点がある。

議論された例では、ＣＡＭは格納された値を４から１４４ビットの幅で変えることが出来、６から１０２４の入力の幅を持っている。図９に示す、１実施例では、二つの連結されたＣＡＭ装置が設けられ、各装置は１２９ビットで６４の入力の装置であり、６４個までの双方向ストリームをサポートする。１２９ビットの内、１２８ビットはデータ格納に使用され、１ビットは、入力−有効（entry-valid）ビットである。この６４ｂｙ２５６ＣＡＭを構成する装置は、図９に、単純化されたＣＡＭ探索ロジックダイアグラムとして表示されている。ここでは、２５６ビットのワードは、二つの１２８ビットのサブワードに分けられ、各サブワードは分離されたＣＡＭ装置の内容と比較される。この装置においては、一方の又は他方の１２８ビットのサブワードをそれぞれのＣＡＭ装置内の多数の項目と比較することが出来る。しかし、完全な２５６ビットの項目だけが唯一の格納された値と対応する。この処理は、二つのＣＡＭ装置のアドレッシングの対応付け及び直列的な比較により容易化される。

到着パケットについてＣＡＭヒットが有ると、到着アドレスに一致する項目のＣＡＭアドレスが該接続に関する多様な情報値にアクセスするために使用される。これらの概要は、以下の表１に示す。

いくつかの接続において、ローカルヘッダが生成され、入ってくるそれぞれのパケットの前に付加される。こうしたローカルヘッダの生成はＡＡＰにより構成が可能である。ＡＵＬＰローカルヘッダは、ネットワークからパケットが到着したときに生成される。ローカルヘッダは図１０に規定されるフォーマットで３２ビットの固定長である。ＵＬＰが各到着パケットのバイト数をカウントすることで引き出されたパケット長を前に付加する。更に、ＵＬＰはギガビットイーサネット制御装置により生成され、そしてローカルヘッダ内の検索によりＵＬＰ自身により生成されたフラグを埋め込む。ＵＬＰは、ローカルヘッダがパケットの目的地に拘わらず有効である限り、同じフォーマットでローカルヘッダを加える。

本発明は、装置として例示されているが、方法発明としてとらえることも可能である。図面を参照することで、本発明のストリーミング装置（図１，２，７参照）は、制御値、ソースアドレス、目的地アドレス及びペイロードタイプの内、少なくとも一つを表しているフィールド２４を有するデータパケット２２を、ソース２７と目的地２９の間で管理する。通信経路３２はサーバ２７などからデータパケットを受取り、少なくともデータパケット２２の中身部分３３は、該データパケット２２の前記フィールドから決定される規則に基づいて、少なくとも一つのクライアント３５に向けて通過させられる。

規則は、データパケットが一つ以上のクライアントに向けて異なる方法で通過することで、変化するものである。例えば、異なる特定の装置にアドレスされたり、異なるプロトコル処理明細を介して処理されたりすることなどである。制御処理装置３９は、通信経路に接続されている。制御処理装置の機能は、一つ以上の上層処理装置（ＵＬＰ）及びアプリケーション処理装置（ＡＡＰ）又は追加的な制御装置により部分的、又は全体的に提供され得る。いずれにせよ、制御処理装置は、接続又はストリームを確立する際にパケットを処理する少なくとも二つの代替え手段に適用可能な手順を、少なくとも部分的に決定する。

発明の観点から見ると、メモリ４３を有するネットワークアクセラレータ４２は制御処理装置３９に接続しており、ネットワークアクセラレータのメモリ４３に、データパケットが異なる方法で通過する際の少なくとも二つの選択手順を示すデータをロードする。手順は、明確なローカルアドレス又はリモートアドレスを指示する（これに限らないが）ことを含んでいる。ネットワークアクセラレータ４２は、その後、制御装置３９と実質的に独立した形で運転可能であり、データパケット２２をクライアント３５に通過させる。データパケット２２は、フィールドを含んだヘッダ２４（図３）を有しており、ネットワークアクセラレータ４２は、そのフィールドを置き換えたり、付け加えたりの少なくとも一つを行なって、少なくとも二つの選択手順を選択するために、該フィールドに反応するように、運転が可能である。

本装置は、ＲＴＰリアルタイムプロトコルストリーミングを取り扱うのに適している。データサンプル又はＲＴＰ内の圧縮データプログラム等のプログラムコンテンツを含んだパケットに加え、データパケットは、ＲＴＳＰ及びＲＴＣＰストリーミング制御プロトコルの一つに基づく制御情報を更に有する。

好適な装置においては、ネットワークアクセラレータは、例えば、動作中に進行中の各ストリームの、ローカルアドレッシングに使用されるような、データ値を持った連想メモリを有している。制御装置は、与えられたストリームで使用されるべきデータ値をセットアップする。連想メモリを使用すると、制御装置のコンピュータによるリソース内に実質的に入り込まなくても、少なくとも連想メモリに接続されるか、含んでいるハードウエアアクセラレータを用いることで可能となる高いデータレートを利用して、同じデータ値の少なくともいくつかが同じストリームの引き続くパケットのために使用される。

少なくとも一つの変数を表す関連ヘッダ情報を有するコンテンツをパケット化するステップ（これにより、パケット化されたコンテンツが該変数により、該変数の機能として、一つ以上のソースと一つ以上の目的地との間で選択可能に取り扱われる）、ストリーミングコンテンツ内の制御情報を含み（パケット化されたコンテンツを選択的に取り扱う方法を、該制御情報により変えることが出来る）、該制御情報に基づいてソースと目的地との間で、パケット化されたコンテンツのストリームを設定し、又は方向を変え、休止し又は変更するステップ、そして、そうするときには、少なくとも部分的な前記制御情報から前記変数をある値に決定し、該値を該ストリームの識別子に関連してネットワークアクセラレータ内に格納するステップ、からなる方法を達成すべく、それぞれの部品は、運転される。その後、ストリームに関してパケット化されたコンテンツを受け取った時、該ストリームの前記識別子に関連してネットワークアクセラレータ内に格納された値を、該受け取ったパケット化されたコンテンツを取り扱うのに使用する。

従って、進行中のストリームのパケット化されたコンテンツはネットワークアクセラレータによって殆ど取り扱われ、制御処理装置の進行中の動作は最小となる。

発明は例示的な実施例に関連して開示されているが、独占権が要求されている発明の範囲を決定するには、実施例を議論するよりもむしろ添付されたクレームを参照すべきである。

図１は、本発明による、ソースから目的地へのデータ伝送関係（例えば、サーバからクライアント）を示すブロック図であり、ＲＴＰデータ内容成分は、ＲＴＳＰ及び／又はＲＴＣＰ制御信号を扱う中央処理装置などの制御ポイントの周囲を回って伝送される。 図２は、本発明によるストリーミング制御装置を示す図ブロック図である。 図３は、ＲＴＰヘッダの成分値を示す表である。 図４は、ローカルアドレスヘッダを有する、前に付加されたＲＴＰヘッダを示すデータ図表である。 図５は、連想メモリを用いて中央処理装置から最初に得た値を何度も適用する、データフロー及びデータ成分を示すブロック図である。 図６は、データストリーミング接続のセットアップを実行し、該接続を維持する機能を示す理論フローチャートである。 図７は、本発明のパケットデータ取り扱い装置を含むように構成された娯楽システム“ＨＮＡＳ”の構成要素を示すブロック図である。 図８は、異なったオフセットを持ったプロトコルが連結される時に適用することの出来るヘッダーオフセットの付加及び、パケットの宛先が該オフセットで決定される方法を示すものである。 図９は、好ましい装置に基づく連想メモリの多段接続を示す回路構成図である。 図１０は、本発明の運用によりデータパケットに適用される、ローカルヘッダの配置を示す、データ図表である。

Claims (16)

1. コントロール値、ソースアドレス、目的地アドレス及びペイロードタイプの少なくとも一つを表すフィールドを有するデータパケットを方向付けるためのストリーミング装置であって、該装置は、
   サーバからの前記データパケットを受け取る通信経路を有し、該経路に沿って前記データパケットの少なくとも内容部分が、少なくとも一つのクライアントに向けて、該データパケットの前記フィールドから部分的に決定された手順に基づいて、通過し、
   前記手順は、前記データパケットを前記少なくとも一つのクライアントに向けて、少なくとも二つの異なる道筋で通過させることの出来る少なくとも二つの選択肢を有し、
   前記通信経路に接続された制御処理装置を有し、該制御処理装置は、それぞれの前記選択肢に適用される前記手順の一つを決定するために、少なくとも部分的に運転することが出来、
   メモリを有するネットワークアクセラレータを有し、前記制御処理装置は、前記ネットワークアクセラレータの前記メモリに、前記データパケットを異なる方法で通過させるための、前記少なくとも二つの選択肢を表すデータをロードするように運転することができ、その後前記ネットワークアクセラレータは、前記制御処理装置とは実質的に独立した形で運転され、前記そのための手順に基づいて、前記データパケットを前記少なくとも一つのクライアントに前記異なる道筋で通過させ得る、
   ことを特徴とするストリーミング装置。
2. 前記データパケットは、前記フィールドを含むヘッダを有しており、前記ネットワークアクセラレータは、前記少なくとも二つの選択肢を選択するために、前記フィールドに対して置換し、付加する、少なくとも一つを行なうように、前記フィールドに対して運転し得る、
   ことを特徴とする、請求項１記載のストリーミング装置。
3. 前記データパケットが前記少なくとも一つのクライアントに向けて、該パケットに関連するアドレッシング情報を変更することによることを含む形で、異なる道筋で通過させられる、
   ことを特徴とする、請求項１記載のストリーミング装置。
4. 前記データパケットには、該データパケットが規則に基づいて通過されるべきローカルアドレスが付加される、
   ことを特徴とする、請求項３記載のストリーミング装置。
5. 前記データパケットは、ＲＴＰストリーミングプロトコルに基づいて構成されたコンテンツパケットを含み、そしてアドレス情報を含んでおり、該コンテンツパケットは、前記ネットワークアクセラレータにより、追加的及び置換的ないずれかのアドレス情報が与えられる、
   ことを特徴とする、請求項１記載のストリーミング装置。
6. 前記データパケットは、ＲＴＳＰ及びＲＴＣＰストリーミングプロトコルのいずれかに基づいた制御情報を更に有する、
   ことを特徴とする、請求項５記載のストリーミング装置。
7. 前記ＲＴＳＰ及びＲＴＣＰストリーミングプロトコルのいずれかに基づく制御情報を有する前記データパケットのうちの少なくといくつかのパケットの情報は、前記制御処理装置のプログラムに基づいて、前記少なくとも一つのクライアントに前記コンテンツパケットを通過させる前記規則を規定するために使用される、
   ことを特徴とする、請求項６記載のストリーミング装置。
8. 前記ネットワークアクセラレータは、前記制御処理装置により、前記規則を規定する情報がロードされた連想メモリを有しており、前記ネットワークアクセラレータは、前記制御処理装置のプログラムに基づいて格納された前記メモリ装置のデータから読み出すことで、所定のパケットに適用可能な所定の規則をアクセスする、
   ことを特徴とする、請求項７記載のストリーミング装置。
9. 前記データパケットは、少なくもとオーディオデータ及びビデオデータのいずれかを表し、前記規則は、オーディオ又はビデオ格納装置、娯楽装置、オーディオ通信設備及び遠隔会議設備のいずれかにおける、異なる切替え処理に適用される、
   ことを特徴とする、請求項８記載のストリーミング装置。
10. 前記ネットワークアクセラレータは、前記規則に基づいて前記パケットを、目的地装置及びネットワーク格納装置に方向付けるように運転することが出来る、
    ことを特徴とする、請求項９記載のストリーミング装置。
11. 前記ネットワークアクセラレータは、前記規則に基づいて前記パケットを、読み出し装置、格納装置、パケット伝送用中間データ処理装置、ローカルターミナル装置及びリモートターミナル装置を含む、目的地装置に方向付けるように運転することが出来る、
    ことを特徴とする、請求項１０記載のストリーミング装置。
12. 実質的にコンテンツをリアルタイムで参照する速度で該コンテンツをストリーミングする方法であって、該方法は、
    前記コンテンツを、少なくとも一つの変数を表す関連するヘッダ情報と共にパケット化し、そのためにパケット化されたコンテンツが、該変数の機能として、該変数により一つ以上のソースと一つ以上の目的地との間で選択的に取り扱われ、
    前記ストリーミングコンテンツに制御情報を含ませ、これにより前記パケット化されたコンテンツの選択的な取り扱い方法を該制御情報に基づいて変えることが出来、
    制御処理装置に前記制御情報へアクセスさせ、また、ネットワークアクセラレータに前記パケット化されたコンテンツにアクセスさせ、
    少なくとも一つの前記ソースと少なくとも一つの前記目的地の間で、前記パケット化されたコンテンツのストリームを確立し、方向を変え、休止し、さもなければ変更するなどのいずれかに際して、前記制御情報からある値を、前記変数の少なくとも一部に決定し、該値を、該ストリームの識別に関連して前記ネットワークアクセラレータ内に格納し、
    前記ストリームからパケット化されたコンテンツを受け取った際に、前記ネットワークアクセラレータから、該ストリームの識別に関連して格納された前記値を決定し、前記ネットワークアクセラレータから決定された前記値に基づいて、前記一つ以上のソースと前記一つ以上の目的地の間で前記受け取ったパケット化されたコンテンツを取り扱い、これにより、現在進行中のストリームの前記パケット化されたコンテンツを、前記制御処理装置の最小限の動作で、選択的に取り扱うようにして、
    構成したことを特徴とする方法。
13. 前記ネットワークアクセラレータに格納された前記値を変更することを含み、前記変更は前記制御処理装置の運転により行なわれる、
    ことを特徴とする、請求項１２記載の方法。
14. 前記制御処理装置は前記ネットワークアクセラレータに格納された前記値を、後に受け取った制御情報を処理した結果として、変更する、
    ことを特徴とする、請求項１３記載の方法。
15. 前記ハードウエアアクセラレータ内に、項目を持った複数の識別されたストリームを供給し、前記ハードウエアアクセラレータは、対応する識別されたストリームに関連して前記ハードウエアアクセラレータ内に格納された複数の値の一つを、前記パケット化されたコンテンツの変化に対して選択的に適用する、
    ことを特徴とする、請求項１２記載の方法。
16. 識別されたストリームに関する項目がアクセス可能なメッセージ待ち行列を持つ連想メモリを設け、
    前記識別されたストリームの一つに対応する識別子と項目をマッチングさせることで、前記複数の値の一つを決定する、
    ことを特徴とする、請求項１５記載の方法。

Images