Why aren't multiple simultaneous reliable publish messages for the same model handle allowed?

[Mathias]

Hi,

I'm using Mesh SDK v3.2 and I've created my own custom client & server model. My client model can call several types of monitoring GET messages to the server model, which answers with corresponding STATUS messages. I'd like to call several of these GET messages simultaneously within the publish timer timeout of the client model. However, it seems that I can't call access_model_reliable_publish multiple times simultaneously for the same model_handle? Why is that? Is this something that is going to be allowed in future versions? Or am I missing something from standardization? Because it does seems that I can enlarge the context space for more reliable structures but that the code still limits to only 1 reliable structure per model_handle being "busy" at the same time (looking at available_context_get in access_reliable.c).

Kind regards,

Mathias

[tesc]

Hi,

You are correct that our Bluetooth mesh stack only allows one ongoing acknowledged message at a time. If the message is not acknowledged it will time out after MODEL_ACKNOWLEDGED_TRANSACTION_TIMEOUT, at which point you can send a new message. From what I understand this is in accordance with the specification, but I have asked our mesh team for clarification.

Regards,
Terje

[Mathias]

Ok, I will await the clarification from the mesh team then. Because it would be an interesting feature to be able to have multiple simultaneous reliable structures ongoing for one model handle.

[tesc]

Hi,

First of all, sorry for the delay. (It was my fault, I missed the notification from our issue tracker.)

Response from our developers:

The access layer as such does not have any restriction as per specification. However, as the access layer is tied closely with the model layer it does not have a queuing mechanism for queuing up multiple model messages. Since there is close tie-up between the access layer and models, implementing queuing does not make sense. Send one message -> wait for the response -> send next message. In request-response based message exchanges queuing at the access layer will not help at all

They also suggest that models be small self-contained entities that do only one thing at a time. Typically if you need queues at the model/access layer, it could be better to split it up into different models instead of having one model that requires access layer queuing mechanisms.

Would it make sense, for your use case, to split the models? E.g. in our light switch examples, we use one model for each light switch. While in that example the models are identical (all on/off models), the same pattern may be used for when the status data differs.

Alternatively, does it make sense, if in any case you ask for the different data at the same time, to merge this into one GET, with a response containing all the status data?

Regards,
Terje

[Mathias]

Hi Terje,

No problem, thanks for getting back to me on this issue!

I understand why it would indeed just be shifting the issue from keeping track on the application layer to keeping track on the access layer. But looking at existing SIG models as well, this sentence in your answer seems a bit strange: "They also suggest that models be small self-contained entities that do only one thing at a time.". Doesn't the Configuration Client / Server model offer a lot of functionality in one model? Or could I see that as the exception to the rule? Anyway, I see that the "node_setup.c" file of the Light Switch example also keeps track of the state of configuration and sends one message at a time. So it indeed already shows one way of coping with this issue.

Maybe I could split up the models but generally, what the model offers, is a monitoring context between a Client and several Servers in the network. The model can be used to ask for either Network parameters, Application parameters or Neighbor Discovery parameters (the discovery itself is done using another custom model's Client/Server interaction, so that's separate). So I have GET and STATUS messages defined for each of these parameters and want to be able to ask for them separately whenever it is required (which is a lot more for Neighbor Discovery opposed to the other parameters). This could be split up in several models, but I am more fan of the second option you offer.

That's actually what we did now.

Since we last spoke, I created another GET/STATUS message to get the Composition parameters, which is all the parameters combined. This solves the issue of having to track the state of the separate GET's per type of parameter and ask them one by one (instead of being able ask them all at once using multiple reliable context's for the same model), but at the same time also offer the ability to ask for separate parameters if needed. So the issue is solved in another way, as you also suggested as well.

Thanks!

Mathias