Rosbridge Protocol v3 - Can we make it fast and simple by default?

[EzraBrooks]

With the renewed activity on roslibjs - which is effectively the reference implementation of a client to Rosbridge - we have hit numerous frustrations with the current state of the Rosbridge protocol when it comes to performance and complexity. It is especially difficult for roslibjs as a client because JavaScript in the browser is inherently single-threaded, which means performance problems in something like the serialization layer of a library like roslib cause cascading performance problems throughout your entire application. We're looking to ameliorate that in RobotWebTools/roslibjs#1078, but I think the conversation of protocol inefficiencies will also be relevant to that fix, since it will mean sending messages to and from Web Workers (which will require serialization and encoding)

We currently support a matrix of 8 serialization/encoding pairs (which is too many):

(JSON | BSON) * (uncompressed | PNG | CBOR | CBOR-Raw)

And they all have different trade-offs that I don't think we can expect our users to evaluate for themselves.

• BSON has some upsides in terms of encoding NaN and inf in ways JSON doesn't support, but it's untested and unsupported (Drop the support for BSON #1105) and has largely fallen out of favor in the greater ecosystem because it's actually less space-efficient than JSON for some data types.

• PNG is bandwidth-efficient but is still JSON under the hood which means it doesn't actually solve the performance overhead problem - a point cloud encoded in a PNG will still take multiple seconds to parse because it's still slow ol' JSON.

• CBOR is pretty neat, I don't really have any gripes with it, but I also don't have much prior exposure to it.

• Why do we provide both CBOR and CBOR-Raw?

I think we should design a Rosbridge Protocol v3 that chooses a good algorithm out of the box (CBOR? MessagePack?) and reduces the support surface here from 8 to 1.

[bjsowa]

Regarding the PNG compression, it baffles me that we first encode the message as JSON, turning binary data into base64 strings, then compress it using PNG and encode the resulting data using base64 again, before packing it into another JSON. Seems like such a waste of space.

[drewhoener]

For my 2 cents I think fragments in particular should be evaluated. If a message is large enough to be fragmented it means that the resulting JSON parse will take even longer once all the fragments are assembled.
IMO the data in a fragment should just be a cbor encoded object by default, applications can read into a buffer and do a fast cbor decode as opposed to having to parse through JSON syntax

Ezra seems fond of MsgPack which I'm not against, but it's similar enough to CBOR that it doesn't make much sense to switch. Also CBOR is a controlled standard, not sure where MsgPack falls

[EzraBrooks]

msgpack is trendy but in reality I think I'd select CBOR since we're already using it.

agreed that fragmentation also needs evaluated. it should be always-on or nonexistent instead of optional imo. Why would you want to disable fragmentation in a protocol with guaranteed data reception?

[drewhoener]

Further complicating this, seems like RosBridge doesn't support receiving CBOR messages, only sending them?
Trying to build out some improvements on the RosLibJS side and there's a lot of gains to be had by passing around CBOR arrays in web workers, but it'll all have to go back to JSON on the way out unless something changes.
#1083 also mentions this

[EzraBrooks]

🤦🏻 I guess we should probably fix that on the bridge side

[EzraBrooks]

Relatedly, I just realized that if we make a newer version of roslibjs default to requesting CBOR from a compatible rosbridge for everything it can, it'll fix the problems with ints vs floats vs NaNs vs infinities that has been talked about elsewhere, since CBOR is IEEE 754 compliant unlike JSON.

[ikwilnaarhuisman]

Maybe an interesting next step could be support for protocol buffers.