fast compressors for TLS (was lzip vs. xz)

[Patrick Pelletier]

address@hidden 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