JP2019092218A - ネットワーキング技術 - Google Patents

ネットワーキング技術 Download PDF

Info

Publication number
JP2019092218A
JP2019092218A JP2019032253A JP2019032253A JP2019092218A JP 2019092218 A JP2019092218 A JP 2019092218A JP 2019032253 A JP2019032253 A JP 2019032253A JP 2019032253 A JP2019032253 A JP 2019032253A JP 2019092218 A JP2019092218 A JP 2019092218A
Authority
JP
Japan
Prior art keywords
packet
network
packets
destination
transport
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019032253A
Other languages
English (en)
Other versions
JP6564960B2 (ja
Inventor
リア シャレブ
Leah Shalev
リア シャレブ
ブライアン ウィリアム バレット
William Barrett Brian
ブライアン ウィリアム バレット
ナフェア バシャラ
Bshara Nafea
ナフェア バシャラ
ジョージ マシュルスキー
Machulsky Georgy
ジョージ マシュルスキー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amazon Technologies Inc
Original Assignee
Amazon Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/983,436 external-priority patent/US9985904B2/en
Priority claimed from US14/983,434 external-priority patent/US9985903B2/en
Priority claimed from US14/983,431 external-priority patent/US10148570B2/en
Application filed by Amazon Technologies Inc filed Critical Amazon Technologies Inc
Publication of JP2019092218A publication Critical patent/JP2019092218A/ja
Application granted granted Critical
Publication of JP6564960B2 publication Critical patent/JP6564960B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/621—Individual queue per connection or flow, e.g. per VC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9057—Arrangements for supporting packet reassembly or resequencing

Abstract

【課題】高出力なコンピューティングシステムとして機能する比較的低価格のコンピュータのネットワークによって、高性能コンピューティングを提供する。【解決手段】装置は、ネットワーク及びホストデバイスと通信する。装置は、メッセージ及びメッセージに関連する宛先情報をホストデバイスから受信する。装置はさらに、宛先情報を使用して、複数のトランスポートコンテキストから１つのトランスポートコンテキストを決定する。トランスポートコンテキストは、ネットワーク上の宛先との接続の状態を含む。ネットワーク上の宛先は宛先情報と関連する。【選択図】図１１

Description

コンピュータクラスタ、つまり、１つの高出力なコンピューティングシステムとして機能する比較的低価格のコンピュータのネットワークによって、高性能コンピューティングが提供され得る。高性能コンピューティングは、通常、クラスタ内のネットワーク接続システムの全体において高帯域幅及び低レイテンシを必要とする。パケットを送信するシステムとパケットを受信するシステムの両方においてプロセッサの関与を削減することによって、トランザクションのレイテンシは削減され得る。パケット送信においてプロセッサの関与を削減するサーバメッセージングプロトコルは、リモートダイレクトメモリアクセス（ＲＤＭＡ）プロトコル、またはより一般的には、カーネルバイパスフレームワークを伴うプロトコルと呼ばれ得る。カーネルバイパスフレームワークを伴うプロトコルは、通常、送信及び受信システム間で通信するためのトランスポートスタックを使用する。トランスポートスタックは、ネットワークから出ていく送信パケットと、ネットワークに入ってくる受信パケットのキューペアを含み得る。トランスポートスタックはさらに、送信システムと受信システムとの間の接続の管理ならびにパケットの送信及び受信の管理を行う１つ以上のトランスポートサービスを含み得る。
本開示に従った多様な実施形態を、図面を参照して説明する。
コンピューティングリソースのクラスタの一例を例示する。 カーネルバイパスフレームワークを実装するために使用され得る通信スタックの一例を例示する。 トランスポートサービスタイプの例を例示する。 緩和された信頼可能なデータグラムトランスポートを供給するように構成され得るシステムの一例を例示する。 ユーザアプリケーションがメッセージを別のアプリケーションに送信するために後続的に使用可能なアドレスハンドルをユーザアプリケーションが取得し得るプロセスの一例を例示する。 ユーザアプリケーションがメッセージを別のアプリケーションに送信するために後続的に使用可能なアドレスハンドルをユーザアプリケーションが取得し得るプロセスの一例を例示する。 ユーザアプリケーションがメッセージを送信するためにアドレスハンドルを使用し得るプロセスの一例を例示する。 ユーザアプリケーションがメッセージを送信するためにアドレスハンドルを使用し得るプロセスの一例を例示する。 緩和された信頼可能なデータグラムトランスポートサービスを含むシステムに対して実装され得る通信スタックの一例を例示する。 緩和された信頼可能なデータグラムトランスポートサービスを含むシステムに対して実装され得る通信スタックの一例を例示する。 利用可能な経路を通じたさらなる活用を達成するために、緩和された信頼可能なデータグラムトランスポートがネットワークを通る複数の経路を管理し得る方法の一例を例示する。 緩和された信頼可能なデータグラムトランスポートが信頼可能なパケット配信を保証し得る方法の一例を例示する。 緩和された信頼可能なデータグラムトランスポートが信頼可能なパケット配信を保証し得る方法の一例を例示する。 フローレットに分割された単一のパケットフロー及びパケットが受信ユーザアプリケーションによって受信される順序の一例を例示する。 フローレットに分割された単一のパケットフロー及びパケットが受信ユーザアプリケーションによって受信される順序の一例を例示する。 ネットワークを通じてメッセージを送信しようとするユーザアプリケーションに対してトランスポートコンテキストを決定し得るプロセスの一例を例示する。 アドレスハンドルを取得するためのプロセスの一例を例示する。 ネットワーク上でパケットを送信し、各パケットが確実に配信されるように各パケットの状態を監視するプロセスの一例を例示する。 ネットワーク上でパケットを受信し、パケットが受信されたことを示すために各パケットに対する応答を生成するプロセスの一例を例示する。 本明細書に記載するシステム及び方法を実装するために使用され得るネットワークアダプタデバイスの一例を例示する。 いくつかの実施形態に従う、１つ以上のネットワークを介して接続される１つ以上のサービスプロバイダコンピュータ及び／またはユーザデバイスを含む、本明細書に記載する機能及びシステムのアーキテクチャ例を例示する。 いくつかの実施形態に従う、態様を実装するためのコンピューティングシステムの環境例の態様を例示する。
以下の説明では多様な実施形態が説明される。説明の目的のため、特定の構成及び詳細が実施形態の完全な理解を提供するために記載される。しかしながら、本実施形態が特定の詳細を伴うことなく実施され得ることも当業者に明らかとなるだろう。さらに、周知の機能は、説明されている実施形態を不明瞭にしないために省略または簡略化され得る。
高性能コンピューティングは、計算クラスタ、つまり、１つの高出力コンピューティングシステムとして機能する比較的低価格のコンピュータのネットワークによって提供され得る。高性能を提供するために、クラスタ内のネットワーク接続システムは高帯域幅をサポートする必要があり、コンピュータクラスタ内のシステム間で送信されるメッセージは可能な限り最小のレイテンシを有する必要がある。伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）などの一般的なネットワーキングプロトコルは、帯域幅を最大化してレイテンシを最小化するのではなく、一般的に、多数の異なるタイプのネットワークを通じた相互運用を目指している。ゆえに、高性能計算クラスタは、一般的に、カーネルバイパスフレームワークを提供するサーバメッセージプロトコルを使用する。オペレーティングシステムのカーネル動作を迂回すると、ネットワーク帯域幅が大幅に改善され、送信レイテンシが削減され得る。カーネルバイパスフレームワークを提供するネットワークプロトコルは、一般的に、リモートダイレクトメモリアクセス（ＲＤＭＡ）プロトコルと呼ばれるが、ほとんどの場合、ＲＤＭＡはこれらのプロトコルによって提供される唯一の機能である。
カーネルバイパスフレームワークを提供するネットワークプロトコルは、一般的に、ネットワークパケットを送信及び受信するためにトランスポートスタックを使用する。トランスポートスタックは、通常、１つ以上のトランスポートサービスを提供する。これらのトランスポートサービスは、一般的に、接続型またはコネクションレス型及び信頼可能または信頼不可能に分類される。接続型のトランスポートサービスタイプは、一般的に、コンピューティングクラスタの拡張性に悪影響を及ぼす。接続型のトランスポートサービスの場合、クラスタに接続されるシステムの数が増加すると、接続数が大幅に増加し得る。信頼可能な非接続型のトランスポートサービスタイプは拡張性が高くなり得るが、一般的には、ネットワーク内でドロップされているパケットに対して耐久性が低い。ゆえに、高性能コンピューティングシステムは、高いパケットドロップ率を有し得るネットワーク上で拡張性と信頼性との両方を備えたトランスポートサービスタイプによって改善され得る。
信頼性、つまり、パケットの保証された配信は、ネットワークアダプタデバイスで最適に処理され得る。ネットワークアダプタは、パケットがドロップされたことを迅速に判断することができ得、それらのパケットを再送する要求を同様に迅速に生成することができる。ホストデバイス上で動作中のソフトウェアが信頼性に対応することは、レイテンシに悪影響を及ぼし得る。信頼可能なパケット配信を確実にするソフトウェアでは、トランスポートスタックまで進み、オペレーティングシステムのカーネルまたはユーザアプリケーションにパケットを配信する必要があり、オペレーティングシステムがビジー状態であるなどの様々な理由によりパケットは途中で遅延し得る。ゆえに、パケットの信頼性動作は、トランスポートスタックを通過することによって生じる潜在的な遅延を回避することにより、より効率的に対応され得る。
しかしながら、パケットドロップ及びパケット再送により、パケットが宛先システムに順不同で到着する可能性がある。パケットドロップが発生する可能性のあるシステムでは、順不同で到着するパケットの並び替えは、通常、例えば、ネットワークアダプタデバイスでパケット配信を保証することで共に処理されてきた。しかし、パケットの並び替えに計算が集中する可能性があり、ネットワークアダプタデバイスは、通常、低電力で安価なプロセッサを有する。一方、ホストデバイスは、通常、高性能プロセッサを有し、パケットの並び替えを容易に管理することができる。しかし、既に述べたように、ホストデバイスソフトウェアがパケットの並び替えと信頼可能なパケット配信の両方に対応することは非効率的な場合がある。
本明細書に開示するシステム及び方法は信頼可能なパケット配信及びパケット並び替えを提供し、信頼性はネットワークアダプタデバイスで対応され、パケット並び替えはホストデバイス上のソフトウェアによって対応される。緩和された信頼可能なデータグラムトランスポートサービスがさらに提供される。緩和された信頼可能なデータグラムトランスポートは、パケットを時々ドロップし得るネットワークを通るパケット配信を保証するメカニズムを提供する。緩和された信頼可能なデータグラムトランスポートを使用するように構成されたネットワークアダプタデバイスは、パケットのバッファリングを回避することがあり、代わりにパケットをホストデバイスに可能な限り迅速に配信する。ホストデバイスは、その後、必要に応じてパケットを並び替え得る。本明細書に記載するこれらのシステム及び方法によって、クラスタを通じた高帯域幅及び低レイテンシ転送を提供することで、低価格のコンピューティングクラスタ上での高性能コンピューティングが可能になり得る。
コンピューティングリソースをクラスタ化することは、高い性能及び拡張性を低価格で提供し得る。図１は、コンピューティングリソースのクラスタ１００の一例を例示する。クラスタは、スイッチに接続されたコンピューティングリソースのグループであり、並列的に動作するように構成される。多数の実装では、様々なコンピューティングリソースは単一の論理コンピューティングリソースを形成する。図１に例示するクラスタ１００の例は、複数のノード１０２ａ〜ｈ及びスイッチ１０４ａ〜ｃを含む。いくつかの実装では、クラスタ１００はルータ１０６をさらに含み得る。
図１に例示するノード１０２ａ〜ｈは、様々なコンピューティングリソースを表し得る。例えば、１つ以上のノード１０２ａ〜ｈは、サーバコンピュータなどのコンピュータであり得る。クラスタアプリケーションで使用するコンピュータは、１つ以上のプロセッサを含み得、これらのプロセッサは、１つ以上の処理コアを含み得る。これらのコンピュータはさらに、メモリ及び周辺装置を含んでよい。いくつかの実装では、これらのコンピュータは、クラスタ１００内のスイッチ１０４ａ〜ｃに接続するためにアダプタデバイスを使用し得る。コンピューティングリソースの他の例として、ストレージデバイス（例えば、ハードドライブ）、ストレージサブシステム（例えば、ストレージデバイスのアレイ）、入出力（Ｉ／Ｏ）モジュール及びクラスタ１００への管理アクセス用コンソールが含まれる。
スイッチ１０４ａ〜ｃは、様々なノード１０２ａ〜ｈ間の接続性を提供し得る。各ノード１０２ａ〜ｈは、スイッチ１０４ａ〜ｃとの接続を通じてクラスタ１００に接続され得る。いくつかの場合、ノード１０２ａ〜ｈは、２つ以上のスイッチ１０４ａ〜ｃに接続され得る。スイッチはさらに、他のスイッチに接続され得る。ほとんどの場合、スイッチ１０４ａ〜ｃ上の任意のポートは、ノード１０２ａ〜ｈまたは別のスイッチのいずれかに接続するために使用され得る。ほとんどの実装では、クラスタ１００のサイズは、より多くのスイッチ及びノードに接続することによって、迅速かつ容易に拡張することができる。
スイッチ１０４ａ〜ｃのネットワークは、任意のノード１０２ａ〜ｈから任意の別のノード１０２ａ〜ｈへの複数の経路を提供し得る。スイッチ１０４ａ〜ｃは別のスイッチ１０４ａ〜ｃとの複数の接続を有し得、スイッチ１０４ａ〜ｃ間の追加の経路を提供する。いくつかの場合、ノード１０２ａ〜ｈは２つ以上のスイッチ１０４ａ〜ｃに接続され得、さらにより多くの経路を作成する。１つのノード１０２ａ〜ｈからのパケットは、同時に複数の経路を使用して、別のノード１０２ａ〜ｈに到達し得る。代替的または追加的には、１つのノード１０２ａ〜ｈから別のノード１０２ａ〜ｈへのパケットは、１つの経路のみに従い得る。いくつかの場合、各スイッチ１０４ａ〜ｃにおいてパケットがどの経路に従うかについての決定が行われ得る。他の場合には、パケットの経路は、通常は送信元ノードにおいて、事前に決定され得る。１つのノード１０２ａ〜ｈから別のノード１０２ａ〜ｈへのパケットの流れは、パケットフローまたは単に「フロー」と呼ばれ得る。いくつかの場合、フロー内のパケットは、例えば、パケットが共に１つのメッセージを形成する場合などのように、関連している。
いくつかの実装では、スイッチ１０４ａ〜ｃの１つ以上は、負荷バランシング機能性を含み得る。これらの実装では、スイッチ１０４ａ〜ｃは、ネットワークトラフィックの効率的な配信を試みるように構成され得る。その目的は、通常、ノードとスイッチとの間のリンクが混雑しないようにし、パケットトラフィックが可能な限り迅速にクラスタ１００を通過することを確実にすることである。しかしながら、多くの場合、スイッチ１０４ａ〜ｃは、それ自体のトラフィック負荷のみを認識しており、他のスイッチ１０４ａ〜ｃでの負荷に対する認識を欠いている。
いくつかの実装では、クラスタ１００はルータ１０６に接続され得る。ルータ１０６は、他のクラスタもしくはサブネットワーク（サブネット）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）またはインターネットなどの他のネットワーク１０８への接続を提供し得る。
相互接続されたスイッチ１０４ａ〜ｃ（及び存在する場合にはルータ１０６）は、スイッチファブリック、ファブリックまたはより単純に「ネットワーク」と呼ばれ得る。本明細書では、「ファブリック」及び「ネットワーク」という用語は区別することなく使用され得る。
例示のクラスタ１００などのコンピューティングクラスタは、より高いコンピューティング出力及びより高い信頼性を提供し得る。個々のコンピューティングリソースは、１台のコンピュータが単独では解決でき得ない大きな問題を解決するために協働することがあるか、または非常に時間をかけて単独で解決することがある。いくつかの場合、コンピューティングクラスタは、スーパーコンピュータと同様の性能を、より低価格かつより少ない複雑性で提供し得る。コンピューティングクラスタによって使用されるスイッチドファブリックアーキテクチャは、フォールトトレラントで拡張性があるという利点をさらに有し得る。スイッチドファブリックアーキテクチャでは、通常、全てのリンクが、リンクの各端部に連結された１つのデバイスを有する。ゆえに、各リンクは、最大でも２つのデバイスの動作のみに依存する。スイッチドファブリックはさらに、より多くのスイッチを追加することによって容易に拡張することができてよく、これにより、より多くのノードを連結するより多くのポートを提供する。いくつかの場合、より多くのスイッチを追加するとクラスタの総帯域幅が増加し得る。ノード間の複数の経路はさらに、高い総帯域幅を保持し、リンク障害が発生した場合には冗長接続を提供し得る。
コンピューティングクラスタは、様々な用途に使用され得る。例えば、コンピューティングクラスタは高性能コンピューティングに使用され得る。高性能コンピューティングは、並列処理を使用して計算集約型アプリケーションを実行することを伴う。科学的研究、技術者及び学術機関は、例えば、自動車事故シミュレーション、気象モデリング、原子シミュレーション及びその他など、複雑なモデリングまたはシミュレーションに高性能コンピューティングを使用し得る。コンピューティングクラスタの他の使用例としては、機械学習、金融応用、分散ストレージ及びデータベースが含まれる。機械学習は、膨大な量のデータを検証し、データから学習して予測を行うことができるアルゴリズムを実行することを伴う。高頻度な取引などの金融応用も大量のデータを検証することがあり、一般的に、データの変化に対して迅速に（例えば、人間よりもはるかに速く）反応することに依存する。分散ストレージは、非常に大量のデータを複数の場所からアクセスできるようにする。ストレージエリアネットワークは分散ストレージの１つの形態である。データベースはさらに、大量のデータを格納して、データベース内に格納されている特定の情報を発見するための非常に迅速な方法を提供する必要がある。
コンピューティングリソースをクラスタ化することによる最大の利益を得るために、ノード間の通信に使用されるプロトコルは、高帯域幅及び低レイテンシを提供する必要がある。高帯域幅とは、大量のトラフィックがクラスタを通過可能である必要があることを意味し、低レイテンシとは、トラフィックが送信元から宛先に可能な限り迅速に移動可能である必要があることを意味する。いくつかの動作がレイテンシに大きく寄与し得る。これには、オペレーティングシステム内でネットワークプロトコルコードを実行することによって生じるオーバーヘッド、カーネルモード内外での移動及びデータ送信に必要なコンテキストスイッチ及び／またはネットワークアダプタでのユーザレベルのバッファとメモリと間のデータの過剰コピーが含まれる。例えば、通常のネットワークプロトコルスタックは、混雑することがなく遅延がほぼゼロのネットワークを仮定すると、約１００マイクロ秒の往復レイテンシを引き起こし得る。しかしながら、この遅延には、スケジューリング遅延に起因する数ミリ秒の長さのスパイク、アプリケーションがネットワークスタックの問題を回避するように設計されていない場合の数十ミリ秒の長さのスパイク及び／または混雑したリンクでパケットがドロップする場合の数秒の長さのスパイクが混在し得る。コンピューティングクラスタは、高帯域幅のハードウェアで設計されることがあり、高帯域幅のハードウェアは、通常、プロセッサ及びメモリのコピーオーバーヘッドにさらに影響を受けやすい。
（ＴＣＰ／ＩＰ）などのネットワークプロトコルは、多くの異なるタイプのネットワーク全体の性能の高さ及び／または費用効果の高さを重視する傾向にある。その結果、ＴＣＰ／ＩＰなどのプロトコルは、高レイテンシになる傾向にあり、複雑になる傾向にある。ＴＣＰなどのネットワークプロトコルは、様々なタイプのネットワーク上で汎用通信に適している場合があるが、高帯域幅かつ低レイテンシである環境では、より特化したプロトコルが有益であり得る。
コンピューティングクラスタ内のノード間で高帯域幅かつ低レイテンシのリンクを提供するために、仮想インタフェース（ＶＩ）アーキテクチャ（ＶＩＡ）サーバメッセージングプロトコルが開発された。ＶＩＡに類似するプロトコルの例には、ＩｎｆｉｎｉＢａｎｄ、インターネットワイドエリアＲＤＭＡプロトコル（ｉＷＡＲＰ）及びＲＤＭＡオーバコンバージドイーサネット（ＲｏＣＥ）が含まれる。これらのプロトコルのそれぞれは、ＲＤＭＡと呼ばれることが多い、カーネルバイパスフレームワークを含み、カーネルバイパスフレームワークについては以下でさらに詳細に説明する。ｉＷＡＲＰは、ＴＣＰ／ＩＰプロトコル上でカーネルバイパスフレームワークを提供する。ＲｏＣＥは、イーサネット型ネットワーク上でカーネルバイパスフレームワークを提供する。ＩｎｆｉｎｉＢａｎｄは、ＩｎｆｉｎｉＢａｎｄ固有のネットワーク上でカーネルバイパスフレームワークを提供する。「ＩｎｆｉｎｉＢａｎｄ」及び「ＲＤＭＡ」という用語はしばしば区別なく使用されるが、他のプロトコル（ｉＷＡＲＰ及びＲｏＣＥなど）もＲＤＭＡ形式のカーネルバイパスフレームワークを提供する。
ＶＩＡタイプのプロトコルは、一般的に、低レイテンシ、高帯域幅及びカーネルバイパスネットワークを提供する。ＶＩＡタイプのプロトコルは少なくとも以下、つまり、複数のユーザアプリケーション間のリソース共有により生じるオーバーヘッドを削減すること、トランスポートプロトコル処理をプロセッサから排除すること、データの高速なバルク転送及びリモートアプリケーションの待機時間を削減することを提供することを目的とする。
ＶＩＡタイプのプロトコルは、複数のユーザアプリケーション間のリソース共有により生じるオーバーヘッドを削減することを目的とする。通常のネットワークプロトコルスタックはカーネルレベルで動作し、複数のアプリケーション間でネットワークインタフェースの共有を容易にする。しかしながら、このリソース共有は、少なくとも以下の理由、つまり、複数のプロセッサコア間の調整によりレイテンシが増加し得ること、アプリケーションを起動するために使用するプロセッサ間の割り込みによりレイテンシが増加し得ること、互いからアプリケーションを保護するために中間キューイングまたはバッファリングが必要になり得ること及びキューまたはバッファ間のコピーによりレイテンシが増加し得ることによって、ネットワーク遅延が生じることがあり、ダイレクトメモリアクセス（ＤＭＡ）はこれらのアプリケーション用に構成できないため、アプリケーションバッファ間で内部カーネルバッファをコピーする必要があり得る。
単一のネットワークインタフェースを共有しようとする複数のユーザアプリケーションにより生じる遅延を回避する１つの方法は、一度に１つのアプリケーションのみがネットワークインタフェースを使用するようにすることである。データプレーン開発キット（ＤＰＤＫ）は、これを可能にするフレームワークの一例を提供する。ＤＰＤＫフレームワークは、ユーザ空間ポーリングモードのデバイスドライバの形態で、単純なネットワークインタフェースを提供し得る。ＤＰＤＫフレームワークは、他のオペレーティングシステムサービスの代替にもなり得、これによって、ユーザアプリケーション用のアプリケーションプログラミングインタフェース（ＡＰＩ）及び単一ユーザの協働マルチタスク用に設計された実行モデルを提供する。このフレームワークは、ネットワークインフラストラクチャ（例えば、ゲートウェイデバイス）にとっては効率的であり得るが、ＤＰＤＫ固有のＡＰＩに対応するために書き直す必要のあり得る従来のユーザアプリケーション及びミドルウェアにとっては実用的でない場合がある。ＤＰＤＫフレームワークはさらに、実行にルート権限が必要な場合があり、これはカーネルに負荷をかける可能性があり、セキュリティ上のリスクが発生する可能性がある。さらに、ＤＰＤＫ環境ではアプリケーションが物理メモリアドレスを使用する必要があり得、これにより仮想マシンの使用が制限されるため、ＤＰＤＫフレームワークはマルチユーザ環境では実用的ではない可能性がある。単一のユーザであっても、ＤＰＤＫフレームワークは実用的ではない可能性がある。ＤＰＤＫ及び類似のモデルを拡張してトランスポートスタックの機能を担い、これにより複数のアプリケーションを提供できるようにしてよい。ただし、これらのアプリケーションとＤＰＤＫプロセスとの間の通信には、大幅なレイテンシが発生する可能性がある。
ハードウェアリソースを効率的に共有するための別の方法はカーネルバイパスフレームワークであり、これは、上記の通り、一般的にはＲＤＭＡフレームワークと呼ばれる。ＲＤＭＡベースのデバイスは、権限のないユーザアプリケーションで使用され得る。ＲＤＭＡベースのデバイスはさらに、複数のアプリケーションが互いに干渉することなくハードウェアに直接アクセスできるようにし得る。ＲＤＭＡデバイスは、初期化を実行するための制御操作及び割り込み処理に必要となり得るいくつかの調整のためのみにカーネルに依存することがあるが、別様には、ＲＤＭＡデバイスはカーネルとは独立して動作し得る。これは、プロセッサがＲＤＭＡ動作に関与する必要がないことを意味する。ＲＤＭＡフレームワークはさらに、ポーリングモード完了処理などの最適化を提供してよく、最適化は超低レイテンシを提供するのに有益であり得る。
上記の通り、ＶＩＡタイプのプロトコルは、トランスポートプロトコルの管理におけるプロセッサの関与を削減することを目的とする。前述の通り、ネットワークプロトコルの管理におけるプロセッサの関与はレイテンシの潜在的な原因である。アプリケーションがリモートの宛先に長いメッセージを送信すると、ローカルコンピュータとリモートコンピュータとの両方でプロセッサが関与する可能性がある。例えば、プロセッサは、メッセージをパケットに分割し、送信のためにハードウェアキューにパケットを個別に送り、パケットを受信し、確認パケットを生成し、ホストメモリ内でデータを配置する位置を決定する必要があり得る。特に、パケットが到着すると、単純なネットワークインタフェースカードは、周辺置バス上でホストデバイスのメインメモリにパケットを渡し、次いで、プロセッサに割り込みを発行することがあり、割り込みは実際にプロセッサに警告するまでにある程度時間がかかり得る。一旦割り込まれると、プロセッサは、通常、オペレーティングシステムにより生じる追加の遅延の後で、確認の生成など、プロトコル処理動作を実行し得る。
プロトコル動作を処理し、これらの動作をプロセッサから排除するように構成されたネットワークアダプタは、各パケットのより高速な処理を可能にし得る。ネットワークアダプタデバイスは、着信メッセージ及びリモート読み取り及び書き込みコマンドを処理することができ得る。ネットワークアダプタはさらに、ホストメモリに対してＤＭＡトランザクションを行い、確認パケットを生成することができ得る。ネットワークアダプタは、プロセッサに割り込むことなく、これらの動作を行うことができ得る。
前に記した通り、ＶＩＡタイプのプロトコルの別の目的は、データの高速なバルク転送を提供することである。データのバルク転送、つまり、大量のデータの転送は、単にネットワークリンクの帯域幅を増やすことによって高速に実行され得る。しかしながら、高速ネットワーク相互接続は、送信元及び／または宛先コンピュータのメモリサブシステムに負荷をかけ得る。メモリサブシステムは、通常、オーバープロビジョニングされないため、高帯域幅のネットワーク転送中に複数回アクセスするとボトルネックになり、メモリへの中間コピーの配置が発生することがある。バルク転送で複数のコピーを作成する必要がある場合、このコピーによって転送のスループットが制限されることがあり、トランザクションレイテンシが増加し得る。この遅延を軽減するための１つの可能な方法は、大容量のレベル３（Ｌ３）キャッシュを含むプロセッサによって提供される。これらのプロセッサでは、ネットワークインタフェースカードがＬ３キャッシュに直接データを書き込み得る。しかしながら、これらのプロセッサは、キャッシュの性質（キャッシュにないデータをフェッチする必要があり、ゆえにレイテンシを招く）に起因して一貫性を伴うことなく行われ得る。さらに、データが迅速にコピーされない場合、より有用なデータに使用される可能性があるＬ３キャッシュ内の空間をデータが専有し得るため、Ｌ３キャッシュは役に立たない可能性がある。
カーネルバイパスフレームワークは、「ゼロコピー」データ転送と呼ばれることが多いプロセスにより、良好な解決策を提供する。ゼロコピーは、ＲＤＭＡによって提供される動作の１つである。ＲＤＭＡは、ダイレクトメモリアクセス（ＤＭＡ）の拡張を表す。ＤＭＡは、通常、特定のハードウェアサブシステムがプロセッサを使用することなくメインシステムメモリにアクセスすることを可能にする。同様に、ＲＤＭＡによって、コンピュータは、いずれのコンピュータのプロセッサも関与させることなく、ネットワーク上で別のコンピュータ上のメモリにアクセスすることが可能になる。ゆえに、ローカルコンピュータは、ローカルコンピュータまたはリモートコンピュータのいずれかにおけるプロセッサによって中間コピーを作成することなく、リモートコンピュータのメモリ上で読み取り、書き込みまたはアトミック操作を行うことができ得る。多数の実装では、それぞれがＲＤＭＡアダプタを有するローカルコンピュータ及びリモートコンピュータによってＲＤＭＡが可能になる。
前に記した通り、ＶＩＡタイプのプロトコルはさらに、リモートアプリケーションの待ち時間を削減することを追求する。アプリケーション自体がネットワークレイテンシに寄与し得る。ネットワークトランザクションには、ローカルコンピュータとリモートコンピュータとの両方でアプリケーションが関与し得る。リモートアプリケーションは、例えば、スケジューリング遅延に起因して、トランザクションに応答するのにある程度時間がかかり得る。ローカルアプリケーションのみが関与する「一方向の」ＲＤＭＡ通信は、リモートアプリケーション上で待機することによって発生するレイテンシを削減し得る。そのメモリへのアクセスを許可することにより、リモートアプリケーションはデータ転送に関与する必要がなくなり得る。代わりに、リモートコンピュータでのＲＤＭＡアダプタは、リモートアプリケーションに関与することなく、リモートメモリに直接アクセスすることができ得る。ＲＤＭＡはさらに、読み取り動作及び書き込み動作に加えて、リモートのアトミック操作を提供することがあり、これは、ロック動作により生じるレイテンシを削減し得る。
要約すると、ＶＩＡタイプのプロトコルは、複数のユーザアプリケーション間のリソース共有により生じるオーバーヘッドを削減し得る。ＶＩＡプロトコルはさらに、トランスポートプロトコル処理の動作をプロセッサから排除し得る。これらのプロトコルはさらに、データの高速なバルク転送を提供し、リモートアプリケーションが応答するまでの待ち時間を削減し得る。これらの動作はＲＤＭＡとして表されることが多いが、より一般的には、カーネルバイパス動作として表され得る。これらの機能はさらに、リモートメモリアクセス（ＲＭＡ）または一方向通信と呼ばれ得る。
図２は、カーネルバイパスフレームワークを実装するために使用され得る通信スタック２００の一例を例示する。図２に例示するような通信スタック２００を使用すると、クライアントプロセス２０２は、ローカルシステム２３０またはリモートシステム２３２のいずれかでプロセッサからの支援を伴うことなく、リモートシステム２３２上のリモートプロセス２０４と直接通信することができ得る。図２の例では、一例として、２つの異なるシステム上で実行している２つのプロセス間の通信スタック２００を例示する。以下に説明する通り、ネットワークファブリック２２０を通じて通信する任意の２つのプロセス間で同様の通信スタックを構成することができる。さらに、一方のシステム２３０を「ローカル」と呼び、他方のシステム２３２を「リモート」と呼ぶが、いくつかの実装では、通信スタック２００は、リモートシステム２３２がローカルシステム２３０に送られるメッセージを発信できるように、逆方向に動作することもできることが理解される。
いくつかの実装形態では、図２に例示する通信スタック２００は、ローカルシステム２３０またはリモートシステム２３２のいずれかでプロセッサを最小限に使用して動作する。ネットワークトラフィック制御作業をプロセッサから排除または削減することは、「作業キューペア」または単に「キューペア」２１０ａ〜ｂとも呼ばれる「作業キュー」によって完了され得る。ローカルシステム２３０とリモートシステム２３２との間の各通信チャネルに対して、キューペア２１０ａ〜ｂが両方のシステム２３０、２３２に割り当てられ得る。キューペア２１０ａ〜ｂは、ネットワークファブリック２２０に向かうトラフィック用の送信キュー２１２ａ〜ｂ及びネットワークファブリック２２０から入ってくるトラフィック用の受信キュー２１４ａ〜ｂを含む。いくつかの実装では、クライアントプロセス２０２は、リモートプロセス２０４との通信チャネルを確立するときに、キューペア２１０ａ〜ｂを開始する。これらの実装では、クライアントプロセス２０２は、異なるプロセスが同じリモートシステム２３２上で動作中であるか、またはプロセスが他のリモートシステム上で動作中である状態で、同じリモートプロセス２０４と通信するために追加の作業キューを開始することができる。クライアントプロセス及びリモートプロセスには、ユーザアプリケーション及び／またはドライバプログラムなど、カーネル以外のプロセスまたはオペレーティングシステムプロセスが含まれる。
いくつかの実装では、ローカルシステム２３０のキューペア２１０ａは、送信元チャネルアダプタ２０８ａ上に存在する。送信元チャネルアダプタ２０８ａは、ネットワークファブリック２２０と通信するように構成され得る。送信元チャネルアダプタ２０８ａは、他のプロセスに割り当てられるか、同じクライアントプロセス２０２に割り当てられる追加のキューペア、あるいは現在使用されていない可能性がある追加のキューペアを含み得る。いくつかの実装では、キューペア２１０ａの使用及び構造が明確に理解されてよく、ゆえに、キューペア２１０ａはハードウェアに実装されてよい。他の実装では、キューペア２１０ａは、ソフトウェア（例えば、ドライバ）またはハードウェアとソフトウェアとの組み合わせに実装されてよい。キューペア２１０ａに加えて、送信元チャネルアダプタはさらに、ネットワークファブリック２２０及びリモートプロセス２０４との通信を管理するトランスポート層２１６ａを含み得る。送信元チャネルアダプタ２０８ａはさらに、送信元チャネルアダプタ２０８ａをファブリック２２０に接続する物理ポート２１８ａを含み得る。送信元チャネルアダプタ２０８ａはさらに、ホストチャネルアダプタ、またはより一般的にはネットワークアダプタと呼ばれ得る。
クライアントプロセス２０２は、「作業キュー要素」２２２（ＷＱＥと略されることが多い）をローカル送信キュー２１２ａに配置することによって、リモートプロセス２０４へのトランザクションを開始し得る。作業キュー要素２２２は、読み取りトランザクション、書き込みトランザクションまたはアトミックトランザクションなどのトランザクションを含み得る。いくつかの実装では、作業キュー要素２２２はさらに、リモートプロセス２０４をトランザクションのターゲットとして識別する情報を含み得る。送信元チャネルアダプタ２０８ａは、送信キュー２１２ａから直接的に作業キュー要素２２２を処理し得る。送信元チャネルアダプタ２０８ａは、作業キュー要素２２２内の情報を使用して１つ以上のパケットを生成し得る。トランスポート層２１６ａは、ポート２１８ａを通じてこれらの１つ以上のパケットをネットワークファブリック２２０に送信し得る。
リモートシステム２３２は、それ自体の宛先チャネルアダプタ２０８ｂ（ターゲットチャネルアダプタ、またはより一般的にはネットワークアダプタとも呼ばれる）でネットワークファブリック２２０から１つ以上のパケットを受信し得る。送信元チャネルアダプタ２０８ａと同様に、宛先チャネルアダプタ２０８ｂは、宛先チャネルアダプタをネットワークファブリック２２０に接続するポート２１８ｂを含む。宛先チャネルアダプタ２０８ｂはさらに、ネットワークファブリック２２０及びクライアントプロセス２０２との通信を管理するトランスポート層２１６ｂを含み得る。宛先チャネルアダプタ２０８ｂはさらに、リモートプロセス２０４に割り当てられるキューペア２１０ｂを含み得る。
リモートシステム２３２で受信されたネットワークファブリック２２０からの１つ以上のパケットは、トランスポート層２１６ｂによって受信キュー２１４ｂに送られ得る。いくつかの実装では、宛先チャネルアダプタ２０８ｂは、クライアントプロセス２０２によって生成されたメッセージ２２２を再構築し、再構築されたメッセージを受信キュー２１４ｂに配置し得る。リモートプロセス２０４は、要素がその受信キュー２１４ｂに到着するときに自動的に通知され得る。リモートプロセス２０４は、受信キュー２１４ｂから要素２２４をポップしてよく、要素２２４に動作を行ってよく、その後、いくつかの場合では、クライアントプロセス２０２に返すことになる応答を生成してよい。リモートプロセス２０４は、応答を含む作業キュー要素２２６をそれ自体の送信キュー２１０ｂに配置し得る。応答は、次いで、ファブリック２２０を通過してローカルシステム２３０に返送されてよく、「完了キューエントリ」２２８（ＣＱＥと略されることが多い）としてクライアントプロセス２０２に配信される。
この情報交換では、ローカルシステム２３０とリモートシステム２３２との両方でオペレーティングシステムのカーネルが必要とされない可能性が高い。例えば、カーネルバイパスを実装していないシステムの場合のように、それぞれのネットワークアダプタカードの使用を調整するためにクライアントプロセス２０２またはリモートプロセス２０４のいずれも不要になり得る。代わりに、各プロセス２０２、２０４は、他のプロセス２０２、２０４との排他的な通信チャネルを有すると考えられ得る。実際には、複数のプロセスがネットワークアダプタカード２０８ａ〜ｂを使用してネットワークファブリック２２０上で通信することがあるが、ネットワークアダプタカード２０８ａ〜ｂは、複数のプロセスとそれらのそれぞれのキューペアとの間の調整を管理する。追加的には、トランスポート層２１６ａ〜ｂは、例えば、ネットワークファブリック２２０によって送信及び受信されドロップされる可能性のあるパケットを追跡するなど、クライアントプロセス２０２とリモートプロセス２０４との間の接続を管理し得る。
多くの実装では、トランスポート層２１６ａ〜ｂは、送信キュー２１２ａ〜ｂに対するいくつかの動作を支援し得る。例えば、トランスポート層２１６ａ〜ｂは、あるプロセスがメッセージを送信し、ネットワーク上の別のシステム上の別のプロセスがそのメッセージを受信するといった典型的な送信及び受信動作を支援し得る。別の例として、トランスポート層２１６ａ〜ｂはさらに、１つのプロセスがリモートシステムのメモリバッファに直接書き込むといったＲＤＭＡ書き込みを支援し得る。この例では、リモートプロセスは適切なアクセス権限を送信システムに事前に付与し、リモートアクセス用にメモリバッファを登録するだろう。別の例として、トランスポート層２１６ａ〜ｂは、１つのプロセスがリモートシステムのメモリバッファから直接読み取るＲＤＭＡ読み取りを支援し得る。この例では、リモートシステムはさらに、適切なアクセス権限を送信システムに事前に付与するだろう。別の例として、トランスポート層２１６ａ〜ｂはさらに、ＲＤＭＡタイプのアトミック操作を支援し得る。このようなアトミック操作の１つに「コンペアアンドスワップ」があり、コンペアアンドスワップでは、プロセスがリモートメモリの位置を読み取り、読み取ったデータが指定の値であれば、同じリモートメモリの位置に新しい値を書き込む。別のアトミック操作には「フェッチアッド」があり、フェッチアッドでは、プロセスがリモートメモリから位置を読み取り、呼び出し元に読み取ったデータを返送し、次いで、指定の値をデータに追加し、変更された値を同じリモートメモリの位置に書き込む。
いくつかの実装では、トランスポート層２１６ａ〜ｂはさらに、受信キュー２１４ａ〜ｂに対する動作を支援し得る。例えば、トランスポート層２１６ａ〜ｂは、「受信後バッファ」と呼ばれる動作を支援することがあり、「受信後バッファ」では、送信用ターゲット、ＲＤＭＡ書き込み及び別のシステムによって開始されたＲＤＭＡ読み取りのために使用され得るバッファが識別される。
いくつかの実装では、キューペアが開始されると、開始プロセスはキューペアをトランスポートサービスタイプに関連させ得る。トランスポートサービスタイプは、次いで、送信元システムから宛先システムへのパケットの送信方法を決定し得る。図３は、トランスポートサービスタイプ３００の例を例示する。ＶＩＡタイプのプロトコルによって使用されるトランスポートサービスタイプ３００は、接続型３０２または非接続型３０４及び信頼可能３０６または信頼不可能３０８に分類することができる。接続型３０２及び非接続型３０４は、送信プロセスと受信プロセスとの間に明確な接続が確立されているかどうかを表す。接続型３０２のトランスポートサービスタイプ３００では、接続は、ほとんどの実装において、送信及び受信プロセスに排他的である。非接続型３０４のトランスポートサービスタイプ３００では、パケットまたは「データグラム」がネットワークに送信され、通常、その宛先に利用可能なあらゆる経路に従う。信頼可能３０６及び信頼不可能３０８は、トランスポートサービスタイプ３００がパケットの配信を保証するかどうかを表す。信頼可能３０６なトランスポートサービスタイプ３００は、通常は配信を保証し、一方で信頼不可能３０８なトランスポートサービスタイプ３００は、通常は配信を保証しない。
接続型３０２かつ信頼可能３０６なトランスポートサービスタイプ３００の例は、信頼可能な接続３１０（ＲＣ）と呼ばれる。信頼可能な接続３１０は、パケットの順序通りの配信を保証する。順序通りとは、メッセージが送信元アプリケーションによって送信された順序と同じ順序で宛先アプリケーションに配信されることを意味する。信頼可能な接続３１０はさらに、通信するプロセスの各ペア間の接続の明確な確立を必要とする。明確な接続を確立するステップの例は、以下の通りである。クライアントプロセスは、まず、通信スタック（例えば、図２の通信スタック２００）を使用して宛先システムのネットワークアドレスを検索し得る。クライアントプロセスは、次に、トランスポート層に接続コンテキストを作成するよう要求し得る。クライアントプロセスは、次いで、トランスポート層（またはトランスポート管理）が接続コンテキストをリモート宛先アドレスに関連させるよう要求し得る。最終的に、トランスポート層（またはトランスポート管理）は、接続を確立するために、宛先システムとのメッセージの交換（例えば、「ハンドシェイク」）を行い得る。
図３に戻ると、明確な接続確立では、信頼可能な接続３１０タイプのトランスポートサービスの拡張は困難になり得る。上記の通り、２つのプロセスがネットワークを通じて通信するには、明確な接続を確立する必要がある。ゆえに、ネットワークに接続されるノードにプロセスが追加されると、接続数が大幅に増加する。例えば、ローカルシステムでの１００のプロセスがリモートシステム上で動作中の１００のプロセス全てと通信すると、１００×１００、つまり１０，０００の接続を確立する必要があるだろう。さらに、コンピューティングクラスタは数百のノードを有することがあり、各ネットワークノードは数百またはそれ以上のプロセッサを実行していることがあり、その結果、クラスタは無数の接続を必要とする可能性がある。
潜在的により高い拡張性を備え得るトランスポートサービスタイプ３００は、信頼不可能なデータグラム３１６（ＵＤ）である。信頼不可能なデータグラム３１６は、明確な接続確立を必要とせず、配信を保証しない。配信を保証しないということは、送信者がパケットをネットワークファブリックに送信し、パケットがその宛先に到着したかどうかを確かめようとしないことを意味する。信頼不可能なデータグラム３１６は、例えば、信頼可能な接続３１０を確立するために交換するメッセージなど、管理目的のためにメッセージを転送するために使用され得る。信頼不可能なデータグラム３１６はパケット配信を保証しないため、パケットドロップがほとんど発生しないネットワーク（例えば、ＩｎｆｉｎｉＢａｎｄネットワークなど）では効果的であり得る。しかしながら、パケットドロップが発生しやすいネットワークでは、信頼不可能なデータグラム３１６は一般に使用されない。
信頼不可能な接続３１２はさらに、パケットドロップが発生しやすいネットワークにおいて使用され得る。信頼可能な接続３１０と同様に、信頼不可能な接続３１２は明確な接続確立を必要とするが、配信を保証する。信頼不可能な接続３１２は、（例えばビデオストリーミングなど）パケットドロップに耐久可能なアプリケーションで使用され得るが、ドロップへの耐久性がないアプリケーションでは問題となる。
信頼可能なデータグラム３１４（ＲＤ）は、明確な接続確立を必要とせず、全てのパケットの配信を保証する。信頼可能なデータグラム３１４は、もともとは信頼可能な接続３１０の拡張性の問題を軽減するために開発されたが、単独接続の性能が損なわれている。その結果、信頼可能なデータグラム３１４は一般に使用されていない。
主要なトランスポートサービスタイプ３００の望ましい態様の組み合わせを試みるいくつかのトランスポートサービスタイプ３００が開発されてきた。信頼可能な接続３１０の拡張性の問題に対処するために、拡張型の信頼可能な接続３１８（ＸＲＣ）が開発された。拡張型の信頼可能な接続３１８は、プロセスが通信している宛先システムにおける全てのプロセスに対して、宛先システムごとに１つの接続のみを使用することを可能にする。拡張型の信頼可能な接続３１８は、しかしながら、複雑なアプリケーションインターフェースを有することが知られている。動的な接続３２０（ＤＣ）は、信頼可能な接続３１０のパケット配信保証と、明確な接続を必要としない信頼不可能なデータグラム３１６とを組み合わせることを試みる。動的な接続３２０では、信頼可能な接続３１０の場合のように接続は固定的ではないが、その代わり、必要に応じて設定され、必要なくなったときに排除される。動的な接続３２０は、しかしながら、パケットドロップが非常に稀であるＩｎｆｉｎｉＢａｎｄタイプのネットワーク向けに開発された。動的な接続３２０は、ゆえに、パケットドロップがより頻繁に発生するネットワークでは、効率性が低くなり得る。
以下のセクションでさらに詳細に説明する緩和された信頼可能なデータグラム３２２（ＲＲＤ）は、パケットドロップが稀に発生するイベントではないネットワークにおいて、拡張性及び保証されたパケット配信を提供し得る。緩和された信頼可能なデータグラム３２２は、信頼不可能なデータグラム３１６と同様の簡素でコネクションレス型のインタフェースをユーザアプリケーションに提供し得る。緩和された信頼可能なデータグラム３２２はさらに、信頼可能な接続３１０と同様に、パケット配信を保証する。緩和された信頼可能なデータグラム３２２はパケットを順序通りに配信せず、これによって、トランスポート設計を簡略化し、パケット配信の効率性を潜在的に高める。
図４は、上記のトランスポートサービスのうちの１つ以上に加えて、緩和された信頼可能なデータグラムトランスポートを供給するように構成され得るシステム４００の一例を例示する。ハードウェア及びソフトウェア構成要素に関して説明するが、システム４００の例は主に機能的な説明であり、例示の様々な構成要素は、ハードウェア、ソフトウェア、ハードウェアとソフトウェアとの組み合わせで実装されてよく、この特定の例で説明される以外の論理構成及び／または物理構成で実装されてよい。
システム４００の例は、ホストデバイス４１０及びネットワークアダプタデバイス４２０を含む。ホストデバイス４１０及びネットワークアダプタデバイス４２０は、ケーブル、プラグ、ソケット、スロット、プリント回路基板またはこれらの物理的構成要素の組み合わせなどの物理接続上で通信し得る。ホストデバイス４１０は、図面には例示していないが、１つ以上のプロセッサ、メモリサブシステム、周辺装置及びその他などの構成要素を含む、汎用コンピューティングシステムであり得る。いくつかの実装では、以下に説明するネットワークアダプタデバイス４２０の動作は、集積回路デバイス及び／または集積回路デバイスの集合体で実施され得る。例えば、様々な実装では、ネットワークアダプタデバイスの動作は、システムオンチップ（ＳｏＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）あるいはこれらのデバイスの組み合わせで実装され得る。
ホストデバイス４１０は、１つ以上の仮想マシン４０２を実行するように構成され得る。仮想マシンは、現実または仮想のコンピューティングシステムを表すエミュレートされたコンピューティング環境である。仮想マシンは、物理コンピュータと同様に、オペレーティングシステムを含むプログラムを実行し得る。仮想マシンは、一般的に、互いに単独的に動作し、仮想マシン内のプロセスは、異なる仮想マシン内で動作中のプロセスに影響を与えることができない。仮想マシンは、専用のハードウェア、ソフトウェア、ハードウェアとソフトウェアとの組み合わせを伴い得る。
システム４００の例の仮想マシン４０２は、１つ以上のユーザアプリケーション４０４ａ〜ｂを実行中であってよい。ユーザアプリケーション４０４ａ〜ｂは、例えば、高性能なコンピューティングアプリケーション、他の計算集中型プログラムならびに通常のユーザアプリケーション、例えば、文書編集ツール及びウェブブラウザなどを含む。ほとんどの実装では、ユーザアプリケーション４０４ａ〜ｂは、「ユーザ空間」、つまり、オペレーティングシステム（通常は「カーネル空間」で動作する）及び基礎となるハードウェアから互いに分離した環境で動作する。オペレーティングシステムのカーネル４１２は、ユーザアプリケーション４０４ａ〜ｂのそれぞれ及びその基礎となるハードウェアへのアクセスを含む、より多くのアクセス権限を有し得る。
ユーザアプリケーション４０４ａ〜ｂは、標準ライブラリ４０６及び／またはユーザ空間ドライバプログラム４０８を通じてシステム４００のハードウェアと通信し得る。標準ライブラリ４０６は、共通の動作を実行するための公知及び合意されたアプリケーションプログラミングインタフェース（ＡＰＩ）を提供する。これらの一般的な動作は、例えば、頻繁に実行されるソフトウェア動作及びシステム４００のハードウェアへのアクセスを含み得る。標準ライブラリの１つのカテゴリは、カーネルバイパスフレームワークのために定義されたものである。これらのライブラリには、例えば、ＯｐｅｎＦａｂｒｉｃｓ Ａｌｌｉａｎｃｅ（ＯＦＡ）、Ｏｐｅｎ Ｆａｂｒｉｃｓ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＯＦＥＤ）ｖｅｒｂｓライブラリ及びＬｉｂＦａｂｒｉｃ ＯｐｅｎＦａｂｒｉｃｓ Ｉｎｔｅｒｆａｃｅｓ（ＯＦＩ）、ＯｐｅｎＦａｂｒｉｃｓ Ｉｎｔｅｒｆａｃｅｓを実装するオープンソースＬｉｎｕｘライブラリが含まれる。ＯＦＥＤはもともとＩｎｆｉｎｉＢａｎｄ ＶｅｒｂｓにＡＰＩを提供するために開発された。ＩｎｆｉｎｉＢａｎｄ Ｖｅｒｂｓは、ハードウェアまたはオペレーティングシステムとは独立したＩｎｆｉｎｉＢａｎｄアダプタの機能性の抽象的な表現である。ＯＦＥＤは後に非ＩｎｆｉｎｉＢａｎｄアダプタをサポートするために発展した。しかしながら、ＯＦＥＤ ＡＰＩのセマンティクスは、一般的に、多くのアプリケーションの要件と互換性がなく、特に規模が大きい場合には使用しにくいことが知られている。ＯＦＩは、対照的に、複数のタイプのセマンティクスを提供し、基礎となるハードウェア機能を公開することに加え、アプリケーションのニーズにも焦点を当てていることが知られている。
いくつかの実装では、標準ライブラリ４０６は、ユーザ空間ドライバプログラム４０８と通信してよく、ユーザ空間ドライバプログラム４０８は、特定のハードウェアデバイスへのアクセスを提供するように構成される。いくつかの場合、ユーザアプリケーション４０４ｂは、ユーザ空間ドライバプログラム４０８と直接的に通信することができ得る。この例では、ユーザ空間ドライバプログラム４０８は、ネットワークアダプタデバイス４２０へのアクセスを提供し得る。ユーザ空間ドライバプログラム４０８は、標準ライブラリ４０６によって提供される抽象化と、ネットワークアダプタデバイス４２０の特定のハードウェアとの間のインタフェースを提供し得る。例えば、ユーザ空間ドライバプログラム４０８は、送信キュー及び受信キューを含む通信スタックへのアクセスを提供してよく、いくつかの実装では、通信スタックはネットワークアダプタデバイス４２０に配置されてよい。
いくつかの実装では、ユーザアプリケーション４０４ａ〜ｂは、構成動作のためにオペレーティングシステムのカーネル４１２と通信し得る。例えば、ユーザアプリケーション４０４ａ〜ｂは、仮想アドレス及びメモリ領域をカーネル４１２に登録し得る。いくつかの実装では、カーネル４１２は、カーネル空間トランスポートドライバ４１６を含み得る。カーネル空間トランスポートドライバ４１６は、ユーザアプリケーション４０４ａ〜ｂへのキューペアのマッピング、メモリ登録及びネットワークアドレス管理を含む制御動作を実行するように構成され得る。
ネットワークアダプタデバイス４２０は、ネットワーク４３０と通信するように構成され得る。ネットワークアダプタデバイス４２０は、送信動作及び受信動作を実行するように構成され得る管理モジュール４２２を有し得る。管理モジュール４２２は、例えば、ファームウェアまたはＦＰＧＡもしくはＡＳＩＣなどの集積回路であり得る。ネットワーク４３０上でメッセージを送信するために、管理モジュール４２２は、ユーザアプリケーションのメッセージを使用してパケットを生成し、パケットヘッダを構築するように構成され得る。ネットワーク４３０からメッセージを受信するために、管理モジュール４２２は、パケットヘッダを削除し、受信ユーザアプリケーション４０４ａ〜ｂに向けて受信メッセージを送信するように構成され得る。受信したメッセージは、いくつかの場合、送信者のアドレスまたは送信者を識別する何らかの他の情報を含み得る。
ネットワークアダプタデバイス４２０は、例えば、信頼不可能なデータグラムトランスポート４２４及び緩和された信頼可能なデータグラムトランスポート４２６など、１つ以上のトランスポートサービスを提供し得る。ネットワークアダプタデバイス４２０は、図面には例示されていない他のトランスポートサービスを提供し得る。いくつかの実装では、緩和された信頼可能なデータグラムトランスポート４２６は、信頼可能な接続タイプの動作を提供するように構成され得る。これらの実装では、緩和された信頼可能なデータグラムのコンテキストを単一のキューペアに割り当ててよく、トランスポートコンテキストを１つのローカルユーザアプリケーションと１つのリモートユーザアプリケーションとの間の１つの通信チャネルに対して排他的にする。
上記の通り、緩和された信頼可能なデータグラムトランスポート４２６を使用するメッセージ転送は、「コネクションレス型」であってよく、つまり、ユーザアプリケーションがターゲットアプリケーションとの明確な接続の確立を必要としない可能性がある。代わりに、接続管理は緩和された信頼可能なデータグラムトランスポート４２６によって処理され得る。
追加的には、緩和された信頼可能なデータグラムトランスポート４２６は、その宛先に順不同で到着し得るパケットの配信を保証し得る。これは、パケットが送信元システムで発信されたときと同じ順序でパケットを並び替える必要があり得ることを意味し得る。従来、パケットの順序付け及び信頼性動作は、ネットワークアダプタまたはホストデバイスソフトウェアのいずれかで、共に処理されていた。例えば、パケット配信を保証する最も信頼可能なトランスポートサービスタイプは、通常、パケットをドロップしないネットワークに依存する。ドロップされたパケットは、（１つ以上のパケットが到着していないため）結果的にパケットが順不同で到着する可能性があり、その場合、ネットワークアダプタデバイスは、順不同のパケットを拒否し得るか、パケットのストリーム全体の再送を必要とし得る。
別の代替策は、ネットワークアダプタデバイスが、順不同で到着したパケットを並び替えることである。パケットの並び替えは、しかしながら、一般的に処理が集中する動作である。ネットワークアダプタデバイスは、通常、安価で低出力のプロセッサを有する。ゆえに、順不同のパケットを処理しようとする実装では、通常、ホストデバイスのソフトウェア内でパケットを並び替え、通常、ホストデバイスによって提供される高出力のプロセッサを利用する。これらの実装では、ソフトウェアも、欠落パケットの追跡及び再要求などの動作を含め、信頼可能なパケット配信を確実にしようとする。しかしながら、上述の通り、プロセッサの関与はレイテンシに悪影響を与え得る。ゆえに、信頼可能なパケット配信を追求する実装は、ネットワークアダプタデバイスの信頼性の態様を実施しており、結果的に、パケットの順序通りの配信を要求する。
図４のシステム４００の例などのシステムは、緩和された信頼可能なデータグラムトランスポートを使用して、パケットの並び替え及び信頼性動作を分離してよく、最も効率的に処理され得るシステム内のポイントでそれらを実行する。例えば、システム４００は、パケットの信頼可能な配信がネットワークアダプタデバイス４２０によって処理されるように構成されてよく、ネットワーク４３０を通じてパケットを転送することに固有のレイテンシを最小化するのに適している可能性がある。さらに、パケットの並び替えは、ユーザアプリケーション４０４ａ〜ｂ及び／またはドライバプログラム４０８、４１６によって処理されてよく、それぞれがホストデバイス４１０のプロセッサ上で実行されてよい。
信頼可能な順不同のパケット配信を完了し得る方法を説明する前に、接続確立をまず説明する。緩和された信頼可能なデータグラムトランスポートを使用するシステムでは、トランスポートサービスは、コンピューティングクラスタによって提供されたネットワークを通じて互いに通信するユーザアプリケーションに対して「コネクションレス型」のメッセージ転送を促進し得る。
Ｉ．「コネクションレス型」のメッセージの転送
図５Ａ〜図５Ｂは、ユーザアプリケーション５０４ａがメッセージを別のアプリケーションに送信するために後続的に使用可能なアドレスハンドルをユーザアプリケーション５０４ａが取得し得るプロセス５００の一例を例示する。プロセス５００は、ユーザアプリケーション５０４ａによって明確な接続が確立されない点において、信頼可能なデータグラム及び信頼不可能なデータグラムのトランスポートによって使用されるプロセスと同様であり得る。プロセス５００は、トランスポートサービス（ここでは、緩和された信頼可能なデータグラムトランスポート）が他のシステムへの接続を確立及び保持するように機能し得るという点において、信頼可能なデータグラム及び信頼不可能なデータグラムによって使用されるプロセスとは異なり得る。さらに、この接続の保持は、明確な接続の代わりにアドレスハンドルが提供されるユーザアプリケーションからは分からない。ユーザアプリケーション５０４ａは同じプロセス５００を使用して、ユーザアプリケーションが通信しようとする各宛先のアドレスハンドルを取得し得る。図５Ａは、ホストデバイス５０２上で実行している任意のプロセスによって宛先が以前に登録されていない場合のプロセス５００の一部を例示する。図５Ｂは、宛先が以前に登録されていた場合を例示する。
いくつかの実装では、ユーザアプリケーション５０４ａは、ネットワーク上でメッセージを送信するためにアドレスハンドルを使用することはできない。例えば、ユーザアプリケーション５０４ａは、メッセージを送信するために、宛先アドレスまたは他の宛先情報を使用し得る。これらの場合、ユーザアプリケーション５０４ａは、アドレスハンドルを提供する代わりに、宛先情報をネットワークアダプタデバイスに直接提供し得る。これらの実装では、少なくともいくつかの宛先に対して、ユーザアプリケーション５０４ａは図５Ａ〜図５Ｂに例示するプロセス５００を使用することができない。ユーザアプリケーションがメッセージを送信するためにアドレスハンドル以外の宛先情報を使用する場合については、図６Ａ〜図６Ｂに関してさらに説明する。
図５Ａに例示する通り、プロセス５００は、ネットワークアダプタデバイス５２０と通信するホストデバイス５０２を伴い得る。ホストデバイス５０２は、図面には例示していないが、１つ以上のプロセッサ、メモリサブシステム、周辺装置及びその他などの構成要素を含む、汎用コンピューティングシステムであり得る。ホストデバイス５０２は、例示のユーザアプリケーション５０４ａを含む、１つ以上のユーザアプリケーションを実行中であり得る。これらのユーザアプリケーションは、図面には例示していない１つ以上の仮想マシンで動作中であり得る。ホストデバイス５０２はさらに、例示のドライバプログラム５０８を含む、１つ以上のドライバプログラムを実行中であり得る。ドライバプログラム５０８は、オペレーティングシステムのカーネル内で実行中であり得る。カーネル内で動作することにより、物理メモリ及びホストデバイスのハードウェアへのアクセスを含む、さらなるアクセス権限がドライバプログラムに提供され得る。代替的または追加的には、ドライバプログラム５０８はユーザ空間で実行中であり得、ユーザ空間ではより少ないアクセス権限を有する可能性があり、安全性が低い可能性がある。
ネットワークアダプタデバイス５２０は、ネットワークと通信するための汎用ネットワークインタフェースカードであり得る。代替的または追加的には、ネットワークアダプタデバイス５２０は、特定のタイプのネットワーク（例えば、ＩｎｆｉｎｉＢａｎｄネットワーク）と通信するための専用カードであり得る。ネットワークアダプタデバイス５２０は、管理モジュール５２２を含み得る。管理モジュール５２２は、例えば、ファームウェアまたはＦＰＧＡもしくはＡＳＩＣなどの集積回路であり得る。ネットワークアダプタデバイス５２０はさらに、ネットワークアダプタデバイス５２０の動作に関連するデータを格納するためのメモリを含み得る。代替的または追加的には、管理モジュール５２２にメモリを統合してよい。いくつかの実装では、ネットワークアダプタデバイス５２０はＲＤＭＡタイプの機能性（つまり、カーネルバイパス機能性）を含み得る。いくつかの実装では、ネットワークアダプタデバイス５２０は、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）タイプのデバイスであり、ＰＣＩバス上でホストデバイス５２０と通信する。いくつかの実装では、以下に説明するネットワークアダプタデバイス４２０の動作は、集積回路デバイスまたは集積回路デバイスの集合体で実施され得る。例えば、様々な実装では、ネットワークアダプタデバイスの動作は、ＳｏＣ、ＦＰＧＡまたはＡＳＩＣあるいはこれらのデバイスの組み合わせで実装され得る。
宛先ノードと通信するためのアドレスハンドルを取得するために、ユーザアプリケーション５０４ａは、まず宛先のアドレスを決定する。宛先は、ほとんどの場合、ネットワークに接続された別のシステム上で実行中のアプリケーションである。宛先のアドレスは、ネットワーク上のシステムのインターネットプロトコル（ＩＰ）または媒体アクセス制御（ＭＡＣ）アドレスなどの一般的なアドレスであり得る。代替的または追加的には、宛先アドレスは、特定のターゲットアプリケーションを識別するアドレスなど、特定のものであり得る。代替的または追加的には、宛先アドレスは、一般的なアドレスと特定のアドレスとの中間に該当し得る。
ユーザアプリケーション５０４ａは、標準的なメカニズムを使用して宛先アドレスを取得し得る。例えば、いくつかの実装では、ユーザアプリケーション５０４ａは、ユーザが提供する入力から、及び／または、ドメインネームシステム（ＤＮＳ）サーバによって提供されるなどの標準的なアドレス解決メカニズムによって、宛先アドレスを取得し得る。いくつかの実装では、ユーザアプリケーション５０４ａは、ターゲットアプリケーションとメッセージを交換することによって宛先アドレスを取得し得る。例えば、ユーザアプリケーション５０４ａは、ネットワーク上で動作中の標準ソケットシステムを使用し、それ自体のアドレスをターゲットアプリケーションのアドレスと交換し得る。別の例として、ユーザアプリケーション５０４ａは、指定または専用のサイドバンドネットワークを使用して、この情報を交換し得る。いくつかの実装では、ユーザアプリケーション５０４ａが宛先アドレスを解明する方式は、特定のアプリケーションに固有である。
宛先アドレスを決定すると、ユーザアプリケーション５０４ａは、アドレスハンドルの要求５５０をドライバプログラム５０８に送信し得る。この要求５５０は、少なくとも宛先アドレスを含み得る。いくつかの実装では、ドライバプログラム５０８は、ホストデバイス５０２上で実行中の全てのプロセスのアドレスハンドルを一括管理するように構成され得るカーネルドライバプログラムである。他の実装では、ドライバプログラム５０８は、通常はデバイスドライバで利用可能な標準的なアクセス権限を備えた、ユーザ空間デバイスドライバである。いくつかの実装では、要求５５０はまずデバイスドライバに行き、次いでカーネルドライバに行き得る。他の実装では、要求５５０は、ユーザアプリケーション５０４ａからカーネルドライバに直接行き得る。
ドライバプログラム５０８は、ステップ５５２において、アドレスハンドル要求５５０の宛先アドレスが「新しい」かどうか、つまり、ドライバプログラム５０８がこの宛先アドレスを以前に登録しているかどうかを判断し得る。ドライバプログラム５０８は、ホストデバイス５０２上で実行中のプロセスによって現在使用されている宛先アドレスのリストまたはディレクトリ（一般的に「アドレスマップ」５１４と呼ばれる）を保持し得る。いくつかの実装では、アドレスマップ５１４は、ネットワークアダプタデバイス５２０によって保持され得る。ドライバプログラム５０８は、アドレスハンドル要求５５０を受信すると、要求が宛先アドレスを含むかどうかを調査するためにアドレスマップ５１４を検証し得る。図５Ａの例では、ドライバプログラム５０８は、アドレスマップ５１４に宛先アドレスを発見することができず、ゆえに宛先アドレスが新しいと判断する。
宛先アドレスが新しいと判断すると、ドライバプログラム５０８は、ネットワークアダプタデバイス５２０上で実行中の管理モジュール５２２に、新しいアドレスハンドルの要求５５４を発行し得る。この新しいアドレスハンドル要求５５４は宛先アドレスを含み得る。管理モジュール５２２は、例えば、ユーザアプリケーション５０４ａ（またはユーザアプリケーション５０４ａを実行中の仮想マシン）が、ターゲットアプリケーションが発見され得るシステムと通信することが許可されていることを確認するなど、宛先アドレスのチェックを実行し得る。管理モジュール５２２は、次いで、ネットワークアダプタデバイス５２０上のメモリ５２８に宛先アドレスを格納し得る。
いくつかの実装では、管理モジュール５２２は、ネットワークアドレスマップオブジェクト５５６をメモリ５２８に格納し得る。ネットワークアドレスマップオブジェクトは、宛先アドレスに関連する情報を格納し得るデータ構造のインスタンスである。例えば、ネットワークアドレスマップオブジェクト５５６は、宛先アドレスを含み得る。いくつかの実装では、ネットワークアドレスマップオブジェクト５５６は、管理モジュール５２２によって生成された事前生成パケットヘッダを含み得る。事前生成パケットヘッダは、送信元アドレス及び宛先アドレス、及び／またはパケットがネットワークを通過して宛先システムに向かうのに必要となり得るルーティング情報、及び／または他のヘッダ情報を含み得る。事前生成パケットヘッダは、後にパケットを迅速に形成する際に使用するために格納され得る。いくつかの実装では、ネットワークアドレスマップオブジェクトは事前生成された内部及び外部ヘッダを含み得る。内部及び外部ヘッダは、１つのプロトコルに従って生成されたパケットが、別のプロトコルのためにヘッダにカプセル化されている場合に使用され得る。カプセル化は、ネットワークトンネリング、つまり、異なるネットワークプロトコル用に構成されたネットワーク上で１つのプロトコルに従って構成されたパケットを送信するときに生じ得る。パケットをカプセル化して外部ヘッダを提供することにより、外部ネットワークプロトコルに対応するように内部ヘッダを変更する必要はない。事前生成された内部及び外部ヘッダは、ネットワークアドレスマップオブジェクトと共に格納されてよい。
宛先アドレスが新しいため、管理モジュールは、追加的または代替的には、トランスポートコンテキスト５２４を構成し得る。トランスポートコンテキスト５２４は、宛先アドレスに関連するシステムとの接続を確立して保持する。トランスポートコンテキストは、ネットワークに接続されたそれぞれの潜在的な宛先システムに対して構成され得るが、一般的にトランスポートコンテキストは必要になるまで構成されない。トランスポートコンテキストは、ほとんどの実装において、２つのアプリケーション間またはアプリケーションとシステムとの間というよりは、２つのシステム間の接続を表す。トランスポートコンテキスト５２４を構成することは、宛先システムとの接続を確立することを含み得る。この接続は、例えば、ネットワークアダプタデバイス５２０と宛先システムとの間のメッセージの交換によって確立され得る。一旦構成されると、トランスポートコンテキスト５２４は、接続の状態を監視して保持し得る。接続の保持は、とりわけ、宛先システムに関連するネットワークアドレスマップオブジェクトを格納するか、あるいは別様には追跡することを含み得る。上記の通り、宛先アドレスは宛先システムのアドレスよりも固有であり得、したがって、所与のトランスポートコンテキストに対して２つ以上のネットワークアドレスマップオブジェクトが存在し得る。トランスポートコンテキスト５２４には、信頼不可能なデータグラムまたは緩和された信頼可能なデータグラムなどのトランスポートサービスタイプが割り当てられ得る。トランスポートコンテキストは以下でさらに詳細に説明される。
宛先アドレスまたはネットワークアドレスマップオブジェクト５５６を格納し、及び／またはトランスポートコンテキスト５２４を構成した後、管理モジュール５２２は、次に、アドレスハンドル５５８をドライバプログラム５０８に返送し得る。アドレスハンドル５５８は、宛先アドレスまたはネットワークアダプタデバイス５２０のメモリ５２８に格納されたネットワークアドレスマップオブジェクト５５６を参照する参照先、ポインタ及び／またはインデックスであり得る。ドライバプログラム５０８は、宛先アドレスによって発見され得るドライバプログラム５０８のアドレスマップ５１４に、アドレスハンドル５５８を格納し得る。いくつかの実装では、ネットワークアダプタデバイス５２０は、アドレスマップ５１４を管理してよく、この場合、管理モジュール５２２は、アドレスマップ５１４にアドレスハンドルを格納してよい。ドライバプログラム５０８が宛先アドレスを認識しているため、ここで宛先アドレスは「登録された」と考えられ得る。ドライバプログラム５０８は次に、アドレスハンドル５５８をユーザアプリケーション５０４ａに送信し得る。ユーザアプリケーション５０４ａは、ほとんどの場合、後の使用のためにアドレスハンドル５５８を格納するか、別様には保持し得る。
前に記した通り、図５Ａは、ドライバプログラム５０８にまだ登録されていない宛先のアドレスハンドルを、ユーザアプリケーション５０４ａが要求した場合を例示する。図５Ｂは、ドライバプログラム５０８に既に登録されている宛先アドレスのアドレスハンドルを、ユーザアプリケーション５０４ｂが要求する例を例示する。図５Ａと同様に、図５Ｂでは、ユーザアプリケーション５０４ｂはまず、ユーザアプリケーション５０４ｂが通信しようとする宛先の宛先アドレスを決定し得る。ユーザアプリケーション５０４ｂは、図５Ａに例示するのと同じユーザアプリケーション５０４ａであり得るか、または同じホストデバイス５０２上で実行中の異なるユーザアプリケーションであり得る。
図５Ｂに戻ると、宛先アドレスを決定すると、ユーザアプリケーション５０４ｂは、ドライバプログラム５０８にアドレスハンドルの要求５５０を送信し得る。この例では、ドライバプログラム５０８は、ステップ５５２において、要求５５０で送信された宛先アドレスを検証してよく、宛先アドレスが宛先マップ５１４に発見されると判断してよい。これは、宛先アドレスがドライバプログラム５０８に既に登録されていることを意味する。これは、さらに、図５Ａの場合のように、アドレスハンドルを提供するためにネットワークアダプタデバイス５２０にアクセスする必要がないことを意味し得る。いくつかの実装では、アドレスマップ５１４はネットワークアダプタデバイス５２０によって保持され、この場合、ドライバプログラム５０８は、ネットワークアドレスマップ５２０に宛先アドレスを検索するように求め得る。これらの実装では、ネットワークアダプタデバイス５２０は、宛先アドレスが以前に登録されていると判断し、アドレスハンドル５５８をドライバプログラム５０８に提供し得る。
図５Ｂでは、宛先アドレスが以前に登録されていると判断されると、ドライバプログラム５０８は、次いで、アドレスマップ５１４に格納された情報を使用してアドレスハンドル５５８を提供し得る。例えば、アドレスマップ５１４は、参照先、ポインタ及び／またはインデックスを格納してよく、ドライバプログラム５０８は、格納された参照先、ポインタまたはインデックスを参照する新しいアドレスハンドル５５８を生成してよい。アドレスハンドル５５８はユーザアプリケーション５０４ｂに返送されてよく、ユーザアプリケーション５０４ｂはアドレスハンドル５５８をその後の使用のために格納し得る。
図６Ａ〜６Ｂは、ユーザアプリケーション６０４が、図５Ａ〜５Ｂに従って取得したアドレスハンドル６５８を使用してメッセージを送信し得るプロセス６００の一例を例示する。いくつかの実装では、ユーザアプリケーション６０４はアドレスハンドル６５８を使用できず、その代わりに他の宛先情報を使用してメッセージを送信し得る。これらの実装は、以下でさらに詳細に説明される。
図６Ａ〜図６Ｂでは、プロセス６００は、ホストデバイス６０２及びネットワークアダプタデバイス６２０を伴い得る。ホストデバイス６０２は、図面には例示していないが、１つ以上のプロセッサ、メモリサブシステム、周辺装置及びその他などの構成要素を含む、汎用コンピューティングシステムであり得る。ホストデバイス６０２は、例示のユーザアプリケーション６０４を含む、１つ以上のユーザアプリケーションを実行中であり得る。ネットワークアダプタデバイス６２０は、ネットワーク６３０と通信するための汎用ネットワークインタフェースカード及び／または特定のタイプのネットワークと通信するための専用カードであり得る。いくつかの実装では、ネットワークアダプタデバイスの動作は、集積回路デバイス及び／または集積回路デバイスの集合体で実施され得る。ネットワークアダプタデバイス６２０はさらにメモリ６２８を含み得るが、いくつかの実装では、メモリ６２８は、ネットワークアダプタデバイス６２０にインストールされたファームウェア（図示せず）に組み込まれる。いくつかの実装では、ネットワークアダプタデバイス６２０はメモリを有さないか、または少量のメモリしか有さず、情報を格納するためにホストデバイス６０２上のメモリを使用し得る。
図６Ａでは、ユーザアプリケーション６０４は、ネットワーク上の異なるシステム上で動作中の別のアプリケーションに送信しようとするメッセージ６６０を有し得る。この例では、ユーザアプリケーション６０４は、ターゲットアプリケーションに関連するアドレスハンドル６５８を以前に取得している。メッセージ６６０をターゲットアプリケーションに送信するために、ユーザアプリケーション６０４は、アドレスハンドル６５８と共にメッセージ６６０をネットワークアダプタデバイス６２０に送信し得る。いくつかの実装では、メッセージ６６０はまず、ネットワークアダプタデバイス６２０に送信される前に、デバイスドライバに送信され得る。
メッセージ６６０を受信すると、ネットワークアダプタデバイス６２０は、アドレスハンドルを使用して、メッセージ６６０のトランスポートコンテキスト６２４を決定し得る。トランスポートコンテキスト６２４は、一般的に、メッセージ６６０を受信するシステムとの接続を保持する。接続の保持は、例えば、パケットの送信、未処理パケットの状態の追跡、ならびに以下でさらに詳細に説明する、ターゲットシステムまでのネットワークを通る経路の設定及び解除を含み得る。
トランスポートコンテキスト６２４はさらに、現在のアドレスハンドルに関連するネットワークアドレスマップオブジェクト６５６など、メモリ６２８に格納された宛先関連情報を追跡し得る。ネットワークアドレスマップオブジェクト６５６は、メッセージ６６０のパケットを生成するための情報を提供し得る。例えば、ネットワークアドレスマップオブジェクト６５６は、宛先アドレス（例えば、ターゲットシステムのＩＰアドレスもしくはＭＡＣアドレスまたはターゲットアプリケーションのアドレス）を含み得る。代替的または追加的には、ネットワークアドレスマップオブジェクト６５６は、パケットがターゲットシステムに到達するために必要なアドレス指定情報及び／またはルーティング情報を含む事前生成ヘッダを含み得る。いくつかの実装では、ネットワークアダプタデバイス６２０はメモリを有することができない、または宛先関連情報などのデータを格納するためにホストデバイス６０２上のメモリを使用してよい。これらの実装では、トランスポートコンテキスト６２４がネットワークアドレスマップオブジェクト６５６を検索するとき、トランスポートコンテキスト６２４はホストデバイス６０２のメモリからネットワークアドレスマップオブジェクト６５６を読み取る要求をホストデバイス６０２に発行し得る。
ネットワークアドレスマップオブジェクト６５６など、メモリ６５６に格納される宛先関連情報を使用して、ネットワークアダプタデバイスは、メッセージ６６０の全てまたは一部を包含する、１つ以上のパケット６６２を生成し得る。ネットワークアドレスマップオブジェクト６５６が事前生成パケットヘッダを提供する実装では、パケット６６２は、事前生成パケットヘッダをペイロードの先頭に追加することによって生成されてよく、ペイロードはメッセージ６６０のデータを含む。１つ以上のパケット６６２を生成した後、ネットワークアダプタ６２０は、次いで、ネットワーク６３０上で１つ以上のパケットを送信し得る。
いくつかの場合、ターゲットアプリケーションは、メッセージ６６０に応答することが求められる。例えば、メッセージ６６０が読み取りトランザクションであり、ターゲットアプリケーションが有するいくつかの情報を要求している場合、ターゲットアプリケーションは読み取りデータに応答することが求められ得る。別の例として、メッセージ６６０は、１つ以上の動作を実行してこれらの動作の結果を返送するため、ターゲットアプリケーションに対するコマンドであり得る。
図６Ｂは、図６Ａに従って送信されたメッセージ６６０に応答して送信された応答６６４の受信の一例を例示する。図６Ｂでは、応答６６４は、ネットワーク６３０上でネットワークアダプタデバイス６２０によってパケットの形態で受信され得る。ネットワークアダプタデバイス６２０は、ホストデバイス６０２上で実行中のユーザアプリケーションによって送信されたメッセージに応答して送信された多数の応答を受信し得る。ネットワークアダプタデバイス６２０及び／またはホストデバイス６０２は、ゆえに、どのユーザアプリケーションが所与の応答６６４を受信すべきかを識別し得る。パケットヘッダは、応答６６４の送信元（例えば、リモートサーバ及び／またはリモートアプリケーションのアドレス）及び応答の宛先（例えば、ローカルサーバ及び／またはユーザアプリケーション６０４）を識別する情報を含み得る。パケットペイロードは、応答６６４のデータを含み得る。
応答６６４は、応答６６４を送信したシステム用に構成され得るトランスポートコンテキスト６２４によって受信され得る。トランスポートコンテキスト６２４を使用して、ネットワークアダプタデバイスは、ネットワーク６３０上で受信したパケットから応答６６４のデータを解凍し得る。いくつかの場合、ネットワークアダプタデバイス６２０は、ネットワーク６３０上で受信した複数の応答パケットから応答メッセージを構築し得る。ネットワークアダプタデバイス６２０はさらに、応答６６４から、送信元アドレス、つまり、応答６６４を送信したシステム及び／またはプロセスのアドレスを抽出し得る。この例では、送信元アドレスは、図６Ａのメッセージ６６０を送信するために使用された宛先アドレスと同じである。いくつかの実装では、応答６６４は、応答の送信元及び／または応答６６４が対応するメッセージ６６０のいずれかを識別するいくつかの他の情報を含み得る。
図６Ｂに戻ると、ネットワークアダプタデバイス６２０は、送信元アドレス（または応答６６４を識別する他の情報）を使用して、送信者アドレスに対応するネットワークアドレスマップオブジェクト６５６をメモリ６２８に配置し得る。ネットワークアドレスマップオブジェクト６５６は、メッセージ６６０を送信するために使用されたアドレスハンドルを提供し得る。このアドレスハンドルは、メッセージ６６０を送信したユーザアプリケーション６０４を識別し得る。アドレスハンドルは、応答６６４と共に、ホストデバイスに提供されてよく、ホストデバイス６０２は、（例えば、ドライバプログラムを使用して）応答メッセージ６６６をユーザアプリケーション６０４に送り得る。代替的には、いくつかの実装では、応答メッセージ６６６は、アドレスハンドルではなく、ネットワークからの応答６６４に付随していた送信元アドレスと共にホストデバイス６０２に提供され得る。ホストデバイスは次いで、代わりに、送信元アドレスを使用して、応答メッセージ６６６をユーザアプリケーション６０４に送ることができる。
ユーザアプリケーション６０４は、アドレスハンドルを使用して、応答メッセージ６６６がどこから来たか、及び／または応答メッセージ６６６がどのメッセージに応答しているかを判断し得る。前に記した通り、アドレスハンドルは、最初のメッセージ６６０が送信されたときに使用されたアドレスハンドルと同じであってよく、この場合、ユーザアプリケーション６０４は、単純な検索メカニズムを使用して、応答メッセージ６６６がどのメッセージに対するものかを判断することができ得る。いくつかの場合、ユーザアプリケーション６０４は、例えば、メッセージ６６０の全てまたは一部を再送するか、または宛先との新しい通信を開始するなど、応答メッセージ６６６に応答し得る。
上記の通り、いくつかの実装では、ユーザアプリケーション６０４は、アドレスハンドル以外のアドレス情報を使用してメッセージを送信し得る。これらの実装では、ユーザアプリケーション６０４は、図６Ａ〜図６Ｂに例示するプロセス６００と同様のプロセスを使用し得る。例えば、図６Ａでは、ユーザアプリケーション６０４は、ネットワーク上の異なるシステム上で動作中の別のアプリケーションに送信するためのメッセージを有し得る。この例では、ユーザアプリケーション６０４は宛先アプリケーションに対するアドレスハンドルを有さないが、アドレスハンドルを取得するために使用する宛先情報を有し得る。例えば、ユーザアプリケーション６０４は、（例えば）ＩＰアドレス及び／またはＭＡＣアドレスの形態で、宛先システムに対するネットワークアドレスを有し得る。別の例として、ユーザアプリケーションはフロー識別子を有し得る。フローは、通常は互いに関連しており、システムと別のシステムとの間を移動するパケットの流れを表す。フロー識別子は、同じフローに属するパケットを識別し得る。フロー識別子は、パケットのヘッダに含まれ得る値の形態をとり得る。代替的または追加的には、フローは、送信元システムのアドレス、宛先システムのアドレス、パケットが送信される送信元システムのポート及び／またはパケットが受信される宛先システムのポートなど、ネットワークアドレスによって識別され得る。いくつかの場合、フロー識別子は、送信元及び宛先及び／またはポートを入力として使用する数学演算の結果である。
ユーザアプリケーション６０４は、ゆえに、宛先情報を使用してメッセージ６６０を送信し得る。ユーザアプリケーション６０４は、宛先情報と共にメッセージ６６０をネットワークアダプタデバイス６２０に送信し得る。ネットワークアダプタデバイス６２０は、適切なトランスポートコンテキスト６２４を決定するために宛先情報を使用し得る。例えば、ネットワークアダプタデバイス６２０は、ネットワークアドレスまたはフロー識別子を使用してトランスポートコンテキスト６２４を検索するように構成され得る。一旦ネットワークアダプタデバイス６２０がトランスポートコンテキスト６２４を決定すると、ネットワークアダプタデバイス６２０は、トランスポートコンテキスト６２４を使用して、パケットの生成及びネットワーク６３０への送信を行い得る。
図５Ａ〜図５Ｂ及び図６Ａ〜図６Ｂに例示するようなコネクションレス型のメッセージ転送プロセス５００、６００を使用するように構成される計算クラスタは、ネットワークアドレスをより効率的に管理する可能性があり、メモリ要求がより少なくなる可能性があり、拡張性をより高める可能性がある。
コネクションレス型のメッセージ転送で提供されるアドレスハンドルは、ホストデバイスにおけるアドレス管理を簡略化し得る。コネクションレス型のメッセージ転送方法を使用しない実装では、ホストデバイス上で実行中のソフトウェアにアドレス管理の負担の多くが課せられ得る。例えば、ユーザアプリケーションまたはドライバプログラムはパケットヘッダを生成する必要があり、送信元及び宛先情報の追跡を必要し得る。別の例として、応答が受信されると、ドライバプログラムまたはユーザアプリケーションは、応答の送信元及び宛先を識別するためにパケットヘッダ全体を読み取る必要があり得る。対照的に、コネクションレス型のメッセージ転送方法を使用する実装では、一旦宛先アドレスが登録されると、ユーザアプリケーション及びドライバプログラムは、宛先を参照するためのアドレスハンドルのみの使用を必要とする。さらに、ホストデバイス６０２によって応答が受信されると、応答はそのアドレスハンドルによって迅速に識別することができる。
アドレスハンドルはさらに、あるシステム上で実行中の多数のプロセスが異なるシステム上で実行中の多数のプロセスと通信しているときに、必要なメモリ量を削減し得る。ユーザアプリケーションが通信しようとする各宛先に対して、ユーザアプリケーションは、個別のアドレスハンドルを取得して保持し得る。ただし、全てのユーザアプリケーションが宛先と通信している可能性があるため、各宛先に対して、１つのみのネットワークアドレスマップオブジェクトを作成して格納する必要がある。ネットワークアダプタでのメモリ使用は、ゆえに、最小化され得る。いくつかの実装では、ドライバプログラムは、アドレスハンドルを取得するためにホストデバイス上で実行中の全てのプロセスによって使用され得るアドレスマップを保持し得るため、ドライバプログラムに必要なメモリがさらに最小化され得る。追加的には、一旦宛先アドレスがドライバプログラムに登録されると、同じ宛先と通信するために行われる他のユーザアプリケーションへのアドレスハンドルの提供は、ネットワークアダプタデバイスとの通信を必要とすることなく迅速に行われ得る。
コネクションレス型のメッセージ転送はさらに、より高い拡張性を有するコンピューティングクラスタを提供し得る。上記の通り、接続型のトランスポートサービスタイプで発生し得る問題の１つは、ネットワークを通じて通信しようとするプロセスの数が増加するにつれ、接続数も増加するということである。対照的に、コネクションレス型のメッセージ転送方法を使用する実装では、ユーザアプリケーションは接続を確立する必要はなく、代わりにアドレスハンドルを取得する。ネットワークアダプタデバイスは他のシステムとの接続を確立するが、ほとんどの場合、ネットワーク上の任意の２つのシステム間で１つの接続しか確立されない。１つのシステムからの全てのトラフィックは、次いで、単独接続を使用して他のシステムに到達し得る。ゆえに、プロセスの数が増加しても接続数が増加する可能性は低く、クラスタに追加されるノードが増加した場合にのみ接続数は増加する。
ＩＩ．信頼可能な順不同のパケット配信
上述の通り、「コネクションレス型」のメッセージ転送は、緩和された信頼可能なデータグラムトランスポートサービスによって促進され得る。このセクションでは、メッセージの処理方法、ネットワークとの通信の管理方法、信頼可能な配信の提供メカニズムを含む、緩和された信頼可能なデータグラムトランスポートを使用したメッセージ転送の管理について詳細に説明する。パケットが順不同で到着し得る方法及び理由についても説明する。
図７Ａ〜７Ｂは、緩和された信頼可能なデータグラムトランスポートサービスを含むシステムに対して実装され得る通信スタック７００の一例を例示する。図７Ａは、通信スタックの送信側の一例を例示し、図７Ｂは、通信スタックの受信側の一例を例示する。これらの例では、接続は、例えば、図５Ａ〜図５Ｂに関して説明したプロセス５００を使用して、以前に確立されている場合がある。例えば、図７Ａ〜図７Ｂでは、（この例によれば）各送信側トランスポートコンテキスト７１６ａ〜ｂが、対応する受信側トランスポートコンテキスト７６８ａ〜ｂとの接続を管理した状態で、１つ以上の送信側トランスポートコンテキスト７１６ａ〜ｂ及び受信側トランスポートコンテキスト７６８ａ〜ｂが構成されている場合がある。図７Ａ〜図７Ｂの例では、１つのシステムを送信システムとして例示し、別のシステムを受信システムとして例示しているが、便宜上、「送信」及び「受信」という分類を割り当てているにすぎない。さらに、ここで受信側システムと呼ばれるシステムは送信システムとしても機能することができ、ここで送信システムと呼ばれるシステムは受信システムとして機能することが理解される。
図７Ａの例では、通信スタック７００の例の送信側が例示されている。この例では、通信スタックの送信側は、２つのユーザアプリケーション７０４ａ〜ｂ、いくつかのキューペア７１０ａ〜ｄ及びネットワーク７３０上で１つ以上の宛先システム７１８ａ〜ｂと通信している１つ以上の送信側トランスポートコンテキスト７１６ａ〜ｂを含む。図７Ａに例示する例は、簡潔にするために２つのユーザアプリケーション７０４ａ〜ｂを表しており、例示の仮想マシン７０２及び／または仮想マシン７０２をホストしているシステムはより多数またはより少数のユーザアプリケーションを有することがあり、それぞれが類似する通信スタックを使用するように構成されることが理解される。
この例では、ユーザアプリケーション７０４ａ〜ｂは、ホストデバイスに対して構成された仮想マシン７０２内で実行中であり得る。各ユーザアプリケーション７０４ａ〜ｂは、ＯＦＥＤタイプのｖｅｒｂｓライブラリなどの標準ライブラリ７０６ａ〜ｂを使用して、ネットワーク７３０と通信し得る。いくつかの実装では、各ユーザアプリケーション７０４ａ〜ｂは、異なる標準ライブラリ７０６ａ〜ｂを使用中であり得る。標準ライブラリ７０６ａ〜ｂは、メッセージを送信するための「ポスト送信」、メッセージを受信するための「ポスト受信」及び完了キューのコンテンツをチェックするための「ポーリング」など、ネットワークコマンドの共通セットを提供し得る。標準ライブラリ７０６ａ〜ｂはさらに、ドライバプログラム７０８ａ〜ｂへのインタフェースを提供し得る。ドライバプログラム７０８ａ〜ｂは、仮想マシン７０２のオペレーティングシステムのカーネル及び／またはネットワークアダプタデバイスを含むシステムのハードウェアと相互作用するためのコマンドを提供し得る。ドライバプログラム７０８ａ〜ｂはカーネルドライバであってよく、この場合、ドライバプログラム７０８ａ〜ｂはより高いアクセス権限を有してよい。代替的には、ドライバプログラム７０８ａは、ユーザ空間ドライバであってよく、より低いアクセス権限を有してよい。いくつかの実装では、各ユーザアプリケーション７０４ａ〜ｂは、異なるドライバプログラム７０８ａ〜ｂを使用中であり得る。他の実装では、両方のユーザアプリケーション７０４ａ〜ｂは同じドライバプログラム７０８ａ〜ｂを使用中であり得る。いくつかの実装では、ユーザアプリケーション７０４ａ〜ｂは、標準ライブラリ７０６ａ〜ｂを介すことなく、ドライバプログラム７０８ａ〜ｂと直接通信し得る。
ネットワーク７３０と通信するために、各ユーザアプリケーション７０４ａ〜ｂは１つ以上の「通信エンドポイント」を割り当てられ得る。通信エンドポイントは、ユーザアプリケーション７０４ａ〜ｂとの論理的な関連を表し、ユーザアプリケーション７０４ａ〜ｂによって送信されたメッセージ内のユーザアプリケーション７０４ａ〜ｂを識別するために使用され得る。つまり、通信エンドポイントの識別子は、少なくとも部分的に、メッセージの送信者アドレスとして使用され得る。通信エンドポイントは異なる方法で実装され得る。例えば、いくつかの実装では、通信スタック７００の例では、通信エンドポイントは、それぞれ、キューペア７１０ａ〜ｄにマッピングされる。これらの実装では、通信エンドポイントは、通常は番号であるキューペア識別子によって識別され得る。さらに、これらの実装では、キューペア識別子は、少なくとも部分的に、ユーザアプリケーション７０４ａ〜ｂによって送信されたメッセージの送信者アドレスとして使用され得る。ユーザアプリケーション７０４ａ〜ｂに割り当てられた通信エンドポイントは、ドライバプログラム７０８ａ〜ｂによって保持され得る。通信エンドポイントは、ほとんどの場合、ユーザアプリケーション間では共有されない。
仮想マシン７０２自体には、ネットワーク７３０と通信するための１つ以上の仮想インタフェース７０９ａ〜ｂが割り当てられ得る。これらの仮想インタフェース７０９ａ〜ｂは、例えば、仮想マシン７０２のオペレーティングシステムまたはホストデバイスのオペレーティングシステムによって、仮想マシン７０２に割り当てられていることがある。各仮想インタフェース７０９ａ〜ｂにはＩＰアドレスが割り当てられ得る。ネットワーク７３０と通信するために、ユーザアプリケーション７０４ａ〜ｂは、仮想インタフェース７０９ａ〜ｂのうちの１つ以上を使用し得る。ゆえに、ユーザアプリケーション７０４ａ〜ｂによって送信されたメッセージは、例えば、２つの利用可能な仮想インタフェース７０９ａのうちの１つを使用して、その仮想インタフェースのＩＰアドレスをメッセージの送信者アドレスとして有し得る。いくつかの実装では、ユーザアプリケーション７０４ａ〜ｂは、ゆえに、この仮想インタフェース７０９ａのＩＰアドレスによって識別され得る。
ユーザアプリケーション７０４ａ〜ｂがそれ自体を仮想マシン７０２のオペレーティングシステムのカーネルに登録したとき、及び／またはユーザアプリケーション７０４ａ〜ｂがキューペア７１０ａ〜ｄへの割り当てを要求したとき、及び／またはユーザアプリケーション７０４ａ〜ｂが宛先システム７１８ａ〜ｂとの通信のために最初に登録されたときに、仮想インタフェース７０９ａ〜ｂはユーザアプリケーション７０４ａ〜ｂに割り当てられることがある。いくつかの実装では、２つ以上のユーザアプリケーション７０４ａ〜ｂは所与の仮想インタフェース７０９ａ〜ｂを使用し得る。例えば、図７Ａの例では、第１のユーザアプリケーション７０４ａと第２のユーザアプリケーション７０４ｂとの両方が第２の仮想インタフェース７０９ｂに割り当てられている。
これらの実装及びその他の実装では、ユーザアプリケーション７０４ａ〜ｂは、通信エンドポイントと１つ以上の仮想インタフェース７０９ａ〜ｂとの両方を使用してネットワーク７３０と通信し得る。これらの実装では、ユーザアプリケーション７０４ａ〜ｂは、通信エンドポイントの識別子（例えば、キューペア番号）と仮想インタフェース７０９ａ〜ｂのＩＰアドレスとの組み合わせによって識別され得る。さらに、仮想インタフェース７０９ａ〜ｂのＩＰアドレスと通信エンドポイントの識別子との組み合わせを、ユーザアプリケーション７０４ａ〜ｂによって送信されたメッセージの送信者アドレスとして使用してよい。
上記の通り、（緩和された信頼可能なデータグラムトランスポートを使用する実装を含む）いくつかの実装では、各通信エンドポイントは、個々のキューペア７１０ａ〜ｄにマッピングされ得る。キューペアは、一般的に、ネットワークに送信されるメッセージのための送信キュー７１２及びネットワーク７３０から入ってくるメッセージを受信するための受信キュー７１４を含む。いくつかの実装では、ユーザアプリケーション７０４ａ〜ｂに割り当てられる各通信エンドポイントは、異なるキューペア７１０ａ〜ｄに割り当てられ得る。他の実装では、通信エンドポイント間でキューペアを共有してよいが、これらの実装では、各通信エンドポイントが一意にアドレス指定されて及び識別されることを確実にするよう、制限及び／または追加パラメータを構成に追加する必要があり得る。
多くの場合、キューペア７１０ａ〜ｄは、ネットワークアダプタデバイス上のハードウェアに実装されてよいが、いくつかの場合、キューペア７１０ａ〜ｄはネットワークアダプタデバイス上のソフトウェアに実装されてよく、及び／またはホストデバイス上のソフトウェアに実装されてよく、及び／またはホストデバイスのオペレーティングシステム及び／または仮想マシンを作成及び管理するハイパーバイザ層、ハードウェア層及び／またはソフトウェア層に存在してよい。いくつかの実装では、ネットワークアダプタデバイス（またはオペレーティングシステムまたはハイパーバイザ）は、キューペア７１０ａ〜ｄがユーザアプリケーション７０４ａ〜ｂ、ドライバプログラム７０８ａ〜ｂによって要求されるとき、またはユーザアプリケーション７０４ａ〜ｂがドライバプログラム７０８ａ〜ｂを通じて要求するときに、キューペア７１０ａ〜ｄを割り当て得る。いくつかの実装では、接続を設定または解除するためのメッセージ及びユーザアプリケーション間でそれらのそれぞれのアドレスを交換するために渡されるメッセージなどの、１つのキューペア（例えば、キューペア番号０または１）が通信管理メッセージのために確保され得る。
上記の通り、いくつかの実装では、キューペア７１０ａ〜ｄ（例えば、第１のキューペア７１０ａ）を、特定のユーザアプリケーション７０４ａ〜ｂ（例えば、第１のユーザアプリケーション７０４ａ）に関連する通信エンドポイントに割り当ててよい。しかしながら、キューペア７１０ａを特定の宛先に関連させる必要はなく、したがって、ネットワーク上の異なる宛先をターゲットとするメッセージをユーザアプリケーション７０４ａから受信してよい。
いくつかの実装では、各仮想インタフェース７０９ａ〜ｂに対するキューペア７１０ａ〜ｄの割り当てを追跡してよい。これにより、例えば、仮想マシン７０２の移行が容易になり得る。移行は、仮想マシン７０２を最初にシャットダウンするかどうかに関係なく、仮想マシン７０２を異なる物理システムに移行するプロセスである。仮想マシン７０２の移行後、通信エンドポイントは新しいキューペアに割り当てられてよいが、古いキューペア識別子が保持されているため、まだ移動中のパケットでもこれらの通信エンドポイントに到達することができる。
上述の通り、ユーザアプリケーション７０４ａ〜ｂは、ユーザアプリケーション７０４ａ〜ｂに割り当てられている通信エンドポイントの識別によって、ユーザアプリケーション７０４ａ〜ｂによって使用されている仮想インタフェース７０９ａ〜ｂのＩＰによって、または通信エンドポイントの識別と仮想インタフェース７０９ａ〜ｂのＩＰとの両方によってのいずれかで識別され得る。ターゲットユーザアプリケーション（例えば、図７Ｂに例示するユーザアプリケーション７５４）も同様の様式で識別され得る。
ここで図７Ａに例示する特定の例を参照すると、この例では、第１のユーザアプリケーション７０４ａは、３つの例示のキューペア７１０ａ〜ｃによって示されるように、少なくとも３つの通信エンドポイントで構成されている。さらに、第１のユーザアプリケーション７０４ａは、（第１のキューペア７１０ａとの通信を示す実線矢印７２０ａで示すように）１つの通信エンドポイントを１つの利用可能な仮想インタフェース７０９ａに関連させ、さらに（第２のキューペア７１０ｂ及び第３のキューペア７１０ｃのとの通信を示す破線矢印７２０ｂで示すように）２つの通信エンドポイントを第２の利用可能な仮想インタフェース７０９ｂに関連させている。さらなる例として、第２のユーザアプリケーション７０４ｂは、点線矢印７２６で示すように、第４のキューペア７１０ｄへの１つの通信エンドポイントで構成されている。さらに、第２のユーザアプリケーション７０４ｂは、この通信エンドポイントを第２の仮想インタフェース７０９ｂに関連させている。
この例では、第１のユーザアプリケーション７０４ａは、ネットワーク７３０上の宛先システム７１８ａに送信するためのメッセージを有し得る。その第１の通信エンドポイントを使用して、第１のユーザアプリケーション７０４ａは、メッセージの宛先システム７１８ａを識別する情報（例えば、アドレスハンドル）と共に、メッセージを、通信エンドポイントに関連する第１のキューペア７１０ａの送信キュー７１２に配置し得る。メッセージを送信キュー７１２に配置することは、通常、ホストデバイスプロセッサの支援を必要としない。追加的には、メッセージを送信キュー７１２に配置することはさらに、ほとんどの場合、ユーザアプリケーション７０４ａがキューペア７１０ａを排他的に使用するため、通常、キューペア７１０ａにアクセスするためのユーザアプリケーション７０４ａによる調整を必要としない。
いくつかの実装では、ネットワークアダプタデバイスはキューペア７１０ａ〜ｄを管理する。ネットワークアダプタデバイスは、キューペア７１０ａ〜ｄを適時に提供することを確実にし得る。代替的または追加的には、ネットワークアダプタデバイスは、各キューペア７１０ａ〜ｄに割り当てられた優先度、トラフィックタイプ及び／またはサービス品質保証に従って、キューペア７１０ａ〜ｄを提供し得る。
図７Ａの例を続けると、第１の送信キュー７１２が提供されるとき、ネットワークアダプタデバイスは、ユーザアプリケーション７０４ａによって送信キュー７１２に配置されたメッセージを（例えば、ファームウェアまたは集積回路を使用して）削除及び処理してよい。ネットワークアダプタは、メッセージと共に送信キュー７１２にプッシュされた宛先情報を検証し、適切なトランスポートコンテキスト７１６ａ〜ｂを識別し得る。前述の通り、トランスポートコンテキスト７１６ａ〜ｂはそれぞれ、ネットワーク上の宛先システム７１８ａ〜ｂとの接続を管理する。ほとんどの実装では、トランスポートコンテキスト７１６ａは、１つの送信元システムと１つの宛先システムとの間の接続を表し、特定のユーザアプリケーションまたはキューペアには関連していない。ゆえに、異なるユーザアプリケーションからのメッセージ及び／または異なる通信エンドポイントを通じて送信されたメッセージを、同じトランスポートコンテキスト７１６ａにマッピングし得る。反対に、１つのユーザアプリケーション７０４ａからのメッセージは、異なるトランスポートコンテキスト７１６ａ〜ｂに送られてよい。例えば、例示の例では、第１のユーザアプリケーション７０４ａにマッピングされた第１のキューペア７１０ａからのメッセージは、（実線矢印７２２ａで示すように）第１のトランスポートコンテキスト７１６ａと（破線矢印７２２ｂで示すように）第２のトランスポートコンテキスト７１６ｂとの両方に送られてよい。同様に、第２のユーザアプリケーション７０４ｂにマッピングされる第４のキューペア７１０ｄからのメッセージはさらに、（点線矢印７２８で示すように）両方のトランスポートコンテキスト７１６ａ〜ｂに送られてよい。キューペア７１０ａ〜ｄの各々はさらに、図面には例示しない追加のトランスポートコンテキストにメッセージを送ってよい。特定のメッセージのトランスポートコンテキスト７１６ａ〜ｂは、メッセージと共に提供される宛先情報によって識別されてよい。
いくつかの実装では、トランスポートコンテキスト７１６ａ〜ｂ（例えば、第２のトランスポートコンテキスト７１６ｂ）は、信頼可能な接続トランスポートと同様のトランスポートサービスを提供するように構成され得る。これらの実装では、トランスポートコンテキスト７１６ｂは、単一のキューペア（例えば、第２のキューペア７１０ｂ）に割り当てられ得る。受信側では、対応する受信側トランスポートコンテキスト７６８ｂはさらに、単一のキューペア（例えば、第２のキューペア７６０ｂ）に割り当てられる。トランスポートコンテキスト７１６ｂ、７６８ｂをそれぞれ単一のキューペアに割り当てることは、結果的に、トランスポートコンテキスト７１６ｂ、７６８ｂが信頼可能な接続トランスポートを提供している場合のように、送信ユーザアプリケーション７０４ａ及び受信ユーザアプリケーション７５４が互いに排他的な通信チャネルを有することになり得る。実際には、トランスポートコンテキスト７１６ｂ、７６８ｂは緩和された信頼可能なデータグラムトランスポートを提供していることがあり、これは正に信頼可能な接続と同様のパケット配信を保証し得る。
図７Ａの例を続けると、この例では、第１のトランスポートコンテキスト７１６ａが、第１の送信キュー７１２からポップされたメッセージのトランスポートコンテキストとして識別されている。いくつかの実装では、トランスポートコンテキスト７１６ａは事前生成パケットヘッダを提供し得る。事前生成パケットヘッダは、事前に定義された送信元及び宛先アドレス及び／または送信側から受信側にパケットをルーティングするために必要な他の情報を含み得る。いくつかの実装では、トランスポートコンテキスト７１６ａは、パケットがトンネリングされる状況に対して、事前生成された内部ヘッダ及び外部ヘッダを提供し得る。
前に記した通り、トランスポートコンテキスト７１６ａ〜ｂは、ネットワーク７３０上の対応する宛先システム７１８ａ〜ｂとの接続を管理し得る。通常、コンピューティングクラスタなどでは、送信側システムから受信側システムまで複数の経路７２４ａ〜ｂが利用可能であり得る。そのような状況では、トランスポートコンテキスト７１６ａ〜ｂは、ネットワーク７３０を通じて複数の利用可能な経路７２４ａ〜ｂを管理し得る。経路７２４ａ〜ｂの管理は、経路７２４ａ〜ｂの設定及び解除を含むことがあり、経路７２４ａ〜ｂが過度に混雑し、その経路にリンク障害が発生した場合には、経路７２４ａ〜ｂは解除されることがある。追加的には、トランスポートコンテキスト７１６ａ〜ｂはさらに、全ての利用可能な経路７２４ａ〜ｂを通じてパケットを送信しようする。これにより、ネットワークを通る負荷バランシング及び／または混雑した経路または障害のある経路に関する最新情報の保持を支援することを改善し得る。例えば、パケットが宛先システム７１８ａに到達しない場合、または宛先システム７１８ａに到達するのに長い時間がかかる場合には、混雑した経路または障害のある経路が検出され得る。ネットワークを通る複数の経路７２４ａ〜ｂの管理については、図８に関してさらに詳細に説明する。
図７Ａに例示された例を続けると、この例では、第１のトランスポートコンテキスト７１６ａは、ネットワーク７３０上の複数の経路７２４ａ上で第１のユーザアプリケーション７０４ａから宛先システム７１８ａにメッセージを送信し得る。いくつかの実装では、ネットワークアダプタデバイスは、トランスポートコンテキスト７１６ａを使用して、メッセージを含む１つのパケットを生成して送信し得る。いくつかの実装では、ネットワークアダプタデバイスは、それぞれがメッセージの一部を包含する複数のパケットを生成し得る。これらの複数のパケットはそれぞれ、宛先システム７１８ａに到達するために同じ経路または異なる経路をとり得る。いくつかの実装では、以下により詳細に説明するように、トランスポートコンテキスト７１６ａは、各パケットが宛先システム７１８ａに確実に配信されるように、各パケットの状態を監視し得る。
図７Ｂは、通信スタック７００の受信側を例示する。送信側と同様に、受信側は、ユーザアプリケーション７５４、１つ以上のキューペア７６０ａ〜ｂ及びネットワーク７３０上の対応する送信元システム７６６ａ〜ｂと通信する１つ以上の受信側トランスポートコンテキスト７７２ａ〜ｂを含む。図７Ｂで例示の例において、例示のユーザアプリケーション７５４は、少なくとも、図７Ａの送信側の例に例示する第１のユーザアプリケーション７０４ａと（必ずしも排他的ではなく）通信するように構成されている。ゆえに、図７Ｂで例示の例において、第１の送信元システム７６６ａは、図７Ａに例示する送信側システムに対応する。さらに、図７Ｂでは、トランスポートコンテキスト７６８ａは、送信元システム７６６ａと通信するように構成されており、送信元システム７６６ａでトランスポートコンテキスト７１６ａとの接続を管理し得る。同様に、第２の送信元システム７６６ｂはさらに、図７Ａに例示する送信側システムに対応するが、異なる送信側トランスポートコンテキスト７１６ｂに接続するように構成される。
図７Ｂはさらに、メッセージを送信及び受信するためにユーザアプリケーション７５４がバッファ７８２を構成し得る方法を例示する。例示されていないが、図７Ａの送信側ユーザアプリケーション７０４ａはさらに、必要な場合には、バッファを構成し得る。図７Ｂでは、ユーザアプリケーション７５４は、常にではないが通常、仮想マシン７５２内で実行中であり得る。いくつかの実装では、仮想マシン７５２は仮想メモリ７８０を提供してよく、仮想メモリ７８０では、ユーザアプリケーション７５４がバッファ７８２のための空間を割り当て得る。これらの実装では、バッファ７８２のアドレスは仮想であってよく、仮想マシン７５２の仮想アドレス空間に存在してよい。多くの場合、仮想アドレスは、オペレーティングシステムのカーネル（仮想マシンのオペレーティングシステムまたはホストデバイスのオペレーティングシステムのいずれか）及びネットワーク７３０へのアクセスを提供しているネットワークアダプタに登録され得る。カーネルに登録することにより、ゲスト物理アドレスへの仮想アドレスのマッピングが固定されることがあり、バッファ７８２を含む仮想ページがスワップアウトして何らかの非効率性を生み出すことを防止し得る。カーネルへの登録は、カーネルドライバを通じて行われてよく、仮想マシン７５２内またはホストシステム上のいずれかで実行される。カーネルドライバは、ネットワークアダプタデバイスに登録情報を渡してよく、ネットワークアダプタデバイスはメモリ登録キーを返送してよい。メモリ登録キーは、後続的に、ユーザアプリケーション７５４によって、バッファ７８２のアドレスと共にネットワークアダプタデバイスに渡されてよく、ユーザアプリケーションによって送信されるメッセージを伴う。登録キーを取得するこのプロセスは、ホストデバイスプロセッサからの支援を必要とすることなく、バッファ７８２に対する読み取り及び書き込みの権限アクセスをネットワークアダプタデバイスに直接的に提供し得る。
いくつかの実装では、ユーザアプリケーション７５４は、仮想メモリの代わりに、または仮想メモリに加えて、ホストデバイスの物理メモリにバッファ７８２を割り当て得る。これらの実装では、物理メモリにユーザアプリケーションのアクセスを付与することは、ユーザアプリケーション７５４を仮想メモリのみに限定することよりも安全性が低いため、ユーザアプリケーション７５４は特別な信頼状態を有し得る。
いくつかの実装では、ユーザアプリケーション７５４は、ネットワーク７３０と通信するために、ＯＦＥＤタイプのｖｅｒｂｓライブラリなどの標準ライブラリ７５６を使用し得る。標準ライブラリ７５６は、ドライバプログラム７０８ａへのインタフェースを提供し得る。ドライバプログラム７０８ａは、仮想マシン７５２のオペレーティングシステムのカーネル及び／またはネットワークアダプタデバイスを含む、システムのハードウェアと相互作用するためのコマンドを提供し得る。いくつかの実装では、ユーザアプリケーション７５４は、標準ライブラリ７５６を介することなく、ドライバプログラム７５８と直接通信し得る。
ネットワーク７３０と通信するために、この例のユーザアプリケーション７５４は、１つ以上の通信エンドポイントを割り当てられ得る。いくつかの実装では、各通信エンドポイントは、キューペア７６０ａ〜ｃにマッピングされ得る。これらの実装では、通信エンドポイントは、キューペア番号によって識別され得る。これらの実装では、キューペア番号をユーザアプリケーション７５４のアドレスとして少なくとも部分的に使用してよい。
仮想マシン７５２にはさらに、ネットワーク７３０と通信するための１つ以上の仮想インタフェース７５９ａ〜ｂが割り当てられ得る。各仮想インタフェース７５９ａ〜ｂには、ＩＰアドレスが割り当てられ得る。いくつかの実装では、ユーザアプリケーション７５４は、ネットワーク７３０と通信するために仮想インタフェース７５９ａ〜ｂのうちの１つ以上を使用し得る。これらの実装では、ユーザアプリケーション７５４は仮想インタフェース７５９ａのＩＰアドレスを使用して、ネットワーク７３０上の他のシステム及びプロセスに対してユーザアプリケーション７５４自体を識別し得る。いくつかの実装では、ユーザアプリケーション７５４は仮想インタフェース７５９ａに割り当てられたＩＰアドレスと通信エンドポイントの識別子（例えば、キューペア番号）との両方を使用して、ユーザアプリケーション７５４自体を識別し得る。
図７Ａに関して述べた例を続けると、この例では、送信側ユーザアプリケーション７０４ａは、メッセージに対する宛先システム７１８ａを識別する情報と共に、メッセージをキューペア７１０ａの送信キュー７１２に配置することによってメッセージを送信した。ネットワークアダプタデバイスは、後続的に、送信キュー７１２を提供し、宛先情報を使用して、メッセージを送信するために使用するトランスポートコンテキスト７１６ａを決定することがある。ネットワークアダプタデバイスは、次いで、トランスポートコンテキスト７１６ａを使用して、メッセージを送信するための１つ以上のパケットを生成することがある。トランスポートコンテキスト７１６ａの支援により、ネットワークアダプタデバイスは、次いで、ネットワーク上の複数の接続７２４ａ上で、１つ以上のパケットを宛先システム７１８ａに送信することがある。
図７Ｂでこの例を続けると、送信システムは、ネットワーク上の第１の送信元システム７６６ａとして表される。送信元システム７６６ａからの１つ以上のパケットは、ネットワーク７３０上の複数の経路７２４ａ上の受信側システムによって受信される。いくつかの実装では、パケットはネットワークアダプタデバイスによって受信される。これらの実装では、ネットワークアダプタデバイスは、どのトランスポートコンテキスト７６８ａ〜ｂがパケットの送信元システム７６６ａに対応するかを判断し得る。ネットワークアダプタデバイスは、適切なトランスポートコンテキスト（この例では、第１のトランスポートコンテキスト７６８ａである）を決めるために、パケット及び／または宛先アドレスに提供された送信元アドレスを使用し得る。いくつかの実装では、ネットワークアダプタデバイスは、送信元アドレスを含むネットワークアドレスマップを有してよく、ネットワークアダプタデバイスは、送信元アドレスを使用してネットワークアドレスマップにインデックスを付け、トランスポートコンテキスト７６８ａを発見してよい。
いくつかの実装では、トランスポートコンテキスト７６８ａは、信頼可能な接続トランスポートと同様のトランスポートサービスを提供するように構成され得る。これらの実装では、ネットワークアダプタデバイスは、信頼可能な接続トランスポートとして構成されたトランスポートコンテキスト７６８ａ〜ｂのテーブルを有し得る。ネットワークアダプタデバイスはさらに、宛先キューペア番号を使用してテーブルにインデックスを付けてよく、テーブルは適切なトランスポートコンテキスト７６８ａを示してよい。いくつかの場合、ネットワークアダプタはさらに、正しいトランスポートコンテキスト７６８ａを決めるために受信パケットに含まれるコンテキスト識別子を使用してよい。
以下により詳細に説明するように、トランスポートコンテキスト７６８ａは、各パケットの状態を監視して、送信元システム７６６ａシステムによって送信された各パケットが受信されることを確実にし得る。トランスポートコンテキスト７６８ａ（特に緩和された信頼可能なデータグラムトランスポートサービス）は、パケットが受信システムで順序通りに受信されるかどうかを追跡することができず、一般的には、全てのパケットが到着することを確実にすることのみを考慮する。いくつかの実装では、トランスポートコンテキスト７６８ａは、受信パケットを処理し、例えば、ネットワークヘッダを削除し得る。トランスポートコンテキスト７６８ａはさらに、重複パケット７７６が受信されたことを検出し得る。パケットがネットワーク７３０内でドロップされたか、またはドロップされたと考えられるときに、重複パケット７７６は受信され得る。パケットがネットワーク７３０にドロップされたと考えられる場合、トランスポートコンテキスト７６８ａは、送信元システム７６６ａがパケットを再送することを要求し得る。いくつかの場合、要求されたパケットは、パケットが実際にはドロップされなかった場合などでは、受信システムによって複数回受信され得るが、単に到着までに非常に長い時間がかかったため、ドロップされたと考えられたにすぎない。これが生じると、トランスポートコンテキスト７６８ａは、第１のコピーが受信された後に受信された任意の追加のコピー７７６をドロップし得る。
ネットワークアダプタデバイスは、トランスポートコンテキスト７６８ａから（例えば、ファームウェアまたは集積回路を使用して）パケットを受信し、パケットを受信することになるキューペア７６０ａ〜ｃを決定し得る。ネットワークアダプタは、受信パケットに含まれる宛先アドレスなどの宛先情報を使用して、適切なキューペア７６０ａを決定し得る。例えば、宛先アドレスは、キューペア番号を少なくとも部分的に含み得る。ネットワークアダプタデバイスは、実線の矢印７７２ａに示すように、１つ以上のパケットを、決定されたキューペア７６０ａの受信キュー７６４に配置し得る。キューペア７６０ａ〜ｃは、特定の通信エンドポイントに関連してよく、必ずしも特定のトランスポートコンテキスト７６８ａ〜ｃに関連するわけではない。ゆえに、特定のキューペア７６０ａは、破線７７２ｂに示すように、異なるトランスポートコンテキストからパケットを受信中であり得る。
受信キュー７６４から、ネットワークアダプタは、パケットをホストメモリ７８０内のバッファ７８２に転送し得る。例えば、ネットワークアダプタはＤＭＡ動作を実行してよく、これは、通常、ホストデバイスのプロセッサにホストメモリ７８０への書き込みを要求しない。いくつかの実装では、仮想インタフェース７５９ａのＩＰアドレス及び／または通信エンドポイントの識別（これらのいずれかまたは両方がパケットの宛先アドレスとして提供され得る）は、正しい仮想マシン７５２へのパケットの転送を支援し得る。いくつかの実装では、ドライバプログラム７５８は、バッファ７８２へのパケットの転送を支援し得る。いくつかの実装では、標準ライブラリはこの支援を提供し得る。
ユーザアプリケーション７５４は、複数の通信エンドポイントを使用するように構成されてよく、したがって、複数のキューペア７６０ａ〜ｃでパケットを受信中であってよい。ネットワークアダプタデバイスは、各キューペア７６０ａ〜ｃに割り当てられた優先度及び／またはサービス品質保証に従って、キューペア７６０ａ〜ｃが公平に提供されること及び／またはキューペア７６０ａ〜ｃを提供し得ることを確実にし得る。
いくつかの実装では、個々のバッファ７８２は、どのような順序で詰められてよく、常時利用可能であってよい。パケットはさらに、任意の順序でバッファ７８２に配置され得る。ほとんどの場合、ネットワークアダプタは、パケットを可能な限り迅速にキューペア７６０ａ〜ｃからホストメモリ７８０に移動して、レイテンシを可能な限り少なくするように構成され得る。この理由及び他の理由により、ネットワークアダプタはさらに、通常、キューペア７６０ａ〜ｃの外部のパケットをバッファリングしない。場合によっては、十分なバッファ７８２が利用できない場合がある。これは、ユーザアプリケーション７５４に十分なバッファを割り当てられていないか、またはバッファを十分に速く解放していないために生じ得る。以下にさらに説明するように、これが生じると、ネットワークアダプタは、ユーザアプリケーション７５４に送られるパケットのドロップを開始し、パケットがドロップされていることをユーザアプリケーション７５４に通知し得る。パケットがドロップされていることを送信元システムに通知するために、応答メッセージはさらに送信元システムに送り返され得る。いくつかの場合、送信元システムは、この特定のユーザアプリケーション７５４にパケットを配信する速度を低下することによって応答し得る。いくつかの実装では、不十分なバッファ空間及び／またはドロップされたパケットがある場合、それらをどのように対処するか決定することはユーザアプリケーション７５４に任せられる。
前に記した通り、パケットは、任意の順序でバッファ７８２に配置され得る。いくつかの実装では、ドライバプログラム７５８は、パケットを意図された順序で配置するために、パケットの並び替えを行うように機能し得る。これらの実装では、ドライバプログラム７５８は、パケットをユーザアプリケーション７５４に順序通りに提示してよく、ユーザアプリケーション７５４はパケットが順不同で到着したことを認識できない。いくつかの実装では、ユーザプログラム７５４はパケット自体を並び替え得る。いずれの場合でも、ユーザアプリケーション７５４及び／またはドライバプログラム７５８は、ホストデバイスで利用可能な高い処理能力を利用し得る。
パケットの順序付けを保証する信頼可能な接続及び信頼可能なデータグラムなどのトランスポートサービスに比べ、緩和された信頼可能なデータグラムトランスポートを使用するシステムは、高い拡張性及び良好なレイテンシを提供し、ゆえに、高性能なコンピューティングアプリケーションに潜在的に良好な性能を提供し得る。例えば、パケットの順序を保証するトランスポートサービスでは、ネットワークアダプタデバイスが一定量のパケットをバッファリングし、次いで、ホストデバイスにパケットを提供する前にパケットを並び替える必要があり得る。いくつかの場合、パケットが順不同で到着すると、ネットワークアダプタデバイスは全てのパケットをフローにドロップし、フローを最初から再送するよう要求することを必要があり得る。ネットワークアダプタデバイスがパケットを並び替えるとホストデバイスのソフトウェアは簡略化され得る一方、ネットワークアダプタの要件はより複雑になり、パケット転送のレイテンシ及び帯域幅の消費が増加し得る。
対照的に、緩和された信頼可能なデータグラムトランスポートでは、ネットワークアダプタデバイスは最小限の時間だけパケットをバッファリングすることがあり、ゆえに、全体的なレイテンシを改善する。並び替え動作は、次いで、ホストデバイス上のソフトウェアによって実行されてよく、ソフトウェアはレイテンシによる負担を最小化した状態で高出力のホストデバイスのプロセッサを利用し得る。緩和された信頼可能なデータグラムトランスポートは、順序付けを保証するために行うことができるが、これにより、送信側キューペアから受信側キューペアへの全てのフローのパケット順序状態を追跡すること、または異なる論理フローに属するパケットをシリアル化して単一のパケットシーケンスにすることのいずれかが必要になるだろう。送信側キューペア及び受信側キューペアの全ての組み合わせの間でパケット順序状態を追跡することにより、システムの拡張が難しくなり得る。異なる論理フローからパケットをシリアル化すると、無関係なフローの間に偽の依存関係が作成されることがあり、平均及び最大パケット転送レイテンシが増加し得る。ほとんどの場合、実際にユーザアプリケーションは独自のメッセージフローを追跡し、順不同で到着するパケットを管理するように迅速に再構成することができる。緩和された信頼可能なデータグラムトランスポートは、ゆえに、パケット並び替えをホストデバイスのソフトウェアに任せてよく、全てのパケットの配信を保証することに集中する。
前述の通り、通常のコンピューティングクラスタシステムでは、パケットがネットワークを通じて送信元システムから宛先システムへ移動するために複数の経路を取ることができる。１つの送信元から１つの宛先へのパケットの流れは、パケットのフロー、または単にはフローと呼ばれ得る。フロー内のパケットは互いに関連してよく（例えば、それらはビデオまたは会話などの１つの連続したデータストリームに属する）、フローは終了及び再開し得る（例えば、ビデオまたは会話は終了してよく、新しいビデオまたは会話を開始してよい）。さらに前に記した通り、所与の送信元から特定の宛先までのパケットが全ての利用可能な経路に分散されている場合、クラスタ全体の効率が向上し得る。しかしながら、既存のトランスポートサービスは、パケットが順序通り到着する可能性を確実にして性能低下を低減するために、通常、順序通りのパケット配信に対して設計されており、１つのみの経路上で１つのフローを送信するように構成され得る。さらに、これらのトランスポートサービスは、通常、１つのフローが終了して別のフローが開始するときにのみ経路を変更することができる。
図８は、利用可能な経路８４０を通じたさらなる活用を達成するために、緩和された信頼可能なデータグラムトランスポートが、ネットワーク８３０を通る複数の経路８４０を管理し得る方法の一例を例示する。図８の例では、送信元システム８０２から宛先システム８５２へのパケットのフロー８１０は、「フローレット」８００と呼ばれ得るパケットのグループに分割され得る。送信元トランスポートコンテキスト８１６及び対応する宛先トランスポートコンテキスト８６８は、ネットワーク８３０を通る経路の設定及び解除を含む、フローレット８００の送信及び受信を管理し得る。送信元及び宛先コンテキスト８１６、８６８はさらに、個別のフローレット８００ごとにパケットの状態を監視し得る。各フローレット８００は、異なる経路８４０上で送信されてよく、１つのフローレット８００内の全てのパケットは同じ経路を使用する。いくつかの実装では、全てのパケットは、１つのポート８２２上で送信元システム８０２から送信され、宛先システム８５２において１つのポート８６２で受信される。他の実装では、送信元システム８０２及び／または宛先システム８５２は、ネットワーク８３０に接続された複数のポートを有し得る。
前述の通り、緩和された信頼可能なデータグラムトランスポート実装では、送信元コンテキスト８１６は、通常、１つの特定の宛先コンテキスト８６８に関連する。送信元コンテキスト８１６は、ほとんどの場合、宛先システム８５２に関連するアドレスによって識別される。宛先アドレスは宛先コンテキスト８６８に割り当てられる。同様に、宛先コンテキスト８６８は、送信元コンテキスト８１６に割り当てられている送信元システム８０２のアドレスによって識別され得る。送信元コンテキスト８１６は、パケットのフロー８１０の送信を管理してよく、フロー８１０は、送信元システム８０２で動作中の複数のユーザアプリケーションからのパケットを含み得る。フロー８１０内のパケットは全て、宛先システム８５２上で動作中のユーザアプリケーションに送られる。宛先コンテキスト８６８は、宛先システム８５２において、フロー８１０内のパケットの受信を管理し得る。
いくつかの実装では、送信元システム８０２は、宛先コンテキスト８６８に関連するアドレスが（例えば、図５Ａ〜図５Ｂの例に従って）初めてマッピングされたときに、新しいフローレット８００を初期化し得る。図８の例の第１のフローレット８００が初期化された場合、追加のフローレット８００が確立され得る。接続確立メッセージは正常なネットワークトラフィックに付属してよく、通常、送信元システム８０２が接続要求を宛先システム８５２に送信し、宛先システム８５２が確認メッセージを送信元システム８０２に送り返すことによって応答することを伴う。いくつかの実装では、フローレット８００は、この例のように一方向であり、フローレット８００は、送信元システム８０２で発生し、宛先システム８５２で終了する。同じ送信元コンテキスト８１６及び宛先コンテキスト８６８を使用して、宛先システム８５２で発生し送信元システム８０２で終了するフローレットが構築され得るが、いくつかの実装では、これらは図８の例に例示されているものとは異なるフローレットのセットであり、個別に管理される。
図８の例は、一例として４つのフローレット８００を例示する。様々な実装では、より多数または少数のフローレット８００がトランスポートコンテキスト８１６、８６８によって使用され得る。いくつかの実装では、送信元システム８０２と宛先システム８５２との間のフローレット８００の数は、変更可能であってよく、及び／または２つのシステム８０２、８５２の間の利用可能な経路８４０の数によってのみ限定されてよい。
通常、フローレット８００は、トランスポートコンテキスト８１６、８６８のみに知られており、キューペア、仮想マシンまたはユーザアプリケーションから独立している。換言すると、送信元システム８０２及び宛先システム８５２上で動作中のユーザアプリケーションは、ほとんどの実装ではフローレット８００を認識せず、標準ライブラリ及び／またはドライバプログラムのみと相互作用する。パケットが同じ宛先システム８５２に送られる場合、様々な送信元からのパケットを同じフロー８１０に配置してよい。フロー８１０からのパケットは、パケットがフローレット８００の全体に均等に分散されるように、フローレット８００に割り当てられ得る。代替的または追加的には、パケットが少なくなっているフローレット８００にパケットが最初に割り当てられるよう、パケットは割り当てられ得る。急激に少なくなっているフローレット８００は、より高速な経路を使用していることがあり、したがって、これらのフローレット８００にパケットを割り当てることにより、全体の利用率及びスループットが向上し得る。
送信元コンテキスト８１６は、個別のフローレット８００ごとにパケットを追跡し得る。各フローレット８００は、パケットシーケンス番号を保持してよく、フロー８１０からのパケットがフローレット８００に割り当てられるとき、各パケットにはさらに、そのフローレット８００の次のパケットシーケンス番号が割り当てられ得る。パケットにはさらにフローレット識別子が割り当てられてよく、これは、各パケットのフローレット８００を識別するために、宛先コンテキスト８６８によって使用されてよい。
各フローレット８００について、送信元システム８０２は、フローレット８００に割り当てられた各パケットの状態情報８２０を保持し得る。状態情報８２０は、各パケットのパケットシーケンス番号及びパケットを再送するのに必要となり得る任意の情報を含み得る。ほとんどの場合、パケットに対する状態情報８２０は、パケットが送信された時点から、パケットが受信されたという確認を送信元システム８０２が受信するまで、保持され得る。送信元コンテキスト８１６は、フローレット８００ごとに限られた数の未処理パケットについてのみ状態情報８２０を保持し得る。例えば、送信元コンテキスト８０２は、フローレット８００ごとに３２の未処理パケットのみを許可するように構成され得る。フローレット８００ごとの未処理パケットの数は一定であってよいか、または変更可能であってよい。フローレット８００が非常に遅い場合、つまり、確認の到着が遅いか、または全く到着しない場合、送信元コンテキスト８０２は、フローレット８００を別の経路８４０に移動させ得る。
宛先コンテキスト８６８はさらに、個別のフローレット８００ごとに、それ自体の状態情報８６０を用いて、パケットを追跡し得る。宛先コンテキスト８６８によって保持される状態情報８６０はさらに、各フローレット８００のパケットシーケンス番号を含み得る。以下でさらに詳細に説明するように、宛先コンテキスト８６８は、状態情報８６０を使用して、送信元システム８０２に送信される確認を生成し得る。確認は、特定のフローのパケットが宛先システム８５２に到着したことを送信元コンテキスト８０２に通知し、通常、どのパケットが到着したかを示し得る。
フローレット８００は、アクティブ又はアイドル状態であってよい。アクティブなフローレット８００には、未処理パケット、つまり、送信されたが未だ確認されていないパケットがある。アイドル状態のフローレット８００には未処理パケットがなく、送信待ちのパケットもない。フローレット８００がアイドル状態の場合、送信元コンテキスト８１６は、フローレット８００を異なる経路８４０に移動することを決定し得る。一般的に、アイドル状態のフローレット８００を別の経路に移動させる送信元コンテキスト８１６の決定は、（例えば、一定時間またはフローレット８００がアイドル状態になる度に）組織的というよりはランダムに行われる。アイドル状態のフローレット８００を他の経路に移動させることにより、送信元コンテキスト８１６は、ネットワーク８３０を通じて混雑の少ない経路８４０を発見することを試みる。
各フローレット８００からのパケットは、送信元システム８０２によって、それらのパケットシーケンス番号の順序で送信され得る。フローレット８００から送信された第１のパケットはさらに、特定のフローレット８００が開始していることを宛先コンテキスト８６８に通知する「シーケンス開始」インジケータを含み得る。宛先コンテキスト８６８は、次いで、パケット内のパケットシーケンス番号をシーケンス開始インジケータと共に使用して、そのフローレット８００の状態を確立し得る。宛先コンテキスト８６８は、後続的には、そのフローレット８００のパケットが、それらのパケットのシーケンス番号の順序通りに到着するよう予期する。ゆえに、例えば、１つのフローレット８００からのパケットは、シーケンス番号「１、２、３、４、５．．．」で送信元システム８０２によって送信されてよく、第１のパケットはシーケンス開始インジケータを含む。宛先システム８５２は第１のパケットを受信し、シーケンス開始インジケータを記録し、後続的に、シーケンス番号「２、３、４、５．．．」のパケットがそのフローレット８００に対して順序通り到着するよう予期し得る。
しかしながら、パケットはネットワーク８３０内でドロップされることがあり、宛先システム８５２に到達しない可能性がある。例えば、上述の例を続けると、宛先システムは、パケットシーケンス番号「１、３」のパケットを受信することがあり、これは、パケットシーケンス番号「２」のパケットがドロップした可能性があることを示す。以下により詳細に説明するように、送信元コンテキスト８１６と宛先コンテキスト８６８との両方が保持するパケット状態により、コンテキスト８１６、８６８は、パケットがネットワーク８３０内でドロップしたことを識別し、失われた全てのパケットを再送することができ得る。
ネットワーク８３０内のリンクの過剰使用を原因とするネットワーク８３０内のドロップ及び遅延は、性能に影響を及ぼす可能性があり、ゆえに、一般的には両方を回避または最小化することが望ましい。送信元コンテキスト８１６は、１つの経路８４０での過度のドロップまたは混雑を多数の方法で検出し得る。例えば、フローレット８００の状態情報８２０は、パケットが送信されたときから、そのパケットに対する確認が受信されたときまでの時間を決定するために送信元コンテキスト８１６が使用できるタイマを含み得る。時間が長いときはフローレット８００によって使用されている経路での混雑を示し得る。代替的または追加的には、送信元コンテキスト８１６は、送信元コンテキスト８１６がどのくらい迅速に各フローレット８００にパケットを追加することができるかを追跡し得る。他のフローレット８００ほど迅速にはパケットを受け入れることができないフローレット８００では、ネットワークを通るその経路８４０に混雑が発生している可能性がある、及び／または過度なドロップが発生している可能性がある。代替的または追加的には、送信元コンテキスト８１６は、特定のフローレット８００に対して大量の再送要求を受信することがあり、これは、フローレット８００が使用している経路での過剰なドロップを示し得る。
送信元コンテキスト８１６が、フローレット８００が混雑または過剰ドロップが発生している可能性があると判断した場合、送信元コンテキスト８１６は、フローレット８００を別の経路８４０に移動し得る。いくつかの実装では、一旦フローレット８００が移動されると、経路の識別子が現在変更されていたとしても、宛先コンテキスト８５２は、フローレット８００からパケットを受信して受け入れ続ける。いくつかの実装では、送信元コンテキスト８１６は、再配置されたフローレット８００に、最も古い未確認のパケットシーケンス番号のパケットと共に、新しいシーケンス開始インジケータを送信させ得る。これらの実装では、宛先コンテキスト８６８は、新しいシーケンス開始インジケータを受信すると、送信元システム８０２が新しいシーケンス開始インジケータを伴うパケットより前に送信した任意のパケットを送信元システム８０２が捨てたと考え、再開されたフローレット８００に関して有していた任意の情報（例えば、パケットシーケンス番号）を破棄し得る。
いくつかの場合、宛先コンテキスト８６８は、順不同で到着したパケット内のシーケンス開始インジケータを受信し得る。例えば、宛先コンテキスト８６８は、シーケンス番号「１、２、３、１」のパケットを受信することがあり、シーケンス番号「１」を有する両方のパケットは同じパケットのコピーであり、シーケンス開始インジケータを有する。これは、例えば、フローレット８００の経路８４０が特に遅く、シーケンス番号「１」の第１のパケットに対する確認が送信元システム８０２に到達するまで非常に遅かった場合に起こり得る。この遅さに起因して、送信元システム８０２は、確認を受信する前に、経路を切り替えてフローレット８００を再開し得る。この状況では、宛先コンテキスト８６８は、パケットシーケンス番号「１」の第２のパケットを受信するときに、フローレット８００の状態をリセットする必要がないことを認識し得る。代わりに、宛先コンテキスト８６８は、パケットシーケンス番号「１」の第１のパケットをシーケンス開始として認識してよく、パケットシーケンス番号「１」とシーケンス開始インジケータの両方のセットで到着する任意の追加パケットを無視してよい。いくつかの実装では、宛先コンテキスト８６８は、追加パケットが受け入れられなかったことを示す確認を送信してよく、送信元コンテキスト８１６が状況を理解するのを支援してよい。
フローレット８００はさらに、送信元システム８０２または宛先システム８５２のいずれかが切断されたときに再開する必要があり得る。宛先システム８５２は、完全にまたは部分的にのみ切断されてよい。宛先システム８５２がリセットされるときに完全な切断が生じ得る。宛先システム８５２がリセット後に動作可能になると、宛先コンテキスト８６８はパケットを受信することができるが、その状態情報８６０がリセットされているため、宛先コンテキスト８６８は、任意のフローレット８００（例えば、到着したパケットのシーケンス番号）に対する状態情報を有することができなくなる。宛先コンテキスト８６８は、ゆえに、全ての受信パケットに対して、パケットが受け入れられなかったことを示す応答を送信し得る。いくつかの場合、応答は、宛先コンテキスト８６８が予期していないパケットシーケンス番号を受信したことを、送信元コンテキスト８１６に伝えるインジケータを含み得る。これらの応答を受信すると、送信元コンテキスト８１６は、これらのパケットを送信しようとしたユーザアプリケーションに、宛先コンテキスト８５２が接続状態の追跡を見失ったことを通知し得る。これにより、ユーザアプリケーションがリカバリ動作を開始し得る。
宛先システム８５２での部分的な切断がさらに生じ得る。例えば、フロー８１０を受信している宛先システム８５２で、仮想マシンが故障したか、またはシャットダウンされたかのいずれかのためにオフラインになったとき、部分的な切断が生じ得る。いくつかの実装では、送信元コンテキスト８１６は、例えば、制御プレーン上で受信されたコマンドによって、そのターゲット仮想マシンがオフラインであることを明示的に通知され得る。他の実装では、送信元コンテキスト８１６は、未処理パケットが所定期間（例えば、タイマの期限切れ）で未確認となった場合に、ターゲット仮想マシンがオフラインであると判断し得る。ターゲット仮想マシンがオフラインであると判断するか、または通知されると、送信元コンテキスト８１６は、任意の未処理パケットをドロップし、宛先システム８５２との接続を閉じ得る。いくつかの実装では、送信元コンテキスト８１６はさらに、送信元側ユーザアプリケーションに、送信元コンテキストがドロップしたパケットは送信されなかったと報告し得る。ターゲット仮想マシンはオフラインであるため、送信元コンテキスト８１６はさらに、フロー８１０からパケットを送信する任意の後続の要求を拒否し得る。ターゲット仮想マシンは、最終的にバックアップされてよく、その時点で、送信元コンテキスト８１６は、ターゲット仮想マシンが再起動することを通知されてよい。送信元コンテキスト８１６は、次いで、宛先システム８５２との接続を再度初期化し、フロー８１０からのパケットの受け入れを再び開始してよい。
例えば、フロー８１０からパケットを受信している宛先システム８５２でユーザアプリケーションがオフラインになったときにも、部分的な切断が生じ得る。宛先側ユーザアプリケーションがクラッシュしたか、または閉じられている可能性がある。この状況では、宛先コンテキスト８６８は、受信パケットを通常通り確認し、現在オフラインである宛先側ユーザアプリケーションに割り当てられた受信キューに、それらを配信し得る。パケットは、その後、受信キューでドロップされ得る。多くの場合、フローレットは、オフラインのユーザアプリケーションを含む、複数の宛先側ユーザアプリケーションに送られるパケットを含み得るため、宛先コンテキスト８６８は、ほとんどの場合、フローレット８００をリセットさせないだろう。代わりに、いくつかの実装では、宛先コンテキスト８６８は、オフラインのユーザアプリケーションに送信されたパケットが受信されたとして処理し、送信元８０２及び宛先８５２のシステムにあるユーザアプリケーションに処理方法の判断を任せる。他の実装では、パケットはドロップされ、ドロップされたパケットを送信ユーザアプリケーションに通知する。
送信元システム８０２はさらに、（例えば、リセットされることによって）完全に切断されてよく、または部分的に切断されてよい。送信元側ユーザアプリケーションが再起動されたときに生じる部分的な切断は、送信元コンテキスト８１６に影響を及ぼさない可能性がある。送信元側の仮想マシンの再起動または送信元システム８０２全体のリセットによって生じる部分的な切断によって、結果的に送信元コンテキスト８１６が再開し得る。これらの場合、送信元コンテキスト８１６は、送信元システム８０２が最初に起動された時と同じ方式でそのフローレット８００を再度初期化し得る。送信元システム８０２では、新たに開始されたフローレット８００は、通常、履歴を持たない（例えば、確認されたパケットシーケンス番号がない）。ゆえに、いくつかの実装では、送信元コンテキスト８１６は、シーケンス開始インジケータのパケットが宛先システム８５２によって確認されるまで、シーケンス開始インジケータのパケットを送信した後、パケット送信を遅延させ得る。これにより、フローレット８００の「最新の確認」パケットシーケンス番号を確立し得る。いくつかの場合、送信元コンテキスト８１６は、シーケンス開始インジケータの初期パケットが宛先システム８５２によって受け入れられなかったことを示す確認を受信し得る。これは、例えば、宛先コンテキスト８６８が初期パケットに含まれているパケットシーケンス番号を拒否した場合に生じ得る。これが生じると、送信元コンテキスト８１６は、シーケンス開始インジケータのパケットを再び送信し、いくつかの実装では、異なる開始パケットシーケンス番号をパケットに提供し得る。
ネットワーク８３０におけるパケットドロップ、経路８４０の切り替え、切断及びフローレットの再開には、それぞれ、パケットの再送が必要となり得る。これらの再送パケットは、宛先システム８５２で受信されると、これまでに受信されたパケットの順序通りではなくなる。例えば、宛先コンテキスト８６８は、シーケンス番号「１、３」のパケットを受信していた可能性があり、ゆえに、シーケンス番号「２」のパケットを再送する必要があることを示し得る。一旦シーケンス番号「２」のパケットが再送されると、宛先コンテキスト８６８は、この特定のフローレット８００に対してシーケンス番号「１、３、２」を有することになる。
以下でさらに詳細に説明するように、宛先コンテキスト８６８は、パケットがこの方式で順不同で到着することを予期するように構成され得る。宛先コンテキスト８６８は、送信元コンテキスト８１６と協働して、ほとんどの実装において、全てのパケットが受信されることを確実にし、通常、それらのパケットが受信される順序は考慮しない。宛先コンテキスト８６８は、通常、パケットが受信されるとすぐに、または実際に可能な限り早急に、パケットを宛先側ホストデバイスに転送し、必要となるパケットの任意の並び替えはホストデバイスに任される。パケットは、フロー８１０の宛先エンドでは、フロー８１０の送信元エンドでの順序とは異なる順序になり得ることに留意されたい。ただし、パケットが一旦ターゲットキューペアに配信されると、特定の宛先側ユーザアプリケーションに対して送られるパケットは、実際には、順序通りとなり得る。しかしながら、キューペアにおける並び替えは、宛先コンテキスト８６８によって保証されるわけではない。
上述の通り、送信元コンテキスト８１６及び宛先コンテキスト８６８はそれぞれ、各個別のフローレット８００に対する状態情報８２０、８６０を保持し得る。送信元及び宛先コンテキスト８１６、８６８は、状態情報８２０、８６０を使用して、フロー８１０内の全てのパケットが宛先システム８５２に到達することを確実にし得る。
図９Ａ〜９Ｂは、緩和された信頼可能なデータグラムトランスポートがパケットの信頼可能な配信を保証し得る方法の一例を例示する。緩和された信頼可能なデータグラムトランスポートサービスは、送信側９００コンテキストが各送信パケットの状態情報を保持し、受信側が受信した全てのパケットに対する応答を受信側９５０コンテキストが送信側９００に返送することによって、保証されたパケット配信を提供し得る。図９Ａは、送信側９００のコンテキストが各送信パケットの状態情報を保持し得る方法の一例を例示する。図９Ｂは、受信側９５０のコンテキストが状態情報を保持し、状態情報を使用して応答を生成し得る方法の一例を例示する。
一般的に、ユーザアプリケーションは、通常、パケットがその宛先に到達することを確実にすることに関与しない。１つ以上のパケットがネットワーク内でドロップされたことを受信側ユーザアプリケーションが判断するには、受信されたパケットは、受信側トランスポートスタックまで進みユーザアプリケーションまで移動する必要がある。例えば、ユーザアプリケーションが非常にビジー状態にあるためにパケットを受信できない場合には、パケットが途中で遅延することがある。その場合、ユーザアプリケーションは、トランスポートスタックまで進み、ネットワークを通り、次いで、送信側トランスポートスタックを上って送信ユーザアプリケーションまで要求を再送する必要がある。対照的に、受信側トランスポートコンテキストは、パケットの受信側の最初の連絡地点であってよく、ゆえに、パケットが到着していないことをより迅速に判断することができ得る。同様に、送信側トランスポートコンテキストは、再送要求を最初に受信してよく、ゆえに、ユーザアプリケーションよりもはるかに迅速に再送要求に応答し得る。
いくつかの実装では、緩和された信頼可能なデータグラムトランスポートサービスは、パケットシーケンス番号を使用して、パケットの保証された信頼可能な配信を提供し得る。送信側９００のトランスポートコンテキストは、送信した各パケットに対して、個別のフローレットごとにパケットシーケンス番号を追跡し得る。受信側９５０のトランスポートコンテキストは、受信したパケットのパケットシーケンス番号を追跡し、送信側９００のトランスポートコンテキストに応答を送り返し得る。これらの応答は、どのパケットが受信されたかを送信側９００のトランスポートコンテキストに通知し得る。具体的には、受信側９５０のトランスポートコンテキストは、パケットシーケンス番号がパケットのパケットシーケンス番号に関して順序通りであるパケットを受信するときに、受信側９５０のトランスポートコンテキストは「ＡＣＫ」応答を送信し得る。受信側９５０のトランスポートコンテキストは、それらのパケットシーケンス番号に応答して順序通りでないパケットを受信するときに、受信側９５０のトランスポートコンテキストは「選択的ＡＣＫ」または「ＳＡＣＫ」応答を送信し得る。場合によっては、パケットが受信側９５０のトランスポートコンテキストに到達することがあるが、受信側９５０のトランスポートコンテキストはパケットを受け入れ不可能である場合がある。この状況では、受信側９５０のトランスポートコンテキストは、パケットが受け入れられなかったことを送信側９００のトランスポートコンテキストに示すために「ＮＡＣＫ」を送信し得る。
図９Ａは、未処理パケットの送信側９００の管理及び応答の受信の一例を例示する。図９Ａの例では、一例として、３つのフローレット９０４ａ〜ｃを例示する。前述の通り、フローレットのセットは、一般的に、１つのパケットフローからのパケットを含むが、フローは、同じ宛先システムに送信している複数のユーザアプリケーション９０２からのパケットを含み得る。パケットフローはグループに分割されてよく（ほとんどの実装では、パケットの相互関係は考慮されない）、これらのパケットグループはサブフローまたはフローレットと呼ばれ得る。経路が送信側９００のトランスポートコンテキストによって変更されない限り、または変更されるまで、特定のフローレット内のパケットは、一般的に、ネットワーク９３０上の同じ経路を使用する。図９Ａの簡略化した例には、フローレット９０４ａ〜ｃごとに４つのパケットしか例示されていないが、各フローレット９０４ａ〜ｃは、５つ以上の未処理パケットに対して状態情報を保持し得ることが理解される。いくつかの実装では、フローレットが状態を保持できるパケットの数は（例えば、８、１６、１３またはそれ以上のパケットに）制限される。これらの実装では、一旦未処理パケットの数が制限値に等しくなると、未処理パケットの少なくとも１つが受信されたと確認されるまで、そのフローレットを使用してそれ以上パケットを送信することができない。
第１のフローレット９０４ａの例では、最初の３つのパケット９０８ａ、９０８ｂ、９０８ｃがネットワーク９３０に送信されており、第４のパケット９０８ｄが送信されるのを待っている。第１のフローレット９０４ａの状態情報９０６ａは、第１のパケット９０８ａのＡＣＫ状態９１０ａと、第２のパケット９０８ｂのＡＣＫ状態９１０ｂとを示す。これらの２つのＡＣＫ状態９１０ａ、９１０ｂは、第１のパケット９０８ａ及び第２のパケット９０８ｂが受信側９５０のトランスポートコンテキストで受信されたことと、それらが順序通りに受信されたこと（例えば、第１のパケット９０８ａが受信された後、第２のパケット９０８ｂが受信された）との両方を示す。いくつかの実装では、古いパケットの再送要求が到着する可能性は低いため、送信側９００のトランスポートコンテキストは、最も古い未確認のパケットを記憶するだけでよい。ゆえに、これらの実装では、送信側９００のトランスポートコンテキストは、第１のパケット９０８ａの状態情報９０６ａを忘れる可能性があり、場合によっては、第２のパケット９０８ｂの状態情報も忘れる可能性がある。フローレット内のパケット数が制限されている実装では、１つまたは２つのパケットの状態情報９０６ａを削除することにより、さらに、より多くのパケットが送信されるようにスロットが解放される。
第１の例示的なフローレット９０４ａを締めくくると、第３のパケット９０８ｃは送信済み状態９１０ｃを有しており、これは、このパケット９０８ｃに対する応答がまだ受信されていないことを意味する。第４のパケット９０８ｄはペンディング状態９１０ｄを有しており、これは、パケットがフローレット９０４ａに追加されたが、ネットワーク９３０にまだ送信されていないことを意味する。
第２のフローレット９０４ｂの例では、４つのパケット９１２ａ〜ｄの全てがネットワーク９３０に送信されている。第２のフローレット９０４ｂの状態情報９０６ｂは、第３のパケット９１２ｃのＳＡＣＫ状態９１４ｃを示す。ＳＡＣＫ状態９１４ｃは、第３のパケット９１２ｃが受信側９５０のトランスポートコンテキストによって受信されたことを示す。ＳＡＣＫ状態９１４ｃはさらに、第１のパケット９１２ａも受信されたことを示してよく、これは、第１のパケット９１２ａのＡＣＫ状態９１４ａの状態を意味する。一方、第２のパケット９１２ｂ及び第４のパケット９１２ｃは送信済み状態９１４ｂ、９１４ｃを有しており、これらのパケット９１２ｂ、９１２ｃに対する応答がまだ受信されていないことを示す。
送信側９５０のトランスポートコンテキストが順序通りでないパケットを受信した場合、送信側９５０のトランスポートコンテキストによってＳＡＣＫメッセージが使用され得る。第２のフローレット９０４ｂの例では、第１のパケット９１２ａが受信され、次いで、第３のパケット９１２ｃが受信された。これは、第２のパケット９１２ｂが送信済み状態９１４ｂを有しているが、第３のパケット９１２ｃの前に第２のパケット９１２ｂが受信側９５０に到着しなかったことを意味する。実際には、第２のパケット９１２ｂは、ネットワーク９３０によってドロップされた可能性がある。いくつかの実装では、ＳＡＣＫ応答は、受信側９５０で順番に受信された最後のパケットのパケットシーケンス番号（ここでは、第１のパケット９１２ａのシーケンス番号）及び順序通りに受信されなかった第１のパケットのパケットシーケンス番号（ここでは、第３のパケット９１２ｃのシーケンス番号）を含む可能性がある。ゆえに、例えば、数字のパケットシーケンス番号が使用されたと仮定すると、ＳＡＣＫ応答は「１、３」を示す可能性がある。このように、ＳＡＣＫ応答は、第２のパケット９１２ｂが、送信側９００のトランスポートコンテキストによって再送される必要があることを効率的に示し得る。
応答メッセージは、一般的に、データパケットと同じ方式でネットワーク９３０を通過する。ゆえに、応答メッセージもネットワーク９３０にドロップする可能性がある。これは、受信側９５０のトランスポートコンテキストが、１つの特定のパケットが到着しなかったことを示す２つ以上のＳＡＣＫを生成し得ることを意味する。例えば、第２のフローレット９０４ｂの例の場合、「１、３」を示すＳＡＣＫがネットワーク９３０にドロップされた可能性がある。第４のパケット９１２ｄが受信側９５０に到着するのに成功したと仮定すると、受信側９５０のトランスポートコンテキストは第２のパケット９１２ｂをまだ受信していないため、送信側９００のトランスポートコンテキストは「１、３〜４」を示すＳＡＣＫを生成し得る。
広範な例では、送信側９００のトランスポートコンテキストがどのパケットを再送する必要があるかを決定し得る方法を良好に例示し得る。送信側９００のフローレットが、パケットシーケンス番号１、２、３、４、５、６を有する６つのパケットを送信したと仮定する。さらに、受信側９５０上のフローレットがシーケンス番号１、３、５及び６のパケットを受信しており、シーケンス番号２及び４のパケットがネットワーク９３０にドロップされたと仮定する。このシナリオを考慮すると、受信側９５０は以下の応答を生成し得る。
パケット番号１の受信時：ＡＣＫ（１）
パケット番号３の受信時：ＳＡＣＫ（１、３）
パケット番号５の受信時：ＳＡＣＫ（１、５）
パケット番号６の受信時：ＳＡＣＫ（１、５〜６）
これらの確認メッセージの全てが送信側９００のトランスポートコンテキストで受信された場合、第１のＳＡＣＫはパケット番号２の再送をトリガし得る。送信側９００のトランスポートコンテキストは、パケット番号２を既に再送したと判断し得るため、第２のＳＡＣＫはパケット番号４のみの再送をトリガし得る。第３のＳＡＣＫは、いずれの再送もトリガしない可能性がある。
しかしながら、第１のＳＡＣＫがネットワーク９００内で失われたと仮定すると、第２のＳＡＣＫ（ＳＡＣＫ（１、５））の受信は、送信側９００のトランスポートコンテキストがパケット番号２、３及び４を再送するようトリガし得る。パケット番号２がパケット番号６の後に到着すると仮定すると、受信側９５０のトランスポートコンテキストは、ＳＡＣＫ（３、５〜６）を生成して、パケット番号４がまだ到着していないことを送信側９００に通知する。パケット番号３が次に到着すると仮定すると、受信側９５０のトランスポートはこのパケットを複製として認識することがあり、追加の応答を送信することなく複製パケットを破棄するだろう。
いくつかの実装では、送信側９００のトランスポートコンテキストは、確認されていない任意のパケットを再送し、再送を続けるだろう。例えば、第３のフローレット９０４ｃの場合、第４のパケット９１６ｄは、送信済み状態９１８ｄを有するため、定期的に再送されてよい。フローレットが２つ以上の未確認パケットを有する場合、一般的に、これらの未確認パケットは、最も低いパケットシーケンス番号を有するパケットから最も高いパケットシーケンス番号を有するパケットまで、順番に再送される。例えば、第２のフローレット９０４ｂの場合、送信側９００のトランスポートコンテキストは、パケット９１２ｂ及びパケット９１２ｃの１つまたは両方が確認されるまで、第２のパケット９１２ｂを再送し、次いで第４のパケット９１２ｄを再送し、次いで再び第２のパケット９１２ｂ及び第４のパケット９１２ｄを再送し得る。追加のＳＡＣＫ応答が到着すると、ＳＡＣＫメッセージによって受信されていないと示されたパケットは、再送のためにパケットのリストに追加されるか、または再追加され得る。送信側９００のトランスポートコンテキストは、多くの場合、ネットワーク９３０が再送パケットでフラッディングすることを回避するように構成されてよい。例えば、送信側９００のトランスポートコンテキストは、フローレットが一度に送信できる最大数のパケットを示す最大バーストサイズで構成されてよい。初めて送信されたパケット及び再送中のパケットを含む、フローレットによって送信されたパケットの数がバーストサイズに達すると、再送が必要な追加パケットが遅延することがある。
いくつかの実装では、少なくとも最も古い未確認パケットが確認されるまで、フローレットは新しいパケットの送信を中止し得る。例えば、いくつかの実装では、フローレットは、限定された数のパケットの状態情報のみを保持し得る。例えば、これらの実装では、フローレットは、最大６つのパケットの状態情報を保持し、フローレットはパケット番号１〜６を送信することがある。フローレットはさらに、パケット番号２、３及び４に対する応答を受信することがあるが、パケット番号１に対する応答は受信できない。フローレットがパケット番号１に対する確認を受信するまで、フローレットがこのパケットを再送できるように、パケット番号１に対する状態情報を保持する必要があり得る。さらに、パケット番号１が確認されてフローレットから削除され、追加のパケット用の空間が作られるまで、フローレットは、任意の新しいパケットを追加することができない可能性がある。
図９Ａの例に戻ると、第３のフローレット９０４ｃでは、４つ全てのパケット９１６ａ〜ｄがネットワーク９３０に送信されている。第３のフローレット９０４ｃの状態情報９０６ｃは第１のパケット９１６ａのＡＣＫ状態９１８ａを示し、これは、第１のパケット９１６ａが順番に受信されたことを示す。「順番に受信される」とは、そのフローレットに対して受信された全てのパケットが、第１のパケット９１６ａのパケットシーケンス番号の直前にある一連のパケットシーケンス番号（例えば、第１のパケット９１６ａがパケットシーケンス番号「１」を有すると仮定し、パケットシーケンス番号は、最大値が３２でありラップアラウンド可能なカウンタから割り当てられると仮定すると、先行のパケットシーケンス番号は「２９、３０、３１、０」であった可能性がある）を有したか、または第１のパケット９１６ａが「シーケンス開始」インジケータを有したために、このフローレット９０４ｃによって送信された第１のパケットであったことを意味し得る。
しかしながら、第２のパケット９１６ｂ及び第３のパケット９１６ｃは、ＮＡＣＫ状態９１８ｂ、９１８ｃを有する。ＮＡＣＫ状態９１８ｂ、９１８ｃは、第２のパケット９１６ｂ及び第３のパケット９１６ｃが受信側９５０に到着したことを示しているが、これらのパケット９１６ｂ、９１６ｃはどういうわけか受信側９５０で受け入れられなかった。ＮＡＣＫ応答は、一般的に、メッセージを受信したパケットを生成したユーザアプリケーション９０２に送り返される。ユーザアプリケーション９０２は、次いで、対処方法を決定し得る。例えば、ユーザアプリケーション９０２はＮＡＣＫ状態９１８ｂを有するパケット９１６ｂを再送すべきであると決定することがあり、この場合、ユーザアプリケーション９０２はパケット９１６ｂの新しいコピーをフローに配置し得る。しかしながら、ＮＡＣＫ応答をユーザアプリケーション９０２に戻す以外に、送信側９００のトランスポートコンテキストは、ＮＡＣＫ状態９１８ｂ、９１８ｃをＡＣＫ状態と同様に扱い、第２のパケット９１６ｂ及び第３のパケット９１６ｃを完了したものとみなし得る。これは、第１のパケット９１６ａ、第２のパケット９１６ｂ及び第３のパケット９１６ｃならびにそれらの対応する状態情報９１８ａ〜ｃがフローレット９０４ｃから削除されてよく、追加のパケット用に新しいスロットを残すことを意味する。
送信側９００のトランスポートコンテキストは、各フローレット９０４ａ〜ｃに様々なタイマを保持し得る。例えば、送信側９００のトランスポートコンテキストは、応答が受信されたときに第１のフローレット９０４ａのタイマを開始し、第１のフローレット９０４ａに対する別の応答が受信される度にタイマをリセットし得る。長期間応答が受信されない場合、タイマは期限切れになり得る。この時点で、送信側９００のトランスポートコンテキストは何らかのアクションをとり得る。例えば、第１のフローレット９０４ａに多数の未処理パケットがある場合、送信側９００のトランスポートコンテキストは、フローレット９０４ａを異なる経路に切り替えるように決定し得る。多数の未処理パケットは、フローレット９０４ａによって使用されている経路が非常に遅いか、または失敗したリンクを有する可能性があることを示し得る。送信側９００のトランスポートコンテキストはさらに、フローレット９０４ａ内の任意の未処理パケットを再送のためにスケジューリングし得る。
図９Ｂは、パケット受信及び応答生成の受信側９５０の管理の一例を例示する。図９Ｂの例では、図９Ａに例示された３つのフローレット９０４ａ〜ｃの例の受信を例示する。図９Ｂでは、３つのフローレット例のそれぞれについて、受信側９５０のトランスポートコンテキストは、個別のフローレットごとに、各受信パケットに対する状態情報９５４ａ〜ｃを保持する。状態情報９５４ａ〜ｃを使用して、受信側９５０のトランスポートコンテキストは、予期したパケットが受信されなかったことを判断することができ得る。受信側９５０のトランスポートコンテキストは、次いで、送信側９００に欠落パケットを再送するよう要求することができる。
第１のフローレットの例の場合、状態情報９５４ａは、第１のパケット９５８ａ及び第２のパケット９５８ｂが到着したことを示し得る。この例では、受信側９５０のトランスポートコンテキストが第１のパケット９５４ａの受信成功を確認するＡＣＫ応答を生成することができる前に、第２のパケット９５８ｂが到着している。一般的に、受信側９５０のトランスポートコンテキストは、受信した各パケットの応答を自動的に生成してキューに入れることはできない可能性がある。代わりに、受信側９５０のトランスポートコンテキストは、フローレットでパケットを受信すると、そのフローレットに応答の生成が必要であるとマークし得る。受信側９５０のトランスポートコンテキストは、次いで、各フローレットを定期的にポーリングし、フローレットが応答を生成する必要があるかどうかを確認してからようやく応答を生成及び送信し得る。
第１のフローレットでは、これは、第２のパケット９５８ｂが到着した後にのみ、第１のフローレットが応答を生成することを意味し得る。この時点で、受信側９５０のトランスポートコンテキストは、フローレットの状態情報９５４ａを検証し、この情報を使用して第１のパケット９５８ａ及び第２のパケット９５８ｂが到着したことを示す累積応答を生成することができる。応答はさらに、これらのパケットがそれらの連続した順序で到着したことを示す可能性があり、これは、これまでに到着に失敗したパケットがないことを意味する。パケット９５８ａ、９５８ｂが順番に到着したため、応答はＡＣＫ９６０となり、ＡＣＫ９６０は最近受信したパケットのパケットシーケンス番号（つまり、第２のパケット９５８ｂ）を含むことになる。
他の状況では、第１のフローレットは、第１のパケット９５８ａ及び第２のパケット９５８ｂのそれぞれについてＡＣＫを生成している可能性がある。例えば、第１のフローレットは、第１のパケット９５８ａが到着した後と第２のパケット９５８ｂが到着した後の両方で応答を生成するようにスケジューリングされる可能性がある。両方の場合において、応答はＡＣＫとなり、それぞれは先行パケットのパケットシーケンス番号を伴う。
ＡＣＫ９６０を生成して送信した後、第１のフローレットは、少なくとも第１のパケット９５８ａの状態情報をクリアすることができ得る。フローレットは、最近受信したシーケンス番号を追跡するために、第２のパケット９５８ｂのパケットシーケンス番号を保持し得る。しかしながら、フローレットは、パケット自体を受信ユーザアプリケーション９５２に送信させ得る。一般的に、受信側９５０のトランスポートコンテキストは、パケットのバッファリングを回避し得、対象となるユーザアプリケーション９５２に可能な限り早急にパケットを送信し得る。
第２のフローレットの例の場合、状態情報９５４ｂは、２つのパケット、この場合は第１のパケット９６２ａ及び第３のパケット９６２ｃが到着したことを示し、第２のパケット９６２ｂは、第３のパケット９６２ｃが受信された時点で欠落していたことを示す。ここで、フローレットは、第１のパケット９６２ａが受信された後にＡＣＫを生成し得るが、第２のパケット９６２ｂがこの時点で欠落しているため、第３のパケット９６２ｃの後にＳＡＣＫ９６４を生成する。ＳＡＣＫ９６４は、第２のパケットが受信されなかったことを送信側９００のトランスポートコンテキストに通知し得る。例えば、ＳＡＣＫ応答は、ＳＡＣＫ９６０のメッセージ内の第１のパケット９６２ａ及び第３のパケット９６２ｃのパケットシーケンス番号を含み得る。ＳＡＣＫ応答はさらに累積的であってよい。例えば、この例のＳＡＣＫ９６４が送信される前に第４のパケットが到着する場合、フローレットは、第１のパケット９６２ａ、第３のパケット９６２ｃ及び第４のパケットの受信を示すＳＡＣＫを生成し得る。
この例を続けると、第２のフローレットが第１のパケット９６２ａ及び第３のパケット９６２ｃにＳＡＣＫ９６４を送信した後、欠落している第２のパケット９６２ｂが到着する可能性がある。第２のパケット９６２ｂは、例えば、ネットワーク９３０が遅いためにやっと到着したところであり得る。第２のパケット９６２ｂも、ＳＡＣＫ９６４に応答して到着した可能性があり、これは第２のパケット９６２ｂが再送されたことを意味する。この例では、第２のパケット９６２ｂが２回到着する。例えば、ＳＡＣＫ９６４がネットワーク９６４内にドロップされた可能性があるため、第２のパケット９６２ｂの第２のコピーが到着する可能性がある。追加的に、送信側９００のフローレットのタイマが期限切れになっている可能性があり、全ての未確認パケットが再送される可能性がある。状態情報９５４ｂは、受信側９５０のトランスポートコンテキストが、第２のパケット９６２ｂの第２のコピーが複製であることを認識することを可能にする。フローレットは、後続的に複製コピーをドロップし得る。
第３のフローレットの例の場合、状態情報９５４ｃは、３つのパケット９６６ａ〜ｃが到着したことを示す。フローレットは第１のパケット９６６ａを受け入れ、送信側９００のトランスポートコンテキストに通知するＡＣＫ９６８ａを生成する。しかしながら、フローレットは、第２のパケット９６６ｂ及び第３のパケット９６６ｃを受け入れない可能性がある。これは、例えば、受信ユーザアプリケーション９５２がメモリ内のバッファを使い果たし、これ以上パケットを受け入れ不可能である場合に生じ得る。これが生じると、フローレットは、受け入れられなかったパケット９６６ｂ、９６６ｃに対するＮＡＫ９６８ｂ、９６８ｃメッセージを生成し得る。
いくつかの実装では、受信側９５０のトランスポートコンテキストは、応答メッセージの生成を停止し得る。これは、新しいパケットが送信側９００でほぼ空のフローレットに追加されず、そのフローレットからのパケットがネットワーク内でドロップされた場合に生じ得る。受信側９５０のトランスポートコンテキストが応答、この場合にはパケットが欠落していることを示すＳＡＣＫを生成すると、受信側９５０のフローレットは別のパケットを受信する必要があり、これは、送信側９００のフローレットが新しいパケットを受信していないため、生じ得ない。いくつかの実装では、この状況を防止する１つの方法は、例えば、急激に少なくなっているフローレットにパケットを頻繁に割り当てることによって、フローレットがほとんど空にならないことを確実にすることである。いくつかの実装では、未処理パケットが滞留しているフローレットを防止する別の方法は、フローレットの数を動的に調整することである。いくつかの実装では、別の解決策は、未処理パケットを長時間有しているフローレットをタイムアウトさせ、それらのフローレットを別の経路に移動させ、それらのフローレットで未処理となっている任意のパケットを再送することである。
図９Ａ及び図９Ｂの例に例示するように、緩和された信頼可能なデータグラムトランスポートサービスは、全てのパケットが最終的に配信されることを保証するために、失われた可能性のあるパケットの応答及び再送を使用し得る。このように、パケットドロップ率の高いネットワーク９３０に対して緩和された信頼可能なデータグラムトランスポートを使用することができる。これらの例に例示するように、パケットは、パケットシーケンス番号に関する順序だけでなく、パケットの相関順序に関しても従わない順序で受信側９５０に到着し得る。
図１０Ａ〜図１０Ｂは、フローレット１００２ａ〜ｃに分割された単一のパケットフロー及び受信ユーザアプリケーションによってパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄが受信される順序の一例を例示する。この簡略化した例では、例示のパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、１つの送信ユーザアプリケーションによって送信されており、１つの受信ユーザアプリケーションによって受信されている。例示のパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄが送信ユーザアプリケーションによって送信される場合、この例では、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは特定の順番を有する。例えば、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、ビデオストリームの一部であってよく、ビデオストリームの連続フレームを搬送してよい。パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは送信ユーザアプリケーションによってシーケンス識別子を割り当てられ、受信アプリケーションにパケットの正しい順序を通知し得る。
上述の通り、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、最初に送信された順序ではない順序で受信ユーザアプリケーションに到着してよい。これは、他の理由の中でもとりわけ、ネットワーク内のドロップ、フローレットの経路変更及び／またはフローレットの再開に起因し得る。順不同で到着するパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、パケットの各グループがとるネットワーク上の経路の差異によっても生じ得る。パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、ゆえに、宛先システムに到着するときに並び替える必要があり得る。図１０Ａは、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄの経時的な到着及びパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄがメモリに格納され得る方法を例示する。図１０Ｂは、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄをそれらの目的の順番に配置する並び替えを例示する。
図１０Ａの例では、パケットフローは３つのフローレット１００２ａ〜ｃに分割されており、４つのパケットは各フローレット１００２ａ〜ｃ上で受信される。図１０Ａの例では、各パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄの到着を経時的に例示する。図１０Ａはさらに、パケットを受信するためにメモリに構成されたバッファ１０１０の一例を例示する。いくつかの実装では、バッファ１０１０は、受信ユーザアプリケーションによって事前に構成されている。これらの実装では、バッファ１０１０は、ホストデバイスのメモリ内に構成されてよい。
上述の通り、各フローレット１００２ａ〜ｃ内のパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、それぞれのフローレット１００２ａ〜ｃ内でその順序を確立し得るパケットシーケンス番号を割り当てられ得る。この例では、パケットシーケンス番号は、文字ａ、ｂ、ｃ及びｄによって表される。第１のフローレット１００２ａでは、第２のパケット１００４ｂが最初に到着し、第１のパケット１００４ａ、第４のパケット１００４ｄ及び第３のパケット１００４ｃが続く。前に記した通り、パケット１００４ａ〜ｄが到着する順序は、パケットドロップ、パケット再送及び不完全なネットワークに生じ得る他の問題に起因し得る。第２のフローレット１００２ｂでは、第１のパケット１００６ａが最初に到着し、次いで、第４のパケット１００６ｄ、第２のパケット１００６ｂ及び次いで第３のパケット１００６ｃがその順序で到着する。第３のフローレット１００２ｃでは、第１のパケット１００８ａが最初に到着し、次いで、しばらくしてから、第２のパケット１００８ｂ、第４のパケット１００８ｄ及び第３のパケット１００８ｃが到着する。
この例を説明するために、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、宛先システムにおいて受信される順序でバッファ１０１０内に配置される。さらに、この例を説明するために、バッファ１０１０は左から右に詰められる。バッファ１０１０は、別様には任意の便宜的な順序で詰められてよいことが理解される。この例では、場合によっては、バッファ１０１０の一部が占有されているか１０１２、または別様には利用不可能である。
フローレット１００２ａ〜ｃ内のパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、フローレット１００２ａ〜ｃ内の他のパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄに関する到着順序を有する一方、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄはさらにフローレット１００２ａ〜ｃを通過する到着順序を有する。この例では、第１のフローレット１００２ａが最初にパケット１００４ｂを配信し、その後すぐに第３のフローレット１００８ａを配信する。これらの２つのパケット１００４ｂ、１００８ａはその順序でバッファ１０１０に書き込まれ得る。いくつかの場合、これらの最初の２つのパケット１００４ｂ、１００８ａはフローレット１００２ａ〜ｃによってほぼ同時に（例えば、同じクロックサイクルで）配信されてよい。このような場合、パケット１００４ｂ、１００８ａが格納される順序はそれらのフローレット１００２ａ、１００２ｃの識別に基づき得るか、または格納順序は任意であり得る。
この例を続けると、パケット１００８ａの次に、第２のフローレット１００２ｂからの２つのパケット１００６ａ、１００６ｄ、第１のフローレット１００２ａからのパケット１００４ａが続き得る。第３のフローレット１００２ｃは次のパケット１００８ｂを提供し、次に第１のフローレット１００２ａ、第２のフローレット１００２ｂ及び第３のフローレット１００２ｃから、それぞれパケット１００４ｄ、１００６ｂ、１００８ｄが続き得る。この例の最後の３つのパケット１００６ｃ、１００４ｃ、１００８ｃは、それぞれ第２のフローレット１００２ｂ、第１のフローレット１００２ａ及び第３のフローレット１００２ｃによって配信される。
一旦バッファ１０１０に格納されると、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、それらのフローレット１００２ａ〜ｃに関して順序通りでなくなるだけでなく、互いに関しても順序通りでなくなる。図１０Ｂは、並び替えが行われ、それらの目的の順番に配置されるパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄを例示する。上記の通り、送信ユーザアプリケーションは、各パケットにシーケンス識別子を割り当て得る。この例では、第１のフローレット１００２ａ上で送信されたパケットのグループ１００４ａ〜ｄが順番の最初にあり、第２のフローレット１００２ｂからのパケットのグループ１００６ａ〜ｄ及び第３のフローレット１００２ｃからのパケットのグループ１００８ａ〜ｄが続く。
パケットの並び替えは、ドライバプログラム及び／または受信ユーザアプリケーションによって実行されてよい。ドライバプログラムがパケットの並び替えを管理する実装では、ドライバプログラムは、受信ユーザアプリケーションがパケットにアクセスする前にパケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄを並び替えてよい。追加のメモリ１０２０は、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄを並び替えるために利用可能であってよく、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、それらの適切な順序でこの追加メモリ１０２０にコピーされてよい。代替的または追加的には、パケット１００４ａ〜ｄ、１００６ａ〜ｄ、１００８ａ〜ｄは、バッファ１０１０の間でそれらをコピーすることによって並び替えられてよい。
ＩＩＩ．方法
図１１〜図１４は、カーネルバイパスフレームワークを使用してネットワーク上でパケットを送信するためのプロセスの例であり、いくつかの実装では、緩和された信頼可能なデータグラムトランスポートサービスを例示する。これらのプロセスは、上記システム、例えば、図４、図５Ａ〜図５Ｂ、図６Ａ〜図６Ｂ及び図７Ａ〜図７Ｂに関して記載したシステムなどによって実施されてよい。理解を容易にするために、各プロセス例のステップが例示されており、個々のステップは、与えられた以外の順序で実行されてよく、追加のステップを含んでよく、及び／またはより少ないステップに組み合わされてよい。
図１１は、ネットワークを通るメッセージを送信しようとしているユーザアプリケーションについてトランスポートコンテキストを決定し得るプロセス１１００の一例を例示する。プロセス１１００の例は、カーネルバイパスフレームワークを実装するように構成されたネットワークアダプタデバイスによって実行されてよい。ネットワークアダプタデバイスは、ホストデバイスと通信してよく、ホストデバイスは、ネットワーク上でメッセージを送信しようとするユーザアプリケーションを実行中であってよい。
ステップ１１０２において、ネットワークアダプタデバイスは、メッセージ及びメッセージに関連する宛先情報を受信し得る。メッセージ及び宛先情報は、ホストデバイスから受信されてよい。メッセージは、ほとんどの場合、ホストデバイス上で実行中のユーザアプリケーションによって生成されてよい。宛先情報は、一般的に、ネットワーク内のどこにメッセージを送信すべきかを表す。ほとんどの場合、宛先情報は送信ユーザアプリケーションによって提供される。
ステップ１１０４では、ネットワークアダプタデバイスは宛先情報を検証し得る。宛先情報は、メッセージの対象となる受信者を様々な方法で表し得る。この例では、宛先情報はネットワークアドレス１１０６であってよく、例えば、ネットワーク上のシステムのＩＰアドレスまたはＭＡＣアドレス及び／またはネットワーク上のシステム上で動作中の仮想マシンのＩＰアドレスなどである。代替的または追加的には、宛先情報は、パケットフローのフロー識別子１１０８であってよい。フロー識別子１１０８は数値であってよく、及び／またはフローの送信元アドレスと宛先アドレスとの組み合わせであってよい。代替的または追加的には、宛先情報はアドレスハンドル１１１０であってよい。アドレスハンドル１１１０は、パケットを生成するために必要となり得るトランスポートコンテキスト及び／または情報を参照するソフトウェア変数またはポインタであってよい。例えば、アドレスハンドル１１１０は、ネットワークアドレスマップオブジェクトへの参照であってよい。アドレスマップオブジェクトは、適切なトランスポートコンテキストへの参照を格納してよく、事前生成パケットヘッダなどのパケットを送信するための情報をさらに格納してよい。ステップ１１１２では、ネットワークアダプタデバイスは、アドレスハンドル１１１０を使用して、ネットワークアドレスマップオブジェクトを決定してよい。
ステップ１１１４では、ネットワークアダプタデバイスは、宛先情報を使用して、トランスポートコンテキストを決定し得る。ほとんどの実装では、トランスポートコンテキストの決定は、ネットワーク上の特定の宛先に関連しており、ここで、宛先はネットワーク上のシステム、及び／またはネットワーク上のシステム上で動作中の仮想マシン、及び／またはネットワーク上のシステム上で動作中のユーザアプリケーション（場合によっては仮想マシンで動作中である）である。トランスポートコンテキストはネットワーク上でメッセージの送信を管理してよく、これには、メッセージの対象となる宛先にメッセージが到着することを保証することが含まれる。いくつかの実装では、トランスポートコンテキストは、緩和された信頼可能なデータグラムトランスポートサービスを使用して実装される。
プロセス１１００の例について、いくつかの任意のステップがさらに例示されている。第１の任意のステップ１１１６では、ネットワークアダプタデバイスは、メッセージ及び決定されたトランスポートコンテキストを使用してパケットを生成してよい。パケットを生成することは、パケットヘッダを生成すること及びメッセージ本体をパケットペイロードに配置することを含んでよい。いくつかの実装では、事前生成ヘッダが、決定されたトランスポートコンテキストに関連してよい。事前生成パケットヘッダは、送信元及び宛先アドレス及び／またはポートなど、ネットワーク上でパケットをルーティングするための情報を含んでよい。トランスポートコンテキストは、一般的に、特定の宛先に関連しているため、ルーティング情報を事前に把握でき、ネットワークアダプタデバイスによってパケットヘッダを事前に生成して格納してよい。
第２の任意のステップ１１１８では、ネットワークアダプタデバイスは、決定されたトランスポートコンテキストを使用して、ステップ１１１６で生成されたパケットを送信してよい。
図１２は、アドレスハンドルを取得するためのプロセス１２００の一例を例示する。プロセス１２００の例は、ネットワークアダプタデバイスによって実行されてよい。ネットワークアダプタデバイスは、ホストデバイスと通信していてよく、ホストデバイスは、ネットワーク上でメッセージを送信しようとするユーザアプリケーションを実行中であってよい。
ステップ１２０２では、ネットワークアダプタデバイスは、新しいアドレスハンドルの要求を受信してよい。要求は、ユーザアプリケーションによって生成されてよく、ネットワーク上の宛先を表す情報を含んでよい。いくつかの実装では、ネットワークアダプタデバイスは、例えば、ネットワークアダプタデバイス上のメモリに格納され得るアドレスマップにアクセスしてよい。アドレスマップは、ホストデバイス上で動作中のユーザアプリケーションが通信しようとするネットワーク上のシステムのためのアドレス情報を格納してよい。ネットワークアダプタデバイスは、ステップ１２０４では、アドレスマップを使用して、ステップ１２０２で受信した要求が新しい宛先に対するものかどうかを判断してよい。この要求は、要求に提供されるアドレス情報がネットワークアダプタデバイスにとって未知である場合に、新しい宛先に対するものである。例えば、ネットワークアダプタデバイスは、既知の宛先を格納するアドレスマップ内の宛先情報を発見できない場合がある。
新しいアドレスハンドルの要求が新しい宛先に対してではない場合、ステップ１２０６において、ネットワークアダプタデバイスは、宛先情報を使用して、トランスポートコンテキストを決定してよい。決定されたトランスポートコンテキストは、トランスポートコンテキストに関連する宛先のアドレスハンドルに対する以前の要求によって構成されてよい。ネットワークアダプタデバイスは、例えば、宛先情報を使用してアドレスマップをインデックス化し、アドレスマップから正しいトランスポートコンテキスト（またはトランスポートコンテキストを表すデータ構造）への参照を抽出することによって、トランスポートコンテキストを決定してよい。
新しいアドレスハンドルの要求が新しい宛先に対するものである場合、ネットワークアダプタデバイスは、ステップ１２１０において、宛先情報によって表された宛先の新しいトランスポートコンテキストを生成してよい。ステップ１２１２では、ネットワークアダプタデバイスは、新しい接続に対する状態情報を新しいトランスポートコンテキストに格納してよい。このステップは、ステップ１２０８で確立された接続にトランスポートコンテキストを関連させることを含んでよい。トランスポートコンテキストは、その後、例えば、ネットワークを通る経路の設定及び解除、パケットの送信及び／または未処理パケットの状態情報の管理を含む、接続の管理を行ってよい。
ステップ１２１６では、ネットワークアダプタデバイスは、新しいアドレスマップオブジェクトを生成してよい。新しいアドレスマップオブジェクトを生成することは、パケットをネットワーク上の宛先にルーティングするための送信元及び宛先情報を含む事前構成パケットヘッダを生成して格納することを含んでよい。新しいアドレスマップオブジェクトはさらに、ステップ１２１０で生成された新しいトランスポートコンテキストまたはステップ１２０６で決定されたトランスポートコンテキストに関連してよい。
ステップ１２０８では、ネットワークアダプタデバイスは、宛先情報に関連するネットワーク上のシステムとの新しい接続を確立してよい。新しい接続を確立することは、要求ユーザアプリケーションが宛先システムとの通信を許可されていることをチェックするなどの、検証ステップを含んでよい。接続を確立することはさらに、ネットワークアダプタデバイスと宛先システムとの間のメッセージ交換を含んでよい。いくつかの実装では、ネットワークアダプタデバイスは、以下に説明するステップ１２１８及び１２２０の後に新しい接続を確立してよい。いくつかの実装では、ネットワークアダプタデバイスは、ステップ１２１８及び１２２０の後に、他の動作を実行しながら接続を確立してよい。いくつかの実装では、ネットワークアダプタデバイスは、ステップ１２２０で返送されたアドレスハンドルに関連する宛先システムにメッセージが最初に送信されるときに接続を確立してよい。
ステップ１２１８では、ネットワークアダプタは、新しいアドレスハンドルを生成してよい。アドレスハンドルは、新しいアドレスマップオブジェクトを参照してよく、例えば、アドレスハンドルは、ネットワークアダプタデバイスのメモリ内のアドレスへのソフトウェアポインタであってよい。
ステップ１２２０では、新しいアドレスハンドルを要求ユーザアプリケーションに返送してよい。要求ユーザアプリケーションは、将来の使用のために新しいアドレスハンドルを格納してよい。
図１３は、ネットワーク上でパケットを送信し、各パケットが配信されることを確実にするために各パケットの状態を監視するプロセス１３００の一例を例示する。プロセス１３００の例は、カーネルバイパスフレームワークを実装するように構成されたネットワークアダプタデバイスによって実行されてよい。いくつかの実装では、ネットワークアダプタデバイスは、緩和された信頼可能なデータグラムトランスポートサービスを使用して、パケットを送信し、それらの状態を監視してよい。
ステップ１３０２では、ネットワークアダプタデバイスは、メッセージ及び宛先情報を受信してよい。メッセージ及び宛先情報はホストデバイスから受信してよく、複数の送信キューからの送信キューで受信されてよい。宛先情報は、メッセージを受信することになるネットワーク上の宛先を表し得る。ネットワークアダプタデバイスは、キューペアの送信キューでメッセージを受信してよい。キューペアは、ホストデバイス上で実行中のユーザアプリケーションに関連してよい。
ステップ１３０４では、ネットワークアダプタデバイスは、宛先情報及び送信キューの識別を使用して、トランスポートコンテキストを決定してよい。ほとんどの実装では、トランスポートコンテキストは特定の宛先に関連してよく、ここで、宛先は、この例では、宛先情報及び／または送信キューの識別によって識別されてよい。送信キューの識別は、複数のキューペアの中から送信キューを識別するためにネットワークアダプタデバイスによって使用される英数字値であってよい。
ステップ１３０５では、ネットワークアダプタデバイスは、各メッセージに対していくつかのステップを実行してよい。まず、ステップ１３０６では、ネットワークアダプタデバイスは、決定されたトランスポートコンテキストを使用して、パケットを生成してよい。トランスポートコンテキストは、ポート番号、ネットワークアドレス及び／または事前生成パケットヘッダなど、対象となる宛先にネットワーク上でパケットをルーティングするために必要な情報を提供してよい。ネットワークアダプタデバイスは１つのパケットを生成し、そのメッセージをパケットのペイロードに配置してよい。代替的または追加的には、ネットワークアダプタデバイスは、２つ以上のパケットを生成してよく、各パケットは、メッセージの一部をパケットのペイロード内に含む。いくつかの実装では、トランスポートコンテキストは、各パケットにパケットシーケンス番号をさらに割り当ててよく、パケットシーケンス番号は、パケットが送信される順序を示す。
ステップ１３０８では、ネットワークアダプタデバイスは、トランスポートコンテキストを使用して、ネットワーク上で各パケットを送信してよい。トランスポートコンテキストは、各パケットの送信を管理してよい。ステップ１３１０では、ネットワークアダプタデバイスは、各送信パケットの状態をさらに監視してよい。トランスポートコンテキストはさらに、パケット状態の監視を管理してよい。各パケットの状態は、パケットが宛先システムで受信されたかどうかを示す。いくつかの実装では、トランスポートコンテキストは、ネットワーク上の宛先からの応答メッセージを予期することがあり、応答メッセージは、１つ以上のパケットが受信されたことを示す。
少なくとも３つのタイプの応答メッセージを受信してよい。まず、ステップ１３１２では、ネットワークアダプタデバイスは、１つ以上のパケットが宛先で受信されたことを示す応答メッセージを受信してよい。いくつかの実装では、この応答は、１つ以上のパケットが順序通りに受信されたことを示し、その順序はパケットシーケンス番号によって提供され、シーケンスから欠落しているパケットはない。例えば、応答は、パケット番号１、２及び３が受信されたことを示す「３」を示し得る。
第２に、ステップ１３１４では、ネットワークアダプタデバイスは、１つ以上のパケットが受信されなかったことを示す応答を受信してよい。いくつかの実装では、この応答メッセージは、到着したパケットのパケットシーケンス番号を提供し、シーケンス番号の抜けにより到着していないパケットを示してよい。例えば、応答のパケットシーケンス番号「１、３」は、シーケンス番号「２」のパケットがまだ到着していないことを示してよい。代替的には、いくつかの実装では、応答は、受信されなかったパケットのパケットシーケンス番号をリスト化してよい。例えば、応答のパケットシーケンス番号「２〜４」は、パケット２、３及び４がまだ到着していないことを示してよい。
第３に、ステップ１３１６では、ネットワークアダプタデバイスは、パケットを再送する要求を含む応答を受信してよい。いくつかの実装では、この応答は、パケットが宛先で受信されたが、パケットがどういうわけか受け入れられなかったことを示す。ステップ１３１８では、ネットワークアダプタデバイスは、この応答をホストデバイスに配信してよい。ホストデバイスは、パケットを再送する必要がある理由を判断することができ得る、及び／またはパケットを再送するために新しいメッセージを生成し得る。
ネットワークアダプタデバイスは、応答メッセージが受信されない、または応答メッセージが長期間受信されない状況に対しても構成され得る。例えば、ネットワークアダプタデバイスは、パケットがステップ１３１０で送信されたときにタイマを開始してよい。ステップ１３２０では、ネットワークアダプタデバイスは、タイマの期限が切れたと判断してよい。タイマの期限が切れると、ネットワークアダプタデバイスは以前に送信された１つ以上のパケットを再送してよい。ネットワークアダプタデバイスはさらに、ネットワーク上の宛先にパケットを送信するために使用されている経路を変更するなどの他の動作をとってよい。
図１４は、ネットワーク上でパケットを受信し、パケットが受信されたことを示すために各パケットの応答を生成するプロセス１４００の一例を例示する。プロセス１４００の例は、カーネルバイパスフレームワークを実装するように構成されるネットワークアダプタデバイスによって実行されてよい。いくつかの実装では、ネットワークアダプタデバイスは、緩和された信頼可能なデータグラムトランスポートサービスを使用して、パケットを受信し、応答を生成してよい。
ステップ１４０２では、ネットワークアダプタデバイスは、受信キューにおいてパケットを受信してよく、パケットは順不同で受信される。パケットは、ネットワーク上で受信されてよい。受信キューは、キューペアの一部であってよい。パケットの順序は、各パケットに割り当てられたパケットシーケンス番号によって決定されてよい。パケットシーケンス番号が数字順（例えば、最小から最大）でない場合、またはシーケンスからパケットシーケンス番号が欠落している（例えば、パケットがシーケンス番号「１、３」を有する）ためのいずれかの場合、パケットは順不同となり得る。
各パケットを受信すると、ネットワークアダプタデバイスは、ステップ１４０４において、パケットに関連するトランスポートコンテキストを識別し得る。ネットワークアダプタデバイスは、各パケットに提供された送信元アドレスからトランスポートコンテキストを識別してよい。識別されたトランスポートコンテキストは、パケットを送信している送信元システムとの接続を管理していてよい。トランスポートコンテキストはさらに、特定の送信元システムからのパケットの状態を監視していてよい。
ステップ１４０５では、ネットワークアダプタデバイスは、パケットが受け入れ可能かどうかを判断してよい。ネットワークアダプタデバイスは、例えば、ホストデバイスにパケットを配置するための利用可能なメモリがない場合にパケットを受け入れ不可能であると判断してよく、これは、パケットを受信するために利用可能なバッファがないことを意味する。これは、受信ユーザアプリケーションがパケットを受信するのに十分なメモリを割り当てていない、及び／またはメモリを十分に速く解放していない場合に生じ得る。いくつかの場合、送信ユーザアプリケーションに通知する必要があり、いくつかの場合、送信ユーザアプリケーションは、パケットを送信している速度を低下し得る。代替的または追加的には、ネットワークアダプタデバイスは、パケットが重複であると判断し得る。代替的または追加的には、ネットワークアダプタデバイスは、パケットが無効であると判断し得る。パケットは、有効なアドレスを持さない場合、不正確なアドレスが指定された場合、破損している場合、及び／または受信前に無効とマークされている場合などには無効となり得る。この例において、ステップ１４０５では、ネットワークアダプタデバイスは、パケットを受け入れ可能であると判断する。
ステップ１４０６では、ネットワークアダプタデバイスは、識別されたトランスポートコンテキスト及び受信キューの識別を使用して、パケットを受信するユーザアプリケーションを決定し得る。トランスポートコンテキストはパケットを検証してその宛先を決定し得る。例えば、パケットは宛先アドレスを有してよく、この宛先アドレスは、少なくとも部分的に、パケットを受信することになるユーザアプリケーションを識別し得る。受信キューの識別はさらに、部分的に、パケットを受信することになるユーザアプリケーションを識別し得る。受信キューの識別は、複数のキューペアの中から受信キューを識別するためにネットワークアダプタによって使用される英数字値であってよい。
ステップ１４０８では、ネットワークアダプタデバイスは、受信ユーザアプリケーションに関連するホストメモリ内のバッファに、受信キューからの受信パケットを転送し得る。ネットワークアダプタデバイスは、受信ユーザアプリケーションに割り当てられたメモリ用の登録キーを有し得る。ネットワークアダプタデバイスは、登録キーを使用して、受信ユーザアプリケーションに割り当てられたメモリにパケットを直接書き込み得る。受信ユーザアプリケーションは、ネットワークからパケットを受信するために、事前にこのメモリにバッファを構成してよい。
いくつかの実装では、ネットワークアダプタデバイスは、１つ以上のパケットを処理する際に、少なくとも３つの応答タイプのうちの１つを送信してよい。トランスポートコンテキストは、フロー内のパケットの状態を監視してよく、適切な応答を提供してよい。
まず、ステップ１４１０では、ネットワークアダプタデバイスは、１つ以上のパケットが受信されたことを示す応答を送信してよい。いくつかの実装では、この応答は、１つ以上のパケットが順序通りに受信されたことを示し、その順序は各パケットに割り当てられたパケットシーケンス番号によって提供され、シーケンスから欠落しているパケットはない。例えば、応答は、パケット番号１、２及び３が受信されたことを示す「３」を示し得る。
第２に、ステップ１４１２では、ネットワークアダプタデバイスは、１つ以上のパケットが受信されなかったことを示す応答を送信してよい。いくつかの実装では、この応答メッセージは、到着したパケットのパケットシーケンス番号を提供し、シーケンス番号の抜けにより到着していないパケットを示してよい。例えば、応答のパケットシーケンス番号「１、３」は、番号「２」のパケットが到着しなかったことを示してよい。代替的には、いくつかの実装では、応答は、受信されなかったパケットのパケットシーケンス番号をリスト化してよい。例えば、応答のパケットシーケンス番号「２〜４」は、パケット２、３及び４がまだ到着していないことを示してよい。
第３に、ステップ１４１４では、ネットワークアダプタデバイスは、上に提供した理由のうちの１つ以上により、別のパケットを受け入れ不可能であると判断してよい。このパケットを受け入れ不可能であると判断すると、ネットワークアダプタデバイスは、ステップ１４１６でそのパケットをドロップしてよい。ネットワークアダプタは、次いで、任意には、ステップ１４１８において、パケットを再送しようとすることを示す応答をネットワーク上で送信してよい。この応答は、パケットが到着したがパケットを受け入れ不可能であり、そのため再送する必要があり得ることを送信元システムに示してよい。
ＩＶ．ネットワークアダプタデバイス
図１５は、上記システム及び方法を実施するために使用され得るネットワークアダプタデバイス１５００の一例を例示する。この例では、ネットワークアダプタデバイス１５００は、処理コア１５０２、構成モジュール１５０４、管理モジュール１５０６、バスインタフェースモジュール１５０８、メモリ１５１０及びネットワークインタフェースモジュール１５１２を含み得る。これらのモジュールは、ハードウェアモジュール、ソフトウェアモジュールまたはハードウェアとソフトウェアとの組み合わせであり得る。ネットワークアダプタデバイス１５００は、図面には例示されていない追加のモジュールを含み得る。いくつかの実装では、ネットワークアダプタデバイス１５００は、より少ないモジュールを含み得る。モジュールのうちの１つ以上は通信チャネル１５１４上で互いに通信し得る。通信チャネル１５１４は、１つ以上のバス、メッシュ、マトリクス、ファブリック、これらの通信チャネルの組み合わせまたはいくつかの他の適切な通信チャネルを含み得る。いくつかの実装では、ネットワークアダプタデバイス１５００の動作は、単一の集積回路または集積回路のグループに実装されてよい。集積回路の例には、ＡＳＩＣ及びＦＰＧＡが含まれる。
いくつかの実装では、処理コア１５０２は、命令を実行するように構成された１つ以上のプロセッサを含み得る。処理コア１５０２に含まれ得るプロセッサの例には、ＡＲＭ、ＭＩＰＳ、ＡＭＤ、Ｉｎｔｅｌ、Ｑｕａｌｃｏｍｍ及びその他によって開発されたプロセッサが含まれる。いくつかの実装では、処理コア１５０２のプロセッサは、例えば、バス、レベル１（Ｌ１）キャッシュ及び／またはレベル２（Ｌ２）キャッシュなどの特定のリソースを共有し得る。処理コア１５０２によって実行される命令は、例えば、コンピュータプログラムの形態でコンピュータ可読記憶媒体に格納されてよい。コンピュータ可読記憶媒体は非一時的であり得る。いくつかの場合、コンピュータ可読媒体はメモリ１５１０の一部であってよい。いくつかの実装では、処理コア１５０２の動作（処理コア１５０２によって実行される命令の一部または全てを含むことがあるが、必ずしもそうではない）は、１つ以上の集積回路に実装されてよい。集積回路の例には、ＡＳＩＣ及びＦＰＧＡが含まれる。
メモリ１５１０は、揮発性または不揮発性のいずれか、または揮発性と不揮発性との両方のタイプのメモリを含み得る。メモリ１５１０は、例えば、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、及び／またはいくつかの他の適切な記憶媒体を含み得る。いくつかの場合、メモリ１５１０の一部または全てがネットワークアダプタデバイス１５００の内部にあってよく、他の場合には、メモリの一部または全てがネットワークアダプタデバイス１５００の外部にあってよい。
いくつかの実装では、構成モジュール１５０４は、１つ以上の構成レジスタを含み得る。構成レジスタは、ネットワークアダプタデバイス１５００の動作を制御し得る。いくつかの実装では、構成レジスタの１つ以上のビットは、ネットワークアダプタデバイス１５００の特定の能力を表わすことができる。構成レジスタは、処理コア１５０２で実行中の命令によって、及び／またはホストデバイス、ホストデバイス上で実行中のオペレーティングシステム、及び／またはリモートサーバなどの外部エンティティによってプログラムされ得る。構成モジュール１５０４はさらに、ネットワークアダプタデバイス１５００の動作を制御するハードウェア及び／またはソフトウェアを含み得る。
いくつかの実装では、管理モジュール１５０６は、ネットワークアダプタデバイス１５００の異なる構成要素を管理するように構成され得る。いくつかの場合、管理モジュール１５０６は、電源投入時に１つ以上の構成レジスタの１つ以上のビットを構成し、ネットワークアダプタデバイス１５００の特定の機能を有効または無効にし得る。
バスインタフェースモジュール１５０８は、外部通信媒体上で、ホストデバイス及び／またはコンピューティングシステム内の他の構成要素などの外部エンティティとの通信を可能にし得る。バスインタフェースモジュール１５０８は、ケーブル、ソケット、ポートに接続する物理インタフェースまたは外部通信媒体への他の接続を含み得る。バスインタフェースモジュール１５０８はさらに、受信及び送信トランザクションを管理するためのハードウェア及び／またはソフトウェアを含み得る。バスインタフェースモジュール１５０８は、ＮＶＭｅ、ＡＨＣＩ、ＳＣＳＩ、ＳＡＳ、ＳＡＴＡ、ＰＡＴＡ及びその他などのローカルバスプロトコルを実装し得る。バスインタフェースモジュール１５０８は、コネクタ、電力管理、エラー処理などを含む、これらのバスプロトコルのうちの任意のための物理層を少なくとも含み得る。いくつかの実装では、ネットワークアダプタデバイス１５００は、複数の外部エンティティと通信するための複数のバスインタフェースモジュールを含み得る。これらの複数のバスインタフェースモジュールは、同じローカルバスプロトコル、異なるローカルバスプロトコルまたは同じバスプロトコルと異なるバスプロトコルとの組み合わせを実装し得る。
ネットワークインタフェースモジュール１５１２は、ネットワークと通信するためのハードウェア及び／またはソフトウェアを含み得る。このネットワークインタフェースモジュール１５１２は、例えば、ネットワークへの有線接続のための物理的コネクタ及び／またはネットワークへの無線通信のためのアンテナを含み得る。ネットワークインタフェースモジュール１５１２はさらに、ネットワークプロトコルスタックを実装するように構成されたハードウェア及び／またはソフトウェアを含み得る。ネットワークインタフェースモジュール１５１２は、とりわけ、例えば、ＴＣＰ／ＩＰ、Ｉｎｆｉｎｉｂａｎｄ、ＲｏＣＥ、米国電気電子技術者協会（ＩＥＥＥ）８０２．１１無線プロトコル、ユーザデータグラムプロトコル（ＵＤＰ）、非同期転送モード（ＡＴＭ）、トークンリング、フレームリレー、高レベルデータリンク制御（ＨＤＬＣ）、ファイバ分散データインタフェース（ＦＤＤＩ）及び／またはポイントツーポイントプロトコル（ＰＰＰ）などのネットワークプロトコルを使用してネットワークと通信し得る。いくつかの実装では、ネットワークアダプタデバイス１５００は、それぞれが異なるネットワークと通信するように構成された複数のネットワークインタフェースモジュールを含み得る。例えば、これらの実装では、ネットワークアダプタデバイス１５００は、有線イーサネットネットワーク、無線８０２．１１ネットワーク、セルラネットワーク、Ｉｎｆｉｎｉｂａｎｄネットワークなどと通信するためのネットワークインタフェースモジュールを含み得る。
いくつかの実装では、ネットワークアダプタデバイス１５００は、ＰＣＩタイプのデバイスである。これらの実装では、ネットワークアダプタデバイス１５００は、ホストデバイスと通信するためのＰＣＩインタフェースを含む。「ＰＣＩ」という用語は、最初のＰＣＩ規格、ＰＣＩ−Ｘ、ＡＧＰ及びＰＣＩｅを含む、ＰＣＩ系列のバスプロトコルの任意のプロトコルを表すために使用され得る。ＰＣＩプロトコルは、ローカル周辺装置をホストデバイスに接続するための標準バスプロトコルである。標準化されたバスプロトコルは、様々な製造者によって仕様が定義されて採用されているデータトランスポートプロトコルである。製造者は、準拠したデバイスがバスプロトコルを実装しているコンピューティングシステムと互換性があり、逆も同じであることを確実にする。
ＰＣＩデバイスは、１つ以上の機能を含み得る。「機能」はネットワークアダプタデバイス１５００によって提供され得る動作を表す。機能の例には、とりわけ、大容量記憶コントローラ、ネットワークコントローラ、ディスプレイコントローラ、メモリコントローラ、シリアルバスコントローラ、無線コントローラならびに暗号化及び復号コントローラが含まれる。いくつかの場合、ＰＣＩデバイスは２つ以上の機能を含み得る。例えば、ＰＣＩデバイスは、大容量記憶コントローラ及びネットワークアダプタを提供し得る。別の例として、ＰＣＩデバイスは、２つの異なるストレージリソースを制御するために、２つのストレージコントローラを提供し得る。いくつかの実装では、ＰＣＩデバイスは最大８つの機能を有し得る。
いくつかの実装では、ネットワークアダプタデバイス１５００は、シングルルートＩ／Ｏ仮想化（ＳＲ−ＩＯＶ）を含み得る。ＳＲ−ＩＯＶは、ＰＣＩデバイスに含まれ得る拡張機能である。ＳＲ−ＩＯＶによって、物理リソース（例えば、単一のネットワークインタフェースコントローラ）は複数のリソース（例えば、６４のネットワークインタフェースコントローラ）として現われることができる。ゆえに、ある特定の機能性（例えば、ネットワークインターフェースコントローラ）を提供するＰＣＩデバイスは、ＰＣＩデバイスを利用しているデバイスにとって、同じ機能性を提供している複数のデバイスとして現れ得る。ＳＲ−ＩＯＶ対応ストレージアダプタデバイスの機能は、物理機能（ＰＦ）または仮想機能（ＶＦ）として分類され得る。物理的機能は、デバイスの完全に機能化された機能であり、検出、管理及び操作が可能である。物理機能は、ストレージアダプタデバイスを構成または制御するために使用できる構成リソースを有する。物理機能には、仮想化されていないデバイスと同じ構成アドレス空間及びメモリアドレス空間が含まれる。物理機能は、それに関連したいくつかの仮想機能を有し得る。仮想機能は物理機能に類似しているが、構成リソースが不足している小型の機能であり、一般的には基礎となる物理機能の構成によって制御される。物理機能及び／または仮想機能のそれぞれは、ホストデバイス上で動作中のそれぞれの実行スレッド（例えば、仮想マシンなど）に割り当てられてよい。
Ｖ．コンピューティングシステム
図１６は、本明細書に記載された機能及びシステムのためのアーキテクチャ１６００の例を例示する。アーキテクチャ１６００の例は、１つ以上のネットワーク１６０８を介して接続される１つ以上のサービスプロバイダコンピュータ１６１０及び／またはユーザデバイス１６０４を含む。上述のシステム及び方法は、図１６に記載されたコンピューティングデバイスの１つ以上の構成要素を使用し得るか、または図１６に記載された１つ以上のコンピューティングデバイスを表し得る。
例示のアーキテクチャ１６００においては、１つ以上のユーザ１６０２は、ユーザコンピューティングデバイス１６０４（１）〜（Ｎ）を使用して、アプリケーション１６０６（例えば、ウェブブラウザまたはモバイルデバイスのアプリケーション）に１つ以上のネットワーク１６０８を介してアクセスし得る。いくつかの態様では、アプリケーション１６０６は、コンピューティングリソースサービスまたはサービスプロバイダによってホスト、管理及び／または提供され得る。１つ以上のサービスプロバイダコンピュータ１６１０は、ユーザ（複数可）１６０２が相互作用し得るユーザデバイス１６０４上で動作するように構成されるネイティブアプリケーションを提供し得る。いくつかの例では、サービスプロバイダコンピュータ（複数可）１６１０は、以下に限定されないが、クライアントエンティティ、低レイテンシデータストレージ、永続データストレージ、データアクセス、管理、仮想化、クラウドベースのソフトウェアソリューション、電子コンテンツの性能管理及びその他などのコンピューティングリソースを提供し得る。サービスプロバイダコンピュータ（複数可）１６１０も、ウェブホスティング、データベース化、コンピュータアプリケーション開発及び／または実装のプラットフォーム、ユーザ（複数可）１６０２に対する前述のものまたはその他等の組み合わせを提供するように動作可能であり得る。サービスプロバイダコンピュータ（複数可）１６１０は、いくつかの例では、１つ以上の第三者コンピュータ１６１２と通信し得る。
いくつかの例では、ネットワーク（複数可）１６０８は、ケーブルネットワーク、インターネット、無線ネットワーク、セルラネットワークならびに他の私設及び／または公衆ネットワークなどの、多くの異なるタイプのネットワークのうちいずれか１つ、またはそれらの組み合わせを含み得る。例示の例は、ネットワーク（複数可）１６０８上でアプリケーション１６０６にアクセスするユーザ（複数可）１６０２を表す一方、記載された技法は、固定電話上のユーザデバイス（複数可）１６０４を介して、電話ボックスを介してまたはいくつかの他の方式でユーザ（複数可）１６０２がサービスプロバイダコンピュータ（複数可）１６１０と相互作用する場合に等しく適用し得る。非クライアント／サーバの配置（例えば、ローカルに格納されるアプリケーション等）と同様に、記載された技法はさらに、他のクライアント／サーバの配置（例えば、セットトップボックス等）に適用し得る。
上述の通り、アプリケーション１６０６は、例えば、ウェブコンテンツ（例えば、ウェブページ、音楽、ビデオ等）にアクセスするサービスプロバイダコンピュータ（複数可）１６１０とユーザ（複数可）１６０２が相互作用することを可能にし得る。サービスプロバイダコンピュータ（複数可）１６１０は、サーバのクラスタまたはサーバファームにおいて配置され得、アプリケーション１６０６及び／またはクラウドベースのソフトウェアサービスをホストし得る。他のサーバ構造はさらに、アプリケーション１６０６をホストするために使用され得る。アプリケーション１６０６は、多くのユーザ１６０２からの要求の処理をし、応答として、例えば、様々な項目ウェブページを提供することが可能であり得る。アプリケーション１６０６は、ソーシャルネットワーキングサイト、オンライン小売業者、情報サイト、ブログサイト、検索エンジンサイト、ニュース及びエンタテインメントサイト及びその他を含むユーザの相互作用を支援する任意のタイプのウェブサイトを提供可能である。上述の通り、説明した技法は、ユーザデバイス（複数可）１６０４上で動作中の他のアプリケーションなどのアプリケーション１６０６の外部で同様に実施されることが可能である。
ユーザデバイス１６０４（複数可）は、例えば、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップコンピュータ、ネットブックコンピュータ、デスクトップコンピュータ、シンクライアントデバイス、タブレットコンピュータ、電子ブック（ｅブック）リーダ、ゲーミングコンソール等などの、コンピューティングデバイスであり得る。いくつかの例では、ユーザデバイス（複数可）１６０４は、ネットワーク（複数可）１６０８を介してまたは他のネットワーク接続を介して、サービスプロバイダコンピュータ（複数可）１６１０と通信し得る。追加的には、ユーザデバイス（複数可）１６０４は、サービスプロバイダコンピュータ（複数可）１６１０（例えば、サービスプロバイダコンピュータ１６１０に統合されたコンソールデバイス）によって管理及び制御される分散システムの一部であり得るか、または別様にはサービスプロバイダコンピュータ（複数可）１６１０の一部であり得る。
１つの構成例において、ユーザデバイス（複数可）１６０４は、少なくとも１つのメモリ１６１４及び１つ以上の処理ユニット（またはプロセッサ（複数可）１６１６）を含み得る。プロセッサ（複数可）１６１６は、ハードウェア、コンピュータ実行可能命令、ファームウェアまたはそれらの組み合わせで実装され得る。コンピュータ実行可能命令またはプロセッサ（複数可）１６１６のファームウェア実装は、記載された様々な機能を行うために好適な任意のプログラミング言語で書かれたコンピュータで実行可能または機械で実行可能な命令を含み得る。ユーザデバイス（複数可）１６０４はさらに、ユーザデバイス（複数可）１６０４と関連する地理的位置情報を提供及び／または記録するための測位デバイス（例えば、衛星測位システム（ＧＰＳ）デバイスまたはその他）を含み得る。
ユーザデバイスメモリ１６１４は、これらのプログラムの実行中に生成されるデータと同様に、ユーザデバイスプロセッサ（複数可）１６１６に搭載可能で、かつ実行可能なプログラム命令を格納し得る。ユーザデバイス（複数可）１６０４の構成及びタイプにより、ユーザデバイスメモリ１６１４は、揮発性（ランダムアクセスメモリ（ＲＡＭ）及び／または不揮発性（読み出し専用メモリ（ＲＯＭ）、フラッシュメモリ等）であり得る。ユーザデバイス（複数可）１６０４はさらに、取り外し可能なストレージ及び／または取り外し不可能なストレージを含み得るが、磁気ストレージ、光ディスク、ソリッドステートディスク、フラッシュメモリ及び／またはテープストレージに限定されない。ストレージデバイス及びそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール及びコンピューティングデバイス用の他のデータの不揮発性ストレージを提供し得る。いくつかの実装では、メモリ１６１４は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）またはＲＯＭなどの複数の異なるタイプのメモリを含み得る。
ユーザデバイスメモリ１６１４の内容をより詳細に見ると、メモリ１６１４は、本明細書で開示される機能を実装するためのオペレーティングシステム及び１つ以上のアプリケーションプログラムまたはサービスを含み得る。１つ以上のアプリケーションプログラムまたはサービスは、ブラウザアプリケーション１６０６または専用のアプリケーション（例えば、スマートフォンのアプリケーション、タブレットのアプリケーション等）などの少なくともユーザが提供した入力要素または電子サービスのウェブページを含み得る。ブラウザアプリケーション１６０６は、サービスプロバイダコンピュータ（複数可）１６１０と相互作用するウェブサイトまたは他のインタフェースを受信、格納及び／または表示するように構成され得る。追加的に、メモリ１６１４は、アクセスの認証情報及び／または、例えば、ユーザＩＤ、パスワード及び／または他のユーザ情報などの他のユーザ情報を格納し得る。いくつかの例では、ユーザ情報は、アカウントへのアクセス要求を認証するための情報を含み得る。このような情報は、例えば、デバイスのＩＤ、クッキー、ＩＰアドレス、位置またはその他を含む。加えて、ユーザ情報は、ユーザデバイス１６０４によって取得されたセキュリティの質問に対してユーザが提供した応答または地理的位置を含み得る。
いくつかの態様では、サービスプロバイダコンピュータ（複数可）１６１０は、携帯電話、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、ネットブックコンピュータ、サーバコンピュータ、シンクライアントデバイス、タブレットコンピュータ、ゲーミングコンソール等などの、コンピューティングデバイスを含み得る。追加的または代替的には、いくつかの実施形態では、サービスプロバイダコンピュータ（複数可）１６１０は、ホスト型コンピューティング環境で実装される１つ以上の仮想マシンによって提供され得る。ホスト型コンピューティング環境は、１つ以上の迅速にプロビジョニングされ、解放されるコンピューティングリソースを含んでよい。これらのコンピューティングリソースは、コンピューティング、ネットワーキング及び／またはストレージデバイスを含み得る。ホスト型コンピューティング環境はさらに、クラウド型コンピューティング環境と呼ばれ得る。いくつかの例では、サービスプロバイダコンピュータ（複数可）１６１０は、ユーザデバイス（複数可）１６０４及び／または他のサービスプロバイダとネットワーク（複数可）１６０８または他のネットワーク接続を介して通信し得る。サービスプロバイダコンピュータ（複数可）１６１０は、場合により、互いに関連しないサーバファームまたは個別のサーバとしてクラスタに配置される１つ以上のサーバを含み得る。これらのサーバは、統合され、分散されたコンピューティング環境の一部として構成され得る。
１つの構成例においては、サービスプロバイダコンピュータ（複数可）１６１０は、少なくとも１つのメモリ１６１８及び１つ以上の処理ユニット（またはプロセッサ（複数可）１６２０）を含み得る。プロセッサ（複数可）１６２０は、ハードウェア、コンピュータ実行可能命令、ファームウェアまたはそれらの組み合わせにおいて実装され得る。コンピュータ実行可能命令またはプロセッサ（複数可）１６２０のファームウェア実装は、記載された様々な機能を行うために任意の好適なプログラミング言語で書かれたコンピュータで実行可能または機械で実行可能な命令を含み得る。
いくつかの場合、ハードウェアプロセッサ（複数可）１６２０は、シングルコアプロセッサまたはマルチコアプロセッサであり得る。マルチコアプロセッサは、同一のプロセッサ内に多数の処理ユニットを含み得る。いくつかの実施形態では、マルチコアプロセッサは、バス及び第２または第３レベルのキャッシュなどの特定のリソースを共有し得る。いくつかの場合、シングルまたはマルチコアプロセッサのそれぞれのコアもまた、多数の実行論理プロセッサ（または実行スレッド）を含み得る。このようなコア（例えば、多数の論理プロセッサを備えるコア）においては、実行パイプライン及びさらに低レベルキャッシュのいくつかのステージもまた共有され得る。
メモリ１６１８は、これらのプログラムの実行中に生成されるデータと同様に、プロセッサ（複数可）１６２０に搭載可能で、かつ実行可能なプログラム命令を格納し得る。サービスプロバイダコンピュータ（複数可）１６１０の構成及びタイプにより、メモリ１６１８は、揮発性（ＲＡＭのような）及び／または不揮発性（ＲＯＭ、フラッシュメモリ等）であり得る。メモリ１６１８は、オペレーティングシステム１６２８、１つ以上のデータストア１６３０、１つ以上のアプリケーションプログラム１６３２、１つ以上のドライバ１６３４及び／または本明細書に開示する機能を実装するためのサービスを含み得る。
オペレーティングシステム１６２８は、タスクのスケジューリング、アプリケーション及び／またはコントローラ周辺装置の実行などのサービスプロバイダコンピュータ１６１０の基本機能を支援し得る。いくつかの実装では、サービスプロバイダコンピュータ１６１０は、１つ以上の仮想マシンをホストし得る。これらの実装では、各仮想マシンは、独自のオペレーティングシステムを実行するように構成され得る。オペレーティングシステムの例には、Ｕｎｉｘ、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ、Ｍａｃ ＯＳ、ｉＯＳ、Ａｎｄｒｏｉｄ及びその他が含まれる。オペレーティングシステム１６２８はさらに、専有オペレーティングシステムであり得る。
データストア１６３０は、オペレーティングシステム１６２８、アプリケーションプログラム１６３２またはドライバ１６３４によって使用及び／または操作される永久または一時データを含み得る。このようなデータの例には、ウェブページ、ビデオデータ、オーディオデータ、画像、ユーザデータなどが含まれる。いくつかの実装では、データストア１６３０内の情報は、ネットワーク１６０８（複数可）上でユーザデバイス１６０４に提供されてよい。いくつかの場合、データストア１６３０は、格納されたアプリケーションプログラム及び／またはドライバを追加的または代替的に含み得る。代替的または追加的には、データストア１６３０は、標準及び／または専有ソフトウェアライブラリ及び／または標準及び／または専有アプリケーションユーザインターフェイス（ＡＰＩ）ライブラリを格納し得る。データストア１６３０に格納される情報は、機械可読オブジェクトコード、ソースコード、解釈済みコードまたは中間コードであり得る。
アプリケーションプログラム１６３２は、ネットワーク（複数可）１６０８上でユーザデバイス１６０４にアクセス可能なプログラムを含み得る。そのようなプログラムの例には、ワードプロセッシングプログラム、会計プログラム、メディアプレーヤ、画像編集プログラム、ゲーム及びその他が含まれる。アプリケーションプログラム１６３２は、代替的または追加的には、クラスタリング環境または分散環境で実行するプログラム、つまり、複数のサーバプロバイダコンピュータ１６１０間で協働して実行するアプリケーションを含み得る。
ドライバ１６３４は、サーバプロバイダコンピュータ１６１０内の構成要素間の通信を提供し得るプログラムを含む。例えば、いくつかのドライバ１６３４は、オペレーティングシステム１６２８と追加のストレージ１６２２、通信接続１６２４及び／またはＩ／Ｏデバイス１６２６との間の通信を提供し得る。代替的または追加的には、いくつかのドライバ１６３４は、アプリケーションプログラム１６３２とオペレーティングシステム１６２８、及び／またはアプリケーションプログラム１６３２とサービスプロバイダコンピュータ１６１０にアクセス可能な周辺装置との間の通信を提供し得る。多くの場合、ドライバ１６３４は、公知の機能性を提供するドライバ（例えば、プリンタドライバ、ディスプレイドライバ、ハードディスクドライバ）を含み得る。他の場合には、ドライバ１６３４は専有または特殊機能性を有し得る。
サービスプロバイダコンピュータ（複数可）１６１０またはサーバはさらに、追加のストレージ１６２２を含むことがあり、取り外し可能なストレージ及び／または取り外し不可能なストレージを含み得る。追加のストレージ１６２２は、磁気ストレージ、光ディスク、ソリッドステートディスク、フラッシュメモリ及び／またはテープストレージを含み得る。追加のストレージ１６２２はサービスプロバイダコンピュータ（複数可）１６１０と同じ筐体に格納され得るか、外部筐体内にあり得る。メモリ１６１８及び／または追加のストレージ１６２２及びそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール及びコンピューティングデバイスのための他のデータの不揮発性ストレージを提供し得る。いくつかの実装では、メモリ１６１８は、ＳＲＡＭ、ＤＲＡＭまたはＲＯＭなどの複数の異なるタイプのメモリを含み得る。
取り外し可能及び取り外し不可能なメモリ１６１８、追加のストレージ１６２２の両方は、コンピュータ可読記憶媒体の例である。例えば、コンピュータ可読記憶媒体は、情報の記憶のための方法または技術で実装される揮発性もしくは不揮発性、取り外し可能もしくは取り外し不可能な媒体を含み得、情報は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを含む。メモリ１６１８及び追加のストレージ１６２２は、コンピュータ記憶媒体の例である。サービスプロバイダコンピュータ（複数可）１６１０において存在し得るコンピュータ記憶媒体の追加のタイプは、ＰＲＡＭ、ＳＲＡＭ、ＤＲＡＭ、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、ソリッドステートドライブまたは所望の情報を記憶するために使用可能であり、サービスプロバイダコンピュータ（複数可）１６１０によってアクセス可能ないくつかの他の媒体を含み得るがこれらに限定されない。上記の媒体のタイプの任意の組み合わせも、コンピュータ可読媒体に含まれる。
代替的または追加的には、コンピュータ可読通信媒体は、コンピュータ可読命令、プログラムモジュールまたは搬送波または他の伝送などのデータ信号内で伝送される他のデータを含み得る。しかしながら、本発明で使用する場合、コンピュータ可読記憶媒体は、コンピュータ可読通信媒体を含まない。
サービスプロバイダコンピュータ（複数可）１６１０もまた、サービスプロバイダコンピュータ（複数可）１６１０が、格納されたデータベース、別のコンピューティングデバイスもしくはサーバ、ユーザ端末及び／またはネットワーク（複数可）１６０８上の他のデバイスと通信できるようにする通信接続（複数可）１６２４を含有し得る。サービスプロバイダコンピュータ（複数可）１６１０もまた、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、ディスプレイ、スピーカ、プリンタ及びその他などのＩ／Ｏデバイス（複数可）１６２６を含み得る。通信接続（複数可）１６２４及びＩ／Ｏデバイス（複数可）１６２６は、ストレージ１６２２と共に、周辺装置として記載され得る。
サービスプロバイダコンピュータ（複数可）１６１０もまた、１つ以上の通信チャネル１６３４を含み得る。通信チャネル１６３４はサービスプロバイダコンピュータ１６１０の様々な構成要素が通信可能な媒体を提供し得る。１つ以上の通信チャネル１６３４はバス、リング、スイッチングファブリクまたはネットワークの形態をとり得る。
本明細書で記載されたモジュールは、ソフトウェアモジュール、ハードウェアモジュールまたはそれらの好適な組み合わせであり得る。モジュールがソフトウェアモジュールである場合には、モジュールは非一時的なコンピュータ可読媒体上で具現化され、本明細書に記載されたコンピュータシステムのいずれかのプロセッサによって処理されることができる。記載された処理及び構造は、リアルタイムでまたは任意のユーザの相互作用の前の非同期モードのいずれかで実行されることが可能であるという点に留意すべきである。モジュールは図１６に提示された方式で構成されてよく、及び／または本明細書で記載された機能は、個別のモジュールとして存在する１つ以上のモジュールによって提供されることが可能であり、及び／または本明細書で記載されたモジュール機能は複数のモジュール上で分散されることが可能である。
図１７は、様々な実施形態に従う態様を実装するための環境１７００の例の態様を例示する。理解されるように、ウェブベースの環境が説明の目的のために使用されるが、様々な実施形態を実装するために異なる環境が必要に応じて使用され得る。環境は電子クライアントデバイス１７０２を含み、電子クライアントデバイスは、要求、メッセージまたは情報を適切なネットワーク１７０４上で送信及び受信し、デバイスのユーザに情報を返送するように動作可能である、適切なデバイスを含むことができる。このようなクライアントデバイスの例には、パーソナルコンピュータ、携帯電話、ハンドヘルドメッセージングデバイス、ラップトップコンピュータ、セットトップボックス、パーソナルデータアシスタント、電子ブックリーダ及びその他が含まれる。ネットワークは、イントラネット、インターネット、セルラネットワーク、ローカルエリアネットワークまたは任意の他のこのようなネットワークもしくはその組み合わせを含む、任意の適切なネットワークを含むことがある。このようなシステムのために使用される構成要素は、選択されるネットワーク及び／または環境のタイプに少なくとも部分的に依存することがある。このようなネットワークを介して通信するためのプロトコル及び構成要素は周知であり、本明細書において詳細に説明されない。ネットワーク上の通信は、有線接続または無線接続及びそれらの組み合わせによって可能にされることがある。この例では、環境は要求を受信し、要求に応えてコンテンツを提供するためのウェブサーバ１７０６を含むため、ネットワークはインターネットを含む。ただし、他のネットワークの場合、当業者に明白であるように、同様の目的を果たす代替のデバイスが使用できるだろう。
例示的な環境は、少なくとも１つのアプリケーションサーバ１７０８及びデータストア１７１０を含む。いくつかのアプリケーションサーバ、層もしくは他の要素、プロセスまたは構成要素が存在することがあり、これらは、チェーン接続されるか、または別様には構成されることがあり、適切なデータストアからデータを取得するなどのタスクを行うために相互作用することがあることを理解されたい。本明細書で使用されるように、用語「データストア」は、データを格納する、データにアクセスする及びデータを取り出すことができる任意のデバイスまたはデバイスの組み合わせを指し、これは、データサーバ、データベース、データストレージデバイス及びデータ記憶媒体の任意の組み合わせ及び数を、任意の標準的な環境、分散環境またはクラスタ化された環境に含んでよい。アプリケーションサーバは、データストアと統合してクライアントデバイスのための１つ以上のアプリケーションの態様を実行するために、必要に応じてデータストアと相互作用し、データアクセス及びアプリケーションのためのビジネスロジックの大多数を処理するための任意の適切なハードウェア及びソフトウェアを含むことがある。アプリケーションサーバは、データストアと協働してアクセス制御サービスを提供し、ユーザに転送されるテキスト、グラフィックス、音声及び／またはビデオなどのコンテンツを生成することができ、コンテンツは、この例ではハイパーテキストマークアップ言語（「ＨＴＭＬ」）、拡張マークアップ言語（「ＸＭＬ」）または別の適切な構造言語の形態でウェブサーバによってユーザに提供されてよい。全ての要求及び応答の処理ならびにクライアントデバイス１７０２とアプリケーションサーバ１７０８との間でのコンテンツの配信は、ウェブサーバ１７０６によって処理できる。本明細書で述べる構造化されたコードは、本明細書の他の部分で述べる任意の適切なデバイスまたはホストマシンで実行できるので、ウェブサーバ１７０６及びアプリケーションサーバ１７０８は必要とされず、単に例の構成要素であることを理解されたい。
データストア１７１０は、いくつかの個別のテーブル、データベースまたは特定の態様に関するデータを記憶するための他のデータ記憶機構及び媒体を含むことがある。例えば、例示のデータストア１７２０は、生産側にコンテンツを提供するために使用できる生産データ１７１２及びユーザ情報１７１６を格納するための機構を含む。データストアはさらに、報告、分析または他のこのような目的のために使用できるログデータ１７１４を記憶するための機構を含むと示される。ページ画像情報のために、及び必要に応じて上記にリストされる機構またはデータストア１７１０の追加の機構のいずれかに記憶できる正しい情報にアクセスするためになど、データストア１７１０に記憶される必要のあり得る多くの他の態様があり得ると理解されたい。データストア１７１０は、データストアに関連するロジックを通して、アプリケーションサーバ１７０８から命令を受信し、命令に応えてデータを取得、更新または別様には処理するよう動作可能である。一例では、ユーザは特定のタイプの項目に対する検索要求を送信する可能性がある。この場合、データストア１７１０は、ユーザ情報１７１６にアクセスしてユーザのアイデンティティを検証する可能性があり、そのタイプの項目についての情報を取得するためにカタログ詳細情報にアクセスできる。情報は、次いで、ユーザがユーザデバイス１７０２上のブラウザを介して見ることができるウェブページ上の結果リストなどで、ユーザに返送することができる。対象のある特定の項目の情報は、ブラウザの専用ページまたはウィンドウ内で見ることができる。
各サーバ１７０６、１７０８は、通常、そのサーバの一般的な管理及び操作のための実行可能なプログラム命令を提供するオペレーティングシステムを含み、通常、サーバのプロセッサによって実行されるときに、サーバがその目的の機能を実行できるようにする命令を格納するコンピュータ可読記憶媒体（例えば、ハードディスク、ランダムアクセスメモリ、読み出し専用メモリ等）を含む。サーバのオペレーティングシステム及び一般的な機能性の適切な実装は既知であるか、または市販されており、特に、本明細書の開示に鑑みて当業者によって容易に実装される。
一実施形態における環境１７００は、１つ以上のコンピュータネットワークまたは直接接続を使用し、通信リンクを介して相互接続されるいくつかのコンピュータシステム及び構成要素を利用する、分散型コンピューティング環境である。しかしながら、このようなシステムは、図１７に例示されるよりも少ない数または多い数の構成要素を有するシステムにおいて同等に良好に動作し得ることが当業者によって理解される。ゆえに、図１７のシステムの描写は、本質的に例示であり、本開示の範囲を限定するものではないと見なされるべきである。
本開示の実施形態は、以下の条項を鑑みて説明できる。
１．プロセッサと、
前記プロセッサに連結されて前記プロセッサによって読み取り可能なメモリであって、前記メモリはユーザアプリケーションを格納するように構成されている、前記メモリと
を備えるホストデバイスと、
ネットワークと通信するように構成されるネットワークアダプタデバイスと
を備えるコンピューティングシステムであって、
前記ホストデバイスは、
前記ユーザアプリケーションを実行するように構成され、前記ユーザアプリケーションは、
メッセージに対する宛先アドレスを決定し、前記宛先アドレスは前記ネットワーク上のサーバに関連している、前記決定することと、
前記宛先アドレスに対するアドレスハンドルを決定することと、
前記メッセージ及び前記アドレスハンドルを前記ネットワークアダプタに提供することと
を行うように構成され、
前記ネットワークアダプタデバイスは、
前記アドレスハンドルを使用して、トランスポートコンテキストを決定し、前記トランスポートコンテキストは前記宛先アドレスに関連する前記ネットワーク上の前記サーバとの接続の状態を含む、前記決定することと、
前記メッセージ及び前記トランスポートコンテキストを使用して、パケットを生成することと、
前記ネットワーク上で前記パケットを送信することと
を行うように構成される、
前記コンピューティングシステム。
２．前記ホストデバイスはさらにドライバプログラムを実行するように構成され、前記ユーザアプリケーションはさらに、前記宛先アドレスに対する前記アドレスハンドルを決定できないときに、
前記ドライバプログラムからアドレスハンドルを要求することであって、前記要求は前記宛先アドレスを含む、前記要求することを行うように構成され、
前記ドライバプログラムは、
アドレスマップを使用して、前記宛先アドレスに対するアドレスハンドルを決定することと、
前記ユーザアプリケーションに前記アドレスハンドルを提供することと
を行うように構成される、
条項１に記載のコンピューティングシステム。
３．前記ドライバプログラムはさらに、
前記アドレスマップが前記宛先アドレスを含まないことを判断することと、
前記ネットワークアダプタデバイスに前記宛先アドレスを提供することと
を行うように構成され、
前記ネットワークアダプタデバイスはさらに、
新しい接続のために新しいトランスポートコンテキストを生成することと、
前記新しいトランスポートコンテキスト内に前記新しい接続の状態を格納することと、
新しいアドレスハンドルを前記新しいトランスポートコンテキストに関連させることと、
新しいアドレスハンドルを前記ドライバプログラムに提供することと、
前記宛先アドレスに関連する前記ネットワーク上の前記サーバとの前記新しい接続を確立することと
を行うように構成され、
前記ドライバプログラムはさらに、
前記新しいアドレスハンドルを使用して、前記アドレスマップ内に前記宛先アドレスを格納することを行うように構成され、
前記決定されたトランスポートコンテキストは前記新しいトランスポートコンテキストであり、前記ドライバプログラムによって提供された前記アドレスハンドルは前記新しいアドレスハンドルである、
条項２に記載のコンピューティングシステム。
４．プロセッサと、
前記１つ以上のプロセッサに連結されて前記１つ以上のプロセッサによって読み取り可能なメモリであって、前記メモリは複数のトランスポートコンテキストを格納するように構成されている、前記メモリとを備える装置であって、
前記装置は、
ネットワーク及びホストデバイスと通信することと、
メッセージ及び前記メッセージに関連する宛先情報を前記ホストデバイスから受信することと、
前記宛先情報を使用して、前記複数のトランスポートコンテキストから１つのトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先との接続の状態を含み、前記ネットワーク上の前記宛先は前記宛先情報に関連している、前記決定することと
を行うように構成される、前記装置。
５．前記装置はさらに、
前記メッセージ及び前記トランスポートコンテキストを使用してパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で、前記パケットを送信することと
を行うように構成される、条項４に記載の装置。
６．前記宛先情報はアドレスハンドルを備え、前記装置はさらに、
前記アドレスハンドルを使用して、複数のアドレスマップオブジェクトから１つのネットワークアドレスマップオブジェクトを決定することであって、前記複数のアドレスマップオブジェクトは前記メモリに格納されており、前記アドレスマップオブジェクトは前記決定されたトランスポートコンテキストに関連している、前記決定すること
を行うように構成される、条項４または５に記載の装置。
７．前記ネットワークアドレスマップオブジェクトは事前生成パケットヘッダを含む、条項６に記載の装置。
８．前記装置はさらに、
新しいアドレスハンドルの要求を受信することであって、前記要求は前記宛先情報を含む、前記受信することと、
前記新しい宛先情報を使用して、前記ネットワークアドレスマップオブジェクトを識別することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記ネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
を行うように構成される、条項６に記載の装置。
９．前記装置はさらに、
新しいアドレスハンドルの要求を受信することであって、前記要求は新しい宛先情報を含む、前記受信することと、
前記複数のトランスポートコンテキストが前記新しい宛先情報に関連するトランスポートコンテキストを含まないと判断するときに、
新しいトランスポートコンテキストを生成することと、
前記新しいトランスポートコンテキスト内に前記新しい接続の状態を格納することとを行い、
新しいネットワークアドレスマップオブジェクトを生成することであって、前記ネットワークアドレスマップオブジェクトは前記新しいトランスポートコンテキストに関連している、前記生成することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記新しいネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
を行うように構成される、条項６に記載の装置。
１０．前記装置はさらに、前記複数のトランスポートコンテキストが前記新しい宛先情報に関連するトランスポートコンテキストを含まないと判断するときに、前記新しい宛先情報に関連する前記ネットワーク上の新しい宛先との新しい接続を確立するように構成される、条項９に記載の装置。
１１．新しいネットワークアドレスマップオブジェクトを生成することは、前記新しい宛先情報を使用して、パケットヘッダを生成することを含み、前記生成されたパケットヘッダは前記新しいネットワークアドレスマップオブジェクトに格納される、条項９に記載の装置。
１２．前記装置はさらに、前記宛先情報に関連する前記ネットワーク上の宛先との接続を確立するように構成される、条項４〜１１のいずれかに記載の装置。
１３．前記宛先情報はネットワークアドレスを備える、条項４〜１２のいずれかに記載の装置。
１４．前記宛先情報はフロー識別子を備える、条項４〜１３のいずれかに記載の装置。
１５．前記ネットワーク上の前記宛先は前記ネットワーク上のサーバに関連している、条項４〜１４のいずれかに記載の装置。
１６．前記ネットワーク上の前記宛先は１つ以上のインターネットプロトコルアドレスに関連している、条項４〜１５のいずれかに記載の装置。
１７．前記ネットワーク上の前記宛先はインターネットプロトコルアドレス及び通信エンドポイントの識別子に関連している、条項４〜１６のいずれかに記載の装置。
１８．前記メッセージはシーケンス識別子を含み、前記シーケンス識別子は前記メッセージの送信元からの他のメッセージに関する前記メッセージのシーケンスを示し、前記装置は、
前記トランスポートコンテキストを使用して、前記メッセージ及び前記メッセージのシーケンス識別子を含むパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと、
前記送信されたパケットの状態を監視することと
を行うように構成される、条項４〜１７のいずれかに記載の装置。
１９．前記装置はネットワークアダプタデバイスである、条項４〜１８のいずれかに記載の装置。
２０．前記装置はシステムオンチップ（ＳｏＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）である、条項４〜１９のいずれかに記載の装置。
２１．プロセッサと、
前記１つ以上のプロセッサに連結されて前記１つ以上のプロセッサによって読み取り可能なメモリであって、前記メモリは複数のトランスポートコンテキストを格納するように構成されている、前記メモリと
を備える装置であって、前記装置は、
ネットワークと通信することと、
前記ネットワーク上でパケットを受信することであって、前記パケットは前記ネットワーク上の送信元との接続の確立を要求する、前記受信することと、
前記ネットワーク上の前記送信元に関連するトランスポートコンテキストを生成することであって、前記トランスポートコンテキストは前記ネットワーク上の前記送信元との接続の状態を示す、前記生成することと、
前記メモリに前記トランスポートコンテキストを格納することと、
前記ネットワーク上の前記送信元に応答を送信することであって、前記応答は前記接続の確立を確認する、前記送信することと
を行うように構成される、前記装置。
２２．前記装置はさらに、
前記ネットワーク上で第２のパケットを受信することであって、前記第２のパケットは前記ネットワーク上の第２の送信元との第２の接続の確立を要求する、前記受信することと、
前記第２のパケットを使用して、前記トランスポートコンテキストを識別することと、
前記ネットワーク上の前記第２の送信元に第２の応答を送信することであって、前記第２の応答は前記第２の接続の確立を確認する、前記送信することと
を行うように構成される、条項２１に記載の装置。
２３．前記装置は、
前記パケットが他のパケットに関して受信された順序を識別することと、
前記パケットを受け入れ可能かどうかを判断することと、
前記パケットを受け入れ可能であると判断するときに、
前記パケットに含まれる宛先情報を使用して、受信キューを決定することであって、前記受信キューは前記ホストデバイス上のユーザアプリケーションに関連している、前記決定することと、
前記受信キューに前記パケットを転送することと、
前記パケットの状態を示す応答を送信することと
を行うように構成される、条項２１または２２に記載の装置。
２４．ネットワークアダプタデバイスによって、メッセージ及び前記メッセージに関連する宛先情報を受信することと、
前記宛先情報を使用して、複数のトランスポートコンテキストから１つのトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先との接続の状態を含み、前記ネットワーク上の前記宛先は前記宛先情報に関連している、前記決定することと
を備える、方法。
２５．前記メッセージ及び前記トランスポートコンテキストを使用して、パケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと
をさらに備える、条項２４に記載の方法。
２６．前記宛先情報はアドレスハンドルを備え、
前記アドレスハンドルを使用して、複数のアドレスマップオブジェクトから１つのネットワークアドレスマップオブジェクトを決定することであって、前記複数のアドレスマップオブジェクトは前記メモリに格納されており、前記アドレスマップオブジェクトは前記決定されたトランスポートコンテキストに関連している、前記決定すること
をさらに備える、条項２４または２５に記載の方法。
２７．前記ネットワークアダプタデバイスによって、新しいアドレスハンドルの要求を受信することであって、前記要求は前記宛先情報を含む、前記受信することと、
前記新しい宛先情報を使用して、前記ネットワークアドレスマップオブジェクトを識別することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記ネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
をさらに備える、条項２６に記載の方法。
２８．前記ネットワークアダプタデバイスによって、新しいアドレスハンドルの要求を受信することであって、前記要求は新しい宛先情報を含む、前記受信することと、
前記複数のトランスポートコンテキストが前記新しい宛先情報に関連するトランスポートコンテキストを含まないと判断するときに、
新しいトランスポートコンテキストを生成することと、
前記新しい接続の状態を前記新しいトランスポートコンテキストに格納することと、
前記新しい宛先情報に関連する前記ネットワーク上の新しい宛先との新しい接続を確立することとを行い、
新しいネットワークアドレスマップオブジェクトを生成することであって、前記ネットワークアドレスマップオブジェクトは前記新しいトランスポートコンテキストに関連している、前記生成することと、
前記新しいアドレスハンドルを生成することであって、前記新しいアドレスハンドルは前記新しいネットワークアドレスマップオブジェクトに関連している、前記生成することと、
前記新しいアドレスハンドルを返送することと
をさらに備える、条項２６に記載の方法。
２９．プロセッサと、
前記プロセッサに連結されて前記プロセッサによって読み取り可能なメモリであって、前記メモリはユーザアプリケーションを格納するように構成されている、前記メモリと
を備えるホストデバイスと、
ネットワークと通信するように構成されるネットワークアダプタデバイスと
を備えるコンピューティングシステムであって、
前記ホストデバイスは前記ユーザアプリケーションを実行するように構成され、前記ユーザアプリケーションは、
前記メモリに複数のバッファを構成するように構成され、
前記ネットワークアダプタデバイスは、
前記ネットワーク上で複数のパケットを受信することであって、前記複数のパケットは前記ネットワーク上の送信元から発生し、前記複数のパケットは順不同で受信される、前記受信することと、
前記複数のパケットから１つのパケットを受信するときに、
前記送信元及び前記パケットの宛先に関連するトランスポートコンテキストを識別することと、
前記パケットに含まれるエンドポイント識別子を使用して、前記パケットが前記ユーザアプリケーションに対するものであると判断することと、
前記複数のバッファから１つのバッファに前記受信パケットを転送することとを行い、
前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、前記複数のパケットからのパケットの状態を示す応答を送信すること
を行うように構成され、
前記ユーザアプリケーションはさらに、
前記受信パケットを順序通りに配置するために、前記複数のバッファで受信した前記パケットを並び替えすることを行うように構成される、
前記コンピューティングシステム。
３０．前記ネットワークアダプタデバイスはさらに、
前記複数のパケットからの各パケットに含まれる識別子を監視することと、
前記複数のパケットからの１つ以上のパケットが受信されなかったと判断することと
を行うように構成され、
前記応答は受信されなかった前記１つ以上のパケットを識別する、
条項２９に記載のコンピューティングシステム。
３１．前記ネットワークアダプタデバイスはさらに、
前記複数のバッファがフルであると判断することと、
前記複数のパケットから１つ以上のパケットをドロップすることと
を行うように構成される、
条項２９または３０に記載のコンピューティングシステム。
３２．前記応答はドロップされた前記１つ以上のパケットを識別する、条項３１に記載のコンピューティングシステム。
３３．プロセッサと、
複数の受信キューと
を備える装置であって、前記装置は、
ホストデバイス及びネットワークと通信することと、
前記ネットワーク上でパケットを受信することであって、前記パケットは前記ネットワーク上の送信元から発生し、順不同で受信される、前記受信することと、
各受信パケットに対して、
前記送信元及び前記受信パケットの宛先に関連するトランスポートコンテキストを識別することと、
前記受信パケットが他のパケットに関して受信された順序を識別することと、
前記受信パケットを受け入れ可能かどうかを判断することと、
前記受信パケットを受け入れ可能であると判断するときに、
前記受信パケットに含まれる宛先情報を使用して、受信キューを決定することであって、前記受信キューは前記ホストデバイス上のユーザアプリケーションに関連している、前記決定することと、
前記受信キューに前記受信パケットを転送することと
を行うように構成される、前記装置。
３４．前記装置はさらに、前記パケットを受け入れ可能であると判断するときに、前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、前記受信パケットのうちの１つ以上の状態を示す応答を送信するように構成される、条項３３に記載の装置。
３５．前記応答は１つ以上のパケットが受信されたことを示す、条項３４に記載の装置。
３６．前記応答は１つ以上のパケットが受信されなかったことを示す、条項３４に記載の装置。
３７．前記装置は、第２の受信パケットに対して、
前記第２の受信パケットを受け入れ不可能であったと判断することと、
前記第２の受信パケットをドロップすることと
を行うように構成される、条項３３〜３６のいずれかに記載の装置。
３８．前記装置は、前記複数のバッファがフルであると判断することによって、前記第２のパケットを受け入れ不可能であると判断するように構成される、条項３７に記載の装置。
３９．前記装置は、前記第２の受信パケットに対応するデータが以前に受信されたと判断することによって、前記第２のパケットを受け入れ不可能であると判断するように構成される、条項３７に記載の装置。
４０．前記装置は、前記第２の受信パケットが無効であると判断することによって、前記第２のパケットを受け入れ不可能であると判断するように構成される、条項３７に記載の装置。
４１．前記装置はさらに、前記第２の受信パケットを受け入れ不可能であると判断するときに、前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、送信されることになる１つ以上のパケットを識別する応答を送信するように構成され、前記１つ以上のパケットは前記第２の受信パケットを含む、条項３７に記載の装置。
４２．前記識別されたトランスポートコンテキストは、前記ネットワーク上の前記装置と前記送信元との間の接続の状態を含む、条項３３〜４１のいずれかに記載の装置。
４３．前記識別されたトランスポートコンテキストは、前記ネットワーク上の前記送信元から前記装置への前記ネットワーク上の複数の経路を提供する、条項３３〜４２のいずれかに記載の装置。
４４．前記パケットはパケットのサブフローに分割される、条項３３〜４３のいずれかに記載の装置。
４５．パケットの各サブフローは異なるネットワーク経路上で受信される、条項３３〜４４のいずれかに記載の装置。
４６．前記装置はさらに、
パケットのサブフローに対して、前記パケットのサブフローからの各パケットに含まれる識別子を監視することと、
前記識別子を使用して、前記パケットのサブフローからの特定のパケットが順序通りに受信されたことを判断することと
を行うように構成され、
前記応答は順序通りに受信された前記パケットのサブフローからの１つ以上のパケットを識別し、前記パケットのサブフローからの前記１つ以上のパケットは前記特定のパケットを含む、
条項３３〜４４のいずれかに記載の装置。
４７．前記装置はさらに、
パケットのサブフローに対して、前記パケットのサブフローからの各パケットに含まれる識別子を監視することと、
前記識別子を使用して、前記パケットのサブフローからの特定のパケットが受信されなかったことを判断することと
を行うように構成され、
前記応答は受信されなかった前記パケットのサブフローからの１つ以上のパケットを識別し、前記パケットのサブフローからの前記１つ以上のパケットは前記特定のパケットを含む、
条項３３〜４４のいずれかに記載の装置。
４８．前記装置はネットワークアダプタデバイスである、条項３３〜４７のいずれかに記載の装置。
４９．前記装置はシステムオンチップ（ＳｏＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）である、条項３３〜４８のいずれかに記載の装置。
５０．ネットワークアダプタデバイスにおいて、ネットワーク上で複数のパケットを受信することであって、前記複数のパケットは前記ネットワーク上の送信元から発生し、順不同で受信される、前記受信することと、
前記複数のパケットからパケットを受信するときに、
前記送信元及び前記受信パケットの宛先に関連するトランスポートコンテキストを識別することと、
前記受信パケットが前記複数のパケットからの他のパケットに関して受信された順序を識別することと、
前記受信パケットを受け入れ可能かどうかを判断することと、
前記受信パケットを受け入れ可能であると判断するときに、
前記受信パケットに含まれる宛先情報を使用して、受信キューを決定することであって、前記受信キューはユーザアプリケーションに関連している、前記決定することと、
前記受信キューに前記受信パケットを転送することと、
前記ネットワーク上で、前記識別されたトランスポートコンテキストを使用して、前記複数のパケットからの１つ以上のパケットの状態を示す応答を送信することと
を備える、前記方法。
５１．前記応答は前記複数のパケットからの前記１つ以上のパケットが受信されたことを示す、条項５０に記載の方法。
５２．前記応答は前記複数のパケットからの前記１つ以上のパケットが受信されなかったことを示す、条項５０または５１に記載の方法。
５３．第２の受信パケットに対して、
前記第２の受信パケットを受け入れ不可能であったと判断することと、
前記第２の受信パケットをドロップすることと
をさらに備え、
前記応答は送信されることになる１つ以上のパケットを識別し、前記１つ以上のパケットは前記第２の受信パケットを含む、
条項５０〜５２のいずれかに記載の方法。
５４．前記識別されたトランスポートコンテキストは、前記ネットワーク上の前記ネットワークアダプタデバイスと前記送信元との間の接続の状態を含む、条項５０〜５３のいずれかに記載の方法。
５５．プロセッサと、
前記プロセッサに連結されて前記プロセッサによって読み取り可能なメモリであって、前記メモリはユーザアプリケーションを格納するように構成されている、前記メモリと
を備えるホストデバイスと、
ネットワークと通信するように構成されるネットワークアダプタデバイスとを備えるコンピューティングシステムであって、
前記ホストデバイスは、
前記ユーザアプリケーションを実行するように構成され、前記ユーザアプリケーションは、メッセージを前記ネットワークアダプタデバイスに提供するように構成され、各メッセージはアドレスハンドルを含み、
前記ネットワークアダプタデバイスは、
前記ユーザアプリケーションからの各メッセージに対して、
前記アドレスハンドルを使用して、前記メッセージに対するトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先に関連しており、前記トランスポートコンテキストは宛先アドレスを提供する、前記決定することと、
前記メッセージに対するパケットを生成することであって、前記パケットは前記宛先アドレスを含む、前記生成することと、
前記ネットワーク上で前記パケットを送信することと、
前記ネットワーク上で応答を受信することであって、各応答は前記メッセージに対して送信される１つ以上のパケットの状態を示す、前記受信することと、
前記１つ以上のパケットの前記状態を前記ユーザアプリケーションに報告することと
を行うように構成される、
前記コンピューティングシステム。
５６．応答は１つ以上のパケットの受信が成功したことを示す、条項５５に記載のコンピューティングシステム。
５７．応答は１つ以上のパケットが受信されなかったことを示し、前記ネットワークアダプタデバイスはさらに、
受信されないと示された前記１つ以上のパケットを再送することを行うように構成される、条項５５または５６に記載のコンピューティングシステム。
５８．応答は１つ以上のパケットが前記宛先でドロップされたことを示し、前記ネットワークアダプタデバイスはさらに、
前記応答を前記ユーザアプリケーションに報告すること
を行うように構成される、条項５５〜５７のいずれかに記載のコンピューティングシステム。
５９．プロセッサと、
複数の送信キューと
を備える装置であって、
前記装置はホストデバイス及びネットワークと通信するように構成され、前記装置はさらに、
前記複数の送信キューで前記ホストデバイスからメッセージを受信することであって、各メッセージはそれぞれのシーケンス識別子を含み、前記シーケンス識別子は前記メッセージの送信元からの他のメッセージに関する各それぞれのメッセージのシーケンスを示し、前記メッセージのそれぞれは同じ宛先情報に関連している、前記受信することと、
処理のために前記複数の送信キューから１つの送信キューを決定することと、
前記決定された送信キュー内の各メッセージに対して、
前記宛先情報及び前記決定された送信キューの識別を使用して、前記ネットワーク上の宛先に関連するトランスポートコンテキストを決定することと、
前記トランスポートコンテキストを使用して、前記メッセージ及び前記メッセージのシーケンス識別子を含むパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと、
前記送信されたパケットの状態を監視することと
を行うように構成される、前記装置。
６０．前記装置はさらに、
前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの１つ以上が前記ネットワーク上の前記宛先で受信されたことを示す、前記受信することを行うように構成される、条項５９に記載の装置。
６１．前記装置はさらに、
前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの１つ以上が前記ネットワーク上の前記宛先で受信されなかったことを示す、前記受信することと、
受信されないと示された前記１つ以上のパケットを再送することと
を行うように構成される、条項６０に記載の装置。
６２．前記装置はさらに、
前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの１つ以上を再送する要求を含む、前記受信することと、
前記応答を前記ホストデバイスに報告することと
を行うように構成される、条項６０に記載の装置。
６３．前記トランスポートコンテキストは前記ネットワーク上で前記ネットワーク上の前記宛先への複数の経路を提供する、条項５９〜６２のいずれかに記載の装置。
６４．前記装置はさらに、
前記メッセージに対する前記パケットをパケットのサブフローに分割すること
を行うように構成される、条項５９〜６３のいずれかに記載の装置。
６５．前記装置はさらに、
異なるネットワーク経路上でパケットの各サブフローを送信すること
を行うように構成される、条項６４に記載の装置。
６６．前記装置はさらに、
パケットのサブフローからの１つ以上のパケットの受信が成功したことを示す応答を受信すること
を行うように構成される、条項６４に記載の装置。
６７．前記装置はさらに、
パケットのサブフローからの１つ以上のパケットが前記ネットワーク上の前記宛先で受信されなかったことを示す応答を前記ネットワーク上で受信することと、
受信されないと示された前記１つ以上のパケットを再送することと
を行うように構成される、条項６４に記載の装置。
６８．前記装置はさらに、各パケットのサブフローに対して、
前記パケットのサブフローからパケットを送信するときに、タイマを開始することと、
前記タイマの期限が切れたときに、前記パケットのサブフローから１つ以上のパケットを再送することと
を行うように構成される、条項６４に記載の装置。
６９．前記装置はネットワークアダプタデバイスである、条項５９〜６８のいずれかに記載の装置。
７０．前記装置はシステムオンチップ（ＳｏＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または特定用途向け集積回路（ＡＳＩＣ）である、条項５９〜６９のいずれかに記載の装置。
７１．ネットワークアダプタデバイスによって、複数の送信キューでホストデバイスからメッセージを受信することであって、各メッセージはシーケンス識別子を含み、前記シーケンス識別子は前記メッセージの送信元からの他のメッセージに関する各それぞれのメッセージのシーケンスを示し、前記メッセージのそれぞれは同じ宛先情報に関連している、前記受信することと、
処理のために前記複数の送信キューから１つの送信キューを決定することと、
前記決定された送信キュー内の各メッセージに対して、
前記宛先情報及び前記決定された送信キューの識別を使用して、トランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先に関連している、前記決定することと、
前記トランスポートコンテキストを使用して、前記メッセージ及び前記メッセージのシーケンス識別子を含むパケットを生成することと、
前記トランスポートコンテキストを使用して、前記ネットワーク上で前記パケットを送信することと、
前記送信されたパケットの状態を監視することと
を備える、方法。
７２．前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの１つ以上が前記ネットワーク上の前記宛先で受信されたことを示す、前記受信すること
をさらに備える、条項７１に記載の方法。
７３．前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの１つ以上が前記ネットワーク上の前記宛先で受信されなかったことを示す、前記受信することと、
受信されないと示された前記１つ以上のパケットを再送することと
をさらに備える、条項７１または７２に記載の方法。
７４．前記ネットワーク上で応答を受信することであって、前記応答は前記メッセージに対する前記パケットの１つ以上を再送する要求を含む、前記受信することと、
前記応答を前記ホストデバイスに報告することと
をさらに備える、条項７１〜７３のいずれかに記載の方法。
７５．パケットのサブフローに対して、
前記パケットを送信するときに、タイマを開始することと、
前記タイマの期限が切れたときに、前記パケットのサブフローから１つ以上のパケットを再送することと
をさらに備える、条項７１〜７４のいずれかに記載の方法。
様々な実施形態は多様な動作環境でさらに実装することができ、動作環境は、いくつかの場合、いくつかのアプリケーションのいずれかを操作するために使用できる１つ以上のユーザコンピュータ、コンピューティングデバイスまたは処理デバイスを含むことがある。ユーザデバイスまたはクライアントデバイスは、標準オペレーティングシステムを実行するデスクトップコンピュータまたはラップトップコンピュータなどのいくつかの汎用パーソナルコンピュータのいずれか、ならびにモバイルソフトウェアを実行し、かついくつかのネットワーキングプロトコル及びメッセージプロトコルをサポートできる、セルラデバイス、無線デバイス及びハンドヘルドデバイスを含むことがある。このようなシステムは、様々な市販のオペレーティングシステムならびに開発及びデータベース管理などの目的のための他の既知のアプリケーションを実行するいくつかのワークステーションを含むこともある。これらのデバイスはさらに、ダミー端末、シンクライアント、ゲーミングシステム及びネットワークを介して通信できる他のデバイスなどの他の電子デバイスを含むことがある。
ほとんどの実施形態は、伝送制御プロトコル／インターネットプロトコル（「ＴＣＰ／ＩＰ」）、オープンシステムインターコネクション（「ＯＳＩ」）、ファイルトランスポートプロトコル（「ＦＴＰ」）、ユニバーサルプラグアンドプレイ（「ＵｐｎＰ」）、ネットワークファイルシステム（「ＮＦＳ」）、共通インターネットファイルシステム（「ＣＩＦＳ」）及びＡｐｐｌｅＴａｌｋなどの様々な市販のプロトコルのいずれかを使用し、通信を支援するための当業者によく知られているだろう少なくとも１つのネットワークを活用する。ネットワークは、例えば、ローカルエリアネットワーク、ワイドエリアネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク及びその任意の組み合わせであることがある。
ウェブサーバを利用する実施形態では、ウェブサーバは、ハイパーテキストトランスポートプロトコル（「ＨＴＴＰ」）サーバ、ＦＴＰサーバ、共通ゲートウェイインタフェース（「ＣＧＩ」）サーバ、データサーバ、Ｊａｖａサーバ及びビジネスアプリケーションサーバを含む様々なサーバまたは中間層アプリケーションのいずれかを実行できる。サーバ（複数可）はさらに、Ｊａｖａ（登録商標）、Ｃ、Ｃ＃もしくはＣ＋＋などの任意のプログラミング言語、またはＰｅｒｌ、ＰｙｔｈｏｎもしくはＴＣＬなどの任意のスクリプト言語ならびにその組み合わせで記述された１つ以上のスクリプトまたはプログラムとして実装されてよい１つ以上のウェブアプリケーションを実行することなどによって、ユーザデバイスからの要求に応えてプログラムまたはスクリプトを実行することができ得る。サーバ（複数可）はさらに、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）及びＩＢＭ（登録商標）から市販されているものを含むがこれらに制限されないデータベースサーバを含んでよい。
環境は、上述の通り、様々なデータストアならびに他のメモリ及び記憶媒体を含むことがある。これらは、コンピュータの１つ以上にローカルな（及び／またはそこに常駐する）あるいはネットワーク全体でのコンピュータのいずれかまたは全てから遠く離れた記憶媒体上などの様々な場所に常駐することがある。実施形態の特定のセットでは、情報は、当業者によく知られているストレージエリアネットワーク（「ＳＡＮ」）に常駐してよい。同様に、コンピュータ、サーバまたは他のネットワークデバイスによる機能を実行するためのあらゆる必要なファイルは、必要に応じてローカルに及び／またはリモートに記憶されてよい。システムがコンピュータ化されたデバイスを含む場合、このようなそれぞれのデバイスはバスを介して電気的に結合されてよいハードウェア要素を含むことがあり、要素は、例えば、少なくとも１つの中央演算処理装置（「ＣＰＵ」）、少なくとも１つの入力デバイス（例えば、マウス、キーボード、コントローラ、タッチスクリーンまたはキーパッド）及び少なくとも１つの出力デバイス（例えば、表示デバイス、プリンタまたはスピーカ）を含むことがある。また、このようなシステムは、例えば、ディスクドライブ、光学式ストレージデバイスなどの１つ以上のストレージデバイス及びランダムアクセスメモリ（「ＲＡＭ」）または読み出し専用メモリ（「ＲＯＭ」）などのソリッドステートストレージデバイス、ならびに取り外し可能な媒体デバイス、メモリカード、フラッシュカードを含んでよい。
このようなデバイスはさらに、上述のようにコンピュータ可読記憶媒体リーダ、通信デバイス（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信デバイス等）及び作業メモリを含むことがある。コンピュータ可読記憶媒体リーダは、リモートストレージデバイス、ローカルストレージデバイス、固定ストレージデバイス及び／または取り外し可能なストレージデバイスを表すコンピュータ可読記憶媒体、ならびにコンピュータ可読情報を一時的に及び／またはより恒久的に含む、記憶する、送信する及び取り出すための記憶媒体と接続できる、またはそれらを受信するように構成できる。システム及び様々なデバイスはさらに、通常、オペレーティングシステム及びクライアントアプリケーションもしくはウェブブラウザなどのアプリケーションプログラムを含む、いくつかのソフトウェアアプリケーション、モジュール、サービスまたは少なくとも１つの作業用メモリデバイス内に位置する他の要素を含む。代替の実施形態は上述の多数の変形形態を有してよいことを理解されたい。例えば、カスタマイズされたハードウェアが使用される可能性もある、及び／または特定の要素がハードウェア、ソフトウェア（アプレットなどのポータブルソフトウェアを含む）または両方で実装される可能性がある。さらに、ネットワーク入力／出力デバイス等の、他のコンピューティングデバイスへの接続が利用されてよい。
コードまたはコードの一部を包含するための記憶媒体コンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、電気的消去可能プログラマブル読み出し専用メモリ（「ＥＥＰＲＯＭ」）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読み出し専用メモリ（「ＣＤ−ＲＯＭ］）、デジタルバーサタイルディスク（ＤＶＤ）もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または所望の情報を記憶するために使用することができ、かつシステムデバイスによってアクセスできる任意の他の媒体を含む、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータ等の情報の記憶及び／または送信のために任意の方法または技術で実装される揮発性及び不揮発性の媒体、取り外し可能及び取り外し不可能な媒体等であるが、これに限定されるものではない記憶媒体及び通信媒体を含む当該分野において既知の、または使用される任意の適切な媒体を含むことがある。本開示及び本明細書に提供される教示に基づいて、当業者は様々な実施形態を実装するための他の方法及び／または手法を理解するであろう。
したがって、明細書及び図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかしながら、特許請求の範囲に記載される本開示のより広範の趣旨及び範囲から逸脱することなく、様々な修正形態及び変更が本明細書に加えられ得ることは明らかである。
他の変形形態は、本開示の趣旨の範囲内である。ゆえに、開示された技法は様々な修正形態及び代替構成の影響を受けるが、その特定の例示の実施形態は図面に示され、上記に詳細に説明されている。しかしながら、本開示を開示された特定の１つ以上の形態に限定する意図はなく、逆に意図は、添付の特許請求の範囲によって定義される本開示の趣旨及び範囲に入る全ての修正形態、代替構成及び均等物を包含することであることを理解されたい。
開示される実施形態を説明する文脈における（特に以下の特許請求の範囲の文脈における）用語「ａ」及び「ａｎ」及び「ｔｈｅ」ならびに同様の指示語の使用は、本明細書において別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、単数及び複数の両方を網羅すると解釈されるべきである。用語「ｃｏｍｐｒｉｓｉｎｇ（備える）」、「ｈａｖｉｎｇ（有する）」及び「ｃｏｎｔａｉｎｉｎｇ（含む）」は、特に断りのない限り、オープンエンド用語（すなわち「を含むが、これらに限定されるものではない」を意味する）として解釈されるべきである。用語「ｃｏｎｎｅｃｔｅｄ（接続された）」は、たとえ介在するものがあっても部分的にまたは完全に、中に含まれる、取り付けられるまたは互いに結合されるとして解釈されるべきである。本明細書での値の範囲の列挙は、本明細書に別段の指示がない限り、単に、範囲内に入るそれぞれの個別の値に個別に言及する短縮方法として機能することが意図され、各個別の値は、それが個別に本明細書に記載されているかのように本明細書に組み込まれる。本明細書に記載される全ての方法は、本明細書で別段の指示がない限り、または別様には文脈に明らかに矛盾するものでない限り、任意の適切な順序で実行できる。本明細書に提供される例の一部及び全ての例または例示的な言語（例えば、「〜など」）の使用は、単に本開示の実施形態を良好に例示することを意図しており、別段の主張がない限り、本開示の範囲を限定するものではない。本明細書のいかなる言葉も、本開示の実施にとって必須として任意の請求されていない要素を示すものと解釈されるべきではない。
特に断りのない限り、句「Ｘ、ＹまたはＺのうちの少なくとも１つ」などの選言的な言葉は、項目、用語等がＸ、ＹもしくはＺまたはそのいずれかの組み合わせ（例えば、Ｘ、Ｙ及び／またはＺ）であってよいことを示すために一般的に用いられるとして文脈の中で理解されることが意図される。ゆえに、このような選言的言語は、特定の実施形態がＸの少なくとも１つ、Ｙの少なくとも１つまたはＺの少なくとも１つがそれぞれ存在することを必要とすることを暗示することを一般的に意図しておらず、意味するべきではない。
本開示を実施するために発明者に知られている最良の形態を含む本開示の好ましい実施形態が本明細書に説明される。これらの好ましい実施形態の変形形態は、前述の説明を読むと当業者に明らかになり得る。本発明者らは、当業者がこのような変形形態を必要に応じて利用することを期待し、本発明者らは本開示が本明細書に具体的に記載されたものとは別の方法で実施されることを意図する。したがって、本開示は、適用法によって許容されるように、本明細書に添付された特許請求の範囲に記載された主題の全ての修正形態及び均等物を含む。さらに、本明細書に別段の指示がない限り、または文脈に明らかに矛盾するものでない限り、上記要素の全ての考え得る変形形態での上記要素の任意の組み合わせが本開示に包含される。

Claims (1)

  1. プロセッサと、
    前記１つ以上のプロセッサに連結されて前記１つ以上のプロセッサによって読み取り可能なメモリであって、前記メモリは複数のトランスポートコンテキストを格納するように構成されている、前記メモリとを備える装置であって、
    前記装置は、
    ネットワーク及びホストデバイスと通信することと、
    メッセージ及び前記メッセージに関連する宛先情報を前記ホストデバイスから受信することと、
    前記宛先情報を使用して、前記複数のトランスポートコンテキストから１つのトランスポートコンテキストを決定することであって、前記トランスポートコンテキストは前記ネットワーク上の宛先との接続の状態を含み、前記ネットワーク上の前記宛先は前記宛先情報に関連している、前記決定することと
    を行うように構成される、前記装置。

JP2019032253A 2015-12-29 2019-02-26 ネットワーキング技術 Active JP6564960B2 (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US14/983,431 2015-12-29
US14/983,436 US9985904B2 (en) 2015-12-29 2015-12-29 Reliable, out-of-order transmission of packets
US14/983,434 2015-12-29
US14/983,434 US9985903B2 (en) 2015-12-29 2015-12-29 Reliable, out-of-order receipt of packets
US14/983,436 2015-12-29
US14/983,431 US10148570B2 (en) 2015-12-29 2015-12-29 Connectionless reliable transport

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2018533679A Division JP6490310B2 (ja) 2015-12-29 2016-12-28 ネットワーキング技術

Publications (2)

Publication Number Publication Date
JP2019092218A true JP2019092218A (ja) 2019-06-13
JP6564960B2 JP6564960B2 (ja) 2019-08-21

Family

ID=57822100

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2018533679A Active JP6490310B2 (ja) 2015-12-29 2016-12-28 ネットワーキング技術
JP2019032252A Active JP6569020B2 (ja) 2015-12-29 2019-02-26 ネットワーキング技術
JP2019032253A Active JP6564960B2 (ja) 2015-12-29 2019-02-26 ネットワーキング技術

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2018533679A Active JP6490310B2 (ja) 2015-12-29 2016-12-28 ネットワーキング技術
JP2019032252A Active JP6569020B2 (ja) 2015-12-29 2019-02-26 ネットワーキング技術

Country Status (10)

Country Link
EP (3) EP3734931B1 (ja)
JP (3) JP6490310B2 (ja)
KR (3) KR102055535B1 (ja)
CN (3) CN108476209B (ja)
AU (3) AU2016382952B2 (ja)
BR (1) BR112018013438A2 (ja)
CA (1) CA3010186C (ja)
CL (1) CL2018001771A1 (ja)
SG (1) SG11201805409SA (ja)
WO (1) WO2017117259A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9985904B2 (en) 2015-12-29 2018-05-29 Amazon Technolgies, Inc. Reliable, out-of-order transmission of packets
CN115941616A (zh) * 2017-12-15 2023-04-07 微软技术许可有限责任公司 多路径rdma传输
US10708170B2 (en) 2018-03-14 2020-07-07 At&T Intellectual Property I, L.P. Transferring data over multiple network paths using decoupled sub-flows
US10574755B2 (en) * 2018-03-28 2020-02-25 Wipro Limited Method and high performance computing (HPC) switch for optimizing distribution of data packets
CN109271268B (zh) * 2018-09-04 2022-03-18 超越科技股份有限公司 一种基于dpdk的智能容错方法
US10945190B2 (en) 2019-01-04 2021-03-09 Apple Inc. Predictive routing based on microlocation
CN109951532B (zh) * 2019-02-27 2021-09-24 江苏省未来网络创新研究院 一种基于dpdk的流量模型自动变换装置
US20220272060A1 (en) * 2019-08-01 2022-08-25 Shift5, Inc Systems, methods, and data structures for serial data collection and compression
CN112749142B (zh) * 2019-10-31 2023-09-01 上海哔哩哔哩科技有限公司 句柄管理方法和系统
CN111064587B (zh) * 2019-11-15 2021-09-07 宁波积幂信息科技有限公司 一种分布式数据系统的节点及广播传输数据管理方法
CN111404893B (zh) * 2020-03-06 2021-12-21 深信服科技股份有限公司 一种主机分类方法、装置、设备及计算机存储介质
US11604743B2 (en) 2020-08-31 2023-03-14 International Business Machines Corporation Input/output queue hinting for resource utilization
EP4207654A4 (en) * 2020-09-17 2023-09-27 Huawei Technologies Co., Ltd. PACKET RETRANSMISSION METHOD AND APPARATUS
WO2023241770A1 (en) * 2022-06-13 2023-12-21 Huawei Technologies Co., Ltd. Efficient rerouting of a selective-repeat connection
CN115174484A (zh) * 2022-06-16 2022-10-11 阿里巴巴（中国）有限公司 基于rdma的数据传输方法、装置、设备及存储介质
CN115550250B (zh) * 2022-11-17 2023-04-07 鹏城实验室 小流报文重传方法、系统、电子设备及存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002305535A (ja) * 2001-01-11 2002-10-18 Internatl Business Mach Corp <Ibm> データを転送する信頼できるプロトコルを提供する方法および装置
US20030031183A1 (en) * 2001-08-09 2003-02-13 International Business Machines Corporation Queue pair resolution in infiniband fabrics
JP2004531175A (ja) * 2001-06-29 2004-10-07 インターナショナル・ビジネス・マシーンズ・コーポレーション ローカル識別子を使ったエンド・ノード区分
US20050144310A1 (en) * 2003-12-11 2005-06-30 International Business Machines Corporation In-order delivery of plurality of RDMA messages
JP2005524264A (ja) * 2002-04-25 2005-08-11 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワークにおけるデータ転送を管理するデータ処理システムおよび方法
US20060075067A1 (en) * 2004-08-30 2006-04-06 International Business Machines Corporation Remote direct memory access with striping over an unreliable datagram transport
JP2008507201A (ja) * 2004-07-14 2008-03-06 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク・プロトコル処理のオフロードにおいて接続確立をサポートする装置および方法
CN103986647A (zh) * 2014-05-21 2014-08-13 大唐移动通信设备有限公司 报文传输方法及设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171484B1 (en) * 2000-05-24 2007-01-30 Krause Michael R Reliable datagram transport service
US6990528B1 (en) * 2000-10-19 2006-01-24 International Business Machines Corporation System area network of end-to-end context via reliable datagram domains
US7716290B2 (en) * 2003-11-20 2010-05-11 Microsoft Corporation Send by reference in a customizable, tag-based protocol
US20070208820A1 (en) * 2006-02-17 2007-09-06 Neteffect, Inc. Apparatus and method for out-of-order placement and in-order completion reporting of remote direct memory access operations
EP2847947B1 (en) * 2012-05-10 2020-12-23 Samsung Electronics Co., Ltd. Method and system for connectionless transmission during uplink and downlink of data packets
US9544927B2 (en) * 2012-07-02 2017-01-10 Alcatel Lucent System, method and computer readable medium for bearer activation in a core network for wireless devices
US9697147B2 (en) * 2012-08-06 2017-07-04 Advanced Micro Devices, Inc. Stacked memory device with metadata management

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002305535A (ja) * 2001-01-11 2002-10-18 Internatl Business Mach Corp <Ibm> データを転送する信頼できるプロトコルを提供する方法および装置
JP2004531175A (ja) * 2001-06-29 2004-10-07 インターナショナル・ビジネス・マシーンズ・コーポレーション ローカル識別子を使ったエンド・ノード区分
US20030031183A1 (en) * 2001-08-09 2003-02-13 International Business Machines Corporation Queue pair resolution in infiniband fabrics
JP2005524264A (ja) * 2002-04-25 2005-08-11 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワークにおけるデータ転送を管理するデータ処理システムおよび方法
US20050144310A1 (en) * 2003-12-11 2005-06-30 International Business Machines Corporation In-order delivery of plurality of RDMA messages
JP2008507201A (ja) * 2004-07-14 2008-03-06 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワーク・プロトコル処理のオフロードにおいて接続確立をサポートする装置および方法
US20060075067A1 (en) * 2004-08-30 2006-04-06 International Business Machines Corporation Remote direct memory access with striping over an unreliable datagram transport
CN103986647A (zh) * 2014-05-21 2014-08-13 大唐移动通信设备有限公司 报文传输方法及设备

Also Published As

Publication number Publication date
AU2018250412A1 (en) 2018-11-08
CN110719294B (zh) 2021-06-01
EP3398315B1 (en) 2020-05-20
KR101941416B1 (ko) 2019-04-12
AU2016382952B2 (en) 2018-08-02
EP3734931A1 (en) 2020-11-04
EP3734931B1 (en) 2022-07-27
JP6569020B2 (ja) 2019-08-28
JP6564960B2 (ja) 2019-08-21
AU2018250412B2 (en) 2019-08-15
CN110557408A (zh) 2019-12-10
EP3731487A1 (en) 2020-10-28
CN110719294A (zh) 2020-01-21
JP6490310B2 (ja) 2019-03-27
CN108476209B (zh) 2019-11-05
JP2019504557A (ja) 2019-02-14
KR20190009419A (ko) 2019-01-28
BR112018013438A2 (pt) 2019-04-24
AU2019261814A1 (en) 2019-12-05
CL2018001771A1 (es) 2018-10-12
CN110557408B (zh) 2021-02-05
CN108476209A (zh) 2018-08-31
EP3398315A1 (en) 2018-11-07
EP3731487B1 (en) 2022-07-06
JP2019092217A (ja) 2019-06-13
KR102023122B1 (ko) 2019-09-20
KR20180089548A (ko) 2018-08-08
AU2016382952A1 (en) 2018-07-12
AU2019261814B2 (en) 2020-09-24
CA3010186C (en) 2021-07-13
SG11201805409SA (en) 2018-07-30
WO2017117259A1 (en) 2017-07-06
KR102055535B1 (ko) 2019-12-12
CA3010186A1 (en) 2017-07-06
KR20190108188A (ko) 2019-09-23

Similar Documents

Publication Publication Date Title
JP6490310B2 (ja) ネットワーキング技術
US11343198B2 (en) Reliable, out-of-order transmission of packets
US10917344B2 (en) Connectionless reliable transport
US10673772B2 (en) Connectionless transport service
JP6697556B2 (ja) マルチパス転送設計

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190304

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190304

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20190304

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20190315

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190325

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190326

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20190426

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20190426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190606

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190701

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190729

R150 Certificate of patent or registration of utility model

Ref document number: 6564960

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250