The preivous usage of two channels - by piping them together to create a
semaphore effect, is difficult to follow and prone to bugs. This commit
now refactors the method to explicitly implement a semaphore.
Prior to this change, we would allow at max 3 concurrent goroutines -
this is now bumped to 5.
In this commit, we refactor the v2 -> v1 downgrade logic to: simplify
the code in the server for reconnection, use a functional option to
avoid breaking the connmgr API, and we also encapsulate the downgrade
state in a new struct so it can be re-used elsewhere.
When ShouldDowngradeToV1() returns true, we'll:
- mark in pendingReconnects that we should attempt v1 bitcoin p2p transport
when the connmgr successfully re-establishes the outbound TCP connection.
- set a bit on the associated *serverPeer that will cause us to tell the
connmgr to reconnect. This is needed because not all outbound peers are
permanent and we might otherwise not reconnect to them if the initial v2
transport negotiation failed.
commit 0b2998b7f279d3aef4d83415dae26948f5a6bdf4
Author: cec489 <173723251+cec489@users.noreply.github.com>
Date: Mon Jun 24 20:01:13 2024 +0000
A cleaner fix is to set the startTime in the server Start() function
which is where the server is actually started.
commit ae6c1256981befb43972e83a086ea663df629873
Author: cec489 <173723251+cec489@users.noreply.github.com>
Date: Mon Jun 24 19:15:23 2024 +0000
Fix the btcctl uptime command by moving the setting of startupTime
This change is part of the effort to add utxocache support to btcd.
utxo cache is now used by the BlockChain struct. By default it's used
and the minimum cache is set to 250MiB. The change made helps speed up
block/tx validation as the cache allows for much faster lookup of utxos.
The initial block download in particular is improved as the db i/o
bottleneck is remedied by the cache.
This change is part of the effort to add pruning support to btcd.
Pruning is now available to the end user via --prune flag. There are
checks in place so that the user doesn't go below the minimum prune
target of 1536 MiB. The minimum is set so that we keep at least 288
blocks per the requirement for NODE_NETWORK_LIMITED nodes specified by
BIP0159. The default value of 0 will disable pruning.
This change is part of the effort to add pruning support to btcd.
Wire now supports the ability to signal NODE_NETWORK_LIMITED which
signals to peers that the node is able to serve the last 288 blocks.
Since archival nodes have all blocks, they can also signal for
NODE_NETWORK_LIMITED. SFNodeNetworkLimited flag is added to the default
services.
In this commit, we update all the btcutil imports to point to the new
sub-module.
In the same commit, we also modify the recently added `btcutil/go.mod`
file as we need to continue pointing to the _old_ version of btcd, until
we merge this PR and push a new tag.
In this commit, we add a new config options that allows one to start
`btcd` in an operating mode that disables the stall detection. This can
be useful in simnet/regtest integration tests settings where it's
important that `btcd` holds on to its possibly sole connection to the
only other node in the test harness.
A new config flag has been added to gate this behavior, which is off by
default.
backport from https://github.com/decred/dcrd/pull/2253
When a peer sends a notfound message, remove the hash from requested
map. Also increase notfound ban score and return early if it
disconnects the peer.
This addresses an issue where the server ends up tracking a peer that
has been disconnected due to it processing a peer's `done` message
before its `add` message.
This was previously done within the OnVersion listener, which should not
be a blocking operation. It turns out that requesting these messages
there can lead to blocking due to peers not being able to process
messages since their message queues have yet to start. Therefore, we'll
now request within handleAddPeerMsg, which should allow it to go
through.
This change is needed as part of requiring peers to also send a verack
message following their version message during protocol negotiation.
Peers were previously added to the SyncManager before their message
queues were started, causing the server to stall if a peer didn't
provide a timely verack response following their version. We now do this
within OnVerAck, which happens shortly before peer message queues are
started.
This makes the logic a bit more unified as previously it was possible we
for us to report the new peer to the SyncManager, but for whatever
reason failed to track the peer in the server internally within AddPeer.
This change ensures this can no longer happen.
Doing so ensures we reach our target number of outbound peers as soon as
possible. This is only necessary after calls to connmgr.Remove, as these
won't request a new peer connection.
The Disconnect method would still attempt to reconnect to the same
peer, which could cause us to reconnect to bad/unstable peers if we came
across them. Instead, we'll now use Remove whenever we intend to remove
a peer that is not persistent.
We do this to ensure the address manager contains live addresses.
Previously, addresses with which we established connections with would
not be marked as connected because it would be done once we disconnect
peers. Given that we don't process all of the disconnect logic when
we're shutting down, addresses of stable and good peers would never be
marked as connected unless the connection was lost during operation.
This modifies the OnVersion handler for server peers to use a local
variable for the remote address of the peer in order to avoid grabbing
the mutex multiple times.
There are no functional changes.
Backported from Decred.
This changes the server peers OnVersion handler to only advertise the
server as a viable target for inbound connections when the server
believes it is close the best known tip.
Backported from Decred.
This modifies the OnVersion handler for server peers to use a local
variable for the inbound status of the peer in order to avoid grabbing
the mutex multiple times.
While here, it also does some light cleanup. There are no functional
changes.
Backported from Decred.
This adds code to update the address manager services for a known
address to the services advertised by peers when they are connected to
via an outbound connection. It is only done for outbound connections to
help prevent malicious behavior from inbound connections.
Backported from Decred.
This modifies the OnVersion callback to allow a reject message to be
returned in which case the message will be sent to the peer and the peer
will be disconnected.
Backported from Decred.
This modifies the negotiation logic to ensure the callback has the
opportunity to see the message before the peer is disconnected and
improves the error handling when reading the remote version message.
It also has the side effect of ensuring the protocol version is
negotiated before sending reject messages with the exception of the
first message not being a version message since negotiation is not
possible in that case.
This is being changed because it is useful for the server to see the
message regardless in order to have the opportunity to things such as
update the address manager and reject peers that don't have desired
services.
Backported from Decred.
In this commit, we fix a panic bug that can arise when we attempt to
process a cf checkpoint message from a remote peer. Before this commit,
if the size of the checkpoint cache was large than the number of
checkpoints requested by the peer, we would panic with an out of bounds
error. In order to prevent, this we'll now use the size of the requested
set of hashes as our bound to ensure that we don't panic.
In this commit, we modify the locking scheme when serving cf checkpoints
for peers to allow the server to serve multiple peers at the same time.
Before this commit, we would first grab the write lock, check to see for
expansion, then release the read lock. In this commit we reverse this
and instead will grab the read lock, and upgrade to the write lock if we
need to actually expand the size of the cache.
