Repeated tid in received message does not throw out message but causes repeated app layer call

[Billy-IV]

I am working on developing an application where the app layer tries to throw out messages if the message parameters are not valid.  One the parameters to validate is a TID which uses the TID validation from the model_common.c . I found a weird interaction. If a message is a retransmission with the same TID from the same source node instead of throwing the message out as a repeated transaction, the message is sent to the model layer multiple times until after the TID_VALIDATION_INTERVAL_US has expired.  Then it treats it as a new transmission.  The log below is from a test with the generic on_off example from the mesh 3.2 sdk.  The only modification I made was to model_common.c to add the LOG statements in lines 142 and 147.

What is causing this repeated calls of the model layer? How do I prevent this from happening?  Is there a function to abort the process or is it a setting somewhere?

[Heidi-Irene Harvey Sollie]

Hi! The developer has the following reply to your previous comment.

I think you are mixing up multiple things here. Let me describe the cause and effect relationship of the message originator and message receiver as follows:
1. As you mentioned earlier, message originator sends 2 messages 0.5 seconds apart, but you see 4 calls to the handle_set() function.
2. This might be happening because either you are sending unacknowledged messages with the repeat count of "2" or model publication is configured with a retransmit count of "1".
3. The access layer of the receiver does not really repeat anything on its own. If you see more than expected calls to the handle_set() function, it means, the receiving access layer indeed has received the message multiple times (see point 2 above).
4. The access layer is unaware of the contents of the message. It does not understand if certain field values are prohibited or if the received message has not been formatted properly. As long as message can be resolved to certain model instance based on the opcode and subscriptions, that particular model callback will be automatically called.
5. When you see that the access layer has stopped calling the handle_set(), it means, message originator has stopped repeating the message.

About TID tracker:
The Mesh specification does not explicitly specify how the TID tracker should be implemented. We have implemented the TID tracker on per model basis. Meaning given model instance as a whole will share the same TID space. Also, unacknowledged and acknowledged variants of the messages are treated as the same kind of messages since they evoke the same user application action (changing some state value). Therefore, for any incoming messages to be qualified as a new message, it should be received with a new TID than the previous one irrespective of the broad type of the message (Set/Delta Set/Move Set).

In your vendor models, you can choose to do this differently if you wish so.

[Billy-IV]

Heidi,

Thank you for your patience.  That answer makes far more sense than the access layer repeating messages.  Could you guide me to the code that drives the client side repetition of the message.  I still find it odd that the generic_on_off example as written has a repeat message send on the client side that out lasts the TID timeout value defined in the TID tracker.  I would like to adjust the sending values.

Thank You,

Billy Ivy

[Heidi-Irene Harvey Sollie]

Hi!

Client models have two kinds of APIs for sending the messages:

1. API for acknowledged sending: It means, after calling the API a message is sent and a response message is expected. If the response is not received, stack will try to re-send the original message on its own.
For example: `generic_onoff_client_get()` or `generic_onoff_client_set()`, here the response message is STATUS (acknowledgement) message.

For these APIs, `access_reliable()` module handles the retransmission if a response is not received.

2. API for un-acknowledged sending: It means, after calling the API a message is sent. There is no response expected. Such APIs have an extra parameter (`repeats`) to specify the number of repetitions for the message. Such API can be used for sending a message to a Group address.
For example: `generic_onoff_client_set_unack()`.

For both of these APIs model publication settings are used. That means, if any publish retransmissions are specified, they will be applied on top of the retransmissions done by the higher layers. This is handled by the `access_publish_retransmissions.c` module. If there is no time left to finish the specified publish retransmissions before the next message is queued by the `access_model_reliable_publish()` API, remaining retransmissions will be abandoned by the `access_publish_retransmissions.c` module.

These publication settings for client models can only be configured via Configuration Client using Model Publication Set message.