D Bus
D-Bus = Desktop Bus
Is an inter-process communication (IPC) and remote procedure call (RPC) that allows communication between different processes.
Part of the freedesktop.org project.
Also provides the libdbus library.
D-Bus is designed to replace communication systems for GNOME and KDE environnements (CORBA and DCOP respectively).
Software bus abstraction that gathers all the communications between a group of processes over a single shared. Indeed, point to point communication will become quickly unreliable due to the number of processes involved.
In fact several instances of the bus itself are instantiated :
-
System bus : service "dbus" in CentOS
-
Session bus (for each user desktop login session) : for example service "session-1" in CentOS.
Process can connect to serveral number of buses.
D-Bus can be also used as framework to integrate different components of an user application.
Actually used by some system services such as NetworkManager, BlueZ bluetooth stack and Pulseaudio sound server and logind.
Every connection to a bus is identified with a bus name commonly called "well-known names" or interface. Ex : org.freedesktop.NetworkManager
Immutable : bus name won't change. Bus name can be used by a process to guarantee that the process uses a single connection to a bus.
A notification is send when the bus name is released.
D-Bus shares an object model between clients and services.
It exposes objects with some members :
-
methods that can be invoked
-
some signals (notifications) that the object can emits.
A client can listen to signals that an object emits when its state changes due to certain events.
An object is identified with its path. Path are unique.
Every object is associated to the particular bus connection where it was exported.
A client must indicate the path as well as the bus connection.
D-Bus is a generic inter-process communication system : communications are based on exchange of messages instead of "raw bytes". Two modes of messages :
- One-to-one request-response : client invoke an object method. Client sends message to service or process exporting the object. Message sends by the client contains :
- Object path
- Method name
- Input parameters (if needed)
Reply consists of the result of the object as well as parameters returned by the object invocation method or exception information.
- Publish/subscribe : way for an object to announce the occurrence of a signal to the interested parties. The service process that exports the object broadcasts a message to its connected client. Message contains :
- Object path
- Signal Name
- Signal parameters (if any)
Communication is one way since to acknoledgment is needed.
Any D-Bus message consists of header and a body.
D-Bus uses marshaling instead of serialization.
Follows the architecture of the reference implementation. Consists of 2 main components :
-
Point-to-point communication library that implements the D-Bus wire protocol : libdbus. In Linux, libdbus uses UNIX domain sockets (Ex. unix:path=/tmp/.hiddensocket) but can also uses TCP sockets.
-
Special daemon process that plays the role of the bus
Usual way to use D-Bus is to use a message bus daemon (dbus-daemon systemd service) as communication central point to which each process should establish its point-to-point D-Bus connection.
D-Bus is able to automatically start a service if needed.
Messages are sent throw objects rather than applications. Each process connected to a bus can have saved one or several objects. Object can be accessed by the way of a path.
dconf is optimized for reads. Data is stored in a unique binary file called dconf database. With such optimization, the I/O scheduler in the kernel can handle several reading requests at the same time. This is desirable since several applications using dconf can run at the same time: this is called multitasking. Writes are less optimized. A D-Bus service can start and stop dynamically as soon as the first write operation is performed. This service sends over the D-Bus the requested writes. There are two types of dconf databases : system and user databases. Each user has its database under $HOME/.config/dconf/user. System database can be found under /etc/dconf/db/local. System database data overrides conflicting user database data. It is possible to have several user databases and/or system databases. This list of configuration databases for a given user is called a profile. It also defines the priority for each database.
Any keys / any setting can be locked. It is also possible to completely lock a subpath. If the locked key has the highest priority, then the targeted user will not be able to modify that setting. This is very useful to restrict users capabilities, mainly in the Linux Desktop.