D-bus Learning (1): overview

　　The D-Bus method is very important in mobile phone operating systems, including Linux-based operating systems such as Maemo and Moblin. It is estimated that Andriod is also widely used. For more information about D-Bus, see http://www.freedesktop.org/wiki/Software/dbus.

, There are a lot of learning materials on the Internet, in http://blog.chinaunix.net/u3/111961/

There are a lot of Chinese materials and a lot of network information is collected. I decided to study hard and take notes. The main information from the above two websites, especially freedesktop D-Bus Tutorial, and refer to the wiki, and http://www.ibm.com/developerworks/cn/linux/l-dbus.html

And http://blog.csdn.net/cuijpus/archive/2008/01/30/2073962.aspx

.

There are many IPC (Interprocess communication

) For different solutions: 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. D-bus (where D originally represents the desktop "desktop"), that is, the communication bus used for the desktop operating system. Now it is gradually introduced into the embedded system, but the original name is retained.

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. Compared with other IPC, D-bus has lost some unnecessary and complex things. It is precisely for this reason that D-bus is fast and simple. D-bus does not directly compete with low-level IPC, such as sockets, shared memory or message queues. The IPC of these low-level nodes has their own characteristics and does not conflict with D-bus.

Three Layers of D-Bus

D-bus is a message bus system used for communication between processes. It is a three-layer architecture IPC System, including:

• Function libraryLibbench

  Used to connect two applications and exchange messages.

• A message bus daemon constructed based on libbench can be connected to multiple applications at the same time, and messages from one application can be routed to 0 or multiple other programs.
• Encapsulation library or bundle based on a specific application framework (Wrapper libraries or bindings

  ). For example, libbench-glib and libbench-qt are bound to other languages, such as Python. Most developers use the APIs of these encapsulated libraries because they simplify the D-Bus programming details. Libbench is intentionally designed as the underlying backend for higher-level binding (Low-level backend

  ). Most libbench APIs are only used for binding.

System bus and session bus

In D-bus, "bus" is the core concept. It is a channel where different programs can perform some operations, for example, call methods, send signals, and listen for specific signals. On a machine, the bus guard has multiple instances ). These buses are independent of each other.

A persistentSystem bus ):

• It starts 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.
• It is the communication between desktop sessions and the operating system. The operating system generally includes kernel and system daemon processes.
• The most common aspect of this channel is to send system messages, such as inserting a new storage device, having a new network connection, and so on.

There will also be manySession bus (session buses ):

• These buses are private to the user after the user logs on. It is a session bus used by your applications to communicate with each other.
• Communication between two desktop applications in the same desktop session enables the desktop session to be integrated as a whole to solve process lifecycle problems. This is widely used in GNOME and KDE desktops.

For some remote workstation, there may be some problems in system bus, such as hot swapping, whether to notify the remote terminal, this will be the kernel to expose the capabilities of some devices, however, we are now concerned about D-Bus because the use of handheld terminal devices will not appear. In Internet Tablet and our mobile phone system, all applications run with a user ID, so there is only one session channel, this is obviously different from the Linux Desktop System.

D-Bus 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. 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 main purpose of D-Bus is to provide the following high-level functions:

• Structured namespace
• Architecture-independent data format
• Supports most common data elements in messages.
• Universal remote call interface with Exception Handling
• Supports broadcast-type communication.

Bus daemon

Bus daemon is a special process that can send messages from one process to another. Of course, if many applications are linked to this channel, the daemon process will forward the message to all the programs with these links. At the bottom layer, D-Bus only supports point-to-point communication. Generally, local Sockets (AF_UNIX) are used to communicate with bus daemon. The point-to-point feature of D-Bus is abstracted by bus daemon. It is used by bus daemon to address and send messages. Therefore, each application does not need to care about the process to which messages are sent. D-Bus generally includes the following steps to send a message (normally ):

• Creates and sends messages to the background bus daemon process. There are two context switches in this process.
• The background bus daemon process processes the message and forwards it to the target process. This also causes context switching.
• The target program receives the message and then responds to the message according to the type of the message: either give a confirmation, response, or ignore it. In the last case, the first two messages of the "Notification" type will cause further switchover.

To sum up, if you want to transmit a large amount of data between different processes, D-Bus may not be the most effective method. The most effective method is to use shared memory, however, the management of shared memory is also quite complicated.

 

Related Links: My Linux articles