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