Last post Apr 17, 2014 05:55 AM by damienBod
Mar 24, 2014 04:04 PM|Bryce|LINK
Is it possible to swap out the default json serializer for the json.net BSON one? I realize this would be changed on both server and client, but I'm unsure on where exactly this would be done if its possible?
We are transmitting alot of image data over the hub, and the conversion of a byte to base64 feels like it would be a waste of bandwidth, so we wanted to look into BSON for this.
Mar 25, 2014 01:14 AM|damienBod|LINK
NO, you can replace the JSON serializer but not the serializer type due to the client. This is a feature I would like to see as well. I would like to use the Protobuf-net serializer instead of JSON for the same reasons.
Mar 25, 2014 01:51 AM|Bryce|LINK
Well that sucks, perhaps I'll open an issue on github to request the feature to provide a custom serializer. I was also looking into protobuf for my needs also, looked promising. May take a look at the code and see how much work it would be to fork it
and impliment the change ourselves after we do some testing.
Mar 25, 2014 04:00 AM|damienBod|LINK
Opening an issue is a cool idea.
Just for info, BSON doesn't provide much of an improvement compared with JSON. You could use ServiceStack JSON on the server/Hub side as this is faster in 'write' but slower in 'read'. BSON is not really faster in read, or write and the size is about the
same as JSON serialization.
Apr 16, 2014 10:15 PM|Bryce|LINK
I spent some time creating a websocket server in owin that talks protobuf, and while the messages are smaller and faster to serialize in .net, the browsers ability to JSON.parse is incredibly fast compared any js libraries that can decode protobuf. For
us, message size is important but with the amount of messages we are going to be sending back and forth the abilitiy to encode/decode those in the client as fast as possible is more important.
The main concern for us is that we are passing around alot of byte arrays, and wanted to preserve them in the client as such when they arrive instead of a base64 string. But as you can see here the browser is just so optimized around json parsing http://jsperf.com/rdpprotoperf/3 and
dealing with that base64 string. Some time could probably be spent in those js libraries to optimize their protobuf decoding, but alot of work would need to be done to catch up.
Its been interesting to dig into Signalr to see whats it really doing under the hood though which was usefull, and we will probably keep that work as we have some need around hosting websockets at dynamic endpoints for authorization issues.
Apr 17, 2014 05:55 AM|damienBod|LINK
Thanks for this info