"DBus Embedded" - a clean break

Alberto Mardegan mardy at users.sourceforge.net
Thu Jan 20 04:37:05 PST 2011

Hi Thiago,

On 01/20/2011 01:56 PM, Thiago Macieira wrote:
>> - Switch to peer-to-peer communication as soon as possible while doing
>> the handshake through daemon (minimize context switches, transmission
>> counts).
> Would buy you 4x at most, in the theoretical case.

Yes, this is very optimistic. But even if it were something about 2x, or just a 
bit less, it still seems a big improvement to me.

>> - Retain the current serialization functionality. However, provide a
>> way to skip it (since people say it's one reason why dbus is slow) and
>> transmit raw binary data very quickly.
> What's wrong with the serialisation? And more importantly, how are you going
> to lay data out on the wire ("wire" stands for any kind of inter-process
> medium) so that two processes can read it?

D-Bus serialization is fine, but providing a way to skip it might be a 
performance benefit when peers need to exchange data that is already serialized 
in some other way (for instance by the serialization provided by QDataStream).

> Yes, it might be easier than fixing libdbus. We have no clue if the D-Bus
> protocol needs fixing. We also don't know for sure that it is easier.

Well, we can expect that by removing one intermediate step in delivering 
messaging (the D-Bus daemon) we'll reduce the time required for a roundtrip.

> I know the current implementation is slow. We all know this. What irritates me
> is that people jump to conclusions that "since it's slow today, it's
> fundamentally flawed, cannot be fixed, we should just write a new thing". There
> is no proof in that statement above. We don't know for sure.

Apart from getting rid of the message verification steps, the points mentioned 
by Ville cannot be (easily?) implemented by just modifying the current code. We 
need a new protocol, essentially based on the transport of very short messages 
(via FIFOs or message queues) with data on shared memory areas, and a p2p net.

It's just easier to write this from scratch as a separate project, and then 
provide an API as close as possible to libdbus-1 on top of it, than modifying 
the existing.


http://blog.mardy.it <-- geek in un lingua international!

More information about the dbus mailing list