Linux Dbus Bus __linux

D-bus three-tier architecture

D-bus is a message bus system for communication between applications for communication between processes. It is a 3-tier architecture of the IPC system, including:

1, function library Libdbus, for two applications to contact and interactive messages.

2. A message bus daemon based on Libdbus constructs can be connected to multiple applications at the same time, and can route messages from one application to 0 or more other programs.

3. Encapsulation libraries or bundles based on a particular application framework (wrapper libraries or bindings). For example, Libdbus-glib and LIBDBUS-QT, and bindings in other languages, such as Python. Most developers use APIs for these wrapper libraries because they simplify the D-bus programming details. Libdbus is intentionally designed to be a higher-level binding of the underlying back-end (Low-levelbackend). Most Libdbus APIs are intended only to implement bindings.

Bus

In D-bus, "bus" is the core concept, it is a channel: different programs can do some operations through this channel, such as method calls, send signals and listen to specific signals. There are multiple instances of the bus guard on a single machine (instance). These buses are independent of each other.

A persistent system bus:

It starts at boot time. This bus is used by the operating system and background processes, and is very secure so that any application cannot spoof system events. It is the communication between the desktop session and the operating system, where the operating system generally includes the kernel and the system daemon. The most common aspect of this channel is sending system messages, such as inserting a new storage device, having a new network connection, and so on.

There will also be many session bus sessions buses:

These buses start after the user logs on, and are owned by that user. It is a session bus that the user's application uses to communicate. Communication between two desktop applications in the same desktop session enables desktop sessions to be integrated together as a whole to resolve issues related to the lifecycle of a process. This is used heavily on GNOME and KDE desktops.

For some remote workstations, there may be some problems in system bus, such as hot swappable, whether it is necessary to notify the terminal of the distal end, which will allow the kernel to expose some of the equipment, but we now care about D-bus because of the use of hand-held terminal equipment, which will not appear. On the Internet Tablet, including our mobile system, all applications run with a single user ID, so there is only one session channel, which is clearly different from the Linux desktop system.

D-bus are low latency and low-cost, designed to be small and efficient in order to minimize the round-trip time of the transfer. In addition, the protocol is binary, not text, which eliminates time-consuming serialization processes. From a developer's point of view, D-bus is easy to use. The wired protocol is easy to understand and the client library is packaged in an intuitive way. The main purpose of D-bus is to provide some of the higher levels of functionality as follows:

A, structured name space

B, schema-independent data format

C, most of the common data elements in the support message

D, common remote Call interface with exception handling

E, communication that supports broadcast types

Buses Daemon Bus Guardian

Bus daemon is a special process: This process can pass messages to another process from one process. Of course, if a lot of applications are linked to this channel, the daemon process forwards the messages to all of these linked programs. At the bottom, D-bus only supports point-to-point communications, and generally uses local sockets (Af_unix) to communicate between applications and bus daemon. D-bus point to Point is Busdaemon abstracted by Busdaemon to complete addressing and sending messages, so each application does not have to care about which process to send the message to. D-bus sending messages usually contains the following steps (normally):

Create and send messages to the background bus daemon process, which will have two context switches.

The background bus daemon process processes the message and forwards it to the target process, which also causes the target program of the context to receive the message and then respond differently depending on the type of message: either give a confirmation, answer it, or ignore it. Last case for messages of type "notification", the first two will cause further context switches.

For the most part, if you're going to transfer a lot of data between different processes, D-bus may not be the most efficient way to use shared memory, but the management of shared memory is also quite complex.

D-bus Process Communication Simple framework

D-bus Common Concepts

Native objects and object paths

All applications that use D-bus contain objects that are sent to an object instead of the entire application when a message is received via a d-bus connection. In development, the program framework defines such objects, such as Java,gobject,qobject, and so on, and becomes the native object in D-bus.

For the underlying D-bus protocol, the Libdbus API, ignores the native object, which uses a concept called object path. Through object path, high-level programming can name object instances and allow remote applications to reference them. These names look like file system paths, such as an object might be called "/ORG/KDE/KSPREAD/SHEETS/3/CELLS/4/5." Readable pathname is an encouraged practice, but it also allows you to use such as "/com/mycompany/c5yo817y0c1y1c5b", as long as it can be used by your application. The Namespacing object path starts with all of the developer's domain names (such as/ORG/KDE) to avoid interfering with different code modules of the system.

To put it simply: An application creates an instance of an object for D-bus communication, which has a name that resembles a path, such as/com/mycompany, which is unique in the global (session or system) and is used for routing messages.

Method and signal Methodsand signals

Each object has two types of members: Method and signal. method is the same concept in Java, the method is a function code, with input and output. Signals are broadcast to all other entities of interest, and signals can be payload with data.

There are four types of messages in D-bus: Method Calls (methods calls), method returns (methods returns), signals (signals), and errors (errors). To execute the method of the D-bus object, you need to send a method call message to the object. It will do some processing (that is, the Method,method in the object can have input parameters.) and returns, returns a message or an error message. The difference between signals is that they do not return anything: there is neither a "signal return" message nor any type of error message.

Interface interface

Each object supports one or more interfaces, which are a set of methods and signals that interface defines the type of an object entity. D-bus the name of the interface, similar to org.freedesktop.Introspectable. Developers typically use the name of the programming language class as the interface name.

Proxies Agent

Proxy objects are used to represent other remote object. When we trigger the method of the proxy object, we will send a method_call message on the D-bus and wait for the reply to return according to the reply. Very convenient to use, just like calling a local object.

Bus names name

When an application is connected to the bus Daemon,daemon immediately assigns a name to this connection, called the unique connection name, which uniquely identifies the name with a colon: beginning, for example: 34-907, the name is unique throughout the daemon lifecycle. But this name is always temporarily allocated, uncertain, and difficult to remember, so applications can require another name well-known name to correspond to this unique identifier, just as we use the domain name to correspond to the IP address. For example, you can use Com.mycompany to map: 34-907. The application may require an additional well-known name (Well-knownname). For example, you can write a specification to define a name called Com.mycompany.TextEditor. Your agreement can specify that you own the name, and an application should have an object that supports interface Org.freedesktop.FileHandler under the path/com/mycompany/textfilemanager. The application can send messages to this bus name, object, and interface to execute the method call.

When an application ends or crashes, the OS kernel closes its bus connection. The bus sends notification messages to tell other applications that the name of this application has lost his owner. When this type of notification is detected, the application can know the lifecycle of other applications. This approach can also be used for applications with only one instance, that is, the case where the same two applications are not opened.

Address

Connection is established with server and client, for bus daemon, the application is Client,daemon is the server. An D-bus address is where the server listens, where the client is used to connect, for example, the UNIX:PATH=/TMP/ABCEDF identity server listens on the UNIX domain socket in the path/TMP/ABCEDF. The address can be a specified TCP/IP socket or other mode of transmission that is or will be defined in the D-bus protocol.

If you use bus Daemon,libdbus, you will automatically get the address of Session bus Damon by reading the environment variable, and obtain the address of system bus by checking a specified UNIX domain socket path. If you use D-bus, but not daemon, you need to define that the application is server, the client, and define a mechanism that they recognize the server's address, which is not the usual practice.

With the above description, we can get the following view:

Address–> [busname]–> path–> interface–> method

Bus name is not necessary, it is used for routing only in the case of daemon, and direct connection to point-to-point is not required.

Simply put: Address is a D-bus server that listens for client addresses, and when a client connects D-bus, usually Daemo, the client has a bus Name. Other applications can determine which application is relevant based on the bus Name in the message. When the message is passed in the bus, it is passed to the application, and then according to the ObjectPath, it is sent to the concrete object instance in the application, which is the object created by interface in the application. These interface have method and Singal two to send, receive, and respond to messages.

A schematic of an example:

D-bus message

Messages are passed between processes through D-bus. There are four types of messages:

One, method call message: A method that will trigger the object

Methods return message: The result returned by the triggered method

Third, the error message: The triggered method returns an exception

IV. signal message: notification, which can be considered as an event message.

A message has a header header, which has field, a message body, which has parameter arguments. The message header contains the message body's routing information, and the message body is the net-load payload. Header fields may include the bus name of the sender, the bus name of the destination, the method or signal name, and so on, one of the header fields is the type used to describe the parameters in the body, for example, "I" identifies a 32-bit integer, and "II" indicates that the net charge is 2 32

Send a scenario for a call message

A method call message from process A to process b,b will answer a method return message or an error message. In each call message comes with a serial number, and the answer message contains the same number so that it can correspond. Their processing process is as follows:

If a proxy is provided, a method that triggers the remote object of another process by triggering the method of a local object. Applying a method that invokes a proxy, the proxy constructs an approach called message sent to the remote process.

For the underlying API, no proxy is used, and the application needs to construct the method call message itself.

A method call message contains the bus name of the remote process, the name of the approach, the parameter of the method, the object path in the remote process, and the optional interface name.

Method call message sent to Bus daemon

Bus Daemon View the destination's bus name. If a process corresponds to this name, bus daemon sends the method call message to the process. If no match is found, bus daemon creates an error message to return as an answer.

When the process receives, it splits the method call message. For a simple low-level API scenario, the method is executed immediately and an reply message is sent to the bus daemon. For high-level APIs, the object Path,interface and method are examined, triggering a native object, and encapsulating the return value in a reply message.