Better intervals between feelers #19869
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
b5eac26 to
53026d5
Compare
We should distinguish the case when we selected a feeler and attempted connecting to it from the case when we didn't even try: maybe the record was invalid, or too many attempts were made. In the latter case, make next feeler attempt sooner.
Feeler intervals are already poisson-randomized, no need to add extra random noise.
53026d5 to
9feba97
Compare
|
🐙 This pull request conflicts with the target branch and needs rebase. Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft". |
|
Concept ACK improvements along these lines. However, I'm not sure about the more complicated interval logic around the feeler connections -- it seems to me like that logic is already a bit hard to follow, so I wonder if a better approach might be to just check for invalidity in the |
|
@sdaftuar I agree with the high-level idea. Even though I don't think I'm making it significantly harder to follow, simplifying is a good idea. But let me check, are you suggesting just to carefully use |
|
Closing this:
|
Draft pending on #19958(1) would make transitioning from "new" to "tried" better in the presence of those events. An adversary here fills our "new" table with garbage to prevent us from trying honest peers from "new". This probably won't help much against a very powerful adversary but will help against a moderate adversary. It also may help in natural non-malicious cases.
Moving from "new" to "tried" table is important for p2p security.