Two forms of Dbus application and its realization

Describes the two forms of applications based on Dbus design and how to use Gdbus to implement them.

Dbus applications can be based on the total line structure of the Dbus daemon, each Dbus request is forwarded via Dbus Daemon, or a point-to-point star structure, and a direct peer2peer connection between the client and the server. The two structures have their advantages and disadvantages: The bus-type structure is clear, the server needs to maintain fewer connections, in fact, only a connection with the Dbus daemon, broadcast messages can easily be sent to the various client;p2p forms of dbus communication in the middle because less dbus Daemon relay, so the performance is better, about 30% increase.

Based on the glib provided Gbus implementation based on the above two forms of Dbus application is very simple:

1. Preparatory work

1.1 provides an XML file for code generation

This XML data is referred to in Gdbus as introspection data, which describes the interface name and parameters of the GObject that provide the service. For Gdbus-codegen You can use this XML file to generate code that is used on the client and server side. For bus-type Dbus applications and Peer-to-peer Dbus applications, this code is generic.

1.2 Compiling the generated code

The generated code needs to be linked separately to two processes: code with skeleton, running on the server side, code with a proxy, running on the client side.

2. General Style

2.1 Server

2.1.1 Provides a glib mainloop based on the default context

2.1.2 Call G_bus_own_name Register this server on the bus

2.1.3 provides a on_name_acquried callback function that creates a skeleton object in the callback function and invokes the G_dbus_interface_skeleton_export output to the bus

2.2 Client

2.2.1 Provides a glib mainloop based on the default context

2.2.2 Calls Dbus_proxy_new_sync gets the proxy object that corresponds to the server's skeleton object, as a parameter to subsequent Dbus method calls

3. Peer-to-peer type

3.1 Server

3.1.1 Provides a glib mainloop based on the default context

3.1.2 Call G_dbus_server_start Start a server

3.1.3 Call G_signal_connect, associating callback to the "new-connection" signal on the server object

3.1.4 provides callback, creates a skeleton object in callback, and invokes G_dbus_interface_skeleton_export output to this newly established connection

3.2 Client

3.2.1 Provides a glib mainloop based on the default context

3.2.2 Call G_dbus_connection_new_for_address_sync to establish a connection to the server

3.2.3 Calls Dbus_proxy_new_sync creates a proxy object that corresponds to the server side skeleton object, as a parameter to subsequent Dbus method calls