Conflicts results in infinite flooding?

[victorpasse]

Hi, If two nodes increment the version and send new but inconsistent data my understanding is the floowing; mesh_app_packet_handle gets called upon reception vh_rx_register gets called delta==0 payload_has_conflict becomes true trickle_rx_inconsistent gets called and both nodes resend their version of the data Will this not result in both nodes sending the data continusly?

My own testing shows that the mesh becomes fully flooded when many nodes change their data at the same time.

[trond-snekvik]

You're correct, and this is an issue we're not quite comfortable with. The conflict event given to the application should optimally result in a decision to either replace or ignore the data on the conflicting handle, but it's not enforced in any way. This decision would have to be the same in every device, and the only data you have to make that decision is the payload of the conflicting data. Everything else may vary from device to device based on their position in the mesh.

If no unified decision is made, the framework will continue pushing conflicts at a high frequency, and as you've observed - it's not pretty. I think we could ease the pain somewhat by not treating the conflict as an inconsistency in the trickle algorithm, but it might have other implications on the propagation of said conflict.

The best solution is always to design the application so that conflicts don't occur, but it's not a solution from the framework's viewpoint.

[victorpasse]

In my case conflicts may occure, if the data is not consistent in all nodes a retry will be carried out a random time later so there is no problem with dropping conflicting packages.

Can I just comment out trickle_rx_inconsistent(&m_data_cache[data_index].trickle, ts_start_time + timestamp); and vh_order_update(timestamp); in vh_rx_register in if (delta == 0)

[trond-snekvik]

Yes, that should be safe :) You could also choose to replace it with the line trickle_rx_consistent(&m_data_cache[data_index].trickle, ts_start_time + timestamp);, from the non-conflict-handler, to reduce redundant traffic.

[trond-snekvik]

Fixed in 5282944, implemented solution from my last comment.