以下に、本発明の好ましい実施例が図示されている添付図面を参照しながら本発明について詳述する。しかし、本発明は多くの異なる態様で実施することができ、本明細書に記載の実施例に限定されるものと解釈してはならない。これらの実施例は、本開示を綿密かつ十全なものとし、本発明の範囲を当業者に完全に伝えるために示すものである。全体を通じて同様の番号は同様の要素を指す。
第3図ないし第12図と第15図ないし第21図は、本発明による方法およびシステムを示すフローチャートである。フローチャートの各ブロックと、フローチャートのブロックの組合せは、コンピュータ・プログラム命令によって実施することができることがわかるであろう。これらのコンピュータ・プログラム命令は、コンピュータまたはその他のプログラム式装置にロードし、それによってコンピュータまたはその他のプログラム式装置上で実行される命令がフローチャートの1つまたは複数のブロックに指定されている機能を実施する手段を生じさせるように機械を作り出すことができる。これらのコンピュータ・プログラム命令を、コンピュータまたはその他のプログラム式装置に対して特定の方式で機能するように指示することができるコンピュータ可読メモリに格納し、それによってコンピュータ可読メモリに格納された命令がフローチャートの1つまたは複数のブロックに指定されている機能を実施する命令手段を含む製品を作り出すようにすることができる。また、コンピュータ・プログラム命令をコンピュータまたはその他のプログラム式装置にロードして、コンピュータまたはその他のプログラム式装置上で一連の操作ステップが行われるようにし、コンピュータまたはその他のプログラム式装置上で実行される命令がフローチャートの1つまたは複数のブロックに指定されている機能を実施するステップを提供するようにコンピュータ実施プロセスを作り出すこともできる。
したがって、フローチャートのブロックは、指定された機能を実行する手段の組合せと、指定された機能を実行するステップの組合せとに対応する。また、フローチャートの各ブロックと、フローチャートのブロックの組合せは、指定された機能またはステップを実行する特定用途向けハードウェア・ベースのコンピュータ・システムによって、または特定用途向けハードウェアとコンピュータ命令の組合せによって実施することができることがわかるであろう。
第2図に、本発明の一実施例を示す。第2図に示すように、ウェブ・ブラウザ10はクライアント側インタセプト・モジュール30と通信する。ウェブ・サーバ20はサーバ側インタセプト・モジュール40と通信する。次にクライアント側インタセプト・モジュール30が通信リンク35を介してサーバ側インタセプト・モジュール40と通信する。ウェブ・ブラウザ10とクライアント側インタセプト・モジュール30は、第1のコンピュータ5に組み込むことができる。サーバ側インタセプト・モジュール40とウェブ・サーバ20は第2のコンピュータ6に組み込むことができる。第1のコンピュータ5と第2のコンピュータ6は外部通信リンク35を介して通信する。
ウェブ・ブラウザ10は、ハイパーテキスト転送プロトコル(HTTP)とハイパーテキスト・マークアップ言語(HTML)を使用して、やはりHTTPとHTMLを使用するインターネット・ウェブ・サーバ20と通信するインターネット・ウェブ・ブラウザであることが好ましい。動作中、ウェブ・ブラウザ10はHTTPデータ・ストリームを出力し、それがクライアント側インタセプト・モジュール30によってインタセプトされる。クライアント側インタセプト・モジュール30によるHTTPデータ・ストリームのインタセプトは、クライアント側インタセプト・モジュール30が127.0.0.1のようなネットワーク番号127を有するIPアドレスにあるTCP/IPループバック機構を使用して行うことができる。次に、クライアント側インタセプト・モジュール30はHTTPデータ・ストリームをクライアント/サーバ固有プロトコルに変換または変形し、そのクライアント/サーバ固有データ・ストリームを外部通信リンク35に送る。サーバ側インタセプト・モジュール40はこのクライアント/サーバ固有データ・ストリームを受け取り、ウェブ・ブラウザ発信通信に対応する元のHTTPデータ・ストリームを再構築する。この再構築されたHTTPデータ・ストリームは次にウェブ・サーバ20に転送される。ウェブ・サーバ20はインターネット・ウェブ・サーバの通常の方式でHTTPデータ・ストリームに応答する。当業者ならわかるように、ウェブ・サーバ20は複数のブラウザがインターネットに接続することができるようにするプロキシとすることもできる。
たとえば特定のURLホーム・ページを求めるブラウザ要求に応答してウェブ・サーバ20がウェブ・ブラウザ10に送る情報を受け取ると、ウェブ・サーバ20はウェブ・ブラウザ10に送る通信に対応するHTTPデータ・ストリームを出力する。このウェブ・サーバ発信通信はサーバ側インタセプト・モジュール40によってインタセプトされ、クライアント/サーバ固有データ・ストリームに変換される。次に、ウェブ・サーバ発信通信に対応するクライアント/サーバ固有データ・ストリームは外部通信リンク35で第2のコンピュータから第1のコンピュータに送られる。このクライアント/サーバ固有データ・ストリームをクライアント側インタセプト・モジュール30が受け取り、ウェブ・サーバ発信通信に対応するHTTPデータ・ストリームが再構築され、ウェブ・ブラウザ10に供給される。
本発明の特定の実施例では、外部通信リンク35は無線通信リンクである。その場合、ユーザにとって受容可能なシステム・パフォーマンスを得るために、外部通信リンク35を介する通信量を、通信リンク35を介して伝送しなければならない通信の頻度と情報量の両方について減らすことが望ましい。したがって、本発明はキャッシング技法と、差分計算技法と、プロトコル縮小技法とを使用して、外部通信リンク35を介する必要通信量を最小限にする。これらの技法は、HTTPのステートレスまたは確率論的プロトコルを、クライアントおよびサーバに固有の情報を使用するクライアント/サーバ固有プロトコルに変換して通信の量と頻度を減らすことによって実現される。
本発明について、単一のウェブ・ブラウザ・アプリケーションと単一のウェブ・サーバ・アプリケーションに関して説明するが、当業者ならわかるように、本発明の利便および利点は、単一のウェブ・サーバに関連づけられた複数のウェブ・ブラウザを使用した場合にも得ることができる。したがって、本発明の方法、装置、およびプログラム製品は、各ブラウザがクライアント側インタセプト・モジュールと通信する複数のブラウザと共に使用することもでき、その場合それらのクライアント側インタセプト・モジュールはウェブ・サーバまたはウェブ・プロキシのサーバ側インタセプト・モジュールと通信することになる。
本発明の一実施例では、クライアント側インタセプト・モジュール30とサーバ側インタセプト・モジュール40の両方がキャッシュ格納機能を有する。第1のコンピュータにあるクライアント・キャッシュには、ウェブ・ブラウザ発信通信に応答してウェブ・ブラウザが受け取るHTTPデータ・ストリームが格納される。第2のコンピュータにあるサーバ・キャッシュには、ブラウザ発信通信に応答してウェブ・サーバが提供するURLのHTTPデータ・ストリームが格納される。
当業者ならわかるように、第1のコンピュータまたは第2のコンピュータにあるキャッシュは、コンピュータの特定のハードウェア構成に基づく任意の容量とすることができる。これらのキャッシュには、各通信について、通信のURL、巡回冗長検査(CRC)などの通信内容に基づく固有識別子、キャッシュ項目の作成またはリフレッシュが行われた時刻を示すデータ格納時刻(SDT)、および通信のデータを含む情報が格納される。したがって、キャッシュに格納されている各通信についてキャッシュ項目のディレクトリを作成することができる。さらに、所与のハードウェア構成で使用可能な資源は限られているため、第1のコンピュータおよび第2のコンピュータにあるキャッシュを維持するために当業者に周知の任意の数のキャッシング技法を使用することができる。したがって、たとえば、新しい項目の追加によってユーザ定義キャッシュサイズを超える場合、キャッシュは最も古いディレクトリ項目を無効化し、無効化された項目の代わりに新しい項目を追加することができる。さらに、ウェブ・ブラウザ・アプリケーションまたはウェブ・サーバ・アプリケーションの複数のインスタンスにわたって、あるいは第1または第2のコンピュータの電源投入サイクルについてさえもキャッシュ項目を維持して持続キャッシュを作成することができる。
以下に、クライアント側インタセプタ・モジュール30とサーバ側インタセプト・モジュール40の動作を示すフローチャートである第3図ないし第6図を参照しながら本発明の一態様によるキャッシング構造について説明する。
具体的に第3図を参照すると、ブロック100はクライアント側インタセプト・モジュール30がウェブ・ブラウザ10から要求を受け取ったことを示している。この要求は、HTTPデータ・ストリームの形式をとることができる。ブロック105に示すように、クライアント側インタセプト・モジュール30は着信した要求のユニフォーム・リソース・ロケータ(URL)を検査する。クライアント側インタセプト・モジュール30はURLから、ウェブ・ブラウザ発信要求に対応する情報が前に第1のコンピュータにある第1のクライアント・キャッシュに格納されているかどうかを判断する。
URLに対応する情報が前にクライアント・キャッシュに格納されていなかった場合、ブロック106に示す操作がクライアント側インタセプト・モジュールによって行われる。クライアント側インタセプト・モジュール30は外部通信リンク35でサーバ側インタセプト・モジュール40に要求を送る。
しかし、ブロック105に示すようにウェブ・ブラウザ発信通信に問い合わせたときに、ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目が存在する場合、最も単純な実施例では、その情報がHTTPデータ・ストリームとしてウェブ・ブラウザに供給される。しかし、第3図に示すように、本発明の好ましい実施例は、ウェブ・ブラウザ発信通信に対応するキャッシュ項目に対して本明細書でコヒーレンシ間隔検査と呼ぶ操作を行う。この操作は第3図のブロック110に示されている。
クライアント側インタセプト・モジュールのコヒーレンシ間隔はユーザ定義とすることができ、キャッシュ項目が陳腐化し、存在はしていてもウェブ・サーバに対してウェブ・ブラウザ発信通信に対応する情報を要求することによって最新化しなければならなくなるまでのキャッシュ項目が存在することができる時間の長さである。ブロック110に示すコヒーレンシ間隔検査は、現在日時をウェブ・ブラウザ発信通信に対応するキャッシュ項目のSDTとユーザによって指定されたコヒーレンシ間隔との和と比較することによって行うことができる。現在日時がこの和より大きい場合、ウェブ・ブラウザ発信通信に対応するキャッシュ内に格納されている情報は陳腐化しており、ブロック110の「No」に分岐する。しかし、現在日時がSDTにユーザ定義コヒーレンシ間隔を足した和よりも小さい場合は、ブロック110で「Yes」に分岐し、ブロック111に示すように、そのキャッシュ項目がHTTPデータ・ストリームとしてブラウザに供給される。したがって、第3図のブロック100でクライアント側インタセプト・モジュール30が受け取ったブラウザ発信通信が完了する。
ブロック110に示すコヒーレンシ間隔検査によって、第1のコンピュータにあるキャッシュ項目が陳腐化していると判断された場合、サーバ側インタセプト・モジュール40に対して要求を行い、第2のコンピュータにあるキャッシュ項目のコヒーレンシを検査する。この操作は第3図のブロック112に示されている。これは、外部通信リンク35を介してサーバ側インタセプト・モジュール40に、特定のクライアント側インタセプト・モジュール30のコヒーレンシ間隔と、ウェブ・ブラウザ10によって発信されたHTTP要求と、ウェブ・ブラウザ発信通信のURLに対応するクライアント・キャッシュの内容を示す固有の標識を供給することによって行われる。好ましい実施例では、この固有の標識はキャッシュ項目の巡回冗長検査(CRC)である。
次に第5図を参照すると、外部通信リンク35を介してクライアント側インタセプト・モジュール30から受け取った情報に応答したサーバ側インタセプト・モジュール操作が示されている。サーバ側インタセプト・モジュール40がクライアント側インタセプト・モジュールから要求を受け取ると、サーバ側インタセプト・モジュール40は所定のクライアント・コヒーレンシ時間間隔と、クライアント・キャッシュ項目のCRC値と、ウェブ・ブラウザによって発信されたHTTP要求を受け取る。この情報の受信は、第5図のブロック120に示されている。
クライアント側インタセプト・モジュール30から情報を受け取った後、サーバ側インタセプト・モジュール40は第2のコンピュータにあるそのサーバ・キャッシュを検査して、ウェブ・ブラウザによって発信されたHTTP要求のURLに対応するサーバ・キャッシュ項目が存在するかどうかを判断する。ブロック125に示すようにウェブ・ブラウザ発信通信に問い合わせた後、サーバ側インタセプト・モジュール40が、ウェブ・ブラウザ発信通信によって要求された情報に対応するキャッシュ項目が存在すると判断した場合、ブロック125で「Yes」分岐をとる。次に、サーバ側インタセプト・モジュール40はSSIモジュール40の現在日時を、ウェブ・ブラウザ発信通信によって要求された情報に対応するサーバ・キャッシュ項目のSDTとクライアント側インタセプト・モジュールから受け取った所定のクライアント・コヒーレンシ時間間隔との和と比較する。
現在日時がサーバ・キャッシュ項目のSDTとコヒーレンシ間隔との和より小さい場合、第5図のブロック130の「Yes」経路をとる。次にサーバ側インタセプト・モジュール40はサーバ・キャッシュ項目のCRCとクライアント・キャッシュのCRCとを比較して、その2つのキャッシュ項目が同じかどうかを判断する。2つのキャッシュ項目が同じ場合、ブロック135の「Yes」分岐をとり、ブロック136に示すように、「コヒーレント」応答がクライアント側インタセプト・モジュール30に送られる。
ブロック135の条件で、CRCが等しくないと判断された場合、クライアント・キャッシュに入っている情報とサーバ・キャッシュに入っている情報は同じでなく、ブロック137に示すようにサーバ側インタセプト・モジュールは外部通信リンクを介して第1のコンピュータにサーバ・キャッシュ項目を送る。サーバ・キャッシュ項目をクライアント側インタセプト・モジュール30に送信する際に、サーバ側インタセプト・モジュールはその項目を、サーバ・キャッシュ項目のCRCと、サーバ・キャッシュ項目データと、サーバ・キャッシュ項目のエージとを含むクライアント固有通信プロトコルに変換する。サーバ・キャッシュ項目のエージは、現行日時からキャッシュ項目のSDTを引くことによって計算する。
第5図に関して最後に、SDTに所定のクライアント・コヒーレンシ時間間隔を足した和が現在日時よりも小さいか、またはウェブ・ブラウザ発信通信のURLに対応する項目がない場合、それぞれブロック130の「No」経路またはブロック125の「No」経路がとられる。したがって、ブロック126の操作が行われ、サーバ側インタセプト・モジュール40がサーバにウェブ・ブラウザ発信通信をHTTPデータ・ストリームとして送ることになる。サーバ側インタセプト・モジュール40がウェブ・ブラウザ発信通信をサーバにHTTPデータ・ストリームとして送らなければならない場合、サーバ側インタセプト・モジュール40は第6図の操作を実行する。
第6図のブロック140に示すように、ウェブ・ブラウザ発信通信に応答して、サーバ側インタセプト・モジュールがウェブ・サーバ20からHTTPデータ・ストリームを受け取る。HTTPデータ・ストリームを受け取ると、サーバ側インタセプト・モジュール40はHTTPデータ・ストリームのCRCを計算し、HTTPデータ・ストリームを一時的に格納する。次に、ブロック145に示すように、サーバ側インタセプト・モジュールはHTTPデータ・ストリームに問い合わせて、HTTPデータ・ストリームのURLに対応するサーバ・キャッシュ項目が存在するかどうかを判断する。そのような項目が存在しない場合、ブロック145の「Yes」経路が実行される。次にサーバ側インタセプト・モジュール40は、ブロック150に示すように、ウェブ・サーバ20から受け取ったHTTPデータ・ストリームの最も最近に計算されたCRCを、ウェブ・サーバ発信応答通信のURLに対応するサーバ・キャッシュ項目のCRCと比較する。CRCが同じ場合、ブロック150の「Yes」分岐が行われる。サーバ側インタセプト・モジュール40はブロック151に示すようにサーバ・キャッシュ項目のSDT項目を更新し、ブロック152に示すようにウェブ・サーバ20によって受信されたHTTPデータ・ストリームを一時格納域から除去する。
CRC比較の結果によって、サーバ・キャッシュ項目がウェブ・サーバ20から受け取ったHTTPデータ・ストリームと異なることが示された場合、ブロック150の「No」経路が行われる。サーバ側インタセプト・モジュール40はブロック153に示すようにサーバ・キャッシュから既存のデータを除去し、次にブロック154に示すようにより新しい方の情報によってサーバ・キャッシュを更新する。ブロック154に示すように、この更新にはサーバ・キャッシュにウェブ・サーバ通信のCRCを格納するステップと、キャッシュ項目の一部として現在日時をキャッシュ項目のSDTとして格納するステップと、HTTPデータ・ストリームを格納するステップとが含まれる。サーバ・キャッシュ項目を更新するかどうか、またはサーバ・キャッシュ項目がウェブ・サーバ20から受け取ったHTTPデータ・ストリームと同じであることが判明したかどうかを問わず、いずれの場合もサーバ側インタセプト・モジュールは次にサーバ・キャッシュ項目がウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目と同じかどうかを判断する。この操作をブロック155に示す。
サーバ側インタセプト・モジュール40が、ウェブ・サーバ20から受け取った応答に対応するキャッシュ項目が存在しないと判断した場合、ブロック145の「No」経路がとられる。ブロック146に示すように、ウェブ・サーバからの応答のURLを格納し、ウェブ・サーバからの応答のCRCを格納し、HTTPデータ・ストリームを格納し、SDTとして現在日時を格納することによって、サーバ・キャッシュ項目が作成される。ウェブ・ブラウザ発信通信に対応するキャッシュ項目を作成した後、サーバ側インタセプト・モジュール40は次に、ブロック155に示すように、再度、このサーバ・キャッシュ項目のCRCを対応するクライアント・キャッシュのCRCと比較する。
サーバ・キャッシュ項目とクライアント・キャッシュ項目との比較の結果によって、キャッシュ項目が同じであることがわかった場合、ブロック155の「Yes」分岐がとられ、ブロック156の操作が行われる。ブロック156に示すように、サーバ側インタセプト・モジュール40がクライアント側インタセプト・モジュール30に応答を送る。サーバ側インタセプト・モジュール40は、クライアント側インタセプト・モジュールにコヒーレント応答を送り、ゼロのエージを送ることによって、サーバ要求キャッシュ項目をクライアント/サーバ固有データ・ストリームに変形する。
サーバ側インタセプト・モジュール40が、クライアント・キャッシュ項目がウェブ・ブラウザ発信通信に対応するサーバ・キャッシュ項目と同じではないと判断した場合、ブロック155の「No」分岐がとられ、ブロック157の操作が行われる。ブロック157に示すように、サーバ側インタセプト・モジュール40は、サーバ・キャッシュ項目をクライアント/サーバ固有データ・ストリームに変換または変形する。このデータ・ストリームには、サーバ・キャッシュ項目のCRCと、サーバ・キャッシュ項目HTTPデータ・ストリームと、キャッシュ項目のゼロに設定されたエージとが含まれる。このクライアント/サーバ固有通信は次に外部通信リンク35を介してクライアント側インタセプト・モジュール30に送信される。
サーバ側インタセプト・モジュールから通信を受け取ったときのクライアント側インタセプト・モジュール30の機能について、第4図を参照しながら以下に説明する。ブロック160に示すように、クライアント側インタセプト・モジュール30は外部通信リンク35を介して送信されたクライアント/サーバ固有データ・ストリームを受信または入手する。クライアント側インタセプト・モジュールは次に、ブロック165に示すように、サーバ側インタセプト・モジュール40からどのようなタイプの応答を受け取ったかを判断する。サーバ側インタセプト・モジュール40が、クライアントがクライアント・キャッシュ項目がコヒーレントであること、すなわちサーバ・キャッシュ項目とクライアント・キャッシュ項目が同じであることを示している場合、ブロック166に示す操作が行われる。ブロック166に示すように、クライアント側インタセプト・モジュール30は、現在日時とサーバ側インタセプト・モジュール40から受け取ったエージとの差を使用してウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目のSDTを更新する。したがって、本発明は、第1のコンピュータ5と第2のコンピュータ6の2つのクロックの同期をとらずに、第1のコンピュータのキャッシュ項目のコヒーレンシ時間を更新して第2のコンピュータの新しい方のデータを反映させたことになる。ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目のSDTを更新した後、クライアント側インタセプト・モジュール30はクライアント・キャッシュ項目をウェブ・ブラウザ10にHTTPデータ・ストリームとして転送する。この操作をブロック174に示す。
しかし、クライアント側インタセプト・モジュール30が応答のタイプがデータまたはデータ・ストリーム応答であると判断した場合は、ブロック165から「ストリーム」経路をとり、ブロック167の操作が行われる。クライアント側インタセプト・モジュール30はHTTPデータ・ストリームを受け取り、そのデータを一時的に格納する。次に、第4図のブロック170に示すように、クライアント側インタセプト・モジュール30は、ウェブ・ブラウザ発信通信に対応するキャッシュ項目が存在するかどうかを判断する。キャッシュ項目が存在する場合、ブロック170の「Yes」経路をとって、ブロック171に示すように、既存のキャッシュ項目がフラッシュされる。クライアント側インタセプト・モジュールは次に、サーバ側インタセプト・モジュール40から受け取ったHTTPデータ・ストリームのCRCを格納し、現在日時とサーバ側インタセプト・モジュール40から受け取ったエージとの差をSDTとして格納し、HTTPデータ・ストリームを格納することによって、ウェブ・ブラウザ発信通信に対応するクライアント・キャッシュ項目を更新する。この操作をブロック172に示す。
ウェブ・ブラウザ発信通信に対応するキャッシュ項目が存在しない場合、ブロック170の「No」経路が取られる。ブロック173に示す操作を行うことによってクライアント・キャッシュ項目が作成される。ブロック173に示すように、クライアント側インタセプト・モジュール30は、サーバ側インタセプト・モジュール40から受け取ったHTTPデータ・ストリームのURLを格納し、サーバ側インタセプト・モジュール40から受け取ったHTTPデータ・ストリームのCRCを格納し、HTTPデータ・ストリームを格納することによって、クライアント・キャッシュ項目を作成する。また、クライアント側インタセプト・モジュール30は、サーバ側インタセプト・モジュール40から外部通信リンク35を介して受け取ったエージSDTを現在日時から引くことによって、SDTを更新または格納する。
しかし、ブロック166、172、173のいずれの操作によってクライアント・キャッシュ項目が作成されるかを問わず、クライアント側インタセプト・モジュールはクライアント・キャッシュ項目をHTTPデータ・ストリームとしてウェブ・ブラウザ10に転送または供給する。これらの操作は第4図のブロック174に示されている。
当業者ならわかるように、クライアント・キャッシュとサーバ・キャッシュは、メモリによって、またはハード・ディスク、読書きCD−ROM、光ディスク、その他の格納技法などの大容量格納装置によって実装することができる。さらに、当業者ならわかるように、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールは、ソフトウェア、ハードウェア、またはその組合せによって実装することができる。
特定の第1または第2のコンピュータにあるキャッシュについて言及したが、当業者ならわかるように、本発明の利点は、キャッシュが第1のコンピュータにではなく、単に外部通信リンクの第1のコンピュータと同じ側にある場合でも得られる。したがって、ハードウェア・キャッシュをクライアント・キャッシュとして機能する第1のコンピュータの外部に実装し、高速通信によって第1のコンピュータに接続することもでき、しかもその場合でも、キャッシュが外部通信リンクの第1のコンピュータと同じ側にある限り、本発明の利点が得られる。
本発明の他の実施例では、サーバ側インタセプト・モジュール40は、ウェブ・サーバ20から受け取ったHTTPデータ・ストリームのコピーを維持せず、単にその通信のディレクトリ項目を維持するに過ぎない。このディレクトリ項目には、通信のURLと、HTTPデータ・ストリームのために計算されたCRCと、HTTPデータ・ストリームをウェブ・サーバから受け取った時刻と、その通信のSDTとが含まれ、このSDTはCRCを計算した時刻に設定することができる。このような場合、クライアント側インタセプト・モジュール30はサーバ側インタセプト・モジュール40に対して、サーバ側インタセプト・モジュールがCRCとSDTを維持していたURLに対応する通信を求める要求を送り、次にサーバ側インタセプト・モジュール30はクライアント側インタセプト・モジュール30から受け取ったCRCを検査して、それが指定されたURLの最新のHTTPデータ・ストリームに対応しているかどうかを判断する。一致している場合、クライアント側インタセプト・モジュールにコヒーレント応答が送られる。一致していない場合、サーバ側インタセプト・モジュールは、クライアント側インタセプト・モジュールから受け取ったHTTPデータ・ストリームをウェブ・サーバ20に送り、ウェブ・サーバ20から受け取った応答をクライアント側インタセプト・モジュール30に返す。
第7図、第8図、第9図、第10図、第11図および第12図に、本発明の他の態様においてクライアント側インタセプト・モジュール30とサーバ側インタセプト・モジュール40によって行われる操作を示す。この態様は、差分計算を使用して、外部通信リンク35を介して伝送されるデータを削減する。第7図を参照すると、ブロック200にクライアント側インタセプト・モジュール30によるウェブ・ブラウザ10からのHTTP要求の受信が示されている。ブロック205に示すように、クライアント側インタセプト・モジュール30はウェブ・ブラウザ10からのインタセプトしたHTTP要求に問い合わせて、その要求が共通ゲートウェイ・インタフェース(CGI)に送るものかどうかを判断する。要求が共通ゲート・インタフェースに送るものでない場合、クライアント側インタセプト・モジュール30は、第3図ないし第6図に示し、第7図のブロック206に図示するように、その要求をサーバ側インタセプト・モジュールに渡す。
しかし、ウェブ・ブラウザ発信通信がCGI要求に対応する場合、ブロック205の「Yes」経路がとられる。ブロック210に示すように、クライアント/サーバ・インタセプト・モジュール30は、対応するCGI要求に応答して前にウェブ・ブラウザに供給されていたHTTPデータ・ストリームに対応するクライアント・ベース・キャッシュ項目が存在するかどうかを判断する。このCGI要求の問い合わせは、ウェブ・ブラウザ発信通信のURLをクライアント・ベース・キャッシュに格納されているURLと比較することによって行うことができる。
クライアント・ベース・キャッシュは、所与のURLについてウェブ・ブラウザ10に供給するクライアント側インタセプト・モジュール30が受信した最初のHTTPデータ・ストリームを格納することによって初期設定することができる。このベース・キャッシュ項目は、ウェブ・ブラウザ10の多くのインスタンスまたはセッションにわたって維持することができる。クライアント・ベース・キャッシュ項目は、第7図、第8図、第9図、第10図、第11図および第12図に示すように更新することができる。ウェブ・ブラウザ発信通信のURLに対応するクライアント・ベース・キャッシュ項目が存在する場合、第7図のブロック211に示すように、外部通信リンク35を介してサーバ側インタセプト・モジュール40に送るCRCが、クライアント・ベース・キャッシュ項目のCRCに等しく設定される。クライアント・ベース・キャッシュ項目がない場合、第7図のブロック210から「No」経路をとり、外部通信リンク35を介してサーバ側インタセプト・モジュール40に送る要求のCRCがナルにされる。この操作は第7図のブロック212に示されている。
ブロック213に、CGI要求を外部通信リンクを介してサーバ側インタセプト・モジュール40に送る操作を示す。ブロック213に示すように、クライアント側インタセプト・モジュール30がHTTP要求と要求CRCを送る。要求CRCは、CGI要求のURLのクライアント・ベース・キャッシュ項目が存在しない場合にはナルに設定されており、クライアント・ベース・キャッシュ項目が存在する場合にはその項目のCRCに設定されている。したがって、クライアント側インタセプト・モジュールは、CGI要求をクライアント/サーバ固有プロトコルに変換し、そのクライアント/サーバ固有通信を外部通信リンクを介して送信して、サーバ側インタセプト・モジュール40が受信するようにしたことになる。
CGI要求を受け取るときのサーバ側インタセプト・モジュールの動作を第9図に示す。サーバ側インタセプト・モジュール40によるCGI要求の受信がブロック220に示されている。サーバ側インタセプト・モジュール40はCGI要求を受け取ると、CRC値とHTTP要求のコピーを保存する。ブロック221に示すように、サーバ側インタセプト・モジュール40はHTTP要求をウェブ・サーバ20に渡す。
第11図のブロック230に示すように、サーバ側インタセプト・モジュール40がウェブ・ブラウザ発信通信またはCGI要求に対応するHTTP要求に対する応答を受け取るとき、サーバ側インタセプト・モジュール40はこの応答をHTTPデータ・ストリームとして受け取る。ブロック230に示すように、サーバ側インタセプト・モジュール40は、HTTPデータ・ストリームを保存し、ウェブ・サーバ20から受け取ったHTTPデータ・ストリームのCRC値を計算する。また、サーバ側インタセプト・モジュール40は、差分値をナルにして差分データを初期設定する。次に、ブロック235に示すように、サーバ側インタセプト・モジュールは、ウェブ・サーバ発信通信として受け取った応答がCGI要求に対する応答であるかどうかを判断する。答えが否定の場合、第11図のブロック235から「No」経路をとり、ブロック236の操作を実行して、HTTPデータ・ストリームがクライアント側インタセプト・モジュールに送る。ブロック236に示すように、この操作には第3図ないし第6図で説明したキャッシング操作が必要な場合がある。ブロック230で受け取った応答がCGIに対する応答の場合、ブロック235の「Yes」経路をとり、サーバ側インタセプト・モジュールは次に、ブロック240に示すように、CGI応答のサーバ・ベース・キャッシュ項目が存在するかどうかを判断する。
サーバ側インタセプト・モジュール40がCGI要求に対する応答を初めて受け取ったとき、サーバ・ベース・キャッシュ項目を作成することができる。この場合、ブロック240に示す条件の結果によって、ブロック240から「No」経路がとられる。次に、サーバ側インタセプト・モジュール40は、CGIのURLと、CGI要求に対する応答のHTTPデータ・ストリームと、HTTPデータ・ストリームのCRCとを格納することによって、サーバ・ベース・キャッシュ項目を作成する。この操作をブロック241に示す。第3図ないし第6図で説明したコヒーレント・キャッシュとの互換性を持たせるために、サーバ・ベース・キャッシュ項目にはSDTも組み込むことができる。本明細書では、サーバCGIベース書式という用語を使用して、ウェブ・ブラウザ10から受け取ったCGI要求に対応するサーバ・ベース・キャッシュ項目を指す。
CGI要求に対応するサーバ・ベース・キャッシュ項目がある場合、ブロック240の「Yes」経路がとられる。サーバ側インタセプト・モジュールはサーバ・ベース・キャッシュ項目のCRCを、ウェブ・サーバ20から受け取った応答のCRCと比較する。これらの操作を第12図のブロック245に示す。CRCが同じ場合、サーバ側インタセプト・モジュールは、サーバ・ベース・キャッシュ項目のCRCがクライアント・ベース・キャッシュ項目のCRCに対応するかどうかを判断する。この2つのCRC値が同じ場合、クライアント・ベース・キャッシュ項目と、サーバ・ベース・キャッシュ項目と、ウェブ・サーバ20から受け取った応答のすべてがHTTPデータ・ストリームに入れられる。サーバ・ベース・キャッシュ項目とクライアント・ベース・キャッシュ項目との比較をブロック250に示す。
2つのベース・キャッシュ項目が同じ場合、サーバ側インタセプト・モジュールはベース・キャッシュ項目をクライアント側インタセプト・モジュール30に送る必要がなく、したがって、ブロック251に示すように、クライアント側インタセプト・モジュール30に送るHTTPデータ・ストリーム・データをナルにする。次に、ブロック252に示すように、サーバ側インタセプト・モジュール40は、CGI要求に対応するサーバ・ベース・キャッシュに格納されているHTTPデータ・ストリームのCRCと、ナルにしたHTTPデータ・ストリームと、ナルにした差分データとを送信して、CGI要求がクライアント・ベース・キャッシュ項目と同じであったことを示すことによって、ウェブ・サーバ20から受け取ったHTTPデータ・ストリームをクライアント/サーバ固有通信プロトコルに変換する。
ブロック245に戻って、CGI要求に対応するサーバ・ベース・キャッシュ項目のCRCが、ウェブ・ブラウザによって発信されたCGI要求に応答してウェブ・サーバから受け取った応答のCRCと異なる場合、ブロック245から「No」経路がとられる。次に、サーバ側インタセプト・モジュール40はブロック246に示す操作を行う。サーバ側インタセプト・モジュール40は、インタセプトしたCGI応答を、インタセプトしたCGIに対応するサーバ・ベース・キャッシュ項目すなわちサーバCGIベース書式と比較する。このインタセプトしたCGI応答とサーバCGIベース書式との比較によって、インタセプトしたCGI応答とサーバCGIベース書式との差分に対応するCGI差分データが得られる。
差分計算は、ベース書式と修正済み書式との間の差分を求める当業者に周知の任意の方法で行うことができる。本発明で使用するのに適した差分計算の一方法は、コピーターズ(Coppieters)による"Cross-Platform Binary Diff"(Dr. Dobb's Journal 1995年5月号32〜36ページ)に記載されており、その開示は参照により、その全部が記載されているかのように本明細書に組み込まれる。差分データを求める際に使用することができるその他の方法には、"IBM Technical Disclosure Bulletin(Vol.22, No.8A、1980年1月)に記載されている方法が含まれ、これも参照によりその全部が記載されているかのように本明細書に組み込まれる。次に、ブロック247に示すように、サーバ側インタセプト・モジュール40はサーバCGIベース書式が更新を必要とするかどうかを判断する。この判断は、インタセプトされたCGI応答とサーバCGIベース書式との平均差分データが所定のしきい値を超えているかどうかを判断することによって行うことができる。CGI要求に対応するサーバ・ベース・キャッシュ項目を更新する必要があるかどうかを判断する他の方法には、第3図ないし第6図で説明したような時間コヒーレンシ方式や、ベース変更を行って新しいベース・キャッシュ項目を作成すればシステム・パフォーマンスが向上するほど差分データが増加したかどうかを判断する当業者に周知のその他の方法が含まれる。
サーバのベース変更計算が不要な場合、ブロック247から「No」経路がとられ、サーバ側インタセプト・モジュール40はブロック250の操作を行って、クライアント・ベース・キャッシュ項目のCRCがサーバ・ベース・キャッシュ項目のCRCと同じかどうか、またはサーバCGIベース書式が、ウェブ・ブラウザ発信通信のその特定のCGI要求に対応するサーバとクライアントのベース・キャッシュ項目であるクライアントCGIベース書式と同じかどうかを判断する。ベース書式が同じ場合、クライアントはベース変更を行う必要がなく、ブロック251に示すようにHTTPデータ・ストリーム情報がナルにされる。次に、サーバ側インタセプト・モジュール40は、CGI要求に対応するサーバ・ベース・キャッシュ項目のCRC(すなわちサーバCGIベース書式のCRC)を送り、ベース・データに対応するナルにしたHTTPデータ・ストリームを送り、ブロック246で求めた差分データを送ることによって、クライアント側インタセプト・モジュール30に差分応答を送る。これらの操作は第12図のブロック252として示されている。
サーバ側インタセプト・モジュール40が、クライアントCGIベース書式とサーバCGIベース書式のCRSが同じでないと判断した場合、クライアントのベース変更計算を行う必要がある。クライアントのベース変更操作は、クライアント側インタセプト・モジュール30にサーバCGIベース書式を送るステップを含む。この操作を行うために、サーバ側インタセプト・モジュールはクライアント側インタセプト・モジュール30に送るHTTPデータ・ストリーム・データを、サーバCGIベース書式と等しく設定する。この操作をブロック253に示す。次に、サーバ側インタセプト・モジュール40は、ブロック252に示すように、サーバCGIベース書式のCRCと、サーバCGIベース書式に対応するHTTPデータ・ストリーム・データを送信し、CGIベース書式とウェブ・サーバから受け取った応答との差分データを送信することによって、ウェブ・サーバから受け取ったHTTPデータ・ストリームをクライアント/サーバ固有プロトコルに変換する。次にこの情報を外部通信リンク35を介してクライアント側インタセプト・モジュール30に送る。
ブロック247に戻って、サーバのベース変更が必要な場合、ブロック247から「Yes」経路がとられる。ブロック248に示すように、サーバ側インタセプト・モジュールは、ウェブ・サーバから受け取ったHTTPデータ・ストリームを使用してブラウザ発信通信に対応するサーバ・ベース・キャッシュを更新する。応答のCRCも更新され、CGI差分データがナルにされる。次に、サーバ側インタセプト・モジュールは、ブロック250に示すように新しいサーバ側キャッシュ項目のCRCを比較し、前述のようにこの転送を完了する。
サーバ側インタセプト・モジュール40から応答を受け取ったときのクライアント側インタセプト・モジュールの操作を第8図に示す。クライアント側インタセプト・モジュール30によるサーバ側インタセプト・モジュール40からの応答の受信は、ブロック260に示されている。ブロック265に示すように、クライアント側インタセプト・モジュール30は、応答がCGI要求に対する応答かどうかを判断する。応答がCGI要求に対する応答ではない場合、クライアント側インタセプト・モジュールはブロック267の操作を行う。この操作には、第3図ないし第6図に示すキャッシュ操作を組み込むことができる。しかし、応答がCGI要求に対する応答の場合、ブロック265から「Yes」経路がとられる。クライアント側インタセプト・モジュール30は、外部通信リンクを介して送信されたクライアント/サーバ固有データ・ストリームから入手した、HTTPデータ・ストリーム・データと、差分データと、CRCとを保管する。これらの操作は第8図のブロック266に示されている。
次に、クライアント側インタセプト・モジュール30は、CGIベース書式を含むインタセプトされたCGI要求に対応するクライアント・ベース・キャッシュ項目が存在するかどうかを判断する。この問い合わせはブロック270に示されており、HTTP要求またはHTTP応答のURLを調べることによって行うことができる。クライアントCGIベース書式が存在する場合、ブロック270から「Yes」経路がとられる。次に、ブロック275に示すように、クライアント側インタセプト・モジュール30は外部通信リンクを介して受け取ったCRCを、クライアントCGIベース書式のCRCと比較する。CRCが異なる場合、ブロック275から「No」経路がとられ、クライアントは、ウェブ・ブラウザ発信通信のCGI要求のURLに対応するクライアント・ベース・キャッシュ項目を、外部通信リンク35を介してサーバ側インタセプト・モジュール40から受け取ったHTTPデータ・ストリーム・データに置き換えてCGIベース書式を更新することによって、ベース変更を行う。クライアント・ベース・キャッシュ項目も、HTTPデータ・ストリームのCRCを基準にして更新される。これらの操作は第8図のブロック276に示されている。
外部通信リンク35を介して受け取ったCRCがGGIベース書式と同じ場合、サーバ側インタセプタ・モジュール・サーバCGIベース書式は、クライアント側インタセプト・モジュール・クライアントCGIベース書式と同じであり、ブロック275の「Yes」経路がとられる。
ベース書式が同じであるかクライアントをベース変更するかを問わず、クライアント側インタセプタ・モジュール30によってブロック277に示す操作が行われる。ブロック277は、クライアント側インタセプタ・モジュール30が、クライアントCGIベース書式を外部通信リンク35を介して受け取ったCGI差分データと比較して、インタセプトしたCGI応答に対応するHTTPデータ・ストリームを作成することによって、外部通信リンク35を介して受け取ったクライアント/サーバ固有データ・ストリームから、ウェブ・サーバ20から受け取った通信に対応するHTTPデータ・ストリームを再構築する操作を示す。ブロック278に示すように、この応答は次にHTTPデータ・ストリームとしてウェブ・ブラウザ10に供給される。
クライアントにCGI要求のURLに対応するCGIベース書式が存在しない場合、第8図のブロック270から「No」経路がとられる。ブロック271に示すように、クライアント側インタセプト・モジュール30は、URLと、サーバ側インタセプト・モジュール40から外部通信リンクを介して受信したHTTPデータ・ストリームのCRCと、実HTTPデータ・ストリーム・データとを格納することによってCGI要求のURLに対応するクライアント・ベース・キャッシュ項目を作成する。この情報を格納することによって、インタセプトされたCGI要求に対応するクライアント・ベース・キャッシュ項目が作成され、したがってクライアントCGIベース書式が作成される。次に、クライアント側インタセプト・モジュールは、クライアントCGIベース書式をCGI差分データ(ナル化されていることがある)と結合またはマージすることによって、HTTPデータ・ストリームを再構築することでブロック277の操作を行う。
本発明の差分計算技法は非CGIデータにも適用可能である。その場合、サーバ側インタセプト・モジュール40は、ウェブ・サーバに接続されているウェブ・ブラウザのクライアント側インタセプト・モジュールが異なるベース書式を持っている可能性を見込んで、複数の世代のサーバ・ベース・キャッシュ項目を維持する必要がある。その場合、サーバ側インタセプト・モジュールは、一致するものが得られるまで、クライアント側インタセプト・モジュールから受け取ったCRCを各世代のサーバ・ベース書式のCRCと比較する。その際、サーバ側インタセプト・モジュール40は、任意選択でクライアント側インタセプト・モジュール30のベース変更を行うか、または単にクライアント側インタセプト・モジュール30に差分データを供給することができる。したがって、本明細書でCGI要求に関して説明した差分計算方法は、どのようなHTTP要求および応答にも等しく適用可能である。
複数の世代のベース書式を維持する上述のシステムでは、非CGI要求について差分計算を使用することができるが、この方法はメモリまたは格納域を多用し、前述のキャッシング機能が十分に活用されない。メモリまたは格納域必要量を少なくし、前述のキャッシング方法を活用するために、非CGI要求に差分計算を使用する以下の好ましい方法を使用することできる。この好ましい実施態様では、サーバ側インタセプト・モジュールは、要求に対応するサーバ・ベース書式とウェブ・サーバからの応答のHTTPデータ・ストリームとの差分を計算する。次に、ベース書式をウェブ・サーバからの新しい応答で置き換えることによって、サーバ・ベース書式を更新する。これにはベース書式のCRCの更新も含まれる。しかし、古いCRCを廃棄するのではなく、前のベース書式のCRCは差分データとして格納する。次に、前の世代の差分データとCRCを、非CGI要求に対応するクライアント・ベースのCRCに基づいて選択的にクライアント側インタセプト・モジュールに送る。
非CGI差分計算方法の一例として、サーバ側インタセプト・モジュールが非CGI要求を受け取った場合、その要求には非CGI要求のURLに対応するクライアント側インタセプト・モジュールにあるベース書式のCRCも付随していることになる。サーバ側インタセプト・モジュールは、ウェブ・サーバから応答を受け取ると、その応答のCRCを計算する。次に、サーバ側インタセプト・モジュールは応答とURLのサーバ・ベース書式との差分を計算し、その差分データを保管する。サーバ側インタセプト・モジュールは、応答データを使用してサーバ・ベース書式を更新し、前のベース書式のCRCと、応答と古いベース書式との間の差分データとをアーカイブする。次に、サーバ側インタセプト・モジュールは、クライアント・ベース書式のCRCをサーバ・ベース書式のCRCおよび格納またはアーカイブされているCRCと比較し、一致しているものがあるかどうかを判断する。一致が見つからない場合、その応答は単にクライアント側インタセプト・モジュールに送られる。
一致が見つかった場合、一致するCRCに対応する差分データと、それ以降の、現行差分データを含む現行差分データまでの差分データがクライアント側インタセプト・モジュールに送られる。クライアント側インタセプト・モジュールは、その差分データをクライアント・ベース書式に適用して応答を再構築する。したがって、3世代古いベース書式のCRCについてCRC一致があった場合、3セットの差分データがクライアント側インタセプト・モジュールに送られることになり、3セットの連続した差分データをクライアント・ベース書式に適用することによって、応答の構築が行われることになる。しかし、応答を再構築するのに必要な差分データ・セットの数が多すぎるかまたは差分データ・セットの大きさが大き過ぎて、実応答を送信した方がデータ転送が少なくて済む場合、サーバ側インタセプト・モジュールは応答自体を送信することができる。いずれにしても、応答の再構築または受信の後、クライアント側インタセプト・モジュールは、要求のURLのクライアント・ベース書式を応答データによって更新し、CRCを要求のCRCで更新する。クライアント・ベース書式は特定のURLについて応答を受信するたびに更新されるため、非CGI要求に対して差分計算を使用した場合、上述のクライアント・キャッシュをクライアント・ベース書式のキャッシュとして使用することができ、それによってクライアント・ベース書式の別個のキャッシュを不要にすることができる。
本発明の他の態様では、HTTPなどのステートレス通信プロトコルの冗長性に基づいて、通信をさらに節約することができる。そのようなプロトコルでは、クライアントは通信を開始するたびにクライアント自体に関する情報をサーバに送信する。同様に、サーバは応答を出すたびにサーバ自体に関する特定の情報をクライアントに伝達する。
本発明の一実施例では、第1のコンピュータ5は第2のコンピュータ6に、第1のコンピュータの事前定義特性に対応するコンピュータ固有情報を伝達する。第2のコンピュータはこのコンピュータ固有情報を格納する。次に、第1のコンピュータはそれ以降のウェブ・ブラウザ発信通信からそのコンピュータ固有情報を除去してから外部通信リンク35で送信する。第2のコンピュータ6は、外部通信リンク35を介して受信したそれ以降の通信と格納しているコンピュータ固有情報とを組み合わせてHTTPデータ・ストリームを作成することによって、元のウェブ・ブラウザ発信通信を再構築する。
ウェブ・ブラウザによって発信される通信からコンピュータ固有情報を除去するほかに、このコンピュータ固有情報をウェブ・サーバによって発信される通信からも除去することができる。その場合、第2図の第2のコンピュータ6は第1のコンピュータ5に外部通信リンク35を介して、第2のコンピュータ6の事前定義特性に対応するコンピュータ固有情報を供給する。第1のコンピュータ5はそのコンピュータ固有情報を格納して、サーバ・ヘッダ情報を備える。その後の通信の時には、第2のコンピュータ6はウェブ・サーバ発信通信からコンピュータ固有情報を除去し、ウェブ・サーバ発信通信の残りの部分を外部通信リンク35で送信する。第1のコンピュータ5は外部通信リンクでその通信を受信し、サーバ・ヘッダ情報を外部通信リンクを介して受信したクライアント/サーバ固有データ・ストリームと結合してHTTPデータ・ストリームを作成することによって、元のウェブ・サーバ発信通信を再構築する。どちらの場合も、操作が第1のコンピュータ5と第2のコンピュータ6のどちらで行われるかに応じて、コンピュータ固有情報を取り除き、その情報を格納してサーバ・ヘッダ情報またはクライアント・ヘッダ情報を作成する操作がクライアント側インタセプト・モジュール30またはサーバ側インタセプト・モジュール40によって行われる。
本発明の一実施例では、ウェブ・ブラウザ10は伝送制御プロトコル/インターネット・プロトコル(TCP/IP)を使用してクライアント側インタセプト・モジュール30と通信する。TCPは、外部通信リンク35を介したクライアント側インタセプト・モジュール30とサーバ側インタセプト・モジュール40との間の通信にも使用することができる。最後に、TCPはサーバ側インタセプト・モジュール40とウェブ・サーバ20との間の通信にも使用することができる。TCPは本発明のシステムを構成する様々な構成要素間の通信に使用することができるが、HTTPプロトコルは外部通信リンクを介した通信にとって最も効率的な手段を提供するものではない。外部通信リンク35のパフォーマンスを向上させるために、本発明の一実施例は本明細書で「仮想ソケット」と呼ぶものを作成する。これは、ウェブ・ブラウザとクライアント側インタセプト・モジュール30の間の接続と、サーバ側インタセプト・モジュール40とウェブ・サーバ20との間の接続に使用される。これらの仮想ソケットの動作について、第13図ないし第25図を参照しながら以下に説明する。
第13図は、仮想ソケットを使用する本発明の1つの可能な実施態様を示すブロック図である。第13図に示すように、第1のコンピュータ5と第2のコンピュータ6は外部通信リンク35を介して接続されている。ウェブ・ブラウザ10は、ウェブ・ブラウザ10をクライアント側インタセプト・モジュール30と接続する複数の実ソケットを有する。第13図に示すように、第1の実ソケットはウェブ・ブラウザ10上に65aとして図示され、それに対応するソケットはクライアント側インタセプト・モジュール30上の65bである。この第1の実ソケットは、それを介してウェブ・ブラウザ10がクライアント側インタセプト・モジュール30に対してさらに接続を要求するTCPソケットである。
ウェブ・ブラウザ10が新しいTCP接続を要求すると、実ソケット65aを介して通信が行われ、それが実ソケット65bによって受信される。次にクライアント側インタセプト・モジュール30は、ウェブ・ブラウザ10との通信のために別の実ソケットを作成する。第13図に示すように、ウェブ・ブラウザ10上で複数の実ソケットが作成され、それに対応する実ソケットがクライアント側インタセプト・モジュール30上で作成される。これらの実ソケットは、ウェブ・ブラウザ10上の60a〜64aおよびクライアント側インタセプト・モジュール30上の60b〜64bとして図示されている。これらの実ソケットは、ウェブ・ブラウザ10がそれを介してクライアント側インタセプト・モジュール30と通信するための手段である。実ソケット60a〜64aおよび60b〜64bを作成した後、これらのソケットを介した通信を多重化して実ソケット36aに送り、実ソケット36aはクライアント側インタセプト・モジュール30に外部通信リンク35へのアクセスを提供する。実ソケット36aおよび36bはコンピュータ5の実ソケット37aを介してコンピュータ6の実ソケット37bに要求を送るときに作成される。実ソケット37bが接続要求を受け取ると、実ソケット36aおよび36bが作成される。ソケット37aおよび37bは、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとの間の通信のための最初の実ソケットとして機能し、ソケット36aおよび36bによって示されているこの2つのモジュールの間の接続を確立するためにのみ使用することができる。これらの実ソケットのそれぞれは標準TCP/IPプロトコルの下で動作する。第2のコンピュータ6が外部通信リンク35を介して通信を受信するとき、それらの通信は実ソケット36bで受信される。次にサーバ側インタセプト・モジュール40は、ソケット36bで受信した通信を多重化解除し、それらをウェブ・サーバ20に送信するために適切なソケットに供給する。したがって、たとえば、特定のURLに対して情報を要求するためのソケット60aからソケット60bまでの通信は、ソケット36a上に多重化され、ソケット36bによって受信され、サーバ側インタセプト・モジュール40によって多重化解除され、ソケット60cからウェブ・サーバ20上のソケット60dに送られることになる。同様に、ソケット61aを介して行われる通信はソケット61bによって受信され、クライアント側インタセプト・モジュール30によって多重化され、ソケット36aからソケット36bに送られ、そこでサーバ側インタセプト・モジュール40がその通信を多重化解除してソケット61cからソケット61dに送る。したがって、ソケット60aと60b、61aと61b、62aと62b、63aと63b、64aと64bを介した通信は、サーバ側インタセプト・モジュール40とウェブ・サーバ20との間のソケット60cと60d、61cと61d、62cと62d、63cと63d、および64cと64dのうちのそれぞれの対応するソケットを介して送信される。
同様に、ウェブ・サーバ20によるウェブ・ブラウザ10からの要求に対する応答も、ウェブ・サーバ20をサーバ側インタセプト・モジュール40に接続するソケットを介して送られ、外部通信リンク35を介してクライアント側インタセプト・モジュール30に送られた後、ウェブ・ブラウザ10に送られる。したがって、たとえばウェブ・サーバ20によって発信された応答はソケット60dから60cを介して送られ、サーバ側インタセプト・モジュール40によってソケット36bに多重化され、そこから外部通信リンク35を介してソケット36aに送られる。次にクライアント側インタセプト・モジュール30がその通信を多重化解除し、それをソケット60bに送り、それがウェブ・ブラウザ10上のソケット60aに送られる。ウェブ・ブラウザ10またはウェブ・サーバ20が使用する各ソケットについて同様の通信経路が確立される。当業者ならわかるように、本発明についてウェブ・ブラウザ10とウェブ・サーバ20との間の4ソケット通信に関して説明したが、ウェブ・ブラウザ10とウェブ・サーバ20との間の通信アクセスを実現するために任意の数のソケットを開くことができる。
第14図は、クライアント側インタセプト・モジュール30とサーバ側インタセプト・モジュール40における仮想ソケット・システムの実施例を示すブロック図である。これらのモジュールの外部で、クライアント側インタセプト・モジュール30とウェブ・ブラウザ10およびサーバ側インタセプト・モジュール40とウェブ・サーバ20の間の実ソケットが、通常のTCP/IPソケットとして機能する。したがって、仮想ソケットの使用はウェブ・ブラウザ10およびウェブ・サーバ20には透過である。
第14図のブロック図と第15図ないし第25図の流れ図を参照しながら本発明の特定の実施例について説明する。第15図ないし第17図は、第14図にブロック68として図示されているソケット・マネージャのフローチャートである。第16図を参照すると、ブロック300はクライアント側インタセプト・モジュール30の実ソケット・マネージャ68の作成を示している。実ソケット・マネージャ68が作成された後、実ソケット・マネージャは第14図にソケット65bとして図示されている第1の実ソケットを作成する。この第1の実ソケットの作成は第16図のブロック301として示されている。第1の実ソケット65bを作成した後、クライアント側インタセプト・モジュール30内にあるソケット・マネージャ68(本明細書ではクライアント・ソケット・マネージャとも呼ぶ)は、第16図のブロック302に示すように、第1の実ソケット65b上での事象を待つ。第1の実ソケット65b上で事象を受け取ると、第16図のブロック305に示すように実ソケット・マネージャ68はその事象を検査し、その検査に基づいて5通りの経路のうちの1つをとる。
第1の実ソケット65bで受信した通信要求に応答して実ソケットが作成された場合は、第16図のブロック305から306までの経路に示すように、実ソケット・マネージャ68はその実ソケットを実事象リストに追加する。次に、実ソケット・マネージャはブロック307に示すようにシンプレックス仮想ソケットを作成する。クライアント側インタセプト・モジュールの場合、実ソケット・マネージャは、第16図のブロック308に示すように、作成された仮想ソケットについてクライアント側インタセプト・モジュールの機能を実行するアプリケーション機能を開始する。
本明細書では、「シンプレックス・ソケット」または「シンプレックス仮想ソケット」という用語は、単一のソケットまたは単一のアプリケーションに直接接続するソケットを指す。本明細書では、「マルチプレックスソケット」とは他の複数のソケットに接続するソケットを指す。したがって、マルチプレックスソケットは、多重化または多重化解除機能を実行し、シンプレックス・ソケットは1対1接続を行う。したがって、たとえば、第16図のブロック306から308までの機能を実行する際、クライアント・ソケット・マネージャ68は第1の実ソケット65bが受信した第1の接続要求に応答して、実ソケット60b、シンプレックス仮想ソケット70を作成し、アプリケーション80のクライアント側インタセプト機能を開始することになる。実ソケットが作成されたその後の事象の場合も同様に、実ソケット・マネージャは実ソケット61b、62b、63b、または64bとシンプレックス仮想ソケット71、72、73、または74を作成し、第14図でブロック81、82、83、または84として図示されている、作成された実ソケットおよび仮想ソケットに対応するCSI機能を開始する。
以下に、クライアント側インタセプト機能の操作について、第14図に示す実ソケット60bとシンプレックス仮想ソケット70とクライアント側インタセプト機能80とを参照しながら説明する。第18図のブロック325はクライアント側インタセプト機能80の作成を示している。作成されると、クライアント側インタセプト機能80はブロック326に示すようにシンプレックス仮想ソケット70上の事象を待つ。この待機操作は、第23図に示す仮想選択機能を実行することによって行われる。事象を受け取ると、ブロック330に示すようにその事象が検査される。事象が仮想ソケット閉鎖である場合、第18図のブロック349に示すようにクライアント側インタセプト機能80はシンプレックス仮想ソケット70を削除し、ブロック350に示すように終了する。
事象がデータの受信である場合、ブロック330からブロック331への経路がとられ、クライアント側インタセプト機能80は第22図を参照しながら説明する仮想受信操作を実行することによって、シンプレックス仮想ソケット70からブラウザ発信通信を受け取る。次に、クライアント側インタセプト機能は前述のクライアント側インタセプト・モジュールの機能(たとえば第3図および第7図を参照)を実行する。これはブロック332に示されている。次にクライアント側インタセプト機能80は、クライアント側インタセプト・モジュール30内の実ソケット36aに接続されるマルチプレックス仮想ソケット90を作成する。実ソケット36aはサーバ側インタセプト・モジュール40上の実ソケット36bに接続される。マルチプレックス仮想ソケットの作成は、第18図のブロック333に示されており、本明細書で第20図を参照しながら説明する仮想作成操作を実行することによって行われる。ブロック334は、ウェブ・ブラウザ発信通信のためにクライアント側インタセプト機能80が実行された後で、実ソケット60bとシンプレックス仮想ソケット70を介してウェブ・ブラウザから受け取った情報を送信する操作を示す。この通信は、第21図を参照しながら説明する仮想送信操作を実行することによってマルチプレックス仮想ソケット90の待ち行列に入れられる。クライアント側インタセプト機能80は、要求をマルチプレックス仮想ソケット90の待ち行列に入れた後、第18図のブロック335に示すようにマルチプレックス仮想ソケット90の待ち行列に入れられているデータをフラッシュし、次にブロック336に示すようにマルチプレックス仮想ソケット上の事象を待つ。仮想フラッシュ機能は、第24図を参照しながら説明する仮想フラッシュ操作を実行することによって行われ、マルチプレックス仮想ソケット待ち行列からデータを取り出してそのデータを実ソケット36aに供給する。待機機能は、第23図に示す仮想選択機能を実行することによって行うことができる。この時点で、クライアント側インタセプト・モジュールはウェブ・ブラウザ発信通信をインタセプトし、その通信を外部通信リンク35を介してサーバ側インタセプト・モジュールに送信し終わったことになる。
第16図に戻ると、サーバ側インタセプト・モジュール40またはクライアント側インタセプト・モジュール30におけるソケット・マネージャのフローチャートが示されている。第14図のブロック69に示すように、サーバ側インタセプト・モジュール内の実ソケット・マネージャ、すなわちサーバ・ソケット・マネージャは、ブロック68に示すクライアント・ソケット・マネージャと同じ機能を実行する。ブロック301に示すように、第1の実ソケットを作成する際、サーバ側インタセプト・モジュール30は、サーバ側インタセプト・モジュール40に関連づけられたクライアント側インタセプト・モジュール30からのソケットの要求を受け取る「周知のポート」37bを作成する。サーバ側インタセプト・モジュール40の実ソケット36b上で実事象が発生すると、ブロック305に示すようにその事象が検査される。この場合、この事象は実ソケット36aからのデータの受信であり、したがって第16図のブロック305からブロック320までの経路がとられる。実ソケット36b上で受信したデータが検査され、この例ではデータはクライアント側インタセプト・モジュールによって送信されたウェブ・ブラウザ発信通信であるため、サーバ側インタセプト・モジュール40において新しい仮想ソケットを作成しなければならない。したがって、第16図のブロック320からブロック321への経路がとられる。次にサーバ・ソケット・マネージャ69は、第17図のブロック321、ブロック322、ブロック323、およびブロック324に示す操作を行う。サーバ・ソケット・マネージャ69はブロック321に示すようにマルチプレックス仮想ソケット95を作成し、ブロック322に示すようにマルチプレックスソケット活動タイマをキャンセルし、第17図のブロック323と第14図のブロック85に示すサーバ側インタセプト機能のアプリケーションを開始する。実ソケット36bで受け取ったデータは次にマルチプレックス仮想ソケット95の待ち行列に入れられ、仮想事象が通知される。
ブロック323に示すサーバ側インタセプト機能の作成は、第19図のブロック360に示されている。サーバ側インタセプト機能85の作成後、この機能は、クライアント側インタセプト・モジュール30から送信され、ウェブ・ブラウザ発信通信に対応するデータを、マルチプレックス仮想ソケット95から受け取る。この操作は第19図のブロック361に示されている。クライアント側インタセプト・モジュールからデータを受け取った後、サーバ側インタセプト機能85は、そのデータを、サーバ側インタセプト・モジュールについて前述したように処理する。このサーバ側機能の実行はブロック362に示されている(たとえば第5図および第9図を参照)。情報を処理した後、サーバ側インタセプト機能85は仮想作成を行うことによってシンプレックス仮想ソケット75を作成する。この操作については本明細書で第20図を参照しながら説明する。この操作は第19図のブロック363に示されている。次に、サーバ側インタセプト機能85は、仮想送信を行うことによって、ブロック364に示すようにウェブ・ブラウザ発信通信をシンプレックス仮想ソケット75に送る。仮想送信の操作については本明細書で第21図を参照しながら説明する。次に、サーバ側インタセプト機能85は、仮想フラッシュを行ってシンプレックス仮想ソケット75の待ち行列に入っているデータをソケット60cにフラッシュし、シンプレックス仮想ソケット75上の事象を待つ。仮想フラッシュ操作については本明細書で第24図を参照しながら説明する。この送信操作とフラッシュ操作は第19図のブロック364および365に示されている。待機操作は、第23図で説明されている仮想選択機能を実行することによって行うことができる。サーバ側インタセプト機能85がシンプレックス仮想ソケット75を作成したとき、対応する実ソケット60cも作成されている。サーバ側インタセプト機能85は、ウェブ・ブラウザ発信通信をシンプレックス仮想ソケット75に送信することによって、ウェブ・ブラウザ発信通信をウェブ・サーバに転送した。
サーバ側インタセプト・モジュール40が実ソケット60c上でウェブ・サーバからの応答を受信すると、実事象が発生し、サーバ・ソケット・マネージャ69は第16図のブロック302を終了して、ブロック305に示すように実ソケット60c上で発生した事象を検査する。この事例の場合、これは既存の仮想ソケットのデータであり、第16図ないし第17図のブロック320からブロック324までの経路がとられる。実ソケット60c上で受信したデータは仮想ソケット75の待ち行列に入れられ、仮想事象が通知される。仮想事象が通知されると、サーバ側インタセプト機能85は第19図のブロック366を終了し、ブロック370に示すようにその事象を検査する。事象がソケット閉鎖である場合、エラー条件が発生し、第19図のブロック375に示すように応答としてエラー・メッセージが作成される。しかし、事象がデータの受信の場合は、ブロック370からブロック371への経路をとり、サーバ側インタセプト機能85は、第22図を参照しながら説明するように仮想受信を実行して、ブロック371に示すようにシンプレックス仮想ソケット75から応答を入手する。次にサーバ側インタセプト機能85は、ブロック372に示し、第25図を参照しながら説明するように、シンプレックス仮想ソケット75の仮想閉鎖を実行し、サーバ側インタセプト・モジュールに関して前述し、ブロック373に示すように、その応答を処理する(たとえば第6図および第10図ないし第12図を参照)。
第19図のブロック370の終了経路がブロック375へのエラー経路であるかブロック371へのデータ経路であるかを問わず、ブロック374でシンプレックス仮想ソケット75が削除される。次にサーバ側インタセプト機能は、ブロック376に示すようにマルチプレックス仮想ソケット95への仮想送信操作を行ってウェブ・サーバ発信通信をクライアント側インタセプト・モジュール30に送信する。サーバ側インタセプト機能85は次に、仮想フラッシュ操作を行って、マルチプレックス仮想ソケット95の待ち行列に入っているデータをフラッシュする。これらの操作はブロック377に示されている。次にサーバ側インタセプト機能85は、第19図のブロック378に示すように仮想閉鎖操作を行ってマルチプレックス仮想ソケット95を閉じる。最後に、サーバ側インタセプト機能85は、ブロック379および380に示すようにマルチプレックス仮想ソケットを削除して終了する。
サーバ側インタセプト機能は、マルチプレックス仮想ソケット95への仮想送信操作とフラッシュ操作を行う。これらの操作によって、実ソケット36a上で事象がトリガされ、クライアント・ソケット・マネージャ68はブロック302を終了し、ブロック305に示すように事象を検査する。これは実ソケット36aでデータを受信し、第16図のブロック305からブロック320までの経路がとられ、データがマルチプレックス仮想ソケット90の待ち行列に入れられるためである。したがって、実ソケット36aが外部通信リンク35を介して実ソケット36bからウェブ・サーバ応答を受け取ると、その情報が多重化解除され、マルチプレックス仮想ソケットに供給される。データの受信によって、第17図のブロック324に示すように仮想事象が発生し、第18図のブロック336が終了してクライアント側インタセプト機能80は第18図のブロック340に示すようにその事象を検査することになる。
事象がソケット閉鎖応答である場合、第18図のブロック340からブロック345への経路をとり、クライアント側インタセプト機能80はエラー・メッセージ応答を作成して第18図のブロック344に進む。この例の場合のように事象がデータ受信の場合、第18図のブロック340からブロック341の経路をとり、クライアント側インタセプト機能80は仮想受信操作を行ってマルチプレックス仮想ソケット90から応答を受信する。この受信操作は第18図のブロック341に示されている。マルチプレックス仮想ソケット90からデータを受信した後、クライアント側インタセプト機能80はブロック342に示すように仮想閉鎖操作を行ってマルチプレックス仮想ソケット90を閉じる。次にクライアント側インタセプト機能80は、ブロック343に示すように、クライアント側インタセプト・モジュールに関して前述したように応答を処理する(たとえば第4図および第8図を参照)。
ブロック340を終了してどちらの経路をとる場合も、ブロック344の操作が行われる。クライアント側インタセプト機能80は、ブロック344に示すようにマルチプレックス仮想ソケットを削除し、次にブロック346に示すように仮想送信操作を行ってシンプレックス仮想ソケット70を介してブラウザに応答を送信する。この仮想送信操作が完了すると、クライアント側インタセプト機能80はブロック347に示すように仮想フラッシュ操作を行ってシンプレックス仮想ソケットの待ち行列に入っているデータを実ソケット60bにフラッシュし、次にブロック348に示すように仮想閉鎖操作を行ってシンプレックス仮想ソケットを閉じる。クライアント側インタセプト機能のシンプレックス仮想ソケットを閉じた後、第18図のブロック349および350に示すようにシンプレックス仮想ソケットが削除され、クライアント側インタセプト機能は終了する。
当業者ならわかるように、本発明についてシンプレックス仮想ソケットおよびマルチプレックス仮想ソケットとクライアント側インタセプト機能およびサーバ側インタセプト機能の1つの特定のインスタンスに関して説明したが、単一のクライアント側インタセプト・モジュールまたはサーバ側インタセプト・モジュール内でこれらの機能を複数作成することができる。したがって、本発明によるクライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールは、クライアント側インタセプト・モジュール30とサーバ側インタセプト・モジュール40との間にTCP/IP接続を作成し、次に、そのTCP/IP接続を維持しながらそのTCP/IP接続上で複数のウェブ・ブラウザ発信通信またはウェブ・サーバ発信通信を多重化することができる。
クライアント・ソケット・マネージャとサーバ・ソケット・マネージャの残りの機能は、第20図ないし第23図と第24図および第25図を参照すれば最もよく理解できよう。これらの図では、第18図および第19図のフローチャートに示されているように仮想作成、仮想送信、仮想受信、仮想選択、仮想フラッシュ、または仮想閉鎖操作を実行するときに、クライアント側インタセプト・モジュールおよびサーバ側インタセプト・モジュールによって行われる操作が説明されている。第18図のブロック333および第19図のブロック363に示すような仮想作成操作を行う場合、第20図のブロック400から始まる操作を行う。ブロック405に示すように、ソケット・マネージャは、実ソケットが必要かどうかを判断する。作成操作によって既存の実ソケットに接続するマルチプレックス仮想ソケットを作成する場合などのように、実ソケットがすでに存在する場合は、ブロック405から「No」経路をとり、ブロック409に示すようにその仮想ソケットが実ソケットに接続される。しかし、実ソケットが必要な場合は、ブロック405から「Yes」経路をとる。ブロック406に示すように実ソケットを作成する。次に、第16図のブロック302に示す監視のために、ブロック408に示すようにその実ソケットを事象リストに追加する。実ソケットを作成し、接続を確立した後、ブロック409に示すように仮想ソケットを実ソケットに接続し、ブロック410に示すように作成操作が完了する。
第18図のブロック334および346または第19図のブロック364および376に示す仮想送信操作を行う場合、第21図のブロック420から始まる操作が行われる。ブロック427に示すようにデータが仮想ソケット待ち行列に加えられ、完了すると、送信操作はブロック428に示すように終了する。
第18図のブロック331および341と第19図のブロック361および371に示す仮想受信操作は、第22図のブロック430から始まる操作を行うことによって行われる。ブロック435に示すように、仮想ソケット待ち行列を調べて仮想ソケット待ち行列に何かデータが入っているか判断する。仮想ソケット待ち行列にデータがある場合、ブロック435の「Yes」経路をとり、ブロック436に示すように受信操作を呼び出した機能にそのデータが返される。仮想ソケット待ち行列にデータがなく、ソケットに閉鎖のマークが付けられていない場合、決定ブロック440の「No」経路をとり、ブロック441に示すように何も返されない。しかし、待ち行列にデータがなく、ソケットに閉鎖のマークが付けられている場合、ブロック440の「Yes」経路をとり、ブロック442に示すようにソケットに閉鎖のマークが付けられて、ブロック443に示すように、受信を要求する操作にソケット閉鎖応答が返される。
第18図のブロック326および336と第19図のブロック366で行われる仮想選択操作は、第23図のブロック445から始まる操作を実行することによって行われる。ブロック446に示すように、まず、選択された仮想ソケットについてデータまたは仮想閉鎖操作が保留状態になっていないかどうかを判断する。保留状態のデータまたは仮想閉鎖がない場合、ブロック446の「No」経路をとり、プロセスはブロック447に示すように選択された仮想ソケット上の仮想ソケットを待ち、そのような事象を受け取った後でブロック448に示すように終了する。選択された仮想ソケットについてデータまたは仮想閉鎖が保留状態になっている場合、仮想事象がすでに発生しており、ブロック446の「Yes」経路をとって、ブロック448に示すようにプロセスが終了する。
第18図のブロック335および347と第19図のブロック365および377で言及した仮想フラッシュ操作は、第24図のブロック450から始まる操作を実行することによって行われる。仮想フラッシュ操作が呼び出されると、決定ブロック455に示すように、フラッシュする仮想ソケット待ち行列にデータが入っているかどうかを調べる。仮想ソケット待ち行列にデータが入っていない場合、ブロック455の「No」経路が示すようにフラッシュ操作は単に終了して呼出し側機能に戻る。しかし、待ち行列にデータが入っている場合、ブロック455の「Yes」経路をとり、ブロック460に示すようにその仮想ソケット待ち行列がマルチプレックスソケットのものであるかどうかを判断する。マルチプレックスソケットである場合は、ブロック461に示すようにソケットの固有識別子と転送中のデータ量を示す3バイトから成るソケット・ヘッダが実ソケット・バッファに加えられる。マルチプレックスソケットであるかシンプレックス・ソケットであるかを問わず、いずれの場合もブロック462に示すように実ソケットのためのデータが実ソケット・バッファに移される。実ソケット・バッファがいっぱいの場合、ブロック465の「Yes」経路をとり、ブロック466に示すように実ソケット・バッファからデータが実ソケットに送られる。実バッファがいっぱいになっていない場合は、ブロック465の「No」経路をとる。次に、仮想フラッシュ機能は、他のいずれかのマルチプレックス仮想ソケット待ち行列に実ソケットに送るべき他のデータがあるかどうかを判断する。答えが肯定の場合、ブロック470の「Yes」経路をとり、実ソケット・バッファ内のデータは、他の仮想ソケット待ち行列の1つをフラッシュするために仮想フラッシュ操作が再び呼び出されるまで送られない。他のデータがない場合、または他のマルチプレックス仮想ソケットからデータを付加した後は、ブロック466の操作を行い、実ソケットバッファ内のデータを実ソケットに送る。仮想フラッシュ操作を呼び出した機能に対応する仮想ソケット待ち行列内のすべてのデータが実ソケットに送られた後、ブロック467に示すように仮想フラッシュ操作は終了する。
第18図のブロック342および348と第19図のブロック372および378に示す仮想閉鎖操作は、第25図のブロック480から始まる操作を実行することによって行われる。仮想閉鎖操作が呼び出されると、まずブロック485に示すようにその仮想閉鎖がマルチプレックス仮想ソケットの閉鎖であるかどうかを判断する。マルチプレックス仮想ソケットである場合、ブロック485の「Yes」経路をとり、仮想ソケット待ち行列に「閉鎖」操作標識が付加される。仮想閉鎖がマルチプレックス仮想ソケットの閉鎖であるか否かを問わず、ブロック487に示すように仮想閉鎖操作によって仮想フラッシュ操作が呼び出され、ブロック488に示すように実ソケットとの接続を断つ。次に、ブロック490に示すように仮想閉鎖がシンプレックス仮想ソケットの閉鎖であるかどうかを調べ、そうでない場合は「No」経路をとってブロック495に進む。閉鎖はマルチプレックス仮想ソケットの閉鎖であるため、ブロック495でそれが最後のマルチプレックス仮想ソケットであるかどうかを判断し、最後のマルチプレックス仮想ソケットである場合は、ブロック496に示すようにマルチプレックス活動タイマをセットする。最後のマルチプレックス仮想ソケットでない場合は、ブロック496をスキップする。
ブロック490に戻って、仮想閉鎖がシンプレックス仮想ソケットの閉鎖である場合、ブロック491に示すようにそれに対応する実ソケットを事象リストから除去し、ブロック492に示すように実ソケットを閉鎖し、削除する。ソケットがシンプレックスとマルチプレックスのどちらの仮想ソケットであるかを問わず、ブロック497に示すようにその仮想ソケットに閉鎖のマークを付け、ブロック498で閉鎖操作は終了する。
次に、第20図ないし第23図および第24図ないし第25図に関連する第15図ないし第17図について説明する。実事象が発生すると、第16図のブロック302を終了し、ソケット・マネージャは事象がどのように生成されたかに基づいてその事象を調べる。事象が第25図のブロック496で設定されたマルチプレックスソケット活動タイマのタイム・アウトである場合、第16図のブロック305からブロック312までの経路がとられる。第16図に示すように、次にソケット・マネージャによってブロック312および313の操作が行われ、マルチプレックス実ソケットが閉じられ、クライアント側インタセプト・モジュールをサーバ側インタセプト・モジュールに接続するソケットに対応するマルチプレックス実ソケットが削除される。その後、ソケット・マネージャは次の実事象を待つ。ブロック322に示すように、このマルチプレックス事象タイマはマルチプレックス仮想ソケットの作成によってリセットされる。
実ソケット上で発生した事象が、ウェブ・サーバがウェブ・サーバとサーバ側インタセプト・モジュールとの間のソケット接続に対する閉鎖操作を行う場合などの実ソケット閉鎖である場合、第16図のブロック305からブロック309への経路がとられる。ソケット・マネージャはブロック309に示すように実事象リストからその実ソケットを除去し、ブロック310に示すように1つの仮想ソケット(または複数のマルチプレックスソケットの場合は複数の仮想ソケット)をその1つの実ソケットまたは複数の実ソケットから切断する。次に、ソケット・マネージャはその仮想ソケットに閉鎖のマークを付け、仮想事象を通知する。この操作はブロック311に示されており、仮想ソケット待ち行列からすべてのデータが空にされると、仮想ソケットは閉じる。仮想ソケットに閉鎖のマークを付けた後、決定ブロック315に示すようにソケット・マネージャは閉じる実ソケットがシンプレックス・ソケットであるかどうかを判断する。閉じる実ソケットがシンプレックス・ソケットである場合、ブロック316に示すようにその実ソケットを閉じ、削除する。次にソケット・マネージャはブロック302に示すように次の実事象を待つ。
閉じるソケットがシンプレックス実ソケットではない場合、ブロック315の「No」経路をとり、ソケット・マネージャは次の実事象を待つ。したがって、マルチプレックス実ソケット、すなわちクライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとを接続するソケットを、マルチプレックスソケット活動タイマのタイムアウトのみによって閉じることができる。これによって、ユーザ指定の所定時間の間、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとの間の接続を、モジュール間の最後の通信が行われた後でも維持することができる。マルチプレックスソケット活動タイマのタイムアウトの前にブラウザからその後の接続要求があった場合、クライアント側インタセプト・モジュールとサーバ側インタセプト・モジュールとの間に接続を再確立せずに通信を行うことができ、それによってそのような接続を再確立するオーバーヘッドが不要になる。
第15図ないし第17図で説明する最後の経路は、実事象が発生し、その事象が第14図の1つまたは複数のマルチプレックス実ソケット36aまたは36b上でのデータの受信である場合である。マルチプレックス実ソケット上でデータを受信すると、そのデータは検査され、第25図のブロック486で仮想待ち行列に付加されるもののようにデータに閉鎖操作標識が含まれている場合は、仮想閉鎖操作が行われ、ブロック320からブロック310への経路がとられる。ソケット・マネージャは、ブロック310に示すように実ソケット上で受信したデータで識別されたマルチプレックス仮想ソケットを実ソケットから切断し、次にブロック311に示すように仮想ソケットに「閉鎖」のマークを付け、仮想事象を通知する。この閉鎖はマルチプレックス仮想ソケットの閉鎖であるため、ブロック315から「No」経路がとられ、ブロック302に示すようにソケット・マネージャは別の実事象を待つ。
第15図ないし第25図で説明されている操作を行うことによって、本発明の特定の態様は外部通信リンクを介して第1のコンピュータと第2のコンピュータとの間に持続的接続を確立する。この持続的接続は、すべてのウェブ・ブラウザ発信通信が完了するまで維持され、持続的接続が維持されている間に複数のウェブ・ブラウザ発信通信がインタセプトされ、外部通信リンクに多重化されて送られる。次にクライアント/サーバ固有データ・ストリームを多重化解除して複数のHTTPデータ・ストリームを作成し、その複数のHTTPデータ・ストリームをウェブ・サーバに供給することができる。また、持続的接続は、すべてのウェブ・サーバ発信通信がインタセプト完了するまで維持される。持続的接続が維持されている間に、複数のウェブ・サーバ発信通信がインタセプトされ、外部通信リンクに多重化されて送られる。さらに、クライアント/サーバ固有データ・ストリームを多重化解除して複数のHTTPデータ・ストリーを作成し、その複数のHTTPデータ・ストリームをウェブ・サーバに供給することができる。
図面および本明細書では、本発明の典型的な好ましい実施例を開示し、特定の用語を使用したが、これらの用語は総称および説明のためものに過ぎず、請求の範囲に記載されている本発明の範囲を限定するためのものではない。
まとめとして、本発明の構成に関して以下の事項を開示する。
(1)外部通信リンクを介して接続され、ウェブ・ブラウザおよびクライアント側インタセプト・モジュールを含む第1のコンピュータと、ウェブ・サーバおよびサーバ側インタセプト・モジュールを含む第2のコンピュータとを含むコンピュータ・システムで、第1のコンピュータ内に常駐するウェブ・ブラウザと第2のコンピュータ内に常駐するウェブ・サーバとの間でURLに対応するデータを、クライアント・キャッシュおよびサーバ・キャッシュを使用してキャッシュする方法であって、
前記第1のコンピュータのクライアント側インタセプト・モジュールが前記ウェブ・ブラウザから受信し、かつ前記ウェブ・サーバに送るべきHTTP要求を前記クライアント・キャッシュ内に格納して、前記ウェブ・ブラウザからの要求に対応するクライアント・キャッシュ項目を生成するステップと、
前記第1のコンピュータが、前記クライアント・キャッシュ項目の生成時間を格納して、クライアント・キャッシュ項目のデータ格納時刻(SDT)を生成するステップと、
前記第2のコンピュータが、前記ウェブ・ブラウザからの要求に応答して、前記ウェブ・ブラウザからの前記HTTP要求を前記サーバ・キャッシュ内に格納して、サーバ要求キャッシュ項目を生成するステップと、
前記第2のコンピュータの前記サーバ側インタセプト・モジュールが、前記HTTP要求に対応する前記サーバ要求キャッシュ項目が前に前記サーバ・キャッシュ内に格納されていたかどうかを判定するために、前記ウェブ・ブラウザが発生し、かつ前記ウェブ・サーバにより受信される前記HTTP要求および前記クライアント・キャッシュ項目の内容を示す固有の標識を受領するステップと、
前記第2のコンピュータの前記サーバ側インタセプト・モジュールが、前記ウェブ・ブラウザからの前記HTTP要求に対応し、前記HTTP要求に対応するサーバ要求キャッシュ項目と同じクライアント・キャッシュ項目が存在するかどうかを判定するステップと、
前記第2のコンピュータの前記サーバ側インタセプト・モジュールが、前記ウェブ・ブラウザからの前記HTTP要求を受信した時間と、前記ウェブ・ブラウザからの前記HTTP要求に対応する前記サーバ要求キャッシュ項目が生成された時間との間の時間間隔を計算して、コヒーレンシ間隔内にある場合であって、前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じ場合に、前記クライアント側インタセプト・モジュールにコヒーレント応答を送るステップと、
前記第2のコンピュータの前記サーバ側インタセプト・モジュールが、前記クライアント・キャッシュ項目が前記サーバ要求キャッシュ項目と同じでなく、かつコヒーレンシ間隔内にあると判断した場合に、現行日時からキャッシュ項目のデータ格納時刻(SDT)を引いて生成された項目エージ・データを生成するステップと、
前記第2のコンピュータの前記サーバ側インタセプト・モジュールが、前記サーバ要求キャッシュ項目が前記クライアント・キャッシュ項目と同じでなく、かつコヒーレンシ間隔内にある場合、生成した前記項目エージ・データを前記クライアント側インタセプト・モジュールに送信するステップと含む方法。
(2)前記サーバ側インタセプト・モジュールから受信した前記項目エージ・データのデータ格納時刻(SDT)を前記第1のコンピュータの現在時間から減じることによって、前記ウェブ・ブラウザからの前記HTTP要求に対応する前記クライアント・キャッシュ項目のデータ格納時刻(SDT)を更新するステップをさらに含む、(1)に記載の方法。
(3)前記第1のコンピュータと前記第2のコンピュータとが無線通信リンクを介して通信することを特徴とする、(1)に記載の方法。