dbus_message_demarshal() and partial messages
apenwarr at gmail.com
Thu Aug 16 21:52:30 PDT 2007
On 16/08/07, Havoc Pennington <hp at redhat.com> wrote:
> Interesting - this is exactly the opposite of what everyone else writing
> dbus bindings is interested in doing (they all want the connection layer
> but not the message marshaling). ;-)
Yeah, the question is if all I'm using is DBusMessage, why not just
rewrite it all from scratch anyway? I'm just as happy not to, but
it's a question I had to ask myself several times :)
Since parsing/forming binary data is the most likely part to result in
buffer overruns, I'd rather not rewrite my own C++ version of that.
It's obvious that the libdbus code is really carefully written, which
gives me a lot of confidence in its security.
> Taking the perspective of a Linux distribution (or other collection of
> apps packaged as a whole), I do think having bindings or apps
> reimplementing the auth and connection layer is quite bad, because the
> auth and connection layer is where the most "new stuff" is likely to
> happen - new transport mechanisms and auth mechanisms - and it would be
> nice if all apps inherited this work and could talk to each other.
> Assuming you are doing something intended to interoperate with dbus at
> all, of course - if not it doesn't matter.
> SSL and Windows portability would definitely be "nice to have" in
> libdbus itself, in any case.
One of my goals is to build a "dbus proxy" that will let you connect
the buses of two separate machines together: in this case, Windows and
Linux, or whatever. For that I need SSL. But it works with an
existing libdbus/dbus-daemon installation, so libdbus can focus on
what it's most useful for, and people who need more connectivity can
just attach the proxy.
Writing all that code in C (without WvStreams, and to libdbus's coding
standards) would take about an order of magnitude longer, so I'm
afraid I don't have time to contribute that.
> That aside, answering your question - the marshal/demarshal API there is
> intended to tunnel dbus through another protocol like XMPP, it was not
> intended for parsing a dbus stream.
> If the API addition to support parsing a dbus stream is trivial then I
> guess we could add it, but I would be reluctant to add much code to
> support this.
Having now done it (I'm linking with libdbus statically so I can
access its internal functions for now), I can confirm that only the
one new function is needed, and its implementation is pretty much
trivial as discussed.
There's also a question of how a serial number gets set: unless I'm
mistaken, dbus_marshal() doesn't set it. You have to lock the message
first, but that's private too. dbus_marshal() should do that,
More information about the dbus