(57)【要約】【課題】ホストの処理負担及びネットワーク負荷の低減【解決手段】ネットワークインターフェースカード１２とホスト１１（受信処理部）との間にパケットパーサー１３を設ける。パケットパーサー１３は、受信したパケットのヘッダ解析を行って、そのパケットのプロトコルを判別し、判別した結果が重要パケットの場合、無条件で、つまり優先的に受信処理が行われるようにホスト１１へ受信通知（インタラプト）する。非重要パケットの場合は、例えばデータ量が設定値を超えてからインタラプトする。またリアルタイムストリームパケットの場合は、ホストではなく直接コーデックに転送する。【選択図】        図４
2004159038.tif 000002
【特許請求の範囲】
【請求項１】
受信通知を受領することにより、受信されたデータパケットに対して所定のプロトコルに従ったデータ処理を実行する処理手段を有する通信装置であって、
上記データパケットに含まれる情報に応じて、受信された上記データパケットが重要パケットか非重要パケットかを判別する判別手段と、
上記判別手段により上記重要パケットと判別された場合は、上記処理手段に対して無条件で上記受信通知を発行し、上記判別手段により上記非重要パケットと判別された場合は、所定の条件が満たされてから上記処理手段に対して上記受信通知を発行する制御手段と、
を備えたことを特徴とする通信装置。
【請求項２】
上記所定の条件は、上記非重要パケットと判断されたデータの量が設定値以上となることである請求項１に記載の通信装置。
【請求項３】
上記判別手段は、上記重要パケット又は上記非重要パケットのヘッダ情報を記憶したテーブル情報を備え、受信した上記データパケットのヘッダ情報を、上記テーブル情報と照合することで、上記重要パケットと上記非重要パケットの判別を行うことを特徴とする請求項１に記載の通信装置。
【請求項４】
リアルタイムストリームパケットをデータ処理する第二の処理手段をさらに備え、
上記判別手段は、さらに、受信された上記データパケットがリアルタイムストリームパケットであるか否かも判別し、
上記制御手段は、受信された上記データパケットが上記リアルタイムストリームパケットと判別された場合は、上記受信通知を発行せずに、上記受信されたデータパケットを、上記第二の処理手段に転送することを特徴とする請求項１に記載の通信装置。
【請求項５】
受信通知を受領することにより、受信されたデータパケットに対して第一のプロトコルに従ったデータ処理を実行する第一の処理手段と、
受信されたリアルタイムストリームパケットに対して第二のプロトコルに従ったデータ処理を実行する第二の処理手段とを有する通信装置であって、
上記データパケットに含まれる情報に応じて、受信された上記データパケットがリアルタイムストリームパケットであるか否かを判別する判別手段と、
上記判別手段によりリアルタイムストリームパケットではないと判別された場合は、上記第一の処理手段に対して受信通知を発行し、上記判別手段によりリアルタイムストリームパケットと判別された場合は、上記第一の処理手段に対する受信通知を発行せずに、上記受信されたデータパケットを、上記第二の処理手段へ転送する制御手段と、
を備えることを特徴とする通信装置。
【請求項６】
データパケットを受信して、受信した上記データパケットに対して所定のプロトコルに従ったデータ処理を実行する通信方法であって、
上記データパケットに含まれる情報に応じて、受信された上記データパケットが重要パケットか非重要パケットかを判別する第一のステップと、
上記第一のステップにおいて上記非重要パケットと判別された場合は、所定の条件が満たされてから上記非重要パケットと判別された上記データパケットのデータ処理を実行する第二のステップとを有することを特徴とする通信方法。
【請求項７】
上記所定の条件は、上記非重要パケットと判断されたデータの量が設定値以上となることである請求項６に記載の通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばローカルエリアネットワーク等のネットワーク通信に係る通信装置及び通信方法に関するものである。
【０００２】
【従来の技術】
ローカルエリアネットワーク（ＬＡＮ）上でホストを通信させ各々のプロトコル処理を行なう場合、従来では、ネットワークインターフェースカードとそれに対応するデバイスドライバ、並びにホストに搭載されたプロトコルスタックが関与して処理を行なうという方式がとられていた。
この方式ではネットワークインターフェースカードとデバイスドライバはＬＡＮ伝送路へのパケット送信や、ＬＡＮ伝送路からのパケット受信しか行なわない。つまり送信パケットの生成や受信パケットの解析、それに伴うプロトコル処理は全てホストが行なっている。
【０００３】
図７にＬＡＮ接続されたホストシステムの例を示す。
図７ににおいては、２台のホストシステム３０，４０の間でイーサネット（登録商標）をデータ転送媒体として、例えばＭＰＥＧ方式の圧縮動画データ等の転送を行なうことを想定する。
図７におけるホスト３１，４１とは、ＣＰＵ及びＲＡＭ等のハードウエアによる主たる情報処理部であり、ＣＰＵで起動されるアプリケーションソフトウェアや各種プロトコル処理のためのプログラムも含めたものとしている。またホストシステム３０，４０とは上記ホスト３１，４１とネットワークインターフェースカード３２，４２により構成されるコンピュータシステムを指す。
【０００４】
ホストシステム４０からホストシステム３０にＭＰＥＧデータの送信を行う場合を考える。この場合、まずホストシステム４０では、搭載されたソフトウェアコーデックかあるいはハードウェアコーデックでＭＰＥＧエンコードされたデータに対して、ホスト４１のＣＰＵとソフトウェアにより、リアルタイムストリーム転送のための各階層の処理を行う。例えばＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）／ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）の各プロトコルのパケッタイズ処理並びにヘッダ処理がなされる。
その後、ホスト４１は処理を施したパケットをネットワークインターフェースカード４２に転送し、ネットワークインターフェースカード４２が伝送路１００を介してホストシステム３０へ送信する。
【０００５】
ホストシステム３０では、搭載しているネットワークインターフェースカード３２からのインタラプト（受信通知としての割込要求）によりパケットを受信したことをホスト３１に感知させる。するとホスト３１は、ネットワークインターフェースカード３２内のバッファに蓄えられた受信パケットを読み出す。なお、このホスト３１に対するインタラプトは受信パケット到着毎に発生される。
ホスト３１は、ネットワークインターフェースカード３２から読み出したパケットのヘッダ解析を、プロトコル処理ソフトウェアとホストＣＰＵにより行ないＭＡＣプロトコル／ＩＰ／ＵＤＰ／ＲＴＰを処理した後、ソフトウェアまたはハードウェアで実現されたコーデックへ転送し、ＭＰＥＧ動画データの再生を行なうものとなる。
【０００６】
また、このようなＬＡＮ通信に適用できる技術として、次のものが知られている。
【０００７】
【特許文献１】特開平７−９５２６０号公報
【０００８】
この特許文献１では、図９（ａ）の構成で図９（ｂ）の処理を行う通信制御装置１０１によりＣＰＵのデータ処理負担を軽減するものである。
この場合、通信制御装置１０１は通信インターフェース１０５を介してアプリケーションプログラム１０７及びパケット処理ルーチン１０９に接続される。
送受信処理部１１１で受信されたデータは共有バッファ１１３に格納される（ステップＳ１）。ここで切換制御部１１５はパケット種別を検出し（ステップＳ２）、それに応じてデータをプロトコル処理部１１７ａ〜１１７ｃ、又はパケット処理ルーチン１０９に振り分けるようにしている（ステップＳ３，Ｓ４，Ｓ５）。
【０００９】
【発明が解決しようとする課題】
ここで、まず図７で説明したホストシステム３０、４０の通信を考える。この場合、ホスト３１、４１がプロトコル処理を受け持っている為、様々なプロトコルに容易に対応できる汎用性に優れている反面、多種プロトコルに対応しようとすればするほどホストでの処理負荷は重くなり、より高性能なホストＣＰＵが求められ、装置のコストアップにつながるといった問題が生ずる。
【００１０】
例えば上記ホストシステム３０では、ネットワークインターフェースカード３２からホスト３１へのインタラプトは、受信パケット到着毎に発生するが、従って、ホストシステム４０，あるいはＬＡＮ接続された他のホストシステムから多数のパケットが送信された場合、或いは上記のＭＰＥＧストリームをＩＰパケッタイズしたパケットを受信する場合などは、非常に多くのパケットを連続受信することになり、ホスト３１へのインタラプト（割込処理）が短時間のうちに多発することとなる。それと同時に、実装如何ではパケット受信の割込処理毎にホスト３１はネットワークインターフェースカード３２へアクセスしてパケットを読み出す必要がある。
また、ホスト３１はネットワークインターフェースカード３２から読み出したパケットのヘッダ解析を行い、必要なプロトコル処理を行って、アプリケーションプログラムやコーデックへ受け渡す処理も行う。アプリケーションプログラムやコーデック（コーデックをホストＣＰＵがソフトウエアにより実行する場合）についても、ホスト３１はそれらの処理を行う必要がある。
【００１１】
従って、リアルタイムストリームのビットレートが非常に高いデータパケットが受信される場合や、リアルタイムストリームでなくとも多数のパケットが受信された場合など、ホスト３１への割込処理が多発することで、ホストＣＰＵが他のタスクを実行できなくなるなどの問題が生ずる。
また、ＯＳＩ参照モデルで言う所の第２層から第７層まで、即ちデータリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層という広い範囲のプロトコル処理をホスト３０が行なう点もホストの処理負荷増大を招く。
そして、これらの問題を解決するには、高性能な高価なＣＰＵが必要となり、装置のコストアップといった問題を引き起こす。
【００１２】
また、このようなホスト３０の処理負担の増大は、単に装置のコストアップだけでなくネットワーク負荷の増大ももたらす。
図７のモデルを拡張して図８のように３台のホストシステム３０，４０，５０がＬＡＮ接続された場合を想定する。ホストシステム５０は、ホストシステム３０、４０と同様にホスト５１及びネットワークインターフェースカード５２を備える。
【００１３】
いま、通信ＤＦ１として示すように、ホストシステム３０がホストシステム４０からのパケットを比較的大量に受信中であるとする。
このときにホストシステム５０からホストシステム３０へファイル転送のアプリケーションが実行されたとすると、ホストシステム５０はまずホストシステム３０のＭＡＣアドレスを得るためにＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）要求を行う（通信ＤＦ２）。ところがホストシステム３０側では、ホストシステム４０から既に受信したパケット分のプロトコル処理が終わるまでは、ホストシステム５０からのＡＲＰ要求に対して応答をすることができない。
【００１４】
このためＡＲＰ応答が得られないホストシステム５０は、そのアプリケーションをタイムアウトしなければならない羽目に陥ることも考えられる。
これは、ホストシステム４０と通信中のホストシステム３０に対しては、ホストシステム５０からの通信要求が拒否されたということであり、これに対しホストシステム５０が再送要求を送ることでネットワーク上に冗長なパケットが発生し、ネットワーク負荷の増大を招く。
但し、イーサネットネットワーク上では再送処理は通常の処理として想定されているため、この再送処理自体が問題となるのではない。問題なのはネットワーク負荷の増大が、通信するホストシステムの台数に比例する点である。
通常のＬＡＮシステムにおいて、通信しているホストの台数は上記図８のモデルのように３台で留まるものではなく、より多数のホストシステムがＬＡＮ接続されることが一般に想定される。よって、再送処理によるネットワーク負荷もかなり増大するものと容易に想像できる。
【００１５】
さらにもう一つの問題としては、上記のＡＲＰやＲＡＲＰ（Ｒｅｖｅｒｓｅ  Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）等の通信の要となるコントロールパケットの受信処理が他に受信中のパケット処理により待たされ、処理が出来ない点である。
前述した例はＭＰＥＧストリームのＲＴＰ／ＵＤＰ／ＩＰ／ＭＡＣプロトコル処理であるが、他にもファイル転送やリモートログインといったＴＣＰ処理を必要とする場合も、全く同様の問題が生じる。
【００１６】
以上のように従来の通信方式において、特にホストの受信処理においては、ホストの処理負荷が増大することによって起こる受信処理以外のタスク及び演算処理を実行できなくなる問題、または受信処理以外の処理を遅延させてしまう問題、並びに重要パケットが優先的に処理されないことによって再送処理が発生し、ネットワーク負荷が増大するといった問題があった。またこれらを解決するためにホストＣＰＵの高速化という手法を採れば、装置のコストアップが生ずるという問題があった。
【００１７】
また、上記特許文献１に記載された技術では、ＣＰＵ処理負担の低減が実現されているが、該技術ではＣＰＵはアプリケーションプログラム１０７及びパケット処理ルーチン１０９の処理を行うものであり、プロトコル処理は通信制御装置１０１側で行うものを想定している。
つまり、汎用性拡大のためにホストＣＰＵがプロトコル処理を受け持つというシステムとは異なるものであり、当然ながらホストＣＰＵがプロトコル処理を受け持つシステムの場合における上記問題が解決されるものではない。特にいえば、パケット受信の集中時に、プロトコル処理を含むＣＰＵの処理負担を軽減させるためのものではない。
【００１８】
【課題を解決するための手段】
本発明は上記の問題に鑑みて、例えばＬＡＮ上の通信処理方式におけるホストシステムの処理負担やネットワーク負荷を低減することを目的とする。
【００１９】
このため本発明の通信装置は、受信通知を受領することにより、受信されたデータパケットに対して所定のプロトコルに従ったデータ処理を実行する処理手段を有する通信装置であって、上記データパケットに含まれる情報に応じて、受信された上記データパケットが重要パケットか非重要パケットかを判別する判別手段と、上記判別手段により上記重要パケットと判別された場合は、上記処理手段に対して無条件で上記受信通知を発行し、上記判別手段により上記非重要パケットと判別された場合は、所定の条件が満たされてから上記処理手段に対して上記受信通知を発行する制御手段とを備える。
この場合、上記所定の条件は、上記非重要パケットと判断されたデータの量が設定値以上となることとする。
また上記判別手段は、上記重要パケット又は上記非重要パケットのヘッダ情報を記憶したテーブル情報を備え、受信した上記データパケットのヘッダ情報を、上記テーブル情報と照合することで、上記重要パケットと上記非重要パケットの判別を行う。
また、リアルタイムストリームパケットをデータ処理する第二の処理手段をさらに備え、上記判別手段は、さらに、受信された上記データパケットがリアルタイムストリームパケットであるか否かも判別し、上記制御手段は、受信された上記データパケットが上記リアルタイムストリームパケットと判別された場合は、上記受信通知を発行せずに、上記受信されたデータパケットを、上記第二の処理手段に転送する。
【００２０】
また本発明の通信装置は、受信通知を受領することにより、受信されたデータパケットに対して第一のプロトコルに従ったデータ処理を実行する第一の処理手段と、受信されたリアルタイムストリームパケットに対して第二のプロトコルに従ったデータ処理を実行する第二の処理手段とを有する通信装置である。そして、上記データパケットに含まれる情報に応じて、受信された上記データパケットがリアルタイムストリームパケットであるか否かを判別する判別手段と、上記判別手段によりリアルタイムストリームパケットではないと判別された場合は、上記第一の処理手段に対して受信通知を発行し、上記判別手段によりリアルタイムストリームパケットと判別された場合は、上記第一の処理手段に対する受信通知を発行せずに、上記受信されたデータパケットを、上記第二の処理手段へ転送する制御手段とを備える。
【００２１】
本発明の通信方法は、データパケットを受信して、受信した上記データパケットに対して所定のプロトコルに従ったデータ処理を実行する通信方法であって、上記データパケットに含まれる情報に応じて、受信された上記データパケットが重要パケットか非重要パケットかを判別する第一のステップと、上記第一のステップにおいて上記非重要パケットと判別された場合は、所定の条件が満たされてから上記非重要パケットと判別された上記データパケットのデータ処理を実行する第二のステップとを有する。
この場合、上記所定の条件は、上記非重要パケットと判断されたデータの量が設定値以上となることとする。
【００２２】
即ち本発明では、例えばホストシステムにおいてネットワークインターフェースカードとホスト（処理手段）との間に、上記構成の判別手段及び制御手段を設ける。又はホスト処理に受け渡す受信処理として上記通信方法を実行する。
そして上記通信装置（又は通信方法）では、例えば受信したパケットのヘッダ解析を行って、そのパケットのプロトコルを判別し、判別した結果が重要パケット（例えばコントロールパケットやリアルタイム性が要求されるパケットなど）の場合、より優先的に受信処理するようホストへ通知する。
これにより、ホスト（処理手段）はヘッダ処理を行なう必要が無く、また、優先処理を必要とするパケットを処理優先度の低いパケットに埋もれさせること無く、受信処理を行なうことができるようにする。
またさらに、特に受信したパケットがリアルタイムストリームパケットの場合は、ホスト（処理手段／第一の処理手段）を介さないでリアルタイムストリームパケットに対応する第二の処理手段に転送するようにもする。
【００２３】
【発明の実施の形態】
以下、本発明の実施の形態として、複数のホストシステムがＬＡＮ通信可能とされる場合における通信制御について第１〜第３の実施の形態を説明していく。
【００２４】
＜第１の実施の形態＞
図１，図２，図３により第１の実施の形態を説明する。
図１ににおいては、２台のホストシステム１０，２０を例示しており、このホストシステム１０，２０の間でイーサネット（登録商標）をデータ転送媒体として各種データパケットの通信を行うものとする。
通信されるデータパケットとしては、各ホストシステム１０，２０におけるアプリケーションプログラムの動作によって処理される各種ファイルなどとしてのテキスト、画像、或いは制御コマンドなどや、通信プロトコル処理によるＡＲＰ、ＲＡＲＰ、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）などのコントロールパケット、さらには例えばＭＰＥＧ方式の圧縮動画データなどのリアルタイムストリームパケットなどが想定される。
【００２５】
図１におけるホスト１１，２１とは、ＣＰＵ及びＲＡＭ等のハードウエアによる主たる情報処理部であり、ＣＰＵで起動されるアプリケーションソフトウェアや各種プロトコル処理のためのプログラムも含めたものとしている。このホスト１１，２１は、ＬＡＮ通信についていえば上記のようなパケットデータの送信処理部及び受信処理部として機能する。
またホストシステム１０，２０とは上記ホスト１１，２１とネットワークインターフェースカード１２，２２により構成されるコンピュータシステムを指す。
【００２６】
ホストシステム１０においては、パケットパーサー１３がホスト１１とネットワークインターフェースカード１２の間に介在するように設けられる。このパケットパーサー１３が、本発明でいう通信装置の判別手段及び制御手段に相当する。
ホストシステム２０におけるパケットパーサー２３も同様である。
【００２７】
コーデック１４は、ＭＰＥＧ動画データなどのリアルタイムストリームデータのパケット処理（パケットエンコード／デコード）を行う部位であり、例えばホスト１１とは別モジュールとしてホストシステム１０を含む装置に搭載される。但し、コーデック１４をソフトウエアとしてホスト１１内に搭載するような例も考えられる。
コーデック２４についても同様である。
【００２８】
このようなホストシステム１０，２０間の通信は以下のように行われる。
今、ホストシステム２０からホストシステム１０へ、パケット送信ＤＦを行うとする。
ホストシステム２０側では、ホスト２１がパケットを生成するか、あるいはコーデック２４によりＭＰＥＧリアルタイムストリームのパケットを生成する。この際、ホスト２１は、例えばＵＤＰ／ＩＰ／ＭＡＣなどの各プロトコルのパケッタイズ処理並びにヘッダ処理を行うことにもなる。
その後、ホスト４１は処理を施したパケットを、パケットパーサー２３をバイパスさせてネットワークインターフェースカード４２に転送し、ネットワークインターフェースカード４２が伝送路１００を介してホストシステム３０へパケットを送信する。つまり送信処理としては、図７で説明した従来方式と同様である。
【００２９】
一方、受信側となるホストシステム１０では、搭載しているネットワークインターフェースカード１２によって伝送路１００から受信したデータパケットは、まずパケットパーサー１３に受け渡される。
パケットパーサー１３の処理については後に詳しく述べるが、受信したデータパケットについてヘッダ解析、プロトコル判別を行い、その結果、重要パケットと非重要パケットを判別する。そしてパケット判別結果に基づいて、所定時点で受信したパケットについてのインタラプト（受信通知の割込要求）をホスト１１に対して発行する。
ホスト１１は、インタラプトに応じてパケットパーサー１３からデータパケットを読み出す。
ホスト１１は、パケットパーサー１３から読み出したパケットについて、プロトコル処理ソフトウェアとホストＣＰＵにより、ＭＡＣプロトコル／ＩＰ／ＵＤＰ／ＲＴＰを処理した後、所定のアプリケーション（パケットがリアルタイムストリームパケットであった場合はコーデック１４）へ受け渡すものとなる。
【００３０】
ここで、パケットパーサー１３は上記のように重要パケットと非重要パケットを判別したうえで、ホスト１１に対してインタラプトを異なるタイミングで通知するようにしている。これによってパケット受信が集中する場合でもホスト１１のＣＰＵの処理負担が過大にならないようにするものである。
このためのパケットパーサー１３の構成例を図２に示す。
【００３１】
パケットパーサー１３は、図２に示すように制御部１，設定値レジスタ２，ヘッダテーブル３、ヘッダ解析部４，ＲＡＭ５を備える。
制御部１及びヘッダ解析部４は、専用ハードウエアとして形成することもでき、また汎用プロセッサにおいてソフトウエアで実現することもできる。設定値レジスタ２，ヘッダテーブル３、及びＲＡＭ５は、メモリ素子やレジスタによって形成される。
【００３２】
制御部１は、ホスト１１に対するインタラプト発行、ＲＡＭ５の管理／アクセス制御、パケットデータのホスト１１への転送制御などを行う。つまりパケット受信時には、ＲＡＭ５へのバッファリングのための書込制御（ＲＡＭポインタ制御）、ヘッダ解析部５からの情報や設定値レジスタ２の情報に基づくインタラプト発行処理、及びホスト１１からの転送要求があった場合の、ＲＡＭＡ５からのパケットデータの読出及び転送制御を行う。
【００３３】
設定値レジスタ２には、例えばホスト１１からの処理等により、或る設定値ｔｈが記憶される。この設定値ｔｈは、後述する非重要パケットに関するインタラプト発行の条件として用いられる。
ヘッダテーブル３は、例えばホスト１１からの処理等により、重要パケットとすべきパケットのヘッダ情報が記憶される。例えばＡＲＰ、ＲＡＲＰ、ＩＣＭＰ、ＶＬＡＮといった、より優先的に受信処理されるべきプロトコルを識別するためのヘッダが格納されている。
【００３４】
ＲＡＭ５は、受信バッファとして用いられ、即ちネットワークインターフェースカード１２から転送された受信パケットデータがバッファリングされる。
この場合、ＲＡＭ５は、例えば領域分割設定により、アドレス０〜Ｎが第１バッファ領域５ａ、アドレスＮ＋１〜Ｍが第２バッファ領域５ｂと設定され、制御部１によって管理される。
そして、ネットワークインターフェースカード１２から転送されたパケットデータは、第１バッファ領域５ａに書き込まれるものとされる。
第２バッファ領域５ｂは、インタラプト発行を所定の条件が整うまで待機する非重要パケットを格納しておく領域とされる。
【００３５】
ヘッダ解析部４は、受信してＲＡＭ５の第１バッファに記憶されたデータパケットについてヘッダ解析を行い、それが重要パケットか非重要パケットかを判別する。具体的には受信したデータパケットのヘッダについて、ヘッダテーブル３に格納されているＡＲＰ等の重要なプロトコルのヘッダと照合して、該当するヘッダであるか否かを判別する。そして、ヘッダテーブル３に格納された重要パケットのヘッダに該当するものであった場合は、それを重要パケットとする。それ以外であれば非重要パケットとする。判別した重要パケット／非重要パケットの情報は制御部１に供給する。
【００３６】
このようなパケットパーサー１３によるパケット受信時の処理を図３で説明する。
伝送路１００を介して送信されてきたパケットデータがネットワークインターフェースカード１２により受信され、パケットパーサー１３に転送されてくると、制御部１は、そのパケットデータをＲＡＭ５の第１バッファ領域５ａに記憶させていく制御を行う。例えば制御部１は、第１バッファ領域５ａについての書込ポインタをアドレス０〜Ｎの範囲で巡回させながら、書込制御を行う。これにより、第１バッファ領域５ａとしてのアドレス０〜Ｎがリングバッファ形式で用いられて、受信パケットのデータが各アドレスにバファリングされていく。
この処理は図３には示していないが、パケット受信に応じて実行される。
【００３７】
パケット受信に伴ってパケットデータがバファリングされたら、まず図３のステップＦ１０１としてヘッダ解析部４は、取り込まれたパケットデータのヘッダ解析を行い、上記のようにヘッダテーブル３の情報を参照して、そのパケットデータが重要パケットであるか否かを判別する。
この判別結果情報は制御部１に受け渡され、制御部１は判別結果情報に応じてステップＦ１０２で処理を分岐する。
即ち、重要パケットであった場合はステップＦ１０３に進み、パケット受信に伴うホスト１１に対するインタラプト通知を無条件で実行する。
そしてステップＦ１０７に進む。
【００３８】
一方、非重要パケットであった場合は、ステップＦ１０４に進み、当該受信したパケットデータ、つまり第１バッファ領域５ａに格納したデータを、インタラプト待機のため第２バッファ領域５ｂに移し替える。
なお、制御部１は第２バッファ領域５ｂについても、書込ポインタをアドレスＮ＋１〜Ｍの範囲で巡回させながら書込制御を行い、第２バッファ領域５ｂとしてのアドレスＮ＋１〜Ｍがリングバッファ形式で用いられるようにしている。
【００３９】
そして、ステップＦ１０５では、第２バッファ領域５ｂに蓄積されたパケットデータ量が、設定値レジスタ２に記憶された設定値ｔｈを超えたか否かを確認する。超えていなければそのままステップＦ１０７に進む。つまりこの時点でインタラプトの発行を行わない。
【００４０】
なおステップＦ１０５の判断のため、制御部１は内部カウンタを設け、第２バッファ領域５ｂに格納されたデータ量のカウントを行っていればよい。例えばステップＦ１０４で第２バッファ領域５ｂにデータを移動させる際に、そのデータ量に相当する値をカウントアップしていく。
そしてステップＦ１０５では、その時点でカウントされているデータ量と、設定値ｔｈを比較する処理を行えばよい。
【００４１】
ある時点で、処理がステップＦ１０５に進んだ際に、第２バッファ領域５ｂに蓄積されたパケットデータ量が、設定値レジスタ２に記憶された設定値ｔｈを超えたと判断した場合は、ステップＦ１０６に進んで、ホスト１１に対するインタラプト通知を行う。そしてステップＦ１０７に進む。
なお、この場合は、第２バッファ領域５ｂに蓄積したパケットデータ、つまり上記カウント対象となっていたデータについてインタラプト通知を行ったため、上記カウンタをリセットする。
【００４２】
ステップＦ１０７では、次の受信パケットの存在を確認し、存在すればステップＦ１０１に戻って同様の処理を行う。存在しなければ図３の処理を終え、次回のパケット受信を待機する。
【００４３】
なお、ステップＦ１０３又はＦ１０６でインタラプト通知を行った場合は、その後の時点でホスト１１からパケットデータの転送要求が送られてくる。その場合、制御部１は、要求されたパケットをＲＡＭ５から読出、ホスト１１に対して転送する制御を行うことになる。
【００４４】
このような図３の処理により、本例では次の動作が実現される。
例えば上記ＡＲＰ、ＲＡＲＰ、ＩＣＭＰ、ＶＬＡＮといった、通信処理に重要なコントロールパケット、及びＭＰＥＧデータなどのリアルタイムストリームパケットが、ヘッダテーブル３において重要パケットとセットされているとする。すると、コントロールパケットやリアルタイムストリームパケットが受信された場合は、パケットパーサー１３は無条件でホスト１１に対してインタラプト通知を行うものとなる。
一方、テキストデータファイル、ウェブアクセスデータなどの、重要とはされていないパケットデータを受信した場合は、それらは一旦第２バッファ領域５ｂに蓄積され、それらの総データ量が設定値ｔｈを超えるまではインタラプト通知が待機される。そして総データ量が設定値ｔｈを超えた場合に、インタラプト通知の条件が満たされたとして、ステップＦ１０６のインタラプト通知が行われるものである。
【００４５】
これにより、受信パケットが到着する度にホスト１１へ通知する従来方式に比べ、ホスト１１に対するインタラプトの集中がなくなり、またホスト１１からＲＡＭ５への受信パケット読出のアクセス回数が減り、結果としてホスト１１の処理負荷が軽減される。
また、重要パケット受信の割り込み通知と非重要パケット受信の割り込み通知が分けられることにより、あるパケットの受信中に送られてきた重要パケットの処理が待たされることが無くなり、待たされることによる遅延で引き起こされていたネットワーク負荷の増大に対する改善効果も得られる。
もちろん重要なコントロールパケットやリアルタイム性が要求されるパケットが優先的に受信処理するようホストへ通知されるため、重要パケットの受信処理の確実性が高まり、通信システムとして好適である。
また、ホスト１１によるヘッダ解析処理の負担が無くなることも、ホスト１１の処理負担低減に貢献する。
またこれらのことから、ホスト１１のＣＰＵとしても処理能力の高い高価なものを採用する必要もなく、装置のコストダウンに有効である。
【００４６】
＜第２の実施の形態＞
第２の実施の形態を図４，図５で説明する。
図４は第２の実施の形態の場合のシステム構成を示している。なお、基本的な構成は図１と同一であるため、各部に同一符号を付し、重複説明を避ける。
この図４の場合、ホストシステム１０側においては、コーデック１４はホスト１１とは別モジュールで構成されることを前提とし、さらに、パケットパーサー１３はホスト１１を介在させないで受信データをコーデック１４に転送する機能（データ転送系回路）を備えるものとしている。
【００４７】
パケットパーサー１３の内部構成は上記図２と基本的に同様であるため新たに図示しないが、制御部１はコーデック１４に対するデータ転送制御機能を備えるものとなる。
またヘッダ解析部４は、重要パケット、非重要パケットの判別以外に、リアルタイムストリームパケットであるか否かの判別も行うようにしている。
ホストシステム２０側のコーデック２４及びパケットパーサー２３についても同様である。
【００４８】
図５にパケットパーサー１３のパケット受信時の処理を示す。
なお、上記図３と同一の処理ステップには同一のステップ番号を付し、詳しい説明を省略する。
この場合、パケット受信時には、ステップＦ１０１でパケットのヘッダ解析が行われ、ステップＦ１０２で重要パケット／非重要パケットの判別結果により処理が分岐される。そして非重要パケットと判別された場合は制御部１はステップＦ１０４，Ｆ１０５，Ｆ１０６として、上記図３で説明した場合と同様の処理を行うことになる。つまり第２バッファ領域５ｂに蓄積されるデータ量が設定値ｔｈ以上となるまではインタラプト通知を待機し、設定値ｔｈ以上となった時点でまとめてインタラプト通知を行う。
【００４９】
ステップＦ１０２で重要パケットと判別された場合は、制御部１はさらにステップＦ１０８で、そのデータパケットがリアルタイムストリームパケットであるか否かにより、さらに処理を分岐する。リアルタイムストリームパケットであるか否かの情報は、ヘッダ解析部４からの判別情報として制御部１に供給される。リアルタイムストリームパケットではない場合、つまり例えばＡＲＰ、ＲＡＲＰ、ＩＣＭＰ、ＶＬＡＮといったコントロールパケットであった場合は、ステップＦ１０３に進み、図３の例と同様に、制御部１は無条件でホスト１１に対するインタラプト通知を行う。
【００５０】
一方、受信パケットがＭＰＥＧデータなどのリアルタイムストリームパケットであった場合は、制御部１の処理はステップＦ１０９に進み、コーデック１４に対して受信パケットのデータ（第１バッファ領域５ａにバッファリングしたデータ）を、転送する。
【００５１】
つまりこの第２の実施の形態では、リアルタイムストリームパケットが受信された場合は、ホスト１１に対するインタラプト通知は行われずに、パケットパーサー１３から直接（ホスト１１の介在無しに）コーデック１４に受信データが転送されるものとなる。
これによって、受信パケット到着毎にホスト１１へインタラプトがあがることがさらに減少され、また、それに伴ったホスト１１からパケットパーサー１３へのアクセスも無くなる為、ホスト１１の処理負荷は上記第１の実施の形態に比べてさらに軽減される。
特に、ＭＰＥＧ動画データストリームなどのリアルタイムストリームデータがＩＰパケッタイズされたパケットを受信することは、大量のパケットを連続的に受信することになり、これに対するホスト１１の処理負担は大きい。従ってリアルタイムストリームをについての処理をホスト１１が行うことが不要となることは、ホスト１１の処理負担低減に非常に有効である。
また、逆に言えば、ホスト１１において実行中の他のタスクや他のパケット受信処理などがあっても、リアルタイムストリームパケットについて確実に受信処理できることになり、通信の確実性を向上させ、またこれはネットワーク負荷の低減も促進するものとなる。
【００５２】
なお、図５の処理例では、ヘッダ解析部４は、リアルタイムストリームパケットが受信された場合は、それを重要パケットであり、かつリアルタイムストリームパケットであるとする判別結果情報を制御部１に送るようにし、これによって制御部１では図５のステップＦ１０２，Ｆ１０８として、重要パケットとされた中でリアルタイムストリームパケットであるか否かにより処理を分岐するものとした。しかしながら、ヘッダ解析部４での判別処理としては、リアルタイムストリームパケットを重要パケットとは区別して判別しても良い。その場合、制御部１ではステップＦ１０８の処理分岐を行ってから、ステップＦ１０２の処理分岐を行うようにすればよい。
【００５３】
＜第３の実施の形態＞
第３の実施の形態を説明する。
第３の実施の形態の場合のシステム構成は図４と同様であり、つまりコーデック１４はホスト１１とは別モジュールで構成されること、及びパケットパーサー１３はホスト１１を介在させないで受信データをコーデック１４に転送する機能（データ転送系回路）を備えるものである。
【００５４】
パケットパーサー１３の内部構成は上記図２と基本的に同様であり、また第２の実施の形態で説明したように制御部１はコーデック１４に対するデータ転送制御機能を備えるものとなる。
但しヘッダ解析部４は、重要パケット、非重要パケットの判別を行わず、単に受信パケットがリアルタイムストリームパケットであるか否かの判別を行うようにしている。
またＲＡＭ５としては、特に第１バッファ領域５ａ、第２バッファ領域５ｂに分ける必要はなく、ＲＡＭ５の全域が単純にバッファ領域として用いられる。
ホストシステム２０側のコーデック２４及びパケットパーサー２３についても同様である。
【００５５】
図６にパケットパーサー１３のパケット受信時の処理を示す。
なお、上記図５と同一の処理ステップには同一のステップ番号を付し、詳しい説明を省略する。
この場合、パケット受信時には、ステップＦ１０１でパケットのヘッダ解析が行われるが、このときのヘッダ解析部４による解析によっては、受信パケットがリアルタイムストリームパケットであるか否かのみが判別される。従ってヘッダテーブル３にはリアルタイムストリームパケットを判別するためのみのヘッダ情報がセットされていればよい。
【００５６】
そして制御部１はステップＦ１０８で、、ヘッダ解析部４からの判別情報によりリアルタイムストリームパケットであるか否かに基づいて処理を分岐する。
リアルタイムストリームパケットではない場合は、ステップＦ１１０に進み、制御部１はホスト１１に対するインタラプト通知を行う。
一方、受信パケットがＭＰＥＧデータなどのリアルタイムストリームパケットであった場合は、制御部１の処理はステップＦ１０９に進み、コーデック１４に対して受信パケットのデータ（ＲＡＭ５にバッファリングしたデータ）を、転送する。
【００５７】
つまりこの第３の実施の形態では、リアルタイムストリームパケットが受信された場合は、ホスト１１に対するインタラプト通知は行われずに、パケットパーサー１３から直接（ホスト１１の介在無しに）コーデック１４に受信データが転送されるものとなる。
リアルタイムストリームパケットでない場合は、上述してきた重要パケット／非重要パケットを区別せずに、ホスト１１に対するインタラプト通知を行う。
【００５８】
従って第３の実施の形態の場合、重要パケット／非重要パケットの判別に基づいたインタラプト制御による、第１，第２の実施の形態で得られた効果は得られないが、最も処理負担の大きいリアルタイムストリームパケットについてはホスト１１は処理不要となり、その点で、従来方式に比べてホスト１１の処理負荷は軽減される。また、それによってネットワーク負荷の低減も促進される。
【００５９】
＜変形例＞
以上、本発明の実施の形態を説明したが、本発明はこれに限定されるものではなく、各種の変形例が考えられ、以下、例を説明する。
【００６０】
本発明は例えばワイヤードＬＡＮのみに適用されるものでなく、伝送路（通信メディア）をワイヤレスとしたワイヤレスＬＡＮにも適用できる。もちろんいわゆるＬＡＮと呼ばれている通信システムのみならず、多様な通信システムに適用できる。
また、実施の形態の説明では、２つのホストシステム１０、２０をモデルにしたが、実際には接続されるホストシステムがより多数になり得ることはいうまでもない。またホストシステムとしてはパーソナルコンピュータ等の形態に限らず、より大型の情報処理装置、或いはＰＤＡその他の小型情報処理装置、或いは通信機能を備えたオーディオ・ビデオ機器、携帯型或いは据え置き型の電話機、家電機器等、各種機器が考えられる。
【００６１】
また、図２の構成例においてヘッダテーブル３に格納されるヘッダ情報は、アプリケーションに応じて変更することができ、様々なアプリケーションへの適用も可能である。
即ち、重要パケットとするのは、コントロールパケットやリアルタイムストリームパケットに限らず、そのホストシステムに搭載されたアプリケーションに応じて適宜変更することが可能である。これにより、ホスト１１にプロトコル処理をさせた場合の優位点である様々なプロトコルに対応可能となる汎用性といった観点から見ても、それと同等の拡張性を持たせることができる。
【００６２】
また、特に第１の実施の形態の場合、リアルタイムストリームパケットについては、非重要パケットとすることも考えられる。ホストシステム（或いはアプリケーション）がリアルタイムストリームパケットのリアルタイム処理を重要視する装置である場合、リアルタイムストリームパケットを重要パケットとすることが適切であるが、特にリアルタイムストリームに関する処理を重要視しないホストシステム（或いはアプリケーション）の場合、リアルタイムストリームパケットを非重要パケットとすることで、ホスト１１の処理負担軽減に好適である。
【００６３】
また上記例では、ヘッダテーブル３に重要パケットのヘッダ情報をセットするとしたが、非重要パケットとすべきパケットのヘッダ情報をセットしても良い。或いは重要パケットのヘッダと非重要パケットのヘッダの両方を区別してセットしてもよい。
いずれにしても、第１，第２の実施の形態の場合では、重要パケット／非重要パケットが判別できるようにする情報がセットされ、第２，第３の実施の形態の場合は、リアルタイムストリームパケットであるか否かを判別できるようにするヘッダ情報がセットされればよい。
【００６４】
第１，第２の実施の形態においては、非重要パケットに関するインタラプト通知の条件を、蓄積データ量が設定値ｔｈを超えることとしたが、この条件設定は多様に考えられる。
例えば第２バッファ領域５ｂに蓄積する各パケットデータについて、それぞれ受信時からの時間経過を管理し、一定の待機時間を経過するたびに、他に重要パケットの受信があるか否かを判別して、なければインタラプト通知を行い、重要パケット受信があれば更に一定時間待機するなどの例も考えられる。
また、受信からの経過時間が或る時間値を超えて長くなってしまったパケットについては、その時点でインタラプト通知を行うようにすることも考えられる。
【００６５】
また設定値ｔｈを、データ量ではなく、パケット数としてもよい。即ち非重要パケットについては、設定値ｔｈとしてのパケット数が蓄積された時点でインタラプト通知を行うようにする例である。
また、パケット数、或いはデータ量としての設定値と、受信からの経過時間の両方を考慮して非重要パケットのインタラプトの発行処理を行うようにしても良い。
【００６６】
第１，第２の実施の形態では、ＲＡＭ５を第１バッファ領域５ａ／第２バッファ領域５ｂに分けたが、このような領域分けでなく、２つのメモリチップにより第１バッファ、第２バッファを設定しても良い。
さらに、これらのようなバッファ分割をせずに、アドレス管理などの手法で非重要パケットを管理しても良い。つまりＲＡＭ５内で重要パケットが記憶されたアドレスと、インタラプトの待機中である非重要パケットが記憶されたアドレスを制御部１で管理しておけば、ＲＡＭ５内でのデータ移送を不要とできる。
【００６７】
また、パケットパーサー１３ではヘッダ解析を行うものであるため、その解析情報をホスト１１に送信するようにして良い。例えば重要パケットのインタラプト通知の際に、受信パケットがＡＲＰであるのかＲＡＲＰあるのか、さらにはＩＣＭＰかＶＬＡＮか等のヘッダ解析結果までもホスト１１へ詳細に通知することで、更にホスト１１の処理負荷を軽減することも可能である。
【００６８】
【発明の効果】
以上の説明から理解されるように本発明によれば、例えばホストシステムにおいてネットワークインターフェースカードとホスト（処理手段）との間において、上記パケットパーサーとしての機能（判別手段及び制御手段、第一のステップと第二のステップ）が設けられる。そして本発明の通信装置（又は通信方法）では、受信したパケットのヘッダ解析を行って、そのパケットのプロトコルを判別し、判別した結果が重要パケットの場合、無条件で、つまり優先的に受信処理が行われるようにホスト（処理手段）へ受信通知（インタラプト）する。
そしてこれにより、受信集中時であってもホスト（処理手段）への割込処理が減少することや、ホスト（処理手段）はヘッダ処理を行なう必要が無くなり、従ってコントロールパケットやリアルタイムストリームなど優先処理を必要とするパケットを処理優先度の低いパケットに埋もれさせること無く確実に受信処理を行なうことができるという効果がある。
そしてこの効果は、ホスト（処理手段）の処理負荷の低減や、ネットワーク負荷の低減といった効果ももたらすことになる。
また従って、ホスト（処理手段）として処理速度の速い高価なＣＰＵを用いる必要はなくなり、装置のコストアップも生じさせない。
【００６９】
また、非重要パケットと判別されたパケットについては、非重要パケットとされたデータのデータ量が設定値以上となった際に、ホストに受信通知するようにすれば適切に対応できる。
また、重要パケット又は非重要パケットのヘッダ情報を記憶したテーブル情報を備え、受信したデータパケットのヘッダ情報を、上記テーブル情報に照合して、重要パケットと非重要パケットの判別を行うことで、パケット判別処理が容易であるとともに、テーブル情報の設定により、重要パケット／非重要パケットをフレキシブルに設定できる。従ってホストシステムの用途、動作環境、性能その他の事情に応じて重要パケットを設定し、最適な通信環境を構築することもできる。
【００７０】
また、受信したパケットがリアルタイムストリームパケットの場合は、ホスト（処理手段／第一の処理手段）を介さないでリアルタイムストリームパケットに対応する第二の処理手段に転送するようにすることで、ホストではリアルタイムストリームパケットに関する処理は不要となり、ホストの処理負担のさらなる低減を実現できる。もちろんこれはネットワーク負荷の低減効果も促進する。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態の通信システムのブロック図である。
【図２】実施の形態のパケットパーサーの構成のブロック図である。
【図３】第１の実施の形態のパケット受信処理のフローチャートである。
【図４】第２の実施の形態の通信システムのブロック図である。
【図５】第２の実施の形態のパケット受信処理のフローチャートである。
【図６】第３の実施の形態のパケット受信処理のフローチャートである。
【図７】従来の通信システムのブロック図である。
【図８】従来の通信システムにおけるネットワーク負荷増大の説明図である。
【図９】従来の通信装置の説明図である。
【符号の説明】
１  制御部、２  設定値レジスタ、３  ヘッダテーブル、４、ヘッダ解析部、５  ＲＡＭ、５ａ  第１バッファ、５ｂ  第２バッファ、１０，２０  ホストシステム、１１，２１  ホスト、１２，２２  ネットワークインターフェースカード、１３，２３  パケットパーサー、１４，２４  コーデック
【図１】
2004159038.tif 000003
【図２】
2004159038.tif 000004
【図３】
2004159038.tif 000005
【図４】
2004159038.tif 000006
【図５】
2004159038.tif 000007
【図６】
2004159038.tif 000008
【図７】
2004159038.tif 000009
【図８】
2004159038.tif 000010
【図９】
2004159038.tif 000011