Does each peer prioritize inv(type=block) over inv(type=tx)?

Question

I found that when a peer receives an inv message with type=block, it will immediately request that block or that block's headers with a getdata message or getheaders message. But if the peer receives an inv message with type=tx, it won't respond immediately. For example:

Node A  inv(tx)      Node B  |  Node A  inv(block)  Node B
        <-----------         |          <---------
                             |
        [delay]              |          [no delay]
                             | 
        getdata(tx)          |          getdata(block)
        ----------->         |          --------->

Why is there a delay in requesting transactions but not a delay in requesting blocks? I'm guessing that relaying a transaction is less important than getting the most recent block to ensure the node is on the consensus best block chain.

Answer 1

I don't see any delay here. Looking at Bitcoin Core 0.9.3's code, I also don't see any code which would cause a delay as long as the node sending the inv responded to a getdata message immediately.

Transactions and blocks are placed into to separate queues in this code:

if (!fAlreadyHave) {
    if (!fImporting && !fReindex) {
        if (inv.type == MSG_BLOCK)
            AddBlockToQueue(pfrom->GetId(), inv.hash);
        else
            pfrom->AskFor(inv);

Transactions and blocks are requested in this long piece of code, which I won't paste here.

I don't see any delays here for transaction requests. I also tested this locally, and my node always immediately replied to a new inv message (type=tx) with a getdata message requesting that transaction.

There can be a delay in relaying transactions. For example: node A sends an inv message for a new transaction to node B. Node B gets the transaction, but then waits before sending an inv message to node C announcing that transaction. You can see that in this code which includes the comment, "trickle out tx inv to protect privacy".