JP6019586B2

JP6019586B2 - ネットワーク通信装置

Info

Publication number: JP6019586B2
Application number: JP2012002385A
Authority: JP
Inventors: 大介阪井; 水梨　亮介; 亮介水梨
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2012-01-10
Filing date: 2012-01-10
Publication date: 2016-11-02
Anticipated expiration: 2032-01-10
Also published as: US20130179531A1; CN103200054B; CN103200054A; JP2013143641A

Description

本発明は、ネットワーク通信装置に関する。

特定の機能を実現するために家電製品や機械等に組み込まれるコンピュータシステム（以下、組み込みシステムと表記）では、省エネ要件を達成するために限定されたリソースしか使用できない。
ここで、リソースとは、何らかのソフトウェアやハードウェアを動作させるのに必要なメモリ容量やCPU(Central Processing Unit)などの処理速度、ハードディスクの容量を意味する。
ところで、組み込みシステムも多機能化してきており、ネットワークで複数の種類のデータを扱い、かつ、性能とリアルタイム性とが同時に求められるようになってきている。ネットワーク通信部とアプリケーション部とを構成上分離し、ネットワーク通信部を共通化することでリソース削減する技術は既に知られている（例えば、特許文献１参照。）。

特許文献１に記載の発明は、Ｗｅｂサービスを提供するアプリケーションの開発及び追加を容易とする画像形成処理装置を提供することを目的とするものである。具体的には、メソッドに従った所定の処理を行う複数のメソッド処理手段と、処理要求に応じて、処理要求で指定されるメソッドに対応するメソッド処理手段に該処理要求を振り分けることによってＷｅｂサービスを実行するＷｅｂサービス実行手段を有するように構成される。

しかし、通信部を共通化するだけでは、ネットワークを使い送受信する異なった種類のデータ毎に最適なリソースを割り当てて転送制御することができない。そのため、複数の種類のデータを同様に扱うと限定されたリソースを無駄に使用することになり、転送速度やリアルタイム性が必要なデータに対して十分な性能が出せないという問題があった。

そこで、本発明の目的は、組み込みシステムにおけるネットワーク通信性能とリアルタイム性を向上させたネットワーク通信装置を提供することにある。

本発明に係るネットワーク通信装置は、ネットワークでデータを送受信するための通信部と、前記通信部で受信したデータをアプリケーションへ転送するためのバッファと、送受信するデータを制御部分とコンテンツ部分とに分けて前記制御部分を解析する解析手段と、前記送受信するデータに基づいて使用リソースと転送制御方式とを決めるためのルールを記憶した記憶手段と、前記送受信するデータの制御部分を解析し、前記ルールを適用した結果から、前記アプリケーションへコンテンツデータを転送する制御手段とを備え、前記制御手段は、前記アプリケーションへ前記コンテンツデータを転送する前に、制御部分を転送することを特徴とする。

本発明によれば、組み込みシステムにおけるネットワーク通信性能とリアルタイム性を向上させたネットワーク通信装置の提供を実現することができる。

本発明に係るネットワーク通信装置の一実施の形態を示す概念図である。図１に示したネットワーク通信装置の説明図である。図２に示した画像処理装置の動作を説明するためのシーケンス図である。本発明に係るネットワーク通信装置のモジュール、タスク構成図の一例である。ＴＲＡＮＳモジュール２０３の内部構造を示す図である。ネットワーク通信装置の動作を説明するためのフローチャートの一例である。図１に示したネットワーク通信装置の動作を説明するためのフローチャートの一例の一部である。図７に示したフローチャートの続きである（ａ）は、平文通信における、ペイロード部分のメモリコピーの送信時の説明図であり、（ｂ）は、ペイロード部分のメモリコピーの受信時の説明図である。（ａ）は、暗号通信における送信時の説明図であり、（ｂ）は、暗号通信の受信時の説明図である。（ａ）は、平文通信における送信時の説明図であり、（ｂ）は、受信時の説明図である。（ａ）は、暗号通信における送信時の説明図であり、（ｂ）は受信時の説明図である。

本発明の実施の形態について図面を参照して説明する。
図１は、本発明に係るネットワーク通信装置の一実施の形態を示す概念図である。
ネットワーク通信装置としてのプロジェクタ装置１は、ネットワークにＬＡＮ(Local Area Network)で接続された通信部２と、通信部２にＵＳＢ(Universal Serial Bus)で接続されたアプリケーション部３と、を有する。

プロジェクタ装置１は、通信部２で受信したデータの一部である制御部だけを解析し「コンテンツデータの特徴」を認識することで、表１に基づき「使用リソースと転送制御方式」を決定する。

本発明に係るネットワーク通信装置のポイントとなる使用リソースは以下のとおりである。
ＳＲＡＭＤＡＴＡは通信部の汎用処理で使うメモリである。
ＳＲＡＭＴＯＥ、ＳＲＡＭＬＡＮは、ＬＡＮインターフェースでデータを送受信するために使うメモリである。
ＳＲＡＭＷＨＩＯはアプリケーション部へデータ転送するときに使うメモリである。ここではこのメモリを論理的に分割し、サイズ小(２ＫＢ)とサイズ大(１６ＫＢ)としている。

表１は、コンテンツデータの特徴、使用リソースと転送制御方式とが記載されている。
コンテンツデータの特徴としては、操作対象、操作方法、ＭＩＭＥタイプ、及び操作対象が存在するサブシステム名が挙げられる。使用リソースと転送制御方式としては、データ転送時に制御情報を含めるか否か、使用するバッファ、転送単位、及びデータフローのパターンが挙げられる。
表１の「操作対象」の「/service/projection」、「/state」、「property」はＵＲＬ(Uniform Resource Locator)を示す。
また、表１の静止画はＪＰＥＧ画像を意味し、ＰＣ画面は動画を意味する。
表１のデータの内容の「投影ジョブ状態取得」とは、プロジェクタの投影ジョブの状態を取得するためのコマンドである。プロジェクタの管理機能にリモートから投影ジョブの状態を取得する機能がある。具体的には、投影ジョブが開始しているか、割り込み可能かという情報が取得できる。

表１のデータの内容の「機器状態取得」とは、プロジェクタの機器状態を取得するためのコマンドである。プロジェクタの管理機能にリモートから機器状態を取得する機能がある。具体的には、電源の状態、入力信号の状態、ＡＶ(Audio Visual)ミュートの状態が取得できる。

表１のデータの内容の「機器情報取得」とは、プロジェクタの機器情報を取得するためのコマンドである。プロジェクタの管理機能にリモートから機器情報を取得する機能がある。具体的には、機器のスペックや設定値が取得できる。

表１の操作方法における「ＰＯＳＴ」、「ＰＵＴ」、「ＧＥＴ」とは、データの操作方法の一例である。本実施形態では、ＨＴＴＰのメソッドを対応づけている。
表１のＭＩＭＥタイプとは、データの中身を示す情報である。本実施形態では、データの中身を示す情報とＭＩＭＥタイプとを対応づけている。

表１の「使用するバッファのサイズ」の大小は、あくまで一例であり、もっと細かく分けても良い。ポイントは、データの内容によって適切なバッファを使用するという点である。たとえば、２，３など投影データを扱う場合は１６ＫＢ、１，４，５，６などコマンドは２ＫＢのバッファを使用することで並行に行える処理を多くする。全部１６ＫＢのバッファを使用すると、メモリの制約で並行に行える処理が少なくなる。

データの内容としては、投影ジョブ生成、投影データ(静止画、PC画面)、投影ジョブ更新、投影ジョブ状態取得、投影ジョブ削除、機器状態取得、機器状態変更、機器情報取得、機器情報変更が挙げられる。尚、データフローのパターンについては後述する。

＜通信部及びネットワークシステム＞

図２は、図１に示したネットワーク通信装置の説明図である。
図２に示したネットワーク通信装置は、ネットワークボード１００と、メイン投影部１０９と、を備えた装置である。
図２に示す画像処理装置は、ネットワークボード１００と、メイン投影部１０９とを有する。
ネットワークボード１００は、通信部２と、ネットワークシステム３とを有する。
通信部２は、プロトコル制御やパケット制御を行うハードウェアであり、一部、受信したデータの解析を行う。ＵＳＢデバイスとして動作し、ネットワークシステム３にデータを転送する。
ネットワークシステム３は、通信モジュール１０４、コンテンツモジュール１０６、ＵＳＢホスト１０３、グラフィックドライバ１０８を動作させるハードウェアである。

通信モジュール１０４は、受信したデータの詳細を解析し、データの内容に応じたアプリケーションソフトウェア（以下、アプリと表記）を動作させるソフトウェアである。通信モジュール１０４は、アプリの動作の際、必要に応じて他のモジュールを利用する。
コンテンツモジュール１０６は、投影用バッファ１０７に書き込まれた画像データ（コンテンツのデータ）を、グラフィックドライバ１０８を利用して出力するソフトウェアである。
ＵＳＢ(Universal Serial Bus)ホスト（図ではＵＳＢＨｏｓｔと表記）１０３は、ＵＳＢデバイスを制御するソフトウェアである。
グラフィックドライバ１０８は、グラフィックデバイスを制御するソフトウェアである。
メイン投影部１０９は、グラフィックデバイスであり、画像データを光の可視画像として映し出すデバイスである。

通信部２には、図には示されないパーソナルコンピュータ(Personal Computer：以下ＰＣと表記）２００が接続されている。

図３は、図２に示した画像処理装置の動作を説明するためのシーケンス図である。
ＰＣ２００から通信部２にＨＴＴＰ(Hyper Text Transfer Protocol)ヘッダとＨＴＴＰボディ（静止画、動画）とを含むデータ（受信データ）が送られると（Ｓ２０１）、通信部２は、ネットワークシステム３のＵＳＢホスト１０３に受信データ、ペイロード（デバイスデータ）、及びＮＵＬＬを送る（Ｓ２０２、Ｓ２０３、Ｓ２０４）。
ＵＳＢホスト１０３は、ネットワークシステム３の通信モジュール１０４に着信通知を行う（Ｓ２０５）。ネットワークシステム３の通信モジュール１０４は通信領域でバッファを用意し、その旨をＵＳＢホスト１０３に通知する（Ｓ２０６）。ＵＳＢホスト１０３は、用意されたバッファ１０５、１０７にデバイスデータのヘッダやボディ等を書き込み、通信モジュール１０４に書き込み通知を行う（Ｓ２０７）。

＜モジュール及びタスク構成＞
図４は、本発明に係るネットワーク通信装置のモジュール、タスク構成図の一例である。
ネットワーク通信装置は、機器モジュール２０２、通信モジュール１０４、ＵＳＥＲ通信モジュール２０４、ＳｏｃｋｅｔＩ/Ｆモジュール２０５、暗号・証明書モジュール２０６、通信ドライバ２０７、及び暗号エンジン２０８、を備える。

ここで、タスクとは、ＯＳから見た処理の実行単位であり、通常はスレッドが実行単位となるが、ＯＳによってはプロセス(複数のスレッドを含むプログラム全体)を一つの実行単位として見る場合もある。

＜モジュール間の依存関係＞
これらのモジュールのうち、機器モジュール２０２はＵＳＥＲ通信モジュール２０４に依存され、暗号・証明書モジュール２０６とは互いに依存しあっている。

通信モジュール１０４は、機器モジュール２０２と互いに依存しあい、ＳｏｃｋｅｔＩ／Ｆモジュール２０５、ＵＳＥＲ通信モジュール２０４、暗号・証明書モジュール２０６に依存されている。
ＳｏｃｋｅｔＩ／Ｆ２０５は、通信ドライバ２０７に依存されている。

暗号・証明書モジュール２０６は、暗号エンジン２０８に依存されている。

次に各モジュールの責務について表２及び表３を参照して述べる。

表４は通信部とアプリケーション部のデータ転送における「使用リソースと転送制御方式」を決めるためにルール表である。表４中のコンテンツデータの特徴は、ＨＴＰＰなどのアプリケーションプロトコルのヘッダ情報（制御情報）から得ることができる。たとえば、操作対象はＨＴＴＰヘッダのＵＲＬに含まれる。操作方法はＨＴＴＰヘッダのリクエストラインに含まれる。ＭＩＭＥタイプはＨＴＴＰヘッダの属性に含まれる。操作対象が存在するサブシステム名に登録する情報はシステム構成によって決め、データ転送するときに使うメモリを転送先の場所毎に決めるための情報として用いる。

起動モジュール２１０は、起動時にハードウェア及びソフトウェアを初期化し、各タスクを起動する機能を有する。

通信領域モジュール２０３は、ネットワークシステムに対してネットワーク通信機能を提供するため、表２に示した機能(1)〜(3)を有し、ネットワークシステムの通常動作時及び省エネ状態時に、ネットワークシステムの代わりにネットワークサブシステムが自律的に実行するネットワーク通信機能を有する。また、通信領域モジュール２０３は、ＳＳＬプロトコル／ＩＥＥＥ８０２．１ｘプロトコル機能を有し、ＳＲＡＭＤＡＴＡ、ＳＲＡＭＳＥＣ上のバッファを管理する機能を有し、プロトコルで行うユーザー認証機能を有する。

サプリカントモジュールは、レイヤー２レベルの接続(セキュリティを含む)を行う機能を有する。

機器モジュール２０２は、ネットワークシステムから［ＵＳＥＲ］経由で受け取った機器固有情報をＦＬＡＳＨメモリに保存し、ネットワークシステムまたは［ＴＲＡＮＳ］の要求により機器固有情報を提供する機能を有する。機器モジュール２０２は、ネットワークシステムから［ＵＳＥＲ］経由で受け取ったファームウェア更新データをＦＬＡＳＨメモリへ書き込む機能を有する。機器モジュール２０２は、通信部の状態制御を行う機能を有する。

ＵＳＥＲ通信モジュール２０４は、ＵＳＢ経由での［ネットワークシステム］との通信制御のため、(1)、(2)の機能を有し、ＳＲＡＭＷＨＩＯ上のバッファを管理する機能を有する。

ＳｏｃｋｅｔＩ／Ｆモジュール２０５は、［ＴＲＡＮＳ］に対してネットワーク機能を提供するため、(1)、(2)の機能を有し、ネットワーク通信のためＴｏＥを制御する機能を有し、ＭＡＣを制御する機能を有する。

図５は、ＴＲＡＮＳモジュール２０３の内部構造を示す図である。
同図はデータ転送のみを示す。
同図に示すＴＲＡＮＳモジュール２０３は、アプリケーション層の手順３０１、リソース情報一覧３０２、アプリケーソン層のパケット３０３、アプリケーション層のペイロード３０４、及びアプリケーション層のヘッダ３０５を有する。

アプリケーション層の手順３０１としては、アプリケーション層のパケット送受信の全体の進捗を管理し、接続、切断を行う。

アプリケーション層のパケット３０３としては、アプリケーション層のパケットがヘッダとペイロードから構成されることを知っている。上位層から受け取ったデータからアプリケーション層のパケットを作成し、次の処理を行う下位層に渡す。下位層から受け取ったデータからアプリケーション層のパケットを解析し、次の処理を行う上位層に渡す。チャンクのエンコード／デコードを行う。

アプリケーション層のパケット３０３が利用するリソース情報一覧３０２は、使用リソースとデータ転送方式の決定ルール表である。

アプリケーション層のペイロードは、アプリケーション層のペイロードの構造を知っている。

アプリケーション層のヘッダは、アプリケーション層のヘッダの構造を知っている。

図６は、ネットワーク通信装置の動作を説明するためのフローチャートの一例である。
転送プロトコルがＴＣＰかＵＤかを判断する。(本実施形態ではアプリケーション部でＵＤＰプロトコルを使う機能がないため別フローとしたが、ＴＣＰプロトコルと同じフローとすることもできる)。
プロトコルのヘッダだけ先にＳＲＡＭＤＡＴＡへコピーし解析する。ヘッダを解析した結果からルール表(表１〜表３)に基づいて使用するリソースと転送制御方式とを決める。

次にデータを処理すべき転送先が別サブシステム(アプリケーション部)か否かを判断する。転送先がアプリケーション部である場合は、コンテンツデータの特徴に応じて使用するバッファサイズを決めてデータ転送を行う。たとえば、データの中身がジョブ生成コマンドなどのときはサイズ小、投影する画像データのときはサイズ大などとする。一回のデータ転送で処理しきれないサイズの場合は、同じ種類のバッファを使いアプリケーションへのデータ転送を繰り返すことですべてのデータを処理する。

以下、図６に示したフローチャートについて詳述する。
動作の主体は、ネットワークシステム３である。
ネットワークシステム３は、プロトコルがＴＣＰか否かを判断し（Ｓ３０１）、プロトコルがＴＣＰであると判断した場合（Ｓ３０１／Ｙｅｓ）、ＳＲＡＭＤＡＴＡにヘッダデータを受信してステップＳ３０３へ進む。ＯＭＰ３は、プロトコルがＴＣＰではないと判断した場合（Ｓ３０１／Ｎｏ）、ＳＲＡＭＴｏＥバッファポインタをアプリケーションへ渡して処理した後終了する（Ｓ３１０）。

ネットワークシステム３は、ステップＳ３０３で、ヘッダを継続し、「コンテンツデータの特徴」を取り出し、「使用リソースと転送制御装置」を決定する（Ｓ３０４）。
ネットワークシステム３は、転送先がネットワークシステム３か否かを判断し（Ｓ３０５）、転送先がネットワークシステム３であると判断した場合（Ｓ３０５／Ｙｅｓ）、データサイズが所定値より大きいか否かを判断する（Ｓ３０６）。
ネットワークシステム３は、転送先がネットワークシステム３ではないと判断した場合（Ｓ３０５／Ｎｏ）、ＳＲＡＭＤＡＴＡを使いアプリケーションへデータ転送して終了する（Ｓ３０８）。
ネットワークシステム３は、データサイズが所定値より大きいと判断した場合（Ｓ３０６／Ｙｅｓ）、ＳＲＡＭＷＨＩＯ（サイズ大）を使いアプリケーションへデータを転送して終了する（Ｓ３０７）。
ネットワークシステム３は、データサイズが所定値より大きくないと判断した場合（Ｓ３０６／Ｎｏ）、ＳＲＡＭＷＨＩＯ（サイズ小）を使いアプリケーションへデータ転送して終了する（Ｓ３０９）。

図７は、図１に示したネットワーク通信装置の動作を説明するためのフローチャートの一例の一部であり、図８は、図７に示したフローチャートの残りである。
動作の主体は、ネットワークシステム３である。
図７において、ネットワークシステム３がエントリー（図ではentry）アクションを開始すると（Ｓ１０１）、ヘッダが有るか否かを判断し（Ｓ１０２）、ヘッダが有ると判断した場合、ソケットからデータを読み込みステップＳ１０４へ進む（図ではIsocketInterface:reaySocket：Ｓ１０８）。
ネットワークシステム３がヘッダが無いと判断した場合、状態/DECONPOSING HEADERパケット作成結果/E PACKET RESULT COMPLETE エラー理由/E PACKET ERROR REASON NO ERRORし、丸２へ進む（Ｓ１１５）。

ネットワークシステム３は、エラーが有ると判断した場合（Ｓ１０４）、状態/END パケット解析結果/E PACKET RELULT COMPLETE エラー理由/E PACKET ERROR REASON SOCKET E PACKET ERROR REASON TIMEOUTとなる（Ｓ１１４）。
ネットワークシステム３は、エラーが無いと判断した場合（Ｓ１０４）、ヘッダを解析し（図ではAAppLayerHeadcredecompos：Ｓ１０５）、ヘッダ解析が完了したか否か判断し（Ｓ１０６）、解析完了（失敗）した場合（Ｓ１０６）にはステップＳ１１４に進み、解析未完了の場合にはステップＳ１０８に戻る。
ネットワークシステム３は、ヘッダ解析が完了（成功）した場合（Ｓ１０６）には、サーバかクライアントかを判断し（Ｓ１０７）、クライアントの場合にはステップＳ１１５に進み、サーバの場合には、リソース情報を検索する（Resource Info Table:get Resource Info :Ｓ１０８）。
ネットワークシステム３は、リソース情報が有るか否かを判断し（Ｓ１０９）、リソース情報が無いと判断した場合（Ｓ１０９）、ステップＳ１１４に進み、リソース情報が有ると判断した場合（Ｓ１０９）、転送先がネットワークシステム３か否か判断する（Ｓ１１０）。
ネットワークシステム３は、転送先が通信部であると判断した場合はステップＳ１１５に進み、転送先がネットワークシステムであると判断した場合（Ｓ１１０）、ネットワークシステムへの転送可否をチェックし（INFO CanExecute：Ｓ１１１）、転送可能か否か判断する（Ｓ１１２）。
ネットワークシステム３は、転送不可であると判断した場合（Ｓ１１２）、状態/END パケット解析結果/END パケット解析結果/E PACKET ERROR REASON NO ERROR（Ｓ１１３）となり、転送可能であると判断すると転送する。

図８において、ステップＳ２０１〜Ｓ２０８、Ｓ２１０〜Ｓ２１４、Ｓ２１６〜Ｓ２２０、Ｓ２２３は、コンテンツバッファを使用する場合のみ実行する。

図８において、エントリアクション（図ではentryアクション）が開始すると（Ｓ２０１）、ネットワークシステム３は、ペイロードが有るか否かを判断し、ペイロードが無いと判断した場合（Ｓ２０２）、ステップＳ２１４にて、状態/END パケット解析結果/E PACKETE RESULT COMPLETE エラー理由 /E PACETE ERROR REASON NO ERROR となる。

ネットワークシステム３は、ペイロードが有ると判断した場合（Ｓ２０２）、転送先がネットワークシステム３か否か判断し（Ｓ２０４）、転送先がネットワークシステムであると判断した場合（Ｓ２０４）、コンテンツバッファの排他を行う（twai sxm(SEM TRANS CNTLT EX)：Ｓ２０５）。
このとき、
１．サーバの場合
排他が獲得できるまで、例えば１秒待つ。１秒以内に排他が獲得できなかった場合、パケット内部にエラー（４０４）として、ペイロード完了とする。
２．クライアントの場合
＜ロケーションフリー（ロケフリとも言う）の場合＞
排他が獲得できるまで、無制限に待つ。
＜@Remoteの場合＞
排他が獲得できるまで、例えば１秒待つ。１秒以内に排他が獲得できなかった場合、受信データを読み捨てる。その後、排他が獲得できるまで、無制限に待ち、排他できた段階でＥＯＬ＝１，データサイズ＝０の応答を返す。

ネットワークシステム３は、ペイロードの転送先が通信部であると判断した場合（Ｓ２０４）、ＳＡＭＤＡＴＡを読み出し（Ｓ２１５）、ソケットからデータを読み込む（Ｓ２０７）。

ネットワークシステム３は、ＳＲＡＭＷＨＩＯのバッファを取得し（Ｓ２０６）、ステップＳ０７に進んで前述したソケットからデータを読み込み、エラーが有るか否かを判断する（Ｓ２０８）。
このとき、
＜コンテンツバッファを使用する場合＞
ソケットからデータを読み込む前にヘッダのみを先にネットワークシステム３に送信する。
＜ペイロードサイズが０の場合＞
ソケットからデータを読み込まずにヘッダのみをネットワークシステム３に送信してペイロード解析が完了する。

ネットワークシステム３は、エラーが有ると判断した場合には（Ｓ２０８）、ネットワークシステム３へネットワーク受信データ共有の要求送信を行い（Ｓ２１６）、ステップＳ２１７へ進む。
こんとき、一度もUSER DhBulStar DhcomBulStart dhComBulStartを行っていなくても、USER GelDhBul/USER GetComDhBufで確保したバッファを開放するため、必ずEOF/Iのネットワーク受信データ共有の要求を送信する。

ネットワークシステム３は、ステップＳ２１７において、コンテンツバッファの排他解除を行い（SIG SEM(SEM TRANS CNTNT EX)）、状態／ＥＮＤとなる（パケット解析結果/E PACKET RESULT COMPLETE エラー理由/E PACKET ERROR RESSON SOCKET E PACKET ERROR REASON TIMEOUT：Ｓ２１８）。

ネットワークシステム３は、エラーが無いと判断した場合には（Ｓ２０８）、ペイロードを解放し（AppLayerPeyload::deconpose：Ｓ２０９）、ペイロード解析が完了したか否かを判断し（Ｓ２１０）、解析未完了であると判断した場合（Ｓ２１０）、転送先がネットワークシステム３か否かを判断する（Ｓ２２３）。

ネットワークシステム３は、転送先がネットワークシステム３ではなく通信部であると判断した場合（Ｓ２２３）にはステップＳ２０７に戻り、転送先がネットワークシステム３であると判断した場合（Ｓ２２３）、ＳＲＡＭＷＨＩＯのバッファフルか否かを判断する（Ｓ２２０）。
ネットワークシステム３は、ＳＲＡＭＷＨＩＯのバッファフルではないと判断した場合はステップＳ２０７に戻り、ＳＲＡＭＷＨＩＯのバッファフルであると判断した場合はネットワークシステム３へネットワーク受信データ共有の要求送信を行い（USER DhBusStart/USER DhComBufStrat：Ｓ２１９）、ステップＳ２０６に戻る。

ネットワークシステム３は、ステップＳ２１０にてペイロード解析が完了したと判断した場合、転送先がネットワークシステム３であるか否かを判断し（Ｓ２１１）、転送先がネットワークシステム３であると判断した場合（Ｓ２１１）、ネットワークシステム３へネットワーク受信データ共有の要求送信を行う（USER DhBufStart/USER DhComBufstart：Ｓ２１２）。
ネットワークシステム３は、コンテンツバッファの排他解除を行う（sig sem(SEM TRANS CNTNT EX)：Ｓ２１３）、状態／ＥＮＤとなり、パケット解析結果/E PACET RESULT COMPLETE エラー理由/E PACKET ERROR REASON NO ERROR：Ｓ２１４）。

ネットワークシステム３は、ステップＳ２１１にて転送先が通信部の場合にはステップＳ２１４に進む。
ネットワークシステム３は、ステップＳ２０２にてペイロードが無いと判断した場合、ステップＳ２１４に進む。

＜データフローパターン＞
データ転送には、以下の３つのメモリコピーのパターンがある。以下、それぞれのパターンについて、メモリコピーの設計を示す。
(ＰＡ)ネットワークシステムへの転送が必要なＴＣＰのデータ転送
例）ＨＴＴＰ(Ｓ)サーバ、ＨＴＴＰ(Ｓ)クライアント
〔平文通信の場合〕
図９（ａ）は、平文通信における、ペイロード部分のメモリコピーの送信時の説明図であり、図９（ｂ）は、ペイロード部分のメモリコピーの受信時の説明図である。
ＴＲＡＮＳモジュールは、図４（ａ）、（ｂ）に示すようにヘッダ部分のみＳＲＡＭＷＨＩＯからＳＲＡＭＤＡＴＡにコピーし、ＳＯＣＫモジュールを使用して、ＳＲＡＭＤＡＴＡにコピーしたヘッダ部分と、ＳＲＡＭＷＨＩＯに残っているペイロード部分をＬＲＡＭＬＡＮにコピーする。ヘッダ部分をＳＲＡＭＤＡＴＡにコピーするのは、通信部側でヘッダを追加する処理が必要なためである。ヘッダ部分のメモリコピーは２回、ペイロード部分のメモリコピーは１回となる。

〔暗号通信の場合〕
図１０（ａ）は、暗号通信における送信時の説明図であり、図１０（ｂ）は、暗号通信の受信時の説明図である。
ＴＲＡＮＳモジュールは、図１０（ａ）、（ｂ）に示すように、ヘッダ部分とペイロード部分との両方を、暗号変換の入力データとしてＳＲＡＭＳＥＣ(ＩＮＤＡＴＡ)にコピーする。暗号変換後、ＳＯＣＫモジュールを使用して、暗号変換の出力データとなるＳＲＡＭＳＥＣ(ＯＵＴＤＡＴＡ)をＳＲＡＭＬＡＮにコピーする。メモリコピーの回数は３回となる。

(ＰＢ) 通信部内で閉じるＴＣＰのデータ転送
図１１（ａ）は、平文通信における送信時の説明図であり、図１１（ｂ）は、受信時の説明図である。
〔平文通信の場合〕
ＴＲＡＮＳモジュールは、図１１（ａ）、（ｂ）に示すように、送信するデータおよび受信するデータをＳＲＡＭＤＡＴＡに読み書きし、ＳＯＣＫモジュールを使用してＳＲＡＭＤＡＴＡからＳＲＡＭＬＡＮに１回コピーする。ＳＯＣＫモジュールでＴＣＰのリングバッファの操作を隠ぺいするため、メモリコピーが１回必要になる。

〔暗号通信の場合〕
図１２（ａ）は、暗号通信における送信時の説明図であり、図１２（ｂ）は受信時の説明図である。
ＴＲＡＮＳモジュールは、図１２（ａ）、（ｂ）に示すように、送信するデータおよび受信するデータを暗号変換の入力データとしてＳＲＡＭＳＥＣ(ＩＮＤＡＴＡ)に読み書きし、ＳＯＣＫモジュールを使用して、暗号変換の出力データとなるＳＲＡＭＳＥＣ(ＯＵＴＤＡＴＡ)をＳＲＡＭＬＡＮにコピーする。メモリコピーの回数は２回となる。

(ＰＣ) 通信部内で閉じるＵＤＰのデータ転送
ＴＲＡＮＳモジュールは、送信するデータおよび受信するデータをＳＲＡＭＴｏＥに直接読み書きし、メモリコピーを発生させない。

＜作用効果＞
以上において、本実施形態によれば、装置内で扱う転送データの「制御部分」を解析することで，データの「コンテンツ部分」の特徴を認識する。その特徴に最も適したリソースの割り当てと転送制御をルールに基づいて決定する制御を行うため、ネットワーク機能を搭載した省エネ組み込みシステムで、ネットワーク通信性能とリアルタイム性を高めることができる。

同じ特徴を持つデータを複数同時に処理できる。
最も性能を出したい機能に関するデータ転送に優先的にバッファを割り当てられる。リアルタイム性を要求するデータ転送で、バッファサイズがフルになる前にアプリケーションへデータを渡すことができる。
プロトコルによって決められた最大データサイズに合わせてバッファサイズを確保できるため、リソースの使用効率を上げられる⇒無駄なデータ転送を排除でき、リソース使用効率を上げられる⇒アプリケーションの変更に柔軟に対応できる。

すなわち、本実施形態によれば、装置内で扱う転送データの内容によって、使用するリソースとデータ転送制御方法をルールに基づいて決定することで、組み込みシステムにおけるネットワーク通信性能とリアルタイム性を向上させたネットワーク通信装置の提供を実現することができる。

なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。

１プロジェクタ装置
２通信部
３ネットワークシステム
１００ネットワークオード
１０３ＵＳＢＨｏｓｔ
１０４通信モジュール
１０５通信用バッファ
１０６コンテンツモジュール
１０７投影用バッファ
１０８グラフィックドライバ
１０９メイン投影部
２００ＰＣ

特開２００４−５５０３号公報

Claims

ネットワークでデータを送受信するための通信部と、
前記通信部で受信したデータをアプリケーションへ転送するためのバッファと、
送受信するデータを制御部分とコンテンツ部分とに分けて前記制御部分を解析する解析手段と、
前記送受信するデータに基づいて使用リソースと転送制御方式とを決めるためのルールを記憶した記憶手段と、
前記送受信するデータの制御部分を解析し、前記ルールを適用した結果から、前記アプリケーションへコンテンツデータを転送する制御手段とを備え、
前記制御手段は、前記アプリケーションへ前記コンテンツデータを転送する前に、制御部分を転送することを特徴とするネットワーク通信装置。
前記制御手段は、前記コンテンツデータの特徴に対して決まったバッファをさらに複数に分割して使用するようにしたことを特徴とする請求項１に記載のネットワーク通信装置。
前記制御手段は、前記送受信するデータの制御部分を解析し、前記ルールを適用した結果、使用できるバッファが複数あった場合に前記バッファを占有するようにしたことを特徴とする請求項１に記載のネットワーク通信装置。
前記制御手段は、前記アプリケーションへのデータの転送単位を、通信プロトコルの転送単位と関連付けるようにしたことを特徴とする請求項１に記載のネットワーク通信装置。
前記制御手段は、前記コンテンツデータの特徴に加えプロトコル種別を確認して使用リソースと転送制御方式とを決めるようにしたことを特徴とする請求項１に記載のネットワーク通信装置。
前記制御手段は、前記アプリケーションへデータ転送する前に、前記アプリケーションが処理可能か否かを確認するようにしたことを特徴とする請求項１に記載のネットワーク通信装置。