The way Bitcoin core handles this (at least in the latest version) is
to first download all the block headers, which is reasonably fast and
not as sensitive to delays. Then, once they have a full chain, they
start fetching the individual blocks and storing them in whatever
order they arrive.

I realize that your data structures probably work best when the blocks
are in a particular order, so maybe create an "incoming block queue"
for blocks 2, 3, 4, 5, 6, which then get validated and stored once
block 1 actually arrives. You know which block is which because you
already have the headers.

-William

On Tue, Jan 6, 2015 at 4:13 AM, Amir Taaki <genjix@???> wrote:
> https://github.com/libbitcoin/libbitcoin-node/blob/master/src/poller.cpp#L155
>
> What do you think is a good way to rate limit "getblocks" requests?
>
> The problem with this is that if you have blocks 1, 2, 3, 4, 5, 6, ...
> and if block one is delayed then blocks 2, 3, 4, 5, 6, ... will all be
> orphans sending multiple "getblocks" requests flooding the other node.
>
> Also if there are connections that drop often, then the current check
> will stop new "getblocks" requests to be issued causing the blockchain
> to fall behind.
>
> There needs to be a newer more robust way of allowing getblocks requests
> without allowing a flood of requests caused by many orphan blocks.
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin