Clarification on some bus behaviour

[Thiago Macieira]

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.

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...

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.

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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100908/cb6d5212/attachment.pgp>