JP2004173287A - パックし圧縮したバッファを使用してクライアント−サーバ間の通信を向上させるシステムおよび方法 - Google Patents

Abstract

【課題】 サーバ上で多数の応答の組をバッチし、その応答をクライアントに単一のバッチ（すなわち「連鎖された」または「パックされた」バッチ）で送信する方法を提供すること。
【解決手段】 応答の組をそれぞれ難読化し、かつ／または圧縮することができる。クライアントがバッチを受信すると、各組は個々に処理される。クライアントは、処理できる未圧縮の応答の組のサイズを伝えるように構成することができる。サーバは、この情報を使用して適切なサイズの応答の組を作成することができ、また応答の組を圧縮しても、あるいは圧縮しなくてもよい。サーバは、サーバのバッファが満杯になる、あるいはほぼ満杯になるまで、応答の組を連鎖させ、圧縮、未圧縮に関わらず、組を引き続き連鎖させることができる。次いで連鎖された応答の組をクライアントに送信することができ、応答の各組を個々に処理することができる。
【選択図】 図６

Description

本発明は一般にコンピュータネットワークに関し、より詳細には、電子メールなどクライアントアプリケーションとサーバアプリケーションの間で通信するための方法に関する。

電子メールは、通信のための重要な方法になってきている。電子メールシステムには一般に、サーバ構成要素（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒなど）およびクライアント構成要素（Ｍｉｃｒｏｓｏｆｔ ＯｕｔｌｏｏｋやＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓなど）などがある。これらの構成要素は一般に、コンピューティング装置（サーバ、ＰＣ、ラップトップ、ＰＤＡなど）上で実行するように構成されているソフトウェアアプリケーションである。

何種類かの電子メールサーバは、専用の電子メールクライアントではなく、インターネットブラウザクライアント（Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒなど）を介して電子メールをアクセスできるように構成されている。こうしたシステムでは、ブラウザは電子メールサーバと対話し、クライアントシステム上で実行する必要がある任意の機能は、ブラウザ（ＪａｖａＳｃｒｉｐｔ（登録商標）によってダウンロードする）を介して、またはＡｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅの使用を介して実行される。

クライアントとサーバとはしばしば帯域幅が低く待ち時間の大きいネットワーク（遅いダイヤルアップ接続など）によって接続されるため、多くの電子メールクライアントおよびサーバは、保留中の命令を格納し、次いでいくつかの命令をいっしょに送信するように構成されている。例えば、クライアントは、オープンフォルダコマンド（ｏｐｅｎ ｆｏｌｄｅｒ ｃｏｍｍａｎｄ）およびオープンカレンダコマンド（ｏｐｅｎ ｃａｌｅｎｄｅｒ ｃｏｍｍａｎｄ）を送信するのではなく、第１の命令を格納し、それを第２の命令と結合して２つの命令をいっしょに送信することができる。各伝送に関連する何らかのオーバーヘッドがあるため、この格納、結合、送信方式によって、結果的にネットワークおよびサーバのリソースをより効率良く使用できるようになる。

従来技術のシステムの中には、各クライアントおよびサーバに割り振られ、命令および／またはデータをいっしょに送信するまでのデータ格納エリアとして働く単一のバッファに依存するものもある。こうしたシステムの一例では、クライアントは、バッファを使用してサーバに送信すべき命令およびデータを格納する。バッファが満杯になる、あるいはほぼ満杯になると、クライアントは、バッファの中身をサーバに送信する。サーバは、受信した中身をバッファに格納して、命令の解析および実行を開始する。処理すべき次の要求を指定するポインタを使用してもよい。

サーバは、その応答をそのバッファ内でアセンブルし、そのバッファの中身がクライアントのバッファのサイズを超えないようにする。サーバがそのバッファ内のすべての要求を完了することができない（例えばバッファに十分な空間がない）場合、サーバは、完了していない要求をバッファに書き込み、完了した応答とともにそれらをクライアントに送り返す。

一部のシステムでは、クライアントを、クライアントがどれだけのメモリをそのバッファに割り振ることを望んでいるかを指定するように構成することができる。例えばクライアントは、３２ＫＢだけをそのバッファに充てることをサーバに示すことができる。これに応答してサーバは、一度に３２ＫＢを超えるものをクライアントに送信しないようにする。

多くの電子メールクライアントとサーバとの間で帯域幅が低く待ち時間の大きい性質の接続が使用されることを考慮すると、性能を向上させるシステムおよび方法が必要である。

以下に、本発明のいくつかの態様を基本的に理解できるようにするために本発明の簡単な概要を示している。この概要は、本発明の広範な概観ではない。本発明の鍵となる／重要な要素を識別するもの、あるいは本発明の範囲を述べるものではない。その唯一の目的は、後述するより詳細な説明の導入部として簡略化した形で本発明のいくつかの概念を示すことである。

応答を要求する方法を開示する。一実施形態では、本方法は、電子メールクライアントと電子メールサーバとの間で使用するために最適化される。この方法は、第１のバッファをクライアント上に割り振り、次いでそのバッファを使用してサーバに対する１つまたは複数の要求をアセンブルすることを含むことができる。また、クライアントを、第１のバッファの中身にヘッダを添付するように構成し、ヘッダを、サーバからの要求に対する応答をクライアントに戻す前に圧縮すべきかどうかについてのインジケータを含むように構成することもできる。

サーバの別の選択肢は、要求をクライアントに送信する前に、その要求を難読化する、あるいは暗号化することである。これらの機能のための対応するインジケータビットをヘッダに含めることもできる。

いくつかの実装形態では、クライアントを、ＲＰＣ（遠隔手続き呼出し）を使用して要求を実施するように構成することができる。こうした実装形態の中には、ヘッダを固定長の遠隔手続き呼出しヘッダとすることができるものもある。一部の実施形態では、ヘッダに、クライアントが処理するように構成されている１組の応答の未圧縮サイズについてのインジケータをさらに含めることもできる。

また、データをサーバからクライアントに転送する方法も開示する。この方法は、クライアントから１バッチの要求を受信することを含むことができる。要求の１つは、連鎖を使用して要求に対する応答を送信するようサーバに求める要求である。これに応答して、サーバは、クライアントへの第１の組の応答をアセンブリし、圧縮し、それに関する情報（そのサイズなど）を提供するヘッダを添付することができる。サーバは、いくつかの応答の組についてこのプロセスを繰り返し、次いでヘッダおよび応答を１つのバッチでクライアントに送信することができる。各ヘッダは、そのバッチ内の次のヘッダへのポインタを含むことができ、それによってクライアントは応答を適切に復号することができる。そのバッチ内の最後のヘッダは、それが最後の応答に相当することを示す特殊タグで構成することができる。

一部の実装形態では、クライアントを、そのバッファのサイズをサーバに伝えるよう構成することができる。次いでサーバは、この情報を使用してそれ自体のバッファのサイズを設定し、それによって、クライアントが応答を受信したときに、その応答によりクライアントのバッファをオーバーフローするのを防ぐ。さらに、クライアントを、処理するよう構成された１組の未圧縮の応答のサイズを伝えるよう構成することができる。サーバは、この情報を使用して適切なサイズの応答の組を作成することができ、応答の組を圧縮しても、あるいは圧縮しなくてもよい。サーバは、サーバのバッファが満杯になるまで、あるいはほぼ満杯になるまで、応答の組を連鎖させ、圧縮、未圧縮に関わらず、組を引き続き連鎖させることができる。次いで連鎖された応答の組をクライアントに送信することができ、クライアントは、（該当する場合）その組を伸張し、応答の各組を個々に処理することができる。

サーバ上で複数の応答の組を圧縮し、これらを単一のバッチ（すなわち「連鎖された」または「パックされた」バッチ）で送信することによって、クライアントとサーバとの間の通信の性能が向上する可能性がある。従来のシステムは、圧縮を使用してクライアント−サーバ間で送信される総バイト数を低減させていたが、送信前にバッファをパックすることによって、より多くのデータを、バッファに追加し、各セッションで送信することができ、したがって待ち時間の大きいネットワークの場合に合計ラウンドトリップ回数が低減する。

この技術の応用範囲は広いが、特に電子メールクライアントと電子メールサーバの間の操作により適している。例えばこの方法を、ＣｏｐｙＭｅｓｓａｇｅｓなど高速転送操作のためにＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋとともに使用することができる。この機能は、サーバからクライアントにメッセージヘッダをコピーする。

本発明の他の特徴および利点を以下の説明に記載する。その一部は説明から明らかになり、一部は本発明の実施によって学びとることができる。本発明の特徴および利点は、添付の特許請求の範囲で特に指摘した手段および組合せによって実現し、得ることができる。本発明のこれらおよび他の特徴は、以下の説明および添付の特許請求の範囲から十分に明らかになり、あるいは以下に記載した本発明の実施によって学びとることができる。以下の詳細な説明に含まれる見出しは、単に構成上付したものであり、本発明の範囲または添付の特許請求の範囲を制限し、あるいは限定するためのものではない。
他の利点は、以下の詳細な説明を図面と併せ読むことによって明らかになる。

以下の説明では、本発明の様々な態様を説明する。説明上、本発明を完全に理解できるようにするために特定の構成および詳細を記載する。しかし、本発明を特定の詳細無しに実施することができることも、当技術分野の技術者であれば理解されよう。さらに、本発明を不明瞭にしないために、よく知られている特徴を省略、あるいは簡略化する場合がある。

本発明の様々な実施形態を説明する前に、本発明の様々な実施形態を実施することができるコンピュータおよびネットワーキング環境について説明する。必須ではないが、本発明は、コンピュータによって実行されるプログラムによって実施することができる。一般にこうしたプログラムには、特定のタスクを実行する、あるいは特定の抽象データ型を実装するルーチン、オブジェクト、構成要素、データ構造などがある。「プログラム」という用語は、本明細書で使用する場合、単一のプログラムモジュール、あるいは協働する複数のプログラムモジュールを意味する場合がある。「コンピュータ」という用語は、本明細書で使用する場合、パーソナルコンピュータ（ＰＣ）、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースのプログラム可能家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、マイクロプロセッサまたはマイクロコントローラを有する家庭用電気器具、ルータ、ゲートウェイ、ハブなど、１つまたは複数のプログラムを電子的に実行する任意の装置を含む。また本発明は、通信ネットワークを介してリンクされている遠隔処理装置によってタスクが実行される分散コンピューティング環境でも使用することができる。分散コンピューティング環境では、プログラムをローカルおよびリモートの双方のメモリ記憶装置に配置することができる。

次に本発明を使用できるネットワーク化環境の一例を、図１に関連して説明する。ネットワークの例は、クラウドで表したネットワーク１１を介して互いに通信するいくつかのコンピュータ１０を含む。ネットワーク１１は、ルータ、ゲートウェイ、ハブなど、よく知られている多くの構成要素を含むことができ、それによってコンピュータ１０が有線および／または無線の媒体を介して通信できるようになる。ネットワーク１１を介して互いに対話するとき、１つまたは複数のコンピュータ１０は、他のコンピュータ１０に対してクライアント、サーバ、またはピアとして働くことができる。したがって、たとえ本明細書に含まれる特定の例がこれらのタイプのコンピュータのすべてに言及していなくても、本発明の様々な実施形態をクライアント、サーバ、ピア、またはそれらの組合せで行うことができる。

図２を参照すると、本明細書に記載した本発明のすべてまたは一部を実施できるコンピュータ１０の基本的な構成の例を示している。その最も基本的な構成では、コンピュータ１０は一般に、少なくとも１つの処理ユニット１４およびメモリ１６を含む。処理ユニット１４は、本発明の様々な実施形態に従ってタスクを行うよう指示する命令を実行する。こうしたタスクを実行する際に、処理ユニット１４は、電子信号を相手側のコンピュータ１０、およびコンピュータ１０の外部の装置に送信して何らかの結果をもたらすことができる。コンピュータ１０の正確な構成およびタイプに応じて、メモリ１６は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭやフラッシュメモリなど）、またはこの２つの何らかの組合せとすることができる。この最も基本的な構成を、図２に破線１８で例示する。

コンピュータ１０は、他の特徴および／または機能を備えていてもよい。これに限定されないが、コンピュータ１０は、例えば磁気または光学式のディスクまたはテープなどの追加の記憶装置（取外し可能記憶装置２０および／または取外し不可記憶装置２２）を含んでいてもよい。コンピュータ記憶媒体には、コンピュータ実行可能命令、データ構造、プログラムモジュール、他のデータを含む、情報を格納するための任意の方法および技術で実施される揮発性および不揮発性、取外し可能および取外し不可の媒体などがある。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、所望の情報を格納するために使用でき、コンピュータ１０からアクセスできる他の任意の媒体などがある。こうしたコンピュータ記憶媒体であればどんなものでもコンピュータ１０の一部とすることができる。

また、コンピュータ１０は、装置が他の装置と通信できるようにする通信接続２４を含んでいることが好ましい。通信接続（例えば通信接続２４の１つ）は、通信媒体の一例である。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波、または他の移送機構などの変調されたデータ信号の形の他のデータを実施する。これには任意の情報配布媒体が含まれる。「通信媒体」という用語は、それだけには限定されないが、一例として、有線ネットワーク、または直接配線接続（ｄｉｒｅｃｔ−ｗｉｒｅｄ ｃｏｎｎｅｃｔｉｏｎ）などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体を含む。「コンピュータ可読媒体」という用語は、本明細書で使用する場合、コンピュータ記憶媒体および通信媒体の双方を含む。

また、コンピュータ１０は、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置２６を含んでいてもよい。また、ディスプレイ３０、スピーカ、プリンタなどの出力装置２８を含んでいてもよい。こうしたすべての装置は、当技術分野ではよく知られており、ここで詳細に説明する必要はない。

（バッファパッキング）
図３を参照すると、本発明を実施できる電子メールネットワーク１００の一例を示している。本発明の電子メールネットワーク１００は、要求および応答の交換を使用して、電子メールネットワーク１００内のクライアント構成要素とサーバ構成要素との間にクエリおよびデータを渡す。実際には、プロトコルの性能は、電子メールネットワーク１００など、電子メールネットワーク内のクライアントとサーバとの間の通信の実施に使用される基礎を成す通信ネットワーク移送機構によって影響を受けることがある。例えば、基礎的通信ネットワーク移送機構として遠隔手続き呼出し（ＲＰＣ）を使用する電子メールネットワークでは、より小さいサイズ（例えば２ＫＢ）の遠隔手続き呼出しを複数回行うことにより、大きいサイズ（例えば３２ＫＢ）の遠隔手続き呼出しを１回だけ行う方がはるかに効率的となり得る。こうした電子メールネットワークにおいて性能を向上させることが知られている１つの方法は、複数の要求および／応答をバッファに入れて１回の遠隔手続き呼出しで送信することである。

一例として、図３は、電子メールクライアント１０２と電子メールサーバ１０６との間の要求および応答の交換を示している。これらの一方または双方は、例えばコンピュータ１０のように構成することができる。この例では、電子メールクライアント１０２は、送信バッファ１０４を割り振り、電子メールサーバ１０６に送信される要求で送信バッファ１０４を満たす。要求は、１つまたは複数のサブ要求または遠隔操作（ＲＯＰ）であってもよい。送信バッファ１０４が満杯（あるいはほぼ満杯）になると、電子メールクライアント１０２は、その中身を電子メールサーバ１０６に送信し、電子メールサーバ１０６は、それらを要求バッファ１０８に格納する。電子メールサーバ１０６は、要求バッファ１０８から要求を読み出し、それらを処理する。各要求を処理することによって、応答の形の結果が生成される。これらの応答は、電子メールクライアント１０２によって要求されたデータ（特定の電子メールメッセージなど）を含むことができる。電子メールサーバ１０６は、これらの応答を応答バッファ１１０に格納する。

本発明の一実施形態によれば、電子メールサーバ１０６は、各要求を処理するとき、どの要求が要求バッファ１０８から処理すべき次の要求であるかを追跡するためにポインタを使用する。電子メールサーバ１０６は、応答バッファ１１０が満杯である（例えば３２ＫＢのうち残りが８ＫＢ未満になった）と判断すると、要求バッファ１０８内にある要求の処理を停止する。処理されていない残りの要求（すなわち完了していない要求）は、応答バッファ１１０の中身に追加される。こうした完了していない要求および完了した要求に対する応答が、電子メールクライアント１０２にある受信バッファ１１２に送信される。

本発明の一実施形態では、電子メールクライアント１０２は、任意のバッファ１０４、１０８、１１０、１１２のサイズを指定することができる。応答のサイズは一般に、要求のサイズより大きい。そのため、応答バッファ１１０および受信バッファ１１２（ひとまとめにして「応答バッファ１１０および１１２」）のサイズは、電子メールクライアント１０２によって、送信バッファ１０４および要求バッファ１０８（ひとまとめにして「要求バッファ１０４および１０８」）のサイズより大きくなるように指定することができる。

本発明者が知っている従来技術の電子メールネットワークシステムは、電子メールクライアントおよび電子メールサーバでバッファを１つしか使用していなかったため、この機能を有していなかった。本明細書が利益を主張する仮出願の背景の部分では、電子メールクライアントおよび電子メールサーバがそれぞれ２つのバッファを有している電子メールネットワークについて記載しているが、出願人は、本発明より前にそれぞれで１つを超えるバッファを使用している電子メールネットワークを知らない。

図３に示す電子メールネットワーク１００など、バッファを使用する一部の電子メールネットワークは、クライアント（電子メールクライアント１０２など）とサーバ（電子メールサーバ１０６など）の間で高速転送モードを使用することができる。高速転送モードは、例えばＲＯＰなど、クライアントによる要求を含み、こうした要求は、サーバにある高速転送データソースの初期化をもたらす要求、および高速転送データソースからクライアントへの効率的なデータ転送をもたらす要求という少なくとも２つのカテゴリに分けられる。高速転送データソースは、例えばデータベーステーブルでもよい。高速転送データソースは、データの作動可能な一時記憶装置（ｒｅａｄｙ ｔｅｍｐｏｒａｒｙ ｓｔｏｒｅ）として働き、別の方法で可能となるはずのものより短い遅延で後からデータの要求を処理できるようにする。高速転送モード要求の第２のカテゴリは、時として、応答のサイズを明示的に指定することによって効率の良いデータ転送を達成しようと努める。一例として、応答のサイズを、受信バッファ１１２全体マイナス応答のオーバーヘッドのサイズに設定することができる。

図４Ａは、少なくとも２つの要求−応答サイクルを有する高速転送操作を示す。第１の要求４０１では、ＲＯＰ（ＦＸＰｒｅｐａｒｅなど）が電子メールサーバ１０６上にある高速転送データソースを初期化する。電子メールサーバ１０６で、ＦＸＰｒｅｐａｒｅのみが処理され（すなわち高速転送データソースが初期化され）、その結果が第１の応答４０２で戻される。第２の要求４０３で、ＲＯＰ（ＦＸＧｅｔＢｕｆｆｅｒなど）が電子メールサーバ１０６に、高速データソースから応答バッファ１１０を満たすよう要求する。電子メールサーバ１０６は、高速データソースを応答バッファ１１０に移し、その結果を第２の応答４０４で戻す。高速データソースが空になる前に電子メールサーバ１０６の応答バッファ１１０が満杯になった場合、追加のＦＸＧｅｔＢｕｆｆｅｒ ＲＯＰが必要となることがある。

図４Ｂは、要求−応答サイクルが１回だけの高速転送操作を示す。第１の要求４０５で、ＦＸＰｒｅｐａｒｅおよびＦＸＧｅｔＢｕｆｆｅｒがいずれも電子メールサーバ１０６によって処理され、両方の操作の結果が第１の応答４０６で戻される。各バッファの一部は共有データテーブルとして明示的に定義されているため、ＦＸＰｒｅｐａｒｅの結果は、電子メールサーバ１０６でＦＸＧｅｔＢｕｆｆｅｒによって入手可能である。

要求−応答サイクルの数を低減させることが望ましい。こうした低減によって、データの転送がより効率的になるからである。要求−応答サイクルが１回を超える高速転送操作は、応答バッファ１１０が満杯になりすぎてＦＸＧｅｔＢｕｆｆｅｒ ＲＯＰの結果を保持できないときに起こり得る。

次に図５を参照すると、クライアントの送信バッファ１０４の中身１２０の一例を示している。この例では、送信バッファ１０４は、遠隔手続き呼出し（ＲＰＣ）ヘッダ１２２、およびいくつかの要求１２４を含む。

本発明の一態様によれば、ＲＰＣヘッダ１２２は、圧縮ビット１２６および難読化ビット（ｏｂｆｕｓｃａｔｉｏｎ ｂｉｔ）１２８を含むことができる。圧縮ビット１２６は、電子メールサーバ１０６が要求に対する応答を圧縮するかどうかを示す。電子メールサーバ１０６が応答を圧縮すべきであることを示すために、他の情報を中身１２０内に備えることもできる。圧縮が常に望ましいとは限らない。例えば、クライアントは待ち時間の小さい高速接続を有し、解凍を効率的に行うのに十分な予備の処理能力がない場合、クライアントは、圧縮を希望しないことを示す指示付きの要求を送信することができる。あるいは、クライアントが十分な処理能力を有しており、サーバへの接続が低帯域幅である場合、クライアントはサーバに（例えばヘッダに圧縮インジケータビットを設定して）圧縮を希望することを知らせることができる。

難読化ビット１２８は、電子メールサーバ１０６が要求を難読化するかどうかを示す。難読化とは、データがネットワークを介して明確に読取り可能なテキストとして送信されないようにするために行われる簡単な操作である。難読化の一例は、要求が送信される前にその要求をＸＯＲ（知られている難読化方法）することである。一部の実施形態では、難読化の代わりに暗号化を使用することができる。この場合もまた、要求を難読化あるいは暗号化すべきであることを示す他の情報を中身１２０内に含めることができる。

図５に示すように、いくつかの実施形態では、電子メールクライアント１０２は、以下で説明する連鎖を使用してクライアントの要求に応答するよう電子メールサーバ１０６に指示する特殊要求１３０を中身１２０に含めるよう構成することができる。

次に図６を参照すると、本発明の一実施形態によるクライアントとサーバとの間にデータを転送する方法を例示するフロー図を示している。ステップ６００で開始し、電子メールサーバ１０６は、クライアントから複数の要求（要求１２４など）を受信する。

本発明の一実施形態によれば、電子メールクライアント１０２は、連鎖または非連鎖を、応答を送信するための電子メールサーバ１０６に要求することができる。ステップ６０２で、電子メールサーバ１０６は、要求１２４を検査して、要求に連鎖の要求（例えば特殊要求１３０）が含まれているかどうかを判定する。含まれていない場合は、ステップ６０２がステップ６０４に分岐して、電子メールサーバ１０６が要求１２４の応答の構築を開始する。図７に非連鎖を使用した応答の構築のプロセスの一例を示しており、図６の諸ステップがこの説明におけるこの例に当てはまる。

ステップ６０４（図６）で、電子メールサーバ１０６は、ヘッダ１４０を作成する。ステップ６０６で、要求１２４に対する応答１４２（図６）が取り出され、応答バッファ１１０に格納される。電子メールサーバ１０６は、応答１４２およびヘッダ１４０が応答バッファ１１０を満杯にする、あるいはほぼ満杯にするように十分な応答を生成したら、要求の処理を停止する。応用バッファ１１０が満杯またはほぼ満杯になったかどうかは、電子メールサーバ１０６および／または電子メールクライアント１０２によって定義することができる。一例として、応答バッファ１１０を、最初は３２Ｋであったバッファの残りが８Ｋ未満になったときに満杯であるとみなすことができる。

電子メールクライアント１０２が（例えば圧縮ビット１２６を適切に設定することによって）圧縮をサポートしていることを示している場合、ステップ６０８で、電子メールサーバ１０６は、応答バッファ１１０内の応答を圧縮して応答１４２の圧縮された１組の応答１４４（図７）にする。同様に、この場合もまたステップ６０８で、電子メールクライアント１０２が（例えば難読化ビット１２８を適切に設定することによって）難読化をサポートしていることを示している場合、電子メールサーバ１０６は、応答１４２を命令通り難読化または暗号化することができる。

ステップ６１０で、処理されていない任意の要求が要求バッファ１０８内の応答に追加される。これらの未処理の応答は、おおまかに示した、図７のメモリ１４６の圧縮後の未使用のメモリに入れることができる。次いでステップ６１２で、電子メールサーバ１０６は、応答および完了していない要求を電子メールクライアント１０２に送信する。

上述し、また図７に示した例からわかるように、非連鎖の応答での圧縮後の未使用のメモリ（すなわちメモリ１４６）はかなりの量となり得る。本発明の一態様によれば、未使用のメモリ量は、連鎖プロセスを使用して最小限に抑えることができる。しかし、これまでに説明した非連鎖方法は、例えば電子メールクライアント１０２が連鎖を望まない場合、例えば高速転送モードを要求しないＲＯＰにおいて有効となり得る。

電子メールクライアント１０２が、電子メールサーバ１０６は連鎖を使用すべきであることを示す場合、ステップ６０２はステップ６１４に分岐して、電子メールサーバ１０６が第１のヘッダ１５０（図８）を作成する。図８は、応答を連鎖用に構築するプロセスの一例を示しており、ステップ６１４から６２０の説明とともに使用する。

ステップ６１６で、電子メールサーバ１０６は、応答１５２を取り出し、それらで応答バッファ１１０を満たす。この場合もまた、応答バッファ１１０は、所定の限界に達したら満杯になったとみなすことができる。１つだけの応答を取得して応答バッファ１１０を満たすことはあり得るが、本明細書で使用する場合、「１組の応答」とは、１つまたは複数の応答を意味する。ステップ６１８で、応答バッファ１１０が満杯、またはほぼ満杯になったら、電子メールサーバ１０６は、電子メールクライアント１０２からの命令に従って応答バッファ１１０内の応答を（例えば圧縮ビット１２６および／または難読化ビット１２８によって）圧縮し、および／または難読化する。圧縮された１組の応答１５４が作成され、要求バッファ１０８内に未使用のメモリの大きい部分１５６が残される。

圧縮および／または難読化の後、ステップ６２０で、追加の応答を応答バッファ１１０内に収めることができるかどうかの判定が行われる。この場合もまた、追加の応答が収まるかどうかは、電子メールクライアント１０２または電子メールサーバ１０６によって定義することができる。しかし、最初の圧縮の後、追加のスペースが使用可能であることが予想される。追加のスペースが使用可能である場合、プロセスは折り返してステップ６１４に戻り、電子メールサーバ１０６が第２のヘッダ１５８（図８）を作成し、添付し、再度要求の処理を開始する（ステップ６１６）。

応答バッファ１１０が応答で満杯、あるいはほぼ満杯になったら、電子メールサーバ１０６は、ステップ６１８で、新たに追加された応答１６０を圧縮し、かつ／または難読化する。ステップ６２０で、再度、他の応答のための空間が残っているかどうかの判定が行われる。空間が残っている場合、プロセスは再度ステップ６１４に戻って、第３のヘッダが添付され、電子メールサーバ１０６は、再度応答バッファ１１０を応答で満たし、応答を圧縮し、かつ／または難読化する（ステップ６１６および６１８）。このプロセスは、すべての要求が完了する、または応答バッファ１１０がヘッダおよび対応する圧縮された応答で満杯、またはほぼ満杯になるまで繰り返される。応答バッファ１１０が圧縮された応答およびヘッダで満杯、あるいはほぼ満杯になったら（図８の下図）、ステップ６２０はステップ６１０に分岐し、電子メールサーバ１０６が（ある場合は）任意の完了していない要求を追加し、応答バッファ１１０の中身を電子メールクライアント１０２に送信する。

次いで応答バッファ１１０の中身をその受信バッファ１１２内に受信した電子メールクライアント１０２は、ヘッダ間の応答の各組を処理することができる。応答の組が圧縮され、かつ／または難読化されている場合、電子メールクライアント１０２は、難読化を伸張または平文化（ｒｅｖｅｒｓｅ）することができる。こうした場合、電子メールクライアント１０２は、次いで処理する複数の応答の組をまだ有している。

図７の非連鎖プロセスで送信されたデータと、図８の連鎖プロセスで送信されたデータの間の違いからわかるように、連鎖によって複数のヘッダ／応答の対をいっしょに連鎖し、またはパックして１つの「バッチ」で送信できるようになり、それによって、場合によっては電子メールクライアント１０２と電子メールサーバ１０６の間の往復回数が低減する。このプロセスは、本明細書では応答の「連鎖」または「パッキング」と呼ぶ。連鎖は、特に低帯域幅環境のネットワークにかなり効率的となり得る。本発明の一実施形態によれば、電子メールサーバ１０６は、高速転送モードの要求には連鎖を行い、高速転送モードではない要求には連鎖を行わないようにすることができる。

次に図９を参照すると、応答バッファ１５９のより詳細な例を示している。この例では、各ヘッダ１６１_１、１６１_２、・・・１６１_Ｎがバッファ内の次ヘッダへのポインタ１６２_１・・・１６２_Ｎを含む。あるいは、ヘッダ１６１は、圧縮サイズの対応する応答を含むことができる。いずれのイベントでも、この特徴によって電子メールクライアント１０２は、各応答のサイズおよび次の応答の先頭の位置がわかるため、圧縮されたバッチを受信すると、それをより簡単にデコードすることができる。

また、各ヘッダ１６１は、ヘッダ１６１がバッファ内の最後の応答に相当するかどうかを示す情報１６４_１・・・１６４_Ｎを、例えばビットファイルの形で含むこともできる。また、ヘッダ１６１は、未圧縮サイズの対応する応答情報など他の情報を含むこともできる。

電子メールサーバ１０６は、複数の電子メールクライアント１０２から並行して要求を受信し、それらを処理できることに注意されたい。このため、電子メールクライアント１０２を１つだけ示しているのは、単に図および付随する説明を簡略化するためである。

（より大きい応答バッファの使用）
上述したように、電子メールクライアント１０２は、電子メールサーバ１０６に、どんなサイズの要求バッファおよび／応答バッファを使用するかを通知するように構成することができる。例えば、本発明の一実施形態では、要求バッファ１０４および１０８はそれぞれ３２ＫＢ、応答バッファ１１０および１１２の最適なサイズはそれぞれ９６ＫＢであり、３対１の比率である。

電子メールクライアント１０２は、より大きい応答バッファ１１０および１１２を指定することはできるが、電子メールクライアント１０２を、応答バッファ１１０および１１２の実際のサイズより小さい応答のデータチャンクを扱うように構成することができる。例えば、応答バッファ１１０および１１２に対して９６Ｋのバッファを指定しても良く、しかし電子メールクライアント１０２は、応答のすべてのデータチャンクが３２Ｋ以下となることを希望しても良い。本発明のパッキングまたは連鎖によって、こうしたシステムが有効となる。

図１０のフロー図に、この機能を可能にする方法の一実施形態を示している。ステップ１０００で開始し、電子メールクライアント１０２は、１組の要求を、応答バッファサイズ（例えば９６Ｋ）を定義する情報、およびクライアントが処理するように構成されたデータチャンクのサイズに関する情報とともに電子メールサーバ１０６に送信する。ステップ１００２で、電子メールサーバ１０６は、クライアントによって定義されたデータチャンクのサイズと等しいフレームを応答バッファ１１０内に作成する。次いで電子メールサーバ１０６は、ステップ１００４で、ヘッダを応答バッファ１１０内のフレームに書き込む。ステップ１００６で、電子メールサーバ１０６は応答の処理を開始し、そのフレームが満杯になる、あるいはほぼ満杯になるまで応答を処理する。応答の組は、ステップ１００８で圧縮または難読化しても、あるいはしなくてもよい。

次いでステップ１０１０で、応答バッファ１１０が満杯かどうかの判定が行われる。一般に、応答バッファ１１０は、最初の応答処理の後では満杯にならない。応答バッファ１１０が満杯になっていない場合、プロセスは折り返しステップ１００２に戻り、電子メールサーバ１０６が、ちょうど今処理された応答の組の最後から始まる新しいフレームを作成する。この次のフレームをどこから開始するかが電子メールサーバ１０６にわかるようにポインタを使用してもよい。応答バッファ１１０内に十分な空間がある場合は、新しいフレームも電子メールクライアント１０２が扱うことができるデータチャンクのサイズとなる。ステップ１００４で、電子メールサーバ１０６は、次のヘッダを新しいフレームに書き込む。次いでプロセスがステップ１０１０に進む。

応答バッファ１１０が満杯になる（あるいはすべての要求が処理されるかのどちらかが先）と、プロセスはステップ１０１２に分岐し、電子メールサーバ１０６が応答バッファ１１０内の残りの未圧縮の要求をコピーする。ステップ１０１４で、電子メールサーバ１０６は、応答バッファ１１０の中身を電子メールクライアント１０２に送信する。

応答バッファ１１０の中身をその受信バッファ１１２に受信した電子メールクライアント１０２は、次いでヘッダ間の各データチャンク（応答の組）を処理することができる。応答が圧縮または難読化されていない場合、電子メールクライアント１０２は、ヘッダ間の応答の各組をそのまま処理することができる。応答の組は、電子メールクライアント１０２によって定義されたデータチャンク以下のサイズなので、電子メールクライアント１０２は、データの組を適切に処理できるはずである。応答の組が圧縮され、および／または難読化されている場合、電子メールクライアント１０２は、難読を解凍または逆転することができる。こうした場合、電子メールクライアント１０２は、それぞれ電子メールクライアント１０２が処理できるデータチャンクのサイズ以下の複数の応答の組をまだ有している。

（サーバを錯覚させてより多くの要求を処理させること）
電子メールサーバ１０６は、１組の要求の処理を完了したとき、「だまされ」て引き続き別の要求を処理しなければならない場合がある。例えば、既存の電子メールサーバは一般に、要求を処理し、一般に電子メールクライアント１０２によって指示されているあるサイズ（例えば３２ＫＢ）までの応答を提供するように構成されている。この処理の後、既存の電子メールサーバは、応答が準備できていることを示す応答（ＦＸＰｒｅｐａｒｅ応答）を送信する、あるいは応答を自動的に送信する（ＦＸＧｅｔＢｕｆｆｅｒ応答）ように構成される。しかし、本明細書で開示した圧縮を使用して、電子メールサーバ１０６がＦＸＧｅｔＢｕｆｆｅｒ応答に対してさらに多くの要求を処理して、応答バッファ１１０内の追加のスペースを満たすようにすることが望ましい場合がある。追加のスペースは、圧縮によって作成することができる。あるいは、上述の大きいバッファの実施形態が、そのフレームの１つを処理した後、追加のスペースを有してもよい。

図１１に、この状況を扱うための方法の一実施形態を示している。ステップ１１００で開始し、応答のための空間がさらにあるかどうか、および処理する要求がさらにあるかどうかの判定が行われる。ない場合、ステップ１１００はステップ１１０２に分岐し、電子メールサーバ１０６は、応答を電子メールクライアント１０２に送信する。１組の応答を提供した後の電子メールサーバ１０６の状況が、処理するものがさらにあり、それを処理するための空間がさらにあることを示す場合、ステップ１１００はステップ１１０４に分岐し、電子メールサーバ１０６は、「偽」のインバウンド要求（例えば偽のＦＸＧｅｔＢＵｆｆｅｒ要求）を生成する。次いでこの擬似ＲＰＣ（遠隔手続き呼出し）インバウンド要求が、あたかも電子メールクライアント１０２から受信したかのように電子メールサーバ１０６によって処理される。ＲＰＣは、実際にはリモートコンピュータから送信されるのではなく、代わりにサーバ内から送信されるという点で「擬似」である。この擬似ＲＰＣのアウトバウンドバッファは、圧縮後の元のアウトバウンドバッファ（上記で定義されたフレームによって限定できる）の残りの部分となるように設定される。次いでステップ１１０６で、電子メールサーバ１０６は、上述したように新しい応答を処理する。

電子メールサーバ１０６は、次の基準の１つに達するまで引き続きこのプロセスを繰り返す。基準とは、インバウンド要求に処理するものは何も残っていない、残りのアウトバウンドバッファサイズが所定のしきい値（例えば８ＫＢ）未満である、最大数のバッファが連鎖された（例えば６４個）、あるいはハードエラーがあったという基準である。

パックされた応答の各組は、それ自体のフラグ付きのそれ自体のヘッダを有する。１つのパケットは圧縮し、次のパケットは難読化し、あるいは、いずれのパケットも圧縮または難読化しないようにすることができる。連鎖された応答の新しいバッファごとにフラグに従う。

（バッファの中身の例）
以下は、アウトバウンド応答バッファ内の連鎖された２つのバッファに関する一例の詳細図である。

上に示したように、応答がパックされた各バッファは、それ自体のＨＳＯＴ（Ｈａｎｄｌｅ ｔｏ Ｓｔｏｒｅ Ｏｐｅｒａｔｉｏｎ Ｔａｂｌｅ）テーブルを有している。ＨＯＳＴは、各ネットワーク要求内にある識別子であり、それが電子メールサーバ１０６上のどのオブジェクトに作用しているかを示す。これはＨＳＯＴのテーブルであり、入力項目は内部記憶オブジェクトに相当する。要求バッファ１０８内の各操作には、その操作がどの記憶オブジェクトに適用するかを識別するこのテーブル内へのインデックスが含まれている。また、操作中に新しい内部記憶オブジェクトが作成された場合、電子メールサーバ１０６は、入力項目をこのテーブルに追加する。ＨＳＯＴテーブルは、リスト内の第１のものと値が異なるべきではなく、上述したようにＦＸＧｅｔＢｕｆｆｅｒ ＲＯＰで使用したものを含め、そこまでのすべてのＨＳＯＴのＨＳＯＴエントリしか含んでいない。これは、電子メールサーバ１０６での複雑さを低減するので、主に実施上の決定である。ＨＳＯＴテーブルは一般に、１組のダブルワード（ＤＷＯＲＤ）以下であるため、帯域幅は大幅には消費されないはずである。

これは単に一例であり、異なる実装形態の詳細は様々であることに注意されたい。例えば、フラグのいくつかは、電子メールクライアント１０２および／または電子メールサーバ１０６がどの機能をサポートするかに基づいて異なるように解釈される。例えば、電子メールクライアント１０２は、パックされ、かつ／または圧縮されたバッファをサポートしていることを示しているが、電子メールサーバ１０６は、これらの一方または双方をサポートしていない場合、対応するフラグを無視することがある。

上述したように、２つの新しいレジストリキーを電子メールクライアント１０２上で追加して、電子メールクライアント１０２が連鎖された応答を使用するべきかどうか、アウトバウンドバッファサイズをどれだけにすべきか（例えば３２Ｋ≦サイズ≦１２８Ｋ）を切り替えることができる。これはまた、圧縮を要求するために使用することもできる。こうした特徴は、実装に応じてデフォルトで有効にする、あるいはデフォルトで無効にすることができる。

一部の実装形態では、電子メールサーバ１０６に行くインバウンドバッファをパックすることができる。これらの実装形態では、電子メールサーバ１０６について上述したようにパッキングを扱う同様のプロセスを電子メールクライアント１０２上で実施することができる。しかし、項目のダウンロードは一般にアップロードよりより時間がかかるため、一部の実装形態は、インバウンドバッファをパッキング無しに電子メールサーバ１０６に送信しても良い。

この開示は、電子メールクライアントおよびサーバの実装形態に焦点を置いているが、本明細書で開示したシステムおよび方法は、他のタイプのアプリケーションにも適用可能である。例えば、本明細書で開示した技術を、ＭｉｃｒｏｓｏｆｔのＭａｐＰｏｉｎｔなどのマッピングアプリケーションにおけるマッピングクライアントとサーバとの間の情報の同期化に適用することもできる。さらに、システムおよび方法の実施形態をソフトウェアアプリケーションに関して説明してきたが、システムはハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せで実施できることを当業者であれば理解されよう。例ではダイヤルアップ接続に焦点を置いているが、他のタイプのネットワーク接続（例えばそれだけには限定されないが、ＬＡＮ、無線、ＩＳＤＮ、ＤＳＬなど）も考えられる。

したがって、バッファパッキングを使用したクライアントアプリケーションとサーバアプリケーションとの間の通信のための新しく有用なシステムおよび方法を提供してきたことがわかる。本発明の原理を適用できる多くの可能な実施形態の観点から、図面と関連して本明細書に記載した実施形態は、単に例にすぎず、本発明の範囲を限定するものとみなされないものとする。例えば、ソフトウェアで示した実施形態の例の要素をハードウェアで、またはその逆で実施できる、あるいは実施形態の例の構成および詳細を本発明の意図から逸脱することなく変更できることを当業者であれば理解されよう。したがって、本明細書に記載した本発明は、添付の特許請求の範囲およびその均等物の範囲内に含まれるこうした実施形態すべてを企図する。

本発明を組み込むことができるコンピュータネットワークを表すブロック図である。 本発明を組み込むことができるコンピュータの構造を示すブロック図である。 本発明による電子メールクライアントと電子メールサーバの間の要求および応答の交換を示すブロック図である。 本発明の一態様による２段階の高速転送モードプロセスを表す図である。 本発明の一態様による１段階の高速転送モードプロセスを表す図である。 本発明の一実施形態による要求を表すブロック図である。 本発明の一実施形態による電子メールサーバによる要求処理の扱い方を表すフロー図である。 本発明の一実施形態による電子メールサーバによる圧縮を表す図である。 本発明の一実施形態による電子メールサーバによる応答の圧縮および連鎖を表す図である。 本発明の一実施形態による電子メールサーバの応答バッファの中身を表す図である。 本発明の一実施形態による、応答のフレームをフレームより大きいバッファ以内で電子メールクライアントに提供するために電子メールサーバによって行われるステップの概略を表すフロー図である。 本発明の一実施形態による、サーバを錯覚させて応答バッファへの追加応答を追加させるステップの概略を表すフロー図である。

符号の説明

１０ コンピュータ
１１ ネットワーク
１４ 処理ユニット
１６、１４６ メモリ
２０ 取外し可能記憶装置
２２ 取外し不可記憶装置
２４ 通信接続
２６ 入力装置
２８ 出力装置
３０ ディスプレイ
１００ 電子メールネットワーク
１０２ 電子メールクライアント
１０４ 送信バッファ
１０６ 電子メールサーバ
１０８ 要求バッファ
１１０ 応答バッファ
１１２ 受信バッファ
１２０ 中身
１２２ 遠隔手続き呼出しヘッダ
１２４ 要求
１２６ 圧縮ビット
１２８ 難読化ビット
１３０ 特殊要求
１４０、１６１ ヘッダ
１４２、１５２、１６０ 応答
１４４、１５４ 圧縮された１組の応答
１５０ 第１のヘッダ
１５６ 未使用メモリの大きい部分
１５８ 第２のヘッダ
１５９ 応答バッファ
１６２ ポインタ
１６４ 情報
４０１、４０５ 第１の要求
４０２ 第１の応答
４０３、４０６ 第２の要求
４０４ 第２の応答

Claims (24)

1. クライアントからの要求のバッチに応答するコンピュータで実施する方法であって、
   ａ）応答のサイズが所望の量未満になるまで要求をトラバースし応答を生成することであって、前記応答は、第１の組の応答を備えること、
   ｂ）前記第１の組の応答にヘッダを添付すること、
   ｃ）前記第１の組の応答を圧縮すること、
   ｄ）追加の応答のサイズおよびバッファの他の中身が前記所望の量未満になるまで残りの要求をトラバースし、各要求のトラバースに応答して、前記追加の応答を作成することであって、前記追加の応答は、追加の１組の応答を備えること、
   ｅ）追加のヘッダを前記追加の１組の応答に添付すること、および
   ｆ）前記ヘッダおよび応答の組をクライアントに送信すること
   を備えることを特徴とする方法。
2. 前記バッファを送信する前に
   ｇ）前記追加の１組の応答を圧縮すること、
   ｈ）前記ヘッダおよび前記応答の組が所望の量のサイズに達する、あるいは前記要求がすべてトラバースされるまでステップｄ）、ｅ）、およびｇ）を繰り返すこと
   をさらに備えることを特徴とする請求項１に記載の方法。
3. 前記所望の量は前記クライアントが処理するように構成された１組の応答のサイズに相当することを特徴とする請求項１に記載の方法。
4. 前記所望の量は前記応答の組および前記ヘッダを保持するように設定されているバッファに関連することを特徴とする請求項１に記載の方法。
5. ステップｄ）の前に要求を処理するためのインバウンド要求を生成することをさらに備えることを特徴とする請求項１に記載の方法。
6. 前記インバウンド要求は擬似遠隔手続き呼出しであることを特徴とする請求項５に記載の方法。
7. 請求項１に記載の前記方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
8. クライアントからの要求のバッチに対して応答するコンピュータで実施する方法であって、
   ａ）応答のサイズがサーバのバッファ内の第１のフレームの所望の量を満たすまで、前記応答をトラバースし、各要求のトラバースに応答して前記応答を生成することであって、前記応答は第１の組の応答を備え、前記第１のフレームのサイズは前記クライアントが処理するように構成される１組の応答のサイズに関連し、前記第１のフレームのサイズは前記バッファのサイズ未満であること、
   ｂ）前記第１の組の応答にヘッダを添付すること、
   ｃ）前記応答のサイズが前記バッファ内の追加のフレームの所望の量を満たすまで、残りの要求をトラバースし、各要求のトラバースに応答して追加の応答を生成することであって、前記追加の応答は追加の１組の応答を備え、前記追加のフレームのサイズは前記クライアントが処理するように構成される１組の応答のサイズまたは前記バッファの残りのどちらか小さい方に関連し、前記追加のフレームのサイズは前記バッファのサイズ未満であること、
   ｄ）追加のヘッダを前記追加の１組の応答に添付すること、および
   ｅ）前記バッファの中身を前記クライアントに送信すること
   を備えることを特徴とする方法。
9. ｆ）ステップｃ）の前に前記第１の組の応答を圧縮すること
   をさらに備えることを特徴とする請求項８に記載の方法。
10. ｇ）ステップｅ）の前に前記追加の１組の応答を圧縮すること
    をさらに備えることを特徴とする請求項９に記載の方法。
11. 前記バッファが所望の量で満たされるまでステップｃ）、ｄ）、およびｇ）を繰り返すこと
    をさらに備えることを特徴とする請求項１０に記載の方法。
12. 前記バッファが所望の量で満たされるまでステップｃ）およびｄ）を繰り返すことをさらに備えることを特徴とする請求項８に記載の方法。
13. ステップｃ）の前に要求を処理するためのインバウンド要求を生成することをさらに備えることを特徴とする請求項８に記載の方法。
14. 前記インバウンド要求は擬似遠隔手続き呼出しであることを特徴とする請求項１３に記載の方法。
15. 請求項８に記載の前記方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
16. 複数の操作のための要求と、
    前記要求に対する応答を連鎖を介して戻すべきであることを示す指示と
    を備えるデータ構造を格納していることを特徴とするコンピュータ可読媒体。
17. 連鎖化は
    ａ）第１の組の応答をアセンブルすること、
    ｂ）前記第１の組の応答にヘッダを添付すること、および
    ｃ）１つまたは複数の追加の応答の組についてａ）およびｂ）を繰り返すこと
    を備えることを特徴とする請求項１６に記載のデータ構造。
18. 応答の組を圧縮すべきであることを示す指示をさらに備えることを特徴とする請求項１７に記載のデータ構造。
19. 圧縮前の前記応答の組のサイズ制限の指示をさらに備えることを特徴とする請求項１８に記載のデータ構造。
20. 前記応答の組のサイズ制限の指示をさらに備えることを特徴とする請求項１７に記載のデータ構造。
21. サーバと前記クライアントとの間でデータを転送する方法であって、
    ａ）複数の要求をクライアントから受信することであって、前記要求に対する応答の連鎖についての要求を含むこと、
    ｂ）前記クライアントに対する第１の組の応答をアセンブルすること、
    ｃ）前記第１の組の応答を圧縮すること、
    ｄ）前記第１の組の応答にヘッダを添付すること、
    ｅ）１つまたは複数の追加の応答の組について（ｂ）から（ｄ）までを繰り返すこと、および
    ｆ）前記圧縮した応答の組およびヘッダをともに前記クライアントに送信すること
    を備えることを特徴とする方法。
22. ステップｅ）の前に要求を処理するためのインバウンド要求を生成することをさらに備えることを特徴とする請求項２１に記載の方法。
23. 前記インバウンド要求は擬似遠隔手続き呼出しであることを特徴とする請求項２２に記載の方法。
24. 請求項２１に記載の前記方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
    

Images