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

[Simon McVittie]

On Tue, 20 Jun 2017 at 09:43:29 -0700, L A Walsh wrote:
> Simon McVittie wrote:
> > [a distributed system bus] 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.
> ---
>    Even if you want the two machines to function as 1?

Yes. D-Bus protocols that work over the system bus may (and in practice
probably do) assume that things like filenames, process IDs, user IDs
sent over the system bus have the same meaning to the client and service.
This is a simplifying assumption to make the system bus easier to use in
solving the use cases for which it was designed.

If your use cases go beyond that, the system bus is not for you.

Some D-Bus protocols that work over the system bus also assume that they
can do Unix file descriptor passing, using the system bus as a control
channel through which they can set up a direct AF_UNIX connection or
get direct access to a device node. That's never going to work across
a network.

>    What is the system bus used for?

The D-Bus Specification says:

    * A "system bus" for notifications from the system to user sessions,
      and to allow the system to request input from user sessions.
    ...
    A computer may have a /system message bus/, accessible to all
    applications on the system. This message bus may be used to
    broadcast system events, such as adding new hardware devices,
    changes in the printer queue, and so forth.

The system bus is potentially used wherever your user processes (typically
desktop UIs) talk to a privileged system component other than the kernel.
Some typical examples:

* systemd-logind uses the system bus to notify user processes and system
  services when users log in or out, or when user sessions become active
  or inactive. This doesn't make sense to distribute between machines,
  because logging in on the two machines is not atomic: you are
  logged in on one before you are logged in on the other.

* systemd-logind also uses the system bus to give your processes access
  to hardware devices while you are the active local user. This cannot
  be distributed between machines because it relies on file descriptor
  passing, so that the process that will use the hardware device can
  write to it directly - anything else would be far too slow.

* BlueZ (the user-space part of the Linux Bluetooth stack) uses the system
  bus to connect Bluetooth services running as root with UIs and other
  clients running as your ordinary user ID. This doesn't make sense to
  distribute between machines because the devices are only physically
  present on one machine, and it cannot be distributed between machines
  because it relies on file descriptor passing.

* NetworkManager, ConnMan, wicd and similar dynamic network connectivity
  managers use the system bus to let UIs and other client processes
  in your desktop session (running as your ordinary uid) configure
  networking. You can't distribute that across a network because it's
  something you use to set up networking.

>    The state of the art 10-20 years ago allowed for Distributed messaging
> between machines using CORBA which was preceeded by "DCE" (something still
> used by Samba).

You're welcome to use such protocols, and you could even use the D-Bus
"wire protocol" and code to implement something distributed.

However, the two well-known D-Bus buses (session and system), which
are the primary use-cases for D-Bus, are not distributed. We make
the simplifying assumption that we are not doing everything across an
arbitrary network, because that way we don't have to deal with network
security, network-length delays, retransmission, distributed identity
and all the other baggage that comes with using a network. If we had
designed the two well-known buses to be distributed, we would have
to pay the complexity cost of using a network protocol all the time,
in order to get a benefit in the rare cases where it is actually used
across a network - and that isn't a great trade-off when the amount
of engineering time spent on it is very limited.  If that simplifying
assumption does not apply to what you're doing, then the well-known
system bus is the wrong tool for it.

Perhaps an analogy would help: Suppose you want to copy text from one
program and paste it into another. It would be technically possible to
implement that by uploading that text to a cloud service and downloading
it again. However, if you have the simplifying assumption that both
programs are running on the same machine, then it makes a lot more
sense to use local interprocess communication - now you can copy and
paste while your Internet connection is down, you don't have to wait
for network lag, and it's a lot easier to be confident that nobody else
is reading your clipboard contents. So, in practice, implementors of
copy/paste use local IPC, even though it makes some potentially
desirable things impossible.

(Copy/paste on Linux doesn't use D-Bus, but if D-Bus had been developed
longer ago, in principle copy/paste could have used the session bus. It
actually goes via X11, which is theoretically network-transparent but in
practice is used locally 99% of the time and doesn't actually work very
well remotely; or via Wayland, which has dropped the network-transparent
property of X11 in order to get better performance and maintainability
in practice.)

>    Since DBUS looks very similar to what CORBA was using (I thought it
> looked
> familiar), I think I was expecting it was an evolution of that, but it looks
> like it was a reimplementation.

For context, GNOME used CORBA for a while (the implementation is called
ORBit), and even had an OLE-like component framework, Bonobo, built
on top of ORBit.

The design of D-Bus was a reaction to problems with CORBA in GNOME -
I don't know the specifics, but I believe the main issue was that CORBA
was extremely general, making it hard to use in practice for common
desktop use-cases. KDE's DCOP, which is simpler than D-Bus, was a
major inspiration: the original niche for D-Bus was to be a bit more
general than DCOP, but not as complicated as CORBA. KDE has since
adopted D-Bus as a DCOP replacement.

>    Maybe unix code from that project could be ported to linux...dunno.

If what you want is CORBA, use CORBA. It hasn't ceased to exist.

D-Bus is not intended to be the right hammer for every nail, and if
your requirements don't match those for which D-Bus was designed,
I would recommend not using it.

    S