JP2005064673A - プロトコル処理装置 - Google Patents

Abstract

【課題】 通信を行うホスト数が多い場合にも照合すべきアドレス数を増やす必要がないプロトコル処理装置を提供する。
【解決手段】 ＣＰＵ１は、プロトコル処理を行うプロトコル処理手段１３０と、アプリケーション処理を行うアプリケーション処理手段１４０とを備える。また、ＣＰＵ１内において、プロトコル処理手段１３０とイーサネットコントローラ４との間には受信処理許可判定手段１５０が介在し、受信処理許可判定手段１５０には計測手段１６０が接続される。受信処理許可判定手段１５０は、受信したイーサネットフレームをプロトコル処理手段１３０に渡すかどうかを判定する。アプリケーション処理手段１４０においてイーサネットフレームのプロトコル処理を許可する送信元ホストのイーサネットアドレスは、記憶装置２に予め登録されている。
【選択図】 図４

Description

本発明は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等の通信プロトコル（以下では単にプロトコルと呼ぶ）に関し、特に、その受信処理に要する処理量を低減することのできるプロトコル処理装置に関するものである。

近年、インターネットの普及により、ＴＣＰ／ＵＤＰ／ＩＰ等のインターネット関連のプロトコルについては、携帯情報端末等の組み込み機器への応用が増えてきている。一般に、組み込み機器では消費電力やコストに制限があるため、比較的に動作周波数と処理性能とが低いＣＰＵで使用される場合が多い。そのため、組み込み機器で通信を行う場合には、通信アプリケーション（以下では単にアプリケーションとも呼ぶ）のプログラムの動作を妨げないように、プロトコル処理に要するＣＰＵ負荷を低減することが必要である。

一般に、受信したパケットのプロトコル処理に要する処理量は、パケットの送信に要する処理量に比べて制御が困難である。これは、送信の場合は、自ホストが内蔵するアプリケーション・プログラムからの要求に基づき処理が行われるのに対し、受信の場合は、他ホストから受信するパケットの数に処理量が依存するからである。

受信パケットには、他ホストから自ホスト宛てに送信されたパケットだけではなく、ネットワーク上に流れるブロードキャストパケットのように、同一ネットワーク上の全てのホストに宛てて送信されたパケットも含まれる。ネットワーク上にはこのように様々なパケットが流れているため、ある期間に自ホスト宛てのパケット（特にブロードキャストパケット）が集中すると、受信パケットのプロトコル処理に要するＣＰＵ負荷が一時的に増加する。これにより、アプリケーション処理もしくはプロトコル処理に要する処理性能が不足しアプリケーションの動作を妨げる可能性がある。これは、特に、リアルタイム性の要求される音声や映像等のデータをやりとりする通信アプリケーション等においては、問題となる。例えば音声データの通信を行うＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アプリケーションにおいては、規定された期間内に完了できなくなるので、音声通信の品質が劣化してしまう場合がある。

上記の問題点を解決するために、ＣＰＵにおいて、パケットの受信処理を行うプロトコル処理手段と、受信処理を行われたパケットでアプリケーションを動作させるアプリケーション処理手段との間に、パケットを蓄積するためのバッファを設けることが考えられる。受信したパケットをこのバッファにある程度蓄積してからアプリケーション処理手段に渡すようにすることで、プロトコル処理に要するＣＰＵ負荷の変動の影響を低減することができる。しかし、バッファにパケットが蓄積されると蓄積された時間に応じて遅延が発生するので、リアルタイム性の要求される通信アプリケーションにおいては、この遅延が問題となる。例えば、上記のＶｏＩＰ等の音声データ通信をやりとりする場合には聴感上問題となる。

また上記の問題点を解決するために、ＣＰＵにおいて、優先度の低い通信アプリケーションを一時的に無効にして処理量を低減することも考えられる。しかし、例えば全ての通信アプリケーションがＵＤＰ上で動作する場合等には、受信したパケットがＶｏＩＰパケットであるかどうかを判定するためには、ＵＤＰ層以下のプロトコル処理、例えばイーサネット（登録商標：以下同様）等の物理層およびデータリンク層、ＩＰ層、ＵＤＰ層が必要となってしまう。そのため、アプリケーション処理に要する処理量は低減できるが、プロトコル処理に要する処理量は低減できないという問題点があった。

特許文献１には、これらの問題点を解決するために、受信処理を許可するホストのアドレスを予め内部に格納（登録）しておくプロトコル処理装置の例が示されている。このプロトコル処理装置においては、パケットを受信したときには、そのパケットの送信元アドレスと、予め登録されたホストのアドレスとを比較・照合して、一致した場合には通常のプロトコル処理を行い、一致しない場合には通常のプロトコル処理を行うことなくパケットを破棄することにより、プロトコル処理に要する処理量を低減している。

特開平５−２９２０８５号公報

特許文献１に示されるプロトコル処理装置においては、予め登録されていないホストからのパケットは破棄されてしまうので、通信を行う可能性のあるホストのアドレスを全て登録しておく必要がある。そのため、不特定のホストまたは比較的多数の特定のホストと通信を行うような場合には、照合すべきアドレス数が増えることによりプロトコル処理に要する処理量が増えてしまい、優先度の高いアプリケーションの動作が妨げられる可能性が高くなるという問題点があった。

本発明は、以上の問題点を解決するためになされたものであり、通信を行うホスト数が多い場合にも照合すべきアドレス数を増やす必要がないプロトコル処理装置を提供することを目的とする。

上記の課題を解決するために、請求項１に記載の発明に係るプロトコル処理装置は、ネットワークからパケットを受信するネットワークコントローラと、受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定する受信処理許可判定手段と、前記受信処理許可条件を満たすパケットに対してプロトコル処理を行うプロトコル処理手段と、プロトコル処理を行った前記受信処理条件を満たさないパケットの合計個数を計測する計測手段とを備え、前記プロトコル処理手段は、前記合計個数が所定の個数に達するまでは前記受信処理許可条件を満たさないパケットに対してもプロトコル処理を行う。

また、請求項２に記載の発明に係るプロトコル処理装置は、ネットワークからパケットを受信するネットワークコントローラと、受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定する受信処理許可判定手段と、前記受信処理許可条件を満たすパケットに対してプロトコル処理を行うプロトコル処理手段と、プロトコル処理を行った前記受信処理条件を満たさないパケットの合計データサイズを計測する計測手段とを備え、前記プロトコル処理手段は、前記合計データサイズが所定のデータサイズに達するまでは前記受信処理許可条件を満たさないパケットに対してもプロトコル処理を行う。

請求項１に記載の発明に係るプロトコル処理装置は、ネットワークからパケットを受信するネットワークコントローラと、受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定する受信処理許可判定手段と、前記受信処理許可条件を満たすパケットに対してプロトコル処理を行うプロトコル処理手段と、プロトコル処理を行った前記受信処理条件を満たさないパケットの合計個数を計測する計測手段とを備え、前記プロトコル処理手段は、前記合計個数が所定の個数に達するまでは前記受信処理許可条件を満たさないパケットに対してもプロトコル処理を行うので、通信を行うホスト数が多い場合にも照合すべきアドレス数を増やす必要がない。

また、請求項２に記載の発明に係るプロトコル処理装置は、ネットワークからパケットを受信するネットワークコントローラと、受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定する受信処理許可判定手段と、前記受信処理許可条件を満たすパケットに対してプロトコル処理を行うプロトコル処理手段と、プロトコル処理を行った前記受信処理条件を満たさないパケットの合計データサイズを計測する計測手段とを備え、前記プロトコル処理手段は、前記合計データサイズが所定のデータサイズに達するまでは前記受信処理許可条件を満たさないパケットに対してもプロトコル処理を行うので、請求項１に記載の発明に係るプロトコル処理装置の効果に加えて、プロトコル処理の負荷がパケットの個数よりもデータサイズにより大きく依存する場合には、実施の形態１よりも精度よくプロトコル処理における処理量を制御することができる。

＜実施の形態１＞
実施の形態１に係るプロトコル処理装置は、ネットワークから受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定し、受信処理許可条件を満たさないパケットに対しても、受信処理を行ったパケット（プロトコル処理を行ったパケット）の合計個数が所定の個数に達するまでは受信処理を行う（プロトコル処理を行う）ものである。以下では、図１に示されるような構成のＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）等からなるホストを例に説明する。また、以下の説明においては、ネットワークの例としてイーサネットを用い、パケットの例としてイーサネットフレーム（以下では単にフレームとも呼ぶ）を用いる。

図１において、ホスト１０は、ＣＰＵ１と、記憶装置２と、コネクタ３と、イーサネットコントローラ４と、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）５と、タッチパネル６とを備える。

ＣＰＵ１は、所定のプログラムに従い動作する。記憶装置２は、ＲＯＭやＲＡＭ等を備え、プログラムや処理途中の演算結果等を格納する。コネクタ３は、ＰＤＡとネットワーク（イーサネット）とを物理的に接続するためのものである。イーサネットコントローラ４は、ＬＳＩ等からなり、ネットワークとのインターフェースを行うためのものである（ネットワークコントローラ）。イーサネットコントローラ４は、パケットの送受信時には割り込み信号を発生させＣＰＵ４に通知する。ＬＣＤ５は、マン・マシン・インターフェース用の出力装置であり、タッチパネル６は、マン・マシン・インターフェース用の入力装置である。図１に示されるＰＤＡ内部において、各装置は、アドレスバス７とデータバス８とを用いて、アドレス信号とデータ信号とをそれぞれ入出力している。

図２は、本発明の実施の形態１に係るプロトコル処理方法およびプロトコル処理装置が用いられるネットワーク（イーサネット）の例を示した構成図である。

図２において、ホスト１０〜５０は、イーサネット１００を介して互いに接続されている。ホスト１０とホスト２０との間では、ＵＤＰプロトコルを用いて、リアルタイムに音声データの通信を行う通信アプリケーションＶｏＩＰを行っている場合の例が示されている。ここで、ホスト１０は、比較的に処理性能の低いＣＰＵにより、プロトコル処理とアプリケーション処理とを行っているＰＤＡ等の携帯情報端末である。また、リアルタイム性の要求される通信アプリケーションＶｏＩＰは、優先度が最も高いアプリケーションであるものとする。

ここで、図３，４を用いて、ホスト１０がイーサネット１００からパケットを受信した場合のプロトコル処理の例を説明する。図３は、イーサネットフレームの構成を示したものである。また図４は、ホスト１０のＣＰＵを動作させるプログラムの構成を示したものである。

図３に示すように、イーサネットフレームはイーサネットヘッダ部とイーサネットデータ部とから構成される。イーサネットデータ部はＩＰデータグラムを含み、ＩＰデータグラムはＩＰヘッダ部とＩＰデータ部とから構成される。ＩＰデータ部はＵＤＰデータグラムを含み、ＵＤＰデータグラムはＵＤＰヘッダ部とＵＤＰデータ部とから構成される。

また、図４に示すように、ＣＰＵを動作させるプログラムは、プロトコル処理を行うプロトコル処理手段１３０と、アプリケーション処理を行うアプリケーション処理手段１４０とを備える。プロトコル処理手段１３０は、イーサネット処理手段１３１と、ＩＰ処理手段１３２と、ＵＤＰ処理手段１３３とを有する。またアプリケーション処理手段１４０は、例えば、アプリケーション処理手段１４１〜１４３を有する。ここで、アプリケーション処理手段１４１は音声データの通信（ＶｏＩＰ）を行うためのものであり、アプリケーション処理手段１４２は、ＵＤＰデータグラムを用いてアドレスの自動割り当て（ＤＨＣＰ：Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を行うためのものである。また、アプリケーション処理手段１４３は、ＵＤＰデータグラムを用いてホストの名前を割り当てる（ＮｅｔＢＩＯＳ：ＮＥＴｗｏｒｋ Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）ためのものである。

また、図４のＣＰＵ１内において、プロトコル処理手段１３０とイーサネットコントローラ４との間には受信処理許可判定手段１５０が介在し、受信処理許可判定手段１５０には計測手段１６０が接続される。

次に、図４を用いて、ホスト１０がイーサネット１００からイーサネットフレームを受信した場合のプロトコル処理について説明する。

図４において、まず、イーサネットコントローラ４は、イーサネット１００のケーブル上で自局宛てのイーサネットフレームが伝送されているのを検出すると、このイーサネットフレームに対して、誤り検出処理等を行う。その後に、イーサネットコントローラ４は、ＣＰＵ１に対して、イーサネットフレームを受信したことを割り込み等により通知する。

次に、受信処理許可判定手段１５０は、イーサネットコントローラ４からの割り込み信号等により起動され、受信したイーサネットフレームをプロトコル処理手段１３０に渡すかどうかを、後述する手順により判定する。イーサネットフレームをプロトコル処理手段１３０に渡すと判定された場合には、以下の手順によりプロトコル処理が行われる。

即ち、プロトコル処理手段１３０において、イーサネット処理手段１３１では、受信したイーサネットフレームをイーサネットコントローラ４から読み出し、イーサネットヘッダ部を解析し、イーサネットデータ部にＩＰデータグラムが含まれているかどうかを判断する。ＩＰデータグラムが含まれている場合にはＩＰデータグラムを抽出しＩＰ処理手段１３２に渡す。ＩＰ処理手段１３２では、ＩＰヘッダ部を解析し、ＩＰデータ部にＵＤＰデータグラムが含まれているかどうかを判断する。ＵＤＰデータグラムが含まれている場合には、ＩＰヘッダ部に含まれている送信元ＩＰアドレスやＵＤＰデータグラムを抽出し、ＵＤＰ処理手段１３３に渡す。ＵＤＰ処理手段１３３では、ＵＤＰヘッダ部を解析し、ＵＤＰヘッダ部に含まれている宛先ポート番号と、ＵＤＰデータ部とを抽出する。そして、この宛先ポート番号に対応する、アプリケーション処理手段１４０に含まれるアプリケーション処理手段１４１〜１４３のうちのいずれかに、ＵＤＰデータグラム受信の通知を行い、送信元ＩＰアドレス、ＵＤＰヘッダ部に含まれる情報、ＵＤＰデータ部等からなるデータを渡す。そして、受信の通知を受けたアプリケーション処理手段は、渡されたデータに応じて各アプリケーション処理を行う。

次に、図２において、ホスト１０とホスト２０との間でアプリケーションＶｏＩＰにより音声データを通信中のある時点において、ホスト３０，５０からアプリケーションＤＨＣＰのブロードキャストパケットが送信され、ホスト４０からアプリケーションＮｅｔＢＩＯＳのブロードキャストパケットが送信され、ホスト２０からアプリケーションＶｏＩＰのパケットが送信され、ホスト１０が、ＤＨＣＰアプリケーション、ＮｅｔＢＩＯＳアプリケーション、ＶｏＩＰアプリケーションの順にパケットを受信した場合について説明する。

このとき、ホスト１０は、プロトコル処理を行うまでは、これらがアプリケーション処理手段１４１〜１４３のうちのいずれ宛てのパケットであるか判断できない。従って、まずアプリケーションＤＨＣＰ及びアプリケーションＮｅｔＢＩＯＳのパケットのプロトコル処理を行った後に、アプリケーションＶｏＩＰのパケットのプロトコル処理が行われることになる。しかし、ホスト１０は比較的に処理性能の低いＣＰＵ１を内蔵しているので、このようにパケットを集中的に受信した場合には、アプリケーションＶｏＩＰのパケットのプロトコル処理が遅れてしまい、前述したように音声通信の品質が劣化してしまう場合がある。

以下では、図５に示されるフローチャートを用いて、図４に示される受信処理許可判定手段１５０及び計測手段１６０の動作の例について説明する。ここで、アプリケーション処理手段１４０において通信するホストすなわちイーサネットフレームの受信処理を許可する送信元ホストの、イーサネットアドレスとしては、ＥＡＤＤＲａｃｐｔ０〜ＥＡＤＤＲａｃｐｔ３の４種類が記憶装置２に予め登録されているものとする。また、記憶装置２は、受信処理許可判定の周期となる所定の期間Ｔと、期間Ｔの計測を開始した時刻Ｔ０と、現在の時刻Ｔ１とを記憶する。さらに、記憶装置２は、期間Ｔの間に受信処理許可の条件を満たさないフレームを受信した場合でもプロトコル処理を行うフレーム数Ｎ０と、期間Ｔの間に受信した受信処理許可の条件を満たさないフレーム数Ｎ１とを記憶する。

まず、ステップＳ１において、初期化処理が実行される。具体的には、計測手段１６０は、Ｎ１として０を設定する。

次に、ステップＳ２に進み、イーサネットコントローラ４からの受信割り込み要求を待つ。ステップＳ２において受信割り込み要求を受け付けた場合には、待ちは解除され、ステップＳ３に進む。

次に、ステップＳ３において、イーサネットコントローラ４から受信したイーサネットフレームのイーサネットヘッダ部を読み出す。

次に、ステップＳ４に進み、イーサネットヘッダ部から送信元イーサネットアドレスＥＡＤＤＲｓｒｃを抽出する。

次に、ステップＳ５に進み、予め登録されているＥＡＤＤＲａｃｐｔ０〜ＥＡＤＤＲａｃｐｔ３の４種類のうちのいずれか１つの値とＥＡＤＤＲｓｒｃの値とが一致するかどうかを判定する。１つでも一致すると判定した場合には、ステップＳ６に進み、プロトコル処理手段１３０へイーサネットフレームの受信を通知し、ステップＳ２へ進む。ステップＳ５において、全く一致しないと判定した場合には、ステップＳ７に進む。

次に、ステップＳ７において、（Ｔ１−Ｔ０）とＴとの比較を行うことにより、計測手段１６０がフレーム数Ｎ１の計測を開始してから期間Ｔ以上経過したかどうかを判定する。（Ｔ１−Ｔ０）がＴに満たない場合には、期間Ｔを経過していないので、ステップＳ８に進む。

次に、ステップＳ８において、計測手段１６０は、フレーム数Ｎ１に１を加算してフレーム数Ｎ１を更新した後に、ステップＳ１１に進む。

ステップＳ７において、（Ｔ１−Ｔ０）がＴ以上の場合には、期間Ｔを経過しているので、ステップＳ９に進む。

次に、ステップＳ９において、計測手段１６０は、フレーム数Ｎ１を初期化（今回受信したフレーム数１を設定）し、ステップＳ１０に進む。

次に、ステップＳ１０において現在の時刻Ｔ１を期間Ｔの計測を開始した時刻Ｔ０として設定した後に、ステップＳ１１に進む。

次に、ステップＳ１１において、フレーム数Ｎ１とフレーム数Ｎ０との比較を行う。Ｎ１がＮ０以下の場合には、ステップＳ６に進み、Ｎ１がＮ０を越える場合には、ステップＳ２に進む。

以上のステップＳ１〜Ｓ１１の手順により、予め登録されたホストから受信したイーサネットフレームについては優先的に受信処理される。また、予め登録されていないホストから受信したイーサネットフレームについても、期間Ｔの間にフレーム数Ｎ０に達するまでは受信処理可能となる。従って、アプリケーションの負荷とアプリケーションで使用する通信パケット数に応じた負荷によりＮ０を適切に設定すれば、アプリケーションの動作を妨げずに、且つ、予め登録されていないホストからのイーサネットフレームも受信処理が可能となる。

このように、本発明の実施の形態に係るプロトコル処置装置においては、予め登録されていないホストからのイーサネットフレームも受信処理が可能である。従って、不特定のホストまたは比較的多数の特定のホストからの通信要求を受け付けることができるので、通信を行うホスト数が多い場合にも照合すべきアドレス数を増やす必要がないという効果を有する。

また、上記の説明においては、ステップＳ１１においてＮ１がＮ０を越える場合には、イーサネットフレームの受信処理を行わないが、このイーサネットフレームを記憶装置２に記憶しておき、所定の優先順位より優先度の低いタスクで受信処理を行うようにしてもよい。このときステップＳ５，Ｓ１１からステップＳ６に進む場合には、イーサネットフレームは所定の優先順位より優先度の高い受信処理を行われる。この所定の優先順位としては、例えば、前述の複数のアプリケーションのうち最も優先度が低いアプリケーション等の優先順位を用いることが考えられる。これにより、記憶装置２の使用量が増加する可能性はあるものの、受信したイーサネットフレームのうち受信処理を行われないイーサネットフレームの数を低減することができるという効果がある。

＜実施の形態２＞
図６は、本発明の実施の形態２に係るプロトコル処理方法を示すフローチャートである。図６は、実施の形態１の図５のフローチャートにおいて、フレーム数Ｎ０，Ｎ１に代えて、パケットのデータサイズを用いたものである。以下では、パケットのデータサイズとして、フレームサイズＶ０，Ｖ１を用いて説明する。

記憶装置２は、期間Ｔの間に受信処理許可の条件を満たさないフレームを受信した場合でもプロトコル処理を行うフレームサイズＶ０と、期間Ｔの間に受信した受信処理許可の条件を満たさないフレームサイズＶ１とを、記憶する。

図６のフローチャートは、以下の点において、図５のフローチャートとは異なっている。

即ち、ステップＳ３において、イーサネットコントローラ４から受信したイーサネットフレームのイーサネットヘッダ部を読み出す際に、フレームサイズＶｒｃｖも併せて読み出す。

また、ステップＳ８において、計測手段１６０は、フレーム数Ｎ１に１を加算してフレーム数Ｎ１を更新する代わりに、フレームサイズＶ１にＶｒｃｖを加算してフレームサイズＶ１を更新する。

また、ステップＳ９において、計測手段１６０は、フレーム数Ｎ１を初期化（今回受信したフレーム数１を設定）する代わりに、フレームサイズを初期化（今回受信したフレームサイズＶｒｃｖを設定）する。

上記以外の点については、図６のフローチャートは図５のフローチャートと同様であるので、説明を省略する。

このように、本実施の形態に係るプロトコル処理装置においては、実施の形態１におけるフレーム数Ｎ０，Ｎ１に代えて、フレームサイズＶ０，Ｖ１を用いている。従って、実施の形態１の効果に加えて、プロトコル処理の負荷がフレーム数よりもフレームサイズにより大きく依存する場合には、実施の形態１よりも精度よくプロトコル処理における処理量を制御することができるという効果を有する。

＜実施の形態３＞
図７は、本発明の実施の形態３に係るプロトコル処理方法を示すフローチャートである。図７は、実施の形態１の図５のフローチャートにおいて、イーサネットアドレスＥＡＤＤＲａｃｐｔ０〜ＥＡＤＤＲａｃｐｔ３に代えて、ポート番号ＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１を用いたものである。

記憶装置２は、イーサネットフレームの受信処理を許可するアプリケーションに対応した２種類のポート番号ＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１を、予め登録する。

図７のフローチャートは、以下の点において、図５のフローチャートとは異なっている。

即ち、ステップＳ３において、イーサネットコントローラ４から受信したイーサネットフレームに含まれるＵＤＰデータグラムのＵＤＰヘッダ部を読み出す。

また、ステップＳ４において、ＵＤＰヘッダ部から宛先ポート番号ＵＰＯＲＴｄｓｔを抽出する。

また、ステップＳ５において、予め登録されているＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１の２種類のうちのいずれか１つの値とＵＰＯＲＴｄｓｔの値とが一致するかどうかを判定する。

上記以外の点については、図７のフローチャートは図５のフローチャートと同様であるので、説明を省略する。

このように、本実施の形態に係るプロトコル処理方法においては、実施の形態１におけるイーサネットアドレスＥＡＤＤＲａｃｐｔ０〜ＥＡＤＤＲａｃｐｔ３に代えて、ポート番号ＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１を用いているので、予め登録されたアプリケーション宛のイーサネットフレームについては優先的に受信処理される。また、予め登録されていないアプリケーション宛のイーサネットフレームについても、期間Ｔの間にフレーム数Ｎ０に達するまでは受信処理可能となる。従って、アプリケーションの負荷とアプリケーションで使用する通信パケット数に応じた負荷によりＮ０を適切に設定すれば、アプリケーションの動作を妨げずに、且つ、予め登録されていないアプリケーション宛てのイーサネットフレームも受信処理が可能となる。よって、アプリケーションに優先度をつけて実行することが可能であるという効果を有する。

なお、図７のフローチャートにおいては、フレーム数Ｎ０，Ｎ１を用いて説明を行っているが、フレーム数Ｎ０，Ｎ１に代えて、フレームサイズＶ０，Ｖ１を用いてもよい。

＜実施の形態４＞
図８は、本発明の実施の形態４に係るプロトコル処理方法を示すフローチャートである。図８は、実施の形態１の図５のフローチャートにおいて、イーサネットアドレスＥＡＤＤＲａｃｐｔ０〜ＥＡＤＤＲａｃｐｔ３に代えて、ＩＰアドレスＩＡＤＤＲａｃｐｔ０〜ＩＡＤＤＲａｃｐｔ１とポート番号ＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１とを用いたものである。

記憶装置２は、イーサネットフレームの受信処理を許可する送信元ホストの２種類のＩＰアドレスＩＡＤＤＲａｃｐｔ０〜ＩＡＤＤＲａｃｐｔ１と、イーサネットフレームの受信処理を許可するアプリケーションに対応した２種類のポート番号ＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１とを、予め登録する。ここで、ＩＰアドレスとポート番号とは組み合わせられ、両方が一致したかどうかで判定が行われるものとする。ここで、ＩＰアドレスとポート番号との組み合わせは、例えば、（ＩＡＤＤＲａｃｐｔ０，ＵＰＯＲＴａｃｐｔ０）、（ＩＡＤＤＲａｃｐｔ１，ＵＰＯＲＴａｃｐｔ０）、（ＩＡＤＤＲａｃｐｔ０，ＵＰＯＲＴａｃｐｔ１）のような３通りで登録されているものとする。

図８のフローチャートは、以下の点において、図５のフローチャートとは異なっている。

即ち、ステップＳ３において、イーサネットコントローラ４から受信したイーサネットフレームに含まれるＩＰデータグラムのＩＰヘッダ部および、イーサネットフレームに含まれるＵＤＰデータグラムのＵＤＰヘッダ部を読み出す。

また、ステップＳ４において、ＩＰヘッダ部から送信元ＩＰアドレスＩＡＤＤＲｓｒｃを、ＵＤＰヘッダ部から宛先ポート番号ＵＰＯＲＴｄｓｔを、それぞれ抽出する。

また、ステップＳ５において、予め登録されている（ＩＡＤＤＲａｃｐｔ０，ＵＰＯＲＴａｃｐｔ０）、（ＩＡＤＤＲａｃｐｔ１，ＵＰＯＲＴａｃｐｔ０）、（ＩＡＤＤＲａｃｐｔ０，ＵＰＯＲＴａｃｐｔ１）の３種類のうちのいずれか１つの組み合わせと（ＩＡＤＤＲｓｒｃ，ＵＰＯＲＴｄｓｔ）の組み合わせとが一致するかどうかを判定する。

上記以外の点については、図８のフローチャートは図５のフローチャートと同様であるので、説明を省略する。

このように、本実施の形態に係るプロトコル処理装置においては、実施の形態１におけるイーサネットアドレスＥＡＤＤＲａｃｐｔ０〜ＥＡＤＤＲａｃｐｔ３に代えて、ＩＰアドレスＩＡＤＤＲａｃｐｔ０〜ＩＡＤＤＲａｃｐｔ１とポート番号ＵＰＯＲＴａｃｐｔ０〜ＵＰＯＲＴａｃｐｔ１と組み合わせを用いている。従って、アプリケーションの負荷とアプリケーションで使用する通信パケット数に応じた負荷によりＮ０を適切に設定すれば、アプリケーションの動作を妨げずに、且つ、予め登録されていないホストからのイーサネットフレームや予め登録されていないアプリケーション宛てのイーサネットフレームも受信処理が可能となる。よって、送信元アドレスと宛先アプリケーションとの組み合わせにより優先度をつけて実行することが可能であるという効果を有する。

なお、図８のフローチャートにおいては、フレーム数Ｎ０，Ｎ１を用いて説明を行っているが、フレーム数Ｎ０，Ｎ１に代えて、フレームサイズＶ０，Ｖ１を用いてもよい。

＜実施の形態５＞
実施の形態１において、受信処理を許可するホストとして登録されているイーサネットアドレスは、例えば図９に示すように、各ホスト毎に異なる登録番号で登録されている。そのため、登録されているイーサネットアドレスのうちのいずれか１つの値と、受信したイーサネットフレームに含まれる送信元アドレスＥＡＤＤＲｓｒｃとが一致するかどうかを判定するには、登録されているイーサネットアドレスの先頭から順に、ＥＡＤＤＲｓｒｃと一致するか順次比較してゆく必要がある。そのため、登録されているホスト数が増えた場合には、登録するイーサネットアドレスの数も増えるので、それに伴いプロトコル処理の処理量が増加してしまう。

そこで、実施の形態５においては、図９に示すように、登録されているイーサネットアドレスが連続している場合には、図１０に示すように、例えば開始アドレスと終了アドレスとからなりアドレス範囲を示すようなデータ形式で登録する。そして、登録されているアドレスと一致するかどうかの判定については、受信したイーサネットフレームに含まれる送信元アドレスＥＡＤＤＲｓｒｃが、開始アドレス以上でかつ終了アドレス以下の場合に一致したと判定し、そうでない場合には一致していないと判定する。

これにより、登録されているホストのイーサネットアドレスが多い場合で、且つ、そのアドレスが連続している場合には、登録されているアドレスと一致するかどうかの判定に要する処理量を低減することができる。

なお、図１０には、１組のアドレス範囲が登録されているが、１組に限らず、複数組のアドレス範囲を登録してもよい。

また、登録されているアドレスのうち他のアドレスと連続していないアドレスについては、他のアドレス範囲を示すデータ形式と整合させるために、開始アドレスと終了アドレスとして同一のアドレスを有する１組のアドレス幅として登録してもよい。

＜実施の形態６＞
実施の形態１〜５においては、受信処理許可の判定を行うアドレスやポート番号は、予め記憶装置２に静的に登録されていたが、実施の形態６においては、アプリケーションにより動的にこれらの値の登録や削除を可能とする。

図１１は、本実施の形態に係るプロトコル処理装置が備えるＣＰＵにおいて動作するアプリケーションの構成を示している。図１１は、図４のＣＰＵ１内に条件変更手段１７０を追加し、記憶装置２を制御させた構成となっている。条件変更手段１７０を用いることにより、アプリケーションから動的に記憶装置２に記憶されたアドレスやポート番号の値の登録や削除が可能となる。例えば、ＶＯＩＰ等の音声通信アプリケーションの動作が正常に行われない場合には、条件変更手段１７０は、記憶装置２を制御し、データ通信アプリケーションの条件が厳しくなるよう設定を変更する。これにより、音声通信アプリケーションの優先度を高め、正常に動作させることができる。

このように、本実施の形態に係るプロトコル処理装置が備えるＣＰＵ１は、アプリケーションによりアドレスやポート番号の登録内容が動的に変更される。従って、優先度の高いアプリケーションで必要となるイーサネットフレームの受信処理許可の判定を動的に変更することが可能となるので、実施の形態１〜５に効果に加えて、優先度の高いアプリケーションの動作が妨げられる可能性が低くなる。

＜実施の形態７＞
実施の形態１〜６においては、受信処理許可判定手段１５０は常に動作していたが、実施の形態７においては、アプリケーションにより動的に、受信処理許可判定手段１５０を動作させる（有効モード）か動作させない（無効モード）かを変更可能とする。

図１２は、本実施の形態に係るプロトコル処理装置が備えるＣＰＵにおいて動作するアプリケーションの構成を示している。図１２は、図４のＣＰＵ１内にモード変更手段１８０を追加し、記憶装置２を制御させた構成となっている。モード変更手段１８０を用いることにより、アプリケーションから動的に記憶装置２に記憶された受信処理許可判定手段１５０の動作モードを変更できる。例えば、受信するパケット数（又はパケットサイズ）が少ない場合には、モード変更手段１８０は、記憶装置２を制御し、受信処理許可判定手段１５０を動作させないように設定を変更する。これにより、受信処理許可判定手段１５０による処理量を低減することができる。

このように、本実施の形態に係るプロトコル処理装置が備えるＣＰＵ１は、アプリケーションにより受信処理許可判定手段１５０の動作モードが動的に変更される。従って、各アプリケーションの優先度が同一である場合等には、受信処理許可判定手段１５０における処理量を低減することができる。

＜実施の形態８＞
実施の形態１〜７においては、受信したイーサネットフレームの内容と、登録されている条件とが一致する場合にはそのイーサネットフレームに対して優先的に受信処理を行っているが、この判定論理を反転させてもよい。

実施の形態１の図５と実施の形態２の図６において判定論理を反転させたフローチャートを図１３，１４に示す。図１３，１４では、ステップＳ５において、受信処理許可条件に代えて、受信処理を許可しない受信処理不許可条件を用い、この受信処理不許可条件を満たさないイーサネットフレームに対して優先的に受信処理を行っている。即ち、図１３においては、Ｎ０，Ｎ１に代えて、期間Ｔの間に受信処理不許可の条件を満たすフレームを受信した場合でもプロトコル処理を完了させるフレーム数Ｎ０’と、期間Ｔの間に受信した受信処理不許可の条件を満たすフレーム数Ｎ１’を用いる。また、図１４においては、Ｖ０，Ｖ１に代えて、期間Ｔの間に受信処理不許可の条件を満たすフレームを受信した場合でもプロトコル処理を完了させるフレームサイズＶ０’と、期間Ｔの間に受信した受信処理不許可の条件を満たすフレームサイズＶ１’を用いて判定を行っている。従って、例えば、優先的に受信処理すべきイーサネットフレームのアドレス数が、優先的に受信処理しないイーサネットフレームのアドレス数に比較して非常に多い場合には、受信処理許可判定手段１５０における処理量を低減することができる。

ここで、ステップＳ５以外の工程については、実施の形態１〜７と同様の手順で動作するので、それらの詳細な説明は省略する。

このように、本実施の形態にプロトコル処理装置においては、実施の形態１〜７において判定論理を反転させている。従って、例えば、優先的に受信処理すべきイーサネットフレームのアドレス数が、優先的に受信処理しないイーサネットフレームのアドレス数に比較して非常に多い場合には、受信処理許可判定手段１５０における処理量を低減することができる。

なお、図１３，１４のフローチャートにおいては、送信元アドレスを用いて説明を行っているが、送信元アドレスに代えて、宛先ポート番号等を用いてもよい。即ち、実施の形態１〜７の全てにおいて、判定論理を反転させることが可能である。

実施の形態１に係るプロトコル処理装置の構成例を示す図である。 実施の形態１に係るプロトコル処理装置が用いられるネットワークの構成例を示す図である。 実施の形態１に係るプロトコル処理装置において用いられるイーサネットフレームの構成を示す図である。 実施の形態１に係るプロトコル処理装置の構成例を示す図である。 実施の形態１に係るプロトコル処理装置をプロトコル処理方法を示すフローチャートである。 実施の形態２に係るプロトコル処理装置を用いたプロトコル処理方法を示すフローチャートである。 実施の形態３に係るプロトコル処理装置を用いたプロトコル処理方法を示すフローチャートである。 実施の形態４に係るプロトコル処理装置を用いたプロトコル処理方法を示すフローチャートである。 実施の形態５に係るプロトコル処理装置におけるイーサネットアドレスの格納形式を示す図である。 実施の形態５に係るプロトコル処理装置におけるイーサネットアドレスの格納形式を示す図である。 実施の形態６に係るプロトコル処理装置の構成例を示す図である。 実施の形態７に係るプロトコル処理装置の構成例を示す図である。 実施の形態８に係るプロトコル処理装置を用いたプロトコル処理方法を示すフローチャートである。 実施の形態８に係るプロトコル処理装置を用いたプロトコル処理方法を示すフローチャートである。

符号の説明

１ ＣＰＵ、２ 記憶装置、３ コネクタ、４ イーサネットコントローラ、５ ＬＣＤ、６ タッチパネル、７ アドレスバス、８ データバス、１０〜５０ ホスト、１００ イーサネット、１３０ プロトコル処理手段、１３１ イーサネット処理手段、１３２ ＩＰ処理部、１３３ ＵＤＰ処理手段、１４０〜１４３ アプリケーション処理手段、１５０ 受信処理許可判定手段、１６０ 計測手段、１７０ 条件変更手段、１８０ モード変更手段。

Claims (14)

1. ネットワークからパケットを受信するネットワークコントローラと、
   受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定する受信処理許可判定手段と、
   前記受信処理許可条件を満たすパケットに対してプロトコル処理を行うプロトコル処理手段と、
   プロトコル処理を行った前記受信処理条件を満たさないパケットの合計個数を計測する計測手段と
   を備え、
   前記プロトコル処理手段は、
   前記合計個数が所定の個数に達するまでは前記受信処理許可条件を満たさないパケットに対してもプロトコル処理を行う
   プロトコル処理装置。
2. ネットワークからパケットを受信するネットワークコントローラと、
   受信したパケットが、受信処理を許可すべき受信処理許可条件を満たすかどうかを判定する受信処理許可判定手段と、
   前記受信処理許可条件を満たすパケットに対してプロトコル処理を行うプロトコル処理手段と、
   プロトコル処理を行った前記受信処理条件を満たさないパケットの合計データサイズを計測する計測手段と
   を備え、
   前記プロトコル処理手段は、
   前記合計データサイズが所定のデータサイズに達するまでは前記受信処理許可条件を満たさないパケットに対してもプロトコル処理を行う
   プロトコル処理装置。
3. 請求項１に記載のプロトコル処理装置であって、
   前記合計個数は、所定の時間毎に初期化される
   プロトコル処理装置。
4. 請求項２に記載のプロトコル処理装置であって、
   前記合計データサイズは、所定の時間毎に初期化される
   プロトコル処理装置。
5. 請求項１に記載のプロトコル処理装置であって、
   前記プロトコル処理手段は、
   前記合計個数が所定の個数に達した後は前記受信処理許可条件を満たさないパケットに対してプロトコル処理を行わない
   プロトコル処理装置。
6. 請求項２に記載のプロトコル処理装置であって、
   前記プロトコル処理手段は、
   前記合計データサイズが所定のデータサイズに達した後は前記受信処理許可条件を満たさないパケットに対してプロトコル処理を行わない
   プロトコル処理装置。
7. 請求項１に記載のプロトコル処理装置であって、
   前記プロトコル処理手段は、
   前記合計個数が所定の個数に達した後は前記受信処理許可条件を満たさないパケットに対して所定の優先順位より低い優先度でプロトコル処理を受け付ける
   プロトコル処理装置。
8. 請求項２に記載のプロトコル処理装置であって、
   前記プロトコル処理手段は、
   前記合計データサイズが所定のデータサイズに達した後は前記受信処理許可条件を満たさないパケットに対して所定の優先順位より低い優先度でプロトコル処理を受け付ける
   プロトコル処理装置。
9. 請求項１乃至請求項８のいずれかに記載のプロトコル処理装置であって、
   前記受信処理許可判定手段は、
   受信した前記パケットに含まれる送信元アドレスが、受信処理を許可すべき所定のホストのアドレスであるかどうかを前記受信許可条件として判定する
   プロトコル処理装置。
10. 請求項１乃至請求項８のいずれかに記載のプロトコル処理装置であって、
    前記受信処理許可判定判定手段は、
    受信した前記パケットに含まれる送信元アドレスが、受信処理を許可すべき所定のホストのアドレス範囲に含まれるかどうか前記受信許可条件としてを判定する
    プロトコル処理装置。
11. 請求項１乃至請求項１０のいずれかに記載のプロトコル処理装置であって、
    前記受信処理許可判定手段は、
    受信した前記パケットに含まれる宛先ポート番号が、受信処理を許可すべきアプリケーションに対応するかどうかを判定する
    プロトコル処理装置。
12. 請求項１乃至請求項１１のいずれかに記載のプロトコル処理装置であって、
    前記受信処理許可条件を動的に変更する条件変更手段
    をさらに備えるプロトコル処理装置。
13. 請求項１乃至請求項１１のいずれかに記載のプロトコル処理装置であって、
    前記受信処理許可判定手段を動作させるかさせないかを動的に変更するモード変更手段をさらに備えるプロトコル処理装置。
14. 請求項１乃至請求項１３のいずれかに記載のプロトコル処理装置であって、
    前記受信処理許可条件に代えて、受信処理を許可しない受信処理不許可条件を用い、判定論理を反転させた
    プロトコル処理装置。
    

Images