Reduced number of addresses per NodeID in peermanager to 1#2990
Reduced number of addresses per NodeID in peermanager to 1#2990
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2990 +/- ##
===========================================
+ Coverage 58.23% 71.98% +13.74%
===========================================
Files 2113 22 -2091
Lines 173747 1942 -171805
===========================================
- Hits 101189 1398 -99791
+ Misses 63541 444 -63097
+ Partials 9017 100 -8917
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| if _, ok := peerAddrs.addrs[addr]; ok { | ||
| peerAddrs.fails[addr] = now | ||
| if peerAddr, ok := p.addrs[addr.NodeID]; ok && peerAddr.addr == addr { | ||
| peerAddr.lastFail = utils.Some(time.Now()) |
Check warning
Code scanning / CodeQL
Calling the system time Warning
| p.addrs[pa.addr.NodeID] = pa | ||
| return nil | ||
| } | ||
| // Otherwise, do not replace |
There was a problem hiding this comment.
Hmm, what if my legitimate peer is moving to a new data center and i do want to replace it? I need to shut down the old one and wait for the address to be valid?
There was a problem hiding this comment.
You can start a new node, then shut down the old node and wait for the network to prune the old address in favor of the new one. If you change the addresses regularly, you are most likely to use DNS anyway. There is little incentive to reuse node keys - persistent peers configuration requires people to configure the new address manually anyway.
| return nil | ||
| } | ||
| } | ||
| // If the new address is public, find a private address to prune. |
There was a problem hiding this comment.
could it be the private address is actually a high staked validator I don't want to lose?
There was a problem hiding this comment.
If there is ANY peer address that you don't want to lose for ANY reason, then you should put it in persistent peers list. And the peer should add you to the unconditional list, otherwise there is no guarantee that it will have capacity for you.
3 participants
With 6.3 upgrade, invalid/outdated addresses are no longer gossiped by honest nodes (malicious nodes can poison the addresses buffer anyway). With that we can simplify the logic to handle just 1 address per peer. I've also added an additional mechanism to prefer public ips over private ips, to account for nodes gossiping private addresses (that they have configured as persistent peers for example).