-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1.0.1] P2P: syncing fix #671
Conversation
…ext_chunk() if sync_last_requested_num > 0 as a request was likely just made.
…plicable when no blocks are being received.
plugins/net_plugin/net_plugin.cpp
Outdated
@@ -2485,6 +2483,7 @@ namespace eosio { | |||
return; | |||
} | |||
c->latest_blk_time = std::chrono::system_clock::now(); | |||
sync_active_time = std::chrono::steady_clock::now(); // reset when we receive a block |
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.
You can do sync_active_time = c->latest_blk_time = std::chrono::system_clock::now();
to guarantee they are all the same.
Looks like |
Note:start |
Note:start |
Two small P2P syncing fixes:
sync_last_requested_num
is 0 as that case is handled in the first part of theif
. If we do request a new range, request from a potentially different peer. Noticed that in practice it would often stick to its current peer here as this would be the first time it realized it needs a new range of blocks.sync_active_time
when a block is received. Noticed this "timer" was firing simply because it was taking too long to apply the blocks. I was testing withsync-fetch-span
of 5000.steady_clock
for stopwatch functionality.Resolves #670