[PATCH 0/5] RFC: Multicast and filtering features on AF_UNIX

[Alban Crequy]

Le Sat, 2 Oct 2010 01:21:01 +0200,
Lennart Poettering <mzqohf at 0pointer.de> a écrit :

> I am not entirely sure how this maps to D-Bus. First of all, the
> destination/path/interface/member tuple i don't really see as a
> "set".

I got some numbers about what kind of match rules applications uses:

* SESSION BUS
   2399 type,interface,member,path,sender,arg0
   2346 type,interface,path,sender
     42 type,interface,member,arg0
     15 type,interface,member
     12 type,interface,sender
     10 interface,member,sender
      8 type,interface,member,path,sender
      5 type,path (gnome bug #631126)
      3 type,interface,path (GNOME SessionManager)
      2 type,interface,member,sender

* SYSTEM BUS
    338 type,interface,path,sender
    336 type,interface,member,path,sender,arg0
     15 type,path,sender
     11 type,member,sender,arg0
     10 type,interface
      6 type,interface,member
      4 type,interface,member,sender
      2 type,interface,path
      2 type,interface,member,arg0

- All rules containing the "arg0" criteria are about the
  NameOwnerChanged signal. Applications are using various syntax for
  that signal (some filter on the path, some don't, etc.)

- If NameOwnerChanged rules are not counted, 98% of the rules on the
  session bus (90% on the system bus) use the tuple
  (type, interface, path, sender). So I think using that tuple makes
  sense.

> However, the number of matches per client can get very high
> (i.e. some clients add one for each object they are interested in),
> and hence it might make sense to still use bloom filter here, but
> encode them in the BPF and simply include precalculated hashes in the
> packet header of the 4 individual strings and then test those hashes
> against the bloom filters in the BPF.

So in udev, the hashes is in the BPF and the bloom set is in the
incoming packet. With D-Bus, the hashes should be in the incoming
packets and the bloom sets should be in the BPF. I agree with that.

I was just pointing out that we cannot have 1 bloom set per field we
care about (1 for the path, 1 for the interface, etc). Consider the
scenario where the application has 2 match rules:
1. type1,interface1,member1
2. type1,interface2,path1,sender1
With the 2 match rules, the 3 bloom set for member, path and sender
would need to be 0xffffffff to let everything pass because the filter on
member1 makes sense only with interface1.

So we need to define hashes function not for individual fields but for
some set of fields. Given the numbers I got, we can have 4 new hash
fields in D-Bus message:
1. hash of arg0 if it is a NameOwnerChanged signal only
2. hash of the tuple (type,interface,path,sender) because almost all
   match rules consider this tuple.
3. hash of the tuple (type,interface,member) for a few rules
4. hash of the tuple (type,interface,sender)

The BPF can contain 4 bloom sets of match rules. Each match rule can be
inserted in one of the 4 sets. A messages can pass if it matches at
least one of the 4 bloom filters. With this choice of tuples, we cover
most of the match rules. If there is a rule that cannot be inserted in
one of the 4 filters, the dbus binding can implement a BPF that accepts
all packets (and the application should probably be fixed).

Alban