Skip to content
This repository has been archived by the owner on Aug 23, 2019. It is now read-only.

fix: improve dial queue and parallel dials #315

Merged
merged 7 commits into from
Mar 28, 2019
Merged

Conversation

jacobheun
Copy link
Contributor

@jacobheun jacobheun commented Mar 28, 2019

Improved Dialer

This improves the dialer queue a bit by doing a few things:

Multidimensional queues
As dial requests are made they no longer go into a single, global queue, they are immediately added to the dial queue for that specific peer. This allows a successful queue, or one that errors, to immediately resolve the remaining dialing requests. Previously, a subsequent request would need to wait until its turn globally, which is slow, especially if it just needs to be aborted or a new stream needs to be created for a protocol.

Immediate dials for connected peers
If a peer is already connected, we immediately start its queue if it's not already running. The max parallel queues aren't affected by this. This ensures that we have a steady stream of communication with our connected peers, which is critical to maintaining a healthy network.

Configurable dial timeout

The dial timeout was also not configurable. This has been corrected and added to the readme.

@ghost ghost assigned jacobheun Mar 28, 2019
@ghost ghost added the in progress label Mar 28, 2019
README.md Outdated Show resolved Hide resolved
src/limit-dialer/index.js Outdated Show resolved Hide resolved
})
})

tryEach(tasks, (_, result) => {
if (result && result.conn) {
parallel(tasks, (_) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, do you want to use async/race for this instead so you don't have to wait for all the dials to finish before calling back?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will use each. race will finish as soon as any of the dial callbacks finish, even if nothing is passed. So if we dial 5 addresses and the first errors, even if we just store an array of the errors as soon as we callback it ends, so we end up having a "failed" dial after the first one errors. Even if the other 4 were actually good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I did go with race for the aforementioned benefits. I just only call the callback if we have a value, or if everything errored.

}
return callback(null, { cancel: true })
return callback(null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does removing these objects do?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe these were left over from some old code, only valid connection results are being used now, so they were deleted. The intent is that it creates a cancel token that causes other successfully dialed connections to be destroyed. Now the token is created when we receive the first valid connection.

docs: fix spelling
@jacobheun jacobheun marked this pull request as ready for review March 28, 2019 18:03
@jacobheun jacobheun changed the title [WIP] fix: improve dial queue and parallel dials fix: improve dial queue and parallel dials Mar 28, 2019
@jacobheun jacobheun requested a review from alanshaw March 28, 2019 18:04
@jacobheun jacobheun merged commit fcbcccc into master Mar 28, 2019
@ghost ghost removed the in progress label Mar 28, 2019
@jacobheun jacobheun deleted the fix/dial-queue branch March 28, 2019 22:19
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 this pull request may close these issues.

2 participants