11:06 p.m.
In Bluetooth Mesh, we have a particular interaction between the mesh daemon, and
Applications where we need to
ensure that the application has received a critical piece of data (the node token), and if
it doesn't, we need
to destroy the newly created node.
Specifically we have the JoinComplete() method, that the Application is required to
implement, and it is
invoked by the daemon with l_dbus_send_with_reply().
This *mostly* works, in that the daemon gets any responses that the App sends, and is
alerted if the App
crashes in such a way the it's dbus socket gets closed.
However: If the Application has a bug in that it *never* responds (for instance, it
returns NULL in the
JoinComplete() message handler, and never responds asyncronously either), then the mesh
daemon never receives a
call on it's callback function. I had always assumed that the dbus-daemon would
timeout on responses, but this
does not appear to be the case.
Is timing out reply required methods the dbus daemon responsibility? Is it the
l_dbus_send_with_reply()
responsibility? The mesh daemon responsibility? Ideally, the App just responds, but we
have no control over
how Apps respond to method calls.
4 p.m.
Hi Brian,
Is timing out reply required methods the dbus daemon responsibility?
Is it the l_dbus_send_with_reply()
responsibility? The mesh daemon responsibility? Ideally, the App just responds, but we
have no control over
how Apps respond to method calls.
Timeouts do not exist at the protocol level, their implementation is
purely a higher level feature.
dbus-daemon can be configured to limit the maximum time an application
can take to respond, but the default reply_timeout is set to -1 (infinite).
ell does not enable or enforce any timeouts for dbus method calls.
Starting a timer for each dbus call is quite expensive, so for now we
have left this up to the application to manage.
Regards,
-Denis
5:46 p.m.
Thanks Denis,
On Apr 11, 2020, at 9:00 AM, Denis Kenzior <denkenz(a)gmail.com>
wrote:
Hi Brian,
> Is timing out reply required methods the dbus daemon responsibility? Is it the
l_dbus_send_with_reply()
> responsibility? The mesh daemon responsibility? Ideally, the App just responds, but
we have no control over
> how Apps respond to method calls.
Timeouts do not exist at the protocol level, their implementation is purely a higher
level feature.
dbus-daemon can be configured to limit the maximum time an application can take to
respond, but the default reply_timeout is set to -1 (infinite).
ell does not enable or enforce any timeouts for dbus method calls. Starting a timer for
each dbus call is quite expensive, so for now we have left this up to the application to
manage.
I suspect this is what we need to do... we have perhaps just the one method that
absolutely requires this time-out, so I agree that pushing this into all “send-with-reply”
calls might be overkill.
It does, however, create the potential for at least a temporary resource leak. The hashmap
gets saved for as long as it takes... if we time out the on the responde, is there
anyway to tell ELL to cancel and cleanup the hashmap?
Regards,
-Denis
8:55 p.m.
Hi Brian,
It does, however, create the potential for at least a temporary
resource leak. The hashmap gets saved for as long as it takes... if we time out the on
the responde, is there anyway to tell ELL to cancel and cleanup the hashmap?
That is what the destroy callback of l_dbus_send_with_reply is for. The
destroy callback gets called on userdata in all cases to free up any
resources.
In the normal case it is called after the callback is invoked, but can
also be called as a result of l_dbus_cancel, etc.
Regards,
-Denis
2:16 a.m.
On Thu, 2020-04-09 at 02:52 -0500, Denis Kenzior wrote:
Hi Brian,
> It does, however, create the potential for at least a temporary resource leak. The
hashmap gets saved for
> as long as it takes... if we time out the on the responde, is there anyway to tell
ELL to cancel and
> cleanup the hashmap?
That is what the destroy callback of l_dbus_send_with_reply is for. The
destroy callback gets called on userdata in all cases to free up any
resources.
In the normal case it is called after the callback is invoked, but can
also be called as a result of l_dbus_cancel, etc.
Ah... That is the API I need. l_dbus_send_with_reply() returns a serial number, and
l_dbus_cancel() accepts a
serial number to cancel. So we can add our own timeouts, and call the dbus_cancel with
the saved serial number
if we don't get the timeout we are waiting for.
Thanks.
Regards,
-Denis
858
days inactive
860
days old
4 comments
2 participants
participants (2)
-
Denis Kenzior -
Gix, Brian