Parallel block download #1326
Parallel block download #1326
Conversation
…iding them disappears. Conflicts: .gitignore src/main.cpp src/net.cpp src/net.h Conflicts: src/main.cpp src/net.h
There was a problem hiding this comment.
If i don't add this line, git complains. How do you manage without git wanting this directory added or ignored?
There was a problem hiding this comment.
Sorry, I'm no GIT master :-/. But I never had a pull or commit, where I needed to include .gitignore.
There was a problem hiding this comment.
Strangely, i can't add .gitignore to .gitignore. It ignores that line!
TODO: Deal with stuck downloads so the same block can be downloaded by another node. Perhaps keep count of the re-asks. Log these. Conflicts: src/main.cpp src/net.h
|
I haven't had a chance to review this yet— though I see you are using GetNumBlocksOfPeers()... It's perfectly possible for nodes to send insane values for the heights and some have done so. It should be treated as untrustworthy. This function is currently only used in the GUI... and I think it should probably stay there. At the very least every caller needs to give consideration to the possibility that a majority of your peers may be malicious and may give values chosen to make your day maximally bad. |
|
I've closed this pull for now, as it was opened for comments, but it's not ready to pull. It still needs: 1) stuck management, and 2a) either a separate AskFor function for txs and blocks, as as it's currently written, it'll getdata the same tx from many nodes at the same time, or 2b) the same treatment of txs, i.e. don't download the same tx from another peer. 2b isn't so ideal as it will produce more getdatas as with the way it's written, it'll only have 1 inv per every getdata. This is ok for blocks (IMHO), but perhaps not so suitable for txs, so I'd be inclined to go with 2a rather than 2b. Feedback much appreciated. @gmaxwell, re your last comment, no worries, it's not finished anyway, so perhaps it's better to wait until I've completed bits 1 and 2a first - although your comments on whether 2a or 2b or 3c (something else) are suitable would be welcome. Re CaughtUp() not being reliable. Well, true, but if one is connected to misbehaving peers such as this, then one'd (!) probably not want to be downloading from them anyway. The reason I created CaughtUp() is so that it can be refined to be more reliable. It serves a different purpose to IsInitialDownload() from what I've been told by others that that function is for. I do think CaughtUp(), based on your comments above, does need refining given the risk you mention. Perhaps it can factor in the timestamp of the last block received also as a sanity check. |
|
rebroad@f11b01d is an update of this pull request, and for some reason has "detached" from this pull request, so I'll have to raise another for this commit once I've done enough testing.... |
* Add missing alert functionality * add alert test generation * re-enable alerts by default
…in mint checks 803f5dd [Trivial] Single method ScriptSigToSerializedSpend (random-zebra) dc0cc41 [Cleanup] Remove CoinSpend dependancy from CTxIn (random-zebra) 935c99c [Cleanup] Remove unused IsSerialKnown function in zpivchain.* (random-zebra) 1493473 [Cleanup] Remove CheckZerocoinMint main function (random-zebra) Pull request description: This is built on top of - [x] bitcoin#1322 This removes `CheckZerocoinMint` (mints are disabled since block 1,686,229 and we can rely on checkpoints during IBD). Also does some minor cleanup in zpivmodule/zpivchain ACKs for top commit: furszy: Looking good, utACK 803f5dd Fuzzbawls: ACK 803f5dd Tree-SHA512: 5fe1c835ff95330be32561ca12e1c29cb46404be68f4ca7caf2e3e5c51ff9364ead8bc781284e3c49dc0bd5efac28d3f24a901e92e3cc0d4b7af17b2146eaf50
3 participants
Builds upon pull #1271, which fixes Issue #1234.
This allows multiple peers to provide blocks, not just one. Up to 8 peers can provide blocks in parallel, thereby increasing block download speed by up to 8.
Submitted for comments. I think ideally I'll add some more code to cater for stuck downloads, so it can give up and move onto another peer. Currently, it'll only move onto another peer if the selected peer disconnects. It a peer took a long time to disconnect, then all blocks downloaded would be orphans until the missing block was eventually downloaded.
Also, the "8" concurrent downloads is hard-coded, would people prefer this to be a configurable command-line option?