Hi Michał,
On Mon, 2020-06-15 at 10:22 +0200, Michał Lowas-Rzechonek wrote:
> Hi Inga,
>
> On 06/10, Inga Stotland wrote:
> > Attach() method:
> > If Attach method is called for a node that is being processed as a result
> > of a Create, Import or Join method calls in progress, node attachment
> > is not allowed and org.bluez.mesh.Error.Busy error is returned.
>
> I don't think I understand how this is supposed to be used by the
> application.
>
> So far, we've implemented the API by calling Import() and then, as soon as
> JoinComplete() call arrives, calling Attach().
>
> > @@ -1654,6 +1665,12 @@ void node_attach(const char *app_root, const char *sender, uint64_t token,
> > return;
> > }
> >
> > + /* Check if there is a pending request associated with this node */
> > + if (node->busy) {
> > + cb(user_data, MESH_ERROR_BUSY, NULL);
> > + return;
> > + }
> > +
> > /* Check if the node is already in use */
> > if (node->owner) {
> > l_warn("The node is already in use");
>
> With this patch, this call sequence fails, because now we're supposed to
> send a *reply* to JoinComplete first, and only then call Attach()?
A couple months ago, we made the decision (with your input, I believe) that we needed to use JoinComplete on
every node creation (Join, Import, Create), to ensure that the App has the token, and all required
informationnthe daemon requires the App to have. If the daemon does *not* get the successful return from
JoinComplete, it destroys the entire node... So therefore the node isn't entirely complete until the daemon
receives the return.
This creates an awkward state for the node... Part of Attach() requires the daemon to make an ObjectManager
request of the app to get the latest composition settings, and validate the App which is attaching with that
token. It also creates the unfortunate situation revealed in one of your test-suite cases where if Leave() was
called before returning the JoinComplete() call, we Seg-Faulted.
Both Leave(), and the situation of the *first* Attach() following JoinComplete are "Once in a Node's Lifetime"
situations. We decided that the safest course of action here was to require the JoinComplete return prior
either Attach or Leave... Because the node needs finalizing.
>
> I'm using a high-level API for D-Bus, so I don't really control when the
> reply is sent, so at the moment the only way to implement this would be
> by delaying Attach() by a fixed timeout - and I'm not comfortable with
> that.
Yeah, I can see how this is now required...
In the mesh-cfgclient tool (which is also built on ELL) we accomplish this by scheduling an idle_oneshot for
the Attach.
It could also be done by issuing the l_dbus_send of the JoinComplete response within join_complete, before
calling the Attach send... Then returning NULL as the return result of join_complete (where the response would
normally be sent).
>
> regards
