Clarification on some bus behaviour

[Alban Crequy]

Le Wed, 8 Sep 2010 11:56:13 +0200,
Thiago Macieira <thiago at kde.org> a écrit :

> Hello all
> 
> While trying to profile the QtDBus binding on an ARM board (yes, I
> have to deal with those too), I found out that the binding spends 18
> ms during the connection startup doing the following:
> 
> dbus_bus_add_match("destination='insert my own unique connection
> here'");
> dbus_bus_add_match("type='signal',sender='org.freedesktop.DBus',member='NameAcquired'");
> dbus_bus_add_match("type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0='org.freedesktop.DBus'");
> blocking call to GetNameOwner("org.freedesktop.DBus")
> dbus_bus_add_match("type='signal',sender='org.freedesktop.DBus',member='NameLost'");
> 
> Now, the interesting thing is that, with the reference implementation
> of the dbus-daemon, I *know* that all of the above are useless. These
> calls are there because my reading of the spec tells me that they are
> necessary.

I agree that they are useless.

But if they were useful, it would be better for performances to always
specified the interface in the 2nd and 4th match rules. Dbus-daemon
stores the match rules in a hash table keyed by interface. Match rules
without an interface are stored separately and needs to be checked
against every message and it slows down the routing. See this bug for
more benchmarks: https://bugs.freedesktop.org/show_bug.cgi?id=23117

> So, I have three questions that need clarification:
> 
> 1) Is the application allowed to assume that the bus will send all
> messages that have this connection as a destination, without having
> to add a match rule for it? In other words, can I drop that first
> add_match above?
> 
> I would think that the answer here is Yes. This rule should be
> implicit. There's also a race condition here, if this weren't the
> case: another process could send my application a message at the
> moment that my unique name appeared on the bus, but before I had a
> chance to add the rule. If the rule weren't present, the message
> would not be delivered.
> 
> Another aspect is that the caller has the guarantee from the bus that
> any directed message (anything but a signal) will either:
>  a) be delivered to exactly one (non-eavesdropping) destination
>  b) be returned with org.freedesktop.DBus.Error.ServiceUnknown
> 
> If a connection is allowed to exist without the rule for its
> destination, directed messages could disappear into the ether...

I agree.

> 2) Is the application allowed to assume that the bus will always send
> the NameAcquired and NameLost signals without having to add a match
> rule for it? In other words, can I drop the second and fourth
> add_match calls above?
> 
> I would think that the answer here is also Yes.
> 
> These two signals are special in that they are the only kinds of
> directed signals. They are delivered exclusively to the connection
> that acquired or lost a name. By the rule above that directed
> messages are always delivered to their destination, I would conclude
> that these two signals are always delivered.

I agree.

> 3) Is the application allowed to assume anything about the owner of
> the org.freedesktop.DBus name?
> 
> I think the answer here is No.
> 
> The reference dbus-daemon has the owner of org.freedesktop.DBus as
> also org.freedesktop.DBus, even though that's not a unique connection
> name. I could think of a different implementation using something
> like :0 or :1.0 as the unique name.
> 
> Therefore, I'd say that a binding must not assume anything about the
> actual owner of the bus service. That GetNameOwner call of mine must
> still be there.
> 
> However, it should be ok to assume that the name never changes
> owners, so the third add_match of mine can be skipped.

I would say it does not matter if another implementation of the bus
has an unique name like ":0" instead of "org.freedesktop.DBus" because
the binding can still send its D-Bus messages to the well-known name
"org.freedesktop.DBus" directly. The spec says:
"This method call [methods on org.freedesktop.DBus] should be sent to
org.freedesktop.DBus"

-- 
Alban