JP2011141894A - ユーザーレベルスタック - Google Patents

Abstract

【課題】データ処理システムによりデータを送信または受信するための方法およびシステムを提供すること。
【解決手段】データの送受信方法は、メモリ領域を割り当てること；アプリケーションがメモリ領域に直接アクセスすること；アプリケーションが無応答である場合に、ネットワークインターフェースデバイスがオペレーティングシステムにシグナル通知してメモリ領域にアクセスさせること；および、オペレーティングシステムがシグナルに応答してメモリ領域に直接アクセスすることを含む。データの送受信システムは、オペレーティングシステムおよびアプリケーションをサポートしてメモリ領域に直接アクセスさせるデータ処理システム；および、アプリケーションが無応答である場合に、オペレーティングシステムにシグナル通知してメモリ領域に直接アクセスさせるネットワークインターフェースデバイスを含む。
【選択図】図５

Description

発明の背景
本発明は、ネットワークインターフェース、例えばコンピューターをネットワークにリンクするためのインターフェースデバイスに関するものである。

図１は、ネットワークインターフェースカード（ＮＩＣ）のようなネットワークインターフェースデバイス、およびそれが使用され得るシステムの一般的アーキテクチャを示す概略図である。ネットワークインターフェースデバイス１０は、データリンク５を介してコンピューター１のような処理デバイスに、およびデータリンク１４を介してデータネットワーク２０に接続されている。さらに、処理デバイス３０のようなネットワークインターフェースデバイスもネットワークに接続され、ネットワークおよび処理デバイス４０のようなさらなる処理デバイス間のインターフェースを提供する。

コンピューター１は、例えばパーソナルコンピューター、サーバー、またはデータロガー若しくはコントローラのような専用処理デバイスであってもよい。この例においてそれは、プロセッサ２、プログラムストア４およびメモリ３を含む。プログラムストアは、オペレーティングシステム、およびそのオペレーティングシステム上で実行できるアプリケーションを規定する命令を保管する。オペレーティングシステムは、ドライバおよびインターフェースライブラリのような手段を提供し、それによりアプリケーションは、コンピューターと接続した周辺のハードウェアデバイスにアクセスできる。

ネットワークインターフェースデバイスは、標準的な転送プロトコル、例えばＴＣＰ、ＲＤＭＡおよびＩＳＣＳＩを、ユーザーレベルで、即ちそれらがコンピューター１上で実行するアプリケーションプログラムにアクセスできるようにサポートできることが望ましい。そのようなサポートは、標準的なプロトコルの使用を要求し、データにカーネルスタックの全探索を要求しないデータ転送を可能にする。この例のネットワークインターフェースデバイスでは、標準的な転送プロトコルは、コンピューター１のオペレーティングシステムにアクセス可能な転送ライブラリ内でインプリメントされる。

典型的なコンピューターシステム１は、プロセッササブシステム（１つまたはそれ以上のプロセッサを含む）、メモリサブシステム（メインメモリ、キャッシュメモリ等を含む）、および周辺バスを介してプロセッササブシステムに接続された様々な「周辺デバイス」を含む。周辺デバイスは、例えばキーボード、マウスおよびディスプレイアダプタ、ディスクドライブおよびＣＤ−ＲＯＭドライブ、ネットワークインターフェースデバイスなどを含み得る。プロセッササブシステムは、デバイスに予め割り当てられた特定アドレスへのコマンドおよび情報を読み書きすることにより、周辺デバイスと通信する。アドレスは、メインメモリ・アドレススペース、Ｉ／Ｏアドレススペース、または別のタイプの構成スペースの領域に予め割り当てられ得る。周辺デバイスとの通信は、ダイレクトメモリアクセス（ＤＭＡ）を介して行うこともでき、その中で周辺デバイス（または周辺バスでの別のエージェント）は、メモリサブシステムと、周辺デバイスに割り当てられたアドレススペースの予め割り当てられた領域の１つとの間で直接データを送信する。

最新のコンピューターシステムはマルチタスクを行う。マルチタスクとは、コンピューターシステムが、複数の異なるアプリケーションプログラムを同じプロセッササブシステム上で同時に実行させることを意味する。最新のコンピューターシステムは、オペレーティングシステムも実行し、それは、他の事項の中で、それぞれの異なるアプリケーションプログラムのコードを実行するために、プロセッササブシステム上で時間を割り当てる。マルチタスクシステムで生じ得る１つの問題は、異なるアプリケーションプログラムが同じ周辺デバイスを同時に制御しようとすることである。そのような競合を防止するために、オペレーティングシステムの別のジョブは、周辺デバイス制御を調和させることである。特にオペレーティングシステムだけが、周辺デバイスに直接アクセスでき、周辺デバイスにアクセスしようとするアプリケーションプログラムは、オペレーティングシステム中のルーチンを呼び出すことによって、それをしなければならない。オペレーティングシステムにおける周辺デバイスの排他的制御の配置は、ハードウェアを制御するために、それぞれの分離アプリケーションプログラムがそれ自身のソフトウェアコードをインプリメントする必要性を無くすことで、システムのモジュール化も助ける。

ハードウェアを制御するオペレーティングシステムの部分は、通常カーネルである。典型的に、それは、ハードウェアの初期化、プロセッサ状態の設定および再設定、プロセッサ内部クロックの調節、ネットワークインターフェースデバイスの初期化、およびハードウェアの他の直接アクセスを行うカーネルである。カーネルは、カーネルモード（時おりトラステッドモードまたは特権モードとも呼ばれる）で実行し、一方、アプリケーションレベルプロセス（ユーザーレベルプロセスとも呼ばれる）は、ユーザーモードで実行する。典型的にそれは、カーネルコードのようなトラステッドモードのみがハードウェアに直接アクセスできることを確保するプロセッササブシステムハードウェア自体である。プロセッサは、これを少なくとも２つの方式で強化する：或る重要命令は、現行の特権レベルが充分に高まるまでプロセッサで実行されず、プロセッサは、プロセスに既に割り振られたユーザーレベルの物理または仮想アドレススペースの外側にあるメモリ位置（特定のハードウェアリソースに関係するアドレスにマップされたメモリを含む）に、ユーザーレベルプロセスがアクセスすることを許可しない。この中で使用されるように、用語「カーネルスペース」または「カーネルアドレススペース」は、カーネルを実行するアドレスおよびコードスペースを指す。これは、カーネルに対して、カーネルデータ構造および機能内部を含む。カーネルも同様にユーザープロセスのメモリにアクセスできるが、「カーネルスペース」は、一般に、カーネル専用であり、あらゆるユーザープロセスがアクセスできないメモリ（コードおよびデータを含む）を意味する。用語「ユーザースペース」または「ユーザーアドレススペース」は、実行可能ファイルからロードされ、ユーザープロセスにとって利用可能であり、コードにより割り振られたアドレスおよびコードスペースを指し、これは、カーネル専用コードデータ構造を排除する。この中で使用されるように、全ての４つの用語は、それ自身のアドレススペースのソフトウェアプログラムのビューと、それに対応する物理メモリ位置との間の介入マッピングの可能性を引き受けることが意図されている。典型的に、そのアドレススペースのソフトウェアプログラムのビューは隣接するのに対して、対応する物理アドレススペースは、ハードディスクドライブのような交換デバイス上で、非隣接で、オーダー外であり、場合により部分的に一様であり得る。

カーネルの部分は、分離した前進カーネルプロセスとして実行し得るが、実際上カーネルのほとんどは、システム上において、分離処理実行ではない。その代わりにそれは、ルーチン設定と考えることができ、ユーザープロセスはそのいくつかにアクセスできる。ユーザープロセスは、プロセスに代わってカーネルにいくつかのコードを実行させる機能であるシステムコールを実行することにより、カーネルルーチンを呼び出すことができる。「現行プロセス」はまだユーザープロセスであるが、システムコール中にそれは、「カーネル内部」を実行し、それによりカーネルアドレススペースにアクセスでき、特権モードで実行できる。割り込みハンドラーがカーネル内で見出されるので、カーネルコードも、ハードウェアデバイスにより出される割り込みに応答して、実行される。カーネルも、プロセススケジューラーとしての役割で、クロック割り込み（および他の手段）を使用して急速にプロセス間で制御をスイッチし、１つのプロセスからもう１つへのスイッチを起動する。カーネルルーチンが呼び出されるたびに、現行の特権レベルは、ルーチンがハードウェアに直接アクセスすることを許可するために、カーネルモードに対して増加する。カーネルが、ユーザープロセスのもとへ制御を解放するときは、現行の特権レベルは、ユーザープロセスのものに戻る。

ユーザーレベルプロセスがＮＩＣと通信することを望むときは、従来それは、オペレーティングシステムに対するコールを通じてのみ、それを行うことができる。オペレーティングシステムは、アプリケーションの代わりにプロトコル処理を行うシステムレベルプロトコル処理スタックをインプリメントする。特にＴＣＰ／ＩＰコールを使用してデータパケットを送信しようとするアプリケーションは、（例えば送信（）コールを使用して）オペレーティングシステムＡＰＩを呼び出し、データが転送される。このコールは、コンテキストスイッチにカーネルルーチンを呼び出させ、データをカーネルデータバッファにコピーし、ＴＣＰ送信処理を実行する。ここでプロトコルが適用され、充分に形成されたＴＣＰ／ＩＰパケットは、インターフェースドライバで送信のために待ち行列に入れられる。別のコンテキストスイッチは、制御がアプリケーションプログラムに戻るときに行われる。ネットワークプロトコル処理のためのカーネルルーチンは、時間経過に起因しても呼び出され得ることは注意すべきである。一例は、再送信アルゴリズムの起動である。一般にオペレーティングシステムは、全てのＯＳモジュールに、（ハードウェアクロック割り込みにより駆動される）時間およびスケジューリングサービスを提供し、これは、接続ごとに基づきＴＣＰスタックにタイマーをインプリメントさせることを可能にする。オペレーティングシステムは、そのようなタイマー起動機能を操作するために、次いで再びアプリケーションに戻るために、コンテキストスイッチを行う。

ネットワーク送信および受信操作は、過度なコンテキストスイッチングを含むことがあり、これはかなりのオーバーヘッドを引き起こし得ることが考えられる。その問題は、特にネットワーキング環境で深刻であり、その中でデータパケットはしばしばショートし、要求される制御作業の量を、全ネットワーク処理作業の割合として増大させる。

過去に試みられた１つの解決策は、オペレーティングシステムのものと並行に作動するユーザーレベルプロトコル処理スタックを作成することであった。そのようなスタックは、カーネルスタックを全探索することをデータに要求せずに、標準的なプロトコルを使用するデータ送信をなし得る。

図２は、この１つのインプリメンテーションを示す。このアーキテクチャでは、ＴＣＰ（および他の）プロトコルは、図２でＴＣＰ１およびＴＣＰ２を表示するように、２回インプリメントされる。典型的なオペレーティングシステムにおいて、ＴＣＰ２は、コンピューターのオペレーティングシステムに構築されているＴＣＰプロトコルの標準インプリメンテーションであろう。ネットワークインターフェースデバイスを制御するおよび／またはそれと通信するために、コンピューター上でのアプリケーション実行は、ＡＰＩ（アプリケーションプログラミングインターフェース）コールを出すことができる。いくつかのＡＰＩコールは、ネットワークインターフェースデバイスをサポートするために供給された転送ライブラリで操作され得る。アプリケーションに対して直接利用できる転送ライブラリにより保守することができないＡＰＩコールは、典型的に、アプリケーションおよびオペレーティングシステムの間のインターフェースを通じて受け渡すことができ、オペレーティングシステムに対して利用できるライブラリにより操作される。多くのオペレーティングシステムでのインプリメンテーションのために、転送ライブラリは、制御プレーン構造に基づく既存のイーサネット（登録商標）／ＩＰ：例えばＳＮＭＰおよびＡＲＰプロトコルを、ＯＳインターフェースを介して使用することが便利である。

ユーザーレベルで転送プロトコルをインプリメントすることには多くの難しさがある。ほとんどのインプリメンテーションは、今日、事前カーネルコードベースをユーザーレベルに移植することに基づいている。これらの例は、アーセニック（Arsenic）およびジェットストリーム（Jet-stream）である。これらは、ユーザーレベル転送の可能性を示すが、完全で、強く、高性能で、商業的に実行できるインプリメンテーションを達成するために要求される、多くの問題を扱っていない。

図３は、標準カーネルＴＣＰ転送（ＴＣＰｋ）を用いるアーキテクチャを示す。

このアーキテクチャの操作は、以下のようなものである。

ネットワークインターフェースハードウェア（例えばネットワークインターフェースカード（ＮＩＣ））からのパケット受信で、ＮＩＣは事前に割り振られたデータバッファ（ａ）にデータを転送し、割り込みラインによりＯＳ割り込みハンドラーを呼び出す（ステップｉ）。割り込みハンドラーは、ハードウェアインターフェースを管理する、例えば新しい受信バッファを通知し、プロトコル情報を探す受信（この場合イーサネット（登録商標））パケットを受け渡す。パケットが、有効なプロトコル、例えばＴＣＰ／ＩＰに向かうように識別されていない場合、それは、（コピーされずに）適切な受信プロトコル処理ブロックに受け渡される（ステップｉｉ）。

ＴＣＰ受信側処理が行われ、宛先部分がパケットから識別される。パケットがポートに対して有効なデータを含有している場合、パケットは、ポートのデータキュー（ステップｉｉｉ）およびマークをつけられたポート（これは、スケジューラーおよびブロックされたプロセスの覚醒を含み得る）上で、有効データが保持されるようにはめ込まれる。

ＴＣＰ受信処理は、例えば先に送信されたデータを再送信すべき場合、または先に待ち行列に入れられたデータが（おそらくＴＣＰウィンドウがオープンであったため）現在送信できる場合に、他のパケットを送信することを要求し得る（ステップｉｖ）。この場合、パケットは、送信のためにＯＳ「ＮＤＩＳ」ドライバで待ち行列に入れられる。

アプリケーションがデータバッファを取り出すために、それは、例えばｒｅｃｖ（）、選択（）またはポーリング（）のようなコールにより、ＯＳ ＡＰＩを呼び出さなければならない（ステップｖ）。これは、アプリケーションにデータが受信されたことを通知し、（ｒｅｃｖ（）コールの場合に）データをカーネルバッファからアプリケーションのバッファにコピーするという効果を有する。そのコピーは、ＤＭＡアクセス可能のような特別な属性を有するそのネットワークバッファを、カーネル（ＯＳ）が再使用できるようにし、およびそのコピーは、アプリケーションがネットワークにより供給される単位内でデータを操作する必要が無いこと、またはアプリケーションが演繹的にデータの最終宛先を知る必要があること、またはアプリケーションが後でデータ受信のために使用できるバッファを事前に割り振らなければならないことを意味する。

受信側では、非同期的に相互作用する少なくとも２つの制御特殊スレッド：割り込みからのアップコールおよびアプリケーションからのシステムコールがあることは注意すべきである。多くのオペレーティングシステムは、多すぎるコードを割り込み優先度で実行することを回避するために、例えば「ソフト割り込み」または「据え置き手順コール」技術でアップコールを分割することもある。

送信プロセスは、実行の１つのパスが通常存在する場合を除いては、同様に挙動する。アプリケーションは、（例えば送信（）コールを使用して）オペレーティングシステムＡＰＩを呼び出し、データが送信される（ステップｖｉ）。このコールは、データをカーネルデータバッファにコピーし、ＴＣＰ送信処理を呼び出す。ここでプロトコルが適用され、充分に形成されたＴＣＰ／ＩＰパケットが、送信用インターフェースドライバで待ち行列に入れられる。

正常な場合、システムコールは、送信のために（ハードウェアにより）スケジュール付けられたデータの表示を伴って戻る。しかしデータがネットワークインターフェースデバイスにより待ち行列に入れられない多くの環境がある。例えば転送プロトコルが、保留中の肯定応答またはウィンドウアップデートを待ち行列に入れることがあり、デバイスドライバが、ハードウェアに対する保留中のデータ送信要求を、ソフトウェア内で、待ち行列に入れることがある。

システムによる第３の制御フローは、時間経過で実行されなければならないアクションにより発生する。一例は、再送信アルゴリズムの起動である。一般にオペレーティングシステムは、全てのＯＳモジュールに、（ハードウェアクロック割り込みにより駆動される）時間およびスケジューリングサービスを供給し、これはＴＣＰスタックが、接続ごとに基いてタイマーをインプリメントすることを可能にする。

標準的なカーネルスタックがユーザーレベルでインプリメントされる場合、その構造は、一般に図４で示されるようなものであろう。アプリケーションは、ＯＳインターフェースと直接リンクされるよりはむしろ、転送ライブラリとリンクされる。その構造は、ユーザーレベルパッケージにより供給されるタイマーサポート、およびユーザーレベル仮想インターフェースモジュールで置き換えられるデバイスドライバインターフェースのような
サービスでのカーネルスタックインプリメンテーションと非常に似ている。しかしＴＣＰインプリメンテーションにより要求される非同期処理のモデルを供給するために、転送ライブラリ内での実行アクティブスレッドが多く存在しなければならない：
（ｉ）アプリケーションにより供給されるシステムＡＰＩコール
（ｉｉ）プロトコルコードへのタイマー発生コール
（ｉｉｉ）仮想ネットワークインターフェースおよび結果として生ずるプロトコルコードへのアップコールの管理。（ｉｉおよびｉｉｉは、いくつかのアーキテクチャのために組み合わせてもよい）

しかしこの配列は多くの問題を持ち込む：
（ａ）共有データ構造を保護するためのこれらスレッドおよびインプリメントロッキング間のコンテキストスイッチングのオーバーヘッドは重大であり得、かなりの量の処理時間を費やす。
（ｂ）ユーザーレベルタイマーコードは、一般に、オペレーティングシステムにより供給されるタイマー／時間サポートを使用することにより作動する。タイマーモジュールからのシステムコールにより引き起こされる大きなオーバーヘッドの結果、システムが、オペレーティングシステムおよびデータバス間の相互作用を防ぐという目的に応じられなくなる。
（ｃ）多くの独立アプリケーションが存在することがあり、それらは、それぞれネットワーク接続のサブセットを、いくつかはそれら自身の転送ライブラリを介して、およびいくつかは既存のカーネルスタック転送ライブラリにより管理する。ＮＩＣは、効率よくパケットを解析し、それらを、ＩＰポートおよびホストアドレスビットのようなプロトコル情報に基づく適切な仮想インターフェース（またはＯＳ）に送信できなければならない。
（ｄ）アプリケーションが、例えば、ユニックスオペレーティングシステム上でのフォーク（）システムコール中に、特定のネットワーク接続制御を別のアプリケーションに受け渡すことは可能である。これは、接続状態にアクセスするために、完全に異なる転送ライブラリインスタンスが要求されることを必要とする。より悪いことに、多くのアプリケーションは、ネットワーク接続を共有することがあり、これは、転送ライブラリが、（プロセス間通信）技術を介して所有権を共有することを意味する。ユーザーレベルでの既存の転送は、これをサポートしようと試みていない。
（ｅ）転送プロトコルが、ネットワークコネクションに、それがつながれているアプリケーションよりも長生きするよう指令することは一般的である。例えばＴＣＰプロトコルを使用して、転送は、送られるが無応答のデータを送信するよう努めなければならず、送信アプリケーションが存在するか、または破損しているときには正常に接続を閉じるよう努めなければならない。これは、アプリケーションの状態（または存在）を問わずに、「タイマー」入力をプロトコルスタックに供給できるカーネルスタックインプリメンテーションでの問題ではなく、アプリケーションが存在する、破損する、またはデバッガー内で停止される場合に、（場合により非正常に）消失することがある転送ライブラリの課題である。

少なくとも部分的に、これら問題ａ〜ｅの１つまたはそれ以上に取り組むシステムを提供することは望まれているであろう。

発明の概要
本発明の一側面によれば、概略的に記載されるように、データ処理システムによるデータ送信方法が提供され、該システムは、オペレーティングシステムおよび少なくとも１つのアプリケーションをサポートでき、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースデバイスにアクセスでき、該方法は：送信されるデータをアプリケーションにより形成するステップ；アプリケーションにより、データ処理システムの非オペレーティングシステム機能に、送信されるデータを送ることを要求するステップ；その要求に応答する：送信されるデータをメモリ領域に書き込むステップ；および非オペレーティングシステム機能およびネットワークインターフェースデバイス間の直接通信により、ネットワーク上に、データの少なくともいくつかの送信操作を開始するステップ；および続いて、オペレーティングシステムによりメモリにアクセスするステップ、およびネットワークインターフェースデバイスによりネットワーク上にデータの少なくともいくつかの送信操作の少なくとも一部を行うステップを含む。

好ましくは、オペレーティングシステムはネットワークインターフェースデバイスと直接通信できる。

非オペレーティングシステム機能間の前記直接通信は、好ましくはオペレーティングシステムを迂回する。

非オペレーティングシステム機能は、好ましくはソフトウェアにより、最も好ましくはデータ処理システム上で実行するソフトウェアによりインプリメントされる。それは、都合の良いことには、転送ライブラリであってもよい。非オペレーティングシステム機能は、最も好ましくは、それが行うステップを達成するために、特権レベルで増加を要求しない。

前記メモリ領域は、メモリの第２領域にマップされていてもよい。メモリの第２領域は、オペレーティングシステムとアクセス可能、最も好ましくは直接アクセス可能であってもよいが、非オペレーティングシステム機能とは直接アクセスできない。

該方法は、ネットワーク上にデータの送信操作を開始するときに、タイマーをスタートすること；および肯定応答がそのデータに対して受信される前にタイマーが予定値に達した場合に、ネットワークインターフェースデバイスからデータ処理システムに失敗メッセージを送信することを含み得る。

該方法は、ネットワーク上にデータの送信操作を開始するときに、その操作の記録およびデータソースであったアプリケーションの表示を保管すること；およびそのアプリケーションのためのデータを受信したときに、そのアプリケーションと関連する各記録に対してタイマーをスタートすること；および肯定応答がそのデータに対して受信される前に前述のタイマーが予定値に達した場合に、ネットワークインターフェースデバイスからデータ処理システムに失敗メッセージを送信することを含み得る。

好ましくは、タイマーまたは各タイマーはネットワークインターフェースデバイス上で実行される。

該方法は、データに対して肯定応答を受信したときにタイマーを取り消すことを含んでもよく、その中で失敗メッセージまたは各失敗メッセージは、オペレーティングシステムに向けて発せられる。

タイマーを取り消すステップは、エンティティをシグナル通知するアプリケーションを含んでもよく、そこでタイマーは、オペレーティングシステムを迂回する方式で実行される。

失敗メッセージまたは各失敗メッセージは、好ましくはデータソースであったアプリケーションに向けて発せられる。

オペレーティングシステムは、好ましくは、失敗メッセージに対応するデータに関して、前記送信操作の少なくとも一部を行うためのネットワークデバイスともはや通信していないアプリケーションに向けて発せられる失敗メッセージに応答する。

本発明の第２側面によれば、概略的に記載されるように、データ処理システムによりデータを受信するための方法が提供され、該システムは、少なくとも１つのアプリケーションをサポートでき、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースデバイスにアクセスでき、該方法は：データ処理システムの非オペレーティングシステム機能により、アプリケーションでデータを受信するためのチャネルを確立するステップ、該チャネルはメモリ領域と関連する；そのチャネルを通じて：ネットワークインターフェースデバイスがメモリ領域に受信データを書き込むこと；およびアプリケーションがその領域から受信データを読み取ること；および続いてアプリケーションがネットワークデバイスと通信できない場合、オペレーティングシステムがその領域から受信データを読み取ることによりデータを受信するステップを含む。

好ましくは、オペレーティングシステムは、アプリケーションがネットワークデバイスと通信できないという決定がなされたときに、自動的にその領域から受信データを読み取るように構成されている。

本発明の第３側面によれば、概略的に記載されるように、データ処理システムによるデータ送信方法が提供され、該システムは、少なくとも１つのアプリケーションをサポートでき、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースデバイスにアクセスでき、該方法は：送信されるデータをアプリケーションにより形成するステップ；そのデータを、送信のためにネットワークインターフェースデバイスに受け渡すステップ；ネットワークインターフェースデバイスによりデータを送信するステップ、および任意にその送信の際に、データに対応するタイマーを確立するステップ；および肯定応答がそのデータに対してネットワーク上で受信された場合に、タイマーを取り消すステップ；またはタイマーが予定値に達した場合に、ネットワークインターフェースデバイスにより、肯定応答がそのデータに対して受信されなかったことを示すために、オペレーティングシステムにシグナル通知するステップを含む。

タイマーを、そのタイマーの確立でスタートさせてもよい。

タイマーが確立されたときそれを、その送信でタイマーが確立されたデータのソースであったアプリケーションに向けて発せられるデータを受信することで、スタートさせてもよい。

前記データ受け渡しは、データ処理システムの非オペレーティングシステム機能により行い得る。

非オペレーティングシステム機能は、転送ライブラリであってもよい。

前記データ受け渡しは、オペレーティングシステムを迂回することで行い得る。

前記シグナル通知は、失敗イベントをオペレーティングシステムのイベントキューに適用することを含み得る。

本発明の第４側面によれば、概略的に記載されるように、データ処理システムによりデータを送信または受信するための方法が提供され、該システムは、オペレーティングシステムおよびアプリケーションをサポートし、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースにアクセスでき、該方法は：データ処理システムおよびネットワークインターフェースデバイス間のデータ転送におけるデータバッファおよび接続状態バッファとして使用するために、１つまたはそれ以上のメモリ領域を割り当てること；ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、アプリケーションによりメモリ領域の少なくとも１つに直接アクセスすること；アプリケーションが無応答であると決定された場合に、ネットワークインターフェースデバイスが、オペレーティングシステムにシグナル通知して、前記メモリ領域の少なくとも１つにアクセスさせること；およびネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、オペレーティングシステムが、シグナルに応答して、データバッファおよび接続状態バッファの少なくとも１つに直接アクセスすることを含む。

好ましくは、該方法は：ネットワークデバイスによりネットワークからデータを受信すること；およびネットワークデバイスにより前記領域の少なくとも１つにデータを書き込むことを含む。

好ましくは、ネットワークデバイスは、アプリケーションが無応答であると決定された場合にオペレーティングシステムにシグナル通知して、前記領域の少なくとも１つにアクセスするように構成されており、方法は、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも１つに直接アクセスする前記ステップを行うことを含む。前記シグナルは、割り込みであってもよい。

好ましくは、ネットワークデバイスはタイマーをサポートし、方法は、受信データが前記領域の少なくとも１つに書き込まれたときに、タイマーをスタートし、事前設定の初期値からカウントすることを含み、アプリケーションは、タイマーが事前設定の最終値に達した場合に、無応答であると決定される。好ましくは、最終値はゼロである。

好ましくは、該方法は、アプリケーションにより初期値および／または最終値を設定するステップを含む。最も好ましくは、最終値はゼロであり、初期値だけがアプリケーションにより設定される。

該方法は、好ましくはアプリケーションにより前記領域の少なくとも１つから受信データを読み取ったときに、アプリケーションによりタイマーを停止することを含む。

好ましくは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスする前記ステップのそれぞれは、ネットワークインターフェースデバイスによりネットワークから受信され、前記領域の少なくとも１つに保管されたデータのプロトコル処理を含む。プロトコル処理は：受信データからトラフィックデータを抽出すること、受信データの少なくともいくつかに関して、肯定応答および／または再送信メッセージをネットワーク上に送信すること、受信データ中の受信データ単位のシーケンス値をチェックすること、および受信データに関してチェックサムを計算することの１つまたはそれ以上を含み得る。プロトコルはＴＣＰであってもよい。

好ましくは、該方法は：ネットワークデバイスにより、前記領域の少なくとも１つからデータを読み取ること；およびネットワークデバイスにより、そのデータをネットワーク上に送信することを含む。

好ましくは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスする前記ステップのそれぞれは、送信用のデータを前記領域の少なくとも１つに保管することを含む。

好ましくは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスする前記ステップのそれぞれは、ネットワークデバイスを起動して、前記領域の少なくとも１つからデータを読み取る前記ステップを行うことを含む。

好ましくは、ネットワークデバイスは、アプリケーションが無応答であると決定された場合に、オペレーティングシステムにシグナル通知して、前記領域の少なくとも１つにアクセスするように構成されており、方法は、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも１つに直接アクセスする前記ステップを行うことを含む。

本発明のさらなる側面によれば、上記のあらゆる方法を行うためのシステムが提供される。

図１は、使用時のネットワークインターフェースデバイスの概略図である。 図２は、転送ライブラリアーキテクチャのインプリメンテーションを示す。 図３は、ユーザーレベルＴＣＰ転送と共に標準的なカーネルＴＣＰ転送を用いるアーキテクチャを示す。 図４は、標準的なカーネルスタックがユーザーレベルでインプリメントされているアーキテクチャを示す。 図５は、ＴＣＰ転送アーキテクチャの例を示す。 図６は、着信ＴＣＰ／パケットをフィルターに掛けるために、ネットワークインターフェースデバイスにより行うことができるステップを示す。 図７は、コンテンツアドレス可能メモリによりサーバー（受動）接続の操作を示す。

図面の説明
本発明を、これから添付図面を参照しながら、例として説明していく：
図１は、使用時のネットワークインターフェースデバイスの概略図である；
図２は、転送ライブラリアーキテクチャのインプリメンテーションを示す；
図３は、ユーザーレベルＴＣＰ転送と共に標準的なカーネルＴＣＰ転送を用いるアーキテクチャを示す；
図４は、標準的なカーネルスタックがユーザーレベルでインプリメントされているアーキテクチャを示す；
図５は、ＴＣＰ転送アーキテクチャの例を示す；
図６は、着信ＴＣＰ／パケットをフィルターに掛けるために、ネットワークインターフェースデバイスにより行うことができるステップを示す；
図７は、コンテンツアドレス可能メモリによりサーバー（受動）接続の操作を示す。

図面の詳細な説明
以下の記載は、あらゆる当業者が本発明を作り、使用できるようにするために示され、特定の適用およびその要件との関連で提供される。開示された実施態様の様々な修正は、当業者にとって容易に理解できるであろう、そしてこの中で明確にされた一般原理は、本発明の意図および範囲から外れることなく、他の実施態様および適用に応用することができる。従って本発明は、示した実施態様に限定されることは意図されておらず、この中で開示された原理および機能と矛盾しない最も広い範囲と一致させられることが意図されている。

図５は、ネットワークインターフェースデバイス、例えば図１のデバイス１０と、コンピューター、例えば図１のコンピューター１との間のインターフェースを提供するために適したＴＣＰ転送アーキテクチャの一例を示す。アーキテクチャは、このインプリメンテーションに限定されない。

図５の例のアーキテクチャと従来のアーキテクチャとの間の主な違いは、以下のようなものである。

（ｉ）ネットワーク接続の代わりにプロトコル処理を行うＴＣＰコードは、転送ライブラリおよびＯＳカーネルの両方に位置指定される。このコードがプロトコル処理を行うということが、特に重要である。
（ｉｉ）接続状態およびデータバッファは、カーネルメモリおよび転送ライブラリのアドレススペースにマップされたメモリに保持される。オペレーティングシステムは、それらバッファの所有者であり、そうしてそれらを完全に制御するが、それらは、その通信のためにそれらが使用されるアプリケーションにより直接アクセスすることができる。これは、アプリケーションが、それらバッファを通じてデータを直接送受信すること、および状態データを対応する状態バッファから読み取ることを可能にする。
（ｉｉｉ）カーネルおよび転送ライブラリコードの両方が、特定のネットワーク接続のために、およびこれに代わって、仮想ハードウェアインターフェースにアクセスできる。
（ｉｖ）タイマーは、仮想ハードウェアインターフェースを通じて管理することができ、（これらはネットワークインターフェースデバイス上の実タイマーに対応する）、システムコールにそれらを設定およびクリアすることを要求しなくてもよい。ＮＩＣは、タイマーイベントを発生させ、それは、ネットワークインターフェースデバイスドライバにより受信され、デバイスのためにＴＣＰサポートコードに受け渡される。

ネットワークインターフェースデバイスのためのＴＣＰサポートコードは、汎用ＯＳに加えて、ＴＣＰインプリメンテーションであることは注目すべきである。これは、適切には、ネットワークインターフェースデバイスのスタックと共存できる。

図５のアーキテクチャにおいてバッファは、ネットワーク上でデータを送信および／または受信するためにＮＩＣと共同して使用されるため、データプロセッサ上のメモリに割り振られる。データ送信に使用するための送信バッファの場合、ＮＩＣは、そのバッファからデータを読み取り、それをネットワーク上に送信するために構成される。ＮＩＣは、自動的にそのデータを読み取り、それを送信することができるか、またはそれは、アプリケーション、もしくはデータプロセッサ上で実行するオペレーティングシステムによりデータを読み取るために起動され得る。トリガーは、好都合には割り込みであり得る。データ受信に使用するための受信バッファの場合、ＮＩＣは、そのバッファに、ネットワーク上で受信されたデータを書き込むために構成される。受信バッファ中のデータは、次いでアプリケーションまたはオペレーティングシステムにより読み取られ、さらにそれにより処理され得る。

バッファは、最も好都合にはオペレーティングシステムに所有される。これは、それが、制御を有し、その制御でエンティティがバッファにアクセスでき、それがバッファを割り当てるおよび／または作成し、そしてそれが、それらを削除する責任があるという意味である。しかしアプリケーションおよびオペレーティングシステムの両方は、バッファに、それらからデータを読み取り、それらにデータを書き込むために直接アクセスできる。これらステップが起こる環境は、以下で記載される。

データ送信の場合、アプリケーションは、送信のためにデータをバッファに書き込み、次いでＮＩＣを起動してバッファから読み取り、そのデータを送信することが期待される。いくつかの状態において、これ単独で、データをネットワーク上に首尾よく送信させるために充分であり得る。しかしＮＩＣは、送信または受信データのプロトコル処理を行わない。代わりにそれは、アプリケーションまたはオペレーティングシステムにより行われる。それゆえ、例えばデータが目的の受信側で首尾よく受信されない場合、アプリケーションまたはオペレーティングシステムは、肯定応答、再送信要求などを（使用時のプロトコルにより）処理し、ＮＩＣに再送信させなければならない。普通これは、アプリケーションによりなされると考えることができる。ＮＩＣが、肯定応答メッセージまたはアプリケーションに対するタイムアウトのようなデータを有するときは、ＮＩＣは、それを受信バッファおよび／またはイベントキューのいずれかに書き込む。同時にそれは、タイマー実行をスタートする。アプリケーションがデータにアクセスするとき、それは、タイマーを停止およびリセットする。そのようにして、ＮＩＣは、アプリケーションが応答であることを知る。しかし、タイマーが予定値に達した場合、ＮＩＣは、アプリケーションが無応答であると決定し、アプリケーションのためにデータを操作するために、オペレーティングシステムに、例えば割り込みによりシグナル通知する。これは、多くの利点を有する。第１に、アプリケーションがビジーである、またはスケジュール解除（descheduled）された場合でさえ、データ送信をオペレーティングシステムにより進めることができる。第２にそれは、オペレーティングシステムが必要ならば引き継ぐので、アプリケーションがデータを送信キューに配置するとすぐに、アプリケーションに、例えばそれ自身スケジュール解除（descheduled）することにより、意図的にデータを無視する機会を与える。好ましくは、アプリケーションは、例えばその初期値を設定することにより、タイマーの長さを制御する。これにより、アプリケーションが、タイマーを設定して、その優先度に適合させることができる。タイマーは、好ましくはアプリケーションが直接アクセスできるＮＩＣ上のハードウェアリソースである。

データ受信の場合にＮＩＣは、データを受信し、それを受信バッファに書き込む。そうするときにそれは、上記のようにタイマーを設定し、好ましくはイベントキューを介してアプリケーションに通知する。アプリケーションがデータにアクセスするとき、それは上記のようにタイマーをリセットする。これは、アプリケーションが無応答であるときに、再びＮＩＣに決定の可能性を与える。他の手段、例えばバッファ中でのＮＩＣによるデータの定期的スキャンを、同じ目的のために使用してもよい。アプリケーションが無応答であると決定されると、再びＮＩＣは、受信データを処理するためにオペレーティングシステムにシグナル通知する。受信データの場合、アプリケーションまたはオペレーティングシステムのいずれかによる処理は、典型的に、プロトコル処理（例えばパケットシーケンス番号のチェック、チェックサムの処理、トラフィックデータの抽出および／または肯定応答若しくは再送信要求を送信するためのＮＩＣへのシグナル通知）および／または使用のための、典型的にユーザーレベルでのバッファからのデータ除去を含む。

バッファは、好ましくはオペレーティングシステムにより割り振られるが、それが、アプリケーションからの要求に応答して行われることは便利である。従って受信データが、アプリケーションのために利用できる受信バッファをオーバーフローさせる場合、アプリケーションは、オペレーティングシステムによりさらなるバッファの割り振りを要求できる。

ＮＩＣは、フリーで残っている受信バッファの量のような要因を考慮する事前保管ルールに基づいてこの状態が生ずる場合に、イベントによりアプリケーションにシグナル通知することができる。再びそれは、このシグナル通知が行われたときにタイマーを設定することができ、そしてアプリケーションが応答しない場合にＮＩＣは、さらなる受信バッファのために、要求をオペレーティングシステムに送信できる。オペレーティングシステムは、次いでそのバッファを割り当てることができ、アプリケーションが無応答である場合でさえ、データがアプリケーションに受信され続けられるように、ＮＩＣにそれを通知する。このアーキテクチャの効果は以下のようなものである。

（ａ）転送ライブラリでアクティブな複数スレッドのための要件
ＴＣＰコードは、転送ライブラリ中でシステムＡＰＩコール（例えばｒｅｃｖ（））（図５のステップｉ参照）の結果として、またはタイマーイベント（図５のステップｉｉ参照）の結果としてカーネルによるいずれかで実行することができるので、この要件は、図５のアーキテクチャのために存在しない。いずれかの場合、ＶＩ（仮想インターフェース）を管理でき、両方のコードパスは、接続状態またはデータバッファにアクセスでき、その保護および相互排他は、共有メモリロックにより管理できる。転送ライブラリレベルでスイッチするスレッドのオーバーヘッドが除去されるのと同様に、この機能は、アプリケーションがそれらスレッドおよび単一操作想定を変更する要件を妨げることができる：例えばいくつかの状態で、単一スレデッドアプリケーションに複数スレデッドライブラリとリンクするよう要求することは、非許容であり得る。

（ｂ）タイマー管理のためにシステムコールを出す要件
ネットワークインターフェースデバイスは多くのタイマーをインプリメントすることができ、これらを、特定の仮想インターフェースインスタンスに割り当てることができる：例えばアクティブＴＣＰ転送ライブラリごとに１つのタイマーが存在し得るので、この要件は、図５のアーキテクチャのために存在しない。これらタイマーは、メモリマップＶＩを通じてプログラム可能にすることができ（図５のステップｉｉｉ参照）、その結果、イベント（図５のステップｉｖ参照）を出すことができる。タイマーは、システムコール無しで、−オペレーティングシステムを直接含まずに−、設定およびクリアできるので、タイマー管理のためのオーバーヘッドは大幅に削減される。

（ｃ）複数転送ライブラリへのパケットの訂正配信
ネットワークインターフェースデバイスは、コンテンツアドレス可能メモリを含有するか、またはそれにアクセスでき、これは、着信パケットのヘッダーから得られるビットを並列ハードウェア一致操作として一致させることができる。一致の結果を、配信のために使用されなければならない宛先仮想インターフェースを示すために得ることができ、ハードウェアは、ＶＩに押し付けられたバッファに、パケットを配信し続けることができる。一致処理のために１つの可能な配列は、以下で記載される。下記配列は、ＩＰｖ６と関連したより大きなホストアドレスを逆多重化するために拡張してもよいが、これは、記載されるような配列よりも広いＣＡＭまたはパケットごとに複数のＣＡＭ検索を要求するであろう。

この目的のためにＣＡＭ使用の１つの代替は、使用される仮想インターフェースを決定するためにパケットのヘッダーからのデータを処理させるハッシュアルゴリズムを使用することである。

（ｄ）処理／アプリケーション／スレッド間の接続引渡し
ネットワーク接続が引き渡されるとき、同じシステム共通リソースハンドルを、アプリケーション間で受け渡すことができる。これは、例えばファイル記述子であってもよい。ネットワークインターフェースデバイスのアーキテクチャは、ネットワーク接続と関連した全ての状態を、その（例えば）ファイル記述子で接続でき、この状態で転送ライブラリにメモリマップすることを要求できる。ネットワーク接続の引渡し後に、新しいアプリケーションは（アプリケーション、スレッドまたは処理のいずれかとして）、−それが異なるアドレススペース内で実行する場合でさえ−、メモリマップし、状態を使用し続けることができる。さらに、カーネルおよび転送ライブラリ間で使用されるのと同じバッキングプリミティブにより、あらゆる数のアプリケーションは、標準的なシステムＡＰＩにより指定されるのと同じ意味で、ネットワーク接続の使用を共有できる。

（ｅ）転送ライブラリが停止または強制終了または終了されたときの転送プロトコル処理の完了
接続状態およびプロトコルコードはカーネル常駐のままでいられるので、このステップを、ネットワークインターフェースデバイスのアーキテクチャにおいて達成できる。ＯＳカーネルコードは、汎用ＴＣＰ（ＴＣＰｋ）プロトコルスタックと同じように、アプリケーション状態の変化を通知され得る。停止されたアプリケーションは、次いで先行プロトコル実行にスレッドを提供しないが、プロトコルは、例えば先行技術のカーネルスタックプロトコルのために知られているように、タイマーイベントを介して続けられるであろう。

ＩＥＴＦ ＲＤＭＡおよびｉＳＣＳＩのような多くの新生プロトコルがある。これらプロトコルの少なくともいくつかは、ＴＣＰおよび他のプロトコルコードがネットワークインターフェースデバイス上で実行する環境で、実行するように設計された。機能は今から説明され、それによって前述のプロトコルが、ホストＣＰＵ上で（即ちネットワークインターフェースデバイスが接続されているコンピューターの処理手段を使用することで）実行できる。そのようなインプリメンテーションは有利である。なぜならそれにより、ユーザーは、コプロセッサに対するメインＣＰＵテクノロジーの価格／パフォーマンスの優位を生かすことができるからである。

ＲＤＭＡのようなプロトコルは、フレーム指示情報および巡回冗長検査（ＣＲＣ）データをＴＣＰストリーム内に埋め込むことを含む。フレーム指示情報は、プロトコルライブラリ内で計算するにはつまらないので、ＣＲＣは、（チェックサムとは対称的に）計算集約型であり、ハードウェアにより最良になされる。これを適合させるために、ＴＣＰストリームが、ＲＤＭＡまたは類似のカプセル化を行うときに、仮想インターフェース中のオプションは、例えばフラグにより可能にされ得る。このオプションを検出するときに、ＮＩＣは、送信で各パケットを構造解析し、ＲＤＭＡフレームを回復し、ＲＤＭＡ ＣＲＣアルゴリズムを適用し、転送中の飛行でＣＣＲＣを挿入する。類似の手順を、有利には、エラーチェックデータの相対的に計算集約型の計算を要求するｉＳＣＳＩのような他のプロトコルに関して使用できる。

このシステムと一致して、ネットワークインターフェースデバイスも、類似の論理を使用して受信パケットでＣＲＣを検査できる。これは、例えば標準的なＴＣＰチェックサムオフロード技術に似た方法で行うことができる。

ＲＤＭＡのようなプロトコルは、従来のインプリメンテーションにおいてネットワークインターフェースデバイス上で追加知能を要求するＲＤＭＡ ＲＥＡＤのような追加操作も命令する。ＲＤＭＡ／ＴＣＰは、最良にはコプロセッサネットワークインターフェースデバイスによりインプリメントされるべきであるという一般的信念に、このタイプのインプリメンテーションはつながっている。この中で記載されるタイプのアーキテクチャでは、特定のハードウェアフィルターは、前述の上位プロトコル要求を特定のネットワーク接続のために捕捉するようエンコードすることができる。そのような環境で、ＮＩＣは、配信データメッセージと同様に、添付コンピューター上でのソフトウェア実行によりアクションを要求するために、タイマーイベントに似たイベントを生み出すことができる。そのような方式でイベントを起動することにより、ＮＩＣは、転送ライブラリまたはカーネルヘルパーのいずれかが、要求に対して直ちに作動するという結果を達成できる。これは、転送ライブラリがスケジュールに入れられるまではカーネル拡張が実行されないという潜在的問題を回避でき、必要ならば他の上位プロトコルに適用できる。

コプロセッサＴＣＰインプリメンテーションのために促進された１つの利点は、ゼロコピー操作を送受信で行う能力である。実際上、コンテキストスイッチまたは他のキャッシュまたはＴＬＢ（送信索引バッファ）フラッシュ操作が受信パス上で存在しない場合、（上記アーキテクチャのためのように）、受信で、単一コピーのためのオーバーヘッドがほとんど存在しない。これは、プロセッサに受信データをロードするという目的を果たすからである。アプリケーションは、続いてデータにアクセスするときに、それはキャッシュミスに影響されず、そうでなければこれは、ゼロコピーインターフェースのケースであろう。

しかし転送で、転送ライブラリにより作成された単一コピーは、プロセッササイクルおよびキャッシュ汚染の両方で追加オーバーヘッドを呼び出す。上記アーキテクチャは、例えば以下の機構がインプリメントされている場合、送信操作でのコピーを回避させることができる：

（ｉ）（例えば低待ち時間環境で）送信データが、早急に確認され得る；代わりに
（ｉｉ）（例えば帯域幅×遅延の積がメッセージサイズよりも小さい場合）転送における全てのデータが送られる前に、そこでデータがほぼ完全に確認される。

転送ライブラリは、送信バッファを、それからのデータが確認されるまで単純に保持することができ、データはコピーされずに送信される。これは、非同期ネットワーキングＡＰＩがアプリケーションによって使用されるときにも、行うことができる。

データコピーを回避できない場合でさえ、転送ライブラリは、非一時的ストアを実行するメモリコピールーチンを使用できる。これらは、（キャッシュよりもむしろ）メモリにコピーされたデータを残すことができ、そうしてキャッシュ汚染を回避する。送信のための次のステップは、ネットワークインターフェースデバイスによるデータのＤＭＡであると期待され、このＤＭＡ操作のパフォーマンスは、キャッシュよりもむしろメモリ中にあるデータによっては影響されそうにないので、キャッシュ中にないデータは、パフォーマンスに影響しないと期待される。

図６は、着信ＴＣＰパケットをフィルターに掛けるために、上記ネットワークインターフェースデバイスにより取り得るステップを示す。ステップＩでパケットは、ネットワークからネットワークインターフェースデバイスで受信され、受信デコードパイプラインに入る。ステップｉｉでハードウェアは、パケットから関連するビットを抽出し、ＣＡＭに与えられる（この例では３２ビット長である）フィルターを形成する。関連ビットの構成および数は、使用中であるプロトコルに依存する;この例は、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰに関する。ステップｉｉｉではＣＡＭ一致がなされたとき、それは、インデックスに帰着する：ＭＡＴＣＨ＿ＩＤＸは戻り、これは配信情報（例えばこの接続のための次の受信バッファのメモリアドレス）を検索するために使用できる。ステップｉｖで、この配信情報は、パケットデコードパイプラインにフィードバックされ、パケットが適切なメモリ位置に配信されることを可能にする。

フィルターを形成するためのビットの選択およびそれらの使用をこれから記載する。
ネットワークインターフェースデバイスは、（好ましくはハードウェア中で）、それが実質上ネットワークヘッダーを休止できるようにするため、着信パケットフローに割り込むか、またはそれをバッファに入れることができる。このことは、データフローに影響せずに、それが着信パケット中の関連ビットシーケンスを識別することを許す。ＴＣＰおよび／またはＵＤＰパケットのために、ビットシーケンスの識別を、例えば前述のパケットの単純ヘッダーレイアウトのせいで単純デコードパイプラインを使用して、インプリメントしても良い。これは、レジスターに保持された多くのフィールドに帰着する。

ゼロは、有効なポート番号または有効なＩＰアドレスのいずれでも無く、（フォーク（）コマンドまたはその等価物の後に、ソケットが共有される場合を除いて）分離処理におけるインターフェースは、ローカルＩＰアドレスおよびポートペアを共有しないことが想定される。後者の条件は、受信ＴＣＰパケットを逆多重化するときに、ローカルＩＰアドレスを無視するのが安全であることを意味する。

ＴＣＰソケットだけをリスンするために、ローカルＩＰおよびポート番号が考慮される必要があり、一方、確立ＴＣＰソケットのためにリモートＩＰおよび両方のポート番号が考慮されるべきである。そのためネットワークインターフェースデバイスにより行われる処理は、（好都合にはハードウェア中で）、受信パケットがＴＣＰまたはＵＤＰパケットのいずれであるかを決定し、ＴＣＰパケットのためにＳＹＮおよびＡＣＫビットを検査しなければならない。次いでそれは、しかるべくトークンを形成することができ、これはＣＡＭ中で検索される。ＣＡＭ操作は、以下の表で示される。

この表では、最初の列は受信パケットのタイプを示し、残りの列は、それぞれトークンの最初の３２ビット、次の１６ビットおよび最後の１６ビットのコンテンツを示す。同じ規則が一貫して使用される場合、ビット順序は重要ではない。

以下の表は、例を示す：

例では、番号１は、１９２．１６８．１２３．１３５：８０でのローカルウェブサーブリスニングのための状態を示し；番号２は、そのサーバーにより６６．３５．２５０．１５０：３３０２８から受け入れられる接続のための状態を示し；番号３は、ローカルに開始される６６．３５．２５０．１５０へのテルネット接続を示し；および番号４は、ポート１２３でのアプリケーション受信ＵＤＰパケットのための状態を示す。

表１の最初の行のように、ＴＣＰ ＳＹＮ＝１＆ＡＣＫ＝０の状態を分離することにより、そのようなエントリーは、（ＬＩＳＴＥＮ状態のソケットに向けられる）ＴＣＰ接続要求メッセージと一致するが、（ＳＹＮ＿ＳＥＮＴ状態のソケットに向けられる）接続応答と一致しないことを確保できる。

ゼロフィールドの他の組合わせは、他のフィールドで逆多重化するために使用され得る。例えば逆多重化は、イーサネット（登録商標）ヘッダーのＥＴＨＥＲ＿ＴＹＰＥフィールドで行われ得る。

ＣＡＭフィルターの構成を決定する論理は、使用されるプロトコルに依存する。特定のインプリメンテーションにおいてＣＡＭを、仮想インターフェースを通して転送ライブラリコードにより構成することができ、それは特定のインプリメンテーションのために動的にセットアップされる。

ＵＤＰプロトコル下では、ＵＤＰパケット中で指定される各ネットワークエンドポイントを、表１に示されるように、フィルターにより一意的に識別できる。

ＴＣＰプロトコル下において、エンドポイントの固有識別は、それが明確に指定されるために、全てのホストおよびポートフィールドを普通は要求する。複数クライアントが同じ宛先ホストおよびポートアドレスでネットワークエンドポイントと接続すること、接続がクライアントまたはサーバーのいずれかから開始されること、またはサーバーネットワークエンドポイントが単一エンドポイントで接続要求を受け入れ、データ転送を操作するために新しいネットワークエンドポイントを作成することを、ＴＰＣプロトコル定義が許すので、この要件が生ずる。

前述のパケットにおけるヘッダーは、典型的に９６ビット長である。しかし９６ビットフィルターを構成することは、ほとんどの市販ＣＡＭのためには効率的ではない。なぜならそれらは、典型的に（９６よりはむしろ）６４または１２８ビットの幅で入手されるからである。以下の機構は、６４ビットフィルターがより効率的に構成されることを可能にする。ＣＡＭの長さは、アプリケーションを適合させるために選択することができる。便利なサイズは１６ｋｂであり得る。

（１）サーバー（ＰＡＳＳＩＶＥ）ソケットが新しい接続をリスンする場合、全ての有効な着信ＴＣＰパケットは、シーケンス番号を同期させる必要性を示すために、それらのＳＹＮビットをそれらのヘッダー中に設定させる。そのタイプのパケットは、ＮＩＣにより識別され、表１に示されるようにフィルターを形成するために使用される。フィルターのビットレイアウトは、このフィルターが、ゼロフィールド配置の故に、同じホスト：ポートペアを有するＵＤＰエンドポイントと衝突できないことを意味することは注意すべきである。そうしてＣＡＭフィルターのレイアウトは、プロトコルデコードケースを示すために使用される。

（２）接続が確立されるとすぐに、有効な着信パケットが、それらのＳＹＮビットをゼロに設定し、表１に示された論理により正しくフィルターに掛けることができる。

ライブラリは、通常の受信過程で通常パケット検証手順の部分としてこのフィールドをチェックするけれども、この場合、訂正宛先転送ライブラリを識別するために、ＤＥＳＴ（宛先）ホストの識別はもはや要求されないことは注意すべきである。この手順は、図７で説明されるように、サーバー（受動）接続、（サーバー転送ライブラリによりプログラムされる）ＣＡＭのコンテンツ、および各パケットでＮＩＣによりＣＡＭに与えられるフィルターに関して説明される。これは以下のステップを含む：
（ａ）転送ライブラリは、ドライバを介してＣＡＭエントリーを割り当てる。
（ｂ）転送ライブラリの仮想インターフェースに割り振られるアドレススペースに、割り振られるＣＡＭをマップするために、ドライバは、その保護制御インターフェースを通じてハードウェアをプログラムする。
（ｃ）転送ライブラリは、仮想インターフェースを介してＣＡＭエントリーをプログラムする。

アプリケーションが、プログラム可能ＣＡＭエントリーを受信するために不充分なアクセス権限しか有さないと考えられる場合、それは、代わりにＯＳコールを介してそれを行うことが許可され得る。

（ｉｉ）ＴＣＰ／ＩＰコンテンツパケットが到着する。パケットヘッダー中のＳＹＮビットは１に設定され、パケットヘッダー中のＡＣＫビットはゼロに設定されるので、ネットワークインターフェースデバイスは、フィルター：
{dest host, 0, dest port}
をビットからパケットヘッダー中に構成でき、それをＣＡＭに与えることができる。これは、一致をＣＡＭインデックスＸで生じさせる。次いで仮想インターフェース：βの基底アドレスを検出するために、ネットワークインターフェースデバイスは、ＳＲＡＭ中を検索できる。次いでＮＩＣは、仮想インターフェースβにパケットを配信できる。

接続パケットの結果としてサーバーアプリケーションは、ネットワーク接続を操作するために、別のネットワークエンドポイントを作成できる。このエンドポイントは、それ自身または別のアプリケーションコンテキスト内にあることができ、そうして別の転送ライブラリにより管理され得る。いずれかの場合、
{dest host, port}
を
{source host, port}
に結合するネットワーク接続を作成することができ、サーバーは、
{source host, source port, dest port}
で新しいＣＡＭエントリーをプログラムする。

（ｉｉｉ）パケットが新しいネットワーク接続に到着するとき、それは、そのＳＹＮビットをゼロに設定する。これは、ＮＩＣにフィルター：
{source, host source port, dest port}
を構成させ、これは、ＣＡＭに与えられるときに、ＳＲＡＭ中で仮想インターフェースσと一致する一致インデックスθを生じさせる。ネットワーク接続がサーバーエンドポイントと同じ転送ライブラリにより管理される場合、σはβと同じであり得ることは注意すべきである。

このエンコードは、ホストにより開始されるアクティブ（クライアント）接続のため、並びにＴＣＰおよびＵＤＰプロトコル指定で指定される通信の全てのモデルのために、同様に用いることができる。

スキームをエンコードすることの注目に値する利益の１つは、それによりハードウェアが、１つだけのＣＡＭ検索を使用して仮想インターフェースのアドレスを決定できることである。

ネットワークインターフェースデバイスは、好ましくは操作モードもサポートし、その中でそれが、ネットワークエンドポイント上よりはむしろ、転送ライブラリ上でパケットを単純に逆多重化する。デバイスが、ネットワークと、同時に多数（例えば何百万）のネットワーク接続を保守するために要求されるサーバーとの間の通信を操作する場合、これは有益であろう。この例は、大容量ウェブサーバーノードであり得る。２つのオプションが利用できる。１つのオプションは、フォーム：
{dest host, dest port}
のフィルターだけをＣＡＭに保管することである。別のオプションは、「ドント・ケア」ビットを使用してマスクできる３進法ＣＡＭを用いることである。両方の操作モードが同時に可能である場合、ＳＹＮビットが受信パケット中でゼロに設定されるときに、異なるフィルターを構成する必要があるために、２つのＣＡＭ検索が要求され得るので、効率が低下し得ることは注意すべきである。一度に１つだけのモードが可能であれば、この要件は回避し得る。

「ネットワークインターフェースカード」を、物理カードとして埋め込むことができ、またはそれを、別の方式で、例えばデータ処理デバイスのマザーボードに組み込まれる統合回路としてインプリメントできる。

このようにして、ＴＣＰ／ＩＰおよびＵＤＰ／ＩＰパケットは、両方とも、６４ビットのＣＡＭを使用して一致させることができる。これは、ビット単位一致を全ヘッダー上で用いる標準サイズ化ＣＡＭが使用される場合に要求され得る１２８ビットとは、対照的である。

これにより出願人は、分離してこの中で記載された個々の機能、および２つまたはそれ以上の前述の機能のあらゆる組合せを、前述の機能または機能の組合わせがこの中で開示したあらゆる問題を解決するか否かにかかわらず、および請求項の範囲を制限せずに、当業者の共通する一般的知識を考慮して、前述の機能または組合せが、本明細書全体に基いて実行できる程度に開示する。出願人は、本発明の側面が、あらゆる前述の個々の機能または機能の組合せからなることができることを示す。上述の記載を考慮すれば、当業者にとって、様々な修正が、本発明の範囲内でなし得ることは明らかであろう。

Claims (16)

1. データ処理システムによりデータを送信または受信するための方法であり、該システムは、オペレーティングシステムおよびアプリケーションをサポートし、メモリに、およびネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートできるネットワークインターフェースにアクセスでき、該方法は：
   データ処理システムおよびネットワークインターフェースデバイス間のデータ転送におけるデータバッファおよび接続状態バッファとして使用するために、１つまたはそれ以上のメモリ領域を割り当てること；
   ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、アプリケーションによりメモリ領域の少なくとも１つに直接アクセスすること；
   アプリケーションが無応答であると決定された場合に、ネットワークインターフェースデバイスが、オペレーティングシステムにシグナル通知して、前記メモリ領域の少なくとも１つにアクセスさせること；および
   ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、オペレーティングシステムが、シグナルに応答して、データバッファおよび接続状態バッファの少なくとも１つに直接アクセスすること、を含む方法。
2. ネットワークデバイスによりネットワークからデータを受信すること；および
   ネットワークデバイスにより前記領域の少なくとも１つにデータを書き込むことを含む、請求項１に記載の方法。
3. アプリケーションが無応答であると決定された場合に、前記領域の少なくとも１つにアクセスするために、ネットワークデバイスが、オペレーティングシステムにシグナル通知するように構成されており、また、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも１つに直接アクセスする前記ステップを行うことを含む、請求項２に記載の方法。
4. ネットワークデバイスがタイマーをサポートし、および受信データが前記領域の少なくとも１つに書き込まれたときに、方法が、タイマーをスタートし、事前設定の初期値からカウントすることを含み、およびタイマーが事前設定の最終値に達した場合に、アプリケーションが無応答であると決定される、請求項３に記載の方法。
5. アプリケーションにより初期値および／または最終値を設定するステップを含む、請求項４に記載の方法。
6. アプリケーションにより前記領域の少なくとも１つから受信データを読み取ったときに、アプリケーションによりタイマーを停止することを含む、請求項４または５に記載の方法。
7. ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスする前記ステップのそれぞれが、ネットワークインターフェースデバイスによりネットワークから受信され、前記領域の少なくとも１つに保管されたデータのプロトコル処理を含む、請求項１〜６のいずれかに記載の方法。
8. プロトコル処理ステップが、受信データからトラフィックデータを抽出することを含む、請求項７に記載の方法。
9. プロトコル処理ステップが、受信データの少なくともいくつかに関して、ネットワークインターフェースデバイスに、肯定応答および／または再送信メッセージをネットワーク上に送信させることを含む、請求項７に記載の方法。
10. ネットワークデバイスにより、前記領域の少なくとも１つからデータを読み取ること；および
    ネットワークデバイスにより、そのデータをネットワーク上に送信すること
    を含む、請求項１に記載の方法。
11. ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスする前記ステップのそれぞれが、送信用のデータを前記領域の少なくとも１つに保管することを含む、請求項１０に記載の方法。
12. ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスする前記ステップのそれぞれが、ネットワークデバイスを起動して、前記領域の少なくとも１つからデータを読み取る前記ステップを行うことを含む、請求項１０または１１に記載の方法。
13. アプリケーションが無応答であると決定された場合に、前記領域の少なくとも１つにアクセスするために、ネットワークデバイスが、オペレーティングシステムにシグナル通知するように構成されており、および方法が、前述のシグナルに対する応答において、オペレーティングシステムにより前記メモリ領域の少なくとも１つに直接アクセスする前記ステップを行うことを含む、請求項１２に記載の方法。
14. ネットワークデバイスがタイマーをサポートし、および受信データが前記領域の少なくとも１つに書き込まれたことをネットワークインターフェースデバイスによりアプリケーションがシグナル通知されたときに、方法が、タイマーをスタートし、事前設定の初期値からカウントすることを含み、およびタイマーが事前設定の最終値に達した場合に、アプリケーションが無応答であると決定される、請求項１３に記載の方法。
15. アプリケーションにより初期値および／または最終値を設定するステップを含む、請求項１４に記載の方法。
16. データの送信または受信システムであり、該システムは：
    オペレーティングシステムおよびアプリケーションをサポートし、データ処理システムおよびネットワークインターフェースデバイス間のデータ転送におけるデータバッファおよび接続状態バッファとして使用するために割り振られている１つまたはそれ以上のメモリ領域にアクセスさせるデータ処理システム；および
    ネットワーク上で別のネットワークインターフェースデバイスとの通信リンクをサポートでき、アプリケーションが無応答であると決定された場合に、オペレーティングシステムにシグナル通知するように構成されているネットワークインターフェースデバイス（ここで、アプリケーションは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、メモリ領域の少なくとも１つに直接アクセスするように構成されており、オペレーティングシステムは、ネットワークインターフェースデバイスによるデータの送信および受信の少なくとも１つのために、前記データバッファおよび接続状態バッファの少なくとも１つに直接アクセスするように構成されている）を含む、システム。

Images