Google Protocol Buffers Vs JSON: C++ to C# communication

Question

I have two applications which communicate via TCP socket. For the time being, these applications are both local but in the future, the server application will run on the cloud (Amazon EC2 Instance).

The Server application is written in C++ The Client application is written in C#

I am sending an object from server to client that has the following properties:

Guid Id
uint8* ImageData

Although, I may wish to add extra properties in the future. However, I will try to keep this object as minimal as possible as latency is important here.

Now, I am currently using JSON to communicate between programs, but I was wondering about Google Protocol Buffers (GPB) because, while JSON is nice and east to work with, plus is human-readable, it does have a large overhead and from the looks of things, is causing a noticeable delay in the communications.

What I am looking for, is a more efficient method to communicate between Client and Server applications.

How do GPB's compare with JSON? Has anyone had any experience with high-performance use of GPB? Are there any other protocols which may be better suited here?

Answer 1

These references will help you.

https://google.github.io/flatbuffers/md__benchmarks.html

https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html

There is a C++ implementation for converting JSON to/from protobuf on github .

Answer 2

There're many things that we don't know:

• How big is uint8* ImageData usually?
• How do you serialise binary data to JSON
• What's available bandwidth
• What's an average and expected data rate

What I'm trying to say is that you need to worry about JSON overhead only if it matters, otherwise why to change anything. You mentioned latency, but it would be affected only if you had more data to send than your available bandwidth.

For your extremely simple case I wouldn't even use JSON but serialise it manually into binary blob, except you expect in the future your protocol will evolve significantly.