Trying to compress in zlib format with low level access to the stream

Question

I'm trying to implement Microsoft specification for message.rpmsg format (here: http://msdn.microsoft.com/en-us/library/ee625343(v=EXCHG.80).aspx). The specification is weird combination of zlib compressed stream, packaged in packets. For each packet I need to put in the packet header the number of bytes in the uncompressed stream (has to be 4096, otherwise Outlook cough, despite the spec), the size of the compressed buffer, and a magic marker.

My code is in .net, and preferably I'm looking for an all managed library.

Looking at various libraries (SharpZlibLib, zlib.NET, the Microsoft Compression.Deflate namespace) - I couldn't find a publicly available entries that for each 'Write' will do: - Return the number of compressed bytes - Guaranty BYTE boundary (FLUSH_SYNC) - Ideally, without spoofing or changing too much the code

The libraries I've looked at have an Output stream from which you can read (the entire compressed stream) - but do not provide access to the packets itself.

For now, I'm using the original zlib library, and the native zlib1.dll, after many modifications to the contrib/dotzlib - however, I'd like to avoid the obvious performance and deployment hassles of my current workaround

So I'm looking for a library that will let me specify the FLUSH mode, and give me access to the size of each packet.

Also, if anyone can rate the various libraries (zlib.net, SharpZipLib seems to be the most ubiquitous - anything else?), and areas such as performance/quality/support

Thanks Much Uri

Answer 1

Untested, but using zlib.net I would have expected something like below to work; note that I'm using a MemoryStream here to avoid having to seek (since that can't be universally supported - since the block length is a maximum of 4k, I am not concerned about this at all), but if you know you can seek you could write a dummy 0 for the compressed length, then write the data, then seek backwards to update the compressed length, and seek forwards to the end again:

static void WriteBlock(Stream destination, byte[] arr, int offset, int length)
{
    using (var ms = new MemoryStream())
    {
        using (var zlib = new zlib.ZOutputStream(ms))
        {
            zlib.Write(arr, offset, length);
        }
        WriteInt32LittleEndian(destination, 0x00000FA0);
        WriteInt32LittleEndian(destination, length);
        WriteInt32LittleEndian(destination, (int)ms.Length);
        destination.Write(ms.GetBuffer(), 0, (int)ms.Length);

    }
}
static void WriteInt32LittleEndian(Stream destination, int value)
{
    destination.WriteByte((byte)value);
    destination.WriteByte((byte)(value >> 8));
    destination.WriteByte((byte)(value >> 16));
    destination.WriteByte((byte)(value >> 24));
}