JP3665271B2 - パケットごとのハッシュテーブルを使用してネットワークパケットのデータを圧縮するための方法および装置 - Google Patents
パケットごとのハッシュテーブルを使用してネットワークパケットのデータを圧縮するための方法および装置 Download PDFInfo
- Publication number
- JP3665271B2 JP3665271B2 JP2001075336A JP2001075336A JP3665271B2 JP 3665271 B2 JP3665271 B2 JP 3665271B2 JP 2001075336 A JP2001075336 A JP 2001075336A JP 2001075336 A JP2001075336 A JP 2001075336A JP 3665271 B2 JP3665271 B2 JP 3665271B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- packets
- compression
- encoded
- hash table
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
Description
【０００１】
【発明の属する技術分野】
本発明は一般にデータ圧縮に関し、特に、パケットネットワーク内でデータの圧縮を向上させることに関する。
【０００２】
【従来の技術】
従来のデータ圧縮技法およびシステムは、デジタルデータのストリームを圧縮された符号ストリームに符号化し、圧縮された符号ストリームを対応する元のデータストリームに復号化して戻す。ストリームは典型的には元のデータストリームに含まれる記号より少ない数の符号から成るので、符号ストリームは「圧縮された」と呼ばれる。このような少ない符号はそれに対応して、元のデータより少ない量のメモリ内に有利に格納することができる。さらに、圧縮された符号ストリームはそれに対応して圧縮されない元のデータよりも短い時間で、たとえば、ワイヤード通信システム、ワイヤレス通信システム、または光ファイバ通信システムなどの通信システム内で送信できる。今日の通信ネットワークにおけるデータ送信および格納容量に対する需要は増大の一途をたどっている。したがって、データ圧縮はほとんどの現代の送信プロトコルおよび通信ネットワークで必要不可欠な役割を果たしている。
【０００３】
よく知られているように、データの圧縮で有用な２種類の圧縮技法は、いわゆる特殊目的圧縮および一般目的圧縮である。特殊目的圧縮技法は特別なタイプのデータを圧縮するために設計されたもので、比較的安価に実装できる場合が多い。たとえば、よく知られた特殊目的圧縮技法は、ランレングス符号化、ゼロ抑止符号化、ヌル圧縮符号化、およびパターン置換である。これらの技法は典型的には共通の特性および冗長度を有するデータを圧縮するという事実のために、これらの技法は一般的に、比較的小さい圧縮比を有する。圧縮比は、元のデータの長さと比較して圧縮された符号の長さの測定値であることが理解されるであろう。しかし、特殊目的圧縮技法は、より一般的な性質のデータ、すなわち、高い程度の共通の特性などを有さないデータの圧縮においては効果的でない傾向がある。
【０００４】
対照的に、一般目的圧縮技法は特に１つのタイプのデータを圧縮するために設計されたものではなく、実際の圧縮プロセスの間に異なるタイプのデータに適合されている場合が多い。もっともよく知られており有用な一般目的圧縮技法のいくつかは、Ｊ．ＺｉｖおよびＡ．Ｌｅｍｐｅｌによって開発され、当技術分野では「Ｌｅｍｐｅｌ−Ｚｉｖ符号化」と一般に呼ばれるアルゴリズムのグループから発している。特に、１９７７年５月のＺｉｖらによる「A Universal Algorithm for Sequential Data Compression」、ＩＥＥＥ Transactions on Information Theory，ＩＴ−２３（３）の３３７〜３４３ページ（一般的に「ＬＺ１」と名付けられたアルゴリズムを説明している）、および、１９７８年９月のＺｉｖらによる「Compression of Individual Sequences Via Variable-Rate Coding」、ＩＥＥＥ Transactions on Information Technology、ＩＴ−２４（５）の５３０〜５３６ページ（一般的に「ＬＺ２」と名付けられたアルゴリズムを説明する）は、あらゆる目的のために参照により本明細書に組み込まれている。ＬＺ１データ圧縮方式およびＬＺ２データ圧縮方式は当技術分野ではよく知られており、ここで詳細に論ずる必要はない。
【０００５】
簡単に言えば、ＬＺ１（本技術分野では「ＬＺ７７」と呼ばれ、知られることもある）データ圧縮プロセスは、文字の反復したシーケンスはそのシーケンスのより早い発生、すなわちマッチするシーケンスへの参照によって置き換えられるという原理に基づいている。たとえばポインタなどの参照は、典型的にはより早い発生の位置を示すことを含み、たとえば、反復されたシーケンスの開始からのバイトオフセット、および、繰り返される文字の数すなわちマッチレングスとして表現される。典型的には、従来のＬＺ１符号化によれば、参照は「＜オフセット、長さ＞」の対として表現される。対照的に、ＬＺ２（本技術分野では「ＬＺ７８」と呼ばれ、知られることもある）圧縮は、入力データの文字のストリームを分析し、圧縮の間に生成され、適応的に成長するルックアップ表または辞書に基づいて、符号化された値にする。すなわち、ＬＺ２ではＬＺ１符号化のように任意のバイトの境界と任意の長さの間にマッチを見い出さず、その代わりに、辞書のワードがソースのストリングにマッチしている時、新しいワードはマッチしたワードおよびそれに続くソースストリングバイトから成る辞書に追加される。ＬＺ２符号化によれば、マッチは辞書内のワードへのポインタまたは索引として符号化される。
【０００６】
上記のように、当技術分野にはＬＺ１アルゴリズムおよびＬＺ２アルゴリズムによって具体化された基本的な原理の上に引きだされた圧縮方式が十分にある。たとえば、Ｔｅｒｒｙ Ａ．Ｗｅｌｃｈ（１９８４年６月のＩＥＥＥ Computer、８〜１９ページにある、Ｔ．Ａ．Ｗｅｌｃｈ「A Technique for High Performance Data Compression」および、１９８５年１２月１０日にＷｅｌｃｈに対して発行された米国特許第４，５５８，３０２号を参照のこと。各々はあらゆる目的のために参照により組み込まれている）は、後にＬＺ２符号化プロセスをよく知られた「Ｌｅｍｐｅｌ−Ｚｉｖ−Ｗｅｌｃｈ」（「ＬＺＷ」）圧縮プロセスに改良した。ＬＺ２圧縮技法およびＬＺＷ圧縮技法はどちらも、入力文字のストリングを固定長の符号にマッピングするいわゆるストリング表を生成し使用することに基づいている。具体的には、これらの圧縮技法は、文字ストリームを連続的に検索し、遭遇した記号のシーケンスが、表、すなわち辞書の中に前もって格納されている、対応するもっとも長いストリングにマッチすることに基づいて符号を生成することによって、データ文字のストリームを符号の圧縮されたストリームに圧縮する。各マッチが作成され符号記号が生成されると、プロセスはまた、データストリーム内でマッチしたシーケンスとそのデータストリームで遭遇した次の文字記号を含む、新しいストリングエントリを辞書に格納する。
【０００７】
上記で説明されたように、Ｌｅｍｐｅｌ−Ｚｉｖ符号化の本質は、元のデータストリーム、たとえば送信されるべき文書の中で反復されたストリングおよびサブストリングを発見することであることが理解されよう。圧縮された文書内では反復したフレーズはポインタによって置き換えられ、これらが元のデータストリーム、たとえば文書内で以前に発生した場所を示す。このように、この方法で圧縮されたデータ、たとえばテキストの復号化では、ポインタを、それが指し示すすでに復号化されたテキストで置き換えることだけを必要とする。よく知られているように、Ｌｅｍｐｅｌ−Ｚｉｖ符号化を使用する時の主な設計上の考慮点の１つは、ポインタがどれくらい遠くまで戻ることができるかについて制限を設定するかどうか、その制限はどのようなものにするかを決定することである。Ｌｅｍｐｅｌ−Ｚｉｖ符号化のさらなる設計上の考慮点は、所望の限界内のどのサブストリングがポインタのターゲットになる可能性があるかを含む。つまり、より早いテキストへのポインタの到達は制限されない、すなわちいわゆる成長ウィンドウである場合もあり、または前の「Ｎ」文字の固定された大きさのウィンドウに制限される場合もあり、ここでＮは典型的には数千文字の範囲、たとえば３キロバイトである。この符号化によれば、ストリングの反復が発見され圧縮されるのは、これらが両方ともそのウィンドウ内に現れた場合のみである。このようなＬｅｍｐｅｌ−Ｚｉｖ符号化設計の選択に関して行われる考慮は、速度、メモリ要件、および圧縮比の間で妥協を意味することが理解されるであろう。
【０００８】
圧縮はネットワーク効率を改善する際の重要な考慮点である。たとえば、使用可能な計算のためのリソース、すなわちデータ送信要件が使用可能なネットワーク帯域幅に比べて大きい場合、ネットワーク上で送信する前にデータパケットを圧縮するのがもっとも有利である。もちろん、実際の圧縮方式は速度および全体的な圧縮という点で慎重に選択しなければならない。すなわち、遅すぎる圧縮方式はネットワークの性能を下げ、不十分な圧縮方式は任意の潜在的な送信ゲインを制限することになる。
【０００９】
さらにネットワーク効率問題を複雑にするのは、多くのパケットネットワークはもともと信頼できないという事実である。すなわち、現在のよく知られたパケットネットワーク、たとえばインターネットは、ネットワークを介して送信されているパケットを日常的に落とすかまたは順序を入れ換えており、これによってデータ送信エラーを引き起こしている。たとえば、圧縮方式がパケット間に所定の依存性を導入し、ネットワークがその後そのようなパケットを落としたり順序を入れ換えたりした場合、パケット間の相互依存性のために前のパケットが失われた場合、受信者が特定のパケットを解凍できなくなる場合がある。そこで、所定のよく知られた手法が使用されてこのような問題を緩和している。（１）ネットワークの信頼性を改良し、これによってインターネットの場合、より信頼できるエンドツーエンド移送レイヤサービス、たとえばよく知られた伝送制御プロトコル（「ＴＣＰ」）が適用でき、移送レベルでパケットを圧縮する。（２）ステートレス圧縮を使用し、各パケットが独立して圧縮されこれによって各パケットが受信側で解凍できるようにする。および（３）ストリーミング圧縮は信頼できる送達を仮定し、この仮定が破られた時にリセット機構を使用する。具体的にはパケットが失われた時、受信側は圧縮がリセットされるまで後に続く各パケットを放棄する。リセットの後、その後のパケットは前のパケットに依存せず、圧縮は通常通りに再開できる。２種類のよく知られたストリーミングタイプの圧縮技法はポイントツーポイントプロトコル（「ＰＰＰ」）の圧縮制御プロトコル、およびユーザデータグラムプロトコル（「ＵＤＰ」）パケットのために使用されているＩＰヘッダ圧縮プロトコルである。
【００１０】
上記のパケット圧縮方式はパケットの相互依存性から生じる問題を緩和するために有用だが、このような方式はある別の複雑さを提供する。たとえば、移送レベルでパケットを圧縮することはエンドツーエンドの使用を必要とし、典型的には送信の間アプリケーションによる所定のレベルの協力を必要とする。同様に、ステートレス圧縮は一定の強固さを提供するが、ステートレス圧縮のパケット独立属性は、このような圧縮は単一のパケット内でデータを検証するという事実のため、実現される圧縮比を下げる。したがってたとえばこの圧縮技法は、隣接するパケットのネットワークヘッダ内に典型的に見いだされる大量の冗長度を除去することはできない。さらに、ストリーミング圧縮はより大きな圧縮比を提供するが、これらの圧縮方式は、１つのパケットがネットワーク内で失われると、それによって受信器がいくつかの他のパケットを失うという点で、パケットの損失という効果を増幅する。信頼性の低いネットワーク、たとえばインターネットについては、このパケット効果の増幅はストリーミング圧縮を使用する効用を減らす。
【００１１】
【発明が解決しようとする課題】
したがって、従来の圧縮方式の有害な効果なしに、より大きな強固さおよび増大された圧縮比を提供する圧縮技法に対するニーズが存在する。
【００１２】
【課題を解決するための手段】
本発明の一態様は、パケット間の圧縮を可能にし、これによってたとえばパケット損失を増幅する効果など先行の圧縮方式の有害な効果なしに、より大きな強固さと増大した圧縮比を達成する、パケットを圧縮するための方法および装置に関する。具体的には、本発明の一態様では、可変長符号化が各パケットについて別のハッシュテーブルを維持することと同時に使用される。本発明の好ましい実施形態によれば、可変長符号化はマッチレングス、オフセットおよびリテラルを使用する。このように、すべてのフレーズは、長さがゼロのマッチで符号化されているリテラルを有する（訳注：つまり符号化されたリテラルを有さない）マッチレングスで始まり、ついでリテラルの符号化が続く。好ましい実施形態によれば、長さがゼロではない最小のマッチは例としては３バイトであり、最大マッチは特定のパケットサイズによって限定される。
【００１３】
さらに、本発明の別の態様によれば、パケットごとのハッシュテーブルはそのパケット内の特定のバイトストリングを示すが、任意の他のパケット内（単数または複数）のデータは示さない。すなわち、本発明は各パケットに関してそれぞれ個別のハッシュテーブルを生成および維持し、ここでこのようなハッシュテーブルは任意の他のパケットからは独立して構築される。例として、本発明の一実施形態によれば、パケットに関するそれぞれのハッシュテーブルは、その特定のパケットが圧縮される時に構築される。本発明のさらなる実施形態によれば、パケットに関するそれぞれのハッシュテーブルは圧縮の前または後に構築される。このように、それぞれのハッシュテーブルは特定のパケットで符号化される。本発明の一態様によれば、パケットに関するそれぞれのハッシュテーブルは全パケットの中のデータを個別のサブストリングの関数として示す。例として、本発明の好ましい一実施形態によれば、このようなサブストリングは長さが３バイトである。したがって、特定のパケットのバイトサイズは、そのパケットに関してそれぞれのハッシュテーブルの中で示されるバイトストリングの数を決定することになる。このように、パケットごとのハッシュテーブルを使用することは、パケット全体の効率的で強固な圧縮を提供する。
【００１４】
すなわち、各パケットのハッシュテーブルはその特定のパケット内のデータにのみ依存しているので、パケットの恣意的な組に関する有効なインデックスは対応するハッシュテーブルを使用して作成できる。したがって、好ましい実施形態によれば、ストリングの検索は現在のパケットに関するハッシュテーブルのクエリによって実行され、その後にもっとも最近送信されたパケットから始まる可変履歴状態内のパケットの各々に関するハッシュテーブルが続く。好ましい実施形態のパケットごとのハッシュテーブルはまた、無効な入力によって終了した単独にリンクされたオフセットチェーンを維持し、ハッシュテーブルに関する有効なオフセット範囲を変更することによって（表全体を消去することによってではなく）ハッシュテーブルをリサイクルすることが理解されよう。さらに、圧縮レベルパラメータ、たとえば８ストリングを使用して、マッチを検索している間にチェックされる最大数を決定することが理解されよう。
【００１５】
本発明の一態様によれば、有利には増大された強固さとより大きな圧縮比は種々の圧縮方法で達成できる。
【００１６】
【発明の実施の形態】
発明者らの同時係属で、本譲受人に譲渡され，同じ日付に提出された出願番号＿＿＿、代理人整理番号Ｓ．Ｍ．Ｄｏｒｗａｒｄ９−２（またはここでは利便のため、「承認された圧縮に関する出願」と呼ばれる）で詳細に示されたように、発明者らは、選択履歴状態をパケットの関数として使用してネットワーク上で送信することによって、エレガントな圧縮ツールの提供が達成され、これによって、強化されたデータ圧縮が実現できることに気づいた。本発明の一態様によれば、いわゆる確認ベクトルの関数として決定される選択履歴状態が使用される。さらに、本発明の一態様によれば、確認ベクトルは通信チャネル上の以前の送信で正常に受信されたパケットの識別に関する情報を含む。すなわち、本発明の一態様によれば、パケット履歴状態はそれぞれのパケットに関連づけられた選択履歴状態である。このように、通信チャネルの第１のサイド、たとえば送信器サイドまたは送信者サイドは、どのパケットが通信チャネルの第２のサイド、たとえば受信器サイドまたは受信者サイドによって正常に受信されたかに関する所定の情報を提供され、それを認識する。また解凍装置も選択履歴を提供され、それを認識し、送信者から送信された、圧縮されたパケットの効率的な解凍を可能にする。すなわち解凍は、パケット圧縮の間、履歴、すなわち選択履歴状態として使用されたパケットの関数として発生する。このように、本発明の選択履歴状態および認識態様を通じて圧縮装置および解凍装置（通信チャネルのいずれかのサイド）は協力して機能し、通信チャネル上で改良された圧縮を達成する。
【００１７】
承認された圧縮に関する出願の中で本発明の種々の態様の圧縮を使用することによって達成された圧縮結果、たとえば帯域幅比は、特により高い帯域幅ではより小さいパケットについてはいくぶん減少される。これは部分的には使用されている実際の圧縮方式のためである。たとえば、よく知られたデフレート圧縮方式はより小さいパケットサイズについては比較的非効率的なフォーマットを使用している。具体的には、デフレート圧縮方式によれば、各パケットはよく知られた静的なホフマン符号化または動的なホフマン符号化のいずれかで圧縮される。このようなホフマン符号化は大きなファイルのオフライン圧縮には役に立つが、各データパケット内の必須のホフマン辞書を計算し送信することに関連する処理オーバーヘッドは、より小さなパケット、たとえばインターネット上で送信される典型的なデータパケットのリアルタイムな圧縮には高価すぎる。さらに、デフレートは1つのパケットを終了するために約8バイトの追加の処理オーバーヘッドを必要とし、これはさらにインターネットのような通信用途内の有用性に影響をあたえる。このようなホフマン符号および／または辞書を使用する他の圧縮方式、たとえばＬＺ７７も同じように影響を受けることが理解されよう。
【００１８】
したがって発明者らは以下により詳細に論じられるように、承認された圧縮に関する出願における本発明の態様およびその完全な利点は、従来の圧縮方式に伴う所定の処理オーバーヘッド問題を緩和する新規の圧縮フォーマット内でさらに実現されることに気づいた。具体的には、本発明の一態様によれば、可変長符号化が各パケットについて別のハッシュテーブルを維持することと同時に使用される。本発明の好ましい実施形態によれば、可変長符号化はマッチレングス、オフセットおよびリテラルを使用する。本発明の種々の態様をより詳細に論じその完全な理解を促進する前に、上記の同時係属の、本譲受人に譲渡された承認された圧縮に関する出願の所定の態様が次に示される。
【００１９】
本発明の一態様はパケット間の圧縮を可能にし、それによってたとえばパケット増幅の効果など先行の圧縮方式の有害な効果なしにより優れた強固さと増大した圧縮比を達成する、パケットを圧縮するための方法および装置を提供する。具体的には、いわゆる認識方式が特定の圧縮アルゴリズムと共に使用され、送信器、すなわち、送信者は圧縮アルゴリズムによって使用される履歴を正しく受信されたパケットに限定できる。好ましい実施形態では、履歴として使用されるパケットを識別するベクトルが圧縮パケット内に含まれ、これによって受信器は、パケットを解凍するために必要なパケット履歴状態を再構築できる。
【００２０】
図１はデータを圧縮および解凍するための例示的なシステム１００の構成図である。システム１００はとりわけ、たとえばいくつか名前を上げるとワイヤ、ワイヤレス、または光ファイバなどの送信媒体上で情報を送信および受信するために有用である。さらに、システム１００は別法としては、コンピュータのディスクドライブなどの磁気媒体またはＣＤ−ＲＯＭなどの光可読媒体に情報を記録したり、そこから情報を読み出すために有用である。本発明によって圧縮されたデータをたとえば磁気ディスクドライブなどの磁気媒体および、たとえばＣＤ−ＲＯＭなどの光可読媒体を含む記録可能な媒体上に記録することが可能である。図１では、たとえばテキストなどの入力データストリーム１０５は、入力データ符号器１１０に供給される。以下にさらに詳細に論じられるように、本発明の一態様によれば入力データ符号器１１０は可変履歴状態パケット間圧縮を適用することによって、入力データストリームを前処理し符号化する。この符号化プロセスに関する本発明の種々の態様は、特に図２に示された例示的な動作を参照しながら、以下にさらに詳細に説明される。
【００２１】
図１の例示的なシステム１００の議論に続き、本発明の一態様によって生成された符号化された入力データストリーム１１５は圧縮装置１２０に渡される。圧縮装置１２０は本発明の好ましい実施形態によれば、たとえばＬｅｍｐｅｌ−Ｚｉｖ圧縮などの圧縮方法を適用して、符号化された入力データストリーム１１５を圧縮されたデータ１２５に圧縮する。上記のように、本発明にしたがってここに説明された本発明の有利な態様を実現するために、符号化された入力データストリーム１１５を圧縮する際には任意のＬｅｍｐｅｌ−Ｚｉｖタイプの圧縮が効果的に使用できることに注意されたい。圧縮されたデータ１２５はついで、チャネル符号器１３０によって符号化され、チャネル符号化された情報１３５を生成する。チャネル符号化は圧縮された情報に情報を追加し、データ読み出しプロセスの中でエラーの検出および／または訂正を可能にすることが理解されよう。従来のチャネル符号化技法はよく知られたＲｅｅｄ Ｓｏｌｏｍｏｎ符号化を含み、Ｒｅｅｄ Ｓｏｌｏｍｏｎ符号化は一連の記号を符号化し、各記号は１つまたは複数のデータビットによって表される。これらの記号はついで、変調符号器１４０によって変調符号化され、変調符号器１４０は変調されたデータストリーム１４５を生成し、変調されたデータストリーム１４５は通信チャネルを介して送信されるかまたは媒体１５０上に記録されるチャネルシーケンスを定義する。
【００２２】
データストリームの送信または記録の間に、チャネル／媒体１５０の中にノイズと干渉がしばしば導入される。変調復号器１５５およびチャネル復号器１６０は変調されたデータストリーム１４５をノイズと共に受信し、よく知られた方法でチャネル符号器１３０の符号化プロセスおよび変調符号器１４０の符号化プロセスをそれぞれ反対にする。チャネル復号器１６０からのデータストリームは、圧縮装置１２０によって生成された圧縮されたデータ１２５に対応する。本発明によればこのデータストリームはついで、解凍装置１６５によって解凍され、データ復号器１７０によって復号化され、出力データストリーム１７５を生成し、これは図４に関して以下に詳細に説明される。
【００２３】
承認された圧縮に関する出願における本発明の種々の態様は、改良された圧縮の強固さと圧縮比を実現することに関する。図２は、上記のように本発明の一態様による、図１の例示的なシステム内で有用な、データを圧縮するための例示的な動作２００のフローチャートを示す。具体的には、入力データストリームが受信され、正常に受信されたパケットが確認される（図２のブロック２１０を参照のこと）。正常に受信されたパケットを検査することにより、特定の確認ベクトルの関数として１つのパケット履歴状態を識別することを可能とする（図２のブロック２２０を参照のこと）。本発明の好ましい実施形態によれば、パケット履歴状態はパケットの以前の組であり、その上に現在のパケットの圧縮が決定される。たとえば、Ｌｅｍｐｅｌ−Ｚｉｖ７７圧縮に関しては、履歴状態はこのようなＬｅｍｐｅｌ−Ｚｉｖ圧縮で使用されているいわゆる辞書に直接相関する。面白いことに、上記のステートレス圧縮とネットワークパケットのストリーミング圧縮の間の主な違いは、各方式が使用する特定の履歴状態である。すなわち、ステートレス圧縮は履歴状態を使用しないが、ストリーミング圧縮は任意の前のパケットを履歴として許可する。このような違いは、本発明の原理に関して依然として有効である。
【００２４】
具体的には、本発明の好ましい実施形態によれば、パケット履歴状態は、たとえば受信器サイドまたは受信者によって通信チャネル上で正常に受信された特定のパケットに関して選択履歴状態である。受信者は選択履歴を提供され認識しているので、送信された圧縮されたパケットの効率的な解凍が可能になる。有利には、本発明のこの態様によれば、選択パケット間履歴状態の使用は、固有のパケット損失を被る、以前のストリーミング圧縮方式に比べて圧縮の強固さおよび圧縮比を向上させる。
【００２５】
上に説明したように選択パケット履歴状態を識別した後に、このような履歴状態が使用されて、送信者からの送信を待つパケットへ所定の情報を符号化する。具体的には、本発明の好ましい実施形態によれば、個別のパケットはそこに関連づけられたそれぞれのパケット履歴状態の関数として符号化される（図２のブロック２３０を参照のこと）。本発明の一実施形態によれば各パケットには、例として、そのパケットに関連づけられたそれぞれのパケット履歴を識別する履歴ベクトルを含むヘッダが、接頭辞として付けられている。注意を簡単に図３に向けると、例示的なパケットストリーム３００は図２の、例示的な動作によって圧縮されているように示されている。図３の実施形態によれば、パケットヘッダはシーケンス番号および確認ベクトルなどの追加の項目を含む。すなわち、本発明のさらなる実施形態によれば、前記の確認ベクトルはパケットヘッダの一部として送信される場合がある。当業者であれば理解されるように、確認ベクトルが符号化されたパケットとは別に送信されるか（上に論じられたように）、またはパケットヘッダの一部として送信されるかの決定は、設計上の選択の問題であり、どちらのコンテキストにも本発明の原理は等しく適用される。たとえば、確認ベクトルはいわゆる「便乗」技法を使用して送信者に送信することができ、ここでは受信者から送信者へ逆の方向のデータストリームが存在する。
【００２６】
たとえば、パケットストリーム３００は、一連のパケットを含む（たとえば、図３にそれぞれパケット３０５〜３１５として示されたようなパケット１からパケットｎ）。さらに、各パケットはヘッダを含む（たとえば、図３にそれぞれヘッダ３２０〜３３０として示されたＨ1からＨn）。さらに、例として、ヘッダ３２０は符号化されたシーケンス番号３３５、履歴ベクトル３４０および確認ベクトル３４５を含んでより詳細に示されている。
【００２７】
好ましい実施形態によれば、たとえばシーケンス番号３３５などのシーケンス番号は送信者および受信者の双方によって使用されて、本発明の原理によって圧縮されたパケットを識別する。シーケンス番号を符号化するために使用されるビットの数は十分に多く、全ネットワークを通り抜けるために必要な最大の時間の間、いわゆる「折り返し」のよく知られた有害な結果を避ける必要がある。例として、シーケンス番号３３５は長さが２４ビットとして示されている。
【００２８】
さらに、好ましい実施形態によれば、たとえば履歴ベクトル３４０などの履歴ベクトルは圧縮のために使用された以前の一組のパケット、すなわち選択履歴状態を記述する。履歴決定のために認識パケットを使用する本発明の好ましい実施形態に関しては、パケットが送信される時間とそのパケットが履歴として使用される時間の間に、ネットワークの往復時間に関して時間遅延が発生する場合がある。このように、本発明の好ましい一実施形態によれば、オフセットがパケットのシーケンス番号から除算されてもっとも最近の履歴パケットのシーケンス番号を確立するように、履歴ベクトルがオフセットおよびビットマスクを使用して符号化される。ビットマスクはこのもっとも最近の履歴パケットのすぐ前の、追加の履歴パケットを識別する。例としては、ヘッダ３２０に関して、履歴ベクトル３４０は８ビットのオフセットおよび８ビットのマスクを含み、これによって最後の２６３内で、最大でも９つの連続パケットに履歴状態を限定する。
【００２９】
上記のように、図３の実施形態のパケットヘッダはまた、たとえば確認ベクトル３４５などの確認ベクトルを含み、一組の最近受信されたパケットを記述する。確認ベクトルは少なくとも、もっとも最近受信されたパケットのシーケンス番号および、そのすぐ前のパケットの状態を記述するビットマスクを含む。例としては、確認ベクトル３４５は長さが３２ビットで、シーケンス番号のために２４ビットをカバーし、関連づけられたマスクのために８ビットをカバーする。
【００３０】
図２に注意を戻してみると、本発明の原理によってパケットをそれぞれのパケット履歴状態の関数として符号化すると（図２のブロック２３０を参照のこと）、これらのパケットはさらなる圧縮の準備ができる。上記に詳細に説明したように、本発明の利点は、これが幅広い既存の圧縮技法と共に適用できることである。たとえば、以下に詳細に説明するように、本発明の原理は、よく知られたＬＺ７７圧縮方式またはよく知られた「デフレート」圧縮方式が適用されているパケットストリームの圧縮を向上させる。したがって、選択された圧縮方式を符号化されたパケットに適用すると（図２のブロック２４０を参照のこと）、圧縮されたパケットは送信の準備ができる（図２のブロック２５０を参照のこと）。
【００３１】
発明者らは、本発明の一態様によれば、選択履歴状態をパケットの関数として使用してネットワーク上を送信することによって、エレガントな圧縮ツールの提供が達成され、これによって強化されたデータ圧縮が実現されることに気づいた。すなわち、本発明の一態様によれば、それぞれのパケットに関連づけられたパケット履歴状態は、送信サイド、すなわち送信者が、受信器サイドすなわち受信者によって正常に受信されたパケットに関する所定の情報を提供され認識しているという点で、選択履歴状態である。同様に、受信器サイドはまたこのようなパケットに関連づけられた選択履歴状態を提供され認識しており、送信者からの圧縮されたパケットの効率的な解凍を可能にする。このように、本発明の選択履歴状態および認識態様を通じて、送信者および受信者は協力して機能して、通信チャネル上で向上した圧縮を達成する。
【００３２】
具体的には、本発明の一態様によれば、確認ベクトルは特定のアルゴリズムと共に使用され、送信器、すなわち送信者は圧縮アルゴリズムによって使用される履歴を正しく受信されたパケットに限定できる。したがって、本発明の一実施形態によれば、履歴として使用されるパケットを識別するベクトルは圧縮されたパケット内に含まれ、それによって、パケットを解凍するために必要なパケット履歴状態を受信者が再構築することが可能になる。本発明のさらなる実施形態によれば、確認ベクトルは圧縮されたパケットとは別に送信される。さらに、この例示的な実施形態は明瞭に説明するために単一の通信チャネル配置を論じているが、本発明の原理は多数の通信チャネル配置および構成にも同様に適用可能であることが理解されるであろう。有利には、本発明のこの態様によれば、選択履歴状態の使用は、パケット損失という固有の妥協を被る以前のストリーミング圧縮方式に比べて、圧縮の強固さおよび圧縮比を改良する。
【００３３】
図４は承認された圧縮に関する出願の発明のさらなる態様による、データを解凍するための例示的な動作４００のフローチャートを示す。具体的には、受信されたパケットの圧縮されたストリームから（図４のブロック４１０を参照のこと）履歴ベクトルがパケットごとに抽出される（図４のブロック４２０を参照のこと）。このように、パケットに関連づけられたそれぞれのパケット履歴状態は、履歴ベクトルの関数として決定される。例として、次の疑似コードは、本発明の一実施形態によるこれらの項目の抽出を記述している。
【００３４】
当業者であれば上記に説明された疑似コードを使用して種々のプログラム、たとえば、よく知られたＣプログラミング言語のコンピュータプログラムを開発して、本発明を実装するためのプロセッサ内で実行できることが理解されよう。履歴ベクトルの抽出から、解凍されているパケットのそれぞれのパケット履歴状態が識別される（図４のブロック４３０を参照のこと）。本発明のさらなる実施形態によれば、抽出はまた、確認ベクトルおよびシーケンス番号をパケットヘッダから抽出することを含む場合がある。本発明の好ましい実施形態によれば、現在のパケットの解凍はそれぞれの履歴状態の関数として行うことができる（図４のブロック４４０を参照のこと）。こうして、現在圧縮されていないパケットは、それぞれの解凍装置、たとえば特定の通信チャネルの受信サイドの解凍装置の、現在受信されたパケット状態に追加され（図４のブロック４５０を参照のこと）、これによって受信されたパケットの組を更新する。最後に、現在のパケットを解凍した後、確認ベクトルが構築され、送信者に送信されて戻される（図４のブロック４６０を参照のこと）。先に説明したように、本発明の一態様によれば、確認ベクトルは一組の最近受信されたパケットを記述し、送信者によって使用されて選択履歴状態と共に今後のパケットを圧縮する。
【００３５】
発明者らは、上記のように、承認された圧縮に関する出願における本発明の態様およびその利点は、新しい符号化技法および圧縮フォーマットでさらに実現されることに気づいた。このような発明的な圧縮フォーマットおよび関連づけられた符号化が本発明の主題である。
【００３６】
所定のよく知られた圧縮方式に関しては、重要な実装の特性はマッチを検出することである。典型的には、マッチは圧縮された現在のパケットの一部の中か、履歴状態を作る任意のパケットの中に見い出される。たとえば、デフレートのＺｌｉｂ実装（上記に論じた）は、単一のハッシュテーブルを使用してマッチを検索し、これはたとえばストリーミング圧縮と共に使用されると許容できる結果を提供する。対照的に、また有利に、本発明は各パケットについて別のハッシュテーブルを生成し維持する。具体的には、図５は本発明の一態様によってデータを圧縮するための例示的な動作５００のフローチャートを示す。一組の入力データから（図５のブロック５１０を参照のこと）、各パケットについて別のハッシュテーブルが生成され維持される（図５のブロック５２０を参照のこと）。すなわち、本発明は各パケットについてそれぞれ別のハッシュテーブルを生成し維持して、このようなハッシュテーブルは別のパケットの内容から独立して構築される。本発明の好ましい一実施形態によれば、特定のハッシュテーブルはパケットが圧縮される時にそのそれぞれのパケットで構築される。先に説明したように、本発明のさらなる実施形態によれば、パケットに関するそれぞれのハッシュテーブルは圧縮の前または圧縮の後に構築される。
【００３７】
したがって、本発明の好ましい実施形態によれば、個別のパケットは、パケットの履歴状態の中でそのパケットに関するそれぞれのハッシュテーブルに関して符号化される（図５のブロック５３０を参照のこと）。すなわち、特定のパケット「Ｐ」の符号化は、パケット履歴状態を定義する関連づけられたパケットの組「Ｓ」を使用する。本発明の一態様によれば、Ｓの中の各パケットはそこに関連づけられたそれぞれのハッシュテーブルを有する。したがって本発明の一態様によれば、特定のパケットＰの符号化は、Ｓの中のそのパケットに関するそれぞれのハッシュテーブルに関して実行される。本発明の一態様によれば、パケットに関するそれぞれのハッシュテーブルは、全パケット内のデータを個別のサブストリングの関数として示す。このように、Ｐの符号化はＳ内のパケットに関連づけられたハッシュテーブルの中のＰから一連のサブストリングを探し出すことを含む。例としては、本発明の好ましい実施形態によれば、このようなサブストリングは長さが３バイトである。したがって、特定のパケットの全体のバイトサイズは、そのパケットに関するそれぞれのハッシュテーブルの中で示されるバイトストリングの数を決定する。このように、パケットごとのハッシュテーブルと、可変履歴状態パケット間圧縮を共に使用することは、パケット全体の効率的で強固な圧縮を提供する。
【００３８】
具体的には、本発明の一態様によれば、可変長符号化と、各パケットに関する別のハッシュテーブルを維持することが共に使用される。本発明の好ましい実施形態によれば、可変長符号化は、マッチレングス、オフセットおよびリテラルに関して使用される。マッチレングスは、すべてのフレーズはマッチレングスで始まり、リテラルはゼロ長さのマッチで符号化されており、ついでリテラルの符号化が続くように、符号化される（図５のブロック５４０を参照のこと）。好ましい実施形態では、もっとも小さい非ゼロのマッチレングスは、例としては３バイトであり、最大のマッチは特定のパケットサイズによって限定される。例として、下の表１は好ましい実施形態による特定のマッチレングスの符号化を示す。
【表１】
【００３９】
さらに、本発明の好ましい実施形態によれば、リテラルは予想方式を使用して符号化される（図５のブロック５５０を参照のこと）。（ａ）デフォルトの８ビットリテラル符号化が適用される。これは、（２）１つの行の中の４つのリテラルが３２から１２７の範囲内にあり（３２および１２７を含む）、可変長符号化が範囲の外側にあるリテラルが符号化されるまで使用される場合を除く。桁が一番小さい７つのビットが、指定された範囲内の値について発せられ、（３）他のリテラルは番号、モジュロ２５６に６４ビットを加えることによって符号化される。その結果の数字が９６未満の場合は９ビットで符号化され、９６以上の場合は１０ビットで符号化される。
【００４０】
本発明の好ましい実施形態によれば、マッチオフセットはマッチするフレーズともっとも最近符号化された入力バイトの間の距離として定義され符号化される（図５のブロック５６０を参照のこと）。オフセットは例としては１４ビットであり、２つの断片、すなわち（１）範囲、および（２）その範囲内の位置に符号化される。ビット数を決定する範囲は位置を符号化するために使用され、より少ないビットはより近いオフセットを符号化するために使用される。例としては、下の表２は好ましい実施形態によるマッチオフセットの符号化を示す。
【表２】
【００４１】
本発明の好ましい実施形態によれば、パケットごとのハッシュテーブルはそのパケット内のバイトストリングを示すが、任意の他のパケット（単数または複数）の中のデータは示さない。したがって、各パケットのハッシュテーブルはその特定のパケット内のデータのみに依存するので、任意のパケットの組に関する有効なインデックスは対応するハッシュテーブルを使用して作成できる。すなわち、好ましい実施形態によれば、ストリングの検索は現在のパケットに関するハッシュテーブルのクエリで実行でき、最初はもっとも最近送信されたパケットである、可変履歴状態内のパケットの各々に関するハッシュテーブルが続く。好ましい実施形態のパケットごとのハッシュテーブルはまた、無効なエントリによって終了した単一のリンクされたオフセットチェーンを維持し、そのハッシュテーブルに関して有効なオフセット範囲を変更することによってハッシュテーブルをリサイクルする（テーブル全体を消去することによってではない）ことが理解されよう。さらに、たとえば８ストリングの圧縮レベルパラメータを使用して、マッチを検索している間にチェックされるストリングの最大数を決定することが理解されよう。圧縮レベルパラメータは圧縮の間に使用される全体の計算レベルを決定するためのインジケータであり、レベルがより高ければデータを圧縮する再に実行される計算がより多いことが理解されよう。
【００４２】
本発明の種々の態様および利点をさらに示すために、本発明の原理が先に論じられたよく知られたｚｌｉｂデフレート圧縮との比較のコンテキストで適用された。具体的には、図６は１６００バイトおよび１２５バイトのパケットサイズについての、それぞれの帯域幅比シミュレーションの結果６００および６１０を示す。帯域幅比シミュレーションの結果６００および６１０は、２つの異なる圧縮レベル設定に関する結果を含む。すなわち、結果６２０および６４０は、圧縮レベルパラメータ６における２つの圧縮方式を比較し、結果６３０および６５０は、圧縮設定が１における２つの圧縮方式を比較する。帯域幅比シミュレーションの結果６００および６１０の検討から理解されるように、本発明の原理によって達成される圧縮は全体として（すなわち、「ｔｈｗａｃｋ−６」、結果６４０を参照のこと、および「ｔｈｗａｃｋ−１」、結果６５０を参照のこと）デフレートの圧縮（すなわち、「ｚｌｉｂ−６」、結果６２０を参照のこと、および「ｚｌｉｂ−１」、結果６３０を参照のこと）より優れており、より小さいパケットサイズの圧縮という点では明らかに優れている。
【００４３】
本発明の種々の態様は、これらの方法を実行するための方法および装置の形で具体化できる。本発明はまた、フロッピディスケット、ＣＤ−ＲＯＭ、ハードドライブまたは任意のマシン可読記憶媒体などの有形メディア内で具体化されるプログラムコードの形で具体化でき、ここでプログラムコードがコンピュータなどのマシン内にロードされそのマシンによって実行されると、そのマシンは本発明を実行するための装置となる。本発明はまたたとえば、マシンにロードされるおよび／またはマシンによって実行されるか、または光ファイバまたは電磁放射線を介して電気ワイヤリングまたはケーブリング上などなんらかの送信媒体上を送信される記憶媒体内のプログラムコードの形で具体化することもでき、この場合、プログラムコードがコンピュータなどのマシン内にロードされそのマシンによって実行されると、そのマシンは本発明を実行するための装置となる。汎用プロセッサ上で実装される時、プログラムコードセグメントはプロセッサと結びついて特定の論理回路と類似の動作を行う独自のデバイスを提供する。
【００４４】
前記は本発明の原理を示したに過ぎない。したがって、当業者であればここに明示的に説明されるかまたは示されてはいないが、本発明の原理を具体化しその精神および範囲内に含まれる種々の構成を工夫できることが理解されよう。さらに、ここに引用されたすべての例および条件付きの言葉は主に、教育上の目的のために特別に意図されたもので、読者が出願者によって与えられた本発明の原理および概念の理解して技法を促進することを助けるためのものであり、このような具体的に列挙された例および条件に限定されるものではないと理解されるべきである。さらに、本発明の原理、態様、実施形態、およびその具体的な例を列挙するすべての文章は、その構造的等価物および機能的等価物の両方を含むことが意図されている。さらに、このような等価物が現在知られている等価物および将来開発される等価物、すなわち、構造にかかわらず同じ機能を実行するために開発される任意の要素も含むことが意図されている。
【００４５】
したがってたとえば、当業者であれば本明細書の構成図は本発明の原理を具体化する例示的な回路を概念的に表していることが理解されるであろう。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コード、プログラムコードなどは、コンピュータ可読媒体内で実質的に表される種々のプロセスを示し、コンピュータ、マシン、またはプロセッサが明示的に示されていなくても、コンピュータ、マシン、プロセッサによって実行される。
【００４６】
この開示全体で、別段の記載のない限り、図の中の同様な要素、ブロック、構成要素、または部分は、同じ参照指示によって示されている。
【図面の簡単な説明】
【図１】データを圧縮および解凍するための例示的なシステムの構成図である。
【図２】本発明の例示的な実施形態による、図１の例示的なシステムで有用な、データを圧縮するための例示的な動作を示すフローチャートである。
【図３】図２の例示的な動作によって圧縮された、例示的なパケットストリームを示す図である。
【図４】本発明の一実施形態により、図１の例示的なシステムで有用な、データを解凍するための例示的な動作を示すフローチャートである。
【図５】本発明の原理による、データを圧縮するための例示的な動作を示すフローチャートである。
【図６】本発明の種々の態様による、テキストファイルを圧縮した結果の比較を示す図である。
【符号の説明】
１００ システム
１０５ 入力データストリーム
１１０ 入力データ符号器
１１５ 符号化された入力データストリーム
１２０ 圧縮装置
１２５ 圧縮されたデータ
１３０ チャネル符号器
１３５ チャネル符号化された情報
１４０ 変調符号器
１４５ 変調されたデータストリーム
１５０ チャネル／媒体
１５５ 変調復号器
１６０ チャネル復号器
１６５ 解凍装置
１７０ データ復号器
２００ 動作
２１０、２２０、２３０、２４０、２５０ ブロック
３００ パケットストリーム
３０５〜３１５ パケット１〜パケットｎ
３２０〜３３０ ヘッダＨ1〜Ｈn
３３５ シーケンス番号
３４０、３４５ 履歴ベクトル
４００ フローチャート
４１０、４２０、４３０、４４０、４５０、４６０ ブロック
５００ 動作
５１０、５２０、５３０、５４０、５５０、５６０ ブロック
６００、６１０ 帯域幅比シミュレーションの結果
６２０、６３０、６４０、６５０ 結果
【発明の属する技術分野】
本発明は一般にデータ圧縮に関し、特に、パケットネットワーク内でデータの圧縮を向上させることに関する。
【０００２】
【従来の技術】
従来のデータ圧縮技法およびシステムは、デジタルデータのストリームを圧縮された符号ストリームに符号化し、圧縮された符号ストリームを対応する元のデータストリームに復号化して戻す。ストリームは典型的には元のデータストリームに含まれる記号より少ない数の符号から成るので、符号ストリームは「圧縮された」と呼ばれる。このような少ない符号はそれに対応して、元のデータより少ない量のメモリ内に有利に格納することができる。さらに、圧縮された符号ストリームはそれに対応して圧縮されない元のデータよりも短い時間で、たとえば、ワイヤード通信システム、ワイヤレス通信システム、または光ファイバ通信システムなどの通信システム内で送信できる。今日の通信ネットワークにおけるデータ送信および格納容量に対する需要は増大の一途をたどっている。したがって、データ圧縮はほとんどの現代の送信プロトコルおよび通信ネットワークで必要不可欠な役割を果たしている。
【０００３】
よく知られているように、データの圧縮で有用な２種類の圧縮技法は、いわゆる特殊目的圧縮および一般目的圧縮である。特殊目的圧縮技法は特別なタイプのデータを圧縮するために設計されたもので、比較的安価に実装できる場合が多い。たとえば、よく知られた特殊目的圧縮技法は、ランレングス符号化、ゼロ抑止符号化、ヌル圧縮符号化、およびパターン置換である。これらの技法は典型的には共通の特性および冗長度を有するデータを圧縮するという事実のために、これらの技法は一般的に、比較的小さい圧縮比を有する。圧縮比は、元のデータの長さと比較して圧縮された符号の長さの測定値であることが理解されるであろう。しかし、特殊目的圧縮技法は、より一般的な性質のデータ、すなわち、高い程度の共通の特性などを有さないデータの圧縮においては効果的でない傾向がある。
【０００４】
対照的に、一般目的圧縮技法は特に１つのタイプのデータを圧縮するために設計されたものではなく、実際の圧縮プロセスの間に異なるタイプのデータに適合されている場合が多い。もっともよく知られており有用な一般目的圧縮技法のいくつかは、Ｊ．ＺｉｖおよびＡ．Ｌｅｍｐｅｌによって開発され、当技術分野では「Ｌｅｍｐｅｌ−Ｚｉｖ符号化」と一般に呼ばれるアルゴリズムのグループから発している。特に、１９７７年５月のＺｉｖらによる「A Universal Algorithm for Sequential Data Compression」、ＩＥＥＥ Transactions on Information Theory，ＩＴ−２３（３）の３３７〜３４３ページ（一般的に「ＬＺ１」と名付けられたアルゴリズムを説明している）、および、１９７８年９月のＺｉｖらによる「Compression of Individual Sequences Via Variable-Rate Coding」、ＩＥＥＥ Transactions on Information Technology、ＩＴ−２４（５）の５３０〜５３６ページ（一般的に「ＬＺ２」と名付けられたアルゴリズムを説明する）は、あらゆる目的のために参照により本明細書に組み込まれている。ＬＺ１データ圧縮方式およびＬＺ２データ圧縮方式は当技術分野ではよく知られており、ここで詳細に論ずる必要はない。
【０００５】
簡単に言えば、ＬＺ１（本技術分野では「ＬＺ７７」と呼ばれ、知られることもある）データ圧縮プロセスは、文字の反復したシーケンスはそのシーケンスのより早い発生、すなわちマッチするシーケンスへの参照によって置き換えられるという原理に基づいている。たとえばポインタなどの参照は、典型的にはより早い発生の位置を示すことを含み、たとえば、反復されたシーケンスの開始からのバイトオフセット、および、繰り返される文字の数すなわちマッチレングスとして表現される。典型的には、従来のＬＺ１符号化によれば、参照は「＜オフセット、長さ＞」の対として表現される。対照的に、ＬＺ２（本技術分野では「ＬＺ７８」と呼ばれ、知られることもある）圧縮は、入力データの文字のストリームを分析し、圧縮の間に生成され、適応的に成長するルックアップ表または辞書に基づいて、符号化された値にする。すなわち、ＬＺ２ではＬＺ１符号化のように任意のバイトの境界と任意の長さの間にマッチを見い出さず、その代わりに、辞書のワードがソースのストリングにマッチしている時、新しいワードはマッチしたワードおよびそれに続くソースストリングバイトから成る辞書に追加される。ＬＺ２符号化によれば、マッチは辞書内のワードへのポインタまたは索引として符号化される。
【０００６】
上記のように、当技術分野にはＬＺ１アルゴリズムおよびＬＺ２アルゴリズムによって具体化された基本的な原理の上に引きだされた圧縮方式が十分にある。たとえば、Ｔｅｒｒｙ Ａ．Ｗｅｌｃｈ（１９８４年６月のＩＥＥＥ Computer、８〜１９ページにある、Ｔ．Ａ．Ｗｅｌｃｈ「A Technique for High Performance Data Compression」および、１９８５年１２月１０日にＷｅｌｃｈに対して発行された米国特許第４，５５８，３０２号を参照のこと。各々はあらゆる目的のために参照により組み込まれている）は、後にＬＺ２符号化プロセスをよく知られた「Ｌｅｍｐｅｌ−Ｚｉｖ−Ｗｅｌｃｈ」（「ＬＺＷ」）圧縮プロセスに改良した。ＬＺ２圧縮技法およびＬＺＷ圧縮技法はどちらも、入力文字のストリングを固定長の符号にマッピングするいわゆるストリング表を生成し使用することに基づいている。具体的には、これらの圧縮技法は、文字ストリームを連続的に検索し、遭遇した記号のシーケンスが、表、すなわち辞書の中に前もって格納されている、対応するもっとも長いストリングにマッチすることに基づいて符号を生成することによって、データ文字のストリームを符号の圧縮されたストリームに圧縮する。各マッチが作成され符号記号が生成されると、プロセスはまた、データストリーム内でマッチしたシーケンスとそのデータストリームで遭遇した次の文字記号を含む、新しいストリングエントリを辞書に格納する。
【０００７】
上記で説明されたように、Ｌｅｍｐｅｌ−Ｚｉｖ符号化の本質は、元のデータストリーム、たとえば送信されるべき文書の中で反復されたストリングおよびサブストリングを発見することであることが理解されよう。圧縮された文書内では反復したフレーズはポインタによって置き換えられ、これらが元のデータストリーム、たとえば文書内で以前に発生した場所を示す。このように、この方法で圧縮されたデータ、たとえばテキストの復号化では、ポインタを、それが指し示すすでに復号化されたテキストで置き換えることだけを必要とする。よく知られているように、Ｌｅｍｐｅｌ−Ｚｉｖ符号化を使用する時の主な設計上の考慮点の１つは、ポインタがどれくらい遠くまで戻ることができるかについて制限を設定するかどうか、その制限はどのようなものにするかを決定することである。Ｌｅｍｐｅｌ−Ｚｉｖ符号化のさらなる設計上の考慮点は、所望の限界内のどのサブストリングがポインタのターゲットになる可能性があるかを含む。つまり、より早いテキストへのポインタの到達は制限されない、すなわちいわゆる成長ウィンドウである場合もあり、または前の「Ｎ」文字の固定された大きさのウィンドウに制限される場合もあり、ここでＮは典型的には数千文字の範囲、たとえば３キロバイトである。この符号化によれば、ストリングの反復が発見され圧縮されるのは、これらが両方ともそのウィンドウ内に現れた場合のみである。このようなＬｅｍｐｅｌ−Ｚｉｖ符号化設計の選択に関して行われる考慮は、速度、メモリ要件、および圧縮比の間で妥協を意味することが理解されるであろう。
【０００８】
圧縮はネットワーク効率を改善する際の重要な考慮点である。たとえば、使用可能な計算のためのリソース、すなわちデータ送信要件が使用可能なネットワーク帯域幅に比べて大きい場合、ネットワーク上で送信する前にデータパケットを圧縮するのがもっとも有利である。もちろん、実際の圧縮方式は速度および全体的な圧縮という点で慎重に選択しなければならない。すなわち、遅すぎる圧縮方式はネットワークの性能を下げ、不十分な圧縮方式は任意の潜在的な送信ゲインを制限することになる。
【０００９】
さらにネットワーク効率問題を複雑にするのは、多くのパケットネットワークはもともと信頼できないという事実である。すなわち、現在のよく知られたパケットネットワーク、たとえばインターネットは、ネットワークを介して送信されているパケットを日常的に落とすかまたは順序を入れ換えており、これによってデータ送信エラーを引き起こしている。たとえば、圧縮方式がパケット間に所定の依存性を導入し、ネットワークがその後そのようなパケットを落としたり順序を入れ換えたりした場合、パケット間の相互依存性のために前のパケットが失われた場合、受信者が特定のパケットを解凍できなくなる場合がある。そこで、所定のよく知られた手法が使用されてこのような問題を緩和している。（１）ネットワークの信頼性を改良し、これによってインターネットの場合、より信頼できるエンドツーエンド移送レイヤサービス、たとえばよく知られた伝送制御プロトコル（「ＴＣＰ」）が適用でき、移送レベルでパケットを圧縮する。（２）ステートレス圧縮を使用し、各パケットが独立して圧縮されこれによって各パケットが受信側で解凍できるようにする。および（３）ストリーミング圧縮は信頼できる送達を仮定し、この仮定が破られた時にリセット機構を使用する。具体的にはパケットが失われた時、受信側は圧縮がリセットされるまで後に続く各パケットを放棄する。リセットの後、その後のパケットは前のパケットに依存せず、圧縮は通常通りに再開できる。２種類のよく知られたストリーミングタイプの圧縮技法はポイントツーポイントプロトコル（「ＰＰＰ」）の圧縮制御プロトコル、およびユーザデータグラムプロトコル（「ＵＤＰ」）パケットのために使用されているＩＰヘッダ圧縮プロトコルである。
【００１０】
上記のパケット圧縮方式はパケットの相互依存性から生じる問題を緩和するために有用だが、このような方式はある別の複雑さを提供する。たとえば、移送レベルでパケットを圧縮することはエンドツーエンドの使用を必要とし、典型的には送信の間アプリケーションによる所定のレベルの協力を必要とする。同様に、ステートレス圧縮は一定の強固さを提供するが、ステートレス圧縮のパケット独立属性は、このような圧縮は単一のパケット内でデータを検証するという事実のため、実現される圧縮比を下げる。したがってたとえばこの圧縮技法は、隣接するパケットのネットワークヘッダ内に典型的に見いだされる大量の冗長度を除去することはできない。さらに、ストリーミング圧縮はより大きな圧縮比を提供するが、これらの圧縮方式は、１つのパケットがネットワーク内で失われると、それによって受信器がいくつかの他のパケットを失うという点で、パケットの損失という効果を増幅する。信頼性の低いネットワーク、たとえばインターネットについては、このパケット効果の増幅はストリーミング圧縮を使用する効用を減らす。
【００１１】
【発明が解決しようとする課題】
したがって、従来の圧縮方式の有害な効果なしに、より大きな強固さおよび増大された圧縮比を提供する圧縮技法に対するニーズが存在する。
【００１２】
【課題を解決するための手段】
本発明の一態様は、パケット間の圧縮を可能にし、これによってたとえばパケット損失を増幅する効果など先行の圧縮方式の有害な効果なしに、より大きな強固さと増大した圧縮比を達成する、パケットを圧縮するための方法および装置に関する。具体的には、本発明の一態様では、可変長符号化が各パケットについて別のハッシュテーブルを維持することと同時に使用される。本発明の好ましい実施形態によれば、可変長符号化はマッチレングス、オフセットおよびリテラルを使用する。このように、すべてのフレーズは、長さがゼロのマッチで符号化されているリテラルを有する（訳注：つまり符号化されたリテラルを有さない）マッチレングスで始まり、ついでリテラルの符号化が続く。好ましい実施形態によれば、長さがゼロではない最小のマッチは例としては３バイトであり、最大マッチは特定のパケットサイズによって限定される。
【００１３】
さらに、本発明の別の態様によれば、パケットごとのハッシュテーブルはそのパケット内の特定のバイトストリングを示すが、任意の他のパケット内（単数または複数）のデータは示さない。すなわち、本発明は各パケットに関してそれぞれ個別のハッシュテーブルを生成および維持し、ここでこのようなハッシュテーブルは任意の他のパケットからは独立して構築される。例として、本発明の一実施形態によれば、パケットに関するそれぞれのハッシュテーブルは、その特定のパケットが圧縮される時に構築される。本発明のさらなる実施形態によれば、パケットに関するそれぞれのハッシュテーブルは圧縮の前または後に構築される。このように、それぞれのハッシュテーブルは特定のパケットで符号化される。本発明の一態様によれば、パケットに関するそれぞれのハッシュテーブルは全パケットの中のデータを個別のサブストリングの関数として示す。例として、本発明の好ましい一実施形態によれば、このようなサブストリングは長さが３バイトである。したがって、特定のパケットのバイトサイズは、そのパケットに関してそれぞれのハッシュテーブルの中で示されるバイトストリングの数を決定することになる。このように、パケットごとのハッシュテーブルを使用することは、パケット全体の効率的で強固な圧縮を提供する。
【００１４】
すなわち、各パケットのハッシュテーブルはその特定のパケット内のデータにのみ依存しているので、パケットの恣意的な組に関する有効なインデックスは対応するハッシュテーブルを使用して作成できる。したがって、好ましい実施形態によれば、ストリングの検索は現在のパケットに関するハッシュテーブルのクエリによって実行され、その後にもっとも最近送信されたパケットから始まる可変履歴状態内のパケットの各々に関するハッシュテーブルが続く。好ましい実施形態のパケットごとのハッシュテーブルはまた、無効な入力によって終了した単独にリンクされたオフセットチェーンを維持し、ハッシュテーブルに関する有効なオフセット範囲を変更することによって（表全体を消去することによってではなく）ハッシュテーブルをリサイクルすることが理解されよう。さらに、圧縮レベルパラメータ、たとえば８ストリングを使用して、マッチを検索している間にチェックされる最大数を決定することが理解されよう。
【００１５】
本発明の一態様によれば、有利には増大された強固さとより大きな圧縮比は種々の圧縮方法で達成できる。
【００１６】
【発明の実施の形態】
発明者らの同時係属で、本譲受人に譲渡され，同じ日付に提出された出願番号＿＿＿、代理人整理番号Ｓ．Ｍ．Ｄｏｒｗａｒｄ９−２（またはここでは利便のため、「承認された圧縮に関する出願」と呼ばれる）で詳細に示されたように、発明者らは、選択履歴状態をパケットの関数として使用してネットワーク上で送信することによって、エレガントな圧縮ツールの提供が達成され、これによって、強化されたデータ圧縮が実現できることに気づいた。本発明の一態様によれば、いわゆる確認ベクトルの関数として決定される選択履歴状態が使用される。さらに、本発明の一態様によれば、確認ベクトルは通信チャネル上の以前の送信で正常に受信されたパケットの識別に関する情報を含む。すなわち、本発明の一態様によれば、パケット履歴状態はそれぞれのパケットに関連づけられた選択履歴状態である。このように、通信チャネルの第１のサイド、たとえば送信器サイドまたは送信者サイドは、どのパケットが通信チャネルの第２のサイド、たとえば受信器サイドまたは受信者サイドによって正常に受信されたかに関する所定の情報を提供され、それを認識する。また解凍装置も選択履歴を提供され、それを認識し、送信者から送信された、圧縮されたパケットの効率的な解凍を可能にする。すなわち解凍は、パケット圧縮の間、履歴、すなわち選択履歴状態として使用されたパケットの関数として発生する。このように、本発明の選択履歴状態および認識態様を通じて圧縮装置および解凍装置（通信チャネルのいずれかのサイド）は協力して機能し、通信チャネル上で改良された圧縮を達成する。
【００１７】
承認された圧縮に関する出願の中で本発明の種々の態様の圧縮を使用することによって達成された圧縮結果、たとえば帯域幅比は、特により高い帯域幅ではより小さいパケットについてはいくぶん減少される。これは部分的には使用されている実際の圧縮方式のためである。たとえば、よく知られたデフレート圧縮方式はより小さいパケットサイズについては比較的非効率的なフォーマットを使用している。具体的には、デフレート圧縮方式によれば、各パケットはよく知られた静的なホフマン符号化または動的なホフマン符号化のいずれかで圧縮される。このようなホフマン符号化は大きなファイルのオフライン圧縮には役に立つが、各データパケット内の必須のホフマン辞書を計算し送信することに関連する処理オーバーヘッドは、より小さなパケット、たとえばインターネット上で送信される典型的なデータパケットのリアルタイムな圧縮には高価すぎる。さらに、デフレートは1つのパケットを終了するために約8バイトの追加の処理オーバーヘッドを必要とし、これはさらにインターネットのような通信用途内の有用性に影響をあたえる。このようなホフマン符号および／または辞書を使用する他の圧縮方式、たとえばＬＺ７７も同じように影響を受けることが理解されよう。
【００１８】
したがって発明者らは以下により詳細に論じられるように、承認された圧縮に関する出願における本発明の態様およびその完全な利点は、従来の圧縮方式に伴う所定の処理オーバーヘッド問題を緩和する新規の圧縮フォーマット内でさらに実現されることに気づいた。具体的には、本発明の一態様によれば、可変長符号化が各パケットについて別のハッシュテーブルを維持することと同時に使用される。本発明の好ましい実施形態によれば、可変長符号化はマッチレングス、オフセットおよびリテラルを使用する。本発明の種々の態様をより詳細に論じその完全な理解を促進する前に、上記の同時係属の、本譲受人に譲渡された承認された圧縮に関する出願の所定の態様が次に示される。
【００１９】
本発明の一態様はパケット間の圧縮を可能にし、それによってたとえばパケット増幅の効果など先行の圧縮方式の有害な効果なしにより優れた強固さと増大した圧縮比を達成する、パケットを圧縮するための方法および装置を提供する。具体的には、いわゆる認識方式が特定の圧縮アルゴリズムと共に使用され、送信器、すなわち、送信者は圧縮アルゴリズムによって使用される履歴を正しく受信されたパケットに限定できる。好ましい実施形態では、履歴として使用されるパケットを識別するベクトルが圧縮パケット内に含まれ、これによって受信器は、パケットを解凍するために必要なパケット履歴状態を再構築できる。
【００２０】
図１はデータを圧縮および解凍するための例示的なシステム１００の構成図である。システム１００はとりわけ、たとえばいくつか名前を上げるとワイヤ、ワイヤレス、または光ファイバなどの送信媒体上で情報を送信および受信するために有用である。さらに、システム１００は別法としては、コンピュータのディスクドライブなどの磁気媒体またはＣＤ−ＲＯＭなどの光可読媒体に情報を記録したり、そこから情報を読み出すために有用である。本発明によって圧縮されたデータをたとえば磁気ディスクドライブなどの磁気媒体および、たとえばＣＤ−ＲＯＭなどの光可読媒体を含む記録可能な媒体上に記録することが可能である。図１では、たとえばテキストなどの入力データストリーム１０５は、入力データ符号器１１０に供給される。以下にさらに詳細に論じられるように、本発明の一態様によれば入力データ符号器１１０は可変履歴状態パケット間圧縮を適用することによって、入力データストリームを前処理し符号化する。この符号化プロセスに関する本発明の種々の態様は、特に図２に示された例示的な動作を参照しながら、以下にさらに詳細に説明される。
【００２１】
図１の例示的なシステム１００の議論に続き、本発明の一態様によって生成された符号化された入力データストリーム１１５は圧縮装置１２０に渡される。圧縮装置１２０は本発明の好ましい実施形態によれば、たとえばＬｅｍｐｅｌ−Ｚｉｖ圧縮などの圧縮方法を適用して、符号化された入力データストリーム１１５を圧縮されたデータ１２５に圧縮する。上記のように、本発明にしたがってここに説明された本発明の有利な態様を実現するために、符号化された入力データストリーム１１５を圧縮する際には任意のＬｅｍｐｅｌ−Ｚｉｖタイプの圧縮が効果的に使用できることに注意されたい。圧縮されたデータ１２５はついで、チャネル符号器１３０によって符号化され、チャネル符号化された情報１３５を生成する。チャネル符号化は圧縮された情報に情報を追加し、データ読み出しプロセスの中でエラーの検出および／または訂正を可能にすることが理解されよう。従来のチャネル符号化技法はよく知られたＲｅｅｄ Ｓｏｌｏｍｏｎ符号化を含み、Ｒｅｅｄ Ｓｏｌｏｍｏｎ符号化は一連の記号を符号化し、各記号は１つまたは複数のデータビットによって表される。これらの記号はついで、変調符号器１４０によって変調符号化され、変調符号器１４０は変調されたデータストリーム１４５を生成し、変調されたデータストリーム１４５は通信チャネルを介して送信されるかまたは媒体１５０上に記録されるチャネルシーケンスを定義する。
【００２２】
データストリームの送信または記録の間に、チャネル／媒体１５０の中にノイズと干渉がしばしば導入される。変調復号器１５５およびチャネル復号器１６０は変調されたデータストリーム１４５をノイズと共に受信し、よく知られた方法でチャネル符号器１３０の符号化プロセスおよび変調符号器１４０の符号化プロセスをそれぞれ反対にする。チャネル復号器１６０からのデータストリームは、圧縮装置１２０によって生成された圧縮されたデータ１２５に対応する。本発明によればこのデータストリームはついで、解凍装置１６５によって解凍され、データ復号器１７０によって復号化され、出力データストリーム１７５を生成し、これは図４に関して以下に詳細に説明される。
【００２３】
承認された圧縮に関する出願における本発明の種々の態様は、改良された圧縮の強固さと圧縮比を実現することに関する。図２は、上記のように本発明の一態様による、図１の例示的なシステム内で有用な、データを圧縮するための例示的な動作２００のフローチャートを示す。具体的には、入力データストリームが受信され、正常に受信されたパケットが確認される（図２のブロック２１０を参照のこと）。正常に受信されたパケットを検査することにより、特定の確認ベクトルの関数として１つのパケット履歴状態を識別することを可能とする（図２のブロック２２０を参照のこと）。本発明の好ましい実施形態によれば、パケット履歴状態はパケットの以前の組であり、その上に現在のパケットの圧縮が決定される。たとえば、Ｌｅｍｐｅｌ−Ｚｉｖ７７圧縮に関しては、履歴状態はこのようなＬｅｍｐｅｌ−Ｚｉｖ圧縮で使用されているいわゆる辞書に直接相関する。面白いことに、上記のステートレス圧縮とネットワークパケットのストリーミング圧縮の間の主な違いは、各方式が使用する特定の履歴状態である。すなわち、ステートレス圧縮は履歴状態を使用しないが、ストリーミング圧縮は任意の前のパケットを履歴として許可する。このような違いは、本発明の原理に関して依然として有効である。
【００２４】
具体的には、本発明の好ましい実施形態によれば、パケット履歴状態は、たとえば受信器サイドまたは受信者によって通信チャネル上で正常に受信された特定のパケットに関して選択履歴状態である。受信者は選択履歴を提供され認識しているので、送信された圧縮されたパケットの効率的な解凍が可能になる。有利には、本発明のこの態様によれば、選択パケット間履歴状態の使用は、固有のパケット損失を被る、以前のストリーミング圧縮方式に比べて圧縮の強固さおよび圧縮比を向上させる。
【００２５】
上に説明したように選択パケット履歴状態を識別した後に、このような履歴状態が使用されて、送信者からの送信を待つパケットへ所定の情報を符号化する。具体的には、本発明の好ましい実施形態によれば、個別のパケットはそこに関連づけられたそれぞれのパケット履歴状態の関数として符号化される（図２のブロック２３０を参照のこと）。本発明の一実施形態によれば各パケットには、例として、そのパケットに関連づけられたそれぞれのパケット履歴を識別する履歴ベクトルを含むヘッダが、接頭辞として付けられている。注意を簡単に図３に向けると、例示的なパケットストリーム３００は図２の、例示的な動作によって圧縮されているように示されている。図３の実施形態によれば、パケットヘッダはシーケンス番号および確認ベクトルなどの追加の項目を含む。すなわち、本発明のさらなる実施形態によれば、前記の確認ベクトルはパケットヘッダの一部として送信される場合がある。当業者であれば理解されるように、確認ベクトルが符号化されたパケットとは別に送信されるか（上に論じられたように）、またはパケットヘッダの一部として送信されるかの決定は、設計上の選択の問題であり、どちらのコンテキストにも本発明の原理は等しく適用される。たとえば、確認ベクトルはいわゆる「便乗」技法を使用して送信者に送信することができ、ここでは受信者から送信者へ逆の方向のデータストリームが存在する。
【００２６】
たとえば、パケットストリーム３００は、一連のパケットを含む（たとえば、図３にそれぞれパケット３０５〜３１５として示されたようなパケット１からパケットｎ）。さらに、各パケットはヘッダを含む（たとえば、図３にそれぞれヘッダ３２０〜３３０として示されたＨ1からＨn）。さらに、例として、ヘッダ３２０は符号化されたシーケンス番号３３５、履歴ベクトル３４０および確認ベクトル３４５を含んでより詳細に示されている。
【００２７】
好ましい実施形態によれば、たとえばシーケンス番号３３５などのシーケンス番号は送信者および受信者の双方によって使用されて、本発明の原理によって圧縮されたパケットを識別する。シーケンス番号を符号化するために使用されるビットの数は十分に多く、全ネットワークを通り抜けるために必要な最大の時間の間、いわゆる「折り返し」のよく知られた有害な結果を避ける必要がある。例として、シーケンス番号３３５は長さが２４ビットとして示されている。
【００２８】
さらに、好ましい実施形態によれば、たとえば履歴ベクトル３４０などの履歴ベクトルは圧縮のために使用された以前の一組のパケット、すなわち選択履歴状態を記述する。履歴決定のために認識パケットを使用する本発明の好ましい実施形態に関しては、パケットが送信される時間とそのパケットが履歴として使用される時間の間に、ネットワークの往復時間に関して時間遅延が発生する場合がある。このように、本発明の好ましい一実施形態によれば、オフセットがパケットのシーケンス番号から除算されてもっとも最近の履歴パケットのシーケンス番号を確立するように、履歴ベクトルがオフセットおよびビットマスクを使用して符号化される。ビットマスクはこのもっとも最近の履歴パケットのすぐ前の、追加の履歴パケットを識別する。例としては、ヘッダ３２０に関して、履歴ベクトル３４０は８ビットのオフセットおよび８ビットのマスクを含み、これによって最後の２６３内で、最大でも９つの連続パケットに履歴状態を限定する。
【００２９】
上記のように、図３の実施形態のパケットヘッダはまた、たとえば確認ベクトル３４５などの確認ベクトルを含み、一組の最近受信されたパケットを記述する。確認ベクトルは少なくとも、もっとも最近受信されたパケットのシーケンス番号および、そのすぐ前のパケットの状態を記述するビットマスクを含む。例としては、確認ベクトル３４５は長さが３２ビットで、シーケンス番号のために２４ビットをカバーし、関連づけられたマスクのために８ビットをカバーする。
【００３０】
図２に注意を戻してみると、本発明の原理によってパケットをそれぞれのパケット履歴状態の関数として符号化すると（図２のブロック２３０を参照のこと）、これらのパケットはさらなる圧縮の準備ができる。上記に詳細に説明したように、本発明の利点は、これが幅広い既存の圧縮技法と共に適用できることである。たとえば、以下に詳細に説明するように、本発明の原理は、よく知られたＬＺ７７圧縮方式またはよく知られた「デフレート」圧縮方式が適用されているパケットストリームの圧縮を向上させる。したがって、選択された圧縮方式を符号化されたパケットに適用すると（図２のブロック２４０を参照のこと）、圧縮されたパケットは送信の準備ができる（図２のブロック２５０を参照のこと）。
【００３１】
発明者らは、本発明の一態様によれば、選択履歴状態をパケットの関数として使用してネットワーク上を送信することによって、エレガントな圧縮ツールの提供が達成され、これによって強化されたデータ圧縮が実現されることに気づいた。すなわち、本発明の一態様によれば、それぞれのパケットに関連づけられたパケット履歴状態は、送信サイド、すなわち送信者が、受信器サイドすなわち受信者によって正常に受信されたパケットに関する所定の情報を提供され認識しているという点で、選択履歴状態である。同様に、受信器サイドはまたこのようなパケットに関連づけられた選択履歴状態を提供され認識しており、送信者からの圧縮されたパケットの効率的な解凍を可能にする。このように、本発明の選択履歴状態および認識態様を通じて、送信者および受信者は協力して機能して、通信チャネル上で向上した圧縮を達成する。
【００３２】
具体的には、本発明の一態様によれば、確認ベクトルは特定のアルゴリズムと共に使用され、送信器、すなわち送信者は圧縮アルゴリズムによって使用される履歴を正しく受信されたパケットに限定できる。したがって、本発明の一実施形態によれば、履歴として使用されるパケットを識別するベクトルは圧縮されたパケット内に含まれ、それによって、パケットを解凍するために必要なパケット履歴状態を受信者が再構築することが可能になる。本発明のさらなる実施形態によれば、確認ベクトルは圧縮されたパケットとは別に送信される。さらに、この例示的な実施形態は明瞭に説明するために単一の通信チャネル配置を論じているが、本発明の原理は多数の通信チャネル配置および構成にも同様に適用可能であることが理解されるであろう。有利には、本発明のこの態様によれば、選択履歴状態の使用は、パケット損失という固有の妥協を被る以前のストリーミング圧縮方式に比べて、圧縮の強固さおよび圧縮比を改良する。
【００３３】
図４は承認された圧縮に関する出願の発明のさらなる態様による、データを解凍するための例示的な動作４００のフローチャートを示す。具体的には、受信されたパケットの圧縮されたストリームから（図４のブロック４１０を参照のこと）履歴ベクトルがパケットごとに抽出される（図４のブロック４２０を参照のこと）。このように、パケットに関連づけられたそれぞれのパケット履歴状態は、履歴ベクトルの関数として決定される。例として、次の疑似コードは、本発明の一実施形態によるこれらの項目の抽出を記述している。
当業者であれば上記に説明された疑似コードを使用して種々のプログラム、たとえば、よく知られたＣプログラミング言語のコンピュータプログラムを開発して、本発明を実装するためのプロセッサ内で実行できることが理解されよう。履歴ベクトルの抽出から、解凍されているパケットのそれぞれのパケット履歴状態が識別される（図４のブロック４３０を参照のこと）。本発明のさらなる実施形態によれば、抽出はまた、確認ベクトルおよびシーケンス番号をパケットヘッダから抽出することを含む場合がある。本発明の好ましい実施形態によれば、現在のパケットの解凍はそれぞれの履歴状態の関数として行うことができる（図４のブロック４４０を参照のこと）。こうして、現在圧縮されていないパケットは、それぞれの解凍装置、たとえば特定の通信チャネルの受信サイドの解凍装置の、現在受信されたパケット状態に追加され（図４のブロック４５０を参照のこと）、これによって受信されたパケットの組を更新する。最後に、現在のパケットを解凍した後、確認ベクトルが構築され、送信者に送信されて戻される（図４のブロック４６０を参照のこと）。先に説明したように、本発明の一態様によれば、確認ベクトルは一組の最近受信されたパケットを記述し、送信者によって使用されて選択履歴状態と共に今後のパケットを圧縮する。
【００３５】
発明者らは、上記のように、承認された圧縮に関する出願における本発明の態様およびその利点は、新しい符号化技法および圧縮フォーマットでさらに実現されることに気づいた。このような発明的な圧縮フォーマットおよび関連づけられた符号化が本発明の主題である。
【００３６】
所定のよく知られた圧縮方式に関しては、重要な実装の特性はマッチを検出することである。典型的には、マッチは圧縮された現在のパケットの一部の中か、履歴状態を作る任意のパケットの中に見い出される。たとえば、デフレートのＺｌｉｂ実装（上記に論じた）は、単一のハッシュテーブルを使用してマッチを検索し、これはたとえばストリーミング圧縮と共に使用されると許容できる結果を提供する。対照的に、また有利に、本発明は各パケットについて別のハッシュテーブルを生成し維持する。具体的には、図５は本発明の一態様によってデータを圧縮するための例示的な動作５００のフローチャートを示す。一組の入力データから（図５のブロック５１０を参照のこと）、各パケットについて別のハッシュテーブルが生成され維持される（図５のブロック５２０を参照のこと）。すなわち、本発明は各パケットについてそれぞれ別のハッシュテーブルを生成し維持して、このようなハッシュテーブルは別のパケットの内容から独立して構築される。本発明の好ましい一実施形態によれば、特定のハッシュテーブルはパケットが圧縮される時にそのそれぞれのパケットで構築される。先に説明したように、本発明のさらなる実施形態によれば、パケットに関するそれぞれのハッシュテーブルは圧縮の前または圧縮の後に構築される。
【００３７】
したがって、本発明の好ましい実施形態によれば、個別のパケットは、パケットの履歴状態の中でそのパケットに関するそれぞれのハッシュテーブルに関して符号化される（図５のブロック５３０を参照のこと）。すなわち、特定のパケット「Ｐ」の符号化は、パケット履歴状態を定義する関連づけられたパケットの組「Ｓ」を使用する。本発明の一態様によれば、Ｓの中の各パケットはそこに関連づけられたそれぞれのハッシュテーブルを有する。したがって本発明の一態様によれば、特定のパケットＰの符号化は、Ｓの中のそのパケットに関するそれぞれのハッシュテーブルに関して実行される。本発明の一態様によれば、パケットに関するそれぞれのハッシュテーブルは、全パケット内のデータを個別のサブストリングの関数として示す。このように、Ｐの符号化はＳ内のパケットに関連づけられたハッシュテーブルの中のＰから一連のサブストリングを探し出すことを含む。例としては、本発明の好ましい実施形態によれば、このようなサブストリングは長さが３バイトである。したがって、特定のパケットの全体のバイトサイズは、そのパケットに関するそれぞれのハッシュテーブルの中で示されるバイトストリングの数を決定する。このように、パケットごとのハッシュテーブルと、可変履歴状態パケット間圧縮を共に使用することは、パケット全体の効率的で強固な圧縮を提供する。
【００３８】
具体的には、本発明の一態様によれば、可変長符号化と、各パケットに関する別のハッシュテーブルを維持することが共に使用される。本発明の好ましい実施形態によれば、可変長符号化は、マッチレングス、オフセットおよびリテラルに関して使用される。マッチレングスは、すべてのフレーズはマッチレングスで始まり、リテラルはゼロ長さのマッチで符号化されており、ついでリテラルの符号化が続くように、符号化される（図５のブロック５４０を参照のこと）。好ましい実施形態では、もっとも小さい非ゼロのマッチレングスは、例としては３バイトであり、最大のマッチは特定のパケットサイズによって限定される。例として、下の表１は好ましい実施形態による特定のマッチレングスの符号化を示す。
【表１】
さらに、本発明の好ましい実施形態によれば、リテラルは予想方式を使用して符号化される（図５のブロック５５０を参照のこと）。（ａ）デフォルトの８ビットリテラル符号化が適用される。これは、（２）１つの行の中の４つのリテラルが３２から１２７の範囲内にあり（３２および１２７を含む）、可変長符号化が範囲の外側にあるリテラルが符号化されるまで使用される場合を除く。桁が一番小さい７つのビットが、指定された範囲内の値について発せられ、（３）他のリテラルは番号、モジュロ２５６に６４ビットを加えることによって符号化される。その結果の数字が９６未満の場合は９ビットで符号化され、９６以上の場合は１０ビットで符号化される。
【００４０】
本発明の好ましい実施形態によれば、マッチオフセットはマッチするフレーズともっとも最近符号化された入力バイトの間の距離として定義され符号化される（図５のブロック５６０を参照のこと）。オフセットは例としては１４ビットであり、２つの断片、すなわち（１）範囲、および（２）その範囲内の位置に符号化される。ビット数を決定する範囲は位置を符号化するために使用され、より少ないビットはより近いオフセットを符号化するために使用される。例としては、下の表２は好ましい実施形態によるマッチオフセットの符号化を示す。
【表２】
本発明の好ましい実施形態によれば、パケットごとのハッシュテーブルはそのパケット内のバイトストリングを示すが、任意の他のパケット（単数または複数）の中のデータは示さない。したがって、各パケットのハッシュテーブルはその特定のパケット内のデータのみに依存するので、任意のパケットの組に関する有効なインデックスは対応するハッシュテーブルを使用して作成できる。すなわち、好ましい実施形態によれば、ストリングの検索は現在のパケットに関するハッシュテーブルのクエリで実行でき、最初はもっとも最近送信されたパケットである、可変履歴状態内のパケットの各々に関するハッシュテーブルが続く。好ましい実施形態のパケットごとのハッシュテーブルはまた、無効なエントリによって終了した単一のリンクされたオフセットチェーンを維持し、そのハッシュテーブルに関して有効なオフセット範囲を変更することによってハッシュテーブルをリサイクルする（テーブル全体を消去することによってではない）ことが理解されよう。さらに、たとえば８ストリングの圧縮レベルパラメータを使用して、マッチを検索している間にチェックされるストリングの最大数を決定することが理解されよう。圧縮レベルパラメータは圧縮の間に使用される全体の計算レベルを決定するためのインジケータであり、レベルがより高ければデータを圧縮する再に実行される計算がより多いことが理解されよう。
【００４２】
本発明の種々の態様および利点をさらに示すために、本発明の原理が先に論じられたよく知られたｚｌｉｂデフレート圧縮との比較のコンテキストで適用された。具体的には、図６は１６００バイトおよび１２５バイトのパケットサイズについての、それぞれの帯域幅比シミュレーションの結果６００および６１０を示す。帯域幅比シミュレーションの結果６００および６１０は、２つの異なる圧縮レベル設定に関する結果を含む。すなわち、結果６２０および６４０は、圧縮レベルパラメータ６における２つの圧縮方式を比較し、結果６３０および６５０は、圧縮設定が１における２つの圧縮方式を比較する。帯域幅比シミュレーションの結果６００および６１０の検討から理解されるように、本発明の原理によって達成される圧縮は全体として（すなわち、「ｔｈｗａｃｋ−６」、結果６４０を参照のこと、および「ｔｈｗａｃｋ−１」、結果６５０を参照のこと）デフレートの圧縮（すなわち、「ｚｌｉｂ−６」、結果６２０を参照のこと、および「ｚｌｉｂ−１」、結果６３０を参照のこと）より優れており、より小さいパケットサイズの圧縮という点では明らかに優れている。
【００４３】
本発明の種々の態様は、これらの方法を実行するための方法および装置の形で具体化できる。本発明はまた、フロッピディスケット、ＣＤ−ＲＯＭ、ハードドライブまたは任意のマシン可読記憶媒体などの有形メディア内で具体化されるプログラムコードの形で具体化でき、ここでプログラムコードがコンピュータなどのマシン内にロードされそのマシンによって実行されると、そのマシンは本発明を実行するための装置となる。本発明はまたたとえば、マシンにロードされるおよび／またはマシンによって実行されるか、または光ファイバまたは電磁放射線を介して電気ワイヤリングまたはケーブリング上などなんらかの送信媒体上を送信される記憶媒体内のプログラムコードの形で具体化することもでき、この場合、プログラムコードがコンピュータなどのマシン内にロードされそのマシンによって実行されると、そのマシンは本発明を実行するための装置となる。汎用プロセッサ上で実装される時、プログラムコードセグメントはプロセッサと結びついて特定の論理回路と類似の動作を行う独自のデバイスを提供する。
【００４４】
前記は本発明の原理を示したに過ぎない。したがって、当業者であればここに明示的に説明されるかまたは示されてはいないが、本発明の原理を具体化しその精神および範囲内に含まれる種々の構成を工夫できることが理解されよう。さらに、ここに引用されたすべての例および条件付きの言葉は主に、教育上の目的のために特別に意図されたもので、読者が出願者によって与えられた本発明の原理および概念の理解して技法を促進することを助けるためのものであり、このような具体的に列挙された例および条件に限定されるものではないと理解されるべきである。さらに、本発明の原理、態様、実施形態、およびその具体的な例を列挙するすべての文章は、その構造的等価物および機能的等価物の両方を含むことが意図されている。さらに、このような等価物が現在知られている等価物および将来開発される等価物、すなわち、構造にかかわらず同じ機能を実行するために開発される任意の要素も含むことが意図されている。
【００４５】
したがってたとえば、当業者であれば本明細書の構成図は本発明の原理を具体化する例示的な回路を概念的に表していることが理解されるであろう。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コード、プログラムコードなどは、コンピュータ可読媒体内で実質的に表される種々のプロセスを示し、コンピュータ、マシン、またはプロセッサが明示的に示されていなくても、コンピュータ、マシン、プロセッサによって実行される。
【００４６】
この開示全体で、別段の記載のない限り、図の中の同様な要素、ブロック、構成要素、または部分は、同じ参照指示によって示されている。
【図面の簡単な説明】
【図１】データを圧縮および解凍するための例示的なシステムの構成図である。
【図２】本発明の例示的な実施形態による、図１の例示的なシステムで有用な、データを圧縮するための例示的な動作を示すフローチャートである。
【図３】図２の例示的な動作によって圧縮された、例示的なパケットストリームを示す図である。
【図４】本発明の一実施形態により、図１の例示的なシステムで有用な、データを解凍するための例示的な動作を示すフローチャートである。
【図５】本発明の原理による、データを圧縮するための例示的な動作を示すフローチャートである。
【図６】本発明の種々の態様による、テキストファイルを圧縮した結果の比較を示す図である。
【符号の説明】
１００ システム
１０５ 入力データストリーム
１１０ 入力データ符号器
１１５ 符号化された入力データストリーム
１２０ 圧縮装置
１２５ 圧縮されたデータ
１３０ チャネル符号器
１３５ チャネル符号化された情報
１４０ 変調符号器
１４５ 変調されたデータストリーム
１５０ チャネル／媒体
１５５ 変調復号器
１６０ チャネル復号器
１６５ 解凍装置
１７０ データ復号器
２００ 動作
２１０、２２０、２３０、２４０、２５０ ブロック
３００ パケットストリーム
３０５〜３１５ パケット１〜パケットｎ
３２０〜３３０ ヘッダＨ1〜Ｈn
３３５ シーケンス番号
３４０、３４５ 履歴ベクトル
４００ フローチャート
４１０、４２０、４３０、４４０、４５０、４６０ ブロック
５００ 動作
５１０、５２０、５３０、５４０、５５０、５６０ ブロック
６００、６１０ 帯域幅比シミュレーションの結果
６２０、６３０、６４０、６５０ 結果
Claims (10)
- データ通信の方法であって、
データの入力ストリームを複数のパケットに分割するステップと、
該複数のパケットのうち特定のパケットに関してそれぞれのパケット履歴状態を少なくとも１つの確認ベクトルの関数として識別するステップと、
該複数のパケットのうち該特定のパケットの各々に関してそれぞれのハッシュテーブルを生成するステップと、
該複数のパケットのうち該特定のパケットを、その特定のパケットと関連している該それぞれのパケット履歴状態を変数とする関数を使用して符号化するステップとを含み、符号化されたパケットの各々は、その符号化されたパケットと関連している該それぞれのハッシュテーブルを使用して符号化されている方法。 - 通信チャネル上で送信側の場所と受信側の場所との間で通信ストリームを送信する方法であって、該方法は、
該通信ストリームを一連のパケットに分割するステップと、
該パケットの各々に関してそれぞれのパケット履歴状態を確認ベクトルの関数として識別するステップと、
該パケットに関連づけられた該それぞれのパケット履歴状態を変数とする関数を使用して該パケットを符号化し、各パケットは、それぞれのハッシュテーブルを使用して符号化されるステップと、
該通信チャネル上で、該送信側の場所から該受信側の場所へ該符号化されたデータストリームを送信するステップとを含む方法。 - 入力データストリームを符号化する方法であって、該入力データストリームは複数のビットを含み、該方法は、
該複数のビットを複数のパケットに構成し、各パケットは該複数のビットのうち特定の一連のビットを含むステップと、
複数のハッシュテーブルを生成するステップとを含み、該ハッシュテーブルの各々は、該複数のパケットのうち特定の１つのパケットと関連しており、該方法は、さらに、
該複数のパケットの各パケットを出力データストリーム内に符号化し、該出力データストリームの各パケットはそれに関連づけられた該それぞれの１つのハッシュテーブルを使用して符号化されるステップとを含む方法。 - 該パケットに関連づけられた該それぞれのハッシュテーブルは、該パケット内の少なくとも一部のデータの関数として識別される請求項１、請求項２又は請求項３に記載の方法。
- 該パケットに関連づけられた該それぞれのハッシュテーブルは一連のバイトサブストリングを含み、該一連のバイトサブストリングは該パケット内の一部のデータの関数として決定される請求項４に記載の方法。
- 該複数のパケットを符号化するステップはさらに、
複数のマッチレングス、複数のリテラル、複数のマッチオフセットを、該パケット内の一部のデータの関数として符号化するステップを含む請求項４に記載の方法。 - 該パケットを符号化するステップはさらに、
該パケットに関連づけられた該それぞれのハッシュテーブルを検索することによって、データの入力ストリームの特定のストリングを識別するステップを含む請求項５に記載の方法。 - 該検索するステップは、該パケットの該それぞれのパケット履歴状態を変数とする関数を使用して実行される請求項７に記載の方法。
- デジタル信号を処理するための装置であって、該デジタル信号は、デジタルデータの入力ストリームを複数のパケットに分割し、該パケットのうち特定のパケットに関してそれぞれのパケット履歴状態を少なくとも１つの確認ベクトルの関数として識別し、該パケットの各々に関してそれぞれ１つのハッシュテーブルを生成し、各パケットをそれに関連づけられた該それぞれのパケット履歴状態を変数とする関数を使用して符号化されたデジタル信号を生成し、該符号化されたパケットの各々は、該パケットのそれぞれのハッシュテーブルを使用して符号化され、該符号化されたデジタル信号を通信チャネルに適用することによって生成され、該装置は、
該通信チャネルから該符号化されたデジタル信号を受信するための受信器と、
該受信された符号化されたデジタル信号を復号化し、該復号化されたデジタル信号から該デジタルデータの入力ストリームを回復するための復号器とを備える装置。 - 複数の命令を格納しているコンピュータ可読媒体であって、該複数の命令は、該コンピュータによって実行された時に、複数の信号のビットを複数のパケットに構成することによって信号符号化方法を該コンピュータに実行させる命令を含み、各パケットは該複数のビットのうち特定の一連のビットを含み、複数のハッシュテーブルを生成し、該ハッシュテーブルの各々は、該複数のパケットのうち特定の１つのパケットと関連づけられ、該複数のパケットのうち各パケットを出力データストリームに符号化し、該出力データストリームの各パケットはそれに関連づけられたそれぞれ１つのハッシュテーブルを使用して符号化されるコンピュータ可読媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/526,844 US6236341B1 (en) | 2000-03-16 | 2000-03-16 | Method and apparatus for data compression of network packets employing per-packet hash tables |
| US09/526844 | 2000-03-16 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001285075A JP2001285075A (ja) | 2001-10-12 |
| JP3665271B2 true JP3665271B2 (ja) | 2005-06-29 |
Family
ID=24099031
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001075336A Expired - Lifetime JP3665271B2 (ja) | 2000-03-16 | 2001-03-16 | パケットごとのハッシュテーブルを使用してネットワークパケットのデータを圧縮するための方法および装置 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6236341B1 (ja) |
| EP (2) | EP1134901B1 (ja) |
| JP (1) | JP3665271B2 (ja) |
| CA (1) | CA2334497C (ja) |
| DE (2) | DE60033184T2 (ja) |
Families Citing this family (44)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6952823B2 (en) * | 1998-09-01 | 2005-10-04 | Pkware, Inc. | Software patch generator using compression techniques |
| JP4193262B2 (ja) * | 1999-01-19 | 2008-12-10 | ソニー株式会社 | 復号装置およびデータ再生装置、並びに復号方法 |
| US6601104B1 (en) | 1999-03-11 | 2003-07-29 | Realtime Data Llc | System and methods for accelerated data storage and retrieval |
| US6318156B1 (en) * | 1999-10-28 | 2001-11-20 | Micro Motion, Inc. | Multiphase flow measurement system |
| US6711164B1 (en) * | 1999-11-05 | 2004-03-23 | Nokia Corporation | Method and apparatus for performing IP-ID regeneration to improve header compression efficiency |
| US6879988B2 (en) * | 2000-03-09 | 2005-04-12 | Pkware | System and method for manipulating and managing computer archive files |
| US20060155788A1 (en) * | 2000-03-09 | 2006-07-13 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US8230482B2 (en) | 2000-03-09 | 2012-07-24 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US20060143180A1 (en) * | 2000-03-09 | 2006-06-29 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US8959582B2 (en) | 2000-03-09 | 2015-02-17 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US20050015608A1 (en) * | 2003-07-16 | 2005-01-20 | Pkware, Inc. | Method for strongly encrypting .ZIP files |
| US20060143253A1 (en) * | 2000-03-09 | 2006-06-29 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US20060143249A1 (en) * | 2000-03-09 | 2006-06-29 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US20060143237A1 (en) * | 2000-03-09 | 2006-06-29 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US20060143199A1 (en) * | 2000-03-09 | 2006-06-29 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US20060173847A1 (en) * | 2000-03-09 | 2006-08-03 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US7844579B2 (en) * | 2000-03-09 | 2010-11-30 | Pkware, Inc. | System and method for manipulating and managing computer archive files |
| US6388584B1 (en) * | 2000-03-16 | 2002-05-14 | Lucent Technologies Inc. | Method and apparatus for data compression of network packets |
| US6516035B1 (en) * | 2000-04-07 | 2003-02-04 | Actisys Corporation | Intelligent encoding method for wireless data communication and control |
| US6501397B1 (en) * | 2000-05-25 | 2002-12-31 | Koninklijke Philips Electronics N.V. | Bit-plane dependent signal compression |
| US6373409B1 (en) * | 2000-06-19 | 2002-04-16 | International Business Machines Corporation | Method and computer program product for implementing text conversion table compression |
| US8692695B2 (en) | 2000-10-03 | 2014-04-08 | Realtime Data, Llc | Methods for encoding and decoding data |
| US9143546B2 (en) | 2000-10-03 | 2015-09-22 | Realtime Data Llc | System and method for data feed acceleration and encryption |
| US7386046B2 (en) | 2001-02-13 | 2008-06-10 | Realtime Data Llc | Bandwidth sensitive data compression and decompression |
| ITTO20020325A1 (it) * | 2002-04-12 | 2003-10-13 | Telecom Italia Lab Spa | ,,procedimento per organizzare la comunicazione fra oggetti gestori ed oggetti gestiti in una rete telematica.relativa architettura e prodot |
| US20050259819A1 (en) * | 2002-06-24 | 2005-11-24 | Koninklijke Philips Electronics | Method for generating hashes from a compressed multimedia content |
| US7580429B1 (en) * | 2002-09-05 | 2009-08-25 | U.S. Robotics | System and methods for improving data compression |
| US20050086383A1 (en) * | 2003-10-17 | 2005-04-21 | Nokia Corporation | Optimizing the compression efficiency in a packet data communication |
| JP4363204B2 (ja) * | 2004-02-04 | 2009-11-11 | ヤマハ株式会社 | 通信端末 |
| US7019674B2 (en) * | 2004-02-05 | 2006-03-28 | Nec Laboratories America, Inc. | Content-based information retrieval architecture |
| JP2006033275A (ja) * | 2004-07-14 | 2006-02-02 | Fujitsu Ltd | ループフレーム検知装置およびループフレーム検知方法 |
| US7592935B2 (en) * | 2005-03-10 | 2009-09-22 | Nec Laboratories America, Inc. | Information retrieval architecture for packet classification |
| JP4587312B2 (ja) * | 2005-09-16 | 2010-11-24 | 株式会社リコー | 符号変換装置及び符号変換方法 |
| DE102006011022A1 (de) * | 2006-03-09 | 2007-10-25 | Netviewer Gmbh | Zweidimensionales adaptives Bildkompressionsverfahren |
| US8391148B1 (en) * | 2007-07-30 | 2013-03-05 | Rockstar Consortion USLP | Method and apparatus for Ethernet data compression |
| US7623047B2 (en) * | 2007-10-30 | 2009-11-24 | Hewlett-Packard Development Company, L.P. | Data sequence compression |
| US9160611B2 (en) | 2009-04-22 | 2015-10-13 | Webroot Inc. | System and method for performing longest common prefix strings searches |
| US8750370B2 (en) * | 2009-09-04 | 2014-06-10 | Brocade Communications Systems, Inc. | Congestion-adaptive compression |
| WO2013052426A1 (en) | 2011-10-03 | 2013-04-11 | Facebook, Inc. | Providing user metrics for an unknown dimension to an external system |
| US8775776B2 (en) | 2012-01-18 | 2014-07-08 | International Business Machines Corporation | Hash table using hash table banks |
| US9246511B2 (en) * | 2012-03-20 | 2016-01-26 | Sandisk Technologies Inc. | Method and apparatus to process data based upon estimated compressibility of the data |
| US10019457B1 (en) | 2013-01-22 | 2018-07-10 | Amazon Technologies, Inc. | Multi-level compression for storing data in a data store |
| US9384204B2 (en) | 2013-05-22 | 2016-07-05 | Amazon Technologies, Inc. | Efficient data compression and analysis as a service |
| US10454498B1 (en) * | 2018-10-18 | 2019-10-22 | Pure Storage, Inc. | Fully pipelined hardware engine design for fast and efficient inline lossless data compression |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4464650A (en) | 1981-08-10 | 1984-08-07 | Sperry Corporation | Apparatus and method for compressing data signals and restoring the compressed data signals |
| US4558302A (en) | 1983-06-20 | 1985-12-10 | Sperry Corporation | High speed data compression and decompression apparatus and method |
| US4730348A (en) * | 1986-09-19 | 1988-03-08 | Adaptive Computer Technologies | Adaptive data compression system |
| US5146221A (en) * | 1989-01-13 | 1992-09-08 | Stac, Inc. | Data compression apparatus and method |
| US5442350A (en) | 1992-10-29 | 1995-08-15 | International Business Machines Corporation | Method and means providing static dictionary structures for compressing character data and expanding compressed data |
| US5550540A (en) | 1992-11-12 | 1996-08-27 | Internatioal Business Machines Corporation | Distributed coding and prediction by use of contexts |
| US5369605A (en) | 1993-07-07 | 1994-11-29 | Dell Usa, L.P. | Incremental search content addressable memory for increased data compression efficiency |
| US5521597A (en) * | 1993-08-02 | 1996-05-28 | Mircosoft Corporation | Data compression for network transport |
| WO1995019662A1 (en) * | 1994-01-13 | 1995-07-20 | Telco Systems, Inc. | Data compression apparatus and method |
| JP3397431B2 (ja) | 1994-03-16 | 2003-04-14 | 富士通株式会社 | データ圧縮方法および装置ならびにデータ復元方法および装置 |
| US5701125A (en) | 1994-06-15 | 1997-12-23 | The United States Of America As Represented By The United States Department Of Energy | Method for compression of data using single pass LZSS and run-length encoding |
| US5572206A (en) | 1994-07-06 | 1996-11-05 | Microsoft Corporation | Data compression method and system |
| US5572209A (en) | 1994-08-16 | 1996-11-05 | International Business Machines Corporation | Method and apparatus for compressing and decompressing data |
| EP0718980A1 (en) | 1994-12-20 | 1996-06-26 | International Business Machines Corporation | Data compression method of individual sequences of strings of a data stream based on a dictionary and device for performing the same |
| US5608396A (en) | 1995-02-28 | 1997-03-04 | International Business Machines Corporation | Efficient Ziv-Lempel LZI data compression system using variable code fields |
| US5663721A (en) | 1995-03-20 | 1997-09-02 | Compaq Computer Corporation | Method and apparatus using code values and length fields for compressing computer data |
| US5659737A (en) * | 1995-08-01 | 1997-08-19 | Oracle Corporation | Methods and apparatus for data compression that preserves order by using failure greater than and failure less than tokens |
| US5710719A (en) * | 1995-10-19 | 1998-01-20 | America Online, Inc. | Apparatus and method for 2-dimensional data compression |
| US5933104A (en) * | 1995-11-22 | 1999-08-03 | Microsoft Corporation | Method and system for compression and decompression using variable-sized offset and length fields |
| US5703581A (en) | 1996-06-14 | 1997-12-30 | Lucent Technologies Inc. | Method and apparatus for data compression and decompression |
| US5831558A (en) * | 1996-06-17 | 1998-11-03 | Digital Equipment Corporation | Method of compressing and decompressing data in a computer system by encoding data using a data dictionary |
| US6021198A (en) * | 1996-12-23 | 2000-02-01 | Schlumberger Technology Corporation | Apparatus, system and method for secure, recoverable, adaptably compressed file transfer |
| JP3372455B2 (ja) * | 1997-07-03 | 2003-02-04 | 富士通株式会社 | パケット中継制御方法，パケット中継装置およびプログラム記憶媒体 |
| US6055538A (en) * | 1997-12-22 | 2000-04-25 | Hewlett Packard Company | Methods and system for using web browser to search large collections of documents |
| US6075470A (en) * | 1998-02-26 | 2000-06-13 | Research In Motion Limited | Block-wise adaptive statistical data compressor |
-
2000
- 2000-03-16 US US09/526,844 patent/US6236341B1/en not_active Expired - Lifetime
- 2000-10-23 DE DE60033184T patent/DE60033184T2/de not_active Expired - Lifetime
- 2000-10-23 DE DE60000912T patent/DE60000912T2/de not_active Expired - Lifetime
- 2000-10-23 EP EP00309338A patent/EP1134901B1/en not_active Expired - Lifetime
- 2000-10-23 EP EP02015108A patent/EP1258998B1/en not_active Expired - Lifetime
-
2001
- 2001-02-07 CA CA002334497A patent/CA2334497C/en not_active Expired - Fee Related
- 2001-03-16 JP JP2001075336A patent/JP3665271B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CA2334497A1 (en) | 2001-09-16 |
| JP2001285075A (ja) | 2001-10-12 |
| EP1258998A2 (en) | 2002-11-20 |
| DE60033184T2 (de) | 2007-11-15 |
| EP1134901B1 (en) | 2002-12-04 |
| DE60000912T2 (de) | 2003-09-04 |
| US6236341B1 (en) | 2001-05-22 |
| EP1258998A3 (en) | 2005-03-09 |
| EP1258998B1 (en) | 2007-01-24 |
| DE60000912D1 (de) | 2003-01-16 |
| DE60033184D1 (de) | 2007-03-15 |
| CA2334497C (en) | 2005-06-07 |
| EP1134901A1 (en) | 2001-09-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3665271B2 (ja) | パケットごとのハッシュテーブルを使用してネットワークパケットのデータを圧縮するための方法および装置 | |
| EP1134900B1 (en) | Method and apparatus for data compression of network packets | |
| CN108880556B (zh) | 基于lz77的无损数据压缩方法、误码修复方法及编码器和解码器 | |
| CA2299902C (en) | Method and apparatus for data compression using fingerprinting | |
| US5293379A (en) | Packet-based data compression method | |
| US9203887B2 (en) | Bitstream processing using coalesced buffers and delayed matching and enhanced memory writes | |
| US8090027B2 (en) | Data compression using an arbitrary-sized dictionary | |
| CA2191403C (en) | Method and apparatus for performing data compression | |
| US5608396A (en) | Efficient Ziv-Lempel LZI data compression system using variable code fields | |
| US5389922A (en) | Compression using small dictionaries with applications to network packets | |
| US7737870B1 (en) | Bit-stream huffman coding for data compression | |
| US5877711A (en) | Method and apparatus for performing adaptive data compression | |
| JP3231663B2 (ja) | データ圧縮方法 | |
| WO2000038330A1 (en) | On-the-fly data re-compression | |
| US8872677B2 (en) | Method and apparatus for compressing data-carrying signals | |
| EP0903865A1 (en) | Method and apparatus for compressing data | |
| US6778109B1 (en) | Method for efficient data encoding and decoding | |
| EP2971721B1 (en) | Data compression for priority-based data traffic, on an aggregate traffic level, in a multi-stream communications system | |
| US5010344A (en) | Method of decoding compressed data | |
| JP4191438B2 (ja) | データ圧縮方法およびデータ伸長方法、該方法を実施するためのコンピュータプログラム製品と電子システム | |
| Dorward et al. | Robust data compression of network packets | |
| Leis | Lossless Source Coding Lecture Notes & Examples |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040426 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040726 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041122 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050222 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050309 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050331 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090408 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090408 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100408 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110408 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120408 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120408 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130408 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140408 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |