D-bus Learning (3): messages

From: http://blog.csdn.net/flowingflying/article/details/5412711

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 .

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

1. method call message: a method of the trigger object
2. Method return message: result returned by the triggered Method
3. error message: An exception is returned for the trigger method.
4. Signal messages: notifications, which can be viewed as event messages.

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

Sending method call messages

A method call message is sent from process a to process B, and B will respond to a method return message or error message. Each call message carries a serial number, and the response message also contains the same number, so that it can be matched. Their processing process is as follows:

• If a proxy is provided, the method of triggering a local object triggers the remote object of another process. The application calls a proxy method. The proxy constructs a method call message and sends it to the remote process.
• For the underlying API, the proxy is not used, and the application needs to construct the method call message by itself.
• A method call message contains the bus name, method name, method parameter, object path, and optional Interface Name of the remote process.
• Method call message sent to bus daemon
• Bus daemon: view the bus name of the destination. If a process corresponds to this name, bus daemon sends the method call message to the process. If no matching is found, the bus daemon creates an error message and returns it as a response.
• After receiving the message, the process splits the method call message. For simple underlying APIs, the method is executed immediately and a method reply message is sent to the bus daemon. For high-level APIs, the system checks the object path, interface, and method, triggers a native object method, and encapsulates the returned value in a method reply message.
• Bus daemon receives the method reply message and forwards it to the original process.
• Process to view the method reply message and obtain the returned value. This response can also identify the residue of an error. When advanced bundling is used, the method reply message is converted to the return value of the proxy method or an exception.

Bus daemon ensures the order of messages without disorder. For example, if we send two method call messages to the same receiver, they will be accepted in order. The recipient does not need to reply in order. The message has a serial number that matches to send and receive messages.

Scenarios for sending signal

Signal is a broadcast message that does not need to respond. The receiving direction is daemon to register matching conditions, including the sender and the signal name. The bus daemon only sends the signal to the desired process. The process is as follows:

• A signal message is sent to the bus daemon.
• A signal message contains the Interface Name, signal name, process bus name, and parameters that publish the signal.
• Match rules, a condition that can be registered by any process, indicates the signal it is interested in. The bus has a registration match Rules list.
• Bus daemon checks which processes are interested in the signal and sends the signal message to these processes.
• Processes that receive signals determine how to handle them. If a high-level binding is used, a porxy object will have a very native signal. If the underlying API is used, the process needs to check the sending and receiving signals and determine the names of the signals to be processed.

Introspection

The D-bus object may support an org. freedesktop. Train. introspectable interface. This interface has a method, introspect, which returns an XML string without parameters. This XML string describes the interface, method, and signal.

D-bus provides two Commands: producer-monitor. You can view the bus and producer-send commands, send messages, and use man to check the messages:

Accept-send [-- System | -- session] -- type = method_call(Or signal. The default value is signal)-- Print-reply -- dest = connection name Object Path interface name. method name parameter type: parameter value parameter type: Parameter Value

We use this interface. method to better understand d-bus. We use the listnames method to view the information:

[Wei @ Wei-desktop ~] $ Export-send -- print-reply -- type = method_call -- dest = org. freedesktop. Examples/org. freedesktop. Examples. listnames
Method return sender = org. freedesktop. Keys-> DEST =: 1.75 reply_serial = 2
Array [
String "org. freedesktop. Large"
String ": 1.7"
String"Org. freedesktop. Specifications"
String "org. freedesktop. Telepathy. Client. empathymorethanmeetstheeye"
......
String ": 1.6"
String ": 1.19"
]

For example, there is a name such as org. freedesktop. configurications. 

[Wei @ Wei-desktop ~] $ Export-send -- print-reply -- type = method_call -- dest = org. freedesktop. specifications/org. freedesktop. Specification. introspectable. introspect
Method return sender =: 1.19-> DEST =: 1.79 reply_serial = 2
String "<! Doctype node public "-// freedesktop // DTD D-BUS object introspection 1.0 // en"
Http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd>
<Node>
<Node name = "org"/>
</Node>
"

 

For example, the node name indicates the path, starting from/org.

 

[Wei @ Wei-desktop ~] $ Export-send -- print-reply -- type = method_call -- dest = org. freedesktop. events/org. freedesktop. invalid. introspectable. introspect
method return sender =: 1.19-> dest=: 1.80 reply_serial = 2
string " "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">



"

Node name, indicating the path, starting from/org/freedesktop 
[Wei @ Wei-desktop ~] $ Export-send -- print-reply -- type = method_call -- dest = org. freedesktop. specifications/org/freedesktop org. freedesktop. Specification. introspectable. introspect
Method return sender =: 1.19-> DEST =: 1.81 reply_serial = 2
String "<! Doctype node public "-// freedesktop // DTD D-BUS object introspection 1.0 // en"
Http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd>
<Node>
<Node name = "notifications"/>
</Node>

"

Node name, indicating that the path starts with/org/freedesktop/configurations. You can obtain the method and singnal of this interface. 
[Wei @ Wei-desktop ~] $ Export-send -- print-reply -- type = method_call -- dest = org. freedesktop. specifications/org/freedesktop/configurications org. freedesktop. Specification. introspectable. introspect
Method return sender =: 1.19-> DEST =: 1.82 reply_serial = 2
String "<! Doctype node public "-// freedesktop // DTD D-BUS object introspection 1.0 // en"
Http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd>
<Node>
<Interface name = "org. freedesktop. Rule. introspectable">
<Method name = "introspect">
<Arg name = "data" direction = "out" type = "S"/>
</Method>
</Interface>
<Interface name = "org. freedesktop. Examples. properties">
<Method name = "get">
<Arg name = "interface" direction = "in" type = "S"/>
<Arg name = "propname" direction = "in" type = "S"/>
<Arg name = "value" direction = "out" type = "v"/>
</Method>
<Method name = "set">
<Arg name = "interface" direction = "in" type = "S"/>
<Arg name = "propname" direction = "in" type = "S"/>
<Arg name = "value" direction = "in" type = "v"/>
</Method>
<Method name = "getall">
<Arg name = "interface" direction = "in" type = "S"/>
<Arg name = "props" direction = "out" type = "A {SV}"/>
</Method>
</Interface>
<Interface name = "org. freedesktop. configurications">
<Method name = "getserverinformation">
<Arg name = "name" type = "S" direction = "out"/>
<Arg name = "vendor" type = "S" ction = "out"/>
<Arg name = "version" type = "S" direction = "out"/>
</Method>
<Method name = "getcapabilities">
<Arg name = "Caps" type = "as" direction = "out"/>
</Method>
<Method name = "closenotification">
<Arg name = "ID" type = "U" direction = "in"/>
</Method>
<Method name = "policy">
<Arg name = "app_name" type = "S" direction = "in"/>
<Arg name = "ID" type = "U" direction = "in"/>
<Arg name = "icon" type = "S" direction = "in"/>
<Arg name = "summary" type = "S" direction = "in"/>
<Arg name = "body" type = "S" direction = "in"/>
<Arg name = "actions" type = "as" direction = "in"/>
<Arg name = "hints" type = "A {SV}" direction = "in"/>
<Arg name = "timeout" type = "I" direction = "in"/>
<Arg name = "return_id" type = "U" ction = "out"/>
</Method>
<Signal name = "icationicationclosed">
<Arg type = "U"/>
<Arg type = "U"/>
</Signal>
</Interface>
</Node>
"