interprocess communication (IPC) mechanism is used extensively by
Linux desktop environments and applications, but it suffers from
less-than-optimal performance. While that problem may not be so noticeable
on desktop-class systems, it can be a real issue for smaller and embedded
the years there have been a number of attempts to add functionality to the
kernel to increase D-Bus performance, but none have passed muster. A recent proposal to add multicast functionality to
Unix sockets is another attempt at solving that problem.
D-Bus currently relies on a daemon process to authenticate processes and
deliver messages that it receives over Unix sockets. Part of the
performance problem is
caused by the user-space daemon, which means that messages need two trips
through the kernel on their way to the destination (once on the way to the
and another on the way to the receiver). It also requires waking up the
daemon and an "extra"
transition to and from kernel mode. Putting D-Bus message handling
directly into the kernel would eliminate the need to involve the daemon at
all. That would eliminate one of the transitions and one of the copies,
If all of the D-Bus messages were simply between pairs of processes, Unix
sockets could potentially be used directly between them. But there is more
than that. Processes can register for certain kinds of events they wish to
receive (things like USB devices being attached, a new song playing, or
battery status changes
for example), so a single message may need to be multicast to multiple
receivers. That is part of what the daemon mediates.
Earlier efforts to add an AF_DBUS
socket type (and associated kdbus module) to handle D-Bus messages in
weren't successful because kernel hackers were not willing to add the
complexity of D-Bus routing. The most recent
proposal was posted by Javier Martinez Canillas based on work from Alban
Créquy, who also proposed the AF_DBUS feature. It adds
Unix (i.e. AF_UNIX) sockets, instead,
packet filters so that receivers only get the messages they are interested
in. That way, the routing is strictly handled via multicast plus existing
As described in Rodrigo Moya's blog
posting, there are a number of reasons that a D-Bus optimization can't
use the existing mechanisms in the kernel. Netlink sockets would seem to
be one plausible alternative, and there is support for multicasting, but
D-Bus requires fully reliable delivery even if the receiver's queue is
full. In that case, netlink sockets just drop packets, while D-Bus needs
the sender to block until the receiver processes some of its messages. In
addition, netlink sockets do not guarantee the ordering of multicast
messages that D-Bus requires.
Another option would be to use UDP multicast, but Moya (and Canillas) seem
skeptical that it will perform as well as Unix socket multicast. There is
also a problem for devices that do not have a network card, because the
lo loopback network device does not support multicast. Moya also
notes that a UDP-based solution suffers from the same packet loss and
ordering guarantee problems that come with netlink sockets.
So, that left Créquy and others at Collabora (including Moya, Canillas, and
others) to try a different approach. Créquy outlines
the multicast approach on his blog. Essentially, both SOCK_DGRAM
and SOCK_SEQPACKET socket types can create and join multicast
groups which will then forward all traffic to each member of the group.
Datagram multicast allows any process that knows the group address to join,
while seqpacket multicast (which is connection-oriented like a
SOCK_STREAM but enforces message boundaries) allows the group
creator to decide whether to allow a particular group member at
As Moya described, a client would still connect to the D-Bus daemon for
authentication, and would then be added to the seqpacket multicast group
for the bus.
The daemon would also attach a packet filter that would eliminate any of
the messages that the client should not receive. One of the patches in the
set implements the ability for the daemon to attach a filter to the remote
endpoint, so that it would be in control of which messages a client can see.
The idea is interesting, but so far comments on the netdev mailing list
have been light. Kernel network maintainer David Miller is skeptical that the proposal is better than
having the daemon just use UDP:
My first impression is that I'm amazed at how much complicated new
code you have to add to support groups of receivers of AF_UNIX
I can't see how this is better than doing multicast over ipv4 using
UDP or something like that, code which we have already and has been
tested for decades.
Cannilas responded by listing some of the
reasons that UDP multicast would not serve their purposes, but admitted
that no performance numbers had yet been gathered. Miller said that he
will await those numbers before reviewing the proposal further, noting: "In many cases TCP/UDP over
loopback is actually faster than AF_UNIX.".
Even if UDP has the needed performance, some solution would need to be
found for the packet loss and ordering issues. Blocking senders due to
inattentive receivers may be a hard sell, however, as it seems like it
to denial of service problems, no matter which socket type is used. But
it is clear that there is a lot of interest in better D-Bus
performance. In fact, it goes well beyond just D-Bus as "fast" IPC
mechanisms are regularly proposed for the kernel. It's unclear whether
multicasting for Unix sockets is suitable for that, but finding a way to
speed up D-Bus (and perhaps other IPC-using programs) is definitely on some
Comments (13 posted)
To be fair, it also omits one of SystemD's greatest strengths:
Roman numeral-compliant project naming. System D is obviously way
better than System V.
-- Steve Langasek
Comments (1 posted)
is a framework
for packet generation and capture from user space; it claims to be
efficient to a point where it can saturate a 10Gb line with minimal system
load. It is available under the BSD license. A
version for Linux
is now available alongside the FreeBSD port.
"This is a preliminary version supporting the ixgbe and e1000/e1000e
driver. Patches for other devices (igb, r8169, forcedeth) are untested and
probably not working yet. Netmap relies on a kernel module (netmap_lin.ko)
and slightly modified device drivers. Userspace programs can use the native
API (documented in netmap.4) or a libpcap emulation library.
Comments (4 posted)
Nntpgit is an NNTP server that tracks branches in a git repository and
makes commits available as "articles" accessible in a news reader. The
initial release of this program (written in Python3) is available for brave
users who do not fear young and irresponsible software.
Full Story (comments: 3)
Release candidates for Python versions 2.6.8, 2.7.3, 3.1.5, and 3.2.3 are
available. "The main impetus for these releases is
fixing a security issue in Python's hash based types, dict and set, as described
below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of
bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues,
2.6.8 and 3.1.5 contain only various security patches.
Full Story (comments: 1)
The PostgreSQL project has announced the release of versions 9.1.3, 9.0.7,
8.4.11 and 8.3.18. They contain a number of fixes, some of which are
security-related. "Users of pg_dump, users of SSL certificates for validation or users of
triggers using SECURITY DEFINER should upgrade their installations
immediately. All other database administrators are urged to upgrade your
version of PostgreSQL at the next scheduled downtime.
Full Story (comments: none)
Newsletters and articles
Comments (none posted)
on the latest defect statistics from Coverity. "With 6,849,378 lines
of Linux 2.6 code scanned, 4,261 outstanding defects were detected and
1,283 were fixed in 2011. The defect density of Linux 2.6 is .62, compared
to .20 for PHP 5.3 and .21 for PostgreSQL 9.1. Keep in mind that the
codebase for PHP 5.3 — 537,871 lines of code — is a fraction of that of
Linux 2.6, and PostgreSQL 9.1 has 1,105,634 lines of code.
Comments (54 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>