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

[L A Walsh]

Simon McVittie wrote:
> 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.
----
	Well... both the client and server have access to each other's
filesystems, though it's a bit specific to my use case, but if I
generalized that case something might be workable.  My linux machine
has the windows file system mounted at /<clienname>.  I have weird paths
like:
 D -> /??/UNC/LinBox/Documents/
 Documents -> /??/UNC/LinBox/Documents/
 M -> /??/UNC/LinBox/Music

On the left (D, Documents, M) are 'drives' or sharenames that
correspond to directories on the LinBox (the LinBox is where
all of the non-program content for the Winbox resides -- I just
trust Linux more w/my content than Windows). But those paths
are more hacks than anything else.  

What are the same are things like /Share, /Music, /Pictures, 
/Media, /home/<user>/Documents (all content dirs if you note).
Applications are different, but content locations are the
same by design.


> This is a simplifying assumption to make the system bus
> easier to use in solving the use cases for which it 
> was designed.
----
	Well, I'm more wanting content to be shared and
am not focusing on the system aspects so much.


> 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.
---
	Another oddball case.  For testing purposes, I have copies
of /dev/zero and /dev/null in my linux-home dir.  For file-bandwidth
testing via samba, my Winclient can read or write to those names in 
in my home directory and the actual devices on the linux box are read
and written.  Not a general mechanism, but an amusing way of 
doing PtP benchmarking.



> 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.
----
	Not so much needed (yet) in my use case.

> 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.
---
	Not exactly -- I have single signon between the two -- authenticating
at one authenticates me at the other.  In that sense, I have 1 session that's
shared between the two.  The linux box acts as a domain-controller for
the windows box.


> * systemd-logind also uses the system bus to give your processes access
>   to hardware devices while you are the active local user.
---
	I don't have a concept of an "active local user" since the linbox
doesn't run a desktop -- it just runs desktop applications.


>   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.
----
	You'd be surprised.  Using Samba, writing from Win->Lin's /dev/zero
(a name instead of a 'fd'), I get about 200MB/s.  For Win reading from Lin's
/dev/null, I get about 400MB/s.  For Lin reading from the Windows
file system (Linux taking a tar-backup of a directory on the WinBox mounted
via CIFS), I averaged over 500MB/s. Those numbers are in the hundreds
of MegaBytes/second (the two are direct-connected via a 8Gb-BaseT
ethernet cable).  What speed requirements are needed for file descriptor
passing, or, what speeds is it getting?

> * BlueZ
> * NetworkManager, ConnMan, wicd
---
	Don't use those.


> You're welcome to use such protocols, and you could even use the D-Bus
> "wire protocol" and code to implement something distributed.
---
	My needs are fairly simple... One of which I accomplished
today -- clicking on a link in an app running on Linux and having
it open in the browser on my windows system instead of on the linux
system;  I map my Windows browser to a desktop-app on linux, that handles
URLs.  So when something wants to open a URL, it sends the URL to
my windows machine.


> 
> 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.
---
	All of that is already solved (distributed identity) or not
an issue in my local use case (direct connect wire -- which is why
I mentioned the "cluster" case).


> 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,
---
	Network protocols aren't slouches.  It's "overhead" that costs --
though even a ~10X slowdown caused by encryption wouldn't rule out most
use cases (some, yes).  Would really depend on use case.


> 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.  
---
	For the local-to-local use case w/no encryption, speeds
over the loopback interface would be "screamingly" fast -- but if
you are talking 3D graphics, even that speeds would slow things down.



> Perhaps an analogy would help: Suppose you want to copy text from one
> program and paste it into another. 
---
	I do that between systems all the time via 'X'.

> - now you can copy and
> paste while your Internet connection is down, you don't have to wait
> for network lag
---
	If the copy/paste is local->local why would it be routed over
an internet?  I'd make the simplifying assumption that local-to-local
traffic would remain local.


> (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.)
---
	I can transfer multi-megabytes in milliseconds.  Example:
glxspheres -- not the best because my screen is limited to 60 frames/second,
but @ full screen (2560x1600) it claims to be getting 240 Mpixels/second.
Not even close to what you need for today's games, but still looking at 240
pixels/microsecond.  OTOH, wayland, I can't say anything for as haven't tried
it.  

 

> 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. 
---
	I can believe that.  Like using a shotgun to kill a fly.

> KDE's DCOP...not as complicated as CORBA. KDE has since
> adopted D-Bus as a DCOP replacement.
----
	Thanks for the back-history.


>>    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.
---
	Well, would need something general-case like a broker-client
to send requests from one system to another, and I might end up with
far more capability and generality than I'd need for my use case.


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

	I mostly need the remote application invocation and starting
which I might get via special case 'forwarding apps' running on linux --
not as easily configurable.

	Thanks for the insights.

	FWIW, I've been various combinations of Windows and unix/linux
for quite a while -- it wasn't until recently that I started wanting
URL's to be passed back...  Tuning my file-transfer speeds has an
ongoing project -- most of my speed tests aren't using settings 
"out-of-the-box"...(and I find that updates on either the Windows
or Linux ends can wreak havoc with them)....

	I'm still curious about the speed benefits of file-descriptors
over paths (other than security issues, which we both are mostly ignoring
due to the client-server's being "local" in some sense).

-l