Message compression is a functionality that allows messages sent through FioranoMQ to be compressed when sending and decompressed, to their original size, prior to delivery to consumers.
Compression has the advantage of improving performance. Less bandwidth is used during message transfer. Memory and storage requirements on the server are reduced as well. This function is important for performance-sensitive applications operating over WAN links. Many data compression implementations have been developed in the past, of which the Zlib implementation is, by far, the most significant one. The Fiorano compression implementation is based on Zlib Compressed Data Format Specification Version.
This specification defines a lossless compression data format. The advantages of this compression implementation, as per specification, are:

• It is independent of CPU type, operating system, file system and character set.
• Can be produced or consumed by an arbitrarily long sequentially presented input data stream, using a bounded amount of intermediate storage.
• Can be implemented readily in a manner not covered by patents.
• Can use a number of different compression methods.

In FioranoMQ C RTL, the Zlib implementation is provided using the zlib general purpose compression library. The zlib compression library provides in-memory compression and decompression functions. This implementation provides 'deflate' and 'inflate' mechanisms using different compression levels and different compression strategies.

• Compression level is the amount of compression required.
• Compression strategy is the actual compression method used.

The default strategy uses a combination of the LZ77 algorithm and Huffman coding.

Message Compression Characteristics

FioranoMQ provides message compression on a 'per message' as well as on 'per destination' basis. In 'per message' compression, clients can enable or disable compression for each message. In 'per destination' compression, all messages sent to a particular destination (topic or queue) are compressed. Client applications can choose compression levels and strategies from Zlib specifications.
The available options are:

• Z_NO_COMPRESSION
• Z_BEST_SPEED (fastest compression)
• Z_BEST_COMPRESSION
• Z_DEFAULT_COMPRESSION

There are ten possible compression levels (0-9) available, where Z_BEST_SPEED is defined as 1 and Z_BEST_COMPRESSION is defined as 9.
The possible values for the compression strategy are:

• Z_FILTERED: Compression strategy best used for data consisting primarily of small values with random distribution. It enforces more Huffman coding and less string matching.
• Z_HUFFMAN_ONLY: Enforces more Huffman coding.
• Z_RLE: Limits match distances to one (run-length encoding). Z_RLE is designed to be almost as fast as Z_HUFFMAN_ONLY, but give better compression for PNG image data.
• Z_FIXED: Prevents the use of dynamic Huffman codes, allowing for a simpler decoder for special applications.
• Z_DEFAULT_STRATEGY: This uses a combination of the LZ77 method and Huffman coding.

Compression support provided helps a client application to decide on the optimum compression level and strategy by providing APIs to check compression ratios of messages sent and/or received. Compression involves compressing only the payload of the message and not its JMS header.
Refer the samples in PTP/Message Compression & PubSub/Message Compression on enabling compression on PerMessage or PerDestination basis in the application code.