We are still seeing problems where if a MeshMS conversation already exists, sending a message may result in non-delivery, because the sender mistakenly doesn't realise that the recipient has only an older version.
We have implemented a partial work-around, where if we see a peer sending and old version of a bundle that we have a newer version, we [re-]queue the latest version for transmission to the recipient.
However, this only works if we see the peer actively sending the wrong version. We still need to get to the bottom of how the situation comes about in the first place. Does treesync work out the situation correctly? Does LBARD queue the bundle for TX? If so, does it get mistakenly de-queued due to the presence of the old version?
Part of the problem has been in reproducing the problem.
To help this, some instrumentation has been added to LBARD that optionally logs the queue and dequeue events.
We are still seeing problems where if a MeshMS conversation already exists, sending a message may result in non-delivery, because the sender mistakenly doesn't realise that the recipient has only an older version.
We have implemented a partial work-around, where if we see a peer sending and old version of a bundle that we have a newer version, we [re-]queue the latest version for transmission to the recipient.
However, this only works if we see the peer actively sending the wrong version. We still need to get to the bottom of how the situation comes about in the first place. Does treesync work out the situation correctly? Does LBARD queue the bundle for TX? If so, does it get mistakenly de-queued due to the presence of the old version?
Part of the problem has been in reproducing the problem. To help this, some instrumentation has been added to LBARD that optionally logs the queue and dequeue events.