3.1.8.2.1 Abstract Data Model

The shared state necessary to support the transmission and reception of RDP6.1-BC compressed data between a client and server requires a level-1 history buffer (HistoryBuffer) and a current offset into the history buffer (HistoryOffset). The size of the history buffer is fixed at 2,000,000 bytes. Any single block of data that is being compressed by a compliant compressor MUST be smaller in size than 16,383 bytes. The HistoryOffset MUST start initialized to zero, while the history buffer MUST be filled with zeros. After it has been initialized, the entire history buffer is immediately regarded as valid.

The shared state necessary to support the level-2 RDP 5.0 bulk compressor is described in [MS-RDPBCGR] section 3.1.8.

The level-1 compressor attempts to describe large matches (lengths of up to 16,382 bytes or offsets of up to 2,000,000 bytes) using RDP61_MATCH_DETAILS (section 2.2.2.4.1.1) structures. The matches could have been found anywhere in the 2,000,000-byte history buffer, including data realized earlier within the same block. Any such matches are encoded in the MatchDetails field of the RDP61_COMPRESSED_DATA (section 2.2.2.4.1) structure, and all remaining data is collapsed into the Literals field. The match count, details, and literals data are then presented to the level-2 compressor for more granular compression.

When compressing data, the sender MUST first check that the uncompressed data can be inserted into the level-1 history buffer at the position in the history buffer given by the HistoryOffset. If the data will not fit into the history buffer (the sum of the HistoryOffset and the size of the uncompressed data exceeds the size of the history buffer), then the HistoryOffset MUST be reset to the start of the history buffer (offset 0). If the data will fit into the history buffer, then the sender endpoint inserts the uncompressed data at the position in the history buffer given by the HistoryOffset, and then advances the HistoryOffset by the amount of data added.

If data compression results in an expansion of the data size (that is, the size of the compressed data plus any additional headers is larger than the original data size), then the original uncompressed data MUST instead be passed directly to the level-2 compressor (this is known as "compressor chaining"), and the L1_NO_COMPRESSION flag (see section 3.1.8.2.2.2) MUST be set in the level-1 compression header (see section 2.2.2.4.1).

Level-2 compression could result in an expansion of the data size. In this case, the PACKET_COMPRESSED flag (see [MS-RDPBCGR] sections 3.1.8.2.1 and 3.1.8.3) MUST NOT be set in the appropriate level-2 compression header, and the level-2 data is passed unencoded. To ensure that the history buffers in both compressors remain synchronized, the compression flags of both compressors (if both compressors are used and the L1_INNER_COMPRESSION flag (0x10) is set) MUST be sent to the receiving endpoint. If the level-2 compressor state is out of sync with the decompressor (for example, if compression is attempted but expansion occurs), then the level-2 compressor MUST reset its internal state, and the level-2 compression flags MUST include the PACKET_FLUSHED flag when the next packet with PACKET_COMPRESSED is sent, in order to cause the decompressor to reset its internal state.

The receiving endpoint checks the L1_INNER_COMPRESSION flag (0x10), and if this flag is set decompresses the input packet according to the rules outlined in [MS-RDPBCGR] section 3.1.8 for RDP 5.0 bulk compression. The output from this decompression phase then becomes the raw data for the level-1 RDP6.1-BC compressor. As a result, the receiver decompresses the data again using the level-1 decompressor and inserts the final decompressed data at the position in the level-1 history buffer given by its local copy of HistoryOffset. If a reset of the level-1 or level-2 history offset occurs, then the sender endpoint MUST notify the target receiver so that it can also reset its local state. In this way, the sender and receiver endpoints maintain an exact replica of the level-1 (and level-2) history buffer(s) and HistoryOffset(s).

The flowchart in the following figure illustrates the process of compressing data by chaining two compressors.

Chained compression with the RDP 6.1 and RDP 5.0 bulk compressors

Figure 10: Chained compression with the RDP 6.1 and RDP 5.0 bulk compressors

The flowchart in following figure describes the how the decompressors are chained during decompression.

Chained decompression with the RDP 6.1 and RDP 5.0 bulk decompressors

Figure 11: Chained decompression with the RDP 6.1 and RDP 5.0 bulk decompressors