This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
Increase number of requested block bodies in chain sync #10247
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
* Increase the number of block bodies requested during Sync. * Check if our peer is an older parity client with the bug of not handling large requests properly * Add a ClientVersion struct and a ClientCapabilites trait
* Replace strings with ClientVersion in PeerInfo * Group further functionality in ClientCapabilities
from ClientVersion.
jam10o-new
approved these changes
Jan 25, 2019
5chdn
added
A0-pleasereview 🤓
tomusdrw
suggested changes
Jan 25, 2019
ordian
reviewed
Jan 26, 2019
if it's parity, remove version check. * Remove dependency on semver in ethcore-sync * Remove unnecessary String instantiation * Rename peer_info to peer_version * Update RPC test helpers * Simplify From<String> * Parse static version string only once * Update RPC tests to new ClientVersion struct * Document public members * More robust parsing of ID string
ordian
reviewed
Jan 31, 2019
ordian
added
A8-looksgood 🦄
ngotchac
suggested changes
Feb 5, 2019
ngotchac
added
A5-grumble 🔥
ordian
reviewed
Feb 5, 2019
Co-Authored-By: elferdo <elferdo@gmail.com>
Co-Authored-By: elferdo <elferdo@gmail.com>
Co-Authored-By: elferdo <elferdo@gmail.com>
ngotchac
approved these changes
Feb 5, 2019
ngotchac
added
A7-looksgoodtestsfail 🤖
tomusdrw
approved these changes
Feb 7, 2019
|
It's squash-and-merge day! Sorry for the conflicts again. |
ordian
added a commit
that referenced
this pull request
Apr 5, 2019
* master: fix: parity-clib/examples/cpp/CMakeLists.txt (#10313) CI optimizations (#10297) Increase number of requested block bodies in chain sync (#10247) Deprecate account management (#10213) Properly handle check_epoch_end_signal errors (#10015) fix(osx and windows builds): bump parity-daemonize (#10291) Add missing step for Using `systemd` service file (#10175) Call private contract methods from another private contract (read-only) (#10086) update ring to 0.14 (#10262) fix(secret-store): deprecation warning (#10301) Update to jsonrpc-derive 10.0.2, fixes aliases bug (#10300) Convert to jsonrpc-derive, use jsonrpc-* from crates.io (#10298)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
In order to speed up syncing and to be on par with geth, we want to increase the number of block bodies requested from a peer. It happens, though, that older parity software would not send any reply at all when a packet went over a given size. To play it safe, if syncing with such a peer we want to keep the lower numbers we have today.
In addition to increasing the number of block bodies per request, I have imlemented a struct, ClientVersion, and associated functionality to help parsing peer Id strings and querying for specific capabilities of the peer software.
Preliminary tests syncing with only geth nodes show an increase in synced blocks for a given fixed length of time of around 30% (with variations between runs).
Thanks to @ngotchac for support and reviewing.