HeaderDelimitedMessageHandler fails when formatter does not implement IJsonRpcMessageTextFormatter

[znakeeye]

Using version 2.22.11. Trying to communicate between two processes using a named pipe. This is how both of them are initialized:

var handler = new HeaderDelimitedMessageHandler(Pipe, new MessagePackFormatter());

However, when calling a simple echo method via the proxy, I get this error:

System.NotSupportedException: 'Text encoding is not supported because the formatter "StreamJsonRpc.MessagePackFormatter" does not implement "StreamJsonRpc.IJsonRpcMessageTextFormatter".'

I dont understand this error. Can't I use the MessagePackFormatter?

[AArnott]

Hmm.... it looks like not. We ought to be able to fix this, but for our own use we always use HeaderDelimitedMessageHandler with a JSON formatter and LengthHeaderMessageHandler with the msgpack formatters. Would that work for you?

[AArnott]

FTR the fix would probably be to only write the encoding HTTP-like header if the formatter implements the text encoding interface.

[znakeeye]

In our case, anything would work. I'm looking for maximum performance (sending large amounts of data).

I got it working with LengthHeaderMessageHandler + MessagePackFormatter, but still considering all options since I'm not happy with the performance. I.e. Sending 10 million guids takes 10 seconds. Maybe that's reasonable, I don't know.

[znakeeye]

5 seconds (and low memory usage) if I batch my guids as 10k arrays. Do you have some docs on how to optimize client/server transfer speed? (I'm using named pipes if that matters.)

[AArnott]

LengthHeaderMessageHandler has better perf than HeaderDelimitedMessageHandler, that's for sure.

As for whether 10 seconds for 10 million guid's is reasonable, I don't know. There are a few places your perf could be going. You can try serializing them straight up into memory just to see how fast the serializer can do it. Then you can try sending them over StreamJsonRpc to Stream.Null just to see how fast they can be sent over StreamJsonRpc's library. Finally, it might be the transport over which your Stream is created that might be slow.