dbus_message_demarshal() and partial messages

Avery Pennarun apenwarr at gmail.com
Tue Aug 14 12:11:19 PDT 2007


Hi all,

I'm having trouble using the new dbus_message_demarshal() function.
My design, essentially, is to reimplement the entire connection layer
in C++ according to the DBus spec document, but to use the existing
DBusMessage code, since it seems to already to what I want in terms of
message encoding.

However, I'm running into a problem with demarshalling data from the
connection.  What I'm receiving from the remote end is a stream of
bytes (of course), and there's no easy way to tell when I've reached
the end of a message so that I can pass it to
dbus_message_demarshal().  Of course the information is available as
part of the message header, but the purpose of using
dbus_message_demarshal() at all is to avoid manually parsing the
header.

It looks like if I pass a partial message, it'll simply fail to
demarshal (claiming an out-of-memory error, it seems from the code)
and I can read more bytes and try again later.  Not efficient, but it
would work.  But if I pass too *much* data, there's no way for me to
find out: I'll correctly decode (at least) one message, but then it
doesn't give back the data it didn't use.

I could instantiate a _dbus_message_loader myself, but of course
that's a private API that's likely to get me into trouble.

What's the recommended way to do this?

I notice that dbus_message_demarshal() is new in the 1.1/1.2 dbus
development code.  What did people do before that?  They couldn't?

Thanks,

Avery

P.S. The reason I'm reimplementing the connection layer stuff is
threefold: I need an increase in portability (both Linux and Windows,
specifically) and the WvStreams library I use has already been ported;
I need full SSL support for the connection without a separate proxy
process/thread, and WvStreams can already do this; and I need a
special authentication mechanism, so writing it from scratch is as
easy as writing a plugin to the DBus library's authentication.  Other
suggestions are welcome too.


More information about the dbus mailing list