(57)【要約】  本発明は、ネットワークのフレームから不要なヘッダ情報を除去する方法に関する。  本発明の方法は、次のことを含む。すなわち、フレームのビギニングバイトを第２バッファよりも小さいサイズの第１バッファに格納し、残りのバイトを第２バッファに格納すること、第１バッファに、不要なヘッダ情報が格納されていることを判定すること、第１バッファに格納される不要なヘッダ情報に続くフレームのバイトを、不要なヘッダ情報の上にコピーすること、第１バッファに格納されたフレームの取得されるべきバイト数を報告すること、そして、第１バッファに格納されたフレームの報告された数のバイトを取得し、第２バッファに格納されたフレームのバイトを取得することを含む。バイトのコピーは第１バッファにおいてのみ行われる。  このように、不要なヘッダ情報の除去に必要とされるプロセッササイクルは、より少なくなり、パケット受信プロセスでのレイテンシーは最小限となる。
2005515649.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークのフレームから不要なヘッダ情報を除去する方法であって、
（ａ）フレームを受信するステップ、
（ｂ）前記フレームのビギニングバイトを、第２バッファよりも小さいサイズの第１バッファ内に格納し、前記フレームの残りのバイトを前記第２バッファ内に格納するステップ、
（ｃ）不要なヘッダ情報が、前記第１バッファに格納されることを判定するステップ、
（ｄ）前記不要なヘッダ情報の位置の上に、前記第１バッファに格納される前記不要なヘッダ情報に続くフレームのバイトをコピーするステップ、
（ｅ）前記第１バッファに格納された前記フレームの取得されるべきバイト数を報告するステップ、
（ｆ）前記第１バッファに格納された前記フレームの報告された数のバイトを取得し、前記第２バッファに格納された前記フレームのバイトを取得するステップ、
を含む方法。
【請求項２】
前記格納するステップ（ｂ）は、
（ｂ１）前記第１バッファに、送信先アドレスを格納するステップ、
（ｂ２）前記第１バッファに、送信元アドレスを格納するステップ、
（ｂ３）前記第１バッファに、リミテッド・オートマティック・リピート・リクエスト（ＬＡＲＱ）を格納するステップ、
（ｂ４）前記第１バッファに、Ｑタグを格納するステップ、
（ｂ５）前記第２バッファに、長さ／タイプ情報を格納するステップ、
（ｂ６）前記第２バッファに、複数のデータバイトを格納するステップ、
（ｂ７）前記第２バッファに、フレームチェックシーケンス（ＦＣＳ）を格納するステップ、
を含む、請求項１記載の方法。
【請求項３】
前記格納するステップ（ｂ）は、
（ｂ１）前記第１バッファに、送信先アドレスを格納するステップ、
（ｂ２）前記第１バッファに、送信元アドレスを格納するステップ、
（ｂ３）前記第１バッファに、ＬＡＲＱを格納するステップ、
（ｂ４）前記第１バッファに、長さ／タイプ情報を格納するステップ、
（ｂ５）前記第１バッファに、複数のデータバイトのビギニングバイトを格納するステップ、
（ｂ６）前記第２バッファに、複数のデータバイトの残りのバイトを格納するステップ、
（ｂ７）前記第２バッファに、ＦＣＳを格納するステップ、
を含む、請求項１記載の方法。
【請求項４】
前記判定するステップ（ｃ）は、
（ｃ１）前記第１バッファに、前記ＬＡＲＱが格納されていることを判定するステップ、
を含む、請求項３記載の方法。
【請求項５】
前記コピーするステップ（ｄ）は、
（ｄ１）長さ／タイプ情報と、複数のデータバイトのビギニングバイトとを、前記第１バッファの前記ＬＡＲＱの上にコピーするステップ、
を含む、請求項３記載の方法。
【請求項６】
前記格納ステップ（ｂ）は、
（ｂ１）前記第１バッファに、送信先アドレスを格納するステップ、
（ｂ２）前記第１バッファに、送信元アドレスを格納するステップ、
（ｂ３）前記第１バッファに、Ｑタグを格納するステップ、
（ｂ４）前記第１バッファに、長さ／タイプ情報を格納するステップ、
（ｂ５）前記第１バッファに、複数のデータバイトのビギニングバイトを格納するステップ、
（ｂ６）前記第２バッファに、前記複数のデータバイトの残りのバイトを格納するステップ、
（ｂ７）前記第２バッファに、ＦＣＳを格納するステップ、
を含む、請求項１記載の方法。  
【請求項７】
前記判定するステップ（ｃ）は、
（ｃ１）前記第１バッファに、前記Ｑタグが格納されていることを判定するステップ、
を含む、請求項６記載の方法。
【請求項８】
前記コピーするステップ（ｄ）は、
（ｄ１）長さ／タイプ情報と、前記複数のデータバイトのビギニングバイトとを、前記第１バッファの前記Ｑタグの上にコピーするステップ、
を含む、請求項６記載の方法。
【請求項９】
前記格納ステップ（ｂ）は、
（ｂ１）前記第１バッファに、送信先アドレスを格納するステップ、
（ｂ２）前記第１バッファに、送信元アドレスを格納するステップ、
（ｂ３）前記第１バッファに、長さ／タイプ情報を格納するステップ、
（ｂ４）前記第１バッファに、複数のデータバイトのビギニングバイトを格納するステップ、
（ｂ５）前記第２バッファに、前記複数のデータバイトの残りのバイトを格納するステップ、
（ｂ６）前記第２バッファに、ＦＣＳを格納するステップ、
を含む、請求項１記載の方法。
【請求項１０】
前記判定するステップ（ｃ）は、
（ｃ１）前記第１バッファに、不要なヘッダ情報が格納されていないことを判定するステップ、
を含む、請求項９記載の方法。
【請求項１１】
ネットワークのフレームから、不要なヘッダ情報を除去するためのコンピュータ命令を記憶したコンピュータ読取り可能な媒体であって、前記コンピュータ命令は、
（ａ）フレームのビギニングバイトを、第２バッファよりも小さいサイズの第１バッファに格納し、フレームの残りのバイトを、前記第２バッファに格納する命令、
（ｂ）不要なヘッダ情報が、前記第１バッファに格納されていることを判定する命令、
（ｃ）前記不要なヘッダ情報の位置の上に、前記第１バッファに格納される前記不要なヘッダ情報に続くフレームのバイトをコピーする命令、
（ｄ）上位層に、前記第１バッファに格納された前記フレームのバイト数を報告する命令、
（ｅ）前記第１バッファに格納された前記フレームの報告された数のバイトを取得し、前記第２バッファに格納された前記フレームの前記バイトを取得する命令、
を含む、媒体。
【請求項１２】
ネットワークのフレームのビギニングバイトを格納する第１バッファと、
前記フレームの残りのバイトを格納する第２バッファと、
ドライバと、を有しており、
前記フレームのビギニングバイトは、不要なヘッダ情報を含んでおり、
前記第１バッファのサイズは、前記第２バッファよりも小さくされており、
前記ドライバは、前記フレームから前記不要なヘッダ情報を除去する、
システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークで受信したデータパケットに関する。特に、そのネットワークで受信したデータパケットからの不要なヘッダ情報の除去に関する。
【本発明の背景】
【０００２】
ホームネットワークは、より一般的で、家庭内のコンピュータの接続に望ましいものになってきている。
ホームネットワークの一つのタイプは、その家の中のコンピュータ間のコミュニケーションのため、民住用の家に設置されている電話回線を使用する、ホームフォンラインネットワークである。
The Home Phone Line Networking Alliance（ＨＰＮＡ）は、ホームフォンラインネットワークの動作を標準化するために、その仕様を公表している。
【０００３】
図１は、ＨＰＮＡの標準バージョン２．０による、フレームフォーマットを示す。このフレームは、既知の６４シンボルのプリアンブル１０２およびフレーム制御ビット１０４を含む。フレーム制御ビット１０４は、変調フォーマットに関する情報、および巡回冗長検査（ＣＲＣ）ビットのような、他の様々な制御情報を含んでいる。
このフレームはさらに、６バイトの送信先アドレス１０６、６バイトの送信元アドレス１０８、８バイトのリミッティド・オートマティック・リピート・リクエスト（Limited automatic repeat request）（以下、ＬＡＲＱとする。）１１０、４バイトのＱタグ１１２、および２バイトの長さ／タイプの情報１１４を含む。
ＬＡＲＱ１１０は、リンクレイヤにプライオリティ情報を伝えて、フレーム再送信の速度を上げるために否定応答プロトコルを提供する。
Ｑタグ１１２は、データフレームを優先させるために使用することができる情報を含む。プリアンブル１０２からＱタグ１１２は、そのフレームの「ヘッダ」を構成する。フレームの残りは、４６から１５００バイトの間であるデータ１１６を構成する。フレームのエラーをチェックするために使用される４バイトのフレームチェックシーケンス（ＦＣＳ）１１８が、データ１１６に続く。
一つのフレームは、ＬＡＲＱ１１０およびＱタグ１１２の両方を有する必要はない。フレームは、Ｑタグ１１２なしにＬＡＲＱ１１０、またはＬＡＲＱ１１０なしにＱタグ１１２を持つか、もしくはＬＡＲＱ１１０およびＱタグ１１２のどちらも持たないものとすることができる。
【０００４】
図２は、ホームフォンラインネットワーク用の典型的なハードウェアソフトウェアインターフェースを示す。
このインターフェースは、電話線からフレームを受信するＨＰＮＡ互換のネットワークインターフェイスコントローラ（ＮＩＣ）２０６を含む。
ＮＩＣ２０６は、典型的にホストコンピュータ上にあるＨＰＮＡ互換のドライバソフトウェア２０４にフレームを送信する。
その後、ドライバソフトウェア２０４は、ネットワークドライバインターフェイス規約（ＮＤＩＳ）のような上位層のソフトウェア２０２にフレームを送信する。
【０００５】
しかしながら、上位層２０２は、ＬＡＲＱ１１０および／またはＱタグ１１２を認識しない可能性があり、また、誤ってフレームを無効のものとして判断する可能性がある。
したがって、ドライバソフトウェア２０４がフレームを上位層のソフトウェア２０２へ送信する前に、ＬＡＲＱ１１０およびＱタグ１１２をフレームから除去する必要がある。
【０００６】
従来、ＮＩＣ２０６がフレームを転送する場合、そのフレームは、上位層２０２の単一のバッファに格納される。
典型的には、ＬＡＲＱ１１０とＱタグ１１２をそのフレームから除去するために、そのＬＡＲＱ１１０とＱタグ１１２の前後の全バイトは、バイト間のギャップを設けずに個別のバッファにコピーされる。
しかしながら、これらのバイトを全てコピーすることは、貴重なプロセッササイクルを浪費し、パケット受信プロセスに不所望なレイテンシーを加える。
【０００７】
従って、ネットワークのフレームから不要なヘッダ情報を除去する、改良された方法およびシステムが必要とされている。本発明は、そのような要求に取り組むものである。
【発明の概要】
【０００８】
ネットワークのフレームから不要なヘッダ情報を除去する方法が開示される。
本発明の方法は、次のことを含む。すなわち、フレームの始めの方のバイト（beginning bytes）（以下、ビギニングバイトという。）を第２バッファよりも小さいサイズの第１バッファに格納し、残りのバイトを第２バッファに格納すること、第１バッファに不要なヘッダ情報が格納されていることを判定すること、第１バッファに格納されている不要なヘッダ情報に続くフレームのバイトを、不要なヘッダ情報の上にコピーすること、第１バッファに格納されたフレームの取得されるべきバイト数を報告すること、そして、第１バッファに格納された報告された数のフレームのバイトを取得し、第２バッファに格納されたフレームのバイトを取得すること、を含む。バイトのコピーは第１バッファの中でだけ行われる。
このように、不要なヘッダ情報の除去に必要とされるプロセッササイクルはより少なくなり、パケット受信プロセスでのレイテンシーは最小限となる。
【発明の詳細な説明】
【０００９】
本発明は、ネットワークのフレームから不要なヘッダ情報を除去する、改良された方法およびシステムを提供する。
以下の説明は、当業者が本発明を実施できるように記載され、また、特許出願とその要件の下で提供される。
好ましい実施例に対する様々な変更は、当業者に極めて明白である。また、ここの一般的な原則は、他の実施例に適用される。
したがって、本発明は、開示された実施例に制限されないが、ここに記述された原則および構造と一致する最も広い範囲に与えられる。
【００１０】
本発明の特徴についてより詳しく説明するために、以下の説明と共に、図３ないし８を参照して頂きたい。
【００１１】
本発明の方法およびシステムは、ネットワークの各フレームを格納する第１および第２バッファを使用する。第１バッファは、第２バッファよりサイズが小さい。
フレームからＬＡＲＱおよびＱタグを取り除くためのバイトのコピーは、もっぱらより小さなバッファで行われる。
フレームが上位層２０２へ転送される場合、プリアンブル１０２およびフレーム制御ビット１０４のどちらも転送されない。
代わりに、送信先アドレス１０６で始まり、ＦＣＳ１１８で終わるフレーム部分だけが、上位層２０２へ転送される。
第１バッファが一杯になるまで、フレームのビギニングバイトは、第１バッファに格納される。フレームの残りのバイトは、第２バッファに格納される。
【００１２】
好ましい実施例では、第１および第２バッファは、受信ディスクリプタ・リングによって管理される。図３は、本発明による方法とシステムで利用される受信ディスクリプタ・リングの好ましい実施例を示す。受信ディスクリプタ・リング３０２は、複数のディスクリプタ３０４ないし３１０を含む。
第１ディスクリプタ３０４は、第１バッファ３１６を指すポインタ３１２および第１バッファ３１６の長さ３１４を有する。
好ましい実施例では、第１バッファは２４バイトのサイズを持っており、これは、最大限のヘッダのサイズである。すなわち、送信先アドレス１０６ないしＱタグ１１２である。
第２ディスクリプタ３０６は、第２バッファ３２２を指すポインタ３１８および第２のバッファ３２２の長さ３２０を有する。
好ましい実施例では、第２バッファは、１５０６バイトのサイズを持っており、これは、長さ／タイプの情報１１４、データ１１６およびフレームチェックシーケンス（ＦＣＳ）１１８の最大限サイズである。
フレームが受信されると、最初の２４バイトは第１バッファ３１６に格納され、残りのバイトは第２バッファ３２２に格納される。
次のフレームの最初の２４バイトは、次のディスクリプタ３０８によって示されたバッファに格納される。そして、残りのバイトは次のディスクリプタ３１０によって示されたバッファに格納される。以下、同様に格納される。
一旦、各ディスクリプタによって示されたバッファが使用されると、受信プロセスは、第1ディスクリプタ３０４に戻り、バッファを再使用する。したがって、受信ディスクリプタのデータ構造３０２は「リング」である。
【００１３】
図４は、本発明によって、ネットワークのフレームから不要なヘッダ情報を除去する方法の好ましい実施例を示すフローチャートである。
まず、フレームが受信される（ステップ４０２）。
フレームのビギニングバイトは、第１バッファ３１６に格納され、また、残りのバイトは、第２バッファ３２２に格納される（ステップ４０４）。第１バッファ３１６のサイズは第２バッファ３２２より小さい。ヘッダはもっぱら第1バッファ３１６に格納されるので、バッファ３１６，３２２のサイズは、このように設定される。
その後、ドライバソフトウェア２０４は、第１バッファ３１６に格納されたバイトを調査し、それが不要なヘッダ情報を含むか判定する（ステップ４０６）。
不要なヘッダ情報は、ＬＡＲＱ１１０および／またはＱタグ１１２を含む。
その後、ドライバソフトウェア２０４は、第１バッファ３１６に格納される不要なヘッダ情報の後のフレームのバイトを、不要なヘッダ情報の位置の上にコピーする（ステップ４０８）。
それからドライバソフトウェア２０４は、第１バッファ３１６に格納された、取得されるべきフレームのバイト数を報告する（ステップ４１０）。
コピー後に、第１バッファ３１６に格納されたフレームバイトが、バッファ３１６のサイズ未満でありうるので、この報告は必要である。
その後、上位層２０２は、２つのバッファ３１６，３２２から、第１バッファ３１６に格納されたフレームの報告された数のバイト、および第２バッファ３２２に格納されたフレームのバイトを、バイト間のギャップなしに取得する（ステップ４１２）。
【００１４】
図５ないし図８は、本発明によって、ネットワークのフレームから不要なヘッダ情報を除去する方法の例を示す。
好ましい実施例では、ヘッダは、以下に示す４つの可能なシナリオのうちの１つを含む。
（１）ＬＡＲＱ１１０およびＱタグ１１２を含むシナリオ。
（２）Ｑタグ１１２ではなく、ＬＡＲＱ１１０を含むシナリオ。
（３）ＬＡＲＱ１１０ではなく、Ｑタグ１１２を含むシナリオ。
（４）ＬＡＲＱ１１０もＱタグ１１２のどちらも含まないシナリオ。
【００１５】
図５は、ヘッダがＬＡＲＱ１１０およびＱタグ１１２を含んでいる、第１のシナリオを示す。
このフレームを受信すると（ステップ４０２）、フレームの最初の２４バイトは第１バッファ３１６に格納され、フレームの残りのバイトは、第２バッファ３２２に格納される（ステップ４０４）。
したがって、第１バッファ３１６は６バイトの送信先アドレス１０６、６バイトの送信元アドレス１０８、８バイトのＬＡＲＱ１１０、および４バイトのＱタグ１１２を含む。
第２バッファ３１８は、２バイトの長さ／タイプの情報１１４、ｎバイトのデータ１１６、および４バイトのＦＣＳ１１８を含む。
ドライバソフトウェア２０４は、ステップ４０６において、第１バッファ３１６のバイトを検査し、それが不要なヘッダ情報、すなわち、ＬＡＲＱ１１０およびＱタグ１１２を含んでいることを判定する。
ＬＡＲＱ１１０およびＱタグ１１２の後に来るフレームのバイトは第１バッファ３１６に格納されないので、ステップ４０８によるコピーは行なわれない。
その後、ドライバソフトウェア２０４は、ステップ４１０によって、第１バッファ３１６に格納されたフレームのバイト数を報告する。
図５の中で示されたシナリオについては、バイト数は１２である。すなわち、送信先アドレス１０６の６バイトと、送信元アドレス１０８の６バイトを加えた数である。
その後、ステップ４１２によって、上位層２０２は、第１バッファ３１６に格納されたフレームの報告された数のバイト、すなわち、最初の１２バイト、そして第２バッファの中に格納されたフレームのバイトを取得する。
このようにして取得されたバイトは、送信先アドレス１０６、送信元アドレス１０８、長さ／タイプの情報１１４、データ１１６およびＦＣＳ１１８データである。
このようにして、ＬＡＲＱ１１０およびＱタグ１１２は、上位層２０２によって取得されるフレームから除去される。
【００１６】
図６は、ヘッダがＱタグ１１２ではなく、ＬＡＲＱ１１０を含んでいる、第２のシナリオを示す。
このフレームを受信すると（ステップ４０２）、フレームの最初の２４バイトは第１バッファ３１６に格納され、フレームの残りのバイトは、第２バッファ３２２に格納される（ステップ４０４）。
したがって、第１バッファ３１６は６バイトの送信先アドレス１０６、６バイトの送信元アドレス１０８、８バイトのＬＡＲＱ１１０、２バイトの長さ／タイプの情報１１４およびデータ１１６の最初の２バイト６０２を含む。
第２バッファ３２２は、データ１１６の残っているバイト６０４および４バイトのＦＣＳ１１８を含む。
ドライバソフトウェア２０４は、ステップ４０６によって、第１バッファ３１６中に格納されたバイトを検査し、それが不要なヘッダ情報、すなわち、ＬＡＲＱ１１０を含んでいることを判定する。
ドライバソフトウェア２０４は、次に、ステップ４０８によって、第１バッファ３１６に格納されたＬＡＲＱ１１０の後にくるフレームのバイトをＬＡＲＱ１１０の上にコピーする。
このシナリオでは、長さ／タイプの情報１１４およびデータバイト６０２がＬＡＲＱ１１０の上にコピーされる。
その後、ドライバソフトウェア２０４は、ステップ４１０によって、第１バッファ３１６に格納されたフレームのバイト数を報告する。
図６の中で示されたシナリオについては、バイト数は１６である。すなわち、送信先アドレス１０６の６バイトに、送信元アドレス１０８の６バイト、長さ／タイプの情報１１４の２バイト、およびデータ１１６の２バイト６０２である。
その後、ステップ４１２によって、上位層２０２は、第1バッファ３１６に格納されたフレームの報告された数のバイト、すなわち、最初の１６バイト、そして第２バッファ３２２の中に格納されたフレームのバイトを取得する。
このようにして取得されたバイトは、送信先アドレス１０６、送信元アドレス１０８、長さ／タイプの情報１１４、データ１１６およびＦＣＳ１１８である。
このようにして、ＬＡＲＱ１１０は、上位層２０２によって取得されるフレームから除去される。
【００１７】
図７は、ヘッダがＬＡＲＱ１１０ではなく、Ｑタグ１１２を含んでいる、第３のシナリオを示す。
このフレームを受信すると（ステップ４０２）、フレームの最初の２４バイトは第１バッファ３１６に格納され、フレームの残りのバイトは、第２バッファ３２２に格納される（ステップ４０４）。
したがって、第１バッファ３１６は６バイトの送信先アドレス１０６、６バイトの送信元アドレス１０８、４バイトのＱタグ１１２、２バイトの長さ／タイプの情報１１４およびデータ１１６の最初の６バイト７０２を含む。
第２バッファ３２２は、データ１１６の残りのバイト７０４および４バイトのＦＣＳ１１８を含む。
ドライバソフトウェア２０４は、ステップ４０６によって、第１バッファ３１６中に格納されたバイトを検査し、それが不要なヘッダ情報、すなわち、Ｑタグ１１２を含んでいることを判定する。
ドライバソフトウェア２０４は、次に、ステップ４０８によって、第１バッファ３１６に格納されたＱタグ１１２の後にくるフレームのバイトをＱタグ１１２の上にコピーする。
このシナリオでは、長さ／タイプの情報１１４およびデータバイト７０２がＱタグ１１２の上にコピーされる。
その後、ドライバソフトウェア２０４は、ステップ４１０によって、第１バッファ３１６に格納されたフレームのバイト数を報告する。
図７で示されたシナリオについては、バイト数は２０である。すなわち、送信先アドレス１０６の６バイトに、送信元アドレス１０８の６バイト、長さ／タイプの情報１１４の２バイト、およびデータ１１６の６バイト７０２である。
その後、ステップ４１２によって、上位層２０２は、第1バッファ３１６に格納されたフレームの報告された数のバイト、すなわち、最初の２０バイト、そして第２バッファ３２２の中に格納されたフレームのバイトを取得する。
このようにして取得されたバイトは、送信先アドレス１０６、送信元アドレス１０８、長さ／タイプの情報１１４、データ１１６およびＦＣＳ１１８である。
このようにして、Ｑタグ１１２は、上位層２０２によって取得されるフレームから、除去される。
【００１８】
図８は、ヘッダがＬＡＲＱ１１０もＱタグ１１２も含んでいない、第４のシナリオを示す。
このフレームを受信すると（ステップ４０２）、フレームの最初の２４バイトは第１バッファ３１６に格納され、フレームの残りのバイトは、第２バッファ３２２に格納される（ステップ４０４）。
したがって、第１バッファ３１６は６バイトの送信先アドレス１０６、６バイトの送信元アドレス１０８、２バイトの長さ／タイプの情報１１４およびデータ１１６の最初の１０バイト８０２を含む。
第２バッファ３１８は、データ１１６の残りのバイト８０４および４バイトのＦＣＳ１１８を含む。
ドライバソフトウェア２０４は、ステップ４０６によって、第１バッファ３１６中に格納されたバイトを検査し、それが不要なヘッダ情報を全く含んでいないことを判定する。
ドライバソフトウェア２０４は、次に、ステップ４１０によって、第１バッファ３１６に格納されたフレームのバイト数を報告する。
図８の中で示されたシナリオについては、バイト数は２４である。すなわち、送信先アドレス１０６の６バイトに、送信元アドレス１０８の６バイト、長さ／タイプの情報１１４の２バイト、およびデータ１１６の１０バイト８０２である。
その後、ステップ４１２によって、上位層２０２は、第1バッファ３１６に格納されたフレームの報告された数のバイト、すなわち、２４バイト、そして第２バッファ３２２の中に格納されたフレームのバイトを取得する。
このようにして取得されたバイトは、送信先アドレス１０６、送信元アドレス１０８、長さ／タイプの情報１１４、データ１１６およびＦＣＳ１１８である。
【００１９】
ネットワークのフレームから不要なヘッダ情報を除去する、改良された方法およびシステムが開示された。
本発明は、ネットワークの各フレームを格納するために第１および第２バッファを使用する。
第１バッファのサイズは、第２バッファよりも小さい。
フレームから不要なヘッダ情報を除去するためのバイトのコピーは、もっぱら小さい方のバッファで起こる。
この方式では、不要なヘッダ情報の除去に必要とされるプロセッササイクルは、より少なくなり、パケット受信プロセスでのレイテンシーを最小限にする。
【００２０】
本発明は、以上の実施形態に従って記載されたが、当業者は、これらの実施形態について、本発明の趣旨および範囲内で様々な変形が可能であることを容易に認識できるだろう。
従って、当業者なら、添付の特許請求の範囲の趣旨及び範囲から逸脱することなく、数多くの変更は可能であろう。
【図面の簡単な説明】
【００２１】
【図１】ＨＰＮＡ標準バージョン２．０によるフレームフォーマットを示す。
【図２】ホームフォンラインネットワーク用の典型的なハードウェア／ソフトウェア間のインターフェースを示す。
【図３】本発明による方法とシステムで利用される受信ディスクリプタ・リングの好ましい実施例を示す。
【図４】本発明に従ってネットワークのフレームから不要なヘッダ情報を除去する方法の好ましい実施例を示すフローチャートである。
【図５】本発明に従ってネットワークのフレームから不要なヘッダ情報を除去する方法の実施例を示す。
【図６】本発明に従ってネットワークのフレームから不要なヘッダ情報を除去する方法の実施例を示す。
【図７】本発明に従ってネットワークのフレームから不要なヘッダ情報を除去する方法の実施例を示す。
【図８】本発明に従ってネットワークのフレームから不要なヘッダ情報を除去する方法の実施例を示す。
【図１】
2005515649.tif 000003
【図２】
2005515649.tif 000004
【図３】
2005515649.tif 000005
【図４】
2005515649.tif 000006
【図５】
2005515649.tif 000007
【図６】
2005515649.tif 000008
【図７】
2005515649.tif 000009
【図８】
2005515649.tif 000010
【国際調査報告】
2005515649.tif 000011
2005515649.tif 000012
2005515649.tif 000013