The algorithm here is important and took some time to get right. Instead
of comparing whether the current number of connected nodes minus the
number of unevictable nodes is greater than the number of max
connections, check that:
* there are any evictable nodes (connected nodes minus unevictable
nodes)
* there are more nodes connected than requested (connected nodes minus
max connections)
While we could wait for nodes to disconnect organically, it's more
important to run the eviction logic frequently enough that we can tell
when it will have an effect.
Whitelisted connections and protected inbound connections are
unevictable, and max connections should account for inbound connections.
Because the evictor will never evict protected inbound connections, the
maximum connection count should always be at least as large as the
protected connection count.
Note that the tests for this use a delay and test that the delay has not
expired. This helps improve determinism in the testing. Otherwise, a
strict test for a fixed number of disconnections is susceptible to
things like CPU jitter, especially when running through CI.
Patrick ran this test for 1000 runs on busy CPUs and saw no failures.
This uses the constant in src/net.h for the minimum allowed number of
connections.
The limit of new max connections is silently capped to the number of
available file descriptors. This value is not exposed in the UI or
RPC messages so as not to leak interesting or important system details.
The floor of maximum connections is set to the number of connections
required for this node to operate.
This makes the best attempt to reduce the number of connections by
reusing the eviction logic. This reuses the core of that algorithm at
the expense of deterministic behavior. In other words, starting with a
max connections value of 125 and then changing the max connections to 3
does not mean that this will immediately evict 122 connections.
Eventually the number of connections will reduce to the limit.
While the body of the condition will add latency to network processing,
the integer comparison between max connections and size of the
connections vector should be quick in most cases.
Note the extraction of connection disconnect/delete helpers so as to
reuse the same logic in multiple places. While this may not be strictly
necessary for the algorithm, it reduces the possibility that this entire
loop will get stuck doing busy work when trying to evict connections to
get under the maximum threshold.
This change separates the `make translate language=...` and `make
translate_base` Makefile targets. The former is useful for translators
and the latter for core developers.
This change also rearranges flags to `lupdate` to improve utility for
both cases.
Finally, this change also documents these targets and gives more advice
on how to use them.
Ubuntu's libgcc-9-dev-arm64-cross on focal is broken: it misses
patch 8c92fcb13a4979232787f0476bf7469ccbb03617 that fixes a
mismatched "extern C" block in arm_acle.h.
We provide the patched header file in src/compat and include a
selector for it. Whenever we detect GCC 9.4, we include the
imported header rather than the system provided, broken header.
This patch can be reverted when Ubuntu has fixed
libgcc-9-dev-arm64-cross.
Current REST API always returns empty UTXO when invoked without
`/checkmempool/` URL part.
Cherry-picked from: bitcoin/bitcoin 9cb9af8c
Conflicts: limited scope to only the QA test, as rest.cpp
implementation is incompatible with Dogecoin 1.14
The chain-only view from pcoinsTip was only assigned when the user
queried inclusive of mempool, but when queried without, the view
only contained an empty dummy.
This fixes issue #2530 by running the `lupdate` and then reviewing the
strings. What is done is 1. replacing references to Bitcoin with Dogecoin,
2. fixing some minor typos and 3. translating some of the new strings (like tips)
- Check SDK shasum to protect against supply-chain attacks
- Don't re-download the SDK archive when we have it in cache
- Purge the cache when the CI configuration changes
Changes the fallback dependency source repository from Bitcoin's
bitcoincore.org to dogecoincore.org. Both are centrally hosted,
as a fallback. Ideally this would be utilizing a decentralized
protocol like IPFS, but this is harder to integrate with the CI
tooling.
Note: because some dependencies have identical filenames in their
source URLs (currently ds_store and mac_alias) we host the target
filename on the mirror, to prevent conflicts.
