Repository navigation
misc: add a PeerStore behaviour #4103
Description
Description
Other implementations have the concept of a PeerStore, should we add one to rust-libp2p too? I am thinking of a NetworkBehaviour implementation tracks currently connected peers and allows to add / remove addresses.
See related discussions:
- chore(libp2p): expose
Behaviour::connectedandBehaviour::addresses#4101 - libp2p-kad: provide a way to get known addresses of a peer from address book #3633
- On connection management #2118
Motivation
Users should be able to query the connected peers in a simple way and add known addresses of peers that will contribute to establishing new connections.
Open questions
- Are the two topics connected-peers and adding new addresses related enough to merge them in one behaviour?
- Is storing addresses in-memory fine for now?
- Should we add a persistent address book as well? e.g. an SQL-based one?
Are you planning to do it yourself in a pull request?
No
Reacted by Max Inden, Darius Clark, Doug A and DrHuangMHT
Activity
mxinden commentedon Jun 23, 2023
In general I am in favor of a
PeerStoreNetworkBehaviourimplementation.In addition to the above, I suggest adding a new variant to
libp2p_swarm::behaviour::ToSwarm, allowing aNetworkBehaviourto inform otherNetworkBehaviours of addresses of peers it discovered. Similar to how we haveToSwarm::NewExternalAddressCandidate, but for addresses of remote peers instead of addresses of the local node.libp2p-identifyandlibp2p-kadcan emit these events andPeerStorecan consume these events.We could then deprecate
libp2p-identify'sdiscovered_peerscache.rust-libp2p/protocols/identify/src/behaviour.rs
Lines 53 to 54 in 85a846a
thomaseizinger commentedon Jun 23, 2023
Good idea.
That is orthogonal though, correct? We can ship an initial peer store without introducing such a variant (which is a breaking change).
A
ToSwarm::NewPeerAddressevent should likely also be consumed bylibp2p-kadto extend the routing table.dariusc93 commentedon Jun 24, 2023
Should be simple to do from the behaviour standpoint. Maybe we could do a trait similar to libp2p-kad store that can be used for others to implement their own backend besides the memory backend. Also, I think storing in memory is fine for now, which is what I usually do although storing it elsewhere (eg database, on-disk, etc) is a nice-to-have solution down the road, but dont think it really fits the scope of rust-libp2p.
thomaseizinger commentedon Jun 24, 2023
The question is, is it worth doing the abstraction of a trait and deal with all the issues of e.g. futures that need to run on a specific executor (thinking tokio-postgresql etc) over just requiring people to implement another
NetworkBehaviourfor it.mxinden commentedon Aug 18, 2023
Tracked in #4302.
thomaseizinger commentedon Aug 18, 2023
Another thing to consider is that reading from this store needs to be synchronous and fast because we do it for every outgoing connection. Thus, the entire list needs to be in-memory anyway.
Storing peer addresses in a database or disk does make sense though. I think we can accommodate for that by:
The above would allow users to integrate the peer store into an event loop and synchronize its state with another data source or sink. It would only be eventually-consistent but I think that is fine.
thomaseizinger commentedon Jan 21, 2024
With #4371 approved, this issue is now unblocked.
guillaumemichel commentedon May 16, 2024
Lessons from go-libp2p: libp2p/go-libp2p#2355
feat(peer-store): introduce libp2p-peer-store
feat(peer-store): introduce libp2p-peer-store