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
Currently we keep all fallback peers which are feasible, and also infeasibles as well (if they have been retracted recently). Certain network topologies can however cause this to become a rather large list. It might be useful to limit the amount of (fallback) routes for a subnet to some number, e.g. 5 should be more than enough (10 if we are really conservative), and kick out the furthest (distance wise) peers. This does mean we need to take care to handle new peers, since those could potentially become the best in the future but start out as the worst and get kicked out. Some grace period should be taken into account for how long we know the given route, to consider if we want to remove it.
The text was updated successfully, but these errors were encountered:
Currently we keep all fallback peers which are feasible, and also infeasibles as well (if they have been retracted recently). Certain network topologies can however cause this to become a rather large list. It might be useful to limit the amount of (fallback) routes for a subnet to some number, e.g. 5 should be more than enough (10 if we are really conservative), and kick out the furthest (distance wise) peers. This does mean we need to take care to handle new peers, since those could potentially become the best in the future but start out as the worst and get kicked out. Some grace period should be taken into account for how long we know the given route, to consider if we want to remove it.
The text was updated successfully, but these errors were encountered: