blob: 53b46eae91ff15035c8ce3391eda52cf52546eb0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
There are plans to get [[D-Bus|Software/dbus]] communication working also in situations where the two programs are not on the same computer and thus cannot use the default unix domain sockets. Possibilities include TCP/IP, SSH forwarding the bus daemon, a proxy daemon, or D-Bus over X. TCP/IP and SSH forwarding could in theory work without further programming. Most remote scenarios would require authentication of end points and encryption of messages on the wire though.
A simple use case is running a remote application that wants to communicate with the local session bus. Another interesting setup is running an X session and the session bus remotely on a server machine, but allow the applications to contact the system bus running locally on a thin client.
## TCP/IP
The TCP/IP transport isn't tested in use and it has the problems of access control, lack of encryption, and inability to go through firewalls and NAT.
## SSH forwarding
SSH doesn't support forwarding of unix domain sockets. Even if it did, the methods that return unix user and unix process would return the local SSH process and not the remote information - perhaps that's not a problem, but needs documentation at least.
A program called socat has been used before to adapt unix domain sockets to SSH forwarding.
## Proxy daemon
Implementing a proxy daemon that poses as a bus daemon and also connects to the existing bus as a client has the problem of unix user and unix process too.
## D-Bus over X
Transporting D-Bus messages over the X protocol does not work in the general case as X isn't always available. The advantages would be automatic support for SSH-forwarded X clients and NX etc. It's not known how much this approach would harm efficieny.
|
