[SignalR] Allow Pre-serialized data in order to avoid duplicated serialization

[emanuel-v-r]

Is your feature request related to a problem? Please describe.

It seems that currently is not possible to send to signalR clients directly a JSON string or even JSON byte encoded. That in some systems could lead to duplicated serialization and therefore degradation of performance.

Describe the solution you'd like

I would like to be able to send a JSON string or JSON byte encoded directly to SignalR Clients

Additional context

• I have tried to use ArraySegment<byte> as described here https://github.com/SignalR/SignalR/issues/1546, but with no luck
• Seems that it was requested before here https://github.com/dotnet/aspnetcore/issues/5339

[BrennanConroy]

Could you describe your scenario and why are you pre-serializing data?

Note: This is somewhat difficult because we support multiple serialization formats (messagepack and json).

[emanuel-v-r]

The scenario described here https://github.com/dotnet/aspnetcore/issues/5339 is really similar to my scenario. I have serialized json in my message bus, with this feature I could consume this json and just bypass it to signalR clients, instead of deserializing and then let signalR serialize it again. I guess that we could have some method like SendRaw(byte[] data) that would assume that data is serialized already. Or just implemente it like here https://github.com/SignalR/SignalR/issues/1546

[davidfowl]

The thing that ASP.NET Core SignalR supports that ASP.NET SignalR doesn't is that client can be connected to the same hub with different protocols. So one client can be message pack and another can be json and when you send a message it'll serialize to the right formats for the right clients. With this change that would break and that's why we haven't pursued it as yet.

[emanuel-v-r]

Got it, it is tricky for sure considering that. I guess that a possible solution would be to use instead SendRaw(Serialization.Json, byte[] data), then if the client is expecting message pack, internally we would convert it from JSON directly to message pack serialization . The problem would be if in future you decide to support more serialization types that could not be so trivial to do this type of conversions.

[NickLarsen]

+1

All our ws messages pass through a message queue as well and we have full control over the client implementations of our app so we're happy to define the message serialization globally. In our case it would be great if the ws relay could be fully agnostic to the shape of the message being sent as well since it's just a relay, and hence wanting to just pass along the already serialized message instead of relying on dynamic serialization twice.

For the time being it's not a make or break; our ws traffic is pretty low overall so we're not bottlenecked by this at all.

[pankof]

Have you reconsidered this change? It is pretty common scenario for high traffic app to receive message through a Queue and then push them to clients.

[HashPong]

@BrennanConroy that sendraw would be nice as i have pre-serialized data of 250 rows, that will prob be accessed 1k+ times a sec, that's a huge cpu load that would be optimised