D-Bus
From Wikipedia, the free encyclopedia
| Latest release: | 1.0.1 / November 17, 2006 |
|---|---|
| OS: | Unix-like |
| Use: | Inter-process communication |
| License: | GPL or Academic Free License |
| Website: | freedesktop.org/wiki/Software/dbus |
D-Bus is a free software project which offers a simple way for applications to communicate with one another. It is developed as part of the freedesktop.org project.
D-Bus was heavily influenced by the DCOP system and will replace DCOP in the upcoming KDE 4 release; already implemented in GNOME.
Contents |
[edit] Introduction
D-Bus allows other programs to register on it for offering services to others. It also offers client programs the possibility to look up which services are available. Programs can also register as waiting for events of the kernel like hot swapping hardware.
D-Bus is implemented as a daemon. Users can run several instances of it, each called a channel. Usually there will be a privileged channel called the system channel, and a private instance for each logged user. The private instances are required because the system channel will have restrictions for access.
The main mission of the system channel will be to deliver the signals from the HAL daemon to the processes interested in them. The mission of the private instances is to provide communication among any applications of the user without restrictions.
[edit] Architecture
D-Bus is an inter-process communication (IPC) system with three architectural layers:
- A library, libdbus, that allows two applications to connect to each other and exchange messages.
- 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 other applications.
- Wrapper libraries based on particular application frameworks.
D-Bus is designed for two specific cases:
- Communication between desktop applications in the same desktop session; to allow integration of the desktop session as a whole, and address issues of process lifecycle.
- Communication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processes.
[edit] Mechanisms
Each application using D-Bus contains objects, which generally (but need not) map to GObject, QObject, C++ objects, or Python objects. An object is an instance rather than a type. When messages are received over a D-Bus connection, they are sent to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to the user as if an object is serialized across the IPC connection, no matter if there is an object on the other side or not.
To allow messages to specify their destination object, there has to be a way to refer to an object. In many programming languages, this is normally called a pointer or reference. However, these references are implemented as memory addresses relative to the address space of the application, and thus can't be passed from one application to another.
To solve this, D-Bus introduces a name for each object. The name looks like a filesystem path, for example an object could be named /org/kde/kspread/sheets/3/cells/4/5. Human-readable paths are preferred, but developers are free to create an object named /com/mycompany/c5yo817y0c1y1c5b if it makes sense for their application.
The D-Bus objects' names are namespaced to ensure different code modules are kept separated. Namespaces are generally prefixed with the developer's domain name components (eg. /org/kde).
