Versions Compared

Old Version 2

changes.mady.by.user Z-Reshmi K R

Saved on

compared with

New Version 3

changes.mady.by.user Z-Reshmi K R

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

D-Bus Bindings must be auto generated using a D-Bus binding tool such as dbus-binding-tool from D-Bus-Glib, using the introspection XML file that defines the component’s interface and supported signals. The Adapter bindings should only be thin glue for bridging Component interfaces. In other words, there should not be any component functionality directly implemented in the bindings, other than just calling into the component’s interface.

<D-Bus Arc diagram>

D-Bus Remote Communication Capabilities 

Applications using D-Bus are either servers or clients. A server listens for incoming connections; a client connects to a server. Once the connection is established, it is a symmetric flow of messages; the client-server distinction only matters when setting up the connection. When using the bus daemon, the bus daemon listens for connections and component initiates a connection to the bus daemon.

A D-Bus address specifies where a server will listen, and where a client will connect. For example, the address

unix:path=/tmp/abcdef

specifies that the server will listen on a Unix domain socket at the path /tmp/abcdef and the client will connect to that socket. An address can also specify TCP/IP sockets. For example the address

tcp:host=10.1.2.4,port=5000,family=ipv4

specifies that server at 10.1.2.4 will listen on tcp port 5000 and the client will connect to that socket. From D-Bus specification at https://dbus.freedesktop.org/doc/dbus-specification.html#transports-tcp-sockets

TCP Sockets

The TCP transport provides TCP/IP based connections between clients located on the same or different hosts. Using TCP transport without any additional secure authentication mechanisms over a network is unsecure.

Server Address Format

TCP/IP socket addresses are identified by the “tcp:” prefix and support the following key/value pairs:

Name

Values

Description

host

(string)

dns name or ip address


port


(number)

The tcp port the server will open.

A zero value let the server choose a free port provided from the underlying operating system.

libdbus is able to retrieve the real used port from the server.

family

(string)

If set, provide the type of socket family either "ipv4" or "ipv6". If unset, the family is unspecified.

Unix Domain Name sockets are used for local intra processor IPC where as TCP/IP sockets are used for remote inter processor communication.

The D-Bus daemon has a configuration file that specializes it for a particular application. One of configuration parameter of interest is the listen element. From the man page of D-Bus daemon https://dbus.freedesktop.org/doc/dbus-daemon.1.html, the following configuration elements are defined.

<!ELEMENT busconfig (user |

type |
fork | 
keep_umask | 
listen  | 
pidfile | 
includedir | 
servicedir |
servicehelper | 
auth |
include | 
policy | 
limit | selinux)*>

The listen element defines address that the bus should listen on. The address is in the standard D-Bus format that contains a transport name plus possible parameters/options.

Example:  <listen>unix:path=/tmp/foo</listen> 
Example: <listen>tcp:host=localhost,port=1234</listen>

If there are multiple <listen> elements, then the bus listens on multiple addresses. The bus will pass its address to started services or other interested parties with the last address given in <listen> first. That is, apps will try to connect to the last <listen> address first.

tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames. If a hostname resolves to multiple addresses, the server will bind to all of them. The family=ipv4 or family=ipv6 options an be used to force it to bind to a subset of addresses
Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen>


R-Bus

RBus is a 3 layered RPC communication bus.

...