data transfer via bus daemon

[David Zeuthen]

On Fri, 2007-09-21 at 10:22 +0200, Alexander Larsson wrote:
> On Fri, 2007-09-21 at 08:49 +0200, Thiago Macieira wrote:
> > Pa1 K wrote:
> > >So if two processes are communicating via bus daemon, using TCP sockets,
> > >then there will be 2 TCP connections- 1. process A to bus daemon; 2
> > > process B to bus daemon. If we need to transfer large amount of data in
> > > this setup, is it a ideal solution to use? OR is it possible in Dbus
> > > for two applications to transfer data directly between each other,
> > > after discovering each other via the bus, and then bypassing the bus.
> > > And thus the overhead of two TCP connections is reduced to one TCP
> > > connection.
> > 
> > That is what I recommend: once the two applications discover each other, 
> > they should open a faster channel for transferring a large bulk of data. 
> > Transferring it over the daemon is very inefficient.
> 
> DBus isn't enourmously fast for bulk transfers, even in the peer-to-peer
> mode. What I do in gvfs is discover the gvfs daemons via the session
> bus, then I create peer-to-peer connections directly to the daemons for
> "metadata" operations like readdir and stat, but for bulk file data
> transfers (saving or loading a file) we pass a socketpair fd to the
> client and use a binary lowlevel protocol.

I've mentioned this before: this is going to break when we start
forwarding $DBUS_SESSION_BUS_ADDRESS to remote hosts via ssh (much like
DISPLAY et. al. is forwarded today). So please make sure you can fall
back to doing IO via the bus. 

(OTOH, I'm sure a lot of other stuff is going to badly break; I've seen
D-Bus session services in the wild passing paths in the local file
system around.)

      David