Using Ingo Rammer's "Extended .NET Remoting" as my basis, I've added a
client-side compression sink after my BinaryClientFormatterSink and a
server-side compression sink before my BinaryServerFormatterSink. The
compression / decompression routines each return a MemoryStream.

On the server-side, when passing my decompressed MemoryStream to the
BinaryServerFormatterSink (via ProcessMessage), multiple .NET CLR
exceptions are thrown, according to the Performance Monitor. If I
eliminate compression from the process and, in my compression sink,
just write the incoming requestStream (type =
TCPFixedLengthReadingStream) to a MemoryStream, I still get the .NET
CLR exception when passed to the BinaryServerFormatterSink. If I
eliminate the MemoryStream entirely and simply pass through the
TCPFixedLengthReadingStream, there's no exception.

When compressing (which, in effect, is the conversion of a
ChunkedMemoryStream to a MemoryStream), I do not get any exceptions.

I suspect that the BinaryServerFormatterSink is expecting the
extremely stripped-down stream of type TCPFixedLengthReadingStream and
choking when it gets the MemoryStream. Yet I haven't seen a single
posting on the Web that addresses this issue.

Has anyone encountered this? We're concerned because under high
usage, you can see the .NET CLR exceptions escalate at an alarming
rate, which clearly is not what we want. Suggestions?

P.S. I'm using Framework 2.0. Also -- I can post some sample code, if
necessary.