D-bus basics
19
-
Upload
emre-can-kucukoglu -
Category
Software
-
view
428 -
download
0
Transcript of D-bus basics
What is d-bus?Desktop bus, IPC mechanism.Medium for local communication between processes
running on the same host.1:1 request-reply, 1:n publish-subscribe.Structured view of the data.
messages can be validated and ill-formed messages rejected.low-level C binding, also Java, Perl and Python.
2
BusesProcesses connect to the daemon
using the library.p2p communication library:
used by any two processes in order to exchange messages among themselves.
the daemon:any number of processes may be connected at
any given time.
Multiple buses may be active simultaneously.
system bus:system-wide communication.
session bus:single user's ongoing session.
● Addresses describes how to connect to bus such as "/tmp/.hiddensocket”. They completely hidden from the client process by the dbus library.
3
ConnectionsWhen a connection is set up, the bus immediately assigns it an immutable bus
name that it will retain for as long as the bus exists.
Services under well-known names that are agreed upon by convention, like org.freedesktop.DBus.
4
Object modelobjects,proxies,methods,signals,interfaces.
5
ObjectsCreated by a client process,Exists within the context of that client's connection to the bus.
Message types carried by the bus: Requests sent to objects by client processes. Replies to requests, going from an object back to a requesting process. One-way messages emanating from objects, broadcast to any connected clients
that have registered an interest in them.
6
ProxiesLocal representation of an object that is really accessed through the bus, and
typically lives outside your program.
GLib binding’s proxies support failover.
7
MethodsWhen a client sends a request to an object, it sees this request as invoking a
method on the object.Arguments can be passed and result back to the requester, along with either
result data or exception information.Messages are encapsulated by d-bus library.Both asynchronous & synchronous method invocation.
8
SignalsOne-way communications come from an object and go client processes.Client processes can register an interest in signals of a particular name
coming from a particular object.There are no replies to signals.No input and output parameters like methods do. Allow clients to restrict their interest to cases where certain of the signal's
parameters match given values.
9
InterfacesEvery object supports particular methods and may emit particular signals.These are specified in interfaces.
When a client invokes a method or listens for a signal, it must indicate the object and the member {methods, signals} it is referring to.
10
Addressing11
Overview picture12
furthermore; ActivationBus daemon can be instructed to start clients automatically when needed.To achieve that describe client in a service file. Default path: /usr/share/dbus-1/services/*.serviceFor example: client program /usr/local/bin/bankcounter can be run to provide
well-known bus names com.bigmoneybank.Deposits and com.bigmoneybank.Withdrawals.
# Sample bankcounter.service file[D-BUS Service]Names=com.bigmoneybank.Deposits; com.bigmoneybank.WithdrawalsExec=/usr/local/bin/bankcounter
13
PerformanceOne-to-one communication was about 2.5x slower than simply pushing the
data raw over a socket.Bus daemon should be about twice as slow as one-to-one mode, because a
round trip involves four socket reads/writes rather than two socket reads/writes.
Overhead comes from:Abstraction penalty (marshalling)Data validation (‘no validation’ mode exist, but not recommended)
Raw bandwidth isn't the only concern; D-Bus is designed to enable asynchronous communication and avoid round trips. This is frequently a more important performance issue than throughput.
14
Why D-Bus?difference from other IPC protocols:
d-bus is also lifecycle tracking, service activation, security policy, and other higher-level structure and assumptions.
not good for:internet applications,clustering, distributed swarms, peer-to-peer.
good for:desktop application talks to other parts of the desktop session,communications between system daemons and communications between
the desktop and system daemons.
15
Why D-Bus?Method call transition, signals, properties, oo, broadcasting,
discovery, introspection, policy, activation, synchronization, type-safe marshalling, security, monitoring, exposes APIs/not streams, passing of credentials, file descriptor passing, language agnostic, network transparency, no trust required, high-level error concepts.
retrieved from http://0pointer.de/public/lca.pdf
16
DrawbacksUsed for control, not payload.Inefficient (10 copies, 4 validations, 4 context switches per
duplex method call transaction)No implicit timestamping.Not available in boot time.Security framework hooks happen in userspace.
retrieved from http://0pointer.de/public/lca.pdf
17
alternative: kdbusEfficient (2 or fewer copies, 2 validations, 2 context switches per
duplex method call transaction).Implicit timestamping.Always available, from earliest boot to latest shutdown.Security framework hooks happen in kernel space.
retrieved from http://0pointer.de/public/lca.pdf
18
Referencesfreedesktop.org: intr. to dbus.freedesktop.org: dbus faq.maemo: dbus.qt 4.8: dbus documentation.wiki: dbus.linux.conf.au.: Lennart Poettering.
19
