During the initial headers download, a client may start to request the same headers multiple times from its syncing peer. This happens if a new block is found while the peer is syncing, for the following reason:

For the ordinary headers syncing procedure, the client starts by asking for an initial set of headers, and then whenever it receives a message with 2,000 headers, it follows up with a request for more. However, if a new block is found, its peer sends a corresponding inv message, which prompts the syncing client to also ask for the headers preceding the new block. This requests the same headers again, and when they are received a second time, it continues requesting more. Depending on how many new blocks are found and how long the header syncing lasts, this may lead to a situation where the same set of headers is requested many times.

This obviously puts unnecessary strain on both the client that syncs and the peer that sends the data. This is a problem particularly for altcoins with either of a high block frequency or merge-mining (much larger header messages), but it happens with Bitcoin itself as well.

To fix it, we could keep (in-memory only) for each peer the highest "from" height for which we requested headers from it. Whenever a new request would be sent with a smaller number, we drop it instead. Alternatively, one could probably also make the logic for requesting headers following an inv message smarter, so that it does not request when we are in the initial headers sync. What do you think? I'm willing to implement a patch for whatever solution is suggested.