Can I know if a handle is still in the handle cache?

[michaelwgnr]

I'm trying to work out an addressing scheme on top of the mesh with node addresses and broadcast addresses. My first try, using the value handles as source address and having a destination address in the packet data, did not work well. The problem here was that some nodes will infinitely rebroadcast obsolete data (i.e. data with a "destination address" that has long since been written to from another node and is therefore obsolete) and another versioning scheme on top would be required. That seems a bit pointless to me, since the mesh already takes care of versioning.

Now I want to reverse the scheme: the value handle corresponds to a node or broadcast address and a source address would be within the packet data. Now if I want to send a message to a certain handle from a node on which this specific handle dropped out of the handle cache, the local framework does not know the currently valid version and thus I can try to send data and then notice that I get an update on this handle.

Is there a way to find out that handle dropped out of the cash beforehand? I noticed that when calling rbc_mesh_value_get, the error code NRF_ERROR_NOT_FOUND is returned if either the handle dropped out of the handle cache or out of the value cache. So checking this would work if both caches are the same size. What if my handle cache is larger?

It looks like I just have to call handle_entry_get and check the return value?

Thanks!

[trond-snekvik]

Wouldn't this second approach cause some trouble if you have two devices sending to one at the same time? The devices in between will only forward the first of two messages with the same handle+segnum, and the messages are going to reach different devices in different orders. It might be an acceptable consequence, though.

It looks like I just have to call handle_entry_get and check the return value?

There's not really any other ways without changing the framework right now. If you're going down that path, you might be better off terminating retransmissions after a certain number of transmits. This can be solved by counting TX events per packet, but I agree that it's sort of redundant. You could always add a counter variable to the data cache entries, that you increment on every call to handle_storage_transmitted(), and do trickle_disable() on the entry's trickle instance when it reaches a certain number.

[michaelwgnr]

Wouldn't this second approach cause some trouble if you have two devices sending to one at the same time?

Yes, that could be an issue but this could be mitigated with e.g. requiring an ACK (which would be prone to the same issue of course)

If you're going down that path, you might be better off terminating retransmissions after a certain number of transmits.

If I understand you correctly, you are suggesting that I keep following the original approach of treating handles handles equal to source addresses and I could add an upper limit to the number of retransmissions to not run into the problem of having obsolete data broadcast. That could be a possibility. I have to give it some thought, as I'm not too keen on using the "handle-as-destination" approach.

Thank you for your support, anyway!