Le Saux, Eric wrote:
You then die from the latency in the inflation/deflation routines. You have to flush the deflater for each block, and depending on how you do it your performance is the same as deflating each block separately.
I am trying to understand why ZLIB is being used that way. Here is what gives better results on a continuous reliable stream of data:
1) You create a z_stream for sending, and another z_stream for receiving.
2) You call deflateInit() and inflateInit() on them, respectively, when the communication is established.
3) For each data block you send, you call deflate() on it. For each data block you receive, you call inflate() on it.
4) When the connection is terminated, you call deflateEnd() and inflateEnd() respectively.
...
But by far, the main advantage is that you can achieve good compression even for very small blocks of data. The "dictionary" window stays open for the whole communication stream, making it possible to compress a message by reference to a number of previously sent messages.If you do a Z_SYNC_FLUSH (iirc), it blows the dictionary. This is intentional, since you can restart the inflater at every SYNC mark.
I thought there was also a mode to flush the buffer (including any necessary padding for partial bytes) but not blowing the dictionary, but I'm not sure how portable it is.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
