diff options
| author | Gert Doering <gert@greenie.muc.de> | 2015-10-10 18:34:49 +0200 |
|---|---|---|
| committer | Gert Doering <gert@greenie.muc.de> | 2015-10-11 10:25:06 +0200 |
| commit | 9403e3f4b510fbc4187044f31be8f7dccbde1cf1 (patch) | |
| tree | e4d0fe330a98c29b9ead343ec854891d849e3852 /src/openvpn/init.c | |
| parent | c67acea173dc9ee37220f5b9ff14ede081181992 (diff) | |
| download | openvpn-9403e3f4b510fbc4187044f31be8f7dccbde1cf1.tar.gz openvpn-9403e3f4b510fbc4187044f31be8f7dccbde1cf1.tar.xz openvpn-9403e3f4b510fbc4187044f31be8f7dccbde1cf1.zip | |
Remove support for snappy compression.
LZ4 is using less CPU at similar performance, and it is easier to
build and support for binary installs (as it does not require C++
and a C++ runtime). Since it was never supported in any formally
released OpenVPN version, just drop it again.
This leaves in the compression opcode for Snappy for documentation
purposes.
trac #617
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Arne Schwabe <arne@rfc2549.org>
Message-Id: <1444494889-28925-1-git-send-email-gert@greenie.muc.de>
URL: http://article.gmane.org/gmane.network.openvpn.devel/10251
Diffstat (limited to 'src/openvpn/init.c')
| -rw-r--r-- | src/openvpn/init.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/openvpn/init.c b/src/openvpn/init.c index c32a809..5dd8781 100644 --- a/src/openvpn/init.c +++ b/src/openvpn/init.c @@ -2379,11 +2379,11 @@ do_init_frame (struct context *c) { comp_add_to_extra_frame (&c->c2.frame); -#if !defined(ENABLE_SNAPPY) && !defined(ENABLE_LZ4) +#if !defined(ENABLE_LZ4) /* * Compression usage affects buffer alignment when non-swapped algs * such as LZO is used. - * Newer algs like Snappy and comp-stub with COMP_F_SWAP don't need + * Newer algs like LZ4 and comp-stub with COMP_F_SWAP don't need * any special alignment because of the control-byte swap approach. * LZO alignment (on the other hand) is problematic because * the presence of the control byte means that either the output of @@ -2394,7 +2394,7 @@ do_init_frame (struct context *c) * dispatch if packet is uncompressed) at the cost of requiring * decryption output to be written to an unaligned buffer, so * it's more of a tradeoff than an optimal solution and we don't - * include it when we are doing a modern build with Snappy or LZ4. + * include it when we are doing a modern build with LZ4. * Strictly speaking, on the server it would be better to execute * this code for every connection after we decide the compression * method, but currently the frame code doesn't appear to be |