On Wed, Jun 16, 2021 at 12:43 PM Jason Hihn <jasonh...@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 <https://cloud.google.com/pubsub> (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. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oMDq_q9tNK53U4Hqyp%3Dc2RtNwA6K8SHwuSopNOGinVM6Q%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
