In the IRI `Node` class, this code segment checks to see if the requested transaction hash is the same as the received transaction hash: 

https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/network/Node.java#L284


    //Request bytes    
    //add request to reply queue (requestedHash, neighbor)
    Hash requestedHash = new Hash(receivedData, TransactionViewModel.SIZE, reqHashSize);
    if (requestedHash.equals(receivedTransactionHash)) {
         //requesting a random tip
         requestedHash = Hash.NULL_HASH;
    }


How is it possible for the request hash to be part of the received transaction hash since the received transaction hash is not known until the transaction is made?

Perhaps I am missing some detail - can someone please explain the purpose of this.


----------


History of This Code Segment
============================

After the first submitted answer below, and after Come_From_Beyond made some comments, I did some digging to see the commit history of this code.

According to the earliest available commits for the  `Node` class, when the transaction hash and the requested hash were the same, the request was to be the Milestone that is requested. Perhaps someone can shed some light on why this existed like this and why it was changed.

**Oct 24, 2016 - If the requested hash is same, then return a Milestone**
https://github.com/iotaledger/iri/blob/5db789222fabd11a9880b457b2b9f24cd783789f/src/iri/Node.java#L90



    if (Arrays.equals(requestedTransaction, receivedTransaction.hash)) {
        transactionPointer = Storage.transactionPointer(Milestone.latestMilestone.bytes);
    } else {
        transactionPointer = Storage.transactionPointer(requestedTransaction);
    }

**Dec 23, 2016 - Introduces Concept of 'Experimental Random Tip Broadcaster'**
https://github.com/iotaledger/iri/blob/577f2ad2db561a4044cbf9a81beae15da599d2ab/src/main/java/com/iota/iri/service/Node.java#L201

    if (Arrays.equals(requestedTransaction, receivedTransaction.hash)) {
        if (Configuration.booling(DefaultConfSettings.EXPERIMENTAL) &&
            ++randomTipBroadcastCounter % 3 == 0) {
            // see code re "Experimental: Random Tip Broadcaster"
        } else {
            transactionPointer = StorageTransactions.instance()
                .transactionPointer(Milestone.latestMilestone.bytes());
        }
    } else {
        transactionPointer = StorageTransactions.instance().transactionPointer(requestedTransaction);
    }

**Jan 29, 2017 - Compare changed to NULL HASH and other changes to scheme**
https://github.com/iotaledger/iri/blob/61ad77be4ce01ee1cc8530320f7c234ee660c822/src/main/java/com/iota/iri/service/Node.java#L205

(truncated for brevity)

    if (Arrays.equals(requestedTransaction, Hash.NULL_HASH.bytes())) {
        if (randomTipBroadcastCounter % 9 == 0) {
            // see code "Random Broadcaster - latestMilestone index==0."
        }
        else if (randomTipBroadcastCounter % 6 == 0) {
            // see code re Milestone
        }
        else if (randomTipBroadcastCounter % 3 == 0) {
            // see code "Random Broadcaster - random tip."
        }
    } else {
        transactionPointer = StorageTransactions.instance().transactionPointer(requestedTransaction);
    }


----------


The Role of `P_MILESTONE TO SELECT` and the `TransactionRequester`
==================================================================

The actual actions of the transaction to request are further obfuscated by the last minute code block before transmission in `Node`.

See https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/network/Node.java#L483

    synchronized (sendingPacket) {
        System.arraycopy(transactionViewModel.getBytes(), 0, sendingPacket.getData(), 0, TransactionViewModel.SIZE);
        Hash hash = transactionRequester.transactionToRequest(rnd.nextDouble() < P_SELECT_MILESTONE);
        System.arraycopy(hash != null ? hash.bytes() : transactionViewModel.getHash().bytes(), 0,
                sendingPacket.getData(), TransactionViewModel.SIZE, reqHashSize);
        neighbor.send(sendingPacket);
    }


By default, `P_MILESTONE_TO_SELECT` is set to 70%, and this tells the `transactionRequester` to use a Milestone if any are found in the `milestoneTransactionsToRequest` queue.

See https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/network/TransactionRequester.java#L90

This further obfuscates the actions of a request, although a little  investigation will find that during validation, if any trunk or branch is found to be a Milestone, then it is added to `transactionsToRequest`. And also, if the [LedgerValidator thread also finds any missing Milestones][1], they too are added to the `transactionsToRequest` queue.

This complicates the logic of a requested transaction quite a bit as it turns out that a requested transaction of either (1) an identical hash or (2) NULL_HASH, has the effect of not `//requesting a random tip` as the comments in `Node` imply, but of an elaborate process of preferring a Milestone if one is missing from the system.

From what I can tell of the effect of the `LedgerValidator`, all tips are checked during the routine `Milestone.java` checking thread `Solid Milestone Tracker` and when the `LedgerValidator` is called, missing Milestones are inventoried and queued to receive priority treatment within the system.

**I suppose this begs the question ...**

How often is a Milestone missing from the system? That determines, ultimately, what a requested transaction actually requests.


[1]: https://github.com/iotaledger/iri/blob/dev/src/main/java/com/iota/iri/LedgerValidator.java#L69