Dbus结构和方法调用C语言

I am starting to create a dbus application in C to interface with bluez. I am new to dbus and I am a little confused as how to correctly structure my application with dbus.

我开始在C中创建一个dbus应用程序来与bluez连接。我是dbus的新手,我对如何使用dbus正确构建应用程序感到困惑。

The first question is related to the Service, Interface, and Object path in dbus. Bluez Adapter API has the org.bluez service, a org.bluez.Adapter1 interface, and a number of methods and properties. If I wanted to call the void StopDiscovery() method, would the following be the correct call?

第一个问题与dbus中的服务,接口和对象路径有关。 Bluez Adapter API具有org.bluez服务,org.bluez.Adapter1接口以及许多方法和属性。如果我想调用void StopDiscovery()方法,以下是正确的调用吗?

DBusPendingCall * pending;
// create a new method call and check for errors
msg = dbus_message_new_method_call("org.bluez",
    "/", // object to call on
    "org.bluez.Adapter1", // interface to call on
    "StopDiscovery"); // method name
// send message and get a handle for a reply
if (!dbus_connection_send_with_reply (m_dbus_conn, msg, &pending, -1))
{
     //err
}

If this is the case, when does the object path come into play?

如果是这种情况,对象路径什么时候起作用?

The follow on to this is how to go about receiving information back from dbus. I've seen a few examples with a DBusPendingCall * however the function has dbus_pending_call_block() so the function blocks until the data is returned. If I wanted to do multiple calls and not block I would need to make a list of DBPendingCall pointers and check each one? Are there any callbacks?

接下来是如何从dbus接收信息。我已经看到了一些带有DBusPendingCall *的示例,但是该函数有dbus_pending_call_block(),因此函数会阻塞,直到返回数据。如果我想进行多次调用而不是阻塞,我需要列出DBPendingCall指针并检查每一个?有没有回调?

Thanks

2 个解决方案

#1

I did create an example showing the non-blocking call based on the dbus watch and timeout mechanism, in response to the SO question dbus watch and timeout examples. Basically you run a unix select() loop and everything is dispatched around it.

我确实创建了一个示例,显示基于dbus监视和超时机制的非阻塞调用,以响应SO问题dbus监视和超时示例。基本上你运行一个unix select()循环,然后围绕它调度一切。

And I did not touch the multiple outstanding pending-call part. I assume one way is to check each pending-call to see whether it is completed when the watched event is received. Checking pending complete is non-blocking. If you keep a small number of outstanding pending calls it should be ok, though that is not an efficient solution if the number becomes big.

而且我没有触及多个未完成的待处理部分。我假设有一种方法是检查每个待处理呼叫,以查看是否在收到监视事件时完成。检查挂起的完成是非阻塞的。如果您保留少量未完成的待处理呼叫,则应该没问题,但如果数量变大则不是有效的解决方案。

It looks like according to the API document, a better solution is to use dbus_pending_call_set_notify() to register a callback to a pending call.

看起来根据API文档,更好的解决方案是使用dbus_pending_call_set_notify()来注册对待处理调用的回调。

#2

So it appears that both the object path and the interface are required when talking to bluez over dbus.

因此,当通过dbus与bluez交谈时,似乎需要对象路径和接口。

// create a new method call for the adapter
msg = dbus_message_new_method_call("org.bluez",
"/org/bluez/hci0", // object to call on
"org.bluez.Adapter1", // interface to call on
"StopDiscovery"); // method name


// create a new method call for a characteristic on
// a given service 
msg = dbus_message_new_method_call("org.bluez",
"/org/bluez/hci0/dev_12_34_56_78_9A_BC/service0010/char0011",
"org.bluez.GattCharacteristic1",
"StartNotify");

The select on Unix sockets for pending looks like a solid, scaleable way to go, I will consider this architecture as the application grows

用于挂起的Unix套接字选择看起来像一个可靠的,可扩展的方式,我会在应用程序增长时考虑这个架构

#1