⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1978.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 2 页
字号:
           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);   }   #define SIZ1 8192   static void   compress_file(f) FILE *f; {       char bufp[SIZ1];       char bufc[SIZ1/8*9+9];Rand                         Informational                      [Page 5]RFC 1978                   Predictor Protocol                August 1996       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);       }   }   static void   decompress_file(f) FILE *f; {       char bufp[SIZ1+9];       char 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);   }   int   main(ac, av)       int ac;       char** av;   {       char **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               (void) fclose(f);           }       }       return(0);   }3.2.  Encapsulation for Predictor type 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.    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                      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   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.   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.   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.Rand                         Informational                      [Page 7]RFC 1978                   Predictor Protocol                August 19963.3.  Encapsulation for Predictor type 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.    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            ...   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.   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   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.Rand                         Informational                      [Page 8]RFC 1978                   Predictor Protocol                August 19964.  Configuration Option Format   There are no options for Predictor type one or 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.      [2]   Rand, D., "The PPP Compression Control Protocol (CCP)",            RFC 1962, June 1996.      [3]   Rand, D., "PPP Reliable Transmission", RFC 1663,            July 1994.Acknowledgments   The predictor algorithm was originally implemented by Timo Raita, at   the ACM SIG Conference, New Orleans, 1987.   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   EMail: karl@ascend.comAuthor's Address   Questions about this memo can also be directed to:   Dave Rand   Novell, Inc.   2180 Fortune Drive   San Jose, CA  95131   +1 408 321-1259   EMail: dave_rand@novell.comRand                         Informational                      [Page 9]

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -