Google "Protocol buffers" over D-bus?
thiago at kde.org
Sun Sep 20 00:22:12 PDT 2009
Em Sábado 19. Setembro 2009, às 21.30.08, Ville M. Vainio escreveu:
> Google "protocol buffers", in case you haven't heard of them, are
> basically a way to encode struct-like data in binary form, coupled
> with an IDL-ish description language & code generators.
> Now, I'm thinking of the performance implications of passing
> protobuf-encoded byte blocks as (complex) arguments for (and return
> values to) dbus methods. This may, or may not, lead to bandwidth
> improvements over just using the usual dbus stuff
> (dbus_message_iter_append_basic, ...), while still retaining the
> convenient dbus semantics (service discovery/naming, activation,
> method call semantics...) - but with simpler transition to, say, using
> local/internet sockets if it appears necessary.
> So I'm asking - has someone already benchmarked this? Can you squeeze
> more data in one dbus invocation using protobufs without hitting
> buffer limit? How about serialization speed/size for complex objects?
> Code complexity implications?
I've just taken a quick look at the protobuf documentation (which doesn't seem
to have any relation to Google, btw, except for being hosted on
It's just a marshalling format. It doesn't do anything else. It matches D-Bus
marshalling, with a different format. From what I can see, anything you can
encode in a protobuf you can encode in D-Bus too, but not the other way
around. I don't see any way in protobuf to send variable-sized arrays,
dictionaries, structures. I could even say I don't see a way of transferring
Unicode strings -- there's only a byte-array type (which they call "string"),
which you can use to transport those strings, as long as you agree on the
Now, the protobuf encoding is shorter than D-Bus for the same payload. D-Bus
is much more verbose, with each integer type occupying the same width,
regardless of type. That also means strings are prefixed with a full 4 bytes of
D-Bus was designed for localhost communications, where bandwidth is not a
problem. It was designed for parsing efficiency -- indeed, many items are 8-byte
aligned inside the wire message so that they can be easily read on any
I'd say that, if you can, use D-Bus marshalling when using D-Bus. It'll be
more efficient and also more compatible with existing implementations.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14 San Francisco, California: Nov 2 - 4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090920/0f77236d/attachment.pgp
More information about the dbus