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: custom dialer addr sorter #792

Merged
merged 4 commits into from
Nov 20, 2020

Conversation

vasco-santos
Copy link
Member

@vasco-santos vasco-santos commented Oct 28, 2020

This PR adds a custom dialer addr sorter via config. It is used both by the dialer and the autoRelay.

The default sorter function puts public addresses first as a first criterium and certified addresses as a second criterium. This comparator function should probably be moved into libp2p-utils.

Needs:

@vasco-santos vasco-santos force-pushed the feat/custom-dialer-multiaddr-sorter branch 2 times, most recently from 203d3de to fa4c480 Compare November 10, 2020 08:33
@vasco-santos vasco-santos marked this pull request as ready for review November 10, 2020 08:39
@vasco-santos vasco-santos force-pushed the feat/custom-dialer-multiaddr-sorter branch 2 times, most recently from dfdd29d to 5fdf959 Compare November 10, 2020 09:30
@@ -120,7 +124,16 @@ class Dialer {
this.peerStore.addressBook.add(id, multiaddrs)
}

let knownAddrs = this.peerStore.addressBook.getMultiaddrsForPeer(id) || []
let knownAddrs = this.addressSorter(
this.peerStore.addressBook.get(id) || []
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason you switched away from getMultiaddrsForPeer? The address sorter should be able to handle /p2p on a multiaddr and avoids the need for the map logic here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes! I want the sorter to get an Address and not a multiaddr. With this, we have the ability to sort with other data, like the .isCertified boolean.

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 downside is having to do the /p2p logic which is embedded in the getMultiaddrsForPeer. I suggest I move that logic to libp2p-utils and reuse it here. What do you think? Any naming suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, right. What if we just extend getMultiaddrsForPeer to take an optional sorter? Then we can keep that logic isolated and allow different systems to use different sorters as needed.

Copy link
Member Author

Choose a reason for hiding this comment

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

that seems good! I will change that as we will only use this with the getMultiaddrsForPeer

// Get peer known addresses and sort them per public addresses first
// Sorting addresses to public first
const remoteAddrs = this._addressSorter(
this._peerStore.addressBook.get(connection.remotePeer) || []
Copy link
Contributor

Choose a reason for hiding this comment

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

Use getMultiaddrsForPeer? This should also avoid the if check below for the p2p protoName.


const isPrivate = require('libp2p-utils/src/multiaddr/is-private')

// TODO: Move to libp2p-utils?
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I think this would be useful for other modules that would avoid needing to use libp2p as a dependency.

@@ -176,14 +177,36 @@ describe('Dialing (direct, WebSockets)', () => {
.and.to.have.property('code', ErrorCodes.ERR_TIMEOUT)
})

it('should sort addresses on dial', async () => {
sinon.spy(dialerUtils, 'sortPublicAddressesFirst')
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be good to actually verify the dial order here, we dont check anything after connectToPeer. Just pass a stub to addressSorter and return a different order than addressBook returns. We should be able to spy on the transportManager and ensure the addresses are executed in the same order addressSorter returns.

@vasco-santos vasco-santos force-pushed the feat/custom-dialer-multiaddr-sorter branch 2 times, most recently from 735973f to 6a686c6 Compare November 11, 2020 09:46
@vasco-santos vasco-santos force-pushed the feat/custom-dialer-multiaddr-sorter branch from eabd04a to f691d9b Compare November 16, 2020 14:25
Copy link
Contributor

@jacobheun jacobheun left a comment

Choose a reason for hiding this comment

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

Pending CI fixes this lgtm, just a couple fixes to the docs

Co-authored-by: Jacob Heun <jacobheun@gmail.com>
@vasco-santos
Copy link
Member Author

CI is green and suggestions added! 🎉

Copy link
Contributor

@jacobheun jacobheun left a comment

Choose a reason for hiding this comment

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

LGTM

@jacobheun jacobheun merged commit ad6187d into 0.30.x Nov 20, 2020
@jacobheun jacobheun deleted the feat/custom-dialer-multiaddr-sorter branch November 20, 2020 14:16
vasco-santos added a commit that referenced this pull request Dec 10, 2020
* feat: custom dialer addr sorter

* chore: use libp2p utils sorter via addressBook getMultiaddrsForPeer

* chore: use new libp2p utils

* chore: apply suggestions from code review

Co-authored-by: Jacob Heun <jacobheun@gmail.com>

Co-authored-by: Jacob Heun <jacobheun@gmail.com>
vasco-santos added a commit that referenced this pull request Dec 16, 2020
* feat: custom dialer addr sorter

* chore: use libp2p utils sorter via addressBook getMultiaddrsForPeer

* chore: use new libp2p utils

* chore: apply suggestions from code review

Co-authored-by: Jacob Heun <jacobheun@gmail.com>

Co-authored-by: Jacob Heun <jacobheun@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants