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

[Lennart Poettering]

On Fri, 01.10.10 19:44, Alban Crequy (alban.crequy at collabora.co.uk) wrote:

> Indeed, it is about 7 lines of code to add the support of socket
> filters in AF_UNIX :)
> 
> http://git.collabora.co.uk/?p=user/alban/linux-2.6.35.y/.git;a=commitdiff;h=7d5116bc34922c51e6ef8db2f4d8e69250f06cc2;hp=9511f0d2731603afe6a50c1ed866ce1e3fc4b2b0
> 
> It makes sense to have socket filters on SOCK_SEQPACKET because it
> preserve the packet boundaries. And it does not cost anything to add it
> to SOCK_STREAM too.

Nice!

While you are at it. Would be awesome to have SO_TIMESTAMP and
SO_TIMETAMPNS support on AF_UNIX datagrams too. It might have some value
for D-Bus in regards of profiling, but especially in some other use
cases this could be very useful (think of syslog, where we could exact
timestamps for messages, without haveing to rely on the second
granularity timestamps in the syslog msg itself...). My superficial
reading through the code tells me that this might actually be a 2line
patch, but I am bit too lazy to sit down to actually do this...

> If match rule implementation in dbus-daemon is replaced by socket
> filters in the kernel, the kernel would need to check n socket filters,
> where n is the number of D-Bus peers. I'm not sure whether
> the dbus-daemon implementation or socket filters in kernel would be
> better.
> 
> If a D-Bus connection has 4 match rules (it looks a reasonable pattern):
> - type=type1, interface=iface1, member=member1
> - type=type1, interface=iface1, member=member2
> - type=type1, interface=iface2
> - type=type1, interface=iface3
> 
> We could imagine to have 2 different bloom filters (with 2 new fields
> in the headers):
> 
> 1. One to represent the set of match rules containing a type and an
>    interface (the hash function will take type+interface as input)
> 
> 2. One to represent the set of match rules containing a type, an
>    interface and a member (the hash function will take type+interface
>    +member as input)
> 
> And the socket filter will let a message pass if it passes any of the
> bloom filters.

A bloom filter tests a word against a dictionary set. In libudev this is
used in a way that to each netlink message can be tagged with a number
of strings, and the bloom filter is then calculated from all this tags
and inserted into the message. The BPF then checks the tag the app is
interested in against the bloom filter and hence the set of tags of a
particular message. This is an appropriate choice here, since clients
usually are interested only in very few tags, but devices might have a
number of them.

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

Lennart

-- 
Lennart Poettering - Red Hat, Inc.