Compilation of well-known properties of d-bus messaging system of linux.

1. D-Bus
Emre Can Kucukoglu
eckucukoglu@gmail.com
06.08.2015

2. What is d-bus?
Desktop bus, IPC mechanism.
Medium for local communication between processes
running on the same host.
1:1 request-reply, 1:n publish-subscribe.
Structured view of the data.
messages can be validated and ill-formed messages rejected.
low-level C binding, also Java, Perl and Python.
2

3. Buses
Processes connect to the daemon
using the library.
p2p communication library:
used by any two processes in order to exchange
messages among themselves.
the daemon:
any number of processes may be connected at
any given time.
Multiple buses may be active
simultaneously.
system bus:
system-wide communication.
session bus:
single user's ongoing session.
● Addresses describes how to connect to bus such as "/tmp/.hiddensocket”. They completely
hidden from the client process by the dbus library.
3

4. Connections
When a connection is set up, the bus immediately assigns it an immutable bus
name that it will retain for as long as the bus exists.
Services under well-known names that are agreed upon by convention, like
org.freedesktop.DBus.
4

5. Object model
objects,
proxies,
methods,
signals,
interfaces.
5

6. Objects
Created by a client process,
Exists within the context of that client's connection to the bus.
Message types carried by the bus:
Requests sent to objects by client processes.
Replies to requests, going from an object back to a requesting process.
One-way messages emanating from objects, broadcast to any connected clients
that have registered an interest in them.
6

7. Proxies
Local representation of an object that is really accessed through the bus, and
typically lives outside your program.
GLib binding’s proxies support failover.
7

8. Methods
When a client sends a request to an object, it sees this request as invoking a
method on the object.
Arguments can be passed and result back to the requester, along with either
result data or exception information.
Messages are encapsulated by d-bus library.
Both asynchronous & synchronous method invocation.
8

9. Signals
One-way communications come from an object and go client processes.
Client processes can register an interest in signals of a particular name
coming from a particular object.
There are no replies to signals.
No input and output parameters like methods do.
Allow clients to restrict their interest to cases where certain of the signal's
parameters match given values.
9

10. Interfaces
Every object supports particular methods and may emit particular signals.
These are specified in interfaces.
When a client invokes a method or listens for a signal, it must indicate the
object and the member {methods, signals} it is referring to.
10

11. Addressing
11

12. Overview picture
12

13. furthermore; Activation
Bus daemon can be instructed to start clients automatically when needed.
To achieve that describe client in a service file.
Default path: /usr/share/dbus-1/services/*.service
For example: client program /usr/local/bin/bankcounter can be run to provide
well-known bus names com.bigmoneybank.Deposits and
com.bigmoneybank.Withdrawals.
# Sample bankcounter.service file
[D-BUS Service]
Names=com.bigmoneybank.Deposits;
com.bigmoneybank.Withdrawals
Exec=/usr/local/bin/bankcounter
13

14. Performance
One-to-one communication was about 2.5x slower than simply pushing the
data raw over a socket.
Bus daemon should be about twice as slow as one-to-one mode, because a
round trip involves four socket reads/writes rather than two socket
reads/writes.
Overhead comes from:
Abstraction penalty (marshalling)
Data validation (‘no validation’ mode exist, but not recommended)
Raw bandwidth isn't the only concern; D-Bus is designed to enable
asynchronous communication and avoid round trips. This is frequently a
more important performance issue than throughput.
14

15. Why D-Bus?
difference from other IPC protocols:
d-bus is also lifecycle tracking, service activation, security policy, and
other higher-level structure and assumptions.
not good for:
internet applications,
clustering, distributed swarms, peer-to-peer.
good for:
desktop application talks to other parts of the desktop session,
communications between system daemons and communications between
the desktop and system daemons.
15

16. Why D-Bus?
Method call transition, signals, properties, oo, broadcasting,
discovery, introspection, policy, activation, synchronization,
type-safe marshalling, security, monitoring, exposes APIs/not
streams, passing of credentials, file descriptor passing,
language agnostic, network transparency, no trust required,
high-level error concepts.
retrieved from http://0pointer.de/public/lca.pdf
16

17. Drawbacks
Used for control, not payload.
Inefficient (10 copies, 4 validations, 4 context switches per
duplex method call transaction)
No implicit timestamping.
Not available in boot time.
Security framework hooks happen in userspace.
retrieved from http://0pointer.de/public/lca.pdf
17

18. alternative: kdbus
Efficient (2 or fewer copies, 2 validations, 2 context switches per
duplex method call transaction).
Implicit timestamping.
Always available, from earliest boot to latest shutdown.
Security framework hooks happen in kernel space.
retrieved from http://0pointer.de/public/lca.pdf
18

19. References
freedesktop.org: intr. to dbus.
freedesktop.org: dbus faq.
maemo: dbus.
qt 4.8: dbus documentation.
wiki: dbus.
linux.conf.au.: Lennart Poettering.
19