Skip to content

Conversation

ariard
Copy link

@ariard ariard commented Oct 16, 2020

This is a simple functional test to increase coverage of #19988, checking that txid announcements from txid-relay peers are delayed by TXID_RELAY_DELAY, assuming we have at least another wtxid-relay peer.

You can verify new test with the following diff :

diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index f14db379f..2a2805df5 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -773,7 +773,7 @@ void PeerManager::AddTxAnnouncement(const CNode& node, const GenTxid& gtxid, std
     auto delay = std::chrono::microseconds{0};
     const bool preferred = state->fPreferredDownload;
     if (!preferred) delay += NONPREF_PEER_TX_DELAY;
-    if (!gtxid.IsWtxid() && g_wtxid_relay_peers > 0) delay += TXID_RELAY_DELAY;
+    //if (!gtxid.IsWtxid() && g_wtxid_relay_peers > 0) delay += TXID_RELAY_DELAY;
     const bool overloaded = !node.HasPermission(PF_RELAY) &&
         m_txrequest.CountInFlight(nodeid) >= MAX_PEER_TX_REQUEST_IN_FLIGHT;
     if (overloaded) delay += OVERLOADED_PEER_TX_DELAY;

@DrahtBot DrahtBot added the Tests label Oct 16, 2020
Copy link
Member

@sipa sipa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

Linter error: test/functional/p2p_segwit.py:14:1: F401 'test_framework.messages.msg_verack' imported but unused

@ariard ariard force-pushed the 2020-10-txid-delay-test branch from 637d7a1 to f0fe840 Compare October 17, 2020 15:29
@ariard
Copy link
Author

ariard commented Oct 17, 2020

Thanks, updated at f0fe840. See if this comment needs further modification.

self.nodes[0].setmocktime(mock_time + TXID_RELAY_DELAY)
peer.wait_until(lambda: peer.tx_getdata_count >= 1, timeout=1)
with p2p_lock:
assert_equal(peer.tx_getdata_count, 1)
Copy link
Member

@naumenkogs naumenkogs Oct 19, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wait until right above wouldn't allow this line to happen if tx_getdata_count == 0. So we're checking it's NOT more than 1? Is it a worthy check?... It has nothing to do with delays.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeh, testnode wait_until grabs p2p_lock so this is redundant with L233

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, in fact it sounds other new functional tests added with #19988 have a redundant p2p lock tacking so added a new commit to remove this oversight. Unless @MarcoFalke they serve something else ?

mock_time = int(time.time() + 1)
self.nodes[0].setmocktime(mock_time)
peer = self.nodes[0].add_p2p_connection(TestP2PConn(wtxidrelay=False))
# Add a second wtxid-relay connection otherwise TXID_RELAY_DELAY is waived in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps also worth testing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a test mutation.

peer.sync_with_ping()
with p2p_lock:
assert_equal(peer.tx_getdata_count, 0)
self.nodes[0].setmocktime(mock_time + TXID_RELAY_DELAY)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't NONPREF_PEER_TX_DELAY also be applied here?

Anyway, I'd first jump in NONPREF_PEER_TX_DELAY to see that it's not enough time passed, and then jump TXID_RELAY_DELAY again to see that enough time passed? I think that's what is supposed to happen..

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The positive case was already tested in test_preferred_inv but added a mutation to cover the negative one, i.e applying NONPREF_PEER_TX_DELAY on non-preferred peers.

@naumenkogs
Copy link
Member

Concept ACK

Copy link
Member

@glozow glozow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

self.nodes[0].setmocktime(mock_time + TXID_RELAY_DELAY)
peer.wait_until(lambda: peer.tx_getdata_count >= 1, timeout=1)
with p2p_lock:
assert_equal(peer.tx_getdata_count, 1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeh, testnode wait_until grabs p2p_lock so this is redundant with L233

peer.sync_with_ping()
with p2p_lock:
assert_equal(peer.tx_getdata_count, 0)
self.nodes[0].setmocktime(mock_time + TXID_RELAY_DELAY)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this supposed to test that the node waits for the duration of TXID_RELAY_DELAY? Seems like it just confirms that the node doesn't send a getdata immediately, then sends it ~TXID_RELAY_DELAY later? I had imagined making TestP2PConn record the time at which it receives getdatas, then asserting that the time difference from sending the inv is at least TXID_RELAY_DELAY... don't think it could use setmocktime though so idk

Copy link
Author

@ariard ariard Oct 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can achieve this with current p2p framework, we can write to the mocktime but can we read it from it ? A quick look, I don't find test doing it so not sure that's a feature of our current test framework. Note that was already the way done by legacy (pre-#19988) tx-download tests. But lmk if there is way to do so I don't see

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't find test doing it so not sure that's a feature of our current test framework

Yeah, I haven't seen an example either. The way I'd do it is just use sleep() instead of setmocktime... 2 seconds isn't too bad when the tests are running in parallel, but fosho not ideal.

@maflcko
Copy link
Member

maflcko commented Oct 21, 2020

ACK f0fe840

@ariard ariard force-pushed the 2020-10-txid-delay-test branch from f0fe840 to c55ce67 Compare October 22, 2020 13:32
@ariard
Copy link
Author

ariard commented Oct 22, 2020

Thanks @naumenkogs, @glozow for reviews, updated addressing your comments at c55ce67

@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 28, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Copy link
Member

@jonatack jonatack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approach ACK. Verified the new test does fail per the PR description.

@bitcoin bitcoin deleted a comment from BARMOLEY007 Nov 1, 2020
Antoine Riard added 4 commits November 2, 2020 18:29
Its usage is extended beyond p2p_segwit.py in next commit.
Add a simple functional test to cover TXID_RELAY_DELAY as applied
as a TxRequestTracker parameter in AddTxAnnoucement.
Add a booelan arg to test_preferred_inv to cover NONPREF_PEER_TX_DELAY
as applied as a TxRequestTracker parameter in AddTxAnnouncement.
New functional test coverage of tx download was added by bitcoin#19988,
but `with p2p_lock` is redundant for some tests with `wait_until`
test helper, already guaranteeing test lock tacking.
@ariard ariard force-pushed the 2020-10-txid-delay-test branch from c55ce67 to bc4a230 Compare November 2, 2020 23:37
@ariard
Copy link
Author

ariard commented Nov 2, 2020

Thanks @jonatack. I think I took everything at bc4a230

@ariard
Copy link
Author

ariard commented Dec 10, 2020

@naumenkogs @jonatack @glozow @MarcoFalke if you have few minutes to review again this PR, it hasn't changed and I think all previous considerations have been addressed.

@laanwj
Copy link
Member

laanwj commented Dec 16, 2020

ACK bc4a230
Thanks for adding a test for this.

@laanwj laanwj merged commit 5b6f970 into bitcoin:master Dec 16, 2020
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Dec 17, 2020
bc4a230 Remove redundant p2p lock tacking for tx download functional tests (Antoine Riard)
d3b5eac Add mutation for functional test test_preferred_inv (Antoine Riard)
06efb31 Add functional test test_txid_inv_delay (Antoine Riard)
a07910a test: Makes wtxidrelay support a generic P2PInterface option (Antoine Riard)

Pull request description:

  This is a simple functional test to increase coverage of bitcoin#19988, checking that txid announcements from txid-relay peers are delayed by TXID_RELAY_DELAY, assuming we have at least another wtxid-relay peer.

  You can verify new test with the following diff :

  ```
  diff --git a/src/net_processing.cpp b/src/net_processing.cpp
  index f14db37..2a2805df5 100644
  --- a/src/net_processing.cpp
  +++ b/src/net_processing.cpp
  @@ -773,7 +773,7 @@ void PeerManager::AddTxAnnouncement(const CNode& node, const GenTxid& gtxid, std
       auto delay = std::chrono::microseconds{0};
       const bool preferred = state->fPreferredDownload;
       if (!preferred) delay += NONPREF_PEER_TX_DELAY;
  -    if (!gtxid.IsWtxid() && g_wtxid_relay_peers > 0) delay += TXID_RELAY_DELAY;
  +    //if (!gtxid.IsWtxid() && g_wtxid_relay_peers > 0) delay += TXID_RELAY_DELAY;
       const bool overloaded = !node.HasPermission(PF_RELAY) &&
           m_txrequest.CountInFlight(nodeid) >= MAX_PEER_TX_REQUEST_IN_FLIGHT;
       if (overloaded) delay += OVERLOADED_PEER_TX_DELAY;
  ```

ACKs for top commit:
  laanwj:
    ACK bc4a230

Tree-SHA512: 150e806bc5289feda94738756ab375c7fdd23c80c12bd417d3112043e26a91a717dc325a01079ebd02a88b90975ead5bd397ec86eb745c7870ebec379a8aa711
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants