Clarification on some bus behaviour

[Thiago Macieira]

Em Quarta-feira 08 Setembro 2010, às 12:59:56, Alban Crequy escreveu:
> 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

Thanks for the pointer. I used a simple rule there because I know no one else 
can be sender='org.freedesktop.DBus'.

I assumed (wrongly, apparently) that a simpler rule would be a faster match.

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

The outgoing message is not the issue.

The problem is the incoming one. On incoming messages, the sender is always 
the unique connection. So I need to know what sender to expect in messages 
that come from the bus itself.

The way QtDBus works is that, when you connect a signal with sender="foo", it 
will do three things:
	1) add a match rule with sender='foo'
	2) start listening for the NameOwnerChanged signal with arg0='foo'
	3) call GetNameOwner('foo')

That's why you saw in my trace that something happened in-between add_match 
for NameAcquired and NameLost.

Internally, the binding keeps an associative map between all names that it's 
listening to signals from and their current owners. When a signal message 
comes from a particular owner, it needs to check whether that connection 
currently owns any of the watched names.

-- 
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/39b8123d/attachment.pgp>