JP7811209B2 - ネクストホップｍａｃアドレスのプログラムによる決定 - Google Patents

Description

本出願は、２０２０年１１月９日に出願された米国仮特許出願第６３／１１１，４８７号について優先権を主張し、それらの全体が参照により本明細書に組み込まれる。

本出願は、一般に、ネットワークを介してデータパケットをルーティングすること、及びそのようなパケットを加速的にルーティングすることに関する。

一般的なネットワーク環境では、クライアントデバイスは、ネットワークサーバに記憶されるコンテンツを要求してダウンロードする。要求は、ルーター、ゲートウェイ、及び、要求をネットワーク経由でパケットとしてネットワークサーバに送信するその他のネットワークインフラストラクチャデバイスを使用してネットワークサーバに送信される。コンテンツ要求を受信すると、ネットワークサーバは通常、要求されたコンテンツを取得し、要求されたコンテンツをパケットに分割し、要求元のクライアントデバイスにパケットを送信する。ルーター、ゲートウェイ、及びその他のネットワークインフラストラクチャは、これらのパケットをネットワーク経由でクライアントデバイスに送信する。クライアントデバイスは、順番に、パケットからコンテンツを再構築し、クライアントデバイス上のアプリケーションを介してコンテンツをユーザーに提示する。

様々なデバイス間のデータの交換は、一連の通信プロトコルに従って実行され得る。通信プロトコルは、デバイス間の通信の構文、セマンティクス、及び同期を定義する一連のルールであり、ハードウェア及び／またはソフトウェアとして実装され得る。プロトコル設計では、プロトコルを階層化してプロトコルスタックを形成し、各層は通信の問題のクラスを解決するために提供される。例示的なプロトコルスタックは、インターネットプロトコルスイート（例えば、ＴＣＰ／ＩＰプロトコルスイート）、インターネットモデル、ＴＣＰ／ＩＰ５層参照モデル、ＴＣＰ／ＩＰモデル、アーパネット参照モデル、開放型システム間相互接続モデル（ＯＳＩモデル）などのネットワークスタックを含むが、これらに限定されない。ネットワークスタックのもう１つの例は、ＯＳＩモデルと同様に、７層のスタックであるＬｉｎｕｘ（登録商標）オペレーティングシステムに含まれるネットワークスタックである。Ｌｉｎｕｘ（登録商標）ネットワークスタックは、アプリケーション層（例えば、第７層）、システムコールインタフェース層（例えば、第６層）、プロトコル非依存インタフェース層（例えば、第５層）、ネットワークプロトコル層（例えば、第４層）、デバイス非依存層（例えば、第３層）、デバイスドライバ層（例えば、第２層）、及び物理ハードウェア層（例えば、第１層）である。アプリケーション層は、ユーザー空間を定義してもよく、第２層～第６層はカーネルで実装されてもよい。

図１は、データグラムパケット（ＵＤＰ）１２０を構築し、ネットワークスタック１３０を介して（トラバースして）送信するソフトウェアアプリケーション１１０を示す概略的な例示的なフローを示している。アプリケーションは、コンピューティングデバイス（例えば、図５のコンピューティングデバイス５００）にインストールされ得、カーネル１４０を含むオペレーティングシステム（例えば、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、ｍａｃＯＳ（登録商標））の下で実行され得る。ソフトウェアアプリケーション１１０は、ソケットアプリケーションプログラミングインタフェース（ＡＰＩ）（例えば、第５層）を使用してシステムコール（例えば、ネットワークスタック１３０の第６層）を行うように構成され得る。アプリケーション１１０は、第７層に情報を提供し、第３層及び第４層で必要とされる情報（例えば、宛先インターネットプロトコル（ＩＰ）及び宛先ＵＤＰポート）を提供することもできる。カーネル１４０と連携するネットワークスタック１３０は、残りの情報を提供して第２層～第４層にポピュレートするために実装され得る。

ステップ１で、アプリケーション層にあるアプリケーション１１０は、ＵＤＰ１２０を送信するためのソケットを作成する。例えば、アプリケーション１１０は、データに対する要求を含むペイロードを生成し、プロトコルヘッダに宛先（ＤＳＴ）ＩＰアドレス及びＤＳＴポート（緑色で示される）をポピュレートする。残りのプロトコルヘッダは、通常、１５０内のネットワークスタックの１つ以上の層を介して、カーネル１４０によってポピュレートされる。アプリケーションは、ソケットＡＰＩを介して、例えばシステムコールインタフェース層を介してカーネル１４０に対して要求を行う。ネットワークスタックの残りの層は、ルーティングルール（ネットワークルール、セキュリティ、またはファイアウォール対策など）に基づいてプロトコルヘッダを解決し、プロトコルヘッダにソース（ＳＲＣ）ＭＡＣアドレス、ＳＲＣ ＩＰアドレス、ＳＲＣポート（ステップ２で緑色で示される）をポピュレートするように構成される。しかしながら、ＤＳＴ ＭＡＣアドレス（例えば、第２層の宛先アドレス）は、ネットワークスタックの第２層（例えば、デバイスドライバ層）によって、解決手順プロトコルを通じて決定される。解決手順１６０は、コメント要求（ＲＦＣ）標準、例えば、ＲＦＣ６７４７、ＲＦＣ８２６、ＲＦＣ６５７５に基づいて実装され得る。例示的な解決手順１６０は、ネットワークルールに基づくＤＳＴ ＩＰアドレスに従って第２層の宛先アドレスを記憶するアドレス解決プロトコル（ＡＲＰ）データベース１６２（例えば、キャッシュまたは他の一時的データ記憶媒体）にアクセスすることを含み得る。例えば、ＡＲＰデータベース１６２は、データパケットをＤＳＴ ＩＰアドレスに送信するために使用されるネクストホップ宛先アドレス（例えば、スイッチ要素、ルーター、ゲートウェイなど）のＤＳＴ ＭＡＣアドレスを記憶する。ネクストホップＭＡＣアドレスは、ネットワークルール、セキュリティ対策、及び／またはファイアウォール対策などのルーティングルールを説明する所定のルールセットに基づいて定義され得る。これらのルールは、ネットワーク／システム管理者によって事前に定義され得る。ＤＳＴ ＭＡＣアドレスがＤＳＴ ＩＰアドレスのＡＲＰデータベースにある場合、ネットワークスタックの第２層は、解決されたＤＳＴ宛先アドレス（例えば、ＤＳＴ ＭＡＣアドレス）を第２層のプロトコルヘッダにポピュレートする。そうでない場合、第２層は、ＤＳＴ ＩＰアドレス及び定位置にあり得るネットワーク管理者ルールに基づいてＡＲＰ要求パケットを送信することを含むＡＲＰ解決交換１６４を実行する。宛先デバイスは、ＤＳＴ宛先アドレスを含むＡＲＰ応答パケットでＡＲＰ要求に応答する。次に、第２層は、第２層のプロトコルヘッダにＤＳＴ宛先アドレスをポピュレートし、後続の手順で使用するためにＤＳＴ宛先アドレスをＡＲＰデータベースに保存する。ステップ３で、ＵＤＰ１２０は、（緑色で示すように）各プロトコルヘッダがポピュレートされた状態で完成し、ＵＤＰ１２０は、物理層によるネットワークを介した送信（本明細書ではＮＩＣまたはＮＩＣ ＴＸと呼ばれてもよい）のためにネットワークインタフェースコントローラ（ＮＩＣ）に提供される。

ネットワークでは、ネットワークへのデータ交換速度（アップロード速度及び／またはダウンロード速度など）に影響を与える様々な問題が発生する可能性がある。これらの問題には、各プロトコルヘッダをポピュレートするのに時間がかかる、またはデータのアップロード速度及び／またはダウンロード速度を低下させる大量の要求が含まれる。伝送速度を上げて待ち時間を短縮するために、ネットワーク全体のデバイス（例えば、クライアントデバイス、ネットワークサーバ、及び／またはクライアントデバイスとサーバの間に配置されたルーター及びゲートウェイなどの中間ネットワークデバイス）によって、ネットワークアクセラレーション技術が採用され得る。これらのネットワークアクセラレーション技術は、ソフトウェア及び／またはハードウェアとして実装され得、クライアントデバイスとネットワークサーバとの間のデータフローの速度を向上させるために使用される。これらの技術は、上記の問題、またはデータ交換速度に悪影響を与えるその他の問題に対処できる。

例示的なネットワークアクセラレーション技術は、クライアントデバイスにインストールされ、ネットワークスタックをバイパスするように構成されたソフトウェアアプリケーションを提供することである。アプリケーションは、アプリケーション層でプロトコルヘッダをポピュレートするように構成されるため、ネットワークへのパケットフローを直接管理する。つまり、アプリケーション内の命令を実行して、１つ以上のプロトコルヘッダにプログラムでポピュレートすることができる。ネットワークアクセラレーションアプリケーションの例には、データプレーン開発キット（ＤＰＤＫ）、ＰＦＲＩＮＧ＿ＺＣ、及びＮＥＴＭＡＰが含まれる。

図２は、ネットワークアクセラレーションアプリケーションの概略流れ図を示す。図１と同様に、図２は、オペレーティングシステムに含まれるアプリケーション２１０及びネットワークスタック１３０を示す。ネットワークスタック１３０は、図１のネットワークスタック１３０と同一または実質的に同様であり得る。しかしながら、アプリケーション層にあるアプリケーション２１０は、図１で上述したようにカーネル１４０によって制御されるのではなく、ＮＩＣを直接制御するように構成される。この変更により、アプリケーション２１０は、ネットワークスタック１３０をバイパスし、加速された速度でネットワークを介してパケットを直接送信することができる。

ネットワークスタック１３０をバイパスする（「カーネルバイパス」とも呼ばれる）結果として、アプリケーション２１０は、ネットワークを介して送信するために各パケット（例えば、ＵＤＰ２２０）のプロトコルヘッダをポピュレートする必要がある。ただし、第２／３層の交換ネットワークに参加するためには、多くのネットワークプロトコル、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）、及び第２及び３のプロトコルヘッダを適切にポピュレートするためにアプリケーションが実装する必要のある標準が存在するため、課題が現れる。アプローチの一例は、パケット処理を高速化するためのライブラリを提供するＤＰＤＫを使用することであり、これにより、（図１のオレンジ色及び図２の緑色で示されるように）ＳＲＣ ＭＡＣアドレス、ＳＲＳ ＩＰアドレス、及びＳＲＣポートのポピュレートが容易になる。ＤＰＤＫが使用するアプローチの一例は、仮想ネットワークインタフェースコントローラ（ＶＮＩＣ）を使用して、現在アプリケーションによって制御されるＮＩＣにカーネル内のインタフェースを提供することである。ＤＰＤＫは、Ｌｉｎｕｘ（登録商標）などのネットワークスタックに統合されたネットワークインタフェースを有効にするために、ＶＮＩＣコンセプト（ＫＮＩ）を提供する。したがって、ＶＮＩＣを実装することにより、アプリケーションによって制御される物理／実際のＮＩＣにパケットを送信するためのカーネル用のインタフェースが提供される。したがって、アプリケーション２１０は、ネットワーク機能（例えば、ＡＲＰ解決、ＤＮＳ、ＰＩＮＧ／ＩＣＭＰなど）に参加することができる。これらのネットワーク機能は、ネットワークに参加しているノードが実行する必要がある手順である。例えば、サーバが「ｐｉｎｇ」パケット（ＩＣＭＰの一種）を受信した場合、サーバは、あらかじめ決められた予想されるコンテンツを含む特定のタイプのパケットで応答する必要がある。ＡＲＰ解決は、ネットワーク機能／手順の別の例である。これらの様々なタイプの機能に対するこれらの手順は、様々なＲＦＣで定義されるが、システム管理者のポリシーの影響も受ける（例えば、システム管理者は、サーバがＩＣＭＰ（ｐｉｎｇパケット）に応答するのを制限するポリシーを有効にすることができる）。仮想ＮＩＣのさらなる例には、ＴＵＮ／ＴＡＰ仮想ＮＩＣが含まれるが、これらに限定されない。本明細書の実施形態は、列挙されたＮＩＣに限定されないが、アプリケーション２１０によって直接制御されることにより、ネットワークスタック１３０の他の層をバイパスすることができる任意のＮＩＣ（仮想または非仮想）を包む。

ただし、パケットごとにネットワークスタック機能を再実装する（したがって毎回ホイールを再発明する）ことなく、スイッチドネットワーク及びルーティングネットワークで行われるように、ソフトウェア実装を介して宛先ＭＡＣアドレスをプログラムで決定する方法はない。したがって、ファストパス（例えば、ネットワークパスバイパス）の場合、アプリケーション２１０は、上で概説したようにカーネルのインタフェースを提供する上記ＶＮＩＣを利用する場合でも、オペレーティングシステムによって実行されるネットワーク機能の設備がなければ、第２層の宛先ＭＡＣアドレス（例えば、ネクストホップＭＡＣアドレス）を決定することができない。

例えば、Ｌｉｎｕｘ（登録商標）では、ネットワークスタックには、第２層の宛先アドレスが何であるべきかをプログラムでクエリするためのＡＰＩがない。したがって、アプリケーション２１０は、このアドレスをクエリすることができず、その代わりに、図１に概説されるようにネットワークスタックを介して処理を進めなければならない。言い換えれば、ＫＮＩ／仮想インタフェースと、あらゆる種類のネットワークスタックＡＰＩ呼び出しを介してバイパスするネットワークスタックとを統合する方法はない。したがって、Ｌｉｎｕｘ（登録商標）でＡＲＰ要求を求める唯一の方法は、ソケットを作成し、図１に関連して前述したプロセスに従ってＩＰパケットの送信を要求することである。これにより、ＡＲＰ解決１６０（図１）が（必要に応じて）発生する。

そのようなＡＰＩが（Ｗｉｎｄｏｗｓ（登録商標）のように）オペレーティングシステムに存在する場合でも、ＡＰＩはＡＲＰを要求する必要があるか否かに対処しない。これは、ネットワーク／システム管理者によって様々なネットワークルール、セキュリティ、またはファイアウォール対策が講じられている可能性があり、その結果、異なる応答が生じる可能性があるためである。したがって、アプリケーションが宛先ＭＡＣアドレスを「ハードコーディング」するかまたは何らかの方法で事前ポピュレートすることを決定した場合、ネットワーク／システム管理者によって講じられる可能性のあるセキュリティまたはファイアウォール対策（ネットワークスタックがネットワークルールに基づいて適用するもの）を効果的にバイパスする。

以下の概要は、本発明のすべての態様を定義することを意図するものではなく、本開示の他の特徴及び利点は、図面を含む以下の詳細な説明から明らかになるであろう。本開示は、統合文書として関連付けられることを意図しており、特徴の組み合わせが本開示の同じ文またはパラグラフまたは節内に一緒に見出されない場合でさえ、本明細書に記載される特徴の全ての組み合わせが想定されることを理解すべきである。さらに、本開示は、追加の態様として、本明細書で具体的に言及された変形よりも何らかの点で範囲が狭い本発明のすべての実施形態を含む。

したがって、本明細書で開示される実施形態は、ネットワークアクセラレーションアプリケーションによって使用されて、加速されたネットワーキング技術を使用して送信されるデータパケットをポピュレートすることができる第２層の宛先アドレスを決定できるシステム、メディア、及び方法を提供することによって、これらの問題に対処する。本明細書で記載される様々な実施形態は、加速されたネットワークを提供するためにＮＩＣインタフェースを制御するコンピューティングデバイス上で実行されるソフトウェアアプリケーションを提供する。ソフトウェアアプリケーションは、ネットワークスタックのアプリケーション層に存在し、仮想ＮＩＣまたはＴＵＮ／ＴＡＰデバイスを介して、カーネル、ネットワークスタック、及びオペレーティングシステム（ＯＳ）機能とインタフェース接続され、加速されたネットワークアプリケーションで使用する第２層の宛先アドレスを決定する。本明細書の実施形態は、上記の組み合わせにより、ファイアウォールルール、静的ＡＲＰエントリ、またはネットワーク操作のために定位置に配置された他のシステム管理者ルールを説明することができる。例えば、仮想ＮＩＣまたはＴＵＮ／ＴＡＰデバイスを介してカーネルとネットワークスタック及びＯＳ機能とインタフェース接続されるソフトウェアアプリケーションによって制御される仮想ＮＩＣインタフェース（ＤＰＤＫのＫＮＩ、ＴＵＮ／ＴＡＰ仮想ＮＩＣ、ｉｐｔａｂｌｅｓまたはｎｅｔｆｉｌｔｅｒによって提供されるポストルーティングルールなど）は、ネクストホップＭＡＣアドレスを決定し、解決されたＭＡＣアドレスをデータベースに記憶し、記憶されたＭＡＣアドレスを使用してデータパケットの第２層のヘッダをポピュレートし、後続のパケットの伝送を高速化する。

実施形態は、プロトコルスタックを有するカーネルを有するシステム内のアプリケーション層にあるアプリケーションによって、ネットワーク内で送信されるパケットの少なくとも１つのネクストホップｍａｃアドレスをプログラムで決定することによって、パケットの送信を加速する方法を含む。このような方法は、プロトコルヘッダを有するファントムデータグラム（ＵＤＰ）を作成することと、ネクストホップＭＡＣアドレスヘッダを未ポピュレートのままにして、ファントムＵＤＰの１つ以上のプロトコルヘッダをポピュレートすることと、プロトコルスタックをトラバースするために、ファントムＵＤＰをカーネルにサブミットすることと、カーネルによってネクストホップＭＡＣアドレスヘッダがポピュレートされた状態でファントムＵＤＰをカーネルから受信することと、１つ以上の所定の特性に基づいてファントムＵＤＰを認識することと、ファントムＵＤＰからのネクストホップＭＡＣアドレスヘッダを記憶することと、ファントムＵＤＰを送信しないこととを含む。

このような方法は、また、次のＵＤＰを作成することと、記憶されたネクストホップＭＡＣアドレスを取得することと、取得したネクストホップＭＡＣアドレスを次のＵＤＰのヘッダにポピュレートすることとを含む。

さらに、カーネルのプロトコルスタックは、ルーティングルールを説明する所定のルールセットに基づいてネクストホップＭＡＣアドレスヘッダを決定し、所定のルールセットは、ネットワークルール、セキュリティ対策、ファイアウォール対策の１つ以上を説明する。

さらに、アプリケーションがＮＩＣを制御し、そのような方法は、さらに、ＮＩＣに、ファントムＵＤＰをドロップするように指示することができる。そのような方法は、さらにカーネルをバイパスし、記憶されたネクストホップＭＡＣアドレスヘッダを次のＵＤＰにポピュレートして次のＵＤＰをＮＩＣに提供することができる。

さらに、そのような方法は、バインド呼び出し及びカーネルとの接続呼び出しを使用してソケットを作成し、カーネルによってポピュレートされたファントムＵＤＰからソースＩＰとソース宛先を取得して記憶し、次のＵＤＰのヘッダに、記憶されたソースＩＰ及びソース宛先をポピュレートする。

実施形態は、また、カーネルを有するシステム内のアプリケーション層にあるアプリケーションによってネットワーク内で送信されるパケットの少なくとも１つの第２層の宛先アドレスをプログラムで決定する方法を含む。そのような方法は、ファントムパケットを作成し、第２層の宛先アドレスを未ポピュレートのままにして、ファントムパケットのプロトコルヘッダの１つ以上をポピュレートし、ファントムパケットをカーネルにサブミットし、カーネルによって第２層の宛先アドレスヘッダがポピュレートされた状態でファントムパケットをカーネルから受信し、ファントムパケットを認識し、ファントムパケットからの第２層の宛先アドレスを記憶し、次のパケットを作成し、次のパケットのヘッダに、記憶された第２層の宛先アドレスをポピュレートすることにより動作する。

実施形態は、さらに、第２層の宛先アドレスをプログラムで決定することによって、ネットワークを介してパケットの伝送を加速するシステムを含む。そのようなシステムは、少なくとも１つのプロセッサと、少なくとも１つのプロセッサと通信し、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに上記方法のうちの１つ以上を実行させる命令を記憶するメモリとを含む。

本開示の実施形態の詳細は、それらの構造及び動作の両方に関して、添付の図面を検討することによって部分的に収集することができ、図面において、同様の参照番号は同様の部品及びまたは機能を指す。

ネットワークスタックを介してデータグラムパケット（ＵＤＰ）を構築及び送信するためのソフトウェアアプリケーションの概略機能流れ図を示す。 ネットワークアクセラレーションアプリケーションの概略機能流れ図を示す。 ネットワークアクセラレーションアプリケーションの概略機能流れ図を示す。 ネットワークアクセラレーションアプリケーションの概略機能流れ図を示す。 本明細書で開示される実施形態に係る、開示されるシステム、方法、及び媒体の実施形態が動作し得るインフラストラクチャの機能ブロック図である。 本明細書で説明される様々な実施形態に関連して使用され得る有線または無線処理システムの例を示す機能ブロック図である。

図３Ａ及び３Ｂは、本明細書で開示される実施形態に従って第２層のＤＳＴアドレスを決定するように構成されたネットワークアクセラレーションアプリケーション３１０の概略機能流れ図を示す。図２と同様に、図３は、オペレーティングシステムに含まれるアプリケーション３１０及びネットワークスタック１３０を示す。ネットワークスタック１３０は、図１のネットワークスタック１３０と実質的に同様であり得る。アプリケーション３１０は、ネットワークスタック１３０のアプリケーション層に存在し、データパケット交換を加速するためにＮＩＣを直接制御するように構成される（ＮＩＣは、例示的にアプリケーション３１０内に示される）点で、図２のアプリケーション２１０と同様であり得る。したがって、アプリケーション２１０と同様に、アプリケーション３１０は、カーネル１４０及びそれによって実装されるネットワークスタックの層をバイパスして、データパケットを直接送信することができる。

アプリケーション３１０は、また、パケットの加速送信で使用するための第２層のＤＳＴアドレスを決定するように構成される。例えば、アプリケーション３１０は、カーネル１４０及びネットワークスタック１３０を活用して第２層のＤＳＴアドレスを決定し、第２層のＤＳＴアドレスをＡＲＰデータベース３６２（例えば、ＡＲＰキャッシュまたは他の一時データ記憶媒体）に記憶するように構成される。次に、第２層のＤＳＴアドレスは、（図３Ｂに示されるように）、アプリケーション３１０によってプログラムで取得され、加速されたＵＤＰ４２０の第２層のヘッダをプログラムでポピュレートするために使用され得る。ＵＤＰ４２０は、両方のＵＤＰが、それぞれのアプリケーションによって直接制御及び送信される加速されたパケットであるという点で、図２のＵＤＰ２２０と実質的に同様であり得る。

例えば、ステップ１（大きな数字１で示される）で、アプリケーション３１０は、ファントムＵＤＰ３２０などのファントムパケットを作成するように構成され、作成する。一実施形態では、ファントムＵＤＰ３２０のペイロードに一意認識子（ＵＩＤ）がポピュレートされる。ＵＩＤは、ファントムＵＤＰ３２０を一意に認識できる任意のグローバル一意認識子（ＧＵＩＤ）であり得る。例えば、いくつかの実施形態では、ＵＩＤは６４ビットの擬似ランダム値であってもよい。ただし、ＵＩＤは、任意のビット長であり得、オペレータの所望に応じて擬似ランダム、ランダム、または非ランダムであり得る。または、アプリケーション３１０がファントムＵＤＰ３２０を認識するための他の方法を使用することができる。例えば、アプリケーション３１０が加速されたパケットのみを送信している場合、カーネルからのＵＤＰはすべてファントムＵＤＰでなければならない。さらに別の例として、ファントムＵＤＰのヘッダのソースＩＰを事前定義されたアドレスに設定する。より一般的には、ファントムＵＤＰ３２０を示すものとしてアプリケーション３１０に知られている任意の基準または基準のセットを使用することができる。

ファントムＵＤＰ３２０は、ネットワークを介した伝送用の加速されたＵＤＰ（例えば、ＵＤＰ２２０及び／またはＵＤＰ４２０）を作成する前に、第２層のＤＳＴアドレスを解決するために使用される。アプリケーション３１０は、図２に関連して上述したように、１つ以上のプロトコルヘッダをポピュレートすることができる。または、ファントムＵＤＰ３２０の１つ以上のプロトコルヘッダが未ポピュレートのままになる。特に、第２層のヘッダ３２４がプログラムで決定することができないため、ヘッダ３２４はポピュレートされない。図３Ａは、アプリケーション３１０がヘッダ３２４（太字で示されるＤＳＴ ＭＡＣ）を除くすべてのヘッダをポピュレートしたことを示す。ファントムＵＤＰ３２０が作成されると、それは、図１に関連して上述したように、カーネル１４０にソケット接続されるかまたは提出される。

ステップ２（大きな数字２で示される）では、アプリケーション層でアプリケーション３１０によってポピュレートされなかった任意のプロトコルヘッダが解決され、例えば、図１に関連して上述したように、カーネル１４０によってポピュレートされる。具体的には、第２層のヘッダ３２４がポピュレートされないため、カーネル内の層１５０（例えば、ネットワークスタック１３０のデバイスドライバ層または第２層）が第２層のＤＳＴアドレスを解決する。例えば、ネットワークスタック１３０の第２層は、解決プロセス３６０を実行し、これは、上述した解決プロセス１６０と同一または実質的に同様であり得る。ファントムＵＤＰ３２０はネットワークスタック１３０をトラバースするため、任意のセキュリティ対策、ファイアウォール対策、及び／またはルーティングルールが、ネットワークスタックによってポピュレートされた情報に適用される。したがって、ファントムＵＤＰ３２０は、そのような手段を考慮し、定位置にあるセキュリティプロトコルを回避しない。

例えば、解決手順３６０は、ネットワークルールに従ってＤＳＴ ＩＰアドレスに従って第２層の宛先アドレスを記憶するアドレス解決プロトコル（ＡＲＰ）データベース３６２（例えば、キャッシュまたは他の一時データ記憶媒体）にアクセスすることを含み得る。例えば、ＡＲＰデータベース３６２は、データパケットをＤＳＴ ＩＰアドレスに送信するために使用されるネクストホップ宛先アドレス（例えば、スイッチ要素、ルーター、ゲートウェイなど）のＤＳＴ ＭＡＣアドレスを記憶する。ネクストホップＭＡＣアドレスは、ネットワークルール、セキュリティ対策、及び／またはファイアウォール対策などのルーティングルールを説明する所定のルールセットに基づくものであり得る。これらのルールは、ネットワーク／システム管理者によって事前に定義され得る。ＤＳＴ ＭＡＣアドレスは、ファントムＵＤＰ３２０にポピュレートされたＤＳＴ ＩＰアドレスのＡＰＰデータベース３６２にある場合、ネットワークスタック１３０は、解決されたＤＳＴ ＭＡＣアドレスを第２層のプロトコルヘッダにポピュレートする。そうでなければ、ＡＲＰ解決交換３６４（交換１６４と同様であり得る）が実行される。交換１６４と同様に、ＡＲＰ解決交換３６４は、定位置にあるＤＳＴ ＩＰアドレス及びネットワーク管理者ルールに基づいてＡＲＰ要求パケットを送信するネットワークスタックの第２層を含む。宛先デバイスは、ネクストホップ宛先デバイスのＤＳＴ ＭＡＣアドレスを含むＡＲＰ応答パケットでＡＲＰ要求に応答する。ステップ３で、ネットワークスタック（例えば、デバイスドライバ層または第２層）は、第２層のプロトコルヘッダ３２４にＤＳＴ ＭＡＣアドレスをポピュレートする。

ステップ３（大きな数字３で示される）で、ファントムＵＤＰ３２０が仮想ＮＩＣ（例えば、ＮＩＣ ＴＸ）に提供される。仮想ＮＩＣを制御するアプリケーション３１０は、ペイロード３２２内のＵＩＤを認識し、ＵＩＤの認識に基づいてパケットをファントムＵＤＰとして認識するように構成される。アプリケーション３１０は、ペイロードに適用されてＵＩＤを認識し、したがってＵＤＰをファントムＵＤＰとして認識する一連のルールを含み得る。ファントムＵＤＰ３２０が認識されると、アプリケーション３１０は、関連するプロトコルヘッダ情報、例えば、アプリケーションがステップ１で事前ポピュレートできなかった情報を抽出し、抽出された情報をデータストレージデバイス３７０に記憶する。例えば、ステップ４（大きな数字４で示される）で、アプリケーション３１０は、ファントムＵＤＰ３２０の第２層のヘッダ３２４から第２層のＤＳＴアドレスを抽出し、第２層のＤＳＴアドレスをデータストレージデバイス３７０に記憶する。いくつかの実施形態では、データストレージデバイス３７０は、キャッシュメモリまたは他の一時記憶媒体である。

また、ステップ４で、アプリケーション３１０の制御下にある仮想ＮＩＣ及び／または実際のＮＩＣ（一般にＮＩＣと呼ばれる）は、所与のＵＤＰを送信のために物理層に提出するか否かを決定する。例えば、アプリケーション３１０は、ペイロードのＵＩＤに基づいてパケットをファントムＵＤＰ３２０として認識し、仮想ＮＩＣは、ファントムＵＤＰ３２０がネットワークを介して送信されるべきではなく、ドロップされると判断する。

情報がデータストレージデバイス３７０に記憶されると、その情報を使用して、ＵＤＰのプロトコルヘッダにプログラムでポピュレートし、伝送を加速することができる。例えば、図３Ｂに示されるように、アプリケーション３１０は、加速されたＵＤＰ４２０を作成し、データストレージデバイス３７０から関連情報を取得することによって、第２層のヘッダを含む各プロトコルヘッダにポピュレートする。ステップ５におけるＵＤＰ４２０及びアプリケーション３１０（大きな数字５で示される）は、第２層のヘッダもアプリケーション３１０によってポピュレートされることを除いて、図２のＵＤＰ２２０及びアプリケーション２１０と同様であり得る。アプリケーション３１０は、カーネル１４０及びそれによって実装されるネットワークスタック１３０の層を完全にバイパスして、パケットを高いデータレートで連続的に送信することができる。

本明細書で説明する実施形態の非限定的な利点は、アプリケーション３１０が、ネットワーク上でデータパケットを不必要に送信することなく、ネットワーク／システム管理者によってポピュレートされた任意のファイアウォールルール／対策、ＩＰテーブル機能、ＡＲＰ解決手順、または任意の他の構成を利用することによって、ネクストホップＭＡＣアドレスを決定することができる。不要なパケットは、必要か否かにかかわらず、各パケットが送信のためにネットワークリソースを必要とするため、データ交換レート／速度を低下させる。換言すれば、本明細書の実施形態は、ＯＳに存在するＡＰＩの欠点を解消して、ネクストホップＭＡＣアドレスを決定することができる。同様に、ＡＰＩが存在する場合でも、本明細書の実施形態は、ネットワーク／システム管理者によって実装されたセキュリティ対策を説明することができる。

カーネルネットワークスタックを使用する他のアプリケーションと共にある上記ネットワークスタック（カーネル）バイパス（ｄｐｄｋを使用するものなど）は、カーネルバイパスソリューションによって確立された接続が、「通常の」ネットワークスタック接続に干渉しないようにする必要がある。潜在的なコンテンション領域の１つは、ＵＤＰ及びＴＣＰソケットなどのソケット接続で使用される第４層のポートである。以下の例示的な実施形態は、ネットワークスタック（ＢＳＤ及びＬｉｎｕｘなど）がサーバ及びクライアント接続の両方で使用されるポートをどのように予約するか、及びこれがカーネルバイパスソリューションとどのように衝突するかを説明する。この例では、ソケット通信で使用されるポートを「予約」するために使用される方法は、ｂｉｎｄ（）を呼び出すことである。

接続が確立されると、オペレーティングシステムは未使用のソースポート番号を選択する必要がある。例えば、Ｌｉｎｕｘは、デフォルトでは、３２７６８～６１０００（選択できるポート数は２８Ｋである）の範囲に設定されるエフェメラルポート範囲からポートを選択する。Ｌｉｎｕｘでは、エフェメラルポート範囲はグローバルリソースである。実際には、ポート番号は１６ビット長であるため、ポート範囲を可能な選択肢の６４Ｋまで拡張できる。複数の宛先アドレスを使用すると、ほぼ無制限の数の接続を確立することができる。ただし、単一の（宛先ＩＰ、宛先ポート）ペアに対して６４Ｋを超える同時接続（デフォルトのエフェメラルポート範囲で２８Ｋ）を確立すると、失敗する。

ｃｏｎｎｅｃｔ（）を呼び出す前にｂｉｎｄ（）を呼び出すことで、特定のソースＩＰとポートを選択するようカーネルに要求することができる。次に例を示す。
ｓ＝ｓｏｃｋｅｔ．ｓｏｃｋｅｔ（ｓｏｃｋｅｔ．ＡＦ＿ＩＮＥＴ，ｓｏｃｋｅｔ．ＳＯＣＫ＿ＳＴＲＥＡＭ）＃
ソースアドレスを１９２．１６８．１．２１：１２３４とする。
ｓ．ｂｉｎｄ（（“１９２．１６８．１．２１”，１２３４））
ｓ．ｃｏｎｎｅｃｔ（（ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ，８０））

このアプローチは、「ｂｉｎｄ ｂｅｆｏｒｅ ｃｏｎｎｅｃｔ」と呼ばれることがよくある。ポート番号０を指定するということは、カーネルが、要求アプリケーションのポート割り当てを行う必要があることを意味する。次に例を示す。
ｓ＝ｓｏｃｋｅｔ．ｓｏｃｋｅｔ（ｓｏｃｋｅｔ．ＡＦ＿ＩＮＥＴ，ｓｏｃｋｅｔ．ＳＯＣＫ＿ＳＴＲＥＡＭ）
ｓ．ｂｉｎｄ（（“１９２．１６８．１．２１”，０））
ｓ．ｃｏｎｎｅｃｔ（（ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ，８０））

この方法はよく知られているが、キャッチがある。バインドが通常、ソケットをリッスンするために呼び出されるため、カーネルはソースアドレスが他のユーザーと共有されていないことを確認する必要がある。それは問題である。この技術をこの形式で使用する場合、合計で６４ｋ（エフェメラルポート範囲）を超える発信接続を確立することは不可能である。その後、ｂｉｎｄ（）を呼び出そうとすると、ＥＡＤＤＲＩＮＵＳＥエラー、即ち、すべてのソースポートがビジーになることで失敗する。

このキャッチを解消するために、アプリケーションは、ＳＯ＿ＲＥＵＳＥＡＤＤＲ設定を使用することができる。ＳＯ＿ＲＥＵＳＥＡＤＤＲを設定することにより、アプリケーションは、バインドされたポートを他のユーザーと共有する意図をカーネルに通知するが、共有がプロトコル層で競合を引き起こさない場合に限る。

以下は使用例である。
ｓ＝ｓｏｃｋｅｔ．ｓｏｃｋｅｔ（ｓｏｃｋｅｔ．ＡＦ＿ＩＮＥＴ，ｓｏｃｋｅｔ．ＳＯＣＫ＿ＳＴＲＥＡＭ）
ｓ．ｓｅｔｓｏｃｋｏｐｔ（ｓｏｃｋｅｔ．ＳＯＬ＿ＳＯＣＫＥＴ，ｓｏｃｋｅｔ．ＳＯ＿ＲＥＵＳＥＡＤＤＲ，１）
ｓ．ｂｉｎｄ（（ “１９２．１６８．１．２１”，０））
ｓ．ｃｏｎｎｅｃｔ（（ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ，８０））

この例では、カーネルは他のソケットと直接競合しないポートを見つけるが、ＳＯ＿ＲＥＵＳＥＡＤＤＲ設定の欠如とは対照的に、ＴＩＭＥ＿ＷＡＩＴ内のポート及び既に確立された接続によって使用されるポートは再利用され得る。したがって、ＳＯ＿ＲＥＵＳＥＡＤＤＲフラグを設定することにより、選択した１つのＩＰから複数の宛先への６４ｋ（エフェメラルポート範囲）を超える発信接続を有することができる。

しかし、別のキャッチがある。アプリケーションがｂｉｎｄ（）を呼び出すとき、カーネルは、アプリケーションが要求しているソースアドレスしか知らない。アプリケーションは、後でｃｏｎｎｅｃｔ（）を呼び出すときにのみ、宛先アドレスをカーネルに通知する。これは、カーネルが別の接続で既に使用されるソースポートを、アプリケーションが使用したいのと同じ宛先に再利用する可能性があるため、問題を引き起こす可能性がある。そのような場合、ｃｏｎｎｅｃｔ（）はＥＡＤＤＲＮＯＴＡＶＡＩＬエラーで失敗する。

アプリケーションが単一の宛先に対して６４ｋ（エフェメラルポート範囲）を超える接続を確立したいとき、前述のすべてのアプローチを使用する必要がある。
カーネルパラメータを微調整して、エフェメラルポート範囲を広げる。
ｂｉｎｄ ｂｅｆｏｒｅ ｃｏｎｎｅｃｔを使用して、多くのソースＩＰアドレスを手動で指定する。
発信接続にＳＯ＿ＲＥＵＳＥＡＤＤＲフラグを設定する。
カーネルが使用可能なポートを使い果たした場合に備えて、ｂｉｎｄ（）でＥＡＤＤＲＩＮＵＳＥエラーを確認する。
接続の競合がある場合は、ｃｏｎｎｅｃｔ（）でＥＡＤＤＲＮＯＴＡＶＡＩＬエラーを確認し、必要に応じて再試行する。

残念ながら、通常のｃｏｎｎｅｃｔ（）で確立された接続とｂｉｎｄ－ｂｅｆｏｒｅ－ｃｏｎｎｅｃｔで確立された接続はうまく混合されない。ある技術で使用される発信ポートは、別の手法では再利用されない。ｃｏｎｎｅｃｔ（）を使用して６４ｋ接続を確立すると、ｂｉｎｄ（）はＥＡＤＤＲＩＮＵＳＥで失敗する。逆に、何千もの接続がｂｉｎｄ ｂｅｆｏｒｅ ｃｏｎｎｅｃｔを使用している場合、ストレート接続はＥＡＤＤＲＮＯＴＡＶＡＩＬで失敗する可能性がある。

他のアプリケーションがｂｉｎｄ－ｂｅｆｏｒｅ－ｃｏｎｎｅｃｔを使用しないシステムでは、エフェメラルポートを予約する前述のｂｉｎｄ－ｂｅｆｏｒｅ－ｃｏｎｎｅｃｔアプローチは、そのようなアプリケーションと競合する可能性がある。したがって、アプリケーション３１０は、ネットワークスタックを使用して、ソケット接続に対して行う通常のバインド／接続呼び出しを使用してソケットを作成し、上記で説明した方法と同様に、カーネル１４０及びネットワークスタック１５０の層を介してファントムＵＤＰを送信する。アプリケーションは、ファントムＵＤＰのヘッダからソースポートと、必要に応じてソースＩＰを記憶し、それらを後続のカーネルバイパスパケットに使用する。単一のファントムＵＤＰ３２０を使用して、ＤＳＴ ＭＡＣアドレスとソースポート（及び必要に応じてソースＩＰ）を取得するか、別のファントムＵＤＰを使用することができる。

アプリケーションは、上記技術を使用してファントムＵＤＰをＮＩＣに返すときに、そのファントムＵＤＰを認識する。ＮＩＣはファントムＵＤＰをドロップし、送信しない。さらに、アプリケーション３１０は、ポート割り当てを「予約」したままにするために、カーネルバイパスパケット送信の間、ソケットを開いたままにしておく必要がある。たとえば、アプリケーションは、カーネルバイパスパケット送信の期間が終了するまでソケットを閉じない。

本明細書の実施形態は、Ｌｉｎｕｘ（登録商標）ＯＳに含まれるネットワークスタックを参照して説明されるが、実施形態は、Ｌｉｎｕｘ（登録商標）ネットワークスタックに限定されず、他のオペレーティングシステム（例えば、ｍａｃＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）など）に含まれるネットワークスタックに等しく適用可能であり得ることが理解される。さらに、本明細書の実施形態は、また、本明細書に記載の７層のプロトコルスタックに限定されず、インターネットプロトコルスイート（例えば、ＴＣＰ／ＩＰプロトコルスイート）、インターネットモデル、ＴＣＰ／ＩＰ５層参照モデル、ＴＣＰ／ＩＰモデル、アーパネット参照モデル、開放型システム間相互接続モデル（ＯＳＩモデル）など、他のプロトコルスタックにも同様に適用される。

図４は、本明細書で開示される実施形態に係る、開示されるシステム、方法、及び媒体の実施形態が動作し得るインフラストラクチャの機能ブロック図を示す。インフラストラクチャは、アプリケーション（複数可）４１２（例えば、アプリケーション３１０）、データストレージデバイス（複数可）４１４、及びネットワークスタック４１６を備えるクライアントコンピューティングデバイス４１０を含み得る。コンピューティングデバイス４１０は、１つ以上のネットワーク（複数可）４２０を介してデータパケットをコンピューティングデバイス４１０からネットワークサーバ（複数可）４５０及び／または１つ以上のネットワークサーバ（複数可）４５０に送信するために、１つ以上のネットワークノード４３０に通信可能に接続され得る。

コンピューティングデバイス（複数可）４１０及びネットワークサーバ４５０は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、またはその他の携帯電話、サーバ、ゲームコンソール、テレビ、セットトップボックス、電子キオスクを含むが、それらに限定されない有線及び／または無線通信が可能な任意のタイプのコンピューティングデバイスを含み得る。同様に、ノード（複数可）４３０は、有線及び／または無線通信が可能な任意のタイプのコンピューティングデバイスを含み得る。ノード（複数可）４３０は、例えば、データパケットをパケットソースデバイス（例えば、コンピューティングデバイス４１０）から宛先デバイス（例えば、ネットワークサーバ４５０）に、またはその逆にルーティングまたは送信することによって、ネットワーク間のゲートとして機能して、データが１つのコンピューティングデバイスから別のコンピューティングデバイスに流れるためのリンクを形成する任意のハードウェアデバイスとして実装され得る。ノード（複数可）４３０は、ルーター、ファイアウォール、サーバ、ハブ、ゲートウェイ、またはトラフィックがネットワークに出入りすることを可能にする任意のデバイスとして実装され得る。さらに、各ノード４３０は、１つ以上のデバイス及び／または他のノード４３０と通信可能に接続され得る。インフラストラクチャが、任意の数のゲートウェイ（複数可）、デバイス（複数可）、ユーザーシステム（複数可）、プラットフォーム（複数可）、サーバ（複数可）のセット、及びデータベース（複数可）を含み得ることは理解される。コンピューティングデバイス４１０及びネットワークサーバ４５０として実装され得る例示的な有線または無線システムは、図５の有線または無線システム５００として示される。

アプリケーション（複数可）４１２及びネットワークスタック４１６は、命令としてデータストレージデバイス（複数可）４１４に記憶され、ピューティングデバイス４１０によって実行され、そこで機能を実行する。上述のように、ネットワークスタック４１６は、コンピューティングデバイス４１０によって実行されるオペレーティングシステムに含まれるカーネルを含む。ネットワークスタック４１６は、図１～図３Ｂに関連して上述したネットワークスタック４３０と同様であり得る、または任意の他のタイプの通信プロトコルスタックと同様であり得る。アプリケーション（複数可）４１２は、アプリケーション４１０、アプリケーション２１０、及び／またはアプリケーション３１０のうちの１つ以上であり得る。例えば、アプリケーション３１０は、アプリケーション（複数可）４１４の１つとしてコンピューティングデバイス４１０にインストールされ、図３Ａ及び図３Ｂに関連して説明された高データレート伝送用の加速ネットワーキングアプリケーションのために実行され得る。したがって、コンピューティングデバイス４１０は、図３Ａ及び図３Ｂに関連して本明細書で説明したように、ネットワークサーバ（複数可）４５０にデータパケットを送信することができる。

ネットワーク（複数可）４２０は、インターネットを含み得、サーバ（複数可）４５０は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）、ファイル転送プロトコル、ＦＴＰセキュア（ＦＴＰＳ）、ＳＳＨ ＦＴＰ（ＳＦＴＰ）などの標準伝送プロトコル及び独自のプロトコルを使用して、インターネットを介してノード４３０及びコンピューティングデバイス４１０と通信し得る。プラットフォーム４１０は、ネットワーク（複数可）４２０の単一のセットを介して様々なシステムに接続されるように示されるが、プラットフォーム４１０が１つ以上のネットワークの異なるセットを介して様々なシステムに接続され得ることは理解される。

ネットワークサーバ（複数可）４５０は、１つ以上のウェブサイト、ウェブサービス、及び／またはウェブコンテンツをホストするウェブサーバを含み得る。ウェブサイトが提供される実施形態では、ウェブサイトは、例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ）または他の言語（例えば、グラフィックベース及び／またはテキストベースの言語）で生成されたウェブページを含む、１つ以上のユーザインタフェースを含み得る。ネットワークサーバ（複数可）４５０は、コンピューティングデバイス４１０からの要求に応答して、これらのユーザインタフェースを送信または提供する。ネットワークサーバ（複数可）４５０へのデータの要求及び応答は、標準通信プロトコル（例えば、ＨＴＴＰ、ＨＴＴＰＳ）を使用して、インターネットを含み得るネットワーク（複数可）４２０を介して通信され得る。応答及び要求は、通信ノード４３０によって受信され、ルーティングルールに従って通信ノード４３０によってネットワークサーバ４５０にルーティングされ得る。ルーティングルールは、例えば、上述のようにデータパケットのプロトコルヘッダをポピュレートする際に参照され得る。

コンピューティングデバイス４１０は、ネットワークサーバ（複数可）４５０からコンテンツ及びデータを要求し得る。要求は、データパケットの形で送信され得、ネットワーク４２０を介して要求をパケットとして送信するノード（複数可）４３０を使用して、ネットワークサーバ（複数可）４５０に送信される。要求パケットを受信すると、ネットワークサーバ（複数可）は通常、要求されたコンテンツを取得し、要求されたコンテンツをパケットに分割し、要求元のクライアントデバイス４１０にパケットを送信する。ノード４３０（複数可）は、ネットワークを介してこれらのパケットをクライアントデバイス４１０に送信する。

図４に示される構成要素を含み得る例示的なプラットフォームは、Ｃｈａｎｎｅｌｉｚｅｒ（登録商標）、Ｃｏｍｂｉｎｅｒ（登録商標）、ｑｕａｎｔｕｍＲａｄｉｏ（登録商標）、ｑｕａｎｔｕｍＲＸ Ｗｉｄｅｂａｎｄ Ｓｏｆｔｗａｒｅ Ｒｅｃｅｉｖｅｒ（登録商標）、ＤａｔａＤｅｆｅｎｄｅｒ（登録商標）、Ｋｒａｔｏｓ Ｄｅｆｅｎｃｅ＆Ｓｅｃｕｒｉｔｙ Ｓｏｌｕｔｉｏｎｓ，Ｉｎｃ．が提供する同様の製品を含むが、これらに限定されない。このような製品は、本明細書で開示される実施形態を活用することによって、高いデータレート及び小さなパケットサイズの転送を達成するために実装され得る。例えば、本明細書のシステムは、１５００バイトであり得る各パケットの最大伝送単位（ＭＴＵ）を使用して、３Ｇｂｐｓ以上のパケット伝送速度を達成することができる。しかしながら、他の製造業者からの他のプラットフォームも本明細書の実施形態を利用して、小さなパケットサイズで加速されたデータ伝送速度を達成することができることは理解される。

図５は、本明細書で説明される様々な実施形態に関連して使用され得る有線または無線処理システム５００の例を示す機能ブロック図である。例えば、システム５００は、（例えば、１つ以上のソフトウェアモジュールを記憶及び／または実行する）上記機構、プロセス、方法、または機能のうちの１つ以上として、またはこれらと併せて使用され得、コンピューティングデバイス４１０、サーバ（複数可）４５０、通信ノード（複数可）４３０、及び／または本明細書で説明される他のデバイスの構成要素を表し得る。システム５００は、サーバまたは任意の従来のパーソナルコンピュータ、または有線または無線データ通信が可能な任意の他のプロセッサ対応デバイスであり得る。当業者には明らかなように、他のコンピュータシステム及び／またはアーキテクチャも使用することができる。さらに、システム５００が特定の要素で示されるが、それが表す特定の構成要素に応じて、示される要素よりも少ないまたは多い要素を含み得ることは理解される。例えば、無線通信機能のないシステム５００は、ベースバンド５６０、無線機５６５、及びアンテナ５７０を含まない場合がある。

システム５００は、好ましくは、プロセッサ５１０などの１つ以上のプロセッサを含む。入力／出力を管理するための補助プロセッサ、浮動小数点数学的演算を実行する補助プロセッサ、信号処理アルゴリズムの高速実行に適したアーキテクチャを有する専用マイクロプロセッサ（例えば、デジタルシグナルプロセッサ）、メイン処理システムに従属するスレーブプロセッサ（例えば、バックエンドプロセッサ）、デュアルまたはマルチプロセッサシステム用の追加のマイクロプロセッサまたはコントローラ、またはコプロセッサなどの追加のプロセッサは提供され得る。そのような補助プロセッサは、ディスクリートプロセッサであってもよいし、プロセッサ５１０と統合されてもよい。システム５００と共に使用されるプロセッサの例は、Ｐｅｎｔｉｕｍ（登録商標）プロセッサ、Ｃｏｒｅ ｉ７（登録商標）プロセッサ、Ｘｅｏｎ（登録商標）プロセッサ、及びカリフォルニア州サンタクララのＩｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎから入手可能な他のモデル、及びカリフォルニア州サニーベールのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅなどの他の製造業者からのハードウェアプロセッサを含むが、これらに限定されない。

プロセッサ５１０は、通信バス５０５に接続されることが好ましい。通信バス５０５は、ストレージとシステム５００の他の周辺コンポーネントとの間の情報転送を容易にするデータチャネルを含み得る。さらに、通信バス５０５は、データバス、アドレスバス、及び制御バス（図示せず）を含む、プロセッサ５１０との通信に使用される信号のセットを提供することができる。通信バス５０５は、業界標準アーキテクチャ（ＩＳＡ）、拡張業界標準アーキテクチャ（ＥＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＣＡ）、周辺コンポーネント相互接続（ＰＣＩ）ローカルバス、またはＩＥＥＥ ４８８汎用インタフェースバス（ＧＰＩＢ）、ＩＥＥＥ ６９６／Ｓ－１００などを含む電気電子技術者協会（ＩＥＥＥ）によって公布された標準に準拠するバスアーキテクチャなど、任意の標準または非標準バスアーキテクチャを含み得る。

システム５００は、メインメモリ５１５を含むことが好ましく、二次メモリ５２０も含むことができる。メインメモリ５１５は、上記で議論され、少なくとも図１～図３Ｂに示される機能及び／またはモジュールのうちの１つ以上など、プロセッサ５１０上で実行されるプログラムのための命令及びデータの記憶を提供する非一時的なコンピュータ可読媒体である。メモリに記憶され、プロセッサ５１０によって実行されるプログラムが、Ｃ／Ｃ＋＋、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、Ｐｅｒｌ、Ｖｉｓｕａｌ Ｂａｓｉｃ．ＮＥＴ、独自のビジュアルスクリプト言語、独自のスクリプト言語などを含むが、これらに限定されない任意の適切な言語に従って記述及び／またはコンパイルすることができることは理解される。メインメモリ５１５は、通常、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）及び／またはスタティックランダムアクセスメモリ（ＳＲＡＭ）などの半導体ベースのメモリである。他の半導体ベースのメモリタイプは、例えば、読み取り専用リメモリ（ＲＯＭ）を含むシンクロナスダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）、ラムバスダイナミックランダムアクセスメモリ（ＲＤＲＡＭ）、強誘電体ランダムアクセスメモリ（ＦＲＡＭ）などを含む。

二次メモリ５２０は、場合によって、内部メモリ５２５及び／またはリムーバブル媒体５３０、例えば、フロッピーディスクドライブ、磁気テープドライブ、コンパクトディスク（ＣＤ）ドライブ、デジタル多用途ディスク（ＤＶＤ）ドライブ、その他の光学ドライブ、フラッシュメモリドライブ、ｍｉｃｒｏＳＤなどを任意に含むことができる。リムーバブルメディア５３０は、周知の方法で読み取られ、及び／または書き込みされる。リムーバブル記憶媒体５３０は、例えば、フロッピーディスク、磁気テープ、ＣＤ、ＤＶＤ、ＳＤカード、サムドライブなどであってもよい。

リムーバブル記憶媒体５３０は、コンピュータ実行可能コード（すなわち、ソフトウェア）及び／またはデータを記憶した非一時的なコンピュータ可読媒体である。リムーバブル記憶媒体５３０に記憶されたコンピュータソフトウェアまたはデータは、プロセッサ５１０による実行のためにシステム５００に読み込まれる。

代替的な実施形態において、二次メモリ５２０は、コンピュータプログラムまたは他のデータまたは命令をシステム５００にロードすることを可能にする他の類似の手段を含み得る。そのような手段は、例えば、外部記憶媒体５９５及びインタフェース５４０を含み得る。外部記憶媒体５９５の例は、外部ハードディスクドライブ、外部光学ドライブ、または外部磁気光学ドライブを含み得る。

二次メモリ５２０の他の例は、プログラム可能な読み取り専用メモリ（ＰＲＯＭ）、消去可能プログラム可能な読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、またはフラッシュメモリ（ＥＥＰＲＯＭと同様のブロック指向メモリ）などの半導体ベースのメモリを含み得る。また、ソフトウェア及びデータを外部媒体５６０からシステム５００に転送できるようにする、任意の他のリムーバブル記憶媒体５３０及び通信インタフェース５４０も含まれる。

システム５００は、通信インタフェース５４０を含み得る。通信インタフェース５４０により、システム５００と外部装置（例えば、プリンタ）、ネットワーク、または情報源との間でソフトウェア及びデータを転送することが可能になる。例えば、コンピュータソフトウェアまたは実行可能コードは、通信インタフェース５４０を介してネットワークまたはクラウドサーバからシステム５００に転送され得る。通信インタフェース５４０の例は、内蔵ネットワークアダプタ、ネットワークインタフェースカード（ＮＩＣ）、パーソナルコンピュータメモリカード国際協会（ＰＣＭＣＩＡ）ネットワークカード、カードバスネットワークアダプタ、ワイヤレスネットワークアダプタ、ユニバーサルシリアルバス（ＵＳＢ）ネットワークアダプタ、モデム、ネットワークインタフェースカード（ＮＩＣ）、ワイヤレスデータカード、通信ポート、赤外線インタフェース、ＩＥＥＥ１３９４ファイヤワイヤ、またはシステム５００をネットワークまたは別のピューティングデバイスとインタフェース接続することができる任意の他のデバイスを含む。

通信インタフェース５４０は、好ましくは、イーサネットＩＥＥＥ８０２標準、ファイバチャネル、デジタル加入者線（ＤＳＬ）、非対称型デジタル加入者線（ＡＤＳＬ）、フレームリレー、非同期転送モード、統合デジタルサービス網（ＩＳＤＮ）、パーソナル通信サービス（ＰＣＳ）、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、シリアルラインインターネットプロトコル／ポイントツーポイントプロトコル（ＳＬＩＰ／ＰＰＰ）などの業界が公布したプロトコル標準を実装し、カスタマイズされた、または非標準のインタフェースプロトコルも実装し得る。

通信インタフェース５４０を介して転送されるソフトウェア及びデータは、一般に、電気通信信号５５５の形である。これらの信号５５５は、通信チャネル５５０を介して通信インタフェース５４０に提供されることが好ましい。一実施形態では、通信チャネル５５０は、有線または無線ネットワーク、または任意の様々な他の通信リンクであってもよい。通信チャネル５５０は、信号５５５を搬送し、ほんの数例を挙げると、ワイヤまたはケーブル、光ファイバ、従来の電話回線、携帯電話リンク、無線データ通信リンク、無線周波数（「ＲＦ」）リンク、または赤外線リンクを含む様々な有線または無線通信手段を使用して実装される。

コンピュータ実行可能コード（即ち、開示されたアプリケーションなどのコンピュータプログラムまたはソフトウェア）は、メインメモリ５１５及び／または二次メモリ５２０に記憶される。コンピュータプログラムは、また、通信インタフェース５４０を介して受信され、メインメモリ５１５及び／または二次メモリ５２０に記憶され得る。このようなコンピュータプログラムは、実行されると、システム５００が前述の本発明の様々な機能を実行できるようにする。

この明細書では、「コンピュータ可読媒体」、「記憶媒体」、及び「媒体」という用語は、システム５００にコンピュータ実行可能コード（例えば、ソフトウェア及びコンピュータプログラム）を提供するために使用される任意の非一時的なコンピュータ可読記憶媒体を指すために使用される。これらの媒体の例は、メインメモリ５１５、二次メモリ５２０（内部メモリ５２５、リムーバブル媒体５３０、及び外部記憶媒体５９５を含む）、及び通信インタフェース５４０と通信可能に結合された任意の周辺装置（ネットワーク情報サーバまたは他のネットワークデバイスを含む）を含む。これらの非一時的なコンピュータ可読媒体は、実行可能コード、プログラミング命令、及びソフトウェアをシステム５００に提供する手段である。

ソフトウェアを使用して実装される実施形態では、ソフトウェアは、コンピュータ可読媒体に記憶され、リムーバブル媒体５３０、Ｉ／Ｏインタフェース５３５、または通信インタフェース５４０を介してシステム５００にロードされ得る。そのような実施形態では、ソフトウェアは、電気通信信号５５５の形でシステム５００にロードされる。ソフトウェアは、プロセッサ５１０によって実行されると、プロセッサ５１０に、本明細書で前述した発明の特徴及び機能を実行させることが好ましい。

一実施形態では、Ｉ／Ｏインタフェース５３５は、システム５００の１つ以上の構成要素と１つ以上の入力及び／または出力デバイスとの間のインタフェースを提供する。入力デバイスの例は、キーボード、タッチスクリーンまたは他のタッチセンシティブデバイス、生体感知デバイス、コンピュータマウス、トラックボール、ペンベースのポインティングデバイスなどを含むが、それらに限定されない。出力デバイスの例は、陰極線管（ＣＲＴ）、プラズマディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、液晶ディスプレイ（ＬＣＤ）、プリンター、真空蛍光ディスプレイ（ＶＦＤ）、表面伝導型電子放出素子ディスプレイ（ＳＥＤ）、電界放出ディスプレイ（ＦＥＤ）などを含むが、それらに限定されない。

システム５００は、音声及びデータネットワークを介した無線通信を容易にするオプションの無線通信コンポーネントも含む。無線通信コンポーネントは、アンテナシステム５７０、無線システム５６５、及びベースバンドシステム５６０を含む。システム５００では、無線周波数（ＲＦ）信号は、無線システム５６５の管理下でアンテナシステム５７０によって無線で送受信される。

一実施形態では、アンテナシステム５７０は、アンテナシステム５７０に送信及び受信信号経路を提供するスイッチング機能を実行する１つ以上のアンテナ及び１つ以上のマルチプレクサ（図示せず）を含み得る。受信経路では、受信したＲＦ信号を、マルチプレクサから、受信したＲＦ信号を増幅し、増幅した信号を無線システム５６５に送信する低ノイズ増幅器（図示せず）に結合することができる。

代替的な実施形態では、無線システム５６５は、様々な周波数及びプロトコルを介して通信するように構成された１つ以上の無線機を含み得る。一実施形態では、無線システム５６５は、復調器（図示せず）と変調器（図示せず）を１つの集積回路（ＩＣ）に組み合わせることができる。復調器と変調器は別のコンポーネントにすることもできる。着信経路では、復調器は、ＲＦキャリア信号を取り除き、無線システム５６５からベースバンドシステム５６０に送信されるベースバンド受信オーディオ信号を残す。

受信信号がオーディオ情報を含む場合、ベースバンドシステム５６０は信号を復号し、それをアナログ信号に変換する。次に、信号が増幅されてスピーカに送信される。ベースバンドシステム５６０は、また、マイクロフォンからアナログオーディオ信号を受信する。これらのアナログオーディオ信号は、デジタル信号に変換され、ベースバンドシステム５６０によって符号化される。ベースバンドシステム５６０は、また、送信用のデジタル信号を符号化し、無線システム５６５の変調器部分にルーティングされるベースバンド送信オーディオ信号を生成する。変調器は、ベースバンド送信オーディオ信号を、ＲＦ送信信号を生成するＲＦキャリア信号と混合する。ＲＦ送信信号はアンテナシステムにルーティングされ、電力増幅器（図示せず）を通過する場合がある。電力増幅器はＲＦ送信信号を増幅し、それを、信号が送信用のアンテナポートに切り替えられるアンテナシステム５７０にルーティングする。

ベースバンドシステム５６０はまた、プロセッサ５１０と通信可能に結合される。中央処理装置５１０は、データ記憶領域５１５及び５２０へのアクセスを有する。中央処理装置５１０は、好ましくは、メモリ５１５または二次メモリ５２０に記憶することができる命令（すなわち、コンピュータプログラムまたはソフトウェア）を実行するように構成される。コンピュータプログラムはまた、ベースバンドシステム５６０から受信され、データ記憶領域５１５または二次メモリ５２０に記憶されるか、または受信時に実行される。このようなコンピュータプログラムは、実行されると、システム５００が前述の本発明の様々な機能を実行できるようにする。例えば、データ記憶領域５１５は、様々なソフトウェアモジュール（図示せず）を含み得る。

様々な実施形態はまた、例えば、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの構成要素を使用して、主にハードウェアで実装することもできる。本明細書に記載の機能を実行できるハードウェア状態マシンの実施態様も、当業者には明らかである。ハードウェアとソフトウェアの両方の組み合わせを使用して、様々な実施形態を実装することもできる。

さらに、当業者は、上記図及び本明細書に開示される実施形態に関連して説明される様々な例示的な論理及び／または機能ブロック、モジュール、回路、及び方法ステップは、多くの場合、電子ハードウェア、コンピュータソフトウェア、またはその両方の組み合わせとして実装されることを理解する。ハードウェア及びソフトウェアのこの互換性を明確に示すために、多様な例示的な構成要素、ブロック、モジュール、回路、及びステップは、概してその機能性の点において上記で説明されている。係る機能性が、ハードウェアとして実装されるのか、それともソフトウェアとして実装されるのかは、特定のアプリケーション、及び全体のシステムに対して課される設計の制約に左右される。当業者は、説明する機能性を、それぞれの特定のアプリケーションに関して様々な点で実装することができるが、係る実施態様の決定は、本発明の範囲からの逸脱を生じさせるとして解釈されるべきではない。さらに、モジュール、ブロック、回路、またはステップ内の機能のグループ化は、説明を簡単にするためのものである。特定の機能またはステップは、本発明から逸脱することなく、あるモジュール、ブロック、または回路から別のモジュール、ブロック、または回路に移すことができる。

さらに、本明細書に開示される実施形態に関連して説明された多様な例示的な論理ブロック、モジュール、機能、及び方法は、例えば汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、ＡＳＩＣ、ＦＰＧＡ、または他のプログラマブル論理デバイス、離散ゲートもしくはトランジスタ論理、離散ハードウェア構成要素、または本明細書に説明する機能を実行することを目的としたその任意の組み合わせなどによって実装または実行できる。汎用プロセッサはマイクロプロセッサにすることができるが、代替ではプロセッサは、任意のプロセッサ、コントローラ、マイクロコントローラ、または状態機械にすることができる。プロセッサは、例えば、ＤＳＰと、マイクロプロセッサ、複数のマイクロプロセッサ、ＤＳＰコアと連動する１つ以上のマイクロプロセッサ、または任意の他の係る構成要素の組み合わせ等、コンピューティングデバイスの組み合わせとしても実装できる。

さらに、本明細書に開示される実施形態と関連して説明する方法またはアルゴリズムのステップは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、または該２つの組み合わせで直接的に実現できる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ－ＲＯＭ、またはネットワーク記憶媒体を含む任意の他の形態の記憶媒体にあり得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるようにプロセッサに結合され得る。代替では、記憶媒体は、プロセッサに一体である場合がある。プロセッサ及び記憶媒体も、ＡＳＩＣにある場合がある。

本明細書で説明するソフトウェアコンポーネントのいずれも、様々な形態をとることができる。例えば、コンポーネントは、スタンドアロンのソフトウェアパッケージである場合もあれば、より大きなソフトウェア製品に「ツール」として組み込まれたソフトウェアパッケージである場合もある。スタンドアロン製品として、または既存のソフトウェアアプリケーションにインストールするための増設パッケージとして、ウェブサイトなどのネットワークからダウンロードされてもよい。また、クライアントサーバソフトウェアアプリケーション、Ｗｅｂ対応ソフトウェアアプリケーション、及び／またはモバイルアプリケーションとして利用できる場合もある。

開示される実施形態の上記説明は、いずれかの当業者が発明を作成または使用することを可能にするために提供される。それらの実施形態に対する様々な修正は、当業者にとって容易に明らかであり、本明細書で説明された一般的な原理は、本発明の精神または範囲から逸脱することなく他の実施形態に適用されることができる。よって、本明細書で提示される説明及び図面は、本発明の現時点で好ましい実施形態を表し、したがって、本発明によって広く考慮される主題を表すことが理解されることになる。更に、本発明の範囲は、当業者にとって明白なることができる他の実施形態を完全に包含し、したがって、本発明の範囲は限定されないことが理解される。

Claims (20)

1. プロトコルスタックを有するカーネルを有するシステム内のアプリケーション層にあるアプリケーションによって、ネットワーク内で送信されるパケットの少なくとも１つのネクストホップｍａｃアドレスをプログラムで決定することによって、パケットの送信を加速する方法であって、前記方法は、
   プロトコルヘッダを有するファントムデータグラム（ＵＤＰ）を作成することと、
   前記ネクストホップＭＡＣアドレスヘッダを未ポピュレートのままにして、前記ファントムＵＤＰのプロトコルヘッダの１つ以上をポピュレートすることと、
   前記プロトコルスタックをトラバースするために、前記ファントムＵＤＰを前記カーネルにサブミットすることと、
   前記カーネルによって前記ネクストホップＭＡＣアドレスヘッダがポピュレートされた状態で前記ファントムＵＤＰを前記カーネルから受信することと、
   １つ以上の所定の特性に基づいて前記ファントムＵＤＰを認識することと、
   前記ファントムＵＤＰから前記ネクストホップＭＡＣアドレスヘッダを記憶することと、
   前記ファントムＵＤＰを送信しないことと、
   を含む、方法。
2. 次のＵＤＰを作成することと、記憶されたネクストホップＭＡＣアドレスを取得することと、取得されたネクストホップＭＡＣアドレスを前記次のＵＤＰのヘッダにポピュレートすることとをさらに含む、請求項１に記載の方法。
3. 前記カーネルのプロトコルスタックは、ルーティングルールを説明する所定のルールセットに基づいて、前記ネクストホップＭＡＣアドレスヘッダを決定する、請求項２に記載の方法。
4. 前記所定のルールセットは、ネットワークルール、セキュリティ対策、ファイアウォール対策のうちの１つ以上を説明する、請求項３に記載の方法。
5. 前記アプリケーションは、ＮＩＣを制御し、前記ＮＩＣに前記ファントムＵＤＰをドロップするように指示することをさらに含む、請求項２に記載の方法。
6. 前記カーネルをバイパスし、記憶されたネクストホップＭＡＣアドレスヘッダを次のＵＤＰにポピュレートして前記次のＵＤＰを前記ＮＩＣに提供することをさらに含む、請求項５に記載の方法。
7. バインド呼び出し、及び前記カーネルとの接続呼び出しを使用してソケットを作成することと、
   前記カーネルによってポピュレートされたファントムＵＤＰからソースＩＰとソース宛先を取得して記憶することと、
   前記次のＵＤＰのヘッダに、記憶されたソースＩＰ及びソース宛先をポピュレートすることと、
   をさらに含む、請求項２に記載の方法。
8. カーネルを有するシステム内のアプリケーション層にあるアプリケーションによってネットワーク内で送信されるパケットの少なくとも１つの第２層の宛先アドレスをプログラムで決定する方法であって、前記方法は、
   ファントムパケットを作成することと、
   前記第２層の宛先アドレスを未ポピュレートのままにして、前記ファントムパケットのプロトコルヘッダの１つ以上をポピュレートすることと、
   前記ファントムパケットを前記カーネルにサブミットすることと、
   前記カーネルによって前記第２層の宛先アドレスヘッダがポピュレートされた状態で前記ファントムパケットを前記カーネルから受信することと、
   前記ファントムパケットを認識することと、
   前記ファントムパケットから前記第２層の宛先アドレスを記憶することと、
   次のパケットを作成することと、
   前記次のパケットのヘッダに、記憶された第２層の宛先アドレスをポピュレートすることと、
   を含む、方法。
9. 前記カーネルはプロトコルスタックを含み、前記カーネルのプロトコルスタックが、ルーティングルールを説明する所定のルールセットに基づいて前記第２層の宛先アドレスを決定することをさらに含む、請求項８に記載の方法。
10. 前記所定のルールセットは、ネットワークルール、セキュリティ対策、ファイアウォール対策のうちの１つ以上を説明する、請求項９に記載の方法。
11. 前記アプリケーションは、ネットワークインタフェースコントローラ（ＮＩＣ）を制御し、前記ＮＩＣが前記ファントムパケットをドロップすることをさらに含む、請求項８に記載の方法。
12. 前記カーネルをバイパスし、前記次のパケットを前記ＮＩＣに提供することをさらに含む、請求項１１に記載の方法。
13. バインド呼び出し、及び前記カーネルとの接続呼び出しを使用してソケットを作成することと、
    前記カーネルによってポピュレートされたファントムパケットからソースＩＰとソース宛先を取得して記憶することと、
    前記次のパケットのヘッダに、記憶されたソースＩＰ及び前記ソース宛先をポピュレートすることと、
    をさらに含む、請求項８に記載の方法。
14. 第２層の宛先アドレスをプログラムで決定することにより、ネットワークを介してパケットの伝送を加速するシステムであって、前記システムは、
    少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサと通信し、前記少なくとも１つのプロセッサによって実行されるときに、前記少なくとも１つのプロセッサに、カーネルを有するオペレーティングシステムを使用して、アプリケーション層にあるアプリケーションを実行させる命令を記憶するメモリであって、前記アプリケーションは、
    ファントムパケットを作成し、
    前記第２層の宛先アドレスを未ポピュレートのままにして、前記ファントムパケットのプロトコルヘッダの１つ以上をポピュレートし、
    前記ファントムパケットを前記カーネルに送信し、
    前記カーネルによって前記第２層の宛先アドレスヘッダがポピュレートされた状態で前記ファントムパケットを前記カーネルから受信し、
    前記ファントムパケットを認識し、
    前記ファントムパケットから前記第２層の宛先アドレスを記憶し、
    次のパケットを作成し、
    前記次のパケットのヘッダに、記憶された第２層の宛先アドレスをポピュレートする
    ように動作可能である、メモリと、
    を含む、システム。
15. 前記カーネルはプロトコルスタックを含み、前記カーネルのプロトコルスタックは、ルーティングルールを説明する所定のルールセットに基づいて前記第２層の宛先アドレスを決定するように構成される、請求項１４に記載のシステム。
16. 前記所定のルールセットは、ネットワークルール、セキュリティ対策、ファイアウォール対策のうちの１つ以上を説明する、請求項１５に記載のシステム。
17. 前記アプリケーションはさらに、ネットワークインタフェースコントローラを制御するように動作可能であり、前記ネットワークインタフェースコントローラは前記ファントムパケットをドロップする、請求項１４に記載のシステム。
18. 前記アプリケーションは、さらに、前記カーネルをバイパスし、前記次のパケットをネットワークインタフェースコントローラに提供するように動作可能である、請求項１４に記載のシステム。
19. 前記アプリケーションは、さらに、
    バインド呼び出し、及び前記カーネルとの接続呼び出しを使用してソケットを作成し、
    前記カーネルによってポピュレートされたファントムパケットからソースＩＰとソース宛先を取得して記憶し、
    前記次のパケットのヘッダに、記憶されたソースＩＰ及び前記ソース宛先をポピュレートする
    ように動作可能である、請求項１４に記載のシステム。
20. 前記アプリケーションは、さらに、前記ファントムパケットのペイロードに認識子をポピュレートするように動作可能であり、前記ファントムパケットを認識することは、前記認識子を認識することをさらに含む、請求項１４に記載のシステム。