-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Cap max incoming new block hashes at c_maxIncomingNewHashes #5676
Conversation
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.
Simple enough I can understand it. @gumb0 ?
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.
Looks fine, did you see this happening?
(our own code looks to be sending out no more than 20 hashes)
@gumb0 Haven't checked to see if we're actually hitting this, came across this issue when comparing our behavior to the Ethereum Wire Protocol spec / other clients' behavior |
gcc CI failure looks infrastructure-related:
|
Codecov Report
@@ Coverage Diff @@
## master #5676 +/- ##
==========================================
+ Coverage 62.97% 63.03% +0.06%
==========================================
Files 350 350
Lines 29990 29953 -37
Branches 3361 3352 -9
==========================================
- Hits 18885 18881 -4
+ Misses 9885 9856 -29
+ Partials 1220 1216 -4 |
You can at least see in the coverage report that this code is not hit by any unit test. https://codecov.io/gh/ethereum/aleth/pull/5676/diff |
46a0426
to
333fa99
Compare
Fixed CHANGELOG merge conflict |
Fix #5677
When we receive a NewBlockHashes ethereum capability packet which contains more hashes than
c_maxIncomingNewHashes
, process the firstc_maxIncomingNewHashes
hashes rather than disabling the peer.This bring's Aleth's behavior in line with Parity's (and I suspect Geth's as well).
Parity's processing of the NewBlockHashes packet is here: https://github.com/paritytech/parity-ethereum/blob/7f707fa524baaaccac499d69f9e452b380c31ffa/ethcore/sync/src/chain/handler.rs#L219-L288