Benchmarking D-Bus / RFC: skip validation in dbus-daemon?

[Simon McVittie]

(This is <https://bugs.freedesktop.org/show_bug.cgi?id=33524>; bringing
discussion here for a wider audience, and I'll summarize on the bug later.)

People keep proposing that we throw away D-Bus and reinvent IPC to get rid of
perceived performance problems. Before throwing away the baby with the
bathwater, let's benchmark it and see what's actually wrong with it...

Before I write my own random code that doesn't necessarily reflect anyone's
use case, does anyone have a favourite automated D-Bus benchmark that I should
be using? I'm currently aware of:

* the libdbus and dbus-glib regression tests
* other D-Bus libraries' regression tests, e.g. telepathy-glib
* dbus-ping-pong from
  http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/
* Adrien Bustany's benchmark tool linked from that blog post:
  http://git.mymadcat.com/index.php/p/ipc-performance/source/tree/master/

-------------------------

Having said we should benchmark, I'm going to disregard my own advice slightly
:-) and suggest that one obvious target (at least for benchmarking) is message
validation. It always seems slightly perverse to me that in the typical case
for a single D-Bus message:

    :1.2 -----------> dbus-daemon ----------> :1.3

we have several sets of validation going on:

* :1.2 composes a message (ideally with a g_return_if_fail() or equivalent to
  check that strings are UTF-8 and so on, which can be turned off in a
  "production" build)

* dbus-daemon receives the message and validates the message body

* :1.3 receives the message; a high-quality client library implementation will
  validate the message again, in a way that can't be turned off [1]

An obvious thing that would be interesting to benchmark: how does performance
compare if we turn off validation entirely, and have all processes blindly
trust other processes?

That's the best performance increase we could possibly achieve by not
validating. Obviously, we don't actually want all processes to trust all other
processes, particularly on the system bus, so that's more of an unattainable
goal than anything else.

However, what if we make dbus-daemon never validate message bodies? Things
that'd be required for that:

* Audit client libraries to make sure they deal with bad message bodies
  gracefully; this includes at least libdbus (on behalf of dbus-glib, QtDbus
  and dbus-python), GDBus, ndesk-dbus and dbus-java.

* Keep DBusConnection validating message bodies by default (because clients
  still want to do that), but have a way to turn that off for dbus-daemon's
  benefit

* If the message body is bad, clients can cope; they should log an error or
  something (synthesize a signal from org.freedesktop.DBus.Local with the bad
  message as a byte-array?), but can skip the rest of the message, because we
  know the length of the message (how many bytes to skip) from the header.

* If the variable-length part of the message header is bad, this is serious
  (dbus-daemon is required to have have checked it so that it can set a trusted
  sender), so we should disconnect

* If the 16-byte prefix of the message header (which contains the actual
  length) is bad, this is absolutely fatal, because we can't know how many
  bytes to skip; we must disconnect

* If we get the length wrong somehow, we'll skip the wrong number of bytes;
  people have expressed worries in the past that becoming de-synchronized with
  message boundaries like this will result in skipping every message, forever,
  silently. However, it's unlikely that the incorrect message boundary will
  leave us at a point that's syntactically valid as the 16-byte prefix[2], so
  we can detect this situation with reasonable certainty.

Regards,
    S

[1] I believe Alban's kernel-assisted D-Bus
(http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/) already
skips message validation, so any client libraries that want to work reliably
with kdbus will have to do this anyway? And, it's just good design.

[2] The somewhat-wasteful header format becomes helpful! Byte 0 (endianness)
must be 'l' or 'B', byte 3 must be 0x01, bytes 4-7 must be a sensible message
length, and bytes 12-15 must be an array length that doesn't exceed the message
length