Server keeps receiving block headers it already has #373
Comments
yeastplume
changed the title
|
Twice now while trying to sync, crapped out in the exact same place with the same PoisonError |
|
Relevant bit of stack trace from above: |
|
Okay, so digging into this further now, using a fresh sync as an example: I have nothing, so I create a locator with a single height [0], genesis block, and ask a peer for some blocks. It gives me 512 (the max) back.. 0..511 That's all fine.. so now I go off to get the next one: First, that seems a bit odd that I'm passing the same locator array.. but looking at the heights I only have up to block 255, so I don't have a header higher than 255 the array and can't ask for it (that seems like problem #1). so I've sent the same locator array off and get back (as I'm downloading and processing blocks) So we're only seem to be saving the headers in the chain when blocks are actually processed, not when we have the header, which means that we only seem to be able to get a list of headers up to the last block we've actually validated, no higher. Have to add I don't know if that's intentional, of course, but it doesn't seem quite right.. at best the syncer should stop asking for more headers until it's caught up with processing what it already has |
|
after letting it run for a while, stop and restart, and it gets a new list of headers, and in this case won't be able to validate anything past block 806, (was was the last header processed) Syncing will stop at block 806, and won't continue until restarting, which indicates there's some count or something that's not being kept up to date and is only re-init upon restart. This is consistent with widespread reports of having to continually stop and re-start the server to sync. Indeed 806 is the last block we processed, and no further blocks will be requested until restart: |
|
So in the code now, first question: why can we not just return the last block we've validated as the locator? On the other peer side, the locator just reconciles to a block we have in common: We probably need to send a few to ensure we're finding a common block if there's a fork... Actually.. that may be the issue.. we're building that locator list based on the last block header height we've received rather than actual validated height. |
|
And indeed, spitting out that tip height: When only up to 54 has been validated. Surely we should be using 54 as our input to create the locator array? |
|
My evolving understanding of how this is supposed to work probably needs correction, so I'll wait for comment before digging much further. |
|
... other way around. The height is being pulled from the header chain to build the locator array, but the locator ids themselves are being pulled from the full chain... not looking at code now, but 99% this is the winner |
|
Think we have this now from yesterday's dicussions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Showing up in logs doing a full sync now, processing header 1 through 511 repeatedly on every single block validation.
Looks as if either the syncer keeps requesting the block headers, or someone keeps sending them to us without us asking
The text was updated successfully, but these errors were encountered: