Yes, very interesting. This is another way of adding compression to the data pipe. I have not looked at the code, but I assume that the compression state is maintained for the whole life of the communication channel, which is what gives the best results.
Have you tried to use SSL_COMP_add_compression_method() also? Cheers, Eric Le Saux Electronic Arts -----Original Message----- From: Pablo J Royo [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 12:27 AM To: [EMAIL PROTECTED] Subject: Re: OpenSSL and compression using ZLIB I have used ZLIB in several projects, but my knowledge of it itīs not as deep as yours, but...aren't you talking about a simple BIO for compressing data?.(Or,probably, I missed something in this discussion thread?) I think the BIO would mantain the context (as z_stream struct of ZLIB do) among several calls to BIO_write/read, so if you want to compress communication data you have to chain this "zBIO" with a socket BIO. Some disccusion and solution on this can be found here http://marc.theaimsgroup.com/?l=openssl-dev&m=99927148415628&w=2 I have used that to compress/cipher/base64 big files with chained BIOs (and a similar implementation of zBIO showed there) and it works, so may be it would work one step more with sockets BIOs. ----- Original Message ----- From: "Le Saux, Eric" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 26, 2002 7:24 PM Subject: RE: OpenSSL and compression using ZLIB > 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] > ______________________________________________________________________ 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]
