Connect Warp Sync to Proper Packets #692
Open
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
This patch connects Warp Sync to the correct packets that come back from Parity when warp syncing. There were a few issues with the algorithm for determining packet ids. It appears that each capability has a size (to allow for protocol upgrades) and we skip that many before the next protocol. These aren't documented from come by Parity's source code. Additionally, it appears that once you negotiate a protocol, you still use the offests from Pv62 but from the higher negotiated ids. It's all a bit weird, but this seems to get everything working. Finally, we had an issue with default map getting called *a lot*, so we instead opt to hard-code the value and try to pass nil around instead of default map.
willmeister
approved these changes
Dec 3, 2018
| @@ -100,6 +100,6 @@ defmodule ExWire.DEVp2p.Session do | |||
| """ | |||
| @spec compatible_capabilities?(t) :: boolean() | |||
| def compatible_capabilities?(%__MODULE__{packet_id_map: packet_id_map}) do | |||
| packet_id_map != PacketIdMap.default_map() | |||
| Map.has_key?(packet_id_map.ids_to_modules, 0x10) | |||
There was a problem hiding this comment.
Hardcoding 0x10 here presumes to know how PacketIdMap works. Pretty safe assumption, but might work better as a function of PacketIdMap.
There was a problem hiding this comment.
Yeah, and I don't think this PR has tests passing yet, since I wanted to get some design review. I wasn't sure what's the best way to say "We have compatibility" but having a 0x10 status packet seems to be pretty common on protocols. Also, it's faster to verify than the previous solution, even if possibly less accurate.
|
@willmeister Was this otherwise addressed in a different PR that you made? |
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 patch connects Warp Sync to the correct packets that come back from Parity when warp syncing. There were a few issues with the algorithm for determining packet ids. It appears that each capability has a size (to allow for protocol upgrades) and we skip that many before the next protocol. These aren't documented from come by Parity's source code. Additionally, it appears that once you negotiate a protocol, you still use the offests from Pv62 but from the higher negotiated ids. It's all a bit weird, but this seems to get everything working. Finally, we had an issue with default map getting called a lot, so we instead opt to hard-code the value and try to pass nil around instead of default map.