JP2008537437A - 接続エンドポイント・プロキシを使用したユーザ・アフィニティに基づくコンテンツ送出 - Google Patents

Abstract

克服すべき動作特性を有するネットワーク・パス上のクライアントとサーバとの間のトランザクションをサポートするネットワークにおいて、1つまたは複数の動作特性を克服するために、ユーザ・アフィニティおよび動的ユーザ位置情報を使用してデータまたはデータの表現、署名、セグメントなどを選択的にプリロードすることにより、動作特性を克服するようにデータが伝送される。克服すべき動作特性の例には、帯域幅制限、エラー、および待ち時間が含まれる。動的位置情報は、データ・サーバのエージェントによってアクセス可能なデータ構造に記憶することができ、かつデータ構造は、ユーザ位置に関連するプロキシに対するユーザ活動に基づいて投入される。または、動的位置情報は、プロキシがクライアントによる終了後に接続を維持し、それらの維持された接続を使用してそれらのクライアントに関連するユーザ用のデータをプリロードする際に、暗黙的に得ることができる。プリロードされるデータは、プロトコル固有のデータであっても、またはプロトコルから独立したデータであってもよい。

Description

発明の分野
本発明は、概してネットワーク上のデータ伝送に関し、特にクライアントとサーバとの間の伝送レベルおよびアプリケーション・レベルでのデータ伝送の改良に関する。

関連出願の相互参照
本開示は、同一出願人による以下の同時係属中の米国特許出願に関する。2002年10月30日に出願された、「Transaction Accelerator for Client Server Communication Systems」（以下では「McCanne I」と呼ぶ）という名称の米国特許出願第10/285,315号は、参照によりすべての目的に関して本明細書に組み入れられる。2002年10月30日に出願された、「Content Based Segmentation Scheme for Data Compression in Storage and Transmission Including Hierarchical Segment Representation」（以下では「McCanne II」と呼ぶ）という名称の米国特許出願第10/285,330号は、参照によりすべての目的に関して本明細書に組み入れられる。2003年8月12日に出願された、「Transparent Client-Server Transaction Accelerator」（以下では「McCanne III」と呼ぶ）という名称の米国特許出願第10/640,405号は、参照によりすべての目的に関して本明細書に組み入れられる。2003年8月12日に出願された、「Cooperative Proxy Auto Discovery and Connection Interception」（以下では「McCanne IV」と呼ぶ）という名称の米国特許出願第10/640,562号は、参照によりすべての目的に関して本明細書に組み入れられる。

発明の背景
ローカル・エリア・ネットワーク（LAN）は、帯域幅が広く、待ち時間が短く、かなりの企業制御がネットワーク上で行われることを特徴とする。これに対して、ワイド・エリア・ネットワーク（WAN）は、LANよりも帯域幅が狭くかつ待ち時間が長いことが多く、WANが使用される企業の外部でのある程度のネットワーク制御が行われることが多い。したがって、大規模な分散型企業では、WANは、特に、分散した職場内で、ユーザが、集中データ・センターから実行されるデータまたはアプリケーションにアクセスしようとしたときに性能ボトルネックを生じさせる。たとえば、WANを通じて集中データ・センター内のメール・サーバから電子メール（eメール）を取り込む場合に、データ伝送に時間がかかり、エンド・ユーザの生産性が影響を受ける可能性がある。これに対して、LANを介してローカル・メール・サーバからeメールを取り込む場合、エンド・ユーザに対してほぼ瞬間的に伝送が行われる。同様に、WANを介して、WebサーバからWebページをフェッチするかまたはファイル・サーバからファイルをフェッチすることは、LANを介してローカル・サーバからそのようなデータをフェッチすることと比べて性能上困難な場合がある。

一般に、ユーザは、特定のネットワーク構成に受け入れられる性能を有するように設計されたアプリケーションを実行する必要があるが、ずっと低い性能を有するネットワーク構成上でそのようなアプリケーションを実行する必要があることが多い。一般的な例は、WANに対応しなければならないLANベースのアプリケーションであるため、この例は、本明細書のいくつかの箇所で使用される。

より高性能のネットワークを考慮に入れて設計されたアプリケーション向けのデータを取り扱う、より低性能のネットワークについて、ネットワーク性能を克服するいくつかの手法がある。しかし、たいていの解決手段は何らかの点で不満足なものである。

1つの手法は、サーバを複製し、データ・センター内のオリジン・サーバから分散した位置にある複製されたサーバへのデータを自動的に鏡像化または複製し、実際上データのコピーをクライアントのより近くに移動させるシステムを配備する手法である。この場合、複製サーバは、オリジン・サーバからのデータのコピー（ミラー）を有するが、複製サーバは、オリジン・サーバよりもそのクライアントの近くに位置する。クライアントは、ローカル複製サーバからのデータにアクセスし、より高い性能を実現する。これは、データがネットワーク的な意味で「より近い」からである。この手法は、重複サーバを配備し、オリジン・サーバから複製サーバへのデータのフローおよび同期化を管理するうえでの複雑さおよび費用を伴う。この手法では、いつどこでどんなデータが必要とされるかを予想するのが困難であり、したがって、実現態様では、各位置ですべての利用可能なデータが単に重複していることが多い。

Webコンテンツおよびストリーミング・メディアに使用されている他の手法は、プロキシ・キャッシュ・デバイスを分散した位置に配備し、所与の位置で複数回にわたって取り込まれるデータのアクセス性能を向上させる手法である。LAN/WANを有するこのような構成では、キャッシング・プロキシはLAN上のクライアントの近くに位置する。キャッシング・プロキシは、そのクライアントのセットとWANを介してアクセスされるサーバとの仲介として働く。キャッシング・プロキシは、キャッシュされたデータが将来のある時点での要求に備えて事前に送信されたデータを記憶する。クライアントがWebサーバにデータを要求すると、たとえば、そのクライアントのWeb接続はプロキシ・キャッシュによって遮断される。プロキシ・キャッシュは、要求されたデータを有する場合、データをそのままLANを介してローカルに供給する。プロキシ・キャッシュは、要求されたデータを有さない場合、要求されたデータをWANを介してサーバから取り込み、データを送信側クライアントに送信し、取り込まれたデータを、以後の要求時に再使用されることに備えてそのユニフォーム・リソース・ロケータ（URL）によってインデックス付けしたうえでキャッシュに記憶する。

このように、複数回アクセスされるデータは、最初のクライアント要求時にのみWANの性能ボトルネックを受け、その後のすべてのアクセスについてLANによる性能上の利益を得る。しかし、一度しかアクセスされないデータについては、性能上の利益は得られない。データに対する最初のクライアント要求（その後再び要求されるかまたは一度しか要求されない）に関する性能を向上させるには他の技術が使用される。たとえば、ネットワーク・キャッシング・システムはコンテンツ送出機能を備えており、それによって、オペレータは所望のコンテンツを、要求される前にプロキシ・キャッシュ内に移動しておくことができる。このモデルでは、コンテンツ・パブリッシング・システムが通常、コンテンツ送出システムとのインタフェースとして働き、オペレータがプロキシ・キャッシング・サーバのセットにコンテンツを発行するのを可能にする。したがって、あるデータがこのようにプロキシ・キャッシュにプリロードされている（pre-loaded）と仮定すると、そのデータに対する最初のクライアント要求については高性能が実現される。しかし、このようなシステムは一般に作成および管理が複雑であり、この情報送出モードをサポートするには新しいビジネス・プロセスを配備することが必要になることが多い。さらに、ユーザ構成を使用してコンテンツを適切に配置するのは一般に費用がかかり、最適ではなく、エラーが生じやすい。

WANボトルネックを克服する他の手法は、企業の一部のためのサーバが、企業のその一部のためにクライアントの近くに配置されるように、サーバを分散する手法である。たとえば、いくつかの支所を有する企業は、各支所にeメール・サーバ、ファイル・サーバなどを配置し、所与のユーザのデータをそのユーザの支所のサーバ上に記憶することができる。たとえば、eメール・メッセージが、企業の、特定のユーザ用のメイン・メール・ゲートウェイに到着すると、メール・ゲートウェイは、特定のユーザの支所用のeメール・サーバを識別し、識別されたサーバにeメール・メッセージを経路指定する。ユーザがそのeメールを取り込むと、eメールは、支所のeメール・サーバからフェッチされ、高性能が実現される。同様に、特定の職場に位置するユーザは、その職場のファイル・サーバにファイルを記憶しファイル・サーバからファイルを取り込み、それによってやはり高性能を実現する。

しかし、この手法は、大規模な企業内の多数の位置におけるサーバを管理しかつ多数の位置にサーバを分散する費用が高くなるため、常に望ましいわけではない。このような各デバイスを管理したり、バックアップしたり、補修したりしなければならない。集中データ・センター内でできるだけ多くのサーバを管理した方がずっと費用が安くかつより望ましいことが多い。しかし、集中アーキテクチャは、WANを介してサーバにアクセスすることを必要とし、上述のように、性能上の困難な問題を生じさせる可能性がある。

認証およびセキュリティ機構がこれらの手法の多くをさらに複雑にする可能性がある。コンテンツをたとえばオリジン・サーバから複製サーバに移動させるエージェントは、そのようなエージェントがすべてのデータに対する完全なアクセス権を有するため完全に信頼できるエージェントでなければならない。第三者のデバイスまたはソフトウェアに、企業内のあらゆる人のデータに対する「スーパー・ユーザ」アクセス権を委ねることは、多くの顧客環境において配備上の障害になる。

したがって、ネットワーク上のデータを取り扱う改良された技術が必要である。

発明の簡単な概要
クライアントが、トランザクションを要求するホストであり、サーバが、クライアント要求に応じて応答を発行するホストであり、クライアントとサーバとの間のパケットが、1つまたは複数のホップを含みかつ克服すべき1つまたは複数の動作特性を有するネットワーク・パスを通じて伝達される、クライアントとサーバとの間のトランザクションをサポートするネットワークにおいて、1つまたは複数の動作特性を克服するために、ユーザ・アフィニティおよび動的ユーザ位置情報を使用してデータまたはデータの表現、署名、セグメントなどを選択的にプリロードすることにより、1つまたは複数の動作特性を克服するようにデータが伝送される。克服すべき動作特性の例には、帯域幅制限、エラー、および待ち時間が含まれる。

いくつかの実施形態では、動的位置情報は、データ・サーバのエージェントによってアクセス可能なデータ構造内に記憶され、このデータ構造は、ユーザ位置に関連するプロキシに対するユーザ活動に基づいて投入される。他の態様では、動的位置情報は、プロキシがクライアントによる終了後に接続を維持し、それらの維持された接続を使用してそれらのクライアントに関連するユーザ用のデータをプリロードする際に、暗黙的に得られる。プリロードされるデータは、プロトコル固有のデータまたはプロトコルから独立したデータであってよい。

本発明の他の特徴および利点は、以下の詳細な説明および好ましい態様を検討すれば明らかになろう。

発明の詳細な説明
本発明は、本開示を読んだ後で明らかになるであろう多数の用途を有する。本発明によるコンテンツ送出システムの一態様について説明するうえで、考えられるいくつかの変形態様のみを説明する。他の用途および変形態様は当業者には明らかであり、したがって、本発明は実施例のみと狭義に解釈すべきではなく、添付の特許請求の範囲に従って解釈すべきである。

本明細書で使用される「トランザクション」という用語は、データをある場所から別の場所まで移動させる論理的なステップのセットである。場合によっては、移動するデータは、ファイルがサーバのディスク上に存在するファイル・トランザクションなどのトランザクションから独立したデータの送出元に存在する。他の場合には、データは、計算、検索などの要求に応じる場合など、送出元でのトランザクション用に生成される。典型的には、トランザクションを開始するコンピュータ、コンピュータ・デバイスなどを「クライアント」と呼び、応答するかまたは応答することが期待されるコンピュータ、コンピュータ・デバイスなどを「サーバ」と呼ぶ。

データはいずれかの方向に流れることができる。たとえば、ファイル・システム・クライアントは、ファイル・サーバにファイルの読み取りを要求することによってトランザクションを開始することができる。対応するデータは、要求に応答するサーバから返され、したがって、その場合、データ全体がサーバからクライアントまで流れる。しかし、クライアントがファイル書き込みトランザクションを開始した場合、データ全体が、開始要求の一部としてまたはそれに続くメッセージとしてクライアントからサーバまで流れる。

トランザクションは、複数の部分から構成されてよいが、単純なトランザクションでは、クライアントが要求（明確に要求である、または要求を示すもしくは表す、データ、メッセージ、信号など）をサーバに送信し、サーバがクライアントへの応答（明確に応答である、または応答を示すもしくは表す、データ、メッセージ、信号など）で応答する。より複雑なトランザクションは、たとえば、サーバが要求を明確化し、クライアントが要求に対する応答を受信する権限を検証し、応答の作成に必要な追加の情報を得ることなどに必要でありうる複数の往復を伴うことがある。

本明細書では、クライアントとサーバとの間の接続の典型的な例は、パケット・ネットワークであるが、ポイント・ツー・ポイント有線チャネルまたはポイント・ツー・ポイント無線チャネルのような他の接続手段を使用してもよい。これらの要素は一般化されており、本明細書では「ノード」と呼び、ノード同士の間の通信用にチャネルが仮定される。

トランザクションは、あるノードのクライアントが別のノードのサーバに向けられたファイル・データを求める要求を出すことによって開始することができ、その後、要求されたファイル・データを含む応答が送出される。他のトランザクションは、ファイルの特定の部分、ファイル全体、他のデータ構造の全体または一部を求める要求であってよく、あるいはトランザクションは要求側から流れるデータに関するかまたはコマンドに関するものであってよい。トランザクションの例には、「ブロックを読み取る」、「ファイルを読み取る」、「ストリームを読み取る」、「このデータでブロックを書き込む」（要求側から流れるデータの例）、「ファイルを開く」、「このデータに対する計算を実行する」、「これらの特性を有するeメールを取得する」、「eメールを送信する」、「新しいeメールをチェックする」、「ディレクトリ・コンテンツを表示する」などが含まれる。

いくつかのトランザクションでは、大量のデータが一方向または両方向に流れる。いくつかのトランザクションは、場合によっては複数の要求側および／または複数の受信側を有する対話を伴う。説明を明確にするために、これらの多数のトランザクション・タイプについては、1つのクライアントが1つのサーバに要求を出し、1つのサーバがクライアントによって予想される方法で要求に応答する、典型的な単純なトランザクションに関して説明する。しかし、本開示を読めば、当業者は、これらの概念をクライアントとサーバの間、またはより一般的には2つのノード間の1対多数および多数対多数のトランザクションに適用することができるであろう。一方向におけるデータ・フローについて説明する場合、データが逆方向に流れる可能性があり、および／または情報が一方向にのみ流れる可能性があるが、データおよび／または信号は、情報の移動を実現するために両方向に流れることを理解されたい。

本明細書では、「近い」とは、物理的な近接を指しうるが、ネットワークの近接を指すこともできる。ネットワークの近さは性能属性に関する。一例として、LANの2つのノードは、低速のネットワーク・チャネルによって分離された2つのノードよりも近いとみなすことができる。物理的な距離が大きいとネットワークの近接はもたらされないことが多いが、2つのノードが物理的に近くてもネットワーク的には離れている例および2つのノードが物理的に離れているがネットワーク的には比較的近い例がある。

本明細書で使用される「ユーザ・アフィニティ」という用語は、コンピュータ・システムまたはネットワーク内のエンド・ユーザとの関連を指す。したがって、ユーザ・アフィニティを有するデータは本来、そのユーザに結合され、または場合によっては1つまたは複数のユーザに結合される。たとえば、ユーザ「John Doe」にアドレス指定されたeメールは、そのユーザのユーザ・アフィニティを有する。同様に、「John Doe」によって所有されるファイル・サーバ上のファイルは、そのユーザのユーザ・アフィニティを有する。より一般的には、分散環境において複数のユーザによってアクセスされるファイルは、各々のそのようなユーザのユーザ・アフィニティを有する。

ユーザ・アフィニティは、データ送出を最適化するうえで好都合に使用することができる。一般的な手法では、上述のように、eメールなどのユーザ・データをそのデータのユーザの近くに保持するように複数のサーバを分散してセットアップすることができる。しかし、これは、サーバが分散され、維持がより困難であることなどの欠点を有する。

このことは、本発明のいくつかの方法および装置によって克服することができる。ここで2つの例およびいくつかの変形態様について説明する。

ユーザ・アフィニティを有するデータを経路指定するための動的位置情報記憶装置の使用
一手法では、サーバ上に記憶されたデータは、クライアントにより近いキャッシュに選択的にコピーされ、この選択は、コピーされたデータのユーザ・アフィニティおよび動的ユーザ位置情報から判定されるユーザの推定位置に基づいて行われる。以下に説明する1つの特定の例は、所与のeメール・メッセージのユーザ・アフィニティがeメール・メッセージの対象となる受信側に基づくものであってよく、かつeメール・コンテンツ送出システムに結合されたクライアントを使用したユーザの前の対話から動的ユーザ位置情報を判定することができる、eメール・コンテンツ送出システムである。

図1は、そのようなeメール・コンテンツ送出システムの一例を示している。図1に示されているように、eメール・プロキシ・キャッシュ（EPC）100は、ネットワーク上の、リモート位置のユーザの近くに配置されている。EPC 100は、WAN上の集中eメール・サーバのユーザによって使用されるクライアント間の通信を最適化する。EPC 100は、1つまたは複数のネットワーク・インタフェース・カード（NIC）を通してネットワークに取り付けられ、クライアント接続を終了し任意に遮断する機構、eメール・メッセージのコピーを保持するメッセージ記憶装置、およびクライアントとサーバとの間のeメール伝送接続を終了および開始する接続ハンドラを含んでいる。

EPC 100は、接続ハンドラ105、メッセージ記憶装置110、クライアント120、およびクライアント120と接続ハンドラ105との間のクライアント接続140を含むように示されている。各図で同様の項目の複数のインスタンスが存在する場合、それらのインスタンスは共通の符番によって示され、互いに異なるインスタンスは異なる括弧内符番によって表される。したがって、図1は、3つの接続ハンドラ105(1)、105(2)、105(3)を示している。これらの例は3つのクライアントおよび3つの接続ハンドラを示しているが、存在するクライアントはこれより多くてもまたは少なくてもよく、かつ存在する接続ハンドラはこれより多くてもまたは少なくてもよい（かつ必ずしも接続ハンドラの数とクライアントの数は同じでなくてもよい）ことを理解されたい。

接続ハンドラ105（およびEPC 100の一部）は、レイヤ2スイッチに接続されたNICを通してネットワークに取り付けられたコンピュータ・システム上で実行されるソフトウェア・プロセスであってよい。EPC 100にはネットワーク・アドレス（たとえば、インターネット・プロトコル・アドレス、またはIPアドレス）が割り当てられている。各接続ハンドラ（CH）105は、対応するクライアント120に代わって、クライアント・セッションを終了し、1つまたは複数のサーバ接続を開始する。たとえば、クライアント120(1)は接続140(1)を通じてCH 105(1)と通信する。接続ハンドラ105は、eメール・メッセージ・データのコピーをメッセージ記憶装置110に記憶し、かつメッセージ記憶装置110から取り出す。

このように配備すると、LANに取り付けられたクライアントは、たとえば、サーバのアドレスの代わりにEPCのIPアドレスを使用することによって、オリジン・サーバと直接通信するのではなくEPC 130と通信する。このことはいくつかの利得をもたらすが、eメール・プロトコルおよびクライアントがこのような構成をサポートするのが容易でないときには図1に示されている手法は実現が困難であることが多いため、さらなる改良も可能である。

図2に改良された態様が示されている。この場合、EPC 200は、二重ポートNICを含み、レイヤ2スイッチとルータとの間のネットワーク・パスに挿入することができ、接続ハンドラ205（または必要に応じて接続ハンドラ205をインスタンス化する機構）およびメッセージ記憶装置210をさらに含んでいる。この構成は、EPCが、McCanne IVに記載された方法に従って接続を透過的に遮断しプロキシ処理を実行するのを可能にする。本態様では、EPC 200は、EPCがプロキシ処理を実行しないすべてのトラフィックに対してレイヤ2リレーまたはブリッジとして働く。EPC 200がプロキシ処理を実行しない接続の場合、EPC 200は、遮断モジュール240内の対応するトラフィックを遮断し、遮断されたトラフィックをEPC 200内の適切な接続ハンドラ205に向ける。

本態様では、eメール・サーバとのクライアント接続は、Webキャッシュが接続を終了するのと同様にEPC 200によって終了される。接続ハンドラは好ましくは、各クライアント・セッションごとに作成され、対応する接続が確立され、eメール・サーバがクライアントのターゲットとされる。eメール・クライアントがサーバからメッセージを取り込むと、EPC 200はそのメッセージ記憶装置210を検査して、メッセージがすでに存在するかどうかを確認し、存在する場合、メッセージを返す。メッセージが存在しない場合、EPC 200はオリジン・メール・サーバからメッセージをフェッチし、メッセージをメッセージ記憶装置210に記憶し、メッセージをeメール・クライアントに送信する。

このようにeメールを複製することは、eメール・プロトコルが、典型的には、あらゆるeメール・メッセージに固有の識別子を割り当て、メッセージが変更可能でないため、直接的なタスクである。したがって、eメール・メッセージのコピーは実際上最初のメッセージと同じであるため、解決すべき整合性の問題はない。言い換えれば、EPCがそのメッセージの固有の識別子を使用してメッセージ記憶装置内のメッセージを見つけることができる場合、EPCは、メッセージのコピーがすでに有効であることを知る。

図3は、サーバにまたはサーバの近くに配備されたコンテンツ送出エージェント（CDA）をさらに含むコンテンツ送出システムを示している。eメール・サーバ用のコンテンツ送出エージェントは、そのEPCの近くに位置すると判定されたユーザ用のメッセージを有するeメール・プロキシ・キャッシュ（EPC）をプリロードする。新しいメール・メッセージがサーバに到達すると、そのサーバのコンテンツ送出エージェントは、メッセージを検査してメッセージの受信側を判定する。コンテンツ送出エージェントは次に、どのEPCが受信側に最も近いかを判定する。このユーザ位置判定は、以下に説明するようにいくつかの方法で行うことができる。適切なEPCが判定された後、クライアント送出エージェントはメッセージのコピーを選択されたEPCに伝送し、そのEPCのメッセージ記憶装置に記憶する。ユーザがメッセージをフェッチすると、EPCはそのメッセージ記憶装置から得たメッセージを実現し、その結果高性能が実現される。

ユーザ位置判定の1つの方法は、システム・オペレータによって維持されるデータベースを参照することを含む。または、ユーザがどこでeメールを読むかについての動的観測から自動的に構築されるデータベースを参照することによって判定を行うことができる。

1つの特定の例において、図3は、それぞれeメール・サーバ302(1)および302(2)を動作させる2つのデータ・センター300(1)および300(2)を示している。図示のように、各データ・センター300はCDA 304も含んでいる。データ・センター300(1)は、ユーザ位置データベース（ULDB）305も含むように示されている。データ・センター、eメール・サーバ、コンテンツ送出エージェント、クライアント、およびEPCの数が図3に示されている数と同一でなくてもよいことを理解されたい。たとえば、単一のeメール・サーバを使用することも、または2つよりも多くのeメール・サーバを使用することもできる。

クライアント310、311、312、313、および314はWANを通じてeメールにアクセスする。各クライアントは、クライアントのローカルEPC 330によってプロキシ処理が実行される接続を通じて2つのeメール・サーバ302と通信する。eメール・サーバにはコンテンツ送出エージェント（CDA）304が関連付けられている。CDAは、eメール・サーバと同じコンピュータ上で実行され、APIを通じてeメール・サーバとのインタフェースとして働くソフトウェアであるか、またはeメール・サーバに適合するネットワークに取り付けられたコンピュータ上で実行され、ネットワーク・プロトコルまたはネットワーク・プロトコル上のAPIを通じてeメール・サーバとのインタフェースとして働くデバイスであってよい。

メッセージがクライアントによってその近くのEPCを通じて様々な位置で取り込まれると、各EPCは、ユーザがその位置からeメールを取り込んでいることを記録し、ユーザとその位置（たとえば、そのEPCの位置）とのマッピングを示すメッセージをULDB 305に送信する。たとえば、EPC 330(1)はこの情報を接続320(1)を通じて送信する。メッセージはユーザ証明（すなわち、ログイン名、ユーザIDなど）ならびに位置識別子（たとえば、ユーザがメッセージを取り込んでいるEPCのIPアドレスなど）を含んでよい。ULDBへのメッセージをバッチ処理して構成可能な最大速度で送信し、性能を劣化させずにシステムの調整（scale）を可能にすることができる。

ULDBは、この情報を使用して、やがて様々なユーザの位置を知る。その結果、特定のユーザについての新しいメッセージが到着すると、受信側サーバのCDAは、動的位置情報による判定に応じてユーザの近くのEPCのメッセージ記憶装置にそのメッセージをプリロードしておくことができる。たとえば、ユーザ310についてのeメールがサーバ302(1)に到着すると、CDA 304(1)は、そのメッセージのコピーを接続350(1)を通じてEPC 330(1)に送出する。ユーザが様々なEPCの対象となる様々な位置でeメールにアクセスすることをULDBが示している場合、CDAは、そのユーザを対象とする可能性の高い各EPCにコピーを送信することができる。

図4は、特定のユーザ用のメッセージの一例の送出のスイム図（swim diagram）を示している。この例では、メッセージ410がインターネットからメール・サーバ400に到着する。メール・サーバは、ユーザ「joe」についてのメッセージが到着したことを示す「通知」メッセージ411をCDA 401に送信する。CDA 401は、ユーザ「joe」用の参照メッセージ412をULDB 402に送信し、ULDB 402はデバイスEPC 403の位置で応答する。CDA 401は、「フェッチ」メッセージ413をメール・サーバ400に送信し、メッセージ410からメッセージ・データ（およびあらゆる添付データ）を取り込む。データが取り込まれると、CDA 401は、EPC 403に送信される「プリロード」メッセージ414でデータを送信する。その後、ユーザがeメール・クライアント404を通じてメッセージを読むことを試みると、クライアントはサーバに「フェッチ」メッセージ415を送信してメッセージ410のコンテンツを要求する。その後、EPC 403はメッセージ415を遮断し、対応するデータをそのローカル・メッセージ記憶装置からクライアントに供給し、それによって高送出性能を実現する。

ユーザ・アフィニティに基づくデータを送出するための接続エンドポイント・プロキシの使用
上述の手法は、既存の解決策よりも優れているが、各サーバに関連するコンテンツ送出エージェントを配備し管理する必要があり、このことは企業IT構成にとって困難であり費用がかかる。さらに、この手法では、いくつかの異なるプロトコル、アプリケーション・プログラミング・インタフェース（API）、相互通信エージェントなどとの統合を必要とするいくつかの独立した構成部材が必要になることがある。

次に、コンテンツが接続エンドポイント・プロキシを使用してユーザ・アフィニティに基づいて送出される他の手法について説明する。本明細書で使用される接続エンドポイント・プロキシ（CEP）という用語は、あるデバイスに埋め込まれるか、またはさもなくば、クライアントがそのサーバ接続を終了した後、プロキシによって開始されるコンテンツ送出にその接続を使用できるようにクライアント-サーバ・セッションを持続するネットワークに取り付けられる、プロキシ・エージェントである。

クライアントがクライアント-サーバ・セッションを表す接続の終了を試みると、CEPは、その判定を妨害してセッションを維持し、それによってクライアント・セッションを継承する。CEPがクライアント・セッションを継承するので、CEPはそのセッションのすべてのセキュリティ機能およびアクセス機能も継承する。したがって、CEPは、メッセージ・データ、添付データなどをサーバからローカル・プロキシに取り込ませる合成トランザクションをクライアント-サーバ・セッションに導入することができる。クライアントがそのセッションを終了した場合、CEPは、クライアント接続を保持し、引き続きクライアントのメッセージ記憶装置を監視し、そのユーザについてのメッセージがサーバからCEPに到着したときにメッセージおよび対応するデータを取り込む。クライアントが対象となるサーバとの新しいセッションを開くと、CEPは、持続していたセッションを切断し、次にその新しいセッションを確立するのを可能にする。クライアント側プロキシで実行されるCEPだけでなくサーバ側プロキシが存在する構成では、サーバ側のプロキシが、第2のユーザ・セッションが確立されたときにそれを知り、クライアント接続が終了した後に持続されているあらゆるCEP接続を切断する。

CEPは、ネットワーク・プロキシ・デバイスに配備することによってクライアント-サーバ接続のパスに介在させることができる。プロキシ処理が実行される各接続ごとに1つのCEPセットを収納するプロキシ・デバイスを本明細書では接続エンドポイント・プロキシ・デバイス（CEPD）と呼ぶ。

図5は、1つまたは複数のネットワーク・インタフェースを通じてネットワークに取り付けられたCEPDを示している。この場合、2つのNICの好ましい構成が示されている。いくつかのクライアント（510、511、512）は、それぞれCEP 503、502、および501によってプロキシ処理が実行されるサーバ520との接続を有する。

図6は、接続エンドポイント・プロキシ・デバイス（CEPD）がeメール・プロキシ・キャッシュ（EPC）と一体化されたコンテンツ送出システムの一態様を示している。図6に示されているように、クライアント601は、サーバ604との1つまたは複数の透過的な接続を開始して、eメール・メッセージ、またはカレンダー・データ、ニュースグループ、共有ファイルのような他の種類のメッセージの取り込み、処理、検査などを行う。

場合によっては、クライアント601がeメール・サーバにアクセスするときに使用するプロトコルは、IMAPなどの標準化プロトコルであっても、またはMAPIのような独自仕様のプロトコルであってもよい。IMAPは、M. Crispin, "Internet Message Access Protocol-Version 4revl", Request-for-Comments (RFC) 2060, December 1996に記載されている。MAPIは、Microsoftの独自仕様のプロトコル・メッセージングAPI （MAPI）であり、Microsoftのリモート・プロシージャ・コール（RPC）プロトコルを通じて実行される。このような態様では、クライアントのIMAP接続またはMAPI接続がCEPD 602によって透過的に遮断され、CEPD 602は、CEP 605でのIMAP/MAPI接続を終了し、送出元のeメール・サーバ604との対応する透過的接続（または接続のセット）を開始する。eメール・プロキシ603は、CEPD 602から開始された接続を遮断し、その後送出元のeメール・サーバ604との対応する透過的接続（または接続のセット）を開始する。

この透過的接続パイプラインが確立されると、クライアントからのメッセージが、サーバへのパイプラインを含む様々な接続を通じて中継され、一方、サーバからの応答がクライアントに送り返される。接続の開始時には、メッセージを交換し合う様々な機構を通じてクライアントを認証することができる。クライアントが認証されると、CEP 605は、クライアント-サーバ・セッションに合成メッセージを導入することによってコンテンツ送出を実行することができる。たとえば、eメール・クライアントは、典型的には、ユーザに表示されるすべてのヘッダをフェッチする。次いで、ユーザがメッセージを表示して読むことを試みてから初めてクライアントがメッセージをフェッチする。さらに、eメール・メッセージは、同様にユーザが添付データを開くまたはダウンロードすることを試みたときにのみフェッチされる大型の添付データを含むことが多い。CEPは、ユーザの経験を向上させるために、積極的に、ユーザのメールボックスのコンテンツを走査し、メッセージおよび添付データを、ユーザによって要求される前に取り込んでおくことができる。または、CEPは、ヘッダが取り込まれるのを監視し、対応するメッセージ・テキストおよび添付データを要求する合成メッセージを導入することができる。

図7は、コンテンツ送出機能が通常のeメール・メッセージング・プロトコルを通じてどのように実行されるかの一例を示すスイム図である。この例では、IMAPプロトコルを仮定する。

図示の例では、クライアントはまず、ログイン・メッセージ内に適切な認証情報を含む「ログイン」要求701によってクライアントとeメール・サーバとのセッションを確立する。クライアントがそれ自体を認証すると、クライアントは、「選択」要求702を発行して、以後の動作を特定のメールボックス、たとえばユーザの「インボックス」に対して実行することを指定する。次に、クライアントは、「開始」要求703を発行して、新しいメッセージが存在するかどうかを含む様々な情報を得る。クライアントは次に、後に続く「フェッチ」コマンド（704および705）を発行し、ユーザがメッセージを読み取って表示したことに応じてメッセージ・データを取り込む。次いで、この例では、ユーザは、何もせず、後に続くメッセージがメールボックス内に存在しているのにもかかわらずそれを読まない。この時点で、CEPは、セッションがアイドル状態であることを検出し、ユーザのインボックス内にあるが取り込まれていない他のメッセージについての合成「フェッチ」要求706を送信する。これによって、eメール・プロキシ・キャッシュはメッセージをそのメール記憶装置に記憶する。その後、ユーザが「フェッチ」要求を送信することによってこれらのメッセージを読み、メッセージがLANを介してeメール・プロキシからクライアントに送信されるときに高性能が実現される。

その後、ユーザはeメール・クライアントを停止し、クライアント接続を終了させる。しかし、CEPは、eメール・プロキシ・キャッシュを通じたサーバとの接続を切断するのではなく、接続を持続し、eメール・サーバ内のそのユーザのデータ送出元を引き続き監視する。たとえば、そのユーザについての新しいeメール・メッセージが到着すると、サーバはクライアントに向けて、CEPによって遮断され消費される「通知」メッセージ709を送信する。これに応じて、CEPは、「フェッチ」要求710を送信することによって新たに到着したeメールのメッセージ本体および添付データに対応するデータを取り込む。したがって、eメール・プロキシ・キャッシュは、ユーザを各位置にマップするデータベースを明示的に構築する必要なしに、ユーザのセッションのeメール・コンテンツを表すデータによって引き続き満たされる。

次に、ユーザがeメール・クライアントを再起動し、eメール・サーバとの接続を開き、新しい「ログイン」要求711を送信してセッションを確立すると仮定する。この時点で、CEPは、ユーザが新しいセッションを確立していることを知り、したがって、古い接続上のサーバに「ログアウト」要求712を送信することによって古いセッションを切断し、接続を閉じ、次いでクライアントの「ログイン」要求を新しい接続を通じてサーバに対して継続するのを可能にする。クライアントは次に、事前にCEPによって「フェッチ」要求713を介してeメール・プロキシ・キャッシュに取り込まれているメッセージを取り込むことを試みる。このため、メッセージがeメール・プロキシ・キャッシュからLANを介して送出されるときに高性能が実現される。

図8は、上記の技術のいくつかをどのように一般化して、複数の位置を有する分散型企業全体に配備するかを示している。図示の例では、2つのデータ・センター内に2つのサーバ、サーバ801および802がある。ある職場には、3つのクライアント813、813、814、各クライアントごとのCEP（811、812、813）、およびEPC 810がある。同様に、他の職場には他のクライアント、CEP、およびEPCがある。各クライアントは、そのメッセージを2つのサーバの一方から取り込む。クライアントが入出力を繰り返しても、CEPはユーザのeメール・クライアントのままである。したがって、新しいメッセージが到着すると、CEPは引き続き、対応するeメール・サーバとの持続された接続に沿ってローカル・サイトにメッセージをコピーする。たとえば、クライアント814はそのメッセージをサーバ802から取り込むため、クライアント814からの接続が存在しないときでもCEP 811は自動的にすべてのメッセージをサーバ802からフェッチしEPC 810にプリロードする。

実際上、EPCで終了される持続的接続の集合は、ネイティブ・クライアント-サーバ接続を通じてコンテンツを送出するサーバからユーザ位置までのユーザ中心のコンテンツ送出ネットワークを形成する。したがって、ユーザ位置は、接続の基本構造によって暗示され、これを収集して何らかの種類のデータベースに明示的に記憶する必要はない。

本発明の他の態様では、EPCおよびCEP機能が1つのプロセスに統合され、CEPDがCEPエントリを含む必要はなくなる。このような態様では、CEPはプロキシ・エンドポイントを実現し、メッセージ記憶装置と直接対話する。クライアントがそのセッションを終了すると、CEPは上述のようにサーバ・セッションを持続する。図9はこの一例を示している。図示のように、CEPは、その機能をEPCに組み込み、クライアント・サーバ伝送接続を直接終了する。

他の態様では、CEPを、McCanne III、McCanne Iに記載されたようにトランザクション・アクセラレータおよびセグメント化システムとして構成し、任意で、McCanne IIに記載されたように階層セグメント化を使用し、McCanne IVに記載されたように伝送接続遮断・自動構成を使用することができる。さらに、CEPを使用して、eメールだけでなく任意のユーザ・アフィニティ・ベースのプロトコル用のコンテンツ送出を実行することができる。このことは、McCanne Iに記載されたセグメント化・トランザクション加速方式がプロトコルおよびアプリケーションから独立したものであるために容易になる。すなわち、上述のEPCとは異なり、セグメント化を使用したトランザクション加速は、eメールだけでなく多くの異なるプロトコルに有効である。

図10はこのことを示している。持続セグメント記憶装置（PSS）1004を有するクライアント側トランザクション・アクセラレータ（CTA）1003はクライアントの近くに位置し、一方、PSS 1006を有するサーバ側トランザクション・アクセラレータ（STA）1005はサーバの近くに位置している。CTA1003とSTA1005との間にWANが介在している。さらに、クライアントとCTA 1003との間にCEPD 1002が介在している。CEP 1008は、クライアント1001からサーバ1007までの伝送接続を終了し、CEPD 1002からサーバ1007までの新しい接続を開くことを試みる。CEP 1008がサーバ1007との接続を開始すると、CTAおよびSTAは、たとえばMcCanne IVに記載されたような何らかの方法で接続を遮断する。

この構成が与えられたと仮定すると、CEP 1008は、サーバに所望のデータをクライアントに向けて送信させる合成プロトコル・メッセージをクライアント-サーバ・セッションに導入することによって所望のデータのコンテンツ送出を実行する位置に存在する。CEP 1008は、結果として得られるデータを含むセグメントがすべてPSS 1004およびPSS 1006にもはや存在していることを知って、データを破棄する。後にクライアント1001が対応するデータをサーバ1007から取り込むことを試みるとき、McCanne Iに記載されたように、CTA/STA対が協働して要求されたデータを破壊するため、データをネットワーク上で再送信する必要はなくなる。

eメールとは異なり、メッセージを特定のユーザに送出する場合、他のプロトコルは、ユーザによってアド・ホック式に生じるデータ・アクセス・パターンを伴う。たとえば、CIFSなどのファイル・アクセス・プロトコルでは、ユーザは、様々なユーザによって作成され、それぞれの異なるサーバ上に記憶された、複数の異なるファイルにアクセスすることができる。同様に、Web（民間企業Webまたは一般にはインターネット）をブラウジングするユーザは、世界のほぼどこからでもデータにアクセスすることができる。このことに対処するために、Webページまたはファイルなどのデータ・オブジェクト用のユーザ・アフィニティをCEPによって推定することができる。

1つの推定手法は、McCanne IIIに記載されたトランザクション予測フレームワークを使用する手法である。他の手法は、ユーザ・アフィニティ情報をデータベースに収集し、このデータベースを使用してCEPコンテンツ送出アルゴリズムを駆動する手法である。

一態様では、デバイス内の各CEPはユーザ・アフィニティ・データベース（UADB）を維持する。UADBは、データ・オブジェクトへのアクセスを記録したレコードのセットを含む。各レコードは、ユーザ識別子（たとえば、ログイン名）、オブジェクト識別子（たとえば、ファイル・サーバおよびパス名、またはWeb URL）、最初のアクセスのタイムスタンプ、最新のアクセスのタイムスタンプ、カウント、および場合によってはその他のフィールドを含む。レコードは、様々なコンテンツ送出ポリシーおよび／またはアルゴリズムによってそれぞれの異なる方法で使用することのできる他のプロトコルまたはアプリケーション固有の情報を含んでよい。たとえば、ファイル・アクセス・プロトコル用のレコード・フォーマットは、対象となるオブジェクトの「最後に修正された時間」を含んでもよい。

データがCEPを通じてクライアントによってアクセスされるたびに、CEPはUADB内のオブジェクト・レコードを参照する。オブジェクト・レコードが存在しない場合、そのユーザおよびオブジェクトについて新しいレコードが作成されてUADBに入力され、タイムスタンプが現在時間に設定され、カウントが1に初期化される。レコードがすでに存在する場合、カウントが増分され、最後のアクセス時間が更新される。

UADBが与えられたと仮定すると、CEPはコンテンツ送出をバックグラウンド・プロセスとして、たとえば、夜間や、ネットワーク活動がアイドル状態である時間に実行したり、構成されたビット・レートで連続的に実行したりする。これは、クライアントが接続を終了した後にCEPによって維持されるセッションに対して行うことができ、またはCEPは、それ自体の接続を開始する許可を有する場合にログインする（接続を確立する）ことができる。

このバックグラウンド送出プロセスは、CEPによってラウンドロビン式に取り扱われる、ユーザに一致するすべてのレコードについて、CEPにUADBを走査させることによって実現される。各レコードごとに、オブジェクトがサーバから取り込まれ、CEPによってそのまま破棄されるので、オブジェクトを表すすべてのセグメント・データがローカルCTA内のPSSに配備される。このステップは、さらに、（上述のように）対象となるオブジェクトについて修正タイムスタンプを維持し、サーバ上の修正時間がオブジェクト・レコードに記憶されている最後の修正時間よりも新しい場合に、データ・オブジェクトを単にフェッチすることによって最適化することができる。この方式は、McCanne IおよびMcCanne IIに記載されたセグメント化アルゴリズムの効率的な特性のために、複数回取り込まれる同様のデータ（たとえば、同じデータを有する2つのファイル）がWANを1度しか通らないので、特に効率的である。

データ・オブジェクトを走査し、かつ必要に応じてネットワークを介して取り込む頻度を制御するために、様々なポリシーを使用することができる。たとえば、より頻繁にアクセスされるオブジェクトは、あまり頻繁にアクセスされないオブジェクトよりも頻繁に走査することができる。またはより最近アクセスされたオブジェクトは、より以前にアクセスされたオブジェクトよりも頻繁に走査することができる。または、設定変更可能な一定期間にわたってアクセスされなかったオブジェクトは、そのままUADBから破棄することができる。

図11は、CEPを介在させ、CIFSのようなファイル・アクセス・プロトコルを仮定した場合の、クライアントとサーバの対話のスイム図である。この例では、CEPは、ファイル・アクセス・パターンを記録するUADB（図示せず）を含む。クライアントがすでにCIFSサーバとのCIFSセッションを確立していると仮定する。

図の1番上で、クライアントはファイル「A」を開き、次にファイル「A」からデータを読み取り、ファイル「A」を閉じる。このようなクライアント-サーバ・トランザクションがCEPを通って流れるとき、CEPは、ユーザがファイル「A」にアクセスしたことを示すオブジェクト・レコードをUADBに記録する。しばらくして、クライアントがログアウトし、セッションが終了する。ただし、上述のように、CEPは、切断されたクライアントに代わってサーバとのセッションを維持し、コンテンツ送出を行う。さらにしばらくして、ファイル「A」の書き込み許可を有する他のあるユーザによってファイル「A」に変更が加えられる。常に、バックグランド・コンテンツ送出プロセスがCEP内で実行され、「stat」メッセージをファイル「A」のサーバに送信することによって、図示のように時折ファイル「A」の修正時間がチェックされる。ある時点で、CEPは、ファイル「A」の修正時間が、UADBオブジェクト・レコードに記憶されている修正時間よりも後の時間であることに気づく。その結果、ファイル「A」に含まれるデータを表すすべてのセグメントをローカルCTAのPSS内に複製するのに成功したので、CEPはファイル「A」を開き、そのコンテンツを読み取り、かつ結果として残ったファイルをそのまま破棄する。クライアントは、サーバとの新しいCIFSセッションを確立し、ファイル「A」にアクセスする。CTAは次に、古いCIFSセッションを切断し、新しいCIFSセッションを確立するのを可能にする。

または、STA内のエージェントは、古いセッションを切断し新しいセッションを確立するのを可能にする作業を実行することができる。このサーバ側手法の利点は、経時的に複数の位置からeメール・サービスにアクセスしているユーザが、一度に1つのクライアントしかアクティブにならないにもかかわらず、アクティブなコンテンツ送出セッションの痕跡を残さないことである。すべての必要なセグメントがCTAに存在するため、WANを介してファイル「A」を取り込むうえで高性能が実現される。

CEPをトランザクション・アクセラレータおよびセグメント化と組み合わせて使用することのいくつかの利点は、eメールが多数の受信側に送信される例で明らかである。この場合、あるメッセージを多数の受信側に送信すると仮定する。すると、CEPの多数のインスタンスのそれぞれがeメール・データの別々のコピーを取り込むにもかかわらず、そのデータはCTA/STA対によってWANを介して各位置に一度だけ送信される。各CEPが互いに独立して働き、データを効率的に送出するための調和を図るうえで何もしないにもかかわらず、eメールの1つのコピーのみが任意の所与の位置に送信される。さらに、この手法は、既存の構造基盤と容易に統合され、既存のクライアント、サーバ、またはアプリケーションに対する変更や追加を必要としない。

CIFSおよびeメールのCEPコンテンツ送出の考察において明白なように、合成メッセージを解釈してクライアント-サーバ・セッションに導入し、所望のデータ伝送を行うには、CEP内のプロトコル固有の知識が必要とされる。いくつかの態様では、プロトコル固有の知識は、CTA内に同時に存在する複数の種類のCEPに埋め込まれ、「修正CTA」が作成される。この構成は、修正CTAを通じて通信するいくつかのクライアントを示す図12に示されている。各クライアントは、プロトコル固有のCEPのインスタンスと通信し、そのような各CEPの複数のインスタンスがあってよい。

たとえば、CIFSクライアントは、CIFS CEPと通信し、MAPクライアントはMAPI CEPと通信する。McCanne Iに記載されているように、これらのCEPのそれぞれは、PSSにてWAN上の帯域幅消費量を減らすトランザクション変換モジュール（TTおよびTT^-1）と通信するクライアント・プロキシとして働くことができる。各CEPは、STA上のサーバ側プロキシと論理的に通信し、STAはオリジン・サーバと通信し、それによってクライアントをターゲット・サーバに接続する。たとえば、CIFS CEPはCIFSサーバ・プロキシと通信し、CIFSサーバ・プロキシはターゲットCIFSサーバと通信する。

上記の説明は例示的なものであり、限定的なものではない。当業者には、本開示を検討したときに本発明の多数の変形態様が明らかになろう。したがって、本発明の範囲は、上記の説明を参照して決定すべきではなく、その代わりに添付の特許請求の範囲をその全範囲の均等物と共に参照して決定すべきである。

この例ではeメール・プロキシ・デバイス（EPD）である、本発明によるプロキシ・デバイスの一態様のブロック図である。 二重ポートNICデバイスとして実現された、本発明によるプロキシ・デバイスのブロック図である。 データを要求している可能性の高いユーザの近くのネットワーク位置に、そのデータが要求される前にそのデータを送出しておくのに使用できるコンテンツ送出エージェント（CDA）、ユーザ位置データベース（ULDB）の構成を示す図である。 図3に示されているような構成を使用したeメール送出プロセスを示すスイム図である。 接続エンドポイント・プロキシ（CEP）によってプロキシ処理を実行される接続を示す図である。 接続エンドポイント・プロキシ・デバイス（CEPD）がeメール・プロキシ・キャッシュ（EPC）と一体化されたコンテンツ送出システムの一態様を示す。 通常のeメール・メッセージ・プロトコルを通じてコンテンツ送出機能をどのように実行するかの一例を示すスイム図である。 分散型企業における接続エンドポイント・プロキシ（CEP）およびeメール・プロキシ・キャッシュ（EPC）の構成を示す図である。 二重ポートNICデバイスを含む一体化されたEPCおよびCEPデバイスの一態様を示す。 一体化されたCEPDおよびクライアント側トランザクション・アクセラレータ（CTA）の一態様を示す。 CEPを介在させ、CIFSなどのファイル・アクセス・プロトコルを用いた場合の、クライアントとサーバの対話のスイム図である。 プロトコル固有および／またはプロトコル対応CEPを含むコンテンツ送出システムの一部の図である。

Claims (17)

1. クライアントが、トランザクションを要求するホストであり、サーバが、クライアント要求に応じて応答を発行するホストであり、クライアントとサーバとの間のパケットが、1つまたは複数のホップを含みかつ克服すべき1つまたは複数の動作特性を有するネットワーク・パスを通じて伝達される、クライアントとサーバとの間のトランザクションをサポートするネットワークにおける、
   データ・オブジェクトに対するユーザ・アフィニティを有するユーザが、該データ・オブジェクトに対するユーザ・アフィニティを有さないユーザよりも該データ・オブジェクトを要求する可能性が高くなるように、データ・オブジェクトのユーザ・アフィニティが、どのユーザが該データ・オブジェクトに関連付けられているかを示す、データ・オブジェクトに対するユーザ・アフィニティを識別する段階；
   ユーザ位置が、ユーザとプリロード・ノード（preload node）との間の関連を表しており、プリロード・ノードがネットワーク位置であり、プリロードされたデータを記憶して1つまたは複数の動作特性のうちの少なくとも1つを克服することができる、ユーザ位置を動的に識別する段階；および
   指定されたユーザ・アフィニティを有する特定のデータを、クライアント要求に先立ち、該特定のデータに対するユーザ・アフィニティを有する特定のユーザに代わって、該特定のユーザのユーザ位置として識別されたプリロード・ノードまでサーバから伝送する段階
   を含む、1つまたは複数の動作特性を克服するためにデータを伝送する方法。
2. 1つまたは複数の動作特性が、帯域幅使用量、エラー率、および待ち時間から選択される、請求項1記載の方法。
3. データ・オブジェクトが、eメール・オブジェクト、データセット、ファイル、またはデータベースの一部のうちの1つまたは複数を有する、請求項1記載の方法。
4. データ・オブジェクトのユーザ・アフィニティが単一のユーザに対するものである、請求項1記載の方法。
5. データ・オブジェクトのユーザ・アフィニティが複数のユーザに対するものである、請求項1記載の方法。
6. ユーザ・アフィニティを識別する段階が、
   どのユーザがどのデータ・オブジェクトにアクセスするかを判定する段階；および
   該データ・オブジェクトにどのユーザがアクセスするかに従って、該データ・オブジェクトにユーザ・アフィニティを割り当てる段階
   を含む、請求項1記載の方法。
7. ユーザ位置を動的に識別する段階が、
   どのユーザが特定のクライアントを使用してネットワークにアクセスするかを判定する段階；
   該特定のクライアントに関連するプリロード・ノードを判定する段階；および
   該ユーザを該プリロード・ノードに関連付けるレコードを、ユーザ位置データベースに投入し、それによってユーザ位置を識別する段階
   を含む、請求項1記載の方法。
8. 各プリロード・ノードがプロキシである、請求項1記載の方法。
9. 各プリロード・ノードがデータ・キャッシュを含む、請求項1記載の方法。
10. 各プリロード・ノードがプロキシおよびセグメント記憶装置を含む、請求項1記載の方法。
11. ユーザ位置を動的に識別する段階が、
    第1のクライアントと第1のクライアントによって開始された第1のサーバとの間の接続のためのクライアント-サーバ接続を、プリロード・ノードに関連するプロキシにおいて遮断する段階；
    該接続が流れるネットワーク・パスに、接続エンドポイント・プロキシ（CEP）を含める段階；ならびに
    CEPが、第1のクライアントによって開始された接続の終了を検出したときに、
    a)第1のサーバとの接続を保持し、合成トランザクションを第1のサーバに向けて投入し、暗黙的に該接続を使用して、該接続に関連するユーザのユーザ位置を識別する段階；および
    b)合成トランザクションの結果を受信し、それによって、副次効果として、該1つまたは複数の動作特性の改善における使用のためにデータが記憶される段階
    を含む、請求項1記載の方法。
12. 合成トランザクションにおいて要求されているデータ・オブジェクトが、すべてのネットワーク・ユーザの部分集合であるユーザに関連付けられ、該合成トランザクションを開始するCEPに関連付けられるクライアントの部分集合が、ユーザの該部分集合のうちの1つまたは複数のユーザに関連付けられたクライアントを含む、請求項11記載の方法。
13. トランザクションがeメール・メッセージに関係しており、合成トランザクションが、1つまたは複数の受信側群に関連付けられるeメール・メッセージの伝送用であり、CEPが、該CEPを通って流れる接続を開始するクライアントが少なくとも1つの受信側群によって動作されることを示す表示を有し、それによって、合成トランザクションの結果を用いてeメール・データが供給されるときの1つまたは複数の動作特性を向上させる、請求項11記載の方法。
14. 第1のクライアントが接続を終了した後にCEPが接続を維持しておりかつ第1のクライアントが第2の接続を開始した場合に、該CEPを使用して、維持されている接続を切断し、第2の接続を確立する段階をさらに含む、請求項11記載の方法。
15. 第2のクライアントによって開始され、CEPを含むネットワーク・パスを流れる、第2のクライアントと第1のサーバまたは第2のサーバとの間の第2の接続についてのデータを伝送する段階；
    該CEPが、第2のクライアントによって開始された第2の接続の終了を検出したときに、
    a)第2の接続を保持し、合成トランザクションを該接続のサーバ端部に向けて投入する段階；および
    b)結果を記憶するか、または結果を少なくとも部分的に再生成するのに使用可能な記憶装置を投入する段階；
    第2のクライアントが新しい接続を開いたことをCEPが検出したときに、新しいトランザクションに対して、記憶された結果または投入された記憶装置を使用し、それによって第2のクライアントについての1つまたは複数の動作特性を向上させる段階
    をさらに含む、請求項11記載の方法。
16. クライアントが、トランザクションを要求するホストであり、サーバが、クライアント要求に応じて応答を発行するホストであり、クライアントとサーバとの間のパケットが、1つまたは複数のホップを含みかつ克服すべき1つまたは複数の動作特性を有するネットワーク・パスを通じて伝達される、クライアントとサーバとの間のトランザクションをサポートするネットワークにおける、
    第1のクライアントと第1のクライアントによって開始された第1のサーバとの間の接続についてのデータを伝送する段階；
    該接続がそれを通じて第1のクライアントの近くを流れるネットワーク・パスに、クライアント接続エンドポイント・プロキシ（クライアントCEP）を含める段階；
    該接続がそれを通じて第1のサーバの近くを流れるネットワーク・パスに、サーバ接続エンドポイント・プロキシ（サーバCEP）を含める段階；
    クライアントCEPが、第1のクライアントによって開始された該接続の終了を検出したときに、
    c)第1のサーバとの接続を保持し、合成トランザクションを第1のサーバに向けて投入する段階；
    d)該合成トランザクションの結果を受信する段階；および
    e)結果を記憶するか、または該結果を少なくとも部分的に再生成するのに使用可能な記憶装置を投入する段階；
    第1のクライアントが新しい接続を開いたことをクライアントCEPが検出したときに、新しいトランザクションに対して、記憶された結果または投入された記憶装置を使用し、それによって1つまたは複数の動作特性を向上させる段階；ならびに
    クライアントCEPとサーバCEPとの間で信号を送り、1つまたは複数の動作特性をさらに向上させる段階
    を含む、1つまたは複数の動作特性を克服するためにデータを伝送する方法。
17. 信号を送る段階が、トランザクションのすべてまたは一部を再生成するのに使用可能なセグメント記憶装置の更新を含む、請求項16記載の方法。

Images