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: improve peer manager and re-integrate to light push #2191

Merged
merged 27 commits into from
Jan 30, 2025

Conversation

weboko
Copy link
Collaborator

@weboko weboko commented Oct 20, 2024

Problem

After spending time with project that use js-waku we were able to determine entities in the code which behavior can be improve. Among them: PeerManager, ReliabilityManager etc.

Solution

For behavior this PR aims to add robustenes to the code by adding new configuration properties and making sure they are enforced.
This PR also re-works PeerManager and partially RelibilityManager.

Notes

Copy link

github-actions bot commented Oct 20, 2024

size-limit report 📦

Path Size Loading time (3g) Running time (snapdragon) Total time
Waku node 84.74 KB (-2.3% 🔽) 1.7 s (-2.3% 🔽) 2.1 s (+93.36% 🔺) 3.8 s
Waku Simple Light Node 135.73 KB (-1.04% 🔽) 2.8 s (-1.04% 🔽) 3.2 s (+65.17% 🔺) 5.9 s
ECIES encryption 22.73 KB (-0.65% 🔽) 455 ms (-0.65% 🔽) 921 ms (+64.74% 🔺) 1.4 s
Symmetric encryption 22.23 KB (-0.63% 🔽) 445 ms (-0.63% 🔽) 789 ms (-11.5% 🔽) 1.3 s
DNS discovery 70.8 KB (+0.37% 🔺) 1.5 s (+0.37% 🔺) 1.5 s (+5.86% 🔺) 2.9 s
Peer Exchange discovery 71.8 KB (-0.03% 🔽) 1.5 s (-0.03% 🔽) 1.3 s (-28.12% 🔽) 2.8 s
Local Peer Cache Discovery 65.39 KB (+0.34% 🔺) 1.4 s (+0.34% 🔺) 1.8 s (+1.51% 🔺) 3.1 s
Privacy preserving protocols 76.52 KB (+0.39% 🔺) 1.6 s (+0.39% 🔺) 2.3 s (+57.99% 🔺) 3.8 s
Waku Filter 78.11 KB (-3.6% 🔽) 1.6 s (-3.6% 🔽) 1.9 s (+48.63% 🔺) 3.4 s
Waku LightPush 75.6 KB (-0.18% 🔽) 1.6 s (-0.18% 🔽) 2 s (-13.97% 🔽) 3.5 s
History retrieval protocols 75.78 KB (-2.47% 🔽) 1.6 s (-2.47% 🔽) 1.7 s (-2.86% 🔽) 3.2 s
Deterministic Message Hashing 7.32 KB (-0.96% 🔽) 147 ms (-0.96% 🔽) 319 ms (-35.12% 🔽) 465 ms

Copy link
Collaborator

@danisharora099 danisharora099 left a comment

Choose a reason for hiding this comment

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

Nice PR! 🚀

Lots happening here.
A few pointers from my side:

  • Are we planning to address the TODOs part of this PR, or follow up?
  • Do we need to introduce newer tests as we delete the functionalities and respective spec tests?
  • How does the peer management work with this PR, considering the overhaul of BaseProtocol, PeerManager and ConnectionManager? Is it stable?

packages/core/src/index.ts Show resolved Hide resolved
return getPeersForProtocol(this.components.peerStore, [this.multicodec]);
}

public async connectedPeers(): Promise<Peer[]> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we still have access to this utility function from elsewhere?
Basically getting the connected peers for a particular protocol

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes, in ConnectionManager there is method implemented for it
public async getConnectedPeers(codec?: string): Promise<Peer[]>

Copy link
Collaborator

@danisharora099 danisharora099 Jan 29, 2025

Choose a reason for hiding this comment

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

easier to do
waku.lightpush.connectedPeers()
vs
waku.connectionManager.getPeers(waku.lightpush.multicodec)

im in favor of not removing this
also is a breaking change

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

why waku.lightpush.connectedPeers() even needed?
I would assume to be used on the consumer side - but then it's something that we don't expect to be used

whereas waku.connectionManager.getPeers(waku.lightpush.multicodec) is for internal usage for protocols and shouldn't be used outside

also is a breaking change

agree, this PR is pretty much breaking change as we found out previous things were not working well enough

Copy link
Collaborator

Choose a reason for hiding this comment

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

we have had feedback in the past that convinces us that consumers want to be able to check the information of connected peers on the protocol (cc @vpavlin)
we can add it on the SDK layer instead of the core layer

Copy link
Collaborator

Choose a reason for hiding this comment

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

we can continue to use ConnectionManager to provide this API - do you see reason in switching out the use of multicodecs as arg for the function, with the enum type for protocols instead to help DX? (ref: #2191)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we have had feedback in the past that convinces us that consumers want to be able to check the information

that should be tackled by health state of the node, otherwise I don't see a need for consumers for do waku.lightPush.connectedPeers() - if that is something they need to do we can tell them:

  • do waku.getConnectedPeers().filter(byMulticodec);
  • expose connectionManager so that they can do the same from it;
    Back then this functionality was added without clear need.

do you see reason in switching out the use of multicodecs as arg for the function, with the enum type for protocols instead to help DX?

as I explained it in the other comment - connectionManager.getPeers(multicodec) - will return peers for metadata and other protocols where as Protocols is for consumers use and has only LightPush/Filter etc.


Just to clarify here - let's not have unnecessary entry points and not needed code. This will be easier for us as to support, bug fix and improve our own code base.
I see us adding one method that does the job and then improving it if we find more evidence.
Of course I might be wrong as to this particular case, but then we can add it once requested.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@danisharora099 let me know what you think.

packages/interfaces/src/connection_manager.ts Show resolved Hide resolved
packages/sdk/src/protocols/light_push/light_push.spec.ts Outdated Show resolved Hide resolved
packages/sdk/src/protocols/peer_manager.ts Show resolved Hide resolved
packages/sdk/src/protocols/store/index.ts Outdated Show resolved Hide resolved
@weboko weboko marked this pull request as ready for review January 15, 2025 23:17
@weboko weboko requested a review from a team as a code owner January 15, 2025 23:17
@weboko
Copy link
Collaborator Author

weboko commented Jan 28, 2025

thank you @danisharora099

Are we planning to address the TODOs part of this PR, or follow up?

absolutely, I was looking at some last week

Do we need to introduce newer tests as we delete the functionalities and respective spec tests?

absolutely again, but I limit this PR to drastic changes + manual validation and dogfooding
tests will be a follow up on a case by case basis

How does the peer management work with this PR, considering the overhaul of BaseProtocol, PeerManager and ConnectionManager? Is it stable?

explained in the comment above
it is stable, last Thursday we didn't find bugs as well

@weboko weboko requested a review from danisharora099 January 28, 2025 00:51
@weboko weboko mentioned this pull request Jan 28, 2025
5 tasks
Copy link
Collaborator

@danisharora099 danisharora099 left a comment

Choose a reason for hiding this comment

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

did another review
left comments in individual threads

* add message cache to Filter

* remove WakuOptions and use only ProtocolCreateOptions

* move subscribe options to createLightNode Fitler protocol options

* rename SubscriptionManager to Subscription

* rename to CreateNodeOptions

* add warning

* feat: introduce subscription manager (#2202)

* feat: inroduce subscription manager

* fix: make pipeline succeed (#2238)

* fix test

* use hardcoded value

* update playwright

* fix test:browser
Copy link
Collaborator

@danisharora099 danisharora099 left a comment

Choose a reason for hiding this comment

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

nice work! lgtm

primarily comments remaining are around not deleting tests, and adding new tests for new functionalities

packages/sdk/src/protocols/peer_manager.ts Outdated Show resolved Hide resolved
packages/tests/tests/filter/peer_management.spec.ts Outdated Show resolved Hide resolved
@weboko weboko merged commit 62f93dc into master Jan 30, 2025
12 of 14 checks passed
@weboko weboko deleted the weboko/peer-manager branch January 30, 2025 23:16
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.

feat: improve peer manager and re-integrate to light push
3 participants