gRPC vs DBUS?

[Jason Hihn]

I am working on a project that currently uses DBUS and I am contemplating moving it to ProtoBuf/gRPC. (C++ based) Protobuf seems to have many advantages.

As a newcomer, there are a few questions I had about gRPC:

1. DBUS provides a session bus and a system bus services. gRPC provides a server implementation of sorts.

2. The documentation seems to be written with the assumption that messages to the server are client-server conversations (like HTTP). Is there anything preventing a client from writing a message to the server, then that message is then broadcast to all connected clients? (Like DBUS)

3. Can the above question be modified to have a publish/subscribe paradigm so that not all connected clients wake up for every message (limit CPU/battery usage).

4. Are there any examples of gPRC busses? 

Thank you.

[Eric Anderson]

On Wed, Jun 16, 2021 at 12:43 PM Jason Hihn <jaso...@gmail.com> wrote:

I am working on a project that currently uses DBUS and I am contemplating moving it to ProtoBuf/gRPC. (C++ based) Protobuf seems to have many advantages.

DBus is object-oriented; you can return data (a struct) or objects (references to remote objects). It has a full type system and you can do reflection on remote objects and it helps manage reference counting. Be aware that gRPC only sends data (messages).

As a newcomer, there are a few questions I had about gRPC:

1. DBUS provides a session bus and a system bus services. gRPC provides a server implementation of sorts.

2. The documentation seems to be written with the assumption that messages to the server are client-server conversations (like HTTP). Is there anything preventing a client from writing a message to the server, then that message is then broadcast to all connected clients? (Like DBUS)

gRPC is point-to-point, where DBus traffic goes through a broker (dbus-daemon; let's ignore kdbus) which provides the bus. You can do the bus-based approach with gRPC, but you'd then need to create that broker daemon. It is certainly possible, and would be a service like Pub/Sub (although obviously not a hosted service).

Essentially I'm saying that DBus is actually several things which in gRPC would be distinct. Protobuf is the message encoding, gRPC is the communication, and some broker service actually provides the bus.

It is possible to make a bus in a peer-to-peer fashion without a central broker (maybe in spirit to zeromq; although I've not looked at their approach), but that's a slightly different discussion.

3. Can the above question be modified to have a publish/subscribe paradigm so that not all connected clients wake up for every message (limit CPU/battery usage).

I think that'd be a decision of the broker. Either the clients poll at their preferred frequency or they establish a stream to the broker to be woken up for messages. If the broker should "batch up" notifications for a stream-based watch, the client would need to inform the broker of its configuration.

4. Are there any examples of gPRC busses? 

Pub/Sub is by far the most obvious. I think if you search around a bit you'll see plenty of examples of using streams for notification. Broadcasting buses do have their own complexities, like protecting the broker if a subscriber reads too slowly, which you may find less gRPC-specific details. But those issues are normal that have to be managed when making a bus using any technology and the solution doesn't need to depend on gRPC much.