JP4809679B2 - ストリームデータ通信方法及びストリームデータ通信装置 - Google Patents

Description

本発明は、ストリームデータの通信方法及びストリームデータの通信装置に関し、特に、チェックサム計算モジュール及びソケット類似のプロトコルスタックを用いたバス帯域の浪費防止及びプロセッサ処理負荷の浪費防止に適用して有効な技術に関するものである。

今般、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）だけでなく、ビデオレコーダ等のＡＶ（Ａｕｄｉｏ／Ｖｉｓｕａｌ）機器を含め様々な組込み機器にも、通信機能が搭載されてきている。それらの機器が採用している通信機能に関する代表的な物理インタフェース及びデータリンク層プロトコルの規格として、Ｅｔｈｅｒｎｅｔ（登録商標）やＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｅｎｇｉｎｅｅｒｓ）８０２．３の有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）規格や、ＩＥＥＥ８０２．１１の無線ＬＡＮ規格がある。又、ネットワーク層プロトコルとして、ＩＡＢ（Ｉｎｔｅｒｎｅｔ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｂｏａｒｄ）によりＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）７９１で定義されているＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）規格があり、又、トランスポート層プロトコルとしてＲＦＣ７９１で定義されているＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）規格や、ＲＦＣ７６８で定義されているＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）規格がある。

ネットワーク層プロトコル及びトランスポート層プロトコル等の機能を合わせ持ったネットワーク制御ソフトウェア群は一般にプロトコルスタックと称され、それらの機器が採用するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）によってプロトコルスタックは異なってくる。例えばＵＮＩＸ（登録商標）系のＯＳには、カーネルにプロトコルスタックが標準搭載されていることが多い。一方、通信に標準対応していないＯＳについても、通信機器の開発メーカ・製造メーカに向けた、そのＯＳに対して通信機能を提供するためのプロトコルスタック製品が販売・提供されていることが多い。そのため、多様な仕様から成る各プロトコル機能を組み合わせた標準規格に則した通信機能を有する機器を開発・製造することは、今般は比較的困難ではなくなってきている。

プロトコルスタックの代表的なＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）仕様として、非特許文献１や非特許文献２に示されるソケットがある。

図１０は、代表的なソケットＡＰＩ仕様を有するプロトコルスタックにおける、ＴＣＰプロトコル通信のＡＰＩ関数呼び出し順を示す図であり、図１１は、代表的なソケットＡＰＩ仕様を有するプロトコルスタックにおける、ＵＤＰプロトコル通信のＡＰＩ関数呼び出し順を示す図である。いずれの図も、右半分がサーバ側を示しており、左半分がクライアント側を示している。これら図に示した関数は一般的な表記であるが、他の一般的な表記としてｗｒｉｔｅ関数１００６の代わりにｓｅｎｄ関数と表記することもあり、又ｒｅａｄ関数１００５の代わりにｒｅｃｖ関数と表記することもある。

ｓｏｃｋｅｔ関数１００１は、ＴＣＰプロトコル通信／ＵＤＰプロトコル通信や、サーバ／クライアント等の属性を持つソケットを生成する。ｂｉｎｄ関数１００２は、ソケットにポート番号等の属性を与える。ｌｉｓｔｅｎ関数１００３は通信相手からの接続を待つ。ｃｏｎｎｅｃｔ関数１０１１は通信相手に接続を要求する。ａｃｃｅｐｔ関数１００４は通信相手からの接続を受け入れる。ｗｒｉｔｅ関数１００６及びｓｅｎｄｔｏ関数１１０６は通信相手にデータを送り、一方、ｒｅａｄ関数１００５及びｒｅｃｖｆｒｏｍ関数１１０５は通信相手からのデータを受ける。ｃｌｏｓｅ関数１００７はソケットを閉じる。

ソケットＡＰＩ仕様を有するプロトコルスタックとそれを用いるアプリケーションプログラムのＴＣＰによるデータ送信時の働きについて、通信相手の指定や接続の確立・切断の手続き等については省略し、特に送信データの流れ（ｗｒｉｔｅ関数１００６の働きの詳細）に着目して説明すると、次の送信ステップ１〜５のようになる。

［送信ステップ１］アプリケーションプログラムは、アプリケーションプログラム自身が（ＯＳのメモリ管理機能を用いて）確保済の第１のメモリ領域に、送信すべきデータを格納（準備）する。

［送信ステップ２］アプリケーションプログラムは、プロトコルスタックに対して第１のメモリ領域を指定しながらｗｒｉｔｅ関数１００６を呼び出し送信指示する。

［送信ステップ３］プロトコルスタックは、プロトコルスタック自身が（ＯＳのメモリ管理機能を用いて）確保済の第２のメモリ領域にアプリケーションプログラムから指定された第１のメモリ領域のデータをコピーし、更にそのデータのチェックサム値を計算する。ここにチェックサム値の計算は、対象とするデータは同一であるため、コピーと同時に行うことも可能である。

［送信ステップ４］プロトコルスタックは、得られたチェックサム値を用いてＴＣＰヘッダ等のプロトコルヘッダを生成する。

［送信ステップ５］プロトコルスタックは、通信相手に対して、生成したプロトコルヘッダとともに第２のメモリ領域のデータを送信する。

又、ソケットＡＰＩ仕様を有するプロトコルスタックとそれを用いるアプリケーションプログラムのＴＣＰによるデータ受信時の働きについて、通信相手の指定や接続の確立・切断の手続き等については省略し、特に受信データの流れ（ｒｅａｄ関数１００５の働きの詳細）に着目して説明すると、次の受信ステップ１〜５のようになる。

［受信ステップ１］プロトコルスタックは、プロトコルスタック自身が（ＯＳのメモリ管理機能を用いて）確保済の第３のメモリ領域に、通信相手からの受信データを格納する。

［受信ステップ２］アプリケーションプログラムは、プロトコルスタックに対してアプリケーションプログラム自身が（ＯＳのメモリ管理機能を用いて）確保済の第四のメモリ領域を指定しながらｒｅａｄ関数１００５を呼び出し受信指示する。

［受信ステップ３］プロトコルスタックは、アプリケーションプログラムから指定された第四のメモリ領域に第３のメモリ領域のデータをコピーし、更にそのデータのチェックサム値を計算する。ここにチェックサム値の計算は、対象とするデータは同一であるため、コピーと同時に行うことも可能である。

［受信ステップ４］プロトコルスタックは、得られたチェックサム値と受信ＴＣＰヘッダに含まれるチェックサム値が整合していることを確認すると、アプリケーションプログラムに知らせる。

［受信ステップ５］アプリケーションプログラムは、第四のメモリ領域のデータを利用する。

尚、以上のソケットＡＰＩ仕様を有するプロトコルスタックとそれを用いるアプリケーションプログラムのＴＣＰによるデータ受信時の働きにおいて、上記受信ステップ１と２は、通信相手からの受信データの到着タイミングによっては前後することもある。

このようにデータの送受信に際して、ソケットＡＰＩ仕様を有するプロトコルスタックを用いたアプリケーションプログラムは、準備した送信データが格納されたメモリ領域を指定しながら送信関数を呼び出したり、後ほど利用するための受信データを格納すべきメモリ領域を指定しながら受信関数を呼び出したりするだけでよい。そのためソケットＡＰＩ仕様を有するプロトコルスタックは、アプリケーションプログラムが負担・配慮しなければならないことが少ない体系として完成しており、機器やＯＳの種別に関わらず広く利用されている。
"Ｔｅｓｔ Ｐａｇｅ． Ｙｏｓｈｉｆｕｍｉ Ｔａｎａｋａ"，［ｏｎｌｉｎｅ］，［２００５年１０月１１日検索］，インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｋａｎｓａｉ．ａｎｅｓｔｈ．ｏｒ．ｊｐ／ｇｉｊｕｔｕ／ｃ＋＋／ｍａｎ−ｓｏｃｋｅｔ．ｐｈｐ＞ Ｍｉｃｈａｅｌ Ｊ． Ｄｏｎａｈｏｏ、Ｋｅｎｎｅｔｈ Ｌ． Ｃａｌｖｅｒｔ共著、小高 知宏訳，「ＴＣＰ／ＩＰソケットプログラミング Ｃ言語編」，オーム社，２００３年

しかしながら、前述のソケットＡＰＩ仕様のプロトコルスタックでは、データ送信時はアプリケーションプログラムが確保したメモリ領域からプロトコルスタックが確保したメモリ領域への、データ受信時はプロトコルスタックが確保したメモリ領域からアプリケーションプログラムが確保したメモリ領域への、チェックサム計算を伴うデータコピーが発生する。これにより、そのデータが流れるバス帯域の浪費を導き、又、その処理を行うプロセッサの処理負荷の浪費を導くという問題があった。

そこで、本発明の目的は、アプリケーションプログラムとプロトコルスタックの間のチェックサム計算を伴うデータコピーを発生させずに送受信することで、バス帯域の消費の効率化、及びプロセッサの処理負荷の消費の効率化を達成するストリームデータ通信方法及びストリームデータ通信装置を提供することにある。

本発明のストリームデータ通信方法及びストリームデータ通信装置においては、チェックサム計算モジュールを有し、ストリームデータが入力されるストリームインタフェースと、ストリームデータを送信する通信インタフェースと、アプリケーションプログラムとプロトコルスタックとで構成されるプログラムが記憶されるメモリと、プログラムを処理するプロセッサとを備え、チェックサム計算モジュールを利用してチェックサム値を計算し、アプリケーションプログラムとプロトコルスタックで利用するメモリを共有化し、送信時にはアプリケーションプログラムが準備した送信すべきデータをプロトコルスタックがコピーすることなく通信インタフェースに指示して送信し、受信時には通信インタフェースがネットワークを介して受信するデータをプロトコルスタックがコピーすることなくアプリケーションプログラムが利用することを最も主要な特徴とする。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明によれば、アプリケーションプログラムとプロトコルスタックの間のチェックサム計算を伴うデータコピーが発生せずに送受信可能なため、バス帯域の消費の効率化、及びプロセッサの処理負荷の消費の効率化を達成するという利点がある。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。尚、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
＜ストリームデータ通信装置の構成＞
図１により、本発明の実施の形態１に係るストリームデータ通信装置の構成について説明する。図１は本発明の実施の形態１に係るストリームデータ通信装置の構成を示す構成図であり、ストリームデータの送信を行う構成である。

図１において、ストリームデータ通信装置１０１は、各種のデータ演算や判断等のデータ処理を行うプロセッサ１１１と、データを記憶するメモリ１１２と、データの送信及び受信を行う通信インタフェース１１３と、ストリームデータの入力及び出力を行うストリームインタフェース１１４を備える。プロセッサ１１１とメモリ１１２と通信インタフェース１１３とストリームインタフェース１１４とは、内バス１１６を介して接続されている。

プロセッサ１１１と通信インタフェース１１３とストリームインタフェース１１４はそれぞれ、特にメモリ１１２へのアクセスについては内バス１１６を主導する（バスマスタである）。ストリームインタフェース１１４は、チェックサム計算を行うチェックサム計算モジュール１１５を備える。

更に、ストリームデータ通信装置１０１は、通信インタフェース１１３に接続された通信ケーブル１２１を介して、ＬＡＮ或いはインターネットといったネットワーク１２２に接続されている。ネットワーク１２２には図示していない通信相手が存在し、ストリームデータ通信装置１０１はその通信相手と通信可能な状態である。

更に、ストリームデータ通信装置１０１は、外バス１３１を介してストリーマ１３２と接続されている。ストリーマ１３２は、図示していない記憶装置からその記憶装置に格納されているストリームデータを入手したり、或いはその記憶装置にストリームデータを格納したり、或いは図示していないチューナからストリームデータを受けたり、或いはストリームデータを処理して映像データや音声データを生成し、図示していないディスプレイに映像データを、図示していないスピーカに音声データを送ったりすること等が可能である。ストリームデータ通信装置１０１は、ストリーマ１３２からストリームデータが入力され、ストリーマ１３２へストリームデータを出力する。

＜ストリームデータ通信装置のストリームデータ通信方法＞
次に、図２及び図３により、本発明の実施の形態１に係るストリームデータ通信装置のストリームデータ通信方法について説明する。図２は本発明の実施の形態１に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートであり、ストリームデータを送信する場合の動作を示している。図３は本発明の実施の形態１に係るストリームデータ通信装置のストリームデータ通信方法においてストリームデータを送信する場合のメモリ内のデータ配置を示す図である。

まず、プロセッサ１１１は、メモリ１１２が記憶している３種類のプログラム、すなわちアプリケーションプログラム３０１、及びプロトコルスタック３０２、及び図示していないＯＳ（カーネル）に従って動作している。

以下では、プロセッサ１１１という語句の代わりにプロセッサ１１１で処理中のプログラム（アプリケーションプログラム３０１、又はプロトコルスタック３０２）を語句として用い、ストリームデータを送信する場合におけるストリームデータ通信装置１０１の動作について説明する。

まず、ステップ１（２０１）において、アプリケーションプログラム３０１は、ストリームインタフェース１１４に対して、ストリーマ１３２から入力されるストリームデータのチェックサム値を計算しつつそのストリームデータを第１のメモリ領域３１１に格納することを指示する。それによって、ストリームインタフェース１１４は、入力されるストリームデータのチェックサム値をチェックサム計算モジュール１１５を用いて計算しつつそのストリームデータを第１のメモリ領域３１１に格納する。

次に、ステップ２（２０２）において、アプリケーションプログラム３０１は、プロトコルスタック３０２に対して、ステップ１（２０１）において、チェックサム計算モジュール１１５が計算したチェックサム値と第１のメモリ領域３１１を指定して送信指示する。

すなわち、アプリケーションプログラム３０１は、ステップ１（２０１）において、チェックサム計算モジュール１１５が計算したチェックサム値と第１のメモリ領域３１１を指定して、プロセッサ１１１の次の処理としてプロトコルスタック３０２の送信処理へと移す。

次に、ステップ３（２０３）において、指示を受けたプロトコルスタック３０２は、指定されたチェックサム値を用いて、指定された第１のメモリ領域３１１に格納されているストリームデータを通信に供させるためのデータ（プロトコルヘッダ）を生成して、第２のメモリ領域３１２に格納する。

一般に、プロトコルヘッダとは、例えば、ＴＣＰプロトコルによる通信の場合はＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダ、ＩＰヘッダ、及びＴＣＰヘッダであり、又、例えば、ＵＤＰプロトコルによる通信の場合はＭＡＣヘッダ及びＩＰヘッダ及びＵＤＰヘッダである。ＩＰｖ６プロトコルによる通信の場合はそれらＩＰヘッダは実際にはＩＰｖ６ヘッダである。

ＴＣＰヘッダには必須として、ＵＤＰヘッダには選択可能として、送信すべきデータとプロトコルヘッダの構成要素の一部（ポート番号等）のチェックサム値を格納する部分がある。ステップ３（２０３）では、指定された第１のメモリ領域３１１に格納されたデータを読み出すことなく、指定されたチェックサム値を利用してその値とプロトコルヘッダの構成要素の一部とのチェックサム値を計算して、ＴＣＰヘッダ或いはＵＤＰヘッダに格納するチェックサム値とする。

次に、ステップ４（２０４）において、プロトコルスタック３０２は、通信インタフェース１１３に対して、第２のメモリ領域３１２と第１のメモリ領域３１１それぞれに格納されているデータを一連の送信データとして送信することを指示する。それによって通信インタフェース１１３は、指定された第２のメモリ領域３１２と第１のメモリ領域３１１に格納されているそれぞれのデータを一連の送信データとして、通信ケーブル１２１、ひいてはネットワーク１２２、ひいては通信相手へと送信する。

次に、プロトコルスタック３０２は、送信完了を認識すると、ステップ５（２０５）において、アプリケーションプログラム３０１に対して送信完了したことを知らせる。

最終的にステップ５（２０５）において、アプリケーションプログラム３０１が送信完了を知った後には、アプリケーションプログラム３０１は、第１のメモリ領域３１１を（ＯＳのメモリ管理機能を用いて）解放、或いは別用途に用いて別データを再格納することが可能であるし、或いはステップ１（２０１）から再開して第１のメモリ領域３１１に次に送信すべきストリームデータを再格納することも可能である。

逆に、送信完了を知る前には、アプリケーションプログラム３０１が第１のメモリ領域３１１の解放や再格納することは制限される。第１のメモリ領域３１１に格納されているストリームデータが通信インタフェース１１３からの送信前に、或いは通信相手からの受信応答の確認前に破壊されてしまうと、アプリケーションプログラム３０１が意図した送信すべきストリームデータを送信、或いは再送信できなくなるためである。

但し、前述した送信完了とは、受信側が正常受信したという意味に限定されるものではなく、信頼性の提供が不要な通信では、例えば通信インタフェース１１３が送信している最中に通信ケーブル１２１で信号が衝突したことによる送信エラーを送信完了と見なす等も可能である。

尚、以上ではアプリケーションプログラム３０１が単一のストリームデータを単一の送信データとして送信する、言わば基本的な流れを説明したが、ストリームデータ通信方法はこれに限定されるものではない。

例えば、ステップ１（２０１）において、アプリケーションプログラム３０１は逐次入力されるストリームデータのそれぞれのチェックサム値を計算しつつそれぞれのストリームデータを複数のメモリ領域それぞれに格納するように指示し、ステップ２（２０２）において、アプリケーションプログラム３０１はそれぞれのチェックサム値と対応するメモリ領域を指定して、それぞれ送信指示し、ステップ３（２０３）において、プロトコルスタック３０２は対応するプロトコルヘッダをそれぞれ生成し、ステップ４（２０４）において、プロトコルスタック３０２はそれぞれのプロトコルヘッダ及び対応するストリームデータを合わせた一連のデータそれぞれを指定しつつ送信指示し、ステップ５（２０５）において、プロトコルスタック３０２は送信完了したものから知らせる、等の実施も可能である。

又、上述ではステップ２（２０２）において、アプリケーションプログラム３０１がプロトコルスタック３０２にチェックサム値を知らせるとしたが、これは明示的なものではなく、暗黙的な実施も可能である。すなわち、例えば、ステップ１（２０１）において、チェックサム計算モジュール１１５が計算したチェックサム値をストリームインタフェース１１４が、例えば第１のメモリ領域３１１の直後のメモリ領域に格納することを決まり事としておけば、ステップ２（２０２）において、アプリケーションプログラム３０１がプロトコルスタック３０２にチェックサム値を明示的に知らせなくても、ステップ３（２０３）では、プロトコルスタック３０２は第１のメモリ領域３１１の直後のメモリ領域を読み出した値をチェックサム値として利用する、等の実施も可能である。

尚、プロトコルスタック３０２は、既存のＡＰＩ仕様を有するプロトコルスタックを簡単に修正することによって実施することが可能である。すなわち、図１０及び図１１に示した公知の代表的なソケットＡＰＩ仕様を有するプロトコルスタックのＡＰＩ関数において、ｗｒｉｔｅ関数１００６或いはｓｅｎｄｔｏ関数１１０６は、ソケットとデータ（メモリ領域）だけを与えられるのではなく、そのデータのチェックサム値も与えられて、ステップ３（２０３）〜ステップ５（２０５）を実行するように修正すればよい。

それに対応するアプリケーションプログラム３０１は、ステップ１（２０１）において、ストリームデータを通信に供するサイズ毎に分割してそれぞれのチェックサム値をチェックサム計算モジュール１１５を用いて計算し（そのようにストリームインタフェース１１４に指示し）、ステップ２（２０２）において、メモリ領域と合わせて得られたチェックサム値も指定してそれら関数を呼び出すように修正すればよい。

そして、アプリケーションプログラム３０１とプロトコルスタック３０２との間でフラグを予め共有し、アプリケーションプログラム３０１がそれら関数の呼び出しの前にそのフラグを初期化しておき、プロトコルスタック３０２はステップ５（２０５）において、そのフラグの値を変更すれば、そのフラグの値をアプリケーションプログラム３０１が観測することにより、プロトコルスタック３０２がアプリケーションプログラム３０１に対して送信完了したことを知らせることが可能である。

ステップ５（２０５）において、プロトコルスタック３０２がアプリケーションプログラム３０１に対して送信完了したことを知らせる他の方法は、アプリケーションプログラム３０１へコールバックする関数を登録するための新規のＡＰＩ関数をプロトコルスタック３０２に予め用意し、コールバック関数（イベントリスナー）をアプリケーションプログラム３０１に予め用意し、アプリケーションプログラム３０１はそのＡＰＩ関数を用いてそのコールバック関数を予め登録し、プロトコルスタック３０２がステップ５（２０５）において、その関数を呼び出せばよい。

ステップ５（２０５）において、プロトコルスタック３０２がアプリケーションプログラム３０１に対して送信完了したことを知らせる更なる他の方法は、アプリケーションプログラム３０１が割り込み処理の関数を予め用意し、プロトコルスタック３０２がステップ５（２０５）において、その割り込み処理の関数に対応する割り込み要求を発生させればよい。

以上説明したストリームデータ通信方法及びストリームデータ通信装置によれば、アプリケーションプログラムとプロトコルスタックの間のチェックサム計算を伴うデータコピーは発生せずにストリームデータを送信可能なため、バス帯域の消費の効率化、及びプロセッサの処理負荷の消費の効率化を達成する。

尚、本実施の形態のストリームインタフェース１１４は、図示していないタイムスタンプ挿入モジュールを備えることが可能である。タイムスタンプ挿入モジュールは、ストリーマ１３２からストリームインタフェース１１４に入力されるストリームデータに対して、所定のサイズ毎に（相対的な）時間データ（タイムスタンプ）を挿入する。

この場合、以前の説明では、ストリーマ１３２からストリームインタフェース１１４に入力されるストリームデータのを除く全ての「ストリームデータ」を「タイムスタンプが挿入されたストリームデータ」と読み替えれば実施可能である。こうすることで、通信相手（受信側）でこのタイムスタンプ値を参照することにより、ストリーマ１３２からの入力と相対的な時間が等しいタイミングで通信相手はストリームデータを扱うことが可能となる。

又、本実施の形態のストリームインタフェース１１４は、図示していない暗復号化モジュールを備えることが可能である。暗復号化モジュールは、ストリーマ１３２からストリームインタフェース１１４に入力される暗号化されたストリームデータを復号して元のストリームデータに戻す。

この場合、以前の説明では、ストリーマ１３２からストリームインタフェース１１４に入力される（暗号化された）「ストリームデータ」のみを「暗号化されたストリームデータ」と読み替えれば実施可能である。こうすることで、外バス１３１を流れるストリームデータが暗号化されることになり、外バス１３１が攻撃されることによるストリームデータの不正な複製等を避けることが可能となる。

又、暗復号化モジュールは、ストリーマ１３２からストリームインタフェース１１４に入力されるストリームデータを暗号化する。この場合、以前の説明では、ストリーマ１３２からストリームインタフェース１１４に入力されるストリームデータを除く全ての「ストリームデータ」を「暗号化されたストリームデータ」と読み替えれば実施可能である。こうすることで、通信相手（受信側）までのネットワーク１２２を流れるストリームデータが暗号化されることになり、ネットワーク１２２が攻撃されることによるストリームデータの不正な複製等を避けることが可能となる。

（実施の形態２）
＜ストリームデータ通信装置の構成＞
図４により、本発明の実施の形態２に係るストリームデータ通信装置の構成について説明する。図４は本発明の実施の形態２に係るストリームデータ通信装置の構成を示す構成図であり、ストリームデータの受信を行う構成である。

図４において、実施の形態１で説明した図１と符号が同じ部位の働きの概要は、実施の形態１と同じであるため、ここでは説明を省く。

ストリームデータ通信装置４０１は、プロセッサ１１１と、メモリ１１２と、データの送信及び受信を行う通信インタフェース４１３と、ストリームデータの入力及び出力を行うストリームインタフェース４１４を備える。プロセッサ１１１とメモリ１１２と通信インタフェース４１３とストリームインタフェース４１４とは、内バス１１６を介して接続されている。

プロセッサ１１１と通信インタフェース４１３とストリームインタフェース４１４はそれぞれ、特にメモリ１１２へのアクセスについては内バス１１６を主導する（バスマスタである）。通信インタフェース４１３は、チェックサム計算を行うチェックサム計算モジュール４１５を備える。

＜ストリームデータ通信装置のストリームデータ通信方法＞
次に、図５及び図６により、本発明の実施の形態２に係るストリームデータ通信装置のストリームデータ通信方法について説明する。図５は本発明の実施の形態２に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートであり、ストリームデータを受信する場合の動作を示している。図６は本発明の実施の形態２に係るストリームデータ通信装置のストリームデータ通信方法においてストリームデータを受信する場合のメモリ内のデータ配置を示す図である。

まず、プロセッサ１１１は、メモリ１１２が記憶している３種類のプログラム、すなわちアプリケーションプログラム６０１、及びプロトコルスタック６０２、及び図示していないＯＳ（カーネル）に従って動作している。

以下では、プロセッサ１１１という語句の代わりにプロセッサ１１１で処理中のプログラム（アプリケーションプログラム６０１、又はプロトコルスタック６０２）を語句として用い、ストリームデータを受信する場合におけるストリームデータ通信装置４０１の動作を説明する。

まず、ステップ１（５０１）において、プロトコルスタック６０２は、通信インタフェース４１３に対して、図示していない通信相手からの受信データのチェックサム値を計算しつつその受信データを第１のメモリ領域６１１に格納することを指示する。それによって通信インタフェース４１３は、通信相手からの受信データのチェックサム値をチェックサム計算モジュール４１５を用いて計算しつつその受信データを第１のメモリ領域６１１に格納する。

尚、ステップ１（５０１）において、チェックサム計算モジュール４１５は、受信データのうち、プロトコルヘッダが常に存在する最初の所定サイズのデータを無視し、残りの部分のチェックサム値を計算するようにも実施可能である。又、チェックサム計算モジュール４１５は、受信データのうち、プロトコルヘッダが拡張されていないか解釈して適切なサイズのデータを無視するようにも実施可能である。更に、チェックサム計算モジュール４１５は、ＴＣＰヘッダやＵＤＰヘッダに格納されるチェックサム値の計算に参照されるプロトコルヘッダの構成要素の一部（ポート番号等）は無視せずに、プロトコルヘッダ以外の部分と合わせてチェックサム値を計算するようにも実施可能である。

次に、ステップ２（５０２）において、プロトコルスタック６０２は、第１のメモリ領域６１１に格納されたデータのうち通信に供させるためのデータ（プロトコルヘッダ）６１２を解釈して、残りのデータが格納された第２のメモリ領域６１３を抽出（認識）しつつ、ステップ１（５０１）において、チェックサム計算モジュール４１５が計算したチェックサム値も用いてアプリケーションプログラム６０１が扱うべき適切なデータかどうかを判定する。

すなわち、プロトコルヘッダ６１２に含まれるアドレスとストリームデータ通信装置４０１のネットワークアドレスが整合しているか、或いはプロトコルヘッダ６１２に含まれるポート番号とアプリケーションプログラム６０１のポート番号が整合しているか、或いはプロトコルヘッダ６１２に含まれるＴＣＰヘッダ或いはＵＤＰヘッダに格納されているチェックサム値と、プロトコルヘッダ６１２の構成要素の一部（ポート番号等）と第２のメモリ領域６１３に格納されているデータから計算されるチェックサム値が整合しているか、等である。このチェックサム値の整合性の判定では、第２のメモリ領域６１３に格納されたデータを読み出すことなく、ステップ１（５０１）によって得られたチェックサム値を利用する。

この判定によって、ストリームデータ通信装置４０１が扱うべきデータではないことを（他の通信装置へのデータ、或いは破損したと推定されるデータである等と）認識すると、プロトコルスタック６０２は第１のメモリ領域６１１に格納されたデータを廃棄（無視）する。又、プロトコルスタック６０２が扱うべきデータであると認識すると、プロトコルスタック６０２は対応した処理を行う。又、アプリケーションプログラム６０１ではない他のアプリケーションプログラムが扱うべきデータであると認識すると、プロトコルスタック６０２は以降のステップを対応するアプリケーションプログラムのために行う。

図示していないが、アプリケーションプログラム６０１が扱うべきデータであると認識された場合のみ、次のステップ３（５０３）に進み、他の場合は本説明においてはステップ１（５０１）に戻る。

更に、ステップ３（５０３）において、アプリケーションプログラム６０１は、プロトコルスタック６０２に対して、受信指示する。

ここに、ステップ１（５０１）とステップ２（５０２）とステップ３（５０３）は、ステップ１（５０１）とステップ２（５０２）の順序は変わらないものの、アプリケーションプログラム６０１の受信指示タイミングと通信相手からの受信データの到着タイミングによっては、図５に示した順序に関わらず前後することもある。

すなわち、ステップ１（５０１）の後にステップ３（５０３）が続き、その後にステップ２（５０２）が続くこともあれば、ステップ３（５０３）の後にステップ１（５０１）が続き、その後にステップ２（５０２）が続くこともある。

次に、ステップ４（５０４）において、プロトコルスタック６０２は、アプリケーションプログラム６０１に対して、アプリケーションプログラム６０１が扱うべきストリームデータが格納されている第２のメモリ領域６１３を知らせる。

次に、ステップ５（５０５）において、アプリケーションプログラム６０１は、ストリームインタフェース４１４に対して、知らされた第２のメモリ領域６１３に格納されているストリームデータをストリーマ１３２に出力することを指示する。

それによってストリームインタフェース４１４は、第２のメモリ領域６１３に格納されているストリームデータをストリーマ１３２に出力する。

次に、アプリケーションプログラム６０１は、出力完了を認識すると、ステップ６（５０６）において、プロトコルスタック６０２に対して利用完了したことを知らせる。

最終的にステップ６（５０６）においてプロトコルスタック６０２が利用完了を知った後には、プロトコルスタック６０２は、第２のメモリ領域６１３を（ＯＳのメモリ管理機能を用いて）解放、或いは別用途に用いて別データを再格納することができるし、或いはステップ１（５０１）から再開して第１のメモリ領域６１１に次の受信データを再格納することもできる。逆に利用完了を知る前には、プロトコルスタック６０２が第２のメモリ領域６１３の解放や再格納することは制限される。

尚、以上ではアプリケーションプログラム６０１が単一の受信データに含まれる単一のストリームデータを利用する、言わば基本的な流れを説明したが、ストリームデータ通信方法はこれに限定されるものではない。例えば、ステップ１（５０１）においてプロトコルスタック６０２は逐次受信される複数の受信データのそれぞれのチェックサム値を計算しつつそれぞれの受信データを複数のメモリ領域それぞれに格納するように指示し、ステップ２（５０２）においてプロトコルスタック６０２はそれぞれのメモリ領域に格納されたデータに対して解釈及び抽出及び判定し、ステップ３（５０３）においてアプリケーションプログラム６０１は複数回受信指示し、ステップ４（５０４）においてプロトコルスタック６０２は複数のメモリ領域を知らせ、ステップ５（５０５）においてアプリケーションプログラム６０１は複数のメモリ領域に格納されたストリームデータそれぞれを出力することを指示し、ステップ６（５０６）においてアプリケーションプログラム６０１は利用完了したものから知らせる、等の実施も可能である。

尚、プロトコルスタック６０２は、既存のＡＰＩ仕様を有するプロトコルスタックを簡単に修正することによって実施することが可能である。すなわち、プロトコルスタック６０２は、ステップ１（５０１）において、受信データのチェックサム値をチェックサム計算モジュール４１５を用いて計算し（そのように通信インタフェース４１３に指示し）、ステップ２（５０２）におけるプロトコルヘッダ６１２の構成要素の一部（ポート番号等）と第２のメモリ領域６１３に格納されているデータから計算されるチェックサム値の計算を、第２のメモリ領域６１３に格納されたデータを読み出すことなく、ステップ１（５０１）によって得られたチェックサム値を利用するように修正すればよい。

又、図１０及び図１１に示した公知の代表的なソケットＡＰＩ仕様を有するプロトコルスタックのＡＰＩ関数において、ｒｅａｄ関数１００５或いはｒｅｃｖｆｒｏｍ関数１１０５は、アプリケーションプログラムが扱うべきデータを格納すべきメモリ領域が与えられるのではなく、アプリケーションプログラムが扱うべきデータが格納されたメモリ領域を与えるように修正すればよい。

それに対応するアプリケーションプログラム６０１は、それら関数によって与えられるメモリ領域に格納されたデータを利用するように修正すればよい。

そして、アプリケーションプログラム６０１とプロトコルスタック６０２との間でフラグを予め共有し、プロトコルスタック６０２がそれら関数に対応する処理から抜ける前にそのフラグを初期化しておき、アプリケーションプログラム６０１はステップ６（５０６）において、そのフラグの値を変更すれば、そのフラグの値をプロトコルスタック６０２が観測することにより、アプリケーションプログラム６０１がプロトコルスタック６０２に対して利用完了したことを知らせることが可能である。

ステップ６（５０６）において、アプリケーションプログラム６０１がプロトコルスタック６０２に対して利用完了したことを知らせる他の方法は、新規のＡＰＩ関数をプロトコルスタック６０２に予め用意し、アプリケーションプログラム６０１がステップ６（５０６）において、その関数を呼び出せばよい。

ステップ６（５０６）において、アプリケーションプログラム６０１がプロトコルスタック６０２に対して利用完了したことを知らせる更なる他の方法は、プロトコルスタック６０２が割り込み処理の関数を予め用意し、アプリケーションプログラム６０１がステップ６（５０６）において、その割り込み処理の関数に対応する割り込み要求を発生させればよい。

以上説明したストリームデータ通信方法及びストリームデータ通信装置によれば、プロトコルスタックとアプリケーションプログラムの間のチェックサム計算を伴うデータコピーは発生せずにストリームデータを受信可能なため、バス帯域の消費の効率化、及びプロセッサの処理負荷の消費の効率化を達成する。

尚、本実施の形態のストリームインタフェース４１４は、図示していないタイムスタンプ削除モジュールを備えることが可能である。タイムスタンプ削除モジュールは、通信相手（送信側）によって（相対的な）時間データ（タイムスタンプ）が挿入されたストリームデータに対して、そのタイムスタンプ値を参照することによって相対的な時間が等しいタイミングで、タイムスタンプを削除したストリームデータをストリーマ１３２に出力する。

この場合、以前の説明では、ストリームインタフェース４１４がストリーマ１３２に出力するストリームデータを除く全ての「ストリームデータ」を「タイムスタンプが挿入されたストリームデータ」と読み替えれば実施可能である。こうすることで、通信相手（送信側）がこのタイムスタンプを挿入したのと相対的な時間が等しいタイミングで、ストリームデータをストリーマ１３２に出力することが可能となる。

又、本実施の形態のストリームインタフェース４１４は、図示していない暗復号化モジュールを備えることが可能である。暗復号化モジュールは、ストリームインタフェース１１４がストリーマ１３２に出力するデータを暗号化する。この場合、以前の説明では、ストリームインタフェース４１４がストリーマ１３２に出力する「ストリームデータ」のみを「暗号化されたストリームデータ」と読み替えれば実施可能である。こうすることで、外バス１３１を流れるストリームデータが暗号化されることになり、外バス１３１が攻撃されることによるストリームデータの不正な複製等を避けることが可能となる。

又、暗復号化モジュールは、通信相手（送信側）によって暗号化されたストリームデータを復号して元のストリームデータに戻す。この場合、以前の説明では、ストリームインタフェース４１４がストリーマ１３２に出力するストリームデータを除く全ての「ストリームデータ」を「暗号化されたストリームデータ」と読み替えれば実施可能である。こうすることで、通信相手（受信側）からのネットワーク１２２を流れるストリームデータが暗号化されることになり、ネットワーク１２２が攻撃されることによるストリームデータの不正な複製等を避けることが可能となる。

（実施の形態３）
＜ストリームデータ通信装置の構成＞
図７により、本発明の実施の形態３に係るストリームデータ通信装置の構成について説明する。図７は本発明の実施の形態３に係るストリームデータ通信装置の構成を示す構成図であり、ストリームデータの送受信を行う構成である。

図７において、実施の形態１及び２で説明した図１及び図４と符号が同じ部位の働きの概要は、実施の形態１及び２と同じであるため、ここでは説明を省く。

ストリームデータ通信装置７０１は、プロセッサ１１１と、メモリ１１２と、データの送信及び受信を行う通信インタフェース１１３と、ストリームデータの入力及び出力を行うストリームインタフェース４１４と、チェックサム計算を行うチェックサム計算モジュール７１５を備える。

プロセッサ１１１とメモリ１１２と通信インタフェース１１３とストリームインタフェース４１４とチェックサム計算モジュール７１５とは、内バス１１６を介して接続されている。プロセッサ１１１と通信インタフェース１１３とストリームインタフェース４１４とチェックサム計算モジュール７１５とはそれぞれ、特にメモリ１１２へのアクセスについては内バス１１６を主導する（バスマスタである）。

＜ストリームデータ通信装置のストリームデータ通信方法＞
次に、図８により、本発明の実施の形態３に係るストリームデータ通信装置のストリームデータ通信方法について説明する。図８は本発明の実施の形態３に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートであり、ストリームデータを送信する場合の動作を示している。尚、本実施の形態のストリームデータを受信する場合のメモリ内のデータ配置は、実施の形態１で示した図３と同じであり、それを用いて説明する。

以下では、プロセッサ１１１という語句の代わりにプロセッサ１１１で処理中のプログラム（アプリケーションプログラム３０１、又はプロトコルスタック３０２）を語句として用い、ストリームデータを送信する場合におけるストリームデータ通信装置７０１の動作を説明する。

まず、ステップ１（８０１）において、アプリケーションプログラム３０１は、ストリームインタフェース４１４に対して、ストリーマ１３２から入力されるストリームデータを第１のメモリ領域３１１に格納することを指示する。それによってストリームインタフェース４１４は、入力されるストリームデータのチェックサム値をチェックサム計算モジュール１１５を用いて計算しつつそのストリームデータを第１のメモリ領域３１１に格納する。

次に、ステップ２（８０２）において、アプリケーションプログラム３０１は、プロトコルスタック３０２に対して、第１のメモリ領域３１１を指定して送信指示する。

次に、ステップ３（８０３）において、プロトコルスタック３０２は、チェックサム計算モジュール７１５に対して、指定された第１のメモリ領域３１１に格納されているデータのチェックサム値を計算することを指示する。それによってチェックサム計算モジュール７１５は、第１のメモリ領域３１１に格納されているデータをメモリ１１２から読み出し、そのチェックサム値を計算する。

次に、ステップ４（８０４）において、得られたチェックサム値を用いて、指定された第１のメモリ領域３１１に格納されているストリームデータを通信に供させるためのデータ（プロトコルヘッダ）を生成して、第２のメモリ領域３１２に格納する。ステップ４（８０４）では、第１のメモリ領域３１１に格納されたデータを読み出すことなく、ステップ３（８０３）によって得られたチェックサム値を利用してその値とプロトコルヘッダの構成要素の一部とのチェックサム値を計算して、ＴＣＰヘッダ或いはＵＤＰヘッダに格納するチェックサム値とする。

残りのステップ５（８０５）及びステップ６（８０６）はそれぞれ、図２に示す実施の形態１におけるステップ４（２０４）及びステップ５（２０５）と同じであるため、ここでは説明を省く。

尚、以上ではアプリケーションプログラム３０１が単一のストリームデータを単一の送信データとして送信する、言わば基本的な流れを説明したが、ストリームデータ通信方法はこれに限定されるものではない。

例えば、ステップ１（８０１）において、アプリケーションプログラム３０１は逐次入力されるそれぞれのストリームデータを複数のメモリ領域それぞれに格納するように指示し、ステップ２（８０２）において、アプリケーションプログラム３０１はそれぞれのメモリ領域を指定して、それぞれ送信指示し、ステップ３（８０３）において、プロトコルスタック３０２は指定されたそれぞれのメモリ領域に格納されているデータのチェックサム値をそれぞれ計算することを指示し、ステップ４（８０４）において、プロトコルスタック３０２は対応するプロトコルヘッダをそれぞれ生成する、等の実施も可能である。

尚、プロトコルスタック３０２は、既存のＡＰＩ仕様を有するプロトコルスタックを簡単に修正することによって実施することが可能である。すなわち、図１０及び図１１に示した公知の代表的なソケットＡＰＩ仕様を有するプロトコルスタックのＡＰＩ関数において、ｗｒｉｔｅ関数１００６或いはｓｅｎｄｔｏ関数１１０６は、それが呼ばれるとステップ３（８０３）〜ステップ６（８０６）を実行するように修正すればよい。

そして、ステップ６（８０６）においてプロトコルスタック３０２がアプリケーションプログラム３０１に対して送信完了したことを知らせる方法は、実施の形態１におけるステップ５（２０５）と同じであるため、ここでは説明を省く。

以上説明したストリームデータ通信方法及びストリームデータ通信装置によれば、アプリケーションプログラムとプロトコルスタックの間のチェックサム計算を伴うデータコピー（メモリからの読み出し及びメモリへの書き込み）は発生せずにストリームデータを送信可能である。チェックサム計算を伴うデータのメモリからの読み出しのみは全てのストリームデータに対して発生するものの、チェックサム計算は主にプロセッサが行うのではなくチェックサム計算モジュールが行う。よって、実施の形態１と比べれば劣ると考えられるものの、バス帯域の消費の効率化、及びプロセッサの処理負荷の消費の効率化を達成する。

尚、本実施例のストリームインタフェース４１４は、図示していないタイムスタンプ挿入モジュールや、図示していない暗復号化モジュールを備えることが可能であり、その機能を利用してその効果を得ることが実施可能であることは、実施の形態１におけるストリームインタフェース１１４と同じであるため、ここでは説明を省く。

（実施の形態４）
＜ストリームデータ通信装置の構成＞
実施の形態３におけるストリームデータ通信装置の構成は、実施の形態３で示した図７と同じでありそれを用いて説明する。働きの概要は、実施の形態３と同じであるため、ここでは説明を省く。

＜ストリームデータ通信装置のストリームデータ通信方法＞
次に、図９により、本発明の実施の形態４に係るストリームデータ通信装置のストリームデータ通信方法について説明する。図９は本発明の実施の形態３に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートであり、ストリームデータを受信する場合の動作を示している。尚、本実施の形態のストリームデータを受信する場合のメモリ内のデータ配置は、実施例実施の形態２で示した図６と同じでありそれを用いて説明する。

以下では、プロセッサ１１１という語句の代わりにプロセッサ１１１で処理中のプログラム（アプリケーションプログラム６０１、又はプロトコルスタック６０２）を語句として用い、ストリームデータを受信する場合におけるストリームデータ通信装置７０１の動作を説明する。

まず、ステップ１（９０１）において、プロトコルスタック６０２は、通信インタフェース１１３に対して、図示していない通信相手からの受信データを第１のメモリ領域６１１に格納することを指示する。それによって通信インタフェース１１３は、通信相手からの受信データを第１のメモリ領域６１１に格納する。

次に、ステップ２（９０２）において、プロトコルスタック６０２は、第１のメモリ領域６１１に格納されたデータのうち通信に供させるためのデータ（プロトコルヘッダ）６１２を解釈して、残りのデータが格納された第２のメモリ領域６１３を抽出（認識）しつつ、アプリケーションプログラム６０１が扱うべき適切なデータかどうかを判定する。

すなわち、プロトコルヘッダ６１２に含まれるアドレスとストリームデータ通信装置７０１のネットワークアドレスが整合しているか、或いはプロトコルヘッダ６１２に含まれるポート番号とアプリケーションプログラム６０１のポート番号が整合しているか、等である。尚、ステップ２（９０２）ではチェックサム値の整合性の判定は行わない。

この判定によって、ストリームデータ通信装置７０１が扱うべきデータではないことを（他の通信装置へのデータ、或いは破損したと推定されるデータである等と）認識すると、プロトコルスタック６０２は第１のメモリ領域６１１に格納されたデータを廃棄（無視）する。又、プロトコルスタック６０２が扱うべきデータであると認識すると、プロトコルスタック６０２は対応した処理を行う。

又、アプリケーションプログラム６０１ではない他のアプリケーションプログラムが扱うべきデータであると認識すると、プロトコルスタック６０２は以降のステップを対応するアプリケーションプログラムのために行う。図示していないが、アプリケーションプログラム６０１が扱うべきデータであると認識された場合のみ、次のステップ３（９０３）に進み、他の場合は本説明においてはステップ１（９０１）に戻る。

次に、ステップ３（９０３）において、プロトコルスタック６０２は、チェックサム計算モジュール７１５に対して、抽出された第２のメモリ領域６１３に格納されているデータのチェックサム値を計算することを指示する。それによってチェックサム計算モジュール７１５は、第２のメモリ領域６１３に格納されているデータをメモリ１１２から読み出し、そのチェックサム値を計算する。

次に、ステップ４（９０４）において、プロトコルスタック６０２は、プロトコルヘッダ６１２に含まれるＴＣＰヘッダ或いはＵＤＰヘッダに格納されているチェックサム値と、プロトコルヘッダ６１２の構成要素の一部（ポート番号等）と第２のメモリ領域６１３に格納されているデータから計算されるチェックサム値が整合しているかを判定する。ステップ４（９０４）では、第２のメモリ領域６１３に格納されたデータを読み出すことなく、ステップ３（９０３）によって得られたチェックサム計算モジュール７１５が計算したチェックサム値を利用する。

更に、ステップ５（９０５）において、アプリケーションプログラム６０１は、プロトコルスタック６０２に対して、受信指示する。

ここに、ステップ１（９０１）〜ステップ４（９０４）とステップ５（９０５）は、ステップ１（９０１）〜ステップ４（９０４）の順序は変わらないものの、アプリケーションプログラム６０１の受信指示タイミングと通信相手からの受信データの到着タイミングによっては、図９に示した順序に関わらず前後することもある。

残りのステップ６（９０６）〜ステップ８（９０８）は、それぞれ、実施の形態２におけるステップ４（５０４）〜ステップ６（５０６）と同じであるため、ここでは説明を省く。

尚、以上ではアプリケーションプログラム６０１が単一の受信データに含まれる単一のストリームデータを利用する、言わば基本的な流れを説明したが、ストリームデータ通信方法はこれに限定されるものではない。

例えば、ステップ１（９０１）において、プロトコルスタック６０２は逐次受信される複数の受信データを複数のメモリ領域それぞれに格納するように指示し、ステップ２（９０２）において、プロトコルスタック６０２はそれぞれのメモリ領域に格納されたデータに対して解釈及び抽出及び判定し、ステップ３（９０３）において、プロトコルスタック６０２は指定されたそれぞれのメモリ領域に格納されているデータのチェックサム値をそれぞれ計算することを指示し、ステップ４（９０４）において、プロトコルスタック６０２はそれぞれのメモリ領域に格納されたデータに対して正当性を判定し、ステップ５（９０５）において、アプリケーションプログラム６０１は複数回受信指示する、等の実施も可能である。

尚、プロトコルスタック６０２は、既存のＡＰＩ仕様を有するプロトコルスタックを簡単に修正することによって実施することが可能である。すなわち、プロトコルスタック６０２は、ステップ３（９０３）において、チェックサム値をチェックサム計算モジュール７１５を用いて計算し（そのようにチェックサム計算モジュール７１５に指示し）、ステップ４（９０４）におけるプロトコルヘッダ６１２の構成要素の一部（ポート番号等）と第２のメモリ領域６１３に格納されているデータから計算されるチェックサム値の計算を、第２のメモリ領域６１３に格納されたデータを読み出すことなく、ステップ３（９０３）によって得られたチェックサム値を利用するように修正すればよい。

又、図１０及び図１１に示した公知の代表的なソケットＡＰＩ仕様を有するプロトコルスタックのＡＰＩ関数において、ｒｅａｄ関数１００５或いはｒｅｃｖｆｒｏｍ関数１１０５は、アプリケーションプログラムが扱うべきデータを格納すべきメモリ領域が与えられるのではなく、アプリケーションプログラムが扱うべきデータが格納されたメモリ領域を与えるように修正すればよい。それに対応するアプリケーションプログラム６０１は、それら関数によって与えられるメモリ領域に格納されたデータを利用するように修正すればよい。

そして、ステップ８（９０８）において、アプリケーションプログラム６０１がプロトコルスタック６０２に対して利用完了したことを知らせる方法は、実施の形態２におけるステップ６（５０６）と同じであるため、ここでは説明を省く。

以上説明したストリームデータ通信方法及びストリームデータ通信装置によれば、アプリケーションプログラムとプロトコルスタックの間のチェックサム計算を伴うデータコピー（メモリからの読み出し及びメモリへの書き込み）は発生せずにストリームデータを受信可能である。チェックサム計算を伴うデータのメモリからの読み出しのみは全てのストリームデータに対して発生するものの、チェックサム計算は主にプロセッサが行うのではなくチェックサム計算モジュールが行う。

よって、実施の形態２と比べれば劣ると考えられるものの、バス帯域の消費の効率化、及びプロセッサの処理負荷の消費の効率化を達成する。

尚、本実施の形態のストリームインタフェース４１４は、図示していないタイムスタンプ削除モジュールや、図示していない暗復号化モジュールを備えることが可能であり、その機能を利用してその効果を得ることが実施可能であることは、実施の形態２と同じであるため、ここでは説明を省く。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、図１，図４，図７に示すストリームデータ通信装置１０１，４０１，７０１それぞれの構成要素、プロセッサ１１１やメモリ１１２や通信インタフェース１１３，４１３やストリームインタフェース１１４，４１４やチェックサム計算モジュール１１５，４１５，７１５は、それぞれ別々の半導体チップで実施することも可能であるし、或いはそのうちの複数或いは全てを一つの半導体チップで実施することも可能である。

すなわち、ストリームデータ通信装置１０１，４０１，７０１のそれぞれは、複数の半導体チップを組み合わせたセットとして実施することも可能であるし、或いはそれ自身を一つの半導体チップとして実施することも可能である。

又、通信インタフェース１１３，４１３それぞれは、通信ケーブル１２１を用いているため有線のネットワークに対応しているように示したが、通信ケーブルを用いない無線ネットワークに対応するように実施することも可能である。

本発明は、ストリームデータの通信方法及びストリームデータの通信装置に関し、特に、チェックサム計算モジュール及びソケット類似のプロトコルスタックを用いたバス帯域の浪費防止及びプロセッサ処理負荷の浪費防止に適用可能である。

本発明の実施の形態１に係るストリームデータ通信装置の構成を示す構成図である。 本発明の実施の形態１に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートである。 本発明の実施の形態１に係るストリームデータ通信装置のストリームデータ通信方法においてストリームデータを送信する場合のメモリ内のデータ配置を示す図である。 本発明の実施の形態２に係るストリームデータ通信装置の構成を示す構成図である。 本発明の実施の形態２に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートである。 本発明の実施の形態２に係るストリームデータ通信装置のストリームデータ通信方法においてストリームデータを受信する場合のメモリ内のデータ配置を示す図である。 本発明の実施の形態３に係るストリームデータ通信装置の構成を示す構成図である。 本発明の実施の形態３に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートである。 本発明の実施の形態３に係るストリームデータ通信装置のストリームデータ通信方法を示すフローチャートである。 代表的なソケットＡＰＩ仕様を有するプロトコルスタックにおける、ＴＣＰプロトコル通信のＡＰＩ関数呼び出し順を示す図である。 代表的なソケットＡＰＩ仕様を有するプロトコルスタックにおける、ＵＤＰプロトコル通信のＡＰＩ関数呼び出し順を示す図である。

符号の説明

１０１，４０１，７０１…ストリームデータ通信装置、１１１…プロセッサ、１１２…メモリ、１１３，４１３…通信インタフェース、１１４，４１４…ストリームインタフェース、１１５，４１５，７１５…チェックサム計算モジュール。

Claims (4)

1. アプリケーションプログラムとプロトコルスタックとで構成されるプログラムがプロセッサで処理されることによって動作し、前記プロセッサの外部に設けられチェックサムの計算を行うチェックサム計算モジュールを内部に備えるストリームインタフェースから入力されるストリームデータを、通信インタフェースから送信するストリームデータ通信装置のストリームデータ通信方法であって、
   前記アプリケーションプログラムが、前記ストリームインタフェースに対して、前記ストリームデータのチェックサム値を前記プロセッサの外部であるストリームインタフェースの内部に設けられた前記チェックサム計算モジュールで計算しつつ前記ストリームデータを第１のメモリ領域に格納することを指示するステップと、
   前記アプリケーションプログラムが、前記プロトコルスタックに対して、前記チェックサム値及び前記第１のメモリ領域を指定して送信指示するステップと、
   前記プロトコルスタックが、前記チェックサム値を用いて前記第１のメモリ領域に格納されているデータを通信に供させるためのプロトコルヘッダを生成し、第２のメモリ領域に前記プロトコルヘッダを格納するステップと、
   前記プロトコルスタックが、前記通信インタフェースに対して、前記第２のメモリ領域及び前記第１のメモリ領域それぞれに格納されているデータを一連のデータとして送信することを指示するステップと、
   前記プロトコルスタックが、前記アプリケーションプログラムに対して、送信完了したことを知らせるステップとを有することを特徴とするストリームデータ通信方法。
2. アプリケーションプログラムとプロトコルスタックとで構成されるプログラムがプロセッサで処理されることによって動作し、ストリームインタフェースから入力されるストリームデータを、前記プロセッサの外部である前記ストリームインタフェースの内部に設けられチェックサムの計算を行うチェックサム計算モジュールを用いて通信インタフェースから送信するストリームデータ通信装置のストリームデータ通信方法であって、
   前記アプリケーションプログラムが、前記ストリームインタフェースに対して、前記ストリームデータを第１のメモリ領域に格納することを指示するステップと、
   前記アプリケーションプログラムが、前記プロトコルスタックに対して、前記第１のメモリ領域を指定して送信指示するステップと、
   前記プロトコルスタックが、前記プロセッサの外部である前記ストリームインタフェースの内部に設けられた前記チェックサム計算モジュールに対して、前記第１のメモリ領域に格納されているデータのチェックサム値を計算することを指示するステップと、
   前記プロトコルスタックが、前記チェックサム値を用いて前記第１のメモリ領域に格納されているデータを通信に供させるためのプロトコルヘッダを生成し、第２のメモリ領域に前記プロトコルヘッダを格納するステップと、
   前記プロトコルスタックが、前記通信インタフェースに対して、前記第２のメモリ領域及び前記第１のメモリ領域それぞれに格納されているデータを一連のデータとして送信することを指示するステップと、
   前記プロトコルスタックが、前記アプリケーションプログラムに対して、送信完了したことを知らせるステップとを有することを特徴とするストリームデータ通信方法。
3. チェックサムの計算を行うチェックサム計算モジュールを有し、ストリームデータが入力されるストリームインタフェースと、
   前記ストリームデータを送信する通信インタフェースと、
   アプリケーションプログラムとプロトコルスタックとで構成されるプログラムが記憶されるメモリと、
   前記プログラムを処理するプロセッサとを備え、
   前記チェックサム計算モジュールは、前記プロセッサの外部である前記ストリームインタフェースの内部に設けられ、
   前記プロセッサは、
   前記アプリケーションプログラムにより、前記ストリームインタフェースに対して、前記ストリームデータのチェックサム値を前記プロセッサの外部である前記ストリームインタフェースの内部に設けられた前記チェックサム計算モジュールで計算しつつ前記ストリームデータを前記メモリの第１のメモリ領域に格納することを指示し、
   前記アプリケーションプログラムにより、前記プロトコルスタックに対して、前記チェックサム値及び前記第１のメモリ領域を指定して送信指示し、
   前記プロトコルスタックにより、前記チェックサム値を用いて前記第１のメモリ領域に格納されているデータを通信に供させるためのプロトコルヘッダを生成し、前記メモリの第２のメモリ領域に前記プロトコルヘッダを格納し、
   前記プロトコルスタックにより、前記通信インタフェースに対して、前記第２のメモリ領域及び前記第１のメモリ領域それぞれに格納されているデータを一連のデータとして送信することを指示し、
   前記プロトコルスタックにより、前記アプリケーションプログラムに対して、送信完了したことを知らせることを特徴とするストリームデータ通信装置。
4. ストリームデータが入力されるストリームインタフェースと、
   前記ストリームデータを送信する通信インタフェースと、
   チェックサムの計算を行うチェックサム計算モジュールと、
   アプリケーションプログラムとプロトコルスタックとで構成されるプログラムが記憶されるメモリと、
   前記プログラムを処理するプロセッサとを備え、
   前記チェックサム計算モジュールは、前記プロセッサの外部である前記ストリームインタフェースの内部に設けられ、
   前記プロセッサは、
   前記アプリケーションプログラムにより、前記ストリームインタフェースに対して、前記ストリームデータを前記メモリの第１のメモリ領域に格納することを指示し、
   前記アプリケーションプログラムにより、前記プロトコルスタックに対して、前記第１のメモリ領域を指定しつつ送信指示し、
   前記プロトコルスタックにより、前記プロセッサの外部である前記ストリームインタフェースの内部に設けられた前記チェックサム計算モジュールに対して、前記第１のメモリ領域に格納されているデータのチェックサム値を計算することを指示し、
   前記プロトコルスタックにより、前記チェックサム値を用いて前記第１のメモリ領域に格納されているデータを通信に供させるためのプロトコルヘッダを生成し、前記メモリの第２のメモリ領域に前記プロトコルヘッダを格納し、
   前記プロトコルスタックにより、前記通信インタフェースに対して、前記第２のメモリ領域及び前記第１のメモリ領域それぞれに格納されているデータを一連のデータとして送信することを指示し、
   前記プロトコルスタックにより、前記アプリケーションプログラムに対して、送信完了したことを知らせることを特徴とするストリームデータ通信装置。

Images