D-Bus optimizations

[Colin Walters]

On Tue, 2012-02-28 at 11:34 +0100, Rodrigo Moya wrote:

> we are thinking on having a proxy that supports old clients, routing all
> traffic from the SOCK_STREAM sockets to the multicast groups. Sorry,
> forgot to mention it in my blog post

We either have backwards compatibility or we don't.  And there's a big
difference between "we think we could later add it" versus "designed
in from the start".

> I mentioned the shared memory solution because it was looked at, but
> hasn't been taken into account. IIRC, the solution was to have different
> shared memory segments, some RW and some read-only, so I think it makes
> things too complicated to be taken into account. I might be wrong, but I
> have never seen this being suggested in this mailing list.

What hasn't been taken into account?

> yes, we have a simple test suite (dbus-ping-pong, as mentioned in
> Alban's blog posts) which we are using right now for measuring times.
> Although right now, with the current D-Bus branch, there are still some
> things to be done before we can certify the improvements. But I have
> both VM machines, one with current D-Bus and one with the multicast one,
> setup to measure the timings, so as soon as I have some real numbers,
> I'll publish them.

Ok, cool.

> yes, there are a lot of other improvements that could be done, message validation being one
> of them. Note though that with multicast, we remove one of the
> validations, as the daemon doesn't do anything on most of the messages
> sent to the bus.

Wait, so you're saying clients now need to do validation?  It's true
that most of the libraries do validation at present, but
there's been discussion before about e.g. allowing clients to skip UTF-8
validation for messages that come from the bus.

Besides structural validation, if any client can create any message
content it wants, including faking the sender field for example, that
seems quite problematic for the system bus.  For example, PolicyKit
relies on it for security.