JP2010045767A - ネットワーク処理装置及びその処理方法 - Google Patents

Abstract

【課題】ネットワーク処理装置において、フラグメント化されたＩＰデータグラムをリアセンブル処理する際に、使用するリソースの浪費を削減する。
【解決手段】フラグメント化されたＩＰデータグラムを受信し、そのＩＰデータグラムをリアセンブル処理する。受信したＩＰデータグラムのリアセンブル処理が完了したＩＰデータグラムを特定する情報を保持する。そして、リアセンブル処理する際に、保持された情報で特定されるＩＰデータグラムを受信した場合、そのＩＰデータグラムをリアセンブル処理しない。
【選択図】図９

Description

本発明は、フラグメント化されたＩＰデータグラムを受信し、そのＩＰデータグラムをリアセンブル処理する技術に関する。

従来、ネットワークプロトコル処理の一環として、フラグメント処理されたＩＰデータグラムのリアセンブル処理が行われている。ＩＰデータグラムのフラグメント処理方法及びリアセンブル処理方法に関しては、RFC791 Internet Protocolに記載されている。

ＩＰデータグラムの受信機器において、フラグメント処理されたＩＰデータグラムを受信した場合、当該ＩＰデータグラムのリアセンブル処理を開始する。具体的なリアセンブル処理方法は、上記RFC791に記載されているため詳細は割愛する。

通常、ＩＰデータグラムは、送信機器がＩＰデータグラムを送出する際に、通信経路に設定されているデータグラムサイズより大きい場合にフラグメント処理される。この送信機器には、ネットワークコネクションの送信元機器だけではなく、通信経路上に存在する中継機器（ルータ）も含まれる。

中継機器は、一旦受信したＩＰデータグラムを解析し、適切な経路上に再送出する役目を担う。そして、送出時に送信元機器と同様に、フラグメント処理が必要な場合はフラグメント処理を施してＩＰデータグラムを送出する。

また、中継機器は通信経路の決定や到達保証等の役割も担う。これに関しては、様々なアルゴリズムが用いられているが、その中にはＩＰデータグラムを異なる経路上に多重に送出する手法や、同じＩＰデータグラムを複数回繰り返し送出する手法なども存在する。そのため、中継機器を経由して送信されるＩＰデータグラムは、先頭から順番に並んでいないばかりではなく、搭載ペイロードの一部もしくは全てが重複するようなフラグメントＩＰデータグラム群となって到着する可能性がある。また、その到着タイミングも比較的まとまった時間に集中する場合もあれば、一部のＩＰデータグラムが所定時間経由した後に到着する可能性もある（例えば、特許文献１参照）。

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

上述したように、ＩＰデータグラムの受信機器では、フラグメント化されたＩＰデータグラムを受信すると、リアセンブル処理を開始するためにリソースを確保する。しかし、通信経路上に中継機器が存在する場合には、既にリアセンブル処理が完了したＩＰデータグラムの（重複した）フラグメントＩＰデータグラムが後から到着することがある。

また、リアセンブルタイマがタイムアウトし、リソースを解放してしまった後に、当該ＩＰデータグラムの一部であるフラグメントＩＰデータグラムが到着することもある。

このような状況が発生すると、受信機器では再度、リアセンブル処理を開始するため、リソースを確保してしまう。しかしながら、上述のような状況では当該リアセンブル処理が完了することはほぼあり得ない。つまり、完了しない可能性の高いリアセンブル処理のために、次にリアセンブルタイマがタイムアウトするまでリソースを確保してしまうこととなる。

このリソースの浪費は、リソースの枯渇を引き起こす原因となり、受信してもリアセンブル処理を行えず、ＩＰデータグラムを破棄しなければならない事態に繋がる。これは、システム全体のパフォーマンス低下を引き起こす可能性がある。特に、組み込みシステムなどのメモリサイズが限られているプラットフォームでは、より影響度が大きい。

一方、これに対応するため、同時に処理可能なリアセンブル処理数を増加（リソースの増加）させると、コストが大幅に増加してしまう。

本発明は、フラグメント化されたＩＰデータグラムをリアセンブル処理する際に、使用するリソースの浪費を削減することを目的とする。

本発明は、ネットワーク処理装置であって、
フラグメント化されたＩＰデータグラムを受信し、該ＩＰデータグラムをリアセンブル処理する処理手段と
リアセンブル処理対象外のＩＰデータグラムを特定する情報を保持する保持手段とを有し、
前記処理手段は、前記保持手段に保持された情報で特定されるＩＰデータグラムを受信した場合、該ＩＰデータグラムをリアセンブル処理しないことを特徴とする。

本発明によれば、フラグメント化されたＩＰデータグラムをリアセンブル処理する際に、使用するリソースの浪費を削減することが可能となる。

第一の実施形態におけるネットワークプロトコル処理装置の構成の一例を示すブロック図である。 ＲＡＭ１０３内のデータを模式的に表した図である。 リアセンブル処理対象管理テーブル２０２に格納された管理エントリを詳細に示す図である。 ビットテーブル領域２０３に格納されているビットテーブルを詳細に示した図である。 リアセンブルバッファ領域２０４に格納されているリアセンブルバッファを詳細に示した図である。 リアセンブル初期化処理の処理手順を示すフローチャートである。 リアセンブル通常処理の処理手順を示すフローチャートである。 リアセンブル終了処理の処理手順を示すフローチャートである。 第一の実施形態におけるＩＰデータグラムの受信処理を示すフローチャートである。 第二の実施形態におけるＩＰデータグラムの受信処理を示すフローチャートである。

以下、図面を参照しながら発明を実施するための形態について詳細に説明する。

［第一の実施形態］
図１は、第一の実施形態におけるプロトコル処理装置の構成の一例を示すブロック図である。図１において、ＣＰＵ１０１は、後述するＲＯＭに格納された制御プログラム（ソフトウェア）に従ってＴＣＰ／ＩＰネットワークのプロトコル処理を実行する。ＲＯＭ１０２にはＣＰＵ１０１が実行するソフトウェアが格納されている。ＲＡＭ１０３はＣＰＵ１０１がプロトコル処理を実行時に、ワークエリアとして使用される。

ＭＡＣ（メディアアクセス制御）１０４は、ＯＳＩ参照モデルの第２層に相当するデータリンク層の一部である通信プロトコルである。ＰＨＹ（物理層）１０５は、ＯＳＩ参照モデルの第１層に相当するプロトコル処理及び電気信号を扱うハードウェアである。ＤＭＡＣ（Direct Memory Access Controller）１０６はＴＣＰ／ＩＰネットワーク通信で送受信するデータのＲＡＭ１０３とＭＡＣ１０４との間の転送を管轄する。バス１０７はＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＭＡＣ１０４、ＤＭＡＣ１０６を相互接続する。

タイマ１０８は、プロトコル処理で必要となる複数種類のタイマ（例えば、リアセンブルタイマ、再送タイマなど）を同時に計時する機能を提供する。

尚、ＲＡＭ１０３は安価なＤＲＡＭ（オフチップ）で実現される場合が一般的であるが、より高速なオンチップＳＲＡＭで実現しても良い。しかし、オンチップＳＲＡＭは高価である。そのため、本実施形態で想定しているＲＡＭ１０３に格納するデータ全てを格納可能なサイズ分を搭載するのは難しい可能性もある。このような場合には、安価であるが低速なＤＲＡＭと、高価であるが高速なオンチップＳＲＡＭとの組み合わせで実現するのが適切である。

即ち、頻繁にアクセスするデータやプロトコル処理性能に大きく影響するデータなどを高速なオンチップＳＲＡＭに配置し、その他のデータをＤＲＡＭに配置するという形態である。本実施形態は、ＤＲＡＭ及びオンチップＳＲＡＭ、その他の記憶媒体の何れで実現されても良く、全てを包含しＲＡＭ１０３と呼ぶこととする。

ここで、ＲＡＭ１０３は、ＣＰＵ１０１のワークエリアとして使用されるだけでなく、ＴＣＰ／ＩＰネットワークプロトコル処理の実行時に必要となるデータの格納領域としても使用される。そのデータには、ＴＣＰ／ＩＰネットワーク通信で送受信されるデータ、フラグメントブロックビットテーブル、フラグメントブロックビットテーブル管理情報のテーブルなどが含まれる。

尚、このフラグメントブロックビットテーブルをビットテーブルと呼び、フラグメントブロックビットテーブル管理情報のテーブルを管理テーブルと呼ぶ。また、管理テーブルに格納される各ビットテーブルの管理情報を管理エントリと呼ぶ。このビットテーブルはビットマップテーブルとも呼ばれる。

図２は、ＲＡＭ１０３内のデータを模式的に表した図である。図２では、本発明を説明するために必要なデータのみを示し、プロトコル処理を実現するために必要なデータは他にも存在するが、図示していない。不図示のデータは、例えばＣＰＵ１０１が処理するワークデータや送信ＩＰデータグラム本体などのデータである。

図２において、受信したＩＰデータグラムは一旦受信データ領域２０１に格納される。リアセンブル処理対象管理テーブル２０２には、各ビットテーブルの管理情報である管理エントリが格納される。管理エントリは、関連付けられたビットテーブルと共に、主にリアセンブル処理の開始時に生成され、リアセンブル処理終了まで、リアセンブル処理対象のＩＰデータグラムの情報を保持する。

ビットテーブル領域２０３には、ビットテーブル本体が格納される。全てのビットテーブルは所定の管理エントリに一対一で関連付けられている。リアセンブルバッファ領域２０４には、リアセンブル処理中のＩＰデータグラムのペイロードデータが格納される。

リアセンブル処理対象外管理テーブル２０５には、リアセンブル処理を行わない（対象外の）ＩＰデータグラムの管理情報である管理エントリが格納される。このリアセンブル処理対象外管理テーブル２０５には、リアセンブル処理が完了したＩＰデータグラム及びリアセンブル処理でタイムアウトしたＩＰデータグラムの管理情報が一定期間格納される。この管理情報の使用方法、登録するタイミング及び削除するタイミングの詳細については、更に後述する。

次に、リアセンブル処理対象管理テーブル２０２内の管理エントリ、ビットテーブル領域２０３内のビットテーブル、リアセンブルバッファ領域２０４内のリアセンブルバッファの関係を、図３〜図５を用いて説明する。

図３は、リアセンブル処理対象管理テーブル２０２に格納された管理エントリを詳細に示す図である。図３において、３０１は送信元アドレスであり、受信されたＩＰヘッダに格納されている送信元アドレス（Source Address）フィールドの値に一致する。３０２は宛先アドレスであり、同じくＩＰヘッダの宛先アドレス（Destination Address）に一致する。３０３は識別子であり、同じくＩＰヘッダの識別子（Identifier）に一致する。

送信元アドレス３０１、宛先アドレス３０２、識別子３０３の各情報は、リアセンブル処理対象のＩＰデータグラムを特定するために使用される。これは、ＩＰデータグラムが送信元の機器やルータによってフラグメント化される場合、フラグメント前のＩＰデータグラムの３フィールドがフラグメント後のＩＰデータグラムのＩＰヘッダの３フィールドにコピーされるためである。

そのため、受信機器では、上述の３フィールドが同一であるＩＰデータグラムに対してリアセンブル処理を行わなければならず、３フィールドが一致しないＩＰデータグラムのリアセンブル処理は、別々の処理として実施しなければならない。

本実施形態では、複数のＩＰデータグラムに対するリアセンブル処理を並列に行うことを想定している。そこで、管理エントリは、関連付けられたビットテーブルが何れのＩＰデータグラムのリアセンブル処理に使用されているかを特定するために、３フィールドの情報を保持している。

図３において、３０４はビットテーブルポインタであり、当該管理エントリに関連付けられたビットテーブル領域２０３の格納先アドレスを示す情報である。３０５はリアセンブルバッファポインタであり、当該管理エントリに関連付けられているリアセンブルバッファ領域２０４の格納先アドレスを示す情報である。

図４は、ビットテーブル領域２０３に格納されているビットテーブルを詳細に示した図である。図４において、４０１は初期化時のビットテーブル本体であり、４０２は所定のリアセンブル処理中のビットテーブル本体である。ビットテーブルのビット４０１−１〜４０１−５、４０２−１〜４０２−５は、それぞれペイロードデータが受信済みか否かを示し、“１”がセットされている場合は受信済みを示す。これに対して、“０”がセットされている場合は未受信であることを示す。また、ビットテーブルの初期化時は、全てのペイロードデータが未受信であるため、全ビットが“０”にセットされている。

図５は、リアセンブルバッファ領域２０４に格納されているリアセンブルバッファを詳細に示した図である。図５において、５０１は初期化時のリアセンブルバッファの状態であり、全て無効データを示している。５０２は処理中のリアセンブルバッファの状態であり、図４に示すビットテーブル４０２で受信済みのビットテーブルに対応するバッファには有効データが格納されている。つまり、リアセンブルバッファの単位領域５０１−１〜５０１−５、５０２−１〜５０２−５はそれぞれペイロードデータ格納領域であり、対応するビットテーブルのビットが受信済みを示していれば、受信済みのペイロードデータが格納されている。尚、初期化時は、全てのペイロードデータが未受信であるため、ビットテーブルの全ビットが“０”にセットされている。このときリアセンブルバッファは全ての単位領域が無効データとなっている。

ビットテーブルの各ビットはフラグメントの最小単位である８バイトを意味している。例えば、図４に示す処理中の４０２でビット４０２−１に“１”がセットされているのは、フラグメント前のＩＰデータグラムのペイロードのうち先頭から８バイト分のデータが既に受信されていることを示している。つまり、図５に示す単位領域５０２−１に有効なペイロードデータが格納されていることを示している。

また同様に、ビット４０２−４に“１”がセットされているのは、フラグメント前のＩＰデータグラムのペイロードのうち、先頭からのオフセット２４バイトから８バイト分のデータが既に受信されていることを示している。即ち、図５に示す単位領域５０２−４に有効なペイロードデータが格納されていることを示している。

一方、“０”がセットされているビット４０２−２は、フラグメント前のＩＰデータグラムのペイロードのうち、先頭からのオフセット８バイトから８バイト分のデータは未受信であることを示している。即ち、図５に示す単位領域５０２−２のデータは無効なペイロードデータであることを示している。そして、ビット４０２−３、４０２−５も同様に、それらの部分の８バイト分のデータはまだ受信されていないことを示している。

ここで、リアセンブル処理対象外管理テーブル２０５には、図３に示す管理エントリと同様のデータが格納されるものとする。このリアセンブル処理対象外のＩＰデータグラムであるか否かは、送信元アドレス３０１、宛先アドレス３０２、識別子３０３の各情報によって判断可能である。しかし、メモリ管理上都合がよいことがあるため、管理エントリをそのまま流用している。

第一の実施形態では、リアセンブル処理対象管理テーブル２０２と、リアセンブル処理対象外管理テーブル２０５とは別領域であることを前提に説明したが、２つの領域は一つの領域に集約されていても良い。その場合は、管理エントリをリンクリスト構造で管理し、リアセンブル処理中の管理エントリリストと、リアセンブル処理対象外の管理エントリリストの２つのリンクリストを生成する。そして、新規にリアセンブル処理を開始する場合は、リアセンブル処理中の管理エントリリストに追加し、リアセンブル処理が完了した場合、若しくはタイムアウトした場合に、当該管理エントリをリアセンブル処理対象外の管理エントリリストに移動する。

従って、リンクリストのポインタのみの操作で処理が完了し、データ部分、即ち送信元アドレス３０１、宛先アドレス３０２、識別子３０３をコピーや修正を行うことなく流用することが可能となる。

また、別の管理方法としてフラグを設けることも考えられる。つまり、管理エントリにリアセンブル処理実行中、若しくは対象外を示すフラグを設け、フラグによってリアセンブル処理中の管理エントリかリアセンブル処理対象外の管理エントリかを区別する。

上述した何れの方法でも、リアセンブル処理対象管理テーブル２０２と、リアセンブル処理対象外管理テーブル２０５とを一つの領域で管理することができる。

従って、本発明は、リアセンブル処理対象外の管理情報として、送信元アドレス、宛先アドレス、識別子の各情報が含まれていれば良い。また、管理エントリのＲＡＭ１０３への格納方法や管理方法は本発明の適用可否に関連するものではなく、上述した何れの方法によっても本発明を実現できる。

次に、リアセンブル処理で使用される管理エントリ、ビットテーブル及びリアセンブルバッファに対する処理（リアセンブル初期化処理、リアセンブル通常処理、リアセンブル終了処理）を、図６〜図８を用いて説明する。これらの処理は、ＣＰＵ１０１によって実行される。

＜リアセンブル初期化処理（図６）＞
図６は、リアセンブル初期化処理の処理手順を示すフローチャートである。尚、リアセンブル初期化処理はリアセンブル処理開始時に行われるが、これはフラグメント化されたＩＰデータグラム受信が前提となる。また、この処理には、受信したＩＰデータグラムのＩＰヘッダ情報が引数（Header）として渡される。

まず、ステップＳ６０１で、ＣＰＵ１０１はリアセンブル処理対象管理テーブル２０２に対して新規の管理エントリを作成する。次に、ステップＳ６０２で、新規作成した管理エントリの送信元アドレス３０１、宛先アドレス３０２、識別子３０３に、引数のHeaderの対象情報（送信元アドレス、宛先アドレス、識別子）を設定する。

次に、ステップＳ６０３で、ビットテーブルとリアセンブルバッファをそれぞれビットテーブル領域２０３、リアセンブルバッファ領域２０４に確保して初期化する。ここで、ビットテーブルの初期化は、図４に示すビットテーブル４０１のように、全てのビットを“０”にセットすることで行う。また、リアセンブルバッファ内のデータの有効又は無効はビットテーブル内のビットにより管理されるため、リアセンブルバッファの初期化は、特に何も行わなくても良い。

初期化完了後、ステップＳ６０４で、ステップＳ６０１で新規作成した管理エントリのビットテーブルポインタ３０４に、確保したビットテーブルの格納先アドレスを設定する。また同様に、リアセンブルバッファポインタ３０５に、確保したリアセンブルバッファの格納先アドレスを設定する。

最後に、ステップＳ６０５で、タイマ１０８に対して、このリアセンブル処理用のリアセンブルタイマの計時を開始するように指示し、このリアセンブル初期化処理を終了する。ここで、リアセンブルタイマは、リアセンブル処理のタイムアウトまでの時間を計時するタイマである。

通常、このリアセンブルタイマがタイムアウトする前に、全てのフラグメント化されたＩＰデータグラムを受信してリアセンブル処理が完了する。しかしながら、フラグメント化されたＩＰデータグラムの一部が何らかの原因により経路上で欠落してしまった場合、いつまで待ってもリアセンブル処理は完了しなくなってしまう。このような場合に、このリアセンブルタイマがタイムアウトした時点でリアセンブル処理を強制終了し、リソースを解放する。

また、リアセンブルタイマは、タイムアウトした際には、割込みなどでＣＰＵ１０１へタイムアウトしたことを通知する。このとき、ＣＰＵ１０１は何れの管理エントリで管理しているリアセンブル処理がタイムアウトしたかを認識できる。この認識方法は、例えば割込み要因に一意に関連付けられている構成もあれば、タイマ１０８がタイムアウトした内容を保持しており、タイムアウト後に、ＣＰＵ１０１がその保持内容を確認することで認識するなどの構成でも良い。ここでは、タイムアウト時に管理エントリが特定できれば良く、その認識方法は限定しない。

＜リアセンブル通常処理（図７）＞
図７は、リアセンブル通常処理の処理手順を示すフローチャートである。尚、このリアセンブル通常処理は、フラグメント化されたＩＰデータグラムの受信時に行われる。また、詳細は後述するが、ＩＰデータグラム受信時に受信したＩＰデータグラムのＩＰヘッダ情報と合致する管理エントリが存在するか否かを確認するために、リアセンブル処理対象管理テーブル２０２の検索が行われる。検索した結果、合致する管理エントリが存在する場合は、受信したＩＰデータグラムのＩＰヘッダ情報、合致する管理エントリがそれぞれ引数（Header、Entry）として渡される。また、検索した結果、合致する管理エントリが存在しない場合には、リアセンブル初期化処理（図６）により新規に管理エントリが作成され、その管理エントリが引数（Entry）として渡される。

まず、ステップＳ７０１で、ＣＰＵ１０１は、引数のEntryのビットテーブルポインタ３０４及びリアセンブルバッファポインタ３０５から、関連付けられたビットテーブル及びリアセンブルバッファの格納場所を特定する。そして、ステップＳ７０２で、引数のHeaderから受信したＩＰデータグラムのペイロードデータが、全ペイロードデータのどこに位置するデータであるかを示すオフセットとペイロードサイズを取得する。

ここで、オフセットは、Headerにおけるフラグメントオフセット（Fragment Offset）フィールドが示す値そのものである。また、ペイロードサイズは、HeaderにおけるIHLフィールド、全パケット長（Total Length）フィールドから算出する。IHLフィールドは、ＩＰデータグラムにおけるヘッダのワード数（１ワード＝４バイト）であり、全パケット長フィールドはＩＰデータグラム全体の長さ（バイト数）である。即ち、ペイロードサイズは、以下の計算式で算出することができる。

ペイロードサイズ（バイト）＝全パケット長フィールド−（IHLフィールド×４）
例えば、全パケット長フィールドが１０４４バイトであり、IHLフィールドが５である場合には、以下の計算式からペイロードサイズは１Ｋバイトと算出される。

１０４４−（５×４）＝１０２４バイト＝１Ｋバイト
上述の方法でオフセットとペイロードサイズを取得した後、ステップＳ７０３へ処理を進め、ステップＳ７０１で特定したビットテーブル及びリアセンブルバッファの更新処理を行う。ビットテーブルの更新処理は、フラグメント前のペイロードデータ内の受信した部分に対応するビットに“１”をセットすることで行う。例えば、オフセットが０（ゼロ）、ペイロードサイズが２４バイトであったとする。この場合は、ビットテーブルの先頭から３ビット分に“１”がセットされる。そして、リアセンブルバッファの更新処理は、フラグメント前のペイロードデータ内の受信した部分に対応する領域にペイロードデータをコピーすることで行う。

次に、ステップＳ７０４で、受信したＩＰデータグラムが終端ＩＰデータグラムであるか否かを確認する。具体的には、HeaderのＭＦ（More Fragment）フラグが“１”であれば後続のデータグラムが存在するため、終端ＩＰデータグラムではないと判断する。また、“０”であれば後続のデータグラムが存在しない、つまり終端ＩＰデータグラムであると判断する。

ステップＳ７０４で終端ＩＰデータグラムであると判断した場合、ステップＳ７０５へ処理を進め、ビットテーブルの終端処理を行う。具体的には、ビットテーブルの受信したＩＰデータグラムに対応する部分以降のビットを全て“１”にセットする。

この処理により、ビットテーブルの全てのビットが“１”にセットされたときに、全てのフラグメント化されたＩＰデータグラムを受信した、つまり、リアセンブル処理が完了したと判断できる。

尚、ビットテーブルの終端処理方法は、上述の方法に限られるわけではなく、他の方法で実現しても良い。即ち、リアセンブル処理が完了したと明確に判断可能な方法であれば、何れの実現方法であっても本発明を適用できる。

このステップＳ７０５でビットテーブルの終端処理を行った場合、ステップＳ７０４で終端ＩＰデータグラムではないと判断した場合の何れにおいても、リアセンブル通常処理は完了となる。

＜リアセンブル終了処理（図８）＞
図８は、リアセンブル終了処理の処理手順を示すフローチャートである。尚、このリアセンブル終了処理は、リアセンブル処理が完了した場合、或いはタイムアウトした場合に実行される。この処理の実行前にはリアセンブル処理が完了、若しくはタイムアウトした管理エントリが特定されており、その管理エントリが引数（Entry）として渡される。

まず、ステップＳ８０１で、ＣＰＵ１０１は、タイマ１０８に対して当該リアセンブル処理用のリアセンブルタイマの計時を停止するように指示する。具体的には、リアセンブル初期化処理（図６）のステップＳ６０５で開始を指示したリアセンブルタイマである。当該リアセンブルタイマは、この後、他のリアセンブル処理で使用可能となる。

次に、ステップＳ８０２で、引数（Entry）として渡された管理エントリのビットテーブルポインタ３０４及びリアセンブルバッファポインタ３０５から、関連付けられたビットテーブル及びリアセンブルバッファの格納場所を特定する。そして、ステップＳ８０３で、ステップＳ８０２で特定されたビットテーブルをビットテーブル領域２０３から解放し、リアセンブルバッファをリアセンブルバッファ領域２０４から解放する。ここで解放とは、解放対象の領域をその後、自由に使用可能にすることを意味する。

最後に、ステップＳ８０４で、引数（Entry）の管理エントリをリアセンブル処理対象管理テーブル２０２から解放する。この処理でリアセンブル終了処理は完了となる。

＜第一の実施形態のリアセンブル処理＞
ここで、プロトコル処理装置におけるＩＰデータグラムを受信した場合の処理手順を、図９を用いて説明する。尚、このリアセンブル処理は、ＩＰデータグラムを受信したことをトリガーとしてＣＰＵ１０１によって実行される。

図９は、第一の実施形態におけるＩＰデータグラムの受信処理を示すフローチャートである。まず、ステップＳ９０１で、ＩＰデータグラムを受信する。ＩＰデータグラムは、外部からＰＨＹ１０５を通して一旦ＭＡＣ１０４に受信される。その後、ＤＭＡＣ１０６によりＲＡＭ１０３内の受信データ領域２０１にバス１０７を介して転送される。ここで、受信データの転送はＤＭＡＣ１０６を用いずに、ＣＰＵ１０１が受信データ領域２０１に転送しても良い。

次に、ステップＳ９０２で、ＣＰＵ１０１は、受信したＩＰデータグラムのＩＰヘッダを解析する。尚、ステップＳ９０１で受信したＩＰデータグラムを受信ＩＰデータグラムと呼び、受信ＩＰデータグラムのＩＰヘッダを受信ＩＰヘッダ、受信ＩＰデータグラムのペイロードデータを受信ペイロードと呼ぶ。また、フラグメント処理前のペイロードにおける終端部分のペイロードを持つフラグメント化されたＩＰデータグラムを終端ＩＰデータグラムと呼ぶ。

次に、ステップＳ９０３では、ステップＳ９０２で行った受信ＩＰヘッダの解析結果に基づいて受信ＩＰデータグラムがフラグメント化されているか否かを判定する。ここでは、受信ＩＰヘッダのＭＦ（More Fragment）フラグ、フラグメントオフセット（Fragment Offset）フィールドにより判定する。

具体的には、まずＭＦフラグがセット（“１”の場合）されているか否かを確認する。ＭＦフラグがセットされている場合は、受信ＩＰデータグラムは終端ＩＰデータグラムではないことを意味する。ＭＦフラグがセットされていない場合、受信ＩＰデータグラムはフラグメントされていないか、或いは終端ＩＰデータグラムであることを意味する。

このＭＦフラグがセットされていない場合は、更にフラグメントオフセットフィールドを確認する。このフラグメントオフセットフィールドが“０”の場合は、受信ＩＰデータグラムはフラグメント化されていないことを意味する。しかし、フラグメントオフセットフィールドが“０”以外の値の場合には、受信ＩＰデータグラムは終端ＩＰデータグラムであることを意味する。

ＭＦフラグがセットされている場合は、受信したＩＰデータグラムはフラグメント化されていると判断する。また、ＭＦフラグがセットされておらず、かつフラグメントオフセットフィールドが“０”以外の値である場合は、受信したＩＰデータグラムはフラグメント化されていると判断する。そして、ＭＦフラグがセットされておらず、かつフラグメントオフセットフィールドが“０”である場合、受信ＩＰデータグラムはフラグメント化されていない通常のＩＰデータグラムであると判断する。

上述のステップＳ９０３で、受信ＩＰデータグラムがフラグメント化されていると判断した場合はステップＳ９０４へ処理を進め、リアセンブル処理対象外管理テーブル２０５を検索し、受信ＩＰヘッダに合致する管理エントリが存在するか否かを確認する。即ち、受信ＩＰデータグラムがリアセンブル処理対象外であるか否かを判定する。この処理は、受信ＩＰヘッダ内の送信元アドレス、宛先アドレス、識別子が、それぞれ管理エントリの送信元アドレス３０１、宛先アドレス３０２、及び識別子３０３と一致するかを確認する処理である。

ここで、上記３項目が一致する管理エントリが存在した場合、受信ＩＰデータグラムはリアセンブル処理対象外であることを意味する。この場合はリアセンブル処理を行わず、ＩＰデータグラムの受信処理を終了する。ここで、当該受信ＩＰデータグラム自体を受信データ領域２０１から削除する、つまり受信ＩＰデータグラムを破棄しても良い。

第一の実施形態では、リアセンブル処理をメインに説明しており、ＩＰデータグラムを受信した際に行う処理内容が他にも存在する可能性がある。受信ＩＰデータグラムの破棄は、その他の処理の全て、或いは一部を行わないということを意味する。

ステップＳ９０４で、リアセンブル処理対象外と判断した場合には、受信ＩＰデータグラムに対するリアセンブル処理を実行しないが、その後、当該ＩＰデータグラムを破棄するか否かについては制限しない。

一方、上述のステップＳ９０４でリアセンブル処理対象外ではないと判定された場合は、ステップＳ９０５へ処理を進める。このステップＳ９０５では、リアセンブル処理対象管理テーブル２０２を検索し、受信ＩＰヘッダに合致する管理エントリが存在するか否かを確認する。ここでは、ステップＳ９０４と同様に受信ＩＰヘッダ内の送信元アドレス、宛先アドレス、識別子が、それぞれ管理エントリの送信元アドレス３０１、宛先アドレス３０２、及び識別子３０３と一致するか否かを確認する。

ここで、上記３項目が一致する管理エントリが存在しない場合、受信ＩＰデータグラムに対するリアセンブル処理はまだ開始していない、つまり受信ＩＰヘッダを持つＩＰデータグラムのリアセンブル処理を開始する必要があることを意味する。そのため、ステップＳ９０６へ処理を進め、リアセンブル初期化処理（図６）を実行する。このとき、引数のHeader（ＩＰヘッダ）には、受信ＩＰヘッダを与える。そして、このリアセンブル初期化処理（図６）を実行した後、ステップＳ９０７へ処理を進める。

一方、ステップＳ９０５で、受信ＩＰヘッダに合致する管理エントリが存在する場合は、受信ＩＰデータグラムに対するリアセンブル処理は既に開始されていることを意味する。そこで、リアセンブル初期化処理（図６）を実行せず、ステップＳ９０７へ処理を進め、リアセンブル通常処理（図７）を実行する。このとき、引数のEntryとして、受信ＩＰデータグラムのリアセンブル処理対象管理テーブル２０２における管理エントリを与える。ここで、その管理エントリは、ステップＳ９０６で、リアセンブル初期化処理（図６）が実行された場合は、ステップＳ６０１で新規作成した管理エントリを意味する。一方、ステップＳ９０６をスキップしてきた場合は、ステップＳ９０５で合致した管理エントリを意味する。また、引数のHeaderには、受信ＩＰヘッダを与える。

次に、ステップＳ９０８で、リアセンブル処理が完了したか、つまりフラグメント化されたＩＰデータグラムのペイロードデータを全て受信したか否かを確認する。この処理は、現在の管理エントリに関連付けられたビットテーブルのビットが全て“１”であるか否かを確認する処理である。ただし、リアセンブル通常処理（図７）のステップＳ７０５（ビットテーブルに対する終端処理）で、上述した方法で終端処理を行っていなかった場合は、この限りではない。

ここで、終端処理とは、受信したＩＰデータグラムに対応する部分以降のビットを全て“１”にセットする処理である。何れにしても、上述のリアセンブル通常処理（図７）のステップＳ７０５で行った終端処理に応じて、リアセンブル処理が完了したか否かを確認すれば良い。

ステップＳ９０８で、リアセンブル処理は未完了と判断した場合は、この処理を完了し、次のＩＰデータグラムが受信されると、再度ステップＳ９０１から処理を行う。一方、ステップＳ９０８で、リアセンブル処理を完了したと判断した場合は、ステップＳ９０９へ処理を進め、リアセンブル終了処理（図８）を実行する。このとき、引数のEntryには現在の管理エントリを与える。このリアセンブル終了処理（図８）により、管理エントリ、その管理エントリに関連付けられたビットテーブル、リアセンブルバッファが解放され、リアセンブルタイマが計時を停止する。

次に、ステップＳ９１０で、リアセンブル処理が完了したＩＰデータグラムの管理エントリをリアセンブル処理対象外管理テーブル２０５に移動する。ここで、移動とは、通常コピーを指すが、リアセンブル処理対象管理テーブル２０２と、リアセンブル処理対象外管理テーブル２０５の構造によって別の処理になる可能性もある。即ち、上述したように、二つの領域をＲＡＭ１０３の物理領域に一つの領域としてリンクリストや、識別フラグにより管理している場合は、それぞれ別の処理を行う必要がある。何れにしてもステップＳ９１０の処理の後、他のＩＰデータグラム受信時に行う一連の処理において、ステップＳ９０４で行うリアセンブル処理対象外管理テーブル２０５の検索時に当該管理エントリが検索対象に入っていれば良い。

次に、ステップＳ９１１で、リアセンブル処理が完了したフラグメント前のペイロードデータを上位層に受け渡す。尚、ステップＳ９０３で受信したＩＰデータグラムがフラグメントされていないと判断した場合も、ステップＳ９１１でペイロードデータを上位層に受け渡す。ここで上位層は、通常はＴＣＰ処理を行うソフトウェアであるが、第一の実施形態では、特に限定はしない。

ここで、プロトコル処理装置におけるリアセンブルタイマがタイムアウトした場合の処理手順を説明する。プロトコル処理装置は、リアセンブルタイマがタイムアウトしたことをトリガーとして、処理を実行する。

尚、リアセンブル初期化処理（図６）で説明したように、このタイムアウト処理開始時には、タイムアウトしたリアセンブル処理の管理情報が格納されているリアセンブル処理対象管理テーブル２０２内の管理エントリが特定できていることを前提とする。

所定のリアセンブルタイマがタイムアウトし、それがＣＰＵ１０１へ通知される。同時に、ＣＰＵ１０１はタイムアウトしたリアセンブル処理の管理情報である管理エントリを特定する。そして、図９に示すステップＳ９０９の処理と同様に、リアセンブル終了処理（図８）を実行する。ここで、引数のEntryには、タイムアウトしたリアセンブル処理の管理情報である管理エントリを与える。次に、ステップＳ９１０と同様に、管理エントリをリアセンブル処理対象外管理テーブル２０５に移動する。

第一の実施形態によれば、既にリアセンブル処理が完了した場合、或いはタイムアウトしたＩＰデータグラムのフラグメントＩＰデータグラムを受信した場合、当該ＩＰデータグラムに対するリアセンブル処理を行わないことで以下の効果が得られる。

リソースを余分に確保することがなくなり、リソースの浪費を削減できる。これにより、プロトコル処理におけるパフォーマンスの低下を抑制でき、システム構築時のコストを低減できる。

［第二の実施形態］
次に、図面を参照しながら本発明に係る第二の実施形態を詳細に説明する。第二の実施形態は、第一の実施形態とＩＰデータグラム受信時の挙動のみが異なり、それ以外は同一である。

尚、第二の実施形態におけるプロトコル処理装置の構成は、図１を用いて説明した第一の実施形態と同じであり、その説明は省略する。また、リアセンブル処理で使用する管理情報も図２〜図５を用いて説明した第一の実施形態と同じであり、その説明も省略する。

更に、リアセンブル初期化処理、リアセンブル通常処理、リアセンブル終了処理も図６〜図８を用いて説明した第一の実施形態と同じであり、その説明も省略する。

＜第二の実施形態のリアセンブル処理＞
ここで、プロトコル処理装置におけるＩＰデータグラムを受信した場合の処理手順を、図１０を用いて説明する。尚、このリアセンブル処理は、ＩＰデータグラムを受信したことをトリガーとしてＣＰＵ１０１によって実行される。

図１０は、第二の実施形態におけるＩＰデータグラムの受信処理を示すフローチャートである。このステップＳ１００１〜Ｓ１００３までの処理は、第一の実施形態で説明した図９に示すステップＳ９０１〜Ｓ９０３までの処理と同じであり、その説明は省略する。

次に、ステップＳ１００４でリアセンブル処理対象管理テーブル２０２を検索し、受信ＩＰヘッダに合致する管理エントリが存在するか否かを確認する。この確認処理は、第一の実施形態と同様であり、その説明は省略する。

ここで、リアセンブル処理対象管理テーブル２０２に管理エントリが存在しない場合は、ステップＳ１００５へ処理を進め、リアセンブル初期化処理（図６）を実行する。このとき、引数のHeader（ＩＰヘッダ）には、受信ＩＰヘッダを与える。そして、このリアセンブル初期化処理（図６）を実行した後、ステップＳ１００６へ処理を進める。

一方、ステップＳ１００４で受信ＩＰヘッダに合致する管理エントリが存在した場合は、リアセンブル処理（図６）を実行せず、ステップＳ１００６へ処理を進める。ステップＳ１００６では、リアセンブル処理対象外管理テーブル２０５を検索し、受信ＩＰヘッダに合致する管理エントリが存在するかを確認する。即ち、受信ＩＰデータグラムがリアセンブル処理対象外であるか否かを判定する。この判定処理は、第一の実施形態と同様であり、その説明は省略する。

ここで、リアセンブル処理対象外管理テーブル２０５に一致する管理エントリが存在した場合は、受信ＩＰデータグラムはリアセンブル処理対象外であることを意味する。この場合はリアセンブル処理を行わず、ステップＳ１０１２へ処理を進め、リアセンブル終了処理（図９）を実行し、その後、ＩＰデータグラムの受信処理を完了する。

即ち、第一の実施形態では、リアセンブル処理を開始しないのに対して第二の実施形態ではリアセンブル処理は一旦開始するもののリアセンブル処理対象外である場合は、即座にリアセンブル終了処理を行う。

一般的に見ると、処理ステップが少ない分、第一の実施形態が有利に見えるが、第二の実施形態にもメリットがある。それは、ファームウェアの仕組みに依存する。新規に開発するファームウェアは如何様にも開発可能であるため、第一の実施形態を選択することが望ましい。しかしながら、既に開発済みのファームウェアを変更する場合はこの限りではない。つまり、既存のファームウェアがヘッダ解析とリアセンブル開始処理が密接に結びついており、修正が困難である場合が考えられる。

このような場合、ヘッダ解析とリアセンブル開始処理に変更を行わず一旦リアセンブル処理を開始してしまい、その後、リアセンブル処理を取り止めるという第二の実装形態の方がファームウェアの修正量、難易度ともに優位であると考えられる。

また、ステップＳ１０１２のリアセンブル終了処理（図９）の後、当該受信ＩＰデータグラム自体を受信データ領域２０１から削除する、つまり受信ＩＰデータグラムを破棄しても良い。

第二の実施形態では、リアセンブル処理をメインに説明しており、ＩＰデータグラムを受信した際に行う処理内容が他にも存在する可能性がある。受信ＩＰデータグラムの破棄は、その他の処理の全て、或いは一部を行わないということを意味する。

従って、ステップＳ１００６でリアセンブル処理対象外と判断した場合には、受信ＩＰデータグラムに対するリアセンブル処理を実行しないが、その後、当該ＩＰデータグラムを破棄するか否かについては制限しない。

一方、上述のステップＳ１００６でリアセンブル処理対象外ではないと判定された場合は、ステップＳ１００７へ処理を進める。このステップＳ１００７〜Ｓ１０１１の処理は、第一の実施形態におけるステップＳ９０７〜Ｓ９１１の処理と同じであり、その説明は省略する。

尚、第一及び第二の実施形態においては、ネットワークプロトコルのリアセンブル処理をＩＰデータグラムの受信時に行うことを前提に説明したが、必ずしもＩＰデータグラムの受信をトリガーにして実行する必要はない。プロトコル処理装置の実装によっては、例えばある程度受信済みＩＰデータグラムがたまった時点で処理を開始するという実装形態も考えられる。本発明は、ＩＰデータグラムを受信し、ＲＡＭ１０３の受信データ領域２０１に格納されている状態であれば実施可能であり、上述したような構成であっても、本発明を適用できることは言うまでもない。

また、第一及び第二の実施形態においては、管理エントリやビットテーブル、リアセンブルバッファの確保において、それぞれの領域の容量が不足し、生成できなかった場合に関しては言及していない。しかし、本事象が発生した場合でも、本発明の適用範囲を何ら減じることはない。例えば、生成できなかった場合には、リアセンブル処理をその時点で放棄し、ＩＰデータグラムを破棄しても構わない。本来、通常のプロトコル処理装置では、リアセンブル処理を並列に実行可能な数を制限しており、制限数を超えてリアセンブル処理を行うことはない。

また、本発明は、ＴＣＰ／ＩＰプロトコルのＩＰ層に適用される内容であり、上位層のＴＣＰ層では、一定時間内に受信できなかったＴＣＰパケットは再送を促す仕組みが定義されている。これにより、ＩＰ層で一度リアセンブル処理を放棄した場合でも、ＴＣＰ層レベルの再送要求により、再度当該データが送信機器から到着することとなる。

また、第一及び第二の実施形態では、管理エントリやビットテーブルのＲＡＭ１０３内での割り当て方法及び解放方法に関して明記していないが、何れの方法であっても本発明を適用できることは言うまでもない。例えば、通常の処理装置では、固定長のデータ領域を確保する場合には、予め所定の個数分のデータ領域を確保しておき、それぞれのデータ領域に対する使用状態を示すフラグ等を準備し、当該フラグによって確保及び解放を管理することが多い。

更に、可変長のデータ領域を確保する場合には、ファイルシステムなどのソフトウェアによって所定サイズのデータ領域の確保及び解放を管理することが多い。何れにおいても、またその他の方法でも、管理エントリ及びビットテーブルの確保、解放が行える限り、本発明の適用範囲である。

また更に、第一及び第二の実施形態では、リアセンブル処理対象外管理テーブル２０５に設定した管理エントリの削除に関して明記していないが、何れの削除手法であっても、本発明を適用できることは言うまでもない。例えば、管理エントリの登録時に、当該管理エントリの有効期間後にタイムアウトするようにタイマを設定し、タイムアウト時に削除するようにしても良い。

しかしながら、上記の方法では登録されている管理エントリ数分タイマが必要になってしまう。これに対して、例えば周期タイマを利用して登録した後、所定回数分周期タイマが計時したら削除するなどの方法を適用すれば複数のタイマを使用する必要はない。この有効期間はＩＰデータグラムのＩＰヘッダ内に含まれるTTL（Time To Live）フィールドを基に算出する方法が考えられる。即ち、TTLフィールドが通信経路上で経由できる中継機器の数を示していることから、各中継機器の最大遅延時間（数十ms〜数百ms等）とTTLフィールド値を乗算して算出した時間を有効期間とするという方法である。

また、有効期間は固定値にするという手法も考えられる。何れの方法、また他の方法を用いて有効期間を決定しても、有効期間内は前記管理エントリを保有しているため本発明による効果が期待できる。

これに対して、有効期間は設けず、リアセンブル処理対象外管理テーブル２０５に登録可能な管理エントリ数を設定するという手法も考えられる。即ち、登録可能な管理エントリ数を超えて登録を行う場合、現在登録されている管理エントリを削除し、新たに登録するという手法である。この場合、削除対象の管理エントリを選択する手法として、LRU（Least Recently Used）やFIFO（First-In First-Out）等の手法が考えられる。また、その他何れの方法を用いても、管理エントリを少なくとも１つ以上保有している限り、本発明の効果が期待できる。

更に、第一及び第二の実施形態では、リアセンブル処理対象外管理テーブルに登録した管理エントリの利用方法として、送信元アドレス、宛先アドレス、識別子の３つが合致した場合にリアセンブル処理を行わないように制御する手法のみを説明した。しかし、その他の利用方法を適用し、ＩＰデータグラム受信時にリアセンブル処理を行うか否かを別の判定方法により実現しても良い。

また、第一及び第二の実施形態では、リアセンブル処理が完了したＩＰデータグラムとリアセンブル処理にタイムアウトしたＩＰデータグラムを同等に扱う構成で説明したが、それぞれ異なる管理方法をとっても良い。例えば、リアセンブル処理にタイムアウトした管理エントリにおいて、同じ送信元であった場合には本システムのハードウェアリソースの浪費を狙ったDoS攻撃である可能性を想像できる。

このような場合には、送信元ＩＰアドレスでのみの合致判定によってリアセンブル処理を行うか否かを判定するような特別な管理エントリテーブルを構成するなどの手法が考えられる。

また、例えばリアセンブル処理にタイムアウトした管理エントリに合致するＩＰデータグラムを所定数以上受信した場合、当該ＩＰデータグラムの送信元との通信経路が原因で、到着タイミングに幅が出てしまっている可能性を想像できる。このような場合には、リアセンブル初期化処理においてリアセンブルタイマのタイムアウト時間を所定時間分長くすることで、リアセンブル処理完了の確率の向上を狙う等の手法が考えられる。

また、例えばリアセンブル処理が完了した管理エントリに合致するＩＰデータグラムが一切到着しなかった場合や、送信元が明らかに同一ネットワーク内である場合には、重複パケットが遅れて到着するような状況が発生しにくいことが想像できる。

このような到着状況の場合には、リアセンブル処理完了時に、当該管理エントリを登録しないように構成し、管理エントリによるメモリ消費量の削減を狙うなどの手法が考えられる。

このように、リアセンブル処理対象外の管理エントリ情報との合致回数・確率・タイミング、合致内容などにより何らかの学習を行い、リアセンブル処理対象外であるか否かの判定やリアセンブルタイマ時間などの調整を行う。

従って、より木目細やかな管理が行えるようになり、総合的なネットワーク処理効率の向上や処理速度の向上が期待できる。

次に、第一及び第二の実施形態に対する補足を説明する。第一及び第二の実施形態と組み合わせて実施する内容であるためその差分のみを説明する。該補足は、リアセンブル処理対象外管理テーブル２０５内の管理エントリの合致条件、保持期間及び破棄条件を明確にするものである。

まず、合致条件について説明する。リアセンブル処理対象外管理テーブル２０５内の管理エントリに合致するか否かは、二つの合致条件が存在する。一つ目の合致条件は、送信元アドレス、宛先アドレス及び識別子の３つ全ての一致である。該合致条件によりリアセンブル処理対象外と判断されるのは、既にリアセンブル処理が完了したＩＰデータグラム或いはタイムアウトしたＩＰデータグラムに属するフラグメントＩＰデータグラムのみである。一方、二つ目の合致条件は、送信元アドレス、宛先アドレスの２つのみの一致がある。この方法によりリアセンブル処理対象外と判断されるのは、既にリアセンブル処理が完了したＩＰデータグラム、或いはタイムアウトしたＩＰデータグラムを送信した送信元クライアントが送信する全てのフラグメントＩＰデータグラムである。以下、一つ目の合致条件をＩＰデータグラム合致条件と呼び、二つ目の合致条件をクライアント合致条件と呼ぶこととする。

これら二つの合致条件を状況によって使い分けることでより高い効果が期待できる。例えば、リアセンブル処理が完了した場合に追加する管理エントリにおいては、ＩＰデータグラム合致条件を適用する。リアセンブル処理が完了した場合に、以降リアセンブル処理対象外と判断したいのは、通信経路上での複製や重複により作成されたフラグメントＩＰデータグラムのみで、当該フラグメントＩＰデータグラムはＩＰデータグラム合致条件で識別することができる。一方、リアセンブル処理がタイムアウトした場合には、ＩＰデータグラム合致条件とクライアント合致条件を使い分ける。同じクライアントによるリアセンブル処理のタイムアウトの回数や頻度等に閾値を設定し、該閾値を超えるまではＩＰデータグラム合致条件を適用し、閾値を超えた後はクライアント合致条件を適用する。例えば、所定回数以上発生した場合には、通信自体に何らかの問題がある場合やDoS攻撃の可能性が考えられるためである。

次に、保持期間及び破棄条件について説明する。合致条件と同様にリアセンブル処理が完了した場合に追加する管理エントリと、タイムアウトした場合に追加する管理エントリで保持期間及び破棄条件を使い分けることでより高い効果が期待できる。例えば、リアセンブル処理が完了した場合に追加する管理エントリにおいては、ＩＰデータグラムの生存時間（TTL：Time to Live）を保持期間に設定し、破棄条件は保持期間経過とする。リアセンブル処理が完了した場合に、以降リアセンブル処理対象外と判断したいのは、通信経路上での複製や重複により作成されたフラグメントＩＰデータグラムのみで、当該フラグメントＩＰデータグラムは、生存時間（TTL）を超えて到達することはない。また、リアセンブル処理がタイムアウトした場合には、前記合致条件に連動して保持時間と破棄条件を変更する。すなわち、同じクライアントによるリアセンブル処理のタイムアウトの回数や頻度等に閾値を設定し、該閾値を超えるまでは保持期間に生存時間（TTL）を適用し、破棄条件は保持期間経過とする。一方、閾値を超えた後は保持期間を無期限に設定し、破棄条件は所定時間の間対象のクライアントからパケットの送信が無かった場合に破棄と設定する。このように設定することで、通信自体に何らかの問題がある場合やシステムの性能低下や破綻を目的としたDoS攻撃に対し、リアセンブル処理に使用するリソースの枯渇を抑制することができる。

尚、本発明は複数の機器（例えば、ホストコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用しても良い。

また、前述した実施形態の機能を実現するソフトウェアプログラムを記録した記録媒体を、システム或いは装置に供給し、システム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が読み取り可能な記録媒体からプログラムを読出し実行する。これによっても、本発明の目的が達成されることは言うまでもない。

Claims (12)

1. ネットワーク処理装置であって、
   フラグメント化されたＩＰデータグラムを受信し、該ＩＰデータグラムをリアセンブル処理する処理手段と
   リアセンブル処理対象外のＩＰデータグラムを特定する情報を保持する保持手段とを有し、
   前記処理手段は、前記保持手段に保持された情報で特定されるＩＰデータグラムを受信した場合、該ＩＰデータグラムをリアセンブル処理しないことを特徴とするネットワーク処理装置。
2. 前記保持手段は、前記処理手段によるリアセンブル処理が終了したＩＰデータグラムを特定する情報を保持することを特徴とする請求項１に記載のネットワーク処理装置。
3. 前記保持手段は、一定時間内にアセンブル処理が終了しなかったＩＰデータグラムを特定する情報を保持することを特徴とする請求項１に記載のネットワーク処理装置。
4. 前記保持手段は、前記処理手段によるリアセンブル処理が終了したＩＰデータグラムを送信した送信元クライアントを特定する情報を保持することを特徴とする請求項１に記載のネットワーク処理装置。
5. 前記保持手段は、一定時間内にアセンブル処理が終了しなかったＩＰデータグラムを送信した送信元クライアントを特定する情報を保持することを特徴とする請求項１に記載のネットワーク処理装置。
6. 前記処理手段は、前記リアセンブル処理を開始した後、前記保持手段に保持される情報で特定されるＩＰデータグラムを受信した場合、該ＩＰデータグラムをリアセンブル処理しないで前記開始したリアセンブル処理を終了させることを特徴とする請求項１に記載のネットワーク処理装置。
7. 前記処理手段は、前記リアセンブル処理しないＩＰデータグラムを破棄することを特徴とする請求項１に記載のネットワーク処理装置。
8. 前記処理手段は、前記フラグメント化されたＩＰデータグラムを格納するリアセンブルバッファ、ＩＰデータグラムの到着状況を管理するビットマップテーブル、リアセンブル処理のタイムアウトを計時するリアセンブルタイマのうち、少なくとも何れか一つを確保することを特徴とする請求項１に記載のネットワーク処理装置。
9. 前記保持手段に保持される情報の保持期間が経過した場合には、前記保持手段に保持される情報を破棄する破棄手段を更に有することを特徴とする請求項１に記載のネットワーク処理装置。
10. 前記保持手段に保持される情報の破棄条件を設定する設定手段と、
    前記設定手段に設定された破棄条件に合致する情報を破棄する破棄手段とを更に有することを特徴とする請求項１に記載のネットワーク処理装置。
11. ネットワーク処理装置の処理方法であって、
    フラグメント化されたＩＰデータグラムを受信し、該ＩＰデータグラムをリアセンブル処理する処理工程と
    リアセンブル処理対象外のＩＰデータグラムを特定する情報を保持する保持工程とを有し、
    前記処理工程では、前記保持工程にて保持された情報で特定されるＩＰデータグラムを受信した場合、該ＩＰデータグラムをリアセンブル処理しないことを特徴とするネットワーク処理装置の処理方法。
12. コンピュータにより読み取り可能な記録媒体であって、請求項１１に記載のネットワーク処理装置の処理方法をコンピュータに実行させるためのプログラムを記録した記録媒体。

Images