RFC1978 日本語訳
1978 PPP Predictor Compression Protocol. D. Rand. August 1996. (Format: TXT=17424 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Rand Request for Comments: 1978 Novell Category: Informational August 1996
コメントを求めるワーキンググループD.底ならし革要求をネットワークでつないでください: 1978年のノベルカテゴリ: 情報の1996年8月
PPP Predictor Compression Protocol
ppp予言者圧縮プロトコル
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]は複数のプロトコルデータグラムをポイントツーポイント接続の上に要約する標準方法を提供します。
The PPP Compression Control Protocol [2] provides a method for transporting multi-protocol datagrams over PPP encapsulated links.
PPP Compression Controlプロトコル[2]はPPPの上でマルチプロトコルデータグラムを輸送するための方法に要約のリンクを提供します。
This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets.
PPPを圧縮するとパケットがカプセルに入れられたので、このドキュメントはPredictorデータ圧縮アルゴリズムの使用について説明します。
Table of Contents
目次
1. Introduction ...................................... 1
2. Licensing ......................................... 2
3. Predictor Packets ................................. 2
3.1 Predictor theory ............................ 2
3.2 Encapsulation for Predictor type 1 .......... 7
3.3 Encapsulation for Predictor type 2 .......... 8
4. Configuration Option Format ....................... 9
SECURITY CONSIDERATIONS .................................. 9
REFERENCES ............................................... 9
ACKNOWLEDGEMENTS ......................................... 9
CHAIR'S ADDRESS .......................................... 9
AUTHOR'S ADDRESS ......................................... 9
1. 序論… 1 2. 認可します。 2 3. 予言者パケット… 2 3.1予言者理論… 2 3.2 Predictorのためのカプセル化は1をタイプします… 7 3.3 Predictorのためのカプセル化は2をタイプします… 8 4. 設定オプション形式… 9 セキュリティ問題… 9つの参照箇所… 9つの承認… 9 議長のアドレス… 9作者のアドレス… 9
1. Introduction
1. 序論
Predictor is a high speed compression algorithm, available without license fees. The compression ratio obtained using predictor is not as good as other compression algorithms, but it remains one of the fastest algorithms available.
予言者は実施料なしで利用可能な高速圧縮アルゴリズムです。 予言者を使用することで得られた圧縮比は他の圧縮アルゴリズムほど良くはありませんが、それは利用可能な最も速いアルゴリズムの1つのままで残っています。
Note that although care has been taken to ensure that the following code does not infringe any patents, there is no assurance that it is
以下のコードがどんな特許も侵害しないのを保証するために注意しましたが、保証が全くないことに注意してください。
Rand Informational [Page 1] RFC 1978 Predictor Protocol August 1996
[1ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
not covered by a patent.
特許で、覆われません。
2. Licensing
2. 認可
There are no license fees or costs associated with using the Predictor algorithm.
Predictorアルゴリズムを使用すると関連しているどんな実施料もコストもありません。
Use the following code at your own risk.
自分の責任で以下のコードを使用してください。
3. Predictor Packets
3. 予言者パケット
Before any Predictor packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the Compression Control Protocol must reach the Opened state.
どんなPredictorパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、Compression ControlプロトコルはOpened状態に達しなければなりません。
Exactly one Predictor datagram is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 00FD (compressed datagram).
ちょうど1個のPredictorデータグラムがPPP情報分野で要約されます。そこで、PPPプロトコル分野はタイプ十六進法00FD(圧縮されたデータグラム)を示します。
The maximum length of the Predictor datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet.
PPPリンクの上に送られたPredictorデータグラムの最大の長さはPPPの情報分野の最大の長さがパケットをカプセルに入れったのと同じです。
Prior to compression, the uncompressed data begins with the PPP Protocol number. This value MAY be compressed when Protocol-Field- Compression is negotiated.
圧縮の前に、解凍されたデータはPPPプロトコル番号で始まります。 プロトコル分野圧縮が交渉されるとき、この値は圧縮されるかもしれません。
PPP Link Control Protocol packets MUST NOT be send within compressed data.
PPP Link Controlプロトコルパケットは圧縮されたデータの中で発信することであるはずがありません。
3.1. Predictor theory
3.1. 予言者理論
Predictor works by filling a guess table with values, based on the hash of the previous characters seen. Since we are either emitting the source data, or depending on the guess table, we add a flag bit for every byte of input, telling the decompressor if it should retrieve the byte from the compressed data stream, or the guess table. Blocking the input into groups of 8 characters means that we don't have to bit-insert the compressed output - a flag byte preceeds every 8 bytes of compressed data. Each bit of the flag byte corresponds to one byte of reconstructed data.
予言者は、見られた前のキャラクタの細切れ肉料理に基づいて値で推測テーブルを満たすことによって、働いています。 ソースデータを放つか、または推測テーブルによっているので、私たちはあらゆるバイトの入力のためにフラグビットを加えます、圧縮されたデータ・ストリーム、または推測テーブルからそれがバイトを検索するべきであるかどうか減圧装置に言って。 8つのキャラクタのグループに入力を妨げるのは、私たちがビット差し込みに圧縮された出力を持っていないことを意味します--フラグバイトは8バイト毎の圧縮されたデータをpreceedsします。 フラグバイトの各ビットは1バイトの再建されたデータに対応しています。
Take the source file:
ソースファイルを取ってください:
000000 4141 4141 4141 410a 4141 4141 4141 410a AAAAAAA.AAAAAAA. 000010 4141 4141 4141 410a 4141 4141 4141 410a AAAAAAA.AAAAAAA. 000020 4142 4142 4142 410a 4241 4241 4241 420a ABABABA.BABABAB. 000030 7878 7878 7878 780a xxxxxxx.
000000 4141 4141 4141 410a4141 4141 4141 410a AAAAAAA.AAAAAAA。 000010 4141 4141 4141 410a4141 4141 4141 410a AAAAAAA.AAAAAAA。 000020 4142 4142 4142 410a4241 4241 4241 420a ABABABA.BABABAB。 000030 7878 7878 7878 780a xxxxxxx。
Rand Informational [Page 2] RFC 1978 Predictor Protocol August 1996
[2ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
Compressing the above data yields the following:
上記のデータを圧縮すると、以下はもたらされます:
000000 6041 4141 4141 0a60 4141 4141 410a 6f41 `AAAAA.`AAAAA.oA 000010 0a6f 410a 4142 4142 4142 0a60 4241 4241 .oA.ABABAB.`BABA 000020 420a 6078 7878 7878 0a B.`xxxxx.
000000 6041 4141 4141 0a60 4141 4141 410a 6f41'AAAAA'AAAAA.oA000010 0a6f 410a4142 4142 4142 0a60 4241 4241 .oA.ABABAB'ラム酒入りケーキ000020 420a6078 7878 7878 0a B.'xxxxx'。
Reading the above data says:
上記のデータを読むのは言います:
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A A A A A
Guess table: A A
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A A A A A
Guess table: A A
flag = 0x6f - 6 bytes in this block were guessed correctly, 0-3, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A
Guess table: A A A A A A
flag = 0x6f - 6 bytes in this block were guessed correctly, 0-3, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A
Guess table: A A A A A A
flag = 0x41 - 2 bytes in this block were guessed correctly, 0 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: B A B A B
Guess table: A A
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: B A B A B
Guess table: A B
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6
Reconstructed data is: 0 1 2 3 4 5 6 7
File: x x x x x
Guess table: x x
これの0×60--2バイトが妨げる旗=が正しく推測された、5と6 再建されたデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: A A A A Guessテーブル: このブロックの0×60--2A旗=バイトが正しく推測された、5と6 再建されたデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: A A A A Guessテーブル: A旗は0x6fと等しいです--このブロックの6バイトが正しく、0-3に推測された、5と6 再建されたデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: Guessテーブル: A A A A A旗は0x6fと等しいです--このブロックの6バイトは正しく推測されました、0-3、5と6 再建されたデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: Guessテーブル: A A A A A旗の=0x41--このブロックの2バイトが正しく推測された、0と6 再建されたデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: B A B A B Guessは以下をテーブルの上に置きます。 このブロックの0×60--2A旗=バイトが正しく推測された、5と6 再建されたデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: B A B A B Guessは以下をテーブルの上に置きます。 B旗の=0x60--このブロックの2バイトは正しく推測されて、5と6つのReconstructedデータは以下の通りです。 0 1 2 3 4 5 6 7はファイルされます: x x x x x推測テーブル: x x
And now, on to the source - note that it has been modified to work with a split block. If your data stream can't be split within a block (e.g., compressing packets), then the code dealing with "final", and the memcpy are not required. You can detect this situation (or errors, for that matter) by observing that the flag byte indicates that more data is required from the compressed data stream, but you are out of data (len in decompress is <= 0). It *is* ok if len == 0, and flags indicate guess table usage.
ソースへの現在--そして、それが分裂ブロックで働くように変更されたことに注意してください。 データ・ストリームがそうすることができないなら、次に、ブロック(例えば、パケットを圧縮する)、「決勝」に対処するコードの中で分けられてください。そうすれば、memcpyは必要ではありません。 あなたがこの状況を検出できる、(または、誤り、さらに言えば)、フラグバイトがそのより多くのデータを示すのを観測するのが圧縮されたデータ・ストリームから必要でしたが、あなたはデータを使い果たしました(コネが減圧するlenは<=0です)。 それ、len=0であるなら、*はOKに*であり、旗は推測テーブル用法を示します。
#include <stdio.h> #ifdef __STDC__
#<stdio.h>#ifdef__STDC__を含めてください。
Rand Informational [Page 3] RFC 1978 Predictor Protocol August 1996
[3ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
#include <stdlib.h>
#endif
#include <string.h>
/*
* pred.c -- Test program for Dave Rand's rendition of the
* predictor algorithm
* Updated by: iand@labtam.labtam.oz.au (Ian Donaldson)
* Updated by: Carsten Bormann <cabo@cs.tu-berlin.de>
* Original : Dave Rand <dlr@bungi.com>/<dave_rand@novell.com>
*/
#<stdlib.h>#endif#インクルード<string.h>/**pred.cを含めてください--デーヴRandの以下によってアップデートされた*予言者アルゴリズム*の表現のためのテストプログラム 以下によってアップデートされた iand@labtam.labtam.oz.au (イアン・ドナルドソン)* カルステン Bormann <cabo@cs.tu-berlin.de 、gt;、*オリジナル: デーヴ Rand <dlr@bungi.com 、gt;、/<dave_底ならし革@novell.com>*/
/* The following hash code is the heart of the algorithm:
* It builds a sliding hash sum of the previous 3-and-a-bit
* characters which will be used to index the guess table.
* A better hash function would result in additional compression,
* at the expense of time.
*/
#define HASH(x) Hash = (Hash << 4) ^ (x)
以下の細切れ肉料理がコード化する/*はアルゴリズムの心です: * それは推測テーブルに索引をつけるのに使用される前の3としばらく*キャラクタの滑っている細切れ肉料理合計を築き上げます。 * より良いハッシュ関数は時間を犠牲にして追加圧縮、*をもたらすでしょう。 */#は細切れ肉料理(x)細切れ肉料理=(細切れ肉料理<<4)^を定義します。(x)
static unsigned short int Hash; static unsigned char GuessTable[65536];
静的な無記名の短いint Hash。 静的な無記名の炭のGuessTable[65536]。
static int
compress(source, dest, len)
unsigned char *source, *dest;
int len;
{
int i, bitmask;
unsigned char *flagdest, flags, *orgdest;
静的なint湿布(ソース、dest、len)の無記名の炭*ソース、*dest。 int len。 int i、ビットマスク;、無記名、*最もflagdestに焦げて、*最もorgdestに弛みます。
orgdest = dest;
while (len) {
flagdest = dest++; flags = 0; /* All guess wrong initially */
for (bitmask=1, i=0; i < 8 && len; i++, bitmask <<= 1) {
if (GuessTable[Hash] == *source) {
flags |= bitmask; /* Guess was right - don't output */
} else {
GuessTable[Hash] = *source;
*dest++ = *source; /* Guess wrong, output char */
}
HASH(*source++);len--;
}
*flagdest = flags;
}
return(dest - orgdest);
}
最もorgdestな=dest。 等しい..旗..すべて..推測..虐待..初めは..ビットマスク..等しい..ビットマスク..等しい..細切れ肉料理..ソース..旗..ビットマスク..推測..権利..出力..ほか..細切れ肉料理..ソース..等しい..ソース..推測..悪事..出力..炭..ソース..等しい..旗..戻る }
static int
静的なint
Rand Informational [Page 4] RFC 1978 Predictor Protocol August 1996
[4ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
decompress(source, dest, lenp, final)
unsigned char *source, *dest;
int *lenp, final;
{
int i, bitmask;
unsigned char flags, *orgdest;
int len = *lenp;
orgdest = dest;
while (len >= 9) {
flags = *source++;
for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) {
if (flags & bitmask) {
*dest = GuessTable[Hash]; /* Guess correct */
} else {
GuessTable[Hash] = *source; /* Guess wrong */
*dest = *source++; /* Read from source */
len--;
}
HASH(*dest++);
}
len--;
}
while (final && len) {
flags = *source++;
len--;
for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) {
if (flags & bitmask) {
*dest = GuessTable[Hash]; /* Guess correct */
} else {
if (!len)
break; /* we seem to be really done -- cabo */
GuessTable[Hash] = *source; /* Guess wrong */
*dest = *source++; /* Read from source */
len--;
}
HASH(*dest++);
}
}
*lenp = len;
return(dest - orgdest);
}
無記名の炭*ソース、*destを減圧してください(ソース、dest、lenp、決勝)。 int*lenp、決勝。 { int i(無記名の炭は*最もorgdestに弛みます; int lenが*lenpと等しいというビットマスク)は最もorgdestにdestと等しいです; *(旗とビットマスク)であるなら、dest=GuessTableHash; /*は正しい*/を推測します。(len>=9)である、旗が(1; i<8; i++、ビットマスク<<i=0、ビットマスク==1)のための*ソース++と等しい、GuessTableHashは*ソースと等しいです; ほかに、/*推測間違った*/*dest=*ソース++(ソース*/lenから読まれた/*)、HASH(*dest++);、len--、;、(最終的である、len); 旗..等しい..ソース..ビットマスク..ビットマスク..旗..ビットマスク..推測..修正..ほかに..中断..見える..本当..ソース..推測..間違う..ソース..読む..ソース..等しい; 戻ってください(dest、最もorgdest); }
#define SIZ1 8192
#SIZ1 8192を定義してください。
static void
compress_file(f) FILE *f; {
char bufp[SIZ1];
char bufc[SIZ1/8*9+9];
静的な空の湿布_ファイル(f)FILE*f。 bufp[SIZ1]を炭にしてください; 炭のbufc[SIZ1/8*9+9]
Rand Informational [Page 5] RFC 1978 Predictor Protocol August 1996
[5ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
int len1, len2;
while ((len1 = fread(bufp, 1, SIZ1, f)) > 0) {
len2 = compress((unsigned char *)bufp,
(unsigned char *)bufc, len1);
(void) fwrite(bufc, 1, len2, stdout);
}
}
int len1、len2。 len2は湿布((無記名の炭*)bufp、(無記名の炭*)bufc、len1)と等しいです; (len1=fread(bufp、1、SIZ1、f)>0)である間の(空)のfwrite(bufc、1、len2、stdout)
static void
decompress_file(f) FILE *f; {
char bufp[SIZ1+9];
char bufc[SIZ1*9+9];
int len1, len2, len3;
静的な空間は_ファイル(f)FILE*fを減圧します。 炭のbufp[SIZ1+9]; bufc[SIZ1*9+9]を炭にしてください; int len1、len2、len3
len1 = 0;
while ((len3 = fread(bufp+len1, 1, SIZ1, f)) > 0) {
len1 += len3;
len3 = len1;
len2 = decompress((unsigned char *)bufp,
(unsigned char *)bufc, &len1, 0);
(void) fwrite(bufc, 1, len2, stdout);
(void) memcpy(bufp, bufp+len3-len1, len1);
}
len2 = decompress((unsigned char *)bufp,
(unsigned char *)bufc, &len1, 1);
(void) fwrite(bufc, 1, len2, stdout);
}
len1=0。 等しい..減圧..無記名..炭..無記名..炭..空..空..減圧..無記名..炭..無記名..炭 (空間) fwrite(bufc、1、len2、stdout)。 }
int
main(ac, av)
int ac;
char** av;
{
char **p = av+1;
int dflag = 0;
intの主な(ac、av)int ac。 **avを炭にしてください。 炭**pはav+1と等しいです; int dflag=0
for (; --ac > 0; p++) {
if (!strcmp(*p, "-d"))
dflag = 1;
else if (!strcmp(*p, "-"))
(dflag?decompress_file:compress_file)(stdin);
else {
FILE *f = fopen(*p, "r");
if (!f) {
perror(*p);
exit(1);
}
(dflag?decompress_file:compress_file)(f);
ほかに..減圧..ファイル..圧縮..ファイル..ほかに..ファイル..等しい..出口..減圧..ファイル..圧縮..ファイル
Rand Informational [Page 6] RFC 1978 Predictor Protocol August 1996
[6ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
(void) fclose(f);
}
}
return(0);
}
(空)のfclose(f)。 } リターン(0)。 }
3.2. Encapsulation for Predictor type 1
3.2. Predictorタイプ1のためのカプセル化
The correct encapsulation for type 1 compression is the protocol type, 1 bit indicating if the data is compressed or not, 15 bits of the uncompressed data length in octets, compressed data, and uncompressed CRC-16 of the two octets of unsigned length in network byte order, followed by the original, uncompressed data packet.
1つの圧縮がデータが圧縮されているかどうかを示す1ビット、八重奏における、解凍されたデータの長さの15ビットのプロトコルタイプであり、データを圧縮して、無記名の長さの2つの八重奏のCRC-16を解凍したタイプがオリジナルがあとに続いたバイトオーダーをネットワークでつなぐので、正しいカプセル化はデータ・パケットを解凍しました。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCP Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*| Uncompressed length (octets)| * is compressed flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 means data is compressed
| Compressed data... | 0 means data is not compressed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC - 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCPプロトコル識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| 解凍された長さ(八重奏)| * 1が意味する圧縮された旗の+++++++++++++++++データは圧縮されていますか?| データを圧縮します… | 0が、データがそうであることを意味する、+++++++++++++++++を圧縮しません。| CRC--16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CCP Protocol Identifier that starts the packet is always 0xfd. If PPP Protocol field compression has not be negotiated, it MUST be a 16-bit field.
いつもパケットを始めるCCPプロトコルIdentifierは0xfdです。 PPPプロトコル分野圧縮が交渉されていないなら、それは16ビットの分野であるに違いありません。
The Compressed data is the Protocol Identifier and the Info fields of the original PPP packet described in [1], but not the Address, Control, FCS, or Flag. The CCP Protocol field MAY be compressed as described in [1], regardless of whether the Protocol field of the CCP Protocol Identifier is compressed or whether PPP Protocol field compression has been negotiated.
Compressedデータは、Address、Control、FCS、またはFlagではなく、オリジナルのPPPパケットの分野が[1]で説明したプロトコルIdentifierとInfoです。 [1]で説明されることCCPプロトコルIdentifierのプロトコル分野が圧縮されるかどうか、またはPPPプロトコル分野圧縮が交渉されたかどうかにかかわらずCCPプロトコル分野は圧縮されるかもしれません。
It is not required that any of the fields land on an even word boundary - the compressed data may be of any length. If during the decode procedure, the CRC-16 does not match the decoded frame, it means that the compress or decompress process has become desyncronized. This will happen as a result of a frame being lost in transit if LAPB is not used. In this case, a new configure-request must be sent, and the CCP will drop out of the open state. Upon receipt of the configure-ack, the predictor tables are cleared to zero, and compression can be resumed without data loss.
分野のどれかが同等の語境界に着陸するのが必要ではありません--圧縮されたデータはどんな長さのものであるかもしれません。 手順を解読してください、そして、CRC-16は解読されたフレームに合わないで、それは、湿布か減圧の過程がdesyncronizedされるようになったことを意味します。 これは、フレームの結果、LAPBが使用されていないならトランジットで失われていながら、起こるでしょう。 この場合a、要求を新しく構成するのは、送って開口状態からのCCP意志の低下であるに違いありません。 ackを構成することを受け取り次第、予言者テーブルをゼロまできれいにします、そして、データの損失なしで圧縮を再開できます。
Rand Informational [Page 7] RFC 1978 Predictor Protocol August 1996
[7ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
3.3. Encapsulation for Predictor type 2
3.3. Predictorタイプ2のためのカプセル化
The correct encapsulation for type 2 compression is the protocol type, followed by the data stream. Within the data stream is the current frame length (uncompressed), compressed data, and uncompressed CRC-16 of the two octets of unsigned length in network byte order, followed by the original, uncompressed data. The data stream may be broken at any convenient place for encapsulation purposes. With type 2 encapsulation, LAPB is almost essential for correct delivery.
タイプ2圧縮のための正しいカプセル化はデータ・ストリームがいうことになったプロトコルタイプです。 中では、データ・ストリームが現在のフレームの長さ(解凍される)です、圧縮されたデータ、そして、オリジナルがあとに続いたネットワークバイトオーダーにおける、無記名の長さの2つの八重奏の解凍されたCRC-16がデータを解凍しました。 データ・ストリームはカプセル化目的のためのどんな便利な場所でも中断しているかもしれません。 タイプ2カプセル化によって、正しい配送に、LAPBはほとんど不可欠です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCP Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*| Uncompressed length (octets)| * is compressed flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 means data is compressed
| Compressed data... | 0 means data is not compressed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*| Uncompressed length (octets)| * is compressed flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCPプロトコル識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| 解凍された長さ(八重奏)| * 1が意味する圧縮された旗の+++++++++++++++++データは圧縮されていますか?| データを圧縮します… | 0が、データがそうであることを意味する、+++++++++++++++++を圧縮しません。| CRC-16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |*| 解凍された長さ(八重奏)| * 圧縮された旗の+++++++++++++++++です…
The CCP Protocol Identifier that starts the packet is always 0xfd. If PPP Protocol field compression has not be negotiated, it MUST be a 16-bit field.
いつもパケットを始めるCCPプロトコルIdentifierは0xfdです。 PPPプロトコル分野圧縮が交渉されていないなら、それは16ビットの分野であるに違いありません。
The Compressed data is the Protocol Identifier and the Info fields of the original PPP packet described in [1], but not the Address, Control, FCS, or Flag. The CCP Protocol field MAY be compressed as described in [1], regardless of whether the Protocol field of the CCP Protocol Identifier is compressed or whether PPP Protocol field compression
Compressedデータは、Address、Control、FCS、またはFlagではなく、オリジナルのPPPパケットの分野が[1]で説明したプロトコルIdentifierとInfoです。 [1]で説明されるように圧縮されていて、CCPプロトコル分野はそうするかもしれません、CCPプロトコルIdentifierのプロトコル分野が圧縮されるかどうか、またはPPPプロトコルが圧縮をさばくかどうかにかかわらず
It is not required that any field land on an even word boundary - the compressed data may be of any length. If during the decode procedure, the CRC-16 does not match the decoded frame, it means that the compress or decompress process has become desyncronized. This will happen as a result of a frame being lost in transit if LAPB is not used. In this case, a new configure-request must be sent, and the CCP will drop out of the open state. Upon receipt of the configure-ack, the predictor tables are cleared to zero, and compression can be resumed without data loss.
どんな分野も同等の語境界に着陸するのが必要ではありません--圧縮されたデータはどんな長さのものであるかもしれません。 手順を解読してください、そして、CRC-16は解読されたフレームに合わないで、それは、湿布か減圧の過程がdesyncronizedされるようになったことを意味します。 これは、フレームの結果、LAPBが使用されていないならトランジットで失われていながら、起こるでしょう。 この場合a、要求を新しく構成するのは、送って開口状態からのCCP意志の低下であるに違いありません。 ackを構成することを受け取り次第、予言者テーブルをゼロまできれいにします、そして、データの損失なしで圧縮を再開できます。
Rand Informational [Page 8] RFC 1978 Predictor Protocol August 1996
[8ページ]RFC1978予言者プロトコル1996年8月の情報の底ならし革
4. Configuration Option Format
4. 設定オプション形式
There are no options for Predictor type one or two.
Predictorタイプ1かtwoのためのオプションが全くありません。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC
1661, July 1994.
[1] シンプソン、W.、「二地点間プロトコル」、STD51、RFC1661、1994年7月。
[2] Rand, D., "The PPP Compression Control Protocol (CCP)",
RFC 1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[2]底ならし革。
[3] Rand, D., "PPP Reliable Transmission", RFC 1663,
July 1994.
[3] 底ならし革、D.、「pppの信頼できる送信」、RFC1663、1994年7月。
Acknowledgments
承認
The predictor algorithm was originally implemented by Timo Raita, at the ACM SIG Conference, New Orleans, 1987.
予言者アルゴリズムはACM SIGコンファレンス、ニューオリンズ、1987年に元々、ティモRaitaによって実行されました。
Bill Simpson helped with the document formatting.
ビル・シンプソンはドキュメント形式で助けました。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Karl Fox Ascend Communications 3518 Riverside Drive, Suite 101 Columbus, Ohio 43221
カールフォックスはオハイオ コミュニケーション3518リバーサイド・ドライブ、Suite101コロンブス、43221を昇ります。
EMail: karl@ascend.com
メール: karl@ascend.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Dave Rand Novell, Inc. 2180 Fortune Drive San Jose, CA 95131
Driveサンノゼ、デーヴ底ならし革ノベルInc.2180Fortuneカリフォルニア 95131
+1 408 321-1259 EMail: dave_rand@novell.com
+1 408 321-1259 メールしてください: dave_rand@novell.com
Rand Informational [Page 9]
底ならし革情報です。[9ページ]
一覧
スポンサーリンク
