D-Bus optimizations

[Rodrigo Moya]

On Tue, 2012-02-28 at 05:49 -0500, Colin Walters wrote:
> 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".
> 
sorry, bad wording from my part: it is indeed in the plan

> > 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?
> 
using shared memory for IPC. As I said, I might be wrong

> > 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.
> 
we are working on the basis that most libs do validation, which is the
case as of today. For not doing validation at all, Ryan Lortie told me
yesterday on IRC about using the GVariant serialization format, which
makes a lot of sense, and can be done after the multicast changes,
AFAICS

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