D-Bus and Bonjour service discovery
Tim Wilkinson
tim at hiveminded.com
Mon Dec 11 23:11:15 PST 2006
Time to climb back on board my local area d-bus (no smoking on the
top and please keep bikes out of the aisle):
So I've been looking at probably criteria for such a system,
particularly at how devices (laptops, desktops, openwrt boxes, etc.)
might want to connect to it. Given this I've come to a couple of
conclusions:
1. Not all boxes are created equal - there are qualititive
differences between laptops (which tend to move about), desktops
(which dont but might get turned off), servers (which dont move) and
random peripheral boxes (which don't move but aren't endowed with
enormous resources).
2. Given (1), a completely symmetric systems for building a local
area d-bus is probably a bad idea.
Of course, this inevitable leads me to the idea of a leadership based
system; that is, one where systems which want to run a 'lan-d-bus'
server can run one, but a leader (master) server is voted for and
utilized by all. This allows poorly resources devices to simply
locate and connect to the leader server (which is good) but still
provides resilience by having multiple potential servers available.
Unfortunately, this looks horribly like the master browser protocol
used in SMB, but what can I say - I think it makes sense if you
believe my conclusions. I'd still use Bonjour for locating and
electing the leader, but after that I think it can fallback on
standard d-bus-over-tcp which already exists.
Other questions remain of course - what is the complexity of the
'client lan d-bus' (the code you need to connected to the lan d-bus
but not actually be a leader for one)? Ideally it should be small
and stupid. Any complexity should be kept in the 'server lan d-bus'
which should only run where resources permit. Haven't spent enough
time on the problem to answer that yet.
Any comments?
Cheers
Tim
On Nov 22, 2006, at 3:24 PM, Jamie McCracken wrote:
> Havoc Pennington wrote:
>> The system bus never listens on TCP, to avoid a whole pile of
>> security exposure that would introduce.
>> I'm not sure why you would want to talk to apps on a remote
>> machine through a system bus instead of directly to the app?
>
> It would make life a lot easier for me if a bus of some sort could
> be used externally. At some point I would like to do network
> searching using tracker (which currently only uses the session bus)
> but it would be quite mucky having to reimplement our dbus
> interfaces using a DBusServer in P2P mode just to make it network
> transparent.
>
> Im sure there's a whole load of groupware style desktop apps that
> would benefit from being able to use a simpler bus for machine to
> machine comms too without worrying about port addresses or having
> to use lower level code.
>
> Rather than use the system bus, would it not be better to have an
> additional "external bus", which can be run as non-root?
>
>
> --
> Mr Jamie McCracken
> http://jamiemcc.livejournal.com/
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
More information about the dbus
mailing list