データ処理システムによりデータを送信または受信するための方法であり、該システムは、オペレーティングシステムおよびアプリケーションをサポートし、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースにアクセスでき、該方法は:データ処理システムおよびネットワークインターフェースデバイス間のデータ転送におけるデータバッファおよび接続状態バッファとして使用するために、1つまたはそれ以上のメモリ領域を割り当てること;ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、アプリケーションによりメモリ領域の少なくとも1つに直接アクセスすること;アプリケーションが無応答であると決定された場合に、ネットワークインターフェースデバイスが、オペレーティングシステムにシグナル通知して、前記メモリ領域の少なくとも1つにアクセスさせること;およびネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、オペレーティングシステムが、シグナルに応答して、データバッファおよび接続状態バッファの少なくとも1つに直接アクセスすること、を含む方法。ネットワークデバイスによりネットワークからデータを受信すること;およびネットワークデバイスにより前記領域の少なくとも1つにデータを書き込むことを含む、請求項1に記載の方法。アプリケーションが無応答であると決定された場合に、前記領域の少なくとも1つにアクセスするために、ネットワークデバイスが、オペレーティングシステムにシグナル通知するように構成されており、また、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも1つに直接アクセスする前記ステップを行うことを含む、請求項2に記載の方法。ネットワークデバイスがタイマーをサポートし、および受信データが前記領域の少なくとも1つに書き込まれたときに、方法が、タイマーをスタートし、事前設定の初期値からカウントすることを含み、およびタイマーが事前設定の最終値に達した場合に、アプリケーションが無応答であると決定される、請求項3に記載の方法。アプリケーションにより初期値および/または最終値を設定するステップを含む、請求項4に記載の方法。アプリケーションにより前記領域の少なくとも1つから受信データを読み取ったときに、アプリケーションによりタイマーを停止することを含む、請求項4または5に記載の方法。ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスする前記ステップのそれぞれが、ネットワークインターフェースデバイスによりネットワークから受信され、前記領域の少なくとも1つに保管されたデータのプロトコル処理を含む、請求項1~6のいずれかに記載の方法。プロトコル処理ステップが、受信データからトラフィックデータを抽出することを含む、請求項7に記載の方法。プロトコル処理ステップが、受信データの少なくともいくつかに関して、ネットワークインターフェースデバイスに、肯定応答および/または再送信メッセージをネットワーク上に送信させることを含む、請求項7に記載の方法。ネットワークデバイスにより、前記領域の少なくとも1つからデータを読み取ること;およびネットワークデバイスにより、そのデータをネットワーク上に送信することを含む、請求項1に記載の方法。ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスする前記ステップのそれぞれが、送信用のデータを前記領域の少なくとも1つに保管することを含む、請求項10に記載の方法。ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスする前記ステップのそれぞれが、ネットワークデバイスを起動して、前記領域の少なくとも1つからデータを読み取る前記ステップを行うことを含む、請求項10または11に記載の方法。アプリケーションが無応答であると決定された場合に、前記領域の少なくとも1つにアクセスするために、ネットワークデバイスが、オペレーティングシステムにシグナル通知するように構成されており、および方法が、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも1つに直接アクセスする前記ステップを行うことを含む、請求項12に記載の方法。ネットワークデバイスがタイマーをサポートし、および受信データが前記領域の少なくとも1つに書き込まれたことをネットワークインターフェースデバイスによりアプリケーションがシグナル通知されたときに、方法が、タイマーをスタートし、事前設定の初期値からカウントすることを含み、およびタイマーが事前設定の最終値に達した場合に、アプリケーションが無応答であると決定される、請求項13に記載の方法。アプリケーションにより初期値および/または最終値を設定するステップを含む、請求項14に記載の方法。データの送信または受信システムであり、該システムは:オペレーティングシステムおよびアプリケーションをサポートし、データ処理システムおよびネットワークインターフェースデバイス間のデータ転送におけるデータバッファおよび接続状態バッファとして使用するために割り振られている1つまたはそれ以上のメモリ領域にアクセスさせるデータ処理システム;およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートでき、アプリケーションが無応答であると決定された場合に、オペレーティングシステムにシグナル通知するように構成されているネットワークインターフェースデバイスここで、アプリケーションは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスするように構成されており、オペレーティングシステムは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、前記データバッファおよび接続状態バッファの少なくとも1つに直接アクセスするように構成されているを含む、システム。少なくとも部分的に、これら問題a~eの1つまたはそれ以上に取り組むシステムを提供することは望まれているであろう。発明の概要本発明の一側面によれば、概略的に記載されるように、データ処理システムによるデータ送信方法が提供され、該システムは、オペレーティングシステムおよび少なくとも1つのアプリケーションをサポートでき、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースデバイスにアクセスでき、該方法は:送信されるデータをアプリケーションにより形成するステップ;アプリケーションにより、データ処理システムの非オペレーティングシステム機能に、送信されるデータを送ることを要求するステップ;その要求に応答する:送信されるデータをメモリ領域に書き込むステップ;および非オペレーティングシステム機能およびネットワークインターフェースデバイス間の直接通信により、ネットワーク上に、データの少なくともいくつかの送信操作を開始するステップ;および続いて、オペレーティングシステムによりメモリにアクセスするステップ、およびネットワークインターフェースデバイスによりネットワーク上にデータの少なくともいくつかの送信操作の少なくとも一部を行うステップを含む。好ましくは、オペレーティングシステムはネットワークインターフェースデバイスと直接通信できる。非オペレーティングシステム機能間の前記直接通信は、好ましくはオペレーティングシステムを迂回する。非オペレーティングシステム機能は、好ましくはソフトウェアにより、最も好ましくはデータ処理システム上で実行するソフトウェアによりインプリメントされる。それは、都合の良いことには、転送ライブラリであってもよい。非オペレーティングシステム機能は、最も好ましくは、それが行うステップを達成するために、特権レベルで増加を要求しない。前記メモリ領域は、メモリの第2領域にマップされていてもよい。メモリの第2領域は、オペレーティングシステムとアクセス可能、最も好ましくは直接アクセス可能であってもよいが、非オペレーティングシステム機能とは直接アクセスできない。該方法は、ネットワーク上にデータの送信操作を開始するときに、タイマーをスタートすること;および肯定応答がそのデータに対して受信される前にタイマーが予定値に達した場合に、ネットワークインターフェースデバイスからデータ処理システムに失敗メッセージを送信することを含み得る。該方法は、ネットワーク上にデータの送信操作を開始するときに、その操作の記録およびデータソースであったアプリケーションの表示を保管すること;およびそのアプリケーションのためのデータを受信したときに、そのアプリケーションと関連する各記録に対してタイマーをスタートすること;および肯定応答がそのデータに対して受信される前に前述のタイマーが予定値に達した場合に、ネットワークインターフェースデバイスからデータ処理システムに失敗メッセージを送信することを含み得る。好ましくは、タイマーまたは各タイマーはネットワークインターフェースデバイス上で実行される。該方法は、データに対して肯定応答を受信したときにタイマーを取り消すことを含んでもよく、その中で失敗メッセージまたは各失敗メッセージは、オペレーティングシステムに向けて発せられる。タイマーを取り消すステップは、エンティティをシグナル通知するアプリケーションを含んでもよく、そこでタイマーは、オペレーティングシステムを迂回する方式で実行される。失敗メッセージまたは各失敗メッセージは、好ましくはデータソースであったアプリケーションに向けて発せられる。オペレーティングシステムは、好ましくは、失敗メッセージに対応するデータに関して、前記送信操作の少なくとも一部を行うためのネットワークデバイスともはや通信していないアプリケーションに向けて発せられる失敗メッセージに応答する。本発明の第2側面によれば、概略的に記載されるように、データ処理システムによりデータを受信するための方法が提供され、該システムは、少なくとも1つのアプリケーションをサポートでき、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースデバイスにアクセスでき、該方法は:データ処理システムの非オペレーティングシステム機能により、アプリケーションでデータを受信するためのチャネルを確立するステップ、該チャネルはメモリ領域と関連する;そのチャネルを通じて:ネットワークインターフェースデバイスがメモリ領域に受信データを書き込むこと;およびアプリケーションがその領域から受信データを読み取ること;および続いてアプリケーションがネットワークデバイスと通信できない場合、オペレーティングシステムがその領域から受信データを読み取ることによりデータを受信するステップを含む。好ましくは、オペレーティングシステムは、アプリケーションがネットワークデバイスと通信できないという決定がなされたときに、自動的にその領域から受信データを読み取るように構成されている。本発明の第3側面によれば、概略的に記載されるように、データ処理システムによるデータ送信方法が提供され、該システムは、少なくとも1つのアプリケーションをサポートでき、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースデバイスにアクセスでき、該方法は:送信されるデータをアプリケーションにより形成するステップ;そのデータを、送信のためにネットワークインターフェースデバイスに受け渡すステップ;ネットワークインターフェースデバイスによりデータを送信するステップ、および任意にその送信の際に、データに対応するタイマーを確立するステップ;および肯定応答がそのデータに対してネットワーク上で受信された場合に、タイマーを取り消すステップ;またはタイマーが予定値に達した場合に、ネットワークインターフェースデバイスにより、肯定応答がそのデータに対して受信されなかったことを示すために、オペレーティングシステムにシグナル通知するステップを含む。タイマーを、そのタイマーの確立でスタートさせてもよい。タイマーが確立されたときそれを、その送信でタイマーが確立されたデータのソースであったアプリケーションに向けて発せられるデータを受信することで、スタートさせてもよい。前記データ受け渡しは、データ処理システムの非オペレーティングシステム機能により行い得る。非オペレーティングシステム機能は、転送ライブラリであってもよい。前記データ受け渡しは、オペレーティングシステムを迂回することで行い得る。前記シグナル通知は、失敗イベントをオペレーティングシステムのイベントキューに適用することを含み得る。本発明の第4側面によれば、概略的に記載されるように、データ処理システムによりデータを送信または受信するための方法が提供され、該システムは、オペレーティングシステムおよびアプリケーションをサポートし、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースにアクセスでき、該方法は:データ処理システムおよびネットワークインターフェースデバイス間のデータ転送におけるデータバッファおよび接続状態バッファとして使用するために、1つまたはそれ以上のメモリ領域を割り当てること;ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、アプリケーションによりメモリ領域の少なくとも1つに直接アクセスすること;アプリケーションが無応答であると決定された場合に、ネットワークインターフェースデバイスが、オペレーティングシステムにシグナル通知して、前記メモリ領域の少なくとも1つにアクセスさせること;およびネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、オペレーティングシステムが、シグナルに応答して、データバッファおよび接続状態バッファの少なくとも1つに直接アクセスすることを含む。好ましくは、該方法は:ネットワークデバイスによりネットワークからデータを受信すること;およびネットワークデバイスにより前記領域の少なくとも1つにデータを書き込むことを含む。好ましくは、ネットワークデバイスは、アプリケーションが無応答であると決定された場合にオペレーティングシステムにシグナル通知して、前記領域の少なくとも1つにアクセスするように構成されており、方法は、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも1つに直接アクセスする前記ステップを行うことを含む。前記シグナルは、割り込みであってもよい。好ましくは、ネットワークデバイスはタイマーをサポートし、方法は、受信データが前記領域の少なくとも1つに書き込まれたときに、タイマーをスタートし、事前設定の初期値からカウントすることを含み、アプリケーションは、タイマーが事前設定の最終値に達した場合に、無応答であると決定される。好ましくは、最終値はゼロである。好ましくは、該方法は、アプリケーションにより初期値および/または最終値を設定するステップを含む。最も好ましくは、最終値はゼロであり、初期値だけがアプリケーションにより設定される。該方法は、好ましくはアプリケーションにより前記領域の少なくとも1つから受信データを読み取ったときに、アプリケーションによりタイマーを停止することを含む。好ましくは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスする前記ステップのそれぞれは、ネットワークインターフェースデバイスによりネットワークから受信され、前記領域の少なくとも1つに保管されたデータのプロトコル処理を含む。プロトコル処理は:受信データからトラフィックデータを抽出すること、受信データの少なくともいくつかに関して、肯定応答および/または再送信メッセージをネットワーク上に送信すること、受信データ中の受信データ単位のシーケンス値をチェックすること、および受信データに関してチェックサムを計算することの1つまたはそれ以上を含み得る。プロトコルはTCPであってもよい。好ましくは、該方法は:ネットワークデバイスにより、前記領域の少なくとも1つからデータを読み取ること;およびネットワークデバイスにより、そのデータをネットワーク上に送信することを含む。好ましくは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスする前記ステップのそれぞれは、送信用のデータを前記領域の少なくとも1つに保管することを含む。好ましくは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも1つのために、メモリ領域の少なくとも1つに直接アクセスする前記ステップのそれぞれは、ネットワークデバイスを起動して、前記領域の少なくとも1つからデータを読み取る前記ステップを行うことを含む。好ましくは、ネットワークデバイスは、アプリケーションが無応答であると決定された場合に、オペレーティングシステムにシグナル通知して、前記領域の少なくとも1つにアクセスするように構成されており、方法は、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも1つに直接アクセスする前記ステップを行うことを含む。本発明のさらなる側面によれば、上記のあらゆる方法を行うためのシステムが提供される。図面の説明本発明を、これから添付図面を参照しながら、例として説明していく:図1は、使用時のネットワークインターフェースデバイスの概略図である;図2は、転送ライブラリアーキテクチャのインプリメンテーションを示す;図3は、ユーザーレベルTCP転送と共に標準的なカーネルTCP転送を用いるアーキテクチャを示す;図4は、標準的なカーネルスタックがユーザーレベルでインプリメントされているアーキテクチャを示す;図5は、TCP転送アーキテクチャの例を示す;図6は、着信TCP/パケットをフィルターに掛けるために、ネットワークインターフェースデバイスにより行うことができるステップを示す;図7は、コンテンツアドレス可能メモリによりサーバー受動接続の操作を示す。図面の詳細な説明以下の記載は、あらゆる当業者が本発明を作り、使用できるようにするために示され、特定の適用およびその要件との関連で提供される。開示された実施態様の様々な修正は、当業者にとって容易に理解できるであろう、そしてこの中で明確にされた一般原理は、本発明の意図および範囲から外れることなく、他の実施態様および適用に応用することができる。従って本発明は、示した実施態様に限定されることは意図されておらず、この中で開示された原理および機能と矛盾しない最も広い範囲と一致させられることが意図されている。図5は、ネットワークインターフェースデバイス、例えば図1のデバイス10と、コンピューター、例えば図1のコンピューター1との間のインターフェースを提供するために適したTCP転送アーキテクチャの一例を示す。アーキテクチャは、このインプリメンテーションに限定されない。図5の例のアーキテクチャと従来のアーキテクチャとの間の主な違いは、以下のようなものである。iネットワーク接続の代わりにプロトコル処理を行うTCPコードは、転送ライブラリおよびOSカーネルの両方に位置指定される。このコードがプロトコル処理を行うということが、特に重要である。ii接続状態およびデータバッファは、カーネルメモリおよび転送ライブラリのアドレススペースにマップされたメモリに保持される。オペレーティングシステムは、それらバッファの所有者であり、そうしてそれらを完全に制御するが、それらは、その通信のためにそれらが使用されるアプリケーションにより直接アクセスすることができる。これは、アプリケーションが、それらバッファを通じてデータを直接送受信すること、および状態データを対応する状態バッファから読み取ることを可能にする。iiiカーネルおよび転送ライブラリコードの両方が、特定のネットワーク接続のために、およびこれに代わって、仮想ハードウェアインターフェースにアクセスできる。ivタイマーは、仮想ハードウェアインターフェースを通じて管理することができ、これらはネットワークインターフェースデバイス上の実タイマーに対応する、システムコールにそれらを設定およびクリアすることを要求しなくてもよい。NICは、タイマーイベントを発生させ、それは、ネットワークインターフェースデバイスドライバにより受信され、デバイスのためにTCPサポートコードに受け渡される。ネットワークインターフェースデバイスのためのTCPサポートコードは、汎用OSに加えて、TCPインプリメンテーションであることは注目すべきである。これは、適切には、ネットワークインターフェースデバイスのスタックと共存できる。図5のアーキテクチャにおいてバッファは、ネットワーク上でデータを送信および/または受信するためにNICと共同して使用されるため、データプロセッサ上のメモリに割り振られる。データ送信に使用するための送信バッファの場合、NICは、そのバッファからデータを読み取り、それをネットワーク上に送信するために構成される。NICは、自動的にそのデータを読み取り、それを送信することができるか、またはそれは、アプリケーション、もしくはデータプロセッサ上で実行するオペレーティングシステムによりデータを読み取るために起動され得る。トリガーは、好都合には割り込みであり得る。データ受信に使用するための受信バッファの場合、NICは、そのバッファに、ネットワーク上で受信されたデータを書き込むために構成される。受信バッファ中のデータは、次いでアプリケーションまたはオペレーティングシステムにより読み取られ、さらにそれにより処理され得る。バッファは、最も好都合にはオペレーティングシステムに所有される。これは、それが、制御を有し、その制御でエンティティがバッファにアクセスでき、それがバッファを割り当てるおよび/または作成し、そしてそれが、それらを削除する責任があるという意味である。しかしアプリケーションおよびオペレーティングシステムの両方は、バッファに、それらからデータを読み取り、それらにデータを書き込むために直接アクセスできる。これらステップが起こる環境は、以下で記載される。データ送信の場合、アプリケーションは、送信のためにデータをバッファに書き込み、次いでNICを起動してバッファから読み取り、そのデータを送信することが期待される。いくつかの状態において、これ単独で、データをネットワーク上に首尾よく送信させるために充分であり得る。しかしNICは、送信または受信データのプロトコル処理を行わない。代わりにそれは、アプリケーションまたはオペレーティングシステムにより行われる。それゆえ、例えばデータが目的の受信側で首尾よく受信されない場合、アプリケーションまたはオペレーティングシステムは、肯定応答、再送信要求などを使用時のプロトコルにより処理し、NICに再送信させなければならない。普通これは、アプリケーションによりなされると考えることができる。NICが、肯定応答メッセージまたはアプリケーションに対するタイムアウトのようなデータを有するときは、NICは、それを受信バッファおよび/またはイベントキューのいずれかに書き込む。同時にそれは、タイマー実行をスタートする。アプリケーションがデータにアクセスするとき、それは、タイマーを停止およびリセットする。そのようにして、NICは、アプリケーションが応答であることを知る。しかし、タイマーが予定値に達した場合、NICは、アプリケーションが無応答であると決定し、アプリケーションのためにデータを操作するために、オペレーティングシステムに、例えば割り込みによりシグナル通知する。これは、多くの利点を有する。第1に、アプリケーションがビジーである、またはスケジュール解除descheduledされた場合でさえ、データ送信をオペレーティングシステムにより進めることができる。第2にそれは、オペレーティングシステムが必要ならば引き継ぐので、アプリケーションがデータを送信キューに配置するとすぐに、アプリケーションに、例えばそれ自身スケジュール解除descheduledすることにより、意図的にデータを無視する機会を与える。好ましくは、アプリケーションは、例えばその初期値を設定することにより、タイマーの長さを制御する。これにより、アプリケーションが、タイマーを設定して、その優先度に適合させることができる。タイマーは、好ましくはアプリケーションが直接アクセスできるNIC上のハードウェアリソースである。データ受信の場合にNICは、データを受信し、それを受信バッファに書き込む。そうするときにそれは、上記のようにタイマーを設定し、好ましくはイベントキューを介してアプリケーションに通知する。アプリケーションがデータにアクセスするとき、それは上記のようにタイマーをリセットする。これは、アプリケーションが無応答であるときに、再びNICに決定の可能性を与える。他の手段、例えばバッファ中でのNICによるデータの定期的スキャンを、同じ目的のために使用してもよい。アプリケーションが無応答であると決定されると、再びNICは、受信データを処理するためにオペレーティングシステムにシグナル通知する。受信データの場合、アプリケーションまたはオペレーティングシステムのいずれかによる処理は、典型的に、プロトコル処理例えばパケットシーケンス番号のチェック、チェックサムの処理、トラフィックデータの抽出および/または肯定応答若しくは再送信要求を送信するためのNICへのシグナル通知および/または使用のための、典型的にユーザーレベルでのバッファからのデータ除去を含む。バッファは、好ましくはオペレーティングシステムにより割り振られるが、それが、アプリケーションからの要求に応答して行われることは便利である。従って受信データが、アプリケーションのために利用できる受信バッファをオーバーフローさせる場合、アプリケーションは、オペレーティングシステムによりさらなるバッファの割り振りを要求できる。NICは、フリーで残っている受信バッファの量のような要因を考慮する事前保管ルールに基づいてこの状態が生ずる場合に、イベントによりアプリケーションにシグナル通知することができる。再びそれは、このシグナル通知が行われたときにタイマーを設定することができ、そしてアプリケーションが応答しない場合にNICは、さらなる受信バッファのために、要求をオペレーティングシステムに送信できる。オペレーティングシステムは、次いでそのバッファを割り当てることができ、アプリケーションが無応答である場合でさえ、データがアプリケーションに受信され続けられるように、NICにそれを通知する。このアーキテクチャの効果は以下のようなものである。a転送ライブラリでアクティブな複数スレッドのための要件TCPコードは、転送ライブラリ中でシステムAPIコール例えばrecv図5のステップi参照の結果として、またはタイマーイベント図5のステップii参照の結果としてカーネルによるいずれかで実行することができるので、この要件は、図5のアーキテクチャのために存在しない。いずれかの場合、VI仮想インターフェースを管理でき、両方のコードパスは、接続状態またはデータバッファにアクセスでき、その保護および相互排他は、共有メモリロックにより管理できる。転送ライブラリレベルでスイッチするスレッドのオーバーヘッドが除去されるのと同様に、この機能は、アプリケーションがそれらスレッドおよび単一操作想定を変更する要件を妨げることができる:例えばいくつかの状態で、単一スレデッドアプリケーションに複数スレデッドライブラリとリンクするよう要求することは、非許容であり得る。bタイマー管理のためにシステムコールを出す要件ネットワークインターフェースデバイスは多くのタイマーをインプリメントすることができ、これらを、特定の仮想インターフェースインスタンスに割り当てることができる:例えばアクティブTCP転送ライブラリごとに1つのタイマーが存在し得るので、この要件は、図5のアーキテクチャのために存在しない。これらタイマーは、メモリマップVIを通じてプログラム可能にすることができ図5のステップiii参照、その結果、イベント図5のステップiv参照を出すことができる。タイマーは、システムコール無しで、-オペレーティングシステムを直接含まずに-、設定およびクリアできるので、タイマー管理のためのオーバーヘッドは大幅に削減される。c複数転送ライブラリへのパケットの訂正配信ネットワークインターフェースデバイスは、コンテンツアドレス可能メモリを含有するか、またはそれにアクセスでき、これは、着信パケットのヘッダーから得られるビットを並列ハードウェア一致操作として一致させることができる。一致の結果を、配信のために使用されなければならない宛先仮想インターフェースを示すために得ることができ、ハードウェアは、VIに押し付けられたバッファに、パケットを配信し続けることができる。一致処理のために1つの可能な配列は、以下で記載される。下記配列は、IPv6と関連したより大きなホストアドレスを逆多重化するために拡張してもよいが、これは、記載されるような配列よりも広いCAMまたはパケットごとに複数のCAM検索を要求するであろう。この目的のためにCAM使用の1つの代替は、使用される仮想インターフェースを決定するためにパケットのヘッダーからのデータを処理させるハッシュアルゴリズムを使用することである。d処理/アプリケーション/スレッド間の接続引渡しネットワーク接続が引き渡されるとき、同じシステム共通リソースハンドルを、アプリケーション間で受け渡すことができる。これは、例えばファイル記述子であってもよい。ネットワークインターフェースデバイスのアーキテクチャは、ネットワーク接続と関連した全ての状態を、その例えばファイル記述子で接続でき、この状態で転送ライブラリにメモリマップすることを要求できる。ネットワーク接続の引渡し後に、新しいアプリケーションはアプリケーション、スレッドまたは処理のいずれかとして、-それが異なるアドレススペース内で実行する場合でさえ-、メモリマップし、状態を使用し続けることができる。さらに、カーネルおよび転送ライブラリ間で使用されるのと同じバッキングプリミティブにより、あらゆる数のアプリケーションは、標準的なシステムAPIにより指定されるのと同じ意味で、ネットワーク接続の使用を共有できる。e転送ライブラリが停止または強制終了または終了されたときの転送プロトコル処理の完了接続状態およびプロトコルコードはカーネル常駐のままでいられるので、このステップを、ネットワークインターフェースデバイスのアーキテクチャにおいて達成できる。OSカーネルコードは、汎用TCPTCPkプロトコルスタックと同じように、アプリケーション状態の変化を通知され得る。停止されたアプリケーションは、次いで先行プロトコル実行にスレッドを提供しないが、プロトコルは、例えば先行技術のカーネルスタックプロトコルのために知られているように、タイマーイベントを介して続けられるであろう。IETFRDMAおよびiSCSIのような多くの新生プロトコルがある。これらプロトコルの少なくともいくつかは、TCPおよび他のプロトコルコードがネットワークインターフェースデバイス上で実行する環境で、実行するように設計された。機能は今から説明され、それによって前述のプロトコルが、ホストCPU上で即ちネットワークインターフェースデバイスが接続されているコンピューターの処理手段を使用することで実行できる。そのようなインプリメンテーションは有利である。なぜならそれにより、ユーザーは、コプロセッサに対するメインCPUテクノロジーの価格/パフォーマンスの優位を生かすことができるからである。RDMAのようなプロトコルは、フレーム指示情報および巡回冗長検査CRCデータをTCPストリーム内に埋め込むことを含む。フレーム指示情報は、プロトコルライブラリ内で計算するにはつまらないので、CRCは、チェックサムとは対称的に計算集約型であり、ハードウェアにより最良になされる。これを適合させるために、TCPストリームが、RDMAまたは類似のカプセル化を行うときに、仮想インターフェース中のオプションは、例えばフラグにより可能にされ得る。このオプションを検出するときに、NICは、送信で各パケットを構造解析し、RDMAフレームを回復し、RDMACRCアルゴリズムを適用し、転送中の飛行でCCRCを挿入する。類似の手順を、有利には、エラーチェックデータの相対的に計算集約型の計算を要求するiSCSIのような他のプロトコルに関して使用できる。このシステムと一致して、ネットワークインターフェースデバイスも、類似の論理を使用して受信パケットでCRCを検査できる。これは、例えば標準的なTCPチェックサムオフロード技術に似た方法で行うことができる。RDMAのようなプロトコルは、従来のインプリメンテーションにおいてネットワークインターフェースデバイス上で追加知能を要求するRDMAREADのような追加操作も命令する。RDMA/TCPは、最良にはコプロセッサネットワークインターフェースデバイスによりインプリメントされるべきであるという一般的信念に、このタイプのインプリメンテーションはつながっている。この中で記載されるタイプのアーキテクチャでは、特定のハードウェアフィルターは、前述の上位プロトコル要求を特定のネットワーク接続のために捕捉するようエンコードすることができる。そのような環境で、NICは、配信データメッセージと同様に、添付コンピューター上でのソフトウェア実行によりアクションを要求するために、タイマーイベントに似たイベントを生み出すことができる。そのような方式でイベントを起動することにより、NICは、転送ライブラリまたはカーネルヘルパーのいずれかが、要求に対して直ちに作動するという結果を達成できる。これは、転送ライブラリがスケジュールに入れられるまではカーネル拡張が実行されないという潜在的問題を回避でき、必要ならば他の上位プロトコルに適用できる。コプロセッサTCPインプリメンテーションのために促進された1つの利点は、ゼロコピー操作を送受信で行う能力である。実際上、コンテキストスイッチまたは他のキャッシュまたはTLB送信索引バッファフラッシュ操作が受信パス上で存在しない場合、上記アーキテクチャのためのように、受信で、単一コピーのためのオーバーヘッドがほとんど存在しない。これは、プロセッサに受信データをロードするという目的を果たすからである。アプリケーションは、続いてデータにアクセスするときに、それはキャッシュミスに影響されず、そうでなければこれは、ゼロコピーインターフェースのケースであろう。しかし転送で、転送ライブラリにより作成された単一コピーは、プロセッササイクルおよびキャッシュ汚染の両方で追加オーバーヘッドを呼び出す。上記アーキテクチャは、例えば以下の機構がインプリメントされている場合、送信操作でのコピーを回避させることができる:i例えば低待ち時間環境で送信データが、早急に確認され得る;代わりにii例えば帯域幅×遅延の積がメッセージサイズよりも小さい場合転送における全てのデータが送られる前に、そこでデータがほぼ完全に確認される。転送ライブラリは、送信バッファを、それからのデータが確認されるまで単純に保持することができ、データはコピーされずに送信される。これは、非同期ネットワーキングAPIがアプリケーションによって使用されるときにも、行うことができる。データコピーを回避できない場合でさえ、転送ライブラリは、非一時的ストアを実行するメモリコピールーチンを使用できる。これらは、キャッシュよりもむしろメモリにコピーされたデータを残すことができ、そうしてキャッシュ汚染を回避する。送信のための次のステップは、ネットワークインターフェースデバイスによるデータのDMAであると期待され、このDMA操作のパフォーマンスは、キャッシュよりもむしろメモリ中にあるデータによっては影響されそうにないので、キャッシュ中にないデータは、パフォーマンスに影響しないと期待される。図6は、着信TCPパケットをフィルターに掛けるために、上記ネットワークインターフェースデバイスにより取り得るステップを示す。ステップIでパケットは、ネットワークからネットワークインターフェースデバイスで受信され、受信デコードパイプラインに入る。ステップiiでハードウェアは、パケットから関連するビットを抽出し、CAMに与えられるこの例では32ビット長であるフィルターを形成する。関連ビットの構成および数は、使用中であるプロトコルに依存するこの例は、TCP/IPおよびUDP/IPに関する。ステップiiiではCAM一致がなされたとき、それは、インデックスに帰着する:MATCH_IDXは戻り、これは配信情報例えばこの接続のための次の受信バッファのメモリアドレスを検索するために使用できる。ステップivで、この配信情報は、パケットデコードパイプラインにフィードバックされ、パケットが適切なメモリ位置に配信されることを可能にする。フィルターを形成するためのビットの選択およびそれらの使用をこれから記載する。ネットワークインターフェースデバイスは、好ましくはハードウェア中で、それが実質上ネットワークヘッダーを休止できるようにするため、着信パケットフローに割り込むか、またはそれをバッファに入れることができる。このことは、データフローに影響せずに、それが着信パケット中の関連ビットシーケンスを識別することを許す。TCPおよび/またはUDPパケットのために、ビットシーケンスの識別を、例えば前述のパケットの単純ヘッダーレイアウトのせいで単純デコードパイプラインを使用して、インプリメントしても良い。これは、レジスターに保持された多くのフィールドに帰着する。ゼロは、有効なポート番号または有効なIPアドレスのいずれでも無く、フォークコマンドまたはその等価物の後に、ソケットが共有される場合を除いて分離処理におけるインターフェースは、ローカルIPアドレスおよびポートペアを共有しないことが想定される。後者の条件は、受信TCPパケットを逆多重化するときに、ローカルIPアドレスを無視するのが安全であることを意味する。TCPソケットだけをリスンするために、ローカルIPおよびポート番号が考慮される必要があり、一方、確立TCPソケットのためにリモートIPおよび両方のポート番号が考慮されるべきである。そのためネットワークインターフェースデバイスにより行われる処理は、好都合にはハードウェア中で、受信パケットがTCPまたはUDPパケットのいずれであるかを決定し、TCPパケットのためにSYNおよびACKビットを検査しなければならない。次いでそれは、しかるべくトークンを形成することができ、これはCAM中で検索される。CAM操作は、以下の表で示される。この表では、最初の列は受信パケットのタイプを示し、残りの列は、それぞれトークンの最初の32ビット、次の16ビットおよび最後の16ビットのコンテンツを示す。同じ規則が一貫して使用される場合、ビット順序は重要ではない。以下の表は、例を示す:例では、番号1は、192.168.123.135:80でのローカルウェブサーブリスニングのための状態を示し;番号2は、そのサーバーにより66.35.250.150:33028から受け入れられる接続のための状態を示し;番号3は、ローカルに開始される66.35.250.150へのテルネット接続を示し;および番号4は、ポート123でのアプリケーション受信UDPパケットのための状態を示す。表1の最初の行のように、TCPSYN=1ACK=0の状態を分離することにより、そのようなエントリーは、LISTEN状態のソケットに向けられるTCP接続要求メッセージと一致するが、SYN_SENT状態のソケットに向けられる接続応答と一致しないことを確保できる。ゼロフィールドの他の組合わせは、他のフィールドで逆多重化するために使用され得る。例えば逆多重化は、イーサネット登録商標ヘッダーのETHER_TYPEフィールドで行われ得る。CAMフィルターの構成を決定する論理は、使用されるプロトコルに依存する。特定のインプリメンテーションにおいてCAMを、仮想インターフェースを通して転送ライブラリコードにより構成することができ、それは特定のインプリメンテーションのために動的にセットアップされる。UDPプロトコル下では、UDPパケット中で指定される各ネットワークエンドポイントを、表1に示されるように、フィルターにより一意的に識別できる。TCPプロトコル下において、エンドポイントの固有識別は、それが明確に指定されるために、全てのホストおよびポートフィールドを普通は要求する。複数クライアントが同じ宛先ホストおよびポートアドレスでネットワークエンドポイントと接続すること、接続がクライアントまたはサーバーのいずれかから開始されること、またはサーバーネットワークエンドポイントが単一エンドポイントで接続要求を受け入れ、データ転送を操作するために新しいネットワークエンドポイントを作成することを、TPCプロトコル定義が許すので、この要件が生ずる。前述のパケットにおけるヘッダーは、典型的に96ビット長である。しかし96ビットフィルターを構成することは、ほとんどの市販CAMのためには効率的ではない。なぜならそれらは、典型的に96よりはむしろ64または128ビットの幅で入手されるからである。以下の機構は、64ビットフィルターがより効率的に構成されることを可能にする。CAMの長さは、アプリケーションを適合させるために選択することができる。便利なサイズは16kbであり得る。1サーバーPASSIVEソケットが新しい接続をリスンする場合、全ての有効な着信TCPパケットは、シーケンス番号を同期させる必要性を示すために、それらのSYNビットをそれらのヘッダー中に設定させる。そのタイプのパケットは、NICにより識別され、表1に示されるようにフィルターを形成するために使用される。フィルターのビットレイアウトは、このフィルターが、ゼロフィールド配置の故に、同じホスト:ポートペアを有するUDPエンドポイントと衝突できないことを意味することは注意すべきである。そうしてCAMフィルターのレイアウトは、プロトコルデコードケースを示すために使用される。2接続が確立されるとすぐに、有効な着信パケットが、それらのSYNビットをゼロに設定し、表1に示された論理により正しくフィルターに掛けることができる。ライブラリは、通常の受信過程で通常パケット検証手順の部分としてこのフィールドをチェックするけれども、この場合、訂正宛先転送ライブラリを識別するために、DEST宛先ホストの識別はもはや要求されないことは注意すべきである。この手順は、図7で説明されるように、サーバー受動接続、サーバー転送ライブラリによりプログラムされるCAMのコンテンツ、および各パケットでNICによりCAMに与えられるフィルターに関して説明される。これは以下のステップを含む:a転送ライブラリは、ドライバを介してCAMエントリーを割り当てる。b転送ライブラリの仮想インターフェースに割り振られるアドレススペースに、割り振られるCAMをマップするために、ドライバは、その保護制御インターフェースを通じてハードウェアをプログラムする。c転送ライブラリは、仮想インターフェースを介してCAMエントリーをプログラムする。アプリケーションが、プログラム可能CAMエントリーを受信するために不充分なアクセス権限しか有さないと考えられる場合、それは、代わりにOSコールを介してそれを行うことが許可され得る。iiTCP/IPコンテンツパケットが到着する。パケットヘッダー中のSYNビットは1に設定され、パケットヘッダー中のACKビットはゼロに設定されるので、ネットワークインターフェースデバイスは、フィルター:desthost0destportをビットからパケットヘッダー中に構成でき、それをCAMに与えることができる。これは、一致をCAMインデックスXで生じさせる。次いで仮想インターフェース:βの基底アドレスを検出するために、ネットワークインターフェースデバイスは、SRAM中を検索できる。次いでNICは、仮想インターフェースβにパケットを配信できる。接続パケットの結果としてサーバーアプリケーションは、ネットワーク接続を操作するために、別のネットワークエンドポイントを作成できる。このエンドポイントは、それ自身または別のアプリケーションコンテキスト内にあることができ、そうして別の転送ライブラリにより管理され得る。いずれかの場合、desthostportをsourcehostportに結合するネットワーク接続を作成することができ、サーバーは、sourcehostsourceportdestportで新しいCAMエントリーをプログラムする。iiiパケットが新しいネットワーク接続に到着するとき、それは、そのSYNビットをゼロに設定する。これは、NICにフィルター:sourcehostsourceportdestportを構成させ、これは、CAMに与えられるときに、SRAM中で仮想インターフェースσと一致する一致インデックスθを生じさせる。ネットワーク接続がサーバーエンドポイントと同じ転送ライブラリにより管理される場合、σはβと同じであり得ることは注意すべきである。このエンコードは、ホストにより開始されるアクティブクライアント接続のため、並びにTCPおよびUDPプロトコル指定で指定される通信の全てのモデルのために、同様に用いることができる。スキームをエンコードすることの注目に値する利益の1つは、それによりハードウェアが、1つだけのCAM検索を使用して仮想インターフェースのアドレスを決定できることである。ネットワークインターフェースデバイスは、好ましくは操作モードもサポートし、その中でそれが、ネットワークエンドポイント上よりはむしろ、転送ライブラリ上でパケットを単純に逆多重化する。デバイスが、ネットワークと、同時に多数例えば何百万のネットワーク接続を保守するために要求されるサーバーとの間の通信を操作する場合、これは有益であろう。この例は、大容量ウェブサーバーノードであり得る。2つのオプションが利用できる。1つのオプションは、フォーム:desthostdestportのフィルターだけをCAMに保管することである。別のオプションは、ドントケアビットを使用してマスクできる3進法CAMを用いることである。両方の操作モードが同時に可能である場合、SYNビットが受信パケット中でゼロに設定されるときに、異なるフィルターを構成する必要があるために、2つのCAM検索が要求され得るので、効率が低下し得ることは注意すべきである。一度に1つだけのモードが可能であれば、この要件は回避し得る。ネットワークインターフェースカードを、物理カードとして埋め込むことができ、またはそれを、別の方式で、例えばデータ処理デバイスのマザーボードに組み込まれる統合回路としてインプリメントできる。このようにして、TCP/IPおよびUDP/IPパケットは、両方とも、64ビットのCAMを使用して一致させることができる。これは、ビット単位一致を全ヘッダー上で用いる標準サイズ化CAMが使用される場合に要求され得る128ビットとは、対照的である。これにより出願人は、分離してこの中で記載された個々の機能、および2つまたはそれ以上の前述の機能のあらゆる組合せを、前述の機能または機能の組合わせがこの中で開示したあらゆる問題を解決するか否かにかかわらず、および請求項の範囲を制限せずに、当業者の共通する一般的知識を考慮して、前述の機能または組合せが、本明細書全体に基いて実行できる程度に開示する。出願人は、本発明の側面が、あらゆる前述の個々の機能または機能の組合せからなることができることを示す。上述の記載を考慮すれば、当業者にとって、様々な修正が、本発明の範囲内でなし得ることは明らかであろう。