Skipping the session bus hop for RPC
walters at verbum.org
Mon Feb 9 12:02:07 PST 2009
On Mon, Feb 9, 2009 at 2:28 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
> I've bumped into situation (doing a large database query) where dbus
> buffer size was a limitation - the message just didn't pass through
> the dbus). I can't quote exact sizes here.
> Sometimes it would be handy if method returns could be routed directly
> to a socket on invoking process. The semantics of that would be pretty
> clear, and writing huge blobs would be feasible (allowing serialize ->
> de-serialize & use at the same time without having copy of the whole
> data around).
My thoughts on this are that if going through the session bus is too
much overhead, at the point where you need direct connection, you
typically also want a different protocol.
There are a ton of choices here, with different tradeoffs. If both of
your applications are in the same security domain (uid, selinux
domain), you have the most choices. POSIX shared memory, file
descriptor passing (create direct unix socket, pass name over dbus).
The filesystem is another choice (create temporary file, pass name).
I think what a lot of people want is an API like
dbus_pass_large_object (DBusConnection *conn, const char *buffer,
But it's tricky, since the details really matter.
Finally if you're in control of both applications, another thing to
consider is simply using one process. There's a reason people code to
application servers; among them is that local data is far easier to
work with than IPC.
I think it'd be relatively sane to have a UNIX-only API for e.g.
passing file descriptors in libdbus, but it's also something that
could exist relatively easily as another library (or just cut&paste
code); someone just needs to write it and define the API.
More information about the dbus