Transfer from http://blog.csdn.net/coroutines/article/details/39313825
Two kinds of morphology and realization of Dbus application
Introduce the two forms of application based on Dbus design and how to use Gdbus to achieve it.
An Dbus-based application can be a total linetype structure that uses the Dbus daemon, each Dbus request is forwarded via Dbus Daemon, or a point-to-point star structure, with a direct peer2peer connection between the client and the server. These two structures have advantages and disadvantages: The structure of the bus type is clear, the server needs to maintain less connections, in fact, there is only one connection to Dbus daemon, broadcast messages can be easily sent to various client;p2p forms of dbus communication in the middle because of the lack of dbus Daemon, so the performance is better, about 30% increase.
Based on the glib provided by the Gbus implementation of the Dbus based on the above two forms of application is very simple:
1. Preparatory work
1.1 provides an XML file for code generation
This XML data is called introspection data in Gdbus to describe the interface name and parameters of the GObject that provides the service. For Gdbus-codegen You can use this XML file to generate code that is used on the client and server side. This code is common for bus-type Dbus applications and peer-to dbus applications.
1.2 Compiling the generated code
The generated code needs to be linked to two processes: code with the skeleton typeface, running on the server side, code with the word proxy, and running on the client side.
Gdbus-codegen rules for automatically generated code can be consulted: http://people.freedesktop.org/~david/gio-gdbus-codegen-20110412/gdbus-codegen.html
2. Total line Style
2.1 Server
2.1.1 Provides a glib mainloop based on the default context
2.1.2 Call G_bus_own_name to register the server on the bus
2.1.3 provides a callback function for on_name_acquried, creating a Skeleton object in the callback function, and invoking 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 Call Dbus_proxy_new_sync to get the proxy object corresponding to the skeleton object of the server, as a parameter for subsequent Dbus method calls
A.consider the following d-bus introspection XML.
<Interfacename= "NET." Corp.MyApp.Frobber "> <Methodname= "HelloWorld"> <Argname= "Greeting"direction= "in"type= "S"/> <Argname= "Response"direction= "Out"type= "S"/> </Method> <Signalname= "Notification"> <Argname= "Icon_blob"type= "Ay"/> <Argname= "height"type= "I"/> <Argname= "Messages"type= "as"/> </Signal> < Propertyname= "Verbose"type= "B"Access= "ReadWrite"/></Interface>
B. On the server side
StaticGbooleanon_handle_hello_world (Myappfrobber*Interface, Gdbusmethodinvocation*Invocation,ConstGchar *greeting, Gpointer user_data) { if(G_strcmp0 (Greeting,"Boo") !=0) {Gchar*response; Response= g_strdup_printf ("word! You said '%s '.", greeting); My_app_complete_hello_world (Interface, invocation, response); G_free (response); } Else{g_dbus_method_invocation_return_error (My_app_error, my_app_error_no_whining, "Hey,%s, there'll be no whining!", G_dbus_method_invocation_get_sender (invocation)); } returnTRUE;} [...] Interface=my_app_frobber_skeleton_new (); My_app_frobber_set_verbose (Interface, TRUE); G_signal_connect (Interface, "Handle-hello-world", G_callback (On_handle_hello_world), some_user_data); [...] Error=NULL; if(!g_dbus_interface_skeleton_export (G_dbus_interface_skeleton (Interface), connection,"/path/of/dbus_object", &error)) { /*Handle Error*/ }
C.client End
Myappfrobber *proxy; Gerror *error;error = Null;proxy = My_app_frobber_proxy_new_for_bus_sync ( g_bus_type_session, G_DBUS_PROXY_ Flags_none, "net. Corp.myapp ",/ * Bus name */ "/net/corp/myapp/somefrobber ",/* Object */ NULL,/ * gcancellable* */< C13/>&ERROR);/* Stuff with Proxy */g_object_unref (proxy);
3. 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 to start a server
3.1.3 Calls 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 calls 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 Call Dbus_proxy_new_sync to create a proxy object corresponding to the server-side skeleton object, as a parameter for subsequent Dbus method calls
How to use Dbus