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

Sort peers & fix bug with filtered peer status #354

Merged
merged 5 commits into from
Oct 30, 2017
Merged

Sort peers & fix bug with filtered peer status #354

merged 5 commits into from
Oct 30, 2017

Conversation

alexbarnsley
Copy link
Member

This is to improve the initial connection to the network. More recently, there's been a lot of connect/disconnect activity. It now looks for the best peers based on highest Block Height, and lowest Delay.

@luciorubeens I couldn't use orderBy - it just didn't work (silently failing). Instead, I did this. I also didn't store in the serviceProvider as suggested, so i check on the first index of getGoodPeer and sort then, once.

Feedback welcome!

@alexbarnsley
Copy link
Member Author

Removing the filter as it's a copy of another (does it twice)

@alexbarnsley alexbarnsley changed the title Sort peers by Height DESC, Delay ASC Sort peers & fix bug with filtered peer status Oct 18, 2017
@alexbarnsley
Copy link
Member Author

I believe I'm done making changes now. There was a bug where it filtered down peers based on status, but it didn't use this filtered down list when making the initial connection to a peer (on first load of the desktop client).

Also now sorting peers based on Height DESC, Delay ASC

}));
findGoodPeer(response.peers, 0);
getFromPeer('/api/peers/version').then(function(versionResponse) {
let peers = response.peers.filter(function(peer) {

Choose a reason for hiding this comment

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

Does there need to be validation for response.success like the above api call 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.

Not a bad shout. It shouldn't be necessary but will add it anyway and will let it fallback on the stored peers if it fails 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

Pushed the change for you to take a look 👀

@luciorubeens
Copy link
Contributor

luciorubeens commented Oct 30, 2017

I think getting the same version from the current peer does not make sense because if it is using an earlier version the user will get stuck in that version

@alexbarnsley
Copy link
Member Author

@luciorubeens would that be possible without manually changing the networks? It all starts from the initial network which would be the master wouldn't it?:

https://github.com/alexbarnsley/ark-desktop/blob/f168b793e5b0b10e704a633bb1a461ba35a04d3a/client/app/src/services/network.service.js#L84-L114

Maybe I've misunderstood, I though it connected to the master network first to get the peers. I'll double check when I'm at a machine.

I'm happy to take it out though if you think it will be an issue!

@luciorubeens
Copy link
Contributor

yeah, but suppose we updated the ark-node, and this default peer has not updated yet.. I'm just making sure that we don't have to manually update this. I'll merge but I think we can improve a bit more.. +5! 👍🏻

@luciorubeens luciorubeens merged commit 84559d0 into ArkEcosystem:master Oct 30, 2017
@alexbarnsley
Copy link
Member Author

That's fair enough @luciorubeens 😁 I'll have a think about whether there's a better way to check version numbers. Perhaps any matching version or greater would work? That way you're not stuck on an old version. Does that sound like an option?

alexbarnsley added a commit that referenced this pull request Dec 3, 2018
* fix: button margin on alert message

* fix: rounded on top of menu (wallet show page)

* fix: copy to clipboard padding (wallet new page)
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.

None yet

3 participants