You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After some tests in #261, it was decided to still replace nodes on first failure.
One scenario where this is troublesome is in case the own network connection drops, the routing table will get cleared.
Other is possibly when the own network connection is just very slow and/or flakey.
And as last, perhaps for usage with much less lookups, one might want a better control of the "stale" nodes.
One simple way to handle this is to flag a node on first failure not to be used for lookups/revalidation any more. And to do in the background (e.g. by some callback after first failure) some exponential back off pinging or just random pinging. (e.g. 5 times).
Should be tested properly though with looking at metrics, e.g. in bad network conditions.
The text was updated successfully, but these errors were encountered:
After some tests in #261, it was decided to still replace nodes on first failure.
One scenario where this is troublesome is in case the own network connection drops, the routing table will get cleared.
Other is possibly when the own network connection is just very slow and/or flakey.
And as last, perhaps for usage with much less lookups, one might want a better control of the "stale" nodes.
One simple way to handle this is to flag a node on first failure not to be used for lookups/revalidation any more. And to do in the background (e.g. by some callback after first failure) some exponential back off pinging or just random pinging. (e.g. 5 times).
Should be tested properly though with looking at metrics, e.g. in bad network conditions.
The text was updated successfully, but these errors were encountered: