error message 'No sync peer candidates available' when 7 are available #138
Comments
|
There is a possibility all 7 others were loading the blockchain, but my upload bandwidth did not show very much data being sent after the 74.103.125.183 peer was lost. |
|
Thanks for the report. I'll look through it, but my first thought is that it might be the fact that the other nodes are not yet known to be at the same block height as the current height, so it doesn't see them as valid sync peer candidates. |
|
this behavior is reproducible. This log shows it happened again. |
|
Yep I know what the issue is. I've marked it as bug. We'll get it fixed. Thanks for the reconfirm. |
|
As an update to this, I've been busy with higher prio tickets, but I'll put the issue here in case somebody else gets to it first. In short, when a peer connects, it reports its height. This information is then used to disqualify peers that are lower than your current height as sync peers since they don't have blocks you need. However, there are no further updates to the height after initial connect. Thus, your local height eventually overtakes the static height in the peer which disqualifies it as a sync candidate. The correct fix here would be to not rely on the reported height at all since the remote peer could lie about their height anyways. |
|
I just installed btcd as a bitcoind replacement. Full sync took 26 hours which is great. Seems rather more efficient in CPU and memory than bitcoind also which nice. As soon as the sync was completed I'm getting continous new peers connecting and then disconnecting similar to the above issue (log below). Is this common for all or does it only occur in certain situations? Just wanted to confirm if this would be causing 'bad behaviour' on the network as I don't want to be causing any issue for other nodes. But if it's not going to be an issue for others then no problem. 16:25:17 2014-09-17 [INF] BMGR: Processed 1 block in the last 10m24.02s (620 transactions, height 321187, 2014-09-17 16:24:53 +0000 UTC) |
|
That's normal. There are a lot of programs out there (seeders, network mappers, etc.) that inbound to full nodes but are not full nodes or SPV wallets themselves. For example, that getaddr.bitnodes.io peer you saw is what powers the website by the same name: https://getaddr.bitnodes.io/ |
|
That is normal. Look at the node user agents. They are network mappers, seeders, etc. They connect up to gather statistics, then disconnect. You'll see them reconnect periodically (typically every few minutes) as well. |
…to-fix-bug-that-happens-here-and-there addrmgr: fix testing bug that happens here and there
I have observed an interesting log message which may be indicative of a bug. When btcd connects to the first node, it starts syncing to it. It then connected to 7 other nodes. All notes are from outbound connections. It gets all the blocks then loses connectivity to the first node. It complains that it cannot sync the blockchain, because there are no peer candidates available, even though it is connected to 7 others. Only after it connects to a new node does it claims to restart syncing.
This is running from the latest commits as of today.
Feel free to close this if it is expected behavior.
The text was updated successfully, but these errors were encountered: