JP2006121699A - 第1のデータネットワークから第2のデータネットワークへのデータパケットのカーネルレベルの通過のための方法及び装置 - Google Patents
第1のデータネットワークから第2のデータネットワークへのデータパケットのカーネルレベルの通過のための方法及び装置 Download PDFInfo
- Publication number
- JP2006121699A JP2006121699A JP2005305147A JP2005305147A JP2006121699A JP 2006121699 A JP2006121699 A JP 2006121699A JP 2005305147 A JP2005305147 A JP 2005305147A JP 2005305147 A JP2005305147 A JP 2005305147A JP 2006121699 A JP2006121699 A JP 2006121699A
- Authority
- JP
- Japan
- Prior art keywords
- data packet
- network
- processor
- data
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/30—Peripheral units, e.g. input or output ports
- H04L49/3009—Header conversion, routing tables or routing tags
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】第1のデータネットワークから第2のデータネットワークへのデータパケットのカーネルレベルの通過のための方法及び装置を提供する。
【解決手段】本発明にかかる方法は、第1のネットワークからデータパケットを受信し、そのデータパケットをカーネル空間バッファに記憶したら、第2のネットワークへ直接渡す必要があるかどうかを判断し、そのデータパケットを第2のネットワークへ直接渡す必要がある場合に、カーネル空間バッファから第2のネットワークへデータパケットを送ることによって実現される。
【選択図】図6
【解決手段】本発明にかかる方法は、第1のネットワークからデータパケットを受信し、そのデータパケットをカーネル空間バッファに記憶したら、第2のネットワークへ直接渡す必要があるかどうかを判断し、そのデータパケットを第2のネットワークへ直接渡す必要がある場合に、カーネル空間バッファから第2のネットワークへデータパケットを送ることによって実現される。
【選択図】図6
Description
本発明は、第1のデータネットワークから第2のデータネットワークへのデータパケットのカーネルレベルの通過のための方法及び装置に関する。
ネットワーキング構造は、多くの場合、さまざまなタイプのサーバを使用して、クライアント−サーバ接続を完成させる。
例えば、クライアント−サーバ接続は、プロキシサーバを通じて行うことができる。
プロキシサーバは、1又は2以上のクライアント対応デバイスの1つからクライアント要求を受信して、そのクライアント要求を、例えばインターネットといった広域ネットワークに渡すデバイスである。
このタイプのネットワーク構造では、プロキシサーバは、2又は3以上のクライアント対応デバイスからのクライアント要求を、あたかも単一のネットワークアドレスから来たものであるかのように見せることによって価値を付加する。
このように、複数のクライアント対応デバイスは、広域ネットワークに対する単一の接続を共有することができる。
例えば、クライアント−サーバ接続は、プロキシサーバを通じて行うことができる。
プロキシサーバは、1又は2以上のクライアント対応デバイスの1つからクライアント要求を受信して、そのクライアント要求を、例えばインターネットといった広域ネットワークに渡すデバイスである。
このタイプのネットワーク構造では、プロキシサーバは、2又は3以上のクライアント対応デバイスからのクライアント要求を、あたかも単一のネットワークアドレスから来たものであるかのように見せることによって価値を付加する。
このように、複数のクライアント対応デバイスは、広域ネットワークに対する単一の接続を共有することができる。
別のネットワーク構造では、広域ネットワークに対する接続と複数のサーバとの間にロードバランサを導入することができる。
この状況では、複数のサーバは、クライアントに対して単一のネットワークアドレスでアクセスできる単一のサーバとして見える。
この場合、クライアント要求は、広域ネットワークから受信されて、ロードバランサの背後にあるサーバの1つにルーティングされる。
この状況では、複数のサーバは、クライアントに対して単一のネットワークアドレスでアクセスできる単一のサーバとして見える。
この場合、クライアント要求は、広域ネットワークから受信されて、ロードバランサの背後にあるサーバの1つにルーティングされる。
プロキシサーバ及びロードバランサは、クライアントとサーバとの間の接続の確立を容易にするように動作する専用ネットワークプロセッサの2つの例にすぎない。
或る意味で、これらの専用ネットワークプロセッサは、「仲介者サーバ(middle-man server)」である。
仲介者サーバは、大規模なネットワーキング方式で価値を付加するが、このような仲介者サーバは、クライアントとサーバとの間の接続を容易にするだけである。
したがって、仲介者サーバが付加する価値は、重要ではあるが、ファイルの要求(クライアント対応デバイスが行うようなもの)やファイルの提供(サーバが提供するようなもの)等の主要なサービスではない。
或る意味で、これらの専用ネットワークプロセッサは、「仲介者サーバ(middle-man server)」である。
仲介者サーバは、大規模なネットワーキング方式で価値を付加するが、このような仲介者サーバは、クライアントとサーバとの間の接続を容易にするだけである。
したがって、仲介者サーバが付加する価値は、重要ではあるが、ファイルの要求(クライアント対応デバイスが行うようなもの)やファイルの提供(サーバが提供するようなもの)等の主要なサービスではない。
専用ネットワークプロセッサは、従来、専用ハードウェア及び専用ソフトウェアを使用して実施されてきた。
しかしながら、これによって、特にパーソナルコンピュータのような大容量のハードウェアコンポーネントに比べて、このようなネットワークプロセッサをより高価なものにしてきた。
このことが認識されたので、今や、多くのネットワークプロセッサは、標準ハードウェアプラットフォーム上で構築される。
標準ハードウェアプラットフォームを使用してネットワークプロセッサを実施する場合、標準ハードウェアプラットフォームは、一般に、常駐オペレーティングシステムによって制御されたままである。
この理由は、「プラグアンドプレイ」ハードウェアという全体概念に基づいている。
例えば、特定のハードウェアプラットフォームを供給された常駐オペレーティングシステム、又は、特定のハードウェアプラットフォームで利用可能な常駐オペレーティングシステムを使用することによって、ネットワークプロセッサは、カスタマイズされたドライバを開発する必要なく、標準周辺コンポーネントを使用することができる。
ネットワークインターフェース周辺機器を提供するベンダも、一般に、常駐オペレーティングシステムがネットワークインターフェースとやりとりすることを可能にするドライバを提供することを考慮すると、これは特に魅力的である。
しかしながら、これによって、特にパーソナルコンピュータのような大容量のハードウェアコンポーネントに比べて、このようなネットワークプロセッサをより高価なものにしてきた。
このことが認識されたので、今や、多くのネットワークプロセッサは、標準ハードウェアプラットフォーム上で構築される。
標準ハードウェアプラットフォームを使用してネットワークプロセッサを実施する場合、標準ハードウェアプラットフォームは、一般に、常駐オペレーティングシステムによって制御されたままである。
この理由は、「プラグアンドプレイ」ハードウェアという全体概念に基づいている。
例えば、特定のハードウェアプラットフォームを供給された常駐オペレーティングシステム、又は、特定のハードウェアプラットフォームで利用可能な常駐オペレーティングシステムを使用することによって、ネットワークプロセッサは、カスタマイズされたドライバを開発する必要なく、標準周辺コンポーネントを使用することができる。
ネットワークインターフェース周辺機器を提供するベンダも、一般に、常駐オペレーティングシステムがネットワークインターフェースとやりとりすることを可能にするドライバを提供することを考慮すると、これは特に魅力的である。
常駐オペレーティングシステムによって提供される機構を使用すること、及び、カスタムアプリケーション用の標準ハードウェアプラットフォームを構成することによって、専用ネットワークプロセッサのコストは、年を追って大幅に削減されてきた。
通常の構成では、パーソナルコンピュータが、2つのネットワークインターフェースカードを含めることによってプロキシサーバとして構成される。
これら2つのネットワークインターフェースカードは、2つのデータネットワークへの独立したアクセスをパーソナルコンピュータに与える。
プロキシサーバアプリケーションでは、或るネットワークがローカルデータネットワークとして使用され、このローカルデータネットワークには、複数のクライアント対応デバイスを通信するように接続することができる。
このような接続は、有線ネットワークとして行うこともできるし、無線ネットワークとして行うこともできることが理解されるべきである。
通常の構成では、パーソナルコンピュータが、2つのネットワークインターフェースカードを含めることによってプロキシサーバとして構成される。
これら2つのネットワークインターフェースカードは、2つのデータネットワークへの独立したアクセスをパーソナルコンピュータに与える。
プロキシサーバアプリケーションでは、或るネットワークがローカルデータネットワークとして使用され、このローカルデータネットワークには、複数のクライアント対応デバイスを通信するように接続することができる。
このような接続は、有線ネットワークとして行うこともできるし、無線ネットワークとして行うこともできることが理解されるべきである。
この構成をさらに説明すると、常駐オペレーティングシステムは、ネットワーク通信サービスをアプリケーションに提供するために、各ネットワークインターフェースカードに特有のドライバを使用するプロトコルスタックを提供する。
プロキシサーバの機能を提供するために、アプリケーションが常駐オペレーティングシステムの制御下で実行される。
次に、このアプリケーションは、オペレーティングシステムによって提供されるネットワーク通信サービスを使用して、クライアントとの接続を確立し、次いで、サーバとの接続を確立する。
そして、オペレーティングシステムの制御下で実行されているアプリケーションは、クライアントからデータパケットを受信し、そのデータパケットをサーバへ転送する。
この通常の低コストネットワークプロセッサ構造では、アプリケーションは、「ネットワーク処理アプリケーション」と呼ばれ、一方のデータネットワークから他方のデータネットワークへデータパケットを渡す時、データパケットの或る部分を変更する。
通常、データは変更される必要はないが、特定のメタデータ(例えば、ヘッダ情報)は、多くの場合、変更されてネットワーク処理機能に影響を与える。
例えば、プロキシサーバの機能を実施するネットワーク処理アプリケーションは、通常、データパケットのヘッダに含まれる送信元アドレス及び宛先アドレス並びに送信元ポート番号及び宛先ポート番号を変更する必要がある。
プロキシサーバの機能を提供するために、アプリケーションが常駐オペレーティングシステムの制御下で実行される。
次に、このアプリケーションは、オペレーティングシステムによって提供されるネットワーク通信サービスを使用して、クライアントとの接続を確立し、次いで、サーバとの接続を確立する。
そして、オペレーティングシステムの制御下で実行されているアプリケーションは、クライアントからデータパケットを受信し、そのデータパケットをサーバへ転送する。
この通常の低コストネットワークプロセッサ構造では、アプリケーションは、「ネットワーク処理アプリケーション」と呼ばれ、一方のデータネットワークから他方のデータネットワークへデータパケットを渡す時、データパケットの或る部分を変更する。
通常、データは変更される必要はないが、特定のメタデータ(例えば、ヘッダ情報)は、多くの場合、変更されてネットワーク処理機能に影響を与える。
例えば、プロキシサーバの機能を実施するネットワーク処理アプリケーションは、通常、データパケットのヘッダに含まれる送信元アドレス及び宛先アドレス並びに送信元ポート番号及び宛先ポート番号を変更する必要がある。
たとえ、ネットワークプロセッサのコストを、標準ハードウェア及び関連した常駐オペレーティングシステムを使用することによって削減できるとしても、オペレーティングシステムによって通例提供される機構を使用することによって、実際には、到達可能な性能が制限される。
例えば、ネットワーク処理アプリケーションが、常駐オペレーティングシステムの制御下で実行され、第1のネットワークインターフェースカードから第2のネットワークインターフェースカードへデータパケットを渡す必要がある場合、複数のメモリトランザクションが必要とされる。
まず、データパケットが第1のネットワークインターフェースカードに到着した時、プロトコルスタックは、そのデータパケットを受信して、オペレーティングシステムによって保持されたメモリバッファ(すなわち、カーネルレベルバッファ)内に入れる。
これには、カーネルレベルバッファの割り当てが必要とされる。
次に、データパケットをネットワーク処理アプリケーションへ渡す必要がある。
ネットワーク処理アプリケーションは、アプリケーション空間で実行されるので、新しいアプリケーションレベルバッファを割り当てる必要があり、データパケットは、カーネルレベルバッファからアプリケーションレベルバッファへコピーされる。
次に、ネットワーク処理アプリケーションは、アプリケーション空間において、データパケットに対し操作を行うことができる。
次に、ネットワーク処理アプリケーションは、データパケットをプロトコルスタックへ戻す必要がある。
これには、アプリケーションレベルバッファから新たに作成されたカーネルレベルバッファへデータパケットをコピーできるようになる前に、新しいカーネルレベルバッファの割り当てが必要とされる。
これらのデータコピーステップのすべてに処理能力が必要とされる。
処理能力は限られているので、所与の期間に処理できるデータパケット数も限られる。
例えば、ネットワーク処理アプリケーションが、常駐オペレーティングシステムの制御下で実行され、第1のネットワークインターフェースカードから第2のネットワークインターフェースカードへデータパケットを渡す必要がある場合、複数のメモリトランザクションが必要とされる。
まず、データパケットが第1のネットワークインターフェースカードに到着した時、プロトコルスタックは、そのデータパケットを受信して、オペレーティングシステムによって保持されたメモリバッファ(すなわち、カーネルレベルバッファ)内に入れる。
これには、カーネルレベルバッファの割り当てが必要とされる。
次に、データパケットをネットワーク処理アプリケーションへ渡す必要がある。
ネットワーク処理アプリケーションは、アプリケーション空間で実行されるので、新しいアプリケーションレベルバッファを割り当てる必要があり、データパケットは、カーネルレベルバッファからアプリケーションレベルバッファへコピーされる。
次に、ネットワーク処理アプリケーションは、アプリケーション空間において、データパケットに対し操作を行うことができる。
次に、ネットワーク処理アプリケーションは、データパケットをプロトコルスタックへ戻す必要がある。
これには、アプリケーションレベルバッファから新たに作成されたカーネルレベルバッファへデータパケットをコピーできるようになる前に、新しいカーネルレベルバッファの割り当てが必要とされる。
これらのデータコピーステップのすべてに処理能力が必要とされる。
処理能力は限られているので、所与の期間に処理できるデータパケット数も限られる。
カーネルレベルで第1のネットワークから第2のネットワークへデータパケットを渡す方法及び装置が開示される。
ある実施態様では、これは、第1のネットワークからデータパケットを受信し、そのデータパケットをカーネル空間バッファに記憶したら、第2のネットワークへ直接渡す必要があるかどうかを判断し、そのデータパケットを第2のネットワークへ直接渡す必要がある場合に、カーネル空間バッファから第2のネットワークへデータパケットを送ることによって行われる。
ある実施態様では、これは、第1のネットワークからデータパケットを受信し、そのデータパケットをカーネル空間バッファに記憶したら、第2のネットワークへ直接渡す必要があるかどうかを判断し、そのデータパケットを第2のネットワークへ直接渡す必要がある場合に、カーネル空間バッファから第2のネットワークへデータパケットを送ることによって行われる。
以下では、複数の別の実施態様を、添付図面と併せて説明する。
なお、添付図面において、同じ符号は同じ要素を示す。
なお、添付図面において、同じ符号は同じ要素を示す。
図1は、第1のデータネットワークから第2のデータネットワークへデータパケットを渡すための一方法例を示すフロー図である。
この方法例によれば、第1のデータネットワークから第2のデータネットワークへデータパケットを渡すことは、カーネルレベルで達成される。
したがって、データパケットは、第1のネットワークから受信される(ステップ5)。
次に、データパケットは、カーネルレベルバッファに記憶される(ステップ10)。
この方法例によれば、データパケットを第2のデータネットワークへ転送すべきかどうかについての判断が行われる。
データパケットを第2のデータネットワークへ転送する必要がある場合(ステップ15)、データパケットは、カーネルレベルバッファから第2のデータネットワークへ送られる(ステップ20)。
本方法は、コンピュータシステムがネットワークプロセッサとして動作するように構成される状況で適用することができる。
ある使用例では、本方法は、コンピュータシステムがロードバランサとして動作するように構成される状況で適用される。
別の使用例では、本方法は、コンピュータシステムがプロキシサーバとして構成される状況で適用される。
これらは、コンピュータシステムがネットワークプロセッサとして動作するように構成される状況で本方法をどのように適用できるかの単なる例にすぎないことが理解されるべきである。
したがって、本明細書に添付した特許請求の範囲は、本明細書で提示した使用例には限定されないものとする。
この方法例によれば、第1のデータネットワークから第2のデータネットワークへデータパケットを渡すことは、カーネルレベルで達成される。
したがって、データパケットは、第1のネットワークから受信される(ステップ5)。
次に、データパケットは、カーネルレベルバッファに記憶される(ステップ10)。
この方法例によれば、データパケットを第2のデータネットワークへ転送すべきかどうかについての判断が行われる。
データパケットを第2のデータネットワークへ転送する必要がある場合(ステップ15)、データパケットは、カーネルレベルバッファから第2のデータネットワークへ送られる(ステップ20)。
本方法は、コンピュータシステムがネットワークプロセッサとして動作するように構成される状況で適用することができる。
ある使用例では、本方法は、コンピュータシステムがロードバランサとして動作するように構成される状況で適用される。
別の使用例では、本方法は、コンピュータシステムがプロキシサーバとして構成される状況で適用される。
これらは、コンピュータシステムがネットワークプロセッサとして動作するように構成される状況で本方法をどのように適用できるかの単なる例にすぎないことが理解されるべきである。
したがって、本明細書に添付した特許請求の範囲は、本明細書で提示した使用例には限定されないものとする。
図2は、第1のネットワークからデータパケットを受信するための、本方法の一例を示すフロー図である。
本方法のこの態様では、データパケットが、トランスポート層のデータパケットとして第1のデータネットワークから受信される(ステップ25)。
いくつかの使用例では、ネットワークプロセッサにおけるデータパケットの処理は、通常、プロトコル定義に従って行われることが理解されるべきである。
通常、ネットワークプロセッサにおけるデータパケットの処理には、プロトコル定義で定義されるようなトランスポート層におけるデータパケットの受信が必要とされる。
したがって、トランスポート層のデータパケットは、通常、接続識別情報を含む。
この接続識別情報は、本方法のこの態様によれば、データパケットを第2のデータネットワークへ転送する必要があるかどうかを判断するのに使用されるものである。
例えば、転送制御プロトコル/インターネットプロトコル(TCP/IP)と呼ばれるよく知られた一通信プロトコルによれば、接続識別情報は、送信元アドレス、宛先アドレス、送信元ポート番号、及び宛先ポート番号から構成される。
データパケットシーケンス番号といった他の情報も、いくつかの通信プロトコル定義に従ってヘッダに含まれる。
本方法は、第1のデータネットワーク及び第2のデータネットワークの一方又は双方のいずれかで利用される通信プロトコルのタイプにかかわらず適用できることが理解されるべきである。
本方法のこの態様では、データパケットが、トランスポート層のデータパケットとして第1のデータネットワークから受信される(ステップ25)。
いくつかの使用例では、ネットワークプロセッサにおけるデータパケットの処理は、通常、プロトコル定義に従って行われることが理解されるべきである。
通常、ネットワークプロセッサにおけるデータパケットの処理には、プロトコル定義で定義されるようなトランスポート層におけるデータパケットの受信が必要とされる。
したがって、トランスポート層のデータパケットは、通常、接続識別情報を含む。
この接続識別情報は、本方法のこの態様によれば、データパケットを第2のデータネットワークへ転送する必要があるかどうかを判断するのに使用されるものである。
例えば、転送制御プロトコル/インターネットプロトコル(TCP/IP)と呼ばれるよく知られた一通信プロトコルによれば、接続識別情報は、送信元アドレス、宛先アドレス、送信元ポート番号、及び宛先ポート番号から構成される。
データパケットシーケンス番号といった他の情報も、いくつかの通信プロトコル定義に従ってヘッダに含まれる。
本方法は、第1のデータネットワーク及び第2のデータネットワークの一方又は双方のいずれかで利用される通信プロトコルのタイプにかかわらず適用できることが理解されるべきである。
繰り返すと、本方法の一特徴により、ヘッダの情報が、データパケットをルーティングするのに使用できる情報を含む特定のプロトコル内のレベルで第1のネットワークからデータパケットを受信することができる。
したがって、本方法は、データパケットに紐付けられたメタデータの受信に依拠するものであり、該メタデータは、データパケットを第2にデータネットワークに転送するか否かを判断するためのものである。
さらに、本方法の別の態様では、接続識別子が、データパケットを第2のデータネットワークへ転送する必要があるかどうかを判断するのに使用されるメタデータのタイプの一例となる。
データパケットに紐付けられたメタデータは、本方法の別の態様では、データパケットに含まれるデータ型を記述する付加情報を含むことがさらに理解されるべきである。
例えば、インターネットプロトコルデータ上の音声としてデータパケットに含まれるデータを記述する情報は、データパケットを第2のデータネットワークへ転送すべきかどうかを判断するのに使用されるその他の付加情報の一例である。
本明細書に提示したいずれの例においても、データパケットを第2のデータネットワークへ通過させるかどうかを判断するのに使用できる多種多様なタイプの情報は、本明細書に添付した特許請求の範囲を限定しないものとする。
データパケットと共に含まれるか、又は、データパケットに紐付けられるメタデータであって、第1のデータネットワークから第2のデータネットワークへのデータパケットのルーティングを容易にするのに使用できるメタデータのいずれのタイプも、本明細書に添付した特許請求の範囲に含まれることになることがさらに理解されるべきである。
したがって、本方法は、データパケットに紐付けられたメタデータの受信に依拠するものであり、該メタデータは、データパケットを第2にデータネットワークに転送するか否かを判断するためのものである。
さらに、本方法の別の態様では、接続識別子が、データパケットを第2のデータネットワークへ転送する必要があるかどうかを判断するのに使用されるメタデータのタイプの一例となる。
データパケットに紐付けられたメタデータは、本方法の別の態様では、データパケットに含まれるデータ型を記述する付加情報を含むことがさらに理解されるべきである。
例えば、インターネットプロトコルデータ上の音声としてデータパケットに含まれるデータを記述する情報は、データパケットを第2のデータネットワークへ転送すべきかどうかを判断するのに使用されるその他の付加情報の一例である。
本明細書に提示したいずれの例においても、データパケットを第2のデータネットワークへ通過させるかどうかを判断するのに使用できる多種多様なタイプの情報は、本明細書に添付した特許請求の範囲を限定しないものとする。
データパケットと共に含まれるか、又は、データパケットに紐付けられるメタデータであって、第1のデータネットワークから第2のデータネットワークへのデータパケットのルーティングを容易にするのに使用できるメタデータのいずれのタイプも、本明細書に添付した特許請求の範囲に含まれることになることがさらに理解されるべきである。
図3は、データパケットを第2のデータネットワークへ直接渡す必要があるかどうかを判断するための、別の一方法を示すフロー図である。
この別の方法では、データパケットに紐付けられたメタデータが、アプリケーション空間で実行されているアプリケーションへ送られる(ステップ30)。
データパケットは、自身を何らかの形式のメタデータに紐付けており、このメタデータは、本方法の別の態様では、データパケットを第2のデータネットワークへ転送するかどうかを判断するのに使用されるものである、ということを理解すべきである。
したがって、データパケットに紐付けられたメタデータは、データ及びそれに紐付けられたメタデータを記憶するのに使用されたカーネルレベルバッファから抽出される。
アプリケーション空間で実行されているアプリケーションは、当該アプリケーションが受信するデータパケットに紐付けられたメタデータに従って、当該データパケットを第2のデータネットワークへ転送するかどうかについての判断を行う。
したがって、この判断を反映する通過インジケータが、アプリケーション空間で実行されているアプリケーションから受信される(ステップ35)。
この別の方法では、データパケットに紐付けられたメタデータが、アプリケーション空間で実行されているアプリケーションへ送られる(ステップ30)。
データパケットは、自身を何らかの形式のメタデータに紐付けており、このメタデータは、本方法の別の態様では、データパケットを第2のデータネットワークへ転送するかどうかを判断するのに使用されるものである、ということを理解すべきである。
したがって、データパケットに紐付けられたメタデータは、データ及びそれに紐付けられたメタデータを記憶するのに使用されたカーネルレベルバッファから抽出される。
アプリケーション空間で実行されているアプリケーションは、当該アプリケーションが受信するデータパケットに紐付けられたメタデータに従って、当該データパケットを第2のデータネットワークへ転送するかどうかについての判断を行う。
したがって、この判断を反映する通過インジケータが、アプリケーション空間で実行されているアプリケーションから受信される(ステップ35)。
図4は、第2のデータネットワークへデータパケットを送るための、別の方法例を示すフロー図である。
ネットワーク処理機能を実施するアプリケーションは、通常、アプリケーション空間で実行される。
したがって、アプリケーション空間は、通常、オペレーティングシステムによって管理される。
さまざまな使用例では、ネットワーク処理機能を実行しているアプリケーションは、第1のデータネットワークから受信されたデータパケットがその後第2のデータネットワークへ転送される前に、通常、そのデータパケットに紐付けられたメタデータ(例えば、ヘッダ)を変更する必要がある。
本方法によれば、元のメタデータ及びデータパケット自体は、カーネルレベルバッファに記憶される。
この本方法の別の態様によれば、変更されたメタデータは、アプリケーション空間で実行されているアプリケーションから受信される(ステップ40)。
次に、変更されたメタデータは、データパケットに紐付けられる(ステップ45)。
これは、さらに、本方法の別の態様では、カーネルレベルバッファに記憶された元のメタデータの代わりに、変更されたメタデータを使用することによって行われる。
データパケットは、変更されたメタデータと共に、第2のデータネットワークへ送られる(ステップ50)。
ネットワーク処理機能を実施するアプリケーションは、通常、アプリケーション空間で実行される。
したがって、アプリケーション空間は、通常、オペレーティングシステムによって管理される。
さまざまな使用例では、ネットワーク処理機能を実行しているアプリケーションは、第1のデータネットワークから受信されたデータパケットがその後第2のデータネットワークへ転送される前に、通常、そのデータパケットに紐付けられたメタデータ(例えば、ヘッダ)を変更する必要がある。
本方法によれば、元のメタデータ及びデータパケット自体は、カーネルレベルバッファに記憶される。
この本方法の別の態様によれば、変更されたメタデータは、アプリケーション空間で実行されているアプリケーションから受信される(ステップ40)。
次に、変更されたメタデータは、データパケットに紐付けられる(ステップ45)。
これは、さらに、本方法の別の態様では、カーネルレベルバッファに記憶された元のメタデータの代わりに、変更されたメタデータを使用することによって行われる。
データパケットは、変更されたメタデータと共に、第2のデータネットワークへ送られる(ステップ50)。
図5は、第2のデータネットワークへ送る必要がないデータパケットを処理するための、別の方法を示すフロー図である。
(図1に示すような)本方法によれば、データパケットを第2のデータネットワークへ転送する必要があるかどうかについての判断が行われる(ステップ15)。
データパケットを第2のデータネットワークへ転送する必要がない場合、本方法の当該態様は、アプリケーション空間で実行されているアプリケーションへデータパケット自体を送ることを可能にする(ステップ60)。
本方法のさらに別の態様では、これは、データパケットを記憶するのに使用されるカーネルレベルバッファに対する読み出し専用参照を提供することによって行われる。
本方法のさらに別の態様では、データパケット及びそれに紐付くメタデータを記憶するのに使用されるカーネルレベルバッファに対する読み出し専用参照を提供することによって行われる。
(図1に示すような)本方法によれば、データパケットを第2のデータネットワークへ転送する必要があるかどうかについての判断が行われる(ステップ15)。
データパケットを第2のデータネットワークへ転送する必要がない場合、本方法の当該態様は、アプリケーション空間で実行されているアプリケーションへデータパケット自体を送ることを可能にする(ステップ60)。
本方法のさらに別の態様では、これは、データパケットを記憶するのに使用されるカーネルレベルバッファに対する読み出し専用参照を提供することによって行われる。
本方法のさらに別の態様では、データパケット及びそれに紐付くメタデータを記憶するのに使用されるカーネルレベルバッファに対する読み出し専用参照を提供することによって行われる。
図6は、ネットワークプロセッサの一実施態様を示すブロック図である。
この実施態様によれば、ネットワークプロセッサは、1又は2以上のプロセッサ100、第1のネットワークインターフェース105、第2のネットワークインターフェース115、及びメモリ130を備える。
これらの要素のすべては、バス125によって相互に通信接続されている。
この実施態様によれば、ネットワークプロセッサは、1又は2以上のプロセッサ100、第1のネットワークインターフェース105、第2のネットワークインターフェース115、及びメモリ130を備える。
これらの要素のすべては、バス125によって相互に通信接続されている。
この実施態様では、ネットワークプロセッサは、さらに、メモリ130に記憶された1又は2以上の機能モジュールを備える。
機能モジュールは、1又は2以上のプロセッサ100によって実行される命令シーケンスを備える。
プロセッサ100は、特定の命令シーケンスを実行する時、本方法の指示に従った一定の機能を実行する。
「少なくともプロセッサに〜させる」という用語及びその類似表現は、プロセッサ100が特定の機能モジュール(すなわち、命令シーケンス)を実行する時に、プロセッサ100によって実行される機能のオープンエンドな列挙として働くものとする、ということを読み手に忠告しておく。
したがって、特定の機能モジュールが、プロセッサ100に、添付した特許請求の範囲で定義した機能に追加した機能を実行させるという実施態様は、本明細書に添付した特許請求の範囲に含まれることになる。
機能モジュールは、1又は2以上のプロセッサ100によって実行される命令シーケンスを備える。
プロセッサ100は、特定の命令シーケンスを実行する時、本方法の指示に従った一定の機能を実行する。
「少なくともプロセッサに〜させる」という用語及びその類似表現は、プロセッサ100が特定の機能モジュール(すなわち、命令シーケンス)を実行する時に、プロセッサ100によって実行される機能のオープンエンドな列挙として働くものとする、ということを読み手に忠告しておく。
したがって、特定の機能モジュールが、プロセッサ100に、添付した特許請求の範囲で定義した機能に追加した機能を実行させるという実施態様は、本明細書に添付した特許請求の範囲に含まれることになる。
これまでに説明した機能モジュール(及びそれらに対応する命令シーケンス)により、本方法の指示に従って第1のデータネットワークから第2のデータネットワークへデータを渡すことが可能になる。
ある実施態様では、これらの機能モジュールは、コンピュータ可読媒体上に付与される。
このような媒体の例には、ランダムアクセスメモリ、読み出し専用メモリ(ROM)、コンパクトディスク(CD-ROM)、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、及び磁気テープが含まれるが、これらに限定されるものではない。
このコンピュータ可読媒体は、単独でスタンドアロン製品を構成することもできるし、組み合わせでスタンドアロン製品を構成することもでき、汎用の計算プラットフォームを、本明細書で提示した技術及び指示に従って第1のデータネットワークから第2のデータネットワークへデータパケットを渡すことができるデバイスに変換するのに使用することができる。
したがって、本明細書に添付した特許請求の範囲は、本方法及びここで述べる指示のすべてを実行できる命令シーケンスを付与されたこのようなコンピュータ可読媒体を含むことになる。
ある実施態様では、これらの機能モジュールは、コンピュータ可読媒体上に付与される。
このような媒体の例には、ランダムアクセスメモリ、読み出し専用メモリ(ROM)、コンパクトディスク(CD-ROM)、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、及び磁気テープが含まれるが、これらに限定されるものではない。
このコンピュータ可読媒体は、単独でスタンドアロン製品を構成することもできるし、組み合わせでスタンドアロン製品を構成することもでき、汎用の計算プラットフォームを、本明細書で提示した技術及び指示に従って第1のデータネットワークから第2のデータネットワークへデータパケットを渡すことができるデバイスに変換するのに使用することができる。
したがって、本明細書に添付した特許請求の範囲は、本方法及びここで述べる指示のすべてを実行できる命令シーケンスを付与されたこのようなコンピュータ可読媒体を含むことになる。
メモリ130には、プロトコルスタック135、受信送信モジュール140、及びアプリケーション150を含む1又は2以上の機能モジュールが記憶される。
別の実施態様では、アプリケーション150はネットワーク処理アプリケーションからなる。
さらに別の実施態様によれば、アプリケーション150はプロキシアプリケーションからなる。
さらに別の実施態様によれば、アプリケーション150はロードバランスアプリケーションからなる。
また、メモリ130は、データパケットを記憶するのに使用される。
データパケット170は、カーネルレベルバッファ155に記憶される。
さらに、別の実施態様では、メモリ130は、データパケットをアプリケーションレベルバッファ160に記憶するのにも使用される。
別の実施態様では、データパケットはメタデータ及びデータペイロードを含むことがさらに理解されるべきである。
別の実施態様では、アプリケーション150はネットワーク処理アプリケーションからなる。
さらに別の実施態様によれば、アプリケーション150はプロキシアプリケーションからなる。
さらに別の実施態様によれば、アプリケーション150はロードバランスアプリケーションからなる。
また、メモリ130は、データパケットを記憶するのに使用される。
データパケット170は、カーネルレベルバッファ155に記憶される。
さらに、別の実施態様では、メモリ130は、データパケットをアプリケーションレベルバッファ160に記憶するのにも使用される。
別の実施態様では、データパケットはメタデータ及びデータペイロードを含むことがさらに理解されるべきである。
図7は、ネットワークプロセッサのある実施態様における内部オペレーションを示すデータフロー図である。
この実施態様では、プロセッサ100は、送受信モジュール140を実行する。
また、プロセッサ100は、プロトコルスタック135A、135Bという少なくとも2つのインスタンスを実行する。
プロトコルスタック135Aの第1のインスタンスは、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、第1のネットワークインターフェース105によって第1のデータネットワーク110からのデータパケットを受信させる。
プロトコルスタック135Bの第2のインスタンスは、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、第2のネットワークインターフェース115によって第2のデータネットワーク120へデータパケットを搬送させる。
この実施態様では、プロセッサ100は、送受信モジュール140を実行する。
また、プロセッサ100は、プロトコルスタック135A、135Bという少なくとも2つのインスタンスを実行する。
プロトコルスタック135Aの第1のインスタンスは、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、第1のネットワークインターフェース105によって第1のデータネットワーク110からのデータパケットを受信させる。
プロトコルスタック135Bの第2のインスタンスは、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、第2のネットワークインターフェース115によって第2のデータネットワーク120へデータパケットを搬送させる。
プロセッサ100が送受信モジュール140を実行し続けると、送受信モジュール140は、少なくとも、プロセッサ100に、プロセッサ100によって実行されるプロトコルスタック135Aの第1のインスタンスからのデータパケットを受け取らせる(190)。
データパケット170は、カーネルレベルバッファに記憶される(185)。
別の実施態様では、データパケットは、メタデータ175及びペイロードデータ180を含む。
さらに、送受信モジュール140は、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、カーネルレベルバッファから、プロセッサ100によって実行されるプロトコルスタック135Bの第2のインスタンスへデータパケット170を送らせる(195)。
別の実施態様では、プロセッサ100は、プロトコルスタック135Bの第2のインスタンスに、データパケットがカーネルレベルバッファから第2のネットワーク120へ搬送されることを通知する転送信号200を発生させる。
この結果、第2のネットワークインターフェース115を介して、第2のネットワーク120へデータパケットが搬送される。
別の実施態様では、プロトコルスタック135は、少なくとも、プロセッサ100に、本方法の技術及び指示に従ってトランスポート層のデータパケットを受信させることにより、プロセッサ100にデータパケットを受信させる。
データパケット170は、カーネルレベルバッファに記憶される(185)。
別の実施態様では、データパケットは、メタデータ175及びペイロードデータ180を含む。
さらに、送受信モジュール140は、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、カーネルレベルバッファから、プロセッサ100によって実行されるプロトコルスタック135Bの第2のインスタンスへデータパケット170を送らせる(195)。
別の実施態様では、プロセッサ100は、プロトコルスタック135Bの第2のインスタンスに、データパケットがカーネルレベルバッファから第2のネットワーク120へ搬送されることを通知する転送信号200を発生させる。
この結果、第2のネットワークインターフェース115を介して、第2のネットワーク120へデータパケットが搬送される。
別の実施態様では、プロトコルスタック135は、少なくとも、プロセッサ100に、本方法の技術及び指示に従ってトランスポート層のデータパケットを受信させることにより、プロセッサ100にデータパケットを受信させる。
別の実施態様では、送受信モジュール140は、少なくとも、プロセッサ100が、カーネルレベルバッファに記憶されたデータパケット170からメタデータ175を取り出す(205)ことにより、プロセッサ100に、プロトコルスタック135Bの第2のインスタンスへデータパケットを送らせる。
プロセッサ100が送受信モジュール140を実行し続けると、送受信モジュール140は、さらに、少なくとも、プロセッサ100に、アプリケーション空間で実行されているアプリケーション150へメタデータを送らせる(215)。
この別の実施態様では、アプリケーション空間で実行されているアプリケーション150は、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、アプリケーション150が受信したメタデータに紐付いたデータパケットを第2のデータネットワーク120へ送る必要があるかどうかを判断させる。
この判断の結果は、プロセッサ100がアプリケーション空間でアプリケーション150を実行し続けると、送受信モジュール140へ搬送して戻される通過インジケータ220に反映される。
カーネルレベルバッファに記憶されたデータパケットを第2のデータネットワーク120へ送る必要があることを通過インジケータ220が示している場合、受信送信モジュール140は、カーネルレベルバッファからプロトコルスタック135Bの第2のインスタンスへデータパケット170を送る。
プロセッサ100が送受信モジュール140を実行し続けると、送受信モジュール140は、さらに、少なくとも、プロセッサ100に、アプリケーション空間で実行されているアプリケーション150へメタデータを送らせる(215)。
この別の実施態様では、アプリケーション空間で実行されているアプリケーション150は、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、アプリケーション150が受信したメタデータに紐付いたデータパケットを第2のデータネットワーク120へ送る必要があるかどうかを判断させる。
この判断の結果は、プロセッサ100がアプリケーション空間でアプリケーション150を実行し続けると、送受信モジュール140へ搬送して戻される通過インジケータ220に反映される。
カーネルレベルバッファに記憶されたデータパケットを第2のデータネットワーク120へ送る必要があることを通過インジケータ220が示している場合、受信送信モジュール140は、カーネルレベルバッファからプロトコルスタック135Bの第2のインスタンスへデータパケット170を送る。
さらに別の実施態様では、送受信モジュール140は、プロセッサ100によって実行されると、少なくとも、プロセッサ100に、アプリケーション空間で実行されているアプリケーション150から代わりの(すなわち、変更された)メタデータを受信させる(225)。
プロセッサ100が、受信送信モジュール140というこの実施態様を実行し続けると、この変更されたメタデータは、カーネルレベルバッファに記憶された元のメタデータ175の代わりに使用される(210)。
プロセッサ100が、送受信モジュール140というこの実施態様を実行し続けると、変更されたメタデータ175及びペイロードデータ180を含むデータパケットは、プロトコルスタック135Bの第2のインスタンスへ送られる。
ある実施態様では、メタデータはプロトコルヘッダを含むことが理解されるべきである。
さらに別の実施態様では、メタデータは、送信元アドレス、宛先アドレス、送信元ポート番号、及び宛先ポート番号を含む。
プロセッサ100が、受信送信モジュール140というこの実施態様を実行し続けると、この変更されたメタデータは、カーネルレベルバッファに記憶された元のメタデータ175の代わりに使用される(210)。
プロセッサ100が、送受信モジュール140というこの実施態様を実行し続けると、変更されたメタデータ175及びペイロードデータ180を含むデータパケットは、プロトコルスタック135Bの第2のインスタンスへ送られる。
ある実施態様では、メタデータはプロトコルヘッダを含むことが理解されるべきである。
さらに別の実施態様では、メタデータは、送信元アドレス、宛先アドレス、送信元ポート番号、及び宛先ポート番号を含む。
さらに別の実施態様の例では、送受信モジュール140は、カーネルレベルバッファに記憶されたデータパケットを第2のデータネットワーク120へ転送する必要がないと判断すると、アプリケーション150が、カーネルレベルバッファに記憶されたデータパケットにアクセスすることを可能にする。
ある実施態様では、これは、プロセッサ100が、カーネルレベルバッファに記憶されたデータパケット170に対する読み出し専用参照を提供する(230)ため、プロトコルスタック135Aの第1のインスタンスを実行すると行われる。
ある実施態様では、これは、プロセッサ100が、カーネルレベルバッファに記憶されたデータパケット170に対する読み出し専用参照を提供する(230)ため、プロトコルスタック135Aの第1のインスタンスを実行すると行われる。
本方法及び本装置を、複数の代替方法および実施態様の観点から説明してきたが、当業者は、明細書を読んで図面を検討することにより、これらの代替、変更、置換、及び同等物が明らかとなるであろう。
したがって、添付した特許請求の範囲の真の精神及び範囲には、このようなすべての代替、変更、置換、及び同等物が含まれるものとする。
したがって、添付した特許請求の範囲の真の精神及び範囲には、このようなすべての代替、変更、置換、及び同等物が含まれるものとする。
100・・・プロセッサ,
110,120・・・ネットワーク,
105,115・・・ネットワークインターフェース,
130・・・メモリ,
135・・・プロトコルスタック,
140・・・受信送信モジュール,
150・・・アプリケーション,
155・・・カーネルレベルバッファ,
160・・・アプリケーションバッファ,
135A,135B・・・プロトコルスタック,
140・・・受信送信,
150・・・アプリケーション,
175・・・メタデータ,
180・・・データ,
110,120・・・ネットワーク,
105,115・・・ネットワークインターフェース,
130・・・メモリ,
135・・・プロトコルスタック,
140・・・受信送信モジュール,
150・・・アプリケーション,
155・・・カーネルレベルバッファ,
160・・・アプリケーションバッファ,
135A,135B・・・プロトコルスタック,
140・・・受信送信,
150・・・アプリケーション,
175・・・メタデータ,
180・・・データ,
Claims (10)
- カーネルレベルで第1のネットワークから第2のネットワークへデータパケットを渡すための方法であって、
第1のネットワークからデータパケットを受信する(5)ことと、
前記データパケットをカーネル空間バッファに記憶する(10)ことと、
前記データパケットを前記第2のネットワークへ直接渡す必要があるかどうかを判断する(15)ことと、
前記データパケットを前記第2のネットワークへ直接渡す必要がある(15)場合に、前記カーネル空間バッファから前記第2のネットワークへ前記データパケットを送る(20)ことと
を含む方法。 - 前記第1のネットワークからデータパケットを受信することは、
トランスポート層のデータパケットを受信する(25)こと
を含む
請求項1に記載の方法。 - 前記データパケットを前記第2のネットワークへ直接渡す必要があるかどうかを判断することは、
アプリケーション空間で実行されているアプリケーションへ、前記データパケットに紐付けられたメタデータを送る(30)ことと、
アプリケーション空間で実行されている前記アプリケーションから通過インジケータを受信する(35)ことと
を含む請求項1に記載の方法。 - 前記データパケットを前記第2のネットワークへ直接渡す必要がある場合に、前記カーネル空間バッファから前記第2のネットワークへ前記データパケットを送ることは、
アプリケーション空間で実行されているアプリケーションから前記データパケットの変更されたメタデータを受信する(40)ことと、
前記変更されたメタデータを前記データパケットに紐付ける(45)こと、及び、
前記データパケット及び前記の紐付け、変更されたメタデータを前記第2のネットワークへ送る(50)ことと
を含む
請求項1に記載の方法。 - 前記データパケットを前記第2のネットワークへ渡す必要がない(15)場合に、アプリケーション空間で実行されているアプリケーションへ前記データパケットを送る(60)こと
をさらに含む請求項1に記載の方法。 - 1以上のプロセッサ(100)と、
プロセッサ(100)に第1のデータネットワーク(110)と通信させることができる第1のネットワークインターフェース(105)と、
プロセッサ(100)に第2のデータネットワーク(120)と通信させることができる第2のネットワークインターフェース(115)と、
命令シーケンス及びカーネルレベルバッファを記憶することができるメモリ(130)と、
前記メモリに記憶された1つ以上の命令シーケンスであって、
プロトコルスタック(135)であって、前記プロトコルスタックの第1のインスタンスが前記プロセッサによって実行されると、少なくとも、前記プロセッサに、前記第1のネットワークインターフェース(105)からのデータパケットを受信させ、前記プロトコルスタックの第2のインスタンスが前記プロセッサによって実行されると、少なくとも、前記プロセッサに、前記第2のネットワークインターフェース(115)へデータパケットを搬送させる、プロトコルスタックと、
受信送信モジュール(140)であって、前記プロセッサによって実行されると、少なくとも、前記プロセッサに、
カーネルレベルバッファ(155)でデータパケットを受信するために、前記プロトコルスタックの第1の実行インスタンス(135A)からデータパケットを受け取らせ、
前記データパケットを前記第2のデータネットワーク(120)へ渡す必要がある場合に、前記カーネルレベルバッファ(155)から前記プロトコルスタックの第2の実行インスタンス(135B)へ前記データパケットを送らせる
送受信モジュール
を含む1つ以上の命令シーケンスと
を備えるネットワークプロセッサ。 - 前記プロトコルスタック(135)は、前記プロセッサ(100)によって実行されると、少なくとも、前記プロセッサ(100)にトランスポート層のデータパケットを受信させる(25)ことによって、前記プロセッサ(100)にデータパケットを受信させる
請求項6に記載のネットワークプロセッサ。 - 前記受信送信モジュール(140)は、前記プロセッサ(100)によって実行されると、少なくとも、前記プロセッサに、
前記カーネルレベルバッファ(155)に記憶された前記データパケットからメタデータ(175)を取り出させ、
アプリケーション空間で実行されているアプリケーション(150)へ前記取り出されたメタデータ(205)を送らせ、
アプリケーション空間で実行されている前記アプリケーション(150)から通過信号を受信させ、
前記データパケットが前記第2のネットワークインターフェース(115)へ渡されることになっていることを前記通過信号が示す場合に、前記データパケットを前記第2のネットワークインターフェース(115)へ送らせる
ことによって、前記プロセッサ(100)に、前記カーネルレベルバッファ(155)から前記プロトコルスタックの第2の実行インスタンス(135B)へ前記データパケットを送らせる
請求項6に記載のネットワークプロセッサ。 - 前記送受信モジュール(140)は、前記プロセッサ(100)によって実行されると、少なくとも、前記プロセッサ(100)に、
アプリケーション空間で実行されているアプリケーション(150)から、前記データパケットの変更されたメタデータ(225)をカーネルレベルバッファ(155)に受信させ、
前記データパケット及び前記変更されたメタデータ(225)を前記第2のネットワークインターフェース(115)へ送らせる
ことによって、前記プロセッサ(100)に、前記カーネルレベルバッファ(155)から前記プロトコルスタックの第2の実行インスタンス(135B)へ前記データパケットを送らせる
請求項6に記載のネットワークプロセッサ。 - 前記データパケットを前記第2のネットワークインターフェース(115)へ送る必要がない場合に、前記送受信モジュール(140)は、前記プロセッサ(100)によって実行されると、前記プロセッサ(100)に、少なくとも、アプリケーション空間で実行されているアプリケーション(150)へ前記カーネルレベルバッファ(155)に対する参照を提供させる
請求項6に記載のネットワークプロセッサ。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/970,479 US20060085557A1 (en) | 2004-10-20 | 2004-10-20 | Method and apparatus for kernel-level passing of a data packet from a first data network to a second data network |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006121699A true JP2006121699A (ja) | 2006-05-11 |
Family
ID=36182123
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005305147A Withdrawn JP2006121699A (ja) | 2004-10-20 | 2005-10-20 | 第1のデータネットワークから第2のデータネットワークへのデータパケットのカーネルレベルの通過のための方法及び装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US20060085557A1 (ja) |
JP (1) | JP2006121699A (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8874780B2 (en) * | 2006-07-17 | 2014-10-28 | Qualcomm Incorporated | Data buffering and notification system and methods thereof |
US7647522B2 (en) * | 2006-09-28 | 2010-01-12 | Microsoft Corporation | Operating system with corrective action service and isolation |
US10348652B2 (en) * | 2017-01-28 | 2019-07-09 | Juniper Networks, Inc. | Systems and methods for propagating metadata of in-flight packets within kernel space |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6584535B1 (en) * | 2000-01-31 | 2003-06-24 | Cisco Technology, Inc. | Configurable serial interconnection |
US20020154635A1 (en) * | 2001-04-23 | 2002-10-24 | Sun Microsystems, Inc. | System and method for extending private networks onto public infrastructure using supernets |
US20030033418A1 (en) * | 2001-07-19 | 2003-02-13 | Young Bruce Fitzgerald | Method of implementing and configuring an MGCP application layer gateway |
EP1563389A4 (en) * | 2001-08-01 | 2008-06-25 | Actona Technologies Ltd | VIRTUAL DATA DISTRIBUTION NETWORK |
US20030110379A1 (en) * | 2001-12-07 | 2003-06-12 | Tatu Ylonen | Application gateway system, and method for maintaining security in a packet-switched information network |
US7254562B2 (en) * | 2002-07-11 | 2007-08-07 | Hewlett-Packard Development Company, L.P. | Rule-based packet selection, storage, and access method and system |
US20040111728A1 (en) * | 2002-12-05 | 2004-06-10 | Schwalm Brian E. | Method and system for managing metadata |
US7613813B2 (en) * | 2004-09-10 | 2009-11-03 | Cavium Networks, Inc. | Method and apparatus for reducing host overhead in a socket server implementation |
-
2004
- 2004-10-20 US US10/970,479 patent/US20060085557A1/en not_active Abandoned
-
2005
- 2005-10-20 JP JP2005305147A patent/JP2006121699A/ja not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
US20060085557A1 (en) | 2006-04-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7502826B2 (en) | Atomic operations | |
CN111034160B (zh) | 在负载均衡连接上具有虚拟vip和源代理的非dsr分布式负载均衡器 | |
US20110134928A1 (en) | Transmitting a packet | |
US7451197B2 (en) | Method, system, and article of manufacture for network protocols | |
US20040049603A1 (en) | iSCSI driver to adapter interface protocol | |
US6487619B1 (en) | Multiprocessor system that communicates through an internal bus using a network protocol | |
CN1667601A (zh) | 在逻辑分区之间共享网络i/o适配器的装置与方法 | |
US12021952B2 (en) | Application based egress interface selection | |
JP2004350188A (ja) | データ転送装置及びプログラム | |
US8819242B2 (en) | Method and system to transfer data utilizing cut-through sockets | |
US6742075B1 (en) | Arrangement for instigating work in a channel adapter based on received address information and stored context information | |
US7159111B1 (en) | Isolation of communication contexts to facilitate communication of data | |
JP2011507065A (ja) | 制御パス入出力仮想化方法 | |
US20070168536A1 (en) | Network protocol stack isolation | |
US20060206453A1 (en) | Dynamically Sizing Buffers to Optimal Size in Network Layers When Supporting Data Transfers Related to Database Applications | |
KR100834431B1 (ko) | 개시자에 의한 iSCSI 데이터 이동 기능의 RNIC기반 오프로드 | |
US8509235B2 (en) | Layer-2 packet return in proxy-router communication protocol environments | |
JP2006121699A (ja) | 第1のデータネットワークから第2のデータネットワークへのデータパケットのカーネルレベルの通過のための方法及び装置 | |
CN114827151B (zh) | 一种异构服务器集群以及数据转发方法、装置和设备 | |
US10742776B1 (en) | Accelerating isochronous endpoints of redirected USB devices | |
CN115361443B (zh) | 一种报文处理方法及系统 | |
US7672299B2 (en) | Network interface card virtualization based on hardware resources and software rings | |
US7616653B1 (en) | Network interface card aggregation framework | |
KR20230003490A (ko) | 오케스트레이션된 프록시 서비스 | |
US8732264B2 (en) | HiperSockets SIGA light-sending without outbound queue |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20061221 |