fast compressors for TLS (was lzip vs. xz)

[Patrick Pelletier]

nmav at gnutls.org wrote:

> LZ4, at http://code.google.com/p/lz4/, although I have not tested it
> a all, I'd be interested to see its interaction with TLS. The code  
> looks
> x86-centric though.

Snappy is another possible option.  (Although at least according to  
the lz4 benchmarks, snappy doesn't perform quite as well as lz4.)  I  
mention it because a co-worker of mine is using snappy to compress  
some real-time data between two machines on the same LAN, and he seems  
very happy with it.

https://code.google.com/p/snappy/

The license should be compatible, although Snappy might not be a good  
fit for gnutls, because Snappy is written in C++.  The Snappy page  
links to an independent Snappy implementation in C, but I can't speak  
for that one; my coworker is using the C++ version.

https://github.com/andikleen/snappy-c

I'm afraid I missed the beginning of the conversation.  Are you guys  
planning on standardizing this new compression method in an RFC?  (i.  
e. in the 0-63 "standards action" or 64-223 "specification required"  
compression methods)  Or is this just going to be in the "private use"  
area (224-255), only for when one gnutls instance is talking to  
another gnutls instance?  It would be nice to have a standardized,  
fast compression method implemented by more than one TLS library.   
(Compression seems to be rarely used in TLS; I assume because people  
feel zlib is too slow.)

--Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120420/97957e3b/attachment.htm>