The message bus and activity system penetrate into the Linux Desktop

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.