D-Bus and Bonjour service discovery

Havoc Pennington hp at redhat.com
Wed Nov 22 08:55:22 PST 2006


Hi,

Tim Wilkinson wrote:
>> The trick is that the D-Bus "bus" is very much about a central daemon. 
>> In the setup you describe, which machine is the daemon running on?
>>
> 
> That's more a 'how' than a 'should' sort of thing.  I'd be happy to 
> discuss how it can be achieved within the current d-bus model (from what 
> little I currently comprehend) , but really I'm trying to get a handle 
> on whether its a good idea at all.  Obviously the subject of networked 
> d-bus has come up before, and I'm sure it will again - the question for 
> me immediately is 'should it be done like this'.

I'm not sure I understand. The semantics and behavior of dbus afaik 
pretty much require the central daemon. Maybe you could emulate it via a 
"P2P swarm" architecture (I don't know a lot about that kind of thing) 
but it would be a completely different codebase from today's dbus and a 
whole new protocol. You could perhaps layer the current dbus API on top 
of it.

>> You could of course offer a service via something like bonjour, where 
>> the service happened to use the dbus protocol. But this would not 
>> require writing any new IPC system or library, it would just be a 
>> particular application (like music sharing or whatever you were coding).
>>
> 
> As you say, sure you could to this - but then all you're doing is using 
> d-bus as a rather useful IPC mechanism and, my understanding is, that 
> it's more than that.   What I want to find is a way of enabling d-bus on 
> a local network, and bonjour seems like an obvious choice for building 
> that bus.

I don't understand what you mean by enabling dbus on a local network, 
though. As I said, all the stuff in dbus that is more than just an IPC 
mechanism is based on a central daemon. If you coded it on a "swarm" 
architecture you might keep the library API and a similar definition of 
a "message" but your implementation and protocol would be near-100% 
different, and behavior in practice would also be a fair bit different.

>> There are some other IPC systems that offer a "P2P swarm" kind of deal 
>> for a distributed bus, but this is very different from what dbus offers.
>>
> 
> Not much into reinventing the wheel (or buying a square one with run 
> flat tires that wont fit), and d-bus is obviously *the* choice for Linux 
> right now.  What I'm looking to do is extend those concepts to a local 
> network environment.

What does this mean, though? For example, what are some use cases?

> Which brings me back to - are their plans to do this (or similar) with 
> d-bus and what are people thoughts on the subject.

While again I'm not sure I understand what you mean, to the extent I 
have a guess I don't see it as possible with today's dbus protocol or 
implementation, though perhaps you could do something "dbus like" in 
certain ways.

Havoc



More information about the dbus mailing list