[PATCH 0/5] RFC: Multicast and filtering features on AF_UNIX
alban.crequy at collabora.co.uk
Fri Sep 24 10:22:57 PDT 2010
I am working on improving the performances of D-Bus . dbus-daemon is
connected to the peers with Unix sockets and delivers D-Bus messages
according to match rules set by the peers themselves. Every D-Bus
message goes through dbus-daemon. The number of recipients if often 1
but it can be 0, 1, or more. With this architecture, dbus-daemon has to
wake up for every message on the bus and the context switches are
/--------\ unix socket /-------------\ unix socket /-----------\
| sender |------------->| dbus-daemon |------------->| recipient |
\--------/ AF_UNIX \-------------/ AF_UNIX \-----------/
Ian and I wrote a kernel module "dbus" to improve the performances (the
sources are not attached to this email but available there: ). This
is a proof-of-concept. It implements a new address family AF_DBUS,
similar to AF_UNIX, but the kernel is smart enough to deliver the
messages directly to the correct recipients, bypassing dbus-daemon. The
only change in userspace is to use AF_DBUS instead of AF_UNIX. I
compared the performances here . It is about 5000 lines of code (a
big part is duplicated from net/unix/af_unix.c).
Another possibility is to add the needed features directly in AF_UNIX
sockets (and avoid to create a new address family for D-Bus):
- some kind of BSD socket filters?
And hopefully the new features would be useful for other userspace
applications in addition to D-Bus. Wireshark could read and display
I am looking for feedback on what is the best way to do this.
The following patches implements multicast on stream Unix socket.
Applications have to enable multicast on the socket with setsockopt()
and then every packets will be delivered to all sockets connected to
the multicast address. The patches are also available on .
More information about the dbus