[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Deflate issue



Slava,

Am I reading correctly that the DEFLATE decompression is dependent 
on the parameters to the compression process, i.e. an extra attribute
needs to be negotiated in order to enable the decompression process? 
For comparison, afaik, LZS has the capability to decompress a packet 
regardless of the compression parameters.

Your suggestion to negotiate a DEFLATE-specific attribute,
while doable and supported by the protocol, will have the side-effect 
of excluding that compression algorithm from the list of well-known 
algorithms, as RFC2393 defines:

   Compression Parameter Index (CPI)

        16-bit index.  The CPI is stored in network order.  The values
        0-63 define well-known compression algorithms, which require no <==
        additional information, and are used for manual setup.  The          <==
        values themselves are identical to IPCOMP Transform identifiers
        as defined in [SECDOI].   [...]                                 The values
        256-61439 are negotiated between the two nodes in definition of
        an IPComp Association, as defined in section 4.  Note: When
        negotiating one of the well-known algorithms, the nodes MAY
        select a CPI in the pre-defined range 0-63.  

In order to keep the advantages of using a well-known algorithm ID,
I'd suggest (a) modifying RFC2394 to dictate a unified approach, 
or (b) creating multiple DEFLATE IDs in the DOI, one for each option.

avram

At 01:32 PM 1/14/00 -0500, Slava Kavsan wrote:
>We discovered some Deflate implementation differences that control the
>inclusion of the Deflate
>header and Adler32 checksum.  RFC2394 makes no mention of the Deflate
>header or Adler32 checksum .  These items are redundant in the case of
>IPCOMP.
>
>It doesn't make sense to spend the time to do it as it uses bandwidth
>unnecessarily for the extra
>(8?) bytes.
>
>Unfortunately, the ability to NOT include the Deflate header and Adler32
>
>checksum is an undocumented feature of the ZLIB implementation of
>Deflate,
>which is controlled by the -15 parameter to the deflateInit2_()
>
>Sooooo... should the inclusion of the extra header and the checksum be
>controlled by another IPCOMP attribute or should we simply all change
>the way Deflate engine is initialized from:
>
>if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break;
>
>to:
>
>if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED,
>-11,
>DEF_MEM_LEVEL,  Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream)))
>break;
>
>And similar for Inflate, from:
>
>if (Z_OK != inflateInit(&d_stream)) break;
>
>to:
>
>if (Z_OK != inflateInit2_(&d_stream,  -15, ZLIB_VERSION,
>sizeof(z_stream))) break;
> 



Follow-Ups: References: