Hey @a1300
This is not an issue, but I understand the doubt here. In the discovery module level, libp2p-bootstrap, libp2p-mdns, ... the peer:discovery event is always triggered, like your expectation.
However, the same does not happen from the libp2p standpoint. What happens behind the scenes is that libp2p listens on peer:discovery events from the discovery modules and adds that information to the PeerStore. If it is a new entry in the PeerStore, it will emit the event from libp2p.
We should probably make it more clear. Is there any place you would see this information?
Hi @vasco-santos
thanks for you fast response.
Does the libp2p-bootstrap still have its raison d'être? It only adds all Peers in the Bootstrap list to the PeerStore on startup and fires an event. Or maybe libp2p shouldn't allow the interval Bootstrap option. Otherwise people think that it will "discover" peers in a regular interval. The 1st example in example/discovery-mechanism also uses the interval property.
My problem is, that I have nodes that are not 100% of the time online. So in previous libp2p versions I dialed the bootstrap nodes in the peer.discovery event handler only if I am not connected. I will now use the following workaround. Is there a more elegant solution?
const myBootstrap = new Bootstrap({
list: bootstrap,
interval: 3000
})
myBootstrap.on('peer', (peer) => {
console.log('this fires every x seconds')
})
options.modules.peerDiscovery = [myBootstrap];
How does libp2p-bootstrap work together with the autodial option? What happens if the target node is currently down, and starts in 5 minutes? Will there be a re-dial (even without a second peer:discovery event) ?
Does the libp2p-bootstrap still have its raison d'être?
Yes it has. It is basically a configurable way of attempting a dial to several peers on startup
Or maybe libp2p shouldn't allow the interval Bootstrap option.
That is probably true! I will need to think better about this for https://github.com/libp2p/js-libp2p/issues/744
So, for libp2p@0.30 we will be working on this connection manager overhaul. Some important things that should happen regarding this issue are:
we will probably remove the autoDial option
libp2p will become more auto sufficient by enabling users and libp2p subsystems to configure how many connections they will want and how their lifecycle should be
for example in bootstrap, the default behaviour would be connect to the provided peers and add a decaying tag to them. This way, once we leverage the bootstrap nodes to build our topology of important peers for the node, the bootstrap nodes should be disconnected as they typically have a large load of requests and their single purpose is bootstrapping a peer network
this above might not be the case for every single scenario. So, we will need to add features like protected peers (and other important tags), that make sure that connections are kept for them.
I will now use the following workaround. Is there a more elegant solution?
Not great, but a bit better would be to configure bootstrap as in the examples and then:
How does libp2p-bootstrap work together with the autodial option? What happens if the target node is currently down, and starts in 5 minutes? Will there be a re-dial (even without a second peer:discovery event) ?
Per this it will not try to re dial the peer unfortunately. You can still manually try to dial it through your event handler. It will probably be the best option at the moment
I renamed the issue to an action point on what we discussed with the bootstrap interval and I will keep it open for visibility while we do not get the connection management stuff in place
@a1300 commented on Tue Nov 24 2020
master
branchType:
Severity: Low
Description: The Bootstrap discovery mechanism only emits the event
peer:discovery
only once even when theinterval
property is specifiedI would expect from the Bootstrap discovery mechanism to fire the
peer:discovery
event every x millisecondsSteps to reproduce the error:
@vasco-santos commented on Tue Nov 24 2020
Hey @a1300 This is not an issue, but I understand the doubt here. In the discovery module level,
libp2p-bootstrap
,libp2p-mdns
, ... thepeer:discovery
event is always triggered, like your expectation. However, the same does not happen from the libp2p standpoint. What happens behind the scenes is that libp2p listens onpeer:discovery
events from the discovery modules and adds that information to the PeerStore. If it is a new entry in the PeerStore, it will emit the event from libp2p. We should probably make it more clear. Is there any place you would see this information?@a1300 commented on Tue Nov 24 2020
Hi @vasco-santos thanks for you fast response. Does the
libp2p-bootstrap
still have its raison d'être? It only adds all Peers in the Bootstrap list to the PeerStore on startup and fires an event. Or maybelibp2p
shouldn't allow theinterval
Bootstrap option. Otherwise people think that it will "discover" peers in a regular interval. The 1st example inexample/discovery-mechanism
also uses theinterval
property.My problem is, that I have nodes that are not 100% of the time online. So in previous
libp2p
versions I dialed the bootstrap nodes in thepeer.discovery
event handler only if I am not connected. I will now use the following workaround. Is there a more elegant solution?How does
libp2p-bootstrap
work together with theautodial
option? What happens if the target node is currently down, and starts in 5 minutes? Will there be a re-dial (even without a secondpeer:discovery
event) ?@vasco-santos commented on Tue Nov 24 2020
Yes it has. It is basically a configurable way of attempting a dial to several peers on startup
That is probably true! I will need to think better about this for https://github.com/libp2p/js-libp2p/issues/744 So, for
libp2p@0.30
we will be working on this connection manager overhaul. Some important things that should happen regarding this issue are:autoDial
optionNot great, but a bit better would be to configure bootstrap as in the examples and then:
Per this it will not try to re dial the peer unfortunately. You can still manually try to dial it through your event handler. It will probably be the best option at the moment
@a1300 commented on Tue Nov 24 2020
@vasco-santos thank you very much Should this ticket be closed? Or should the documentation first be changed/enhanced?
@vasco-santos commented on Tue Nov 24 2020
I renamed the issue to an action point on what we discussed with the bootstrap interval and I will keep it open for visibility while we do not get the connection management stuff in place
@vasco-santos commented on Fri Nov 27 2020
@jacobheun can you move this into the bootstrap repo?