JP7023384B2 - ユーザおよびシステムヒントを用いて最適化される階層表示リモーティングを与えるコンピュータシステムおよび関連する方法 - Google Patents

Description

本発明は、ユーザおよびシステムヒントを用いて最適化される階層表示リモーティングを与えるコンピュータシステムおよび関連する方法に関する。

従来、パーソナルコンピュータは、各々が継続的に所有者または管理者によって個々に管理されるオペレーティングシステムと、アプリケーションと、ユーザ設定との組合せを含む。しかしながら、多くの団体は、現在、それらのユーザの様々な必要性に対処するためによりフレキシブルなオプションを与えるためにアプリケーションおよび／またはデスクトップの仮想化を使用している。デスクトップの仮想化では、ユーザのコンピューティング環境（たとえば、オペレーティングシステム、アプリケーション、および／またはユーザ設定）は、ユーザの物理コンピューティングデバイス（たとえば、スマートフォン、ラップトップ、デスクトップコンピュータ）から分離され得る。クライアントサーバ技術を使用して、「仮想化されたデスクトップ」は、クライアントコンピューティングデバイスのローカルストレージ中にではなくリモートサーバ中に記憶され、それによって管理され得る。

いくつかの異なるタイプのデスクトップ仮想化システムがある。一例として、仮想デスクトップインフラストラクチャ（ＶＤＩ）は、サーバ上に常駐する仮想マシン内でユーザデスクトップを動作する処理を指す。ＶＤＩおよび他のサーバベースのデスクトップ仮想化システムは、集中型の管理およびセキュリティを可能にしながら各ユーザに個人用デスクトップを与え得る。そのようなシステム中のサーバは、仮想デスクトップイメージおよびシステム構成情報ならびに仮想デスクトップを与え、ユーザがそれらに相互接続することを可能にするソフトウェア構成要素のためのストレージを含み得る。たとえば、ＶＤＩサーバは、複数の仮想マシンを作成し、維持するための１つまたは複数のハイパーバイザ（仮想マシンマネージャ）と、ハイパーバイザを管理するためのソフトウェアと、接続ブローカーと、仮想デスクトップをプロビジョニングし、管理するためのソフトウェアとを含み得る。いくつかの実施形態では、ＶＤＩサーバは、共有サーバベースのホストアプリケーションならびにウェブ／サービスとしてのソフトウェア（ＳａａＳ）アプリケーションへのアクセスを与え得る。

デスクトップ仮想化システムは、単一の仮想化サーバまたはサーバグリッドとして相互接続されたサーバの組合せを使用して実装され得る。たとえば、クラウドコンピューティング環境またはクラウドシステムは、クラウドシステムに管理および顧客ポータルを与えるための追加のコンピューティングデバイスとともに、コンピューティングリソース（たとえば、デスクトップ仮想化サーバ）のプールと、記憶ディスクと、ネットワーキングハードウェアと、仮想デスクトップをプロビジョニングし、および／または共有アプリケーションへのアクセスを与えるために使用され得る他の物理リソースとを含み得る。いくつかの実装形態では、サービスとしてのデスクトップ（ＤａａＳ）セッションは、異なるテナントまたは企業のためにクラウドコンピューティング環境から動作され得る。

コンピューティングデバイスは、メモリと、フレームバッファを介してクライアントデバイスにリモートで表示されるべき仮想コンピューティングセッションをホストすることであって、クライアントデバイスは、グラフィカルユーザインターフェース（ＧＵＩ）を介して仮想コンピューティングセッションをレンダリングするように構成される、ホストすることを行うようにメモリと協働するプロセッサとを含み得る。仮想化サーバは、仮想セッション入力に基づいて、およびフレームバッファを分析することなしに仮想コンピューティングセッション内の対話型グラフィックスの領域を検出することと、フレームバッファ内の他のコンテンツよりも高い優先度を対話型グラフィックスの領域に割り当てることと、割り当てられた優先度に基づいてＧＵＩ中でレンダリングするためにクライアントデバイスにフレームバッファのコンテンツを送ることとをさらに行い得る。

例示的な実装形態では、コンピューティングデバイスは、仮想セッション入力をキャプチャするように構成され得る。例として、仮想セッション入力は、ウィンドウパターンイベント、スクロールパターンイベント、およびテキストパターンイベントのうちの１つまたは複数を備え得る。一例によれば、プロセッサは、フレームバッファの対応するコンテンツのレンダリングの前にレンダリングするためにクライアントデバイスにテキストパターン入力データを非同期的に送るようにさらに構成され得る。より詳細にはテキストパターン入力データは、テキストデータと関連するテキストメタデータとを備え得、テキストメタデータは、たとえば、フォントタイプと、フォントサイズと、前景色と、背景色と、イタリックと、ボールドと、下線と、行間とのうちの少なくとも１つを備え得る。さらに別の例示的な実装形態では、テキストパターン入力データは、スクロールコンテナ内のテキストパターンに対応し得る。

さらに、プロセッサは、フレームバッファ内の他のコンテンツとは異なるレベルの前方誤り訂正（ＦＥＣ）をもつ関心領域に対応するフレームバッファのコンテンツを送るように構成され得る。例示的な実施形態では、プロセッサは、第１のチャネルを介してフレームバッファからクライアントコンピューティングデバイスに対話型グラフィックスの領域に対応するグラフィックスデータを送り、第２のチャネルを介してフレームバッファからクライアントコンピューティングデバイスに残りのグラフィックデータを送るように構成され得る。さらに、プロセッサはまた、たとえば、フレームバッファ内の他のコンテンツとは異なる仮想チャネルを介して対話型グラフィックスの領域に対応するグラフィックスデータを送るように構成され得る。

関連する方法は、フレームバッファを介してクライアントデバイスにリモートで表示されるべき仮想コンピューティングセッションをコンピューティングデバイスにおいてホストするステップであって、クライアントコンピューティングデバイスは、ＧＵＩを介して仮想コンピューティングセッションをレンダリングするように構成される、ステップを含み得る。本方法は、仮想セッション入力に基づいて、およびフレームバッファを分析することなしにコンピューティングデバイスにおいて仮想コンピューティングセッション内の対話型グラフィックスの領域を検出するステップと、コンピューティングデバイスにおいてフレームバッファ内の他のコンテンツよりも高い優先度を対話型グラフィックスの領域に割り当てるステップと、割り当てられた優先度に基づいてＧＵＩ中でレンダリングするためにコンピューティングデバイスからクライアントデバイスにフレームバッファのコンテンツを送るステップとをさらに含み得る。

関連するコンピューティングシステムは、仮想コンピューティングセッションをホストすることとフレームバッファを介して仮想コンピューティングセッションをリモートで表示することとを行うように構成されたサーバと、ＧＵＩを介してサーバから仮想コンピューティングセッションにリモートでアクセスするように構成されたクライアントデバイスとを含み得る。サーバは、仮想セッション入力に基づいて、およびフレームバッファを分析することなしに仮想コンピューティングセッション内の対話型グラフィックスの領域を検出することと、フレームバッファ内の他のコンテンツよりも高い優先度を対話型グラフィックスの領域に割り当てることと、割り当てられた優先度に基づいてＧＵＩ中でレンダリングするためにクライアントデバイスにフレームバッファのコンテンツを送ることとを行うようにさらに構成され得る。

本開示の様々な態様が実装され得るコンピューティングデバイスのネットワーク環境のブロック図である。 図１に示したクライアントマシンまたはリモートマシンの一実施形態を実施するために有用なコンピューティングデバイスのブロック図である。 本開示の様々な態様が実装され得るクラウドコンピューティング環境の概略ブロック図である。 地理的ロケーションに基づく異なるクラウドサービスポイントオブプレゼンス（ＰＯＰ）のためのラウンドトリップタイム（ＲＴＴ）を示す図である。 拡張クライアントコンピューティングデバイス表示リモーティング機能をもつ仮想コンピューティングセッションを与えるために様々な実施形態が実装され得る例示的なコンピューティングシステムの概略ブロック図である。 例示的な実施形態による、対話型グラフィックスの優先度付けを通して拡張表示リモーティングを与えるコンピューティングシステムの概略ブロック図である。 例示的な実施形態による、対話型グラフィックスの優先度付けを用いて実行され得るさらなる態様を示す図６のコンピューティングシステムの概略ブロック図である。 図６のシステムに関連する方法態様を示す流れ図である。 例示的な実施形態による、前方誤り訂正（ＦＥＣ）を通して拡張表示リモーティングを与えるコンピューティングシステムの概略ブロック図である。 例示的な実施形態による、ＦＥＣを用いて実行され得るさらなる態様を示す図９のコンピューティングシステムの概略ブロック図である。 図９のシステムに関連する方法態様を示す流れ図である。 例示的な実施形態による、ユーザ入力の優先度付けおよび送信を通して拡張表示リモーティングを与えるコンピューティングシステムの概略ブロック図である。 例示的な実施形態による、ユーザ入力の優先度付けおよび送信を用いて実行され得るさらなる態様を示す図１２のコンピューティングシステムの概略ブロック図である。 図１２のシステムに関連する方法態様を示す流れ図である。

概して、本明細書で開示する実施形態は、仮想コンピューティングセッションへのリモートアクセスを与えるコンピューティングシステムに関する。より詳細には、より多くの作業負荷がクラウドに移動され、データセンターが大陸にわたって統合されるので、作業負荷とクライアントエンドポイントとの間のネットワーク状態がより難しくなり、はるかに高いレイテンシおよびパケットロスで特徴づけられ、クライアントデバイスにおいて仮想コンピューティングセッションをリモートで表示することを困難にする。さらに、高解像度、たとえば、４Ｋ、およびマルチモニタ表示は、グラフィックス負荷をさらに高くする。逆に、モバイルデバイスを使用する間に、解像度がより低い間に、Ｃｉｔｒｉｘ Ｒｅｃｅｉｖｅｒ／Ｗｏｒｋｓｐａｃｅアプリとの天然様のアプリケーション応答性の期待がある。

リモートで表示される仮想コンピューティングセッションに関する現在のユーザエクスペリエンスは、いくつかの例では、相応して「遅く」なり得る。たとえば、そのような事例は、タイピング、マウスまたはタッチウィンドウのドラッグ、スクロール、アプリの切り替えなどの通常のオフィス作業負荷、複雑な３Ｄグラフィックスモデルと対話する３Ｄ Ｐｒｏの使用事例、ＸｅｎＡｐｐホストアプリを用いたバーチャルリアリティ（ＶＲ）の使用事例を含み得る。

本明細書に記載の実施形態は、有利には、いくつかの実装形態ではクラウドコンピューティング環境においてホストされ得る、仮想化サーバによってホストされる仮想セッションからのグラフィックスの拡張配信およびレンダリングを与える。これは、たとえば、帯域幅および／またはシステム負荷への低減されたまたは無視できる影響で、ユーザ入力が仮想コンピューティングセッションに配信され得、および／またはグラフィックスの更新がクライアントコンピューティングデバイスによってグラフィカルユーザインターフェース（ＧＵＩ）中にレンダリングされ得る改善された品質および／または速度を生じる。

本説明は、例示的な実施形態が示される添付の図面を参照して行われる。しかしながら、多くの異なる実施形態が使用され得、したがって、説明は、本明細書に記載の特定の実施形態に限定されるものと解釈すべきではない。同様の番号は、全体にわたって同様の要素を指す。

以下の開示を読めば当業者なら諒解するように、本明細書で説明される様々な態様は、デバイス、方法またはコンピュータプログラム製品（たとえば、言及される動作またはステップを実行するためのコンピュータ実行可能命令を有する非一時的コンピュータ可読媒体）として具現化され得る。相応して、それらの態様は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはソフトウェアおよびハードウェア態様を組み合わせた実施形態の形態を取り得る。

さらに、そのような態様は、記憶媒体中にまたはそれの上に組み込まれたコンピュータ可読プログラムコードまたは命令を有する１つまたは複数のコンピュータ可読記憶媒体によって記憶されたコンピュータプログラム製品の形態を取り得る。ハードディスク、ＣＤ－ＲＯＭ、光ストレージデバイス、磁気ストレージデバイス、および／またはそれらの任意の組合せを含む任意の好適なコンピュータ可読記憶媒体が利用され得る。

最初に図１を参照すると、本開示の様々な態様が実装され得る非限定的なネットワーク環境１０１は、コンピューティング環境１０１内に設置される１つまたは複数のクライアントマシン１０２Ａ～１０２Ｎと、１つまたは複数のリモートマシン１０６Ａ～１０６Ｎと、１つまたは複数のネットワーク１０４、１０４’と、１つまたは複数の機器１０８とを含む。クライアントマシン１０２Ａ～１０２Ｎは、ネットワーク１０４、１０４’を介してリモートマシン１０６Ａ～１０６Ｎと通信する。

いくつかの実施形態では、クライアントマシン１０２Ａ～１０２Ｎは、中間機器１０８を介してリモートマシン１０６Ａ～１０６Ｎと通信する。図示された機器１０８は、ネットワーク１０４とネットワーク１０４’との間に配置され、ネットワークインターフェースまたはゲートウェイと呼ばれることもある。いくつかの実施形態では、機器１０８は、データセンター、クラウド中に展開されるか、もしくはクライアントデバイスの範囲にわたってサービスとしてのソフトウェア（ＳａａＳ）として配信されるビジネスアプリケーションおよび他のデータへのアクセスをクライアントに与えるためにアプリケーション配信コントローラ（ＡＤＣ）として動作し、ならびに／または負荷分散などの他の機能を与え得る。いくつかの実施形態では、複数の機器１０８が使用され得、機器１０８は、ネットワーク１０４および／または１０４’の一部として展開され得る。

クライアントマシン１０２Ａ～１０２Ｎは、一般に、クライアントマシン１０２、ローカルマシン１０２、クライアント１０２、クライアントノード１０２、クライアントコンピュータ１０２、クライアントデバイス１０２、コンピューティングデバイス１０２、エンドポイント１０２、またはエンドポイントノード１０２と呼ばれることがある。リモートマシン１０６Ａ～１０６Ｎは、一般に、サーバ１０６またはサーバファーム１０６と呼ばれることがある。いくつかの実施形態では、クライアントデバイス１０２は、サーバ１０６によって与えられたリソースへのアクセスを求めるクライアントノードと、他のクライアントデバイス１０２Ａ～１０２Ｎのためのホストされたリソースへのアクセスを与えるサーバ１０６との両方として機能する能力を有し得る。ネットワーク１０４、１０４’は、一般に、ネットワーク１０４と呼ばれることがある。ネットワーク１０４は、ワイヤードおよびワイヤレスネットワークの任意の組合せで構成され得る。

サーバ１０６は、たとえば、ファイルサーバ、アプリケーションサーバ、ウェブサーバ、プロキシサーバ、機器、ネットワーク機器、ゲートウェイ、アプリケーションゲートウェイ、ゲートウェイサーバ、仮想化サーバ、展開サーバ、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒバーチャルプライベートネットワーク（ＳＳＬ ＶＰＮ）サーバ、ファイアウォール、ウェブサーバ、アクティブディレクトリを実行するサーバ、クラウドサーバ、またはファイアウォール機能、アプリケーション機能、もしくは負荷分散機能を与えるアプリケーション加速プログラムを実行するサーバなどの任意のサーバタイプであり得る。

サーバ１０６は、ソフトウェア、プログラム、実行可能命令、仮想マシン、ハイパーバイザ、ウェブブラウザ、ウェブベースのクライアント、クライアントサーバアプリケーション、シンクライアントコンピューティングクライアント、ＡｃｔｉｖｅＸコントロール、Ｊａｖａアプレット、ソフトＩＰ電話のようなボイスオーバーインターネットプロトコル（ＶｏＩＰ）通信に関係するソフトウェア、ストリーミングビデオおよび／もしくはオーディオのためのアプリケーション、リアルタイムデータ通信を容易にするためのアプリケーション、ＨＴＴＰクライアント、ＦＴＰクライアント、Ｏｓｃａｒクライアント、Ｔｅｌｎｅｔクライアント、または実行可能命令の任意の他のセットのうちのいずれか１つであり得るアプリケーションを実行するか、動作するか、そうでなければ与え得る。

いくつかの実施形態では、サーバ１０６は、サーバ１０６上で実行されるアプリケーションによって生成された表示出力をキャプチャし、クライアントデバイス１０２にアプリケーションの表示出力を送信するためにシンクライアントまたはリモートディスプレイプロトコルを使用するリモート提示サービスプログラムまたは他のプログラムを実行し得る。

また他の実施形態では、サーバ１０６は、クライアントデバイス１０２のユーザに、コンピューティング環境へのアクセスを与える仮想マシンを実行し得る。クライアントデバイス１０２は、仮想マシンであり得る。たとえば、仮想マシンは、ハイパーバイザ、仮想マシンマネージャ（ＶＭＭ）、またはサーバ１０６内の任意の他のハードウェア仮想化技法によって管理され得る。

いくつかの実施形態では、ネットワーク１０４は、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ワイドエリアネットワーク中のソフトウェア定義のネットワーキング（ＳＤ－ＷＡＮ）、１次公衆ネットワーク１０４、および１次プライベートネットワーク１０４であり得る。追加の実施形態は、モバイルデバイスの間で通信するために様々なプロトコルを使用する携帯電話網のネットワーク１０４を含み得る。ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）内の短距離通信のために、プロトコルは、８０２．１１と、Ｂｌｕｅｔｏｏｔｈと、近距離通信（ＮＦＣ）とを含み得る。

ＳＤ－ＷＡＮエンタープライズの１つの特に有利な実装形態は、より多くのスケーラビリティをもち、クラウドに接続する準備ができているコスト効果の高い形で企業がそれらのＷＡＮをレンダリングすることを可能にするＣｉｔｒｉｘ ＳＤ－ＷＡＮによって与えられる。Ｃｉｔｒｉｘ ＳＤ－ＷＡＮは、個々のＳａａＳアプリケーションを含むアプリケーションを識別し、ブランチからインターネット、クラウド、またはＳａａＳにトラフィックをインテリジェントに操作するために統合データベースおよびディープパケットインスペクションを含んでいる。さらに、Ｃｉｔｒｉｘ ＳＤ－ＷＡＮはまた、セキュアなウェブゲートウェイを介してブランチからインターネットにトラフィックをルーティングする能力を与え、ファイアウォール、ＵＲＬフィルタリング、および使用課金を含むクラウドベースのセキュリティを与える。

図２は、クライアントデバイス１０２、機器１０８および／またはサーバ１０６の実施形態を実施するのに有用なコンピューティングデバイス１００のブロック図を示す。コンピューティングデバイス１００は、１つまたは複数のプロセッサ１０３と、揮発性メモリ１２２（たとえば、ランダムアクセスメモリ（ＲＡＭ））と、不揮発性メモリ１２８と、ユーザインターフェース（ＵＩ）１２３と、１つまたは複数の通信インターフェース１１８と、通信バス１５０とを含む。

不揮発性メモリ１２８は、１つもしくは複数のハードディスクドライブ（ＨＤＤ）または他の磁気もしくは光学記憶媒体、フラッシュドライブもしくは他の固体記憶媒体などの１つもしくは複数のソリッドステートドライブ（ＳＳＤ）、１つもしくは複数のハイブリッド磁気およびソリッドステートドライブ、ならびに／またはクラウドストレージなどの１つもしくは複数の仮想ストレージボリューム、またはそのような物理ストレージボリュームと仮想ストレージボリュームもしくはそれのアレイとの組合せを含み得る。

ユーザインターフェース１２３は、グラフィカルユーザインターフェース（ＧＵＩ）１２４（たとえば、タッチスクリーン、ディスプレイなど）と、１つまたは複数の入出力（Ｉ／Ｏ）デバイス１２６（たとえば、マウス、キーボード、マイクロフォン、１つまたは複数のスピーカ、１つまたは複数のカメラ、１つまたは複数の生体スキャナ、１つまたは複数の環境センサ、および１つまたは複数の加速度計など）とを含み得る。

不揮発性メモリ１２８は、オペレーティングシステム１１５と、１つまたは複数のアプリケーション１１６と、データ１１７とを記憶し、したがって、たとえば、オペレーティングシステム１１５および／またはアプリケーション１１６のコンピュータ命令は、揮発性メモリ１２２の外でプロセッサ１０３によって実行される。いくつかの実施形態では、揮発性メモリ１２２は、１つもしくは複数のタイプのＲＡＭおよび／またはメインメモリよりも速い応答時間を提供し得るキャッシュメモリを含み得る。データは、ＧＵＩ１２４の入力デバイスを使用して入力されるか、またはＩ／Ｏデバイス１２６から受信され得る。コンピュータ１００の様々な要素は、通信バス１５０を介して通信し得る。

図示されたコンピューティングデバイス１００は、単に例示的なクライアントデバイスまたはサーバとして示されており、本明細書で説明されるように動作することが可能な好適なハードウェアおよび／またはソフトウェアを有し得る任意のタイプのマシンまたはマシンのセットをもつ任意の計算または処理環境によって実装され得る。

プロセッサ１０３は、システムの機能を実行するためにコンピュータプログラムなどの１つまたは複数の実行可能命令を実行するために１つまたは複数のプログラマブルプロセッサによって実装され得る。本明細書で使用する「プロセッサ」という用語は、機能、動作、または一連の動作を実行する回路を表す。機能、動作、または一連の動作は、回路にハードコードされるか、またはメモリデバイス中に保持され、回路によって実行される命令としてソフトコードされ得る。プロセッサは、デジタル値を使用しておよび／またはアナログ信号を使用して機能、動作、または一連の動作を実行し得る。

いくつかの実施形態では、プロセッサは、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、グラフィックス処理ユニット（ＧＰＵ）、マイクロコントローラ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）、マルチコアプロセッサ、または関連メモリをもつ汎用コンピュータで具現化され得る。

プロセッサ１０３は、アナログ、デジタルまたは混合信号であり得る。いくつかの実施形態では、プロセッサ１０３は、１つもしくは複数の物理プロセッサ、または１つもしくは複数の仮想（たとえば、遠隔に位置するもしくはクラウド）プロセッサであり得る。複数のプロセッサコアを含むプロセッサおよび／または複数のプロセッサは、命令の並列、同時実行のための機能、または２つ以上のデータに対する１つの命令の並列、同時実行のための機能を与え得る。

通信インターフェース１１８は、コンピューティングデバイス１００がセルラー接続を含む様々なワイヤードおよび／またはワイヤレス接続を通してＬＡＮ、ＷＡＮもしくはＳＤ－ＷＡＮ、パーソナルエリアネットワーク（ＰＡＮ）、またはインターネットなどのコンピュータネットワークにアクセスすることを可能にするために１つまたは複数のインターフェースを含み得る。

説明される実施形態では、コンピューティングデバイス１００は、クライアントデバイスのユーザに代わってアプリケーションを実行し得る。たとえば、コンピューティングデバイス１００は、ハイパーバイザによって管理される１つまたは複数の仮想マシンを実行し得る。各仮想マシンは、ホストされたデスクトップセッションなど、アプリケーションがユーザまたはクライアントデバイスに代わって実行する実行セッションを与え得る。コンピューティングデバイス１００はまた、ホストされたデスクトップ環境を与えるために端末サービスセッションを実行し得る。コンピューティングデバイス１００は、１つまたは複数のアプリケーションと、１つまたは複数のデスクトップアプリケーションと、１つまたは複数のアプリケーションが実行し得る１つまたは複数のデスクトップセッションとを含むリモートコンピューティング環境へのアクセスを与え得る。

例示的な仮想化サーバ１０６は、Ｆｌｏｒｉｄａ州Ｆｏｒｔ ＬａｕｄｅｒｄａｌｅのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．（「Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ」）によって与えられるＣｉｔｒｉｘ Ｈｙｐｅｒｖｉｓｏｒを使用して実装され得る。仮想アプリおよびデスクトップセッションは、さらに、同じくＣｉｔｒｉｘ ＳｙｓｔｅｍｓからのＣｉｔｒｉｘ Ｖｉｒｔｕａｌ Ａｐｐｓ ａｎｄ Ｄｅｓｋｔｏｐｓによって与えられ得る。Ｃｉｔｒｉｘ Ｖｉｒｔｕａｌ Ａｐｐｓ ａｎｄ Ｄｅｓｋｔｏｐｓは、スケーラブルなＶＤＩ解決策を実装するオプションに加えて、任意のデバイスからの仮想アプリ、デスクトップ、およびデータセッションを含む仮想セッションへのユニバーサルアクセスを用いて生産性を向上させるアプリケーション仮想化解決策である。

図３を参照すると、クラウド環境、クラウドコンピューティングまたはクラウドネットワークと呼ばれることもあるクラウドコンピューティング環境１６０が示されている。クラウドコンピューティング環境１６０は、複数のユーザまたはテナントに共有コンピューティングサービスおよび／またはリソースの配信を与えることができる。たとえば、共有リソースおよびサービスは、限定はしないが、ネットワークと、ネットワーク帯域幅と、サーバと、処理と、メモリと、ストレージと、アプリケーションと、仮想マシンと、データベースと、ソフトウェアと、ハードウェアと、分析と、インテリジェンスとを含むことができる。

クラウドコンピューティング環境１６０では、（上記で説明されたものなどの）１つまたは複数のクライアント１６２Ａ～１６２Ｃがクラウドネットワーク１６４と通信している。クラウドネットワーク１６４は、バックエンドプラットフォーム、たとえば、サーバ、ストレージ、サーバファームまたはデータセンターを含み得る。ユーザまたはクライアント１６２Ａ～１６２Ｃは、単一の団体／テナントまたは複数の団体／テナントに対応することができる。より詳細には、例示的な一実装形態では、クラウドコンピューティング環境１６０は、単一の団体（たとえば、エンタープライズクラウド）をサービスするプライベートクラウドを与え得る。別の例では、クラウドコンピューティング環境１６０は、複数の団体／テナントをサービスするコミュニティまたはパブリッククラウドを与え得る。

いくつかの実施形態では、ゲートウェイ機器またはサービスは、クラウドコンピューティングリソースおよび仮想セッションへのアクセスを与えるために利用され得る。たとえば、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．によって与えられるＣｉｔｒｉｘ Ｇａｔｅｗａｙは、仮想、ＳａａＳおよびウェブアプリケーションへのセキュアなアクセスおよびシングルサインオンをユーザに与えるためにオンプレミス（on-premises）でまたはパブリッククラウド上に展開され得る。さらに、ウェブ脅威からユーザを保護するために、Ｃｉｔｒｉｘ Ｓｅｃｕｒｅ Ｗｅｂ Ｇａｔｅｗａｙなどのゲートウェイが使用され得る。Ｃｉｔｒｉｘ Ｓｅｃｕｒｅ Ｗｅｂ Ｇａｔｅｗａｙは、ＵＲＬの評判およびカテゴリについて検査するためにクラウドベースのサービスおよびローカルキャッシュを使用する。

またさらなる実施形態では、クラウドコンピューティング環境１６０は、パブリッククラウドとプライベートクラウドとの組合せであるハイブリッドクラウドを与え得る。パブリッククラウドは、クライアント１６２Ａ～１６２Ｃまたは企業／テナントに対してサードパーティによって維持される公開サーバを含み得る。サーバは、遠く離れた地理的ロケーションに離れて位置するか、またはそうでなく位置し得る。

クラウドコンピューティング環境１６０は、異なる物理および仮想リソースがそれぞれの環境内での異なる需要に応答して動的に割り当てられ、再び割り当てられる状態でマルチテナント環境またはマルチテナントモデルを通してクライアント１６２Ａ～１６２Ｃを介して複数のユーザをサービスするためにリソースプーリングを与えることができる。マルチテナント環境は、複数のユーザをサービスするためにソフトウェアの単一のインスタンス、アプリケーションまたはソフトウェアアプリケーションを与えることができるシステムまたはアーキテクチャを含むことができる。いくつかの実施形態では、クラウドコンピューティング環境１６０は、複数のクライアント１６２Ａ～１６２Ｃのためのネットワークにわたって計算能力（たとえば、サーバ時間、ネットワークストレージ）を単方向にプロビジョニングするためにオンデマンドのセルフサービスを与えることができる。例として、サービスをプロビジョニングすることは、Ｃｉｔｒｉｘ Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｓｅｒｖｉｃｅｓ（Ｃｉｔｒｉｘ ＰＶＳ）などのシステムを通して与えられ得る。Ｃｉｔｒｉｘ ＰＶＳは、共有デスクトップイメージを通して複数の仮想デスクトップエンドポイントにパッチ、更新および他の構成情報を配信するソフトウェアストリーミング技術である。クラウドコンピューティング環境１６０は、１つまたは複数のクライアント１６２からの異なる需要に応答して動的にスケールアウトかまたはスケールインする弾性を与えることができる。いくつかの実施形態では、クラウドコンピューティング環境１６０は、与えられた共有サービスおよびリソースに対応する報告を監視、制御および／または生成するために監視サービスを含むかまたは与えることができる。

いくつかの実施形態では、クラウドコンピューティング環境１６０は、たとえば、サービスとしてのソフトウェア（ＳａａＳ）１７０、サービスとしてのプラットフォーム（ＰａａＳ）１７２、サービスとしてのインフラストラクチャ（ＩａａＳ）１７４、およびサービスとしてのデスクトップ（ＤａａＳ）１７６などの異なるタイプのクラウドコンピューティングサービスのクラウドベースの配信を与え得る。ＩａａＳは、指定された時間期間中に必要とされるインフラストラクチャリソースの使用をレンタルするユーザを指すことがある。ＩａａＳプロバイダは、大きいプールからストレージ、ネットワーキング、サーバまたは仮想化リソースを提供し、必要に応じてより多くのリソースにアクセスすることによってユーザが迅速にスケールアップすることを可能にし得る。ＩａａＳの例は、Ｗａｓｈｉｎｇｔｏｎ州ＳｅａｔｔｌｅのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．によって与えられるＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ、Ｔｅｘａｓ州Ｓａｎ ＡｎｔｏｎｉｏのＲａｃｋｓｐａｃｅ ＵＳ，Ｉｎｃ．によって与えられるＲＡＣＫＳＰＡＣＥ ＣＬＯＵＤ、Ｃａｌｉｆｏｒｎｉａ州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＧｏｏｇｌｅ Ｉｎｃ．によって与えられるＧｏｏｇｌｅ Ｃｏｍｐｕｔｅ Ｅｎｇｉｎｅ、またはＣａｌｉｆｏｒｎｉａ州Ｓａｎｔａ ＢａｒｂａｒａのＲｉｇｈｔＳｃａｌｅ，Ｉｎｃ．によって与えられるＲＩＧＨＴＳＣＡＬＥを含む。

ＰａａＳプロバイダは、たとえば、ストレージ、ネットワーキング、サーバまたは仮想化を含むＩａａＳによって与えられる機能ならびにたとえば、オペレーティングシステム、ミドルウェア、またはランタイムリソースなどの追加のリソースを提供し得る。ＰａａＳの例は、Ｗａｓｈｉｎｇｔｏｎ州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって与えられるＷＩＮＤＯＷＳ ＡＺＵＲＥと、Ｇｏｏｇｌｅ Ｉｎｃ．によって与えられるＧｏｏｇｌｅ Ａｐｐ Ｅｎｇｉｎｅと、Ｃａｌｉｆｏｒｎｉａ州Ｓａｎ ＦｒａｎｃｉｓｃｏのＨｅｒｏｋｕ，Ｉｎｃ．によって与えられるＨＥＲＯＫＵとを含む。

ＳａａＳプロバイダは、ストレージ、ネットワーキング、サーバ、仮想化、オペレーティングシステム、ミドルウェア、またはランタイムリソースを含むＰａａＳが与えるリソースを提供し得る。いくつかの実施形態では、ＳａａＳプロバイダは、たとえば、データおよびアプリケーションリソースを含む追加のリソースを提供し得る。ＳａａＳの例は、Ｇｏｏｇｌｅ Ｉｎｃ．によって与えられるＧＯＯＧＬＥ ＡＰＰＳ、Ｃａｌｉｆｏｒｎｉａ州Ｓａｎ ＦｒａｎｃｉｓｃｏのＳａｌｅｓｆｏｒｃｅ．ｃｏｍ Ｉｎｃ．によって与えられるＳＡＬＥＳＦＯＲＣＥ、またはＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって与えられるＯＦＦＩＣＥ ３６５を含む。ＳａａＳの例はまた、データストレージプロバイダ、たとえばＣｉｔｒｉｘ ＳｙｓｔｅｍｓからのＣｉｔｒｉｘ ＳｈａｒｅＦｉｌｅ、Ｃａｌｉｆｏｒｎｉａ州Ｓａｎ ＦｒａｎｃｉｓｃｏのＤｒｏｐｂｏｘ，Ｉｎｃ．によって与えられるＤＲＯＰＢＯＸ、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって与えられるＭｉｃｒｏｓｏｆｔ ＳＫＹＤＲＩＶＥ、Ｇｏｏｇｌｅ Ｉｎｃ．によって与えられるＧｏｏｇｌｅ Ｄｒｉｖｅ、またはＣａｌｉｆｏｒｎｉａ州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｉｎｃ．によって与えられるＡｐｐｌｅ ＩＣＬＯＵＤを含み得る。

ＳａａＳと同様に、（ホストされたデスクトップサービスとしても知られる）ＤａａＳは、仮想デスクトップセッションが仮想デスクトップ上で使用されるアプリとともにクラウドサービスとして一般に配信される仮想デスクトップインフラストラクチャ（ＶＤＩ）の形態である。Ｃｉｔｒｉｘ ＳｙｓｔｅｍｓからのＣｉｔｒｉｘ Ｃｌｏｕｄは、ＤａａＳ配信プラットフォームの一例である。ＤａａＳ配信プラットフォームは、たとえば、Ｗａｓｈｉｎｇｔｏｎ州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＡＺＵＲＥ ＣＬＯＵＤ（本明細書では「Ａｚｕｒｅ」）、またはＷａｓｈｉｎｇｔｏｎ州ＳｅａｔｔｌｅのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．によって与えられるＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（本明細書では「ＡＷＳ」）などのパブリッククラウドコンピューティングインフラストラクチャ上でホストされ得る。Ｃｉｔｒｉｘ Ｃｌｏｕｄの場合、Ｃｉｔｒｉｘ Ｗｏｒｋｓｐａｃｅアプリは、統一されたエクスペリエンスを配信するために（オンプレミスかまたはクラウド中かにかかわらず）アプリ、ファイルおよびデスクトップを一緒にするための単一のエントリポイントとして使用され得る。

次に図４～図５を参照すると、ユーザおよびシステムヒントの組合せを使用して難しいネットワーク状態において最適化された領域検出および配信を含むリモートコンピューティングコンテキスト内での階層表示のためのシステムおよび方法が与えられる。背景として、より多くの作業負荷がクラウドに移動され、データセンターが大陸にわたって統合されるので、作業負荷とクライアントエンドポイントとの間のネットワーク状態はより難しくなり、はるかに高いレイテンシおよびパケットロスで特徴づけられる。たとえば、Ｃｉｔｒｉｘ Ｗｏｒｋｓｐａｃｅは、サービスの中でもデスクトップおよびアプリ、たとえばＣｉｔｒｉｘ Ｖｉｒｔｕａｌ Ａｐｐｓ ａｎｄ Ｄｅｓｋｔｏｐｓ（ＣＶＡＤ）のクラウドベースの作業負荷、またはクラウド作業負荷と統合されたストアエクスペリエンスをもつオンプレミス作業負荷とのハイブリッド組合せへの統合されたリモートアクセスを与えるサービスである。さらに、サービスとしてのＣｉｔｒｉｘ Ｇａｔｅｗａｙ（ＧＷａａＳ）は、ユーザが顧客のオンプレミスのＣｉｔｒｉｘ ＮｅｔＳｃａｌｅｒ Ｇａｔｅｗａｙをセットアップすることなしにクラウド作業負荷とオンプレミス作業負荷との両方にリモートでアクセスすることを可能にする。しかしながら、クラウドとの間でのネットワークホップは、ネットワークのレイテンシをさらに増加させる。

図４の棒グラフ４０は、地理的ロケーションに基づいて異なるＣｉｔｒｉｘ Ｇａｔｅｗａｙのプレゼンスポイント（ＰＯＰ）中の独立コンピューティングアーキテクチャ（ＩＣＡ）ファイルのラウンドトリップ時間（ＲＴＴ）を示す。より詳細には、Ｃｉｔｒｉｘ ＩＣＡは、アプリケーションサーバシステムのためのプロプライエタリプロトコルである。それは、任意の単一のプラットフォームに制限されず、サーバとクライアントとの間でデータを受け渡すための仕様を与える。Ｃｉｔｒｉｘ ＩＣＡは、サーバソフトウェア構成要素と、ネットワークプロトコル構成要素と、クライアントソフトウェア構成要素とを含む。すべての測定は、トランスポートプロトコルとしての伝送制御プロトコル（ＴＣＰ）を介したＣｉｔｒｉｘ Ｈｉｇｈ－ｄｅｆｉｎｉｔｉｏｎ Ｕｓｅｒ Ｅｘｐｅｒｉｅｎｃｅ（ＨＤＸ）に基づく。Ｃｉｔｒｉｘ ＨＤＸ技術は、データセンターから任意のネットワークを介してクライアントコンピューティングデバイスに仮想デスクトップおよびアプリケーションの高品位のユーザエクスペリエンスを配信するために協力するプロトコルおよび能力のセットである。ＩＣＡ ＲＴＴは、ＨＤＸセッションの双方向性、たとえば、クリックツー光子時間を測定する。たとえば、これは、Ｃｉｔｒｉｘ ＲｅｃｅｉｖｅｒまたはＣｉｔｒｉｘ Ｗｏｒｋｓｐａｃｅアプリ（ＣＷＡ）をホストするクライアントデバイスにおけるユーザ入力イベント（キーボード、マウス、タッチ、電子ペン）とホストされるアプリケーションによって生成され、ＣＷＡをホストするクライアントデバイスにおいて配信される対応するグラフィックスの更新との間の時間差であり得る。ＩＣＡ ＲＴＴがアプリケーションの応答時間、サーバ負荷などによって影響を及ぼされ得るので、ＩＣＡ ＲＴＴは、必ずしもネットワークレイヤ７レイテンシに等しくなるとは限らない。

棒グラフ４０を見るとわかるように、アジア太平洋の作業負荷（ａｓ－ａｓｉａ－ｓｅ）でのユーザエクスペリエンス（ＵＸ）が特に難しくなっている。しかし、米国においてさえ、５０％を超える接続が、たとえば、ａｚ－ｕｓ－ｗまたはａｚ－ｕｓ－ｓｃが１００ｍｓ以上のＩＣＡ ＲＴＴを招いている。１０００～２０００ｍｓのレイテンシをもつ超小型地球局（ＶＳＡＴ：Very Small Aperture Termina）接続を使用するリモートブランチオフィスロケーションにいるユーザの追加の事例ある。棒グラフ４０では、「ａｗｓ」は、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ設備を指し、一方、「ａｚ」は、Ａｚｕｒｅ設備を指す。

さらに、高解像度（たとえば、４Ｋ）およびマルチモニタ表示は、グラフィックス負荷をさらに高くする。逆に、モバイルデバイスを使用するとき、解像度がより低い間に、Ｃｉｔｒｉｘ Ｒｅｃｅｉｖｅｒ／Ｗｏｒｋｓｐａｃｅアプリなどの製品との天然様のアプリケーション応答性の期待があり得る。ユーザエクスペリエンスは、タイピング、マウスまたはタッチウィンドウのドラッグ、スクロール、アプリの切り替えなどの通常のオフィス作業負荷、複雑な３Ｄグラフィックスモデルと対話する３Ｄ Ｐｒｏの使用事例、仮想ホストアプリを用いた、たとえば、ＣＶＡＤによって与えられるアプリおよびデスクトップを用いたバーチャルリアリティ（ＶＲ）の使用事例などのいくつかの状況において「遅く」なり得る。

スループットと双方向性との両方を改善するために、本明細書に記載のシステムおよび方法の例示的な実施形態は、ＴＣＰの制限の一部を克服するためにトランスポートプロトコルとしてユーザデータグラムプロトコル（ＵＤＰ）へのシフトを利用し得る。ＴＣＰは、加算的な増加乗算的な減少（ＡＩＭＤ：Additive Increments Multiplicative Decrements）輻輳制御アルゴリズムを使用し、レイテンシおよびロスの条件で帯域幅を十分に利用することができない。現代のネットワークでは、帯域幅は、より豊富にある傾向があり、パケットロスは、大部分はエンドポイント干渉（確率損失）によるものであり、輻輳によらない。したがって、若干のパケットロスは、スループットを大幅に低減することなしに許容され得る。たとえば、Ｇｏｏｇｌｅ製品ファミリ全体がＱＵＩＣに移行している。Ｃｉｔｒｉｘ ＨＤＸは、帯域幅割振りに関して依然として十分でありながら難しいネットワーク状態においてＴＣＰよりもよい輻輳およびフロー制御を有するＥｎｌｉｇｈｔｅｎｅｄ Ｄａｔａ Ｔｒａｎｓｐｏｒｔ（ＥＤＴ）プロトコルという高信頼送信のＵＤＰベースのプロトコルを最近導入した。

２５０ｍｓのＲＴＴおよび片道１％のパケットロスの典型的な海外のＷＡＮの場合、トランスポートとしてＥＤＴを介したＨＤＸは、仮想セッションの双方向性は最高２．５倍改善する（程度は作業負荷、たとえば、ノートパッド中のテキスト対画像をもつウェブページのスクロールに依存する）、クライアントドライブマッピングでのファイル転送（リモートファイルコピー）の速度－最高１０倍の改善、印刷（ホストアプリケーションからクライアントまたはネットワークマッピングされたプリンタへの印刷）の速度－最高２倍の改善、一般的なＵＳＢリダイレクションの速度－最高３５％の改善のようにＴＣＰを介したものよりはるかにうまく実行する。リモーティング技術がよりストリーム指向になり、より双方向的でなくなるほど、信頼できるＥＤＴの利益がより高くなる。したがって、ＥＤＴを用いたパフォーマンス改善は、リモート化されている様々な技術およびそれぞれのリモーティング仮想チャネルプロトコルによって異なる。

棒グラフ４０中の棒の各々において、関連する鍵によって示されるように、棒の下の部分は、ＲＴＴ時間＜５０ｍｓであるＩＣＡファイルの割合を表し、上の次のセクションは、５０～１００ｍｓのＲＴＴ時間を有するＩＣＡファイルの割合であり、上の次のセクションは、１００～２００ｍｓのＲＴＴ時間を有するＩＣＡファイルの割合であり、上の次のセクションは、２００～４５０ｍｓのＲＴＴ時間を有するＩＣＡファイルの割合であり、各棒の最も上のセクションは、ＲＴＴ時間＞４５０ｍｓであるＩＣＡファイルの割合を表す。

ＥＤＴが、程度の差はあってもすべてのＩＣＡ仮想チャネル（ＶＣ）に利益を与えるが、ＥＤＴが、ＵＸの双方向性を常に限定する、あらゆる紛失パケットがパケット再送信を生じることを意味する現在（唯一の）信頼できるプロトコルであるという事実により改善の余地が依然としてある。たとえば、ユーザ入力パケットの紛失は、紛失したパケットが正常に再送信されるまで、後続のユーザ入力パケットの送信の遅延を生じる可能性がある。別の例として、グラフィックス更新パケットの紛失は、紛失したパケットが正常に再送信されるまで、後続のグラフィックス更新パケットの送信の遅延を生じる可能性がある。（最初はあいまいで、変化が停止するとシャープ化される）過渡領域のためのプログレッシブ表示などのＨＤＸ Ｔｈｉｎｗｉｒｅの改善は、ＵＸを改善するのに役立つが、それらは基礎を成すトランスポートプロトコルの信頼できる性質によって依然として制限される。Ｔｈｉｎｗｉｒｅは、ＣＶＡＤにおいて使用されるＣｉｔｒｉｘデフォルトの表示リモーティング技術である。表示リモーティング技術により、１つのマシン上で生成されたグラフィックスが、表示のために別のマシンに一般にネットワークにわたって送信されることが可能になる。

さらに、現在のグラフィックス領域分析および分類は、ＣＰＵおよびメモリ集約的であるフレームバッファ分析に基づく。Ｍｉｃｒｏｓｏｆｔ Ｄｅｓｋｔｏｐ Ｄｅｄｕｐｌｉｃａｔｉｏｎ ＡＰＩなどのＡＰＩが「ダーティー領域」の検出（たとえば、最近変更され、更新を送信する必要があるグラフィックス領域）のための設備を与えるが、それらは、たとえば、ＣＶＡＤによる使用中のすべてのＯＳおよびグラフィックスドライバモデル上で利用可能でない。さらに、利用可能なときでも、これらのＡＰＩは、グラフィックスデータのセマンティクスに関する追加の緻密な情報、たとえば、静止画像と、速く変化するグラフィックス（ビデオ）と、テキストとの間の差異を与えない。したがって、効率的な動作のために追加のフレームバッファ分析が常に必要とされる。

図５を参照すると、システム５０は、クライアントデバイス５１がＶＤＩまたはクラウドベースの仮想化インフラストラクチャなどのホストから仮想コンピューティングセッション（たとえば、仮想デスクトップおよびアプリ）にリモートでアクセスし得る表示リモーティングアーキテクチャを示す。図示の例では、クライアントデバイス５１は、たとえば、Ｃｉｔｒｉｘ ＶＤＡなどによって与えられる仮想配信機器５２によって仮想コンピューティングセッションに接続される。クライアントデバイス５１と仮想配信機器５２とは、Ｔｈｉｎｗｉｒｅ（グラフィックス）チャネル５３、クライアントドライブマッピング（ＣＤＭ）チャネル５４、ユニバーサルシリアルバス（ＵＳＢ）チャネル５５、マルチメディアチャネル５６などを含む複数の異なる仮想チャネルを介して通信する。仮想チャネルデータは、仮想チャネルの多重化、たとえば、圧縮、優先度付け、および帯域幅の制限を実行するｗｉｎｓｔａｔｉｏｎドライバ（ＷＤ）５７を含む、リモートセッションへの成功した完全に機能的な接続を確立するために必要とされる随意のプロトコルドライバのセットをロードすることによって異なる機能を実行する独立コンピューティングアーキテクチャ（ＩＣＡ）プロトコルスタック４９内の一連のドライバをパススルーする。さらに、プロトコルドライバ（ＰＤ）５８の１つまたは複数のインスタンスは、たとえば、ＩＰフレーミングおよびセキュアなＩＣＡ（カスタム暗号化）動作を実行し得、一方、トランスポートドライバ（ＴＤ）５９は、Ｃｉｔｒｉｘ共通ゲートウェイプロトコル（ＣＧＰ）またはＳＯＣＫＳ５、ＷｅｂＳｏｃｋｅｔｓ、ＴＬＳ、およびＴＣＰなどのＴＣＰスタック動作ならびに／もしくはＣＧＰ、（信頼できるトランスポートと信頼できない（非可逆の）トランスポートとの両方のためのオプションをもつ）Ｅｎｌｉｇｈｔｅｎｅｄ Ｄａｔａ Ｔｒａｎｓｐｏｒｔ（ＥＤＴ）、データグラムトランスポートレイヤセキュリティ（ＤＴＬＳ）、およびＵＤＰを含むＵＤＰスタック動作を実行する。

図示の例では、ｗｉｎｓｔａｔｉｏｎドライバ５７とプロトコルドライバ５８との間で、ＩＣＡパケットは圧縮フォーマットのペイロードバイトであり、プロトコルドライバとトランスポートドライバ５９との間で、ＩＣＡパケットはフレーミングおよび／または内部暗号化を有する。トランスポートドライバ５９と（スイッチ、ルータ、ファイアウォール、ゲートウェイ、トラフィック整形器などを含み得る）ネットワークリンク４８との間で、ＩＣＡパケットは、ＣＧＰヘッダ、トランスポートレベルの暗号化（可能な場合）、イーサネットヘッダなどをもつワイヤフォーマットにある。システム５０の仮想配信機器５２側上に示されている同じ動作はまた、クライアント側上の対応する構成要素によって実行される。システム５０が、本明細書に記載の例示的な表示リモーティング技法が実装され得る１つの例示的な構成にすぎず、他の好適なアーキテクチャが異なる実装形態において使用され得ることに留意されたい。

概して、様々な有利な表示リモーティング最適化技法が、システム５０の例示的なアーキテクチャ（または他の好適なアーキテクチャ）内で実行され得る。これらは、（レイテンシおよび／またはパケットロスをもつ）難しいネットワーク状態における最適化されたグラフィックスリモーティングを用いる領域の検出、分類および更新優先度付け、ならびに階層表示のための最適化技法を含む。より詳細には、最適化されたグラフィックスリモーティングは、いくつかのエリア中での非可逆送信または信頼できる送信と非可逆送信との組合せを用いて忠実度を犠牲にしてより良い双方向性を達成することと、（帯域幅およびＣＰＵの利用率との何らかのトレードオフで）信頼できる送信の前方誤り訂正（ＦＥＣ）を用いて重要なエリア中での双方向性をさらに改善することと、非可逆送信のＦＥＣを用いて重要なエリア中での忠実度を回復すること（したがって、何らかの帯域幅およびＣＰＵを犠牲にして双方向性とともにより良い品質を達成すること）と、予想されるビットレート、割合損失および／または他のファクタに基づいて最適なＦＥＣアルゴリズムを選択することとを行うのに役立ち得る。さらに、いくつかの実装形態では、ユーザおよびシステムヒントが、上記のすべてを容易にするために使用され得、ユーザ入力が、再送信の遅延を回避するためにアグレッシブなＦＥＣを用い、帯域幅に対する無視できる影響で送られ得る。これらの様々な態様について、図６～図１４に関して以下でさらに説明することにする。

本明細書に記載の例示的な実施形態は、有利には、１つまたは複数の態様を通してユーザエクスペリエンスを改善する機会を与える。第１の態様は、ユーザおよびシステムヒントからの仮想セッション入力の組合せに基づき、フレームバッファ分析を実行する必要なしにより効率的で緻密なグラフィックス領域の検出、分類および更新優先度付けのためのものである。別の態様は、新しいＥＤＴ非可逆トランスポートプロトコルを介して信頼できない（非可逆の）方法であまり重要でないまたは過渡的な更新を送ること、たとえば、「撃ちっぱなし」方式で更新を送ることに関する。さらに別の態様は、確実にまたは非可逆な方法でだが、どちらの場合もＦＥＣを使用して重要な更新を送ることに関する。したがって、信頼できるトラフィックの場合、再送信は、ＦＥＣが失敗したときにのみ使用される必要がある。非可逆のトラフィックの場合、ＦＥＣが失敗したときの再送信は、データセマンティクスに応じて随意である。たとえば、紛失される場合、後続のフレームがより最新のグラフィックスを搬送し得るので、グラフィックスフレームは再送信される必要がなく、したがって、今はもう使われていないグラフィックスフレームを再送信する必要を除去し得る。別の同様の例として、後続のマウスドラッグイベントが現在のマウス位置などを搬送し得るので、紛失された個々のマウスドラッグイベントは再送信される必要がない可能性がある。さらに別の態様は、いずれかの方向での再送信の遅延を回避するためにグラフィックスの更新とユーザ入力との両方のためにＦＥＣを利用する。

１つの課題は、帯域幅または逆に有効なコンテンツビットレートとＣＰＵとに対する全体的な影響を最小化するための、およびＦＥＣ計算自体におけるレイテンシを回避するためのＦＥＣアルゴリズムの選択に関する。たとえば、ＦＥＣアルゴリズムは、等しいサイズのパケットに適用されるときに、およびオーディオまたはビデオなどの一定のビットレートストリームに適用されるときに最良に動作する。しかしながら、ＨＤＸなどの対話型のトラフィックに適用されるとき、データパケットのサイズとビットレートとは保証されず、ユーザのアクティビティ、アプリケーションタイプ、セッション解像度などに実質的に応じて変化することができる。この点について、以下でさらに説明されるように有用な方式でＦＥＣ技法を適用するために様々なファクタが考慮され得る。これらのファクタは、輻輳の回避を含み、すなわち、ＦＥＣは、有効なロスを減少させながら、帯域幅の消費量を増加させ、および／またはデータ送信の有効なビットレートを低下させる。しかも、推定された利用可能な帯域幅を上回るビットレートで送ることは輻輳を生じ得る。別のファクタはコストである。たとえば、帯域幅は、現代のネットワークではより豊富であるが、いくつかのアジアの領域では、米国においてよりも何倍も多く費用がかかることをデータは示している。

考慮すべきさらに別のファクタは双方向性である。次のパケットが送信キューから失われている場合、（たとえば、ユーザが、追加の入力イベント（たとえば、キーボード、マウス、タッチ、ペン入力）を生成していないか、またはホストアプリケーションがさらなるグラフィックスの更新を生成していない（たとえば、現在必要とされるさらなる更新がない）場合）、ＦＥＣ符号化されたパケットのバッチを完了するために、ＦＥＣの単純なアプリケーションがダミーパケットを送る必要がある可能性があり、これは、帯域幅を浪費するか、または次のパケットを待機し、これは、遅延をもたらし、ＦＥＣを使用する目的をくじく。したがって、ビットレートを予測し、対話型トラフィックに所望のＦＥＣ符号化を適用することは、所望のパフォーマンスのために有意であり得る。

次に図６～図７を参照すると、例示的な仮想化システム６０が示されており、ここで、仮想化サーバ６１は、フレームバッファ６５を介して１つまたは複数のクライアントコンピューティングデバイス６４に表示されるべき仮想コンピューティングセッション６３をホストするように構成されたプロセッサ６２を例示的に含む。上記のように、クライアントコンピューティングデバイス６４は、デスクトップ／ラップトップコンピュータ、スマートフォン、タブレットコンピュータなどの様々な形態を取り得、グラフィカルユーザインターフェース（ＧＵＩ）６６を介して仮想コンピューティングセッションをレンダリングするように構成される。仮想化サーバ６１は、さらに、フレームバッファ６５を分析することなしにユーザおよび／またはシステムヒントを含み得る仮想セッション入力に基づいて仮想コンピューティングセッション６３内の対話型グラフィックスの領域を検出し、フレームバッファ内の対話型グラフィックスの領域により高い優先度を割り当て得る。したがって、フレームバッファ６５のコンテンツは、割り当てられた優先度に基づいてＧＵＩ中でレンダリングするために仮想チャネル６７を介してクライアントコンピューティングデバイス６４に送られ得る。すなわち、領域または対話型グラフィックスは、ユーザに関心のあるエリアに関するより速い表示の更新を与えるためにＧＵＩの他のエリア（たとえば、静的バックグラウンドなど）と比較して最初にレンダリング／更新され、それによって、ユーザエクスペリエンスを向上させ得る。さらに、フレームバッファ６５は、フレーム内のより高い重要性のエリア（たとえば、対話型グラフィックス領域）を区別するために一行一行分析または走査される必要はないので、これはまた、より速い処理速度および／または低減された計算オーバーヘッドに寄与し得る。

図７の例示的な実装形態では、ユーザ入力から取られるヒントを含む仮想セッション入力をキャプチャするためにＵＩ自動化クライアントエージェントが与えられる。他の実施形態では、ユーザ入力から取られるヒントは、自動化クライアントエージェントの使用を必要としないことがある。たとえば、ユーザ入力ヒントは、それぞれの仮想コンピューティングセッション６３にクライアントコンピューティングデバイス６４によって与えられるユーザ入力を注入することを担当する仮想化サーバ６１サブシステム（図示せず）から直接導出され得る。他のタイプの仮想セッション入力は、仮想コンピューティングセッション６３へのフックから収集されるシステムヒントであり得る。概して、仮想セッション入力は、たとえば、ウィンドウパターンイベント、スクロールパターンイベント、およびテキストパターンイベントのうちの１つまたは複数を備え得る。

たとえば、背景として、ＵＩ要素は、（たとえば、アプリケーションウィンドウによってサポートされる）ウィンドウパターン、（たとえば、編集制御、文書またはリッチテキストの閲覧および処理制御によってサポートされる）テキストパターン、（たとえば、スクロール可能なビューによってサポートされる）スクロールパターン、（たとえば、表またはスプレッドシートの処理ビューによってサポートされる）格子パターンのうちの１つまたは複数のパターンを公開（またはサポート）し得る。場合によっては、ＵＩ要素は埋め込まれるか、そうでなければＵＩ要素の階層を形成し得、たとえば、文書編集ビューは、スクロールパターン内にテキストパターンを備えるスクロールコンテナを含み得る。異なるＵＩ要素パターンは、それぞれ名前が付けられたイベントを発行し得る。たとえば、ウィンドウパターンをサポートするＵＩ要素は、ウィンドウパターンイベント、たとえば、移動する、最大化する、最小化する、閉じるなどを発行し得る。別の例として、テキストパターンをサポートするＵＩ要素は、テキストパターンイベント、たとえば、変更されたテキスト、変更されたテキスト選択などを発行し得る。さらに別の例として、スクロールパターンをサポートするＵＩ要素は、スクロールイベント、たとえば、垂直スクロールアップまたは垂直スクロールダウンイベントなどを発行し得る。

以下でさらに説明されるように、プロセッサ６２はまた、ユーザエクスペリエンスをなお一層向上させるためにフレームバッファ６５の対応するコンテンツのレンダリングより前のレンダリングのためにクライアントコンピューティングデバイス６４にテキストパターンイベントに関連するテキストパターン入力データを非同期的に送るように構成され得る。すなわち、クライアントコンピューティングデバイス６４は、フレームバッファ６５からの対応するグラフィックスコンテンツが完全に受信される前でさえも変化するテキストを事前レンダリングまたはプレビューし得る。より詳細には、テキストパターン入力データは、テキストデータ（たとえば、ＡＳＣＩＩまたはＵＴＦ－８文字、シンボルなど）とフォントタイプ、フォントサイズ、前景色、背景色、イタリック、ボールド、下線、行間などの関連するテキストメタデータとを含み得る。さらに別の例示的な実装形態では、テキストパターン入力データは、スクロールコンテナ内のテキストパターン（スクロールバーをもつテキストウィンドウ）に対応し得る。

さらに、プロセッサ６２はまた、以下でさらに説明されるように、フレームバッファ内の他のコンテンツとは異なるレベルのＦＥＣをもつ関心領域に対応するフレームバッファ６５のコンテンツを送るように構成され得る。図示の例では、プロセッサ６２は、フレームバッファからの他のグラフィックスコンテンツとは異なるチャネル上でフレームバッファ６５からクライアントコンピューティングデバイス６４に対話型グラフィックスの領域に対応するグラフィックスデータを送るように構成される。ここで、対話型グラフィックスデータは、信頼できるチャネル６８を介して送られ、残りのグラフィックスデータは、非可逆チャネル６９を介してフレームバッファからクライアントコンピューティングデバイスに送られる。さらに、異なる量またはタイプのＦＥＣが、これらのチャネルの各々に適用され得、適用されるＦＥＣの量はまた、以下でさらに説明されるように、変動されるか、そうでなければ場合によっては調整され得る。

上記は、たとえば、図５に示されたフレームワーク内に与えられ得る様々な実装例を参照してさらに理解されよう。しかしながら、本明細書で説明される技法は、他のシステムアーキテクチャ中にも実装され得ることを理解されよう。領域検出のためのシステムヒントは、１つまたは複数の手法を含み得る。第１の手法は、仮想アプリウィンドウ追跡である。たとえば、これは、トップレベルウィンドウへの更新を列挙し、追跡するＣｉｔｒｉｘ ＣＶＡＤ Ｓｅａｍｌｅｓｓ Ａｐｐ Ｓｕｐｐｏｒｔ Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ（ＶＣ）サブシステムによって与えられ得る。別の手法は、たとえば、Ｓｅａｍｌｅｓｓ Ａｐｐ Ｓｕｐｐｏｒｔ ＶＣサブシステムによって使用される処理監視ドライバによって与えられるような仮想アプリ処理監視である。さらに別の手法は、たとえば、Ｍｉｃｒｏｓｏｆｔ ＵＩ Ａｕｔｏｍａｔｉｏｎ ＡＰＩ（Ｍｉｃｒｏｓｏｆｔ Ａｃｔｉｖｅ Ａｃｃｅｓｓｉｂｉｌｉｔｙ ＡＰＩの後継）に基づいてホストアプリケーションまたはデスクトップ環境から取り出されるパターン、プロパティおよびイベントを検出することを含み得る。特に、クライアントＡＰＩにより、アプリケーションは、他のアプリケーション中の制御と対話し、それらに関する情報を取り出すことが可能になる。ＨＤＸセッション中でエージェントは、ホストアプリケーションおよびデスクトップに関する情報を取り出すためにクライアントＡＰＩを使用し得る。エージェントは、特定のイベント通知に登録し得、特定のＵＩ自動化プロパティおよび制御パターン情報がそれのイベントハンドラに受け渡されることを要求することができる。さらなる手法は、たとえば、ＨＤＸトランスポートドライバによって測定され得るネットワークロス割合と、ロスの標準偏差と、レイテンシと、利用可能な帯域幅とを含み得る。ロスの計算がＦＥＣ自体の影響を除外し得ることに留意されたい。

ユーザヒントは、キーボード、マウス、タッチまたは他の入力デバイスからのアクティブユーザ入力を含み得る。別の例は、ホストアプリケーションまたはデスクトップの特定のＵＩ要素におけるユーザ入力である。たとえば、これは、ＳｃｒｏｌｌＰａｔｔｅｒｎをサポートするＵＩ要素中でのクリックもしくはタップまたはＴｅｘｔＰａｔｔｅｒｎをサポートするＵＩ要素中でのキーボード入力などを含み得る。

上記のヒントは、以下でさらに説明されるように、入力として使用され、たとえば、Ｔｈｉｎｗｉｒｅによって対話型グラフィックス配信を最適化するために利用され得る。上記のように、Ｔｈｉｎｗｉｒｅは、ホストとクライアントとの間でのグラフィックスリモーティングのためのＣｉｔｒｉｘ ＸｅｎＡｐｐ Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ（ＶＣ）である。しかしながら、他のグラフィックスリモーティングツールおよびシステムも異なる実施形態において使用され得ることを諒解されよう。

領域の検出、分類および更新優先度付けのための最適化技法に関して、ホストＴｈｉｎｗｉｒｅビットマップマッチポイントアルゴリズムにロケーションヒントを与えることは、より速い、より効率的な（より少ないＣＰＵ、メモリ）キャッシュされたビットマップの検出を生じ得る。さらに、ホストＴｈｉｎｗｉｒｅテキスト検出アルゴリズムにロケーションヒントを与えることは、有利には、より速い、より効率的な（より少ないＣＰＵ、メモリ）キャッシュされたグリフの検出を生じ得る。

領域の検出のためのシステムヒントは、たとえば、仮想セッション中で動作し、ＷｉｎｄｏｗＰａｔｔｅｒｎイベントおよびプロパティ更新をリッスンするＵＩ自動化クライアントエージェントからウィンドウ移動によって与えられ得る。これは、仮想セッション中のＴｈｉｎｗｉｒｅグラフィックスコンシューマモジュールへのトリガとして使用され得る。例示的なパラメータは、新旧のウィンドウ位置、サイズを含み得る。

以下は、ウィンドウ移動検出およびグラフィックスリモーティングの最適化のために使用され得る例示的なプロセスフローである。
サーバからクライアントに送られるローカルスクリーンツースクリーンコピー／ＢｉｔＢｌｉｔ（近似）コマンド。
クライアントにおける露出エリアのローカルフィル
無地を用いる、
または、露出ウィンドウまたはデスクトップバックグラウンドの事前キャッシュされたグラフィックスを用いる。これは、ウィンドウ階層の追跡と、クライアントにおいてキャッシュされるべき重複ウィンドウのウィンドウサーフェスグラフィックスを事前に送ることとを必要とし得る。
＜非同期的に＞
サーバからクライアントに露出エリアを送る。
＜非同期的に＞
ホストＴｈｉｎｗｉｒｅビットマップマッチポイントアルゴリズムにロケーションヒント（領域移動）を与える。
今はＴｈｉｎｗｉｒｅから見えるものとして新しいウィンドウエリアを送る
それぞれマッチヒットまたはマッチミスによりキャッシュされたビットマップまたは新しいビットマップ。
この手法がまた、ウィンドウコンテンツがドラッグしながら変化する可能性がある場合をカバーし得ることに留意されたい。

ウィンドウ／コンテナスクロールに関して、これは、上記で説明されたウィンドウ移動手法と同様であるが、ウィンドウ全体の移動とは反対に局地的にスクロールされたエリアが対象となり得る。スクロールのシステムヒントは、たとえば、仮想セッション中で動作し、ＳｃｒｏｌｌＰａｔｔｅｒｎおよび／またはＳｃｒｏｌｌＩｔｅｍＰａｔｔｅｒｎイベントならびにプロパティ更新をリッスンするＵＩ自動化クライアントエージェントから与えられ得る。これは、仮想セッション中のＴｈｉｎｗｉｒｅグラフィックスコンシューマモジュールへのトリガとして使用され得る。パラメータは、ＵＩ制御が水平方向におよび／または垂直方向にスクロール可能であるのかどうか、水平および垂直ビューサイズ、水平および垂直スクロール割合の新旧の値を含み得る。以下は、例示的なプロセスフローである。
サーバからクライアントに送られるローカルスクリーンツースクリーンコピー／ＢｉｔＢｌｉｔ（近似）コマンド。
無地を用いたクライアントにおける露出エリアのローカルフィル。
＜非同期的に＞
サーバからクライアントに露出エリアを送る。
＜非同期的に＞
ホストＴｈｉｎｗｉｒｅビットマップマッチポイントアルゴリズムにロケーションヒント（領域移動）を与える。
今はＴｈｉｎｗｉｒｅから見えるものとしてスクロールコンテナの残りの可視領域（ビューポート）を送る。
それぞれマッチヒットまたはマッチミスによりキャッシュされたビットマップまたは新しいビットマップ。
ここで再度、これは、スクロールされるアイテムコンテンツがスクロールしながら変化する可能性がある場合をカバーし得る。

テキストをもつウィンドウ／コンテナスクロールに関して、上記で説明されたウィンドウ／コンテナスクロールの最適化バージョンが使用され得る。より詳細には、スクロールコンテナの可視領域（ビューポート）の露出エリア内のＴｅｘｔＰａｔｔｅｒｎを検出することと、スクロールコンテナの残りの可視領域（ビューポート）内のＴｅｘｔＰａｔｔｅｒｎを検出することとの追加のシステムヒントが使用され得る。以下は、例示的なプロセスフローである。
サーバからクライアントに送られるローカルスクリーンツースクリーンコピー／ＢｉｔＢｌｉｔ（近似）コマンド。
ＴｅｘｔＰａｔｔｅｒｎが露出エリア内で検出された場合
サーバからクライアントにフォントタイプ、フォントサイズ、前景／背景色、イタリック、ボールド、下線、行間などの属性とともに実際のテキストを送る。
クライアントにおいて受信されたテキストのローカルレンダリング（近似）
＜非同期的に＞
ホストＴｈｉｎｗｉｒｅテキスト検出アルゴリズムにロケーションヒント（領域）を与える。
そうでない場合
無地を用いたクライアントにおける露出エリアのローカルフィル。
＜非同期的に＞
ホストＴｈｉｎｗｉｒｅビットマップマッチポイントアルゴリズムにロケーションヒントを与える。
サーバからクライアントに露出エリアを送る。
ＴｅｘｔＰａｔｔｅｒｎが露出エリア内に実際に存在した場合
それぞれマッチヒットまたはマッチミスによりキャッシュされたおよび／または新しいグリフのセット
そうでない場合
それぞれマッチヒットまたはマッチミスによりキャッシュされたビットマップまたは新しいビットマップ。
＜非同期的に＞
ＴｅｘｔＰａｔｔｅｒｎが残りの可視領域内で検出された場合
ホストＴｈｉｎｗｉｒｅテキスト検出アルゴリズムにロケーションヒント（領域）を与える。
そうでない場合
ホストＴｈｉｎｗｉｒｅビットマップマッチポイントアルゴリズムにロケーションヒント（領域移動）を与える。
今はＴｈｉｎｗｉｒｅから見えるものとして残りの可視領域を送る
ＴｅｘｔＰａｔｔｅｒｎが残りの可視領域に実際に存在した場合
それぞれマッチヒットまたはマッチミスによりキャッシュされたおよび／または新しいグリフのセット。
そうでない場合
それぞれマッチヒットまたはマッチミスによりキャッシュされたビットマップまたは新しいビットマップ。
可能性は低いが、スクロールされるアイテムコンテンツがスクロールしながら変化する可能性がある場合をカバーし得る。

クライアントは、最初に、（非同期的に、実際にはより早く）サーバから受信された属性（テキストメタデータ）をもつ実際のテキストに基づいてユーザに近似の更新を与える。クライアントは、次いで、（非同期的に、実際には後で）テキストグリフ（グラフィックス）を使用して真の最終的なアプリケーション更新を与える。この手法は、有利には、最初に、軽量の近似のフィードバックを与え、その後、コンピューティングパワーおよび帯域幅に関してより重いフィードバックだが、正確な最終的なアプリケーションフィードバックを与えることによって双方向性を改善する。テキストメタデータは、さらなる双方向性の利益を達成するために非可逆トランスポート６９を介しておよび／またはＦＥＣを用いて送られ得る。

テキスト編集に関して、（たとえば、仮想セッション中に動作し、テキストを含んでいる制御への入力フォーカスを監視するＵＩ自動化クライアントエージェント７０からの）ＴｅｘｔＰａｔｔｅｒｎを含んでいるＵＩ要素中の入力フォーカスのシステムヒントは、仮想セッション中のＴｈｉｎｗｉｒｅグラフィックスコンシューマモジュールへのトリガとして使用され得る。パラメータは、入力フォーカスのロケーション、文字、単語、行、章、ページまたは文書全体のある範囲内のテキスト、フォントタイプ、フォントサイズ、前景／背景色、イタリック、ボールド、下線、行間などを含み得る。以下は、例示的なプロセスフローである。
カーソル（入力フォーカス）の位置を決定する。
ＴｅｘｔＰａｔｔｅｒｎを含んでいるＵＩ要素中の入力フォーカスを検出する。
以下のうちの１つまたは複数を検出する
（入力チャネルからの）アクティブユーザ入力
テキストの変更（ＴｅｘｔＣｈａｎｇｅｄＥｖｅｎｔ）
テキスト選択の変更（ＴｅｘｔＳｅｌｅｃｔｉｏｎＣｈａｎｇｅｄＥｖｅｎｔ）
など。
ホストＴｈｉｎｗｉｒｅテキスト検出アルゴリズムにロケーションヒント（領域）を与える。
入力フォーカスの周りの重要なエリアを決定する
周囲の単語または文字カウント（前後）、フォントタイプおよびサイズ、行間、インデント、箇条書き、テキスト選択範囲などのしきい値に基づく。
ＶＣ Ｗｒｉｔｅインターフェース中でＱｏＳを要求する
より高い優先度。
高度なＦＥＣを用いて送る。
ＦＥＣを用いて確実に送るか、またはＦＥＣを用いて非可逆的な方式で送る。決定は、カーソル位置に対して更新テキストがどこにあるのかに基づき得る
左／上の場合、すぐの変更は予想されなく、したがって、信頼できる送信を使用する。
右／下の場合、すぐの変更が予想され、したがって、変更が停止するまで非可逆的送信を使用し、次いで、信頼できる送信を使用する。
変更されるテキストエリアのサイズがあるしきい値を上回る場合、テキストをもつウィンドウ／コンテナスクロールについて上記で説明された技法は次のように応答時間を高速化するために使用され得る。
サーバからクライアントにフォントタイプ、フォントサイズ、前景／背景色、イタリック、ボールド、下線、行間などの属性とともに実際のテキストを送る。
クライアントにおいて受信されたテキストのローカルレンダリング（近似）。
＜非同期的に＞
入力フォーカスの周りの重要なエリアを送る。

上記で説明されたテキストをもつウィンドウ／コンテナスクロールの場合と同様に、クライアントコンピューティングデバイス６４は、最初に、（非同期的に、実際にはより早く）仮想化サーバ６１から受信された属性（テキストメタデータ）をもつ実際のテキストに基づいてＧＵＩ６６を通してユーザに近似の更新を与え得る。クライアントコンピューティングデバイス６４は、次いで、（非同期的に、実際には後で）テキストグリフ（グラフィックス）を使用して真の最終的なアプリケーション更新を与え得る。この手法は、有利には、最初に、軽量の近似のフィードバックを与え、その後、（コンピューティングパワーおよび帯域幅に関して）より重いが、正確な最終的なアプリケーションフィードバックを与えることによって双方向性を改善する。ここで再度、テキストメタデータは、さらなる双方向性の利益を得るために非可逆トランスポート６９を介しておよび／またはＦＥＣを用いて送られ得る。

次に図８の流れ図８０を参照すると、システム６０に関する関連する方法態様について次に説明する。ブロック８１から始まり、本方法は、ブロック８２において、フレームバッファ６５を介してクライアントコンピューティングデバイス６４にリモートで表示されるべき仮想コンピューティングセッション６３を仮想化サーバ６１においてホストすることを含み得る。上記のように、クライアントコンピューティングデバイス６４は、ＧＵＩ６６を介して局所的に仮想コンピューティングセッション６３をレンダリングする。本方法は、さらに、ブロック８３において、仮想セッション入力（たとえば、上記でさらに説明されたユーザおよび／またはシステムヒント）に基づいて、フレームバッファ６５を分析することなしに仮想化サーバ６１において仮想コンピューティングセッション６３内の対話型グラフィックスの領域を検出することと、仮想化サーバにおいてフレームバッファ内の対話型グラフィックスの領域により高い優先度を割り当てることと（ブロック８４）を例示的に含む。本方法はまた、上記でさらに説明されたように、割り当てられた優先度に基づいてＧＵＩ６６中でレンダリングするために仮想化サーバ６１からクライアントコンピューティングデバイス６４にフレームバッファ６５のコンテンツを送ること（ブロック８５）を例示的に含む。図８の方法は、ブロック８６において例示的に終わる。

図９～図１０を参照して、ＱｏＳレベルまたはパラメータに基づいて、場合によっては、異なる仮想グラフィックスチャネル（たとえば、信頼できる非可逆チャネル）にわたって適切な程度および／またはタイプのＦＥＣを選定することに関する別の例示的な実施形態について次に説明する。図示の例では、コンピューティングシステム９０は、上記で説明されたように、フレームバッファ９５を介してリモートで表示されるべき仮想コンピューティングセッション９３をホストするように構成されたプロセッサ９２をもつ仮想化サーバ９１と、仮想化サーバから仮想コンピューティングセッションにリモートでアクセスし、ＧＵＩ９６を介して仮想コンピューティングセッションをレンダリングするように構成されたクライアントコンピューティングデバイス９４とを例示的に含む。ただし、プロセッサ９２は、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比に基づいてフレームバッファ９５内のグラフィカルコンテンツのためのＦＥＣデータを生成するようにさらに構成され得る。

さらに、プロセッサ９２は、ＧＵＩ９６内での表示のために１つまたは複数の仮想チャネル９７を介してクライアントコンピューティングデバイス９４にグラフィカルコンテンツと関連するＦＥＣデータとをさらに送る。さらに、プロセッサ９２はまた、以下でさらに説明されるように、有利には、仮想チャネル９７に関連するＱｏＳパラメータを決定し、ＱｏＳパラメータの変化に基づいてＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比を選択的に変更するように構成される。

より詳細には、クライアントコンピューティングデバイス９４に送られるグラフィカルデータコンテンツはパケットに分割され得、例示的な一実装形態では、ＱｏＳパラメータは、パケットロス率であり得る。この場合、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、パケットロス率が増加するにつれて減少し得、逆もまた同じである。すなわち、増加されたパケットロスを緩和するのを助けるためにより多くのＦＥＣデータが生成され、（全体的な利用可能な帯域幅のより多くを消費して）クライアントコンピューティングデバイス９４に送られ得る。プロセッサ９２がまた、送られているＦＥＣデータに対するグラフィックスの比を同じく調節しながら全体的な利用可能な帯域幅を増加／または減少させ得るが、場合によっては、プロセッサ９２は、仮想チャネル９７の全体的な帯域幅を変更することなしにＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比を選択的に変更し得ることに留意されたい。比がどのように変更され得るのかのさらなる詳細および例について、以下でさらに説明する。

図１０に示す例示的な実施形態では、たとえば上記で説明された手法を用いて異なるグラフィックスコンテンツを送るために信頼できるチャネル９８と非可逆チャネル８９との両方が使用される。この場合、異なるチャネル９８、９９にわたって送られているグラフィックスデータのために異なる比が使用され得る。たとえば、信頼できるチャネルにわたってパケットロスはより少なくなるべきであるので、信頼できるチャネル９８上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、非可逆チャネル９９上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比よりも高くなり得る。さらに、これらの比は、各チャネルに関連するそれぞれのＱｏＳ測定値に基づいて調整されるかまたは変更され得、場合によっては、異なるタイプのＱｏＳ測定値が、同様に異なるチャネルのために使用され得る。

ＱｏＳ測定が行われる方式は、異なるタイプの測定で異なり得る。たとえば、上記のようにおよび以下でさらに詳細に説明されるように、ロス、レイテンシ、推定された帯域幅などは、上記で説明されたＣｉｔｒｉｘアーキテクチャ中のＨＤＸスタックによって測定され得る。予想されるビットレートなどの他の測定は、リモート技術に固有であり得る。たとえば、それらは、ユーザ入力およびグラフィックスを生成するそれぞれの予想されるグラフィックスサブシステムのファクタであり得る。目的は、「重要な」データが遅滞なく送出され、さらに「あまり重要でない」データが許容できる品質のロスで送出されることを保証するために、控えめにだが十分にＦＥＣを使用することであり得る。

別の例示的な実装形態では、ＱｏＳパラメータはレイテンシに関連し得、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、レイテンシが増加するにつれて減少し得る。すなわち、レイテンシが増加するにつれて、グラフィックスデータに対してより多くのＦＥＣデータが送られ、逆もまた同じである。さらに別の例では、ＱｏＳパラメータは、グラフィックスチャネル９７のための推定された帯域幅に関係し得、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、必要に応じて、より多くのグラフィックスデータまたはＦＥＣデータが送られるのを可能にするために推定された帯域幅が増加するにつれて増加または減少し得る。さらに、別の例示的な実装形態では、ＱｏＳパラメータは、仮想チャネル９７に関連する予想されるビットレートを備え得、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、たとえば、予想されるビットレートが減少するにつれて減少し得、逆もまた同じである。さらに別のＱｏＳパラメータは、仮想化サーバ９１に関連するサーバ負荷（たとえば、コンピュータプロセッサにアクセスするために何個の処理がキュー中で待っているのか）に関連し得る。

上記で与えた例以外の他のＱｏＳパラメータが異なる実施形態で使用され得、また、ＦＥＣ帯域幅に対するグラフィックスコンテンツの比をいつ変更すべきかを決定する際にプロセッサ９２が２つ以上のＱｏＳパラメータを考慮に入れ得ることに留意されたい。さらに、いくつかの実装形態では、特定のＱｏＳ測定における短い変化またはスパイクを考慮するために比を変更するときに遅延またはヒステリシスが使用され得、変化は、所望される場合、測定されたＱｏＳが異なるしきい値に達するときに行われ得る。

前述は、様々な実装例を参照してさらに理解されよう。ここで再度、これらの例示的な実装形態は、図５に示されるフレームワークのコンテキストで与えられるが、これらの技法は、同様に他の仮想化アーキテクチャ内に適用され得る。概して、パケットロスがあるときにＦＥＣを適用することが望ましいことがある。そうでない場合、帯域幅が利益なしで浪費され得る。パケットロスの計算は、独立しており、すなわち、ＦＥＣによって歪められないことがある。たとえば、ＦＥＣは、たとえば、ＷＡＮ上にまたはワイヤレスネットワーク上に固有のランダムパケットロスがある場合、利用可能な帯域幅が依然として限定され、共有される可能性があるが、高い場合、および最大許容レイテンシが限定される上にネットワークＲＴＴに相当するかまたはそれよりも低い場合といったネットワーク状態において望ましいことがある。

仮想化サーバ９１は、コンテンツ帯域幅とＦＥＣ帯域幅との間で総スループットをどのように分割するのかを決定し得る。たとえば、サーバは、適度なロス率では９０％から１０％の比を使用し、またはより高いロス率では６６％から３３％の比を使用することを決定し得る。他の勾配も使用される可能性がある。

仮想化サーバ９１はまた、単に発信ストリームにＦＥＣを追加し得、これは、全体的な帯域幅使用量を増加させることになる。あるいは、サーバは、全体的な帯域幅使用量を同じ状態にしておき、ＦＥＣのために残りを使用しながらコンテンツデータレートを調整するか、そうでなければスロットルダウンし得る。後者の手法は、サーバが利用可能な帯域幅を推定し、それを超えないことを保証するネットワークの公正な共有および輻輳回避により寄与する。

仮想化サーバ９１は、送信されるべきコンテンツを理想的には同じサイズのパケットのグループ（またはフレーム）にパッケージングし得、ここで、バイト単位のグループサイズは、ＦＥＣ計算によりコンテンツ帯域幅に最大許容レイテンシを乗算したものとすることができる。たとえば、Ｎ個のコンテンツパケットのグループごとに、ＦＥＣアルゴリズムは、Ｋ個のＦＥＣパケットを作成し得る。任意の妥当な値のＮおよびＫが使用され得る。得られた帯域幅分割は、コンテンツのためのＮ／（Ｎ＋Ｋ）およびＦＥＣのためのＫ／（Ｎ＋Ｋ）である。さらに、コンテンツまたはＦＥＣのいずれか最高Ｋ個のパケットがグループ送信中で紛失され得、受信側は、元のＮ個のコンテンツパケットを復元することが依然として可能であることになる。

サーバトランスポートドライバ５９において、ＩＣＡパケットは、良好な自然境界、たとえば、高スループットモードで約５ＫＢを与える。たとえば、それは、４つのパケットに分割され得る。このような場合、ＦＥＣは、１つの追加のＦＥＣパケットでは、１つのドロップされたパケット（２０％のロス）を許容し、２つの追加のＦＥＣパケットでは、２つのドロップされたパケット（３３％のロス）を許容するように適用され得る。実際には、ロスは時々連続するので、結果はより少なくなり得る。

ＦＥＣの単純な形態は追加のライブラリを必要としない「排他的論理和」（ＸＯＲ）である。数学的計算とＦＥＣを適用することとの通常２つの部分を有する例示的な実施形態において使用され得るＦＥＣおよびライブラリの複数の異なる形態がある。たとえば、Ｊｅｒａｓｕｒｅ、Ｅｒａｓｕｒｅ Ｃｏｄｉｎｇ Ｌｉｂｒａｒｙは、必要な数学プリミティブのためのオープンソースライブラリである。別の例示的な手法は、ＧＦ－Ｃｏｍｐｌｅｔｅである。他の好適な手法も使用され得る。

送信されるべきグラフィックス更新を生成するサーバグラフィックスコンシューマモジュールは、最大アプリケーションペイロードサイズ、すなわち、ネットワークの最大転送ユニット（ＭＴＵ）からたとえば、トランスポート暗号化、信頼性、フレーミング、ＩＣＡプロトコルオーバーヘッドなどからの任意のプロトコルオーバーヘッドを減じたものに一致するデータパケットを生成しようと試み得る。グラフィックスモジュールは、周期的に更新を生成し得る。たとえば、フレーム更新は、Ｋ個のＦＥＣパケットのグループによって保護されるＮ個のコンテンツパケットのグループに非常に自然にマッピングすることになる。所望の結果のために、レイテンシを最小化するために、フレームサイズは、最大アプリケーションペイロードサイズに等しくなるか、またはそれの倍数になり得る。同様に、ビデオ符号化、たとえば、Ｈ．２６４のために、ネットワーク抽象化レイヤユニット（ＮＡＬＵ）は、最大アプリケーションペイロードサイズに一致し得る。

トランスポートドライバ５９中でのＦＥＣ符号化／復号処理中のレイテンシは、ＦＥＣを生成する前に送信側／サーバにおいてパケットの完全なグループをバッファしなければならないことから来ることになり、受信機／クライアント側において紛失したパケットを復元することから来ることになる。上記の最適化では、レイテンシは、それをレンダリングし始める前にクライアントにおいてフレーム更新全体を収集しなければならないことによってしか発生しないことになる。

例示的な実施形態は、１つまたは複数のＦＥＣ最適化技法を利用し得る。第１の最適化技法は、ＦＥＣを用いる信頼できるトランスポートまたはチャネル９８を介したおよび／またはＦＥＣを用いる９９の非可逆のトランスポートを介したグラフィックス送信に関与する。この場合、グラフィックスモジュールは、トランスポートとしてＥＤＴを検出し得、これは、ＥＤＴ高信頼能力およびＥＤＴ非可逆の能力を与え得る。（有効なコンテンツビットレートを低下させることが望ましくないと仮定すると）グラフィックスモジュールは、ロス率、レイテンシ、利用可能な帯域幅などのＱｏＳのしきい値を超えることをさらに検出し得、それは、ハイブリッドの信頼できる非可逆のモードにさらに切替え得る。

ＦＥＣを用いる非可逆トランスポートに関して、いくつかのグラフィックス更新が、たとえば、信頼できるまたは順序どおりの配信を保証しない追加のＬｏｓｓｙ ＶＣ Ｗｒｉｔｅインターフェースを使用して不確実に送られる。さらに、ＦＥＣ要求は、Ｌｏｓｓｙ ＶＣ ＷｒｉｔｅインターフェースへのＱｏＳパラメータに基づいてトランスポートドライバ５９によって処理され得る。Ｌｏｓｓｙ ＶＣ Ｗｒｉｔｅインターフェースは、送信されているパケットの状態、たとえば、配信済み、紛失、未知などに関して問い合わされ得るチケットを戻す。グラフィックスモジュールは、任意選択で、それがそれを再送信することを決定し得る場合に送信されたデータを手放さないことがある。

ＦＥＣに失敗した場合、応答、たとえば、パケットのためのＮａｃｋ／Ａｃｋが、ＥＤＴトランスポート応答チャネルを介して送られる。パケットに関連するチケットの状態が更新され、チケットを保持するグラフィックスモジュールが更新を受信する。さらに、グラフィックスモジュールは、同じＱｏＳ要求で紛失データを再送信するか、よりアグレッシブなＦＥＣを要求するか、それを代わりに信頼できるトランスポートを介して送るか、または紛失データについて断念することを決定し、代わりにより最近のデータを送る。

ＦＥＣを用いる信頼できるトランスポートに関して、他のグラフィックス更新は、依然として信頼できるように送られるが、今度は、ＦＥＣを使用するためにトランスポートドライバ５９に命令するＱｏＳパラメータとともにＲｅｌｉａｂｌｅ ＶＣ Ｗｒｉｔｅインターフェースを使用して送られる。ＦＥＣが失敗する場合、ＥＤＴトランスポートは、ＦＥＣなしに信頼できるように送られる任意の他のパケットのように自動的に再送信を処理する。グラフィックスモジュールは、パケットの状態を問い合わせることに関係せず、すなわち、チケットは与えられる必要がない。

ＦＥＣの使用をトリガするロス率およびレイテンシのしきい値は、信頼できる送信対非可逆送信で異なり得ることに留意されたい。たとえば、しきい値は、信頼できる送信の場合により高くなることができる。さらに、たとえば、ＣＰＵおよびメモリとのトレードオフを仮定すると、ＱｏＳパラメータはまた、異なる構成に使用するために異なるＦＥＣアルゴリズムを暗示し得る。さらに、信頼できる送信と非可逆送信との両方のための要求されたＦＥＣの程度は、以下でさらに詳細に説明されるように、入力の数による。

別の最適化技法は、適用されるべきＦＥＣの程度または積極性を決定するための入力に関する。ロスに関して、より高い平均割合ロスおよびロスのより高い標準偏差のためにより高いＦＥＣが使用され得る。レイテンシに関して、ロスと組み合わせてより高いレイテンシのためにより高いＦＥＣが使用され得る。帯域幅に関して、より高い推定された帯域幅のためにより高いＦＥＣが使用され得る。

さらに、グラフィックスデータの重要性も考慮に入れられ得る。より詳細には、より重要なデータのためにより高いＦＥＣが使用され得る。たとえば、より重要なデータは、ビデオのキーフレーム、クライアントキャッシュに大きいビットマップを追加すること、クライアントキャッシュからビットマップを引き出すこと、クライアントキャッシュ中に（テキストのための）グリフを追加すること、クライアントキャッシュからグリフを引き出すこと、塗りつぶし、スクリーンツースクリーンコピー、近接してアクティブに編集されているテキストなどに関係する可能性がある。一方、あまり重要でないグラフィックスデータは、ビデオの中間フレーム、過渡的なビットマップ、アクティブにスクロールされているテキストなどに関係し得る。同様に、グラフィックスデータのサイズ、たとえば、より小さいデータのためにより高いＦＥＣも考慮に入れられ得る。小さいパケットに関して、それらを単に複製するのに最も効率的であり得る。上記のように、他の例は、ビットレート（たとえば、より高いＦＥＣがより小さい予想されるビットレートとともに使用され得る）、サーバ負荷（たとえば、より高いＦＥＣがより多くのスペア容量とともに使用され得る）などを含む。

さらに別のＦＥＣ最適化手法は、周波数、タイプ、および／またはユーザ入力のロケーションに関係する。以下は、高速にタイプ入力し、フォントが大きい、スクロールバーまたはウィンドウタイトルバーのエリアをマウスまたはタッチドラッグすること、ウィンドウ制御領域をクリックまたはタップする（最小化する、最大化する、閉じる）こと、アプリを切り替えるためのａｌｔタブまたは他の組合せなどの例である。これらは、グラフィックス応答からより高い即時ビットレートを示し得る。

別のファクタは、注目するアプリケーションである。たとえば、ウェブブラウザまたはメディアプレーヤは、ワードプロセシングアプリまたは単純なテキストエディタよりも高いビットレートを示し得る。他のファクタは、トップレベルのウィンドウサイズ、表示解像度、およびグラフィックスサブシステムコンシューマモジュール構成（たとえば、フレーム毎秒（ＦＰＳ））を含み得る。

いくつかの実施形態では、機械学習（ＭＬ）のアプリケーションは、ＭＬモデルをトレーニングするために上記の入力を使用して実装され得る。これは、別個の機器にオフロードすることによってリアルタイムで行われ得る。ＭＬモデルが複数の作業負荷で動作されていると、簡略化された静的範囲が、作成され、ビットレートのより効率的でリアルタイムの予測のために使用され得る。

ビットレートに関して、予想されるビットレートが増加する場合、ＦＥＣの程度が減少され、任意選択で、しきい値レベルの上でオフにされ得る。これは、有効なコンテンツビットレートを増加させるが、有効なロスの関連するリスクを伴う。しかしながら、後続の更新が任意の紛失されたグラフィックス更新に取って代わり得るので、これは望ましいことがある。さらに、推定された帯域幅に達し、輻輳を生じるのを回避するために帯域幅の節約が望まれ得る。

一方、予想されるビットレートが減少する場合、ＦＥＣの程度は増加され得る。不十分なパケットがＦＥＣ符号化されたパケットのグループ／バッチを完了するために送信キュー中で利用可能である場合、トランスポートドライバ５９は、遅延を回避するためにダミーパケットを送るか、またはパケットを複製し得る。これは、有効なコンテンツビットレートを減少させるが、ロスのリスクも減少させる。さらに、これは、後続の更新がすぐに予想されない場合に望まれる。さらに、十分な帯域幅が予想され得る。

予想されるビットレートしきい値レベルを下回る場合、グラフィックスコンシューマモジュールは、高品質の更新を送り得る。たとえば、ユーザ入力が停止し、それ以上の変化が予想されない場合、「最終の／シャープな」画像が送られ得る。現在の「ロスレス向けに構築された」システムは、検出された変化が停止するとき高品質の更新を送り、これは、常にある程度の遅延を伴い、双方向性を損なう。ユーザ入力などのヒントを使用することにより、システム９０は、高品質の更新をすぐに送る必要を検出することが可能になり、双方向性を改善する。高品質の更新は、たとえば、ＦＥＣを用いて信頼できるように送られ得る。

さらに図１１の流れ図２１０を参照すると、システム９０に関する関連する方法態様について次に説明する。ブロック２１１から始まり、本方法は、ブロック２１２において、フレームバッファ９５を介してクライアントコンピューティングデバイス９４にリモートで表示されるべき仮想コンピューティングセッション９３を仮想化サーバ９１においてホストすることを例示的に含む。本方法は、ブロック２１３において、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比に基づいて仮想化サーバ９１においてフレームバッファ９５内のグラフィカルコンテンツのためのＦＥＣデータを生成することと、ＧＵＩ９６内での表示のために仮想チャネル９７を介して仮想化サーバからクライアントコンピューティングデバイス９４にグラフィカルコンテンツと関連するＦＥＣデータとを送ることとをさらに例示的に含む。本方法はまた、上記でさらに説明されたように、ブロック２１４において仮想チャネル９７に関連するＱｏＳパラメータを決定することと、ブロック２１５、２１６において、ＱｏＳパラメータの変化に基づいて仮想化サーバ９１においてＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比を選択的に変更することとを例示的に含む。

図１２～図１３を参照して、拡張グラフィックスレンダリング能力を与えるためにユーザ入力データに優先度を付け、分割し、異なる仮想チャネルにわたってそれを送ることに関する別の例示的な実施形態について次に説明する。コンピューティングシステム２２０は、上記で説明されたように、仮想コンピューティングセッション２２３をホストするように構成された仮想化サーバ２２１と、ＧＵＩ２２６内の仮想コンピューティングセッションをレンダリングするように構成されたクライアントコンピューティングデバイス２２４とを例示的に含む。クライアントコンピューティングデバイス２２４は、１つまたは複数のユーザ入力デバイス２３１から仮想コンピューティングセッションに関連するユーザ入力データのストリームを受信することと、第１のデータパケットおよび第２のデータパケットにストリームを分類することとを行うように構成されたプロセッサ２３０を例示的に含む。

より詳細には、第１のデータパケットは、第２のデータパケットよりも高い優先度を有する。プロセッサ２３０はまた、第１の（たとえば、信頼できる）仮想チャネル２２８を介して仮想化サーバ２２１に第１の（すなわち、高優先度のまたは重要な）データパケットを送り、第１の仮想チャネル（たとえば、非可逆チャネル）よりも高いそれに関連するパケットロス率を有する第２の仮想チャネル２２９を介して仮想化サーバに第２の（より低い）データパケットを送るように構成される。仮想化サーバ２２１は、第１のデータパケットに基づいてユーザ入力データのストリームを再構成し、それを仮想コンピューティングセッション２２３に注入するために第２のデータパケットを組み立てるように構成されたプロセッサ２２２を例示的に含む。

図１３に示す例では、データパケット１からＮのストリングがユーザ入力のストリーム中に含まれ、第１のデータパケット（ここで、パケット１およびＮ）は、それぞれ、ユーザ入力データのストリームの開始および終了パケットである。第２のデータパケットは、第１のパケットと最後のパケットとの中間のパケット、すなわち、パケット２からＮ－１である。このようにして、第１のデータパケットは、有利には、ユーザ入力データのストリーム内の基準のポイントまたはアンカーポイントを定義し、クライアントコンピューティングデバイス２２４は、（たとえば、開始パケットがパケット１であり、終了パケットがパケットＮである）アンカーポイントへの参照とともに第２の仮想チャネル２２９を介して仮想化サーバ２２１に第２のデータパケットを送り得る。したがって、プロセッサ２２２は、有利には、アンカーポイント（すなわち、それぞれ、開始および終了データパケット１およびＮ）への参照に基づいてユーザ入力データのストリームを再構成し、それを仮想コンピューティングセッション２２３に注入するために第２のデータパケット（すなわち、パケット２からＮ－１）を組み立て得る。異なる実施形態では、高優先度パケットを選択し、これらのパケットを参照するための他の手法が使用され得ることに留意されたい。

いくつかの例示的な実施形態では、プロセッサ２３０はまた、所望される場合、第１のチャネル２２８を介した通信が遅延される場合に冗長性を与え、ユーザ入力データストリームのより速い再構成を保証するのを助けるために第１のデータチャネル２２８だけでなく第２の仮想チャネル２２９を介して第１のデータパケットのうちの１つまたは複数を送るようにさらに構成され得る。また、上記でさらに説明されたように、プロセッサ２３０はまた有利には、所望される場合、送るより前に第１のデータパケットおよび第２のデータパケットにＦＥＣを適用し、さらに、データパケットロス中のスパイクなどに基づいて第１のデータパケットおよび第２のデータパケットの一方または両方に適用されるＦＥＣのレベルを選択的に変更し得る。

上位入力のストリームを作成するユーザ入力イベントは、様々な異なるタイプのユーザ入力デバイス２３１から来るものであり得る。たとえば、ユーザ入力デバイス２３１がキーボードである場合、第１のデータパケットは、キーボードを介したキーボードイベント入力に対応し得る。ユーザ入力デバイス２３１がタッチスクリーンである場合、たとえば、第１のデータパケットは、タッチスクリーンを介したタッチアップおよびタッチダウンイベント（たとえば、指がディスプレイにタッチするかまたはそれから離されるときの）入力に対応し得、一方、第２のデータパケットは、タッチスクリーンを介したタッチムーブイベント（たとえば、ディスプレイにタッチしている指がディスプレイに沿って移動されるときの）入力に対応し得る。ユーザ入力デバイス２３１がマウスである別の例示的な実施形態では、第１のデータパケットは、マウスを介したマウスボタンアップおよびマウスボタンダウンイベント（たとえば、マウスボタンが押下されるかまたは解放されることの）入力に対応し得、一方、第２のデータパケットは、マウスを介したマウスドラッグ（たとえば、マウスボタンが保持され、および／またはポインタが移動される）またはマウスホイールイベント（たとえば、マウスホイールがスクロールアップまたはダウンされる）入力に対応し得る。ユーザ入力デバイス２３１が電子ペンまたはスタイラスであるさらに別の例示的な実施形態では、第１のデータパケットは、電子ペンを介したペンアップおよびペンダウンイベント（たとえば、電子ペンがディスプレイにタッチするかまたはそれから離されるときの）入力に対応し得、一方、第２のデータパケットは、電子ペンを介したペンドラッグイベント（たとえば、電子ペンがディスプレイにタッチし、ポイントがディスプレイに沿って移動されるときの）入力に対応し得る。しかしながら、異なる実施形態では、第１の（高優先度の）データパケットおよび第２の（より低い優先度の）データパケットの他の入力デバイスおよび指定が使用され得ることに留意されたい。

前述は、様々な実装例を参照してさらに理解されよう。ここで再度、これらの例示的な実装形態は、図５に示されるフレームワークのコンテキストで与えられるが、これらの技法は、同様に他の仮想化アーキテクチャ内に適用され得る。ロスおよびレイテンシのいくつかのしきい値を上回る場合、使用され得る１つ手法は、重要な入力イベント、たとえば、キーボードイベント、タッチダウン、タッチアップ、マウスボタンダウン、マウスボタンアップなどを信頼できるように送ることである。さらに、あまり重要でない入力イベント、たとえば、タッチムーブ、マウスドラッグ、マウスホイール、ペンドラッグは、非可逆的な方法で送られる。さらに、帯域幅への影響は無視できるものになるが、冗長性は、ロスおよびレイテンシの条件における滑らかなユーザエクスペリエンスを保証することになるので、ＦＥＣまたは単純なパケットの複製は、任意選択で、信頼できるユーザ入力の送信と非可逆的なユーザ入力の送信との一方または両方に適用され得る。これは、上記で説明された低い予想されるビットレート、小さいデータサイズおよび重要なデータファクタに一致する。

上記のように、ユーザ入力は、優先度を付けられ、重要な入力（パケット）と重要でない入力（パケット）とに分類され、それぞれ、信頼できるストリーム２２８と信頼できない（非可逆）ストリーム２２９とを介して送られ得る。信頼できるストリームと非可逆ストリームとは、独立しており、非同期であるので、信頼できる入力パケット対非可逆入力パケットはホストにおいて順不同で受信され得、これは、ユーザ入力のセマンティクスを破壊し得る。したがって、重要でない非可逆パケットごとに、クライアントコンピューティングデバイス２２４は、シーケンス番号によってあらかじめ必要で重要な信頼できるパケットを識別し得る。これは、パケット形成のときにクライアントコンピューティングデバイス２２４において指定される。重要なパケットは、入力シーケンスの「始まり」、たとえば、ドラッグを始める前のマウスダウンを識別し得る。

非可逆パケットは、ホストにおいてキャッシュされ、それぞれの重要であらかじめ必要なパケットも受信されるまで再生されないことがある（ホストされたアプリ／デスクトップに注入されないことがある）。シーケンスを「終わらせる」重要なパケット、たとえば、マウスボタンアップが受信されると、その後受信され、今は「終わった」必要条件を参照し得るあらゆる重要でない非可逆パケットは破棄される。たとえば、これは、シーケンスを終わらせるマウスボタンアップが受信された後に受信された場合に破棄され得るマウスドラッグで発生し得る。

機会主義的に重要な入力は、いくつかの実装形態では、信頼できるストリームと非可逆ストリームとの両方を介して送られ得る。これは、信頼できるパケットと非可逆パケットとを伴う入力シーケンスが開始するときにホスト側での潜在的な同期ラグをさらに低減する。たとえば、マウスダウンイベントは、信頼できるトランスポートと非可逆トランスポートとの両方を介して送られ得る。上記で説明されたように、マウスドラッグは、対応するシーケンスを開始するマウスダウンが最初に受信される前にホストにおいて保持される。有利には、マウスダウンはマウスドラッグとともに必要条件として配信される場合、ホストは、入力シーケンスを直ちに再生／注入し始めることができる。これは、たとえば、信頼できるストリームと非可逆ストリームとが別様にルーティングされる場合、異なるＱｏＳがトランジットの間にそれらに適用される場合、および／またはパケットが他の理由のために順不同で到着する傾向がある場合に有用であり得る。

追加のＦＥＣが、ロス中のスパイクを処理するために同様にある程度の遅延とともに実行され得る。この追加のＦＥＣ（またはパケットの複製）が適用される遅延は、ロスのスパイクの持続時間の平均または標準偏差のうちの少なくとも１つに基づいて計算され得る。現代のネットワークでは、ロスのスパイクは、たとえば、確率干渉により発生し得、ここで、損失は、拡散するのではなく連続し、平均ロス割合に一致する。たとえば、５％の平均パケットロスをもつネットワークでは、ロスが２秒の持続時間の間５０％にあるロスのスパイクがあり得る。したがって、最初のＦＥＣが大きく、５％のパケットロスをカバーするのに十分であり得るが、スパイク中の２０％の損失をカバーすることは不十分であり得る。したがって、２秒後に追加のＦＥＣ（または複製）を適用することは、場合によっては遅延を伴うが、パケットが配信されるチャンスを改善することになる。連続適用は、スパイクと重なり得るので、これは追加のＦＥＣを連続的に適用するよりも良好であり得る。

ＦＥＣの調節またはスロットリングは、上記で説明された手法と同様の手法を使用して実行され得る。たとえば、クライアントコンピューティングデバイス２２４は、単語または文のタイピングを監視し、不完全な句または文法を検出して、高いレベルの信頼性で追加の即時のユーザ入力を決定（予期）し得る。言い換えれば、クライアントコンピューティングデバイス２２４は、不完全な単語または文を予測し、それに応じてＦＥＣの程度（たとえば、より途切れた単語／文のためにより大きいＦＥＣ）をチューニングし得る。

入力のサイズが一般に小さい場合、ＦＥＣは、帯域幅およびＣＰＵに対して無視できる影響しか有しないが、信頼できる非可逆送信と組み合わせると、双方向性に対して有意な影響を有する。テスト結果およびデモビデオは、５％のパケットロスで３００ｍｓのＲＴＴで実行された。ＥＤＴ高信頼トランスポート単独を介した同じ対話に対してウィンドウの移動、スクロール、ペイントおよび他のタイプの対話で約３倍の双方向性の改善が達成された。

ＦＥＣは、いくつかの実施形態では、対話型トラフィックのみ、たとえば、上記で説明されたＴｈｉｎｗｉｒｅグラフィックスと同様のリアルタイムオーディオまたはマルチメディアＶＣに適用され得る。バルクデータ転送ＶＣ、たとえば、クライアントドライブマッピング（ＣＤＭ ＶＣは、一般に、ＦＥＣを要求するＱｏＳの利益を使用する必要はなく、したがって、帯域幅への影響を最小化するが、ＦＥＣは、たとえば、追加の帯域幅の使用を犠牲にしてリモートファイル転送の速度を増加させることが所望される場合に、いくつかの実施形態で同様に使用され得る。

図１４の流れ図１４０を参照して、システム２２０に関する方法態様について次に説明する。ブロック１４１において始まり、本方法は、ブロック１４２において、仮想化サーバ２２１からクライアントコンピューティングデバイス２２４において仮想コンピューティングセッション２２３にリモートでアクセスすることと、ブロック１４３において、クライアントコンピューティングデバイス２２４において仮想コンピューティングセッションに関連するユーザ入力データのストリームを受信し、第１のデータパケットおよび第２のデータパケットにストリームを分類することとを例示的に含む。上記のように、第１のデータパケットは、第２のデータパケットよりも高い優先度を有する。本方法はまた、ブロック１４４において、第１の仮想チャネル２２８を介してクライアントコンピューティングデバイス２２４から仮想化サーバ２２１に第１のデータパケットを送ることと、ブロック１４５において、第１の仮想チャネルよりも高いそれに関連するパケットロス率を有する第２の仮想チャネル２２９を介してクライアントコンピューティングデバイスから仮想化サーバに第２のデータパケットを送ることとを例示的に含む。したがって、仮想化サーバ２２１は、上記でさらに説明されたように、有利には、第１のデータパケットに基づいてユーザ入力データのストリームを再構成し、それを仮想コンピューティングセッション２２３に注入するために第２のデータパケットを組み立て得る。図１４の方法は、ブロック１４６において例示的に終わる。

上記の説明および関連する図面で提示する教示の利益を有する当業者は、多くの変更および他の実施形態を思い浮かぶであろう。したがって、上記は、例示的な実施形態に限定されるものではなく、変更および他の実施形態が、添付の特許請求の範囲に含まれるものとすることを理解されたい。

Claims (21)

1. メモリと、
   フレームバッファを介してクライアントデバイスにリモートで表示されるべき仮想コンピューティングセッションをホストすることであって、前記クライアントデバイスは、グラフィカルユーザインターフェース（ＧＵＩ）を介して前記仮想コンピューティングセッションをレンダリングするように構成される、ホストすることと、
   前方誤り訂正（ＦＥＣ）帯域幅に対するグラフィカルコンテンツ帯域幅の比に基づいて前記フレームバッファ内のグラフィカルコンテンツのためのＦＥＣデータを生成することと、
   少なくとも１つの仮想チャネルに関連するサービス品質（ＱｏＳ）パラメータを決定することと、
   前記ＱｏＳパラメータの変化および前記フレームバッファ内のグラフィカルコンテンツデータの優先度に基づいてＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を調整することと、
   前記ＧＵＩ内での表示のために前記少なくとも１つの仮想チャネルを介して前記クライアントデバイスに前記グラフィカルコンテンツと前記調整されたＦＥＣデータとを送ることと
   を行うように前記メモリと協働するプロセッサと
   を備えるコンピューティングデバイス。
2. 前記クライアントデバイスに送られた前記グラフィカルコンテンツは、パケットに分割され、前記ＱｏＳパラメータは、パケットロス率を備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、前記パケットロス率が増加するにつれて減少する請求項１に記載のコンピューティングデバイス。
3. 前記プロセッサは、前記少なくとも１つの仮想チャネルの全体的な帯域幅を変更することなしにＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を調整する請求項１に記載のコンピューティングデバイス。
4. 前記少なくとも１つの仮想チャネルは、信頼できるチャネルと非可逆チャネルとを備え、前記信頼できるチャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、前記非可逆チャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比より高い請求項１に記載のコンピューティングデバイス。
5. 前記ＱｏＳパラメータは、ネットワークレイテンシを備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、ネットワークレイテンシが増加するにつれて減少する請求項１に記載のコンピューティングデバイス。
6. 前記ＱｏＳパラメータは、前記少なくとも１つの仮想チャネルのための推定された帯域幅を備える請求項１に記載のコンピューティングデバイス。
7. 前記ＱｏＳパラメータは、前記少なくとも１つの仮想チャネルに関連する予想されるビットレートを備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、前記予想されるビットレートが減少するにつれて減少する請求項１に記載のコンピューティングデバイス。
8. 前記ＱｏＳパラメータは、前記コンピューティングデバイスに関連する負荷を備える請求項１に記載のコンピューティングデバイス。
9. 前記プロセッサは、前記フレームバッファ内の前記グラフィカルコンテンツデータのサイズに基づいてＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を選択的に変更するようにさらに構成された請求項１に記載のコンピューティングデバイス。
10. フレームバッファを介してクライアントデバイスにリモートで表示されるべき、サーバにおいてホストされる仮想コンピューティングセッションについて、前記クライアントデバイスが、グラフィカルユーザインターフェース（ＧＵＩ）を介して前記仮想コンピューティングセッションをレンダリングするように構成された状態で、前方誤り訂正（ＦＥＣ）帯域幅に対するグラフィカルコンテンツ帯域幅の比に基づいて前記サーバが前記フレームバッファ内のグラフィカルコンテンツのためのＦＥＣデータを生成するステップと、
    少なくとも１つの仮想チャネルに関連するサービス品質（ＱｏＳ）パラメータを決定するステップと、
    前記ＱｏＳパラメータの変化および前記フレームバッファ内のグラフィカルコンテンツデータの優先度に基づいて前記サーバにおいてＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を調整するステップと、
    前記ＧＵＩ内でのレンダリングのために少なくとも１つの仮想チャネルを介して前記サーバから前記クライアントデバイスに前記グラフィカルコンテンツと関連するＦＥＣデータとを送るステップと
    を備える方法。
11. 前記クライアントデバイスに送られた前記グラフィカルコンテンツは、パケットに分割され、前記ＱｏＳパラメータは、パケットロス率を備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、前記パケットロス率が増加するにつれて減少する請求項１０に記載の方法。
12. 選択的に変更するステップは、前記少なくとも１つの仮想チャネルの全体的な帯域幅を変更することなしにＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を調整するステップを備える請求項１０に記載の方法。
13. 前記少なくとも１つの仮想チャネルは、信頼できるチャネルと非可逆チャネルとを備え、前記信頼できるチャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、前記非可逆チャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比より高い請求項１０に記載の方法。
14. 前記ＱｏＳパラメータは、ネットワークレイテンシを備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、ネットワークレイテンシが増加するにつれて減少する請求項１０に記載の方法。
15. フレームバッファを介してリモートで表示されるべき仮想コンピューティングセッションをホストするように構成されたサーバと、
    前記サーバから前記仮想コンピューティングセッションにリモートでアクセスすることと、グラフィカルユーザインターフェース（ＧＵＩ）を介して前記仮想コンピューティングセッションをレンダリングすることとを行うように構成されたクライアントデバイスと
    を備え、
    前記サーバは、
    前方誤り訂正（ＦＥＣ）帯域幅に対するグラフィカルコンテンツ帯域幅の比に基づいて前記フレームバッファ内のグラフィカルコンテンツのためのＦＥＣデータを生成することと、
    少なくとも１つの仮想チャネルに関連するサービス品質（ＱｏＳ）パラメータを決定することと、
    前記ＱｏＳパラメータの変化および前記フレームバッファ内のグラフィカルコンテンツデータの優先度に基づいてＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を調整することと、
    前記ＧＵＩ内での表示のために前記少なくとも１つの仮想チャネルを介して前記クライアントデバイスに前記グラフィカルコンテンツと前記調整されたＦＥＣデータとを送ることと
    を行うようにさらに構成されたコンピューティングシステム。
16. 前記クライアントデバイスに送られた前記グラフィカルコンテンツは、パケットに分割され、前記ＱｏＳパラメータは、パケットロス率を備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、前記パケットロス率が増加するにつれて減少する請求項１５に記載のコンピューティングシステム。
17. 前記サーバは、前記少なくとも１つの仮想チャネルの全体的な帯域幅を変更することなしにＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比を調整する請求項１５に記載のコンピューティングシステム。
18. 前記少なくとも１つの仮想チャネルは、信頼できるチャネルと非可逆チャネルとを備え、前記信頼できるチャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、前記非可逆チャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比より高い請求項１５に記載のコンピューティングシステム。
19. 前記ＱｏＳパラメータは、ネットワークレイテンシを備え、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の前記比は、ネットワークレイテンシが増加するにつれて減少する請求項１５に記載のコンピューティングシステム。
20. サーバでホストされている仮想コンピューティングセッションを、グラフィカルユーザーインターフェース（ＧＵＩ）を介して前記仮想コンピューティングセッションをレンダリングするように構成されたクライアントデバイスにフレームバッファを介してリモートで表示する場合、前記サーバが、信頼できる仮想チャネルについての前方誤り訂正（ＦＥＣ）帯域幅に対するグラフィカルコンテンツ帯域幅の第１の比、および非可逆の仮想チャネルについてのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の第２の比に基づいて前記フレームバッファ内のコンテンツに対するグラフィカルなＦＥＣデータを生成するステップと、
    前記信頼できる仮想チャネルと前記非可逆の仮想チャネルとに関連付けられたサービス品質（ＱｏＳ）パラメータを決定するステップと、
    前記ＱｏＳパラメータの変更に基づいて、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の第１および第２の比を調整するステップと、
    前記ＧＵＩ内に表示するために、前記信頼できる非可逆の仮想チャネルを介してグラフィカルコンテンツおよび調整された前記ＦＥＣデータを前記クライアントデバイスに送信するステップと
    を含み、前記信頼できる仮想チャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比は、前記非可逆の仮想チャネル上でのＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比よりも高い、方法。
21. サーバでホストされている仮想コンピューティングセッションを、グラフィカルユーザーインターフェース（ＧＵＩ）を介して前記仮想コンピューティングセッションをレンダリングするように構成されたクライアントデバイスにフレームバッファを介してリモートで表示する場合、前記サーバが、前方誤り訂正（ＦＥＣ）帯域幅に対するグラフィカルコンテンツ帯域幅の比に基づいて前方フレームバッファ内のグラフィカルコンテンツに対するＦＥＣデータを生成するステップと、
    少なくとも１つの仮想チャネルに関連付けられたサービス品質（ＱｏＳ）パラメータを決定するステップと、
    前記ＱｏＳパラメータの変更と前記フレームバッファ内のグラフィカルコンテンツデータのサイズとに基づいて、ＦＥＣ帯域幅に対するグラフィカルコンテンツ帯域幅の比を調整するステップと、
    前記ＧＵＩ内に表示するために、前記グラフィカルコンテンツおよび調整された前記ＦＥＣデータを、前記少なくとも１つの仮想チャネルを介して前記クライアントデバイスに送信するステップと
    を含む、方法。

Images