JP6164747B2 - 協働環境におけるフロー制御のためのおよび信頼性のある通信のための方法 - Google Patents

Description

サービス、アプリケーションプログラム、およびデータに対する遍在する遠隔アクセスは、ブロードバンドならびにワイヤレスネットワークアクセスの成長および可用性によって、当たり前のものとなった。そのように、ユーザは、増え続けている種々のクライアントデバイス（例えば、モバイルデバイス、テーブルコンピューティングデバイス、ラップトップ／ノートブック／デスクトップコンピュータなど）を使用してアプリケーションプログラムおよびデータにアクセスする。データは、３Ｇおよび４Ｇモバイルデータネットワーク、例えばＷｉＦｉおよびＷｉＭａｘのようなワイヤレスネットワーク、有線ネットワークなどを含む種々のネットワーク上で、遠隔サーバからデバイスに通信され得る。クライアントは、多くの異種のネットワーク帯域幅や待ち時間で、サービス、アプリケーションプログラムおよびデータを提供するサーバに接続し得る。しかしながら、サービスは、通常、高帯域幅で短い待ち時間の専用接続によって、サーバに接続されていた。

多くのクライアントを、例えばサーバを通して１つのサービスに、接続するための全二重通信を効果的に使用するために、フロー制御機構が必要とされる。サービスとサーバとの間およびクライアントとサーバとの間の帯域幅の大きな差異は、サービスの実装への難題をもたらすものであり、それは、各クライアントの接続の限度および能力に従って、適時の情報を各クライアントに提供することができなければならない。

本明細書において開示されるものは、遠隔アクセスシステムにおけるフロー制御を提供するためのシステムおよび方法である。方法は、クライアントデバイスにおいてクライアントレイヤを提供することと、サービスと関連付けられたサービスレイヤであって、クライアントデバイスから受信されるメッセージのためのサービス受信キューと、クライアントデバイス行きのメッセージのサービス送信キューとを有するサービスレイヤを提供することと、クライアントデバイスとサービスとの間に送信されるメッセージのための通信プロキシとして、クライアントデバイス行きのメッセージのアウトバウンドクライアントキューを含むサーバレイヤを提供することと、サービス送信キューにおけるメッセージをクライアントデバイスへの伝送のためにサーバレイヤに送信するように制御信号をサービスレイヤに通信することとを含み得る。

いくつかの実施態様によれば、回復可能な（信頼性のある）通信を提供する方法であって、ネットワーク接続でアプリケーションに遠隔的にアクセスするクライアントレイヤを提供することと、クライアントレイヤとアプリケーションとの間の通信を代理するサーバレイヤを提供することと、クライアントレイヤとサーバレイヤとの間の通信のために第１のチャネルにサービスプロトコルを実装することによって、およびサーバレイヤとクライアントレイヤとの間の通信のために第２のチャネルにサービスプロトコルを実装することによって、クライアントレイヤとサーバレイヤとの間の全二重通信を容易にすることと、第１のチャネルまたは第２のチャネル上の通信の失敗を検出することと、第１のチャネルまたは第２のチャネル上の失敗を検出すると、サービスプロトコルを使用して通信を再確立することと、を含む、方法が提供される。

更に他の実施態様によれば、コンピュータで読み取り可能な媒体の上にコンピュータで実行可能な命令を有する当該コンピュータで読み取り可能な媒体であって、コンピュータで実行可能な命令がコンピューティングデバイスのプロセッサによって実行されると、サービスと関連付けられたサービスレイヤであって、クライアントデバイスから受信されるメッセージのためのサービス受信キューと、クライアントデバイス行きのメッセージのサービス送信キューとを有するサービスレイヤを提供することと、クライアントデバイスとサービスとの間に送信されるメッセージのための通信プロキシとして、クライアントデバイス行きのメッセージのアウトバウンドクライアントキューを含むサーバレイヤを提供することと、サービス送信キューにおけるメッセージをクライアントデバイスへの伝送のためにサーバレイヤに送信するように制御信号をサービスレイヤに通信することと、を含む方法を機能させる、コンピュータで読み取り可能媒体が、提供される。

以下の図面および詳細な説明を検討することによって、当業者には他のシステム、方法、特徴および／または利点が明らかとなる、あるいは明らかになり得る。すべてのそのような追加のシステム、方法、特徴および／または利点は、この説明に含まれ、添付のクレームによって保護されることが意図される。

図面における構成要素は、必ずしも互いに対して一定の縮尺であるとは限らない。同様の参照番号は、いくつかの図面を通して対応する部分を示している。

コンピュータネットワークを介して、遠隔デバイスにおけるアプリケーションに対する遠隔アクセスを提供するためのシステムを例示する、簡略化されたブロック図である。 遠隔アクセスプログラムの動作を例示する、簡略化されたブロック図である。 本開示に従う層状アーキテクチャを例示する。 １つのサービスに通信する複数クライアントの多対一関係を例示する、本開示に従う別の層状アーキテクチャを例示する。 図１〜図２、図３Ａおよび図３Ｂのシステム内で機能される動作例のフロー図を例示する。 図１〜図２、図３Ａおよび図３Ｂのシステム内で機能される動作例のフロー図を例示する。 例示的なコンピューティングデバイスを例示する。

特に定義されない限り、本明細書において使用されるすべての技術的および科学的な用語は、本開示が属する技術の当業者によって一般的に理解されるものと同一の意味を有する。本明細書において説明されるものと類似または同等とみなされる方法および用具は、本開示の実施または実験において使用され得る。実施態様は、アプリケーションに遠隔的にアクセスすることについて説明されることになるが、実施態様はそれに限定されるものではなくて、遠隔デバイスを介して任意の種類のデータまたはサービスに遠隔的にアクセスすることに適用可能であることが、当業者に明らかになるであろう。

図１を参照すると、コンピュータネットワークを介してアプリケーション、データまたは他のサービスに対する遠隔アクセスを提供するためのシステム１００。システムは、例えば、インターネット等のようなコンピュータネットワーク１１０を介してサーバ１０２Ｂに接続された、例えば、ＩＰＨＯＮＥ１１２ＡまたはＢＬＡＣＫＢＥＲＲＹ１１２Ｂ等のようなワイヤレス手持ち型デバイス等の、クライアントコンピュータ１１２Ａまたは１１２Ｂを備える。同様に、クライアントコンピューティングデバイスはまた、通信ネットワーク１１０によってサーバ１０２Ｂに接続されるデスクトップ／ノートブックパーソナルコンピュータ１１２Ｃまたはタブレットデバイス１１２Ｎを含み得る。通信ネットワーク１１０への接続は、任意の種類の接続、例えば、Ｗｉ‐Ｆｉ（ＩＥＥＥ８０２．１１ｘ）、ＷｉＭａｘ（ＩＥＥＥ８０２．１６）、イーサネット（登録商標）、３Ｇ、４Ｇなどとすることができることに留意する。

サーバ１０２Ｂは、例えば、コンピュータネットワーク１１０を介してローカルエリアネットワーク（ＬＡＮ）１０９に接続されるか、あるいは、コンピュータネットワーク１１０に直接的に接続されてもよい。例えば、ＬＡＮ１０９は、病院、銀行、大企業、または政府機関等のような施設の内部コンピュータネットワークである。典型的には、そのような施設は依然として、ＬＡＮ１０９に接続されたメインフレームコンピュータ１０２Ａおよびデータベース１０８を使用する。多くのアプリケーションプログラム１０７Ａは、メインフレームコンピュータ１０２Ａのメモリ１０６Ａ内に格納され得、プロセッサ１０４Ａ上で実行され得る。同様に、多くのアプリケーションプログラム１０７Ｂは、サーバ１０２Ｂのメモリ１０６Ｂ内に格納され得、プロセッサ１０４Ｂ上で実行され得る。本明細書において使用される際、アプリケーションプログラム１０７Ａおよび１０７Ｂは、遠隔アクセスのために提供される「サービス」であり得る。メインフレームコンピュータ１０２Ａ、サーバ１０２Ｂおよびクライアントコンピュータ１１２Ａ、１１２Ｂ、１１２Ｃまたは１１２Ｎは、図６の汎用コンピューティングデバイスに示されるものなどのハードウェアを使用して実装され得る。

クライアント遠隔アクセスプログラム１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｎは、それぞれ、例えば、クライアントコンピュータ１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎのタッチスクリーン１１４Ａまたはグラフィックディスプレイ１１４Ｂ／１１４Ｎおよびキーボード１１６Ｂ／１１６Ｃを用いたグラフィックディスプレイを使用してアプリケーションプログラムと相互に作用するための、受信したユーザ命令に従って、人が理解できる様式でデータおよび／または画像を表示するため、また、ユーザ入力データを決定するために、ユーザとの相互作用を提供するために設計されてもよい。例えば、クライアント遠隔アクセスプログラムは、実行可能なコマンドをプロセッサ１１８Ａ、１１８Ｂ、１１８Ｃ、１１８Ｎ上で実行することによって機能し、これらのコマンドは、クライアントコンピュータ１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎのメモリ１２０Ａ、１２０Ｂ、１２０Ｃ、１２０Ｎにそれぞれ格納される。あるいは、ユーザインターフェースプログラムは、（アプリケーションプログラム１０７Ｂの１つとして）サーバ１０２Ｂ上で実行され、そのサーバは、さらにまた、例えば、クライアントコンピュータ１１２Ａ、１１２Ｂ上で実行されるウェブブラウザ等のような一般的なクライアントアプリケーションによって、ＵＲＬを介してアクセスされる。ユーザインターフェースは、例えば、ハイパーテキストマークアップ言語ＨＴＭＬ５を使用して実装される。

クライアント遠隔アクセスプログラム１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｎと共にサーバ遠隔アクセスプログラム１１１Ｂの動作は、図２に例示されるように、状態モデルと協働して機能し得る。実行されると、クライアント遠隔アクセスプログラム１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｎは、ユーザインターフェースプログラムから受信したユーザ入力データに従って状態モデルを更新する。遠隔アクセスプログラム１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｎは、更新された状態モデルに従って制御データを生成し得、サーバ１０２Ｂ上で動いているサーバ遠隔アクセスプログラム１１１Ｂに同一のものを提供する。

アプリケーションプログラム１０７Ａまたは１０９７Ｂからアプリケーションデータを受信すると、サーバ遠隔アクセスプログラム１１１Ｂは、スクリーンまたはアプリケーションデータに従って状態モデルを更新し、更新された状態モデルに従って表現データを生成し、同一のものをクライアントコンピューティングデバイス上のクライアント遠隔アクセスプログラム１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｎに提供する。状態モデルには、アプリケーションプログラムの論理要素の、アプリケーションプログラムの対応する状態との関連付けが含まれ、論理要素は、階層的順序にある。例えば、論理要素は、アプリケーションプログラムユーザインターフェースを構成する、スクリーン、メニュー、サブメニュー、ボタンなどであり得る。これは、クライアントデバイスが、例えば、論理要素をネイティブに表示することを可能にする。そのように、移動電話上に提示されるアプリケーションプログラムのメニューは、移動電話のネイティブメニューのように見えることになる。同様に、デスクトップコンピュータ上に提示されるアプリケーションプログラムのメニューは、デスクトップコンピュータオペレーティングシステムのネイティブメニューのように見えることになる。

状態モデルは、それぞれの論理要素がアプリケーションプログラム１０７Ａまたは１０７Ｂの対応する状態に関連付けられるように決定される。状態モデルは、論理要素がユーザとの相互作用に関連付けられるように決定されてもよい。例えば、アプリケーションプログラムの論理要素は、論理要素が遷移要素を含むように決定され、それぞれの遷移要素は、状態モデルの変更を、制御データおよびそれに関連付けられたアプリケーション表現データのうちの１つに関連付ける。

いくつかの実施態様では、クライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ…１１２Ｎの２つ以上は、アプリケーションプログラム１０７Ａまたは１０７Ｂと協働的に相互作用し得る。そのように、協働セッションに関与するクライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ…１１２Ｎのそれぞれと、メインフレームコンピュータ１０２Ａまたはサーバ１０２Ｂとの間で状態情報を通信することによって、関与するクライアントコンピューティングデバイス１１２Ａ、１１２Ｂ、１１２Ｃ…１１２Ｎのそれぞれは、アプリケーションプログラム１０７Ａまたは１０７Ｂの表示の同期されたビューを提示し得る。

図３Ａは、本開示に従う層状アーキテクチャを例示する。層状アーキテクチャは、フロー制御処理を実装し、その処理は、例えば、サーバ１０２Ｂが、１つ以上のクライアント（１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎなど）をサーバ１０２Ｂを通して１つのサービス１０７Ａまたは１０７Ｂに接続するために全二重通信を効果的に使用することを可能にする。例えば、全二重通信は、クライアント１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎとサーバ遠隔アクセスプログラム１１１Ｂとの間の２つの半二重通信接続３０５を使用することによって実現され得る。そのように、他のクライアントのあるネットワーク接続特性と独立して、クライアントのネットワーク接続特性と合致するように情報の生成を調整するためのサービスについての機構が提供される。

図３Ａに例示されるように、システムには３つのレイヤ、すなわち、クライアントレイヤ３０２、サーバレイヤ３０４およびサービスレイヤ３０６がある。本開示によれば、層状アーキテクチャは、サービスとサーバとの間、サーバと（複数の）クライアントとの間の帯域幅の差異を考慮する。特に、その差異の理由で、サービス３０６は、１つ以上のクライアントについてサーバ１０２Ｂ上に保持されたアウトバウンドメッセージキュー（下記）が、それらが空にされるよりもかなり速く増大するように、各クライアント１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎに対してある速度で非同期的に情報を生成し得る。このことは、キュー内のより古い情報は、より新しい情報の前に伝送される必要があるので、望ましくない実行特性をもたらす可能性がある。クライアントビューはサービスの現在の状態のますます後になるので、このことは、時間が経過し、キュー長が大きくなるにつれ、より問題となる。

クライアントレイヤ３０２は、各クライアント１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎ内に属し、サーバレイヤ３０４に接続するために使用される。典型的には、これは、クライアントアプリケーション１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｎ、例えば、ウェブブラウザ、専用アプリケーションなどを含む。サーバレイヤ３０４は、下記のように、各クライアント１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎからサービスレイヤ３０６への通信を代理する。本開示によれば、各クライアント１１２Ａ、１１２Ｂ、１１２Ｃ、１１２Ｎは固有識別子（例えば、セッションＩＤ）を有する。各クライアントレイヤ３０２は、サーバ１０２Ｂから受信されるメッセージのクライアント受信キュー３１０を含み、それは、サービス（アプリケーション１０７Ａまたは１０７Ｂ）に代わって送信され、クライアントはそのサービスに論理的に接続される。各クライアントレイヤ３０２はまた、それがサーバ１０２Ｂに送信するメッセージのクライアント送信キュー３１２も含み、それは、１つの特定のサービス（例えば、１０７Ｂ）行きのものである。

（例えば、アプリケーション１０７Ａまたは１０７Ｂと関連付けられる）サービスレイヤ３０６のインスタンスはサーバレイヤ３０４に接続し、そのサーバレイヤは、サービスからそのサービスと論理的に関連付けられた各クライアントへの通信を代理する。サービスレイヤ３０６は、サービスが論理的に接続されるすべてのクライアントに代わって、それが、サーバから受信するメッセージのサービス受信キュー３１８を含む。各メッセージは、サーバがクライアントからメッセージを受信したそのクライアントの固有識別子でラベル付けされる。サービスレイヤ３０６はまた、それがサーバ１０２Ｂに送信するメッセージのサービス送信キュー３２０を含む。各メッセージは、サーバ１０２Ｂに論理的に接続されるクライアントの１つだけ行きのものである。サーバ１０２Ｂが一定のコンテンツを各クライアントに送信する必要がある場合、それは、それぞれ論理的に接続されるクライアントのためにそのコンテンツを含むメッセージを作成する。各メッセージは、サーバがメッセージを送信するべきであるクライアントの固有識別子でラベル付けされる。

図３Ｂは、１つのサービスに対する複数クライアントの多対一関係を例示する、本開示に従う別の層状アーキテクチャを例示する。図３Ａのアーキテクチャに類似の要素は、下記では再度説明されない。図３Ｂは、１つのサービス（１０７Ａまたは１０７Ｂ）に通信する２つのクライアント（１１２Ａおよび１１２Ｎ）を例示する。サーバレイヤ３０４は、下記のように、クライアントから、また、サービスから、それぞれ通信を受信するように働くサービスマルチプレクサ３２２およびクライアントデマルチプレクサ３２６を提供することによって、クライアントをサービスレイヤ３０６に多対一関係で論理的に接続する。

図３Ｂにおいて、サーバレイヤ３０４は、クライアントとサービスとの間に送信されるすべてのメッセージのための通信プロキシとして働く。それぞれ接続されたクライアントからのメッセージは、サーバレイヤ３０４におけるサービスマルチプレクサ３２２で受信され、そのサービスマルチプレクサは、メッセージをサーバレイヤ３０４に送信した特定のクライアント１２１Ａまたは１２１Ｎと関連付けられた固有識別子を使用してインバウンドメッセージをラベル付けする。固有識別子は、例えば、セッションＩＤとすることができる。次いで、サービスマルチプレクサ３２２は、メッセージをサービスレイヤ３０６行きのメッセージの単一ストリームに組み合わせる（多重化する）。メッセージの単一ストリームは、まず、受信キュー３１３におけるキューに入れられ得る。

サービスレイヤ３０６がクライアントに通信すると、アウトバウンドメッセージは、サービス送信キュー３２０におけるキューに入れられ、サーバレイヤ３０４におけるクライアントデマルチプレクサ３２６に通信される。クライアントデマルチプレクサ３２６は、メッセージの固有識別子を調べ、メッセージの固有識別子および宛先クライアントデバイスに従って、メッセージを適切なクライアントキュー３１４または３１６に構文解析する。メッセージは、それの各々の半二重通信接続３０５で、クライアントキュー３１４または３１６からクライアント１２１Ａまたは１２１Ｎに通信される。

図３Ｂのアーキテクチャは、複数のクライアントをサービスに対して多対一様式で接続するように記載されるが、アーキテクチャはまた、単一クライアントをサービスに接続することもでき、ここで、サービスマルチプレクサ３２２およびクライアントデマルチプレクサ３２６は、メッセージストリームをクライアントとサービスとの間で、それらの変更無しに、単に渡すことになる。

図４は、図３Ａ、３Ｂのアーキテクチャ内のそれぞれ論理的に接続されるクライアントのためのサービスと関連付けられたメッセージフローを制御する制御信号を提供する動作上のフロー図４００を例示する。最初に、サービスレイヤ３０６は、それぞれ論理的に接続されたクライアントに対して「伝送オフ」状態にある（Ｓ４０２、図４）。すなわち、サービスレイヤ３０６は、論理的に接続されるいかなるクライアントのためのいかなるメッセージも生成しないことになる。サービスレイヤ３０６は、１つのクライアントの固有識別子を含むサーバ１０２Ｂからの「伝送オン」メッセージを受信すると、それは、そのクライアントに対して「伝送オン」状態に入る（Ｓ４０４、図４）。いくつかの実施態様（図４における経路「Ａ」）によれば、所与のクライアントに対して「伝送オン」状態にあると、サービスレイヤ３０６は、そのクライアントのためのすべての未処理メッセージを短い待ち時間、高い帯域幅リンク３０８で、サーバレイヤ３０４に送信することになり、その高い帯域幅リンク３０８はまた、２つの半二重リンクを使用する全二重通信を提供し（Ｓ４０６、図４）、さらにまた、そのクライアントに対して「伝送オフ」状態に入る（Ｓ４０８、図４）。

いくつかの実施態様では、サービスレイヤ３０６はまた、それのサブ構成要素が、任意のクライアントのためにメッセージ遂行要求を非同期的に生成することを可能にする。この実施態様（図４における経路「Ｂ」）において、サービスレイヤ３０６が所与のクライアントに対して「伝送オン」状態に入ると、それは、クライアントのための保留メッセージ遂行要求と関連付けられた新たなメッセージを生成し（Ｓ４０７、図４）、任意の未処理のおよび新たに生成されたメッセージをサーバに送信し（Ｓ４０９、図４）、次いで、そのクライアントに対して「伝送オフ」状態に再度入る（Ｓ４１１、図４）ことになる。

サーバレイヤ３０４が、論理的に接続されたクライアントからメッセージを受信すると、サーバレイヤ３０４は、クライアントの固有識別子でメッセージをラベル付けし、それをサービスレイヤ３０６に送信する。いくつかの実施態様では、メッセージは、ラベル付けられ、サービスマルチプレクサ３２２によってメッセージの単一ストリームに組み合わされる。インバウンドメッセージは、受信キュー３１３におけるキューに入れられ得る。

サーバレイヤ３０４が、サービスレイヤ３０６からメッセージを受信すると、サーバレイヤ３０４は、クライアントに送信されることになるアウトバウンドメッセージのクライアントキュー３１４または３１６にメッセージを配置し、メッセージは、そのクライアントのためにラベル付けされる。いくつかの実施態様では、未処理メッセージは、クライアントキュー３１４または３１６の中に配置される前に、クライアントデマルチプレクサ３２６によって処理され得る。クライアントのためのアウトバウンドメッセージクライアントキュー３１４または３１６が空であるとき、サーバレイヤ３０４は、クライアントの固有識別子を含む「伝送オン」メッセージを関連付けられたサービスレイヤに送信する（Ｓ４０３、図４）。一実施態様では、サーバ上のアウトバウンドメッセージクライアントキュー３１４および３１６のサイズは無限に増大せず、アウトバウンドキュー内に配置されるその任意の情報は、常に比較的「新しい」ものであることになる。

それ故、上記のように、メッセージキューは、待ち時間および帯域幅差異を考慮するように管理され得る。上記の結果は、サーバ上のアウトバウンドメッセージキューが、２つの条件下、（１）クライアントに送信されることになる情報がない、（２）サーバがメッセージのすべてを送信する十分な時間および帯域幅が許可されている場合、あるいは（１）および（２）のある組み合わせでのみ、空であるというものである。

図３Ａおよび３Ｂを参照にして、いくつかの実施態様によれば、ＨＴＴＰ／ＨＴＴＰＳプロトコルは、通信接続３０５で、２つの同時ＨＴＴＰ／ＨＴＴＰＳ接続を使用することによってクライアントとサーバとの間の全二重接続をシミュレートするためのサービスプロトコルとして使用され得る。ＨＴＴＰ／ＨＴＴＰＳを用いると、クライアントからサーバに「無限の要求」を送信することが可能である。この場合において、サーバは、要求ペイロードの長さは不定であることを命令され、この様式において、情報は、クライアントからサーバに継続的に流れ得る。また、ＨＴＴＰ／ＨＴＴＰＳを通じて「無限の応答」を受信することも可能である。この場合において、クライアントは、応答ペイロードの長さは不定であることを命令され、この様式において、情報は、サーバからクライアントに継続的に流れ得る。それ故、全二重通信回路は、２つの半二重ＨＴＴＰ／ＨＴＴＰＳチャネルから形作られ得る。説明されることになるように、クライアントは、両方の接続を始め、「無限の応答」接続上で待ち受ける一方で、「無限の要求」接続上で伝送する。

上記のように、各クライアントレイヤ３０２は、サーバ１０２Ｂから受信したメッセージのクライアント受信キュー３１０を含み、それは、クライアントが論理的に接続されるサービス（アプリケーションプログラム１０７Ａ、１０７Ｂ）に代わって送信される。クライアントレイヤ３０２は、１つのＨＴＴＰ／ＨＴＴＰＳ接続を通じて（任意の他の半二重接続は十分であることになるが）「無限の応答」を使用してこれらのメッセージを受信する。各クライアントレイヤ３０２はまた、それがサーバ１０２Ｂに送信するメッセージのクライアント送信キュー３１２を含み、それは、１つの特定のサービス（例えば、アプリケーションプログラム１０７Ａ、１０７Ｂ）行きのものである。クライアントレイヤ３０２は、第２のＨＴＴＰ／ＨＴＴＰＳ接続を通じて（任意の他の半二重接続は十分であることになるが）「無限の要求」を使用してこれらのメッセージを送信する。

サーバレイヤ３０４が、クライアントからメッセージを受信すると、サーバレイヤ３０４は、クライアントの固有識別子でメッセージをラベル付け、それをサービスレイヤ３０６に送信する。メッセージは、典型的には、１つのＨＴＴＰ／ＨＴＴＰＳ接続を通じて作成された「無限の要求」を通してサーバレイヤ３０４によって受信される。サーバレイヤ３０４が、サービスレイヤ３０６からメッセージを受信すると、サーバレイヤ３０４は、クライアントに送信されることになるアウトバウンドメッセージのクライアントキュー３１４または３１６内にメッセージを配置し、メッセージは、そのクライアントのためにラベル付けされる。次いで、メッセージは、第２のＨＴＴＰ／ＨＴＴＰＳ接続を通じて作成された「無限の応答」を通してクライアントキュー３１４または３１６から送信される。

層状アーキテクチャにおいて利用されるＨＴＴＰ／ＨＴＴＰＳ通信チャネル（または任意の半二重通信チャネル）の失敗は、望ましくない実行特性を結果としてもたらし得る。半二重チャネルの待ち受け側上の無音と、そのチャネルの失敗とを区別することは、困難であることがあるのに対し、伝送側から半二重チャネルの失敗を検出することは、一般的に問題ではない。また、１つ以上のメッセージは、半二重通信チャネルが失敗するときにクライアントとサーバとの間を「飛行中（ｉｎ ｆｌｉｇｈｔ）」であり得る。この状況において、半二重チャネルの伝送側が、どのメッセージが成功裏に受信されたかを知る手法は無い。

それ故、本開示の実施態様によれば、接続の待ち受け側から通信の失敗を検出するための、および失敗の時に１つまたは両方の接続を通じて「飛行中」であった可能性がある情報の回復のための方法が提供される。更に、情報がＨＴＴＰ／ＨＴＴＰＳプロトコルを使用して通信されているように説明されたが、接続ベースの通信を提供する他のプロトコル、例えばＦＴＰ、ＵＤＰ、ＲＴＳＰ、ＲＴＰなどが、利用されてもよい。

図５は、以下のように、それぞれ論理的に接続されたクライアントのためのサービスと関連付けられた信頼性のあるメッセージングを提供する動作上のフロー図５００を例示する。例えば、いくつかの実施態様では、頻繁な「キープアライブ」メッセージが、サービスからクライアントにおよびクライアントからサービスに送信され得る（Ｓ５０２、図５）。これは、通信チャネルの待ち受け側が無音を失敗と区別することを可能にする。半二重チャネルの待ち受け側が予測された期間内に「キープアライブ」メッセージを受信しない場合、それは、接続が失敗したことを推定し得、新たな接続を始めるステップを取る（クライアント側）、または新たな接続を待つ（サーバ側）（Ｓ５０４、図５）。

いくつかの実施態様では、独立したメッセージ連続番号が、クライアントおよびサーバ上で使用され得る。クライアント送信キュー３１２からサーバに送信されるすべてのメッセージは、順序を示す連続番号で注釈を付けられ得、各メッセージは、その順序でサーバに送信されるすべての他のメッセージに関して送信される（Ｓ５０６、図５）。メッセージは、クライアントから送信されると、クライアントのアウトバウンドキューから即時には取り除かれない。クライアントのアウトバウンドメッセージキュー内の次のメッセージは、通常動作下で、送信されることになる次のメッセージになる。同様に、サーバアウトバウンドメッセージクライアントキュー３１４または３１６からクライアントに送信されるすべてのメッセージは、順序を示す連続番号で注釈を付けられ、各メッセージは、その順序でクライアントに送信されるすべての他のメッセージに関して送信される（Ｓ５０６、図５）。メッセージは、サーバから送信されると、サーバのアウトバウンドキューから即時には取り除かれない。サーバのアウトバウンドメッセージキュー内の次のメッセージは、通常動作下で、送信されることになる次のメッセージになる。

いくつかの実施態様では、前の実施態様を踏まえて、「連続確認」メッセージ注釈が、クライアントとサーバとの間で、それぞれの側がどのメッセージが他方によって成功裏に受信されたかを知るように、使用され得る。毎回クライアントがメッセージをサーバに送信する度に、クライアントは、それが、「待ち受け」接続上でサーバから成功裏に受信した最後のメッセージの連続番号でメッセージに注釈を付ける（Ｓ５０８、図５）。サーバがこのメッセージを受信する場合、サーバは、連続番号と、その連続番号に先行する全てと関連付けられたメッセージをそのサーバのアウトバウンドキューから安全に取り除くことができる（Ｓ５１０、図５）。同様に、毎回サーバがメッセージをクライアントに送信する度に、サーバは、それが「待ち受け」接続上のクライアントから成功裏に受信した最後のメッセージの連続番号でメッセージに注釈を付ける（Ｓ５０８、図５）。クライアントがこのメッセージを受信する場合、クライアントは、連続番号と、その連続番号に先行する全てと関連付けられたメッセージをそのクライアントのアウトバウンドキューから安全に取り除くことができる（Ｓ５１０、図５）。

いくつかの実施態様では、失敗が原因で新たな接続が始められると、関連付けられたアウトバウンドキュー内に残る、前に送信されたいずれのメッセージも、他側によって受信されていない可能性があり、再送信される。クライアントが「無限の応答」チャネル（すなわち、そのクライアントがチャネル上で待ち受けている当該チャネル）上の失敗を検出すると、それは、その接続を放棄し、新たなＨＴＴＰ／ＨＴＴＰＳ「無限の応答」接続を始める（Ｓ５１２、図５）。これが成功する場合、サーバは、新たな接続を承認し、それが前に送信した最後のメッセージの後からに代わって、それのアウトバウンドメッセージキューの始めからの送信を開始する（Ｓ５１４、図５）。この様式において、クライアントが受信していない可能性がある任意の移動中のメッセージが再送信されることになる。クライアントは、それがサーバに対して成功裏に確認することができていなかったといういくつかの重複メッセージを検出し得、それは、そのような重複メッセージを安全に捨て得る（Ｓ５１６、図５）。そのようなメッセージは、失敗検出の前に受信した最後の成功した連続番号より小さいまたはその番号に等しい連続番号を有することになる。同様に、クライアントが「無限の要求」チャネル（すなわち、そのクライアントがチャネル上で伝送している当該チャネル）上の失敗を検出すると、それはその接続を放棄し、新たなＨＴＴＰ／ＨＴＴＰＳ「無限の要求」接続を始める（Ｓ５１２、図５）。これが成功する場合、それは、それが前に送信した最後のメッセージの後からに代わって、それのアウトバウンドキューの始めからのメッセージの送信を開始する（Ｓ５１４、図５）。サーバは、新たな接続を承認し、成功裏に確認する見込みがあった可能性がないという、それが受信する任意の重複メッセージを安全に無視する（Ｓ５１６、図５）。そのようなメッセージは、新たな接続が始められた前に受信された最後の成功した連続番号より小さいまたはその番号に等しい連続番号を有することになる。それ故、クライアントが新たなＨＴＴＰ／ＨＴＴＰＳ接続を成功裏に始めることができる限り、すべての通信失敗は、成功裏に回復されることができる。新たな接続が、許容できる期間内になされ得ない場合には、その新たな接続は、サーバとクライアント側の両方上でタイムアウトし、クライアント側は、セッションを終わらせ、リソースを回復し、および他の適切な行動を取るために、使用され得る。セッションがサーバ上で終わらされた後に、接続がクライアントによって試みられる場合には、サーバは、接続試みを拒否することになり、クライアントは、ユーザに知らせ得るおよび／または他の適切な行動を取り得る。

上記技法の組み合わせが、信頼性のある（回復可能な）通信を提供するために使用され得ることを留意する。それ故、上記技法は、クライアントとサーバとの間で信頼性のある通信を提供する一方で、全二重通信機能を提供する。

図６は、実施形態および態様例が実装され得る例示的なコンピューティング環境を示す。コンピューティングシステム環境は、適切なコンピューティング環境の単なる一例であり、使用または機能の範囲についての何の限定も提案することを意図されない。

多くの他の汎用または特別目的のコンピューティングシステム環境または構成が、使用され得る。使用に適するであろう周知のコンピューティングシステム、環境、および／または構成の例は、限定されるものではないが、パーソナルコンピュータ、サーバ、手持ち型またはラップトップ型デバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、ネットワークパーソナルコンピュータ（ＰＣ）、ミニコンピュータ、メインフレームコンピュータ、埋め込み型システム、上記システムまたはデバイスのいずれかを含む分散型コンピューティング環境、および同様のものを含む。

コンピュータによって実行される、例えばプログラムモジュールなどのコンピュータで実行可能な命令が、使用され得る。一般的に、プログラムモジュールは、特定のタスクを機能させるまたは特定の抽象データ種類を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。分散型コンピューティング環境が、使用され得、そこでは、タスクは、通信ネットワークまたは他のデータ伝送媒体を通してつなげられる遠隔処理デバイスによって機能される。分散型コンピューティング環境では、プログラムモジュールおよび他のデータは、メモリ記憶デバイスを含むローカルおよび遠隔の両方のコンピュータ記憶媒体内に位置し得る。

図６を参照にして、本明細書において説明される態様を実装するための例示的なシステムは、コンピューティングデバイス６００などのコンピューティングデバイスを含む。それの最も基本的な構成において、コンピューティングデバイス６００は、典型的には少なくとも１つの処理部６０２およびメモリ６０４を含む。正確な構成およびコンピューティングデバイスの種類次第で、メモリ６０４は、揮発性（例えば、ランダムアクセスメモリ（ＲＡＭ）など）、不揮発性（例えば、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリなど）、またはその２つのいくつかの組み合わせとすることができる。これの最も基本的な構成は、破線６０６によって図６に例示される。

コンピューティングデバイス６００は、付加的な特徴／機能を有し得る。例えば、コンピューティングデバイス６００は、限定されるものではないが、磁気もしくは光学ディスクまたはテープを含む付加的な（取り外し可能および／または取り外し不可能な）記憶装置を含み得る。そのような付加的な記憶装置は、取り外し可能な記憶装置６０８および取り外し不可能な記憶装置６１０によって、図６に例示される。

コンピューティングデバイス６００は、典型的には、種々の具体的な、コンピュータで読み取り可能な媒体を含む。コンピュータで読み取り可能な媒体は、デバイス６００によってアクセスされ得る任意の可用な具体的な媒体とすることができ、揮発性と不揮発性の媒体、取り外し可能および取り外し不可能な媒体の両方を含む。

具体的なコンピュータ記憶媒体は、例えばコンピュータで読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性の、ならびに取り外し可能および取り外し不可能な媒体を含む。メモリ６０４、取り外し可能な記憶装置６０８、および取り外し不可能な記憶装置６１０は、すべて、コンピュータ記憶媒体の例である。具体的なコンピュータ記憶媒体は、限定されるものではないが、ＲＡＭ、ＲＯＭ、電気的に消去可能なプログラム読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ‐ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を格納するために使用され得るおよびコンピューティングデバイス６００によってアクセスされ得る任意の他の媒体を含む。任意のそのようなコンピュータ記憶媒体は、コンピューティングデバイス６００の一部とすることができる。

コンピューティングデバイス６００は、デバイスが他のデバイスと通信することを可能にする（複数の）通信接続６１２を含み得る。コンピューティングデバイス６００はまた、例えばキーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの（複数の）入力デバイス６１４を含み得る。ディスプレイ、スピーカ、プリンタなどの（複数の）出力デバイス６１６もまた、含まれ得る。すべてのこれらのデバイスは、当技術分野において周知であり、ここで長々と記述される必要はない。

本明細書において説明される様々な技法は、ハードウェアまたはソフトウェアに関して、あるいは適切な場合には両者の組み合わせに関して実装され得ることが理解されるべきである。それ故、現在開示された主題の方法および装置、あるいはそれらの一定の態様または部分は、例えばフロッピー（登録商標）ディスケット、ＣＤ‐ＲＯＭ、ハードドライブ、または任意の他の機械で読み取り可能な記憶媒体などの具体的な媒体に具現化されたプログラムコード（すなわち、命令）の形態を取り得、プログラムコードがコンピュータなどの機械にロードされ、その機械によって実行されると、機械は、現在開示された主題を実践するための装置になる。プログラム化できるコンピュータ上のプログラムコードの実行の場合には、コンピューティングデバイスは、一般的に、プロセッサ、プロセッサによって読み取り可能な（揮発性および不揮発性メモリならびに／あるいは記憶要素を含む）記憶媒体、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。１つ以上のプログラムは、例えば、アプリケーションプログラミングインターフェース（ＡＰＩ）、再使用可能な制御、または同様のものの使用を通して、現在開示された主題に関して説明される処理を実装し得るまたは利用し得る。そのようなプログラムは、コンピュータシステムと通信するための高レベル手順またはオブジェクト指向プログラミング言語で実装され得る。しかしながら、（複数の）プログラムは、必要に応じて、アセンブリまたは機械言語で実装され得る。いずれの場合においても、言語は、コンパイルされたまたは解釈された言語であり得、それは、ハードウェア実装と組み合わされ得る。

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

Claims (13)

1. 遠隔アクセスシステムにおいてフロー制御を提供する方法であって、
   クライアントデバイスにクライアントレイヤを提供することと、
   サービスと関連付けられたサービスレイヤであって、前記クライアントデバイスから受信されるメッセージのためのサービス受信キューと、前記クライアントデバイス行きのメッセージのサービス送信キューとを有するサービスレイヤを提供することと、
   前記クライアントデバイスと前記サービスとの間に送信されるメッセージのための通信プロキシとして、前記クライアントデバイス行きのメッセージのアウトバウンドクライアントキューを含むサーバレイヤを提供することと、
   前記クライアントデバイスの特有の識別子を含む伝送オンメッセージを、前記サーバレイヤから前記サービスレイヤに通信することと、
   前記サービスレイヤにおいて前記伝送オンメッセージを受信すると、前記クライアントデバイスへの伝送のために前記サービス送信キューにおける前記メッセージを前記サーバレイヤへ送信することと、を含む、方法。
2. メッセージが前記サービス送信キューにおけるキューに入れられるように、前記サービスレイヤを伝送オフ状態に設定することと、
   前記制御信号を使用して前記サービスレイヤを伝送オン状態に設定することと、
   前記クライアントデバイスのためのメッセージを前記サーバレイヤ内の前記アウトバウンドクライアントキューに送信することと、
   前記サービスレイヤで前記伝送オフ状態に再度入ることとを更に含む、請求項１に記載の方法。
3. 前記サービスレイヤを伝送オフ状態に最初に設定することと、
   前記サービスレイヤで前記クライアントデバイスのためのメッセージを生成することと、
   前記クライアントデバイスのための前記メッセージを前記サービス送信キューにおけるキューに入れることとを更に含む、請求項１〜２のいずれかに記載の方法。
4. 前記制御信号を使用して前記サービスレイヤを伝送オン状態に設定することと、
   前記クライアントデバイスのためのメッセージを前記サーバレイヤ内の前記アウトバウンドクライアントキューに送信することと、
   前記サービスレイヤで前記伝送オフ状態に再度入ることとを更に含む、請求項１〜３のいずれかに記載の方法。
5. 複数のクライアントデバイスから通信を受信することと、各クライアントデバイスと関連付けられた固有識別子で、前記複数のクライアントデバイスのそれぞれからのメッセージをラベル付けすることと、
   複数のクライアントデバイスからのメッセージをメッセージの単一ストリームに組み合わせることとを更に含む、請求項１〜４のいずれかに記載の方法。
6. 複数のメッセージストリームであって、それぞれが、前記固有識別子によって前記複数のクライアントデバイスの１つと関連付けられる、複数のメッセージストリームに、前記サービスレイヤからのストリームメッセージを構文解析することと、
   複数のメッセージストリームのそれぞれを前記複数のクライアントデバイスに通信することとを更に含む、請求項５に記載の方法。
7. 前記クライアントデバイスへのメッセージを非同期的に生成することを更に含む、請求項１〜６のいずれかに記載の方法。
8. コンピュータで読み取り可能な記憶媒体の上にコンピュータで実行可能な命令を有する当該コンピュータで読み取り可能な記憶媒体であって、当該コンピュータで実行可能な命令がコンピューティングデバイスのプロセッサによって実行されると、
   サービスと関連付けられたサービスレイヤであって、クライアントデバイスから受信されるメッセージのためのサービス受信キューと、前記クライアントデバイス行きのメッセージのサービス送信キューとを有するサービスレイヤを提供することと、
   前記クライアントデバイスと前記サービスとの間に送信されるメッセージのための通信プロキシとして、前記クライアントデバイス行きのメッセージのアウトバウンドクライアントキューを含むサーバレイヤを提供することと、
   前記クライアントデバイスの特有の識別子を含む伝送オンメッセージを、前記サーバレイヤから前記サービスレイヤに通信することと、
   前記サービスレイヤにおいて前記伝送オンメッセージを受信すると、前記クライアントデバイスへの伝送のために前記サービス送信キューにおける前記メッセージを前記サーバレイヤへ送信することと、
   を含む方法を機能させる、コンピュータで読み取り可能な記憶媒体。
9. メッセージが前記送信キューにおけるキューに入れられるように、前記サービスレイヤを伝送オフ状態に設定することと、
   前記制御信号を使用して前記サービスレイヤを伝送オン状態に設定することと、
   前記クライアントデバイスのためのメッセージを前記サーバレイヤ内のアウトバウンドクライアントキューに送信することと、
   前記サービスレイヤで前記伝送オフ状態に再度入ることとのための命令を更に含む、請求項８に記載のコンピュータで読み取り可能な記憶媒体。
10. 前記サービスレイヤを伝送オフ状態に最初に設定することと、
    前記サービスレイヤで前記クライアントデバイスのためのメッセージを生成することと、
    前記クライアントデバイスのための前記メッセージを前記サービス送信キューにおけるキューに入れることと、
    前記制御信号を使用して前記サービスレイヤを伝送オン状態に設定することと、
    前記クライアントデバイスのためのメッセージを前記サーバレイヤ内の前記アウトバウンドクライアントキューに送信することと、
    前記サービスレイヤで前記伝送オフ状態に再度入ることとのための命令を更に含む、請求項８〜９のいずれかに記載のコンピュータで読み取り可能な記憶媒体。
11. 前記クライアントデバイスの固有識別子で各メッセージをラベル付けするための命令を更に含む、請求項８〜１０のいずれかに記載のコンピュータで読み取り可能な記憶媒体。
12. 前記クライアントデバイスへのメッセージを非同期的に生成するための命令を更に含む、請求項８〜１１のいずれかに記載のコンピュータで読み取り可能な記憶媒体。
13. 多対一様式で、複数のクライアントデバイスと前記サービスレイヤとの間の関係を確立するための命令を更に含む、請求項８〜１２のいずれかに記載のコンピュータで読み取り可能な記憶媒体。

Images