JP4716909B2 - ネットワーク接続テーブルを提供するための方法および装置 - Google Patents

Description

本発明は、コンピュータ・デバイスのためのネットワーク接続に関し、詳細には、ネットワーク接続を実現するために使用されるネットワーク接続テーブルに関する。

コンピュータ・システムは、ネットワーク接続を確立し使用することによって、ネットワークにより通信する。たとえば、ネットワークによりクライアント・コンピュータからのアクセスに使用可能であることをサーバが希望する場合、サーバは、そのネットワーキング・プロセスおよびコンポーネントがクライアントから受信される要求を処理できるようにすることができる。サーバ上で実行される複数のサーバ・アプリケーションは、ネットワークによりそのサーバ・アプリケーションへのアクセスを希望するクライアントにとって使用可能なものにすることができる。一例では、クライアントはサーバに接触することができ、サーバは、クライアントとサーバとの間にネットワーク接続を確立することができる。

伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）を使用する場合、たとえば、ＴＣＰ接続は、異なるパラメータまたはフィールドに分割されたビット・パターンなどの接続情報によって表される。たとえば、接続を定義する５つのパラメータのセットである「５タプル（5-tuple）」を使用することができる。ＴＣＰ／ＩＰの場合、この５タプルは、ネットワーク上で送信される各パケットのヘッダに含まれる。この５つのパラメータは、そのパケットに関するプロトコルのＩＤ（この場合はＴＣＰ）、ソースＩＰアドレス（ＳＡ：sourceIP address）、ソース・ポート（ＳＰ：source port）、宛先ＩＰアドレス（ＤＡ：destination IP address）、および宛先ポート（ＤＰ：destinationport）である。クライアントの観点から述べると、ソース・アドレスおよびソース・ポートはクライアント側にあり、宛先アドレスおよびポートはサーバ側にある。５タプル接続情報により、ネットワーク・データ・パケットは、双方向式にサーバ・プロセスとクライアント・プロセスとの間で通信することができる。各接続は、各パケット・ヘッダ内で識別される固有の５タプル・パターンを有する。

サーバとクライアントとの間で接続が確立される前に、サーバは概して、クライアントが接続可能な特定のプロセスへの接続の可用性を公示する。たとえば、サーバは、使用可能な潜在的接続を示すために、その接続に関する基本接続情報を「３タプル」または「２タプル」の形でセットアップすることができる。３タプルは、使用可能な接続に使用すべきプロトコルのＩＤ、その接続に関するサーバの宛先ポート、およびサーバの宛先アドレスに関する３つのパラメータを有する。３タプルは、サーバが複数のＩＰアドレスを有するときに（たとえば、マルチホーム・サーバ）使用され、その場合、使用可能な接続の特定のＩＰアドレスを指定しなければならない。その他の時期またはその他の環境では、サーバ接続のために単一ＩＰアドレスのみが提供されるか、または複数ＩＰアドレスのうちのどれが接続に使用可能であるかをサーバが気にかけない可能性がある。このようなケースでは、２タプルが使用可能な接続を示すことができ、これは、プロトコルのＩＤおよび宛先ポートという２つのパラメータを有する。

サーバは、５タプル、３タプル、および２タプルをＴＣＰ接続テーブルに保管することができる。サーバが接続情報（５タプル）が付いたヘッダを有するパケットを受信すると、サーバは、複数接続のうちのどれがパケットを受信しなければならないかを判定するために、複数テーブルのうちの１つにおいて一致する接続を捜す。各接続におけるパケットは最終的に、その接続の終了時にサーバ・アプリケーションに提供される。たとえば、サーバへの接続を確立するために、クライアントはサーバにＳＹＮ（同期）パケットを送信する。サーバは、ＳＹＮパケットを受信すると、クライアントとの３ウェイ・ハンドシェーク・プロセスを開始できるようにするためにテーブル内の一致する３タプルまたは２タプル・パターンをルックアップし、その結果、接続が確立される（パケット内の５タプルの残りのフィールドは無視される）。概して、まず３タプルに関する一致がサーチされ、何も見つからない場合に、２タプルに関する一致がサーチされる。接続が確立されると、５タプル・パターンはダイレクト・テーブル（direct table）に保管され、その接続上のその後のパケットと一致する。

既存のサーバ・システムは、着信パケットをどこに送信すべきかを決定するために、ＴＣＰ接続をルックアップするための種々の方法を使用する。ある方法では、それぞれが新しい接続または既存の接続を保管する３つの個別のテーブルが提供され、接続をルックアップするために単純なハッシュ・アルゴリズムが使用される。１つのテーブルは既存の接続に関する５タプル・パターンに使用され、もう１つのテーブルは新しい接続に関する３タプル・パターンに使用され、第３のテーブルは新しい接続に関する２タプル・パターンに使用される。各テーブルは、パターンのタイプに基づいて、異なるハッシュ・キー長を必要とする。

この方法の問題は、３つの異なるテーブルを保管するために、メイン・メモリ内のストレージ・スペースを必要とすることである。加えて、このルックアップ手順は場合によっては長い時間を要する場合があり、たとえば、３タプル・テーブルで新しい接続がルックアップされ、いかなる一致も見つからないときに、２タプル・テーブルでルックアップするためにメイン・メモリに対する第２のアクセスが必要であり、処理時間が増加する。

もう１つのルックアップ方法では単一テーブルを使用することができ、最長接頭部一致（ＬＰＭ：Longest Prefix Match）アルゴリズムが実現される。このタイプのアルゴリズムにより、サーバは最も厳しいかまたは詳細な基準に適合する最良一致を見つけることができ、いかなる一致も見つからない場合、より一般的な基準が使用される。複数のノードおよびリーフを有するツリー構造が使用され、したがって、処理するのに時間を要する。加えて、ＬＰＭ方法は複雑なアルゴリズムであり、特に、ハードウェアで実現される場合、メモリなどのより多くのハードウェア・コンポーネントを必要とし、したがって、システムの経費を増加する。

したがって、必要とされるものは、必要な処理時間およびアクセス時間がより短く、実現するのがより簡単で、より効率的で、しかもより安価であるネットワーク接続ルックアップ・メカニズムを提供するための装置および方法である。本発明は、このような要求に対処するものである。

本出願の発明は、ネットワーク接続を実現するために使用されるネットワーク接続テーブルに関する。本発明の一態様では、ネットワーク接続をサーチするための方法は、コンピュータ・システムにおいてネットワークによりパケットを受信し、そのパケットから接続情報を検索し、新しい接続を確立する場合に接続情報内の特定のフィールドをゼロにするステップを含む。接続情報は、テーブル・アクセス・プロセスを使用して、ダイレクト・テーブル内の位置に関するアドレスに変換される。ダイレクト・テーブルは、新しい接続および既存の接続に関するパターンおよび関連参照情報を保管する。接続情報は、受信パケットに関する参照情報を見つけるために、ダイレクト・テーブル内のそのアドレスによって指し示された位置に保管された少なくとも１つのパターンと比較される。本発明の同様の一態様は、同様の特徴を実現するための装置を提供する。

本発明の他の態様では、ネットワーク接続情報を保管するための方法は、ネットワーク接続情報を受信するステップと、ネットワーク接続情報が新しい接続を参照する場合にネットワーク接続情報内の特定のフィールドをゼロにするステップと、テーブル・アクセス・プロセスを使用して、ネットワーク接続情報をダイレクト・テーブル内のアドレスに変換するステップと、接続情報をパターンとして保管し、参照情報をアドレスに対応する位置でダイレクト・テーブルに保管するステップとを含む。ダイレクト・テーブルは、新しい接続および既存の接続に関する接続情報および参照情報を保管する。

本発明の他の態様では、ネットワーク接続情報の保管およびサーチを可能にする装置は、メモリ内に設けられ、新しいネットワーク接続に関する３タプルおよび２タプル・パターンと、確立されたネットワーク接続に関する５タプル・パターンとを含むネットワーク接続情報と、ネットワーク接続を指し示す関連参照情報とを保管するダイレクト・テーブルを含む。ネットワーク・アダプタ・デバイス上に実現されたサーチ・メカニズムは、接続情報を含むパケットがネットワークにより受信されたときに、ダイレクト・テーブル内のネットワーク接続情報をサーチする。サーチ・メカニズムはパケット接続情報からサーチ・パターンを作成し、そのサーチ・パターンは関連参照情報を見つけるためにダイレクト・テーブル内で一致するパターンをサーチするために使用される。

本発明は、新しい接続および確立された接続を含む種々のタイプのネットワーク接続をルックアップするために単一ダイレクト・テーブルを使用できるようにし、同じテーブル内への２タプル、３タプル、および５タプル・パターンの保管を可能にする方法および装置を提供する。これにより、効率の良い単一メモリ・アクセスですべての可能なタイプの接続をルックアップすることができる。さらに、本発明は、ハッシュ・プロセスまたはその他のテーブル・アクセス・メカニズムを使用して接続の直接ルックアップを可能にするが、これは既存の複雑なルックアップ・アルゴリズムより効率が良く安価である。

本発明は、コンピュータ・デバイスのためのネットワーク接続に関し、詳細には、ネットワーク接続を実現するために使用されるネットワーク接続テーブルに関する。以下の説明は、当業者が本発明を成し使用できるようにするために提示され、特許出願およびその要件に関連して示されている。本明細書に記載されている好ましい実施形態ならびに汎用原理および特徴に対する様々な変更は、当業者にとって容易に明らかなものになるであろう。したがって、本発明は、図示されている実施形態に限定されるものではなく、本明細書に記載されている原理および特徴と一致した最も広い範囲が与えられる。

主に特定の実現例で示されるシステムに関して本発明を説明する。しかし、当業者であれば、この方法およびシステムが他の実現例でも効果的に機能することを容易に認識するであろう。たとえば、本発明とともに使用可能なシステム・アーキテクチャおよびネットワーク構成は、いくつかの異なる形を取ることができる。また、特定の諸ステップを有する特定の方法に関しても本発明を説明する。しかし、この方法およびシステムは、本発明と一致しないわけではない異なる諸ステップまたは追加の諸ステップあるいはその両方を有する他の方法についても効果的に機能する。

本発明の特徴を詳細に説明するために、以下の考察に併せて図１〜６を参照されたい。ＴＣＰ／ＩＰプロトコル・クライアント／サーバ・システムに関して本発明を説明するが、適切な変更を加えた他の諸実施形態では他のプロトコル（ユーザ・データグラム・プロトコル（ＵＤＰ：User Datagram Protocol）など）および構成を使用することができる。たとえば、ＵＤＰにはＳＹＮパケットがまったく存在しないが、特定の接続／キューにパケットを誘導するために依然として５タプルを使用することができる。

図１は、本発明とともに使用するのに適したシステム１０の一例のブロック図である。システム１０は、サーバ、メインフレーム、デスクトップ・クライアント・コンピュータ、ワークステーション、その他のコンピュータまたは電子デバイスなどのコンピュータ・システムである。記載されている実施形態では、システム１０は、ネットワーク接続１４を介して様々な他のコンピュータ１２と通信することができるサーバ・システムとして示されている。記載されている実施形態ではコンピュータ１２はクライアント・コンピュータとして示されているが、他の諸実施形態ではサーバまたは他のコンピュータ・デバイスにすることができる。クライアント・コンピュータ１２はいずれも、１つまたは複数のデータ・パケットをサーバに送信することにより、ネットワーク１４によりサーバ・システム１０へのアクセスを要求することができ、サーバとクライアントとの間の接続が確立されると、それらの間で情報を伝達することができる。

サーバ・システム１０はいくつかのサーバ・アプリケーション１６を実行し、そのサーバ・アプリケーションは、本発明の文脈内では要求側のクライアント・コンピュータ１２に対してサービス、処理、データなどを提供できる、サーバ上で実行されるプロセスである。たとえば、サーバ・アプリケーション１６は、クライアント１２にＷｅｂページ・データを提供するかまたはクライアント１２にデータベース・データを提供するかあるいはその両方を行うＷｅｂサーバ・アプリケーションであるか、またはクライアント１２によって提供されたデータを処理することができる。

システム１０は、サーバ・アプリケーション１６へのネットワーク接続を管理するためのＴＣＰ／ＩＰスタック２０を含む。スタック２０は、サーバ上で実行されるオペレーティング・システムまたはユーザ・ソフトウェア・スペース内のプロセス・コードであって、ネットワーク接続１４への着信データおよびネットワーク接続１４からの発信データを処理するものである。ＴＣＰ／ＩＰスタックは、サーバ・アプリケーション１６への新しいネットワーク接続を確立するかまたは既存の接続にパケットを提供することができる。各サーバ・アプリケーション１６は、１つまたは複数の接続を有することができる。たとえば、スタック２０は、サーバ・アプリケーション１６に対するネットワーク接続を開くために、たとえば、サーバ・アプリケーション１６が開始されたときに、サーバ・アプリケーション１６からの要求を受信することができる。サーバ・アプリケーション１６はスタック２０にデータを送信し、そのスタックはネットワーク１４によりそのデータをＴＣＰ／ＩＰネットワーク・パケットとして宛先ポートおよびアドレスに送信する。また、スタック２０は、ネットワーク上の他のコンピュータ・デバイス１２によって提供されたネットワーク・パケットも受信し、そのパケットをネットワーク接続を介して適切なサーバ・アプリケーション１６に提供する。

ＴＣＰ／ＩＰスタック２０は、サーバ・システム１０のメイン・メモリ２４のダイレクト・テーブル２２にアクセスする。ダイレクト・テーブル２２は、サーバ１０へのすべての新しい接続および既存の接続に関する接続情報ならびにシステム１０によって受信されたパケットに関する宛先接続（複数も可）を示す関連「参照情報」または「接続参照情報」を保管する。一実施形態では、たとえば、参照情報は特定の接続キューを指し示すキュー番号にすることができ、その場合、接続キュー内のパケットは最終的にスタック２０によって処理され、関連データはそのキューに関する接続にならびにその接続の終了時にサーバ・アプリケーションに経路指定される。他の諸実施形態では、それぞれがテーブル内に示されているようにそれ専用のキューを有する、複数のプロトコル・スタック２０を提供することができる。他の実施形態では、各アプリケーション１６はそれ専用のキューを有することができるであろう。他の諸実施形態では、接続キューの他に、サーバ内の他の宛先を参照情報によって示すことができる。

たとえば、サーバ・アプリケーション１６への新しい接続を受け入れることをそのアプリケーションが要求すると、スタック２０は、その接続を要求したサーバ・アプリケーションへの接続に関連する接続キューを示すキュー番号とともに、適切な接続情報（パターン）をテーブル２２に保管する。システム１０にパケットを送信することにより、クライアントが新しい接続を要求すると、ネットワーク・アダプタ２６上のロジックがテーブルを調べて、どの接続キューにクライアントを接続し、パケットを送信すべきかを決定する（代わって、スタック２０はテーブルを調べることができるが、効率のために、アダプタ２６にそのタスクを実行させることにより、サーバ１０から負荷を除去する）。同様に、接続が確立された後、アダプタ２６がクライアント・コンピュータ１２からパケットを受信すると、アダプタ２６はテーブル２２を調べて、そのパケットを受信しなければならない確立された接続を決定する。これらのプロセスについては、図２および図４に関して以下により詳細に説明する。

本発明では、単一ダイレクト・テーブル２２は、５タプル、３タプル、および２タプル・パターンを含む、すべての新しい接続および確立された接続に関する接続情報を保管し、したがって、従来技術の実現例と比べて、接続テーブルに関するストレージ要件を低減し、接続ルックアップに必要なメモリ・アクセスの回数も低減する。さらに、接続情報は、ハッシュ・プロセス（以下に記載する）などの効率の良い方法によりテーブル内で直接アクセスされ、したがって、最長接頭部一致などのより複雑なアルゴリズムおよび構造を使用する他の実現例より必要な処理が少なくなる。

ネットワーク・アダプタ２６は、サーバ・システム１０と、ネットワーク１４に接続されたその他のコンピュータ１２との間の物理接続ポイントを提供するために使用される。アダプタ２６は、たとえば、ハードウェア・ネットワーク・インターフェース・アダプタにすることができる。ＴＣＰ／ＩＰスタック２０はアダプタ２６によりクライアント・コンピュータ１２からパケットを受信し、スタック２０はアダプタ２６によりネットワーク１４上でパケットを送出する。また、アダプタ２６は好ましくは、接続情報についてダイレクト・テーブル２２を調べることなど、ネットワーク情報の処理を可能にするために、ロジック、メモリ、および処理コンポーネントを含む。これは、サーバからネットワーク・アダプタに負担を軽減するものである。

図２は、ネットワーク接続情報をダイレクト・テーブル２２に保管するための本発明の方法１００を示す流れ図である。方法１００は、サーバのＴＣＰ／ＩＰスタック２０で、たとえば、ソフトウェアで、実現することができる。代わって、方法１００は、ハードウェアまたはハードウェアとソフトウェアの組み合わせとして実現することができる。方法１００（および方法２００）の諸ステップは、メモリ、ハード・ドライブ、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなど）、磁気ディスクなどのコンピュータ可読メディア上に保管されたプログラム命令を使用して実現することができる。

方法１００は概して、ネットワーク接続情報をダイレクト・テーブル２２に保管する必要性が存在するときに開始される。サーバ・アプリケーション１６が開始されるかまたは接続が開かれる（セットアップされる）ことを要求すると、この接続セットアップはここでは「新しい接続」と見なされ、この新しい接続に関する接続情報がダイレクト・テーブル２２に保管される。サーバ・アプリケーション１６は、そのサーバ・アプリケーションにアクセスするための任意のクライアント要求を受け入れるための要求をＴＣＰ／ＩＰスタック２０に提供し、そのアプリケーションに関するスタックにプロトコル（たとえば、ＴＣＰ）およびサーバＴＣＰポート（および場合によってはＩＰアドレス）を提供する。さらに、確立された接続に関する接続情報は、概してクライアントとサーバが通信を確立した後、たとえば、ＴＣＰプロトコルを使用するときの３ウェイ・ハンドシェーク後に、保管される。

この方法は１０２から始まり、ステップ１０４では、５タプルの接続情報（５タプル「パターン」）を保管すべきかどうかがチェックされる。方法１００に関連して、５タプル・パターンを保管しない場合、３タプルまたは２タプル・パターンの接続情報が保管される。

本明細書で言及される５タプル・パターンは、プロトコルのＩＤ、ソース（クライアント）アドレス、ソース・ポート、宛先（サーバ）アドレス、および宛先ポートという５つの接続パラメータを定義するために指定されるビット・ストリング（たとえば、多くの一般的なＴＣＰ／ＩＰ実現例では１０４ビット）である。５タプル・パターンは、接続が確立され、ソース（クライアント）および宛先（サーバ）が既知のものであるときに、テーブルに保管される。テーブル２２に保管すべき５タプルは、３ウェイ・ハンドシェークの終了時に受信されるパケットのヘッダ内で受信される。対照的に、本明細書で言及される３タプル・パターンは、プロトコルＩＤ、宛先アドレス、および宛先ポートという３つの接続パラメータを含み、サーバ・アプリケーションへの接続がクライアントにとって使用可能な状態にならなければならないことをそのサーバ・アプリケーションが要求したときに保管される。３タプル・パターンでは、５タプルの他の２つのフィールドがゼロにされている。同様に、２タプル・パターンの接続情報は、プロトコルＩＤおよび宛先ポートという２つのパラメータを含み、５タプルの他の３つのフィールドがゼロにされている。２タプル・パターンは、新しい接続を使用可能な状態にするときに３タプル・パターンの代わりに保管することができ、宛先アドレスを指定する必要がないときに使用される。たとえば、いくつかのサーバ・システム１０は、それに対して接続すべき複数の使用可能なＩＰアドレスを有することができ、その結果、３タプル・パターンを使用して宛先アドレスを指定しなければならない。他のシステムは、アドレスを１つだけ有する場合もあれば、クライアントによって複数の宛先アドレスのうちのどれに接続されるかを気にかけない場合もあり、その結果、２タプル・パターンを使用することができる。

５タプル・パターンを保管する場合、プロセスは、以下に詳述するステップ１２０に進む。３タプルまたは２タプル・パターンを保管する場合、プロセスはステップ１０６に進む。ステップ１０６では、サーバ・アプリケーションから受信した宛先ポート（ＤＰ）およびプロトコル（Ｐ）を所定のフィールドに含め、ソース・アドレス（ＳＡ）、ソース・ポート（ＳＰ）、および宛先アドレス（ＤＡ）用のフィールドをゼロにすることにより、ハッシュ・キーが作成される。

次のステップ１０８では、ステップ１０６の結果として得られるパターンは、ネットワーク接続情報のパターンを保管するためのダイレクト・テーブル２２内のテーブル行を決定するために実行されるＳＹＮハッシュ・プロセスでハッシュ・キーとして使用される。本明細書で言及されるテーブル「行」（または「位置」）は、複数の項目を保管することができ、アドレス指定することができる、テーブル内の位置またはスペースを示し、テーブル行は様々な方法で実現することができる。ＳＹＮハッシュは、テーブル２２の項目を決定するために、フル・パターンのＤＰフィールドおよびプロトコル・フィールドのみを使用する。ＳＹＮハッシュは、大きい値のキーを、行数がより少ないテーブルへのインデックスとして付けることができるより小さい値に変換するハッシュ・アルゴリズムであり、その小さい方の値はそのテーブルの行範囲内に十分分散される。ＳＹＮハッシュは、３タプルまたは２タプル接続がダイレクト・テーブル２２内でルックアップされるとき、たとえば、ＳＹＮパケットがサーバによってクライアントから受信されるときに、使用される。ＴＣＰプロトコルにおけるＳＹＮパケットは、接続を開始するためにクライアントがサーバに送信する初期パケットである。本発明のＳＹＮハッシュ・プロセスの一例については、図７に関連して以下に説明する。他の諸実施形態では、ハッシュ・プロセス以外の他のテーブル・アクセス・メカニズム／プロセス、たとえば、キーを与えられると、１つまたは複数の項目を有するテーブル内の行へのアクセスを可能にするテーブル・アクセス・メカニズムを使用することができる。

次のステップ１１０では、プロセスは、保管すべきパターンが３タプルであるか２タプルであるかをチェックする。３タプルまたは２タプル・パターンを接続テーブルに入れることにより、そのアプリケーションが接続を聴取していることを示している。パターンが３タプルである場合、すなわち、要求側サーバ・アプリケーションがプロトコル、宛先ポート、および宛先アドレスを提供した場合、プロセスはステップ１１２に進み、そこで、サーバ・アプリケーションからのＰ、ＤＰ、およびＤＡフィールドが適切なフィールドに含まれ、ＳＡおよびＳＰフィールドがゼロにされた状態で３タプル・パターンが作成される。ステップ１１４では、ステップ１１２の結果として得られるパターンは、ステップ１０８で決定されたテーブル２２のテーブル行で次に使用可能な項目（スロット）に保管される。加えて、キュー番号は、３タプル・パターンとともに、決定されたテーブル項目に保管される。たとえば、キュー番号は、着信ＳＹＮパケットが保管されるはずのサーバのどの接続キューを処理すべきかを識別する。各接続キューは、サーバ・アプリケーション１６への特定の接続に関連付けられている。したがって、ＴＣＰ／ＩＰスタック２０が接続キュー内のパケットを処理すると、そのスタックは、その接続に関連するサーバ・アプリケーションに適切なデータを送信する。他の諸実施形態では、たとえば、接続キューが実現されない場合、保管されたパターンに関連する接続を示すために、キュー番号の代わりに他のタイプの参照情報をその項目に保管することができる。ステップ１１４の後、プロセスは１１６で完了する。

ステップ１１０で保管すべきパターンが２タプルである場合、すなわち、要求側サーバ・アプリケーションがプロトコルおよび宛先ポートを提供した場合（宛先アドレスなし）、プロセスはステップ１１８に進み、そこでステップ１０６の結果として得られるハッシュ・キー・パターンは、ステップ１０８で決定されたテーブル２２のテーブル行で次に使用可能な項目に保管される。ハッシュ・キー・パターンは、ＳＡ、ＳＰ、およびＤＡフィールドがゼロにされており、したがって、２タプル・パターンと同一である。加えて、キュー番号（たとえば）は、一致ＳＹＮパケットが保管されるはずのサーバのどの接続キューを処理すべきかを識別する２タプル・パターン（ハッシュ・キー）を有するテーブル項目に保管される。ステップ１１８の後、プロセスは１１６で完了する。

５タプル・パターンが保管されることをステップ１０４でプロセスが発見した場合、ステップ１２０が実行される。ステップ１２０では、受信したフル・パターンがハッシュ・キーとして使用され、受信した５タプル・パターンを保管すべきテーブル２２の行を決定するためにＴＣＰ／ＵＤＰハッシュが実行される。ＴＣＰ／ＵＤＰハッシュ・アルゴリズムは、テーブル２２内のテーブル行に関するアドレス値を決定するためにそのパターンのすべてのフィールド、すなわち、ビット・パターン全体を使用し、したがって、ハッシュ・キーに関するフル・パターンの３つのフィールドをゼロにしたステップ１０８のＳＹＮハッシュ・アルゴリズムとは異なるものである。本発明のＴＣＰ／ＵＤＰハッシュ・プロセスの一例については、図８に関連して以下に説明する。

次のステップ１２２では、受信した５タプル・パターンの接続情報は、ステップ１２０のハッシュ・アルゴリズムによって決定されたテーブル行内の次に使用可能な項目でダイレクト・テーブル２２に保管される。加えて、キュー番号（またはその他のタイプの参照情報）は、サーバのどの接続キューに一致パケットが保管されるはずかを識別する５タプル・パターンを有するテーブル項目に保管される。したがって、プロセスは１１６で完了する。

テーブル２２の各行内の各項目は、５タプル、３タプル、または２タプル・パターンを保管できる汎用項目であり、３タプルおよび２タプル・パターンは実際には特定のフィールドがゼロになっている５タプルであることに留意されたい。３タプルおよび２タプル・パターン内のゼロは無効な５タプルを作成し、その結果、テーブル内の２タプル、３タプル、および５タプルのドメインにはオーバーレイはまったく存在しない。したがって、本発明は、５タプル・パターンのサーチにより誤って３タプルまたは２タプル・パターンが見つかることはないことを認めるものである。

図３は、本発明によりダイレクト・テーブルへの接続情報の保管の一例を示す概略図１５０である。図１５０は、図２に関して上述した通り、５タプル、３タプル、および２タプルという３つの形の接続情報がダイレクト・テーブル２２に保管されることを示している。

５タプル・パターン１５２がテーブル２２に保管される場合、パターン１５２全体がＴＣＰ／ＵＤＰハッシュ・プロセス１５４においてハッシュ・キーとして使用される。ハッシュ・プロセス１５４の結果はダイレクト・テーブル２２内の行へのアドレス１５６として使用され、この例では行「４７」であり、５タプル・パターンはその行内の次に使用可能な項目（すなわち、スロット）に保管される。加えて、キュー（参照）番号１５８は、５タプル・パターンを有する同じ行および項目に保管され、上述の例では、一致パケットが保管されるはずの特定の接続キューが最終的に関連の接続およびサーバ・アプリケーション１６について処理されることを示している。

また、３タプル・パターン１６０もテーブル２２に保管することができる。３タプル・パターン１６０では、そのＳＡおよびＳＰフィールドがゼロにされている。ハッシュ・プロセス用のハッシュ・キー１６２を作成するために、パターン１６０では、そのＤＡフィールドもゼロにされている。ハッシュ・キー１６２はＳＹＮハッシュ・プロセス１６４に提供され、ハッシュ・プロセス１６４の結果はダイレクト・テーブル２２内の行へのアドレス１６６として使用される。３タプル・パターン１６０はその行（この例では行４７）の次に使用可能な項目に保管され、参照（たとえば、キュー）番号１６８は同じ行および項目に保管され、この例では、特定の接続およびサーバ・アプリケーション１６に関する特定の接続キューを示している。

また、２タプル・パターン１７０もテーブル２２に保管することができる。２タプル・パターン１７０では、そのＳＡ、ＳＰ、およびＤＡフィールドがゼロにされている。したがって、パターン１７０は、ＳＹＮハッシュ・キーとしても作用することができ、ＳＹＮハッシュ・プロセス１７２に提供される。ハッシュ・プロセス１７２の結果はダイレクト・テーブル２２へのアドレス１７４として使用される。２タプル・パターン１７０はアドレス１７２によって示される行（この例では行４７）の次に使用可能な項目に保管され、参照（たとえば、キュー）番号１７６は同じ行および項目に保管される。

この例では、５タプル・パターン１５２、３タプル・パターン１６０、および２タプル・パターン１７０がすべてダイレクト・テーブル２２の同じ行の項目に保管される（また、複数の５タプル、３タプル、または２タプルを同じ行に保管することができる）ことに留意されたい。図３の例では、ＴＣＰ／ＵＤＰハッシュ・プロセス１５４ならびにＳＹＮハッシュ・プロセス１６４および１７２は、異なるハッシュ・キー・パターンを取っており、この特徴を示すためにダイレクト・テーブル２２の同じアドレス（行４７）を提供している。異なるハッシュ・アルゴリズムを使用することにより、単一テーブル２２は複数タイプのパターンを任意の行に保管することができ、それにより、従来の実現例のように複数テーブルの非効率な使用が解消される。

加えて、テーブルの各行に複数の項目が保管され、それにより、ハッシュ・プロセスはアドレス指定するために使用可能なテーブル行の数を削減することができる（たとえば、ハッシュ・プロセス１５４、１６４、および１７２は可能なパターン範囲より小さいアドレス範囲をテーブル内に生成する）。たとえば、図３の行４７でのパターン保管のために所定の数の項目が使用可能になる可能性がある。

いくつかの諸実施形態では、テーブル２２の任意の特定の行内の使用可能なスペースからオーバーフローしたパターンを保管するための追加の項目を提供するために、オーバーフロー・ストレージ域も提供することができる。たとえば、追加の項目のリンク・リストを保管することができるか、またはテーブル２２の構造と同様の２次テーブルが各行ごとのオーバーフロー・パターンを保管することができる。

図４は、ダイレクト・テーブル２２内のネットワーク接続情報をサーチするための本発明の方法２００を示す流れ図である。方法２００は、ハードウェアで、たとえば、ネットワーク・アダプタ２６上に実現された「サーチ・メカニズム」によって実現することができる。代わって、方法２００は、ハードウェアまたはハードウェアとソフトウェアの組み合わせとして実現することができる。

方法２００は概して、ダイレクト・テーブル２２内のネットワーク接続情報をサーチする必要性が存在するときに開始される。新しい接続に関する情報は、概して、アダプタ２６がネットワーク１４によりクライアントからパケットを受信したときにサーチされる。このパケットは、５タプル・パターンを含むヘッダを含む。それが新しい接続を確立するためのＳＹＮパケットである場合、それぞれ２タプルまたは３タプル・パターンをサーチするために、５タプル・パターンのうちの２つまたは３つのフィールドのみが使用される。それがすでに確立されている接続上での通信中に受信されたパケットである場合、この方法では５タプル・パターン全体を使用する。

この方法は２０２から始まり、ステップ２０４では、受信パケットがＳＹＮパケットであるかどうかがチェックされる。そうである場合、プロセスはステップ２０６に進み、そこでＳＹＮパケットのヘッダ内の受信パターンの特定のフィールドが検索され、他のフィールドはゼロにされ、サーチに使用するためのサーチ・パターンを作成し、ハッシュ・キーを決定する。サーチに使用するための３タプル・サーチ・パターンを作成するために、受信した３タプル・パラメータ（Ｐ、ＤＰ、ＤＡ）は、ＳＡおよびＳＰフィールドがゼロにされたサーチ・パターンに含まれる。サーチに使用するための２タプル・サーチ・パターンおよびハッシュ・キーを作成するために、受信した２タプル・パラメータ（Ｐ、ＤＰ）は、ＳＡ、ＳＰ、およびＤＡフィールドがゼロにされたサーチ・パターンに含まれる。

次のステップ２０８では、テーブル２２内のテーブル行のアドレスを決定するためにステップ２０６のハッシュ・キーを使用してＳＹＮハッシュ手順が実行される。使用されるＳＹＮハッシュ・アルゴリズムは、図２に関連して前に説明した通り、テーブル２２に３タプルまたは２タプル接続情報を保管するときに使用されるものと同じである。本発明のＳＹＮハッシュ・プロセスの一例については、図７に関連して以下に説明する。また、前に説明した通り、ハッシュ・プロセス以外の他のテーブル・アクセス・メカニズム／プロセスを使用して、行アドレスを決定することができる。ステップ２１０では、ステップ２０６のサーチ・パターンは、決定された行のテーブル項目に保管されたパターンと比較される（現行サーチについて初めてステップ２０８が実行された場合、テーブル項目はその行内の最初の項目になる）。したがって、３タプル・サーチ・パターンはそのパターンと比較され、２タプル・サーチ・パターンはそのパターンと比較される。３タプル・パターンを使用する比較は「１次」比較と見なすことができ、２タプル・パターンを使用する比較は「２次」比較と見なすことができる。

ステップ２１２では、２タプル・サーチ・パターンが現行テーブル項目内のパターンと一致する場合、すなわち、２次一致が行われた場合、プロセスはその情報をテーブル項目に保管する。この情報は、都合の良いバッファに保管することができ、テーブルに保管されたパターンおよびそのパターンに関連する参照情報を含むことができる。以下に記載する通り、テーブル行で１次一致がまったく見つからない場合、この情報はステップ２２４でプロセスの後半で使用することができる。

ステップ２１４では、プロセスは、３タプル・サーチ・パターンと、現行テーブル項目に保管されたパターンとの間に一致が存在するかどうかをチェックする。１次一致が存在する場合、ステップ２１６では、一致パターン項目が所望の接続として取られ、受信パケットを経路指定すべき接続およびサーバ・アプリケーション１６を決定するためにテーブル２２内の一致パターンに関連するキュー番号（またはその他のタイプの参照情報）が読み取られる。次にプロセスは２１８で完了する。

ステップ２１４で３タプル・サーチ・パターンとパターンとの一致がまったく存在しない場合、プロセスはステップ２２０に進み、そこでプロセスは、まだ比較されていないパターンを保持する項目がこのテーブル行にそれ以上存在するかどうかをチェックする。そうである場合、ステップ２２２でテーブル項目ポインタはそのテーブル行内の次の項目に移動し、プロセスはステップ２１０に戻って、サーチ・パターンとこの次のテーブル項目に保管されたパターンとを比較する。上述の通り、いくつかの諸実施形態では、オーバーフローの場合にその行に関する追加のパターンを保管する追加の項目を提供するために、追加のテーブルまたはその他のストレージ構造を使用することができる。

ステップ２１４で１次一致がまったく見つからず、ステップ２２０で比較するための項目がそのテーブル行にそれ以上存在しない場合、プロセスはステップ２２４に進み、そこで、その行の第１の２タプル２次一致が所望の接続として取られる。この第１の２次一致項目情報は、現行行について２次一致が見つかるたびにステップ２１２で２次一致項目情報が保管されたバッファから分かる。受信パケットを経路指定すべき接続およびサーバ・アプリケーション１６を決定するためにテーブル２２内の一致パターンに関連する参照情報（キュー番号）が読み取られ、プロセスは２１８で完了する。

２０４のチェックで受信パケットが非ＳＹＮパケットであると判定された場合、プロセスはステップ２２６に進み、そこで、ハッシュ・キーとしてパケットのヘッダに提供されるフル・パターンを使用してＴＣＰ／ＵＤＰハッシュ操作が実行される。本発明のＴＣＰ／ＵＤＰハッシュ・プロセスの一例については、図８に関連して以下に説明する。ステップ２２８では、受信したフル・パターンは、サーチ・パターンとして使用され、ステップ２２６のハッシュ操作の結果によって指し示されるテーブル行内のテーブル項目に保管された５タプル・パターンと比較される（ステップ２２８が初めて実行された場合、テーブル項目はその行内の最初の項目になる）。前に説明した通り、使用される各テーブル項目は、パターンおよび参照情報を保管する。

ステップ２３０では、プロセスは、サーチ・パターンと、そのテーブルに保管されたパターンとの間に一致が存在するかどうかをチェックする。存在しない場合、ステップ２３２では、テーブル項目ポインタはそのテーブル行内の次の項目に移動し、プロセスはステップ２２８に戻って、サーチ・パターンとこの次のテーブル項目に保管されたパターンとを比較する。ステップ２３０で一致が存在する場合、プロセスはステップ２１６に進み、そこで、一致パターン項目が所望の接続として取られ、受信パケットを経路指定すべき接続およびサーバ・アプリケーション１６を決定するためにテーブル項目内の一致パターンに関連するキュー番号（またはその他の参照情報）が読み取られる。一致接続情報は、それをアプリケーション１６に転送するためにサーバ・システム１０の適切なコンポーネントに提供することができる。次にプロセスは２１８で完了する。

代替諸実施形態では、比較し、３タプルおよび２タプルについて１次一致と２次一致を見つけるために、他の方法を使用することができる。たとえば、２次一致情報を保管するステップ２１２はスキップすることができ、その行の項目（およびその行に関する任意のオーバーフロー項目）に保管されたすべてのパターンが３タプル・サーチ・パターンと一致しないと判明した後でのみ、２タプル・サーチ・パターンをその行に保管されたパターンと比較することができる。

図５は、図４に関連して上述した通り、新しい接続を確立するためにＳＹＮパケットが受信されたときに本発明により行われるダイレクト・テーブル内の接続情報のサーチを示す概略図２５０である。

第１の例では、パターン２５２は、受信ＳＹＮパケット内の情報から作成される。それはＳＹＮパケットであるので、ダイレクト・テーブル２２内で３タプルまたは２タプル・パターンをサーチしなければならない。図示の通り、３タプル・サーチ・パターン２５４を作成するために、作成されたパターンのＳＡおよびＳＰフィールドがゼロにされる。ハッシュ・キー２５６（これは２タプル・サーチ・パターンでもある）を作成するために、受信パターンのＤＡフィールドがさらにゼロにされる。ＳＹＮハッシュ・プロセス２５８の結果として、ダイレクト・テーブル２２内の行へのインデックスまたはアドレス２６０が得られ、それはこの例では行「４７」である。次に、３タプル・サーチ・パターン２５４は、その行内の（第１の）テーブル項目に保管されたパターン２６１と比較される。パターン２６１は５タプル・パターンであるので、一致はまったく存在せず、したがって、プロセスはその行内の次の項目に移動し、３タプル・サーチ・パターンとパターン２６２とを比較する。この例では、パターン間の一致が存在し、その結果、パターンに関連するキュー番号２６４が検索される。図４の方法によれば、３タプル・サーチ・パターンが比較されるのと同時に、ハッシュ・キー２５６と同じ２タプル・サーチ・パターンがさらに同時にパターン２６１および２６２と比較されるが、パターン２６１は２タプル・サーチ・パターンと一致せず、パターン２６２は３タプル・サーチ・パターンと一致していたので、これらの比較はこの例では不適切なものである。

他の例では、パターン２７０は、受信ＳＹＮパケット内の情報から作成される。パターン２７０内のＤＡフィールド２７１はパターン２５２のＤＡフィールドとは異なるものである。３タプル・サーチ・パターン２７２を作成するために、作成されたパターンのＳＡおよびＳＰフィールドがゼロにされる。２タプル・サーチ・パターン／ハッシュ・キー２７４を作成するために、パターンのＤＡフィールドがゼロにされる。ＳＹＮハッシュ・プロセス２７６の結果として、ダイレクト・テーブル２２内の行へのインデックスまたはアドレス２７８が得られ、この例では行「４７」である（これは上述の例と同じ行である）。次に、３タプル・サーチ・パターン２７２および２タプル・サーチ・パターン２７４は、その行内の（第１の）テーブル項目に保管されたパターン２６１と比較される。パターン２６１は５タプル・パターンであるので、一致はまったく存在せず、したがって、プロセスはその行内の次の項目に移動し、３タプルおよび２タプル・サーチ・パターンとパターン２６２とを比較する。この例では、やはり一致がまったく存在しない。同様に、３タプルおよび２タプル・サーチ・パターンは、その行内の次の項目であるパターン２６６と比較される。この場合、３タプル・パターンは一致しないが、２タプル・パターンについては２次一致が見つかり、したがって、項目情報が保管される（図４のステップ２１２）。この例では、サーチ・パターンのこの比較はその行内のすべての項目（任意のオーバーフロー項目を含む）について続行され、点線２７６によって示される通り、その行内のどの項目についても１次一致はまったく見つからない。したがって、その行から第１の２次一致が選択される。この例では、第１の２次一致はパターン２６６に関するものである。受信パケットを経路指定すべき接続を決定するためにパターン２６６に関連するキュー番号２８０がストレージから検索される。

図６は、図４に関連して上述した通り、非ＳＹＮパケットが受信されたときに本発明により行われるダイレクト・テーブル２２内の接続情報のサーチを示す概略図３００である。

図示の例では、受信した非ＳＹＮパケットは、５タプル・パターン３０２を有するヘッダを含む。これは非ＳＹＮパケットであるので、５タプル・パターンは変更する必要はなく、ダイレクト・テーブル２２用のサーチ・パターンとして直接使用することができる。５タプル・パターン３０２と同じであるハッシュ・キーがＴＣＰ／ＵＤＰハッシュ・プロセス３０４に使用され、その結果、ダイレクト・テーブル２２内の行へのインデックスまたはアドレス３０６が得られ、この場合、行「４７」である。５タプル・サーチ・パターン３０２は、そのテーブル項目に保管されたパターン３０８と比較される。この例では、パターン間の一致が存在し、その結果、テーブル２２に保管され、パターン３０８に関連する参照情報（たとえば、キュー番号）３１０が検索される。一致がまったく見つからなかった場合、任意の一杯になったオーバーフロー項目を含む、その行の次の項目内のパターンなどが比較されることになるであろう。

図７および図８は、本発明とともに使用できるハッシュ・プロセスを示している。これらの例では、上述の５タプルの代わりに、６タプルの接続情報が使用される。２００５年４月１日に出願され、「Ｎｅｔｗｏｒｋ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｆｏｒ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｐａｒｔｉｔｉｏｎｓ」という発明の名称の同時係属の米国特許出願第１１／０９７０５１号に記載されている通り、論理ポートを使用する本発明の一実現例の場合、論理ポート（ＬＰ）番号およびプロトコル（ＴＣＰまたはＵＤＰ）を識別するために、この追加のタプルが使用される。接続情報パターンの残りの部分は上述のものと同じである。これらのプロセスは、この追加のタプルを使用しない他の諸実施形態では適切に変更することができる。ハッシュ出力番号は、入力キーに対する１対１対応を備えたｎビット番号である。

図７は、図２のステップ１０８および図４のステップ２０８で使用することができる本発明のＳＹＮハッシュ・プロセス３５０を示している。６タプル・パターン３５２は、２タプル接続情報（ＳＡ、ＳＰ、およびＤＡはゼロにされている）を含み、ＳＹＮハッシュ・プロセス３５０においてハッシュ・キーとして使用されるものである。パターン３５４を作成するために、パターン３５２の全バイトは図示の通りスワップされる。このスワッピングは、「エントロピ」（最大の変動（the most variation））が左側の最上位ビット内にあり、その結果、ダイレクト・テーブル２２内のパターンの分散が最も効率的になるように選択される。最大のエントロピ（themost entropy）を含む元のキーのバイト・フィールドをそのキーの最上位バイトに移動することにより、最大出力エントロピはハッシュ・プロセスの最上位ビットに含まれる。この例では、スワッピング前のキーはＡＢＣＤＥＦＧＨＩＪＫＬＭ０００であり、スワップ後のパターンはＫＬＭＧＨＡＢＣＤＥＦＩＪ０００である。

パターン３５６を作成するために追加のスワッピングが実行され、それぞれの３２ビットは３２ビット・ハッシュ３５８の対象となる。このハッシュ３５８は、標準的なハッシュ・アルゴリズムにすることができる。結果的に、ハッシュ・プロセスの結果である最終的な３２ビット・パターンが得られるように、ハッシュの結果は図示の通りステージ３６０でＸＯＲが取られる。ダイレクト・テーブル２２へのインデックスを計算するために、その結果の最上位ビット（ダイレクト・テーブルに必要なもの）が使用される。

図８は、図２のステップ１２０および図４のステップ２２６で使用することができる本発明のＴＣＰ／ＵＤＰハッシュ・プロセス３７０を示している。６タプル・パターン３７２は、５タプル接続情報を含み、ハッシュ・プロセス３７０においてハッシュ・キーとして使用されるものである。パターン３７４を作成するために、パターン３７２の全バイトは図示の通りスワップされる。このスワッピングは、上述のプロセス３５０と同様に、エントロピが最上位ビット内にあるように選択される。この例では、スワッピング前のキーはＡＢＣＤＥＦＧＨＩＪＫＬＭ０００であり、スワップ後のパターンはＣＤＩＪＡＢＥＦＧＨＫＬＭ０００である。

パターン３７６を作成するために追加のスワッピングが実行され、それぞれの３２ビットは３２ビット・ハッシュ３７８の対象となる。このハッシュ３７８は、標準的なハッシュ・アルゴリズムにすることができる。結果的に、ハッシュ・プロセスの結果である最終的な３２ビット・パターンが得られるように、ハッシュの結果は図示の通りステージ３８０でＸＯＲが取られる。ダイレクト・テーブル２２へのインデックスを計算するために、その結果の最上位ビット（ダイレクト・テーブルに必要なもの）が使用される。

図示の諸実施形態により本発明を説明してきたが、当業者であれば、この諸実施形態に対する変形が可能であり、これらの変形が本発明の精神および範囲内になることを容易に認識するであろう。したがって、特許請求の範囲の精神および範囲を逸脱せずに、当業者により多くの変更を行うことができる。

本発明とともに使用するのに適したシステムの一例のブロック図である。 ネットワーク接続情報をダイレクト・テーブルに保管するための本発明の方法を示す流れ図である。 本発明によりダイレクト・テーブルへの接続情報の保管の一例を示す概略図である。 本発明のサーチ・メカニズムの基本的一実施形態の動作を示す流れ図である。 新しい接続を確立するためにパケットが受信されたときに本発明により行われるダイレクト・テーブル内の接続情報のサーチを示す概略図である。 確立された接続についてパケットが受信されたときに本発明により行われるダイレクト・テーブル内の接続情報のサーチを示す概略図である。 本発明のハッシュ・プロセスを示すブロック図である。 本発明のハッシュ・プロセスを示すブロック図である。

符号の説明

１０：サーバ・システム
１２：クライアント・コンピュータ
１４：ネットワーク接続
１６：サーバ・アプリケーション
２０：ＴＣＰ／ＩＰスタック
２２：ダイレクト・テーブル
２４：メイン・メモリ
２６：ネットワーク・アダプタ

Claims (17)

1. ネットワーク接続をサーチするための方法であって、
   コンピュータ・システムにおいてネットワークからパケットを受信し、前記パケットから接続情報を検索し、新しい接続を確立する場合に前記接続情報内の特定のフィールドをゼロにするステップと、
   ハッシュ・プロセスを使用して、前記接続情報を、新しい接続および既存の接続に関するパターンおよび関連する参照情報を保管するダイレクト・テーブル内の位置に関するアドレスに変換するステップと、
   前記受信パケットに関する参照情報を見つけるために、前記ダイレクト・テーブル内の前記アドレスによって指し示された前記位置に保管された少なくとも１つのパターンと前記接続情報を比較するステップとを含み、
   前記接続情報を新しい接続に関する前記ダイレクト・テーブル内のパターンと比較するときに、第１のハッシュ・プロセスを使用して前記ダイレクト・テーブルの前記位置への前記アドレスが提供され、前記接続情報を確立された接続に関する前記ダイレクト・テーブル内のパターンと比較するときに、第２の異なるハッシュ・プロセスを使用して前記位置への前記アドレスが提供される、
   方法。
2. 前記参照情報が、前記受信パケットを送信するための前記コンピュータ・システム内の接続を示す、請求項１に記載の方法。
3. 前記参照情報が前記パターンと同じ前記ダイレクト・テーブルの項目に保管され、前記接続情報と前記パターンとの一致により、前記項目に保管された前記参照情報を前記ダイレクト・テーブルから検索することができる、請求項２に記載の方法。
4. ハッシュ・プロセスを使用して前記接続情報をアドレスに変換する前記ステップが、前記接続情報から導出されるハッシュ・キーを使用することを含む、請求項１に記載の方法。
5. 前記ハッシュ・プロセスが、最大エントロピを含む前記ハッシュ・キーのバイト・フィールドを前記ハッシュ・キーの最上位のバイトに移動する、請求項４に記載の方法。
6. 前記ダイレクト・テーブルが、２つのフィールドがゼロにされた３タプル・パターンと、３つのフィールドがゼロにされた２タプル・パターンと、どのフィールドもゼロにされていない５タプル・パターンとを保管し、前記ダイレクト・テーブルの任意の項目にこれらのタイプのパターンのいずれかを保管することができる、請求項４に記載の方法。
7. 検索された前記接続情報全体が、５タプル・パターンとして使用され、前記ダイレクト・テーブルに保管される、確立された接続に関するパターンと比較され、特定のフィールドがゼロにされた前記接続情報が、３タプル・パターンまたは２タプル・パターンとして使用され、前記ダイレクト・テーブルに保管される、新しい接続に関するパターンと比較される、請求項１に記載の方法。
8. 前記接続情報を比較する前記ステップが、３タプル・サーチ・パターンを使用して１次比較を行うことと、２タプル・サーチ・パターンを使用して２次比較を行うことを含み、パターンに対する１次一致がまったく見つからない場合に、前記受信パケットに関する前記参照情報を決定するために２次一致が使用される、請求項１に記載の方法。
9. 前記受信パケットに関する前記参照情報を決定するために、前記ダイレクト・テーブル内のパターンに対する前記２タプル・サーチ・パターンの第１の２次一致が使用される、請求項８に記載の方法。
10. ネットワーク接続情報を保管するための方法であって、
    前記ネットワーク接続情報を受け取るステップと、
    前記ネットワーク接続情報が新しい接続を参照する場合に前記ネットワーク接続情報内の特定のフィールドをゼロにするステップと、
    ハッシュ・プロセスを使用して、前記ネットワーク接続情報をダイレクト・テーブル内のアドレスに変換するステップと、
    前記ダイレクト・テーブル内の前記アドレスに対応する位置に、パターンとしての前記接続情報と接続参照情報とを保管するステップとを含み、
    前記ダイレクト・テーブルは、新しい接続および既存の接続に関する接続情報および参照情報を保管し、
    新しい接続に関する３タプル・パターンおよび２タプル・パターンを保管するときに、第１のハッシュ・プロセスを使用して前記ダイレクト・テーブルへの前記アドレスが提供され、確立された接続に関する５タプル・パターンを保管するときに、第２の異なるハッシュ・プロセスを使用して前記ダイレクト・テーブルへの前記アドレスが提供される、
    方法。
11. ネットワーク接続に関する前記接続参照情報が前記パターンと同じ前記ダイレクト・テーブルの項目に保管され、ネットワーク接続情報を含むパケットが受信されたときに、前記ネットワーク接続情報と前記パターンとの一致により、前記項目に保管された前記参照情報を前記ダイレクト・テーブルから検索することができる、請求項１０に記載の方法。
12. ハッシュ・プロセスを使用して前記接続情報をアドレスに変換する前記ステップが、前記接続情報から導出されるハッシュ・キーを使用することを含む、請求項１０に記載の方法。
13. 前記ダイレクト・テーブルが、２つのフィールドがゼロにされた３タプル・パターンと、３つのフィールドがゼロにされた２タプル・パターンと、どのフィールドもゼロにされていない５タプル・パターンとを保管し、前記ダイレクト・テーブルの任意の項目にこれらのタイプのパターンのいずれかを保管することができる、請求項１２に記載の方法。
14. 前記ネットワーク接続情報内の特定のフィールドをゼロにする前記ステップが、３タプル・パターンまたは２タプル・パターンを作成するために複数フィールドをゼロにすることを含み、前記パターン内のソース・アドレスおよびソース・ポート・フィールドをゼロにすることにより前記３タプル・パターンが作成され、前記パターン内のソース・アドレス、ソース・ポート、および宛先アドレス・フィールドをゼロにすることにより前記２タプル・パターンが作成される、請求項１０に記載の方法。
15. 確立された接続に関するパターンを保管するときに、前記接続情報が５タプル・パターンとして前記ダイレクト・テーブルに保管され、新しい接続に関するパターンを保管するときに、前記接続情報が前記特定のフィールドがゼロにされた３タプル・パターンまたは２タプル・パターンとして前記ダイレクト・テーブルに保管される、請求項１０に記載の方法。
16. 接続がセットアップされることをサーバ・アプリケーションが要求するときに、新しい接続に関するパターンおよび参照情報が前記ダイレクト・テーブルに保管される、請求項１０に記載の方法。
17. 前記ダイレクト・テーブルを保管するサーバにおいてネットワークを越えてクライアントからパケットが受信されるときに、確立された接続に関するパターンおよび参照情報が前記ダイレクト・テーブルに保管される、請求項１０に記載の方法。

Images