Arch Linux

n0stradamus

Member

Registered: 2010-11-08

Posts: 94

Website

D-Bus Communication done right?

Hi!

I need to do some IPC with D-Bus in my current project and as I am using Qt anyway, the QDBus module came in quite handy.
In the project, a Daemon has to send some information over to another process. Replies or checks aren't needed and so I got my communication setup pretty quickly.
Then, I stumbled over the Qt chat-example: http://doc.qt.nokia.com/4.7/dbus-dbus-chat.html
In it, they inherit from QDBusAbstractAdaptor and QDBusAbstractInterface. These classes are then used to establish a working D-Bus communication.

In my daemon I simply did this:

QDBusMessage msg = QDBusMessage::createSignal("/", "com.foo", "test");
msg << testString;
QDBusConnection::sessionBus().send(msg);

And in the receiving class constructor:

QDBusConnection::sessionBus().connect(QString(), QString(), "com.foo","test", this, SLOT(print(QString)));

This also works...can anyone explain to me why ?

PirateJonno

Forum Fellow

From: New Zealand

Registered: 2009-04-13

Posts: 372

Re: D-Bus Communication done right?

Because... uh, Qt does a nice job of wrapping the DBus library?

Basically how it works is the QDBusConnection::sessionBus() object represents the "session bus", which is an interface defined when you log in. The environment variable DBUS_SESSION_BUS_ADDRESS points to a unix socket which acts as a name server, in that your daemon can register itself under the name com.foo, and your client can then request access to the daemon via a socket or something (not sure exactly how it works). Then DBus will handle marshalling of parameters and what not, just like any IPC/RPC mechanism.

---

"You can watch for your administrator to install the latest kernel with watch uname -r" - From the watch man page

n0stradamus

Member

Registered: 2010-11-08

Posts: 94

Website

Re: D-Bus Communication done right?

Thanks!
I simply couldn't understand why the example uses such an elaborate method compared to mine.
But now that I look at it with your explanation in mind, it does make sense. The chat-example uses bi-directional communication and my project doesn't.
I could imagine that a double registration of the same interface from two different programs could lead to confusion, like the signal sent by one process is received by the process which is ought to receive AND the sender, because both have a slot connected to the signal.

Last edited by n0stradamus (2010-11-11 16:05:57)