data transfer via bus daemon

[Alexander Larsson]

On Fri, 2007-09-21 at 14:23 -0400, David Zeuthen wrote:
> 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. 

We can't do this at the moment. But it can be fixed up when needed, as
this all happens behind the scenes. It will be pretty slow though.