Currently when an "addr" message is broadcast in the p2p network, a connected instance of Pool will add these to the end of the '_addrs' array, so that if another peer disconnect, the pool can attempt to connect to one of these addresses. However after running a p2p node for over ten days, it's possible that the number of "_addrs" will grow beyond 21,000 known peers. This is valuable information in being able to maintain connections, however currently it's all stored in memory. Having an option to save these between restarts would be useful, in addition, a way to rate the peers based on latency, geographic location, bitcoin version, and message reliability woulld be excellent. However in the short term, it's theoretical that this number could grow and consume lots of memory. So it could be useful to provide a configuration option to limit the length of the "_addrs" array in pool, and possibly provide some convience methods to save/read these from disk.
maraoz
commented
9 years ago
Currently when an "addr" message is broadcast in the p2p network, a connected instance of Pool will add these to the end of the '_addrs' array, so that if another peer disconnect, the pool can attempt to connect to one of these addresses. However after running a p2p node for over ten days, it's possible that the number of "_addrs" will grow beyond 21,000 known peers. This is valuable information in being able to maintain connections, however currently it's all stored in memory. Having an option to save these between restarts would be useful, in addition, a way to rate the peers based on latency, geographic location, bitcoin version, and message reliability woulld be excellent. However in the short term, it's theoretical that this number could grow and consume lots of memory. So it could be useful to provide a configuration option to limit the length of the "_addrs" array in pool, and possibly provide some convience methods to save/read these from disk.