|Developer(s)||Red Hat and the community|
|Stable release||1.10.0 / August 25, 2015|
|License||GNU GPL version 2 or later, or AFL 2.1|
D-Bus is an inter-process communication (IPC) and remote procedure call (RPC) mechanism that allows communication between multiple computer programs (that is, processes) concurrently running on the same machine. D-Bus was designed as part of the effort of the freedesktop.org project to standardize services provided by Linux desktop environments such as GNOME and KDE.
The freedesktop.org project also developed a free and open-source software library called libdbus, as a reference implementation of the specification. This library is often confused with the D-Bus itself. Other implementations of D-Bus also exist, such as GDBus (GNOME), QtDBus (Qt/KDE), dbus-java and sd-bus (part of systemd).
D-Bus is an IPC mechanism initially designed to replace the software component communications systems used by GNOME and KDE Linux desktop environments (CORBA and DCOP respectively). The components of these desktop environments are normally distributed in many processes, each one providing only a few —usually one— service. These services may be used by regular client applications or by other components of the desktop environment to perform their tasks.
Due to the large number of processes involved —adding up processes providing the services and clients accessing them— establishing one-to-one IPC communications between all of them is an inefficient and quite unreliable approach. Instead, D-Bus provides an abstraction called bus that gathers all the communications between a group of processes over a single shared virtual channel. Processes connected to a bus don't know how it is internally implemented, but D-Bus specification guarantees that every process connected to the bus is able to communicate with each other through it.
Linux desktop environments take advantage of the D-Bus facilities by instancing not one bus but many:
- a single system bus, available to all users and processes of the system, that provides access to system services (i.e. services provided by the operating system and also by any system daemons).
- a session bus for each user login session, that provides desktop services to user applications in the same desktop session, and allows the integration of the desktop session as a whole.
A process can connect to any number of buses, provided that it has granted access to them. In practice, this means that any user process can connect to the system bus and to its current session bus, but not to another users' session buses, or even to a different session bus owned by the same user. The latter restriction may change in the future if all user sessions are combined into a single one user bus.
D-Bus provides additional or simplifies existing functionality to the applications, including information sharing, modularity and privilege separation. For example, information on an incoming voice call received through Bluetooth or Skype can be propagated and interpreted by any currently running music player, which can react by muting the volume or pausing playback until the call is finished.
D-Bus can also be used as a framework to integrate different components of an user application. For instance, an office suite can communicate through the session bus to share data between the word processor and the spreadsheet.
Every connection to a bus is identified in the context of D-Bus by what is called a bus name. A bus name consists of two or more dot-separated strings of letters, digits, dashes, and underscores. An example of a valid bus name is
When a process sets up a connection to a bus, the bus assigns to the connection a special bus name called unique connection name. This type of bus names are immutable —it's guaranteed they won't change as long as the connection exists— and, more importantly, they can't be reused during the bus lifetime. This means that no other connection to that bus will ever have assigned such unique connection name, even if the same process closes down the connection to the bus and creates a new one. Unique connection names are easily recognizable because they start with the —otherwise forbidden— colon character. An example of a unique connection name is
:1.1553 (the characters after the colon have no particular meaning).
A process can ask for additional bus names for its connection, provided that any requested name is not already being used by another connection to the bus. In D-Bus parlance, when a bus name is assigned to a connection, it is said the connection owns the bus name. In that sense, a bus name can't be owned by two connections at the same time, but, unlike unique connection names, these names can be reused if they are available: a process may reclaim a bus name released —purposely or not— by another process.
The idea behind these additional bus names, commonly called well-known names, is to provide a way to refer to a service using a prearranged bus name. For instance, the service that reports the current time and date in the system bus lies in the process whose connection owns the org.freedesktop.timedate1 bus name, regardless of which process is it.
Because its original conception as a replacement of several component oriented communications systems, D-Bus shares with its predecessors an object model in which to express the semantics of the communications between clients and services. The terms used in the D-Bus object model mimics those used by some object oriented programming languages. That doesn't mean that D-Bus is somehow limited to OOP languages —in fact, the most used implementation is written in C, a procedural programming language.
In D-Bus, a process offers its services exposing objects. These objects have methods that can be invoked, and signals that the object can emit. Methods and signals are collectively referred as the members of the object. Any client connected to the bus can interact with the object by its members, making requests or commanding the object to perform actions. For instance, an object representing a time service can be queried by a client using a method that returns the current date and time.
A process connected to a D-Bus bus can request it to export as many D-Bus objects as it wants. Each object is identified by an object path, a string of numbers, letters and underscores separated and prefixed by the slash character, called that because of their resemblance to Unix filesystem paths. The object path is selected by the requesting process, and must be unique in the context of that bus connection. An example of a valid object path is
/org/kde/kspread/sheets/3/cells/4/5. However, it's not enforced —but also not discouraged— to form hierarchies within object paths. The particular naming convention for the objects of a service is entirely up to the developers of such service.
Every object is inextricably associated to the particular bus connection where it was exported, and, from the D-Bus point of view, only lives in the context of such connection. Therefore, in order to be able to use a certain service, a client must indicate not only the object path implementing the desired service, but also the bus name under which the service process is connected to the bus. This in turn allows that several processes connected to the bus can export different objects with identical object paths unambiguously.
Members —methods and signals— that can be used with an object are specified by an interface. An interface is a set of declarations of methods (including its passing and returning parameters), and signals (including its parameters), identified by a dot-separated name resembling the Java language interfaces notation. An example of valid interface name is
org.freedesktop.Introspectable. Despite their similarity, interface names and bus names should not be mistaken. A D-Bus object can implement several interfaces, but at least must implement one, providing support for every method and signal defined by it. The combination of all interfaces implemented by an object is called the object type.
D-Bus was conceived as a generic, high-level inter-process communication system. To acomplish such goals, D-Bus communications are based on the exchange of messages between processes instead of "raw bytes". D-Bus messages are high-level discrete items that a process can send through the bus to another connected process. Messages have a well-defined structure, even the types of the data carried in their payload are defined, allowing the bus to validate them and to reject any ill-formed message. In this regard, D-Bus is closer to an RPC mechanism than to a classic IPC mechanism, with its own type definition system and its own marshaling.
- libdbus - a library that allows two applications to connect to each other and exchange messages
- dbus-daemon - a message-bus daemon executable, built on
libdbus, that multiple applications can connect to. The daemon can route messages from one application to zero or more applications, thereby implementing the publish/subscribe paradigm.
- wrapper libraries based on particular application frameworks
Messages received over a D-Bus connection get routed to a specific object, not to a process. It thus appears to clients as if they are interacting with an object whether or not there actually is an object on the other side.
D-Bus defines a name for each object which looks like (but is not actually) a POSIX filesystem path, e.g., /org/kde/kspread/sheets/3/cells/4/5. D-Bus objects' names are conventionally namespaced to help with independently developing code modules. Namespaces are generally prefixed with the developer's reserved domain name components (e.g. /org/kde).
Heavily influenced by the DCOP system used by versions 2 and 3 of KDE, D-Bus has replaced DCOP in the KDE 4 release. An implementation of D-Bus supports most POSIX operating systems, and a port for Windows exists. It is used by Qt 4 and GNOME. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism. It is also used by Xfce.
The usage of D-Bus is steadily expanding beyond the initial scope of desktop environments to cover an increasing amount of system services. For instance, NetworkManager network daemon, BlueZ bluetooth stack and Pulseaudio sound server use D-Bus to provide part or all of its services, and systemd is promoting traditional system daemons to D-Bus services, such as logind.
It is also used as the Wire protocol for the AllJoyn protocol for home automation, to this end AllJoyn adds discovery, session management, security, header compression, embedded device support and makes it transport agnostic.
- Although there are several implementations of D-Bus, the most widely used is the reference implementation libdbus, developed by the same freedesktop.org project that designed the specification. However, libdbus is a low-level implementation that was never meant to be used directly by application developers, but as a reference guide for other reimplementations of D-Bus (such as those included in standard libraries of desktop environments, or in programming language bindings). The freedesktop.org project itself recommends applications authors to "use one of the higher level bindings or implementations" instead.
- The predominance of libdbus as the most used D-Bus implementation caused the terms "D-Bus" and "libdbus" to be often used interchangeably, leading to confusion.
- GDBus is an implementation of D-Bus based on GIO streams included in GLib, aiming to be used by GTK+ and GNOME. GDBus is not a wrapper of libdbus, but a complete and independent reimplementation of the D-Bus specification and protocol.
- QtDBus is an implementation of D-Bus included in the Qt library since its version 4.2. This component is used by KDE applications, libraries and components to access the D-Bus services available in a system.
- In 2013, the systemd project rewrote libdbus in an effort to simplify the code, but it also resulted in a significant increase of the overall D-Bus performance. In preliminary benchmarks, BMW found that the systemd's D-Bus library increased performance by 360%. As of version 221 of systemd, the sd-bus API has been declared stable.
- There is an ongoing development project called kdbus that aims to reimplement D-Bus as a kernel-mediated peer-to-peer inter-process communication mechanism. Beside performance improvements, kdbus would have advantages arising from already existing Linux kernel features such as namespaces and auditing, security from the kernel mediating, closing race conditions, and allowing D-Bus to be used during boot and shutdown (as needed by systemd). kdbus inclusion in the Linux kernel has proven controversial, and As of September 2015[update] has not been merged yet.
- Language bindings
- Several programming language bindings for D-Bus has been developed, such as those for Java, C# and Ruby.
- "Announcing D-Bus 1.10.0 (new stable branch)". 2015-08-25. Retrieved 2015-08-25.
- Havoc's Blog July, 2007
- Cocagne, Tom. "DBus Overview". pythonhosted.org. Retrieved 23 May 2015.
- "Introduction to D-Bus". FreeDesktop.org. Retrieved 3 October 2015. "D-Bus [...] is designed for use as a unified middleware layer underneath the main free desktop environments."
- "gdbus". GNOME developer. GNOME project. Retrieved 4 January 2015.
- "QtDBus module". Qt Project. Qt Project. Retrieved 1 June 2015.
- "DBus-Java Documentation". FreeDesktop.org. Retrieved 4 January 2015.
- "The new sd-bus API of systemd". 19 June 2015. Retrieved 20 June 2015.
- Poettering, Lennart. "The new sd-bus API of systemd". Retrieved 7 October 2015.
we are working on moving things to a true user bus, of which there is only one per user on a system, regardless how many times that user happens to log in
- Robert Love (2005-01-05). "Get on the D-BUS". Linux Journal. Retrieved 2014-10-14.
- "D-Bus Tutorial".
- Poettering, Lennart. "The new sd-bus API of systemd". Retrieved 5 October 2015.
Since systemd's inception it has been the IPC system it exposes its interfaces on.
- "What is D-Bus?". FreeDesktop.org. Retrieved 5 January 2015. "It should be noted that the low-level implementation is not primarily designed for application authors to use. Rather, it is a basis for binding authors and a reference for reimplementations. If you are able to do so it is recommended that you use one of the higher level bindings or implementations."
- "Migrating to GDBus". GNOME Developer. Retrieved 16 June 2015. "dbus-glib uses the libdbus reference implementation, GDBus doesn't. Instead, it relies on GIO streams as transport layer, and has its own implementation for the D-Bus connection setup and authentication."
- Poettering, Lennart. "libsystemd-bus + kdbus plans". systemd-devel mailing list. Retrieved 24 April 2015.
- "ALS: Linux inter-process communication and kdbus". LWN.net. 2013-05-30. Retrieved 2013-11-13.
- "[systemd-devel] [ANNOUNCE] systemd v221". freedesktop.org. 2015-06-19. Retrieved 2015-06-20.
- Jake Edge (2013-05-30). "ALS: Linux interprocess communication and kdbus". LWN.net. Retrieved 2014-04-11.
- Jonathan Corbet (2014-01-13). "The unveiling of kdbus". LWN.net. Retrieved 2014-04-11.
- Corbet, Jonathan. "The kdbuswreck". LWN.Net. Retrieved 29 June 2015.
- "D-Bus Bindings". FreeDesktop.org. Retrieved 5 January 2015.
- D-Bus home page at Freedesktop.org
- Introduction to D-Bus on the Freedesktop.org wiki
- It doesn't look like kdbus will make it for Linux kernel 4.1, Phoronix, April 26, 2015, by Michael Larabel