The message bus and activity system penetrate into the Linux desktop-general Linux technology-Linux programming and kernel information. The following is a detailed description. D-BUS is a promising message bus and activity system that is starting to penetrate into Linux®Desktop. Understand the reason for creating it, its purpose, and development prospects.
D-BUS is essentially an implementation of inter-process communication (IPC. However, there are some features that make D-BUS far from "just another IPC implementation ". There are many different IPC implementations, because each one is positioned to solve specific clearly defined problems. CORBA is a powerful solution for complex IPC in object-oriented programming. DCOP is a lightweight IPC framework with few functions, but can be well integrated into K desktop environments. SOAP and XML-RPC are designed for Web services and therefore use HTTP as their transport protocol. D-BUS is designed for desktop applications and OS communications.
Desktop Application Communication
In a typical desktop, multiple applications are running, and they often need to communicate with each other. DCOP is a KDE solution, but it depends on Qt, so it cannot be used in other desktop environments. Similarly, Bonobo is a GNOME solution, but it is very cumbersome because it is based on CORBA. It also depends on GObject, so it cannot be used outside GNOME. The D-BUS's goal is to replace DCOP and Bonobo with a simple IPC and integrate these two desktop environments. Because the dependencies required by the D-BUS are minimized, other applications that may use the D-BUS do not have to worry about introducing too many dependencies.
Desktop/operating system communication
The term "Operating System" includes not only the kernel but also the background processes of the system. For example, by using the D-BUS's udev (replacing devfs in Linux 2.6, providing a dynamic/dev directory), a signal is sent when a device (such as a USB camera) is inserted. In this way, hardware can be integrated into the desktop more closely to improve the user experience.
D-BUS Characteristics
D-BUS has some interesting features that make it like a very promising choice.
The Protocol is low-latency and low-cost. It is designed to be small and efficient to minimize the round-trip time of transmission. In addition, the Protocol is binary rather than text, thus eliminating the time-consuming serialization process. Because it is only applicable to the use cases processed by local machines, all messages are sent in the natural byte order. Byte order is declared in each message, so if a D-BUS message is transmitted over the network to a remote host, it can still be correctly identified.
From the developer's point of view, D-BUS is easy to use. Wired protocols are easy to understand, and client libraries are packaged in an intuitive way.
The Library is also designed for packaging other systems. It is expected that GNOME will use GObject to create the wrapper for the wrapper D-BUS (which actually already exists, integrating the D-BUS into their event loop), and KDE will use Qt to create a similar wrapper. Because Python has object-oriented features and flexible types, it already has a Python package with similar interfaces.
Finally, D-BUS is being developed under the protection of freeyuntop.org, where interested members from GNOME, KDE and other organizations are involved in the design and implementation.
Internal Working Style of D-BUS
The typical D-BUS settings will consist of several bus. There will be a persistent system bus that will start at boot. This bus is used by the operating system and background processes, and is very secure, so that any application cannot cheat system events. There will also be many session buses, which are private to the user when the user logs on. It is a session bus used by your applications to communicate with each other. Of course, if an application needs to receive messages from the system bus, it is better to connect directly to the system bus-however, the messages it can send will be limited.
Once an application connects to a bus, they must declare the messages they want to receive by adding matchers. A set of rules is specified for messages that can be received based on interfaces, object paths, and methods (see the following section ). In this way, the application can focus on the content they want to process to achieve efficient message routing and maintain the expected number of messages on the bus, in this way, the performance of all applications will not degrade and become slow due to these messages.
Object
Essentially, D-BUS is a peer-to-peer protocol-each message has a source and a destination. These addresses are specified as object paths. Conceptually, all applications that use a D-BUS contain a set of objects that are sent to or sent from a specific object-not an application-that are identified by the object path.
In addition, each object supports one or more interfaces (interfaces ). These interfaces look like Java interfaces or pure virtual classes in C ++ ). However, there is no option to check whether the objects implement the interfaces they declare, and there is no way to investigate the objects internally to list the interfaces they support. An interface is used for namespaces and method names. Therefore, a single object can have multiple methods with the same name and different interfaces.
Message
There are four types of messages in the D-BUS: method calls, method returns, signals, and errors ). To execute methods for D-BUS objects, you need to send a method call message to the object. It completes some processing and returns a method to return a message or error message. The difference between signals is that they do not return any content: neither a "signal return" message nor any type of error message.
Messages can also have any parameters. Parameters are strongly typed, and the range of types is from basic non-derived types (booleans), bytes, INTEGER (integers) to high-level data structures (strings) array (arrays) and Dictionary (dictionaries )).
Service
Services are the highest level of abstraction of D-BUS, and their implementations are still evolving. An application can register a service through a bus. if the service is successful, the application has obtained the service. Other applications can check whether a specific service already exists on the bus, and if not, ask the bus to start it. The details of service abstraction-especially Service Activation-are currently under development and should change.
Use Cases
Although the D-BUS is relatively new, it was quickly adopted. As mentioned above, you can build a udev with D-BUS support so that it can send a signal when hot-swappable (hot-plug) devices. Any application can listen on these events and execute actions when these events are received. For example, gnome-volume-manager can detect the insertion of a USB storage stick and automatically mount it. Alternatively, it can automatically download photos when a digital camera is inserted.
A more interesting but impractical example is the combination of Jamboree and Ringaling. Jamboree is a simple music player that has a D-BUS interface so that it can be told to play, to the next song, to change the volume and so on. Ringaling is a small program that opens/dev/ttyS0 (a serial port) and observes the received content. When Ringaling finds the text "RING", it tells Jamboree via D-BUS to reduce the volume. The final result is that if a modem is inserted on your computer and the phone rings, the Music volume will decrease for you. This is exactly what computers are pursuing!
Sample Code
Now let's come up with some examples of using D-BUS code.
The dbus-ping-send.c sends a parameter per second "Ping!" as the string via the session Bus !" . I use Glib to manage the bus so that I do not need to handle the connection details of the bus myself.
Configuration 1. dbus-ping-send.c
