Again I want to clarify this point: the issue is in the way ZLIB is used by OpenSSL, not in ZLIB itself. The compressor's state is built and destroyed on every record because OpenSSL uses ZLIB's compress() call, which in turn calls the lower-level deflateInit(), deflate() and deflateEnd() functions.
This ensures that the records are compression-independent from one another, and the initial question that started this thread was about the existence of any requirement in the definition of SSL that required such independence. Most people discussing this point here do not believe there is such a requirement, but I am not sure if we have a definitive opinion on this. Some standards body will have to address that. One thing is sure though: for specific applications where client and server are under the control of the same developers, it does make sense to use ZLIB differently when it is definitely known that the underlying protocol is indeed reliable. That is why I am currently testing a very small addition to OpenSSL's compression methods that I called streamzlib (I am considering another name suggested yesterday on this mailing list). Some preliminary tests with ZLIB showed that I can go from 2:1 compression factor to 6:1. For completeness I must also say that for specific applications, compression can be done just before and outside of the OpenSSL library. My personal decision to push it down there is to avoid adding another encapsulation layer in that part of our code that is written in C. Now when compression within SSL matures, it will be necessary to have more control over the compressor's operation than just turning it on. In ZLIB you have the choice of 10 compression levels which trade-off between compression quality and speed of execution. There are other options that you could set, such as the size of the dictionary that you use. Future compression methods supported by SSL will probably have their own different set of options. All this will be an excellent subject of discussion in some SSL standard committee. Cheers, Eric Le Saux Electronic Arts -----Original Message----- From: Howard Chu [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 9:01 PM To: [EMAIL PROTECTED] Subject: RE: OpenSSL and compression using ZLIB > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Le Saux, Eric > In the current implementation of OpenSSL, > compression/decompression state is > initialized and destroyed per record. It cannot possibly > interoperate with > a compressor that maintains compression state across records. The > decompressor does care, unfortunately. This is surprising. I haven't looked at the code recently, but my experience has been that a special bit sequence is emitted to signal a dictionary flush. I haven't tested it either, so if you say it didn't work I believe you. But plain old LZW definitely does not have this problem, the compressor can do whatever it wants, and the decompressor will stay sync'd up because it detects these reset codes. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
