handleInitTopicLookup may have outdated information

[harnen]

We do not rebuild a search table if there's already one existing. Shouldn't we always do it, in case the routing information changes (turbulance, new peers etc.)? @srene

https://github.com/harnen/p2p-service-discovery/blob/master/service-discovery/src/main/java/peersim/kademlia/Discv5TicketProtocol.java#L467

[srene]

I’m not sure i understand. There is a searchtable per topic for each node. why would you want to create more? new peers does not affect because the searchtable is created per node so a new node will create its own searchtable. On 27 Nov 2020, at 11:03, Michał Król <notifications@github.com<mailto:notifications@github.com>> wrote: We do not rebuild a search table if there's already one existing. Shouldn't we always do it, in case the routing information changes (turbulance, new peers etc.)? @srene<https://github.com/srene> https://github.com/harnen/p2p-service-discovery/blob/master/service-discovery/src/main/java/peersim/kademlia/Discv5TicketProtocol.java#L467 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#16>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABNSP4RCQWXQZWMNIENGZEDSR52NLANCNFSM4UEWP3GQ>.

[harnen]

The search table is built based on the routing table of the respective. It's possible, that the routing table will be updated between consecutive lookups (i.e., with new peers), but the search table will stay the same.

[srene]

I agree on that. Its only initialised from routign table but needs to be updated. I think every time local routing table is updated (when receiving response messages), search table is also updated, but need to check if its updated with src id for any message. The current refresh (which can be disabled) sends findnode msg for buckets that are empty, but i think there is a lot of room for improvement in this aspect. On 27 Nov 2020, at 11:09, Michał Król <notifications@github.com<mailto:notifications@github.com>> wrote: The search table is built based on the routing table of the respective. It's possible, that the routing table will be updated between consecutive lookups (i.e., with new peers), but the search table will stay the same. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#16 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABNSP4QQLLGZCSTQ4BBUYD3SR53EZANCNFSM4UEWP3GQ>.

[harnen]

It might be easier to just remove the if statement, and rebuild it every single time we call handleInitLookup/Regiser. I can to this it that's ok with you. Will be simpler code-wise.

[srene]

ok On 27 Nov 2020, at 11:20, Michał Król <notifications@github.com<mailto:notifications@github.com>> wrote: It might be easier to just remove the if statement, and rebuild it every single time we call handleInitLookup/Regiser. I can to this it that's ok with you. Will be simpler code-wise. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#16 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABNSP4SLHUCLJFB3KRHGV3TSR54QVANCNFSM4UEWP3GQ>.