Hi Andreas,
On Friday 26 February 2016 14:19:50 Andreas Pape wrote:
Consider the following situation which has been found in a test setup: Gateway B has claimed client C and gateway A has the same backbone network as B. C sends a broad- or multicast to B and directly after this packet decides to send another packet to A due to a better TQ value. B will forward the broad-/multicast into the backbone as it is the responsible gw and after that A will claim C as it has been chosen by C as the new gateway. If it now happens that A claims C before it has received the broad-/multicast forwarded by B (due to backbone topology or due to some delay in B when forwarding the packet) we get a critical situation: in the current code A will immediately unclaim C when receiving the multicast due to the roaming client scenario although the position of C has not changed in the mesh. If this happens the multi-/broadcast forwarded by B will be sent back into the mesh by A and we have looping packets until one of the gateways claims C again. In order to prevent this, unclaiming of a client due to the roaming client scenario is only done after a certain time is expired after the last claim of the client. 100 ms are used here, which should be slow enough for big backbones and slow gateways but fast enough not to break the roaming client use case.
That's an interesting solution. My original idea was to make clients "race" for clients, which wasn't ever implemented because in the scenarios I tested this was not a problem (Check batadv_bla_rx(), there is a note on a possible optimization).
I believe your solutions looks valid, let's implement that.
Acked-by: Simon Wunderlich sw@simonwunderlich.de
Thanks, Simon