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

[Simon McVittie]

On Sat, 17 Jun 2017 at 20:30:58 -0700, L A Walsh wrote:
> That leaves system-bus traffic on the
> linux-box that needs a way to connect back to the winbox's
> system-bus.

This is not something that will ever be supported. The system bus is
specifically per-machine; sharing a system bus between two machines is
never correct.

The session bus *might* be possible to distribute between machines, but
I don't think that configuration will ever be reliable or predictable.

>   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 particular application or use-case needs to communicate between
the system buses of two different machines, then that is something for
that application to solve.

> 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.

The state of the art for doing this is to typically to use VNC, Spice,
RFB or a similar protocol to put as much as possible on the server,
with the client being merely a terminal or viewer (in the sense of
<https://en.wikipedia.org/wiki/Computer_terminal>). This would
typically mean that all D-Bus communication happens between processes
on the server.

I believe Windows Remote Desktop Services (formerly Terminal Services)
is the closest equivalent in Windows.

>   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?

Changing the meaning of the well-known system bus is not appealing.
I expect that with the current number of active contributors to D-Bus,
we would never get this to be reliable.

Building a reliable distributed system is a hard engineering problem, and
D-Bus does not have any full-time developers (I'm probably the closest,
and I don't think I average as much as 10% of full-time on D-Bus).

>   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?

D-Bus is not designed for a cluster environment.

The session bus is primarily designed for desktop sessions.

The system bus is designed for desktop sessions and single servers
(either real hardware, virtual machine, or OS container with its own init
process). If multiple servers running separate kernel instances are
combined into a cluster, then anything that is shared across the cluster
is happening at a higher level than the system bus.

Regards,
    S