This commit modified the condition to whether drop an existing
connection to a peer when a new connection to this peer is
established.
The previous algorithm used public keys comparison for this decision
which determines that between every two nodes only one of them will
ever drop the connection in such cases.
The problematic case is when a node disconnects and reconnects in a
short interval which is the case of mobile devices.
In such case it takes as much as the "timeout" configured value for
the remote node to detect the "disconnection" (and try to reconnect
if this connection is persistent). In the case this node is also the
one that has the "smaller" public key the reconnect attempts of the
other node will be rejected causing it impossible to fast reconnect.
The solution is to only drop the connection if if we already have a
connected peer that is of the opposite direction from the this new
connection. By doing so the "initiator" will be enabled to replace
the connection and recconnect immediately.
In this commit, we also allow channel updates for our channels to be
sent reliably to our channel counterparty. This is especially crucial
for private channels, since they're not announced, in order to ensure
each party can receive funds from the other side.
In this commit, we implement a new subsystem for the gossiper that
uses some of the existing logic for resending channel announcement
signatures and implements it in a way to make it message-agnostic,
meaning that any type of message can be resent. Along the way we also
modify the way this works to prevent multiple goroutines per peer _and_
message.
A peerHandler will be spawned for each peer for which we attempt to send
a message reliably to. This handler is responsible for managing requests
to reliably send messages to a peer while also taking the peer's
connection lifecycle into account by requesting notifications for when
the peer connects/disconnects. A peer connection notification is first
requested to determine when we should attempt to send any pending
messages. After the messages are sent, a peer disconnection notification
is requested to ensure we don't continue to request connection
notifications while the peer remains connected. Once there are no more
pending messages left to be sent for a given peer, the peerHandler can
be torn down.
In this commit, we introduce a migration for the message store
sub-bucket that will migrate all keys within it to a new key format.
This new key format is composed of the peer's public key, followed by
the short channel ID, followed by the message type. This migration is
needed in order to provide backwards-compatibility with messages that
were previously stored before the introduction of the new key format.
In this commit, we add a new store within the database that'll be
responsible for storing gossip messages which we need to reliably send
to peers. This aims to replace the current messageStore that exists
within the gossiper, so much of this logic is borrowed from there.
One of the main differences between the two is that we now index
messages with a new key format in which we take into account the
message's type. This allows us to store different messages for a
specific channel with a peer. The old key format is still supported in
order to prevent a database migration.
Exposes the three parameters that dictate
the behavior of the channel status manager:
* --chan-enable-timeout
* --chan-disable-timeout
* --chan-status-sample-interval
ScoreSettable is an interface that let caller set external scores for
the heuristic. The ExternalScoreAttachment and WeightedCombAttachment
heuristics implement this interface.
This commit adds a method SetNodesScores to the WeightedCombAttachment
heuristic.
Since the heuristic keeps a list of sub-heuristics, it will attempt to
recursively apply the scores to the sub heuristics.
This commit adds a new autopilot heuristic that is scoring based. It is
a simple heuristic that will keep a list of pubkeys and scores, and will
try opening channels with the nodes with the largest score first.
In this commit, we update all the `btcsuite` dependencies, along with
neutrino to their latest version. The main change in this version is a
bug fix in the way that we generated the filters that neutrino uses. As
a result, any users running btcd with neutrino today will need to
**regenerate their filter chain** using `--dropcfindex`. Any existing
neutrino clients out there will also need _re sync_ all together as the
"correct" filter header chain.
