-
Notifications
You must be signed in to change notification settings - Fork 47
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
Protocol methods refactoring. #182
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since `Sleep` was not an option as discussed in #141, the waitGroup has been implemented in order to make the program itself trigger the protocol methods once a packet type in concrete is received. Also, added state-vars in order to force the `packetProcessor` gorutine to just activate the waitGroup if a bootstrapping or network discovery process is in progress. Now we need to add timeouts in order to prevent the app to get stucked at any protocol method execution.
On this way, we speed up the app by copying directly in the stack.
Now that we are using a different aproach with waitgroups, we can get rid of this state variables.
Now the `Router` provides blocking methods to poll Bootstrapp node and closestPeers (FIND_NODES) to allow a better and more logical library construction also featuring waitGroups and removing the timeouts.
Now that the `Router` offers blocking methods to search for the closest `alpha` peers and for polling the bootstrapping nodes, the logic can be leaved there and the protocol functions just take car of the logic of the algorithms itself.
We should not send the poll messages inside of the afterFunc, instead, we should send the messages on polling methods and wait on the afterFunc to execute the getters to our tree.
With lower timings we should be able to get all of the info we are expecting on the polling methods.
CPerezz
added
type:rfc
Changing the behaviour of something already defined
area:architecture
Issues related to general architectural improvements to enhance performance and/or maintainabilty
labels
Dec 8, 2019
Maybe there's no need for review since @autholykos is aware of all of the modifications. We discussed them during the weekend. Can this be merged? It's tested and working as it was with the |
autholykos
approved these changes
Dec 10, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area:architecture
Issues related to general architectural improvements to enhance performance and/or maintainabilty
type:rfc
Changing the behaviour of something already defined
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue comes out from #141 and closes #180
The protocol methods for the node have been refactored.
protocol.go
methods and send it to therouter.go
polling methods. Which are blocking and await for the responses toPING
andFIND_NODES
messages.