Packet Encoding and Compression

Bencode vs Rencode

Each packet exchanged between the client and server is encoded using one of those two stream encoders:

• The old ​bencode mode (see ​Bencode on wikipedia): a modified bencoder which supports non string keys in dictionaries, and support for unicode
• The newer/faster ​rencode mode, based on ​this version with minor tweaks/fixes

This allows various languages to implement the xpra protocol, specifying which encoder they want to use (bencode is more widely available than rencode).

Pixels and Icons

Note: all window pixels, icons and cursors are sent using dedicated picture encodings and bypass the stream encoder completely (for speed).

The only exception to this rule is the RGB encoding, which will use the stream encoder on the raw pixels.

Compression

The compression level can be specified via the command line ("-z LEVEL" or "--compress=LEVEL").

Here is what the LEVEL does:

• 0 means no compression at all and is useful when bandwidth is no issue but latency is
• 1 is the best trade-off and will compress everything but without making too much of an effort
• values of 2 and above increase the compression (CPU usage and latency will increase) and should rarely be needed - the picture encoding used is much more important

lz4 vs zlib

As of version 0.11.0, xpra supports ​lz4 compression and will use it instead of the default ​zlib when LEVEL is set to 1 and both ends support the compression mode. More information here: #443
There is a benchmark test you can run to measure the performance of lz4 compared to zlib. On average, lz4 is at least 10 times faster than zlib on its fastest setting for regular packets, and even faster for RGB data (close to 20 times faster than zlib)
We have an python-lz4.spec rpm specfile and RPMs should be available for Fedora and CentOS 6.x in the RPM repository.