Multiple connections to dbus-daemon in single appication
Simon McVittie
smcv at collabora.com
Mon Sep 17 11:45:10 UTC 2018
On Mon, 17 Sep 2018 at 11:30:52 +0900, dtdang wrote:
> Is it possible to create multiple connections by using "dbus_bus_get" &
> "dbus_bus_request_name" inside a single server to listen from multiple client ?
You seem to be mixing up connections with well-known bus names.
As Lawrence D'Oliveiro said in a previous reply, you can register
multiple well-known bus names on the same connection by calling
dbus_bus_request_name() several times on the same DBusConnection. If you
want multiple well-known bus names, 95% of the time this is the right
thing to do.
You can also open multiple connections, each of which can own any number
of well-known names, by calling dbus_bus_get_private() several times to
get several distinct DBusConnection objects. This is usually the wrong
thing to do, but is an option if you have specialized requirements.
If you do this, beware that there are no ordering guarantees between
different DBusConnection objects: if two messages A and B are sent,
then one DBusConnection might see both A and B before a second
DBusConnection has seen A.
Consider using a more user-friendly (and thread-safe) D-Bus implementation
such as GLib's GDBus. The reference implementation, libdbus, has this
statement on the first page of its documentation:
This manual documents the *low-level* D-Bus C API. **If you use
this low-level API directly, you're signing up for some pain.**
In GDBus, the equivalent of dbus_bus_get() is g_bus_get()
or g_bus_get_sync(), the equivalent of DBusConnection is
GDBusConnection, the equivalent of dbus_bus_request_name() is
g_bus_own_name_on_connection(), and the closest equivalent for
g_bus_get_private() is g_dbus_connection_new_for_address[_sync]()
with the G_DBUS_CONNECTION_FLAGS_AUTHENTICATION_CLIENT and
G_DBUS_CONNECTION_FLAGS_MESSAGE_BUS_CONNECTION flags. Similar comments
apply about the ability to own more than one well-known name per
GDBusConnection.
> com.app.bluetooth
> com.ap.wifi
> com.ap.ap
I suspect you don't own app.com (owned by Gannett Media Technologies
International, according to whois) and ap.com (owned by Audio Precision,
according to web page content). Please choose a namespace starting with
a reversed domain name that your organisation controls.
smcv
More information about the dbus
mailing list