Last Updated: 2022-05-26
It facilitates interprocess communication between applications (either two copies of the same application or different applications altogether)
Example: There's this program called
terminator (a rough analogy would be something
that lets you manage terminal space, like
iterm). Someone runs
$ terminator & $ terminator --new-tab &
The first command opens a new window. The second command opens a new tab in the first window -- i.e. no long-lasting new process is started.
How does it do this? Because the second process is using
dbus to find the first
process, asking it to open a new tab, then quitting.
bus = DBus::SystemBus.instance # Access the service by name rhythm_box_service = bus.service("org.gnome.Rhythmbox") # Get "reference" to a remote function in the (remote) rhythm box service rb_player = rhythm_box_service.object("/org/gnome/Rhythmbox/Player") # Execute it. Note that is is async rb_player.introspect # You can also respond to a remote signal rb_player.on_signal("elapsedChanged") do |data| puts data end
Sockets also do Inter Process Communication (IPC) - e.g. process Z opens
/var/run/z.socket and process L reads/writes to it. The standard way of doing
this is clunky and expects one process to be running with its socket before the
other is loaded (however this need not be to so - see SystemD Socket Optimization)
Now what if you want to have communication between two programs' processes where one program didn't exist when the other was written. D-Bus can solve this issue by providing protocols and service discovery and information exchange. That way an interface is worked with rather than a pre-existing socket.
Modern daemons on Linux tend to provide services via D-Bus instead of plain AF_UNIX sockets.