509a7af26a
This fixes an issue where the mumbai testnet node struggle to find peers. Before this fix in general test peer numbers are typically around 20 in total between eth66, eth67 and eth68. For new peers some can struggle to find even a single peer after days of operation. These are the numbers after 12 hours or running on a node which previously could not find any peers: eth66=13, eth67=76, eth68=91. The root cause of this issue is the following: - A significant number of mumbai peers around the boot node return network ids which are different from those currently available in the DHT - The available nodes are all consequently busy and return 'too many peers' for long periods These issues case a significant number of discovery timeouts, some of the queries will never receive a response. This causes the discovery read loop to enter a channel deadlock - which means that no responses are processed, nor timeouts fired. This causes the discovery process in the node to stop. From then on it just re-requests handshakes from a relatively small number of peers. This check in fixes this situation with the following changes: - Remove the deadlock by running the timer in a separate go-routine so it can run independently of the main request processing. - Allow the discovery process matcher to match on port if no id match can be established on initial ping. This allows subsequent node validation to proceed and if the node proves to be valid via the remainder of the look-up and handshake process it us used as a valid peer. - Completely unsolicited responses, i.e. those which come from a completely unknown ip:port combination continue to be ignored. - |
||
|---|---|---|
| .. | ||
| database | ||
| observer | ||
| reports | ||
| utils | ||
| main.go | ||
| README.md | ||
Observer - P2P network crawler
Observer crawls the Ethereum network and collects information about the nodes.
Build
make observer
Run
observer --datadir ... --nat extip:<IP> --port <PORT>
Where IP is your public IP, and PORT has to be open for incoming UDP traffic.
See observer --help for available options.
Report
To get the report about the currently known network state run:
observer report --datadir ...
Description
Observer uses discv4 protocol to discover new nodes. Starting from a list of preconfigured "bootnodes" it uses FindNode to obtain their "neighbor" nodes, and then recursively crawls neighbors of neighbors and so on. Each found node is re-crawled again a few times. If the node fails to be pinged after maximum attempts, it is considered "dead", but still re-crawled less often.
A separate "diplomacy" process is doing "handshakes" to obtain information about the discovered nodes. It tries to get RLPx Hello and Eth Status from each node. The handshake repeats a few times according to the configured delays.