以下の説明では多様な実施形態が説明される。説明の目的のため、特定の構成及び詳細が実施形態の完全な理解を提供するために記載される。しかしながら、本実施形態が特定の詳細を伴うことなく実施され得ることも当業者に明らかとなるだろう。さらに、周知の機能は、説明されている実施形態を不明瞭にしないために省略または簡略化され得る。
高性能コンピューティングは、計算クラスタ、つまり、1つの高出力コンピューティングシステムとして機能する比較的低価格のコンピュータのネットワークによって提供され得る。高性能を提供するために、クラスタ内のネットワーク接続システムは高帯域幅をサポートする必要があり、コンピュータクラスタ内のシステム間で送信されるメッセージは可能な限り最小のレイテンシを有する必要がある。伝送制御プロトコル/インターネットプロトコル(TCP/IP)などの一般的なネットワーキングプロトコルは、帯域幅を最大化してレイテンシを最小化するのではなく、一般的に、多数の異なるタイプのネットワークを通じた相互運用を目指している。ゆえに、高性能計算クラスタは、一般的に、カーネルバイパスフレームワークを提供するサーバメッセージプロトコルを使用する。オペレーティングシステムのカーネル動作を迂回すると、ネットワーク帯域幅が大幅に改善され、送信レイテンシが削減され得る。カーネルバイパスフレームワークを提供するネットワークプロトコルは、一般的に、リモートダイレクトメモリアクセス(RDMA)プロトコルと呼ばれるが、ほとんどの場合、RDMAはこれらのプロトコルによって提供される唯一の機能である。
カーネルバイパスフレームワークを提供するネットワークプロトコルは、一般的に、ネットワークパケットを送信及び受信するためにトランスポートスタックを使用する。トランスポートスタックは、通常、1つ以上のトランスポートサービスを提供する。これらのトランスポートサービスは、一般的に、接続型またはコネクションレス型及び信頼可能または信頼不可能に分類される。接続型のトランスポートサービスタイプは、一般的に、コンピューティングクラスタの拡張性に悪影響を及ぼす。接続型のトランスポートサービスの場合、クラスタに接続されるシステムの数が増加すると、接続数が大幅に増加し得る。信頼可能な非接続型のトランスポートサービスタイプは拡張性が高くなり得るが、一般的には、ネットワーク内でドロップされているパケットに対して耐久性が低い。ゆえに、高性能コンピューティングシステムは、高いパケットドロップ率を有し得るネットワーク上で拡張性と信頼性との両方を備えたトランスポートサービスタイプによって改善され得る。
信頼性、つまり、パケットの保証された配信は、ネットワークアダプタデバイスで最適に処理され得る。ネットワークアダプタは、パケットがドロップされたことを迅速に判断することができ得、それらのパケットを再送する要求を同様に迅速に生成することができる。ホストデバイス上で動作中のソフトウェアが信頼性に対応することは、レイテンシに悪影響を及ぼし得る。信頼可能なパケット配信を確実にするソフトウェアでは、トランスポートスタックまで進み、オペレーティングシステムのカーネルまたはユーザアプリケーションにパケットを配信する必要があり、オペレーティングシステムがビジー状態であるなどの様々な理由によりパケットは途中で遅延し得る。ゆえに、パケットの信頼性動作は、トランスポートスタックを通過することによって生じる潜在的な遅延を回避することにより、より効率的に対応され得る。
しかしながら、パケットドロップ及びパケット再送により、パケットが宛先システムに順不同で到着する可能性がある。パケットドロップが発生する可能性のあるシステムでは、順不同で到着するパケットの並び替えは、通常、例えば、ネットワークアダプタデバイスでパケット配信を保証することで共に処理されてきた。しかし、パケットの並び替えに計算が集中する可能性があり、ネットワークアダプタデバイスは、通常、低電力で安価なプロセッサを有する。一方、ホストデバイスは、通常、高性能プロセッサを有し、パケットの並び替えを容易に管理することができる。しかし、既に述べたように、ホストデバイスソフトウェアがパケットの並び替えと信頼可能なパケット配信の両方に対応することは非効率的な場合がある。
本明細書に開示するシステム及び方法は信頼可能なパケット配信及びパケット並び替えを提供し、信頼性はネットワークアダプタデバイスで対応され、パケット並び替えはホストデバイス上のソフトウェアによって対応される。緩和された信頼可能なデータグラムトランスポートサービスがさらに提供される。緩和された信頼可能なデータグラムトランスポートは、パケットを時々ドロップし得るネットワークを通るパケット配信を保証するメカニズムを提供する。緩和された信頼可能なデータグラムトランスポートを使用するように構成されたネットワークアダプタデバイスは、パケットのバッファリングを回避することがあり、代わりにパケットをホストデバイスに可能な限り迅速に配信する。ホストデバイスは、その後、必要に応じてパケットを並び替え得る。本明細書に記載するこれらのシステム及び方法によって、クラスタを通じた高帯域幅及び低レイテンシ転送を提供することで、低価格のコンピューティングクラスタ上での高性能コンピューティングが可能になり得る。
コンピューティングリソースをクラスタ化することは、高い性能及び拡張性を低価格で提供し得る。図1は、コンピューティングリソースのクラスタ100の一例を例示する。クラスタは、スイッチに接続されたコンピューティングリソースのグループであり、並列的に動作するように構成される。多数の実装では、様々なコンピューティングリソースは単一の論理コンピューティングリソースを形成する。図1に例示するクラスタ100の例は、複数のノード102a〜h及びスイッチ104a〜cを含む。いくつかの実装では、クラスタ100はルータ106をさらに含み得る。
図1に例示するノード102a〜hは、様々なコンピューティングリソースを表し得る。例えば、1つ以上のノード102a〜hは、サーバコンピュータなどのコンピュータであり得る。クラスタアプリケーションで使用するコンピュータは、1つ以上のプロセッサを含み得、これらのプロセッサは、1つ以上の処理コアを含み得る。これらのコンピュータはさらに、メモリ及び周辺装置を含んでよい。いくつかの実装では、これらのコンピュータは、クラスタ100内のスイッチ104a〜cに接続するためにアダプタデバイスを使用し得る。コンピューティングリソースの他の例として、ストレージデバイス(例えば、ハードドライブ)、ストレージサブシステム(例えば、ストレージデバイスのアレイ)、入出力(I/O)モジュール及びクラスタ100への管理アクセス用コンソールが含まれる。
スイッチ104a〜cは、様々なノード102a〜h間の接続性を提供し得る。各ノード102a〜hは、スイッチ104a〜cとの接続を通じてクラスタ100に接続され得る。いくつかの場合、ノード102a〜hは、2つ以上のスイッチ104a〜cに接続され得る。スイッチはさらに、他のスイッチに接続され得る。ほとんどの場合、スイッチ104a〜c上の任意のポートは、ノード102a〜hまたは別のスイッチのいずれかに接続するために使用され得る。ほとんどの実装では、クラスタ100のサイズは、より多くのスイッチ及びノードに接続することによって、迅速かつ容易に拡張することができる。
スイッチ104a〜cのネットワークは、任意のノード102a〜hから任意の別のノード102a〜hへの複数の経路を提供し得る。スイッチ104a〜cは別のスイッチ104a〜cとの複数の接続を有し得、スイッチ104a〜c間の追加の経路を提供する。いくつかの場合、ノード102a〜hは2つ以上のスイッチ104a〜cに接続され得、さらにより多くの経路を作成する。1つのノード102a〜hからのパケットは、同時に複数の経路を使用して、別のノード102a〜hに到達し得る。代替的または追加的には、1つのノード102a〜hから別のノード102a〜hへのパケットは、1つの経路のみに従い得る。いくつかの場合、各スイッチ104a〜cにおいてパケットがどの経路に従うかについての決定が行われ得る。他の場合には、パケットの経路は、通常は送信元ノードにおいて、事前に決定され得る。1つのノード102a〜hから別のノード102a〜hへのパケットの流れは、パケットフローまたは単に「フロー」と呼ばれ得る。いくつかの場合、フロー内のパケットは、例えば、パケットが共に1つのメッセージを形成する場合などのように、関連している。
いくつかの実装では、スイッチ104a〜cの1つ以上は、負荷バランシング機能性を含み得る。これらの実装では、スイッチ104a〜cは、ネットワークトラフィックの効率的な配信を試みるように構成され得る。その目的は、通常、ノードとスイッチとの間のリンクが混雑しないようにし、パケットトラフィックが可能な限り迅速にクラスタ100を通過することを確実にすることである。しかしながら、多くの場合、スイッチ104a〜cは、それ自体のトラフィック負荷のみを認識しており、他のスイッチ104a〜cでの負荷に対する認識を欠いている。
いくつかの実装では、クラスタ100はルータ106に接続され得る。ルータ106は、他のクラスタもしくはサブネットワーク(サブネット)、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)またはインターネットなどの他のネットワーク108への接続を提供し得る。
相互接続されたスイッチ104a〜c(及び存在する場合にはルータ106)は、スイッチファブリック、ファブリックまたはより単純に「ネットワーク」と呼ばれ得る。本明細書では、「ファブリック」及び「ネットワーク」という用語は区別することなく使用され得る。
例示のクラスタ100などのコンピューティングクラスタは、より高いコンピューティング出力及びより高い信頼性を提供し得る。個々のコンピューティングリソースは、1台のコンピュータが単独では解決でき得ない大きな問題を解決するために協働することがあるか、または非常に時間をかけて単独で解決することがある。いくつかの場合、コンピューティングクラスタは、スーパーコンピュータと同様の性能を、より低価格かつより少ない複雑性で提供し得る。コンピューティングクラスタによって使用されるスイッチドファブリックアーキテクチャは、フォールトトレラントで拡張性があるという利点をさらに有し得る。スイッチドファブリックアーキテクチャでは、通常、全てのリンクが、リンクの各端部に連結された1つのデバイスを有する。ゆえに、各リンクは、最大でも2つのデバイスの動作のみに依存する。スイッチドファブリックはさらに、より多くのスイッチを追加することによって容易に拡張することができてよく、これにより、より多くのノードを連結するより多くのポートを提供する。いくつかの場合、より多くのスイッチを追加するとクラスタの総帯域幅が増加し得る。ノード間の複数の経路はさらに、高い総帯域幅を保持し、リンク障害が発生した場合には冗長接続を提供し得る。
コンピューティングクラスタは、様々な用途に使用され得る。例えば、コンピューティングクラスタは高性能コンピューティングに使用され得る。高性能コンピューティングは、並列処理を使用して計算集約型アプリケーションを実行することを伴う。科学的研究、技術者及び学術機関は、例えば、自動車事故シミュレーション、気象モデリング、原子シミュレーション及びその他など、複雑なモデリングまたはシミュレーションに高性能コンピューティングを使用し得る。コンピューティングクラスタの他の使用例としては、機械学習、金融応用、分散ストレージ及びデータベースが含まれる。機械学習は、膨大な量のデータを検証し、データから学習して予測を行うことができるアルゴリズムを実行することを伴う。高頻度な取引などの金融応用も大量のデータを検証することがあり、一般的に、データの変化に対して迅速に(例えば、人間よりもはるかに速く)反応することに依存する。分散ストレージは、非常に大量のデータを複数の場所からアクセスできるようにする。ストレージエリアネットワークは分散ストレージの1つの形態である。データベースはさらに、大量のデータを格納して、データベース内に格納されている特定の情報を発見するための非常に迅速な方法を提供する必要がある。
コンピューティングリソースをクラスタ化することによる最大の利益を得るために、ノード間の通信に使用されるプロトコルは、高帯域幅及び低レイテンシを提供する必要がある。高帯域幅とは、大量のトラフィックがクラスタを通過可能である必要があることを意味し、低レイテンシとは、トラフィックが送信元から宛先に可能な限り迅速に移動可能である必要があることを意味する。いくつかの動作がレイテンシに大きく寄与し得る。これには、オペレーティングシステム内でネットワークプロトコルコードを実行することによって生じるオーバーヘッド、カーネルモード内外での移動及びデータ送信に必要なコンテキストスイッチ及び/またはネットワークアダプタでのユーザレベルのバッファとメモリと間のデータの過剰コピーが含まれる。例えば、通常のネットワークプロトコルスタックは、混雑することがなく遅延がほぼゼロのネットワークを仮定すると、約100マイクロ秒の往復レイテンシを引き起こし得る。しかしながら、この遅延には、スケジューリング遅延に起因する数ミリ秒の長さのスパイク、アプリケーションがネットワークスタックの問題を回避するように設計されていない場合の数十ミリ秒の長さのスパイク及び/または混雑したリンクでパケットがドロップする場合の数秒の長さのスパイクが混在し得る。コンピューティングクラスタは、高帯域幅のハードウェアで設計されることがあり、高帯域幅のハードウェアは、通常、プロセッサ及びメモリのコピーオーバーヘッドにさらに影響を受けやすい。
(TCP/IP)などのネットワークプロトコルは、多くの異なるタイプのネットワーク全体の性能の高さ及び/または費用効果の高さを重視する傾向にある。その結果、TCP/IPなどのプロトコルは、高レイテンシになる傾向にあり、複雑になる傾向にある。TCPなどのネットワークプロトコルは、様々なタイプのネットワーク上で汎用通信に適している場合があるが、高帯域幅かつ低レイテンシである環境では、より特化したプロトコルが有益であり得る。
コンピューティングクラスタ内のノード間で高帯域幅かつ低レイテンシのリンクを提供するために、仮想インタフェース(VI)アーキテクチャ(VIA)サーバメッセージングプロトコルが開発された。VIAに類似するプロトコルの例には、InfiniBand、インターネットワイドエリアRDMAプロトコル(iWARP)及びRDMAオーバコンバージドイーサネット(RoCE)が含まれる。これらのプロトコルのそれぞれは、RDMAと呼ばれることが多い、カーネルバイパスフレームワークを含み、カーネルバイパスフレームワークについては以下でさらに詳細に説明する。iWARPは、TCP/IPプロトコル上でカーネルバイパスフレームワークを提供する。RoCEは、イーサネット型ネットワーク上でカーネルバイパスフレームワークを提供する。InfiniBandは、InfiniBand固有のネットワーク上でカーネルバイパスフレームワークを提供する。「InfiniBand」及び「RDMA」という用語はしばしば区別なく使用されるが、他のプロトコル(iWARP及びRoCEなど)もRDMA形式のカーネルバイパスフレームワークを提供する。
VIAタイプのプロトコルは、一般的に、低レイテンシ、高帯域幅及びカーネルバイパスネットワークを提供する。VIAタイプのプロトコルは少なくとも以下、つまり、複数のユーザアプリケーション間のリソース共有により生じるオーバーヘッドを削減すること、トランスポートプロトコル処理をプロセッサから排除すること、データの高速なバルク転送及びリモートアプリケーションの待機時間を削減することを提供することを目的とする。
VIAタイプのプロトコルは、複数のユーザアプリケーション間のリソース共有により生じるオーバーヘッドを削減することを目的とする。通常のネットワークプロトコルスタックはカーネルレベルで動作し、複数のアプリケーション間でネットワークインタフェースの共有を容易にする。しかしながら、このリソース共有は、少なくとも以下の理由、つまり、複数のプロセッサコア間の調整によりレイテンシが増加し得ること、アプリケーションを起動するために使用するプロセッサ間の割り込みによりレイテンシが増加し得ること、互いからアプリケーションを保護するために中間キューイングまたはバッファリングが必要になり得ること及びキューまたはバッファ間のコピーによりレイテンシが増加し得ることによって、ネットワーク遅延が生じることがあり、ダイレクトメモリアクセス(DMA)はこれらのアプリケーション用に構成できないため、アプリケーションバッファ間で内部カーネルバッファをコピーする必要があり得る。
単一のネットワークインタフェースを共有しようとする複数のユーザアプリケーションにより生じる遅延を回避する1つの方法は、一度に1つのアプリケーションのみがネットワークインタフェースを使用するようにすることである。データプレーン開発キット(DPDK)は、これを可能にするフレームワークの一例を提供する。DPDKフレームワークは、ユーザ空間ポーリングモードのデバイスドライバの形態で、単純なネットワークインタフェースを提供し得る。DPDKフレームワークは、他のオペレーティングシステムサービスの代替にもなり得、これによって、ユーザアプリケーション用のアプリケーションプログラミングインタフェース(API)及び単一ユーザの協働マルチタスク用に設計された実行モデルを提供する。このフレームワークは、ネットワークインフラストラクチャ(例えば、ゲートウェイデバイス)にとっては効率的であり得るが、DPDK固有のAPIに対応するために書き直す必要のあり得る従来のユーザアプリケーション及びミドルウェアにとっては実用的でない場合がある。DPDKフレームワークはさらに、実行にルート権限が必要な場合があり、これはカーネルに負荷をかける可能性があり、セキュリティ上のリスクが発生する可能性がある。さらに、DPDK環境ではアプリケーションが物理メモリアドレスを使用する必要があり得、これにより仮想マシンの使用が制限されるため、DPDKフレームワークはマルチユーザ環境では実用的ではない可能性がある。単一のユーザであっても、DPDKフレームワークは実用的ではない可能性がある。DPDK及び類似のモデルを拡張してトランスポートスタックの機能を担い、これにより複数のアプリケーションを提供できるようにしてよい。ただし、これらのアプリケーションとDPDKプロセスとの間の通信には、大幅なレイテンシが発生する可能性がある。
ハードウェアリソースを効率的に共有するための別の方法はカーネルバイパスフレームワークであり、これは、上記の通り、一般的にはRDMAフレームワークと呼ばれる。RDMAベースのデバイスは、権限のないユーザアプリケーションで使用され得る。RDMAベースのデバイスはさらに、複数のアプリケーションが互いに干渉することなくハードウェアに直接アクセスできるようにし得る。RDMAデバイスは、初期化を実行するための制御操作及び割り込み処理に必要となり得るいくつかの調整のためのみにカーネルに依存することがあるが、別様には、RDMAデバイスはカーネルとは独立して動作し得る。これは、プロセッサがRDMA動作に関与する必要がないことを意味する。RDMAフレームワークはさらに、ポーリングモード完了処理などの最適化を提供してよく、最適化は超低レイテンシを提供するのに有益であり得る。
上記の通り、VIAタイプのプロトコルは、トランスポートプロトコルの管理におけるプロセッサの関与を削減することを目的とする。前述の通り、ネットワークプロトコルの管理におけるプロセッサの関与はレイテンシの潜在的な原因である。アプリケーションがリモートの宛先に長いメッセージを送信すると、ローカルコンピュータとリモートコンピュータとの両方でプロセッサが関与する可能性がある。例えば、プロセッサは、メッセージをパケットに分割し、送信のためにハードウェアキューにパケットを個別に送り、パケットを受信し、確認パケットを生成し、ホストメモリ内でデータを配置する位置を決定する必要があり得る。特に、パケットが到着すると、単純なネットワークインタフェースカードは、周辺置バス上でホストデバイスのメインメモリにパケットを渡し、次いで、プロセッサに割り込みを発行することがあり、割り込みは実際にプロセッサに警告するまでにある程度時間がかかり得る。一旦割り込まれると、プロセッサは、通常、オペレーティングシステムにより生じる追加の遅延の後で、確認の生成など、プロトコル処理動作を実行し得る。
プロトコル動作を処理し、これらの動作をプロセッサから排除するように構成されたネットワークアダプタは、各パケットのより高速な処理を可能にし得る。ネットワークアダプタデバイスは、着信メッセージ及びリモート読み取り及び書き込みコマンドを処理することができ得る。ネットワークアダプタはさらに、ホストメモリに対してDMAトランザクションを行い、確認パケットを生成することができ得る。ネットワークアダプタは、プロセッサに割り込むことなく、これらの動作を行うことができ得る。
前に記した通り、VIAタイプのプロトコルの別の目的は、データの高速なバルク転送を提供することである。データのバルク転送、つまり、大量のデータの転送は、単にネットワークリンクの帯域幅を増やすことによって高速に実行され得る。しかしながら、高速ネットワーク相互接続は、送信元及び/または宛先コンピュータのメモリサブシステムに負荷をかけ得る。メモリサブシステムは、通常、オーバープロビジョニングされないため、高帯域幅のネットワーク転送中に複数回アクセスするとボトルネックになり、メモリへの中間コピーの配置が発生することがある。バルク転送で複数のコピーを作成する必要がある場合、このコピーによって転送のスループットが制限されることがあり、トランザクションレイテンシが増加し得る。この遅延を軽減するための1つの可能な方法は、大容量のレベル3(L3)キャッシュを含むプロセッサによって提供される。これらのプロセッサでは、ネットワークインタフェースカードがL3キャッシュに直接データを書き込み得る。しかしながら、これらのプロセッサは、キャッシュの性質(キャッシュにないデータをフェッチする必要があり、ゆえにレイテンシを招く)に起因して一貫性を伴うことなく行われ得る。さらに、データが迅速にコピーされない場合、より有用なデータに使用される可能性があるL3キャッシュ内の空間をデータが専有し得るため、L3キャッシュは役に立たない可能性がある。
カーネルバイパスフレームワークは、「ゼロコピー」データ転送と呼ばれることが多いプロセスにより、良好な解決策を提供する。ゼロコピーは、RDMAによって提供される動作の1つである。RDMAは、ダイレクトメモリアクセス(DMA)の拡張を表す。DMAは、通常、特定のハードウェアサブシステムがプロセッサを使用することなくメインシステムメモリにアクセスすることを可能にする。同様に、RDMAによって、コンピュータは、いずれのコンピュータのプロセッサも関与させることなく、ネットワーク上で別のコンピュータ上のメモリにアクセスすることが可能になる。ゆえに、ローカルコンピュータは、ローカルコンピュータまたはリモートコンピュータのいずれかにおけるプロセッサによって中間コピーを作成することなく、リモートコンピュータのメモリ上で読み取り、書き込みまたはアトミック操作を行うことができ得る。多数の実装では、それぞれがRDMAアダプタを有するローカルコンピュータ及びリモートコンピュータによってRDMAが可能になる。
前に記した通り、VIAタイプのプロトコルはさらに、リモートアプリケーションの待ち時間を削減することを追求する。アプリケーション自体がネットワークレイテンシに寄与し得る。ネットワークトランザクションには、ローカルコンピュータとリモートコンピュータとの両方でアプリケーションが関与し得る。リモートアプリケーションは、例えば、スケジューリング遅延に起因して、トランザクションに応答するのにある程度時間がかかり得る。ローカルアプリケーションのみが関与する「一方向の」RDMA通信は、リモートアプリケーション上で待機することによって発生するレイテンシを削減し得る。そのメモリへのアクセスを許可することにより、リモートアプリケーションはデータ転送に関与する必要がなくなり得る。代わりに、リモートコンピュータでのRDMAアダプタは、リモートアプリケーションに関与することなく、リモートメモリに直接アクセスすることができ得る。RDMAはさらに、読み取り動作及び書き込み動作に加えて、リモートのアトミック操作を提供することがあり、これは、ロック動作により生じるレイテンシを削減し得る。
要約すると、VIAタイプのプロトコルは、複数のユーザアプリケーション間のリソース共有により生じるオーバーヘッドを削減し得る。VIAプロトコルはさらに、トランスポートプロトコル処理の動作をプロセッサから排除し得る。これらのプロトコルはさらに、データの高速なバルク転送を提供し、リモートアプリケーションが応答するまでの待ち時間を削減し得る。これらの動作はRDMAとして表されることが多いが、より一般的には、カーネルバイパス動作として表され得る。これらの機能はさらに、リモートメモリアクセス(RMA)または一方向通信と呼ばれ得る。
図2は、カーネルバイパスフレームワークを実装するために使用され得る通信スタック200の一例を例示する。図2に例示するような通信スタック200を使用すると、クライアントプロセス202は、ローカルシステム230またはリモートシステム232のいずれかでプロセッサからの支援を伴うことなく、リモートシステム232上のリモートプロセス204と直接通信することができ得る。図2の例では、一例として、2つの異なるシステム上で実行している2つのプロセス間の通信スタック200を例示する。以下に説明する通り、ネットワークファブリック220を通じて通信する任意の2つのプロセス間で同様の通信スタックを構成することができる。さらに、一方のシステム230を「ローカル」と呼び、他方のシステム232を「リモート」と呼ぶが、いくつかの実装では、通信スタック200は、リモートシステム232がローカルシステム230に送られるメッセージを発信できるように、逆方向に動作することもできることが理解される。
いくつかの実装形態では、図2に例示する通信スタック200は、ローカルシステム230またはリモートシステム232のいずれかでプロセッサを最小限に使用して動作する。ネットワークトラフィック制御作業をプロセッサから排除または削減することは、「作業キューペア」または単に「キューペア」210a〜bとも呼ばれる「作業キュー」によって完了され得る。ローカルシステム230とリモートシステム232との間の各通信チャネルに対して、キューペア210a〜bが両方のシステム230、232に割り当てられ得る。キューペア210a〜bは、ネットワークファブリック220に向かうトラフィック用の送信キュー212a〜b及びネットワークファブリック220から入ってくるトラフィック用の受信キュー214a〜bを含む。いくつかの実装では、クライアントプロセス202は、リモートプロセス204との通信チャネルを確立するときに、キューペア210a〜bを開始する。これらの実装では、クライアントプロセス202は、異なるプロセスが同じリモートシステム232上で動作中であるか、またはプロセスが他のリモートシステム上で動作中である状態で、同じリモートプロセス204と通信するために追加の作業キューを開始することができる。クライアントプロセス及びリモートプロセスには、ユーザアプリケーション及び/またはドライバプログラムなど、カーネル以外のプロセスまたはオペレーティングシステムプロセスが含まれる。
いくつかの実装では、ローカルシステム230のキューペア210aは、送信元チャネルアダプタ208a上に存在する。送信元チャネルアダプタ208aは、ネットワークファブリック220と通信するように構成され得る。送信元チャネルアダプタ208aは、他のプロセスに割り当てられるか、同じクライアントプロセス202に割り当てられる追加のキューペア、あるいは現在使用されていない可能性がある追加のキューペアを含み得る。いくつかの実装では、キューペア210aの使用及び構造が明確に理解されてよく、ゆえに、キューペア210aはハードウェアに実装されてよい。他の実装では、キューペア210aは、ソフトウェア(例えば、ドライバ)またはハードウェアとソフトウェアとの組み合わせに実装されてよい。キューペア210aに加えて、送信元チャネルアダプタはさらに、ネットワークファブリック220及びリモートプロセス204との通信を管理するトランスポート層216aを含み得る。送信元チャネルアダプタ208aはさらに、送信元チャネルアダプタ208aをファブリック220に接続する物理ポート218aを含み得る。送信元チャネルアダプタ208aはさらに、ホストチャネルアダプタ、またはより一般的にはネットワークアダプタと呼ばれ得る。
クライアントプロセス202は、「作業キュー要素」222(WQEと略されることが多い)をローカル送信キュー212aに配置することによって、リモートプロセス204へのトランザクションを開始し得る。作業キュー要素222は、読み取りトランザクション、書き込みトランザクションまたはアトミックトランザクションなどのトランザクションを含み得る。いくつかの実装では、作業キュー要素222はさらに、リモートプロセス204をトランザクションのターゲットとして識別する情報を含み得る。送信元チャネルアダプタ208aは、送信キュー212aから直接的に作業キュー要素222を処理し得る。送信元チャネルアダプタ208aは、作業キュー要素222内の情報を使用して1つ以上のパケットを生成し得る。トランスポート層216aは、ポート218aを通じてこれらの1つ以上のパケットをネットワークファブリック220に送信し得る。
リモートシステム232は、それ自体の宛先チャネルアダプタ208b(ターゲットチャネルアダプタ、またはより一般的にはネットワークアダプタとも呼ばれる)でネットワークファブリック220から1つ以上のパケットを受信し得る。送信元チャネルアダプタ208aと同様に、宛先チャネルアダプタ208bは、宛先チャネルアダプタをネットワークファブリック220に接続するポート218bを含む。宛先チャネルアダプタ208bはさらに、ネットワークファブリック220及びクライアントプロセス202との通信を管理するトランスポート層216bを含み得る。宛先チャネルアダプタ208bはさらに、リモートプロセス204に割り当てられるキューペア210bを含み得る。
リモートシステム232で受信されたネットワークファブリック220からの1つ以上のパケットは、トランスポート層216bによって受信キュー214bに送られ得る。いくつかの実装では、宛先チャネルアダプタ208bは、クライアントプロセス202によって生成されたメッセージ222を再構築し、再構築されたメッセージを受信キュー214bに配置し得る。リモートプロセス204は、要素がその受信キュー214bに到着するときに自動的に通知され得る。リモートプロセス204は、受信キュー214bから要素224をポップしてよく、要素224に動作を行ってよく、その後、いくつかの場合では、クライアントプロセス202に返すことになる応答を生成してよい。リモートプロセス204は、応答を含む作業キュー要素226をそれ自体の送信キュー210bに配置し得る。応答は、次いで、ファブリック220を通過してローカルシステム230に返送されてよく、「完了キューエントリ」228(CQEと略されることが多い)としてクライアントプロセス202に配信される。
この情報交換では、ローカルシステム230とリモートシステム232との両方でオペレーティングシステムのカーネルが必要とされない可能性が高い。例えば、カーネルバイパスを実装していないシステムの場合のように、それぞれのネットワークアダプタカードの使用を調整するためにクライアントプロセス202またはリモートプロセス204のいずれも不要になり得る。代わりに、各プロセス202、204は、他のプロセス202、204との排他的な通信チャネルを有すると考えられ得る。実際には、複数のプロセスがネットワークアダプタカード208a〜bを使用してネットワークファブリック220上で通信することがあるが、ネットワークアダプタカード208a〜bは、複数のプロセスとそれらのそれぞれのキューペアとの間の調整を管理する。追加的には、トランスポート層216a〜bは、例えば、ネットワークファブリック220によって送信及び受信されドロップされる可能性のあるパケットを追跡するなど、クライアントプロセス202とリモートプロセス204との間の接続を管理し得る。
多くの実装では、トランスポート層216a〜bは、送信キュー212a〜bに対するいくつかの動作を支援し得る。例えば、トランスポート層216a〜bは、あるプロセスがメッセージを送信し、ネットワーク上の別のシステム上の別のプロセスがそのメッセージを受信するといった典型的な送信及び受信動作を支援し得る。別の例として、トランスポート層216a〜bはさらに、1つのプロセスがリモートシステムのメモリバッファに直接書き込むといったRDMA書き込みを支援し得る。この例では、リモートプロセスは適切なアクセス権限を送信システムに事前に付与し、リモートアクセス用にメモリバッファを登録するだろう。別の例として、トランスポート層216a〜bは、1つのプロセスがリモートシステムのメモリバッファから直接読み取るRDMA読み取りを支援し得る。この例では、リモートシステムはさらに、適切なアクセス権限を送信システムに事前に付与するだろう。別の例として、トランスポート層216a〜bはさらに、RDMAタイプのアトミック操作を支援し得る。このようなアトミック操作の1つに「コンペアアンドスワップ」があり、コンペアアンドスワップでは、プロセスがリモートメモリの位置を読み取り、読み取ったデータが指定の値であれば、同じリモートメモリの位置に新しい値を書き込む。別のアトミック操作には「フェッチアッド」があり、フェッチアッドでは、プロセスがリモートメモリから位置を読み取り、呼び出し元に読み取ったデータを返送し、次いで、指定の値をデータに追加し、変更された値を同じリモートメモリの位置に書き込む。
いくつかの実装では、トランスポート層216a〜bはさらに、受信キュー214a〜bに対する動作を支援し得る。例えば、トランスポート層216a〜bは、「受信後バッファ」と呼ばれる動作を支援することがあり、「受信後バッファ」では、送信用ターゲット、RDMA書き込み及び別のシステムによって開始されたRDMA読み取りのために使用され得るバッファが識別される。
いくつかの実装では、キューペアが開始されると、開始プロセスはキューペアをトランスポートサービスタイプに関連させ得る。トランスポートサービスタイプは、次いで、送信元システムから宛先システムへのパケットの送信方法を決定し得る。図3は、トランスポートサービスタイプ300の例を例示する。VIAタイプのプロトコルによって使用されるトランスポートサービスタイプ300は、接続型302または非接続型304及び信頼可能306または信頼不可能308に分類することができる。接続型302及び非接続型304は、送信プロセスと受信プロセスとの間に明確な接続が確立されているかどうかを表す。接続型302のトランスポートサービスタイプ300では、接続は、ほとんどの実装において、送信及び受信プロセスに排他的である。非接続型304のトランスポートサービスタイプ300では、パケットまたは「データグラム」がネットワークに送信され、通常、その宛先に利用可能なあらゆる経路に従う。信頼可能306及び信頼不可能308は、トランスポートサービスタイプ300がパケットの配信を保証するかどうかを表す。信頼可能306なトランスポートサービスタイプ300は、通常は配信を保証し、一方で信頼不可能308なトランスポートサービスタイプ300は、通常は配信を保証しない。
接続型302かつ信頼可能306なトランスポートサービスタイプ300の例は、信頼可能な接続310(RC)と呼ばれる。信頼可能な接続310は、パケットの順序通りの配信を保証する。順序通りとは、メッセージが送信元アプリケーションによって送信された順序と同じ順序で宛先アプリケーションに配信されることを意味する。信頼可能な接続310はさらに、通信するプロセスの各ペア間の接続の明確な確立を必要とする。明確な接続を確立するステップの例は、以下の通りである。クライアントプロセスは、まず、通信スタック(例えば、図2の通信スタック200)を使用して宛先システムのネットワークアドレスを検索し得る。クライアントプロセスは、次に、トランスポート層に接続コンテキストを作成するよう要求し得る。クライアントプロセスは、次いで、トランスポート層(またはトランスポート管理)が接続コンテキストをリモート宛先アドレスに関連させるよう要求し得る。最終的に、トランスポート層(またはトランスポート管理)は、接続を確立するために、宛先システムとのメッセージの交換(例えば、「ハンドシェイク」)を行い得る。
図3に戻ると、明確な接続確立では、信頼可能な接続310タイプのトランスポートサービスの拡張は困難になり得る。上記の通り、2つのプロセスがネットワークを通じて通信するには、明確な接続を確立する必要がある。ゆえに、ネットワークに接続されるノードにプロセスが追加されると、接続数が大幅に増加する。例えば、ローカルシステムでの100のプロセスがリモートシステム上で動作中の100のプロセス全てと通信すると、100×100、つまり10,000の接続を確立する必要があるだろう。さらに、コンピューティングクラスタは数百のノードを有することがあり、各ネットワークノードは数百またはそれ以上のプロセッサを実行していることがあり、その結果、クラスタは無数の接続を必要とする可能性がある。
潜在的により高い拡張性を備え得るトランスポートサービスタイプ300は、信頼不可能なデータグラム316(UD)である。信頼不可能なデータグラム316は、明確な接続確立を必要とせず、配信を保証しない。配信を保証しないということは、送信者がパケットをネットワークファブリックに送信し、パケットがその宛先に到着したかどうかを確かめようとしないことを意味する。信頼不可能なデータグラム316は、例えば、信頼可能な接続310を確立するために交換するメッセージなど、管理目的のためにメッセージを転送するために使用され得る。信頼不可能なデータグラム316はパケット配信を保証しないため、パケットドロップがほとんど発生しないネットワーク(例えば、InfiniBandネットワークなど)では効果的であり得る。しかしながら、パケットドロップが発生しやすいネットワークでは、信頼不可能なデータグラム316は一般に使用されない。
信頼不可能な接続312はさらに、パケットドロップが発生しやすいネットワークにおいて使用され得る。信頼可能な接続310と同様に、信頼不可能な接続312は明確な接続確立を必要とするが、配信を保証する。信頼不可能な接続312は、(例えばビデオストリーミングなど)パケットドロップに耐久可能なアプリケーションで使用され得るが、ドロップへの耐久性がないアプリケーションでは問題となる。
信頼可能なデータグラム314(RD)は、明確な接続確立を必要とせず、全てのパケットの配信を保証する。信頼可能なデータグラム314は、もともとは信頼可能な接続310の拡張性の問題を軽減するために開発されたが、単独接続の性能が損なわれている。その結果、信頼可能なデータグラム314は一般に使用されていない。
主要なトランスポートサービスタイプ300の望ましい態様の組み合わせを試みるいくつかのトランスポートサービスタイプ300が開発されてきた。信頼可能な接続310の拡張性の問題に対処するために、拡張型の信頼可能な接続318(XRC)が開発された。拡張型の信頼可能な接続318は、プロセスが通信している宛先システムにおける全てのプロセスに対して、宛先システムごとに1つの接続のみを使用することを可能にする。拡張型の信頼可能な接続318は、しかしながら、複雑なアプリケーションインターフェースを有することが知られている。動的な接続320(DC)は、信頼可能な接続310のパケット配信保証と、明確な接続を必要としない信頼不可能なデータグラム316とを組み合わせることを試みる。動的な接続320では、信頼可能な接続310の場合のように接続は固定的ではないが、その代わり、必要に応じて設定され、必要なくなったときに排除される。動的な接続320は、しかしながら、パケットドロップが非常に稀であるInfiniBandタイプのネットワーク向けに開発された。動的な接続320は、ゆえに、パケットドロップがより頻繁に発生するネットワークでは、効率性が低くなり得る。
以下のセクションでさらに詳細に説明する緩和された信頼可能なデータグラム322(RRD)は、パケットドロップが稀に発生するイベントではないネットワークにおいて、拡張性及び保証されたパケット配信を提供し得る。緩和された信頼可能なデータグラム322は、信頼不可能なデータグラム316と同様の簡素でコネクションレス型のインタフェースをユーザアプリケーションに提供し得る。緩和された信頼可能なデータグラム322はさらに、信頼可能な接続310と同様に、パケット配信を保証する。緩和された信頼可能なデータグラム322はパケットを順序通りに配信せず、これによって、トランスポート設計を簡略化し、パケット配信の効率性を潜在的に高める。
図4は、上記のトランスポートサービスのうちの1つ以上に加えて、緩和された信頼可能なデータグラムトランスポートを供給するように構成され得るシステム400の一例を例示する。ハードウェア及びソフトウェア構成要素に関して説明するが、システム400の例は主に機能的な説明であり、例示の様々な構成要素は、ハードウェア、ソフトウェア、ハードウェアとソフトウェアとの組み合わせで実装されてよく、この特定の例で説明される以外の論理構成及び/または物理構成で実装されてよい。
システム400の例は、ホストデバイス410及びネットワークアダプタデバイス420を含む。ホストデバイス410及びネットワークアダプタデバイス420は、ケーブル、プラグ、ソケット、スロット、プリント回路基板またはこれらの物理的構成要素の組み合わせなどの物理接続上で通信し得る。ホストデバイス410は、図面には例示していないが、1つ以上のプロセッサ、メモリサブシステム、周辺装置及びその他などの構成要素を含む、汎用コンピューティングシステムであり得る。いくつかの実装では、以下に説明するネットワークアダプタデバイス420の動作は、集積回路デバイス及び/または集積回路デバイスの集合体で実施され得る。例えば、様々な実装では、ネットワークアダプタデバイスの動作は、システムオンチップ(SoC)、フィールドプログラマブルゲートアレイ(FPGA)または特定用途向け集積回路(ASIC)あるいはこれらのデバイスの組み合わせで実装され得る。
ホストデバイス410は、1つ以上の仮想マシン402を実行するように構成され得る。仮想マシンは、現実または仮想のコンピューティングシステムを表すエミュレートされたコンピューティング環境である。仮想マシンは、物理コンピュータと同様に、オペレーティングシステムを含むプログラムを実行し得る。仮想マシンは、一般的に、互いに単独的に動作し、仮想マシン内のプロセスは、異なる仮想マシン内で動作中のプロセスに影響を与えることができない。仮想マシンは、専用のハードウェア、ソフトウェア、ハードウェアとソフトウェアとの組み合わせを伴い得る。
システム400の例の仮想マシン402は、1つ以上のユーザアプリケーション404a〜bを実行中であってよい。ユーザアプリケーション404a〜bは、例えば、高性能なコンピューティングアプリケーション、他の計算集中型プログラムならびに通常のユーザアプリケーション、例えば、文書編集ツール及びウェブブラウザなどを含む。ほとんどの実装では、ユーザアプリケーション404a〜bは、「ユーザ空間」、つまり、オペレーティングシステム(通常は「カーネル空間」で動作する)及び基礎となるハードウェアから互いに分離した環境で動作する。オペレーティングシステムのカーネル412は、ユーザアプリケーション404a〜bのそれぞれ及びその基礎となるハードウェアへのアクセスを含む、より多くのアクセス権限を有し得る。
ユーザアプリケーション404a〜bは、標準ライブラリ406及び/またはユーザ空間ドライバプログラム408を通じてシステム400のハードウェアと通信し得る。標準ライブラリ406は、共通の動作を実行するための公知及び合意されたアプリケーションプログラミングインタフェース(API)を提供する。これらの一般的な動作は、例えば、頻繁に実行されるソフトウェア動作及びシステム400のハードウェアへのアクセスを含み得る。標準ライブラリの1つのカテゴリは、カーネルバイパスフレームワークのために定義されたものである。これらのライブラリには、例えば、OpenFabrics Alliance(OFA)、Open Fabrics Distribution(OFED)verbsライブラリ及びLibFabric OpenFabrics Interfaces(OFI)、OpenFabrics Interfacesを実装するオープンソースLinuxライブラリが含まれる。OFEDはもともとInfiniBand VerbsにAPIを提供するために開発された。InfiniBand Verbsは、ハードウェアまたはオペレーティングシステムとは独立したInfiniBandアダプタの機能性の抽象的な表現である。OFEDは後に非InfiniBandアダプタをサポートするために発展した。しかしながら、OFED APIのセマンティクスは、一般的に、多くのアプリケーションの要件と互換性がなく、特に規模が大きい場合には使用しにくいことが知られている。OFIは、対照的に、複数のタイプのセマンティクスを提供し、基礎となるハードウェア機能を公開することに加え、アプリケーションのニーズにも焦点を当てていることが知られている。
いくつかの実装では、標準ライブラリ406は、ユーザ空間ドライバプログラム408と通信してよく、ユーザ空間ドライバプログラム408は、特定のハードウェアデバイスへのアクセスを提供するように構成される。いくつかの場合、ユーザアプリケーション404bは、ユーザ空間ドライバプログラム408と直接的に通信することができ得る。この例では、ユーザ空間ドライバプログラム408は、ネットワークアダプタデバイス420へのアクセスを提供し得る。ユーザ空間ドライバプログラム408は、標準ライブラリ406によって提供される抽象化と、ネットワークアダプタデバイス420の特定のハードウェアとの間のインタフェースを提供し得る。例えば、ユーザ空間ドライバプログラム408は、送信キュー及び受信キューを含む通信スタックへのアクセスを提供してよく、いくつかの実装では、通信スタックはネットワークアダプタデバイス420に配置されてよい。
いくつかの実装では、ユーザアプリケーション404a〜bは、構成動作のためにオペレーティングシステムのカーネル412と通信し得る。例えば、ユーザアプリケーション404a〜bは、仮想アドレス及びメモリ領域をカーネル412に登録し得る。いくつかの実装では、カーネル412は、カーネル空間トランスポートドライバ416を含み得る。カーネル空間トランスポートドライバ416は、ユーザアプリケーション404a〜bへのキューペアのマッピング、メモリ登録及びネットワークアドレス管理を含む制御動作を実行するように構成され得る。
ネットワークアダプタデバイス420は、ネットワーク430と通信するように構成され得る。ネットワークアダプタデバイス420は、送信動作及び受信動作を実行するように構成され得る管理モジュール422を有し得る。管理モジュール422は、例えば、ファームウェアまたはFPGAもしくはASICなどの集積回路であり得る。ネットワーク430上でメッセージを送信するために、管理モジュール422は、ユーザアプリケーションのメッセージを使用してパケットを生成し、パケットヘッダを構築するように構成され得る。ネットワーク430からメッセージを受信するために、管理モジュール422は、パケットヘッダを削除し、受信ユーザアプリケーション404a〜bに向けて受信メッセージを送信するように構成され得る。受信したメッセージは、いくつかの場合、送信者のアドレスまたは送信者を識別する何らかの他の情報を含み得る。
ネットワークアダプタデバイス420は、例えば、信頼不可能なデータグラムトランスポート424及び緩和された信頼可能なデータグラムトランスポート426など、1つ以上のトランスポートサービスを提供し得る。ネットワークアダプタデバイス420は、図面には例示されていない他のトランスポートサービスを提供し得る。いくつかの実装では、緩和された信頼可能なデータグラムトランスポート426は、信頼可能な接続タイプの動作を提供するように構成され得る。これらの実装では、緩和された信頼可能なデータグラムのコンテキストを単一のキューペアに割り当ててよく、トランスポートコンテキストを1つのローカルユーザアプリケーションと1つのリモートユーザアプリケーションとの間の1つの通信チャネルに対して排他的にする。
上記の通り、緩和された信頼可能なデータグラムトランスポート426を使用するメッセージ転送は、「コネクションレス型」であってよく、つまり、ユーザアプリケーションがターゲットアプリケーションとの明確な接続の確立を必要としない可能性がある。代わりに、接続管理は緩和された信頼可能なデータグラムトランスポート426によって処理され得る。
追加的には、緩和された信頼可能なデータグラムトランスポート426は、その宛先に順不同で到着し得るパケットの配信を保証し得る。これは、パケットが送信元システムで発信されたときと同じ順序でパケットを並び替える必要があり得ることを意味し得る。従来、パケットの順序付け及び信頼性動作は、ネットワークアダプタまたはホストデバイスソフトウェアのいずれかで、共に処理されていた。例えば、パケット配信を保証する最も信頼可能なトランスポートサービスタイプは、通常、パケットをドロップしないネットワークに依存する。ドロップされたパケットは、(1つ以上のパケットが到着していないため)結果的にパケットが順不同で到着する可能性があり、その場合、ネットワークアダプタデバイスは、順不同のパケットを拒否し得るか、パケットのストリーム全体の再送を必要とし得る。
別の代替策は、ネットワークアダプタデバイスが、順不同で到着したパケットを並び替えることである。パケットの並び替えは、しかしながら、一般的に処理が集中する動作である。ネットワークアダプタデバイスは、通常、安価で低出力のプロセッサを有する。ゆえに、順不同のパケットを処理しようとする実装では、通常、ホストデバイスのソフトウェア内でパケットを並び替え、通常、ホストデバイスによって提供される高出力のプロセッサを利用する。これらの実装では、ソフトウェアも、欠落パケットの追跡及び再要求などの動作を含め、信頼可能なパケット配信を確実にしようとする。しかしながら、上述の通り、プロセッサの関与はレイテンシに悪影響を与え得る。ゆえに、信頼可能なパケット配信を追求する実装は、ネットワークアダプタデバイスの信頼性の態様を実施しており、結果的に、パケットの順序通りの配信を要求する。
図4のシステム400の例などのシステムは、緩和された信頼可能なデータグラムトランスポートを使用して、パケットの並び替え及び信頼性動作を分離してよく、最も効率的に処理され得るシステム内のポイントでそれらを実行する。例えば、システム400は、パケットの信頼可能な配信がネットワークアダプタデバイス420によって処理されるように構成されてよく、ネットワーク430を通じてパケットを転送することに固有のレイテンシを最小化するのに適している可能性がある。さらに、パケットの並び替えは、ユーザアプリケーション404a〜b及び/またはドライバプログラム408、416によって処理されてよく、それぞれがホストデバイス410のプロセッサ上で実行されてよい。
信頼可能な順不同のパケット配信を完了し得る方法を説明する前に、接続確立をまず説明する。緩和された信頼可能なデータグラムトランスポートを使用するシステムでは、トランスポートサービスは、コンピューティングクラスタによって提供されたネットワークを通じて互いに通信するユーザアプリケーションに対して「コネクションレス型」のメッセージ転送を促進し得る。
I.「コネクションレス型」のメッセージの転送
図5A〜図5Bは、ユーザアプリケーション504aがメッセージを別のアプリケーションに送信するために後続的に使用可能なアドレスハンドルをユーザアプリケーション504aが取得し得るプロセス500の一例を例示する。プロセス500は、ユーザアプリケーション504aによって明確な接続が確立されない点において、信頼可能なデータグラム及び信頼不可能なデータグラムのトランスポートによって使用されるプロセスと同様であり得る。プロセス500は、トランスポートサービス(ここでは、緩和された信頼可能なデータグラムトランスポート)が他のシステムへの接続を確立及び保持するように機能し得るという点において、信頼可能なデータグラム及び信頼不可能なデータグラムによって使用されるプロセスとは異なり得る。さらに、この接続の保持は、明確な接続の代わりにアドレスハンドルが提供されるユーザアプリケーションからは分からない。ユーザアプリケーション504aは同じプロセス500を使用して、ユーザアプリケーションが通信しようとする各宛先のアドレスハンドルを取得し得る。図5Aは、ホストデバイス502上で実行している任意のプロセスによって宛先が以前に登録されていない場合のプロセス500の一部を例示する。図5Bは、宛先が以前に登録されていた場合を例示する。
いくつかの実装では、ユーザアプリケーション504aは、ネットワーク上でメッセージを送信するためにアドレスハンドルを使用することはできない。例えば、ユーザアプリケーション504aは、メッセージを送信するために、宛先アドレスまたは他の宛先情報を使用し得る。これらの場合、ユーザアプリケーション504aは、アドレスハンドルを提供する代わりに、宛先情報をネットワークアダプタデバイスに直接提供し得る。これらの実装では、少なくともいくつかの宛先に対して、ユーザアプリケーション504aは図5A〜図5Bに例示するプロセス500を使用することができない。ユーザアプリケーションがメッセージを送信するためにアドレスハンドル以外の宛先情報を使用する場合については、図6A〜図6Bに関してさらに説明する。
図5Aに例示する通り、プロセス500は、ネットワークアダプタデバイス520と通信するホストデバイス502を伴い得る。ホストデバイス502は、図面には例示していないが、1つ以上のプロセッサ、メモリサブシステム、周辺装置及びその他などの構成要素を含む、汎用コンピューティングシステムであり得る。ホストデバイス502は、例示のユーザアプリケーション504aを含む、1つ以上のユーザアプリケーションを実行中であり得る。これらのユーザアプリケーションは、図面には例示していない1つ以上の仮想マシンで動作中であり得る。ホストデバイス502はさらに、例示のドライバプログラム508を含む、1つ以上のドライバプログラムを実行中であり得る。ドライバプログラム508は、オペレーティングシステムのカーネル内で実行中であり得る。カーネル内で動作することにより、物理メモリ及びホストデバイスのハードウェアへのアクセスを含む、さらなるアクセス権限がドライバプログラムに提供され得る。代替的または追加的には、ドライバプログラム508はユーザ空間で実行中であり得、ユーザ空間ではより少ないアクセス権限を有する可能性があり、安全性が低い可能性がある。
ネットワークアダプタデバイス520は、ネットワークと通信するための汎用ネットワークインタフェースカードであり得る。代替的または追加的には、ネットワークアダプタデバイス520は、特定のタイプのネットワーク(例えば、InfiniBandネットワーク)と通信するための専用カードであり得る。ネットワークアダプタデバイス520は、管理モジュール522を含み得る。管理モジュール522は、例えば、ファームウェアまたはFPGAもしくはASICなどの集積回路であり得る。ネットワークアダプタデバイス520はさらに、ネットワークアダプタデバイス520の動作に関連するデータを格納するためのメモリを含み得る。代替的または追加的には、管理モジュール522にメモリを統合してよい。いくつかの実装では、ネットワークアダプタデバイス520はRDMAタイプの機能性(つまり、カーネルバイパス機能性)を含み得る。いくつかの実装では、ネットワークアダプタデバイス520は、ペリフェラルコンポーネントインターコネクト(PCI)タイプのデバイスであり、PCIバス上でホストデバイス520と通信する。いくつかの実装では、以下に説明するネットワークアダプタデバイス420の動作は、集積回路デバイスまたは集積回路デバイスの集合体で実施され得る。例えば、様々な実装では、ネットワークアダプタデバイスの動作は、SoC、FPGAまたはASICあるいはこれらのデバイスの組み合わせで実装され得る。
宛先ノードと通信するためのアドレスハンドルを取得するために、ユーザアプリケーション504aは、まず宛先のアドレスを決定する。宛先は、ほとんどの場合、ネットワークに接続された別のシステム上で実行中のアプリケーションである。宛先のアドレスは、ネットワーク上のシステムのインターネットプロトコル(IP)または媒体アクセス制御(MAC)アドレスなどの一般的なアドレスであり得る。代替的または追加的には、宛先アドレスは、特定のターゲットアプリケーションを識別するアドレスなど、特定のものであり得る。代替的または追加的には、宛先アドレスは、一般的なアドレスと特定のアドレスとの中間に該当し得る。
ユーザアプリケーション504aは、標準的なメカニズムを使用して宛先アドレスを取得し得る。例えば、いくつかの実装では、ユーザアプリケーション504aは、ユーザが提供する入力から、及び/または、ドメインネームシステム(DNS)サーバによって提供されるなどの標準的なアドレス解決メカニズムによって、宛先アドレスを取得し得る。いくつかの実装では、ユーザアプリケーション504aは、ターゲットアプリケーションとメッセージを交換することによって宛先アドレスを取得し得る。例えば、ユーザアプリケーション504aは、ネットワーク上で動作中の標準ソケットシステムを使用し、それ自体のアドレスをターゲットアプリケーションのアドレスと交換し得る。別の例として、ユーザアプリケーション504aは、指定または専用のサイドバンドネットワークを使用して、この情報を交換し得る。いくつかの実装では、ユーザアプリケーション504aが宛先アドレスを解明する方式は、特定のアプリケーションに固有である。
宛先アドレスを決定すると、ユーザアプリケーション504aは、アドレスハンドルの要求550をドライバプログラム508に送信し得る。この要求550は、少なくとも宛先アドレスを含み得る。いくつかの実装では、ドライバプログラム508は、ホストデバイス502上で実行中の全てのプロセスのアドレスハンドルを一括管理するように構成され得るカーネルドライバプログラムである。他の実装では、ドライバプログラム508は、通常はデバイスドライバで利用可能な標準的なアクセス権限を備えた、ユーザ空間デバイスドライバである。いくつかの実装では、要求550はまずデバイスドライバに行き、次いでカーネルドライバに行き得る。他の実装では、要求550は、ユーザアプリケーション504aからカーネルドライバに直接行き得る。
ドライバプログラム508は、ステップ552において、アドレスハンドル要求550の宛先アドレスが「新しい」かどうか、つまり、ドライバプログラム508がこの宛先アドレスを以前に登録しているかどうかを判断し得る。ドライバプログラム508は、ホストデバイス502上で実行中のプロセスによって現在使用されている宛先アドレスのリストまたはディレクトリ(一般的に「アドレスマップ」514と呼ばれる)を保持し得る。いくつかの実装では、アドレスマップ514は、ネットワークアダプタデバイス520によって保持され得る。ドライバプログラム508は、アドレスハンドル要求550を受信すると、要求が宛先アドレスを含むかどうかを調査するためにアドレスマップ514を検証し得る。図5Aの例では、ドライバプログラム508は、アドレスマップ514に宛先アドレスを発見することができず、ゆえに宛先アドレスが新しいと判断する。
宛先アドレスが新しいと判断すると、ドライバプログラム508は、ネットワークアダプタデバイス520上で実行中の管理モジュール522に、新しいアドレスハンドルの要求554を発行し得る。この新しいアドレスハンドル要求554は宛先アドレスを含み得る。管理モジュール522は、例えば、ユーザアプリケーション504a(またはユーザアプリケーション504aを実行中の仮想マシン)が、ターゲットアプリケーションが発見され得るシステムと通信することが許可されていることを確認するなど、宛先アドレスのチェックを実行し得る。管理モジュール522は、次いで、ネットワークアダプタデバイス520上のメモリ528に宛先アドレスを格納し得る。
いくつかの実装では、管理モジュール522は、ネットワークアドレスマップオブジェクト556をメモリ528に格納し得る。ネットワークアドレスマップオブジェクトは、宛先アドレスに関連する情報を格納し得るデータ構造のインスタンスである。例えば、ネットワークアドレスマップオブジェクト556は、宛先アドレスを含み得る。いくつかの実装では、ネットワークアドレスマップオブジェクト556は、管理モジュール522によって生成された事前生成パケットヘッダを含み得る。事前生成パケットヘッダは、送信元アドレス及び宛先アドレス、及び/またはパケットがネットワークを通過して宛先システムに向かうのに必要となり得るルーティング情報、及び/または他のヘッダ情報を含み得る。事前生成パケットヘッダは、後にパケットを迅速に形成する際に使用するために格納され得る。いくつかの実装では、ネットワークアドレスマップオブジェクトは事前生成された内部及び外部ヘッダを含み得る。内部及び外部ヘッダは、1つのプロトコルに従って生成されたパケットが、別のプロトコルのためにヘッダにカプセル化されている場合に使用され得る。カプセル化は、ネットワークトンネリング、つまり、異なるネットワークプロトコル用に構成されたネットワーク上で1つのプロトコルに従って構成されたパケットを送信するときに生じ得る。パケットをカプセル化して外部ヘッダを提供することにより、外部ネットワークプロトコルに対応するように内部ヘッダを変更する必要はない。事前生成された内部及び外部ヘッダは、ネットワークアドレスマップオブジェクトと共に格納されてよい。
宛先アドレスが新しいため、管理モジュールは、追加的または代替的には、トランスポートコンテキスト524を構成し得る。トランスポートコンテキスト524は、宛先アドレスに関連するシステムとの接続を確立して保持する。トランスポートコンテキストは、ネットワークに接続されたそれぞれの潜在的な宛先システムに対して構成され得るが、一般的にトランスポートコンテキストは必要になるまで構成されない。トランスポートコンテキストは、ほとんどの実装において、2つのアプリケーション間またはアプリケーションとシステムとの間というよりは、2つのシステム間の接続を表す。トランスポートコンテキスト524を構成することは、宛先システムとの接続を確立することを含み得る。この接続は、例えば、ネットワークアダプタデバイス520と宛先システムとの間のメッセージの交換によって確立され得る。一旦構成されると、トランスポートコンテキスト524は、接続の状態を監視して保持し得る。接続の保持は、とりわけ、宛先システムに関連するネットワークアドレスマップオブジェクトを格納するか、あるいは別様には追跡することを含み得る。上記の通り、宛先アドレスは宛先システムのアドレスよりも固有であり得、したがって、所与のトランスポートコンテキストに対して2つ以上のネットワークアドレスマップオブジェクトが存在し得る。トランスポートコンテキスト524には、信頼不可能なデータグラムまたは緩和された信頼可能なデータグラムなどのトランスポートサービスタイプが割り当てられ得る。トランスポートコンテキストは以下でさらに詳細に説明される。
宛先アドレスまたはネットワークアドレスマップオブジェクト556を格納し、及び/またはトランスポートコンテキスト524を構成した後、管理モジュール522は、次に、アドレスハンドル558をドライバプログラム508に返送し得る。アドレスハンドル558は、宛先アドレスまたはネットワークアダプタデバイス520のメモリ528に格納されたネットワークアドレスマップオブジェクト556を参照する参照先、ポインタ及び/またはインデックスであり得る。ドライバプログラム508は、宛先アドレスによって発見され得るドライバプログラム508のアドレスマップ514に、アドレスハンドル558を格納し得る。いくつかの実装では、ネットワークアダプタデバイス520は、アドレスマップ514を管理してよく、この場合、管理モジュール522は、アドレスマップ514にアドレスハンドルを格納してよい。ドライバプログラム508が宛先アドレスを認識しているため、ここで宛先アドレスは「登録された」と考えられ得る。ドライバプログラム508は次に、アドレスハンドル558をユーザアプリケーション504aに送信し得る。ユーザアプリケーション504aは、ほとんどの場合、後の使用のためにアドレスハンドル558を格納するか、別様には保持し得る。
前に記した通り、図5Aは、ドライバプログラム508にまだ登録されていない宛先のアドレスハンドルを、ユーザアプリケーション504aが要求した場合を例示する。図5Bは、ドライバプログラム508に既に登録されている宛先アドレスのアドレスハンドルを、ユーザアプリケーション504bが要求する例を例示する。図5Aと同様に、図5Bでは、ユーザアプリケーション504bはまず、ユーザアプリケーション504bが通信しようとする宛先の宛先アドレスを決定し得る。ユーザアプリケーション504bは、図5Aに例示するのと同じユーザアプリケーション504aであり得るか、または同じホストデバイス502上で実行中の異なるユーザアプリケーションであり得る。
図5Bに戻ると、宛先アドレスを決定すると、ユーザアプリケーション504bは、ドライバプログラム508にアドレスハンドルの要求550を送信し得る。この例では、ドライバプログラム508は、ステップ552において、要求550で送信された宛先アドレスを検証してよく、宛先アドレスが宛先マップ514に発見されると判断してよい。これは、宛先アドレスがドライバプログラム508に既に登録されていることを意味する。これは、さらに、図5Aの場合のように、アドレスハンドルを提供するためにネットワークアダプタデバイス520にアクセスする必要がないことを意味し得る。いくつかの実装では、アドレスマップ514はネットワークアダプタデバイス520によって保持され、この場合、ドライバプログラム508は、ネットワークアドレスマップ520に宛先アドレスを検索するように求め得る。これらの実装では、ネットワークアダプタデバイス520は、宛先アドレスが以前に登録されていると判断し、アドレスハンドル558をドライバプログラム508に提供し得る。
図5Bでは、宛先アドレスが以前に登録されていると判断されると、ドライバプログラム508は、次いで、アドレスマップ514に格納された情報を使用してアドレスハンドル558を提供し得る。例えば、アドレスマップ514は、参照先、ポインタ及び/またはインデックスを格納してよく、ドライバプログラム508は、格納された参照先、ポインタまたはインデックスを参照する新しいアドレスハンドル558を生成してよい。アドレスハンドル558はユーザアプリケーション504bに返送されてよく、ユーザアプリケーション504bはアドレスハンドル558をその後の使用のために格納し得る。
図6A〜6Bは、ユーザアプリケーション604が、図5A〜5Bに従って取得したアドレスハンドル658を使用してメッセージを送信し得るプロセス600の一例を例示する。いくつかの実装では、ユーザアプリケーション604はアドレスハンドル658を使用できず、その代わりに他の宛先情報を使用してメッセージを送信し得る。これらの実装は、以下でさらに詳細に説明される。
図6A〜図6Bでは、プロセス600は、ホストデバイス602及びネットワークアダプタデバイス620を伴い得る。ホストデバイス602は、図面には例示していないが、1つ以上のプロセッサ、メモリサブシステム、周辺装置及びその他などの構成要素を含む、汎用コンピューティングシステムであり得る。ホストデバイス602は、例示のユーザアプリケーション604を含む、1つ以上のユーザアプリケーションを実行中であり得る。ネットワークアダプタデバイス620は、ネットワーク630と通信するための汎用ネットワークインタフェースカード及び/または特定のタイプのネットワークと通信するための専用カードであり得る。いくつかの実装では、ネットワークアダプタデバイスの動作は、集積回路デバイス及び/または集積回路デバイスの集合体で実施され得る。ネットワークアダプタデバイス620はさらにメモリ628を含み得るが、いくつかの実装では、メモリ628は、ネットワークアダプタデバイス620にインストールされたファームウェア(図示せず)に組み込まれる。いくつかの実装では、ネットワークアダプタデバイス620はメモリを有さないか、または少量のメモリしか有さず、情報を格納するためにホストデバイス602上のメモリを使用し得る。
図6Aでは、ユーザアプリケーション604は、ネットワーク上の異なるシステム上で動作中の別のアプリケーションに送信しようとするメッセージ660を有し得る。この例では、ユーザアプリケーション604は、ターゲットアプリケーションに関連するアドレスハンドル658を以前に取得している。メッセージ660をターゲットアプリケーションに送信するために、ユーザアプリケーション604は、アドレスハンドル658と共にメッセージ660をネットワークアダプタデバイス620に送信し得る。いくつかの実装では、メッセージ660はまず、ネットワークアダプタデバイス620に送信される前に、デバイスドライバに送信され得る。
メッセージ660を受信すると、ネットワークアダプタデバイス620は、アドレスハンドルを使用して、メッセージ660のトランスポートコンテキスト624を決定し得る。トランスポートコンテキスト624は、一般的に、メッセージ660を受信するシステムとの接続を保持する。接続の保持は、例えば、パケットの送信、未処理パケットの状態の追跡、ならびに以下でさらに詳細に説明する、ターゲットシステムまでのネットワークを通る経路の設定及び解除を含み得る。
トランスポートコンテキスト624はさらに、現在のアドレスハンドルに関連するネットワークアドレスマップオブジェクト656など、メモリ628に格納された宛先関連情報を追跡し得る。ネットワークアドレスマップオブジェクト656は、メッセージ660のパケットを生成するための情報を提供し得る。例えば、ネットワークアドレスマップオブジェクト656は、宛先アドレス(例えば、ターゲットシステムのIPアドレスもしくはMACアドレスまたはターゲットアプリケーションのアドレス)を含み得る。代替的または追加的には、ネットワークアドレスマップオブジェクト656は、パケットがターゲットシステムに到達するために必要なアドレス指定情報及び/またはルーティング情報を含む事前生成ヘッダを含み得る。いくつかの実装では、ネットワークアダプタデバイス620はメモリを有することができない、または宛先関連情報などのデータを格納するためにホストデバイス602上のメモリを使用してよい。これらの実装では、トランスポートコンテキスト624がネットワークアドレスマップオブジェクト656を検索するとき、トランスポートコンテキスト624はホストデバイス602のメモリからネットワークアドレスマップオブジェクト656を読み取る要求をホストデバイス602に発行し得る。
ネットワークアドレスマップオブジェクト656など、メモリ656に格納される宛先関連情報を使用して、ネットワークアダプタデバイスは、メッセージ660の全てまたは一部を包含する、1つ以上のパケット662を生成し得る。ネットワークアドレスマップオブジェクト656が事前生成パケットヘッダを提供する実装では、パケット662は、事前生成パケットヘッダをペイロードの先頭に追加することによって生成されてよく、ペイロードはメッセージ660のデータを含む。1つ以上のパケット662を生成した後、ネットワークアダプタ620は、次いで、ネットワーク630上で1つ以上のパケットを送信し得る。
いくつかの場合、ターゲットアプリケーションは、メッセージ660に応答することが求められる。例えば、メッセージ660が読み取りトランザクションであり、ターゲットアプリケーションが有するいくつかの情報を要求している場合、ターゲットアプリケーションは読み取りデータに応答することが求められ得る。別の例として、メッセージ660は、1つ以上の動作を実行してこれらの動作の結果を返送するため、ターゲットアプリケーションに対するコマンドであり得る。
図6Bは、図6Aに従って送信されたメッセージ660に応答して送信された応答664の受信の一例を例示する。図6Bでは、応答664は、ネットワーク630上でネットワークアダプタデバイス620によってパケットの形態で受信され得る。ネットワークアダプタデバイス620は、ホストデバイス602上で実行中のユーザアプリケーションによって送信されたメッセージに応答して送信された多数の応答を受信し得る。ネットワークアダプタデバイス620及び/またはホストデバイス602は、ゆえに、どのユーザアプリケーションが所与の応答664を受信すべきかを識別し得る。パケットヘッダは、応答664の送信元(例えば、リモートサーバ及び/またはリモートアプリケーションのアドレス)及び応答の宛先(例えば、ローカルサーバ及び/またはユーザアプリケーション604)を識別する情報を含み得る。パケットペイロードは、応答664のデータを含み得る。
応答664は、応答664を送信したシステム用に構成され得るトランスポートコンテキスト624によって受信され得る。トランスポートコンテキスト624を使用して、ネットワークアダプタデバイスは、ネットワーク630上で受信したパケットから応答664のデータを解凍し得る。いくつかの場合、ネットワークアダプタデバイス620は、ネットワーク630上で受信した複数の応答パケットから応答メッセージを構築し得る。ネットワークアダプタデバイス620はさらに、応答664から、送信元アドレス、つまり、応答664を送信したシステム及び/またはプロセスのアドレスを抽出し得る。この例では、送信元アドレスは、図6Aのメッセージ660を送信するために使用された宛先アドレスと同じである。いくつかの実装では、応答664は、応答の送信元及び/または応答664が対応するメッセージ660のいずれかを識別するいくつかの他の情報を含み得る。
図6Bに戻ると、ネットワークアダプタデバイス620は、送信元アドレス(または応答664を識別する他の情報)を使用して、送信者アドレスに対応するネットワークアドレスマップオブジェクト656をメモリ628に配置し得る。ネットワークアドレスマップオブジェクト656は、メッセージ660を送信するために使用されたアドレスハンドルを提供し得る。このアドレスハンドルは、メッセージ660を送信したユーザアプリケーション604を識別し得る。アドレスハンドルは、応答664と共に、ホストデバイスに提供されてよく、ホストデバイス602は、(例えば、ドライバプログラムを使用して)応答メッセージ666をユーザアプリケーション604に送り得る。代替的には、いくつかの実装では、応答メッセージ666は、アドレスハンドルではなく、ネットワークからの応答664に付随していた送信元アドレスと共にホストデバイス602に提供され得る。ホストデバイスは次いで、代わりに、送信元アドレスを使用して、応答メッセージ666をユーザアプリケーション604に送ることができる。
ユーザアプリケーション604は、アドレスハンドルを使用して、応答メッセージ666がどこから来たか、及び/または応答メッセージ666がどのメッセージに応答しているかを判断し得る。前に記した通り、アドレスハンドルは、最初のメッセージ660が送信されたときに使用されたアドレスハンドルと同じであってよく、この場合、ユーザアプリケーション604は、単純な検索メカニズムを使用して、応答メッセージ666がどのメッセージに対するものかを判断することができ得る。いくつかの場合、ユーザアプリケーション604は、例えば、メッセージ660の全てまたは一部を再送するか、または宛先との新しい通信を開始するなど、応答メッセージ666に応答し得る。
上記の通り、いくつかの実装では、ユーザアプリケーション604は、アドレスハンドル以外のアドレス情報を使用してメッセージを送信し得る。これらの実装では、ユーザアプリケーション604は、図6A〜図6Bに例示するプロセス600と同様のプロセスを使用し得る。例えば、図6Aでは、ユーザアプリケーション604は、ネットワーク上の異なるシステム上で動作中の別のアプリケーションに送信するためのメッセージを有し得る。この例では、ユーザアプリケーション604は宛先アプリケーションに対するアドレスハンドルを有さないが、アドレスハンドルを取得するために使用する宛先情報を有し得る。例えば、ユーザアプリケーション604は、(例えば)IPアドレス及び/またはMACアドレスの形態で、宛先システムに対するネットワークアドレスを有し得る。別の例として、ユーザアプリケーションはフロー識別子を有し得る。フローは、通常は互いに関連しており、システムと別のシステムとの間を移動するパケットの流れを表す。フロー識別子は、同じフローに属するパケットを識別し得る。フロー識別子は、パケットのヘッダに含まれ得る値の形態をとり得る。代替的または追加的には、フローは、送信元システムのアドレス、宛先システムのアドレス、パケットが送信される送信元システムのポート及び/またはパケットが受信される宛先システムのポートなど、ネットワークアドレスによって識別され得る。いくつかの場合、フロー識別子は、送信元及び宛先及び/またはポートを入力として使用する数学演算の結果である。
ユーザアプリケーション604は、ゆえに、宛先情報を使用してメッセージ660を送信し得る。ユーザアプリケーション604は、宛先情報と共にメッセージ660をネットワークアダプタデバイス620に送信し得る。ネットワークアダプタデバイス620は、適切なトランスポートコンテキスト624を決定するために宛先情報を使用し得る。例えば、ネットワークアダプタデバイス620は、ネットワークアドレスまたはフロー識別子を使用してトランスポートコンテキスト624を検索するように構成され得る。一旦ネットワークアダプタデバイス620がトランスポートコンテキスト624を決定すると、ネットワークアダプタデバイス620は、トランスポートコンテキスト624を使用して、パケットの生成及びネットワーク630への送信を行い得る。
図5A〜図5B及び図6A〜図6Bに例示するようなコネクションレス型のメッセージ転送プロセス500、600を使用するように構成される計算クラスタは、ネットワークアドレスをより効率的に管理する可能性があり、メモリ要求がより少なくなる可能性があり、拡張性をより高める可能性がある。
コネクションレス型のメッセージ転送で提供されるアドレスハンドルは、ホストデバイスにおけるアドレス管理を簡略化し得る。コネクションレス型のメッセージ転送方法を使用しない実装では、ホストデバイス上で実行中のソフトウェアにアドレス管理の負担の多くが課せられ得る。例えば、ユーザアプリケーションまたはドライバプログラムはパケットヘッダを生成する必要があり、送信元及び宛先情報の追跡を必要し得る。別の例として、応答が受信されると、ドライバプログラムまたはユーザアプリケーションは、応答の送信元及び宛先を識別するためにパケットヘッダ全体を読み取る必要があり得る。対照的に、コネクションレス型のメッセージ転送方法を使用する実装では、一旦宛先アドレスが登録されると、ユーザアプリケーション及びドライバプログラムは、宛先を参照するためのアドレスハンドルのみの使用を必要とする。さらに、ホストデバイス602によって応答が受信されると、応答はそのアドレスハンドルによって迅速に識別することができる。
アドレスハンドルはさらに、あるシステム上で実行中の多数のプロセスが異なるシステム上で実行中の多数のプロセスと通信しているときに、必要なメモリ量を削減し得る。ユーザアプリケーションが通信しようとする各宛先に対して、ユーザアプリケーションは、個別のアドレスハンドルを取得して保持し得る。ただし、全てのユーザアプリケーションが宛先と通信している可能性があるため、各宛先に対して、1つのみのネットワークアドレスマップオブジェクトを作成して格納する必要がある。ネットワークアダプタでのメモリ使用は、ゆえに、最小化され得る。いくつかの実装では、ドライバプログラムは、アドレスハンドルを取得するためにホストデバイス上で実行中の全てのプロセスによって使用され得るアドレスマップを保持し得るため、ドライバプログラムに必要なメモリがさらに最小化され得る。追加的には、一旦宛先アドレスがドライバプログラムに登録されると、同じ宛先と通信するために行われる他のユーザアプリケーションへのアドレスハンドルの提供は、ネットワークアダプタデバイスとの通信を必要とすることなく迅速に行われ得る。
コネクションレス型のメッセージ転送はさらに、より高い拡張性を有するコンピューティングクラスタを提供し得る。上記の通り、接続型のトランスポートサービスタイプで発生し得る問題の1つは、ネットワークを通じて通信しようとするプロセスの数が増加するにつれ、接続数も増加するということである。対照的に、コネクションレス型のメッセージ転送方法を使用する実装では、ユーザアプリケーションは接続を確立する必要はなく、代わりにアドレスハンドルを取得する。ネットワークアダプタデバイスは他のシステムとの接続を確立するが、ほとんどの場合、ネットワーク上の任意の2つのシステム間で1つの接続しか確立されない。1つのシステムからの全てのトラフィックは、次いで、単独接続を使用して他のシステムに到達し得る。ゆえに、プロセスの数が増加しても接続数が増加する可能性は低く、クラスタに追加されるノードが増加した場合にのみ接続数は増加する。
II.信頼可能な順不同のパケット配信
上述の通り、「コネクションレス型」のメッセージ転送は、緩和された信頼可能なデータグラムトランスポートサービスによって促進され得る。このセクションでは、メッセージの処理方法、ネットワークとの通信の管理方法、信頼可能な配信の提供メカニズムを含む、緩和された信頼可能なデータグラムトランスポートを使用したメッセージ転送の管理について詳細に説明する。パケットが順不同で到着し得る方法及び理由についても説明する。
図7A〜7Bは、緩和された信頼可能なデータグラムトランスポートサービスを含むシステムに対して実装され得る通信スタック700の一例を例示する。図7Aは、通信スタックの送信側の一例を例示し、図7Bは、通信スタックの受信側の一例を例示する。これらの例では、接続は、例えば、図5A〜図5Bに関して説明したプロセス500を使用して、以前に確立されている場合がある。例えば、図7A〜図7Bでは、(この例によれば)各送信側トランスポートコンテキスト716a〜bが、対応する受信側トランスポートコンテキスト768a〜bとの接続を管理した状態で、1つ以上の送信側トランスポートコンテキスト716a〜b及び受信側トランスポートコンテキスト768a〜bが構成されている場合がある。図7A〜図7Bの例では、1つのシステムを送信システムとして例示し、別のシステムを受信システムとして例示しているが、便宜上、「送信」及び「受信」という分類を割り当てているにすぎない。さらに、ここで受信側システムと呼ばれるシステムは送信システムとしても機能することができ、ここで送信システムと呼ばれるシステムは受信システムとして機能することが理解される。
図7Aの例では、通信スタック700の例の送信側が例示されている。この例では、通信スタックの送信側は、2つのユーザアプリケーション704a〜b、いくつかのキューペア710a〜d及びネットワーク730上で1つ以上の宛先システム718a〜bと通信している1つ以上の送信側トランスポートコンテキスト716a〜bを含む。図7Aに例示する例は、簡潔にするために2つのユーザアプリケーション704a〜bを表しており、例示の仮想マシン702及び/または仮想マシン702をホストしているシステムはより多数またはより少数のユーザアプリケーションを有することがあり、それぞれが類似する通信スタックを使用するように構成されることが理解される。
この例では、ユーザアプリケーション704a〜bは、ホストデバイスに対して構成された仮想マシン702内で実行中であり得る。各ユーザアプリケーション704a〜bは、OFEDタイプのverbsライブラリなどの標準ライブラリ706a〜bを使用して、ネットワーク730と通信し得る。いくつかの実装では、各ユーザアプリケーション704a〜bは、異なる標準ライブラリ706a〜bを使用中であり得る。標準ライブラリ706a〜bは、メッセージを送信するための「ポスト送信」、メッセージを受信するための「ポスト受信」及び完了キューのコンテンツをチェックするための「ポーリング」など、ネットワークコマンドの共通セットを提供し得る。標準ライブラリ706a〜bはさらに、ドライバプログラム708a〜bへのインタフェースを提供し得る。ドライバプログラム708a〜bは、仮想マシン702のオペレーティングシステムのカーネル及び/またはネットワークアダプタデバイスを含むシステムのハードウェアと相互作用するためのコマンドを提供し得る。ドライバプログラム708a〜bはカーネルドライバであってよく、この場合、ドライバプログラム708a〜bはより高いアクセス権限を有してよい。代替的には、ドライバプログラム708aは、ユーザ空間ドライバであってよく、より低いアクセス権限を有してよい。いくつかの実装では、各ユーザアプリケーション704a〜bは、異なるドライバプログラム708a〜bを使用中であり得る。他の実装では、両方のユーザアプリケーション704a〜bは同じドライバプログラム708a〜bを使用中であり得る。いくつかの実装では、ユーザアプリケーション704a〜bは、標準ライブラリ706a〜bを介すことなく、ドライバプログラム708a〜bと直接通信し得る。
ネットワーク730と通信するために、各ユーザアプリケーション704a〜bは1つ以上の「通信エンドポイント」を割り当てられ得る。通信エンドポイントは、ユーザアプリケーション704a〜bとの論理的な関連を表し、ユーザアプリケーション704a〜bによって送信されたメッセージ内のユーザアプリケーション704a〜bを識別するために使用され得る。つまり、通信エンドポイントの識別子は、少なくとも部分的に、メッセージの送信者アドレスとして使用され得る。通信エンドポイントは異なる方法で実装され得る。例えば、いくつかの実装では、通信スタック700の例では、通信エンドポイントは、それぞれ、キューペア710a〜dにマッピングされる。これらの実装では、通信エンドポイントは、通常は番号であるキューペア識別子によって識別され得る。さらに、これらの実装では、キューペア識別子は、少なくとも部分的に、ユーザアプリケーション704a〜bによって送信されたメッセージの送信者アドレスとして使用され得る。ユーザアプリケーション704a〜bに割り当てられた通信エンドポイントは、ドライバプログラム708a〜bによって保持され得る。通信エンドポイントは、ほとんどの場合、ユーザアプリケーション間では共有されない。
仮想マシン702自体には、ネットワーク730と通信するための1つ以上の仮想インタフェース709a〜bが割り当てられ得る。これらの仮想インタフェース709a〜bは、例えば、仮想マシン702のオペレーティングシステムまたはホストデバイスのオペレーティングシステムによって、仮想マシン702に割り当てられていることがある。各仮想インタフェース709a〜bにはIPアドレスが割り当てられ得る。ネットワーク730と通信するために、ユーザアプリケーション704a〜bは、仮想インタフェース709a〜bのうちの1つ以上を使用し得る。ゆえに、ユーザアプリケーション704a〜bによって送信されたメッセージは、例えば、2つの利用可能な仮想インタフェース709aのうちの1つを使用して、その仮想インタフェースのIPアドレスをメッセージの送信者アドレスとして有し得る。いくつかの実装では、ユーザアプリケーション704a〜bは、ゆえに、この仮想インタフェース709aのIPアドレスによって識別され得る。
ユーザアプリケーション704a〜bがそれ自体を仮想マシン702のオペレーティングシステムのカーネルに登録したとき、及び/またはユーザアプリケーション704a〜bがキューペア710a〜dへの割り当てを要求したとき、及び/またはユーザアプリケーション704a〜bが宛先システム718a〜bとの通信のために最初に登録されたときに、仮想インタフェース709a〜bはユーザアプリケーション704a〜bに割り当てられることがある。いくつかの実装では、2つ以上のユーザアプリケーション704a〜bは所与の仮想インタフェース709a〜bを使用し得る。例えば、図7Aの例では、第1のユーザアプリケーション704aと第2のユーザアプリケーション704bとの両方が第2の仮想インタフェース709bに割り当てられている。
これらの実装及びその他の実装では、ユーザアプリケーション704a〜bは、通信エンドポイントと1つ以上の仮想インタフェース709a〜bとの両方を使用してネットワーク730と通信し得る。これらの実装では、ユーザアプリケーション704a〜bは、通信エンドポイントの識別子(例えば、キューペア番号)と仮想インタフェース709a〜bのIPアドレスとの組み合わせによって識別され得る。さらに、仮想インタフェース709a〜bのIPアドレスと通信エンドポイントの識別子との組み合わせを、ユーザアプリケーション704a〜bによって送信されたメッセージの送信者アドレスとして使用してよい。
上記の通り、(緩和された信頼可能なデータグラムトランスポートを使用する実装を含む)いくつかの実装では、各通信エンドポイントは、個々のキューペア710a〜dにマッピングされ得る。キューペアは、一般的に、ネットワークに送信されるメッセージのための送信キュー712及びネットワーク730から入ってくるメッセージを受信するための受信キュー714を含む。いくつかの実装では、ユーザアプリケーション704a〜bに割り当てられる各通信エンドポイントは、異なるキューペア710a〜dに割り当てられ得る。他の実装では、通信エンドポイント間でキューペアを共有してよいが、これらの実装では、各通信エンドポイントが一意にアドレス指定されて及び識別されることを確実にするよう、制限及び/または追加パラメータを構成に追加する必要があり得る。
多くの場合、キューペア710a〜dは、ネットワークアダプタデバイス上のハードウェアに実装されてよいが、いくつかの場合、キューペア710a〜dはネットワークアダプタデバイス上のソフトウェアに実装されてよく、及び/またはホストデバイス上のソフトウェアに実装されてよく、及び/またはホストデバイスのオペレーティングシステム及び/または仮想マシンを作成及び管理するハイパーバイザ層、ハードウェア層及び/またはソフトウェア層に存在してよい。いくつかの実装では、ネットワークアダプタデバイス(またはオペレーティングシステムまたはハイパーバイザ)は、キューペア710a〜dがユーザアプリケーション704a〜b、ドライバプログラム708a〜bによって要求されるとき、またはユーザアプリケーション704a〜bがドライバプログラム708a〜bを通じて要求するときに、キューペア710a〜dを割り当て得る。いくつかの実装では、接続を設定または解除するためのメッセージ及びユーザアプリケーション間でそれらのそれぞれのアドレスを交換するために渡されるメッセージなどの、1つのキューペア(例えば、キューペア番号0または1)が通信管理メッセージのために確保され得る。
上記の通り、いくつかの実装では、キューペア710a〜d(例えば、第1のキューペア710a)を、特定のユーザアプリケーション704a〜b(例えば、第1のユーザアプリケーション704a)に関連する通信エンドポイントに割り当ててよい。しかしながら、キューペア710aを特定の宛先に関連させる必要はなく、したがって、ネットワーク上の異なる宛先をターゲットとするメッセージをユーザアプリケーション704aから受信してよい。
いくつかの実装では、各仮想インタフェース709a〜bに対するキューペア710a〜dの割り当てを追跡してよい。これにより、例えば、仮想マシン702の移行が容易になり得る。移行は、仮想マシン702を最初にシャットダウンするかどうかに関係なく、仮想マシン702を異なる物理システムに移行するプロセスである。仮想マシン702の移行後、通信エンドポイントは新しいキューペアに割り当てられてよいが、古いキューペア識別子が保持されているため、まだ移動中のパケットでもこれらの通信エンドポイントに到達することができる。
上述の通り、ユーザアプリケーション704a〜bは、ユーザアプリケーション704a〜bに割り当てられている通信エンドポイントの識別によって、ユーザアプリケーション704a〜bによって使用されている仮想インタフェース709a〜bのIPによって、または通信エンドポイントの識別と仮想インタフェース709a〜bのIPとの両方によってのいずれかで識別され得る。ターゲットユーザアプリケーション(例えば、図7Bに例示するユーザアプリケーション754)も同様の様式で識別され得る。
ここで図7Aに例示する特定の例を参照すると、この例では、第1のユーザアプリケーション704aは、3つの例示のキューペア710a〜cによって示されるように、少なくとも3つの通信エンドポイントで構成されている。さらに、第1のユーザアプリケーション704aは、(第1のキューペア710aとの通信を示す実線矢印720aで示すように)1つの通信エンドポイントを1つの利用可能な仮想インタフェース709aに関連させ、さらに(第2のキューペア710b及び第3のキューペア710cのとの通信を示す破線矢印720bで示すように)2つの通信エンドポイントを第2の利用可能な仮想インタフェース709bに関連させている。さらなる例として、第2のユーザアプリケーション704bは、点線矢印726で示すように、第4のキューペア710dへの1つの通信エンドポイントで構成されている。さらに、第2のユーザアプリケーション704bは、この通信エンドポイントを第2の仮想インタフェース709bに関連させている。
この例では、第1のユーザアプリケーション704aは、ネットワーク730上の宛先システム718aに送信するためのメッセージを有し得る。その第1の通信エンドポイントを使用して、第1のユーザアプリケーション704aは、メッセージの宛先システム718aを識別する情報(例えば、アドレスハンドル)と共に、メッセージを、通信エンドポイントに関連する第1のキューペア710aの送信キュー712に配置し得る。メッセージを送信キュー712に配置することは、通常、ホストデバイスプロセッサの支援を必要としない。追加的には、メッセージを送信キュー712に配置することはさらに、ほとんどの場合、ユーザアプリケーション704aがキューペア710aを排他的に使用するため、通常、キューペア710aにアクセスするためのユーザアプリケーション704aによる調整を必要としない。
いくつかの実装では、ネットワークアダプタデバイスはキューペア710a〜dを管理する。ネットワークアダプタデバイスは、キューペア710a〜dを適時に提供することを確実にし得る。代替的または追加的には、ネットワークアダプタデバイスは、各キューペア710a〜dに割り当てられた優先度、トラフィックタイプ及び/またはサービス品質保証に従って、キューペア710a〜dを提供し得る。
図7Aの例を続けると、第1の送信キュー712が提供されるとき、ネットワークアダプタデバイスは、ユーザアプリケーション704aによって送信キュー712に配置されたメッセージを(例えば、ファームウェアまたは集積回路を使用して)削除及び処理してよい。ネットワークアダプタは、メッセージと共に送信キュー712にプッシュされた宛先情報を検証し、適切なトランスポートコンテキスト716a〜bを識別し得る。前述の通り、トランスポートコンテキスト716a〜bはそれぞれ、ネットワーク上の宛先システム718a〜bとの接続を管理する。ほとんどの実装では、トランスポートコンテキスト716aは、1つの送信元システムと1つの宛先システムとの間の接続を表し、特定のユーザアプリケーションまたはキューペアには関連していない。ゆえに、異なるユーザアプリケーションからのメッセージ及び/または異なる通信エンドポイントを通じて送信されたメッセージを、同じトランスポートコンテキスト716aにマッピングし得る。反対に、1つのユーザアプリケーション704aからのメッセージは、異なるトランスポートコンテキスト716a〜bに送られてよい。例えば、例示の例では、第1のユーザアプリケーション704aにマッピングされた第1のキューペア710aからのメッセージは、(実線矢印722aで示すように)第1のトランスポートコンテキスト716aと(破線矢印722bで示すように)第2のトランスポートコンテキスト716bとの両方に送られてよい。同様に、第2のユーザアプリケーション704bにマッピングされる第4のキューペア710dからのメッセージはさらに、(点線矢印728で示すように)両方のトランスポートコンテキスト716a〜bに送られてよい。キューペア710a〜dの各々はさらに、図面には例示しない追加のトランスポートコンテキストにメッセージを送ってよい。特定のメッセージのトランスポートコンテキスト716a〜bは、メッセージと共に提供される宛先情報によって識別されてよい。
いくつかの実装では、トランスポートコンテキスト716a〜b(例えば、第2のトランスポートコンテキスト716b)は、信頼可能な接続トランスポートと同様のトランスポートサービスを提供するように構成され得る。これらの実装では、トランスポートコンテキスト716bは、単一のキューペア(例えば、第2のキューペア710b)に割り当てられ得る。受信側では、対応する受信側トランスポートコンテキスト768bはさらに、単一のキューペア(例えば、第2のキューペア760b)に割り当てられる。トランスポートコンテキスト716b、768bをそれぞれ単一のキューペアに割り当てることは、結果的に、トランスポートコンテキスト716b、768bが信頼可能な接続トランスポートを提供している場合のように、送信ユーザアプリケーション704a及び受信ユーザアプリケーション754が互いに排他的な通信チャネルを有することになり得る。実際には、トランスポートコンテキスト716b、768bは緩和された信頼可能なデータグラムトランスポートを提供していることがあり、これは正に信頼可能な接続と同様のパケット配信を保証し得る。
図7Aの例を続けると、この例では、第1のトランスポートコンテキスト716aが、第1の送信キュー712からポップされたメッセージのトランスポートコンテキストとして識別されている。いくつかの実装では、トランスポートコンテキスト716aは事前生成パケットヘッダを提供し得る。事前生成パケットヘッダは、事前に定義された送信元及び宛先アドレス及び/または送信側から受信側にパケットをルーティングするために必要な他の情報を含み得る。いくつかの実装では、トランスポートコンテキスト716aは、パケットがトンネリングされる状況に対して、事前生成された内部ヘッダ及び外部ヘッダを提供し得る。
前に記した通り、トランスポートコンテキスト716a〜bは、ネットワーク730上の対応する宛先システム718a〜bとの接続を管理し得る。通常、コンピューティングクラスタなどでは、送信側システムから受信側システムまで複数の経路724a〜bが利用可能であり得る。そのような状況では、トランスポートコンテキスト716a〜bは、ネットワーク730を通じて複数の利用可能な経路724a〜bを管理し得る。経路724a〜bの管理は、経路724a〜bの設定及び解除を含むことがあり、経路724a〜bが過度に混雑し、その経路にリンク障害が発生した場合には、経路724a〜bは解除されることがある。追加的には、トランスポートコンテキスト716a〜bはさらに、全ての利用可能な経路724a〜bを通じてパケットを送信しようする。これにより、ネットワークを通る負荷バランシング及び/または混雑した経路または障害のある経路に関する最新情報の保持を支援することを改善し得る。例えば、パケットが宛先システム718aに到達しない場合、または宛先システム718aに到達するのに長い時間がかかる場合には、混雑した経路または障害のある経路が検出され得る。ネットワークを通る複数の経路724a〜bの管理については、図8に関してさらに詳細に説明する。
図7Aに例示された例を続けると、この例では、第1のトランスポートコンテキスト716aは、ネットワーク730上の複数の経路724a上で第1のユーザアプリケーション704aから宛先システム718aにメッセージを送信し得る。いくつかの実装では、ネットワークアダプタデバイスは、トランスポートコンテキスト716aを使用して、メッセージを含む1つのパケットを生成して送信し得る。いくつかの実装では、ネットワークアダプタデバイスは、それぞれがメッセージの一部を包含する複数のパケットを生成し得る。これらの複数のパケットはそれぞれ、宛先システム718aに到達するために同じ経路または異なる経路をとり得る。いくつかの実装では、以下により詳細に説明するように、トランスポートコンテキスト716aは、各パケットが宛先システム718aに確実に配信されるように、各パケットの状態を監視し得る。
図7Bは、通信スタック700の受信側を例示する。送信側と同様に、受信側は、ユーザアプリケーション754、1つ以上のキューペア760a〜b及びネットワーク730上の対応する送信元システム766a〜bと通信する1つ以上の受信側トランスポートコンテキスト772a〜bを含む。図7Bで例示の例において、例示のユーザアプリケーション754は、少なくとも、図7Aの送信側の例に例示する第1のユーザアプリケーション704aと(必ずしも排他的ではなく)通信するように構成されている。ゆえに、図7Bで例示の例において、第1の送信元システム766aは、図7Aに例示する送信側システムに対応する。さらに、図7Bでは、トランスポートコンテキスト768aは、送信元システム766aと通信するように構成されており、送信元システム766aでトランスポートコンテキスト716aとの接続を管理し得る。同様に、第2の送信元システム766bはさらに、図7Aに例示する送信側システムに対応するが、異なる送信側トランスポートコンテキスト716bに接続するように構成される。
図7Bはさらに、メッセージを送信及び受信するためにユーザアプリケーション754がバッファ782を構成し得る方法を例示する。例示されていないが、図7Aの送信側ユーザアプリケーション704aはさらに、必要な場合には、バッファを構成し得る。図7Bでは、ユーザアプリケーション754は、常にではないが通常、仮想マシン752内で実行中であり得る。いくつかの実装では、仮想マシン752は仮想メモリ780を提供してよく、仮想メモリ780では、ユーザアプリケーション754がバッファ782のための空間を割り当て得る。これらの実装では、バッファ782のアドレスは仮想であってよく、仮想マシン752の仮想アドレス空間に存在してよい。多くの場合、仮想アドレスは、オペレーティングシステムのカーネル(仮想マシンのオペレーティングシステムまたはホストデバイスのオペレーティングシステムのいずれか)及びネットワーク730へのアクセスを提供しているネットワークアダプタに登録され得る。カーネルに登録することにより、ゲスト物理アドレスへの仮想アドレスのマッピングが固定されることがあり、バッファ782を含む仮想ページがスワップアウトして何らかの非効率性を生み出すことを防止し得る。カーネルへの登録は、カーネルドライバを通じて行われてよく、仮想マシン752内またはホストシステム上のいずれかで実行される。カーネルドライバは、ネットワークアダプタデバイスに登録情報を渡してよく、ネットワークアダプタデバイスはメモリ登録キーを返送してよい。メモリ登録キーは、後続的に、ユーザアプリケーション754によって、バッファ782のアドレスと共にネットワークアダプタデバイスに渡されてよく、ユーザアプリケーションによって送信されるメッセージを伴う。登録キーを取得するこのプロセスは、ホストデバイスプロセッサからの支援を必要とすることなく、バッファ782に対する読み取り及び書き込みの権限アクセスをネットワークアダプタデバイスに直接的に提供し得る。
いくつかの実装では、ユーザアプリケーション754は、仮想メモリの代わりに、または仮想メモリに加えて、ホストデバイスの物理メモリにバッファ782を割り当て得る。これらの実装では、物理メモリにユーザアプリケーションのアクセスを付与することは、ユーザアプリケーション754を仮想メモリのみに限定することよりも安全性が低いため、ユーザアプリケーション754は特別な信頼状態を有し得る。
いくつかの実装では、ユーザアプリケーション754は、ネットワーク730と通信するために、OFEDタイプのverbsライブラリなどの標準ライブラリ756を使用し得る。標準ライブラリ756は、ドライバプログラム708aへのインタフェースを提供し得る。ドライバプログラム708aは、仮想マシン752のオペレーティングシステムのカーネル及び/またはネットワークアダプタデバイスを含む、システムのハードウェアと相互作用するためのコマンドを提供し得る。いくつかの実装では、ユーザアプリケーション754は、標準ライブラリ756を介することなく、ドライバプログラム758と直接通信し得る。
ネットワーク730と通信するために、この例のユーザアプリケーション754は、1つ以上の通信エンドポイントを割り当てられ得る。いくつかの実装では、各通信エンドポイントは、キューペア760a〜cにマッピングされ得る。これらの実装では、通信エンドポイントは、キューペア番号によって識別され得る。これらの実装では、キューペア番号をユーザアプリケーション754のアドレスとして少なくとも部分的に使用してよい。
仮想マシン752にはさらに、ネットワーク730と通信するための1つ以上の仮想インタフェース759a〜bが割り当てられ得る。各仮想インタフェース759a〜bには、IPアドレスが割り当てられ得る。いくつかの実装では、ユーザアプリケーション754は、ネットワーク730と通信するために仮想インタフェース759a〜bのうちの1つ以上を使用し得る。これらの実装では、ユーザアプリケーション754は仮想インタフェース759aのIPアドレスを使用して、ネットワーク730上の他のシステム及びプロセスに対してユーザアプリケーション754自体を識別し得る。いくつかの実装では、ユーザアプリケーション754は仮想インタフェース759aに割り当てられたIPアドレスと通信エンドポイントの識別子(例えば、キューペア番号)との両方を使用して、ユーザアプリケーション754自体を識別し得る。
図7Aに関して述べた例を続けると、この例では、送信側ユーザアプリケーション704aは、メッセージに対する宛先システム718aを識別する情報と共に、メッセージをキューペア710aの送信キュー712に配置することによってメッセージを送信した。ネットワークアダプタデバイスは、後続的に、送信キュー712を提供し、宛先情報を使用して、メッセージを送信するために使用するトランスポートコンテキスト716aを決定することがある。ネットワークアダプタデバイスは、次いで、トランスポートコンテキスト716aを使用して、メッセージを送信するための1つ以上のパケットを生成することがある。トランスポートコンテキスト716aの支援により、ネットワークアダプタデバイスは、次いで、ネットワーク上の複数の接続724a上で、1つ以上のパケットを宛先システム718aに送信することがある。
図7Bでこの例を続けると、送信システムは、ネットワーク上の第1の送信元システム766aとして表される。送信元システム766aからの1つ以上のパケットは、ネットワーク730上の複数の経路724a上の受信側システムによって受信される。いくつかの実装では、パケットはネットワークアダプタデバイスによって受信される。これらの実装では、ネットワークアダプタデバイスは、どのトランスポートコンテキスト768a〜bがパケットの送信元システム766aに対応するかを判断し得る。ネットワークアダプタデバイスは、適切なトランスポートコンテキスト(この例では、第1のトランスポートコンテキスト768aである)を決めるために、パケット及び/または宛先アドレスに提供された送信元アドレスを使用し得る。いくつかの実装では、ネットワークアダプタデバイスは、送信元アドレスを含むネットワークアドレスマップを有してよく、ネットワークアダプタデバイスは、送信元アドレスを使用してネットワークアドレスマップにインデックスを付け、トランスポートコンテキスト768aを発見してよい。
いくつかの実装では、トランスポートコンテキスト768aは、信頼可能な接続トランスポートと同様のトランスポートサービスを提供するように構成され得る。これらの実装では、ネットワークアダプタデバイスは、信頼可能な接続トランスポートとして構成されたトランスポートコンテキスト768a〜bのテーブルを有し得る。ネットワークアダプタデバイスはさらに、宛先キューペア番号を使用してテーブルにインデックスを付けてよく、テーブルは適切なトランスポートコンテキスト768aを示してよい。いくつかの場合、ネットワークアダプタはさらに、正しいトランスポートコンテキスト768aを決めるために受信パケットに含まれるコンテキスト識別子を使用してよい。
以下により詳細に説明するように、トランスポートコンテキスト768aは、各パケットの状態を監視して、送信元システム766aシステムによって送信された各パケットが受信されることを確実にし得る。トランスポートコンテキスト768a(特に緩和された信頼可能なデータグラムトランスポートサービス)は、パケットが受信システムで順序通りに受信されるかどうかを追跡することができず、一般的には、全てのパケットが到着することを確実にすることのみを考慮する。いくつかの実装では、トランスポートコンテキスト768aは、受信パケットを処理し、例えば、ネットワークヘッダを削除し得る。トランスポートコンテキスト768aはさらに、重複パケット776が受信されたことを検出し得る。パケットがネットワーク730内でドロップされたか、またはドロップされたと考えられるときに、重複パケット776は受信され得る。パケットがネットワーク730にドロップされたと考えられる場合、トランスポートコンテキスト768aは、送信元システム766aがパケットを再送することを要求し得る。いくつかの場合、要求されたパケットは、パケットが実際にはドロップされなかった場合などでは、受信システムによって複数回受信され得るが、単に到着までに非常に長い時間がかかったため、ドロップされたと考えられたにすぎない。これが生じると、トランスポートコンテキスト768aは、第1のコピーが受信された後に受信された任意の追加のコピー776をドロップし得る。
ネットワークアダプタデバイスは、トランスポートコンテキスト768aから(例えば、ファームウェアまたは集積回路を使用して)パケットを受信し、パケットを受信することになるキューペア760a〜cを決定し得る。ネットワークアダプタは、受信パケットに含まれる宛先アドレスなどの宛先情報を使用して、適切なキューペア760aを決定し得る。例えば、宛先アドレスは、キューペア番号を少なくとも部分的に含み得る。ネットワークアダプタデバイスは、実線の矢印772aに示すように、1つ以上のパケットを、決定されたキューペア760aの受信キュー764に配置し得る。キューペア760a〜cは、特定の通信エンドポイントに関連してよく、必ずしも特定のトランスポートコンテキスト768a〜cに関連するわけではない。ゆえに、特定のキューペア760aは、破線772bに示すように、異なるトランスポートコンテキストからパケットを受信中であり得る。
受信キュー764から、ネットワークアダプタは、パケットをホストメモリ780内のバッファ782に転送し得る。例えば、ネットワークアダプタはDMA動作を実行してよく、これは、通常、ホストデバイスのプロセッサにホストメモリ780への書き込みを要求しない。いくつかの実装では、仮想インタフェース759aのIPアドレス及び/または通信エンドポイントの識別(これらのいずれかまたは両方がパケットの宛先アドレスとして提供され得る)は、正しい仮想マシン752へのパケットの転送を支援し得る。いくつかの実装では、ドライバプログラム758は、バッファ782へのパケットの転送を支援し得る。いくつかの実装では、標準ライブラリはこの支援を提供し得る。
ユーザアプリケーション754は、複数の通信エンドポイントを使用するように構成されてよく、したがって、複数のキューペア760a〜cでパケットを受信中であってよい。ネットワークアダプタデバイスは、各キューペア760a〜cに割り当てられた優先度及び/またはサービス品質保証に従って、キューペア760a〜cが公平に提供されること及び/またはキューペア760a〜cを提供し得ることを確実にし得る。
いくつかの実装では、個々のバッファ782は、どのような順序で詰められてよく、常時利用可能であってよい。パケットはさらに、任意の順序でバッファ782に配置され得る。ほとんどの場合、ネットワークアダプタは、パケットを可能な限り迅速にキューペア760a〜cからホストメモリ780に移動して、レイテンシを可能な限り少なくするように構成され得る。この理由及び他の理由により、ネットワークアダプタはさらに、通常、キューペア760a〜cの外部のパケットをバッファリングしない。場合によっては、十分なバッファ782が利用できない場合がある。これは、ユーザアプリケーション754に十分なバッファを割り当てられていないか、またはバッファを十分に速く解放していないために生じ得る。以下にさらに説明するように、これが生じると、ネットワークアダプタは、ユーザアプリケーション754に送られるパケットのドロップを開始し、パケットがドロップされていることをユーザアプリケーション754に通知し得る。パケットがドロップされていることを送信元システムに通知するために、応答メッセージはさらに送信元システムに送り返され得る。いくつかの場合、送信元システムは、この特定のユーザアプリケーション754にパケットを配信する速度を低下することによって応答し得る。いくつかの実装では、不十分なバッファ空間及び/またはドロップされたパケットがある場合、それらをどのように対処するか決定することはユーザアプリケーション754に任せられる。
前に記した通り、パケットは、任意の順序でバッファ782に配置され得る。いくつかの実装では、ドライバプログラム758は、パケットを意図された順序で配置するために、パケットの並び替えを行うように機能し得る。これらの実装では、ドライバプログラム758は、パケットをユーザアプリケーション754に順序通りに提示してよく、ユーザアプリケーション754はパケットが順不同で到着したことを認識できない。いくつかの実装では、ユーザプログラム754はパケット自体を並び替え得る。いずれの場合でも、ユーザアプリケーション754及び/またはドライバプログラム758は、ホストデバイスで利用可能な高い処理能力を利用し得る。
パケットの順序付けを保証する信頼可能な接続及び信頼可能なデータグラムなどのトランスポートサービスに比べ、緩和された信頼可能なデータグラムトランスポートを使用するシステムは、高い拡張性及び良好なレイテンシを提供し、ゆえに、高性能なコンピューティングアプリケーションに潜在的に良好な性能を提供し得る。例えば、パケットの順序を保証するトランスポートサービスでは、ネットワークアダプタデバイスが一定量のパケットをバッファリングし、次いで、ホストデバイスにパケットを提供する前にパケットを並び替える必要があり得る。いくつかの場合、パケットが順不同で到着すると、ネットワークアダプタデバイスは全てのパケットをフローにドロップし、フローを最初から再送するよう要求することを必要があり得る。ネットワークアダプタデバイスがパケットを並び替えるとホストデバイスのソフトウェアは簡略化され得る一方、ネットワークアダプタの要件はより複雑になり、パケット転送のレイテンシ及び帯域幅の消費が増加し得る。
対照的に、緩和された信頼可能なデータグラムトランスポートでは、ネットワークアダプタデバイスは最小限の時間だけパケットをバッファリングすることがあり、ゆえに、全体的なレイテンシを改善する。並び替え動作は、次いで、ホストデバイス上のソフトウェアによって実行されてよく、ソフトウェアはレイテンシによる負担を最小化した状態で高出力のホストデバイスのプロセッサを利用し得る。緩和された信頼可能なデータグラムトランスポートは、順序付けを保証するために行うことができるが、これにより、送信側キューペアから受信側キューペアへの全てのフローのパケット順序状態を追跡すること、または異なる論理フローに属するパケットをシリアル化して単一のパケットシーケンスにすることのいずれかが必要になるだろう。送信側キューペア及び受信側キューペアの全ての組み合わせの間でパケット順序状態を追跡することにより、システムの拡張が難しくなり得る。異なる論理フローからパケットをシリアル化すると、無関係なフローの間に偽の依存関係が作成されることがあり、平均及び最大パケット転送レイテンシが増加し得る。ほとんどの場合、実際にユーザアプリケーションは独自のメッセージフローを追跡し、順不同で到着するパケットを管理するように迅速に再構成することができる。緩和された信頼可能なデータグラムトランスポートは、ゆえに、パケット並び替えをホストデバイスのソフトウェアに任せてよく、全てのパケットの配信を保証することに集中する。
前述の通り、通常のコンピューティングクラスタシステムでは、パケットがネットワークを通じて送信元システムから宛先システムへ移動するために複数の経路を取ることができる。1つの送信元から1つの宛先へのパケットの流れは、パケットのフロー、または単にはフローと呼ばれ得る。フロー内のパケットは互いに関連してよく(例えば、それらはビデオまたは会話などの1つの連続したデータストリームに属する)、フローは終了及び再開し得る(例えば、ビデオまたは会話は終了してよく、新しいビデオまたは会話を開始してよい)。さらに前に記した通り、所与の送信元から特定の宛先までのパケットが全ての利用可能な経路に分散されている場合、クラスタ全体の効率が向上し得る。しかしながら、既存のトランスポートサービスは、パケットが順序通り到着する可能性を確実にして性能低下を低減するために、通常、順序通りのパケット配信に対して設計されており、1つのみの経路上で1つのフローを送信するように構成され得る。さらに、これらのトランスポートサービスは、通常、1つのフローが終了して別のフローが開始するときにのみ経路を変更することができる。
図8は、利用可能な経路840を通じたさらなる活用を達成するために、緩和された信頼可能なデータグラムトランスポートが、ネットワーク830を通る複数の経路840を管理し得る方法の一例を例示する。図8の例では、送信元システム802から宛先システム852へのパケットのフロー810は、「フローレット」800と呼ばれ得るパケットのグループに分割され得る。送信元トランスポートコンテキスト816及び対応する宛先トランスポートコンテキスト868は、ネットワーク830を通る経路の設定及び解除を含む、フローレット800の送信及び受信を管理し得る。送信元及び宛先コンテキスト816、868はさらに、個別のフローレット800ごとにパケットの状態を監視し得る。各フローレット800は、異なる経路840上で送信されてよく、1つのフローレット800内の全てのパケットは同じ経路を使用する。いくつかの実装では、全てのパケットは、1つのポート822上で送信元システム802から送信され、宛先システム852において1つのポート862で受信される。他の実装では、送信元システム802及び/または宛先システム852は、ネットワーク830に接続された複数のポートを有し得る。
前述の通り、緩和された信頼可能なデータグラムトランスポート実装では、送信元コンテキスト816は、通常、1つの特定の宛先コンテキスト868に関連する。送信元コンテキスト816は、ほとんどの場合、宛先システム852に関連するアドレスによって識別される。宛先アドレスは宛先コンテキスト868に割り当てられる。同様に、宛先コンテキスト868は、送信元コンテキスト816に割り当てられている送信元システム802のアドレスによって識別され得る。送信元コンテキスト816は、パケットのフロー810の送信を管理してよく、フロー810は、送信元システム802で動作中の複数のユーザアプリケーションからのパケットを含み得る。フロー810内のパケットは全て、宛先システム852上で動作中のユーザアプリケーションに送られる。宛先コンテキスト868は、宛先システム852において、フロー810内のパケットの受信を管理し得る。
いくつかの実装では、送信元システム802は、宛先コンテキスト868に関連するアドレスが(例えば、図5A〜図5Bの例に従って)初めてマッピングされたときに、新しいフローレット800を初期化し得る。図8の例の第1のフローレット800が初期化された場合、追加のフローレット800が確立され得る。接続確立メッセージは正常なネットワークトラフィックに付属してよく、通常、送信元システム802が接続要求を宛先システム852に送信し、宛先システム852が確認メッセージを送信元システム802に送り返すことによって応答することを伴う。いくつかの実装では、フローレット800は、この例のように一方向であり、フローレット800は、送信元システム802で発生し、宛先システム852で終了する。同じ送信元コンテキスト816及び宛先コンテキスト868を使用して、宛先システム852で発生し送信元システム802で終了するフローレットが構築され得るが、いくつかの実装では、これらは図8の例に例示されているものとは異なるフローレットのセットであり、個別に管理される。
図8の例は、一例として4つのフローレット800を例示する。様々な実装では、より多数または少数のフローレット800がトランスポートコンテキスト816、868によって使用され得る。いくつかの実装では、送信元システム802と宛先システム852との間のフローレット800の数は、変更可能であってよく、及び/または2つのシステム802、852の間の利用可能な経路840の数によってのみ限定されてよい。
通常、フローレット800は、トランスポートコンテキスト816、868のみに知られており、キューペア、仮想マシンまたはユーザアプリケーションから独立している。換言すると、送信元システム802及び宛先システム852上で動作中のユーザアプリケーションは、ほとんどの実装ではフローレット800を認識せず、標準ライブラリ及び/またはドライバプログラムのみと相互作用する。パケットが同じ宛先システム852に送られる場合、様々な送信元からのパケットを同じフロー810に配置してよい。フロー810からのパケットは、パケットがフローレット800の全体に均等に分散されるように、フローレット800に割り当てられ得る。代替的または追加的には、パケットが少なくなっているフローレット800にパケットが最初に割り当てられるよう、パケットは割り当てられ得る。急激に少なくなっているフローレット800は、より高速な経路を使用していることがあり、したがって、これらのフローレット800にパケットを割り当てることにより、全体の利用率及びスループットが向上し得る。
送信元コンテキスト816は、個別のフローレット800ごとにパケットを追跡し得る。各フローレット800は、パケットシーケンス番号を保持してよく、フロー810からのパケットがフローレット800に割り当てられるとき、各パケットにはさらに、そのフローレット800の次のパケットシーケンス番号が割り当てられ得る。パケットにはさらにフローレット識別子が割り当てられてよく、これは、各パケットのフローレット800を識別するために、宛先コンテキスト868によって使用されてよい。
各フローレット800について、送信元システム802は、フローレット800に割り当てられた各パケットの状態情報820を保持し得る。状態情報820は、各パケットのパケットシーケンス番号及びパケットを再送するのに必要となり得る任意の情報を含み得る。ほとんどの場合、パケットに対する状態情報820は、パケットが送信された時点から、パケットが受信されたという確認を送信元システム802が受信するまで、保持され得る。送信元コンテキスト816は、フローレット800ごとに限られた数の未処理パケットについてのみ状態情報820を保持し得る。例えば、送信元コンテキスト802は、フローレット800ごとに32の未処理パケットのみを許可するように構成され得る。フローレット800ごとの未処理パケットの数は一定であってよいか、または変更可能であってよい。フローレット800が非常に遅い場合、つまり、確認の到着が遅いか、または全く到着しない場合、送信元コンテキスト802は、フローレット800を別の経路840に移動させ得る。
宛先コンテキスト868はさらに、個別のフローレット800ごとに、それ自体の状態情報860を用いて、パケットを追跡し得る。宛先コンテキスト868によって保持される状態情報860はさらに、各フローレット800のパケットシーケンス番号を含み得る。以下でさらに詳細に説明するように、宛先コンテキスト868は、状態情報860を使用して、送信元システム802に送信される確認を生成し得る。確認は、特定のフローのパケットが宛先システム852に到着したことを送信元コンテキスト802に通知し、通常、どのパケットが到着したかを示し得る。
フローレット800は、アクティブ又はアイドル状態であってよい。アクティブなフローレット800には、未処理パケット、つまり、送信されたが未だ確認されていないパケットがある。アイドル状態のフローレット800には未処理パケットがなく、送信待ちのパケットもない。フローレット800がアイドル状態の場合、送信元コンテキスト816は、フローレット800を異なる経路840に移動することを決定し得る。一般的に、アイドル状態のフローレット800を別の経路に移動させる送信元コンテキスト816の決定は、(例えば、一定時間またはフローレット800がアイドル状態になる度に)組織的というよりはランダムに行われる。アイドル状態のフローレット800を他の経路に移動させることにより、送信元コンテキスト816は、ネットワーク830を通じて混雑の少ない経路840を発見することを試みる。
各フローレット800からのパケットは、送信元システム802によって、それらのパケットシーケンス番号の順序で送信され得る。フローレット800から送信された第1のパケットはさらに、特定のフローレット800が開始していることを宛先コンテキスト868に通知する「シーケンス開始」インジケータを含み得る。宛先コンテキスト868は、次いで、パケット内のパケットシーケンス番号をシーケンス開始インジケータと共に使用して、そのフローレット800の状態を確立し得る。宛先コンテキスト868は、後続的には、そのフローレット800のパケットが、それらのパケットのシーケンス番号の順序通りに到着するよう予期する。ゆえに、例えば、1つのフローレット800からのパケットは、シーケンス番号「1、2、3、4、5...」で送信元システム802によって送信されてよく、第1のパケットはシーケンス開始インジケータを含む。宛先システム852は第1のパケットを受信し、シーケンス開始インジケータを記録し、後続的に、シーケンス番号「2、3、4、5...」のパケットがそのフローレット800に対して順序通り到着するよう予期し得る。
しかしながら、パケットはネットワーク830内でドロップされることがあり、宛先システム852に到達しない可能性がある。例えば、上述の例を続けると、宛先システムは、パケットシーケンス番号「1、3」のパケットを受信することがあり、これは、パケットシーケンス番号「2」のパケットがドロップした可能性があることを示す。以下により詳細に説明するように、送信元コンテキスト816と宛先コンテキスト868との両方が保持するパケット状態により、コンテキスト816、868は、パケットがネットワーク830内でドロップしたことを識別し、失われた全てのパケットを再送することができ得る。
ネットワーク830内のリンクの過剰使用を原因とするネットワーク830内のドロップ及び遅延は、性能に影響を及ぼす可能性があり、ゆえに、一般的には両方を回避または最小化することが望ましい。送信元コンテキスト816は、1つの経路840での過度のドロップまたは混雑を多数の方法で検出し得る。例えば、フローレット800の状態情報820は、パケットが送信されたときから、そのパケットに対する確認が受信されたときまでの時間を決定するために送信元コンテキスト816が使用できるタイマを含み得る。時間が長いときはフローレット800によって使用されている経路での混雑を示し得る。代替的または追加的には、送信元コンテキスト816は、送信元コンテキスト816がどのくらい迅速に各フローレット800にパケットを追加することができるかを追跡し得る。他のフローレット800ほど迅速にはパケットを受け入れることができないフローレット800では、ネットワークを通るその経路840に混雑が発生している可能性がある、及び/または過度なドロップが発生している可能性がある。代替的または追加的には、送信元コンテキスト816は、特定のフローレット800に対して大量の再送要求を受信することがあり、これは、フローレット800が使用している経路での過剰なドロップを示し得る。
送信元コンテキスト816が、フローレット800が混雑または過剰ドロップが発生している可能性があると判断した場合、送信元コンテキスト816は、フローレット800を別の経路840に移動し得る。いくつかの実装では、一旦フローレット800が移動されると、経路の識別子が現在変更されていたとしても、宛先コンテキスト852は、フローレット800からパケットを受信して受け入れ続ける。いくつかの実装では、送信元コンテキスト816は、再配置されたフローレット800に、最も古い未確認のパケットシーケンス番号のパケットと共に、新しいシーケンス開始インジケータを送信させ得る。これらの実装では、宛先コンテキスト868は、新しいシーケンス開始インジケータを受信すると、送信元システム802が新しいシーケンス開始インジケータを伴うパケットより前に送信した任意のパケットを送信元システム802が捨てたと考え、再開されたフローレット800に関して有していた任意の情報(例えば、パケットシーケンス番号)を破棄し得る。
いくつかの場合、宛先コンテキスト868は、順不同で到着したパケット内のシーケンス開始インジケータを受信し得る。例えば、宛先コンテキスト868は、シーケンス番号「1、2、3、1」のパケットを受信することがあり、シーケンス番号「1」を有する両方のパケットは同じパケットのコピーであり、シーケンス開始インジケータを有する。これは、例えば、フローレット800の経路840が特に遅く、シーケンス番号「1」の第1のパケットに対する確認が送信元システム802に到達するまで非常に遅かった場合に起こり得る。この遅さに起因して、送信元システム802は、確認を受信する前に、経路を切り替えてフローレット800を再開し得る。この状況では、宛先コンテキスト868は、パケットシーケンス番号「1」の第2のパケットを受信するときに、フローレット800の状態をリセットする必要がないことを認識し得る。代わりに、宛先コンテキスト868は、パケットシーケンス番号「1」の第1のパケットをシーケンス開始として認識してよく、パケットシーケンス番号「1」とシーケンス開始インジケータの両方のセットで到着する任意の追加パケットを無視してよい。いくつかの実装では、宛先コンテキスト868は、追加パケットが受け入れられなかったことを示す確認を送信してよく、送信元コンテキスト816が状況を理解するのを支援してよい。
フローレット800はさらに、送信元システム802または宛先システム852のいずれかが切断されたときに再開する必要があり得る。宛先システム852は、完全にまたは部分的にのみ切断されてよい。宛先システム852がリセットされるときに完全な切断が生じ得る。宛先システム852がリセット後に動作可能になると、宛先コンテキスト868はパケットを受信することができるが、その状態情報860がリセットされているため、宛先コンテキスト868は、任意のフローレット800(例えば、到着したパケットのシーケンス番号)に対する状態情報を有することができなくなる。宛先コンテキスト868は、ゆえに、全ての受信パケットに対して、パケットが受け入れられなかったことを示す応答を送信し得る。いくつかの場合、応答は、宛先コンテキスト868が予期していないパケットシーケンス番号を受信したことを、送信元コンテキスト816に伝えるインジケータを含み得る。これらの応答を受信すると、送信元コンテキスト816は、これらのパケットを送信しようとしたユーザアプリケーションに、宛先コンテキスト852が接続状態の追跡を見失ったことを通知し得る。これにより、ユーザアプリケーションがリカバリ動作を開始し得る。
宛先システム852での部分的な切断がさらに生じ得る。例えば、フロー810を受信している宛先システム852で、仮想マシンが故障したか、またはシャットダウンされたかのいずれかのためにオフラインになったとき、部分的な切断が生じ得る。いくつかの実装では、送信元コンテキスト816は、例えば、制御プレーン上で受信されたコマンドによって、そのターゲット仮想マシンがオフラインであることを明示的に通知され得る。他の実装では、送信元コンテキスト816は、未処理パケットが所定期間(例えば、タイマの期限切れ)で未確認となった場合に、ターゲット仮想マシンがオフラインであると判断し得る。ターゲット仮想マシンがオフラインであると判断するか、または通知されると、送信元コンテキスト816は、任意の未処理パケットをドロップし、宛先システム852との接続を閉じ得る。いくつかの実装では、送信元コンテキスト816はさらに、送信元側ユーザアプリケーションに、送信元コンテキストがドロップしたパケットは送信されなかったと報告し得る。ターゲット仮想マシンはオフラインであるため、送信元コンテキスト816はさらに、フロー810からパケットを送信する任意の後続の要求を拒否し得る。ターゲット仮想マシンは、最終的にバックアップされてよく、その時点で、送信元コンテキスト816は、ターゲット仮想マシンが再起動することを通知されてよい。送信元コンテキスト816は、次いで、宛先システム852との接続を再度初期化し、フロー810からのパケットの受け入れを再び開始してよい。
例えば、フロー810からパケットを受信している宛先システム852でユーザアプリケーションがオフラインになったときにも、部分的な切断が生じ得る。宛先側ユーザアプリケーションがクラッシュしたか、または閉じられている可能性がある。この状況では、宛先コンテキスト868は、受信パケットを通常通り確認し、現在オフラインである宛先側ユーザアプリケーションに割り当てられた受信キューに、それらを配信し得る。パケットは、その後、受信キューでドロップされ得る。多くの場合、フローレットは、オフラインのユーザアプリケーションを含む、複数の宛先側ユーザアプリケーションに送られるパケットを含み得るため、宛先コンテキスト868は、ほとんどの場合、フローレット800をリセットさせないだろう。代わりに、いくつかの実装では、宛先コンテキスト868は、オフラインのユーザアプリケーションに送信されたパケットが受信されたとして処理し、送信元802及び宛先852のシステムにあるユーザアプリケーションに処理方法の判断を任せる。他の実装では、パケットはドロップされ、ドロップされたパケットを送信ユーザアプリケーションに通知する。
送信元システム802はさらに、(例えば、リセットされることによって)完全に切断されてよく、または部分的に切断されてよい。送信元側ユーザアプリケーションが再起動されたときに生じる部分的な切断は、送信元コンテキスト816に影響を及ぼさない可能性がある。送信元側の仮想マシンの再起動または送信元システム802全体のリセットによって生じる部分的な切断によって、結果的に送信元コンテキスト816が再開し得る。これらの場合、送信元コンテキスト816は、送信元システム802が最初に起動された時と同じ方式でそのフローレット800を再度初期化し得る。送信元システム802では、新たに開始されたフローレット800は、通常、履歴を持たない(例えば、確認されたパケットシーケンス番号がない)。ゆえに、いくつかの実装では、送信元コンテキスト816は、シーケンス開始インジケータのパケットが宛先システム852によって確認されるまで、シーケンス開始インジケータのパケットを送信した後、パケット送信を遅延させ得る。これにより、フローレット800の「最新の確認」パケットシーケンス番号を確立し得る。いくつかの場合、送信元コンテキスト816は、シーケンス開始インジケータの初期パケットが宛先システム852によって受け入れられなかったことを示す確認を受信し得る。これは、例えば、宛先コンテキスト868が初期パケットに含まれているパケットシーケンス番号を拒否した場合に生じ得る。これが生じると、送信元コンテキスト816は、シーケンス開始インジケータのパケットを再び送信し、いくつかの実装では、異なる開始パケットシーケンス番号をパケットに提供し得る。
ネットワーク830におけるパケットドロップ、経路840の切り替え、切断及びフローレットの再開には、それぞれ、パケットの再送が必要となり得る。これらの再送パケットは、宛先システム852で受信されると、これまでに受信されたパケットの順序通りではなくなる。例えば、宛先コンテキスト868は、シーケンス番号「1、3」のパケットを受信していた可能性があり、ゆえに、シーケンス番号「2」のパケットを再送する必要があることを示し得る。一旦シーケンス番号「2」のパケットが再送されると、宛先コンテキスト868は、この特定のフローレット800に対してシーケンス番号「1、3、2」を有することになる。
以下でさらに詳細に説明するように、宛先コンテキスト868は、パケットがこの方式で順不同で到着することを予期するように構成され得る。宛先コンテキスト868は、送信元コンテキスト816と協働して、ほとんどの実装において、全てのパケットが受信されることを確実にし、通常、それらのパケットが受信される順序は考慮しない。宛先コンテキスト868は、通常、パケットが受信されるとすぐに、または実際に可能な限り早急に、パケットを宛先側ホストデバイスに転送し、必要となるパケットの任意の並び替えはホストデバイスに任される。パケットは、フロー810の宛先エンドでは、フロー810の送信元エンドでの順序とは異なる順序になり得ることに留意されたい。ただし、パケットが一旦ターゲットキューペアに配信されると、特定の宛先側ユーザアプリケーションに対して送られるパケットは、実際には、順序通りとなり得る。しかしながら、キューペアにおける並び替えは、宛先コンテキスト868によって保証されるわけではない。
上述の通り、送信元コンテキスト816及び宛先コンテキスト868はそれぞれ、各個別のフローレット800に対する状態情報820、860を保持し得る。送信元及び宛先コンテキスト816、868は、状態情報820、860を使用して、フロー810内の全てのパケットが宛先システム852に到達することを確実にし得る。
図9A〜9Bは、緩和された信頼可能なデータグラムトランスポートがパケットの信頼可能な配信を保証し得る方法の一例を例示する。緩和された信頼可能なデータグラムトランスポートサービスは、送信側900コンテキストが各送信パケットの状態情報を保持し、受信側が受信した全てのパケットに対する応答を受信側950コンテキストが送信側900に返送することによって、保証されたパケット配信を提供し得る。図9Aは、送信側900のコンテキストが各送信パケットの状態情報を保持し得る方法の一例を例示する。図9Bは、受信側950のコンテキストが状態情報を保持し、状態情報を使用して応答を生成し得る方法の一例を例示する。
一般的に、ユーザアプリケーションは、通常、パケットがその宛先に到達することを確実にすることに関与しない。1つ以上のパケットがネットワーク内でドロップされたことを受信側ユーザアプリケーションが判断するには、受信されたパケットは、受信側トランスポートスタックまで進みユーザアプリケーションまで移動する必要がある。例えば、ユーザアプリケーションが非常にビジー状態にあるためにパケットを受信できない場合には、パケットが途中で遅延することがある。その場合、ユーザアプリケーションは、トランスポートスタックまで進み、ネットワークを通り、次いで、送信側トランスポートスタックを上って送信ユーザアプリケーションまで要求を再送する必要がある。対照的に、受信側トランスポートコンテキストは、パケットの受信側の最初の連絡地点であってよく、ゆえに、パケットが到着していないことをより迅速に判断することができ得る。同様に、送信側トランスポートコンテキストは、再送要求を最初に受信してよく、ゆえに、ユーザアプリケーションよりもはるかに迅速に再送要求に応答し得る。
いくつかの実装では、緩和された信頼可能なデータグラムトランスポートサービスは、パケットシーケンス番号を使用して、パケットの保証された信頼可能な配信を提供し得る。送信側900のトランスポートコンテキストは、送信した各パケットに対して、個別のフローレットごとにパケットシーケンス番号を追跡し得る。受信側950のトランスポートコンテキストは、受信したパケットのパケットシーケンス番号を追跡し、送信側900のトランスポートコンテキストに応答を送り返し得る。これらの応答は、どのパケットが受信されたかを送信側900のトランスポートコンテキストに通知し得る。具体的には、受信側950のトランスポートコンテキストは、パケットシーケンス番号がパケットのパケットシーケンス番号に関して順序通りであるパケットを受信するときに、受信側950のトランスポートコンテキストは「ACK」応答を送信し得る。受信側950のトランスポートコンテキストは、それらのパケットシーケンス番号に応答して順序通りでないパケットを受信するときに、受信側950のトランスポートコンテキストは「選択的ACK」または「SACK」応答を送信し得る。場合によっては、パケットが受信側950のトランスポートコンテキストに到達することがあるが、受信側950のトランスポートコンテキストはパケットを受け入れ不可能である場合がある。この状況では、受信側950のトランスポートコンテキストは、パケットが受け入れられなかったことを送信側900のトランスポートコンテキストに示すために「NACK」を送信し得る。
図9Aは、未処理パケットの送信側900の管理及び応答の受信の一例を例示する。図9Aの例では、一例として、3つのフローレット904a〜cを例示する。前述の通り、フローレットのセットは、一般的に、1つのパケットフローからのパケットを含むが、フローは、同じ宛先システムに送信している複数のユーザアプリケーション902からのパケットを含み得る。パケットフローはグループに分割されてよく(ほとんどの実装では、パケットの相互関係は考慮されない)、これらのパケットグループはサブフローまたはフローレットと呼ばれ得る。経路が送信側900のトランスポートコンテキストによって変更されない限り、または変更されるまで、特定のフローレット内のパケットは、一般的に、ネットワーク930上の同じ経路を使用する。図9Aの簡略化した例には、フローレット904a〜cごとに4つのパケットしか例示されていないが、各フローレット904a〜cは、5つ以上の未処理パケットに対して状態情報を保持し得ることが理解される。いくつかの実装では、フローレットが状態を保持できるパケットの数は(例えば、8、16、13またはそれ以上のパケットに)制限される。これらの実装では、一旦未処理パケットの数が制限値に等しくなると、未処理パケットの少なくとも1つが受信されたと確認されるまで、そのフローレットを使用してそれ以上パケットを送信することができない。
第1のフローレット904aの例では、最初の3つのパケット908a、908b、908cがネットワーク930に送信されており、第4のパケット908dが送信されるのを待っている。第1のフローレット904aの状態情報906aは、第1のパケット908aのACK状態910aと、第2のパケット908bのACK状態910bとを示す。これらの2つのACK状態910a、910bは、第1のパケット908a及び第2のパケット908bが受信側950のトランスポートコンテキストで受信されたことと、それらが順序通りに受信されたこと(例えば、第1のパケット908aが受信された後、第2のパケット908bが受信された)との両方を示す。いくつかの実装では、古いパケットの再送要求が到着する可能性は低いため、送信側900のトランスポートコンテキストは、最も古い未確認のパケットを記憶するだけでよい。ゆえに、これらの実装では、送信側900のトランスポートコンテキストは、第1のパケット908aの状態情報906aを忘れる可能性があり、場合によっては、第2のパケット908bの状態情報も忘れる可能性がある。フローレット内のパケット数が制限されている実装では、1つまたは2つのパケットの状態情報906aを削除することにより、さらに、より多くのパケットが送信されるようにスロットが解放される。
第1の例示的なフローレット904aを締めくくると、第3のパケット908cは送信済み状態910cを有しており、これは、このパケット908cに対する応答がまだ受信されていないことを意味する。第4のパケット908dはペンディング状態910dを有しており、これは、パケットがフローレット904aに追加されたが、ネットワーク930にまだ送信されていないことを意味する。
第2のフローレット904bの例では、4つのパケット912a〜dの全てがネットワーク930に送信されている。第2のフローレット904bの状態情報906bは、第3のパケット912cのSACK状態914cを示す。SACK状態914cは、第3のパケット912cが受信側950のトランスポートコンテキストによって受信されたことを示す。SACK状態914cはさらに、第1のパケット912aも受信されたことを示してよく、これは、第1のパケット912aのACK状態914aの状態を意味する。一方、第2のパケット912b及び第4のパケット912cは送信済み状態914b、914cを有しており、これらのパケット912b、912cに対する応答がまだ受信されていないことを示す。
送信側950のトランスポートコンテキストが順序通りでないパケットを受信した場合、送信側950のトランスポートコンテキストによってSACKメッセージが使用され得る。第2のフローレット904bの例では、第1のパケット912aが受信され、次いで、第3のパケット912cが受信された。これは、第2のパケット912bが送信済み状態914bを有しているが、第3のパケット912cの前に第2のパケット912bが受信側950に到着しなかったことを意味する。実際には、第2のパケット912bは、ネットワーク930によってドロップされた可能性がある。いくつかの実装では、SACK応答は、受信側950で順番に受信された最後のパケットのパケットシーケンス番号(ここでは、第1のパケット912aのシーケンス番号)及び順序通りに受信されなかった第1のパケットのパケットシーケンス番号(ここでは、第3のパケット912cのシーケンス番号)を含む可能性がある。ゆえに、例えば、数字のパケットシーケンス番号が使用されたと仮定すると、SACK応答は「1、3」を示す可能性がある。このように、SACK応答は、第2のパケット912bが、送信側900のトランスポートコンテキストによって再送される必要があることを効率的に示し得る。
応答メッセージは、一般的に、データパケットと同じ方式でネットワーク930を通過する。ゆえに、応答メッセージもネットワーク930にドロップする可能性がある。これは、受信側950のトランスポートコンテキストが、1つの特定のパケットが到着しなかったことを示す2つ以上のSACKを生成し得ることを意味する。例えば、第2のフローレット904bの例の場合、「1、3」を示すSACKがネットワーク930にドロップされた可能性がある。第4のパケット912dが受信側950に到着するのに成功したと仮定すると、受信側950のトランスポートコンテキストは第2のパケット912bをまだ受信していないため、送信側900のトランスポートコンテキストは「1、3〜4」を示すSACKを生成し得る。
広範な例では、送信側900のトランスポートコンテキストがどのパケットを再送する必要があるかを決定し得る方法を良好に例示し得る。送信側900のフローレットが、パケットシーケンス番号1、2、3、4、5、6を有する6つのパケットを送信したと仮定する。さらに、受信側950上のフローレットがシーケンス番号1、3、5及び6のパケットを受信しており、シーケンス番号2及び4のパケットがネットワーク930にドロップされたと仮定する。このシナリオを考慮すると、受信側950は以下の応答を生成し得る。
パケット番号1の受信時:ACK(1)
パケット番号3の受信時:SACK(1、3)
パケット番号5の受信時:SACK(1、5)
パケット番号6の受信時:SACK(1、5〜6)
これらの確認メッセージの全てが送信側900のトランスポートコンテキストで受信された場合、第1のSACKはパケット番号2の再送をトリガし得る。送信側900のトランスポートコンテキストは、パケット番号2を既に再送したと判断し得るため、第2のSACKはパケット番号4のみの再送をトリガし得る。第3のSACKは、いずれの再送もトリガしない可能性がある。
しかしながら、第1のSACKがネットワーク900内で失われたと仮定すると、第2のSACK(SACK(1、5))の受信は、送信側900のトランスポートコンテキストがパケット番号2、3及び4を再送するようトリガし得る。パケット番号2がパケット番号6の後に到着すると仮定すると、受信側950のトランスポートコンテキストは、SACK(3、5〜6)を生成して、パケット番号4がまだ到着していないことを送信側900に通知する。パケット番号3が次に到着すると仮定すると、受信側950のトランスポートはこのパケットを複製として認識することがあり、追加の応答を送信することなく複製パケットを破棄するだろう。
いくつかの実装では、送信側900のトランスポートコンテキストは、確認されていない任意のパケットを再送し、再送を続けるだろう。例えば、第3のフローレット904cの場合、第4のパケット916dは、送信済み状態918dを有するため、定期的に再送されてよい。フローレットが2つ以上の未確認パケットを有する場合、一般的に、これらの未確認パケットは、最も低いパケットシーケンス番号を有するパケットから最も高いパケットシーケンス番号を有するパケットまで、順番に再送される。例えば、第2のフローレット904bの場合、送信側900のトランスポートコンテキストは、パケット912b及びパケット912cの1つまたは両方が確認されるまで、第2のパケット912bを再送し、次いで第4のパケット912dを再送し、次いで再び第2のパケット912b及び第4のパケット912dを再送し得る。追加のSACK応答が到着すると、SACKメッセージによって受信されていないと示されたパケットは、再送のためにパケットのリストに追加されるか、または再追加され得る。送信側900のトランスポートコンテキストは、多くの場合、ネットワーク930が再送パケットでフラッディングすることを回避するように構成されてよい。例えば、送信側900のトランスポートコンテキストは、フローレットが一度に送信できる最大数のパケットを示す最大バーストサイズで構成されてよい。初めて送信されたパケット及び再送中のパケットを含む、フローレットによって送信されたパケットの数がバーストサイズに達すると、再送が必要な追加パケットが遅延することがある。
いくつかの実装では、少なくとも最も古い未確認パケットが確認されるまで、フローレットは新しいパケットの送信を中止し得る。例えば、いくつかの実装では、フローレットは、限定された数のパケットの状態情報のみを保持し得る。例えば、これらの実装では、フローレットは、最大6つのパケットの状態情報を保持し、フローレットはパケット番号1〜6を送信することがある。フローレットはさらに、パケット番号2、3及び4に対する応答を受信することがあるが、パケット番号1に対する応答は受信できない。フローレットがパケット番号1に対する確認を受信するまで、フローレットがこのパケットを再送できるように、パケット番号1に対する状態情報を保持する必要があり得る。さらに、パケット番号1が確認されてフローレットから削除され、追加のパケット用の空間が作られるまで、フローレットは、任意の新しいパケットを追加することができない可能性がある。
図9Aの例に戻ると、第3のフローレット904cでは、4つ全てのパケット916a〜dがネットワーク930に送信されている。第3のフローレット904cの状態情報906cは第1のパケット916aのACK状態918aを示し、これは、第1のパケット916aが順番に受信されたことを示す。「順番に受信される」とは、そのフローレットに対して受信された全てのパケットが、第1のパケット916aのパケットシーケンス番号の直前にある一連のパケットシーケンス番号(例えば、第1のパケット916aがパケットシーケンス番号「1」を有すると仮定し、パケットシーケンス番号は、最大値が32でありラップアラウンド可能なカウンタから割り当てられると仮定すると、先行のパケットシーケンス番号は「29、30、31、0」であった可能性がある)を有したか、または第1のパケット916aが「シーケンス開始」インジケータを有したために、このフローレット904cによって送信された第1のパケットであったことを意味し得る。
しかしながら、第2のパケット916b及び第3のパケット916cは、NACK状態918b、918cを有する。NACK状態918b、918cは、第2のパケット916b及び第3のパケット916cが受信側950に到着したことを示しているが、これらのパケット916b、916cはどういうわけか受信側950で受け入れられなかった。NACK応答は、一般的に、メッセージを受信したパケットを生成したユーザアプリケーション902に送り返される。ユーザアプリケーション902は、次いで、対処方法を決定し得る。例えば、ユーザアプリケーション902はNACK状態918bを有するパケット916bを再送すべきであると決定することがあり、この場合、ユーザアプリケーション902はパケット916bの新しいコピーをフローに配置し得る。しかしながら、NACK応答をユーザアプリケーション902に戻す以外に、送信側900のトランスポートコンテキストは、NACK状態918b、918cをACK状態と同様に扱い、第2のパケット916b及び第3のパケット916cを完了したものとみなし得る。これは、第1のパケット916a、第2のパケット916b及び第3のパケット916cならびにそれらの対応する状態情報918a〜cがフローレット904cから削除されてよく、追加のパケット用に新しいスロットを残すことを意味する。
送信側900のトランスポートコンテキストは、各フローレット904a〜cに様々なタイマを保持し得る。例えば、送信側900のトランスポートコンテキストは、応答が受信されたときに第1のフローレット904aのタイマを開始し、第1のフローレット904aに対する別の応答が受信される度にタイマをリセットし得る。長期間応答が受信されない場合、タイマは期限切れになり得る。この時点で、送信側900のトランスポートコンテキストは何らかのアクションをとり得る。例えば、第1のフローレット904aに多数の未処理パケットがある場合、送信側900のトランスポートコンテキストは、フローレット904aを異なる経路に切り替えるように決定し得る。多数の未処理パケットは、フローレット904aによって使用されている経路が非常に遅いか、または失敗したリンクを有する可能性があることを示し得る。送信側900のトランスポートコンテキストはさらに、フローレット904a内の任意の未処理パケットを再送のためにスケジューリングし得る。
図9Bは、パケット受信及び応答生成の受信側950の管理の一例を例示する。図9Bの例では、図9Aに例示された3つのフローレット904a〜cの例の受信を例示する。図9Bでは、3つのフローレット例のそれぞれについて、受信側950のトランスポートコンテキストは、個別のフローレットごとに、各受信パケットに対する状態情報954a〜cを保持する。状態情報954a〜cを使用して、受信側950のトランスポートコンテキストは、予期したパケットが受信されなかったことを判断することができ得る。受信側950のトランスポートコンテキストは、次いで、送信側900に欠落パケットを再送するよう要求することができる。
第1のフローレットの例の場合、状態情報954aは、第1のパケット958a及び第2のパケット958bが到着したことを示し得る。この例では、受信側950のトランスポートコンテキストが第1のパケット954aの受信成功を確認するACK応答を生成することができる前に、第2のパケット958bが到着している。一般的に、受信側950のトランスポートコンテキストは、受信した各パケットの応答を自動的に生成してキューに入れることはできない可能性がある。代わりに、受信側950のトランスポートコンテキストは、フローレットでパケットを受信すると、そのフローレットに応答の生成が必要であるとマークし得る。受信側950のトランスポートコンテキストは、次いで、各フローレットを定期的にポーリングし、フローレットが応答を生成する必要があるかどうかを確認してからようやく応答を生成及び送信し得る。
第1のフローレットでは、これは、第2のパケット958bが到着した後にのみ、第1のフローレットが応答を生成することを意味し得る。この時点で、受信側950のトランスポートコンテキストは、フローレットの状態情報954aを検証し、この情報を使用して第1のパケット958a及び第2のパケット958bが到着したことを示す累積応答を生成することができる。応答はさらに、これらのパケットがそれらの連続した順序で到着したことを示す可能性があり、これは、これまでに到着に失敗したパケットがないことを意味する。パケット958a、958bが順番に到着したため、応答はACK960となり、ACK960は最近受信したパケットのパケットシーケンス番号(つまり、第2のパケット958b)を含むことになる。
他の状況では、第1のフローレットは、第1のパケット958a及び第2のパケット958bのそれぞれについてACKを生成している可能性がある。例えば、第1のフローレットは、第1のパケット958aが到着した後と第2のパケット958bが到着した後の両方で応答を生成するようにスケジューリングされる可能性がある。両方の場合において、応答はACKとなり、それぞれは先行パケットのパケットシーケンス番号を伴う。
ACK960を生成して送信した後、第1のフローレットは、少なくとも第1のパケット958aの状態情報をクリアすることができ得る。フローレットは、最近受信したシーケンス番号を追跡するために、第2のパケット958bのパケットシーケンス番号を保持し得る。しかしながら、フローレットは、パケット自体を受信ユーザアプリケーション952に送信させ得る。一般的に、受信側950のトランスポートコンテキストは、パケットのバッファリングを回避し得、対象となるユーザアプリケーション952に可能な限り早急にパケットを送信し得る。
第2のフローレットの例の場合、状態情報954bは、2つのパケット、この場合は第1のパケット962a及び第3のパケット962cが到着したことを示し、第2のパケット962bは、第3のパケット962cが受信された時点で欠落していたことを示す。ここで、フローレットは、第1のパケット962aが受信された後にACKを生成し得るが、第2のパケット962bがこの時点で欠落しているため、第3のパケット962cの後にSACK964を生成する。SACK964は、第2のパケットが受信されなかったことを送信側900のトランスポートコンテキストに通知し得る。例えば、SACK応答は、SACK960のメッセージ内の第1のパケット962a及び第3のパケット962cのパケットシーケンス番号を含み得る。SACK応答はさらに累積的であってよい。例えば、この例のSACK964が送信される前に第4のパケットが到着する場合、フローレットは、第1のパケット962a、第3のパケット962c及び第4のパケットの受信を示すSACKを生成し得る。
この例を続けると、第2のフローレットが第1のパケット962a及び第3のパケット962cにSACK964を送信した後、欠落している第2のパケット962bが到着する可能性がある。第2のパケット962bは、例えば、ネットワーク930が遅いためにやっと到着したところであり得る。第2のパケット962bも、SACK964に応答して到着した可能性があり、これは第2のパケット962bが再送されたことを意味する。この例では、第2のパケット962bが2回到着する。例えば、SACK964がネットワーク964内にドロップされた可能性があるため、第2のパケット962bの第2のコピーが到着する可能性がある。追加的に、送信側900のフローレットのタイマが期限切れになっている可能性があり、全ての未確認パケットが再送される可能性がある。状態情報954bは、受信側950のトランスポートコンテキストが、第2のパケット962bの第2のコピーが複製であることを認識することを可能にする。フローレットは、後続的に複製コピーをドロップし得る。
第3のフローレットの例の場合、状態情報954cは、3つのパケット966a〜cが到着したことを示す。フローレットは第1のパケット966aを受け入れ、送信側900のトランスポートコンテキストに通知するACK968aを生成する。しかしながら、フローレットは、第2のパケット966b及び第3のパケット966cを受け入れない可能性がある。これは、例えば、受信ユーザアプリケーション952がメモリ内のバッファを使い果たし、これ以上パケットを受け入れ不可能である場合に生じ得る。これが生じると、フローレットは、受け入れられなかったパケット966b、966cに対するNAK968b、968cメッセージを生成し得る。
いくつかの実装では、受信側950のトランスポートコンテキストは、応答メッセージの生成を停止し得る。これは、新しいパケットが送信側900でほぼ空のフローレットに追加されず、そのフローレットからのパケットがネットワーク内でドロップされた場合に生じ得る。受信側950のトランスポートコンテキストが応答、この場合にはパケットが欠落していることを示すSACKを生成すると、受信側950のフローレットは別のパケットを受信する必要があり、これは、送信側900のフローレットが新しいパケットを受信していないため、生じ得ない。いくつかの実装では、この状況を防止する1つの方法は、例えば、急激に少なくなっているフローレットにパケットを頻繁に割り当てることによって、フローレットがほとんど空にならないことを確実にすることである。いくつかの実装では、未処理パケットが滞留しているフローレットを防止する別の方法は、フローレットの数を動的に調整することである。いくつかの実装では、別の解決策は、未処理パケットを長時間有しているフローレットをタイムアウトさせ、それらのフローレットを別の経路に移動させ、それらのフローレットで未処理となっている任意のパケットを再送することである。
図9A及び図9Bの例に例示するように、緩和された信頼可能なデータグラムトランスポートサービスは、全てのパケットが最終的に配信されることを保証するために、失われた可能性のあるパケットの応答及び再送を使用し得る。このように、パケットドロップ率の高いネットワーク930に対して緩和された信頼可能なデータグラムトランスポートを使用することができる。これらの例に例示するように、パケットは、パケットシーケンス番号に関する順序だけでなく、パケットの相関順序に関しても従わない順序で受信側950に到着し得る。
図10A〜図10Bは、フローレット1002a〜cに分割された単一のパケットフロー及び受信ユーザアプリケーションによってパケット1004a〜d、1006a〜d、1008a〜dが受信される順序の一例を例示する。この簡略化した例では、例示のパケット1004a〜d、1006a〜d、1008a〜dは、1つの送信ユーザアプリケーションによって送信されており、1つの受信ユーザアプリケーションによって受信されている。例示のパケット1004a〜d、1006a〜d、1008a〜dが送信ユーザアプリケーションによって送信される場合、この例では、パケット1004a〜d、1006a〜d、1008a〜dは特定の順番を有する。例えば、パケット1004a〜d、1006a〜d、1008a〜dは、ビデオストリームの一部であってよく、ビデオストリームの連続フレームを搬送してよい。パケット1004a〜d、1006a〜d、1008a〜dは送信ユーザアプリケーションによってシーケンス識別子を割り当てられ、受信アプリケーションにパケットの正しい順序を通知し得る。
上述の通り、パケット1004a〜d、1006a〜d、1008a〜dは、最初に送信された順序ではない順序で受信ユーザアプリケーションに到着してよい。これは、他の理由の中でもとりわけ、ネットワーク内のドロップ、フローレットの経路変更及び/またはフローレットの再開に起因し得る。順不同で到着するパケット1004a〜d、1006a〜d、1008a〜dは、パケットの各グループがとるネットワーク上の経路の差異によっても生じ得る。パケット1004a〜d、1006a〜d、1008a〜dは、ゆえに、宛先システムに到着するときに並び替える必要があり得る。図10Aは、パケット1004a〜d、1006a〜d、1008a〜dの経時的な到着及びパケット1004a〜d、1006a〜d、1008a〜dがメモリに格納され得る方法を例示する。図10Bは、パケット1004a〜d、1006a〜d、1008a〜dをそれらの目的の順番に配置する並び替えを例示する。
図10Aの例では、パケットフローは3つのフローレット1002a〜cに分割されており、4つのパケットは各フローレット1002a〜c上で受信される。図10Aの例では、各パケット1004a〜d、1006a〜d、1008a〜dの到着を経時的に例示する。図10Aはさらに、パケットを受信するためにメモリに構成されたバッファ1010の一例を例示する。いくつかの実装では、バッファ1010は、受信ユーザアプリケーションによって事前に構成されている。これらの実装では、バッファ1010は、ホストデバイスのメモリ内に構成されてよい。
上述の通り、各フローレット1002a〜c内のパケット1004a〜d、1006a〜d、1008a〜dは、それぞれのフローレット1002a〜c内でその順序を確立し得るパケットシーケンス番号を割り当てられ得る。この例では、パケットシーケンス番号は、文字a、b、c及びdによって表される。第1のフローレット1002aでは、第2のパケット1004bが最初に到着し、第1のパケット1004a、第4のパケット1004d及び第3のパケット1004cが続く。前に記した通り、パケット1004a〜dが到着する順序は、パケットドロップ、パケット再送及び不完全なネットワークに生じ得る他の問題に起因し得る。第2のフローレット1002bでは、第1のパケット1006aが最初に到着し、次いで、第4のパケット1006d、第2のパケット1006b及び次いで第3のパケット1006cがその順序で到着する。第3のフローレット1002cでは、第1のパケット1008aが最初に到着し、次いで、しばらくしてから、第2のパケット1008b、第4のパケット1008d及び第3のパケット1008cが到着する。
この例を説明するために、パケット1004a〜d、1006a〜d、1008a〜dは、宛先システムにおいて受信される順序でバッファ1010内に配置される。さらに、この例を説明するために、バッファ1010は左から右に詰められる。バッファ1010は、別様には任意の便宜的な順序で詰められてよいことが理解される。この例では、場合によっては、バッファ1010の一部が占有されているか1012、または別様には利用不可能である。
フローレット1002a〜c内のパケット1004a〜d、1006a〜d、1008a〜dは、フローレット1002a〜c内の他のパケット1004a〜d、1006a〜d、1008a〜dに関する到着順序を有する一方、パケット1004a〜d、1006a〜d、1008a〜dはさらにフローレット1002a〜cを通過する到着順序を有する。この例では、第1のフローレット1002aが最初にパケット1004bを配信し、その後すぐに第3のフローレット1008aを配信する。これらの2つのパケット1004b、1008aはその順序でバッファ1010に書き込まれ得る。いくつかの場合、これらの最初の2つのパケット1004b、1008aはフローレット1002a〜cによってほぼ同時に(例えば、同じクロックサイクルで)配信されてよい。このような場合、パケット1004b、1008aが格納される順序はそれらのフローレット1002a、1002cの識別に基づき得るか、または格納順序は任意であり得る。
この例を続けると、パケット1008aの次に、第2のフローレット1002bからの2つのパケット1006a、1006d、第1のフローレット1002aからのパケット1004aが続き得る。第3のフローレット1002cは次のパケット1008bを提供し、次に第1のフローレット1002a、第2のフローレット1002b及び第3のフローレット1002cから、それぞれパケット1004d、1006b、1008dが続き得る。この例の最後の3つのパケット1006c、1004c、1008cは、それぞれ第2のフローレット1002b、第1のフローレット1002a及び第3のフローレット1002cによって配信される。
一旦バッファ1010に格納されると、パケット1004a〜d、1006a〜d、1008a〜dは、それらのフローレット1002a〜cに関して順序通りでなくなるだけでなく、互いに関しても順序通りでなくなる。図10Bは、並び替えが行われ、それらの目的の順番に配置されるパケット1004a〜d、1006a〜d、1008a〜dを例示する。上記の通り、送信ユーザアプリケーションは、各パケットにシーケンス識別子を割り当て得る。この例では、第1のフローレット1002a上で送信されたパケットのグループ1004a〜dが順番の最初にあり、第2のフローレット1002bからのパケットのグループ1006a〜d及び第3のフローレット1002cからのパケットのグループ1008a〜dが続く。
パケットの並び替えは、ドライバプログラム及び/または受信ユーザアプリケーションによって実行されてよい。ドライバプログラムがパケットの並び替えを管理する実装では、ドライバプログラムは、受信ユーザアプリケーションがパケットにアクセスする前にパケット1004a〜d、1006a〜d、1008a〜dを並び替えてよい。追加のメモリ1020は、パケット1004a〜d、1006a〜d、1008a〜dを並び替えるために利用可能であってよく、パケット1004a〜d、1006a〜d、1008a〜dは、それらの適切な順序でこの追加メモリ1020にコピーされてよい。代替的または追加的には、パケット1004a〜d、1006a〜d、1008a〜dは、バッファ1010の間でそれらをコピーすることによって並び替えられてよい。
III.方法
図11〜図14は、カーネルバイパスフレームワークを使用してネットワーク上でパケットを送信するためのプロセスの例であり、いくつかの実装では、緩和された信頼可能なデータグラムトランスポートサービスを例示する。これらのプロセスは、上記システム、例えば、図4、図5A〜図5B、図6A〜図6B及び図7A〜図7Bに関して記載したシステムなどによって実施されてよい。理解を容易にするために、各プロセス例のステップが例示されており、個々のステップは、与えられた以外の順序で実行されてよく、追加のステップを含んでよく、及び/またはより少ないステップに組み合わされてよい。
図11は、ネットワークを通るメッセージを送信しようとしているユーザアプリケーションについてトランスポートコンテキストを決定し得るプロセス1100の一例を例示する。プロセス1100の例は、カーネルバイパスフレームワークを実装するように構成されたネットワークアダプタデバイスによって実行されてよい。ネットワークアダプタデバイスは、ホストデバイスと通信してよく、ホストデバイスは、ネットワーク上でメッセージを送信しようとするユーザアプリケーションを実行中であってよい。
ステップ1102において、ネットワークアダプタデバイスは、メッセージ及びメッセージに関連する宛先情報を受信し得る。メッセージ及び宛先情報は、ホストデバイスから受信されてよい。メッセージは、ほとんどの場合、ホストデバイス上で実行中のユーザアプリケーションによって生成されてよい。宛先情報は、一般的に、ネットワーク内のどこにメッセージを送信すべきかを表す。ほとんどの場合、宛先情報は送信ユーザアプリケーションによって提供される。
ステップ1104では、ネットワークアダプタデバイスは宛先情報を検証し得る。宛先情報は、メッセージの対象となる受信者を様々な方法で表し得る。この例では、宛先情報はネットワークアドレス1106であってよく、例えば、ネットワーク上のシステムのIPアドレスまたはMACアドレス及び/またはネットワーク上のシステム上で動作中の仮想マシンのIPアドレスなどである。代替的または追加的には、宛先情報は、パケットフローのフロー識別子1108であってよい。フロー識別子1108は数値であってよく、及び/またはフローの送信元アドレスと宛先アドレスとの組み合わせであってよい。代替的または追加的には、宛先情報はアドレスハンドル1110であってよい。アドレスハンドル1110は、パケットを生成するために必要となり得るトランスポートコンテキスト及び/または情報を参照するソフトウェア変数またはポインタであってよい。例えば、アドレスハンドル1110は、ネットワークアドレスマップオブジェクトへの参照であってよい。アドレスマップオブジェクトは、適切なトランスポートコンテキストへの参照を格納してよく、事前生成パケットヘッダなどのパケットを送信するための情報をさらに格納してよい。ステップ1112では、ネットワークアダプタデバイスは、アドレスハンドル1110を使用して、ネットワークアドレスマップオブジェクトを決定してよい。
ステップ1114では、ネットワークアダプタデバイスは、宛先情報を使用して、トランスポートコンテキストを決定し得る。ほとんどの実装では、トランスポートコンテキストの決定は、ネットワーク上の特定の宛先に関連しており、ここで、宛先はネットワーク上のシステム、及び/またはネットワーク上のシステム上で動作中の仮想マシン、及び/またはネットワーク上のシステム上で動作中のユーザアプリケーション(場合によっては仮想マシンで動作中である)である。トランスポートコンテキストはネットワーク上でメッセージの送信を管理してよく、これには、メッセージの対象となる宛先にメッセージが到着することを保証することが含まれる。いくつかの実装では、トランスポートコンテキストは、緩和された信頼可能なデータグラムトランスポートサービスを使用して実装される。
プロセス1100の例について、いくつかの任意のステップがさらに例示されている。第1の任意のステップ1116では、ネットワークアダプタデバイスは、メッセージ及び決定されたトランスポートコンテキストを使用してパケットを生成してよい。パケットを生成することは、パケットヘッダを生成すること及びメッセージ本体をパケットペイロードに配置することを含んでよい。いくつかの実装では、事前生成ヘッダが、決定されたトランスポートコンテキストに関連してよい。事前生成パケットヘッダは、送信元及び宛先アドレス及び/またはポートなど、ネットワーク上でパケットをルーティングするための情報を含んでよい。トランスポートコンテキストは、一般的に、特定の宛先に関連しているため、ルーティング情報を事前に把握でき、ネットワークアダプタデバイスによってパケットヘッダを事前に生成して格納してよい。
第2の任意のステップ1118では、ネットワークアダプタデバイスは、決定されたトランスポートコンテキストを使用して、ステップ1116で生成されたパケットを送信してよい。
図12は、アドレスハンドルを取得するためのプロセス1200の一例を例示する。プロセス1200の例は、ネットワークアダプタデバイスによって実行されてよい。ネットワークアダプタデバイスは、ホストデバイスと通信していてよく、ホストデバイスは、ネットワーク上でメッセージを送信しようとするユーザアプリケーションを実行中であってよい。
ステップ1202では、ネットワークアダプタデバイスは、新しいアドレスハンドルの要求を受信してよい。要求は、ユーザアプリケーションによって生成されてよく、ネットワーク上の宛先を表す情報を含んでよい。いくつかの実装では、ネットワークアダプタデバイスは、例えば、ネットワークアダプタデバイス上のメモリに格納され得るアドレスマップにアクセスしてよい。アドレスマップは、ホストデバイス上で動作中のユーザアプリケーションが通信しようとするネットワーク上のシステムのためのアドレス情報を格納してよい。ネットワークアダプタデバイスは、ステップ1204では、アドレスマップを使用して、ステップ1202で受信した要求が新しい宛先に対するものかどうかを判断してよい。この要求は、要求に提供されるアドレス情報がネットワークアダプタデバイスにとって未知である場合に、新しい宛先に対するものである。例えば、ネットワークアダプタデバイスは、既知の宛先を格納するアドレスマップ内の宛先情報を発見できない場合がある。
新しいアドレスハンドルの要求が新しい宛先に対してではない場合、ステップ1206において、ネットワークアダプタデバイスは、宛先情報を使用して、トランスポートコンテキストを決定してよい。決定されたトランスポートコンテキストは、トランスポートコンテキストに関連する宛先のアドレスハンドルに対する以前の要求によって構成されてよい。ネットワークアダプタデバイスは、例えば、宛先情報を使用してアドレスマップをインデックス化し、アドレスマップから正しいトランスポートコンテキスト(またはトランスポートコンテキストを表すデータ構造)への参照を抽出することによって、トランスポートコンテキストを決定してよい。
新しいアドレスハンドルの要求が新しい宛先に対するものである場合、ネットワークアダプタデバイスは、ステップ1210において、宛先情報によって表された宛先の新しいトランスポートコンテキストを生成してよい。ステップ1212では、ネットワークアダプタデバイスは、新しい接続に対する状態情報を新しいトランスポートコンテキストに格納してよい。このステップは、ステップ1208で確立された接続にトランスポートコンテキストを関連させることを含んでよい。トランスポートコンテキストは、その後、例えば、ネットワークを通る経路の設定及び解除、パケットの送信及び/または未処理パケットの状態情報の管理を含む、接続の管理を行ってよい。
ステップ1216では、ネットワークアダプタデバイスは、新しいアドレスマップオブジェクトを生成してよい。新しいアドレスマップオブジェクトを生成することは、パケットをネットワーク上の宛先にルーティングするための送信元及び宛先情報を含む事前構成パケットヘッダを生成して格納することを含んでよい。新しいアドレスマップオブジェクトはさらに、ステップ1210で生成された新しいトランスポートコンテキストまたはステップ1206で決定されたトランスポートコンテキストに関連してよい。
ステップ1208では、ネットワークアダプタデバイスは、宛先情報に関連するネットワーク上のシステムとの新しい接続を確立してよい。新しい接続を確立することは、要求ユーザアプリケーションが宛先システムとの通信を許可されていることをチェックするなどの、検証ステップを含んでよい。接続を確立することはさらに、ネットワークアダプタデバイスと宛先システムとの間のメッセージ交換を含んでよい。いくつかの実装では、ネットワークアダプタデバイスは、以下に説明するステップ1218及び1220の後に新しい接続を確立してよい。いくつかの実装では、ネットワークアダプタデバイスは、ステップ1218及び1220の後に、他の動作を実行しながら接続を確立してよい。いくつかの実装では、ネットワークアダプタデバイスは、ステップ1220で返送されたアドレスハンドルに関連する宛先システムにメッセージが最初に送信されるときに接続を確立してよい。
ステップ1218では、ネットワークアダプタは、新しいアドレスハンドルを生成してよい。アドレスハンドルは、新しいアドレスマップオブジェクトを参照してよく、例えば、アドレスハンドルは、ネットワークアダプタデバイスのメモリ内のアドレスへのソフトウェアポインタであってよい。
ステップ1220では、新しいアドレスハンドルを要求ユーザアプリケーションに返送してよい。要求ユーザアプリケーションは、将来の使用のために新しいアドレスハンドルを格納してよい。
図13は、ネットワーク上でパケットを送信し、各パケットが配信されることを確実にするために各パケットの状態を監視するプロセス1300の一例を例示する。プロセス1300の例は、カーネルバイパスフレームワークを実装するように構成されたネットワークアダプタデバイスによって実行されてよい。いくつかの実装では、ネットワークアダプタデバイスは、緩和された信頼可能なデータグラムトランスポートサービスを使用して、パケットを送信し、それらの状態を監視してよい。
ステップ1302では、ネットワークアダプタデバイスは、メッセージ及び宛先情報を受信してよい。メッセージ及び宛先情報はホストデバイスから受信してよく、複数の送信キューからの送信キューで受信されてよい。宛先情報は、メッセージを受信することになるネットワーク上の宛先を表し得る。ネットワークアダプタデバイスは、キューペアの送信キューでメッセージを受信してよい。キューペアは、ホストデバイス上で実行中のユーザアプリケーションに関連してよい。
ステップ1304では、ネットワークアダプタデバイスは、宛先情報及び送信キューの識別を使用して、トランスポートコンテキストを決定してよい。ほとんどの実装では、トランスポートコンテキストは特定の宛先に関連してよく、ここで、宛先は、この例では、宛先情報及び/または送信キューの識別によって識別されてよい。送信キューの識別は、複数のキューペアの中から送信キューを識別するためにネットワークアダプタデバイスによって使用される英数字値であってよい。
ステップ1305では、ネットワークアダプタデバイスは、各メッセージに対していくつかのステップを実行してよい。まず、ステップ1306では、ネットワークアダプタデバイスは、決定されたトランスポートコンテキストを使用して、パケットを生成してよい。トランスポートコンテキストは、ポート番号、ネットワークアドレス及び/または事前生成パケットヘッダなど、対象となる宛先にネットワーク上でパケットをルーティングするために必要な情報を提供してよい。ネットワークアダプタデバイスは1つのパケットを生成し、そのメッセージをパケットのペイロードに配置してよい。代替的または追加的には、ネットワークアダプタデバイスは、2つ以上のパケットを生成してよく、各パケットは、メッセージの一部をパケットのペイロード内に含む。いくつかの実装では、トランスポートコンテキストは、各パケットにパケットシーケンス番号をさらに割り当ててよく、パケットシーケンス番号は、パケットが送信される順序を示す。
ステップ1308では、ネットワークアダプタデバイスは、トランスポートコンテキストを使用して、ネットワーク上で各パケットを送信してよい。トランスポートコンテキストは、各パケットの送信を管理してよい。ステップ1310では、ネットワークアダプタデバイスは、各送信パケットの状態をさらに監視してよい。トランスポートコンテキストはさらに、パケット状態の監視を管理してよい。各パケットの状態は、パケットが宛先システムで受信されたかどうかを示す。いくつかの実装では、トランスポートコンテキストは、ネットワーク上の宛先からの応答メッセージを予期することがあり、応答メッセージは、1つ以上のパケットが受信されたことを示す。
少なくとも3つのタイプの応答メッセージを受信してよい。まず、ステップ1312では、ネットワークアダプタデバイスは、1つ以上のパケットが宛先で受信されたことを示す応答メッセージを受信してよい。いくつかの実装では、この応答は、1つ以上のパケットが順序通りに受信されたことを示し、その順序はパケットシーケンス番号によって提供され、シーケンスから欠落しているパケットはない。例えば、応答は、パケット番号1、2及び3が受信されたことを示す「3」を示し得る。
第2に、ステップ1314では、ネットワークアダプタデバイスは、1つ以上のパケットが受信されなかったことを示す応答を受信してよい。いくつかの実装では、この応答メッセージは、到着したパケットのパケットシーケンス番号を提供し、シーケンス番号の抜けにより到着していないパケットを示してよい。例えば、応答のパケットシーケンス番号「1、3」は、シーケンス番号「2」のパケットがまだ到着していないことを示してよい。代替的には、いくつかの実装では、応答は、受信されなかったパケットのパケットシーケンス番号をリスト化してよい。例えば、応答のパケットシーケンス番号「2〜4」は、パケット2、3及び4がまだ到着していないことを示してよい。
第3に、ステップ1316では、ネットワークアダプタデバイスは、パケットを再送する要求を含む応答を受信してよい。いくつかの実装では、この応答は、パケットが宛先で受信されたが、パケットがどういうわけか受け入れられなかったことを示す。ステップ1318では、ネットワークアダプタデバイスは、この応答をホストデバイスに配信してよい。ホストデバイスは、パケットを再送する必要がある理由を判断することができ得る、及び/またはパケットを再送するために新しいメッセージを生成し得る。
ネットワークアダプタデバイスは、応答メッセージが受信されない、または応答メッセージが長期間受信されない状況に対しても構成され得る。例えば、ネットワークアダプタデバイスは、パケットがステップ1310で送信されたときにタイマを開始してよい。ステップ1320では、ネットワークアダプタデバイスは、タイマの期限が切れたと判断してよい。タイマの期限が切れると、ネットワークアダプタデバイスは以前に送信された1つ以上のパケットを再送してよい。ネットワークアダプタデバイスはさらに、ネットワーク上の宛先にパケットを送信するために使用されている経路を変更するなどの他の動作をとってよい。
図14は、ネットワーク上でパケットを受信し、パケットが受信されたことを示すために各パケットの応答を生成するプロセス1400の一例を例示する。プロセス1400の例は、カーネルバイパスフレームワークを実装するように構成されるネットワークアダプタデバイスによって実行されてよい。いくつかの実装では、ネットワークアダプタデバイスは、緩和された信頼可能なデータグラムトランスポートサービスを使用して、パケットを受信し、応答を生成してよい。
ステップ1402では、ネットワークアダプタデバイスは、受信キューにおいてパケットを受信してよく、パケットは順不同で受信される。パケットは、ネットワーク上で受信されてよい。受信キューは、キューペアの一部であってよい。パケットの順序は、各パケットに割り当てられたパケットシーケンス番号によって決定されてよい。パケットシーケンス番号が数字順(例えば、最小から最大)でない場合、またはシーケンスからパケットシーケンス番号が欠落している(例えば、パケットがシーケンス番号「1、3」を有する)ためのいずれかの場合、パケットは順不同となり得る。
各パケットを受信すると、ネットワークアダプタデバイスは、ステップ1404において、パケットに関連するトランスポートコンテキストを識別し得る。ネットワークアダプタデバイスは、各パケットに提供された送信元アドレスからトランスポートコンテキストを識別してよい。識別されたトランスポートコンテキストは、パケットを送信している送信元システムとの接続を管理していてよい。トランスポートコンテキストはさらに、特定の送信元システムからのパケットの状態を監視していてよい。
ステップ1405では、ネットワークアダプタデバイスは、パケットが受け入れ可能かどうかを判断してよい。ネットワークアダプタデバイスは、例えば、ホストデバイスにパケットを配置するための利用可能なメモリがない場合にパケットを受け入れ不可能であると判断してよく、これは、パケットを受信するために利用可能なバッファがないことを意味する。これは、受信ユーザアプリケーションがパケットを受信するのに十分なメモリを割り当てていない、及び/またはメモリを十分に速く解放していない場合に生じ得る。いくつかの場合、送信ユーザアプリケーションに通知する必要があり、いくつかの場合、送信ユーザアプリケーションは、パケットを送信している速度を低下し得る。代替的または追加的には、ネットワークアダプタデバイスは、パケットが重複であると判断し得る。代替的または追加的には、ネットワークアダプタデバイスは、パケットが無効であると判断し得る。パケットは、有効なアドレスを持さない場合、不正確なアドレスが指定された場合、破損している場合、及び/または受信前に無効とマークされている場合などには無効となり得る。この例において、ステップ1405では、ネットワークアダプタデバイスは、パケットを受け入れ可能であると判断する。
ステップ1406では、ネットワークアダプタデバイスは、識別されたトランスポートコンテキスト及び受信キューの識別を使用して、パケットを受信するユーザアプリケーションを決定し得る。トランスポートコンテキストはパケットを検証してその宛先を決定し得る。例えば、パケットは宛先アドレスを有してよく、この宛先アドレスは、少なくとも部分的に、パケットを受信することになるユーザアプリケーションを識別し得る。受信キューの識別はさらに、部分的に、パケットを受信することになるユーザアプリケーションを識別し得る。受信キューの識別は、複数のキューペアの中から受信キューを識別するためにネットワークアダプタによって使用される英数字値であってよい。
ステップ1408では、ネットワークアダプタデバイスは、受信ユーザアプリケーションに関連するホストメモリ内のバッファに、受信キューからの受信パケットを転送し得る。ネットワークアダプタデバイスは、受信ユーザアプリケーションに割り当てられたメモリ用の登録キーを有し得る。ネットワークアダプタデバイスは、登録キーを使用して、受信ユーザアプリケーションに割り当てられたメモリにパケットを直接書き込み得る。受信ユーザアプリケーションは、ネットワークからパケットを受信するために、事前にこのメモリにバッファを構成してよい。
いくつかの実装では、ネットワークアダプタデバイスは、1つ以上のパケットを処理する際に、少なくとも3つの応答タイプのうちの1つを送信してよい。トランスポートコンテキストは、フロー内のパケットの状態を監視してよく、適切な応答を提供してよい。
まず、ステップ1410では、ネットワークアダプタデバイスは、1つ以上のパケットが受信されたことを示す応答を送信してよい。いくつかの実装では、この応答は、1つ以上のパケットが順序通りに受信されたことを示し、その順序は各パケットに割り当てられたパケットシーケンス番号によって提供され、シーケンスから欠落しているパケットはない。例えば、応答は、パケット番号1、2及び3が受信されたことを示す「3」を示し得る。
第2に、ステップ1412では、ネットワークアダプタデバイスは、1つ以上のパケットが受信されなかったことを示す応答を送信してよい。いくつかの実装では、この応答メッセージは、到着したパケットのパケットシーケンス番号を提供し、シーケンス番号の抜けにより到着していないパケットを示してよい。例えば、応答のパケットシーケンス番号「1、3」は、番号「2」のパケットが到着しなかったことを示してよい。代替的には、いくつかの実装では、応答は、受信されなかったパケットのパケットシーケンス番号をリスト化してよい。例えば、応答のパケットシーケンス番号「2〜4」は、パケット2、3及び4がまだ到着していないことを示してよい。
第3に、ステップ1414では、ネットワークアダプタデバイスは、上に提供した理由のうちの1つ以上により、別のパケットを受け入れ不可能であると判断してよい。このパケットを受け入れ不可能であると判断すると、ネットワークアダプタデバイスは、ステップ1416でそのパケットをドロップしてよい。ネットワークアダプタは、次いで、任意には、ステップ1418において、パケットを再送しようとすることを示す応答をネットワーク上で送信してよい。この応答は、パケットが到着したがパケットを受け入れ不可能であり、そのため再送する必要があり得ることを送信元システムに示してよい。
IV.ネットワークアダプタデバイス
図15は、上記システム及び方法を実施するために使用され得るネットワークアダプタデバイス1500の一例を例示する。この例では、ネットワークアダプタデバイス1500は、処理コア1502、構成モジュール1504、管理モジュール1506、バスインタフェースモジュール1508、メモリ1510及びネットワークインタフェースモジュール1512を含み得る。これらのモジュールは、ハードウェアモジュール、ソフトウェアモジュールまたはハードウェアとソフトウェアとの組み合わせであり得る。ネットワークアダプタデバイス1500は、図面には例示されていない追加のモジュールを含み得る。いくつかの実装では、ネットワークアダプタデバイス1500は、より少ないモジュールを含み得る。モジュールのうちの1つ以上は通信チャネル1514上で互いに通信し得る。通信チャネル1514は、1つ以上のバス、メッシュ、マトリクス、ファブリック、これらの通信チャネルの組み合わせまたはいくつかの他の適切な通信チャネルを含み得る。いくつかの実装では、ネットワークアダプタデバイス1500の動作は、単一の集積回路または集積回路のグループに実装されてよい。集積回路の例には、ASIC及びFPGAが含まれる。
いくつかの実装では、処理コア1502は、命令を実行するように構成された1つ以上のプロセッサを含み得る。処理コア1502に含まれ得るプロセッサの例には、ARM、MIPS、AMD、Intel、Qualcomm及びその他によって開発されたプロセッサが含まれる。いくつかの実装では、処理コア1502のプロセッサは、例えば、バス、レベル1(L1)キャッシュ及び/またはレベル2(L2)キャッシュなどの特定のリソースを共有し得る。処理コア1502によって実行される命令は、例えば、コンピュータプログラムの形態でコンピュータ可読記憶媒体に格納されてよい。コンピュータ可読記憶媒体は非一時的であり得る。いくつかの場合、コンピュータ可読媒体はメモリ1510の一部であってよい。いくつかの実装では、処理コア1502の動作(処理コア1502によって実行される命令の一部または全てを含むことがあるが、必ずしもそうではない)は、1つ以上の集積回路に実装されてよい。集積回路の例には、ASIC及びFPGAが含まれる。
メモリ1510は、揮発性または不揮発性のいずれか、または揮発性と不揮発性との両方のタイプのメモリを含み得る。メモリ1510は、例えば、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、電気的消去可能プログラマブル読み出し専用メモリ(EEPROM)、フラッシュメモリ、及び/またはいくつかの他の適切な記憶媒体を含み得る。いくつかの場合、メモリ1510の一部または全てがネットワークアダプタデバイス1500の内部にあってよく、他の場合には、メモリの一部または全てがネットワークアダプタデバイス1500の外部にあってよい。
いくつかの実装では、構成モジュール1504は、1つ以上の構成レジスタを含み得る。構成レジスタは、ネットワークアダプタデバイス1500の動作を制御し得る。いくつかの実装では、構成レジスタの1つ以上のビットは、ネットワークアダプタデバイス1500の特定の能力を表わすことができる。構成レジスタは、処理コア1502で実行中の命令によって、及び/またはホストデバイス、ホストデバイス上で実行中のオペレーティングシステム、及び/またはリモートサーバなどの外部エンティティによってプログラムされ得る。構成モジュール1504はさらに、ネットワークアダプタデバイス1500の動作を制御するハードウェア及び/またはソフトウェアを含み得る。
いくつかの実装では、管理モジュール1506は、ネットワークアダプタデバイス1500の異なる構成要素を管理するように構成され得る。いくつかの場合、管理モジュール1506は、電源投入時に1つ以上の構成レジスタの1つ以上のビットを構成し、ネットワークアダプタデバイス1500の特定の機能を有効または無効にし得る。
バスインタフェースモジュール1508は、外部通信媒体上で、ホストデバイス及び/またはコンピューティングシステム内の他の構成要素などの外部エンティティとの通信を可能にし得る。バスインタフェースモジュール1508は、ケーブル、ソケット、ポートに接続する物理インタフェースまたは外部通信媒体への他の接続を含み得る。バスインタフェースモジュール1508はさらに、受信及び送信トランザクションを管理するためのハードウェア及び/またはソフトウェアを含み得る。バスインタフェースモジュール1508は、NVMe、AHCI、SCSI、SAS、SATA、PATA及びその他などのローカルバスプロトコルを実装し得る。バスインタフェースモジュール1508は、コネクタ、電力管理、エラー処理などを含む、これらのバスプロトコルのうちの任意のための物理層を少なくとも含み得る。いくつかの実装では、ネットワークアダプタデバイス1500は、複数の外部エンティティと通信するための複数のバスインタフェースモジュールを含み得る。これらの複数のバスインタフェースモジュールは、同じローカルバスプロトコル、異なるローカルバスプロトコルまたは同じバスプロトコルと異なるバスプロトコルとの組み合わせを実装し得る。
ネットワークインタフェースモジュール1512は、ネットワークと通信するためのハードウェア及び/またはソフトウェアを含み得る。このネットワークインタフェースモジュール1512は、例えば、ネットワークへの有線接続のための物理的コネクタ及び/またはネットワークへの無線通信のためのアンテナを含み得る。ネットワークインタフェースモジュール1512はさらに、ネットワークプロトコルスタックを実装するように構成されたハードウェア及び/またはソフトウェアを含み得る。ネットワークインタフェースモジュール1512は、とりわけ、例えば、TCP/IP、Infiniband、RoCE、米国電気電子技術者協会(IEEE)802.11無線プロトコル、ユーザデータグラムプロトコル(UDP)、非同期転送モード(ATM)、トークンリング、フレームリレー、高レベルデータリンク制御(HDLC)、ファイバ分散データインタフェース(FDDI)及び/またはポイントツーポイントプロトコル(PPP)などのネットワークプロトコルを使用してネットワークと通信し得る。いくつかの実装では、ネットワークアダプタデバイス1500は、それぞれが異なるネットワークと通信するように構成された複数のネットワークインタフェースモジュールを含み得る。例えば、これらの実装では、ネットワークアダプタデバイス1500は、有線イーサネットネットワーク、無線802.11ネットワーク、セルラネットワーク、Infinibandネットワークなどと通信するためのネットワークインタフェースモジュールを含み得る。
いくつかの実装では、ネットワークアダプタデバイス1500は、PCIタイプのデバイスである。これらの実装では、ネットワークアダプタデバイス1500は、ホストデバイスと通信するためのPCIインタフェースを含む。「PCI」という用語は、最初のPCI規格、PCI−X、AGP及びPCIeを含む、PCI系列のバスプロトコルの任意のプロトコルを表すために使用され得る。PCIプロトコルは、ローカル周辺装置をホストデバイスに接続するための標準バスプロトコルである。標準化されたバスプロトコルは、様々な製造者によって仕様が定義されて採用されているデータトランスポートプロトコルである。製造者は、準拠したデバイスがバスプロトコルを実装しているコンピューティングシステムと互換性があり、逆も同じであることを確実にする。
PCIデバイスは、1つ以上の機能を含み得る。「機能」はネットワークアダプタデバイス1500によって提供され得る動作を表す。機能の例には、とりわけ、大容量記憶コントローラ、ネットワークコントローラ、ディスプレイコントローラ、メモリコントローラ、シリアルバスコントローラ、無線コントローラならびに暗号化及び復号コントローラが含まれる。いくつかの場合、PCIデバイスは2つ以上の機能を含み得る。例えば、PCIデバイスは、大容量記憶コントローラ及びネットワークアダプタを提供し得る。別の例として、PCIデバイスは、2つの異なるストレージリソースを制御するために、2つのストレージコントローラを提供し得る。いくつかの実装では、PCIデバイスは最大8つの機能を有し得る。
いくつかの実装では、ネットワークアダプタデバイス1500は、シングルルートI/O仮想化(SR−IOV)を含み得る。SR−IOVは、PCIデバイスに含まれ得る拡張機能である。SR−IOVによって、物理リソース(例えば、単一のネットワークインタフェースコントローラ)は複数のリソース(例えば、64のネットワークインタフェースコントローラ)として現われることができる。ゆえに、ある特定の機能性(例えば、ネットワークインターフェースコントローラ)を提供するPCIデバイスは、PCIデバイスを利用しているデバイスにとって、同じ機能性を提供している複数のデバイスとして現れ得る。SR−IOV対応ストレージアダプタデバイスの機能は、物理機能(PF)または仮想機能(VF)として分類され得る。物理的機能は、デバイスの完全に機能化された機能であり、検出、管理及び操作が可能である。物理機能は、ストレージアダプタデバイスを構成または制御するために使用できる構成リソースを有する。物理機能には、仮想化されていないデバイスと同じ構成アドレス空間及びメモリアドレス空間が含まれる。物理機能は、それに関連したいくつかの仮想機能を有し得る。仮想機能は物理機能に類似しているが、構成リソースが不足している小型の機能であり、一般的には基礎となる物理機能の構成によって制御される。物理機能及び/または仮想機能のそれぞれは、ホストデバイス上で動作中のそれぞれの実行スレッド(例えば、仮想マシンなど)に割り当てられてよい。
V.コンピューティングシステム
図16は、本明細書に記載された機能及びシステムのためのアーキテクチャ1600の例を例示する。アーキテクチャ1600の例は、1つ以上のネットワーク1608を介して接続される1つ以上のサービスプロバイダコンピュータ1610及び/またはユーザデバイス1604を含む。上述のシステム及び方法は、図16に記載されたコンピューティングデバイスの1つ以上の構成要素を使用し得るか、または図16に記載された1つ以上のコンピューティングデバイスを表し得る。
例示のアーキテクチャ1600においては、1つ以上のユーザ1602は、ユーザコンピューティングデバイス1604(1)〜(N)を使用して、アプリケーション1606(例えば、ウェブブラウザまたはモバイルデバイスのアプリケーション)に1つ以上のネットワーク1608を介してアクセスし得る。いくつかの態様では、アプリケーション1606は、コンピューティングリソースサービスまたはサービスプロバイダによってホスト、管理及び/または提供され得る。1つ以上のサービスプロバイダコンピュータ1610は、ユーザ(複数可)1602が相互作用し得るユーザデバイス1604上で動作するように構成されるネイティブアプリケーションを提供し得る。いくつかの例では、サービスプロバイダコンピュータ(複数可)1610は、以下に限定されないが、クライアントエンティティ、低レイテンシデータストレージ、永続データストレージ、データアクセス、管理、仮想化、クラウドベースのソフトウェアソリューション、電子コンテンツの性能管理及びその他などのコンピューティングリソースを提供し得る。サービスプロバイダコンピュータ(複数可)1610も、ウェブホスティング、データベース化、コンピュータアプリケーション開発及び/または実装のプラットフォーム、ユーザ(複数可)1602に対する前述のものまたはその他等の組み合わせを提供するように動作可能であり得る。サービスプロバイダコンピュータ(複数可)1610は、いくつかの例では、1つ以上の第三者コンピュータ1612と通信し得る。
いくつかの例では、ネットワーク(複数可)1608は、ケーブルネットワーク、インターネット、無線ネットワーク、セルラネットワークならびに他の私設及び/または公衆ネットワークなどの、多くの異なるタイプのネットワークのうちいずれか1つ、またはそれらの組み合わせを含み得る。例示の例は、ネットワーク(複数可)1608上でアプリケーション1606にアクセスするユーザ(複数可)1602を表す一方、記載された技法は、固定電話上のユーザデバイス(複数可)1604を介して、電話ボックスを介してまたはいくつかの他の方式でユーザ(複数可)1602がサービスプロバイダコンピュータ(複数可)1610と相互作用する場合に等しく適用し得る。非クライアント/サーバの配置(例えば、ローカルに格納されるアプリケーション等)と同様に、記載された技法はさらに、他のクライアント/サーバの配置(例えば、セットトップボックス等)に適用し得る。
上述の通り、アプリケーション1606は、例えば、ウェブコンテンツ(例えば、ウェブページ、音楽、ビデオ等)にアクセスするサービスプロバイダコンピュータ(複数可)1610とユーザ(複数可)1602が相互作用することを可能にし得る。サービスプロバイダコンピュータ(複数可)1610は、サーバのクラスタまたはサーバファームにおいて配置され得、アプリケーション1606及び/またはクラウドベースのソフトウェアサービスをホストし得る。他のサーバ構造はさらに、アプリケーション1606をホストするために使用され得る。アプリケーション1606は、多くのユーザ1602からの要求の処理をし、応答として、例えば、様々な項目ウェブページを提供することが可能であり得る。アプリケーション1606は、ソーシャルネットワーキングサイト、オンライン小売業者、情報サイト、ブログサイト、検索エンジンサイト、ニュース及びエンタテインメントサイト及びその他を含むユーザの相互作用を支援する任意のタイプのウェブサイトを提供可能である。上述の通り、説明した技法は、ユーザデバイス(複数可)1604上で動作中の他のアプリケーションなどのアプリケーション1606の外部で同様に実施されることが可能である。
ユーザデバイス1604(複数可)は、例えば、携帯電話、スマートフォン、携帯情報端末(PDA)、ラップトップコンピュータ、ネットブックコンピュータ、デスクトップコンピュータ、シンクライアントデバイス、タブレットコンピュータ、電子ブック(eブック)リーダ、ゲーミングコンソール等などの、コンピューティングデバイスであり得る。いくつかの例では、ユーザデバイス(複数可)1604は、ネットワーク(複数可)1608を介してまたは他のネットワーク接続を介して、サービスプロバイダコンピュータ(複数可)1610と通信し得る。追加的には、ユーザデバイス(複数可)1604は、サービスプロバイダコンピュータ(複数可)1610(例えば、サービスプロバイダコンピュータ1610に統合されたコンソールデバイス)によって管理及び制御される分散システムの一部であり得るか、または別様にはサービスプロバイダコンピュータ(複数可)1610の一部であり得る。
1つの構成例において、ユーザデバイス(複数可)1604は、少なくとも1つのメモリ1614及び1つ以上の処理ユニット(またはプロセッサ(複数可)1616)を含み得る。プロセッサ(複数可)1616は、ハードウェア、コンピュータ実行可能命令、ファームウェアまたはそれらの組み合わせで実装され得る。コンピュータ実行可能命令またはプロセッサ(複数可)1616のファームウェア実装は、記載された様々な機能を行うために好適な任意のプログラミング言語で書かれたコンピュータで実行可能または機械で実行可能な命令を含み得る。ユーザデバイス(複数可)1604はさらに、ユーザデバイス(複数可)1604と関連する地理的位置情報を提供及び/または記録するための測位デバイス(例えば、衛星測位システム(GPS)デバイスまたはその他)を含み得る。
ユーザデバイスメモリ1614は、これらのプログラムの実行中に生成されるデータと同様に、ユーザデバイスプロセッサ(複数可)1616に搭載可能で、かつ実行可能なプログラム命令を格納し得る。ユーザデバイス(複数可)1604の構成及びタイプにより、ユーザデバイスメモリ1614は、揮発性(ランダムアクセスメモリ(RAM)及び/または不揮発性(読み出し専用メモリ(ROM)、フラッシュメモリ等)であり得る。ユーザデバイス(複数可)1604はさらに、取り外し可能なストレージ及び/または取り外し不可能なストレージを含み得るが、磁気ストレージ、光ディスク、ソリッドステートディスク、フラッシュメモリ及び/またはテープストレージに限定されない。ストレージデバイス及びそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール及びコンピューティングデバイス用の他のデータの不揮発性ストレージを提供し得る。いくつかの実装では、メモリ1614は、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)またはROMなどの複数の異なるタイプのメモリを含み得る。
ユーザデバイスメモリ1614の内容をより詳細に見ると、メモリ1614は、本明細書で開示される機能を実装するためのオペレーティングシステム及び1つ以上のアプリケーションプログラムまたはサービスを含み得る。1つ以上のアプリケーションプログラムまたはサービスは、ブラウザアプリケーション1606または専用のアプリケーション(例えば、スマートフォンのアプリケーション、タブレットのアプリケーション等)などの少なくともユーザが提供した入力要素または電子サービスのウェブページを含み得る。ブラウザアプリケーション1606は、サービスプロバイダコンピュータ(複数可)1610と相互作用するウェブサイトまたは他のインタフェースを受信、格納及び/または表示するように構成され得る。追加的に、メモリ1614は、アクセスの認証情報及び/または、例えば、ユーザID、パスワード及び/または他のユーザ情報などの他のユーザ情報を格納し得る。いくつかの例では、ユーザ情報は、アカウントへのアクセス要求を認証するための情報を含み得る。このような情報は、例えば、デバイスのID、クッキー、IPアドレス、位置またはその他を含む。加えて、ユーザ情報は、ユーザデバイス1604によって取得されたセキュリティの質問に対してユーザが提供した応答または地理的位置を含み得る。
いくつかの態様では、サービスプロバイダコンピュータ(複数可)1610は、携帯電話、スマートフォン、携帯情報端末(PDA)、ラップトップコンピュータ、デスクトップコンピュータ、ネットブックコンピュータ、サーバコンピュータ、シンクライアントデバイス、タブレットコンピュータ、ゲーミングコンソール等などの、コンピューティングデバイスを含み得る。追加的または代替的には、いくつかの実施形態では、サービスプロバイダコンピュータ(複数可)1610は、ホスト型コンピューティング環境で実装される1つ以上の仮想マシンによって提供され得る。ホスト型コンピューティング環境は、1つ以上の迅速にプロビジョニングされ、解放されるコンピューティングリソースを含んでよい。これらのコンピューティングリソースは、コンピューティング、ネットワーキング及び/またはストレージデバイスを含み得る。ホスト型コンピューティング環境はさらに、クラウド型コンピューティング環境と呼ばれ得る。いくつかの例では、サービスプロバイダコンピュータ(複数可)1610は、ユーザデバイス(複数可)1604及び/または他のサービスプロバイダとネットワーク(複数可)1608または他のネットワーク接続を介して通信し得る。サービスプロバイダコンピュータ(複数可)1610は、場合により、互いに関連しないサーバファームまたは個別のサーバとしてクラスタに配置される1つ以上のサーバを含み得る。これらのサーバは、統合され、分散されたコンピューティング環境の一部として構成され得る。
1つの構成例においては、サービスプロバイダコンピュータ(複数可)1610は、少なくとも1つのメモリ1618及び1つ以上の処理ユニット(またはプロセッサ(複数可)1620)を含み得る。プロセッサ(複数可)1620は、ハードウェア、コンピュータ実行可能命令、ファームウェアまたはそれらの組み合わせにおいて実装され得る。コンピュータ実行可能命令またはプロセッサ(複数可)1620のファームウェア実装は、記載された様々な機能を行うために任意の好適なプログラミング言語で書かれたコンピュータで実行可能または機械で実行可能な命令を含み得る。
いくつかの場合、ハードウェアプロセッサ(複数可)1620は、シングルコアプロセッサまたはマルチコアプロセッサであり得る。マルチコアプロセッサは、同一のプロセッサ内に多数の処理ユニットを含み得る。いくつかの実施形態では、マルチコアプロセッサは、バス及び第2または第3レベルのキャッシュなどの特定のリソースを共有し得る。いくつかの場合、シングルまたはマルチコアプロセッサのそれぞれのコアもまた、多数の実行論理プロセッサ(または実行スレッド)を含み得る。このようなコア(例えば、多数の論理プロセッサを備えるコア)においては、実行パイプライン及びさらに低レベルキャッシュのいくつかのステージもまた共有され得る。
メモリ1618は、これらのプログラムの実行中に生成されるデータと同様に、プロセッサ(複数可)1620に搭載可能で、かつ実行可能なプログラム命令を格納し得る。サービスプロバイダコンピュータ(複数可)1610の構成及びタイプにより、メモリ1618は、揮発性(RAMのような)及び/または不揮発性(ROM、フラッシュメモリ等)であり得る。メモリ1618は、オペレーティングシステム1628、1つ以上のデータストア1630、1つ以上のアプリケーションプログラム1632、1つ以上のドライバ1634及び/または本明細書に開示する機能を実装するためのサービスを含み得る。
オペレーティングシステム1628は、タスクのスケジューリング、アプリケーション及び/またはコントローラ周辺装置の実行などのサービスプロバイダコンピュータ1610の基本機能を支援し得る。いくつかの実装では、サービスプロバイダコンピュータ1610は、1つ以上の仮想マシンをホストし得る。これらの実装では、各仮想マシンは、独自のオペレーティングシステムを実行するように構成され得る。オペレーティングシステムの例には、Unix、Linux、Windows、Mac OS、iOS、Android及びその他が含まれる。オペレーティングシステム1628はさらに、専有オペレーティングシステムであり得る。
データストア1630は、オペレーティングシステム1628、アプリケーションプログラム1632またはドライバ1634によって使用及び/または操作される永久または一時データを含み得る。このようなデータの例には、ウェブページ、ビデオデータ、オーディオデータ、画像、ユーザデータなどが含まれる。いくつかの実装では、データストア1630内の情報は、ネットワーク1608(複数可)上でユーザデバイス1604に提供されてよい。いくつかの場合、データストア1630は、格納されたアプリケーションプログラム及び/またはドライバを追加的または代替的に含み得る。代替的または追加的には、データストア1630は、標準及び/または専有ソフトウェアライブラリ及び/または標準及び/または専有アプリケーションユーザインターフェイス(API)ライブラリを格納し得る。データストア1630に格納される情報は、機械可読オブジェクトコード、ソースコード、解釈済みコードまたは中間コードであり得る。
アプリケーションプログラム1632は、ネットワーク(複数可)1608上でユーザデバイス1604にアクセス可能なプログラムを含み得る。そのようなプログラムの例には、ワードプロセッシングプログラム、会計プログラム、メディアプレーヤ、画像編集プログラム、ゲーム及びその他が含まれる。アプリケーションプログラム1632は、代替的または追加的には、クラスタリング環境または分散環境で実行するプログラム、つまり、複数のサーバプロバイダコンピュータ1610間で協働して実行するアプリケーションを含み得る。
ドライバ1634は、サーバプロバイダコンピュータ1610内の構成要素間の通信を提供し得るプログラムを含む。例えば、いくつかのドライバ1634は、オペレーティングシステム1628と追加のストレージ1622、通信接続1624及び/またはI/Oデバイス1626との間の通信を提供し得る。代替的または追加的には、いくつかのドライバ1634は、アプリケーションプログラム1632とオペレーティングシステム1628、及び/またはアプリケーションプログラム1632とサービスプロバイダコンピュータ1610にアクセス可能な周辺装置との間の通信を提供し得る。多くの場合、ドライバ1634は、公知の機能性を提供するドライバ(例えば、プリンタドライバ、ディスプレイドライバ、ハードディスクドライバ)を含み得る。他の場合には、ドライバ1634は専有または特殊機能性を有し得る。
サービスプロバイダコンピュータ(複数可)1610またはサーバはさらに、追加のストレージ1622を含むことがあり、取り外し可能なストレージ及び/または取り外し不可能なストレージを含み得る。追加のストレージ1622は、磁気ストレージ、光ディスク、ソリッドステートディスク、フラッシュメモリ及び/またはテープストレージを含み得る。追加のストレージ1622はサービスプロバイダコンピュータ(複数可)1610と同じ筐体に格納され得るか、外部筐体内にあり得る。メモリ1618及び/または追加のストレージ1622及びそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール及びコンピューティングデバイスのための他のデータの不揮発性ストレージを提供し得る。いくつかの実装では、メモリ1618は、SRAM、DRAMまたはROMなどの複数の異なるタイプのメモリを含み得る。
取り外し可能及び取り外し不可能なメモリ1618、追加のストレージ1622の両方は、コンピュータ可読記憶媒体の例である。例えば、コンピュータ可読記憶媒体は、情報の記憶のための方法または技術で実装される揮発性もしくは不揮発性、取り外し可能もしくは取り外し不可能な媒体を含み得、情報は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを含む。メモリ1618及び追加のストレージ1622は、コンピュータ記憶媒体の例である。サービスプロバイダコンピュータ(複数可)1610において存在し得るコンピュータ記憶媒体の追加のタイプは、PRAM、SRAM、DRAM、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、DVDまたは他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、ソリッドステートドライブまたは所望の情報を記憶するために使用可能であり、サービスプロバイダコンピュータ(複数可)1610によってアクセス可能ないくつかの他の媒体を含み得るがこれらに限定されない。上記の媒体のタイプの任意の組み合わせも、コンピュータ可読媒体に含まれる。
代替的または追加的には、コンピュータ可読通信媒体は、コンピュータ可読命令、プログラムモジュールまたは搬送波または他の伝送などのデータ信号内で伝送される他のデータを含み得る。しかしながら、本発明で使用する場合、コンピュータ可読記憶媒体は、コンピュータ可読通信媒体を含まない。
サービスプロバイダコンピュータ(複数可)1610もまた、サービスプロバイダコンピュータ(複数可)1610が、格納されたデータベース、別のコンピューティングデバイスもしくはサーバ、ユーザ端末及び/またはネットワーク(複数可)1608上の他のデバイスと通信できるようにする通信接続(複数可)1624を含有し得る。サービスプロバイダコンピュータ(複数可)1610もまた、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、ディスプレイ、スピーカ、プリンタ及びその他などのI/Oデバイス(複数可)1626を含み得る。通信接続(複数可)1624及びI/Oデバイス(複数可)1626は、ストレージ1622と共に、周辺装置として記載され得る。
サービスプロバイダコンピュータ(複数可)1610もまた、1つ以上の通信チャネル1634を含み得る。通信チャネル1634はサービスプロバイダコンピュータ1610の様々な構成要素が通信可能な媒体を提供し得る。1つ以上の通信チャネル1634はバス、リング、スイッチングファブリクまたはネットワークの形態をとり得る。
本明細書で記載されたモジュールは、ソフトウェアモジュール、ハードウェアモジュールまたはそれらの好適な組み合わせであり得る。モジュールがソフトウェアモジュールである場合には、モジュールは非一時的なコンピュータ可読媒体上で具現化され、本明細書に記載されたコンピュータシステムのいずれかのプロセッサによって処理されることができる。記載された処理及び構造は、リアルタイムでまたは任意のユーザの相互作用の前の非同期モードのいずれかで実行されることが可能であるという点に留意すべきである。モジュールは図16に提示された方式で構成されてよく、及び/または本明細書で記載された機能は、個別のモジュールとして存在する1つ以上のモジュールによって提供されることが可能であり、及び/または本明細書で記載されたモジュール機能は複数のモジュール上で分散されることが可能である。
図17は、様々な実施形態に従う態様を実装するための環境1700の例の態様を例示する。理解されるように、ウェブベースの環境が説明の目的のために使用されるが、様々な実施形態を実装するために異なる環境が必要に応じて使用され得る。環境は電子クライアントデバイス1702を含み、電子クライアントデバイスは、要求、メッセージまたは情報を適切なネットワーク1704上で送信及び受信し、デバイスのユーザに情報を返送するように動作可能である、適切なデバイスを含むことができる。このようなクライアントデバイスの例には、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージングデバイス、ラップトップコンピュータ、セットトップボックス、パーソナルデータアシスタント、電子ブックリーダ及びその他が含まれる。ネットワークは、イントラネット、インターネット、セルラネットワーク、ローカルエリアネットワークまたは任意の他のこのようなネットワークもしくはその組み合わせを含む、任意の適切なネットワークを含むことがある。このようなシステムのために使用される構成要素は、選択されるネットワーク及び/または環境のタイプに少なくとも部分的に依存することがある。このようなネットワークを介して通信するためのプロトコル及び構成要素は周知であり、本明細書において詳細に説明されない。ネットワーク上の通信は、有線接続または無線接続及びそれらの組み合わせによって可能にされることがある。この例では、環境は要求を受信し、要求に応えてコンテンツを提供するためのウェブサーバ1706を含むため、ネットワークはインターネットを含む。ただし、他のネットワークの場合、当業者に明白であるように、同様の目的を果たす代替のデバイスが使用できるだろう。
例示的な環境は、少なくとも1つのアプリケーションサーバ1708及びデータストア1710を含む。いくつかのアプリケーションサーバ、層もしくは他の要素、プロセスまたは構成要素が存在することがあり、これらは、チェーン接続されるか、または別様には構成されることがあり、適切なデータストアからデータを取得するなどのタスクを行うために相互作用することがあることを理解されたい。本明細書で使用されるように、用語「データストア」は、データを格納する、データにアクセスする及びデータを取り出すことができる任意のデバイスまたはデバイスの組み合わせを指し、これは、データサーバ、データベース、データストレージデバイス及びデータ記憶媒体の任意の組み合わせ及び数を、任意の標準的な環境、分散環境またはクラスタ化された環境に含んでよい。アプリケーションサーバは、データストアと統合してクライアントデバイスのための1つ以上のアプリケーションの態様を実行するために、必要に応じてデータストアと相互作用し、データアクセス及びアプリケーションのためのビジネスロジックの大多数を処理するための任意の適切なハードウェア及びソフトウェアを含むことがある。アプリケーションサーバは、データストアと協働してアクセス制御サービスを提供し、ユーザに転送されるテキスト、グラフィックス、音声及び/またはビデオなどのコンテンツを生成することができ、コンテンツは、この例ではハイパーテキストマークアップ言語(「HTML」)、拡張マークアップ言語(「XML」)または別の適切な構造言語の形態でウェブサーバによってユーザに提供されてよい。全ての要求及び応答の処理ならびにクライアントデバイス1702とアプリケーションサーバ1708との間でのコンテンツの配信は、ウェブサーバ1706によって処理できる。本明細書で述べる構造化されたコードは、本明細書の他の部分で述べる任意の適切なデバイスまたはホストマシンで実行できるので、ウェブサーバ1706及びアプリケーションサーバ1708は必要とされず、単に例の構成要素であることを理解されたい。
データストア1710は、いくつかの個別のテーブル、データベースまたは特定の態様に関するデータを記憶するための他のデータ記憶機構及び媒体を含むことがある。例えば、例示のデータストア1720は、生産側にコンテンツを提供するために使用できる生産データ1712及びユーザ情報1716を格納するための機構を含む。データストアはさらに、報告、分析または他のこのような目的のために使用できるログデータ1714を記憶するための機構を含むと示される。ページ画像情報のために、及び必要に応じて上記にリストされる機構またはデータストア1710の追加の機構のいずれかに記憶できる正しい情報にアクセスするためになど、データストア1710に記憶される必要のあり得る多くの他の態様があり得ると理解されたい。データストア1710は、データストアに関連するロジックを通して、アプリケーションサーバ1708から命令を受信し、命令に応えてデータを取得、更新または別様には処理するよう動作可能である。一例では、ユーザは特定のタイプの項目に対する検索要求を送信する可能性がある。この場合、データストア1710は、ユーザ情報1716にアクセスしてユーザのアイデンティティを検証する可能性があり、そのタイプの項目についての情報を取得するためにカタログ詳細情報にアクセスできる。情報は、次いで、ユーザがユーザデバイス1702上のブラウザを介して見ることができるウェブページ上の結果リストなどで、ユーザに返送することができる。対象のある特定の項目の情報は、ブラウザの専用ページまたはウィンドウ内で見ることができる。
各サーバ1706、1708は、通常、そのサーバの一般的な管理及び操作のための実行可能なプログラム命令を提供するオペレーティングシステムを含み、通常、サーバのプロセッサによって実行されるときに、サーバがその目的の機能を実行できるようにする命令を格納するコンピュータ可読記憶媒体(例えば、ハードディスク、ランダムアクセスメモリ、読み出し専用メモリ等)を含む。サーバのオペレーティングシステム及び一般的な機能性の適切な実装は既知であるか、または市販されており、特に、本明細書の開示に鑑みて当業者によって容易に実装される。
一実施形態における環境1700は、1つ以上のコンピュータネットワークまたは直接接続を使用し、通信リンクを介して相互接続されるいくつかのコンピュータシステム及び構成要素を利用する、分散型コンピューティング環境である。しかしながら、このようなシステムは、図17に例示されるよりも少ない数または多い数の構成要素を有するシステムにおいて同等に良好に動作し得ることが当業者によって理解される。ゆえに、図17のシステムの描写は、本質的に例示であり、本開示の範囲を限定するものではないと見なされるべきである。
本開示の実施形態は、以下の条項を鑑みて説明できる。
1.プロセッサと、
前記プロセッサに連結されて前記プロセッサによって読み取り可能なメモリであって、前記メモリはユーザアプリケーションを格納するように構成されている、前記メモリと
を備えるホストデバイスと、
ネットワークと通信するように構成されるネットワークアダプタデバイスと
を備えるコンピューティングシステムであって、
前記ホストデバイスは、
前記ユーザアプリケーションを実行するように構成され、前記ユーザアプリケーションは、
メッセージに対する宛先アドレスを決定し、前記宛先アドレスは前記ネットワーク上のサーバに関連している、前記決定することと、
前記宛先アドレスに対するアドレスハンドルを決定することと、
前記メッセージ及び前記アドレスハンドルを前記ネットワークアダプタに提供することと
を行うように構成され、
前記ネットワークアダプタデバイスは、
前記アドレスハンドルを使用して、トランスポートコンテキストを決定し、前記トランスポートコンテキストは前記宛先アドレスに関連する前記ネットワーク上の前記サーバとの接続の状態を含む、前記決定することと、
前記メッセージ及び前記トランスポートコンテキストを使用して、パケットを生成することと、
前記ネットワーク上で前記パケットを送信することと
を行うように構成される、
前記コンピューティングシステム。
2.前記ホストデバイスはさらにドライバプログラムを実行するように構成され、前記ユーザアプリケーションはさらに、前記宛先アドレスに対する前記アドレスハンドルを決定できないときに、
前記ドライバプログラムからアドレスハンドルを要求することであって、前記要求は前記宛先アドレスを含む、前記要求することを行うように構成され、
前記ドライバプログラムは、
アドレスマップを使用して、前記宛先アドレスに対するアドレスハンドルを決定することと、
前記ユーザアプリケーションに前記アドレスハンドルを提供することと
を行うように構成される、
条項1に記載のコンピューティングシステム。
3.前記ドライバプログラムはさらに、
前記アドレスマップが前記宛先アドレスを含まないことを判断することと、
前記ネットワークアダプタデバイスに前記宛先アドレスを提供することと
を行うように構成され、
前記ネットワークアダプタデバイスはさらに、
新しい接続のために新しいトランスポートコンテキストを生成することと、
前記新しいトランスポートコンテキスト内に前記新しい接続の状態を格納することと、
新しいアドレスハンドルを前記新しいトランスポートコンテキストに関連させることと、
新しいアドレスハンドルを前記ドライバプログラムに提供することと、
前記宛先アドレスに関連する前記ネットワーク上の前記サーバとの前記新しい接続を確立することと
を行うように構成され、
前記ドライバプログラムはさらに、
前記新しいアドレスハンドルを使用して、前記アドレスマップ内に前記宛先アドレスを格納することを行うように構成され、
前記決定されたトランスポートコンテキストは前記新しいトランスポートコンテキストであり、前記ドライバプログラムによって提供された前記アドレスハンドルは前記新しいアドレスハンドルである、
条項2に記載のコンピューティングシステム。
4.プロセッサと、
前記1つ以上のプロセッサに連結されて前記1つ以上のプロセッサによって読み取り可能なメモリであって、前記メモリは複数のトランスポートコンテキストを格納するように構成されている、前記メモリとを備える装置であって、
前記装置は、
ネットワーク及びホストデバイスと通信することと、
メッセージ及び前記メッセージに関連する宛先情報を前記ホストデバイスから受信することと、
前記宛先情報を使用して、前記複数のトランスポートコンテキストから1つのトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先との接続の状態を含み、前記ネットワーク上の前記宛先は前記宛先情報に関連している、前記決定することと
を行うように構成される、前記装置。
5.前記装置はさらに、
前記メッセージ及び前記トランスポートコンテキストを使用してパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で、前記パケットを送信することと
を行うように構成される、条項4に記載の装置。
6.前記宛先情報はアドレスハンドルを備え、前記装置はさらに、
前記アドレスハンドルを使用して、複数のアドレスマップオブジェクトから1つのネットワークアドレスマップオブジェクトを決定することであって、前記複数のアドレスマップオブジェクトは前記メモリに格納されており、前記アドレスマップオブジェクトは前記決定されたトランスポートコンテキストに関連している、前記決定すること
を行うように構成される、条項4または5に記載の装置。
7.前記ネットワークアドレスマップオブジェクトは事前生成パケットヘッダを含む、条項6に記載の装置。
8.前記装置はさらに、
新しいアドレスハンドルの要求を受信することであって、前記要求は前記宛先情報を含む、前記受信することと、
前記新しい宛先情報を使用して、前記ネットワークアドレスマップオブジェクトを識別することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記ネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
を行うように構成される、条項6に記載の装置。
9.前記装置はさらに、
新しいアドレスハンドルの要求を受信することであって、前記要求は新しい宛先情報を含む、前記受信することと、
前記複数のトランスポートコンテキストが前記新しい宛先情報に関連するトランスポートコンテキストを含まないと判断するときに、
新しいトランスポートコンテキストを生成することと、
前記新しいトランスポートコンテキスト内に前記新しい接続の状態を格納することとを行い、
新しいネットワークアドレスマップオブジェクトを生成することであって、前記ネットワークアドレスマップオブジェクトは前記新しいトランスポートコンテキストに関連している、前記生成することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記新しいネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
を行うように構成される、条項6に記載の装置。
10.前記装置はさらに、前記複数のトランスポートコンテキストが前記新しい宛先情報に関連するトランスポートコンテキストを含まないと判断するときに、前記新しい宛先情報に関連する前記ネットワーク上の新しい宛先との新しい接続を確立するように構成される、条項9に記載の装置。
11.新しいネットワークアドレスマップオブジェクトを生成することは、前記新しい宛先情報を使用して、パケットヘッダを生成することを含み、前記生成されたパケットヘッダは前記新しいネットワークアドレスマップオブジェクトに格納される、条項9に記載の装置。
12.前記装置はさらに、前記宛先情報に関連する前記ネットワーク上の宛先との接続を確立するように構成される、条項4〜11のいずれかに記載の装置。
13.前記宛先情報はネットワークアドレスを備える、条項4〜12のいずれかに記載の装置。
14.前記宛先情報はフロー識別子を備える、条項4〜13のいずれかに記載の装置。
15.前記ネットワーク上の前記宛先は前記ネットワーク上のサーバに関連している、条項4〜14のいずれかに記載の装置。
16.前記ネットワーク上の前記宛先は1つ以上のインターネットプロトコルアドレスに関連している、条項4〜15のいずれかに記載の装置。
17.前記ネットワーク上の前記宛先はインターネットプロトコルアドレス及び通信エンドポイントの識別子に関連している、条項4〜16のいずれかに記載の装置。
18.前記メッセージはシーケンス識別子を含み、前記シーケンス識別子は前記メッセージの送信元からの他のメッセージに関する前記メッセージのシーケンスを示し、前記装置は、
前記トランスポートコンテキストを使用して、前記メッセージ及び前記メッセージのシーケンス識別子を含むパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと、
前記送信されたパケットの状態を監視することと
を行うように構成される、条項4〜17のいずれかに記載の装置。
19.前記装置はネットワークアダプタデバイスである、条項4〜18のいずれかに記載の装置。
20.前記装置はシステムオンチップ(SoC)、フィールドプログラマブルゲートアレイ(FPGA)または特定用途向け集積回路(ASIC)である、条項4〜19のいずれかに記載の装置。
21.プロセッサと、
前記1つ以上のプロセッサに連結されて前記1つ以上のプロセッサによって読み取り可能なメモリであって、前記メモリは複数のトランスポートコンテキストを格納するように構成されている、前記メモリと
を備える装置であって、前記装置は、
ネットワークと通信することと、
前記ネットワーク上でパケットを受信することであって、前記パケットは前記ネットワーク上の送信元との接続の確立を要求する、前記受信することと、
前記ネットワーク上の前記送信元に関連するトランスポートコンテキストを生成することであって、前記トランスポートコンテキストは前記ネットワーク上の前記送信元との接続の状態を示す、前記生成することと、
前記メモリに前記トランスポートコンテキストを格納することと、
前記ネットワーク上の前記送信元に応答を送信することであって、前記応答は前記接続の確立を確認する、前記送信することと
を行うように構成される、前記装置。
22.前記装置はさらに、
前記ネットワーク上で第2のパケットを受信することであって、前記第2のパケットは前記ネットワーク上の第2の送信元との第2の接続の確立を要求する、前記受信することと、
前記第2のパケットを使用して、前記トランスポートコンテキストを識別することと、
前記ネットワーク上の前記第2の送信元に第2の応答を送信することであって、前記第2の応答は前記第2の接続の確立を確認する、前記送信することと
を行うように構成される、条項21に記載の装置。
23.前記装置は、
前記パケットが他のパケットに関して受信された順序を識別することと、
前記パケットを受け入れ可能かどうかを判断することと、
前記パケットを受け入れ可能であると判断するときに、
前記パケットに含まれる宛先情報を使用して、受信キューを決定することであって、前記受信キューは前記ホストデバイス上のユーザアプリケーションに関連している、前記決定することと、
前記受信キューに前記パケットを転送することと、
前記パケットの状態を示す応答を送信することと
を行うように構成される、条項21または22に記載の装置。
24.ネットワークアダプタデバイスによって、メッセージ及び前記メッセージに関連する宛先情報を受信することと、
前記宛先情報を使用して、複数のトランスポートコンテキストから1つのトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先との接続の状態を含み、前記ネットワーク上の前記宛先は前記宛先情報に関連している、前記決定することと
を備える、方法。
25.前記メッセージ及び前記トランスポートコンテキストを使用して、パケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと
をさらに備える、条項24に記載の方法。
26.前記宛先情報はアドレスハンドルを備え、
前記アドレスハンドルを使用して、複数のアドレスマップオブジェクトから1つのネットワークアドレスマップオブジェクトを決定することであって、前記複数のアドレスマップオブジェクトは前記メモリに格納されており、前記アドレスマップオブジェクトは前記決定されたトランスポートコンテキストに関連している、前記決定すること
をさらに備える、条項24または25に記載の方法。
27.前記ネットワークアダプタデバイスによって、新しいアドレスハンドルの要求を受信することであって、前記要求は前記宛先情報を含む、前記受信することと、
前記新しい宛先情報を使用して、前記ネットワークアドレスマップオブジェクトを識別することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記ネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
をさらに備える、条項26に記載の方法。
28.前記ネットワークアダプタデバイスによって、新しいアドレスハンドルの要求を受信することであって、前記要求は新しい宛先情報を含む、前記受信することと、
前記複数のトランスポートコンテキストが前記新しい宛先情報に関連するトランスポートコンテキストを含まないと判断するときに、
新しいトランスポートコンテキストを生成することと、
前記新しい接続の状態を前記新しいトランスポートコンテキストに格納することと、
前記新しい宛先情報に関連する前記ネットワーク上の新しい宛先との新しい接続を確立することとを行い、
新しいネットワークアドレスマップオブジェクトを生成することであって、前記ネットワークアドレスマップオブジェクトは前記新しいトランスポートコンテキストに関連している、前記生成することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記新しいネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
をさらに備える、条項26に記載の方法。
29.プロセッサと、
前記プロセッサに連結されて前記プロセッサによって読み取り可能なメモリであって、前記メモリはユーザアプリケーションを格納するように構成されている、前記メモリと
を備えるホストデバイスと、
ネットワークと通信するように構成されるネットワークアダプタデバイスと
を備えるコンピューティングシステムであって、
前記ホストデバイスは前記ユーザアプリケーションを実行するように構成され、前記ユーザアプリケーションは、
前記メモリに複数のバッファを構成するように構成され、
前記ネットワークアダプタデバイスは、
前記ネットワーク上で複数のパケットを受信することであって、前記複数のパケットは前記ネットワーク上の送信元から発生し、前記複数のパケットは順不同で受信される、前記受信することと、
前記複数のパケットから1つのパケットを受信するときに、
前記送信元及び前記パケットの宛先に関連するトランスポートコンテキストを識別することと、
前記パケットに含まれるエンドポイント識別子を使用して、前記パケットが前記ユーザアプリケーションに対するものであると判断することと、
前記複数のバッファから1つのバッファに前記受信パケットを転送することとを行い、
前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、前記複数のパケットからのパケットの状態を示す応答を送信すること
を行うように構成され、
前記ユーザアプリケーションはさらに、
前記受信パケットを順序通りに配置するために、前記複数のバッファで受信した前記パケットを並び替えすることを行うように構成される、
前記コンピューティングシステム。
30.前記ネットワークアダプタデバイスはさらに、
前記複数のパケットからの各パケットに含まれる識別子を監視することと、
前記複数のパケットからの1つ以上のパケットが受信されなかったと判断することと
を行うように構成され、
前記応答は受信されなかった前記1つ以上のパケットを識別する、
条項29に記載のコンピューティングシステム。
31.前記ネットワークアダプタデバイスはさらに、
前記複数のバッファがフルであると判断することと、
前記複数のパケットから1つ以上のパケットをドロップすることと
を行うように構成される、
条項29または30に記載のコンピューティングシステム。
32.前記応答はドロップされた前記1つ以上のパケットを識別する、条項31に記載のコンピューティングシステム。
33.プロセッサと、
複数の受信キューと
を備える装置であって、前記装置は、
ホストデバイス及びネットワークと通信することと、
前記ネットワーク上でパケットを受信することであって、前記パケットは前記ネットワーク上の送信元から発生し、順不同で受信される、前記受信することと、
各受信パケットに対して、
前記送信元及び前記受信パケットの宛先に関連するトランスポートコンテキストを識別することと、
前記受信パケットが他のパケットに関して受信された順序を識別することと、
前記受信パケットを受け入れ可能かどうかを判断することと、
前記受信パケットを受け入れ可能であると判断するときに、
前記受信パケットに含まれる宛先情報を使用して、受信キューを決定することであって、前記受信キューは前記ホストデバイス上のユーザアプリケーションに関連している、前記決定することと、
前記受信キューに前記受信パケットを転送することと
を行うように構成される、前記装置。
34.前記装置はさらに、前記パケットを受け入れ可能であると判断するときに、前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、前記受信パケットのうちの1つ以上の状態を示す応答を送信するように構成される、条項33に記載の装置。
35.前記応答は1つ以上のパケットが受信されたことを示す、条項34に記載の装置。
36.前記応答は1つ以上のパケットが受信されなかったことを示す、条項34に記載の装置。
37.前記装置は、第2の受信パケットに対して、
前記第2の受信パケットを受け入れ不可能であったと判断することと、
前記第2の受信パケットをドロップすることと
を行うように構成される、条項33〜36のいずれかに記載の装置。
38.前記装置は、前記複数のバッファがフルであると判断することによって、前記第2のパケットを受け入れ不可能であると判断するように構成される、条項37に記載の装置。
39.前記装置は、前記第2の受信パケットに対応するデータが以前に受信されたと判断することによって、前記第2のパケットを受け入れ不可能であると判断するように構成される、条項37に記載の装置。
40.前記装置は、前記第2の受信パケットが無効であると判断することによって、前記第2のパケットを受け入れ不可能であると判断するように構成される、条項37に記載の装置。
41.前記装置はさらに、前記第2の受信パケットを受け入れ不可能であると判断するときに、前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、送信されることになる1つ以上のパケットを識別する応答を送信するように構成され、前記1つ以上のパケットは前記第2の受信パケットを含む、条項37に記載の装置。
42.前記識別されたトランスポートコンテキストは、前記ネットワーク上の前記装置と前記送信元との間の接続の状態を含む、条項33〜41のいずれかに記載の装置。
43.前記識別されたトランスポートコンテキストは、前記ネットワーク上の前記送信元から前記装置への前記ネットワーク上の複数の経路を提供する、条項33〜42のいずれかに記載の装置。
44.前記パケットはパケットのサブフローに分割される、条項33〜43のいずれかに記載の装置。
45.パケットの各サブフローは異なるネットワーク経路上で受信される、条項33〜44のいずれかに記載の装置。
46.前記装置はさらに、
パケットのサブフローに対して、前記パケットのサブフローからの各パケットに含まれる識別子を監視することと、
前記識別子を使用して、前記パケットのサブフローからの特定のパケットが順序通りに受信されたことを判断することと
を行うように構成され、
前記応答は順序通りに受信された前記パケットのサブフローからの1つ以上のパケットを識別し、前記パケットのサブフローからの前記1つ以上のパケットは前記特定のパケットを含む、
条項33〜44のいずれかに記載の装置。
47.前記装置はさらに、
パケットのサブフローに対して、前記パケットのサブフローからの各パケットに含まれる識別子を監視することと、
前記識別子を使用して、前記パケットのサブフローからの特定のパケットが受信されなかったことを判断することと
を行うように構成され、
前記応答は受信されなかった前記パケットのサブフローからの1つ以上のパケットを識別し、前記パケットのサブフローからの前記1つ以上のパケットは前記特定のパケットを含む、
条項33〜44のいずれかに記載の装置。
48.前記装置はネットワークアダプタデバイスである、条項33〜47のいずれかに記載の装置。
49.前記装置はシステムオンチップ(SoC)、フィールドプログラマブルゲートアレイ(FPGA)または特定用途向け集積回路(ASIC)である、条項33〜48のいずれかに記載の装置。
50.ネットワークアダプタデバイスにおいて、ネットワーク上で複数のパケットを受信することであって、前記複数のパケットは前記ネットワーク上の送信元から発生し、順不同で受信される、前記受信することと、
前記複数のパケットからパケットを受信するときに、
前記送信元及び前記受信パケットの宛先に関連するトランスポートコンテキストを識別することと、
前記受信パケットが前記複数のパケットからの他のパケットに関して受信された順序を識別することと、
前記受信パケットを受け入れ可能かどうかを判断することと、
前記受信パケットを受け入れ可能であると判断するときに、
前記受信パケットに含まれる宛先情報を使用して、受信キューを決定することであって、前記受信キューはユーザアプリケーションに関連している、前記決定することと、
前記受信キューに前記受信パケットを転送することと、
前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、前記複数のパケットからの1つ以上のパケットの状態を示す応答を送信することと
を備える、前記方法。
51.前記応答は前記複数のパケットからの前記1つ以上のパケットが受信されたことを示す、条項50に記載の方法。
52.前記応答は前記複数のパケットからの前記1つ以上のパケットが受信されなかったことを示す、条項50または51に記載の方法。
53.第2の受信パケットに対して、
前記第2の受信パケットを受け入れ不可能であったと判断することと、
前記第2の受信パケットをドロップすることと
をさらに備え、
前記応答は送信されることになる1つ以上のパケットを識別し、前記1つ以上のパケットは前記第2の受信パケットを含む、
条項50〜52のいずれかに記載の方法。
54.前記識別されたトランスポートコンテキストは、前記ネットワーク上の前記ネットワークアダプタデバイスと前記送信元との間の接続の状態を含む、条項50〜53のいずれかに記載の方法。
55.プロセッサと、
前記プロセッサに連結されて前記プロセッサによって読み取り可能なメモリであって、前記メモリはユーザアプリケーションを格納するように構成されている、前記メモリと
を備えるホストデバイスと、
ネットワークと通信するように構成されるネットワークアダプタデバイスとを備えるコンピューティングシステムであって、
前記ホストデバイスは、
前記ユーザアプリケーションを実行するように構成され、前記ユーザアプリケーションは、メッセージを前記ネットワークアダプタデバイスに提供するように構成され、各メッセージはアドレスハンドルを含み、
前記ネットワークアダプタデバイスは、
前記ユーザアプリケーションからの各メッセージに対して、
前記アドレスハンドルを使用して、前記メッセージに対するトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先に関連しており、前記トランスポートコンテキストは宛先アドレスを提供する、前記決定することと、
前記メッセージに対するパケットを生成することであって、前記パケットは前記宛先アドレスを含む、前記生成することと、
前記ネットワーク上で前記パケットを送信することと、
前記ネットワーク上で応答を受信することであって、各応答は前記メッセージに対して送信される1つ以上のパケットの状態を示す、前記受信することと、
前記1つ以上のパケットの前記状態を前記ユーザアプリケーションに報告することと
を行うように構成される、
前記コンピューティングシステム。
56.応答は1つ以上のパケットの受信が成功したことを示す、条項55に記載のコンピューティングシステム。
57.応答は1つ以上のパケットが受信されなかったことを示し、前記ネットワークアダプタデバイスはさらに、
受信されないと示された前記1つ以上のパケットを再送することを行うように構成される、条項55または56に記載のコンピューティングシステム。
58.応答は1つ以上のパケットが前記宛先でドロップされたことを示し、前記ネットワークアダプタデバイスはさらに、
前記応答を前記ユーザアプリケーションに報告すること
を行うように構成される、条項55〜57のいずれかに記載のコンピューティングシステム。
59.プロセッサと、
複数の送信キューと
を備える装置であって、
前記装置はホストデバイス及びネットワークと通信するように構成され、前記装置はさらに、
前記複数の送信キューで前記ホストデバイスからメッセージを受信することであって、各メッセージはそれぞれのシーケンス識別子を含み、前記シーケンス識別子は前記メッセージの送信元からの他のメッセージに関する各それぞれのメッセージのシーケンスを示し、前記メッセージのそれぞれは同じ宛先情報に関連している、前記受信することと、
処理のために前記複数の送信キューから1つの送信キューを決定することと、
前記決定された送信キュー内の各メッセージに対して、
前記宛先情報及び前記決定された送信キューの識別を使用して、前記ネットワーク上の宛先に関連するトランスポートコンテキストを決定することと、
前記トランスポートコンテキストを使用して、前記メッセージ及び前記メッセージのシーケンス識別子を含むパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと、
前記送信されたパケットの状態を監視することと
を行うように構成される、前記装置。
60.前記装置はさらに、
前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの1つ以上が前記ネットワーク上の前記宛先で受信されたことを示す、前記受信することを行うように構成される、条項59に記載の装置。
61.前記装置はさらに、
前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの1つ以上が前記ネットワーク上の前記宛先で受信されなかったことを示す、前記受信することと、
受信されないと示された前記1つ以上のパケットを再送することと
を行うように構成される、条項60に記載の装置。
62.前記装置はさらに、
前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの1つ以上を再送する要求を含む、前記受信することと、
前記応答を前記ホストデバイスに報告することと
を行うように構成される、条項60に記載の装置。
63.前記トランスポートコンテキストは前記ネットワーク上で前記ネットワーク上の前記宛先への複数の経路を提供する、条項59〜62のいずれかに記載の装置。
64.前記装置はさらに、
前記メッセージに対する前記パケットをパケットのサブフローに分割すること
を行うように構成される、条項59〜63のいずれかに記載の装置。
65.前記装置はさらに、
異なるネットワーク経路上でパケットの各サブフローを送信すること
を行うように構成される、条項64に記載の装置。
66.前記装置はさらに、
パケットのサブフローからの1つ以上のパケットの受信が成功したことを示す応答を受信すること
を行うように構成される、条項64に記載の装置。
67.前記装置はさらに、
パケットのサブフローからの1つ以上のパケットが前記ネットワーク上の前記宛先で受信されなかったことを示す応答を前記ネットワーク上で受信することと、
受信されないと示された前記1つ以上のパケットを再送することと
を行うように構成される、条項64に記載の装置。
68.前記装置はさらに、各パケットのサブフローに対して、
前記パケットのサブフローからパケットを送信するときに、タイマを開始することと、
前記タイマの期限が切れたときに、前記パケットのサブフローから1つ以上のパケットを再送することと
を行うように構成される、条項64に記載の装置。
69.前記装置はネットワークアダプタデバイスである、条項59〜68のいずれかに記載の装置。
70.前記装置はシステムオンチップ(SoC)、フィールドプログラマブルゲートアレイ(FPGA)または特定用途向け集積回路(ASIC)である、条項59〜69のいずれかに記載の装置。
71.ネットワークアダプタデバイスによって、複数の送信キューでホストデバイスからメッセージを受信することであって、各メッセージはシーケンス識別子を含み、前記シーケンス識別子は前記メッセージの送信元からの他のメッセージに関する各それぞれのメッセージのシーケンスを示し、前記メッセージのそれぞれは同じ宛先情報に関連している、前記受信することと、
処理のために前記複数の送信キューから1つの送信キューを決定することと、
前記決定された送信キュー内の各メッセージに対して、
前記宛先情報及び前記決定された送信キューの識別を使用して、トランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先に関連している、前記決定することと、
前記トランスポートコンテキストを使用して、前記メッセージ及び前記メッセージのシーケンス識別子を含むパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと、
前記送信されたパケットの状態を監視することと
を備える、方法。
72.前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの1つ以上が前記ネットワーク上の前記宛先で受信されたことを示す、前記受信すること
をさらに備える、条項71に記載の方法。
73.前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの1つ以上が前記ネットワーク上の前記宛先で受信されなかったことを示す、前記受信することと、
受信されないと示された前記1つ以上のパケットを再送することと
をさらに備える、条項71または72に記載の方法。
74.前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの1つ以上を再送する要求を含む、前記受信することと、
前記応答を前記ホストデバイスに報告することと
をさらに備える、条項71〜73のいずれかに記載の方法。
75.パケットのサブフローに対して、
前記パケットを送信するときに、タイマを開始することと、
前記タイマの期限が切れたときに、前記パケットのサブフローから1つ以上のパケットを再送することと
をさらに備える、条項71〜74のいずれかに記載の方法。
様々な実施形態は多様な動作環境でさらに実装することができ、動作環境は、いくつかの場合、いくつかのアプリケーションのいずれかを操作するために使用できる1つ以上のユーザコンピュータ、コンピューティングデバイスまたは処理デバイスを含むことがある。ユーザデバイスまたはクライアントデバイスは、標準オペレーティングシステムを実行するデスクトップコンピュータまたはラップトップコンピュータなどのいくつかの汎用パーソナルコンピュータのいずれか、ならびにモバイルソフトウェアを実行し、かついくつかのネットワーキングプロトコル及びメッセージプロトコルをサポートできる、セルラデバイス、無線デバイス及びハンドヘルドデバイスを含むことがある。このようなシステムは、様々な市販のオペレーティングシステムならびに開発及びデータベース管理などの目的のための他の既知のアプリケーションを実行するいくつかのワークステーションを含むこともある。これらのデバイスはさらに、ダミー端末、シンクライアント、ゲーミングシステム及びネットワークを介して通信できる他のデバイスなどの他の電子デバイスを含むことがある。
ほとんどの実施形態は、伝送制御プロトコル/インターネットプロトコル(「TCP/IP」)、オープンシステムインターコネクション(「OSI」)、ファイルトランスポートプロトコル(「FTP」)、ユニバーサルプラグアンドプレイ(「UpnP」)、ネットワークファイルシステム(「NFS」)、共通インターネットファイルシステム(「CIFS」)及びAppleTalkなどの様々な市販のプロトコルのいずれかを使用し、通信を支援するための当業者によく知られているだろう少なくとも1つのネットワークを活用する。ネットワークは、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク及びその任意の組み合わせであることがある。
ウェブサーバを利用する実施形態では、ウェブサーバは、ハイパーテキストトランスポートプロトコル(「HTTP」)サーバ、FTPサーバ、共通ゲートウェイインタフェース(「CGI」)サーバ、データサーバ、Javaサーバ及びビジネスアプリケーションサーバを含む様々なサーバまたは中間層アプリケーションのいずれかを実行できる。サーバ(複数可)はさらに、Java(登録商標)、C、C#もしくはC++などの任意のプログラミング言語、またはPerl、PythonもしくはTCLなどの任意のスクリプト言語ならびにその組み合わせで記述された1つ以上のスクリプトまたはプログラムとして実装されてよい1つ以上のウェブアプリケーションを実行することなどによって、ユーザデバイスからの要求に応えてプログラムまたはスクリプトを実行することができ得る。サーバ(複数可)はさらに、Oracle(登録商標)、Microsoft(登録商標)、Sybase(登録商標)及びIBM(登録商標)から市販されているものを含むがこれらに制限されないデータベースサーバを含んでよい。
環境は、上述の通り、様々なデータストアならびに他のメモリ及び記憶媒体を含むことがある。これらは、コンピュータの1つ以上にローカルな(及び/またはそこに常駐する)あるいはネットワーク全体でのコンピュータのいずれかまたは全てから遠く離れた記憶媒体上などの様々な場所に常駐することがある。実施形態の特定のセットでは、情報は、当業者によく知られているストレージエリアネットワーク(「SAN」)に常駐してよい。同様に、コンピュータ、サーバまたは他のネットワークデバイスによる機能を実行するためのあらゆる必要なファイルは、必要に応じてローカルに及び/またはリモートに記憶されてよい。システムがコンピュータ化されたデバイスを含む場合、このようなそれぞれのデバイスはバスを介して電気的に結合されてよいハードウェア要素を含むことがあり、要素は、例えば、少なくとも1つの中央演算処理装置(「CPU」)、少なくとも1つの入力デバイス(例えば、マウス、キーボード、コントローラ、タッチスクリーンまたはキーパッド)及び少なくとも1つの出力デバイス(例えば、表示デバイス、プリンタまたはスピーカ)を含むことがある。また、このようなシステムは、例えば、ディスクドライブ、光学式ストレージデバイスなどの1つ以上のストレージデバイス及びランダムアクセスメモリ(「RAM」)または読み出し専用メモリ(「ROM」)などのソリッドステートストレージデバイス、ならびに取り外し可能な媒体デバイス、メモリカード、フラッシュカードを含んでよい。
このようなデバイスはさらに、上述のようにコンピュータ可読記憶媒体リーダ、通信デバイス(例えば、モデム、ネットワークカード(無線または有線)、赤外線通信デバイス等)及び作業メモリを含むことがある。コンピュータ可読記憶媒体リーダは、リモートストレージデバイス、ローカルストレージデバイス、固定ストレージデバイス及び/または取り外し可能なストレージデバイスを表すコンピュータ可読記憶媒体、ならびにコンピュータ可読情報を一時的に及び/またはより恒久的に含む、記憶する、送信する及び取り出すための記憶媒体と接続できる、またはそれらを受信するように構成できる。システム及び様々なデバイスはさらに、通常、オペレーティングシステム及びクライアントアプリケーションもしくはウェブブラウザなどのアプリケーションプログラムを含む、いくつかのソフトウェアアプリケーション、モジュール、サービスまたは少なくとも1つの作業用メモリデバイス内に位置する他の要素を含む。代替の実施形態は上述の多数の変形形態を有してよいことを理解されたい。例えば、カスタマイズされたハードウェアが使用される可能性もある、及び/または特定の要素がハードウェア、ソフトウェア(アプレットなどのポータブルソフトウェアを含む)または両方で実装される可能性がある。さらに、ネットワーク入力/出力デバイス等の、他のコンピューティングデバイスへの接続が利用されてよい。
コードまたはコードの一部を包含するための記憶媒体コンピュータ可読媒体は、RAM、ROM、電気的消去可能プログラマブル読み出し専用メモリ(「EEPROM」)、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読み出し専用メモリ(「CD−ROM])、デジタルバーサタイルディスク(DVD)もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスできる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータ等の情報の記憶及び/または送信のために任意の方法または技術で実装される揮発性及び不揮発性の媒体、取り外し可能及び取り外し不可能な媒体等であるが、これに限定されるものではない記憶媒体及び通信媒体を含む当該分野において既知の、または使用される任意の適切な媒体を含むことがある。本開示及び本明細書に提供される教示に基づいて、当業者は様々な実施形態を実装するための他の方法及び/または手法を理解するであろう。
したがって、明細書及び図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかしながら、特許請求の範囲に記載される本開示のより広範の趣旨及び範囲から逸脱することなく、様々な修正形態及び変更が本明細書に加えられ得ることは明らかである。
他の変形形態は、本開示の趣旨の範囲内である。ゆえに、開示された技法は様々な修正形態及び代替構成の影響を受けるが、その特定の例示の実施形態は図面に示され、上記に詳細に説明されている。しかしながら、本開示を開示された特定の1つ以上の形態に限定する意図はなく、逆に意図は、添付の特許請求の範囲によって定義される本開示の趣旨及び範囲に入る全ての修正形態、代替構成及び均等物を包含することであることを理解されたい。
開示される実施形態を説明する文脈における(特に以下の特許請求の範囲の文脈における)用語「a」及び「an」及び「the」ならびに同様の指示語の使用は、本明細書において別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、単数及び複数の両方を網羅すると解釈されるべきである。用語「comprising(備える)」、「having(有する)」及び「containing(含む)」は、特に断りのない限り、オープンエンド用語(すなわち「を含むが、これらに限定されるものではない」を意味する)として解釈されるべきである。用語「connected(接続された)」は、たとえ介在するものがあっても部分的にまたは完全に、中に含まれる、取り付けられるまたは互いに結合されるとして解釈されるべきである。本明細書での値の範囲の列挙は、本明細書に別段の指示がない限り、単に、範囲内に入るそれぞれの個別の値に個別に言及する短縮方法として機能することが意図され、各個別の値は、それが個別に本明細書に記載されているかのように本明細書に組み込まれる。本明細書に記載される全ての方法は、本明細書で別段の指示がない限り、または別様には文脈に明らかに矛盾するものでない限り、任意の適切な順序で実行できる。本明細書に提供される例の一部及び全ての例または例示的な言語(例えば、「〜など」)の使用は、単に本開示の実施形態を良好に例示することを意図しており、別段の主張がない限り、本開示の範囲を限定するものではない。本明細書のいかなる言葉も、本開示の実施にとって必須として任意の請求されていない要素を示すものと解釈されるべきではない。
特に断りのない限り、句「X、YまたはZのうちの少なくとも1つ」などの選言的な言葉は、項目、用語等がX、YもしくはZまたはそのいずれかの組み合わせ(例えば、X、Y及び/またはZ)であってよいことを示すために一般的に用いられるとして文脈の中で理解されることが意図される。ゆえに、このような選言的言語は、特定の実施形態がXの少なくとも1つ、Yの少なくとも1つまたはZの少なくとも1つがそれぞれ存在することを必要とすることを暗示することを一般的に意図しておらず、意味するべきではない。
本開示を実施するために発明者に知られている最良の形態を含む本開示の好ましい実施形態が本明細書に説明される。これらの好ましい実施形態の変形形態は、前述の説明を読むと当業者に明らかになり得る。本発明者らは、当業者がこのような変形形態を必要に応じて利用することを期待し、本発明者らは本開示が本明細書に具体的に記載されたものとは別の方法で実施されることを意図する。したがって、本開示は、適用法によって許容されるように、本明細書に添付された特許請求の範囲に記載された主題の全ての修正形態及び均等物を含む。さらに、本明細書に別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、上記要素の全ての考え得る変形形態での上記要素の任意の組み合わせが本開示に包含される。