Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: ensure dials are sorted based on their recent success #2164

Conversation

maschad
Copy link
Member

@maschad maschad commented Oct 20, 2023

Title

feat: ensure dials are sorted based on their recent success

Description

Given that we are now tracking dials based on their lastSuccess and lastFailure we should ensure that they the are properly ordered before dialling, and subsequently update the peerStore with that metadata dependent on the outcome of that dial.

This PR also removes the AUTO_DIAL_PEER_RETRY_THRESHOLD since we are no longer sorting dials on a per peer basis but rather on a peer multiaddr basis. This adds a retry mechanism that exponentially backoffs of dialling failed addresses per peer.

Closes #2150
Closes #2114

Related #2090

Notes & open questions

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation if necessary (this includes comments as well)
  • I have added tests that prove my fix is effective or that my feature works

@maschad maschad requested a review from a team as a code owner October 20, 2023 02:28
@maschad maschad marked this pull request as draft October 23, 2023 16:11
@maschad maschad marked this pull request as ready for review October 23, 2023 18:50
@maschad maschad marked this pull request as draft October 23, 2023 18:51
@maschad maschad marked this pull request as ready for review October 23, 2023 20:20
@maschad maschad self-assigned this Oct 24, 2023
Comment on lines +609 to +611
addr.lastFailure *= 2
} else {
addr.lastFailure = Date.now()
Copy link
Member

Choose a reason for hiding this comment

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

Something seems wrong here.
Is lastFailure a timeout value or a date?
If its a date, then multiplying it by 2 is wrong.
If its a timeout value, setting as the current date is wrong.

Copy link
Member Author

Choose a reason for hiding this comment

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

The lastFailure value is a unix timestamp but it's being utilized as a value for ordering the list of multiaddrs, therefore exponentially increasing it so that it will be penalized even further to the bottom of the list seems a valid approach i.e. it could be any unique incremental numerical value as long as it is sequentially increasing to create an order within the list of addrs.


try {
if (pendingDial.peerId != null) {
peer = await this.peerStore.get(pendingDial.peerId)
Copy link
Member

Choose a reason for hiding this comment

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

maybe this peerStore.get should happen in _updateAddressStatus and leave _updateAddressStatus signature alone?

I think it tracks more nicely to have the get+update in the "same place".
Also thats one less promise that has to be fulfilled before we get to dial.

Copy link
Member Author

Choose a reason for hiding this comment

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

I take your point but when refactored that way a potential ERR_NOT_FOUND would be propagated in lieu of a consequent and perhaps more meaningful error such as a NO_RESERVATION error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants