Fix broadcast timeout #241
Closed
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
The original transaction send check depended on the node relaying the transaction back to Armory. However this behavior is not guaranteed and, due to changes in Core, almost never happens. The only guaranteed thing that will happen is that if the transaction is rejected for any reason, a reject message will be sent. If no reject message is received and the connection remains open and the node responsive, then the transaction was successfully sent. The transaction send check mechanism has been replaced with one that waits for a reject, and if it does not receive one, it will test the connection with a ping-pong.
|
Superseeded by 42a7ff4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes the problem where users would receive a "tx broadcast timed out (get)" error.
Asking the transaction back from the node is unreliable since the node will not relay a transaction back to the node that sent it. In order for the transaction to be received back, it must have relayed it to the other nodes it is connected to.
This PR replaces that mechanism entirely. Instead of asking for the transaction back, we send a ping and wait for a pong. If a reject is received before a pong, the transaction is bad and was not broadcast. If we receive a pong, then the transaction was good and was successfully sent to the node.
Users who run nodes with a large amount of connections (like myself) were unlikely to experience the original error since there is a higher probability that the transaction would be relayed to other nodes by the time it was requested for again by Armory.