| Developer(s) | Red Hat and the community |
|---|---|
| Stable release | 1.4.16[1] / September 21, 2011 |
| Operating system | Cross-platform |
| Type | Inter-process communication |
| License | GNU General Public License or Academic Free License 2.1[2] |
| Website | www.freedesktop.org/wiki/Software/dbus |
In computing, D-Bus (Desktop Bus) is a simple inter-process communication (IPC) open-source system for software applications to communicate with one another. Heavily influenced by KDE2–3's DCOP system, 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.
Red Hat operates as the primary developer of D-Bus as part of the freedesktop.org project.
Contents |
In a D-Bus system, a process that offers a service registers with a central server. A process that wants to use a service checks the registry to find out who is offering it. A process can also register as waiting for events of the kernel, such as the event that hot-swapping hardware has been attached.
D-Bus functions are provided by daemons, typically running the program dbus-daemon. There can be several such daemons in a system, with the service provided by an individual daemon called a channel. Most systems implement a privileged system channel, plus a private channel for each logged-in user. The private channels are required because the system channel has access restrictions.
The purpose of the private channel is to provide unrestricted communication among any applications of the user.
D-Bus works with Unix sockets between applications and the daemons (applications communicate with each other through a daemon), but work is being done to create a 'peer-to-peer' socket type in the Linux kernel able to route messages between applications, leaving the daemon as a top-level manager.[3] The main advantage of this new approach is that it improves speed by halving the number of memory-copy operations.
D-Bus has three architectural layers:[4]
libdbus - a library that allows two applications to connect to each other and exchange messagesdbus-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.The design of D-Bus addresses two specific cases:
Each application using D-Bus contains objects that usually map to GObject, QObject, C++ objects, or Python objects. Each D-bus object operates as an instance rather than as a type. Messages received over a D-Bus connection get routed to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to users as if they are interacting with an object across the IPC connection, whether or not there is an object on the other side.
To allow messages to specify their destination object, the system needs a way to identify and address an object. For this purpose, D-Bus defines a name for each object. The name looks like a filesystem path, for example an object could have the name /org/kde/kspread/sheets/3/cells/4/5. D-Bus encourages human-readable paths, 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 help with independently developing code modules. Namespaces are generally prefixed with the developer's reversed domain name components (e.g. /org/kde).
|
||||||||||||||||
|
|||||||||||