JP6296632B2 - マルチスレッドアプリケーションのためのセッションをリマッピングするための技術 - Google Patents

Description

本明細書において説明される例は、概ね、サーバとクライアントとの間のマルチスレッドプログラムにより生成されたデータをルーティングすることに関する。

複数のクライアントコンピューティングデバイスに結合された複数のネットワークサーバは、単一のコンピューティングプラットフォームによりサポートされる複数のオペレーティングシステムおよび／またはアプリケーションを可能とする仮想マシン（ＶＭ）をサポートまたはホスティングするべくますます構成されるようになっている。また、複数のＶＭをホスティングするサーバに高い利用可能性が所望である場合に、一次ＶＭ（ＰＶＭ）および二次ＶＭ（ＳＶＭ）は各々、別個の複数のサーバまたはノード（例えば、データセンタ内）においてホスティングされることがあり、それらの状態が再現され得る。複数の状態のこの再現は、「ノンストップサービス」のためのアプリケーションアグノスティックな、ソフトウェア実装されたハードウェアのフォールトトレンランスソリューションを提供し得る。フォールトトレンランスソリューションは、ＰＶＭをホスティングするサーバがハードウェア障害を被り、および／またはＰＶＭが障害状態に陥った場合に、ＳＶＭが引き継ぐ（フェールオーバ）ことを可能にし得る。

ロックステッピングは、１つの命令毎に複数のＶＭ状態を再現し得るフォールトトレンランスソリューションである。例えば、ＰＶＭおよびＳＶＭは、複数の決定論的命令においては並行して、実行されるが、複数の決定論的命令についてはロックステップする。しかし、各メモリアクセスが非決定論的であり得る複数のマルチプロセッサ（ＭＰ）実装を扱う場合に、ロックステッピングは、非常に大きなオーバヘッドを被り得る。

チェックポイントは、複数の周期的エポックでＳＶＭに対してＰＶＭ状態を再現する別のフォールトトレランスソリューションである。チェックポイントにおいては、好結果のフェールオーバを保証するべく、全ての出力パケットは、好結果のチェックポイントが完了するまでバッファリングされる必要があり得る。ＶＭ環境における好結果のチェックポイントに至るまでバッファリングすることは、出力パケットバッファリングおよび頻繁なチェックポイントに起因して更なるネットワークのレーテンシおよびオーバヘッドをもたらし得る。

コースグレインのロックステッピング（ＣＯＬＯ）は、クライアントからの同一の要求／データ（入力）ネットワークパケットを提供されるＰＶＭおよびＳＶＭの双方を有する、別のフォールトトレランスソリューションである。ＣＯＬＯをサポートするロジックは、ＰＶＭおよびＳＶＭの複数の出力応答をモニタリングすることが可能であり、ＳＶＭにより生成されたネットワーク応答（出力）がＰＶＭのものと一致する限り、ＳＶＭの状態をＰＶＭの状態の有効なレプリカとみなし得る。所与のネットワーク応答が一致しない場合、クライアントへのネットワーク応答の送信は、ＰＶＭ状態がＳＶＭ状態に同期される（新しいチェックポイントを強制する）まで保留される。従って、ＣＯＬＯは、フォールトトレンラントなシステムがＳＶＭに対するフェールオーバにより高度に利用可能であることを保証し得る。ＳＶＭの内部状態がＰＶＭのものと異なることを非決定論が意味したとしても、高い利用可能性は、存在し得、ＳＶＭは、同様に有効であり、外部のオブサーバの視点から見て、ＣＯＬＯを実装するフォールトトレンラントなシステムと依然として一致する。従って、ＣＯＬＯは、純粋なロックステップ、またはチェックポイントによるフォールトトレランスソリューションに対する複数の利点を有し得る。

複数のＣＯＬＯフォールトトレンランスソリューションは、トランスポート制御プロトコル（ＴＣＰ）スタックに関連するものとして、そのような複数のプロトコルを利用し得る。ＴＣＰスタックは、１つの接続毎に状態を有するように構成され得、パケット損失および／またはパケット再配列から回復することが可能となり得る。ＣＯＬＯは、ＴＣＰ接続毎の応答パケット比較を用いることを含み得る。ＰＶＭから出力された各ＴＣＰ接続の複数の応答パケットがＳＶＭから出力された各ＴＣＰ接続の複数の応答パケットに一致する場合に、ＴＣＰ接続毎の応答パケット比較は、ＳＶＭ状態を有効なレプリカとみなし得る。この一致は、複数のＴＣＰ接続全体における可能なパケット配列とは関係ない。

例示的な第１のシステムを図示する。 複数の例示的なプログラミングモデルを図示する。 例示的な第２のシステムを図示する。 例示的な第３のシステムを図示する。 例示的なＴＣＰフローを図示する。 装置の例示的なブロック図を図示する。 第１のロジックフローの一例を図示する。 第２のロジックフローの一例を図示する。 第３のロジックフローの一例を図示する。 ストレージ媒体の一例を図示する。 例示的なコンピューティングプラットフォームを図示する。

本開示において企図されるように、ＣＯＬＯは、純粋なロックステップ、またはチェックポイントによるフォールトトレランスソリューションに対する複数の利点を有し得る。ＣＯＬＯは、ＰＶＭおよびＳＶＭをホスティングする複数のサーバを用いることにより、高度に利用可能なフォールトトレンラントなシステムの性能を大きく向上させ得る。しかし、ＣＯＬＯの性能は、各ＴＣＰ接続の出力の類似性に依存する。例えば、ＴＣＰ接続毎のＰＶＭおよびＳＶＭの同一の出力パケットの数が生成され得、あるいはＰＶＭおよびＳＶＭの持続時間は、全てのＴＣＰ接続に対する一致する出力パケットを生成し得る。

出力の類似性に対する潜在的に大きな影響は、ＰＶＭまたはＳＶＭにより実行される複数のマルチスレッドアプリケーションにより実装されたプログラミングモデルであり得る。例えば、国際標準化機構（ＩＳＯ）の１９９６年６月に刊行された刊行物ＩＳＯ／ＩＥＣ７４９８−１により説明される開放型システム間相互接続（ＯＳＩ）モデルのレイヤ５、６または７等のより高い複数のレベルのレイヤに対するプログラミングモデルである。ＴＣＰ接続毎の応答パケットを生成するべく、専用のスレッドが用いられる場合、出力は、ＰＶＭおよびＳＶＭの間で一致する可能性が高い。これは、シングルセッションプログラミングモデルと呼ばれる。一方、より高い複数のＯＳＩレイヤのためのプログラミングモデルが単一のＴＣＰ接続にマージされる複数のスレッド（マルチセッションプログラミング）を用いる場合、出力の類似性が問題となる。出力の類似性は、マルチセッションプログラミングにおける各スレッドの実行時間がＰＶＭとＳＶＭとの間で異なり得るので問題となることがある。本明細書において説明される複数の例が必要とされるのは、この問題に関してである。

いくつかの第１の例によれば、マルチスレッドアプリケーションのための複数のセッションをリマッピングするための技術は、アプリケーションを別個に実行することが可能なＰＶＭまたはＳＶＭをホスティングするように構成されたサーバ用の回路において、アプリケーションから行われた第１および第２のソケットＡＰＩの呼び出しを傍受することを含み得る。これらの第１の例においては、第１および第２のソケットＡＰＩは、第１および第２のセッションのそれぞれを、サーバのクライアントに結合された複数のＴＣＰ接続のうち同一のＴＣＰ接続を介した予期される出力にルーティングするように構成され得る。第１および第２のセッションは、クライアントから受信されたデータに応答して、アプリケーションにより生成され得る。複数の技術は、第１および第２のセッションについての第１および第２の識別子情報のそれぞれを用いてセッションインデックスを生成し、次いで第１および第２のセッションを複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介した実際の出力にリマッピングすることも含み得る。第１および第２のセッションは、リマッピングされ、セッションインデックスは、第１および第２のセッションを同一のＴＣＰ接続と再度組み合わせるべく、クライアントにおいて用いられることが可能である。

いくつかの第２の例において、マルチスレッドアプリケーションのための複数のセッションをリマッピングするための技術は、複数のＴＣＰ接続を介してサーバに結合されたクライアント用の回路において、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して、第１および第２のセッションを受信することを含み得る。これらの第２の例においては、第１および第２のセッションは、サーバによりホスティングされるＰＶＭまたはＳＶＭにより実行される第１のアプリケーションにより生成され、別個の複数のＴＣＰ接続を介してサーバから出力され得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションにより第１のアプリケーションにすでに送信された要求に応答して生成され得る。複数の技術は、第１および第２のセッションについての識別子情報を有するセッションインデックスを受信し、セッションインデックスに基づいて複数のＴＣＰ接続のうち同一のＴＣＰ接続に対して第１および第２のセッションを再グループ化することも含み得る。複数の技術は、同一のＴＣＰ接続を介して、第２のアプリケーションに対する第１および第２のソケットＡＰＩそれぞれに第１および第２のセッションを転送することも含み得る。

図１は、例示的な第１のシステムを図示する。いくつかの例において、図１に示されるように、第１の例示的システムは、システム１００を含む。システム１００は、内部ネットワーク１３０を介して二次ノード／サーバ１２０に結合された一次ノード／サーバ１１０を有するデータセンタ１０５を含む。また、図１に示されるように、一次ノード１１０または二次ノード１２０は、ネットワーク１４０によりルーティングされるネットワーク（ＮＷ）通信チャネル１４２を介してクライアント１５０に結合され得る。

いくつかの例によれば、一次ノード１１０および二次ノード１２０は、フォールトトレンランスシステムの一部として構成され得る。これらの例において、一次ノード１１０は、ＰＶＭ１１２をホスティングするように構成され得、二次ノード１２０は、ＳＶＭ１２２をホスティングするように構成され得る。ＰＶＭ１１２およびＳＶＭ１２２の双方は、同一のアプリケーション１０１を別個に実行することが可能であり得る。いくつかの例において、アプリケーション１０１は、複数のセッションを同一のＴＣＰ接続にルーティングするマルチセッションプログラミングモデルを使用し得る。このタイプのマルチセッションプログラミングモデルは、より詳細に以下に説明される。

いくつかの例において、一次ノード１１０および二次ノード１２０は各々、それぞれのハートビート１１５および１２５を保持して、ＰＶＭ１１２およびＳＶＭ１２２についての正常ステータスを通信し得る。例えば、ハートビート１１５は、ＰＶＭ１１２についての正常ステータス情報を中継し、ＰＶＭが障害を起こし、または応答不能になり、従ってＳＶＭ１２２に、フェールオーバし、クライアント１５０からの複数の要求を提供または処理するＰＶＭになるように要求しているか否かを二次ノード１２０が判断することを可能にし得る。同様に、ハートビート１２５は、ＳＶＭ１２２についての正常ステータス情報を中継し、一次ノード１１０に、ＳＶＭが障害を起こし、または応答不能になり、従って別のＳＶＭに、ＰＶＭ１１２に対するフォールトトレンランスを提供するように構成されることを要求しているか否かを判断することを可能にし得る。

いくつかの例によれば、ＰＶＭ１１２およびＳＶＭ１２２は、クライアント１５０におけるアプリケーション１５２から受信された複数の要求を処理するための同一のネットワークドメイン０内で動作し得る。これらの例において、複数の要求は、一次ノード１１０における外部ＮＷインターフェース１１８を介して、ＮＷ通信チャネル１４２経由で受信され得る。その後、複数の要求は、ＰＶＭ１１２およびＳＶＭ１２２の双方において実行されるアプリケーション１０１に同時にルーティングされ得る。一次ノード１１０およびＣＯＬＯマネージャ１２４におけるＣＯＬＯマネージャ１１４は、アプリケーション１０１により生成された複数の出力／応答をモニタリングし得る。ＣＯＬＯマネージャ１１４および１２４は、複数の出力／応答が一致しない場合に複数の出力／応答を留保し、それぞれのストレージ１１６および１２６に保留された複数の出力／応答を少なくとも一時的に格納し得る。次いで、ＣＯＬＯマネージャ１１４および１２４は、新しいチェックポイント（例えば、ＶＭチェックポイント１１３および１２３）に強制して、ＳＶＭ１２２がＳＶＭ１１２と同期されるようにし得る。

いくつかの例において、マルチセッションプログラミングによりＰＶＭ１１２およびＳＶＭ１２２において別個に実行されるアプリケーション１０１の間の可能性のある出力の不均衡を減少させ得る、複数の技術が実行され得る。以下に更に説明されるように、これらの技術は、これらのセッションを実際に出力する異なる複数のＴＣＰセッションにリマッピングすることにより、同一のＴＣＰ接続を介して予期される出力に対する複数のセッションを切断することが可能なロジックおよび／または複数の特徴（図１において示されない）を含み得る。次いで、リマッピングされた複数のＴＣＰセッションに対する実際の複数の出力／応答は、ＣＯＬＯマネージャ１１４および１２４により比較され、ＰＶＭ１１２およびＳＶＭ１２２が同期された状態にあるか否かを判断し得る。ＣＯＬＯマネージャ１１４および１２４によるこの比較は、典型的に、ＴＣＰ毎の接続に依存する。クライアント１５０における類似の切断ロジックおよび／または複数の特徴は、アプリケーション１０１がこれらの出力／応答をルーティングすることを最初に想定していたという複数の出力／応答を、同一のＴＣＰ接続を介してクライアント１５０におけるアプリケーション１５２に提供する前に、複数のセッションを再グループ化することが可能であり得る。従って、アプリケーション１０１およびアプリケーション１５２の双方は、この切断を認識していないことがある。

図１は、ネイティブデバイスドライバを起動し、他の複数のゲストを管理するべく、ドメイン０等の特権を付与されたゲストのオペレーティングシステムが用いられ得る、１タイプのハイブリッド仮想マシンマネージャ（ＶＭＭ）のモデルを図示する。他の複数の例において、ハイパーバイザモデルまたはホストベースのモデル等、複数のタイプのＶＭモデルが、データセンタ１０５に類似するデータセンタにおいて実装され得る。これらの他の例においては、ハイパーバイザモデルまたはホストベースのモデルは、タイプＩＩのＶＭＭモデルであってもよい。一方、図１に示されるハイブリッドＶＭモデルは、タイプＩのＶＭＭモデルであり得る。複数の例は、タイプＩまたはタイプＩＩのＶＭＭモデルのみに限定されない。マルチスレッドアプリケーションのための複数のセッションをリマッピングするための複数の例は、双方のタイプのＶＭモデルに等しく適用され得る。

図２は、複数の例示的なプログラミングモデル２００を図示する。いくつかの例において、図２に示されるように、シングルセッションプログラミング２１０は、アプリケーションレイヤ２１２、プレゼンテーションレイヤ２１４、およびセッションレイヤ２１６のためのより高いレベルのレイヤのスタック処理にシングルスレッドを用いることを含み得る。このシングルスレッドからの複数の出力は、ＴＣＰレイヤ２１８におけるＴＣＰ接続２１５を介して、ソケットアプリケーションインターフェース（ＡＰＩ）２１７においてルーティングされ得る。これらの例において、ＴＣＰパケット２１９は、次にＴＣＰパケット２１９の生成をもたらす要求のソースに最後の提供を行うべく、ＯＳＩプロトコルスタックの複数のより低いレイヤ（例えば、ネットワーク、データリンク、または物理的レイヤ）に送信または出力され得る。ＰＶＭまたはＳＶＭにより実行されるアプリケーションにより実行される場合にシングルセッションプログラミング２１０を用いると、ＴＣＰパケット２１９の類似の複数の出力をもたらす可能性が高くなり得る。従って、ＣＯＬＯのフォールトトレランススキームは、このタイプのシングルセッションプログラミングと良好に機能し得る。

いくつかの例によれば、図２に示されるように、マルチセッションプログラミング２２０は、複数のスレッドＴ１、Ｔ２、Ｔ３、およびＴｎを用いることを含み得、「ｎ」は、３より大きい任意の正の全ての整数であり得る。これらの例において、スレッドＴ１〜Ｔｎは、アプリケーションレイヤ２２２、プレゼンテーションレイヤ２２４、およびセッションレイヤ２２６のためのより高いレベルのレイヤのスタック処理に用いられ得る。次いで、スレッドＴ１〜Ｔｎに対する複数の出力は、ＴＣＰレイヤ２２８におけるＴＣＰ接続２２５を介してソケットＡＰＩ２２７においてルーティングされ得る。ＴＣＰパケット２２９は、次にＴＣＰパケット２１９の生成をもたらす要求のソースに最後の提供を行うべく、ＯＳＩプロトコルスタックの複数のより低いレイヤに送信または出力され得る。シングルセッションプログラミング２１０と対照的に、ＰＶＭまたはＳＶＭにより実行されるアプリケーションにより実行される場合にマルチセッションプログラミング２２０を用いると、複数のＴＣＰパケット２１９の異なる複数の出力をもたらす可能性が高くなり得る。すでに言及されたように、この相違は、各スレッド間の実行時間における変更に起因することがある。マルチセッションプログラミング２２０に用いられるスレッドの数が増加するので、これらの変更は、増加する可能性が高い。ＰＶＭとＳＶＭとの間のＴＣＰパケット２１９に対する複数の出力の変更は、ＣＯＬＯのフォールトトレランススキームの性能に対する問題となり得る。

図３は、例示的な第２のシステムを図示する。図３に示されるように、例示的な第２のシステムは、システム３００を含む。いくつかの例において、システム３００は、ノードまたはサーバによりホスティングされるＰＶＭまたはＳＶＭにより実行され得るアプリケーション３１０を含み得る。ノードまたはサーバは、例えば、図１に示されるデータセンタ１０５等のデータセンタに位置し得る。また、アプリケーション３１０は、図１において示されるクライアント１５０等のサーバに結合されたクライアントにおいて実行され得る。いくつかの例によれば、アプリケーション３１０は、それぞれのスレッド１、２、３、およびｎにより実行されるセッション３１２―１、３１２―２、３１２―３、および３１２―ｎを含み得るマルチセッションプログラミングモデルを用いるように構成され得る。これらの例において、アプリケーション３１０は、元のソケットＡＰＩ３１５を呼び出し、同一のＴＣＰ接続３１１を介して予期される出力に対するセッション３１２―１〜３１２―ｎをルーティングし得る。複数の出力は、受信された要求（例えば、クライアントからサーバに、または逆にサーバからクライアントに）関連または関係し得る。

いくつかの例において、図３に示されるように、システム３００は、アプリケーション３１０およびＴＣＰレイヤ３３０に対する複数のセッション出力の間に位置するＴＣＰデカップラ３２０も含み得る。これらの例において、ＴＣＰデカップラ３２０は、リマッピング／再グループ化ロジック３２２を含み得る。リマッピング／再グループ化ロジック３２２は、ＴＣＰ接続３１１を介して出力するべく、セッション３１２―１〜３１２―ｎをルーティングするように構成された複数の元のソケットＡＰＩ３１５を傍受することが可能であり得る。また、リマッピング／再グループ化ロジック３２２は、セッション３１２―１〜３１２―ｎについての識別子情報を取得することが可能であり、セッションインデックス３２４を生成し、その次にＴＣＰレイヤ３３０において別個の複数のＴＣＰ接続３３２―１〜３３２―ｎを介する実際に出力するためにセッション３１２―１〜３１２―ｎをリマッピングし得る。リマッピング／再グループ化ロジック３２２は、例えば、新しい複数のソケットＡＰＩ３２５を呼び出し、ＴＣＰ接続３３２―１〜３３２―ｎを介した実際の複数の出力のためにセッション３１２―１〜３１２―ｎをルーティングし、ＴＣＰパケット３３４がこれらの異なるＴＣＰ接続を介して出力されるようにし得る。

いくつかの例によれば、セッションインデックス３２４は、セッション３１２―１〜３１２―ｎがアプリケーション３１０から出力されるようにした要求アプリケーションを生じたサーバまたはクライアントに通信し得る。この点で、セッションインデックス３２４は、サーバまたはクライアントにおいて用いられることが可能であり、要求アプリケーションに提供する前にセッション３１２―１〜３１２―ｎをＴＣＰ接続３１１と再度組み合わせることができる。いくつかの例において、識別子情報は、（例えば、アプリケーション３１０により）スレッド１〜ｎの各々に別個に割り当てられた複数のスレッド名または識別子を含み得る。いくつかの他の例において、識別子情報は、それぞれのセッション３１２―１〜３１２―ｎを生成するためのプロトコルスタックパターンを実行することに関連するコードパターン（例えば、インターネットプロトコル（ＩＰ）アドレスを含む）の組み合わせ等、セッション３１２―１〜３１２―ｎと関連する複数のプロトコルスタックパターンを含み得る。

いくつかの例において、アプリケーション３１０は、複数のソケットＡＰＩのダイナミックリンクライブラリ（図示せず）を使用して、ＴＣＰ接続３１１を含む複数のＴＣＰ接続を介して予期される出力に対するセッション３１２―１〜３１２―ｎをルーティングし得る。これらの例においては、リマッピング／再グループ化ロジック３２２は、ダイナミックリンクライブラリをＴＣＰデカップルリンクライブラリ（図示せず）で代用することにより元の複数のソケットＡＰＩ３１５を傍受することが可能であり得る。次に、代用されるＴＣＰデカップルリンクライブラリは、ＴＣＰ接続３２２―１〜３２２―ｎを介して実際の出力のためにセッション３１２―１〜３１２―ｎをリマッピングするべく、用いられ得る。デカップルリンクライブラリは、セッションインデックス１２４と通信し、要求アプリケーションに提供する前に、要求元クライアントまたはサーバがセッション３１２―１〜３１２―ｎをＴＣＰ接続３１１と再度組み合わせることを可能にし得る。

図３には示されていないが、いくつかの例によれば、アプリケーション３１０とＴＣＰレイヤ３３０との間のＴＣＰデカップラ３２０をむしろ展開する。ＴＣＰデカップラ３２０は、ＴＣＰレイヤ３３０に含まれ得る、組み込まれたインサイダレイヤ４（ＴＣＰ）ソフトウェアであってもよい。例えば、カーネルＴＣＰ／ＩＰスタックに組み込まれる。

いくつかの例によれば、要求元クライアントは、ラウンドロビンポリシを含むが、これに限定されない再グループ化ポリシを用いてＴＣＰ接続３１１にセッション３１２―１〜３１２―ｎを再グループ化することが可能であり得る。また、一次ノードの障害（例えば、ハードウェア障害）に起因するフェールオーバの場合に、複数の内部ＴＣＰエラー制御メカニズムは、ＳＶＭを用いて障害を起したＰＶＭのＴＣＰ状態を回復するべく使用され、ＴＣＰ接続毎ベースで複数の応答パケットを更に提供し得、次いで応答パケットは、再グループ化ポリシにより再グループ化され得る。

いくつかの例において、セッション３１２―１〜３１２―ｎのリマッピングは、モニタリングされる複数の出力が複数のマルチセッションプログラミングモデルを用いるアプリケーションに対するものである場合、ＰＶＭまたはＳＶＭをホスティングするように構成された一次または二次ノードにおいて、ＣＯＬＯマネージャに対する１つのＴＣＰ出力毎の類似性を向上させ得る。また、いくつかの例において、セッション３１２―１〜３１２―ｎは、図３に示された１：１のマッピングではなく複数のセットのＴＣＰ接続にマッピングされ得る。例えば、ＴＣＰ接続３１１からリマッピングすることは、ｍ：１の比に応じてリマッピングすることを含み得、「ｍ」は、１よりも大きい任意の正の全整数値であり、セッション３１２―１〜３１２―ｎ以外のｍのセッションは、マッピングされ、ＴＣＰ接続３３２―１〜３３２―ｎ以外の単一のＴＣＰ接続を共有し得る。ＴＣＰ接続３１１からリマッピングすることは、ｍ：ｏの比に応じてリマッピングすることも含み得、「ｏ」は、ｍよりも大きい任意の正の全整数値である。ｍ：ｏの比については、セッション３１２―１〜３１２―ｎ以外のｍのセッションは、ＴＣＰ接続３３２―１〜３３２―ｎのうち複数のｏＴＣＰ接続にマッピングされ得る。１：１、ｍ：１、またはｍ：ｏのこれらの比は、これらのリマッピングスキームを使用し得るシステムの必要性に基づいて柔軟に確立され得る。例えば、複数のＴＣＰ接続は、所与のシステムにおいて限定され、または豊富であり、所与のシステムの要求に基づいて変動もし得る。従って、所与のシステムの必要性に適合する比は、それに応じて調整され得る。

図４は、例示的な第３のシステムを図示する。図４に示されるように、例示的な第３のシステムは、システム４００を含む。いくつかの例において、図４に示されるように、システム４００は、ＮＷ通信チャネル４３０を介してサーバ４２０に結合されたクライアント４１０を含む。これらの例において、クライアント４１０は、アプリケーション４１２、ＴＣＰデカップラ４１４、およびオペレーティングシステム（ＯＳ）のＴＣＰスタック４１６を含み得る。また、サーバ４２０は、アプリケーション４２２、ＴＣＰデカップラ４２４、およびＯＳ ＴＣＰスタック４２６を含み得る。サーバ４２０は、例えば、アプリケーション４２２を実行することが可能であり得るＰＶＭまたはＳＶＭ（図示せず）をホスティングするように構成され得る。

いくつかの例によれば、アプリケーション４１２および４２２の双方は、Ａｐｐ＿Ｓｏｃｋｅｔ４１１および４２１のそれぞれを呼び出し、同一のＴＣＰ接続を介して複数のセッションをルーティングするマルチセッションプログラミングモデルを使用する、少なくとも１つのアプリケーションを含み得る。図３について上に説明されたＴＣＰデカップラ３２０と同様に、ＴＣＰデカップラ４１４および４２４は、複数の異なるＴＣＰ接続を介して、それぞれのＯＳ＿Ｓｏｃｋｅｔ４１５に実際に出力する複数のセッションをリマッピングすることが可能であり得る。例えば、ＴＣＰデカップラ４２４のリマッピング／再グループ化ロジック４２３は、これらのセッションを傍受し、識別子情報を得、セッションインデックス４０５を生成し、次いでＯＳ ＴＣＰスタック４２６における異なるか、または別個の複数のＴＣＰ接続を介してＯＳ＿Ｓｏｃｋｅｔ４２５に対する出力の複数のセッションをリマッピングし得る。次に、ＯＳ ＴＣＰスタック４２６は、ＮＷ通信チャネル４３０を介して複数の応答ＴＣＰパケットをクライアント４１０へとルーティングし得る。次に、ＴＣＰデカップラ４１４のロジック４１３を再グループ化すると、複数の異なるＴＣＰ接続にリマッピングされた複数のセッションは、アプリケーション４２２がこれらのセッションを最初にマッピングしたのと同一のＴＣＰ接続と再グループ化され得る。セッションインデックス４０５は、ＴＣＰデカップラ４１４により用いられ、アプリケーション４１２に提供するべく、複数のセッションを同一のＴＣＰ接続と再グループ化し得る。

いくつかの例において、リマッピング／再グループ化ロジック４２３は、アプリケーション４２２により生成された複数のセッションを選択的に傍受し、再度ルーティングすることが可能であり得る。例えば、アプリケーション４２２は、シングルセッションプログラミングモデルを実行する第１のアプリケーションと、マルチセッションプログラミングモデルを実行する第２のアプリケーションとを含み得る。リマッピング／再グループ化ロジック４２３は、リマッピングする第２のアプリケーションのみを選択的に傍受し得る。シングルセッションプログラミングは、複数のスレッドを用いるマルチセッションプログラミングの場合に生じる可能性が高い、ありうる異なる複数の出力による損害がないので、リマッピング／再グループ化ロジック４２３は、第１のアプリケーションを選択しないことがある。従って、サーバ４２０によりホスティングされるＰＶＭとＳＶＭとの間の出力の類似性を向上させるのに、シングルセッションプログラミングについては、リマッピングは必要とされないことがある。

いくつかの他の例において、アプリケーション４２２は、複数のＴＣＰ接続を用いてもよく、これらの複数のＴＣＰ接続の一部のみがリマッピング／再グループ化ロジック４２３により傍受およびリマッピングされ得る。例えば、１つのＴＣＰ接続は、シングルセッションプログラミングモデルと共に用いられるが、他のＴＣＰ接続は、マルチセッションプログラミングモデルと共に用いられる。これらの他の例において、マルチセッションプログラミングモデルと共に用いられた他のＴＣＰ接続のみが、傍受され得る。

図５は、例示的なＴＣＰフロー５００を図示する。いくつかの例において、ＴＣＰフロー５００は、ＴＣＰプログラミングインターフェースのパラダイムであってもよく、ＴＣＰクライアント５１０とＴＣＰサーバ５２０との間の通信のフローを図示し得る。図５に示されるように、ＴＣＰフロー５００は、ＴＣＰ接続設定５０５、データ交換５１５、およびＴＣＰテアダウン５２５を含むＴＣＰプログラミングのための様々なフェーズまたはステージを含み得る。いくつかの例によれば、ＴＣＰデカップラ３２０またはＴＣＰデカップラ４１３／４２３等のＴＣＰデカップラは、同一のＴＣＰ接続に対する出力のための複数のセッションをルーティングするように構成された複数のソケットＡＰＩを傍受するべく、ＡＰＩエミュレーションが可能であり得る。当該ＡＰＩエミュレーションは、様々なフェーズのどれが当該ＡＰＩエミュレーションが対象とされるＴＣＰ接続設定５０５、データ交換５１５、またはＴＣＰテアダウン５２５を含むかに基づいて行われ得る。

いくつかの例によれば、ＴＣＰ接続設定５０５におけるＡＰＩエミュレーションについては、ＴＣＰデカップラは、複数のセッションのためのソケットＡＰＩ（図５においてｓｏｃｋｅｔ（）として示される）を傍受し、これらの傍受されたソケットＡＰＩに対して即時に複数のＯＳ＿ｓｏｃｋｅｔ ＡＰＩを生成し得る。例えば、ｏｓ＿ｓｏｃｋｅｔ＿ｘ（ｘ＝１，２，３，...ｎ）であれば、ａｐｐ＿ｓｏｃｋｅｔ＿１を有するアプリケーションを返す。これらの例において、ａｐｐ＿ｓｏｃｋｅｔ＿１は、ＴＣＰデカップラのみにおいて有効であってもよい。アプリケーションは、複数の他のａｐｐ＿ｓｏｃｋｅｔ＿ｘ（ｘ＝２，３...）も同様に生成し得る。同一のポリシは、ｏｓ＿ｓｏｃｋｅｔ＿ｘ（ｘ＝１，２，...，ｎ）に対するＯＳ＿ｓｏｃｋｅｔレイヤのｂｉｎｄ（）、ｌｉｓｔｅｎ（）、ｃｏｎｎｅｃｔ（）、およびａｃｃｅｐｔ（）のオペレーションにより、ａｐｐ＿ｓｏｃｋｅｔ＿１のｂｉｎｄ（）、ｌｉｓｔｅｎ（）、ｃｏｎｎｅｃｔ（）、およびａｃｃｅｐｔ（）ＡＰＩ ａｃｃｅｓｓに適用され得る。

いくつかの例において、ＴＣＰ接続設定５０５におけるＡＰＩエミュレーションは、ｏｓ＿ｓｏｃｋｅｔレイヤアクセスを即時に含むことなく、複数の内部ソフトウェア状態を純粋に伴うｓｏｃｋｅｔ（）、ｂｉｎｄ（）、ｌｉｓｔｅｎ（）、ｃｏｎｎｅｃｔ（）、およびａｃｃｅｐｔ（）ＡＰＩをエミュレートするデカップラも含み得る。これに代えて、ＴＣＰ接続設定５０５が完了（例えば、ＴＣＰ３―ｗａｙハンドシェークが完了）したことを検出すると、ＴＣＰデカップラがｏｓ＿ｓｏｃｋｅｔレイヤの複数の接続ｏｓ＿ｓｏｃｋｅｔ＿ｘ（ｘ＝１，２，３，...ｎ）を設定し、そして、ｏｓ＿ｓｏｃｋｅｔ ｌａｙｅｒ ｓｏｃｋｅｔ（）、ｂｉｎｄ（）、ｌｉｓｔｅｎ（）、ｃｏｎｎｅｃｔ（）、およびａｃｃｅｐｔ（）ＡＰＩを用いて、ｓｏｃｋｅｔ（）で返されるｓｏｃｋｅｔ＿１で返されるａｐｐ＿ｓｏｃｋｅｔ＿１とマッピングする。いくつかの例において、ＴＣＰデカップラは、次にＴＣＰテアダウン５２５において、ＴＣＰクライアント５１０から送信されたＴＣＰサーバ５２０において読み取られたファイル終了（ＥＯＦ）メッセージに応答して、ｏｓ＿ｓｏｃｋｅｔ＿ｘにマッピングされた複数のセッションを除去し得る。

いくつかの例によれば、データ交換５１５におけるＡＰＩエミュレーションは、複数のアウトバウンドデータセッションに対して、一意なセッションインデックスとして、現在の所与のスレッドの識別子および／または所与のスレッドの名前および／またはコール関数ＩＰアドレスを用いるＴＣＰデカップラを含み得る。ＴＣＰデカップラは、ｏｓ＿ｓｏｃｋｅｔ＿ｘ接続ＩＤの場合に、固定マッピングテーブル（リニアテーブル等）をアドレス指定するべくセッションインデックスを用い、あるいはセッションからｏｓ＿ｓｏｃｋｅｔにマッピングするコリジョンチェーンを有するハッシュテーブルを用い得る。これらの例においては、ゲストＯＳタスクマネージメントコンポーネントは、各スレッドに対しても同様に一意な識別子を提供するべくフックされ得る。ｏｓ＿ｓｏｃｋｅｔ＿ｘが選択されると、ＴＣＰデカップラは、ｏｓ＿ｓｏｃｋｅｔ＿ｘのｗｒｉｔｅ（）ＡＰＩを用いてセッションデータ（例えば、セッションインデックス）を送信し得る。一方、クライアント５１０は、複数のＴＣＰ接続からのｒｅａｄ（）ＡＰＩを用いてセッションデータを受信すると、それらを互いに組み合わせ、再グループ化された複数のセッションをクライアント５１０におけるセッションレイヤに提供し得る。

図６は、装置６００の例示的なブロック図を図示する。図６に示されるように、第１の装置は、装置６００を含む。図６に示す装置６００は一定のトポロジにおいて限定された数の要素を有するが、装置６００は、所与の実装のために所望の代替のトポロジにおいて、より多いか、またはより少ない要素を含んでもよいことを理解されたい。

装置６００は、サーバまたはクライアントコンピューティングデバイスにおいて保持された回路６２０によりサポートされ得る。回路６２０は、１または複数のソフトウェアもしくはファームウェア実装されたモジュールまたはコンポーネント６２２―ａを実行するように構成され得る。本明細書で用いられる「ａ」、「ｂ」、および「ｃ」、ならびに類似の標記は、任意の正の整数を表す変数であることが意図されていることは留意に値する。従って、例えば、実装がａ＝６の値を設定する場合、コンポーネント６２２―ａに対するソフトウェアまたはファームウェアの完全なセットは、コンポーネント６２２―１、６２２―２、６２２―３、６２２―４、６２２―５、または６２２−６を含み得る。提示される複数の例は、この文脈において限定されず、終始用いられる異なる複数の変数は、同一または異なる整数値を表し得る。また、これらの「コンポーネント」は、コンピュータ可読媒体内に格納されたソフトウェア／ファームウェアであってもよく、複数のコンポーネントは、図６において複数の離散的ボックスとして示されているが、これは、別個の複数のコンピュータ可読媒体コンポーネント（例えば、別個のメモリ等）に格納するこれらのコンポーネントを限定するものではない。

いくつかの例によれば、回路６２０は、プロセッサまたはプロセッサ回路を含み得る。回路６２０は、複数の処理コアまたは要素を含み得るサーバまたはクライアント（例えば、一次ノード／サーバ１１０、二次ノード／サーバ１２０、サーバ４２０、またはクライアント４１０）における回路の一部であってもよい。１または複数の処理コアを含む回路としては、ＡＭＤ（登録商標）のアスロン（登録商標）、デュロン（登録商標）、およびオプテロン（登録商標）のプロセッサ、ＡＲＭ（登録商標）のアプリケーション、エンベデッドおよびセキュアプロセッサ、ＩＢＭ（登録商標）、モトローラ（登録商標）のドラゴンボール（登録商標）およびＰｏｗｅｒＰＣ（登録商標）プロセッサ、ＩＢＭおよびソニー（登録商標）のセルプロセッサ、インテル（登録商標）のアトム（登録商標）、セレロン（登録商標）、コア（２）デュオ（登録商標）、コアｉ３、コアｉ５、コアｉ７、アイテニアム（登録商標）、ペンティアム（登録商標）、ジーオン（登録商標）、ジーオンＰｈｉ（登録商標）、およびエックススケール（登録商標）プロセッサ、および類似のプロセッサを含むが、これらに限定されない様々な市販のプロセッサのいずれであってもよい。いくつかの例によれば、回路６２０は、特定用途向け集積回路（ＡＳＩＣ）も含み得、少なくともいくつかのコンポーネント６２２―ａは、ＡＳＩＣの複数のハードウェア要素として実装され得る。

いくつかの第１の例によれば、装置６００は、複数のＴＣＰ接続６１５を介してクライアントに結合されたサーバに存在し得、サーバは、第１のアプリケーションを別個に実行することが可能なＰＶＭまたはＳＶＭをホスティングするように構成され得る。これらの第１の例において、装置６００は、傍受コンポーネント６２２―１を含み得る。傍受コンポーネント６２２―１は、回路６２０により実行され、第１のアプリケーションから行われた第１および第２のソケットＡＰＩ呼び出を傍受し得る。いくつかの例において、第１および第２のソケットＡＰＩは、複数のソケットＡＰＩ６０５に含まれ得る。ソケットＡＰＩ６０５は、第１のアプリケーションにより生成された複数のセッションを、複数のＴＣＰ接続６１５のうち同一のＴＣＰ接続にルーティングするように構成され得る。複数のセッションは、クライアントにおける第２のアプリケーションから受信された要求に応答して生成され得る。

いくつかの第１の例によれば、装置６００は、インデックスコンポーネント６２２―２も含み得る。インデックスコンポーネント６２２―２は、回路６２０により実行され、第１のアプリケーションにより生成された複数のセッションについての識別子情報を用いてセッションインデックスを生成する。これらの例において、インデックスコンポーネント６２２―２は、セッションインデックス６２４―ａを含むデータ構造体（例えば、ルックアップテーブル（ＬＵＴ）内に生成済みのセッションインデックスを保持または格納し得る。また、生成済みのセッションインデックスは、セッションインデックス６１０を介してクライアントに通信され得る。

第１の複数の例において、装置６００は、リマッピングコンポーネント６２２―３も含み得る。リマッピングコンポーネント６２２―３は、回路６２０により実行され、複数のＴＣＰ接続６１５のうち別個の複数のＴＣＰ接続を介して実際の出力のための第１のアプリケーションにより生成された複数のセッションをリマッピングし得る。これらの例において、複数のセッションは、セッションインデックス６１０がクライアントにおいて用いられ、クライアントにおける第２のアプリケーションに提供するべく、第１および第２のセッションを同一のＴＣＰ接続と再度組み合わせ得るように、リマッピングされ得る。いくつかの例において、リマッピングコンポーネント６２２―３は、デカップルリンクライブラリ６２５―ｂ（例えば、ＬＵＴ内に保持される）を用いて、複数のセッションを別個の複数のＴＣＰ接続にリマッピングすることが可能であり得る。

いくつかの第２の例によれば、装置６００は、複数のＴＣＰ接続６１５を介してサーバに結合されたクライアントに存在し得る。第１の複数の例と同様に、サーバは、第１のアプリケーションを別個に実行することが可能なＰＶＭまたはＳＶＭをホスティングするように構成され得る。これらの第２の複数の例において、装置６００は、受信コンポーネント６２２―４も含み得る。受信コンポーネント６２２―４は、回路６２０により実行され、複数のＴＣＰ接続６１５のうち別個の複数のＴＣＰ接続を介して第１のアプリケーションにより生成された第１および第２のセッションを受信し得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションにより第１のアプリケーションにすでに送信された要求に応答して生成され得る。

いくつかの第２の例によれば、クライアントにおける装置６００は、第１の複数の例について上で言及されたインデックスコンポーネント６２２―２も含み得る。これらの第２の例におけるインデックスコンポーネント６２２―２は、第１および第２のセッションについての識別子情報を有するセッションインデックス６１０を受信し得る。例えば、インデックスコンポーネント６２２―２は、セッションインデックス６２４―ａを含むＬＵＴ等のデータ構造体内に受信済みのセッションインデックス６１０を保持または格納し得る。

いくつかの第２の例によれば、装置６００は、再グループ化コンポーネント６２２―５も含み得る。再グループ化コンポーネント６２２―５は、回路６２０により実行され、セッションインデックス６２４―ａにおいて格納または保持されたセッションインデックスに基づいて、複数のＴＣＰ接続６１５のうち同一のＴＣＰ接続に第１および第２のセッションを再グループ化し得る。

いくつかの第２の例によれば、装置６００は、転送コンポーネント６２２―６も含み得る。転送コンポーネント６２２―６は、回路６２０により実行され、同一のＴＣＰ接続を介して、クライアントにおける第２のアプリケーションの第１および第２のソケットＡＰＩのそれぞれに第１および第２のセッションを転送し得る。

開示されるアーキテクチャの新規な複数の態様を実行する例示的な複数の方法論を表すロジックフローのセットが、本明細書に含まれる。簡明な説明の目的のために言えば、本明細書に示される１または複数の方法論は、連続する動作として示され、説明されるが、当業者は、本方法論が動作の順序によって限定されないことを理解するであろう。それによれば、いくつかの動作は、異なる順序および／または本明細書に示され、説明されるもの以外の複数の動作と同時に行われ得る。例えば、当業者は、別法では方法論を状態図等に連続する相互に関連した状態または事象として表すことができることを理解するであろう。更に、ある方法論において例示される動作全てが新規な実装に要求されないことがある。

ロジックフローは、ソフトウェア、ファームウェア、および／またはハードウェアで実装され得る。ソフトウェアおよびファームウェアの実施形態において、ロジックフローは、光、磁気、または半導体ストレージ等の少なくとも１つの非一時的コンピュータ可読媒体または機械可読媒体上に格納された複数のコンピュータ実行可能命令によって実装することができる。実施形態は、この文脈において限定されない。

図７は、第１のロジックフローの一例を図示する。図７に示されるように、第１のロジックフローは、ロジックフロー７００を含む。ロジックフロー７００は、１もしくは複数のロジック、特徴、または装置６００等、本明細書において説明される複数のデバイスにより実行されたいくつか、または全てのオペレーションを表し得る。より具体的には、ロジックフロー７００は、少なくとも傍受コンポーネント６２２―１、インデックスコンポーネント６２２―２、またはリマッピングコンポーネント６２２―３により実装され得る。

いくつかの例によれば、ブロック７０２におけるロジックフロー７００は、アプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成されたサーバ用の回路において、アプリケーションから行われた第１および第２のソケットＡＰＩ呼び出しを傍受し得る。第１および第２のソケットＡＰＩは、サーバのクライアントに結合された複数のＴＣＰ接続のうち同一のＴＣＰ接続を介して、予期される出力に対する第１および第２のセッションのそれぞれをルーティングするように構成され得る。第１および第２のセッションは、クライアントから受信されたデータに応答して、アプリケーションにより生成される。これらの例において、傍受コンポーネント６２２―１は、第１および第２のソケットＡＰＩを傍受し得る。

いくつかの例において、ブロック７０４におけるロジックフロー７００は、第１および第２のセッションについての第１および第２の識別子情報のそれぞれを用いてセッションインデックスを生成し得る。これらの例において、インデックスコンポーネント６２２―２は、セッションインデックスを生成し得る。

いくつかの例によれば、ブロック７０６におけるロジックフロー７００は、セッションインデックスがクライアントにおいて用いられ、第１および第２のセッションを同一のＴＣＰ接続と再度組み合わせることが可能となるように、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して実際に出力する第１および第２のセッションをリマッピングし得る。これらの例において、リマッピングコンポーネント６２２―３は、第１および第２のセッションをリマッピングし得る。

図８は、第２のロジックフローの一例を図示する。図８に示されるように、第２のロジックフローは、ロジックフロー８００を含む。ロジックフロー８００は、１もしくは複数のロジック、特徴、または装置６００等、本明細書において説明される複数のデバイスにより実行されたいくつか、または全てのオペレーションを表し得る。より具体的には、ロジックフロー８００は、少なくとも受信コンポーネント６２２―４、インデックスコンポーネント６２２―２、再グループ化コンポーネント６２２―５、または転送コンポーネント６２２―６により実装され得る。

いくつかの例によれば、ブロック８０２におけるロジックフロー８００は、アプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成されたサーバにおいて、クライアントとの別個の複数のＴＣＰ接続を介して第１および第２のセッションを受信し得る。第１および第２のセッションは、第１のアプリケーションから第２のアプリケーションへとすでに送信された要求に応答して、クライアントにおける第２のアプリケーションにより生成され得る。これらの例においては、受信コンポーネント６２２―４は、第１および第２のセッションを受信し得る。

いくつかの例において、ブロック８０４におけるロジックフロー８００は、第１および第２のセッションについての識別子情報を有するセッションインデックスを受信し得る。これらの例において、インデックスコンポーネント６２２―２は、セッションインデックスを受信し得る。

いくつかの例によれば、ブロック８０６におけるロジックフロー８００は、セッションインデックスに基づいて、同一のＴＣＰ接続に第１および第２のセッションを再グループ化し得る。これらの例においては、再グループ化コンポーネント６２２―５は、第１および第２のセッションを再グループ化し得る。

いくつかの例において、ブロック８０８におけるロジックフロー８００は、同一のＴＣＰ接続を介して、第１のアプリケーションに対する第１および第２のソケットＡＰＩのそれぞれに第１および第２のセッションを転送し得る。これらの例において、転送コンポーネント６２２―６は、第１および第２のセッションを、サーバにおける第１のアプリケーションに転送し得る。

図９は、第３のロジックフローの一例を図示する。図１０に示されるように、第３のロジックフローは、ロジックフロー９００を含む。ロジックフロー９００は、１もしくは複数のロジック、特徴、または装置６００等、本明細書において説明される複数のデバイスにより実行されたいくつか、または全てのオペレーションを表し得る。より具体的には、ロジックフロー９００は、少なくとも受信コンポーネント６２２―４、インデックスコンポーネント６２２―２、再グループ化コンポーネント６２２―５、または転送コンポーネント６２２―６により実装され得る。

いくつかの例によれば、ブロック９０２におけるロジックフロー９００は、複数のＴＣＰ接続を介してサーバに結合されたクライアント用の回路において、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して、第１および第２のセッションを受信し得る。第１および第２のセッションは、サーバによりホスティングされた一次または二次仮想マシンにより実行される第１のアプリケーションにより生成され、別個の複数のＴＣＰ接続を介してサーバから出力され得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションにより第１のアプリケーションにすでに送信された要求に応答して生成され得る。これらの例においては、受信コンポーネント６２２―４は、第１および第２のセッションを受信し得る。

いくつかの例において、ブロック９０４におけるロジックフロー９００は、第１および第２のセッションについての識別子情報を有するセッションインデックスを受信し得る。これらの例において、インデックスコンポーネント６２２―２は、セッションインデックスを受信し得る。

いくつかの例によれば、ブロック９０６におけるロジックフロー９００は、セッションインデックスに基づいて、同一のＴＣＰ接続に第１および第２のセッションを再グループ化し得る。これらの例においては、再グループ化コンポーネント６２２―５は、第１および第２のセッションを再グループ化し得る。

いくつかの例において、ブロック９０８におけるロジックフロー９００は、同一のＴＣＰ接続を介して、第２のアプリケーションに対する第１および第２のソケットＡＰＩのそれぞれに第１および第２のセッションを転送し得る。これらの例において、転送コンポーネント６２２―６は、第１および第２のセッションを、クライアントにおける第２のアプリケーションに転送し得る。

図１０は、第１のストレージ媒体の一例を図示する。図１１に示されるように、第１のストレージ媒体は、ストレージ媒体１０００を含む。ストレージ媒体１０００は、製造物品を備え得る。いくつかの例において、ストレージ媒体１０００は、光、磁気、または半導体ストレージ等、任意の非一時的コンピュータ可読媒体または機械可読媒体を含み得る。ストレージ媒体１０００は、ロジックフロー７００、８００、または９００を実装する複数の命令等、様々なタイプのコンピュータ実行可能命令を格納し得る。コンピュータ可読または機械可読ストレージ媒体の例としては、揮発性メモリもしくは不揮発性メモリ、リムーバブルメモリもしくはノンリムーバブルメモリ、消去可能メモリもしくは消去不可能メモリ、ライタブルメモリもしくはリライタブルメモリ等を含む、電子データを格納することが可能な任意の有形媒体が挙げられ得る。コンピュータ実行可能命令の複数の例としては、ソースコード、コンパイラ型コード、インタープリタ型コード、実行可能コード、スタティックコード、ダイナミックコード、オブジェクト指向コード、視覚コード等、任意の好適なタイプのコードが挙げられ得る。例は、この文脈において限定されない。

図１１は、例示的なコンピューティングプラットフォーム１１００を図示する。いくつかの例において、図１１に示されるように、コンピューティングプラットフォーム１１００は、処理コンポーネント１１４０、他の複数のプラットフォームコンポーネント１１５０、または通信インターフェース１１６０を含み得る。いくつかの例によれば、コンピューティングプラットフォーム１１００は、ＮＷ通信チャネルを介して結合することが可能なサーバまたはクライアントコンピューティングデバイス内に実装され得る。

いくつかの例によれば、処理コンポーネント１１４０は、装置６００および／またはストレージ媒体１０００のための複数の処理オペレーションまたはロジックを実行し得る。処理コンポーネント１１４０は、様々なハードウェア要素、ソフトウェア要素、または双方の組み合わせを含んでもよい。ハードウェア要素の複数の例としては、デバイス、論理デバイス、コンポーネント、プロセッサ、マイクロプロセッサ、回路、プロセッサ回路、回路素子（例えば、トランジスタ、抵抗器、コンデンサ、インダクタ等）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラマブル論理デバイス（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、メモリユニット、論理ゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセット等が挙げられ得る。ソフトウェア要素の例としては、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、デバイスドライバ、システムプログラム、ソフトウェア開発プログラム、マシンプログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、方法、プロシージャ、ソフトウェアインターフェース、アプリケーションプログラムインタフェース（ＡＰＩ）、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、シンボル、またはそれらの任意の組み合わせが挙げられ得る。複数のハードウェア要素および／またはソフトウェア要素を用いて、例が実装されているか否かを判断する段階は、所望の計算レート、電力レベル、耐熱性、処理サイクル予算、入力データレート、出力データレート、メモリリソース、データバスの速度、および他の設計もしくは性能の制約等、所与の例に所望の任意の数の複数の要因により異なることがある。

いくつかの例において、他のプラットフォームコンポーネント１１５０は、１もしくは複数のプロセッサ、マルチコアプロセッサ、コプロセッサ、メモリユニット、チップセット、制御器、周辺機器、インターフェース、発振器、タイミングデバイス、ビデオカード、オーディオカード、マルチメディア入力／出力（Ｉ／Ｏ）コンポーネント（例えばデジタルディスプレイ）、電力供給等の共通のコンピューティング要素を含み得る。メモリユニットの複数の例としては、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、ダブルデータレートＤＲＡＭ（ＤＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、消去式プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去式プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、強誘電体ポリマーメモリ、オボニックメモリ、相変化または強誘電体メモリ等のポリマーメモリ、シリコン‐酸化物‐窒化物‐酸化物‐シリコン（ＳＯＮＯＳ）メモリ、磁気または光学カード、独立ディスクのリダンダントアレイ（ＲＡＩＤ）デバイス等のデバイスのアレイ、ソリッドステートメモリデバイス（例えばＵＳＢメモリ）、ソリッドステートドライブ（ＳＳＤ）、および情報を格納するのに好適なその他のタイプのストレージ媒体等、１または複数の高速メモリユニットの形態の様々なタイプのコンピュータ可読および機械可読ストレージ媒体が挙げられ得るが、これらに限定されない。

いくつかの例において、通信インターフェース１１６０は、通信インターフェースをサポートするロジックおよび／または複数の特徴を含み得る。これらの例において、通信インターフェース１１６０は、様々な通信プロトコルまたは規格により動作し、直接のリンクまたはネットワーク通信リンクを経由して通信する１または複数の通信インターフェースを含み得る。複数の直接通信は、ＰＣＩｅ仕様に関連するもの等の１または複数の産業規格（後継および変形を含む）において説明される複数の通信プロトコルまたは標準の使用により行われ得る。ネットワーク通信は、ＩＥＥＥにより公表された１または複数のイーサネット（登録商標）規格において説明されるもの等、複数の通信プロトコルまたは標準の使用により行われ得る。例えば、１つのそのようなイーサネット（登録商標）規格としては、ＩＥＥＥ８０２．３．が挙げられ得る。また、ネットワーク通信は、ＯｐｅｎＦｌｏｗハードウェア抽象化ＡＰＩ仕様等の１または複数のＯｐｅｎＦｌｏｗ仕様により行われ得る。

上で言及されたように、コンピューティングプラットフォーム１１００は、サーバまたはクライアントコンピューティングデバイス内に実装され得る。従って、本明細書において説明されるコンピューティングプラットフォーム１１００の複数の機能および／または特定の構成は、サーバまたはクライアントコンピューティングデバイスについて適宜に所望されるコンピューティングプラットフォーム１１００の様々な実施形態において、含まれ、または省略され得る。

コンピューティングプラットフォーム１１００の複数のコンポーネントおよび特徴は、ディスクリート回路、複数の特定用途向け集積回路（ＡＳＩＣ）、論理ゲート、および／またはシングルチップアーキテクチャの任意の組み合わせを用いて実装され得る。更に、コンピューティングプラットフォーム１１００複数の特徴は、複数のマイクロコントローラ、プログラマブルロジックアレイ、および／もしくはマイクロプロセッサ、または好適な場合に、上述の任意の組み合わせを用いて実装され得る。ハードウェア、ファームウェア、および／または複数のソフトウェア要素は、本明細書において、集合的または個別的に「ロジック」または「回路」と呼ばれる場合があることに留意されたい。

図１１のブロック図に示される例示的なコンピューティングプラットフォーム１１００は、多くの潜在的実装の機能を記述する一例を表し得ることを理解されたい。従って、添付の図面に図示するブロックの機能を分割、省略、または含んでも、複数のハードウェアコンポーネント、回路、ソフトウェア、および／またはこれらの機能を実装する複数の要素が、複数の実施形態において必ず分割され、省略され、または含まれることを暗示するものではない。

少なくとも一例の１または複数の態様は、機械により読み取られると、コンピューティングデバイスまたはシステムが機械、コンピューティングデバイス、またはシステムにロジックを作成させ、本明細書において説明される複数の技術を実行させるプロセッサ内で様々なロジックを表す、少なくとも１つの機械可読媒体上に格納された代表的な複数の命令により実装され得る。「ＩＰコア」として知られるそのような表現は、実際にロジックまたはプロセッサを製造する複数の製造機械にロードするべく、有形の機械可読媒体上に格納され、様々な顧客または製造施設に供給され得る。

様々な例は、複数のハードウェア要素、ソフトウェア要素、または双方の組み合わせを用いて実装され得る。いくつかの例において、複数のハードウェア要素としては、デバイス、コンポーネント、プロセッサ、マイクロプロセッサ、回路、回路素子（例えばトランジスタ、抵抗器、コンデンサ、インダクタなど）、集積回路、特定用途向け集積回路（ＡＳＩＣ）、プログラムマブル論理デバイス（ＰＬＤ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、メモリユニット、論理ゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセット等が挙げられ得る。いくつかの例において、ソフトウェア要素としては、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、マシンプログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、方法、プロシージャ、ソフトウェアインターフェース、アプリケーションプログラムインターフェース（ＡＰＩ）、命令セット、計算コード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、記号、またはこれらの任意の組み合わせが挙げられ得る。複数のハードウェア要素および／またはソフトウェア要素を用いて、例が実装されているか否かを判断する段階は、所望の計算レート、電力レベル、耐熱性、処理サイクル予算、入力データレート、出力データレート、メモリリソース、データバスの速度、および他の設計もしくは性能の制約等、所与の実装に所望の任意の数の複数の要因により異なることがある。

いくつかの例は、製造物品または少なくとも１つのコンピュータ可読媒体を含み得る。コンピュータ可読媒体は、ロジックを格納する非一時的記憶媒体を含み得る。いくつかの例において、非一時的記憶媒体としては、揮発性メモリもしくは不揮発性メモリ、リムーバブルもしくはノンリムーバブルメモリ、消去可能もしくは消去不可能メモリ、ライタブルもしくはリライタブルメモリ等を含む、電子データを格納することが可能な１または複数のタイプのコンピュータ可読ストレージ媒体が挙げられ得る。いくつかの例において、ロジックは、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、マシンプログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、関数、方法、プロシージャ、ソフトウェアインターフェース、ＡＰＩ、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、記号、またはこれらの任意の組み合わせ等、様々なソフトウェア要素を含み得る。

いくつかの例によれば、コンピュータ可読媒体としては、機械により実行されると、コンピューティングデバイスまたはシステムが機械、コンピューティングデバイス、またはシステムに説明された複数の例に従って複数の方法および／またはオペレーションを実行させる複数の命令を格納または保持する非一時的記憶媒体が挙げられ得る。複数の命令としては、ソースコード、コンパイラ型コード、インタープリタ型コード、実行可能コード、スタティックコード、ダイナミックコード等、任意の好適なタイプのコードが挙げられ得る。複数の命令は、機械、コンピューティングデバイス、またはシステムに一定の機能を実行するように命令するための予め規定されたコンピュータ言語、態様または構文により実装され得る。複数の命令は、任意の好適なハイレベル、ローレベル、オブジェクト指向、視覚的、コンパイル型、および／またはインタープリタ型プログラミング言語を用いて実装され得る。

いくつかの例は、複数の派生物と共に、表現「一例において」または「一例」を用いて説明され得る。これらの用語は、例と関して説明された特定の特徴、構造、または特性が少なくとも一例に含まれることを意味する。本明細書全体の様々な箇所で「一例において」の文言が現れても、全てが必ずしも同一の例を指している訳ではない。

いくつかの例は、その派生物と共に、「結合され（ｃｏｕｐｌｅｄ）」および「接続され（ｃｏｎｎｅｃｔｅｄ）」という表現を用いて説明され得る。これらの用語は、必ずしも互いに同義語として意図されない。例えば、用語「接続され」および／または「結合され」を用いる説明は、２またはそれより多い要素が互いに直接的に物理的または電気的に接触していることを示し得る。しかし、「結合され」という用語は、２またはそれより多い要素が互いに直接的には接触していないが、依然として協働または互いに相互作用していることも意味し得る。

以下の複数の例は、本明細書において開示される複数の技術の更なる例に関する。

例１。例示的な装置は、複数のＴＣＰ接続を介してクライアントに結合されたサーバにおける回路を含み得る。これらの例においては、サーバは、第１のアプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成され得る。装置は、第１のアプリケーションから行われた第１および第２のソケットＡＰＩ呼び出しを傍受するべく、回路により実行するための傍受コンポーネントも含み得る。第１および第２のソケットＡＰＩは、第１および第２のセッションのそれぞれを、複数のＴＣＰ接続のうち同一のＴＣＰ接続を介した予期される出力にルーティングするように構成され得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションから受信された要求に応答して、第１のアプリケーションにより生成され得る。装置は、第１および第２のセッションに対する第１および第２の識別子情報のそれぞれを用いてセッションインデックスを生成するべく、回路により実行するためのインデックスコンポーネントも含み得る。装置は、クライアントにおいて第２のアプリケーションへの送達のために第１のセッションおよび第２のセッションを同一のＴＣＰ接続に再度組み合わせるためにセッションインデクスを用いることができるように、第１のセッションおよび第２のセッションを、複数のＴＣＰ接続のうち別個のＴＣＰ接続を介した実際の出力にリマッピングする、回路により実行するためのリマッピングコンポーネントも含み得る。

例２。また、例１の装置は、アプリケーションが複数のセッションをクライアントへの複数のＴＣＰ接続を介した予期される出力にルーティングするために用いられる複数のソケットＡＰＩのダイナミックリンクライブラリを代用することにより、第１および第２のソケットＡＰＩを傍受する傍受コンポーネントを含み得る。これらに例においては、ダイナミックリンクライブラリは、ＴＣＰデカップルリンクライブラリで代用され得る。装置は、ＴＣＰデカップルリンクライブラリを用いて、第１および第２のセッションを、別個の複数のＴＣＰ接続を介してクライアントに実際に出力させることをことにより、第１および第２のセッションをリマッピングするリマッピングコンポーネントも含み得る。

例３。例１の装置において、傍受コンポーネントは、クライアントとのＴＣＰ接続設定またはクライアントとのＴＣＰデータ交換のうち１つに基づいて、第１および第２のソケットＡＰＩをエミュレートする傍受コンポーネントにより、第１および第２のソケットＡＰＩを傍受し得る。

例４。例３の装置は、ＴＣＰ接続設定に基づいて、第１および第２のソケットＡＰＩをエミュレートする傍受コンポーネントも含み得る。これらの例においては、傍受コンポーネントは、第１および第２のソケットＡＰＩのための複数のＯＳソケットＡＰＩを生成し、複数のＯＳソケットＡＰＩを別個の複数のＴＣＰ接続に割り当て得る。例３の装置は、複数のＯＳソケットＡＰＩを用いるべく第１および第２のセッションをリマッピングし、第１および第２のセッションを、別個の複数のＴＣＰ接続を介してクライアントに実際に出力させるリマッピングコンポーネントも含み得る。

例５。また、例４の装置は、クライアントとのＴＣＰテアダウンのＥＯＦメッセージに応答して、第１および第２のソケットＡＰＩに対する複数のＯＳソケットＡＰＩを除去する傍受コンポーネントを含み得る。

例６。例３の装置は、ＴＣＰデータ交換に基づいて、第１および第２のソケットＡＰＩをエミュレートし、別個の複数のＴＣＰ接続に割り当てられた複数のＯＳソケットＡＰＩに、第１および第２のセッションをマッピングする固定マッピングテーブルをアドレス指定するセッションインデックスを用いる傍受コンポーネントも含み得る。例３の装置は、固定マッピングテーブルに基づいて、第１および第２のセッションをリマッピングし、第１および第２のセッションを、別個の複数のＴＣＰ接続を介してクライアントに実際に出力させるリマッピングコンポーネント含み得る。

例７。例１の装置において、傍受コンポーネントは、傍受に対して選択的に選択されたアプリケーションに基づいて、第１および第２のソケットＡＰＩを傍受し得るが、一次または二次ＶＭにより実行されることが可能な別のアプリケーションは、傍受のために選択されない。

例８。例１の装置において、第１および第２の識別子情報は、第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含み得る。

例９。例１の装置において、第１および第２の識別子情報は、第１のセッションの生成に関連する第１のＩＰアドレスを含む第１のプロトコルスタックパターンと、第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含み得る。

例１０。例１の装置は、ユーザインターフェース表示を提示する回路に結合されたデジタルディスプレイも含み得る。

例１１。例示的な方法は、アプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成されたサーバ用の回路において、アプリケーションから行われた第１および第２のソケットＡＰＩ呼び出しを傍受する段階を備え得る。これらの例において、第１および第２のソケットＡＰＩは、サーバのクライアントに結合された複数のＴＣＰ接続のうち同一のＴＣＰ接続を介して、予期される出力に対する第１および第２のセッションのそれぞれをルーティングするように構成され得る。第１および第２のセッションは、クライアントから受信されたデータに応答して、アプリケーションにより生成され得る。方法は、第１および第２のセッションに対する第１および第２の識別子情報のそれぞれを用いてセッションインデックスを生成する段階も備え得る。方法は、セッションインデックスがクライアントにおいて用いられ、第１および第２のセッションを同一のＴＣＰ接続と再度組み合わることが可能となるように、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して、実際に出力する第１および第２のセッションをリマッピングする段階も備え得る。

例１２。例１１の方法において、第１および第２のソケットＡＰＩを傍受する段階は、複数のＴＣＰ接続を介してクライアントに予期される出力に対する複数のセッションをルーティングするアプリケーションにより用いられる複数のソケットＡＰＩのダイナミックリンクライブラリを代用する段階を有し得る。これらに例においては、ダイナミックリンクライブラリは、ＴＣＰデカップルリンクライブラリで代用され得る。また、例１１の方法においては、第１および第２のセッションをリマッピングする段階は、ＴＣＰデカップルリンクライブラリを用いて、第１および第２のセッションが別個の複数のＴＣＰ接続を介してクライアントに実際に出力されるようにする段階を有し得る。

例１３。例１１の方法において、第１および第２のソケットＡＰＩを傍受する段階は、クライアントとのＴＣＰ接続設定またはクライアントとのＴＣＰデータ交換のうち１つに基づいて第１および第２のソケットＡＰＩうぃエミュレートする段階を有し得る。

例１４。例１３の方法において、ＴＣＰ接続設定に基づいて第１および第２のソケットＡＰＩをエミュレートする段階は、第１および第２のソケットＡＰＩに対する複数のＯＳソケットＡＰＩを生成する段階を有し得る。これらの例においては、複数のＯＳソケットＡＰＩは、別個の複数のＴＣＰ接続に割り当てられ得る。また、例１３の方法は、複数のＯＳソケットＡＰＩを用いることにより第１および第２のセッションが別個の複数のＴＣＰ接続を介してクライアントに実際に出力され得るように第１および第２のセッションをリマッピングする段階を有し得る。

例１５。例１４の方法は、クライアントとのＴＣＰテアダウンのＥＯＦメッセージに応答して、第１および第２のソケットＡＰＩに対する複数のＯＳソケットＡＰＩを除去する段階を備え得る。

例１６。例１３の方法において、ＴＣＰデータ交換に基づいて、第１および第２のソケットＡＰＩをエミュレートする段階は、別個の複数のＴＣＰ接続に割り当てられた複数のＯＳソケットＡＰＩに、第１および第２のセッションをマッピングする固定マッピングテーブルをアドレス指定するセッションインデックスを用いる段階を有し得る。例１３の方法においては、第１および第２のセッションをリマッピングする段階は、固定マッピングテーブルを用いて、第１および第２のセッションが別個の複数のＴＣＰ接続を介してクライアントに実際に出力されるようにする段階を有し得る。

例１７。例１１の方法において、第１および第２のソケットＡＰＩを傍受する段階は、傍受に対して選択的に選択されたアプリケーションに基づいて、第１および第２のソケットＡＰＩを傍受し得るが、一次または二次ＶＭにより実行されることが可能な別のアプリケーションが傍受のために選択されない段階を有し得る。

例１８。例１１の方法において、第１および第２の識別子情報は、第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含み得る。

例１９。例１１の方法において、第１および第２の識別子情報は、第１のセッションの生成に関連する第１のＩＰアドレスを有する第１のプロトコルスタックパターンと、第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含み得る。

例２０。少なくとも１つの機械可読媒体は、サーバにおけるシステムにより実行されることに応答して、システムに、例１１〜１９のうちいずれか１つによる方法を実行させ得る複数の命令を含み得る。

例２１。装置は、例１１〜１９のうちいずれか１つの方法を実行するための手段を含み得る。

例２２。例示的な少なくとも１つの機械可読媒体は、第１のアプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成されたサーバにおけるシステムにより、実行されることに応答して、システムに、クライアントとの別個の複数のＴＣＰ接続を介して第１および第２のセッションを受信させ得る複数の命令を含み得る。第１および第２のセッションは、第１のアプリケーションから第２のアプリケーションへとすでに送信された要求に応答して、クライアントにおける第２のアプリケーションにより生成され得る。また、複数の命令は、システムに、第１および第２のセッションについての識別子情報を有するセッションインデックスを受信させ得る。また、複数の命令は、システムにセッションインデックスに基づいて、同一のＴＣＰ接続に対して第１および第２のセッションを再グループ化させ得る。また、複数の命令は、システムに、同一のＴＣＰ接続を介して、第１および第２のセッションを第１のアプリケーションに対する第１および第２のソケットＡＰＩのそれぞれに転送させ得る。

例２３。例２２の少なくとも１つの機械可読媒体において、識別子情報は、第１のアプリケーションに対する第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、第１のアプリケーションに対する第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含み得る。

例２４。例２２の少なくとも１つの機械可読媒体において、識別子情報は、第１のセッションの生成に関連する第１のＩＰアドレスを含む第１のプロトコルスタックパターンと、第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含み得る。

例２５。例２２の少なくとも１つの機械可読媒体において、複数の命令は更に、システムに、サーバにおいて用いられるのと同一のラウンドロビンポリシを用いて、第１および第２のセッションを同一のＴＣＰ接続に再グループ化し、サーバにおける同一のＴＣＰ接続からの第１および第２のセッションを、別個の複数のＴＣＰ接続にリマッピングさせ得る。

例２６。例示的な装置は、複数のＴＣＰ接続を介してサーバに結合されたクライアントにおける回路を含み得る。これらの例においては、サーバは、第１のアプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成され得る。また、装置は、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して、第１のアプリケーションにより生成された第１および第２のセッションを受信するように回路により実行するための受信コンポーネントを含み得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションにより第１のアプリケーションにすでに送信された要求に応答して生成され得る。また、装置は、第１および第２のセッションについての識別子情報を有するセッションインデックスを受信するべく、回路により実行するためのインデックスコンポーネントを含み得る。装置は、セッションインデックスに基づいて複数のＴＣＰ接続のうち同一のＴＣＰ接続に対して第１および第２のセッションを再グループ化するべく、回路により実行するための再グループ化コンポーネントも含み得る。装置は、同一のＴＣＰ接続を介して、第２のアプリケーションに対する第１および第２のソケットＡＰＩのそれぞれに第１および第２のセッションを転送するべく、回路により実行するための転送コンポーネントも含み得る。

例２８。例２６の装置において、識別子情報は、第１のアプリケーションに対する第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、第１のアプリケーションに対する第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含み得る。

例２９。例２６の装置において、識別子情報は、第１のセッションの生成に関連する第１のＩＰアドレスを含む第１のプロトコルスタックパターンと、第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含み得る。

例３０。例２６の装置は、ユーザインターフェース表示を提示するべくプロセッサ回路に結合されたデジタルディスプレイも含み得る。

例３１。例示的な方法は、複数のＴＣＰ接続を介してサーバに結合されたクライアント用の回路において、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して、第１および第２のセッションを受信する段階を備え得る。これらの例においては、第１および第２のセッションは、サーバによりホスティングされた一次または二次仮想マシンにより実行される第１のアプリケーションにより生成され、別個の複数のＴＣＰ接続を介してサーバから出力され得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションにより第１のアプリケーションにすでに送信された要求に応答して生成され得る。方法は、第１および第２のセッションに対する識別子情報を有するセッションインデックスを受信する段階も備え得る。方法は、第１および第２のセッションを、セッションインデックスに基づいて複数のＴＣＰ接続のうち同一のＴＣＰ接続に対して再グループ化する段階も含み得る。方法は、同一のＴＣＰ接続を介して、第２のアプリケーションに対する第１および第２のソケットＡＰＩのそれぞれに第１および第２のセッションを転送する段階を備え得る。

例３２。例３１の方法において、識別子情報は、第１のアプリケーションに対する第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、第１のアプリケーションに対する第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含む。

例３３。例３１の方法において、識別子情報は、第１のセッションの生成に関連する第１のＩＰアドレスを含む第１のプロトコルスタックパターンと、第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含み得る。

例３４。例３１の方法において、第１および第２のセッションを同一のＴＣＰ接続に再グループ化する段階は、サーバにおいて用いられるのと同一のラウンドロビンポリシを用いて、サーバにおける同一のＴＣＰ接続からの第１および第２のセッションを、別個の複数のＴＣＰ接続にリマッピングする段階を有し得る。

例３５。少なくとも１つの機械可読媒体は、サーバに結合されたクライアントにおけるシステムにより実行されることに応答して、システムに、例３１〜３４のうちいずれか１つによる方法を実行させ得る複数の命令を含み得る。

例３６。装置は、例３１〜３４のうちいずれか１つの方法を実行するための手段を含み得る。

例３７。少なくとも１つの機械可読媒体は、複数のＴＣＰ接続を介してサーバに結合されたクライアントにおけるシステムにより実行されることに応答する複数の命令を含み得、サーバは、第１のアプリケーションを別個に実行することが可能な一次または二次ＶＭをホスティングするように構成され得、複数の命令は、システムに、複数のＴＣＰ接続のうち別個の複数のＴＣＰ接続を介して、第１および第２のセッションを受信させ得る。これらの例においては、第１および第２のセッションは、第１のアプリケーションにより生成され、別個の複数のＴＣＰ接続を介してサーバから出力され得る。第１および第２のセッションは、クライアントにおける第２のアプリケーションにより第１のアプリケーションにすでに送信された要求に応答して生成され得る。また、複数の命令は、システムに、第１および第２のセッションについての識別子情報を有するセッションインデックスを受信させ得る。また、複数の命令は、システムにセッションインデックスに基づいて、複数のＴＣＰ接続のうち同一のＴＣＰ接続に対する第１および第２のセッションを再グループ化させ得る。また、複数の命令は、システムに、同一のＴＣＰ接続を介して、第１および第２のセッションを第２のアプリケーションに対する第１および第２のソケットＡＰＩのそれぞれに転送させ得る。

例３８。例３７の少なくとも１つの機械可読媒体において、識別子情報は、第１のアプリケーションに対する第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、第１のアプリケーションに対する第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含み得る。

例３９。例３７の少なくとも１つの機械可読媒体において、識別子情報は、第１のセッションの生成に関連する第１のＩＰアドレスを含む第１のプロトコルスタックパターンと、第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含み得る。

例４０。例３７の少なくとも１つの機械可読媒体において、同一のＴＣＰ接続に対して再グループ化された第１および第２のセッションは、サーバにおいて用いられるのと同一のラウンドロビンポリシを用いて、サーバにおける同一のＴＣＰ接続からの第１および第２のセッションを、別個の複数のＴＣＰ接続にリマッピングさせりことを含み得る。

本開示の要約書は、連邦規則法典集第３７巻に準拠して提供されることが強調される。セクション１．７２（ｂ）は、読者が技術的な開示の性質を確認することを可能とする要約を要求している。要約書は、特許請求の範囲または意味を解釈または限定するべく用いられないとの理解と共に提出される。更に、上述の詳細な説明で、様々な特徴が、本開示を一通り示す目的のために単一の例で一緒にグループ化されていることが見て取られ得る。本開示の方法は、特許請求される複数の例が各請求項において明示的に列挙されるよりも多くの特徴を要求するとの意図を反映するものとして解釈されるものではない。むしろ、以下の特許請求の範囲が反映するように、発明の主題は、１つの開示例の全ての特徴よりも少ない。従って、以下の特許請求の範囲は発明を実施するための詳細な説明に組み込まれ、各請求項は別個の例として独立している。添付の特許請求の範囲において、「含む」および「そこにおいて（ｉｎ ｗｈｉｃｈ）」という用語は、「備える」および「そこで（ｗｈｅｒｅｉｎ）」という各用語の平易な英語の均等物として、それぞれ用いられる。更に、「第１の」、「第２の」、「第３の」等の用語は、分類としてのみ用いられ、その対象に数字的な要求を課すことは意図されない。

主題は、構造的特徴および／または方法論的動作に特有の言語で説明されてきたが、添付の特許請求の範囲において定義された主題は、必ずしも上記の特定の特徴または動作に限定されないことを理解されたい。むしろ、特定の複数の特徴および動作は、特許請求の範囲を実装する例示的形態として上に説明され、開示される。

Claims (8)

1. 第１のアプリケーションを別個に実行することが可能な一次仮想マシン（ＰＶＭ）または二次仮想マシン（ＳＶＭ）をホスティングするサーバに複数のトランスポート制御プロトコル（ＴＣＰ）接続を介して結合されるクライアント側の装置であって、
   前記装置は、
   前記複数のＴＣＰ接続のうち別個のＴＣＰ接続を介して、前記第１のアプリケーションにより生成された第１のセッションおよび第２のセッションを受信するための、ソフトウェアまたはファームウェア実装された受信コンポーネントと、
   前記第１のセッションおよび前記第２のセッションについての識別子情報を有するセッションインデックスを受信するための、ソフトウェアまたはファームウェア実装されたインデックスコンポーネントと、
   前記セッションインデックスに基づいて、前記第１のセッションおよび前記第２のセッションを前記複数のＴＣＰ接続のうち同一のＴＣＰ接続に再グループ化するための、ソフトウェアまたはファームウェア実装された再グループ化コンポーネントと、
   前記同一のＴＣＰ接続を介して、前記第１のセッションおよび前記第２のセッションを、第２のアプリケーションの第１のソケットアプリケーションインターフェースおよび第２のソケットアプリケーションインターフェース（ＡＰＩ）のそれぞれに転送するための、ソフトウェアまたはファームウェア実装された転送コンポーネントと
   を実行する回路を備え、
   前記第１のセッションおよび前記第２のセッションは、クライアントにおける前記第２のアプリケーションによって前記第１のアプリケーションにすでに送信された要求に応答して生成される
   装置。
2. 前記識別子情報は、前記第１のアプリケーションに対する前記第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、前記第１のアプリケーションに対する前記第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含む、請求項１に記載の装置。
3. 前記識別子情報は、前記第１のセッションの生成に関連する第１のインターネットプロトコル（ＩＰ）アドレスを含む第１のプロトコルスタックパターンと、前記第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含む、請求項１に記載の装置。
4. 前記回路に接続され、ユーザインターフェース表示を提示するデジタルディスプレイを備える請求項１に記載の装置。
5. 複数のトランスポート制御プロトコル（ＴＣＰ）接続を介してサーバに結合されるクライアント側の装置であって、
   前記複数のＴＣＰ接続のうち別個のＴＣＰ接続を介して第１のセッションおよび第２のセッションを受信する手段と、
   前記第１のセッションおよび前記第２のセッションについての識別子情報を有するセッションインデックスを受信する手段と、
   前記セッションインデックスに基づいて、前記第１のセッションおよび前記第２のセッションを前記複数のＴＣＰ接続のうち同一のＴＣＰ接続に再グループ化する手段と、
   前記同一のＴＣＰ接続を介して、前記第１のセッションおよび前記第２のセッションを、第２のアプリケーションの第１のソケットアプリケーションインターフェースおよび第２のソケットアプリケーションインターフェース（ＡＰＩ）のそれぞれに転送する手段と
   を備え、
   前記第１のセッションおよび前記第２のセッションは、前記サーバによりホスティングされる一次仮想マシンまたは二次仮想マシンにより実行される第１のアプリケーションにより生成され、前記別個のＴＣＰ接続を介して前記サーバから出力され、
   前記第１のセッションおよび前記第２のセッションは、クライアントにおける前記第２のアプリケーションによって前記第１のアプリケーションにすでに送信された要求に応答して生成される
   装置。
6. 前記識別子情報は、前記第１のアプリケーションに対する前記第１のセッションを生成するべく用いられる第１のスレッドに割り当てられた第１のスレッド名もしくは識別子と、前記第１のアプリケーションに対する前記第２のセッションを生成するべく用いられる第２のスレッドに割り当てられた第２のスレッド名もしくは識別子とを含む、請求項５に記載の装置。
7. 前記識別子情報は、前記第１のセッションの生成に関連する第１のインターネットプロトコル（ＩＰ）アドレスを含む第１のプロトコルスタックパターンと、前記第２のセッションの生成に関連する第２のＩＰアドレスを含む第２のプロトコルスタックパターンとを含む、請求項５に記載の装置。
8. 前記第１のセッションおよび前記第２のセッションを前記同一のＴＣＰ接続に再グループ化する前記手段は、前記サーバにおいて用いられるのと同一のラウンドロビンポリシを用いて、前記サーバにおける前記同一のＴＣＰ接続からの前記第１のセッションおよび前記第２のセッションを、前記別個のＴＣＰ接続にリマッピングする手段を含む、請求項５に記載の装置。

Images