-
Notifications
You must be signed in to change notification settings - Fork 22
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
Refactor some Nominator & NetworkManager code #618
Conversation
Codecov Report
@@ Coverage Diff @@
## v0.x.x #618 +/- ##
==========================================
+ Coverage 90.06% 90.07% +<.01%
==========================================
Files 62 62
Lines 4571 4564 -7
==========================================
- Hits 4117 4111 -6
+ Misses 454 453 -1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really? That was not my intention, but I'm glad if it's true. 👀 |
maybe Intermittent http error began to be invisible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful. Just rebase and feel free to self merge.
723219a
to
7e9fffa
Compare
Clients should not expect any status code when issuing calls to the receiveEnvelope() API. The node itself may care whether its internal SCP class considers the envelope valid or not, but it does not need to signal back to the client whether it accepted the envelope. This is because this API should be used in an asynchronous way. Aftera client floods a given SCPEnvelope to the network, it does not care about how that envelope is further processed by each node.
The transaction is propagated to the entire network, so the name of the function should reflect that.
The NetworkManager should be in charge of gossiping any transactions and SCPEnvelopes. This reduces complexity, and avoids delayed initialization of the set of peers in the Nominator class. Additionally, in the future this will enable easier gossiping to clients which connected to us first, see issue bosagora#606 for more info.
7e9fffa
to
2105ebb
Compare
This is the first part of fixing #606
While implementing the feature, I've realized there are leaky abstractions here. In fact SCP only requires two networking functionalities:
The second part can be left to the NetworkManager, as it also deals with features such as node banning, receiving new network connections (to be done), etc.