thoughts(?) on interconnecting dbus on 2 systems to get anything useful...

[L A Walsh]

Thiago Macieira wrote:
>  On Saturday, 17 June 2017 12:43:56 PDT L A Walsh wrote:
> > Are there any examples or documentation on interconnecting
> > dbus's on different machines to function more as one, "extended
> > bus", or how would I connect them?  Has anyone else tried
> > this or gotten this to work?
>
>  No one has tried, much less succeeded in doing that, that we
>  know of. There are no examples for you to draw upon.
----
   :-( -- worse than bleeding edge, eh?
>
>  And then you made things even more complicated by introducing
>  Windows into the mix.

----

   If it's never been done before, why make it simple?  Ehhrr...
_actually_, on the Winbox I intend to use cygwin's Dbus as I use
its 'X'server now (and I intend to simplify where feasible).

   Currently, the Cyg-X-server is started as a login-autorun.  The
system Dbus is stared as an "onboot" service. So I figure to start
a the session bus on Windows at the same point I start the 'X'
server.

   The Cygwin session bus script can also populate the user registry
area for ENV vars that get propagated to new user procs started by
windows (new procs aren't forked on windows, but created by
a request to the OS; thus the propagating of ENV vars through the
registry.

   When I first login to the linux box that can propagate the
session bus from win->lin (presuming winSessBus is listening on tcp
not a local unix:socket).  That leaves system-bus traffic on the
linux-box that needs a way to connect back to the winbox's
system-bus.

   That's a bit of an unknown -- since "theoretically" the linux box
would have its own system bus running from boot.  At some point,
when the winbox comes up, I need to join the two so system messages
can go back and forth on its bus -- but since both start w/system
buses on boot, it seems there should be some way to "peer" them and
have traffic 'bridged'.

   I think the presence of 2 system buses with no way to "cooperate"
is what I'm stumbling upon.

   Is there ever a situation where 2 system buses can communicate
w/each other?  Any way to peer them?

   That seems to be a conceptual blocking point -- not sure what
needs to happen there.

   As a parallel to my situation, if you think about people with
remote linux systems (android based), wanting to connect to services
of linux systems "in the cloud", there might also be situations
where system buses of client-server systems need to communicate or
do some temporary bridging (with filtering being 'optional').

   If a method isn't already in place for doing so (and sounds like
not),  it might be something to plan-ahead for.  Allowing remote
users on a remote handheld or tablet system (might be based on some
OS other than linux) to 'cloud-connect' to server-systems might
allow clients to reserve or attach server resources (compute,
graphical rendering, disk, fax, media-streams, etc) with actual
content coming back via higher-bandwidth channels.

   Would "dbus experts" see a need for system-buses on client and
server machines?  Would one system defer to the other or would
bridging messages work better?  Any thought to a way to get
different system-dbuses coordinating together?

   I don't know what it is, exactly, but windows has a "Distributed
Transaction Coordinator" -- maybe a Distributed Bus Arbitrator would
be needed for inter-sys-bus coordination, though that could easily
be overkill for two systems.

   Has anyone used or thought about how multiple systems all running
the same OS, but acting as a cluster might have their system-buses
coordinate <anything>?  Maybe dbus isn't intended for, or isn't
suitable for a cluster environment?  Is it designed primarily for
a desktop-type machines?

  Thanks for any thoughts...

  Main hope is to figure out if I can even get a distributed session
bus working -- maybe a coordinated or connected system bus isn't
needed?

   Thanks again,
   Linda W.