Skip to content
This repository was archived by the owner on Oct 3, 2023. It is now read-only.

Waiting 10s BEFORE discovering bootstrap nodes? #85

Closed
alanshaw opened this issue Jan 3, 2019 · 0 comments · Fixed by #86
Closed

Waiting 10s BEFORE discovering bootstrap nodes? #85

alanshaw opened this issue Jan 3, 2019 · 0 comments · Fixed by #86
Assignees

Comments

@alanshaw
Copy link
Member

alanshaw commented Jan 3, 2019

Shouldn't we discover on start instead of setting an interval and initially discovering after 10s? Looks like this is the main issue behind ipfs/js-ipfs#1706

this._timer = setInterval(() => {
this._list.forEach((candidate) => {
if (!isIPFS(candidate)) { return log.error('Invalid multiaddr') }
const ma = multiaddr(candidate)
const peerId = PeerId.createFromB58String(ma.getPeerId())
PeerInfo.create(peerId, (err, peerInfo) => {
if (err) { return log.error('Invalid bootstrap peer id', err) }
peerInfo.multiaddrs.add(ma)
this.emit('peer', peerInfo)
})
})
}, this._interval)

Here we set an interval, which triggers initially after 10s.

refs #72

alanshaw pushed a commit that referenced this issue Jan 3, 2019
Previously we had to wait 10s (by default) **before** initial peer discovery, since the module uses an interval to re-emit discovered peers every 10s. This PR refactors `start` to do an initial discovery of the boostrap peers immediately after it has started (i.e. after the callback has been called).

This addresses the problem where a call to `cat`/`get`/others immediately after the IPFS `ready` event would take at minimum 10s to get content stored on the preload nodes due to the initial delay in discovery.

fixes #85
resolves ipfs/js-ipfs#1706

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
@ghost ghost assigned alanshaw Jan 3, 2019
@ghost ghost added the status/in-progress In progress label Jan 3, 2019
vasco-santos pushed a commit that referenced this issue Jan 3, 2019
Previously we had to wait 10s (by default) **before** initial peer discovery, since the module uses an interval to re-emit discovered peers every 10s. This PR refactors `start` to do an initial discovery of the boostrap peers immediately after it has started (i.e. after the callback has been called).

This addresses the problem where a call to `cat`/`get`/others immediately after the IPFS `ready` event would take at minimum 10s to get content stored on the preload nodes due to the initial delay in discovery.

fixes #85
resolves ipfs/js-ipfs#1706

License: MIT
Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
@ghost ghost removed the status/in-progress In progress label Jan 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant