Xiaoyao's manspreading seems like what we need to efficiently maintain a large number of peer connections. I think we could implement this into our current node-finder and run only a small number (possibly only 1) eth-monitor behind it.
The current node-finder disconnects peers as soon as we learn about their info. I'm thinking, with the proxy feature, we let the node-finder keep p2p connections and continue relaying eth subprotocol messages to the eth-monitor, if online.
This would accomplish followings:
Most of the resource heavy tasks occur on the eth subprotocol. Having node-finder maintain p2p connections won’t have much impact on its resource usage as the heavy-lifting is really done by eth-monitor.
eth-monitor communicates with only manspreading/node-finder instance(s), greatly reducing its resource usage.
This eliminates aggressive p2p connection attempts of eth-monitor, which is also redundant as the node-finder already does this when gathering node info.
This solves the problem of potentially losing all peers when eth-monitor goes down due to some fatal error.
https://github.com/xiaoyao1991/manspreading
Xiaoyao's manspreading seems like what we need to efficiently maintain a large number of peer connections. I think we could implement this into our current
node-finderand run only a small number (possibly only 1)eth-monitorbehind it.The current
node-finderdisconnects peers as soon as we learn about their info. I'm thinking, with the proxy feature, we let thenode-finderkeep p2p connections and continue relaying eth subprotocol messages to theeth-monitor, if online.This would accomplish followings:
node-findermaintain p2p connections won’t have much impact on its resource usage as the heavy-lifting is really done byeth-monitor.eth-monitorcommunicates with onlymanspreading/node-finderinstance(s), greatly reducing its resource usage.eth-monitor, which is also redundant as thenode-finderalready does this when gathering node info.eth-monitorgoes down due to some fatal error.