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  

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?


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