DNS peers handled the same as boot nodes#4178
Conversation
Signed-off-by: Stefan <stefan.pingel@consensys.net>
Signed-off-by: Stefan <stefan.pingel@consensys.net>
Signed-off-by: Stefan <stefan.pingel@consensys.net>
matkt
left a comment
There was a problem hiding this comment.
just a few questions to understand the PR
| return; | ||
| } | ||
|
|
||
| if (messageData.getSize() > this.maxMessageSize) { |
There was a problem hiding this comment.
not sure why this modification is present in the PR
.../main/java/org/hyperledger/besu/ethereum/p2p/discovery/internal/PeerDiscoveryController.java
Outdated
Show resolved
Hide resolved
| .build(); | ||
| final DiscoveryPeer peer = DiscoveryPeer.fromEnode(enodeURL); | ||
| peers.add(peer); | ||
| rlpxAgent.connect(peer); |
There was a problem hiding this comment.
why are we no longer trying to connect to the peer?
There was a problem hiding this comment.
It looks like it is just moved to the subsequent block on line 357 after adding to the peer table
Signed-off-by: Stefan <stefan.pingel@consensys.net>
| messageData.getSize(), | ||
| this.maxMessageSize); | ||
| } | ||
|
|
There was a problem hiding this comment.
this is useful, although unrelated to this PR
| } | ||
|
|
||
| private void addInitialPeers(final List<DiscoveryPeer> initialPeers) { | ||
| LOG.debug("INITIAL PEERS: {}", initialPeers); |
| .build(); | ||
| final DiscoveryPeer peer = DiscoveryPeer.fromEnode(enodeURL); | ||
| peers.add(peer); | ||
| rlpxAgent.connect(peer); |
.../main/java/org/hyperledger/besu/ethereum/p2p/discovery/internal/PeerDiscoveryController.java
Show resolved
Hide resolved
jflo
left a comment
There was a problem hiding this comment.
Tested and a slight initial speedup in gained peers was observed.
| * @param limit The amount of results to return. | ||
| * @return The <code>limit</code> closest peers, at most. | ||
| */ | ||
| public List<DiscoveryPeer> nearestBondedPeers(final Bytes target, final int limit) { |
There was a problem hiding this comment.
I presume this is necessary in order to not give remote clients a list of unverified peers from DNSDaemon lookups?
There was a problem hiding this comment.
This is using the definition of distance from the devP2P spec to find the limit number of closest peers to the target.
This is needed to respond to a peer asking for neighbours.
|
|
||
| final PeerTable.AddResult result = peerTable.tryAdd(peer); | ||
| if (result.getOutcome() == PeerTable.AddResult.AddOutcome.SELF) { | ||
| return false; | ||
| } | ||
|
|
||
| // Reset the last seen timestamp. |
There was a problem hiding this comment.
(bug) This change is problematic - if we discover our own node, we will now attempt to connect to ourselves because we're no longer short-circuiting the notifyPeerBonded logic below. The call to notifyPeerBonded dispatches an event which will cause the RlpxAgent to attempt a new connection.
There was a problem hiding this comment.
This check is not needed anymore. The peerPermissions.isallowedInPeerTable takes care of this, as the local node is checked in the PeerPermissionsDenylist isPermitted() method.
| if (messageData.getSize() > this.maxMessageSize) { | ||
| LOG.debug( | ||
| "Peer {} sent a message with size {}, larger than the max message size {}", | ||
| ethPeer, | ||
| messageData.getSize(), | ||
| this.maxMessageSize); | ||
| } |
There was a problem hiding this comment.
We've had 2 tickets and 3 PRs recently touch this logic, and now we're silently modifying it again in an unrelated PR.
Related Issues:
- Besu peers send messages exceeding the 10MB message size limit #3867
- Increase default maximum size for p2p messages #4119
We should not be including these kinds of changes mixed in with other functional changes. There's also no explanation for why we're changing this again here.
Note: I'm not saying we should remove this, just that as a practice we should not be lumping in unrelated functional changes into a PR with no documentation on why the change is being made.
There was a problem hiding this comment.
This is just adding debug info so we can see which clients are sending these messages
There was a problem hiding this comment.
I've removed that. The only time I saw it in the logs was from an older Besu version!
| public Optional<PeerDiscoveryController> getPeerDiscoveryController() { | ||
| return controller; | ||
| } | ||
|
|
There was a problem hiding this comment.
The PeerDiscoveryController is marked as internal and is not intended to be accessed from outside the discovery package. Any functionally that is needed should be exposed through PeerDiscoveryAgent.
| public boolean addToPeerTable(final DiscoveryPeer peer) { | ||
| final PeerTable.AddResult result = peerTable.tryAdd(peer); | ||
|
|
||
| if (result.getOutcome() == PeerTable.AddResult.AddOutcome.SELF) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
(bug) This method bypasses peerPermissions.
There was a problem hiding this comment.
Yes, this was missed. I will create a new PR to add this check.
| public List<DiscoveryPeer> nearestPeers(final Bytes target, final int limit) { | ||
| final Bytes keccak256 = Hash.keccak256(target); | ||
| return streamAllPeers() | ||
| .filter(p -> p.getStatus() == PeerDiscoveryStatus.BONDED) |
There was a problem hiding this comment.
Why has this method been modified? And why did we create the very similar nearestBondedPeers? It looks like the functional effect of this is to make the periodic peer searches run across all peers, not just bonded peers. Perhaps this is desired, but it should be addressed in a separate PR.
I suspect the reason this was added is because we're now directly injecting peers into the discovery table instead of bonding with them first. I would suggest reverting these changes, and attempting to bond with the DNS peers rather than directly injecting them.
There was a problem hiding this comment.
This would be cleaner, I guess. I will do that in a separate PR.
| 60000L, | ||
| 1800000L, |
There was a problem hiding this comment.
If the call to the DNS server fails, this introduces a big time lag before we try again.
There was a problem hiding this comment.
good point. maybe somewhere in between?
| if (peerDiscoveryController.isPresent()) { | ||
| final PeerDiscoveryController controller = peerDiscoveryController.get(); | ||
| LOG.debug("Adding {} DNS peers to PeerTable", peers.size()); | ||
| peers.forEach(controller::addToPeerTable); |
There was a problem hiding this comment.
As mentioned previously, we should be calling PeerDiscoveryAgent.bond here instead of directly injecting peers into the discovery peer table.
* DNS peers handled the same as boot nodes * make sure that non bonded peers can be used as initial peers * try to connect to DNS nodes Signed-off-by: Stefan <stefan.pingel@consensys.net> Co-authored-by: Justin Florentine <justin+github@florentine.us>
Peers discovered through the DNSDaemon are now added to the peerTable. These peers are potentially used (16 are randomly chosen from the peer table) in RecursivePeerRefreshStateas as the initial peers for bonding and then for finding neighbours, etc.
Signed-off-by: Stefan stefan.pingel@consensys.net