Woke up this morning asking myself why a full node needs so many connected peers (constantly between 600 and 900) while doing nothing (no content hosted/downloaded)?
I know that Golang can’t get restricted in ressources usage, which is normal, and I don’t think the problem is coming from that.
When I start a computer and browse the Internet, the network stack is not using that much ressources compared to running an IPFS full node (up to 90% of CPU, 70% of RAM etc).
From a naive design point of view, I would expect connections to be limited to:
- Closest peers, part of the same bucket, as described in the Kademlia DHT routing table principle
- Peers querying the DHT for a ressource my bucket/node should be aware of (some sort of content hash based spliting to restrict query to a part of the network)
- Peers messaging to update ressource list my bucket/node is responsible of (can be huge but effemeral…and in a pub/sub pattern shouldn’t need a direct connection)
- Peers I’m downloading/uploading data from/to (which is effemeral too)
I may need a real strong coffee to reset my mind or am in a “dumb-day”, but can someone explain me where I’m wrong ?
Does the huge number of connected peers only comes from some DHT flooding due too many nodes getting in and out of the network ? In that case, isn’t there a technical design problem that needs a quick refactoring and are there ideas being explored already?