Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| for id := range s.last { | ||
| if _,ok := GetAny(conns,id); !ok { | ||
| delete(s.last, id) | ||
| update = PeerUpdate{ | ||
| NodeID: id, | ||
| Status: PeerStatusDown, | ||
| } | ||
| return true | ||
| } | ||
| } |
Check warning
Code scanning / CodeQL
Iteration over map Warning
| for _, e := range t.bySender { | ||
| if !yield(e) { | ||
| return | ||
| } | ||
| } |
Check warning
Code scanning / CodeQL
Iteration over map Warning
| for old, priority := range p.out { | ||
| if id, ok := low.Get(); !ok || priority < id.priority { | ||
| low = utils.Some(pNodeID{priority, old}) | ||
| } | ||
| } |
Check warning
Code scanning / CodeQL
Iteration over map Warning
| regular: newPoolManager(&poolConfig{ | ||
| MaxIn: options.maxInbound(), | ||
| MaxOut: options.maxOutbound(), | ||
| FixedAddrs: bootstrapAddrs, |
There was a problem hiding this comment.
Is it possible someone set all bootstrap addresses in persistent so FixedAddrs is now empty?
There was a problem hiding this comment.
Yeah, peers are either persistent or not. I can add logic to move bootstrap addresses to persistent addresses in case of overlap to make it slightly more foolproof, wdyt?
There was a problem hiding this comment.
As long as we can use the PEX from persistent peers in regular pool, this is probably fine. Moving bootstrap addresses to persistent pool is probably bad, because if everyone tries to connect to bootstrap nodes and never disconnect, then bootstrap will have all its incoming connections occupied and start to reject new-comers, which is worse.
In fact, we should probably intentionally disconnect old connections on bootstrap nodes. But we can do that in the future.
There was a problem hiding this comment.
To be clear, I didn't mean to make all bootstrap nodes persistent - I just meant that IF the same peer has an address in both in bootstrap list AND persistent list THEN both addresses could be used to establish the persistent connection to this peer (while currently the address from the bootstrap list is just discarded).
There was a problem hiding this comment.
ah I see, that's fine then
2 participants
To make the p2p network uniformly random, nodes need to be able to change their peers periodically (otherwise network would be centralized at bootstrap peers). This PR implements an algorithm based on stable hashing, which makes nodes assign random priority to every node ID, and connect to peers with higher priority.
This pr also separates inbound and outbound connection pools to simplify logic. In particular it is possible that there will be 2 concurrent connections between 2 peers (inbound + outbound). Avoiding duplicate connections is best effort - nodes try not to dial peers that they are connected to, but in case 2 peers dial each other at the same time they let those 2 connections be.
Basic requirements: