Export (0) Print
Expand All Compressing Data

The uncompressed data is first inserted into the local history buffer at the position indicated by HistoryOffset by the sender. The compressor then runs through the length of newly added uncompressed data to be sent and produces as output a sequence of literals (bytes to be sent uncompressed) or copy-tuples which consists of a <copy-offset, length-of-match> pair.

The copy-offset component of the copy-tuple is an index into HistoryBuffer (counting backwards from the current byte being compressed in the history buffer towards the start of the buffer) where there is a match to the data to be sent. The length-of-match component is the length of that match in bytes, and MUST be larger than 2 (section and If the resulting data is not smaller than the original bytes (that is, expansion instead of compression results), then this results in a flush and the data is sent uncompressed so as never to send more data than the original uncompressed bytes.

In this way the compressor aims to reduce the size of data that needs to be transmitted. For example, consider the following string.

 0         1         2         3         4

The compressor produces the following:


The <16,15> tuple is the compression of '.the.bell.tolls' and <40,4> is 'for.', <19,3> gives 'the'.

The expansion of a copy-tuple MUST use a "replicating copy". A replicating copy is implemented using the following pseudocode.

 SrcPtr = HistoryPtr - CopyOffset;
 while (LengthOfMatch > 0)
     *HistoryPtr = *SrcPtr;
     SrcPtr = SrcPtr + 1;
     HistoryPtr = HistoryPtr + 1;
     LengthOfMatch = LengthOfMatch - 1;

For example, consider the following compressed stream.


Using a replicating copy, this is correctly decompressed to


Literals and copy-tuples are encoded using the scheme described in section or (the scheme used depends on whether RDP 4.0 or 5.0 bulk compression is being used).

© 2016 Microsoft