(57)【要約】【課題】  再使用のために、圧縮されたオブジェクトを格納しかつそれらにアクセスするための方法と装置を提供すること。【解決手段】  本発明は、再使用のために圧縮されたオブジェクトを格納し、かつそれらにアクセスするための方法と装置を提供する。圧縮されたデータ、例えば、ウェブから受信されたオブジェクトは、キャッシュに書き戻される。これは、圧縮設定に応じて、同じオブジェクトに対して、多重のオブジェクト・サイズの蓄積を可能にする。一旦オブジェクトが圧縮されてしまうと、再びそれを圧縮する必要はない。本発明は、例えば、もしリクエストがクライアントにより受信されると、オブジェクトに対する第2のリクエストに対して、追加圧縮を達成するために、オブジェクト・ヘッダを圧縮することも提供する。クライアントレスモードの場合、ヘッダを圧縮する必要は全くない。【選択図】なし【特許請求の範囲】
【請求項１】
オブジェクトをリクエストするためのクライアント、
当該リクエストされたオブジェクトを読み出すためのサーバ、
当該オブジェクトが初めてリクエストされるときに、当該リクエストされたオブジェクトを圧縮するためのコンプレッサ、並びに、
当該リクエストに応答して当該圧縮されたオブジェクトを当該クライアントに提供し、及び、再使用のためにキャッシュに当該圧縮されたオブジェクトを格納するためのゲートウェイ
を備える、オブジェクトを格納しかつそれらにアクセスするための装置。
【請求項２】
当該コンプレッサが、さらに、複数の圧縮レベルの何れかを遂行するための手段を備える装置であって、
当該ゲートウェイが、当該オブジェクトに適用される圧縮の各レベルにおいて当該オブジェクトのコピーを保存する、請求項１に記載の装置。
【請求項３】
その元のフォーマットから当該オブジェクトを複数の目標フォーマットの何れかに変換する翻訳手段を、さらに、備え、
当該ゲートウェイが、当該オブジェクトのコピーを当該オブジェクトが翻訳される各目標フォーマットに格納する、請求項１に記載の装置。
【請求項４】
当該オブジェクトをプリフェッチするための手段を、さらに、備え、
当該オブジェクトが、圧縮されていて、かつそれに対するリクエストの前に、当該キャッシュに格納されている、請求項１に記載の装置。
【請求項５】
当該オブジェクトが、さらにヘッダを備える、請求項１に記載の装置。
【請求項６】
当該ヘッダが、圧縮されている、請求項５に記載の装置。
【請求項７】
そこにおいて当該ヘッダは圧縮されていない請求項５に記載の装置
【請求項８】
当該オブジェクトがリクエストされるときに、キャッシュされ、圧縮されたオブジェクトを確認し、かつ位置を探すためのテーブルを、さらに、備える、請求項１に記載の方法。
【請求項９】
当該オブジェクトが、さらに、当該オブジェクトと関連したメタデータを備える、請求項１に記載の方法。
【請求項１０】
オブジェクト識別情報、オブジェクト圧縮係数、オブジェクト解像度、オブジェクトフォーマット、オブジェクト換算係数、および、オブジェクト暗号情報の何れかを備える請求項９に記載の方法。
【請求項１１】
クライアントが、オブジェクトを要求するステップ、
サーバが、当該要求オブジェクトを読み出すステップ、
初めて当該オブジェクトがリクエストされるときに、当該要求オブジェクトを圧縮するステップ、
当該リクエストに応答して、当該圧縮されたオブジェクトを当該クライアントに提供するステップ、そして、
当該圧縮されたオブジェクトを再使用のためにキャッシュに格納するステップ
を備える、オブジェクトを格納しかつそれにアクセスする方法。
【請求項１２】
当該圧縮ステップが、圧縮の複数のレベルの何れかを遂行するステップを、さらに、備え、
当該オブジェクトのコピーが、当該オブジェクトに適用される圧縮の各レベルに保存される、請求項１１に記載の方法。
【請求項１３】
その元のフォーマットから複数の目標フォーマットの何れかに変換するステップを備え、
当該オブジェクトのコピーが、当該オブジェクトが翻訳される各目標フォーマットに格納される、請求項１１に記載の方法。
【請求項１４】
当該オブジェクトをプリフェッチするステップを、さらに、備え、
当該オブジェクトが、圧縮されていて、かつそれに対するリクエストの前に、当該キャッシュに格納される、請求項１１に記載の方法。
【請求項１５】
当該オブジェクトが、さらに、ヘッダを備える、請求項１１に記載の方法。
【請求項１６】
当該ヘッダが、圧縮されている、請求項１５に記載の方法。
【請求項１７】
当該ヘッダが、圧縮されていない、請求項１５に記載の方法。
【請求項１８】
当該オブジェクトがリクエストされるときに、キャッシュされ、圧縮されたオブジェクトを確認しかつ位置を探すためのテーブルを提供するステップを、さらに、備える、請求項１１に記載の方法。
【請求項１９】
当該オブジェクトと関連したメタデータを、さらに、備える、請求項１１に記載の方法。
【請求項２０】
オブジェクト識別情報、オブジェクト圧縮係数;
オブジェクト解像度;
オブジェクトフォーマット;
オブジェクト換算係数;および
オブジェクト暗号情報
の何れかを備える、請求項１９に記載の方法。
【請求項２１】
一度、オブジェクトを圧縮するステップ、
再使用のために、キャッシュに当該圧縮されたオブジェクトを保存するステップ、
当該キャッシュから当該圧縮されたオブジェクトを直接読み出すステップ、および
当該圧縮されたオブジェクトをクライアントに直接送信するステップ
を備えるオブジェクトを格納しかつそれらにアクセスする方法。
【請求項２２】
圧縮されていないオリジナルのオブジェクトを当該キャッシュに保存するステップを、さらに、備える、請求項２１に記載の方法。
【請求項２３】
一度、元の当該オリジナルの圧縮されていないオブジェクトが受信されると、当該オブジェクトのデータは圧縮されるが、オブジェクト・ヘッダは圧縮されない、請求項２２に記載の方法。
【請求項２４】
当該圧縮ステップが、使用される圧縮技術を確認するために内部的に情報を保存するステップを、さらに、備える、請求項２２に記載の方法。
【請求項２５】
オブジェクトに対しリクエストが再びなされると、当該オブジェクトに対する識別子が、内部テーブルに維持されている、対応する圧縮されたオブジェクト識別子に翻訳される、請求項２１に記載の方法。
【請求項２６】
圧縮されたデータ部分と別々の、圧縮されていないヘッダ部分として当該オブジェクトを維持するステップを、さらに、備え、
当該ヘッダが、当該オブジェクトを識別するために使用され、
圧縮されたオブジェクトがリクエストされるときに、その大きさが、当該オブジェクト自体を備えるデータより非常に小さいので、当該オブジェクト・ヘッダは急速に圧縮することができる、請求項２１に記載の方法。
【請求項２７】
オブジェクトのプリフェッチ・リクエストを始めるステップ、
当該オブジェクトが圧縮されたオブジェクトとしてキャッシュの中に存在しない場合、標準ヘッダを備えるリクエストを準備するステップ、
当該リクエストをサーバに送信するステップであって、当該サーバが、当該サーバからの、または、オリジナルのサーバからの当該リクエストを満たしているステップ、
当該サーバから応答が戻るときに、当該オブジェクトに関連するが、応答ヘッダには関連しないデータを圧縮するために、当該オブジェクトを、圧縮されたデータにそれに話しているフラグを備えるコンプレッサに送るステップ、  
当該コンプレッサが圧縮されたオブジェクトを送り返すときに、当該圧縮されたオブジェクトを列に保存するステップ、
第2のリクエストを当該サーバに送信するステップ、
当該サーバが当該第2のリクエストを受け取るときに、当該サーバが、当該キャッシュから直接当該第2のリクエストを満たすステップ
を備える、オブジェクトを格納しかつそれらにアクセスする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、圧縮されたオブジェクトを保存するための技術に関する。特に、本発明は、後の検索のために圧縮されたオブジェクトを保存するための技術に関する。
【背景技術】
【０００２】
電子形式で情報を表現するオブジェクト、例えば、ウェブページまたはその部分を有するHTML情報は、しばしばキャッシュされる。これによって、ウェブからオブジェクトを再ロードする必要なく、オブジェクトを急速に読み出すことが可能になる。この種のオブジェクトは、しばしば、例えば、ブラウザを備える携帯電話のような無線デバイスに対して提供されるコンテンツの重要な部分を構成する。しかしながら、ワイヤレス・デバイスがウェブ・ゲートウェイと通信することを可能にするウェブとワイヤレス通信チャネル間の帯域幅の違いのため、オブジェクトは、それがワイヤレス通信チャネルを介して無線デバイスに送られる前に、先ず圧縮されなければならない。現行では、すべてのオブジェクトがキャッシュに格納される。オブジェクトが、再びリクエストされると、キャッシュから完全なオブジェクトを獲得して、それを再び圧縮することが必要となる。これは、重要なシステムリソースを使用する。図1は、プリフェッチ作業を用いずに、オブジェクトに対するリクエスト・フローを示すブロック図であって、ここでは、一連のフローが、相当する矢と関連付けられたアルファベットと数字A1〜A6によって示されている。図２は、オブジェクトに対するリクエスト・フローを示すブロック図である。図1および図2の各々において、クライアント11は、HTTPのような転送機構により、ゲートウェイ15から、サーバ17に格納されているオブジェクトからのオブジェクトを要求する。検索時、オブジェクトは、コンプレッサ13によって圧縮され、次いで、ゲートウェイを経てリクエスト・クライアントに戻される。図2は、プリフェッチ動作が可能である場合を示す。このように、オブジェクトは、あらかじめキャッシュされ、そして圧縮のために局所的に読み出すことができる。
【０００３】
オブジェクトが、解像度の様々なレベルでリクエストされると、更なる問題が発生する。現在では、オブジェクトは、それがリクエストされるたびに、キャッシュ（または、もしオブジェクトがキャッシュされていなかったならば、ウェブ）から読み出されなければならない。そして、更に、それは、目標デバイスに対して適切な程度の圧縮を用いて圧縮されなければならない。これは、特定のオブジェクトが、繰り返し圧縮されなければならないことを意味する。ここで、オブジェクトの解像度は、それが圧縮されるたびに、異ならせてもよい。
【０００４】
最後に、さまざまな目標デバイスに対して、オブジェクトをリクエストすることができるが、この場合、このオブジェクトに対しては、異なるフォーマットが必要である。例えば、このオブジェクトが、1つのプラットホームでHTMLで必要となるが、他のプラットホームは、ASCIIをサポートしている場合がある。このように、オブジェクトは、それがリクエストされるたびに、始めのフォーマットから目標プラットホーム・フォーマットに翻訳され、かつ次いで圧縮されなければならない場合がある。
【０００５】
これらの反復される圧縮およびフォーマットの翻訳作業によって、重要なバッファリングおよび処理要求が、システムに加わる。
【０００６】
再使用のために圧縮されたオブジェクトを保存しかつそれらにアクセスするための方法と装置を提供することは、有利であろう。この種の方法と装置が、いくつかのフォーマットおよび／または解像度の程度の内の一つまたは複数において、オブジェクトをキャッシュすることが可能で有れば、このことも有利であろう。
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明は、再使用のために、圧縮されたオブジェクトを格納しかつそれらにアクセスするための方法と装置を提供する。圧縮されたデータ、例えば、ウェブから受信されるオブジェクトは、キャッシュに書き戻される。これは、圧縮設定に応じて、同じオブジェクトに対して複数のオブジェクト・サイズの格納を可能にする。オブジェクトが既に圧縮されている場合には、それを再び圧縮する必要はない。例えば、もしリクエストが、クライアントによって受信された場合、オブジェクトに対する第2のリクエストに対して、オブジェクトのヘッダを圧縮して、追加の圧縮を達成することを提供する。クライアントレスモードの場合、ヘッダを圧縮する必要は全くない。
【０００８】
（定義）
以下の簡略記憶記号が、この文書において、それらの関連する意味に対して使用される：
VS：これは、サーバに関連する。
VC：これは、クライアントに関連する。
VCO：これは、圧縮されたオブジェクトを格納するために使用されるデータ構造である。
プリフェッチ(Prefetch)：これは、本発明によって強化される下部データ構造である。
COURL：これは、VCO拡張を有する修正されたURLである
NMURL：これは、キャッシュに送られる通常のURLである
CP：これは、COURLを扱うために使用されるキャッシュ・プロクシである。
【発明を実施するための最良の形態】
【０００９】
（明細書本文）
オブジェクトが読み出されるときに、それはコンプレッサを通過しなければならない。オブジェクトを圧縮するための、CPUに対する負荷は、極めて大きい。同じオブジェクト上で同じ圧縮をすることは、時間がかかりそして遅い。本発明は、時折オブジェクトを圧縮して、それらをキャッシュに保存することが、CPUを多く使用ことを回避するという認識に起因する。本発明の好ましい実施例は、キャッシュに圧縮されたオブジェクトを保存する。特定のオブジェクトに対して新しいリクエストが受信されると、それは、直接キャッシュから読み出すことができ、かつクライアントに送信することができる。
【００１０】
本実施例の場合、元々のオブジェクトは、キャッシュに保存される。一旦完全なオブジェクトが、受信されると、データは、圧縮される、しかし、ヘッダは、圧縮されない。圧縮されたオブジェクト（VCO）は、キャッシュに保存される。十分な情報は、使用された圧縮技術を特定するために、内部的に保存される。この方法の1つの長所は、圧縮されたオブジェクトが、次の使用のためにキャッシュに保存されるということである。リクエストが、そのオブジェクトに対し再びなされると、URLは、対応するCOURLに転送され、それは、内部テーブルに維持される。その後、圧縮されたデータは、キャッシュから直接読み出すことができる。このような方法でキャッシュに格納されているデータは、それらが圧縮されているので、バッファの使用量は、より少なくなる。データが、はるかにより速い時間でキャッシュからサーバに移される、つまり、転送が、少なく、かつ圧縮する必要がなくなるので、この方法は、CPUの使用がより少なくなり、かつより高速になる。VCOが、リクエストされると、ヘッダは、そのサイズが、オブジェクト自体を有するデータよりはるかに小さいので、比較的急速に圧縮させることができる。VCOは、次いで、クライアントへ転送される。
【００１１】
これは、図3-5に最もよく示される。ここで、図3は、本発明の第１実施例のオブジェクトに対するリクエスト・フローを示すブロック図である。図4は、本発明の第２実施例のオブジェクトに対するリクエスト・フローを示すブロック図である。そして、図5は、本発明の第３実施例のオブジェクトに対するリクエスト・フローを示すブロック図である。
【００１２】
図3に示されるように、クライアントは、オブジェクト、つまりTaj.gif.を要求する。オブジェクトは、本発明を組み込んだゲートウェイ31を介してアクセスされる。オブジェクトは、プリフェッチ動作の結果キャッシュさせてもよいし、又はそれは、リクエストの実行に応じてフェッチさせてもよい。最初リクエストされると、オブジェクトは、コンプレッサ13に送られ、そして、それは、クライアントに提供され、かつその圧縮形態、例えば、Taj.gif.vcoでキャッシュに格納される。オブジェクトを伸長することなくオブジェクトの位置を探すことを容易にするために、オブジェクトのヘッダは、圧縮されていない形、例えば、Vco.htmlとしてオブジェクトから離れて維持される。さまざまなメタデータは、フォーマット、解像度等のようなオブジェクト名に含ませることができる。図4は、オブジェクトがフェッチされ、圧縮され、そしてキャッシュに格納され、そして、オブジェクトの複数のフォーマット、つまり、GIFおよびPNGが存在する実施例による本発明を示す。そして、図5は、オブジェクトが、すでにキャッシュ中にあり、そしてその圧縮状態で読み出されるだけである更なるケースを示す。
【００１３】
（相関性）
下記は、他のモジュールによって使用される外部関数である。
* int http_a_prefetch（int wi,int flags）;
* int http_vbuf_to_url（uchar *url、int bidx、int max_len）;
* int vco_process_courl_request（int wi）;
* int vco_process_http_request（int wi）;
* int vco_set_compression_info（int wi）;
* int fwd_vco_a_data（int wi、int idx、int ta_close、int flags）;
* void vco_get_request_capability（int wi）;
【００１４】
（要求）
VCOに対する主な相互作用は、HTTPリクエスト、プリフェッチ・リクエスト、およびコンプレッサの間にある。
【００１５】
（使用性）
サーバ上のグラフィカル・ユーザー・インターフェイス（GUI）は、構成される特徴を有する。圧縮ページは、GUI上の主なものである。それは、Gif2Png、J2kに対する構成を有する。それは、また、ポップアップ・ブロッキングとロッシー HTMLフィルターも有する。これらは、能力関数によりそれらをコンプレッサ・フラグに翻訳するために、VCOにより使用される。
【００１６】
（GUI）
GIF からPNGへの変換：［画像］
JPEG 2000 サポート：:［画像］
リロードによりオリジナル画像を送る
クライアント／サーバ：［画像］
クライアントレス：［画像］
下記は、VCO特徴を構成するためのGUIである：
圧縮されたオブジェクトをキャッシュする：［画像］
これは、使用不能または可能にさせることができるチェックボックスである。
【００１７】
（設計仕様）
リクエスト・フロー
図6は、リクエストのフローを記載するフロー図である。リクエストは、クライアント（VC）から来る。我々は、VCOをチェックして、リクエストがあるか無いかを知る必要がある。我々は、プリフェッチから来るリクエストとHTTPから来るリクエストを区別する。
【００１８】
プリフェッチから来るリクエスト
この場合、コンプレッサは、ベースHTMLページを解析し、そしてページに埋め込まれるオブジェクトに対するリクエストを出す。プリフェッチ側におけるフローは、図7に示される。
【００１９】
プリフェッチ
プリフェッチのリクエストは、VSによって始められる。オブジェクトが、VCOの中に存在しなければ、我々が、標準ヘッダを有するリクエストを配置する。次いで、我々は、キャッシュにリクエストを送る。キャッシュは、これを通常のリクエスト（A1）とみなして、サーバまたは原サーバの何れかのリクエストを実現する。応答（A2）が戻ると、我々は、フラグを有するコンプレッサにデータを送り、それに、データは圧縮するが応答ヘッダは圧縮しないよう伝える。コンプレッサが、圧縮されたオブジェクトを送り返すと、我々は、テンポラリ・バッファにそれを保存する。コンプレッサは、オリジナル情報および圧縮情報がいつ得られたかについても我々に伝える。それは、次いでエイド（特定されたアプリケーション）をデータ構造にセットする。その時、VSは、VSによって始められる他のリクエストであるCOURL（A3）をキャッシュに送る。キャッシュが、このリクエストを受信すると、それは、キャッシュから直接それを実現することができる。応答（A4）がVSによって得られると、それは接続を落とす。
【００２０】
もしサーバが、データを有さない場合（最初のリクエストの場合、またはディスクからデータが取り除かれてしまっている場合）、それは、キャッシュ・プロクシ（A5）のポート8009のCOURLに対するVSにリクエストを送り返す。VSがこのリクエストを得ると、それは、このリクエストを以前のリクエストとマッチングさせ、そしてこれらの2つのリクエストを接続する。A3からのソケットは、A2に接続され、そして、A3は、閉じられる。次いで、データは、A2にフローし、そして、この応答は落される。このようにして、キャッシュは、このデータをそれに格納させるべきである。
【００２１】
HTTP
リクエストは、HTTPから来る。この場合、リクエストは、VCを介してまたは直接、ブラウザによって、始められている。いずれにせよ、我々は、この接続、つまり、プリフェッチ・リクエストによる区別化を落とすことができない。この場合のフローは、オブジェクトがVCOに存在するか否かに依存する。
【００２２】
この間、我々は、関連するさまざまなバケットにオリジナル情報および圧縮情報を格納する。最初、我々は、圧縮情報がどのように見えるかについて知らない。
【００２３】
COが存在しない場合
図8は、COが存在しない場合の、リクエストのフローを記載するフロー図である。
【００２４】
COが存在する場合
図9は、COが存在する場合の、リクエストのフローを記載するフロー図である。この場合、我々は、同じオブジェクトに対し一連のリクエストを有する。
【００２５】
サーバ要求
もしサーバが、圧縮されたオブジェクトを有すると、それはすぐにそれをキャッシュから返す。これは、実際の利益がVCOのものである場合である。我々は、この目的のためにMCPを使用する。VCOリクエストが、MCPを介して、COURLに基づいて来る時、我々は、どのエントリがVCOの中にあるのか、そして、拡張が、我々に圧縮情報を与えることを知っている。これは、我々にリクエストを相関させる。我々は、ヒンフォをこれらの値に基づいて設定し、次いでNMURL リクエストを出すべきである。
【００２６】
外部キャッシュ・サポート
キャッシュは、外部モードでも働かせることができる。サーバが、外部キャッシュに接続されると、我々は、キャッシュに対してプロクシ・リクエストとしてHTTPリクエストを送る。サーバは、次いで、HTTPサーバとして動作し、そして、外部キャッシュは、HTTP クライアントとして動作する。
【００２７】
もしそれが、VCO拡張によって終わり、外部キャッシュが、この特徴を利用することができるか否かを決定する場合には、外部キャッシュの能力は、サーバに戻すリクエストを我々に送ることを可能にする。キャッシュは、我々に送り返すリクエストを発行する通常の表現を使用する。他のいかなるキャッシュも、この種の構成をサポートしなければならない。フローの残りは、これと類似して起こるべきで、かつ、我々が、世話をするべき特別な必要性も存在しない。
【００２８】
内部構造
ファイルのフォーマット
2007523400.tif 000002
2007523400.tif 000003
【００２９】
Gif2Png、PPM、J2kに対する構成を有するapp.xmlへ移動した2つの他のテーブルがある。また、ポップアップ・ブロッキングおよびロッシーHtmlフィールドが、加えられている。これらは、構成に基づいてコンプレッサ・フラグを設定するために、VCOにより使用される。
2007523400.tif 000004
【００３０】
レベル4は、それが、制御リフレッシュ・メカニズムのために使用されるので、内部にあり、xmlでは常にオフであるべきである。
データ構造
2007523400.tif 000005
2007523400.tif 000006
【００３１】
現在、定義されるコンプレッサ・タイプは、6つある：
#define COMP_TYPE_UNKNOWN                0
#define COMP_TYPE_NONE                   1
#define COMP_TYPE_GIF                    2
#define COMP_TYPE_JPG                    3
#define COMP_TYPE_ZLIB                   4
#define COMP_TYPE_HTML                   5
【００３２】
未知なのは、我々が、それがどんなタイプのオブジェクトであるかわからない時である。一旦コンプレッサが、応答を見ると、それは、そのタイプが、何であるかについて決定することができ、そして、それは、それにしたがって、タイプをセットする。
【００３３】
コンプレッサ・コントロール・フラグは、以下のように定義される。これらのフラグは、それが、リクエストを送り出す前に、VentSが、セットするコンプレッサに対する制御を表すので、コンプレッサは、この応答をどのように扱うかを知る。我々がタイプを知っており、かつ我々が、どんなフラグがセットされなければならないかについても知っているオブジェクトに対して、フォースが、使用される。
2007523400.tif 000007
【００３４】
コンプレッサhdrおよびコンプレッサ・ボディ・フラグが、応答のどの部分が圧縮されることが必要であるかをコンプレッサに知らせるために使用される。ZLIBヘッダも、それにしたがってセットされる。VALIDフラグは、戻って来る値が有効であるということを知らせる方法として、コンプレッサからVentSへの信号として使用される。PREFETCHは、プリフェッチ特徴がオンにされたこと、およびHTMLの中のオブジェクトがプリフェッチさせることができることを示すためにセットされる。HEADは、ヘッドのリクエストを表すので、我々は、それに対するボディを有しない。
【００３５】
下記は、VentSからコンプレッサに送られかつ再び戻されるコンプレッサ・フラグである。VentSが値をセットすると、それは、リクエストの能力を見て、これらのフラグのうちのどれをセットさせることが必要であるかを決定する。コンプレッサが、VALIDフラグをセットすると、それは、我々が適切に行動することができるように、それがオブジェクトに何をしたかについても示す。
2007523400.tif 000008
【００３６】
これらのフラグは、コンプレッサからセットされる。これらは、それらを送り返すために、VCOにより使用されるであろう。
2007523400.tif 000009
【００３７】
Gif画像に対して、我々には、各レベルに対してチャンキングを有するgif、gif2pngの選択がある。考慮するレベルが5個あるので、潜在的に許容される組合せは、以下の通りである。
#define VCO_ST_GIF_NONE                0
#define VCO_ST_GIF_L0                  1
#define VCO_ST_GIF_L1                  2
#define VCO_ST_GIF_L2                  3
#define VCO_ST_GIF_L3                  4
#define VCO_ST_GIF_L4                  5
#define VCO_ST_GIF_CHUNK_L0            6
#define VCO_ST_GIF_CHUNK_L1            7
#define VCO_ST_GIF_CHUNK_L2            8
#define VCO_ST_GIF_CHUNK_L3            9
#define VCO_ST_GIF_CHUNK_L4           10
#define VCO_ST_GIF_PNG_L0             11
#define VCO_ST_GIF_PNG_L1             12
#define VCO_ST_GIF_PNG_L2             13
#define VCO_ST_GIF_PNG_L3             14
#define VCO_ST_GIF_PNG_L4             15
#define VCO_ST_GIF_PNG_CHUNK_L0       16
#define VCO_ST_GIF_PNG_CHUNK_L1       17
#define VCO_ST_GIF_PNG_CHUNK_L2       18
#define VCO_ST_GIF_PNG_CHUNK_L3       19
#define VCO_ST_GIF_PNG_CHUNK_L4       20
#define VCO_ST_GIF_MAX_BUCKET
VCO_ST_GIF_PNG_CHUNK_L4 + 1
【００３８】
JPEG画像に対して、我々には、各レベルに対してチャンキングして、jpeg、j2kの選択がある：
2007523400.tif 000010
【００３９】
ZLIBのタイプに対して、我々は、以下のサブタイプを使用する。これらのサブタイプは、5つの異なるタイプである。
- ppm
- 標準辞書を有するzlib
- ロード可能な辞書を有するzlib
- DEFLATE
- GZIP
【００４０】
次いで、あなたには、チャンキングするかしないかの選択がある。これは、以下の組合せを導く。
2007523400.tif 000011
【００４１】
HTMLのタイプに対して：
これは、他のZLIbオプションと比較された特別なタイプの種類として扱われる。それは、最大数のオプションを有する。
【００４２】
以下のサブタイプ、STD辞書、ロード可能な辞書、パルス位置変調、デフレートおよびGZIPが、ある：。
【００４３】
各サブタイプに対して、チャンキング、ロッシーHTMLおよびポップアップ・ブロッキングの選択がある。このようにして、操作されるバケットに5* 8 = 20組合せがある。これは、バケットの以下の組合せを導く。
2007523400.tif 000012
2007523400.tif 000013
【００４４】
下記は、コンプレッサへの／からのVentSから情報を渡すために使用されるヒンフォ構造である。
2007523400.tif 000014
2007523400.tif 000015
【００４５】
関数の記述
この節は、本発明の現在の好ましい本実施例において、実施されているコードを詳細に記載する。
【００４６】
VCOに対する内部関数
*static int vco_get_courl_extension（int wi、uchar *co_extension）
co url拡張は、以下のフォーマット
.vco_<type%lu>_<comp_flags %lx>_<lddict %lu>_vco
を有する。
【００４７】
サーバは、その最端部で_vcoをサポートするために構成されている。それは、この種のリクエストをキャッシュ・プロクシに送信する（VentSに戻る）。
【００４８】
サーバのアクセスログにおけるリクエストは、以下に類似するようなものである：
1067672272.136     22 127.0.0.1 TCP_MISS/200 541 GET http://www.employees.org/~pradeep/vco.html.vco_5_8_0_vco
-
DEFAULT_PARENT/127.0.0.1 text/html
1067673025.244      2 127.0.0.1 TCP_MEM_HIT/200 3452 GET
http://www.employees.org/~pradeep/images/feedback.gif.vco
_2_5020_2_vco -
NONE/- image/gif
【００４９】
* static int vco_get_ci_from_courl_extension
(uchar *co_extension, ulong *type, ulong *comp_flags, ulong *ld_dict)
この関数は、CO拡張を入力として取り込みそしてタイプcomp_flags、Id_dictを戻す。
【００５０】
* static void vco_update_prefetch_record (int wi)
プリフェッチ・リクエストまたはVCO プリフェッチ・リクエストが完了すると、これはプリフェッチ記録を更新するために使用される。
【００５１】
* static int  get_compression_index (int wi, int *cidx)
これは、どの圧縮値が存在するかを知るために我々が必要とするバケットを得る。
【００５２】
* static int  vco_set_hinfo_by_record (int wi, int cidx)
この関数は、VCO表の特定のバケットから情報を得て、そしてそれに基づいてヒンフォをセットする。これは、我々が、以前の完了から使用される利用可能なフラグを有する次のリクエストに対して使用される。
【００５３】
* static void vco_set_other_buckets (int wi, int cidx)
我々が、同じ特徴を有する他のバケットをセットすることに決めるときに、この関数は、呼び出される。
【００５４】
以下は、バケットの概要である。オブジェクトのZLIBタイプの例を採用する。
2007523400.tif 000016
左側の列は、我々がサポートするフラグとしてコンプレッサに送るものである。他の列は、それが、圧縮情報をセットしたいときに、コンプレッサが、セットする値である。ここで、チャンキングをするまたはしない組合せが、存在する。
【００５５】
我々が、あるオブジェクトに対し、下記のようにコンプレッサに圧縮フラグを送ったとしよう。
2007523400.tif 000017
【００５６】
コンプレッサが有効フラグとともに戻ると、
2007523400.tif 000018
【００５７】
我々は、タイプが5（HTML）であることを知っているので、我々は、リクエストが、29. VCO_ST_DEF_CHUNK_NLHNPBのバケットを有すると決定することができる。これは、それが、デフレートであり、かつチャンクされ、サポートされ、何のロッシーhtmlも、ポップアップ・ブロッキングも持たないことを意味する。
【００５８】
これらのオブジェクトも圧縮すること（VCO）が出来るように、この情報で満たすことができるバケットが他に存在するか否かということが、今や問題である。VCO_ST_DEF_NLHNPBが、使用することができる他のバケット（25）であることがわかる。これは、それがデフレートであり、それが、ロッシーHTMLを有せず、そして、ポップアップ・ブロッキングセットも有しないという類似の特徴を有する。唯一の違いは、チャンキングがセットされないことである。しかし、コンプレッサは、それがオブジェクトを圧縮した時、チャンキング・ビットをセットしなかった。我々は、またこのバケットも使用することができる。このようにして、もし我々が、HTTP/1.0リクエスト（チャンキング無し）を得れば、我々は、依然としてリクエストを提供することができる。いくつかの場合には、複数の組合せもありうる。この方法でVCOは、製品から最大の利益を得ることができる。これと同じ実施は、他のタイプのオブジェクトに対しても行うことができる。
【００５９】
* static void vco_copy_cidx_new (int wi, int cidx, int cidx_new)
これは、旧インデックス（cidx）から新しいインデックス（cidx_new）へバケット情報をコピーするユーティリティ関数のうちの一つである。これは、他のバケット（s）に対してパラメータを設定するためにも、vco_set_other_bucketsにより使用される。
【００６０】
* static void print_compression_info (HdCompInfo *comp_info)
これは、読み取りを容易にするために、圧縮情報のコンテンツを印刷するユーティリティ・デバッグ関数の一つである。#define VCO_PRINT 9//chnge to 100によりオフとなることが、制御される。
【００６１】
外部関数
* int vco_process_http_request（int wi）
この関数は、クライアントのないまたはクライアント・ユーザから入ってきたHTTPリクエストに対して要求される。接続が確立し、かつ、我々が、リクエストをセットアウトする必要がある場合には、我々はこの関数を呼ぶ。この関数の目的は、我々がリクエストをどのように処理しようとするかについて決定することである。我々は、VCOまたはプリフェッチか否かに関わりなくコンプレッサ・フラグをセットする必要がある。
【００６２】
出力：
-1: エラーがあり、そしてリクエストは処理することができない
0: OK
1:拡張を加えるためにパーサを、再び呼ぶ必要がある。
【００６３】
それは、値をヒンフォ構造にセットする。それは、また、それがプリフェッチ・レコード・テーブル（VCOテーブル）を調べるのが、初めてであるか否かを決定し、そして、我々がこれをVCO URLリクエストに変換することが必要であるか否かも決定する。
【００６４】
* int vco_process_courl_request（int wi）
我々が、サーバからキャッシュ・プロクシ・ポートを介して来るキャッシュ・プロクシ・リクエストを処理したいときに、この関数は、呼ばれる。それは、拡張を解析して、それが使用することを必要とする圧縮情報を得る。このリクエストに対しては、それが、サーバに行こうとしているので、ボディのみが、圧縮されるべきである。プリフェッチの場合には、我々に対してリクエストをサーバに送らせた以前の接続から、我々はwiOldデータを得る可能性がある。この場合、我々は、これらの2つのリクエストを接続し、次いで、このプロセスは終了する。もし古いリクエストがアイドル状態でない場合、我々は、このリクエストをオリジナルURLに変換して、それを送る。
【００６５】
* int vco_set_compression_info（int wi）
コンプレッサが圧縮情報を有するときに、この関数は、呼び出される。それは、値をヒンフォ構造内にセットして、そして有効フラグをキャッシュ制御フラグ内にセットする。これにより、情報が利用できるようになっているということがVentSに示される。この関数の目的は、リクエストに対してバケットの圧縮情報を設定することである。もしオリジナル情報が、セットされていない場合、それは、オリジナルのタイプ、サイズおよびレベルをセットする。それは、次いで、それが興味を持つバケットを得、そしてcomp_flags、comp_control_flags等のパラメータに対して値を設定する。次いで、それは、前進し、そして同じ特徴を有することができる他のバケットをセットする。
【００６６】
* void  vco_get_request_capability（int wi）
この関数は、リクエストの能力を得るために使用される。これは、3つの方法により得られる：
1. サーバ構成：サーバは、セットされるいくつかのフラグを決定する。
2. クライアント能力
3. リクエスト能力
【００６７】
コンプレッサ・フラグは、上述したことに基づいて設定される。最初、我々は、それがどのようなリクエストであるか知らないので、我々は、complnfoに対するフィールドを未知に設定する。次いで、我々は、コンプレッサ・フラグをセットする必要がある。以下は、各々のフラグに対する概要である：
2007523400.tif 000019
2007523400.tif 000020
【００６８】
* int vco_get_comp_control_flags（int wi、intフラグ）
コンプレッサ・コントロール・フラグは、特定のパラメータに基づいて設定される。これらのパラメータは、以下の通りである。
1.  クライアントレス(Clientless)：これは、リクエストが、クライアントレスユーザ
からか、クライアントからかを我々に知らせる。
2.  VCO：これは、キャッシュされたオブジェクトが、VCOテーブル内で既に発見されて
いるか否かを我々に知らせる。
3.  プリフェッチ(Prefetch)：これは、リクエストがプリフェッチされたリクエストで
あるか否かを我々に知らせる。
4.  キャッシュ・プロクシ(CacheProxy)：これは、ポート8009上でサーバーから我々ま
で戻ってくるリクエストであり、そしてVCOリクエストである。
【００６９】
これらのパラメータに基づいて、我々は、我々がFORCE、COMP_HDRまたはCOMP_BODYフラグを使用したいか否かを決める。「No」はそれがセットされないことを意味する。「Yes」は、それがセットされることを意味する。「−」は、これが可能でないことを意味する。フラグは、VCOパラメータをセットすることを意図している。他のものは、構成パラメータによって見出される。
2007523400.tif 000021
【００７０】
もしリクエストが、ヘッドのリクエストであれば、これは、VCO_CC_HEADもセットする。もしリクエストが、プリフェッチ・リクエストであれば、それは、VCO_CC_PREFETCHフラグもセットする。
【００７１】
* int vco_http_process_courl_prefetch（int wi）
この関数の目的は、プリフェッチされるべきであるcourlを処理することである。一旦我々が、オリジナルプリフェッチ・リクエストを送り出し、そして応答が戻ってくると、我々は、圧縮ボディおよびオリジナル・ヘッダを保存する。次いで、我々は、COURLに対しこの呼び出しを要求する。キャッシュが、このオブジェクトを有する場合には、このプロセスは、終了する。さもないと、それは、輪になって、そして、CPURL（ポート8009）をVentSに送信する。次いで、CPURLは処理され、そして、2つのリクエストは、一緒に結ばれる。このようにして、キャッシュは、適切な方法でCPURLを得ることができる。
【００７２】
本発明が、本願明細書において好ましい実施例を参照して記載されているが、当業者は、これ以外の応用を、本発明の趣旨および範囲から逸脱することなく、本願明細書において記載されているものに置換することができることは、直ちに理解できるであろう。したがって、本発明は、添付の請求の範囲によってしか制限されるべきはない。
【図面の簡単な説明】
【００７３】
【図１】圧縮されたオブジェクトおよびプリフェッチ動作を用いない、オブジェクトに対するリクエスト・フローを示すブロック図である。
【図２】圧縮されたオブジェクトを用いないオブジェクトに対するリクエスト・フローを示すブロック図である。
【図３】本発明の第１実施例に従ったオブジェクトに対するリクエスト・フローを示すブロック図である。
【図４】本発明の第２実施形態に従ったオブジェクトに対するリクエスト・フローを示すブロック図である。
【図５】本発明の第３実施態様に従ってオブジェクトに対するリクエスト・フローを示すブロック図である。
【図６】リクエストのフローを記載するフロー図である。
【図７】プリフェッチ側のリクエスト・フローを記載するフロー図である。
【図８】COが存在しないときの、リクエストのフローを記載するフロー図である。
【図９】COが存在しないときの、リクエストのフローを記載するフロー図である。
【符号の説明】
【００７４】
１１  クライアント
１３  コンプレッサ
１５  ゲートウェイ
１７  サーバ
３１  ゲートウェイ
３３  オブジェクト
【図１】
2007523400.tif 000022
【図２】
2007523400.tif 000023
【図３】
2007523400.tif 000024
【図４】
2007523400.tif 000025
【図５】
2007523400.tif 000026
【図６】
2007523400.tif 000027
【図７】
2007523400.tif 000028
【図８】
2007523400.tif 000029
【図９】
2007523400.tif 000030