This commit adds a goroutine watchChannelStatus to the server, which
will query the switch for the status of all open channels every
InactiveChanTimeout / 4. If a channel's status has remained unchanged
during the last InactiveChanTimeout it'll send out a ChannelUpdate
setting the disabled bit accordingly.
ProcessLocalAnnouncement will attempt to call UpdateEdge with the new
policy. If we call it manually before handing it to the gossiper, that
call will fail with "Outdated" and the announcement won't propagate.
This commit adds asynchronous starting of peers,
in order to avoid potential DOS vectors. Currently,
we block with the server's mutex while peers exchange
Init messages and perform other setup. Thus, a remote
peer that does not reply with an init message will
cause server to block for 15s per attempt.
We also modify the startup behavior to spawn
peerTerminationWatchers before starting the
peer itself, ensuring that a peer is properly
cleaned up if the initialization fails. Currently,
failing to start a peer does not execute the bulk
of the teardown logic, since it is not spawned
until after a successful Start occurs.
In this commit, we fix a small bug where we would increase epochErrors
by one even if connections were successfully established. Due to this,
we would stay stuck inside of the peer bootstrapper loop without
requerying for new peers.
In this commit, we move the initialization of the server into the
funding manager itself. We do this as it's no longer the case that _any_
RPC needs to access the funding manager. In the past, this was the
only reason that the funding manager was instantiated outside of the
server: to be able to respond to queries _before_ the server was
started.
This change also fixes a bug as atm, the funding manager will try to
register for notifications _before_ the ChainNotifier itself has fully
started.
In this commit, we modify the existing message sending functionality
within the fundingmanager. Due to each mesage send requiring to hold the
server's lock to retrieve the peer, we might run into a case where the
lock is held for a larger than usual amount of time and would therefore
block on sending the message within the fundingmanager. We remedy this
by taking a similar approach to some recent changes within the gossiper.
We now keep track of each peer within the internal fundingmanager
messages and send messages directly to them.
In this commit, we extend the server's functionality to prune link nodes
on startup. Since we currently only decide whether to prune a link node
from the database based on a channel close, it's possible that we have
link nodes lingering from before this functionality was added on.
In this commit, we update all the lncfg methods used to properly pass in
a new resolver. This is required in order to ensure that we don't leak
our DNS queries if Tor mode is active.
In this commit, we move the block height dependency from the links in
the switch to the switch itself. This is possible due to a recent change
on the links no longer depending on the block height to update their
commitment fees.
We'll now only have the switch be alerted of new blocks coming in and
links will retrieve the height from it atomically.
In this commit, we address an existing issue with regards to the inital
peer bootstrapping stage. At times, the bootstrappers can be unreliable
by providing addresses for peers that no longer exist/are currently
offline. This would lead to nodes quickly entering an exponential
backoff method used to maintain a minimum target of peers without first
achieving said target.
We address this by separating the peer bootstrapper into two stages: the
initial peer bootstrapping and maintaining a target set of nodes to
maintain an up-to-date view of the network. The initial peer
bootstrapping stage has been made aggressive in order to provide such
view of the network as quickly as possible. Once done, we continue on
with the existing exponential backoff method responsible for maintaining
a target set of nodes.
traversal
In this commit, we allow our node to automatically advertise its
connection's external IPs on the ports it is currently listening on in
order to accept inbound connections. This is only done when specifying
a NAT traversal technique when starting the daemon.
We also include a handy method that watches for dynamic IP changes in
the background. If a new IP is detected, we'll craft a new node
announcement using the new IP and broadcast it to the network.
In this commit, we finish the fix for the inbound/outbound peer bool in
the server. The prior commit forgot to also flip the inbound/output maps
in Inbound/Outbound peer connected. As a result, the checks were
incorrect and could cause lnd to refuse to accept any more inbound
connections in the case of a concurrent connection attempt.
In this commit, we ensure that if we're already ignoring a connection,
then we also ignore the pending persistent connection request.
Otherwise, we'll move to accept the replaced connection, but then
continue to attempt connection requests.
In this commit, we modify the look up for inbound peers to ensure that
we connect to the "freshest" address until we need to execute the
peerTerminationWatcher. We do this as it's possible for a channel to be
created by the remote peer during our session. If we don't query for the
node's address at the latest point, then we'll miss this new node
announcement for the node.
In this commit, we address the meaning of the inbound parameter to
peerConnected. An inbound connection is defined as a connection
initiated by the peer, rather than ourselves.
We also update the inbound value for the peerConnected calls within
OutboundPeerConnected and InboundPeerConnected to reflect the definition
above.
We remove the internale broadcastMessage method, and instead handle the
mutex handling within BroadcastMessage. This lets us hold the mutex only
when neccessary.
This commit removes the sendToPeer method from the server, and instead
moves the necessary logic into SendToPeer. This let's us make the mutex
acquisition more fine-grained, only holding it while reading from the
peer map. Earlier it was required to be held during the whole call to
sendToPeer, as the method would access the map internally.
