Closed coderbyheart closed 3 years ago
Performance Comparison of Messaging Protocols and Serialization Formats for Digital Twins in IoV This article argues that protobuf is more suited for device->cloud communication than flatbuffers. Mostly due to payload size.
Yes, right, however there is no official C client, so I consider this a no go, and it looks like event the in official ones are quite big. Flatbuffers removes some of the Protobuf features, which results in more data being sent, but reduces the client size.
Protobuf (using nanopb)is already used in NCS in the alexa gadget sample: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/alexa_gadget/README.html and nanopb on its way into Zephyr as a module in a PR https://github.com/zephyrproject-rtos/zephyr/pull/33211
Nice, I know that there are issues with different implementations of protobuf not being 100% compatible in their output, so we might need to look into using https://jpa.kapsi.fi/nanopb/ also on the cloud side as well. Nevertheless these are all good links to add to the docs.
:tada: This issue has been resolved in version 13.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Explain why flatbuffer is recommended over protobuf for resource constrained devices like the nRF 9160.
https://github.com/NordicSemiconductor/asset-tracker-cloud-docs/blob/02b6db0bc363a6770b462da368c2fee2d6b5fe1b/docs/device-cloud-protocol/TransportAndData.rst#L51