Create a header-less StreamHandler

[haakoo]

I'm going to be using JSON RPC (v1.0) to talk to OVSDB over TCP, from a .Net Core app.

The OVSDB implementation does not have any header, so I'll have a header-less Networkstream. I was hoping to find a .Net implementation of JSON RPC that I could use without too much work, and it looks like vs-streamjsonrpc is the only .Net Standard or .Net Core library out there.

Would it be possible to create an handler for a header-less (tcp)stream?

[AArnott]

So does OVSDB literally put one JSON-RPC message directly after another? Like this:

{ "id": 1, ... }{ "id": 2 ...}

Doing such a thing isn't well supported by newtonsoft.json last I checked. It doesn't like being given partial JSON fragments to try to deserialize, so we'd end up deserializing many times as fragments get read in until we hit on what happens to be a message boundary.
When Utf8JsonReader is available I believe that makes it more natural to do so.

[haakoo]

That’s what it looks like. When I look at the traffic in Wireshark, all messages are sent in one frame (Wireshark concept!?), even when they’re very large. This in local on the computer (127.0.0.1).

I’ll try a few more scenarios today, but it looks like I’ll need a special handler that creates whole messages, using ‘}{‘ as separator.

[AArnott]

Well, somewhere in the network stack there is a frame concept, but I'm pretty sure it has a maximum size.
When you say "all messages are sent in one frame" I'm guessing you meant "each message is sent in exactly one frame". I'm not sure we can count on that frame being reliably perceivable at the .NET NetworkStream or PipeReader layer though, so I think it's best that the code can find the message boundaries even when that doesn't exist.

using ‘}{‘ as separator.

Remember that those two characters can legally appear together within a JSON string. So it's not as easy as just searching for that. You'd need to actually parse the JSON to know what context you're in (at least that you're not in a string) when you see them.

But yes, this should be doable using a MessageHandler-derived type, which I suggest you write outside this library first and you can use it immediately. If you like what you end up with, we can chat about including it in this repo if you'd like.

I'm going to close this issue for now, but if you have more questions feel free to comment more.