D-Bus
In computing, D-Bus
is a software bus, inter-process communication, and remote procedure call mechanism that allows communication between multiple processes running concurrently on the same machine. D-Bus was developed as part of the freedesktop.org project, initiated by Havoc Pennington from Red Hat 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 should not be confused with D-Bus itself, as other implementations of the D-Bus specification also exist, such as GDBus, QtDBus, dbus-java and sd-bus.
Overview
D-Bus is an IPC mechanism initially designed to replace the software component communications systems used by the GNOME and KDE Linux desktop environments. The components of these desktop environments are normally distributed in many processes, each one providing only a few —usually one— services. 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 becomes an inefficient and quite unreliable approach. Instead, D-Bus provides a software-bus abstraction 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 all processes connected to the bus can communicate with each other through it.
Linux desktop environments take advantage of the D-Bus facilities by instantiating not one bus but many:
- a single system bus, available to all users and processes of the system, that provides access to system services
- 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
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 by pausing playback until the call is finished.
D-Bus can also be used as a framework to integrate different components of a user application. For instance, an office suite can communicate through the session bus to share data between a word processor and a spreadsheet.
D-Bus specification
Bus model
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. Bus names of this type 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 .
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 bus name, regardless of which process it is.
Bus names can be used as a simple way to implement single instance applications. It can also be used to track a service process lifecycle, since the bus sends a notification when a bus name is released due to a process termination.
Object model
Because of its original conception as a replacement for 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 mimic 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 by exposing objects. These objects have methods that can be invoked, and signals that the object can emit. Methods and signals are collectively referred to as the members of the object. Any client connected to the bus can interact with an object by using its methods, 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 client can also listen to signals that an object emits when its state changes due to certain events, usually related to the underlying service. An example would be when a service that manages hardware devices —such as USB or network drivers— signals a "new hardware device added" event. Clients should instruct the bus that they are interested in receiving certain signals from a particular object, since a D-Bus bus only passes signals to those processes with a registered interest in them.
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. 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, but many developers choose to namespace them using the reserved domain name of the project as a prefix.
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 providing 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 and signals identified by a dot-separated name resembling the Java language interfaces notation. An example of a valid interface name is. 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.
When using an object, it's a good practice for the client process to provide the member's interface name besides the member's name, but is only mandatory when there is an ambiguity caused by duplicated member names available from different interfaces implemented by the object —otherwise, the selected member is undefined or erroneous. An emitted signal, on the other hand, must always indicate to which interface it belongs.
The D-Bus specification also defines several standard interfaces that objects may want to implement in addition to its own interfaces. Although technically optional, most D-Bus service developers choose to support them in their exported objects since they offer important additional features to D-Bus clients, such as introspection. These standard interfaces are:
- : provides a way to test if a D-Bus connection is alive.
- : provides an introspection mechanism by which a client process can, at run-time, get a description of the interfaces, methods and signals that the object implements.
- : allows a D-Bus object to expose the underlying native object properties or attributes, or simulate them if it doesn't exist.
- : when a D-Bus service arranges its objects hierarchically, this interface provides a way to query an object about all sub-objects under its path, as well as their interfaces and properties, using a single method call.
Communications model
D-Bus was conceived as a generic, high-level inter-process communication system. To accomplish 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, 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.
The bus supports two modes of interchanging messages between a client and a service process:
- One-to-one request-response: This is the way for a client to invoke an object's method. The client sends a message to the service process exporting the object, and the service in turn replies with a message back to the client process. The message sent by the client must contain the object path, the name of the invoked method, and the values of the input parameters as defined by the object's selected interface. The reply message carries the result of the request, including the values of the output parameters returned by the object's method invocation, or exception information if there was an error.
- Publish/subscribe: This is the way for an object to announce the occurrence of a signal to the interested parties. The object's service process broadcasts a message that the bus passes only to the connected clients subscribed to the object's signal. The message carries the object path, the name of the signal, the interface to which the signal belongs, and also the values of the signal's parameters. The communication is one-way: there are no response messages to the original message from any client process, since the sender knows neither the identities nor the number of the recipients.
The D-Bus specification defines the wire protocol: how to build the D-Bus messages to be exchanged between processes within a D-Bus connection. However, it does not define the underlying transport method for delivering these messages.
Internals
Most existing D-Bus implementations follow the architecture of the reference implementation. This architecture consists of two main components:- a point-to-point communications library that implements the D-Bus wire protocol in order to exchange messages between two processes. In the reference implementation this library is '. In other implementations may be wrapped by another higher-level library, language binding, or entirely replaced by a different standalone implementation that serves the same purpose. This library only supports one-to-one communications between two processes.
- a special daemon process that plays the bus role and to which the rest of the processes connect using any D-Bus point-to-point communications library. This process is also known as the message bus daemon, since it is responsible for routing messages from any process connected to the bus to another. In the reference implementation this role is performed by ', which itself is built on top of. Another implementation of the message bus daemon is ', which is built on top of '.
The communications libraries of both processes must agree on the selected transport method and also on the particular channel used for their communication. This information is defined by what D-Bus calls an address. Unix-domain socket are filesystem objects, and therefore they can be identified by a filename, so a valid address would be
unix:path=/tmp/.hiddensocket. Both processes must pass the same address to their respective communications libraries to establish the D-Bus connection between them. An address can also provide additional data to the communications library in the form of comma-separated key=value pairs. This way, for example, it can provide authentication information to a specific type of connection that supports it.When a message bus daemon like is used to implement a D-Bus bus, all processes that want to connect to the bus must know the bus address, the address by which a process can establish a D-Bus connection to the central message bus process. In this scenario, the message bus daemon selects the bus address and the remainder processes must pass that value to their corresponding or equivalent libraries. defines a different bus address for every bus instance it provides. These addresses are defined in the daemon's configuration files.
Two processes can use a D-Bus connection to exchange messages directly between them, but this is not the way in which D-Bus is normally intended to be used. The usual way is to always use a message bus daemon as a communications central point to which each process should establish its point-to-point D-Bus connection. When a process —client or service— sends a D-Bus message, the message bus process receives it in the first instance and delivers it to the appropriate recipient. The message bus daemon may be seen as a hub or router in charge of getting each message to its destination by repeating it through the D-Bus connection to the recipient process. The recipient process is determined by the destination bus name in the message's header field, or by the subscription information to signals maintained by the message bus daemon in the case of signal propagation messages. The message bus daemon can also produce its own messages as a response to certain conditions, such as an error message to a process that sent a message to a nonexistent bus name.
improves the feature set already provided by D-Bus itself with additional functionality. For example, service activation allows automatic starting of services when needed —when the first request to any bus name of such service arrives at the message bus daemon. This way, service processes neither need to be launched during the system initialization or user initialization stage nor need they consume memory or other resources when not being used. This feature was originally implemented using setuid helpers, but nowadays it can also be provided by systemd's service activation framework. Service activation is an important feature that facilitates the management of the process lifecycle of services.
History and adoption
D-Bus was started in 2002 by Havoc Pennington, Alex Larsson and Anders Carlsson. The version 1.0 —considered API stable— was released in November 2006.s.
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.
One of the earlier adopters was the Hardware Abstraction Layer. HAL used D-Bus to export information about hardware that has been added to or removed from the computer.
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. systemd uses the D-Bus wire protocol for communication between Systemd#Core_components_and_libraries| and systemd, and is also promoting traditional system daemons to D-Bus services, such as logind. Another heavy user of D-Bus is Polkit, whose policy authority daemon is implemented as a service connected to the system bus.
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.