Re: [RFC] CryptoAPI & Compression

["Artem B. Bityuckiy" <dedekind@yandex.ru>]

Herbert Xu wrote:
> On Sun, Apr 03, 2005 at 01:45:58PM +0400, Artem B. Bityuckiy wrote: 
> I think the overhead could be higher.
IIUC, not. But I'll check this in practice.

> But even if it is 2 bytes
Ok, suppose.

> per block, then for 1M of incompressible input the total overhead is
> 
> 2 * 1048576 / 65536 = 32
> 
> bytes.
I've given an example why is this OK.

Shortly, because we need to reserve space only for the EOB marker of the 
*last* block (1 byte) and for the adler32 (4 bytes).

Look closer to the algorithm. It consists of 2 parts.

1. We reserve 12 bytes And compress as much as possible to the output 
buffer with Z_SYNC_FLUSH. Zlib produces:

| stream header | Block 1 (<header, 64 K, EOB>) |  -> more
| Block 2 (<header, 64 K, EOB>) | ... etc ... |    -> more
| Block N (<header, 64 K, EOB>) |                  -> more
| Last block (<header, 25K

Here zlib stops on, say 25 KiB because there is no more room for output.

2. We call zlib_deflate() with Z_FINISH and provide additional 12 bytes. 
  After zlib_deflate() has finished, the output stream is:

| stream header | Block 1 (<header, 64 K, EOB>) |  -> more
| Block 2 (<header, 64 K, EOB>) | ... etc ... |    -> more
| Block N (<header, 64 K, EOB>) |                  -> more
| Last block (<header, 25K, EOB>) | adler32 |

And all is OK.

> Actually there is a limit on that too but that's not relevant to
> this discussion.
Agreed :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.