JP2006109016A - 送受信装置、送受信制御方法、プログラム、およびメモリ - Google Patents

Abstract

【課題】低コストでかつホストＣＰＵのソフトの通信プロトコル処理が低負荷であるか、又は、ホストＣＰＵの通信プロトコル処理の介在なしで高速データ伝送可能で、かつ通信制御等で柔軟に処理することができ、さらに従来のホストＣＰＵがソフト処理するデータ伝送も使用可能な送受信装置を実現する。
【解決手段】ネットワーク３から受信したＡＶデータ及び制御データの一部が格納される第１受信バッファ３１と、それ以外の受信データが格納される第２受信バッファ３５と、所定の条件に従って第１受信バッファ３１と第２受信バッファ３５に受信データを格納するセレクタ手段３３と、第１受信バッファ３１のデータに所定のハード的処理を行うＩＰ処理手段１２と、ＩＰ処理手段１２で処理された結果と第１受信バッファ３１のデータに基づいて、所定のプロトコルで送信データを生成し、第１送信バッファ３６へ転送するローカルＣＰＵ１４とを備えた。
【選択図】図１

Description

本発明は、所定の通信プロトコルに従ってデータを送受信する、送受信装置および送受信制御方法に関するものである。

近年、Ｅｔｈｅｒｎｅｔ（登録商標）、ＩＥＥＥ８０２．１１規格に準拠した無線通信伝送路を用いて、インターネットプロトコルでデータ通信を行うＡＶ機器の開発が盛んに行われている。

例えば、映像コンテンツを、離れた場所にあるテレビや携帯端末にインターネットプロトコルで伝送して視聴するアプリケーションが多く提案されている。このアプリケーションでは、視聴される映像コンテンツの品質が高いほど、それを実現する機器の付加価値が高くなるため、インターネットプロトコルを安価に高速処理できる技術開発が望まれている。

しかし、インターネットプロトコル技術は、ワークステーションやパーソナルコンピュータで進化した経緯から、高速ＣＰＵによるソフトウェアでの実現が一般的であり、インターネットプロトコルで伝送された映像データをソフトウェアで処理すると、映像データの情報量が膨大になるため、高性能なＣＰＵを搭載する必要があり、製品価格が高くなってしまうという問題点があった。

この問題を解決するため、特許文献１では、高速処理が必要な映像データだけについてハード処理を行い、そのほかの処理については従来どおりソフト処理を行う方法で、コスト問題を解決する提案がなされている。

以下、図面を参照して説明する。

図９は、特許文献１で提案されているデータ送受信装置の一例の構成図をしめしている。図９において、１は映像データを送信するサーバ装置である。

サーバ装置１は、ＡＶエンコーダ２１、第１プロトコル処理部１２２、第１制御部１２５、第１ルータ２３、第１送受信部１２４で構成される。

また、クライアント装置２はＡＶデコーダ２６、第２プロトコル処理部１２７、第２制御部１２９、第２ルータ２８、第２送受信部１１９で構成される。

この様に構成された、サーバ装置１とクライアント装置２は、ネットワーク回線３で接続されている。ネットワーク回線３は、ＩＥＥＥ８０２．３規格のＥｔｈｅｒｎｅｔや、ＩＥＥＥ８０２．１１規格に準拠した無線ＬＡＮ等の、インターネットプロトコルが伝送可能な伝送路が使用されることが多い。

サーバ装置１では、送信ＡＶ信号を、ＡＶエンコーダ２１でデジタル処理を施し、第１プロトコル処理部１２２でＩＰ伝送のために所定のパケット構造に変換する。そして、第１ルータ２３を介して第１送受信部１２４へ信号伝達し、ネットワーク回線３へＡＶパケットを出力する。

ネットワーク回線３に出力されたＡＶパケットは、クライアント装置２の第２送受信部１１９で受信され、第２ルータ２８へ伝送される。第２ルータ２８は、受信されたパケットがＡＶパケットである場合には、ハードウェアで構成された第２プロトコル処理部１２７に転送する。そして、第２プロトコル処理部１２７が、パケット内に格納されたＡＶデータを抜き出してＡＶデコーダ２６に出力し、ＡＶデコーダ２６がＡＶ信号を生成する。

この様にして、サーバ装置１から転送されたＡＶ信号がネットワーク回線３を介してクライアント装置２で再生されることになるので、離れた場所でのＡＶコンテンツの視聴が可能になる。

この従来例のように、リアルタイムのＡＶ信号を伝送するには、ＵＤＰを用いた伝送方式が採用されることが多い。ＵＤＰによる伝送方式は、フロー制御を行う必要がないために簡単な回路で構成できるという特徴がある。この従来例では、第１プロトコル処理部１２２と第２プロトコル処理部１２７は、それぞれ異なる回路となるが簡単に構成できるので高品位の映像信号が安価に実現できる。

また、クライアント装置２を利用しているユーザが、視聴を開始・中断、またはコンテンツ選択するために、クライアント装置２からサーバ装置１に対して制御データを送信する場合や、サーバ装置１に選択されているコンテンツの種別・選択されているチャンネルなどのサーバ装置１の機器状況などをクライアント装置２が取得する場合などには、相互に通信する必要がある。この様な場合の制御データの通信は、ＴＣＰによる伝送が一般的である。

ＴＣＰは、高い信頼性で伝送できる特徴があるが、処理が複雑なためソフトウェアにより実現されるのが一般的であり、図９に示す従来例の場合には、この処理は第１制御部１２５および第２制御部１２９で実施される。処理は複雑であるが、ネットワーク回線３に伝送されるこのときの制御情報の情報量は、ＡＶパケットと比較してきわめて少ないため、処理負荷が小さく、ＡＶ機器内蔵のＣＰＵを他の処理と共用で第１制御部１２５および第２制御部１２９に使用できるので、安価に製造することができる。

この様なアプリケーションを実施する場合には、ネットワーク回線３にＡＶパケットと制御パケットが混在して伝送される事になる。したがって、受信パケットを、ソフト処理される第１制御部１２５または第２制御部１２９に伝送するのか、ハード処理される第１プロトコル処理部２２または第２プロトコル処理部２７へ伝送するのかを選択する、第１ルータ２３および第２ルータ２８の処理が重要になる。

図１０に、第１ルータ２３（第２ルータ２８も同様）の構成図を示した。

図１０に示した従来の第１ルータ２３では、受信データは、判別回路１３２に転送され、ＡＶデータと認識された場合には、セレクタ３３へその認識情報が伝達されて、ハードウェア用受信バッファ３４へ転送される。ＡＶデータ以外のデータの場合には、受信データはソフトウェア用受信バッファ３５へ転送される。

ハードウェア用受信バッファ３４に受信データが格納されると、その受信データは、ハードウェアで構成された第１プロトコル処理部２２へ転送され処理される。また、第１プロトコル処理部２２がデータを送信する場合は、ハードウェア用送信バッファ３８にデータを転送する。ソフトウェア用受信バッファ３５に受信データが格納された場合には、その受信データは、第１制御部１２５によりソフトウェアで処理される。第１制御部１２５からデータ送出する場合には、ソフトウェア用送信バッファ３９へデータが送信される。

第２ルータ２８においても、受信データおよび送信データは、上記と同様に処理される。

この様に設計された第１ルータ２３および第２ルータ２８は、サーバ装置１およびクライアント装置２で共用に使用することができるので開発工数の削減が可能となる。

この様に構成された送受信装置は、ＡＶパケットを高速にかつ安価にインターネットプロトコルで伝送可能であるという特徴を有する。

また、近年、ハードディスクを用いた記録装置が普及してきているが、ハードディスクには、映像データばかりでなく、写真、音楽など、さまざまなデータがファイル形式で記録されている。ハードディスクを搭載したサーバからクライアントへ伝送する方式として、データ信頼性が高く伝送できるＴＣＰを用いた汎用性の高いＨＴＴＰ伝送を採用したＡＶ伝送方式を採用した製品開発が行われている。

また、サーバ機器のハードディスクに記録されたファイル形式の映像データも、クライアント機器から高速に読み出し、離れた場所でも再生することをユーザから望まれているのは言うまでもない。
特許第３４９１６２６号公報

しかしながら、特許文献１に示されるような従来の構成の送受信装置では、ハードウェアでプロトコル処理を行うため、汎用性を実現することが難しく、以下の問題点があった。

（１）処理が複雑なＴＣＰでデータを送信する場合、ハードウェアの設計が困難である。

（２）複数の伝送方式に対応すると、ハードウェアの規模が大きくなる。

（３）ＡＶの伝送方式が確定しないとハード設計が行えない。

（４）プロトコル処理部は、送信側と受信側とで共通設計が難しい。

したがって、従来の構成の送受信装置では、複数種のコンテンツを扱う場合や、異なる伝送方式の対応などを実現する汎用性のある設計が困難であり、また、ＴＣＰやＨＴＴＰのような複雑な転送方式に対応することが困難であった。

本発明は、上述した従来の課題を解決するもので、ＡＶコンテンツ等の高速な伝送を安価に実現する、送受信装置、および送受信制御方法を提供することを目的とする。

上述した課題を解決するために、第１の本発明は、
ネットワーク回線からのデータを受信し、また、前記ネットワークへデータを送信する送受信手段と、
前記ネットワーク回線から受信したＡＶデータおよび前記ＡＶデータに関連する受信制御データの一部が格納される第１の受信バッファと、
前記第１の受信バッファに格納された以外の受信データが格納される第２の受信バッファと、
前記ネットワーク回線に送信するＡＶデータおよび前記ＡＶデータに関連する送信制御データの一部が格納される第１の送信バッファと、
前記第１の送信バッファに格納された以外の送信データが格納される第２の送信バッファと、
前記第２の受信バッファに格納された受信データをソフトウェア的に処理すると共に、所定のプロトコルで生成した送信データを前記第２の送信バッファに転送する制御部と、
前記ネットワーク回線から受信したデータのうち、予め設定された所定の条件により、前記第１の受信バッファまたは前記第２の受信バッファのいずれに格納させるかを判定する判別手段と、
前記判別手段の判定結果に基づいて、前記ＡＶデータおよび前記ＡＶデータに関連する受信制御データの前記一部を前記第１の受信バッファに格納し、それ以外の受信データを前記第２の受信バッファに格納するセレクタ手段と、
前記第１の受信バッファに格納された受信制御データの前記一部を読み込んで、そのデータに対して所定のハード的な処理を行うＩＰ処理手段と、
前記第１の受信バッファからＡＶデータを抽出して出力し、および／または、入力されてくるＡＶデータを前記第１の送信バッファへ転送する、ストリーム処理手段と、
前記ＩＰ処理手段で処理された結果と前記第１の受信バッファに格納されたデータを読み込み、これらの情報に基づいて、ソフトウェアで前記ストリーム処理手段を制御し、また所定のプロトコルで生成した送信データを前記第１の送信バッファへ転送して前記ネットワーク回線に出力させるローカルＣＰＵと、
前記ローカルＣＰＵを動作させるためのプログラムが格納されたメモリとを備えた、送受信装置である。

第２の本発明は、
前記ストリーム処理手段から出力されたＡＶデータを受信して処理し、および／または、前記第１の送信バッファに格納するためのＡＶデータを前記ストリーム処理手段に送信するＡＶ処理手段をさらに備えた、第１の本発明の送受信装置である。

第３の本発明は、
前記ネットワーク回線は、ＩＥＥＥ８０２．３規格に準拠している、第１の本発明の送受信装置である。

第４の本発明は、
前記ネットワーク回線は、ＩＥＥＥ８０２．１１規格に準拠している、第１の本発明の送受信装置である。

第５の本発明は、
前記所定のプロトコルは、ＴＣＰ／ＩＰであり、
前記判別手段は、ＴＣＰ／ＩＰ通信プロトコルに基づいたＴＣＰ制御フラグの一部またはすべてを走査する走査手段を有し、その走査した情報を前記所定の条件と比較することにより、前記ネットワーク回線から受信したデータを、前記第１の受信バッファへ格納させるか、前記第２の受信バッファへ格納させるかを判定する、第１の本発明の送受信装置である。

第６の本発明は、
前記ＩＰ処理手段は、（１）ＩＰヘッダのチェックサムの確認、（２）ＴＣＰヘッダのチェックサムの確認、（３）ＴＣＰヘッダのシーケンス番号の確認、（４）ＴＣＰヘッダのＡＣＫ番号の確認、（５）ＴＣＰヘッダのＷＩＮＤＯＷの検出および前記ローカルＣＰＵへの通知、（６）ＴＣＰの制御フラグ（ＦＩＮ、ＳＹＮ、ＲＳＴ、ＵＲＧ）の検出および前記ローカルＣＰＵへの通知、の各処理の一部またはすべてをハードで行う受信ＩＰ・ＴＣＰ処理手段を有している、第５の本発明の送受信装置である。

第７の本発明は、
前記第１の受信バッファは、前記受信データであるＴＣＰ／ＩＰセグメントを格納するために、それぞれが１５３６バイト以上の容量を持つ複数のセグメントバッファに分割されている、第５の本発明の送受信装置である。

第８の本発明は、
前記第１の受信バッファは、８つのセグメントバッファに分割されている、第７の本発明の送受信装置である。

第９の本発明は、
前記ローカルＣＰＵは、セグメント化された前記第１の受信バッファをリングバッファ方式で制御し、その起動開始バッファを設定する、第７の本発明の送受信装置である。

第１０の本発明は、
前記第１の受信バッファには、前記ＩＰ処理手段で処理された結果も格納される、第７の本発明の送受信装置である。

第１１の本発明は、
前記ＩＰ処理手段は、ＩＰヘッダおよびＴＣＰヘッダを解析し、ＴＣＰペイロードデータの開始位置および前記受信データの最後尾の位置をハード的に検出する、第７の本発明の送受信装置である。

第１２の本発明は、
前記ＩＰ処理手段は、検出した前記ＴＣＰペイロードデータの開始位置および前記受信データの最後尾の位置情報を、受信管理データとして前記第１の受信バッファに格納する、第１１の本発明の送受信装置である。

第１３の本発明は、
前記第１の受信バッファに格納された前記ＴＣＰペイロードデータの開始位置および前記受信データの最後尾位置情報に基づいて、前記受信データのＩＰヘッダおよびＴＣＰヘッダを削除して前記ストリーム処理手段にハード的に転送する手段を備えた、第１２の本発明の送受信装置である。

第１４の本発明は、
前記所定のプロトコルは、ＨＴＴＰであり、
前記ローカルＣＰＵは、前記第１の受信バッファに格納されている前記受信データを走査してＨＴＴＰヘッダの検出を行う、第１の本発明の送受信装置である。

第１５の本発明は、
前記ローカルＣＰＵは、前記ＨＴＴＰヘッダを検出した場合には、ＨＴＴＰペイロードデータの開始位置を検出して、前記受信データを前記ＨＴＴＰペイロードデータの先頭から前記ストリーム処理手段にハード的に転送させる、第１４の本発明の送受信装置である。

第１６の本発明は、
前記ＨＴＴＰペイロードデータは、動画像データを含んでいる、第１５の本発明の送受信装置である。

第１７の本発明は、
さらに、ＨＴＴＰヘッダ情報をソフトウェア的に処理するホストＣＰＵを備え、
前記ローカルＣＰＵは、前記ＨＴＴＰヘッダを検出した場合には、前記ＨＴＴＰヘッダに含まれるＨＴＴＰ＿ＧＥＴコマンドを検出し、そのＨＴＴＰヘッダ情報を前記ホストＣＰＵに伝達する、第１４の本発明の送受信装置である。

第１８の本発明は、
前記ホストＣＰＵは、ＨＴＴＰ＿ＧＥＴコマンドに対する応答情報を生成して前記ローカルＣＰＵに伝達し、
前記ローカルＣＰＵは、前記応答情報を受け取ると、前記応答情報を含むＨＴＴＰヘッダを生成して前記第１の受信バッファに格納し、前記ネットワーク回線に送信させる、第１７の本発明の送受信装置である。

第１９の本発明は、
前記ローカルＣＰＵは、前記ホストＣＰＵから受け取るＨＴＴＰヘッダ情報に基づいて、前記第１の送信バッファに所定のフォーマットでＨＴＴＰヘッダを書き込む、第１７の本発明の送受信装置である。

第２０の本発明は、
前記第１の送信バッファは、セグメント分割されており、
前記ストリーム処理手段は、入力されてくるＡＶデータを所定の長さに分割すると共に、少なくともＩＰヘッダを含むヘッダ情報を生成して前記第１の送信バッファに格納する送信ＩＰ・ＴＣＰ処理手段を有している、第１の本発明の送受信装置である。

第２１の本発明は、
前記送信ＩＰ・ＴＣＰ処理手段は、
ＭＡＣアドレスを含むＭＡＣヘッダと、
ＩＰのバージョン情報、サービス型（ＴＯＳ）、ＩＰヘッダ長（ＩＨＬ）、ＩＰヘッダＩＤ情報，フラグメント制御情報、フラグメントオフセット情報、生存時間（ＴＴＬ）、プロトコル大部、ソースＩＰアドレス、ディストネーションＩＰアドレス情報の一部またはすべてを含むＩＰヘッダと、
ソース・ポート、ディストネーション・ポート、アクノーリッジ番号、ＴＣＰ制御フラグ、データ・オフセット、シーケンス番号の一部またはすべて含むＴＣＰヘッダとを所定のフォーマットでハード的に生成する、第２０の本発明の送受信装置である。

第２２の本発明は、
前記ローカルＣＰＵは、ＨＴＴＰヘッダを付加してデータを送信する場合には、前記送信ＩＰ・ＴＣＰ処理手段で生成された前記ヘッダ情報を前記第１の送信バッファに書き込ませた後、ＨＴＴＰヘッダ長だけオフセットを設けて、前記ストリーム処理手段から転送されてくるＡＶデータを、そのオフセットの位置から前記第１の送信バッファに格納させる、第２０の本発明の送受信装置である。

第２３の本発明は、
前記第１の受信バッファは前記第１の送信バッファを兼ねており、データを送信する際には送信用のバッファとして使用し、データを受信する際には受信用のバッファとして使用する、第１の本発明の送受信装置である。

第２４の本発明は、
ネットワーク回線からＡＶデータを受信する際には、
前記ネットワーク回線から受信したデータのうち、予め設定された所定の条件により、第１の受信バッファまたは第２の受信バッファのいずれに格納させるかを判定し、ＡＶデータおよび前記ＡＶデータに関連する受信制御データの一部を前記第１の受信バッファに格納し、それ以外の受信データを前記第２の受信バッファに格納する受信データ判別格納ステップと、
前記第１の受信バッファに格納された受信制御データの前記一部を読み込んで、そのデータに対して所定のハード的な処理を行うＩＰ処理ステップと、
前記ＩＰ処理ステップで処理された結果および前記第１の受信バッファに格納されたデータに基づいて、前記第１の受信バッファからＡＶデータを抽出して出力させるＡＶ受信データ転送ステップと、
前記ＩＰ処理ステップで処理された結果および前記第１の受信バッファに格納されたデータに基づいて、所定のプロトコルで送信データを生成して前記ネットワーク回線に出力する応答送信ステップとを備え、
前記ネットワーク回線にＡＶデータを送信する際には、
前記受信データ判別格納ステップと、
前記ＩＰ処理ステップと、
前記ＩＰ処理ステップで処理された結果および前記第１の受信バッファに格納されたデータに基づいて、送信するＡＶデータを第１の送信バッファに転送するＡＶ送信データ転送ステップと、
前記応答送信ステップとを備えた、送受信制御方法である。

第２５の本発明は、
第１の本発明の送受信装置の、ローカルＣＰＵを動作させるためのプログラムである。

第２６の本発明は、
第１の本発明の送受信装置の、ローカルＣＰＵを動作させるためのプログラムが格納されたメモリである。

第２７の本発明は、
前記第１の送信バッファに格納される送信データに含まれるＩＰヘッダのＩＤ情報には、前記第２の送信バッファに格納される送信データに含まれるＩＰヘッダのＩＤ情報とは常に異なるＩＤ情報を使用する、第１の本発明の送受信装置である。

本発明により、ＡＶコンテンツ等の高速な伝送を安価に実現する、送受信装置、および送受信制御方法を提供することができる。

以下に、本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
図１は、本発明の実施の形態１の送受信装置の構成図である。

以下、図１を使用して、本実施の形態１の送受信装置の構成とともに、ＡＶデータ受信時の動作について説明する。なお、図９、図１０と同じ機能を有する構成部分については、同じ符号を用いている。

図１において、ネットワーク回線３に送受信手段２４が接続されており、データの送信及び受信ができる構成となっている。

送受信手段２４にデータが受信されると、判別処理手段３２に受信データが転送される。判別処理手段３２では、受信データに含まれる送信先ＩＰアドレス、送信元ＩＰアドレス、ＴＣＰ送信ポート番号、ＴＣＰ受信ポート、ＴＣＰ制御フラグ等の走査を行い、所定の条件に基づいて、高速処理が必要なＡＶデータおよびＡＶデータに関わる制御データであると識別した場合には、セレクタ３３に、高速処理用受信バッファ３１へ受信データを転送する指示を与える。またセレクタ３３は、受信データが高速処理が必要なＡＶデータおよびＡＶデータに関わる制御データでない場合には、受信データをソフトウェア用受信バッファ３５へ転送する。

ソフトウェア用受信バッファ３５に受信データが格納されると、制御部２５は、その受信データに対して必要な処理をソフトウェアにより実施する。そして、受信応答や、ネットワーク回線３に接続された別の機器に対してデータを送信する場合には、制御部２５が、ソフトウェア用送信バッファ３９にデータを送信し、送信制御部３７および送受信手段２４を介してネットワーク回線３にデータを出力できる構成となっている。

なお、判別処理手段３２が、本発明の判別手段の一例であり、セレクタ３３が、本発明のセレクタ手段の一例である。また、高速処理用受信バッファ３１、ソフトウェア用受信バッファ３５、ソフトウェア用送信バッファ３９が、それぞれ、本発明の、第１の受信バッファ、第２の受信バッファ、第２の送信バッファの一例である。

１２は、ＩＰ処理回路でありハードウェアで構成されている。ＩＰ処理回路１２は、インターネットプロトコルの規格が既に確定されている処理を行い、ローカルＣＰＵ１４にその処理結果を伝達する事により、ローカルＣＰＵ１４の処理負荷の低減を行う。具体的には、ＩＰレイヤのチェックサムやＴＣＰ／ＵＤＰレイヤのチェックサムの演算結果や、受信されたパケット長の抽出、受信データが正しい順番で受信されているかを確認するためにシーケンス番号をチェックしたり、受信データの種別などの情報を抜き出しローカルＣＰＵ１４に伝達する処理などを行う。また、ＩＰ処理回路１２は、受信データの格納情報等を、図５に示される受信バッファ管理情報として、高速処理用受信バッファ３１に受信データとともに格納する。なお、ＩＰ処理回路１２が、本発明のＩＰ処理手段の一例である。

ローカルＣＰＵ１４は、受信データが高速処理用受信バッファ３１に格納されると、ＩＰ処理回路１２が取得した情報を基に、受信データがＴＣＰ伝送の場合には、ＩＰ処理回路１２で処理された結果より、正しく受信されているかを確認すると共に、高速処理用受信バッファ３１の空き容量を確認して、以後の受信可能なデータサイズを算定するなどして、応答データ（ＡＣＫパケット）を高速処理用送信バッファ３６を介してネットワーク回線３に出力する。なお、高速処理用送信バッファ３６が、本発明の第１の送信バッファの一例である。

また、ローカルＣＰＵ１４は、ＩＰ処理回路１２で検出された情報から、正しく受信されていないことが分かると、再送要求パケットを、高速処理用送信バッファ３６を介してネットワーク回線３に出力することにより送信側に送信し、間違ったパケットを破棄して正しいデータが来るのを待つ事によりデータの信頼性を向上させることができる。

さらにローカルＣＰＵ１４は、受信データが高速処理用受信バッファ３１に格納されると、ストリーム処理手段１３に指示を出し、高速処理用受信バッファ３１に格納されたＡＶデータの格納情報をストリーム処理手段１３に伝達する。ストリーム処理手段１３は、受け取ったＡＶデータの格納情報を基に、高速処理用受信バッファ３１に格納された受信データをリードし、ＡＶ処理手段１６に受信データを渡す。そして、ＡＶ処理手段１６は、受け取ったＡＶデータを外部に出力する。

ストリーム処理手段１３は、ローカルＣＰＵ１４から得られた受信データ内にあるＡＶデータの格納情報を基にＡＶ処理手段１６にＡＶデータの転送を行うと共に、ＡＶデータの転送完了情報をローカルＣＰＵ１４に伝達する。ローカルＣＰＵ１４は、ストリーム処理手段１３からＡＶデータの転送完了情報を取得すると、高速処理用受信バッファ３１の当該データのバッファ領域を開放して次の受信データが格納されるのを待つが、必要に応じてバッファが空いたことをサーバ機器に伝達するＡＣＫパケットを高速処理用送信バッファ３６を介してネットワーク回線３に出力する。

受信データがＨＴＴＰによるプロトコル処理であった場合には、ローカルＣＰＵ１４で処理することも可能である。また、ＨＴＴＰ処理が、制御部２５で処理されるアプリケーションと密接に関係がある場合には、ローカルＣＰＵ１４で高速処理用受信バッファ３１内に格納されているＨＴＴＰデータ（ＨＴＴＰヘッダ情報）を読み出して制御部２５に伝達し、制御部２５で処理し、ＨＴＴＰ情報の送信が必要な場合は、逆に制御部２５からローカルＣＰＵ１４にＨＴＴＰ情報を伝達してネットワーク回線３に出力させることも可能である。

以上のように構成された本実施の形態１の送受信装置のローカルＣＰＵ１４の処理は、以下の理由によりパフォーマンスの低い安価のものであっても高速かつ汎用性のある伝送処理が可能となる。

（１）判別処理手段３２により、処理すべき受信データがＡＶデータに限定される。

（２）受信データの受信状況に対する処理を、ＩＰ処理回路１２内でハードウェアにより高速処理する。

（３）受信状況に応じて、ローカルＣＰＵ１４が判断してＡＣＫパケットを送出する。

（４）高速処理用受信バッファ３１に格納されているＡＶデータの格納情報をストリーム処理手段１３に伝達して、ハード的にＡＶ処理手段１６にＡＶデータの転送が行われるため、ローカルＣＰＵ１４の処理負荷を低減できる。

（５）受信データの状況、バッファ状態、ストリーム処理手段１３の情報を基にソフトウェア制御により動作することが可能であるため、伝送方式が異なる場合でもソフトウェアの変更を行えば良いので汎用設計が可能となる。

次に、ＡＶデータ送信時の動作について説明する。

図１において、ＡＶ処理手段１６からストリーム処理手段１３へのＡＶデータの転送が開始すると、ローカルＣＰＵ１４は、ストリーム処理手段１３に対して、所定のフォーマットで高速処理用送信バッファ３６ヘデータを転送するように指示する。

送信するプロトコルがＴＣＰプロトコル場合には、送信先（クライアント機器）から送られてくる受信データが高速処理用受信バッファ３１へ転送されるように、ローカルＣＰＵ１４が判別処理手段３２を設定することにより、クライアント機器が受信可能なバッファサイズ（ｗｉｎｄｏｗサイズ）をローカルＣＰＵ１４で知ることが可能となる。

そして、ローカルＣＰＵ１４は、高速処理用送信バッファ３６に格納された送信データの状況と、高速処理用受信バッファ３１に格納された受信データから分かるクライアント機器の受信可能なバッファサイズ（ｗｉｎｄｏｗサイズ）に基づいて、送信制御部３７に対して送信指示を与えてネットワーク回線３にデータを出力させる。

また、クライアント機器がデータを受信できた場合には、応答パケット（ＡＣＫ）が高速処理用受信バッファ３１に格納されることになるので、ローカルＣＰＵ１４は、その応答パケットを確認して高速処理用送信バッファ３６に格納されているデータを開放する。もし、仮にクライアント機器が受信できていない場合は、ローカルＣＰＵ１４は高速処理用送信バッファ３６に格納されているデータを再送する。

この様に、本実施の形態１の送受信装置では、ＴＣＰによるフロー制御が簡単に実施可能であるため、データ信頼性の高い高速通信が可能となる。

また、ローカルＣＰＵ１４が、高速処理用送信バッファ３６の空き状況を確認してストリーム処理手段１３の停止、再開の指示を与えることにより、確実にＡＶデータの伝送が可能となる。

この様に、ＡＶデータの送信であっても受信機と同じ構成の回路で実現できるため、送信回路と受信回路を共通設計とすることができる。

また、ローカルＣＰＵ１４を動作させるためのプログラムを格納するメモリ１５を、ＲＡＭまたは書き換え可能なＲＯＭで実現すれば、製品の仕様追加や規格の変更があった場合にもソフトウェアの変更をすればよくハードウェアの修正を行う必要がない。

なお、本実施の形態１の送受信装置は、図１に示すようにＡＶ処理手段１６を含む構成としたが、ＡＶ処理手段１６を含まない構成とし、その代わりに外部のＡＶ処理手段と入出力を行う手段を設ける構成としてもよい。

図９に示す従来の送受信装置において、例えばサーバ装置１については、ハード処理を行なう第１プロトコル処理部１２２において、送信処理と受信処理とでの連携処理、例えば、第１プロトコル処理部１２２内部で受信処理したデータに対する送達確認、フロー制御用ＡＣＫ送信処理等は、個別の処理として動作していた。また、ソフトで処理を行なう第１制御部１２５においても同様であり、送信処理と受信処理との連携した処理を行なうには、図９には示されない、さらに上流の制御装置等で行う必要があった。

これに対して、本実施の形態１の送受信装置では、送信処理と受信処理との連携した処理を、ローカルＣＰＵ１４と一部ハードウェアで専用処理するプロトコル手段内で行なうようにしている。

（実施の形態２）
図６は、本発明の実施の形態２のＡＶデータ送受信システムの構成を示した図であり、図７は、本発明の実施の形態２におけるネットワーク送受信装置の構成図である。

実施の形態１では、図１０に示す従来例と比較する形で説明を行ってきたが、以下に、具体的な実施形態を用いて説明する。

なお、図７において、ソフトウェア用送受信バッファ４００は、図１の、ソフトウェア用送信バッファ３９とソフトウェア用受信バッファ３５の部分を合せた機能を有する部分である。また、送受信データ選択処理手段４０１は、図１の、判別処理手段３２、セレクタ３３、送信制御部３７の部分を合せた機能を有する部分である。また、プロトコル処理手段４１は、図１のＩＰ処理回路１２と高速処理用受信バッファ３１と高速処理用送信バッファ３６の部分を合せた機能を有する部分である。

図７において、ＡＶストリームデータ処理手段３０は、ネットワーク送受信装置が図６で示されるファイル・サーバ１０１として動作する場合は、ＨＤＤ等の記録媒体よりストリーム・データ・ファイルを読み出す制御デバイス、あるいは、制御装置（以下、ファイル読み出し処理部）となる。

また、ネットワーク送受信装置が図６で示されるクライアント１（１０２）あるいは、クライアントｎ（１０３）として動作する場合は、ＡＶストリームデータ処理手段３０は、ストリームデータの再生処理デバイス、あるいは、処理装置（以下、データ再生処理部）となる。

図６に示すネットワーク環境を例にとり、図６〜図８を用いてＨＴＴＰプロトコルの動作を以下に説明する。

図８にＨＴＴＰプロトコルの動作シーケンスの一例を示す。なお、図８におけるサーバ１０４とは、図６のファイル・サーバ１０１のことであり、図８におけるクライアント１０５とは、図６のクライアント１（１０２）あるいは、クライアントｎ（１０３）のことである。

図８において、ストリームデータをプロトコル処理手段４１、ストリーム処理手段１３、ＡＶ処理手段１６を通して取得するクライアント１０５は、サーバ１０４にＴＣＰコネクション確立を要求するため、ＳＹＮ１９０を送信する。

この動作を図７を用いて説明すると、クライアント１０５の制御部（ホストＣＰＵ）２５が経路９１を通じてローカルＣＰＵ１４に対して、クライアント１０５が保持しているサーバ１０４のコネクション管理情報とサーバ１０４とのコネクション確立を指示する。ローカルＣＰＵ１４は、コネクション確立のため、予め設定されたサーバ１０４の受信ＴＣＰポートを指示した送信ＳＹＮパケット１９０を生成し、経路９３を通して、プロトコル処理手段４１に書き込む。さらに、ローカルＣＰＵ１４がプロトコル処理手段４１に送信を指示することにより、前記送信ＳＹＮパケット１９０は、経路６１、送受信データ選択処理手段４０１を通してＩＥＥＥ８０２．３規定のＭＡＣ処理装置およびＩＥＥＥ８０２．３規定のＰＨＹ処理装置である送受信手段２４に伝達され、ケーブル等伝送媒体７０により接続されているネットワーク回線３に送信する。

次に、図８において、ストリームデータをプロトコル処理手段４１を通してクライアント１０５に送信するサーバ１０４は、クライアント１０５からのコネクション要求ＳＹＮ１９０を受信した場合、もし、サーバ１０４がコネクション確立が不可であると判断した場合には、ＲＳＴパケットをクライアント１０５に返信し、コネクション確立に失敗したことを通知する。もし、サーバ１０４がコネクション確立可能と判断した場合には、ＳＹＮ、ＡＣＫ１９１をクライアント１０５に返信し、コネクション確立に成功したことを通知する。

この動作を図７を用いて説明すると、サーバ１０４では、制御部（ホストＣＰＵ）２５は、予めの設定により経路９１を通してローカルＣＰＵ１４に、ＴＣＰコネクション確立要求の受付を指示する。ローカルＣＰＵ１４は、コネクション確立要求のＳＹＮパケットをクライアント１０５の受信ＴＣＰポートで待受け、ネットワーク回線３よりＳＹＮパケットを送受信手段２４、送受信データ選択処理手段４０１、プロトコル処理手段４１、経路９３を通して受信し、コネクションを確立するか拒否するかの判定を行い、コネクション確立と判定した場合は、ＳＹＮ、ＡＣＫパケット１０１を生成し、経路９３、プロトコル処理手段４１、経路６１、送受信データ選択処理手段４０１を通して送受信手段２４に伝達し、ケーブル等伝送媒体７０により接続されているネットワーク回線３に送信する。

次に、図８において、クライアント１０５は、ＳＹＮ、ＡＣＫパケット１９１を受信し、その応答としてＡＣＫ１９２をサーバ１０４に送信する。

この動作を図７を用いて説明すると、クライアント１０５のローカルＣＰＵ１４は、ネットワーク回線３より、送受信手段２４、送受信データ選択処理手段４０１、プロトコル処理手段４１、経路９３を通してＳＹＮ、ＡＣＫ１９１を受信することにより、コネクションが確立したことを認識し、経路９１を通して、サーバ１０４とコネクションが確立したことを制御部（ホストＣＰＵ）２５に通知するとともに、ＡＣＫパケット１９２を生成し、経路９３、プロトコル処理手段４１、経路６１、送受信データ選択処理手段４０１を通して送受信手段２４に伝達し、ケーブル等伝送媒体７０により接続されているネットワーク回線３に送信する。

次に、サーバ１０４では、図７においてネットワーク回線３より、送受信手段２４、送受信データ選択処理手段４０１、プロトコル処理手段４１、経路９３を通してＡＣＫ１９２を受けとることにより、ローカルＣＰＵ１４は、経路９１を通してコネクションが確立したことを制御部（ホストＣＰＵ）２５に、コネクション確立したクライアント１０５のコネクション管理情報とともに通知する。

このように、コネクションの確立は、ＴＣＰ通信プロトコルで規定されたコネクション確立シーケンスの仕様、手順に沿って行なわれる。この一連のシーケンス動作を制御部（ホストＣＰＵ）２５が管理、制御する手法、処理手段もあるが、その場合、制御部（ホストＣＰＵ）２５に負荷がかかる。またこの場合、ローカルＣＰＵ１４とプロトコル処理手段４１でコネクション管理情報を共有しなければならないが、管理元が制御部（ホストＣＰＵ）２５となるため、情報更新での応答性が悪く、また、常に共有する情報の同期をとる必要があることから、制御部（ホストＣＰＵ）２５、ローカルＣＰＵ１４での管理更新処理が複雑になる。

したがって、上記したように、プロトコル処理手段４１で送受信するためのＴＣＰコネクションの確立、維持、管理をローカルＣＰＵ１４で行なうと、制御部（ホストＣＰＵ）２５の負荷を抑えると共に、ローカルＣＰＵ１４で一元管理できることから、応答性の向上、管理の容易化ができる。

次に、ＴＣＰコネクションを確立した後のストリームデータ伝送におけるデータ取得要求処理について、以下説明する。

図８おけるＨＴＴＰ＿ＧＥＴ２００は、図７を用いて説明すると、クライアント１０５の制御部（ホストＣＰＵ）２５は、ローカルＣＰＵ１４に対して経路９１を通して、サーバ１０４に対する読み出すファイル名等の指定情報、データサイズ、範囲情報と、サーバ１０４からのストリームデータの取得（Ｇｅｔ）を指示する。

ローカルＣＰＵ１４は、制御部（ホストＣＰＵ）２５から与えられた情報をＨＴＴＰ＿ＧＥＴ２００に加工するため、プロトコル処理手段４１に送信ＴＣＰパケット生成を指示し、経路９３を通してＨＴＴＰ＿ＧＥＴデータを書き込む。その後に、ローカルＣＰＵ１４がプロトコル処理手段４１に送信指示することにより、生成されたＨＴＴＰ＿ＧＥＴ２００は、経路６１を通して送受信手段２４に伝達され、ケーブル等伝送媒体７０により接続されているネットワーク回線３に送信される。

次に、サーバ１０４での動作を説明する。図７において、経路６１を通りプロトコル処理手段４１で受信処理された後、経路９３を通り受信したＨＴＴＰ＿ＧＥＴ２００から、ローカルＣＰＵ１４は、ＨＴＴＰヘッダデータ（サーバ１０４に対する読み出すファイル名等の指定情報、データサイズ、範囲情報の部分）を抽出する。そして、ローカルＣＰＵ１４は、抽出したデータを経路９１を通して、制御部（ホストＣＰＵ）２５に通知する。

制御部（ホストＣＰＵ）２５は、通知された情報を元に、クライアント１０５からのデータ取得に対する応答を判定するとともに、判定結果を経路９１を通してローカルＣＰＵ１４に通知する。ローカルＣＰＵ１４は、通知された判定結果をＨＴＴＰ＿ＯＫ２０１等の応答フレームに加工するため、プロトコル処理手段４１に送信ＴＣＰパケット生成を指示し、経路９３を通して判定結果をプロトコル処理手段４１に書き込む。その後に、ローカルＣＰＵ１４がプロトコル処理手段４１に送信を指示することにより、ＨＴＴＰ＿ＯＫ２０１等の応答フレームがネットワーク回線３に送信される。

次に、クライアント１０５でのＨＴＴＰ＿ＯＫ２０１等の応答フレーム受信処理について説明する。図７において、経路６１を通りプロトコル処理手段４１で受信処理された後、経路９３を通り受信したＨＴＴＰ＿ＯＫ２０１から、ローカルＣＰＵ１４は、ＨＴＴＰヘッダデータ（送信したＨＴＴＰ＿ＧＥＴの応答）を抽出する。ローカルＣＰＵ１４は、抽出したＨＴＴＰ＿ＧＥＴの応答を経路９１を通して制御部（ホストＣＰＵ）２５に通知する。

このように処理されることにより、制御部（ホストＣＰＵ）２５に負荷をかけず、かつ、高速な処理を行なうことができるので、図８でのＨＴＴＰ＿ＧＥＴ２００からＨＴＴＰヘッダ＋最初のストリームデータ２０２までの時間を、制御部（ホストＣＰＵ）２５等でソフトで処理する場合より大幅に短縮できる。

次に、ＴＣＰコネクションを確立した後のストリームデータの伝送処理、特に送信処理について、以下に説明する。

図８において、サーバ１０４は、ＨＴＴＰ＿ＧＥＴ２００より得た情報により、クライアント１０５に送信するストリームデータを準備し、ＨＴＴＰフレームにカプセル化し、ＨＴＴＰ＿ｈｅａｄｅｒ＋ストリームデータ２０２や、ストリームデータ２０３や、ストリームデータ２０４や、ストリームデータ２０５のように、ＴＣＰセグメントに分割して送信を行なう。

図７を用いて説明すると、制御部（ホストＣＰＵ）２５の制御下にあるＡＶストリームデータ処理手段３０から、送信ストリームデータは、経路６０を通してＡＶ処理手段１６に入力され、ストリーム処理手段１３、プロトコル処理手段４１を通して送信される。

図２は、図７に示すＬＡＮコントローラ４０の内部構成を示した図である。

なお、図２において、受信データ選択処理手段３０７が、図１の、判別処理手段３２とセレクタ３３の部分を合わせた機能を有する部分である。また、ストリームデータ入出力処理手段３１６とバンク・メモリ３１８と暗号演算処理手段３２０と経路３２１を合わせたものが、図１のＡＶ処理手段１６の機能を有する部分である。また、送信ＩＰ・ＴＣＰ処理手段３２２と経路３２３と送信データライト処理手段３２４と経路３３９と受信データリード処理手段３３８を合せたものが、図１のストリーム処理手段１３の機能を有する部分である。また、ローカルバッファ３２５と送信制御処理手段３２６と受信制御処理手段３３６を合せたものが、図１の、高速処理用受信バッファ３１と高速処理用送信バッファ３６を合わせた機能を有する部分である。

このように、本実施の形態２の構成では、本発明の第１の受信バッファおよび第２の受信バッファの２つのバッファを、１つのローカルバッファ３２５で共用させて用いている。

図２を用いて、ＡＶ処理手段１６、ストリーム処理手段１３、プロトコル処理手段４１を通しての送信処理を説明する。ＡＶストリームデータ処理手段３０から経路６０を通して入力されたストリームデータは、ストリームデータ入出力処理手段３１６に入力され、経路３１７を通って、ストリームデータの入力単位でバンク・メモリ３１８に一時的に蓄積される。バンク・メモリ３１８に蓄積されたストリームデータは、ローカルＣＰＵ１４が送信データライト処理手段３２４に指示することにより、経路３１９を通して暗号演算処理手段３２０に入力される。暗号演算処理手段３２０において、入力されるストリームデータを暗号化あるいは復号化するか、そのまま処理しないかは、制御部（ホストＣＰＵ）２５、あるいは、ローカルＣＰＵ１４からの予めの設定により決められている。

暗号演算処理手段３２０を通過したストリームデータは、経路３２１を通して送信ＩＰ・ＴＣＰ処理手段３２２に入力される。送信ＩＰ・ＴＣＰ処理手段３２２は、ローカルＣＰＵ１４からの予めの設定に従い、先頭に２バイトのオフセットとＩＥＥＥ８０２．３で規定されたＭＡＣヘッダとＩＰヘッダとＴＣＰヘッダを付加し、ローカルＣＰＵ１４からの指示により、ＨＴＴＰフレームの先頭であれば、ＨＴＴＰヘッダ分のデータオフセット長を勘案し、入力されたストリームデータを指定されたＴＣＰセグメント長で分割して、送信ＴＣＰセグメントを生成し、経路３２３を通して、送信データライト処理手段３２４に入力する。

図４に、送信ＩＰ・ＴＣＰ処理手段３２２において付加されるＩＰヘッダおよびＴＣＰヘッダのフォーマット例を示す。

ＩＰヘッダ内のＩＤに関して、ＩＰプロトコルの規定でＩＰプロトコル層においてフラグメント（分割）されないＩＰパケットは、各々ユニークＩＤを持つ必要がある。本実施の形態２のＬＡＮコントローラ４０では、制御部（ホストＣＰＵ）２５がソフト処理するＴＣＰ／ＩＰプロトコル処理の送信データとＡＶ処理手段１６、ストリーム処理手段１３を通してプロトコル処理手段４１が処理する送信データは、それぞれ独立して処理されるため、ＩＰヘッダのＩＤが同時期に重複する場合が想定される。

このことを回避するため、制御部（ホストＣＰＵ）２５から、使用しているＩＰヘッダのＩＤがメッセージバッファ３０９を経由してローカルＣＰＵ１４に通知され、ローカルＣＰＵ１４は、このＩＤをもとに、異なるＩＤ情報を生成し、送信ＩＰ・ＴＣＰ処理手段３２２に指示することにより、ＩＤの重複が回避可能となる。ただし、これは一例であり、他に、ＬＡＮコントローラ４０内において、制御部（ホストＣＰＵ）２５が送信処理する送信データに対して、ハードウェアが、その送信データのＩＰヘッダのＩＤを監視し、そのＩＤをローカルＣＰＵ１４に通知し、ローカルＣＰＵ１４が、その情報をもとに異なるＩＤ情報を生成し、送信ＩＰ・ＴＣＰ処理手段３２２に指示するという手段もある。

次に、送信データライト処理手段３２４が、送信ＴＣＰセグメントをローカルバッファ３２５に格納する。送信ＴＣＰセグメントを送信のため保持するローカルバッファ３２５は、最大送信ＴＣＰセグメント長を格納できる領域１５３６バイト単位にセグメントされ、その１５３６バイト単位の領域を８面有している。

送信データライト処理手段３２４は、８面あるローカルバッファ３２５の内、ローカルＣＰＵ１４により指示されているローカルバッファ３２５に、ＴＣＰセグメントデータを、図３に示すフォーマット形式のように、２バイトの送信バッファ管理情報と送信データの形で格納する。

ここで、ＴＣＰ／ＩＰプロトコルを使用したデータ伝送では、一般的に、２つあるいは３つの送信ＴＣＰセグメントに対して、１つの送達確認用の応答制御データであるＡＣＫセグメントが受信先より返信される。このＴＣＰセグメントを送信し、返信されたＡＣＫセグメントを受信し、送信したＴＣＰセグメントが送信先に正しく届いたことを確認できるまでの間、送信バッファとなるローカルバッファ３２５を開放できない。また、ＴＣＰセグメントを送信し、返信のＡＣＫセグメントが返るまでは、ネットワーク上での往復時間となること、さらに、ネットワークの混み具合等により変動するため、それなりの待ち時間を必要とする。

このため、ローカルバッファ３２５のバッファ数が、例えば、２面というように少なく、かつ、ＡＣＫセグメント確認までの待ち時間が、送信伝達時間の２倍程度と見た場合、伝送の性能は１／２に低下してしまう。このため、伝送の性能を低下させないためには、バッファ数を２倍にする必要がある。さらに、ネットワークの混み具合等による変動でさらに待ち時間が大きくなることを考慮すると、２倍以上のバッファ数が必要となる。ここで、ハードウェアが複数バッファを管理制御する場合、２のｎ乗の数が扱い易いため、これらの条件を基に最少のバッファ数を算出すると、２面×２^２＝８面のバッファ数があれば、ネットワークによる伝送の性能の低下を抑えることが出来る。

図３は、本実施の形態２で、ローカルバッファ３２５に格納されるＴＣＰセグメントデータのフォーマット形式を示している。図３において、送信バッファ管理情報である先頭２バイトは、ＴＣＰセグメントデータの最終データのアドレスを示している。

本実施の形態２では、送信バッファ管理情報を、ＴＣＰセグメントデータの最終データのアドレスとしているが、他の例として、送信データ長でもかまわない。送信バッファ管理情報の要件は、ローカルバッファ３２５に格納された送信データの終端を検出できる２バイトの情報であることが重要である。

以降、送信データであるＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ＨＴＴＰフレームにカプセル化され、ＴＣＰセグメント化された送信ストリームデータ（以下、ＴＣＰペイロードデータという）の形式で格納され、データの書き込み順番に関しては、本実施の形態２では、ＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ＴＣＰペイロードデータ、ＴＣＰヘッダのチェックサム、ＴＣＰセグメントデータの最終データのアドレスの順に書き込まれるが、これは、ほんの一例であり、データの書き込み順番は問わない。

次に、ストリームデータのＨＴＴＰフレームカプセル化処理について、図２、図３、図７を用いて説明する。

本実施の形態２では、ＨＴＴＰフレームカプセル化処理は、ＨＴＴＰプロトコルに規定されるデータフォーマットに従い、送信ストリームデータの先頭にＨＴＴＰヘッダを付加することで実現する。

図７において、ＨＴＴＰヘッダの情報は、制御部（ホストＣＰＵ）２５から、経路９１を通してローカルＣＰＵ１４に通知され、ローカルＣＰＵ１４は、ＨＴＴＰヘッダの情報に基づいてＨＴＴＰヘッダデータを生成し、あるいは、ＨＴＴＰヘッダデータに加工して、経路９３を通してプロトコル処理手段４１に入力する。そして、プロトコル処理手段４１において、経路９３を通して入力されたＨＴＴＰヘッダを先頭の送信ストリームデータに付加することによりＨＴＴＰカプセル化処理は行なわれる。

図２において、ＨＴＴＰヘッダを付加する処理を説明すると、ローカルＣＰＵ１４は、ＨＴＴＰフレームの先頭データを格納するローカルバッファ３２５を選択し、選択したローカルバッファ３２５に対して、経路３２３を通して、ＨＴＴＰヘッダデータを書き込む。ＨＴＴＰヘッダを書き込むローカルバッファ３２５内の位置は、図３において、ペイロードデータ（Ｐａｙｌｏａｄ）の先頭領域に格納する。

次に、ローカルＣＰＵ１４は、送信ＩＰ・ＴＣＰ処理手段３２２に、ＨＴＴＰヘッダデータのチェックサム演算途中結果を付与し、送信データライト処理手段３２４に選択したローカルバッファ３２５およびＨＴＴＰヘッダ分のオフセットを指示するとともに、バンク・メモリ３１８からの送信ストリームデータの読み出しと、ローカルバッファ３２５への書込みを指示する。

送信ＩＰ・ＴＣＰ処理手段３２２、送信データライト処理手段３２４は、ローカルＣＰＵ１４からの設定、指示に従い、ＭＡＣヘッダの書込み、ＩＰヘッダの書込み、ＴＣＰヘッダの書込み、ＨＴＴＰヘッダのオフセット分書き込む領域を飛ばして送信ストリームデータの書き込み、ＴＣＰチェックサムの書込み、送信バッファ管理情報の書き込みを行なう。これにより、ＨＴＴＰヘッダと送信ストリームヘッダの結合処理は、完了する。

ここで、本実施の形態２では、先にローカルバッファにＨＴＴＰヘッダデータを書き込む処理を行なうこととしたが、先にバンク・メモリ３１８からローカルバッファ３２５にストリームデータをＴＣＰセグメント化して転送させた後に、ＨＴＴＰヘッダを書き込んでもかまわない。あとは、ＨＴＴＰフレーム長の送信ストリームデータをＴＣＰセグメントに分割しながらローカルバッファに格納していくことで、ＨＴＴＰフレーム化処理は行なわれていく。そして、ＨＴＴＰフレーム長の最後のＴＣＰセグメントを生成し、ローカルバッファに格納したところで、ＨＴＴＰフレーム化処理を終了し、ローカルＣＰＵ１４に、完了を通知する。

ローカルＣＰＵ１４は、送信制御のローカルバッファ３２５を管理するため、ローカルバッファ３２５に格納されたＴＣＰセグメントのＳＥＱ番号を算出し、あるいは、ＴＣＰセグメントより抽出し、ローカルＣＰＵ１４の管理する８面のローカルバッファ３２５に格納されたＴＣＰセグメントに対応したＳＥＱ番号情報テーブルに登録する。ここで、ＳＥＱ番号情報テーブルは、送信ＩＰ・ＴＣＰ処理手段３２２または送信データライト処理手段３２４に専用のハードウェアとして実装されても良いし、ローカルＣＰＵ１４が使用するメモリ１５またはローカルバッファ３２５にソフトウェアにて実装されても良い。

次に、送信ストリームデータがＨＴＴＰフレーム化され、ＴＣＰセグメントに分割されたローカルバッファ３２５に格納された送信データの送信制御について、図２、図３を用いて説明する。

図２において、ローカルＣＰＵ１４は、送信制御処理手段３２６に対して、送信ＴＣＰセグメント数と開始ローカルバッファと送信開始と送信要求優先度とを指示する。ローカルＣＰＵ１４からの指示を受けた送信制御処理手段３２６は、送信要求調停・選択処理手段（送信制御部）３７に送信要求優先度と送信要求を渡すとともに、指定されたローカルバッファ３２５から送信バッファ管理情報を読み出し、当該ローカルバッファ３２５の送信ＴＣＰセグメントの最終ポインタとして保持する。そして、送信制御処理手段３２６は、順次、当該ローカルバッファ３２５を読み出し、読み出したデータを、送信要求の応答として送信要求調停・選択処理手段３７より選択された許可通知を受けると、経路３２７を通して、送信要求調停・選択処理手段３７に出力し、さらに、送信要求調停・選択処理手段３７は経路３２９を通して送受信手段２４に伝達し、ネットワーク上に送信させる。

上記の当該ローカルバッファ３２５から読み出す処理において、読み出しアドレスが保持していた送信ＴＣＰセグメントの最終ポインタと一致した場合には、送信制御処理手段３２６は、送信ＴＣＰセグメントの終端と判定し、読み出し処理を終了するとともに送信要求調停・選択処理手段３７に通知する。送信要求調停・選択処理手段３７は、通知された送信ＴＣＰセグメントの終端を送受信手段２４に通知する。送受信手段２４は、その通知をうけて、送信ＴＣＰセグメントの送信終端処理を行なう。

その後、送受信手段２４は、正常にネットワークに送信ＴＣＰセグメントを送信し終わったことを確認し、送信完了を送信要求調停・選択処理手段３７を経由し、送信制御元である送信制御処理手段３２６に通知する。送信制御処理手段３２６は、送信完了を受け、指定された送信ＴＣＰセグメント数に達したかを判定し、送信ＴＣＰセグメント数に達していなければ、次のローカルバッファ３２５について上記の一連の送信制御処理を行う。そして、送信ＴＣＰセグメント数に達していたならば、送信制御処理を終了し、終了したことをローカルＣＰＵ１４に通知する。

このようにして、ストリームデータ伝送処理における送信処理は、送信ＩＰ・ＴＣＰ処理手段３２２、送信データライト処理手段３２４、ローカルバッファ３２５というハードウェア主体で処理されるため、高速な処理が可能となり高速伝送を行なうことができる。

次に、ＴＣＰコネクションを確立した後のストリームデータの伝送処理、特に受信処理について、以下に説明する。

図８において、クライアント１０５では、ストリームデータがＨＴＴＰフレームにカプセル化され、ＨＴＴＰ＿ｈｅａｄｅｒ＋ストリームデータ２０２やストリームデータ２０３やストリームデータ２０４やストリームデータ２０５のように分割されて、サーバ１０４から送信されてきたＴＣＰセグメントをＨＴＴＰフレームに組み立て直し、さらにＨＴＴＰフレームのデカプセル化処理を行い、ストリームデータに戻す。

図７を用いて説明すると、ネットワーク回線３よりケーブル等伝送媒体７０を通り、送受信手段２４で受信処理されたＴＣＰセグメントは、送受信データ選択処理手段４０１、経路６１を通りプロトコル処理手段４１に入力される。

図２を用いてプロトコル処理手段４１、ストリーム処理手段１３、ＡＶ処理手段１６を通しての受信処理を説明すると、プロトコル処理手段４１において、経路３３３を通してＩＰ処理回路１２に入力される。ＩＰ処理回路１２は、受信ＴＣＰセグメントについて、ＩＰヘッダのチェックサムを演算し、チェックサムが正しいかどうかを判定する。また、ＩＰヘッダから擬似ＴＣＰヘッダ情報を取得し、擬似ＴＣＰヘッダを生成し、擬似ＴＣＰヘッダを含めてＴＣＰデータのチェックサムを演算し、チェックサムが正しいかどうかを判定するとともに、ＩＰヘッダのＩＰヘッダ長（ＩＨＬ）およびＴＣＰヘッダのデータオフセットから、ＴＣＰペイロードデータの先頭を検出し、受信制御処理手段３３６に通知する。さらに、ＴＣＰヘッダのＳＥＱ番号を抽出して、そのＳＥＱ番号が期待するＳＥＱ番号であるかの合否を判定し、その合否判定結果をローカルＣＰＵ１４に通知するとともに、受信データをカウントし、次に期待するＳＥＱ番号を生成し、さらにＴＣＰヘッダのアクノーリッジ番号（以下、ＡＣＫ番号）を予め設定された期待するＡＣＫ番号と比較し、合否判定し、その合否判定結果をローカルＣＰＵ１４に通知する。さらに、ＴＣＰヘッダのウィンドウサイズがゼロ（０）かどうかを検出し、その検出結果をローカルＣＰＵ１４に通知する。また、ＴＣＰヘッダのウィンドウサイズと、予め設定された閾値を比較し、その閾値より小さいことを検出し、その検出結果をローカルＣＰＵ１４に通知することと、ＴＣＰヘッダＵＲＧ、ＳＹＮ、ＲＳＴ、ＦＩＮ等のＴＣＰ制御フラグを抽出する処理をおこなう。

次に、ＩＰ処理回路１２を通過したＴＣＰセグメントは、経路３３５を通して、受信制御処理手段３３６に渡され、受信制御処理手段３３６では、ローカルＣＰＵ１４より指示された８面あるローカルバッファ３２５のいずれかに格納される。

図５に、受信ＴＣＰセグメントの格納フォーマットを示す。図５において、ローカルバッファ３２５には、左端から右端方向で格納される。先頭から１０バイトは、受信バッファ管理情報であり、その受信バッファ管理情報のあとに受信ＴＣＰセグメントが格納される。さらに、受信バッファ管理情報は、受信処理における上記の諸処理のチェック結果等が格納される３バイトのＳｔａｔｕｓと、ＩＰ処理回路１２において抽出されたＴＣＰ制御フラグ情報を格納する１バイトのＴＣＰ Ｆｌａｇｓと、ＭＡＣヘッダ長、ＩＰヘッダ長、ＴＣＰヘッダ長の全ヘッダの総和情報を格納する２バイトのＨｅａｄｅｒ＿ｌｅｎｇｔｈと、受信したデータのデータ長情報を格納する２バイトのＴｏｔａｌ＿Ｌｅｎｇｔｈと、２バイトのオフセットとから構成される。

本実施の形態２では、受信バッファ管理情報におけるＨｅａｄｅｒ＿ｌｅｎｇｔｈは、ＭＡＣヘッダとＩＰヘッダとＴＣＰヘッダの総和としているが、他の例としては、受信データのＴＣＰペイロードデータの開始アドレス等でもかまわない。Ｈｅａｄｅｒ＿ｌｅｎｇｔｈ情報を設けている理由は、ＴＣＰペイロードデータの開始アドレス、および位置を検出するのに利用するためであるし、また、本実施の形態２では、受信バッファ管理情報におけるＴｏｔａｌ＿Ｌｅｎｇｔｈは、受信したデータのデータ長であるが、他の例として、受信したデータの最終端データのライト・アドレスでもかまわない。Ｔｏｔａｌ＿Ｌｅｎｇｔｈ情報を設けている理由は、受信データの終端アドレス、および位置を検出するのに利用するためである。

受信制御処理手段３３６において、受信ＴＣＰデータは、ＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ＴＣＰセグメント、受信バッファ管理情報の順に格納されるが、これは一例であり、格納の順番に関しては、順番は問わない。

受信制御処理手段３３６は、図５のフォーマットに従い、受信ＴＣＰセグメントをローカルバッファ３２５に格納すると、ローカルＣＰＵ１４に受信ＴＣＰペイロード開始アドレスと受信データ長と受信エラー情報等、ならびに、受信完了の通知を行なう。ローカルＣＰＵ１４は、この通知を受け、受信ＴＣＰセグメントにＨＴＴＰヘッダが含まれているかどうかを判定し、ＨＴＴＰヘッダが含まれると判断した場合には、ＨＴＴＰヘッダの終端を検出するために当該ローカルバッファ３２５が通知された受信ＴＣＰペイロード開始アドレスを参照し、ＨＴＴＰヘッダをリードし、解析を行なう。

また、ローカルＣＰＵ１４は、リードしたＨＴＴＰヘッダ情報を図７においては経路９１、図２においてはメッセージバッファ３０９経由で、制御部（ホストＣＰＵ）２５に通知するとともに、解析した結果より受信するＨＴＴＰフレームの総データ長を取得し、受信データリード処理手段３３８に指示する。さらに、ローカルＣＰＵ１４は、受信データリード処理手段３３８に対して、ローカルバッファ３２５内の受信ＴＣＰセグメントを読み切った時点でローカルＣＰＵ１４に報告するか、読み出しデータの転送先であるバンク・メモリ３１８をフルの状態にした時点でローカルＣＰＵ１４に報告するかのどちらか一方を選択指示し、受信データの読み出しを開始するローカルバッファ３２５と、読み出しの開始位置を指示し、さらにＨＴＴＰヘッダを含む場合はＨＴＴＰヘッダのデータ長も指示する。ここで、指示するＨＴＴＰヘッダのデータ長は、一例であって、ＨＴＴＰの終端の後に続くＨＴＴＰペイロードの開始位置を検出できる情報であればよく、ＨＴＴＰペイロード開始のローカルバッファの直接、間接アドレス等でもかまわない。

次に、受信データリード処理手段３３８は、指示されたローカルバッファ３２５から、受信バッファ管理情報の内、３バイトのＳｔａｔｕｓ情報と２バイトのＨｅａｄｅｒ＿ｌｅｎｇｔｈ情報と２バイトのＴｏｔａｌ＿Ｌｅｎｇｔｈを読み出し、Ｓｔａｔｕｓよりローカルバッファ３２５内の当該データが正規のデータであるかを判定する。この判定結果より、不正規なデータであると判定した場合は、読み出し制御をその時点で終了し、ローカルＣＰＵ１４に、読み出しをエラー検出により終了したことを通知する。正規なデータであると判定した場合で、さらにＨＴＴＰヘッダのデータ長の指示が有効である場合には、ＨＴＴＰヘッダのデータ長とＨｅａｄｅｒ＿ｌｅｎｇｔｈより読み出し開始バッファアドレスを算出し、データの読み出しを開始する。ここで、読み出し開始アドレスは、ＨＴＴＰペイロードの先頭を示しており、かつ、このアドレス位置は、組み立て直すストリームデータの先頭を示している。

このようにして、ＨＴＴＰフレームのデカプセル化処理が行なわれる。また、上記に続き、上記判定結果で正規なデータであると判定した場合で、かつＨＴＴＰヘッダのデータ長が指示が無効である場合は、Ｈｅａｄｅｒ＿ｌｅｎｇｔｈより読み出し開始バッファアドレスを算出し、データの読み出しを開始する。次に、Ｔｏｔａｌ＿Ｌｅｎｇｔｈよりローカルバッファ３２５内の当該受信ＴＣＰセグメントの終端位置を算出し、読み出し制御は、終端になるまで読み出しを行い、この時点で、ＨＴＴＰフレームの総データ長に達していれば、ローカルＣＰＵ１４にＨＴＴＰフレーム読み出し完了を通知する。

さらに、「ローカルバッファ３２５内の受信ＴＣＰセグメントを読み切った時点で報告する」が指示されている場合は、ローカルＣＰＵ１４にＭＳＳ毎での読み出し完了を通知する。もし、「読み出しデータの転送先であるバンク・メモリ３１８をフルの状態にした時点で報告する」が指示されていた場合、ローカルバッファ３２５からの読み出しは、バンク・メモリ３１８分のデータを読み出したところで、ローカルＣＰＵ１４にバンクメモリ転送分読み出し完了を通知し、かつ、読み出し制御を終了する。

また、ローカルバッファ３２５からの読み出しで、終端データまで達したなら、受信データリード処理手段３３８は、次のローカルバッファ３２５に格納されたデータが有るかどうかを判定する。そして、格納されたデータが有ると判定した場合は、次のローカルバッファ３２５にチェインし、受信バッファ管理情報の読み出しから、一連の読み出し制御処理を行なう。また、格納データが無いと判断した場合は、有ると判定できるまで、一旦読み出し制御を停止する。そして、受信データリード処理手段３３８により読み出されたストリームデータは、経路３３９を通して暗号演算処理手段３２０に入力される。

暗号演算処理手段３２０において、入力されるストリームデータを暗号化あるいは復号化するか、そのまま処理しないかは、制御部（ホストＣＰＵ）２５、あるいはローカルＣＰＵ１４からの予めの設定による。暗号演算処理手段３２０を通過したストリームデータは、経路３４０を通してバンク・メモリ３１８に一旦保持され、バンク・メモリ３１８が満杯の状態になると、経路３４１を通して、ストリームデータ入出力処理手段３１６に渡される。さらに、図７で示す経路６０を通してＡＶストリームデータ処理手段３０に入力され、処理される。

これにより、プロトコル処理手段４１、ストリーム処理手段１３、ＡＶ処理手段１６を通してのストリームデータ伝送処理における受信処理は、ハードウェア主体で処理されるため、高速な処理が可能となり、ローカルバッファ３２５およびバンク・メモリ３１８に受信データが滞留してる時間を短縮できるので、メモリ容量を最小化できる。

次に、上記に説明したストリームデータ受信処理等におけるフロー制御、送達確認および再送制御処理であるＡＣＫセグメントの送信処理に関して説明する。

図８において、クライアント１０５は、サーバ１０４からの送信データに対して、ＡＣＫセグメント２１０、ＡＣＫセグメント２１１、ＡＣＫセグメント２１２、ＡＣＫセグメント２１３のように、ＴＣＰプロトコルに則ったＡＣＫセグメントをサーバ１０４に返す。但し、図８は一例に過ぎず、ＡＣＫセグメント２１０、ＡＣＫセグメント２１１、ＡＣＫセグメント２１２、ＡＣＫセグメント２１３が必ずクライアント１０５から返されるとは、限らない。

図２において、クライアント動作では、ＬＡＮコントローラのローカルＣＰＵ１４に対して、受信制御処理手段３３６からの受信エラー情報等、ならびに、受信完了の通知と受信データリード処理手段３３８からの読み出しをエラー検出したことにより終了したことの通知とＭＳＳ毎での読み出し完了の通知か、あるいはバンク・メモリ３１８転送分読み出し完了の通知とローカルバッファ３２５の空き領域情報とＡＣＫセグメントの送信間隔の監視タイマで、タイマが予めの設定された閾値以上達することを示す通知等が行なわれることより、ＴＣＰプロトコルに準拠したＡＣＫセグメントの送信処理を行なうため、ローカルＣＰＵ１４は、送信ＩＰ・ＴＣＰ処理手段３２２に対してＴＣＰヘッダのＳＥＱ番号、ＡＣＫ番号、ウィンドウサイズを指示するとともに、ＡＣＫセグメントの生成を指示する。

ここで、ＡＣＫセグメントにおいて、送信するＡＣＫセグメントに送信すべきペイロードデータが存在しない場合、ＳＥＱ番号は、固定値として扱え、ＡＣＫ番号は、初回の受信ＴＣＰセグメントのＳＥＱ番号と受信データリード処理手段３３８が読み出したデータ長の和（＋）より算出できるし、また、ウィンドウサイズの算出は、ローカルバッファ３２５に書き込んだデータ量と読み出したデータ量等のローカルバッファ３２５の空き領域情報から算出できる。

ＡＣＫ番号の算出は、ハードウェアで算出しても、ローカルＣＰＵ１４が算出しても、どちらでもかまわない。また、ウィンドウサイズの算出は、ローカルＣＰＵ１４が受信したデータ量と読み出したデータ量から算出する手段でも、ハードウェアでローカルバッファ３２５に書き込んだデータ量と読み出したデータ量から残格納データ量を監視して、自動的に算出する手段でも、ハードウェアでローカルバッファ３２５に書き込んだデータ量と読み出したデータ量等の情報をローカルＣＰＵ１４に通知あるいは表示し、その情報をもとにローカルＣＰＵ１４が算出する手段でも、いずれの手段でもかまわない。

また、ＡＣＫセグメントを生成指示するタイミングは、予め決められたローカルバッファ数分読み出したか、あるいは、ＡＣＫセグメントの送信間隔の監視タイマが予めの設定された閾値以上に達したことをローカルＣＰＵ１４が検知した時となる。

次に、送信ＩＰ・ＴＣＰ処理手段３２２は、指示されたＳＥＱ番号、ＡＣＫ番号、ウィンドウサイズと予めの設定に従い、上記のストリームデータの送信処理でのＴＣＰセグメント生成と同様の一連の処理で、ＭＡＣヘッダとＩＰヘッダとＴＣＰヘッダとからなるＡＣＫセグメントを生成し、ローカルバッファ３２５のＡＣＫセグメント格納領域に格納する。その後、送信制御処理手段３２６は、送信指示に従い、ローカルバッファ３２５のＡＣＫセグメントを読み出し、経路３２７、送信要求調停・選択処理手段３７、経路３２９、送受信手段２４を通して、ネットワークに送信される。

ここで、送信制御処理手段３２６に対する送信指示は、送信ＩＰ・ＴＣＰ処理手段３２２がローカルバッファ３２５にＡＣＫセグメントを格納した後に、直接指示する手段もあるだろうし、送信ＩＰ・ＴＣＰ処理手段３２２がローカルバッファ３２５にＡＣＫセグメントを格納した後にローカルＣＰＵ１４にＡＣＫセグメントの生成完了を通知し、ローカルＣＰＵ１４が指示する手段もあるであろうし、送信制御処理手段３２６がローカルバッファ３２５にＡＣＫセグメントを格納されたことを検出することで指示する手段もあるが、いずれの手段をとるかは、問わない。

上記に説明したように、ローカルＣＰＵ１４がローカルバッファ３２５の開放管理とＡＣＫセグメントの送信制御をおこなうことで、ローカルバッファ３２５をオーバーフローさせることなく、ＴＣＰセグメントのフロー制御を行なうことができる。また、ローカルＣＰＵ１４がＡＣＫ番号、ウィンドウサイズを自由に設定、制御することにより、柔軟にＡＣＫセグメントによりフロー制御と送達確認および再送制御を行なうことができる。

次に、上記で説明したストリームデータ送信処理等におけるフロー制御、送達確認および再送制御処理であるＡＣＫセグメント受信処理に関して説明する。

図８において、サーバ１０４は、自身が送信した送信データに対してクライアント１０５がＴＣＰプロトコルに則って送信制御した、ＡＣＫセグメント２１０、ＡＣＫセグメント２１１、ＡＣＫセグメント２１２、ＡＣＫセグメント２１３を受信する。但し、図８は一例に過ぎず、ＡＣＫセグメント２１０、ＡＣＫセグメント２１１、ＡＣＫセグメント２１２、ＡＣＫセグメント２１３が必ずクライアント１０５から送信されるとは、限らない。

図２において、ＡＣＫセグメントは、ネットワーク上より送受信手段２４、経路３３０、受信データ選択処理手段３０７、経路３３３を通って、ＩＰ処理回路１２に入力される。ＩＰ処理回路１２は、入力された受信ＡＣＫセグメントについて、ＩＰヘッダのチェックサムを演算し、チェックサムが正しいかどうかを判定する。また、ＩＰヘッダより擬似ＴＣＰヘッダ情報を取得し、擬似ＴＣＰヘッダを生成し、その擬似ＴＣＰヘッダのチェックサムを演算し、チェックサムが正しいかどうかを判定する。さらに、ＴＣＰヘッダのＳＥＱ番号を抽出して、そのＳＥＱ番号が期待するＳＥＱ番号か合否判定し、その合否判定結果をローカルＣＰＵ１４に通知するとともに受信データをカウントし、次に期待するＳＥＱ番号を生成する。さらに、ＴＣＰヘッダのＡＣＫ番号を予め設定された期待するＡＣＫ番号と比較し、合否判定し、その合否判定結果をローカルＣＰＵ１４に通知する。さらに、ＴＣＰヘッダのウィンドウサイズがゼロ（０）かどうかを検出し、その検出結果をローカルＣＰＵ１４に通知する。また、前記ウィンドウサイズと予め設定された閾値を比較し、その閾値より小さいことを検出し、その検出結果をローカルＣＰＵ１４に通知することと、ＴＣＰヘッダＵＲＧ、ＳＹＮ、ＲＳＴ、ＦＩＮ等のＴＣＰ制御フラグを抽出する処理をおこなう。

次に、ＩＰ処理回路１２通過したＴＣＰセグメントは、経路３３５を通して、受信制御処理手段３３６に渡される。受信制御処理手段３３６は、予めの設定に従い、ローカルバッファ３２５のローカルＣＰＵ１４用に設けられた受信バッファにそのＴＣＰセグメントを格納するとともに、ローカルＣＰＵ１４にＡＣＫセグメントの受信完了を通知する。ローカルＣＰＵ１４は、ＡＣＫセグメントの受信完了通知を受けると、ローカルバッファ３２５のＡＣＫセグメント格納領域より、ＡＣＫセグメントのＡＣＫ番号を抽出する。

次に、ローカルＣＰＵ１４は、抽出したＡＣＫ番号を、前述した８面のＳＥＱ番号情報テーブルに登録されたＳＥＱ番号と比較する。比較した結果、一致するＳＥＱ番号情報があったなら、送達確認の出来たローカルバッファを開放し、ローカルバッファ３２５に新たな送信ＴＣＰセグメントの格納を許可する。また、ローカルＣＰＵ１４は、ウィンドウサイズをチェックし、受信側の受信データの許容量から、送信可能なＴＣＰセグメントの数を算出し、新たに送信可能な個数分のＴＣＰセグメントを送信制御する。

本実施の形態２では、ローカルＣＰＵ１４が送信制御している、あるいは、送信制御していたＴＣＰセグメントのＳＥＱ番号を管理し、受信ＡＣＫセグメントのＡＣＫ番号と比較する処理手段をとっているが、これは一例であって、他の手段として、ハードウェアでＳＥＱ番号の管理、比較一致を行い、ローカルＣＰＵ１４に結果を通知する処理手段等もあるだろう。上記に説明したように、ローカルＣＰＵ１４がローカルバッファ３２５の開放管理とＡＣＫセグメントの受信制御をおこなうことで、受信ローカルバッファ３２５の状況に応じたＴＣＰセグメントのフロー制御行なうことができ、受信側のローカルバッファ３２５をオーバーフローさせることがない。

なお、本実施の形態２で説明したコネクション確立用のＳＹＮセグメント、ＳＹＮ・ＡＣＫセグメント、ＡＣＫセグメント、ＨＴＴＰ＿ＧＥＴ、ＨＴＴＰ＿ＯＫ、ＨＴＴＰ＿Ｈｅａｄｅｒ情報が、本発明の、ＡＶデータに関連する受信制御データおよび送信制御データの一例である。

以上に説明した各実施の形態は、例示であって本発明の範囲を限定するものでは無い。

なお、各実施の形態の送受信装置に接続されるネットワークは、ＩＥＥＥ８０２．３規格に準拠しているネットワークや、ＩＥＥＥ８０２．１１規格に準拠しているネットワークなど、ＨＴＴＰプロトコルを用いることができるネットワークであればよい。

以上に説明したように、本発明の送受信装置は、ホストＣＰＵには処理負荷の重く高速伝送を必要とするＨＴＴＰプロトコルに従った処理を、ホストＣＰＵとは別手段で、プロトコル処理に柔軟で複雑な対処が必要な送受信制御等を処理するローカルＣＰＵと、プロトコル処理で単純であるがソフト処理では負荷が重過ぎる処理を処理するハードウェアと、ストリームデータを専用に制御ならびに管理を可能とするローカルバッファとで処理するＨＴＴＰプロトコル処理手段と、ホストＣＰＵがソフトで伝送データのＴＣＰ／ＩＰ処理し直接制御可能な通信処理手段とを備えた。

本発明の送受信装置によれば、ネットワーク回線にインターネットプロトコルで伝送されたＡＶパケットだけが判別手段で第１の受信バッファへ転送されるので、ローカルＣＰＵはＡＶ伝送のための処理に最適化することができる。また、規格が既に確定して単純な処理をＩＰ処理手段で行えるので、性能の低い安価なＣＰＵで実現できる。また、処理が複雑なＴＣＰ・ＨＴＴＰ処理であっても、第１の受信バッファの情報とローカルＣＰＵによってネットワーク回線へ送信する手段を設ける事により、ソフトウェアで実現できることから汎用性を持った設計が可能である。複数の伝送方式に対応する場合には、ソフトウェアを追加すれば対応できるので、プログラムメモリサイズの増加程度のコストアップで済み、回路規模の増大を抑えることができる。また、伝送方式がすべて確定してない状況でもソフトウェアで対応可能であるため、早期に製品の市場投入が可能である。また、本発明によれば、受信装置、送信装置の共用設計が可能であり開発費用の削減が可能である。

本発明の送受信装置を用いることにより、ホストＣＰＵに超高速処理可能なＣＰＵと高速なメモリを必要とせず、難易度の高い実装技術も不要となる。

このため、本発明の送受信装置を利用したネットワーク送受信装置は、低コストで、消費電力が低く、ホストＣＰＵがソフト処理する通信プロトコル処理負荷を少なくでき、その上で、データ伝送を高速に行なうこととネットワークを効率良く使用することができる。

さらに、ローカルＣＰＵのプログラムの変更等により、新規機能の追加にも、柔軟に対応できる。

また、従来の高速伝送を必要としないホストＣＰＵがソフト処理するデータ伝送も、そのままか、一部の変更で使用でき、従来のソフトの移植が容易に行なえる。

なお、本発明のプログラムは、上述した本発明の送受信装置の、ローカルＣＰＵを動作させるためのプログラムであって、コンピュータと協働して動作するプログラムである。

また、本発明のメモリは、上述した本発明の送受信装置の、ローカルＣＰＵを動作させるためのプログラムを担持したメモリであり、コンピュータにより読み取り可能かつ、読み取られた前記プログラムが前記コンピュータと協働して利用されるメモリである。

また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であっても良い。

また、記録媒体としては、ＲＯＭ等が含まれる。

また、上述した本発明のコンピュータは、ＣＰＵ等の純然たるハードウェアに限らず、ファームウェアや、ＯＳ、更に周辺機器を含むものであっても良い。

なお、以上説明した様に、本発明の構成は、ソフトウェア的に実現しても良いし、ハードウェア的に実現しても良い。

本発明にかかる送受信装置は、ＡＶデータを複雑なＴＣＰやＨＴＴＰなどのインターネットプロトコルで伝送する機能を安価に提供できるばかりでなく、複数種のコンテンツ対応や規格の変更などに柔軟対応できる汎用性をもっている。そのため、ネットワークに接続される家電製品やモバイル端末等の用途に有用である。

本発明の実施の形態１の送受信装置の構成図 本発明の実施の形態２のＬＡＮコントローラ４０の内部構成図 本発明の実施の形態２のローカルバッファ３２５に格納される送信ＴＣＰセグメントデータのフォーマット形式を示した図 本発明の実施の形態２の送信データに付加されるＩＰヘッダおよびＴＣＰヘッダのフォーマットを示した図 本発明の実施の形態２のローカルバッファ３２５に格納される受信ＴＣＰセグメントデータのフォーマット形式を示した図 本発明の実施の形態２のＡＶデータ送受信システムの構成図 本発明の実施の形態２のネットワーク送受信装置の構成図 本発明の実施の形態２のＨＴＴＰプロトコルの動作シーケンスの一例を示す図 従来の送受信装置の構成図 従来の送受信装置に用いられる送受信装置の構成図

符号の説明

１ サーバ装置
２ クライアント装置
３ ネットワーク回線
１２ ＩＰ処理回路
１３ ストリーム処理手段
１４ ローカルＣＰＵ
１５ メモリ
１６ ＡＶ処理手段
１１９ 第２送受信部
２１ ＡＶエンコーダ
１２２ 第１プロトコル処理部
２３ 第１ルータ
１２４ 第１送受信部
２６ ＡＶデコーダ
１２７ 第２プロトコル処理部
２８ 第２ルータ
１２９ 第２制御部
３１ 高速処理用受信バッファ
３２ 判別処理手段
３３ セレクタ
３４ ハードウェア用受信バッファ
３５ ソフトウェア用受信バッファ
３６ 高速処理用送信バッファ
３７ 送信制御部
３８ ハードウェア用送信バッファ
３９ ソフトウェア用送信バッファ
１０１ ファイル・サーバ
１０２ クライアント１
１０３ クライアントｎ
０４ クライアントからファイル・サーバに対するファイル・データの読み出し要求
０５ ファイル・サーバからクライアントに対するファイル・データの伝送
１０ ネットワーク送受信装置
３０ ＡＶストリームデータ処理手段
４０ ＬＡＮコントローラ
４１ プロトコル処理手段
５０ ホストＣＰＵとソフトウェア用送受信バッファとのデータ経路
６０ ストリームデータ処理手段とプロトコル処理手段とのインタフェース
６１ プロトコル処理手段とＩＥＥＥ８０２．３ＭＡＣ＋ＰＨＹとのデータ経路
７０ ケーブル等伝送媒体
９１ ローカルＣＰＵ１４と制御部（ホストＣＰＵ）２５の双方向通知経路
９２ ローカルＣＰＵ１４とＩＥＥＥ８０２．３ＭＡＣ＋ＰＨＹとのデータ経路
９３ ローカルＣＰＵ１４とプロトコル処理手段４１とのデータ経路
１９０ コネクション確立要求用ＳＹＮセグメント
１９１ ＳＹＮセグメントに対する応答であるＳＹＮ、ＡＣＫセグメント
１９２ ＳＹＮ、ＡＣＫセグメントに対する応答であるＡＣＫセグメント
２００ ＨＴＴＰ＿ＧＥＴであるＴＣＰセグメント
２０１ ＨＴＴＰ＿ＧＥＴの応答の一例であるＨＴＴＰ＿ＯＫのＴＣＰセグメント
２０２ ＨＴＴＰフレームにカプセル化された先頭ストリームデータであるＴＣＰセグメント
２０３ ＨＴＴＰフレームにカプセル化されたストリームデータ２であるＴＣＰセグメント
２０４ ＨＴＴＰフレームにカプセル化されたストリームデータ３であるＴＣＰセグメント
２０５ ＨＴＴＰフレームにカプセル化された最終ストリームデータであるＴＣＰセグメント
２１０ ＨＴＴＰ＿ＯＫのＴＣＰセグメントに対する応答であるＡＣＫセグメント
２１１ ＴＣＰセグメントに対する応答であるＡＣＫセグメント
２１２ ＴＣＰセグメントに対する応答であるＡＣＫセグメント
２１３ ＴＣＰセグメントに対する応答であるＡＣＫセグメント
３００ ホストＣＰＵインタフェース
３０１ 受信バッファ３０４からホストＣＰＵインタフェース処理手段３００への経路
３０２ ホストＣＰＵインタフェースから送信バッファ３９への経路
３０５ 受信データ選択処理手段３０７から受信バッファ３０４への経路
３０６ 送信バッファ３９から送信要求調停・選択処理手段３７への経路
３０７ 受信データ選択処理手段
３０８ メッセージバッファ３０９とホストＣＰＵインターフェース処理手段３００の経路
３０９ メッセージバッファ
３１０ ローカルＣＰＵ１４から制御部（ホストＣＰＵ）２５に対する通知処理手段の経路
３１１ メッセージバッファ３０９とローカルＣＰＵ１４の経路
３１５ ローカルＣＰＵ１４とメモリ１５の経路
３１６ ストリームデータ入出力処理手段
３１７ ストリームデータ入出力処理手段３１６からバンク・メモリ３１８へのデータ経路
３１８ バンク・メモリ
３１９ バンク・メモリ３１８から暗号演算処理手段３２０へのデータ経路
３２０ 暗号演算処理手段
３２１ 暗号演算処理手段３２０から送信ＩＰ・ＴＣＰ処理手段３２２へのデータ経路
３２２ 送信ＩＰ・ＴＣＰ処理手段
３２３ 送信ＩＰ・ＴＣＰ処理手段３２２から送信データライト処理手段３２４へのデータ経路
３２４ 送信データライト処理手段
３２５ ローカルバッファ
３２６ 送信制御処理手段
３２７ 送信制御処理手段３２６から送信要求調停・選択処理手段３７へのデータ経路
３２９ 送信要求調停・選択処理手段３７からＩＥＥＥ８０２．３ＭＡＣ＋ＰＨＹ処理手段へのデータ経路
３３０ ＩＥＥＥ８０２．３ＭＡＣ＋ＰＨＹから受信データ選択処理手段３０７へのデータ経路
３３１ ローカルＣＰＵ１４の直接処理の送信データの送信要求調停・選択処理手段３７に対する経路
３３２ 受信データ選択処理手段３０７からのローカルＣＰＵ１４の直接処理の受信データ経路
３３３ 受信データ選択処理手段３０７からＩＰ処理回路１２へのデータ経路
３３５ ＩＰ処理回路１２から受信制御処理手段３３６への経路
３３６ 受信制御処理手段
３３８ 受信データリード処理手段
３３９ 受信データリード処理手段３３８から暗号演算処理手段３２０へのデータ経路
３４０ 暗号演算処理手段３２０からバンク・メモリ３１８へのデータ経路
３４１ バンク・メモリ３１８からストリームデータ入出力処理手段３１６へのデータ経路
４００ ソフトウェア用送受信バッファ
４０１ 送受信データ選択処理手段
１０４ サーバ
１０５ クライアント

Claims (27)

1. ネットワーク回線からのデータを受信し、また、前記ネットワークへデータを送信する送受信手段と、
   前記ネットワーク回線から受信したＡＶデータおよび前記ＡＶデータに関連する受信制御データの一部が格納される第１の受信バッファと、
   前記第１の受信バッファに格納された以外の受信データが格納される第２の受信バッファと、
   前記ネットワーク回線に送信するＡＶデータおよび前記ＡＶデータに関連する送信制御データの一部が格納される第１の送信バッファと、
   前記第１の送信バッファに格納された以外の送信データが格納される第２の送信バッファと、
   前記第２の受信バッファに格納された受信データをソフトウェア的に処理すると共に、所定のプロトコルで生成した送信データを前記第２の送信バッファに転送する制御部と、
   前記ネットワーク回線から受信したデータのうち、予め設定された所定の条件により、前記第１の受信バッファまたは前記第２の受信バッファのいずれに格納させるかを判定する判別手段と、
   前記判別手段の判定結果に基づいて、前記ＡＶデータおよび前記ＡＶデータに関連する受信制御データの前記一部を前記第１の受信バッファに格納し、それ以外の受信データを前記第２の受信バッファに格納するセレクタ手段と、
   前記第１の受信バッファに格納された受信制御データの前記一部を読み込んで、そのデータに対して所定のハード的な処理を行うＩＰ処理手段と、
   前記第１の受信バッファからＡＶデータを抽出して出力し、および／または、入力されてくるＡＶデータを前記第１の送信バッファへ転送する、ストリーム処理手段と、
   前記ＩＰ処理手段で処理された結果と前記第１の受信バッファに格納されたデータを読み込み、これらの情報に基づいて、ソフトウェアで前記ストリーム処理手段を制御し、また所定のプロトコルで生成した送信データを前記第１の送信バッファへ転送して前記ネットワーク回線に出力させるローカルＣＰＵと、
   前記ローカルＣＰＵを動作させるためのプログラムが格納されたメモリとを備えた、送受信装置。
2. 前記ストリーム処理手段から出力されたＡＶデータを受信して処理し、および／または、前記第１の送信バッファに格納するためのＡＶデータを前記ストリーム処理手段に送信するＡＶ処理手段をさらに備えた、請求項１に記載の送受信装置。
3. 前記ネットワーク回線は、ＩＥＥＥ８０２．３規格に準拠している、請求項１に記載の送受信装置。
4. 前記ネットワーク回線は、ＩＥＥＥ８０２．１１規格に準拠している、請求項１に記載の送受信装置。
5. 前記所定のプロトコルは、ＴＣＰ／ＩＰであり、
   前記判別手段は、ＴＣＰ／ＩＰ通信プロトコルに基づいたＴＣＰ制御フラグの一部またはすべてを走査する走査手段を有し、その走査した情報を前記所定の条件と比較することにより、前記ネットワーク回線から受信したデータを、前記第１の受信バッファへ格納させるか、前記第２の受信バッファへ格納させるかを判定する、請求項１に記載の送受信装置。
6. 前記ＩＰ処理手段は、（１）ＩＰヘッダのチェックサムの確認、（２）ＴＣＰヘッダのチェックサムの確認、（３）ＴＣＰヘッダのシーケンス番号の確認、（４）ＴＣＰヘッダのＡＣＫ番号の確認、（５）ＴＣＰヘッダのＷＩＮＤＯＷの検出および前記ローカルＣＰＵへの通知、（６）ＴＣＰの制御フラグ（ＦＩＮ、ＳＹＮ、ＲＳＴ、ＵＲＧ）の検出および前記ローカルＣＰＵへの通知、の各処理の一部またはすべてをハードで行う受信ＩＰ・ＴＣＰ処理手段を有している、請求項５に記載の送受信装置。
7. 前記第１の受信バッファは、前記受信データであるＴＣＰ／ＩＰセグメントを格納するために、それぞれが１５３６バイト以上の容量を持つ複数のセグメントバッファに分割されている、請求項５に記載の送受信装置。
8. 前記第１の受信バッファは、８つのセグメントバッファに分割されている、請求項７に記載の送受信装置。
9. 前記ローカルＣＰＵは、セグメント化された前記第１の受信バッファをリングバッファ方式で制御し、その起動開始バッファを設定する、請求項７に記載の送受信装置。
10. 前記第１の受信バッファには、前記ＩＰ処理手段で処理された結果も格納される、請求項７に記載の送受信装置。
11. 前記ＩＰ処理手段は、ＩＰヘッダおよびＴＣＰヘッダを解析し、ＴＣＰペイロードデータの開始位置および前記受信データの最後尾の位置をハード的に検出する、請求項７に記載の送受信装置。
12. 前記ＩＰ処理手段は、検出した前記ＴＣＰペイロードデータの開始位置および前記受信データの最後尾の位置情報を、受信管理データとして前記第１の受信バッファに格納する、請求項１１に記載の送受信装置。
13. 前記第１の受信バッファに格納された前記ＴＣＰペイロードデータの開始位置および前記受信データの最後尾位置情報に基づいて、前記受信データのＩＰヘッダおよびＴＣＰヘッダを削除して前記ストリーム処理手段にハード的に転送する手段を備えた、請求項１２に記載の送受信装置。
14. 前記所定のプロトコルは、ＨＴＴＰであり、
    前記ローカルＣＰＵは、前記第１の受信バッファに格納されている前記受信データを走査してＨＴＴＰヘッダの検出を行う、請求項１に記載の送受信装置。
15. 前記ローカルＣＰＵは、前記ＨＴＴＰヘッダを検出した場合には、ＨＴＴＰペイロードデータの開始位置を検出して、前記受信データを前記ＨＴＴＰペイロードデータの先頭から前記ストリーム処理手段にハード的に転送させる、請求項１４に記載の送受信装置。
16. 前記ＨＴＴＰペイロードデータは、動画像データを含んでいる、請求項１５に記載の送受信装置。
17. さらに、ＨＴＴＰヘッダ情報をソフトウェア的に処理するホストＣＰＵを備え、
    前記ローカルＣＰＵは、前記ＨＴＴＰヘッダを検出した場合には、前記ＨＴＴＰヘッダに含まれるＨＴＴＰ＿ＧＥＴコマンドを検出し、そのＨＴＴＰヘッダ情報を前記ホストＣＰＵに伝達する、請求項１４に記載の送受信装置。
18. 前記ホストＣＰＵは、ＨＴＴＰ＿ＧＥＴコマンドに対する応答情報を生成して前記ローカルＣＰＵに伝達し、
    前記ローカルＣＰＵは、前記応答情報を受け取ると、前記応答情報を含むＨＴＴＰヘッダを生成して前記第１の受信バッファに格納し、前記ネットワーク回線に送信させる、請求項１７に記載の送受信装置。
19. 前記ローカルＣＰＵは、前記ホストＣＰＵから受け取るＨＴＴＰヘッダ情報に基づいて、前記第１の送信バッファに所定のフォーマットでＨＴＴＰヘッダを書き込む、請求項１７に記載の送受信装置。
20. 前記第１の送信バッファは、セグメント分割されており、
    前記ストリーム処理手段は、入力されてくるＡＶデータを所定の長さに分割すると共に、少なくともＩＰヘッダを含むヘッダ情報を生成して前記第１の送信バッファに格納する送信ＩＰ・ＴＣＰ処理手段を有している、請求項１に記載の送受信装置。
21. 前記送信ＩＰ・ＴＣＰ処理手段は、
    ＭＡＣアドレスを含むＭＡＣヘッダと、
    ＩＰのバージョン情報、サービス型（ＴＯＳ）、ＩＰヘッダ長（ＩＨＬ）、ＩＰヘッダＩＤ情報，フラグメント制御情報、フラグメントオフセット情報、生存時間（ＴＴＬ）、プロトコル大部、ソースＩＰアドレス、ディストネーションＩＰアドレス情報の一部またはすべてを含むＩＰヘッダと、
    ソース・ポート、ディストネーション・ポート、アクノーリッジ番号、ＴＣＰ制御フラグ、データ・オフセット、シーケンス番号の一部またはすべて含むＴＣＰヘッダとを所定のフォーマットでハード的に生成する、請求項２０に記載の送受信装置。
22. 前記ローカルＣＰＵは、ＨＴＴＰヘッダを付加してデータを送信する場合には、前記送信ＩＰ・ＴＣＰ処理手段で生成された前記ヘッダ情報を前記第１の送信バッファに書き込ませた後、ＨＴＴＰヘッダ長だけオフセットを設けて、前記ストリーム処理手段から転送されてくるＡＶデータを、そのオフセットの位置から前記第１の送信バッファに格納させる、請求項２０に記載の送受信装置。
23. 前記第１の受信バッファは前記第１の送信バッファを兼ねており、データを送信する際には送信用のバッファとして使用し、データを受信する際には受信用のバッファとして使用する、請求項１に記載の送受信装置。
24. ネットワーク回線からＡＶデータを受信する際には、
    前記ネットワーク回線から受信したデータのうち、予め設定された所定の条件により、第１の受信バッファまたは第２の受信バッファのいずれに格納させるかを判定し、ＡＶデータおよび前記ＡＶデータに関連する受信制御データの一部を前記第１の受信バッファに格納し、それ以外の受信データを前記第２の受信バッファに格納する受信データ判別格納ステップと、
    前記第１の受信バッファに格納された受信制御データの前記一部を読み込んで、そのデータに対して所定のハード的な処理を行うＩＰ処理ステップと、
    前記ＩＰ処理ステップで処理された結果および前記第１の受信バッファに格納されたデータに基づいて、前記第１の受信バッファからＡＶデータを抽出して出力させるＡＶ受信データ転送ステップと、
    前記ＩＰ処理ステップで処理された結果および前記第１の受信バッファに格納されたデータに基づいて、所定のプロトコルで送信データを生成して前記ネットワーク回線に出力する応答送信ステップとを備え、
    前記ネットワーク回線にＡＶデータを送信する際には、
    前記受信データ判別格納ステップと、
    前記ＩＰ処理ステップと、
    前記ＩＰ処理ステップで処理された結果および前記第１の受信バッファに格納されたデータに基づいて、送信するＡＶデータを第１の送信バッファに転送するＡＶ送信データ転送ステップと、
    前記応答送信ステップとを備えた、送受信制御方法。
25. 請求項１に記載の送受信装置の、ローカルＣＰＵを動作させるためのプログラム。
26. 請求項１に記載の送受信装置の、ローカルＣＰＵを動作させるためのプログラムが格納されたメモリ。
27. 前記第１の送信バッファに格納される送信データに含まれるＩＰヘッダのＩＤ情報には、前記第２の送信バッファに格納される送信データに含まれるＩＰヘッダのＩＤ情報とは常に異なるＩＤ情報を使用する、請求項１に記載の送受信装置。
    

Images