(57)【要約】ネットワーク・プロキシは、クライアント・アプリケーションからの一連の要求に応じてサーバ・レイテンシを短縮する。ネットワーク・プロキシは、クライアントとサーバとの間のメッセージをインターセプトする。インターセプトされたクライアント要求はルールと比較される。クライアント要求があるルールと一致するとき、追加の要求メッセージがクライアント・アプリケーションのためにサーバに転送される。追加の要求メッセージに応じて、サーバは対応する応答メッセージを提供する。ネットワーク・プロキシは、応答メッセージをインターセプトしてキャッシュする。以後のクライアント応答は、ネットワーク・アプリケーション・プロキシによってインターセプトされ、キャッシュされたメッセージと比較される。キャッシュされた応答メッセージがクライアント要求メッセージに対応する場合、同じ情報をサーバに再要求する代わりに、応答メッセージが直ちにクライアント・アプリケーションに返される。サーバ側ネットワーク・プロキシは、クライアント要求をルールと比較し、追加の要求メッセージを送信することができる。対応する応答メッセージをクライアント側ネットワーク・プロキシに転送してキャッシュすることができる。2008537814.tif 000003
2008537814.tif 000002
【特許請求の範囲】
【請求項１】
クライアント−サーバ・トランザクションを加速する方法であって、以下の段階を含む方法：
（a）クライアント・アプリケーションから第1のメッセージを受信する段階；
（b）第1のメッセージを1組のルールと比較する段階；
（c）第1のメッセージが1組のルールのうちの少なくとも1つのルールと一致したことに応じて第1のメッセージおよび少なくとも1つの追加のメッセージをサーバ・アプリケーションに転送する段階；
（d）追加のメッセージに対応する少なくとも1つの応答メッセージをサーバ・アプリケーションから受信する段階；
（e）追加のメッセージに対応する応答メッセージをメッセージ・キャッシュに記憶する段階；
（f）クライアント・アプリケーションから第2のメッセージを受信する段階；
（g）第2のメッセージが追加のメッセージに類似しているかどうかを判定する段階；および
（h）第2のメッセージが追加のメッセージに類似していることに応じて、メッセージ・キャッシュに記憶されている応答メッセージをクライアント・アプリケーションに転送する段階。
【請求項２】
段階（a）、（b）、（c）、および（d）はサーバ側ネットワーク・プロキシによって実行され、段階（e）、（f）、（g）、および（h）はクライアント側ネットワーク・プロキシによって実行される、請求項1記載の方法。
【請求項３】
少なくとも1つの応答メッセージをサーバ側ネットワーク・プロキシからクライアント側ネットワーク・プロキシに送信する段階
を、段階（e）がさらに含む、請求項2記載の方法。
【請求項４】
応答メッセージをメッセージ・キャッシュに記憶すべきであることをクライアント側ネットワーク・プロキシに示すように適合されている追加の情報と応答メッセージをラッピングする段階
を、応答メッセージを送信する段階がさらに含む、請求項3記載の方法。
【請求項５】
追加の情報が、応答メッセージに対応する追加のメッセージを識別する、請求項4記載の方法。
【請求項６】
段階（e）に応じて、キャッシュ限界に達したかどうかを判定する段階；
キャッシュ限界に達したと判定されたことに応じて、クライアント側プロキシによってサーバ側プロキシにスロットリング・メッセージを送信する段階；および
サーバ側ネットワーク・プロキシがスロットリング・メッセージを受信したことに応じて、サーバ側ネットワーク・プロキシからクライアント側ネットワーク・プロキシへの少なくとも1つの応答メッセージの送信を一時停止する段階
をさらに含む、請求項3記載の方法。
【請求項７】
段階（h）に応じて、以下の段階をさらに含む、請求項6記載の方法：
転送された応答メッセージを応答キャッシュから削除する段階；
キャッシュ記憶限界に達したかどうかを判定する段階；
キャッシュ記憶限界に達していないと判定されたことに応じて、クライアント側プロキシによってサーバ側プロキシにアンスロットリング・メッセージを送信する段階；および
サーバ側ネットワーク・プロキシがアンスロットリング・メッセージを受信したことに応じて、サーバ側ネットワーク・プロキシからクライアント側ネットワーク・プロキシへの少なくとも1つの応答メッセージの送信を再開する段階。
【請求項８】
第1のメッセージに対応する事前肯定応答メッセージを生成する段階；および
事前肯定応答メッセージをクライアント・アプリケーションに転送する段階
をさらに含む、請求項1記載の方法。
【請求項９】
第1のメッセージに対する応答である肯定応答メッセージをサーバ・アプリケーションから受信する段階；
肯定応答メッセージのステータス・コードを分析する段階；
ステータス・コードが成功状態を示していることに応じて肯定応答メッセージを破棄する段階；および
肯定応答メッセージのステータス・コードが失敗状態を示していることに応じて、クライアント・アプリケーションから第2のメッセージを受信した後でクライアント・アプリケーションに失敗状態を示す応答メッセージを転送する段階
をさらに含む、請求項8記載の方法。
【請求項１０】
クライアント−サーバ・トランザクションを加速する方法であって、以下の段階を含む方法：
サーバ・アプリケーションに宛てられたメッセージをクライアント・アプリケーションから受信する段階；
メッセージがサーバ・アプリケーションに送信された前のメッセージと整合するかどうかを判定する段階；
メッセージが、サーバ・アプリケーションに送信された前のメッセージと整合していると判定されたことに応じて、メッセージをサーバに送信する段階；
メッセージを1組のルールと比較する段階；
メッセージが少なくとも1つのルールと一致することに応じて、少なくとも1つの追加のメッセージを生成する段階；および
追加のメッセージをサーバ・アプリケーションに転送する段階。
【請求項１１】
前のメッセージは、少なくとも1つの追加の前のメッセージが1組のルールと一致したことに応じてサーバ側プロキシによって生成されたものである、請求項10記載の方法。
【請求項１２】
メッセージが、サーバ・アプリケーションに送信された前のメッセージと矛盾していると判定されたことに応じて、メッセージが、サーバ・アプリケーションに送信された前のメッセージに対応する結果メッセージを記憶する結果キャッシュの少なくとも一部と矛盾するかどうかを判定する段階；および
メッセージが結果キャッシュの一部と矛盾すると判定されたことに応じて、結果キャッシュの一部を無効化する段階
をさらに含む、請求項10記載の方法。
【請求項１３】
サーバ・アプリケーションから第2のメッセージを受信する段階；
第2のメッセージが追加のメッセージに対する応答であるかどうかを判定する段階；および
第2のメッセージが追加のメッセージに対する応答であると判定されたことに応じて、クライアント・アプリケーションに関連するネットワーク・プロキシに含まれる結果キャッシュに第2のメッセージを記憶すべきであることを示すように第2のメッセージをラッピングし、ラッピングされた第2のメッセージをクライアント・アプリケーションに関連するネットワーク・プロキシに転送する段階
をさらに含む、請求項10記載の方法。
【請求項１４】
第2のメッセージがクライアント・アプリケーションからのメッセージに対する応答であるかどうかを判定する段階；および
第2のメッセージがクライアント・アプリケーションからのメッセージに対する応答であると判定されたことに応じて、第2のメッセージをクライアント・アプリケーションに転送する段階
をさらに含む、請求項13記載の方法。
【請求項１５】
第2のメッセージが、クライアント・アプリケーションに関連するネットワーク・プロキシに含まれる結果キャッシュの少なくとも一部を無効化するかどうかを判定する段階；および
結果キャッシュの一部を無効化することを指定するキャッシュ無効化メッセージをネットワーク・プロキシに送信する段階
をさらに含む、請求項13記載の方法。
【請求項１６】
クライアント−サーバ・トランザクションを加速する方法であって、以下の段階を含む方法：
サーバ・アプリケーションに宛てられたメッセージをクライアント・アプリケーションから受信する段階；
メッセージが結果キャッシュ内のデータに対応しているかどうかを判定する段階；
メッセージが結果キャッシュ内のデータに対応していないと判定されたことに応じて、メッセージをサーバ・アプリケーションに送信する段階；および
メッセージが結果キャッシュ内のデータの少なくとも一部に対応していると判定されたことに応じて、結果キャッシュからのデータの少なくとも一部を含む応答メッセージをクライアント・アプリケーションに送信する段階。
【請求項１７】
事前肯定応答メッセージを生成し、メッセージが結果キャッシュ内のデータに対応していないと判定されたことに応じて、事前肯定応答メッセージをクライアント・アプリケーションに転送する段階
をさらに含む、請求項16記載の方法。
【請求項１８】
クライアント・アプリケーションからのメッセージに対する応答である肯定応答メッセージメッセージをサーバ・アプリケーションから受信する段階；
肯定応答メッセージのステータス・コードを分析する段階；
成功状態を示すステータス・コードに応じて肯定応答メッセージ破棄する段階；
サーバ・アプリケーションに宛てられた第2のメッセージをクライアント・アプリケーションから受信する段階；および
失敗状態を示す肯定応答メッセージのステータス・コードに応じて、クライアント・アプリケーションから第2のメッセージを受信した後で失敗状態を示す応答メッセージをクライアント・アプリケーションに転送する段階
をさらに含む、請求項17記載の方法。
【請求項１９】
サーバ側プロキシから第2のメッセージを受信する段階；
第2のメッセージが、サーバ側プロキシによってプリフェッチされた追加のデータまたはクライアント・アプリケーションからのメッセージに対する応答を含むかどうかを判定する段階；
追加のデータがサーバ側プロキシによってプリフェッチされたと判定されたことに応じて、追加のデータを結果キャッシュに記憶する段階；および
追加のデータがクライアント・アプリケーションからのメッセージに対する応答であると判定されたことに応じて、第2のメッセージをクライアント・アプリケーションに送信する段階
をさらに含む、請求項16記載の方法。
【請求項２０】
第2のメッセージがキャッシュ無効化メッセージであるかどうかを判定する段階；および
第2のメッセージがキャッシュ無効化メッセージであると判定されたことに応じて、結果キャッシュの少なくとも一部を無効化する段階
をさらに含む、請求項16記載の方法。
【請求項２１】
第2のメッセージを受信したことに応じて結果キャッシュの容量を判定する段階；
結果キャッシュの容量が満杯であると判定されたことに応じて、サーバ側プロキシにスロットリング・メッセージを送信する段階
をさらに含む、請求項19記載の方法。
【請求項２２】
データの少なくとも一部を含む応答メッセージを結果キャッシュからクライアント・アプリケーションに送信したことに応じて、結果キャッシュからデータの少なくとも一部を削除する段階；および
データの少なくとも一部を結果キャッシュから削除したことに応じてサーバ側プロキシにアンスロットリング・メッセージを送信する段階
をさらに含む、請求項21記載の方法。
【請求項２３】
クライアント・アプリケーションとメッセージを交換するように適合されている第1のネットワーク・インタフェースと、
サーバ・アプリケーションとメッセージを交換するように適合されている第2のネットワーク・インタフェースと、
クライアント・アプリケーションからの1組の少なくとも1つのメッセージの属性を指定するルール要素および1組の少なくとも1つのメッセージに関連する追加のメッセージの少なくとも一部を指定するアクション要素を含む少なくとも1つのルールを記憶するように適合されているルール・ストアと、
第1のネットワーク・インタフェースを介してクライアント・アプリケーションから受信されたメッセージをルール・ストアのルール要素と比較し、クライアント・アプリケーションからのメッセージがルール要素の属性と一致することに応じてアクション要素から追加のメッセージを生成し、追加のメッセージをサーバ・アプリケーションに送信するように適合されている一致エンジンとを含む、
クライアント・サーバ・トランザクションを加速するように適合されているネットワーク・プロキシ。
【請求項２４】
第2のメッセージがクライアント・アプリケーションに関連するネットワーク・プロキシに含まれる結果キャッシュの少なくとも一部を無効化するメッセージであるかどうかを判定し、結果キャッシュの一部を無効化すべきあることを指定するキャッシュ無効化メッセージを、クライアント・アプリケーションに関連するネットワーク・プロキシに送信するように適合されている無効化チェッカをさらに含む、請求項23記載のネットワーク・プロキシ。
【請求項２５】
サーバ・アプリケーションから受信された第2のメッセージが追加のメッセージに対する応答であるかどうかを判定し、かつ
第2のメッセージが追加のメッセージに対する応答であると判定されたことに応じて、クライアント・アプリケーションに関連するネットワーク・プロキシに含まれる結果キャッシュに第2のメッセージを記憶すべきであることを示すように第2のメッセージをラッピングし、ラッピングされた第2のメッセージをクライアント・アプリケーションに関連するネットワーク・プロキシに転送するように適合されている論理をさらに含む、
請求項23記載のネットワーク・プロキシ。
【請求項２６】
第2のメッセージが、クライアント・アプリケーションからのメッセージに対する応答であるかどうかを判定し、かつ
第2のメッセージがクライアント・アプリケーションから受信されたメッセージに対する応答であると判定されたことに応じて、第2のメッセージをクライアント・アプリケーションに転送するように適合されている論理をさらに含む、
請求項25記載のネットワーク・プロキシ。
【請求項２７】
クライアント・アプリケーションとメッセージを交換するように適合されている第1のネットワーク・インタフェースと、
サーバ・アプリケーションとメッセージを交換するように適合されている第2のネットワーク・インタフェースと、
クライアント・アプリケーションのためにプリフェッチされた応答メッセージを含むデータを記憶するように適合されている結果キャッシュと、
クライアント・アプリケーションから受信され、サーバ・アプリケーションに宛てられたメッセージが結果キャッシュ内のデータに対応しているかどうかを判定し、
メッセージが結果キャッシュ内のデータに対応していないと判定されたことに応じて、メッセージをサーバ・アプリケーションに送信し、
メッセージが結果キャッシュ内のデータの少なくとも一部に対応していると判定されたことに応じて、結果キャッシュに記憶されている応答メッセージをクライアント・アプリケーションに送信するように適合されている論理とを含む、
クライアント−サーバ・トランザクションを加速するように適合されているネットワーク・プロキシ。
【請求項２８】
サーバ側プロキシから第2のメッセージを受信し、
第2のメッセージが、サーバ側プロキシによってプリフェッチされた追加のデータまたはクライアント・アプリケーションからの前のメッセージに対する応答を含むかどうかを判定し、
追加のデータがサーバ側プロキシによってプリフェッチされたと判定されたことに応じて、追加のデータを結果キャッシュに記憶し、かつ
追加のデータがクライアント・アプリケーションからの前のメッセージに対する応答であると判定されたことに応じて、第2のメッセージをクライアント・アプリケーションに送信するように適合されている論理をさらに含む、
請求項27記載のネットワーク・プロキシ。
【請求項２９】
事前肯定応答メッセージを生成し、クライアント・アプリケーションから受信されたメッセージが結果キャッシュ内のデータに対応していないと判定されたことに応じて、事前肯定応答メッセージをクライアント・アプリケーションに転送するように適合されている論理をさらに含む、
請求項27記載のネットワーク・プロキシ。
【請求項３０】
クライアント・アプリケーションから受信されたメッセージに対する応答である肯定応答メッセージメッセージをサーバ・アプリケーションから受信し、
肯定応答メッセージのステータス・コードを分析し、
成功状態を示すステータス・コードに応じて肯定応答メッセージ破棄し、
失敗状態を示す肯定応答メッセージのステータス・コードに応じて、クライアント・アプリケーションから以後のメッセージを受信した後で失敗状態を示す応答メッセージをクライアント・アプリケーションに転送するように適合されている論理をさらに含む、
請求項29記載のネットワーク・プロキシ。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願の相互参照
本出願は、2005年3月15日に出願され、"Rules-Based Transaction Prefetching Using Connection End-Point Proxies"という名称を有し、開示が参照によりすべての目的で本明細書に組み入れられる米国特許仮出願第60/662,452号に対する優先権を主張する。本出願は、2002年10月30日に出願され、"Transaction Accelerator for Client-Server Communication Systems"という名称を有する米国特許出願第10/285,315号（以下"McCanne I"）、2003年8月12日に出願され、"Transparent Client-Server Transaction Accelerator"という名称を有する米国特許出願第10/640,405号（以下"McCanne III"）、2003年8月12日に出願され、"Cooperative Proxy Auto-Discovery and Connection Interception "という名称を有する米国特許出願第10/640,562号（以下"McCanne IV"）、2003年8月12日に出願され、"Content Delivery for Client-Server Protocols with User Affinities using Connection End-Point Proxies "という名称を有する米国特許出願第10/640,459号（以下"McCanne V"）に関しており、これらの出願を参照によりすべての目的で組み入れる。
【０００２】
発明の背景
本発明は、概して、ネットワークを介したクライアント−サーバ・トランザクションを加速することに関する。多くの典型的なコンピュータ・アプリケーションは、クライアントとサーバの対話に要求−応答ベースのメッセージング方式を使用する。この方式では、クライアントは要求を発行し、次いで、次の要求を発行する前にサーバからの応答を待つ。ある場合には、サーバは、クライアントへの要求または「コールバック」メッセージを開始することができる。
【０００３】
クライアントによって開始されるトランザクションは、1つまたは複数の要求−応答メッセージ対から成る。クライアント・エンドポイントおよびサーバ・エンドポイントがネットワーク・チャネル上で通信する別々のエンティティであるとき、ネットワーク・チャネルのレイテンシ（latency）特性は全トランザクション時間において重要な役割を果たす。通常、ワイド・エリア・ネットワーク（WAN）は、ローカル・エリア・ネットワーク（LAN）と比べてより長い往復遅延時間（round-trip-time）（RTT）を有する。したがって、クライアントが要求を発行してからクライアントがサーバから応答を受信するまでの時間が長くなる。さらに、複数の要求−応答メッセージ対を含むトランザクションの場合、クライアントが前の要求に対する応答を受信してからでないかぎり次の要求を発行しないので、往復遅延時間が長くなるため、全トランザクション時間が長くなる。
【０００４】
高レイテンシWANの場合、クライアントがトランザクションを実行する方法を修正することによって全トランザクション時間を短縮することができる。2つの要求が互いに独立している場合、クライアントは、次の要求を発行する前に第1の未解決の要求に対する応答の受信を待たなくてよい。一般に、データ独立形態およびタイミング独立形態のような少なくとも2つの独立形態がある。一対の要求は、第2の要求のコンテンツが、第1の要求から受信される応答メッセージにかかわらず同じである場合にはデータ独立形態である。一対の要求は、サーバによる第1の要求の肯定応答（通常応答メッセージによって伝送される）なしに第2の要求を発行できる場合には互いにタイミング独立している。すべてのタイミング独立要求はデータ独立要求でもあるが、この逆は成り立たない。2つまたはそれ以上の独立要求メッセージをクライアントによって同時に発行するかまたは高速に連続して発行し、全所要時間を短縮してトランザクションを軽減することができる。しかし、この方法は、要求同士が相互依存することが多いため、すべての場合に実現可能であるわけではない。
【０００５】
このような改良が可能であり、互いに独立したトランザクションを識別できる場合でも、クライアント・アプリケーションは容易に修正できないことが多い。法律的または営利的な理由でソース・コードが利用できないか、サポート上の理由でソース・コードの変更が許可されないか、またはクライアント・アプリケーションを変更するのに必要な技能を有する人がいない場合がある。
【０００６】
したがって、アプリケーションを修正する必要なしにクライアント−サーバ・トランザクションの時間を短縮するシステムおよび方法が望ましい。
【発明の開示】
【０００７】
発明の概要
本発明のある態様では、ネットワーク・アプリケーション・プロキシを使用して、クライアント・アプリケーションを修正せずにクライアント・サーバ・トランザクションの速度を向上させることができる。特に、ネットワーク・アプリケーション・プロキシを使用して、クライアント・アプリケーションからの一連の要求に対する応答におけるサーバ・レイテンシを短縮することができる。ネットワーク・アプリケーション・プロキシは、クライアントとサーバとの間に確立されたネットワーク接続をインターセプトするためにクライアント・エンドおよび/またはサーバ・エンドで使用される。ネットワーク・アプリケーション・プロキシによってインターセプトされたクライアント要求は、1組のルールと比較される。クライアント要求が1つまたは複数のルールと一致するとき、プリフェッチ要求と呼ばれる追加のメッセージがクライアント・アプリケーションのためにサーバに転送される。ある態様では、このルールは、システム上の特定のアプリケーションに従って定義される。
【０００８】
サーバに送信される1つまたは複数のプリフェッチ・メッセージに応じて、サーバは対応する応答メッセージを提供することができる。ネットワーク・アプリケーション・プロキシは、応答メッセージをインターセプトし、プリフェッチ・メッセージに対応する応答をキャッシュする。以後のクライアント応答は、ネットワーク・アプリケーション・プロキシによってインターセプトされると、キャッシュされたプリフェッチ・メッセージと比較される。クライアント要求がキャッシュされたプリフェッチ・メッセージと一致する場合、同じ情報をサーバに再要求するのではなく、関連する結果メッセージが直ちにクライアント・アプリケーションに返される。
【０００９】
さらなる態様では、この機能は、クライアント側ネットワーク・プロキシおよびサーバ側ネットワーク・プロキシの両方によって実現される。サーバ側ネットワーク・プロキシは、クライアント要求を1組のルールと比較し、プリフェッチ・メッセージを作成し、プリフェッチ・メッセージに対する応答メッセージを受信することができる。サーバ側ネットワーク・プロキシは次いで、応答メッセージを含むデータをクライアント側ネットワーク・プロキシに転送してキャッシュすることができる。クライアント側ネットワーク・プロキシは、さらなるクライアント要求をインターセプトして、ローカルにキャッシュされたプリフェッチ・メッセージと比較する。クライアント要求がキャッシュされたプリフェッチ・メッセージと一致する場合、クライアント側プロキシは、関連する結果メッセージを直ちにクライアント・アプリケーションに返すことができる。逆に、クライアント要求がキャッシュされたプリフェッチ・メッセージと一致しない場合、クライアント側プロキシはクライアント要求をサーバ側プロキシに転送して、1組のルールと比較し、サーバによって最終的に処理することができる。
【００１０】
よりさらなる態様では、クライアントが事前に発行されキャッシュされている要求メッセージ以外の要求メッセージを発行する場合、クライアント・プロキシは、このアウト・オブ・オーダー要求メッセージをサーバ側プロキシに転送する。このメッセージを受信すると、サーバ側プロキシのある態様は、このメッセージがすべての事前にフェッチされている応答を無効化するか、これらの応答にまったく影響しないか、それとも回復できないトランザクション障害を生じさせるかを判定する。すべての事前にフェッチされているメッセージを無効化する必要がある場合、サーバ側プロキシは、その判定をクライアント側プロキシに中継し、クライアント側プロキシはそのキャッシュのすべてまたは一部をパージする。アウト・オブ・オーダー・メッセージによって回復できないトランザクション障害が生じる場合、サーバ側プロキシはサーバならびにそのピア・クライアント側プロキシとの接続を閉鎖し、クライアント側プロキシは、クライアント・ノードにエラーを返さなければならない。
【００１１】
いくつかのサーバ・アプリケーションは、ある条件が生じたときにサーバによってクライアントにメッセージが送信される非同期クライアント通知をサポートする。この通知は、クライアントへのコールバックとして働き、1つまたは複数のクライアント・ノードおよび/またはサーバ・ノードによって共有される状態情報の整合性を保証することができる。たとえば、サーバがデータベース・サーバとして機能し、多数のクライアントがデータベースにアクセスする場合、あるクライアントは、そのクライアントがサーバとの事前の読み取りトランザクションから記録したあるデータベース・エントリを別のクライアントが修正したときに通知を受信することに関心を持つことがある。整合性を保証するために、クライアントの態様は、事前に記録されているデータベース・エントリを更新または消去する。ネットワーク・レベル・アプリケーションを使用するときにこの整合性を維持するために、プロキシは、このようなコールバックが行われる場合に、プリフェッチされた応答をいつ無効化または更新すべきかを知るべきである。ルールは、サーバが発信したコールバック・メッセージが指定された正規の表現と一致するときにとられるアクションを決定する。通常、このアクションとして、クライアント側プロキシでプリフェッチされた応答がパージされる。
【００１２】
ある態様では、ユーザ指定ルールは、クライアントまたはサーバによって生成されたどの要求が一致するかを判定するのに使用される基準を正確に指定する。さらに、ルールは、一致したときにとるべき適切なアクションを指定する。一致を判定するのに使用される基準は、要求/応答メッセージの構造によって決まる。例示のために、MicrosoftのSybaseによって実現されるTabular Data Stream（TDS）プロトコルで符号化されているもののようなクリア・テキスト・クエリおよび/またはリモート・プロシージャ・コール（RPC）、ならびにwww.freetds.orgで入手可能なプログラムを使用してクライアントによってアクセスされているデータベース・アプリケーション・サーバを考えてみよう。この例では、ユーザが、クリア・テキスト・クエリの場合にテキストを厳密または部分的に一致させる正規表現を指定する。RPCメッセージの場合、RPC名、識別子、引数、パラメータなどの非テキスト・ベースの符号化（たとえば、バイナリ符号化）で要求メッセージを構成することができるため、シンプル・テキスト・ベースの正規表現照合は十分ではない。したがって、アプリケーション・プロキシは、RPC名、RPC識別子、RPCパラメータの数、パラメータ名、パラメータ・タイプ、または引数値のうちの1つまたは複数の組み合わせによって照合が行われるように、符号化されたRPCメッセージ構成要素を復号し、ユーザにクリア・テキスト（または文字フォーマット）で示さなければならない。
【００１３】
ある態様では、ユーザ指定アクションは、クエリまたはRPCメッセージがユーザ指定ルールと一致するときにプリフェッチされた要求がいくつ生成されるかを判定する。第1のプリフェッチされた要求は、元のルール・トリガ・メッセージをクローン化し、次にそれを修正することによって得られる。プレーン・テキスト・ベースのクエリ・メッセージの場合、修正は、正規表現置換動作であってよい。RPCベースのメッセージの場合、ユーザ・アクションは、正規表現置換を介してRPC名または識別子変更を指定する。RPC引数の場合、ユーザ・アクションは、引数をリスト内のそのオフセットを使用して指定し、正規表現を使用して修正を指定する。以後のプリフェッチされた要求メッセージは、ルール・トリガ・メッセージまたは事前のプリフェッチされたメッセージからクローン化される。
【００１４】
ユーザ指定ルールがサーバ側プロキシにおいて多数のプリフェッチされた要求を生成することが可能である。このような状況の結果として、サーバ・ノードのリソースに重い負荷がかかるか、またはクライアント・ノードがプロキシによってまだキャッシュされていない要求メッセージを発行するときに過度の遅延が生じる。ある態様では、以下の2つの方式を使用してこの問題を解消することができる。すなわち、a)ユーザ指定制限によって、サーバ・エンド・プロキシからサーバに発行される未解決のプリフェッチされた要求の数を制御する、b)プロキシ間のフィードバック機構によって、いつプリフェッチを再開するかを決定する。フィードバック機構は、応答がすでにクライアントでプリフェッチされ記憶されている要求メッセージをクライアント・ノードが要求したときに、クライアント側プロキシにサーバ側に肯定応答を送り返させる。クライアントが、すでにフェッチされているメッセージ以外のメッセージを要求した場合、フィードバック機構は、サーバ側プロキシが新しい要求を発行するのを妨げる。一方、プリフェッチされた応答をクライアントに送信する場合、正のフィードバックによって、サーバ側プロキシはサーバからより多くの応答をプリフェッチする。
【００１５】
発明の詳細な説明
図1は、本発明の態様による、クライアント110とサーバ170との間のトランザクションを加速するシステム100を示している。図では、クライアント110とクライアント側ネットワーク・プロキシ130はどちらも、通常ローカル・エリア・ネットワークまたはLANであるクライアント側ネットワーク120に取り付けられている。同様に、サーバ170およびサーバ側ネットワーク・プロキシ150はどちらも、サーバ側ネットワーク160に取り付けられている。クライアント側ネットワーク120およびサーバ側ネットワーク160はどちらもWAN 140を介し、場合によっては、図1に示されていない追加のルーティング装置、スイッチング装置、およびブリッジング装置、ならびにリンクを介して接続されている。WAN 140は、仮想専用ネットワーキング・プロトコルを含む、データ・メッセージを運ぶことのできる様々なネットワークまたはインターネットからなり得る。
【００１６】
クライアント110からの要求115は、クライアント側ネットワーク・プロキシ130を介して送信され、クライアント側ネットワーク・プロキシ130は、一致するキャッシュされているプリフェッチされた応答136で応答することができる。クライアント側ネットワーク・プロキシ130が一致するキャッシュされているプリフェッチされた応答を有さない場合、クライアント側ネットワーク・プロキシ110は、要求115を最適化または変換し、最適化された要求135としてワイド・エリア・ネットワークWAN 140の他方の側のサーバ側ネットワーク・プロキシ150に送信する。サーバ側ネットワーク・プロキシ150は、クライアント側ネットワーク・プロキシ130の同等物であり、受信された最適化された要求135に逆最適化または変換を適用して元の要求116を生成する。サーバ側ネットワーク・プロキシ150は、元の要求116と一致するルールがあるかどうか検査し、1つまたは複数のルールがファイアしており、プリフェッチがスロットルされていない場合、ファイアしているルールが元の要求116を新しい要求155、156に変換するかまたは置き換える。ファイアしているルールがないかまたはプリフェッチがスロットルされている場合、元の要求116がサーバ170に転送される。
【００１７】
サーバ170からクライアント110への応答175は逆の経路を辿る。応答175は、サーバ側プロキシ150を介して送信され、サーバ側プロキシ150は、クライアント側ネットワーク・プロキシ130でキャッシュされている情報を更新するかまたは無効化し、それによって場合によっては応答175を拡張するかまたは応答157で置き換えることのような追加のアクションをとらなければならないかどうかを判定する。サーバ側ネットワーク・プロキシ170は、修正された応答157を最適化または変換し、最適化された応答158としてWAN 140を介してクライアント側ネットワーク・プロキシ130に送信する。クライアント側ネットワーク・プロキシ130は、サーバ側ネットワーク・プロキシ170の同等物であり、受信された最適化された要求158に逆最適化または変換を適用して元の修正された要求157を生成する。クライアント側ネットワーク・プロキシは、必要に応じてそのローカル・キャッシュを更新または無効化することによって修正された応答157を処理する。修正された応答157が直接（非プリフェッチ）応答を含む場合、その直接応答136がクライアント110に送信される。
【００１８】
図2は、本発明の態様による、クライアント側ネットワーク・プロキシ130およびサーバ側ネットワーク・プロキシ150の内部要素を示している。クライアント側ネットワーク・プロキシ130は結果キャッシュ210、最適化コーデック215、およびプリフェッチ・スロットル・コントロール220を含んでいる。サーバ側ネットワーク・プロキシ150は、最適化コーデック216、無効化チェッカ230、一致エンジン240、通知レシーバ250、ルール・ストア260、およびプリフェッチ・スロットル270を含んでいる。
【００１９】
要求メッセージ115がクライアント側ネットワーク・プロキシ130によってクライアント110から受信されると、要求メッセージ115は、結果キャッシュ210のコンテンツと比較される。ある態様では、結果キャッシュ210は、プリフェッチ・クライアント要求およびサーバ170からの対応する応答を含むテーブルまたはその他のデータ構造である。結果キャッシュ210が、要求115と一致する結果を含む場合、その一致する結果はクライアント110に返され、要求115はサーバ側プロキシ150上に送信される。
【００２０】
以下に詳しく論じるように、クライアント側プロキシ130の態様は、プリフェッチされた要求のデータがクライアント110とのWAN接続218に負担をかけるのを防止し、それによって、クライアント110によってサーバ170に明示的に要求されたデータが遮断または遅延されるプリフェッチ・スロットル・コントロール220を含んでよい。これらの態様では、サーバ側プロキシ150でプリフェッチがスロットルされていることをプリフェッチ・スロットル・コントロール220が示している場合、結果キャッシュ210の結果を使用すると、クライアント側ネットワーク・プロキシ130は、サーバ側ネットワーク・プロキシ150のプリフェッチ・スロットル270に「アンスロットル」メッセージを送信する。プリフェッチ・スロットル270は、「アンスロットル」メッセージを受信すると、サーバ側ネットワーク・プロキシ150がクライアント110のデータのプリフェッチを再開するのを可能にする。
【００２１】
結果キャッシュ210内に一致する結果がない場合、要求メッセージ115は最適化コーデック215に伝えられ、最適化コーデック215は特許出願McCanne I、McCanne III、McCanne IV、およびMcCanne Vに記載されたような最適化および変換を適用する。最適化されたメッセージ218は、クライアント側最適化コーデック215からサーバ側最適化コーデック216に流れ、このような最適化されたメッセージ218は、数もサイズも元の要求メッセージ115に厳密には対応しない。
【００２２】
サーバ側ネットワーク・プロキシ150で、サーバ側最適化コーデック216は、クライアント側最適化コーデック215によって適用された最適化および変換を解除し、元の要求メッセージ115を回復する。無効化チェッカ230は、要求メッセージ115を検査し、要求115がプリフェッチされ結果キャッシュ210にキャッシュされた情報を無効化するかどうかを判定する。そうである場合、無効化チェッカ230は、クライアント側ネットワーク・プロキシ130に無効化メッセージを送信する。無効化チェッカ230が、要求115は実行できないと判定した場合、無効化チェッカ230は、クライアント側ネットワーク・プロキシ130に致命的エラー・メッセージを送信する。
【００２３】
無効化チェッカ230が致命的エラーを検出しなかった場合、メッセージ115は一致エンジン240に転送される。一致エンジン240は、メッセージ115をルール・ストア260のコンテンツと比較し、ルール・ストア260内ルールのうちのどのルールが「ファイアしている」、すなわちアクティブにされているかを判定する。あるルールがファイアされている場合、その定義された効果が作用し、場合によっては、サーバ170に送信すべき新しいメッセージ280が生成される。ルールはステートレスであってもステートフルであってもよい。
【００２４】
一致エンジン240およびルール・ストア260は、ファイアされているルールがあるかどうか、複数のルールをファイアできるかどうか、ルールがどんな順序でファイアされるかを判定する。ルールは、他のルールを有効にするかまたは無効にするのを可能にすることができる。ある態様では、一致エンジン240またはルール・ストア260によって収束特性または時間制限特性が実施され、ルール・ファイアのエンドレス・サイクルがないことを確実にする。1つのこのような構成は、各ルールがファイアした後で無効にし、新しいメッセージが受信されるまでそれを再有効化できなくする。この構成では、単調に減少する1組の適用可能なルールが必ずあるようにする。他のそのような構成では、各ファイア後にデクリメントさせられるルール用のリミット・カウンタが設けられる。他のそのような構成では、時間の経過と共にデクリメントするリアルタイム・カウンタが設けられる。
【００２５】
以下に詳しく論じるように、ルール・ストア260の態様は、少なくともルール要素およびアクション要素を使用して各ルールを指定する。ルール要素は、クライアント要求との一致についての基準を指定する。ある態様では、ルール要素は、クライアント要求内の他の文字に置き換わることのできるワイルドカードを含んでよい。さらなる態様では、ルール要素は、対応する構文ルールと共に、ルール要素が、より複雑な一致するクライアント要求の組を、その組のあらゆる考えられる要素を実際にリストにすることなく指定するのを可能にする正規表現を含んでよい。
【００２６】
さらなる態様では、一致エンジン240およびルール・ストア260は、文脈依存文法を利用してルールをアクティブにする。この態様では、一致エンジン240は、2つまたはそれ以上のメッセージのコンテンツの分析を使用して、ルールをアクティブにするかどうかを判定する。たとえば、文脈依存文法は、基準を満たす1つまたは複数の追加のメッセージが受信されるまで第1のメッセージに応じてルールをアクティブにすることはできない。他の例では、1つまたは複数の前のメッセージのコンテンツに基づいてメッセージに応じたルール・アクティベーションを抑制することができる。
【００２７】
アクション要素は、対応するルール要素と一致する受信されたメッセージに対してとるべきアクションを記述する。ある態様では、アクション要素は、一致するクライアント要求に関連するクライアントのためにサーバ170に送信すべき1つまたは複数の追加のメッセージのフォーマットを指定することができる。アクション要素は、正確なプリフェッチ・メッセージおよび/またはプリフェッチ・メッセージ用のテンプレートを指定することができる。後者の場合、テンプレートは、クライアント要求の属性または他のシステム属性を使用して完全なプリフェッチ・メッセージを形成することによって完成することができる。
【００２８】
本発明の追加の態様は、プリフェッチされた要求のデータがクライアント110とのWAN接続218に負担をかけるのを防止し、それによって、クライアント110によってサーバ170から明示的に要求されたデータが遮断または遅延されるスロットリング・システムを含んでよい。これらの態様では、一致エンジン240およびルール・ストア260の動作をプリフェッチ・スロットル270によって阻止することができる。受信された要求115と同一ではない新しいメッセージ280は、プリフェッチ要求とみなされ、このようなメッセージの生成をプリフェッチ・スロットル270によって制限することができる。プリフェッチ・スロットル270は、プリフェッチ・メッセージ280の生成を追跡し、生成されたメッセージの数が構成可能な限界に達したときにルール・ファイアによるそのようなメッセージの生成を阻止する（プリフェッチをスロットルする）。追加の態様では、プリフェッチ・スロットル270は、1つまたは複数のプリフェッチ・メッセージ280によって返されるデータの全サイズ、プリフェッチ・メッセージおよびその応答に使用されるネットワーク・パケットの総数、プリフェッチ・メッセージおよびその応答に費やされる時間、または1つまたは複数のプリフェッチ・メッセージおよびその応答の他の個々の属性または総属性に応じて、生成されるメッセージの数を制限することができる。さらなる態様では、このスロットリングが行われる点で、プリフェッチがスロットルされていることを示すメッセージが、クライアント側プロキシ130のプリフェッチ・スロットル・コントロール220にも送信される。スロットリングが行われた後、（前述のように）クライアント側プロキシ130の結果キャッシュ210の結果が使用されるか、または無効化チェッカ230の判定によって結果キャッシュ210が無効化されるまでプリフェッチは再開されない。
【００２９】
受信された要求115に対応する結果は、一対の最適化コーデック216、215を通じてクライアント側プロキシ130に送り返され、クライアント側プロキシ130は、ある態様では、変更されていない結果をクライアント110に転送する。プリフェッチ・メッセージ280に対応する結果は、それに応じてマーク付けされ、一対の最適化コーデック216、215を通じてクライアント側プロキシ130に送信され、クライアント側プロキシ130は、結果を結果キャッシュ210に付加し、クライアント110には何も送信しない。
【００３０】
さらなる態様では、クライアント要求に関連する2つまたはそれ以上のプリフェッチ・メッセージおよびその対応する応答メッセージが、クライアント側プロキシに転送される前に併せてバンドリングまたはパッケージングされる。たとえば、サーバ側プロキシは、できるだけ多くのプリフェッチ・メッセージおよび対応する応答メッセージの、単一のネットワーク・パケットへのバンドリングを試みることができる。メッセージのバンドルについてのパケットのデータ・サイズ限界に達するかまたは時間限界に達した後、サーバ側プロキシは、場合によってはクライアント側プロキシへの複数のメッセージを含むパケットを転送する。サーバ側プロキシは、残りのメッセージに対してこのバンドリングを繰り返す。このことは、プリフェッチ・メッセージおよびその対応する応答をクライアント側プロキシに伝達するのに必要なネットワーク・パケットの数を最小限に抑え、それによってネットワーク性能を向上させる効果を有する。
【００３１】
いくつかの状況では、「結果」メッセージが、サーバから通知として送信され、すなわち、そのメッセージを開始する対応する要求なしに送信される。他の用途のうちで、このような通知は、特定の共有データ項目の状況の変化を、このような項目に関心を持つ可能性があるクライアントに示すのに使用されることが多い。このような通知は、サーバ側プロキシ150において通知レシーバ250によって受信される。無効化チェッカ230と同様に、通知レシーバ250は、受信された通知を分析し、受信された通知が結果キャッシュ210内のプリフェッチされキャッシュされた情報を無効化する通知であるかどうかを判定する。そうである場合、通知レシーバ250は、クライアント側ネットワーク・プロキシ130に無効化メッセージを送信する。通知レシーバ250はまた、その通知が、修正不能な問題が発生したことを示していると判定し、致命的エラー・メッセージをクライアント側ネットワーク・プロキシ130に送信する。
【００３２】
図3Aおよび3Bは、本発明の態様によるサーバ側ネットワーク・プロキシでデータを処理する方法を示している。図3Aは、本発明の態様による、クライアント側プロキシを介してクライアントから受信されたメッセージを処理する方法300を示している。段階305で、サーバ側プロキシは、サーバを対象とするクライアント要求メッセージをクライアント・アプリケーションから受信する。ある態様では、クライアント要求メッセージはクライアント側プロキシを通過し、クライアント側プロキシは、結果キャッシュ内のデータを使用してクライアント要求メッセージの要求を満たすことができるかどうかを判定する。結果キャッシュ内のデータを使用してクライアント要求メッセージの要求を満たすことができない場合、クライアント側プロキシはクライアント要求メッセージをサーバ側プロキシに転送する。
【００３３】
段階310では、クライアント要求メッセージをエラーを導入せずにサーバに転送できるかどうかを判定する。ある態様では、クライアント要求が、サーバ側プロキシによってすでに発行されているプリフェッチされたメッセージと整合しない場合、クライアント要求メッセージをサーバに送信することはできない。これは、サーバ側プロキシによって使用されるルール・セットが一連の1つまたは複数の関連するクライアント要求メッセージを正しく予想できなかった場合に生じる可能性がある。クライアント要求メッセージをサーバに送信できない他の理由は、たとえばアウト・オブ・オーダー・クライアント・メッセージ要求または予想されないクライアント・メッセージ要求のためにクライアント要求メッセージが回復できないトランザクション・エラーを生じさせることである。
【００３４】
クライアント要求メッセージをサーバに安全に送信できる場合、方法300は、段階315に進む。逆に、クライアント要求メッセージをサーバに安全に送信できない場合、方法300は段階320に進む。段階320では、結果キャッシュまたは段階305で受信されるクライアント要求メッセージの代わりにシステムによって予想されるプリフェッチ・メッセージを記憶するキャッシュの部分のような結果キャッシュの一部を無効化すると、クライアント要求メッセージのサーバへの送信が安全になるかどうかを判定する。そうである場合、方法300は段階325に進み、クライアント側プロキシの結果キャッシュのすべてまたは一部を無効化する。ある態様では、段階325は、結果キャッシュのすべてまたは一部を無効化し、関連するデータを破棄することを指定するメッセージを適切なクライアント側プロキシに送信する。方法300は次に、段階325から段階315に進む。
【００３５】
ある態様では、サーバ側プロキシは、クライアント要求メッセージがサーバ側プロキシにおけるルールと一致するときに、全体またはルール・ベースの部分のようなキャッシュ無効化ポリシーをクライアント側プロキシに発行する。後述のように、クライアント側プロキシは、キャッシュ・ミスが生じたときにこのキャッシュ無効化ポリシーを使用して、クライアント側プロキシのすべてを無効化するかまたはその一部を無効化するかを判定する。
【００３６】
段階320で、クライアント側プロキシ結果キャッシュが無効化された場合でもクライアント要求メッセージをサーバに安全に送信できると判定された場合、段階330で、クライアント要求メッセージが終了する。こうなる可能性のあるのは、たとえば、アウト・オブ・オーダー・クライアント要求メッセージによって回復できないトランザクション障害が生じた場合である。段階330のある態様では、サーバ側プロキシはサーバならびにそのピア・クライアント側プロキシとの接続を閉鎖し、クライアント側プロキシはクライアント・アプリケーションにエラーを返さなければならない。
【００３７】
段階310または段階325のいずれかの後で、段階315は、クライアント要求メッセージを対象となるサーバに処理のため転送する。ある態様では、サーバ側プロキシは、クライアント要求メッセージをサーバによって返される任意の結果メッセージと照合するために、クライアント要求メッセージの記録を維持する。
【００３８】
段階315の後で、段階335では、クライアント要求メッセージが、サーバ側プロキシによって維持されている1組のルールと比較される。ある態様では、段階335で、クライアント要求メッセージが1つまたは複数のルールと一致したことに応じてクライアント・アプリケーションのために1つまたは複数のプリフェッチ・メッセージがサーバに発行される。プリフェッチ・メッセージは同時に発行するかまたは順次発行することができる。ある態様では、サーバ側プロキシは、クライアント要求メッセージと共にサーバに送信されるプリフェッチ・メッセージの記録を維持する。さらなる態様では、上述のトラフィック・スロットリング・システムを使用して段階335を無効にすることができる。方法300は、段階335の後で段階305に戻り、クライアント側プロキシからのさらなるメッセージを待つ。
【００３９】
図3Bは、サーバから受信されたメッセージを処理する方法350を示している。代わりの態様では、明示的に示される場合を除いて必要な同期またはシーケンス付けがないために、これらの段階を異なる順序で実行することができる。段階355で、サーバからメッセージが受信される。段階360で、受信されたメッセージが、サーバ側プロキシによって事前に受信されているクライアント要求メッセージへのサーバ応答であるかどうかが判定される。受信されたメッセージが、サーバ側プロキシによって事前に受信されているクライアント要求メッセージへのサーバ応答である場合、方法350は、段階365に進む。ある態様では、サーバ側プロキシによって維持されているクライアント要求メッセージの記録によってこの比較を容易にすることができる。
【００４０】
逆に、段階360で、受信されたメッセージがサーバ側プロキシによって事前に受信されているクライアント要求メッセージへのサーバ応答ではないと判定された場合、段階370で、クライアント要求メッセージが1つまたは複数のルールと一致したことに応じてクライアント・アプリケーションのためにサーバ側プロキシによって送信されたプリフェッチ・メッセージへのサーバ応答であるかどうかを判定する。そうである場合、方法350は段階375に進む。ある態様では、この比較はサーバ側プロキシによって維持されているプリフェッチ・メッセージの記録によって容易にすることができる。
【００４１】
段階375では、メッセージがマーク付けされラッピングされる。ある態様では、メッセージが追加のデータとラッピングされ、クライアント側プロキシによるキャッシングが容易になる。ある態様では、この追加のデータは、対応するプリフェッチ要求のコピーまたはそれから得られた識別子を含んでよい。これによって、クライアント側プロキシは、将来のクライアント要求を結果キャッシュに記憶されているデータと照合することができる。段階375の後で、方法350は段階365に進む。
【００４２】
段階375または段階360の後で、段階365において、クライアント側プロキシに、メッセージを送信するか、または以下およびその他の箇所で論じるように、メッセージのバンドルを送信する。
【００４３】
さらなる態様では、段階375で、複数のメッセージをネットワーク・パケット内にバンドリングしてネットワーク性能を向上させることができる。この態様では、段階375の後で、パケットが満杯でない場合には段階365をバイパスすることができる。この場合、方法350は次に、段階355に直接進み、サーバからの次のメッセージを待つ。さらなる態様では、部分的に充填されたパケットに関連するサーバからの他のメッセージがある期間内に受信されなかった場合、方法350は段階365に戻り、部分的に充填されたパケットを適切なクライアント側プロキシに送信する。
【００４４】
段階370に戻ると、受信されたメッセージがプリフェッチ・メッセージに対するサーバ応答ではない場合、方法350は段階380に進む。段階380では、受信されたメッセージがクライアント側プロキシの結果キャッシュ内のデータを無効化するメッセージであるかどうかを判定する。そうである場合、方法350は、段階385に進み、クライアント側プロキシの結果キャッシュを無効化する。ある態様では、段階385で、キャッシュ無効化ポリシーを提供するクライアント側プロキシにメッセージが送信される。クライアント要求がキャッシュ内のどのデータとも一致しないときに生じるキャッシュ・ミスに応じて、クライアント側プロキシは、キャッシュ無効化ポリシーに従ってその結果キャッシュのすべてまたは一部を破棄する。キャッシュ無効化ポリシーは、結果キャッシュ内のすべてのデータを破棄するか、またはルールと一致するデータのみを破棄することを指定することができる。
【００４５】
ある態様では、サーバ側プロキシは、クライアント側プロキシの結果キャッシュのすべてまたは一部を無効化する。たとえば、これは、一対のプロキシ・ルール、ルールAおよびルールBを使用して行うことができる。ルールAは、クエリ一致基準、プリフェッチ指令、および「サーバへのキャッシュ・フラッシュのない転送ミス」のキャッシュ・ミス・ポリシーから成る。ルールBは、一致基準および（部分または全）アクティブ・キャッシュ・フラッシュ指令から成る。アクティブ・フラッシュ・メッセージはクライアント側ポリシーに送信され、クライアント側プロキシにキャッシュをフラッシュさせる。
【００４６】
この一対のルールは、サーバ側プロキシが、ルールAを使用して、クエリの大きなリストをプリフェッチしクライアント側プロキシを介して送信する場合に使用することができる。クライアントは、クライアント側プロキシにおけるキャッシュ・ミスであるクライアント要求メッセージを備えたこれらのプリフェッチ・クエリのサブセットのみを要求する。ある時点で、クライアントはクライアントでキャッシュ・ミスを生じさせる特定のクライアント要求メッセージを発行する可能性がある。キャッシュ・ミスを生じさせる他の同様のクライアント要求メッセージと同様に、この特定のクライアント要求メッセージは、実行すべきサーバ側プロキシに転送される。サーバ側プロキシでは、このクライアント要求メッセージがルールBと一致する。ルールBの基準は、クライアントがクライアント側プロキシの結果キャッシュに記憶されている残りのプリフェッチされた要求をもはや要求することがないことを示すクライアント要求メッセージとルールBが一致するように指定される。クライアント要求メッセージがルールBと一致した結果として、サーバ側プロキシは、クライアント側プロキシの結果キャッシュの一部または全体をパージするメッセージをクライアント側プロキシに送信する。
【００４７】
逆に、受信されたメッセージが、結果キャッシュを無効化することを必要としないメッセージである場合、方法350は段階390に進む。段階390では、メッセージが致命的エラーを示しているかどうかが判定される。そうである場合、方法350は、段階395に進み、それにより方法は終了する。さもなければ、方法350は、段階390から段階355に戻り、さらなるメッセージを待つ。
【００４８】
図4は、本発明の態様による、クライアント側ネットワーク・プロキシでデータを処理する方法を示している。図4Aは、クライアントから受信されたメッセージを処理する方法400を示している。段階405では、クライアント・アプリケーションからクライアント要求メッセージが受信される。段階410では、クライアント要求メッセージが、クライアント側ネットワーク・ポリシーの結果キャッシュに記憶されているデータと一致するかどうかが判定される。ある態様では、結果キャッシュは、プリフェッチ・メッセージおよびそれに対応する結果メッセージを記憶する。この態様では、段階410は、結果キャッシュにおいて、受信されたクライアント要求メッセージと一致するプリフェッチ・メッセージを探索する。さらなる態様では、ハッシュ・テーブルなどの技術を使用して、結果キャッシュにおける受信されたクライアント要求メッセージと一致する結果メッセージの探索を容易にすることができる。
【００４９】
段階410で、結果キャッシュが受信されたクライアント要求メッセージに対応するデータを含んでいないと判定された場合、段階415で、受信されたクライアント要求メッセージがサーバに送信され処理される。ある態様では、段階415で、受信されたクライアント要求メッセージがサーバ側プロキシに転送され、上述のように処理される。方法400は次に段階405に戻り、さらなるクライアント要求メッセージを待つ。
【００５０】
逆に、段階410で、結果キャッシュが受信されたクライアント要求メッセージに対応する1つまたは複数の結果メッセージを含むと判定された場合、段階420で、対応する結果メッセージが結果キャッシュから削除される。段階425で、結果メッセージがクライアント・アプリケーションに転送され、それによって、サーバとのさらなる通信を開始する必要無しにクライアント要求メッセージの要求が満たされる。
【００５１】
ある態様では、クライアント側ネットワーク・プロキシは、プリフェッチ・スロットル・コントロールを含んでよい。この態様では、段階430で、追加のプリフェッチ・メッセージおよび対応する結果メッセージに関連するデータを含むネットワーク・トラフィックが、サーバ側ネットワーク・プロキシからスロットルまたは中断されるかどうかが判定される。そうである場合、段階435で、サーバ側ネットワーク・プロキシが追加のプリフェッチ・メッセージおよび対応する結果メッセージに関連するデータのクライアント側プロキシへの送信を再開できることを示す「アンスロットル」通知がサーバ側ネットワークに送信される。そうでない場合、方法400は、段階405に戻りクライアント・アプリケーションからの追加のクライアント要求メッセージを待つ。同様に、方法400は、段階440の後で段階405に戻る。
【００５２】
図4Bは、本発明の態様によるサーバ側プロキシから受信されるメッセージを処理する方法450を示している。代わりの態様では、明示的に示される場合を除いて必要な同期またはシーケンス付けがないために、これらの段階を異なる順序で実行することができる。
【００５３】
段階455で、サーバ側プロキシからメッセージが受信される。メッセージは、特にクライアント側プロキシ、またはクライアント・アプリケーションに送ることができる。後者の場合、クライアント側プロキシは、サーバまたはサーバ側プロキシによってクライアント・アプリケーションに送られるメッセージをインターセプトする。段階460で、受信されたメッセージが、クライアント側プロキシの結果キャッシュのすべてまたは一部の無効化を要求するメッセージであるかどうかが判定される。そうである場合、次に段階465で、クライアント側プロキシは、その結果キャッシュの適切な部分におけるデータを破棄するかまたはその他の方法で無効化する。方法450は、段階465の後で段階455に戻り、サーバ側プロキシからの追加のメッセージを待つ。
【００５４】
逆に、段階460で、メッセージが結果キャッシュの任意の部分の無効化を要求するメッセージではないと判定された場合、次に段階470で、メッセージがキャッシュすべきデータを含んでいるかどうかが判定される。ある態様では、キャッシュすべきデータを含むメッセージは、クライアント・アプリケーションのためにサーバ側プロキシによって発行される1つまたは複数のプリフェッチ・メッセージに対応する1つまたは複数の結果メッセージを含んでよい。さらなる態様では、キャッシュすべきデータを含むメッセージは、受信されたクライアント要求メッセージと、結果キャッシュに記憶されている対応する結果メッセージとの照合を容易にするプリフェッチ・メッセージのコピーまたはそれから得られる識別子を含んでよい。
【００５５】
段階470で、サーバ側ネットワーク・プロキシから受信されたメッセージに、キャッシュすべきデータが含まれていると判定された場合、段階475で、メッセージのデータがクライアント側ネットワーク・プロキシの結果キャッシュに追加される。逆に、段階470で、サーバ側ネットワーク・プロキシから受信されたメッセージに、キャッシュすべきデータは含まれていないと判定された場合、段階480で、受信されたメッセージは、クライアント・アプリケーションなどのその目的地に転送される。方法450は、段階480または475の後で段階455に戻り、追加のメッセージを待つ。
【００５６】
図5A〜5Cは、本発明の態様によるシステムの要素間のメッセージ・フローの例を示している。図5Aは、クライアント・アプリケーション510からクライアント側ネットワーク・プロキシ520およびサーバ側ネットワーク・プロキシ530を通ってサーバ・アプリケーション540に至るクライアント要求メッセージ501の単純なフローを示している。対応する応答メッセージ502は、サーバ・アプリケーション540からサーバ側ネットワーク・プロキシ530およびクライアント側ネットワーク・プロキシ520を通ってクライアント・アプリケーション510に至る。図5Aでは、クライアント側ネットワーク・プロキシ520およびサーバ側ネットワーク・プロキシ530は、クライアント要求メッセージ501および応答メッセージ502を調べることができるが、クライアント510とサーバ540との間の通信には影響を及ぼさない。
【００５７】
図5Bは、クライアント・アプリケーション510からクライアント側ネットワーク・プロキシ520へのクライアント要求メッセージ503のフローを示している。この例では、クライアント要求メッセージ503は、クライアント側プロキシの結果キャッシュ内のキャッシュされている応答メッセージに対応する。したがって、クライアント側プロキシ520は、その結果キャッシュから応答メッセージ504を取り込んでクライアント・アプリケーション510に返す。この例では、システムの他の要素との追加の通信は必要とされない。
【００５８】
図5Cは、プリフェッチがどのように行われるかを示し、したがって、クライアント側ネットワーク・プロキシ520がどのように、すでに図5Bに示されているようにキャッシュされている結果を転送できるかを示している。クライアント・アプリケーション510からのクライアント要求メッセージ505は、クライアント側プロキシ520で調べることができるが、この例では、キャッシュされている結果とは一致しない。したがって、クライアント要求メッセージ505はサーバ側プロキシ530に転送され、そこで再び調べられる。この例では、クライアント要求メッセージは1つまたは複数のルールと一致し、サーバ側プロキシ530がメッセージ505aおよび505bを生成するのをトリガする。いくつかの態様では、サーバ側プロキシ530によって生成されるメッセージはこれより多くてもまたは少なくてもよく、この例では2つを使用することは重要ではない。メッセージ505aおよび505bはサーバ540に送信され、サーバ540は対応する結果メッセージ506aおよび506bを生成する。一つの構成では、505aは、未修正の直接要求505であり、したがって、対応する結果506aは、507aとしてクライアント側ネットワーク・プロキシ520に渡され、508aとしてクライアント510に渡される。しかし、505bはプリフェッチ・メッセージであり、したがって、対応する結果メッセージ506bは、キャッシュしメッセージ507b内にラッピングすべきデータとしてマーク付けされる。結果メッセージ507bがクライアント側ネットワーク・プロキシ520に送信されると、507bのコンテンツはクライアント側ネットワーク・プロキシ520の結果キャッシュに配置され、対応するメッセージがクライアント510に送信されることはない。
【００５９】
図6は、図2で説明したルール・ストア260内のルールをセットアップするのに使用できるようなルール例の要素を示している。図中に符号化されている例は以下のケースを取り込む。
【００６０】
メッセージがタイプ3であり、RPC ID 5と7つの引数を有するTDSフォーマットで符号化されたMicrosoft Project製品であるクライアントから、サーバ側プロキシがメッセージを受信し、そのメッセージのクエリ部分が以下の正規表現と一致するとき、以下のアクションが実行される：
タイプ3、rpc id 5であり、クエリ・ストリング「select proj_read_count, proj_locked, proj_read_write, proj_read_only, proj_id, proj_machine_id, proj_data_source from msp_projects where proj_name=<the _matched_sub_expression>」を有するプリフェッチTDSメッセージを送信する。
【００６１】
ルール要素610は、ルールの照合部分を記述する。アクション要素620は、対応するルール要素610と一致する受信されたメッセージに対してとるべき全メッセージ置換アクションを記述する。ルール要素610は、各アクション要素620が異なる全メッセージ置換を生じさせる複数の関連するアクション要素620を有してよい。引数アクション要素630は引数レベル置換を記述し、一方、アクション要素620は全メッセージ・レベル置換を記述する。アクション要素620は、各引数アクション要素630が異なる全メッセージ置換を生じさせる複数の関連する引数アクション要素630を有してよい。
【００６２】
例示のために図6のルール例について論じる。本発明の態様では、様々な種類のルールおよびアクション要素を含む任意の数のルールを使用することができる。さらに、様々な種類および範疇のクライアント・アプリケーション、様々なサーバ・アプリケーション、ならびに様々なメッセージ・フォーマットおよびプロトコルについてルールを指定することができる。一般に、本発明の態様は、クライアントが任意の種類の要求/応答プロトコルを使用してサーバ・アプリケーションと通信するシステムに適用することができる。たとえば、本発明の態様は、任意の種類のデータベース・サーバ、Java RMI、およびCORBAと共に使用することができる。
【００６３】
さらなる態様では、上述のようなプリフェッチおよびキャッシングのシステムおよび技術を事前肯定応答クライアント要求メッセージに拡張することができる。事前肯定応答は、クライアント側またはサーバ側ネットワーク・プロキシあるいはトランザクション・アクセラレータによってクライアント要求メッセージに対する合成応答を作成し、通常サーバによってクライアント要求メッセージに応じてクライアントに送信される肯定応答メッセージに置き換えることである。事前肯定応答を使用すると、クライアント要求メッセージを送信してから、サーバから肯定応答メッセージを受信するまでの間にクライアントが受ける遅延が軽減される。
【００６４】
いくつかのアプリケーションでは、事前肯定応答がデータ整合性の観点から安全ではない場合がある。したがって、ある態様では、事前肯定応答は、ネットワーク・プロキシおよびトランザクション・アクセラレータのデフォルト構成ではオフにされる。この場合、事前肯定応答は、特定の種類のトランザクションに対してのみ有効にすることができる。さらなる態様では、クライアント要求メッセージの周りにトランザクション境界を挿入することによって、データ整合性の安全性が保証される。
【００６５】
ある態様では、要求が事前肯定応答され得るかどうかを判定するためにクライアント側および/またはサーバ側プロキシでルールが使用される。第1の態様では、サーバ側ルール・エンジンは、着信クライアント要求メッセージを調べて、事前肯定応答メッセージで応答するのが安全であるかどうかを判定する。1つまたは複数のサーバ側ルールとクライアント要求メッセージが一致している場合、サーバ側プロキシは、ステートメントid、ハンドル、またはその他のトランザクション識別情報などの識別子をクライアント側プロキシに送信する。この識別子を使用して、クライアント側プロキシまたはトランザクション・アクセラレータによって事前肯定応答することのできる、同じまたは関連するトランザクション内の以後のクライアント要求メッセージが識別される。
【００６６】
ある態様では、クライアント側プロキシまたはトランザクション・アクセラレータは、識別子のみを使用するかまたは識別子と追加のクライアント側ルールを一緒に使用して、安全に事前肯定応答できる以後のクライアント要求メッセージを識別する。識別子と一致する以後のクライアント要求メッセージの識別に応じて、クライアント側プロキシまたはトランザクション・アクセラレータはただちに事前肯定応答メッセージをクライアントに返す。
【００６７】
一例を挙げれば、クライアント要求メッセージがサーバによって受信され処理されるとすれば、クライアントが、クライアントが様々な引数を有するSQLプロシージャをアップロードし繰り返し呼び出すことのような、一連のクライアント要求メッセージの結果に関心を抱かないときに事前肯定応答メッセージを使用することができる。
【００６８】
他の態様では、クライアント側プロキシまたはトランザクション・アクセラレータにおけるクライアント側ルールは、トランザクションで連続的ではないが頻繁に出される要求に使用される。ある態様では、クライアント側プロキシは、着信クライアント要求メッセージから識別子を生成する機能を含む。さらなる態様では、クライアント側プロキシは、クライアント側ルールに一致せずかつ事前肯定応答されないメッセージを含む、すべての着信クライアント要求メッセージの識別子を生成し記憶する。これによって、事前肯定応答できないクライアント要求メッセージが識別子同士の不一致のために誤識別されるのが防止される。
【００６９】
さらなる態様では、クライアント側ネットワーク・プロキシは、事前肯定応答される第1のクライアント要求メッセージの前にトランザクション開始点を挿入することによってデータ整合性の安全性をさらに保証する。クライアント側プロキシは、このトランザクション開始点要求に対するサーバ応答を破棄する。
【００７０】
よりさらなる態様では、クライアント要求メッセージに応じて送信される肯定応答メッセージを含むサーバ応答は、クライアント側プロキシによって受信される。クライアント側プロキシは、肯定応答メッセージに成功コードがあるかそれとも失敗コードがあるかを調べる。すでにクライアント側プロキシによって事前肯定応答されているクライアント要求メッセージに対する成功コードの場合、クライアント側プロキシは応答メッセージを冗長であるとして破棄する。すでにクライアント側プロキシによって事前肯定応答されているクライアント要求メッセージに対する失敗コードの場合、同じトランザクション内の、クライアントから受信される次のクライアント要求メッセージは、エラー応答を受信する。または、クライアント側プロキシは、失敗コードに応じて接続を切断する。
【００７１】
クライアント要求メッセージに対するすべての応答が成功を示し、非事前肯定応答可能クライアント要求メッセージが受信された場合、トランザクション・エンド・ポイント要求がサーバ側に送信される。成功応答を受信すると、保留中の非事前肯定応答可能要求がプロキシによってサーバ側に送信される。応答が不成功であると、非肯定応答がクライアントに送信されるか、またはクライアント側プロキシが接続を切断する。
【００７２】
さらなる態様では、クライアント側プロキシに戻る応答に基づいてスロットリング機構を使用することができる。クライアント側プロキシは、事前肯定応答された要求に対する未解決の応答の数が構成可能なしきい値を超えたときには事前肯定応答要求の生成を一時停止する。これによって、クライアント要求メッセージと事前肯定応答までの間の遅延が短くなるためにクライアントがサーバにフラッディングするのが防止される。
【００７３】
ある態様では、事前肯定応答を実現するために、図2のクライアント側ネットワーク・プロキシは、任意の一致エンジン240aおよびルール・ストア260aで補足される。任意の一致エンジン240aおよびルール・ストア260aは上述の一致エンジン240およびルール・ストア260に類似しており、事前肯定応答メッセージに関連して説明した追加の機能を有している。
【００７４】
図7は、本発明の態様によるサーバ側プロキシから受信されたメッセージを処理する方法700を示している。方法700は、図4Aの方法400に実質的に類似しており、方法700の段階405、410、415、420、425、430、および435は方法400の同じ番号を有する対応する段階と同様に動作する。しかし、段階405の後で、段階705において、クライアント要求メッセージが事前肯定応答ルールと一致するかどうかが判定される。クライアント要求メッセージが事前肯定応答ルールと一致しない場合、方法700は、上述のように段階410および以後の段階に進む。段階705で、メッセージが事前肯定応答ルールと一致しない場合、段階710で、事前肯定応答メッセージが生成されクライアントに送り返される。方法700は、段階710の後で段階405に戻る。
【００７５】
本発明についてその特定の態様に関して説明したが、これらの態様は本発明を例示するものに過ぎず、本発明を制限するものではない。さらに、上述のシステム・アーキテクチャは例示のためのものである。本発明は、スタンドアロン・アプリケーションまたは他のアプリケーションと一体化されたモジュールとして実現することを含め、多数の異なる形態で実現することができる。したがって、本発明の範囲は特許請求の範囲によってのみ決定すべきである。
【図面の簡単な説明】
【００７６】
本発明について図面を参照して説明する。  
【図１】本発明の態様と共に使用するのに適したクライアント、サーバ、プロキシ、および相互接続ネットワークの構成例を示す。
【図２】本発明の態様による、クライアント側プロキシおよびサーバ側プロキシの内部構成を示す。
【図３】本発明の態様による、クライアント側プロキシから受信されたメッセージを処理する方法を示す。
【図４】本発明の態様による、サーバ側プロキシから受信されたメッセージを処理する方法を示す。
【図５】本発明の態様による、クライアント側プロキシとサーバ側プロキシとの間のメッセージのフローを示す。
【図６】本発明の態様と共に使用するのに適したサーバ側プロキシのルール・ストア内のルールの例を示す。
【図７】本発明の態様による、サーバ側プロキシから受信されたメッセージを処理する方法を示す。
【図１】
2008537814.tif 000004
【図２】
2008537814.tif 000005
【図３Ａ】
2008537814.tif 000006
【図３Ｂ】
2008537814.tif 000007
【図４Ａ】
2008537814.tif 000008
【図４Ｂ】
2008537814.tif 000009
【図５Ａ】
2008537814.tif 000010
【図５Ｂ】
2008537814.tif 000011
【図５Ｃ】
2008537814.tif 000012
【図６】
2008537814.tif 000013
【図７】
2008537814.tif 000014