What would be the smart way to stop propagating a particular instance of trickle?

[bayou9]

Hello, I'm wondering are there ready-made APIs that allow me to simply purge a trickle instance out of the pool? By that I mean render the relevant handle cache invalid, and free the corresponding data cache entry.

I understand It's relatively difficult as that's not exactly FIFO caches work, but please be assured that I'm not at all concenred about saving precious memory spaces, I'm more concenred about stop sending certain packets completely.

I have thought of a couple of ways to do it:

1. I do not have to do it, the propagating of certain trickle instance will die out eventually, given enough time.

2. Modify the code, so that a node, before sending a packet, will look into the packet and for a flag. Once it reads the flag, it knows that it should not re-send this packet, and this packet will be discarded, thus suppressing the transmission.

3. Write a function that looks up the PERVIOUS handle of the current handle, and point it to the NEXT handle, and subsequently ignores the current handle as well as its corresponding data entry completely useless. This could be an overly simplified solution and it may be risky as it might have overlooked certain things.

Any way, above are just my ideas. Does the code come with an API that can eliminate an entry? I haven't found any, to be honest.

[twvd]

Instead of removing unnecessary handles, you could consider making the important ones persistent instead?

[bayou9]

@twvd Hello, thank you for your tip, are you saying that non-persistent ones will gradually be "phased out" over time, and "persistent" ones will stay inside the pool repeating itself over the network indefinitely?

[trond-snekvik]

There's no function that purges an entry, no. It was suggested some months ago too, in #103, but nothing came of it. We were a bit reluctant to doing this, as it would likely cause unwanted behavior when the devices fail to sync their handle deletion, and the same handle keeps popping up from neighbors over and over. Instead, we have the rbc_mesh_value_disable() function, that has a similar effect. It will prevent the device from rebroadcasting the current version of the handle, but it has to be called every time a new version of that handle pops up. If you do this in the application event handler, you should never see this handle being retransmitted by that device. Would this function fit your use-case?

[michaelwgnr]

@trond-snekvik I actually only read in your comment how rbc_mesh_value_disable() only stops rebroadcasting the current version of the handle. It would probably be helpful, if the documentation of the function would clearly state this.

Currently it says:

Values will not be propagated to other nodes through this node before they are either written to or re-enabled.

To me, "written to" sounds like it has to be written to from the local node!

[trond-snekvik]

Good point. I'll change it :)