This commits changes the behavior of our connection
reestablishment, and resolves some minor issues that
could lead to uncancelled requests or an infinite
connection loop.
- Will not attempt to Remove connection requests with
an ID of 0. This can happen for reconnect attempts
that get scheduled, but have not started at the
time the server cancels the connection requests.
- Adds a per-peer cancellation channel, that is
closed upon a successful inbound or outbound
connection. The goroutine spwaned to handle the
reconnect by the peerTerminationWatch now
selects on this channel, and skips reconnecting
if it is closed before the backoff matures.
- Properly computes the backoff when no entry in
persistentPeersBackoff is found. Previously, a
value of 0 would be returned, cause all subsequent
backoff attempts to use a backoff of 0.
- Cancels a peers retries and remove connections
immediately after receiving an inbound connection,
to mimic the structure of OutboundPeerConnected.
- Cancels all persistent connection requests after
calling DisconnectPeers.
- Allow additional connection attempts to peers, even if
there already exists a pending connection attempt.
In this commit, we fix an existing bug within the codebase: if a peer
connected to us inbound, then we'd attempt to use the assigned port when
re-establishing a connection to them. We fix this issue in this commit
by adding a new method to look up any advertisements for the peer, and
use the specified port that matches our connection attempt. If we can't
find a proper advertisement, then we'll simply use the default peer
port.
In this commit we modify the storage location of the sphinx replay
database to be under the precise network, and not only the graph sub
directory. Before this commit, due to the usage of filepath.Dir(), the
db would lie under /graph/, rather than say, /graph/simnet.
This commit adds an backoff policy to the peer termination
watcher to avoid getting stuck in tight connection loops
with failing peers. The maximum backoff is now set to 128s,
and each backoff is randomized so that two instances using
the same algorithm have some hope of desynchronizing.
This commit adds the `lnnet` package which contains an
implementation of the newly created LightningNet interface which
multiplexes the Dial and DNS-related functions to use net
by default and torsvc if a flag is specified. This modularization
makes for cleaner code.
This commit adds a new interface named NetInterface and two
implementations of it: RegularNet & TorProxyNet. These two structs
are used in config.go in an attempt to clean up the code and
abstract away the dialer and DNS functions.
This commit adds a new module named 'torsvc' which houses all Tor
functionality in an attempt to isolate it and make it reusable in
other projecs. Some additional tweaks were made to config.go and
to the bootstrapper.
This commit adds Tor support. Users can set the --TorSocks flag
to specify which port Tor's SOCKS5 proxy is listening on so that
lnd can connect to it. When this flag is set, ALL traffic gets
routed over Tor including DNS traffic. Special functions for
DNS lookups were added, and since Tor doesn't natively support
SRV requests, the proxySRV function routes connects us to
a DNS server via Tor and SRV requests can be issued directly
to the DNS server.
Co-authored-by: MeshCollider <dobsonsa68@gmail.com>
A recent commit modified the mutex in the server to the read/write. In
order to further reduce contention, we’ll grab the read lock when we’re
examining get set of peers to ignore.
This commit aims to reduce the contention on the server's primary
mutex by (1) replacing it with a RWMutex, and (2) not holding an
exclusive lock throughout the duration of the SendToPeer method.
For the latter, we now only have to hold a shared lock until all
messages have been queued, where as before an exclusive lock
was held until all messages had been acknowledged by the target
peer's write handler. Since the initial syncing of announcements
with peer now comprises a couple thousand messages on testnet,
these changes should help keep the server from deadlocking while
completing and long-lived syncing operations.
In this commit, we modify the way that notifications are dispatched
within the chainWatcher. Before we would *always* wait for an ack back
before we started to clean up he database state. This would at times
lead to deadlocks. To remedy this, we now allow callers to decide if
they want notifications to be sync or not. The only current caller that
requires this is the breach arbiter.
In this commit, we add the IsOurAddress field into the config of the
chain arb. With this new function closure, the chain arb is able to
detect co-op on chain closes automatically.
In this commit, we modify the breach arbiter to no longer require
holding a channel object directly in order to receive new notifications
about possible breaches. Instead, we’ll contact the chain arbiter to
request a new channel event subscription.
As a result of the new architecture, we no longer need to receive a
handoff once the new channel comes online, as the chainWatcher will
always be active and watching the channel until it’s been closed.
Peers are treated as transient by default. When a peer is disconnected,
no attempt is made to reconnect. However, if we have a channel open
with a peer that peer will be added as persistent. If a persistent peer
becomes disconnected then we will attempt to reconnect.
This behavior implies that a fresh node - those without any channels -
will fall off the network over time as remote nodes restart or due to
connectivity changes. This change marks bootstrap peers as persistent
and ensures that the node remains connected to those specific peers over
time. This does not keep the node connected in the case that all
bootstrap peers are down.
Fixes#451.
In this commit, we modify the Broadcast to take a *set* of peers to
skip, rather than just a single peer. We make this modification as when
a new channel is discovered, it’s likely the case that we get the
announcement from several peers rather than a single peer. With this
change, we’ll ensure that the caller (who is aware of the set of
senders) is able to properly avoid wasting bandwidth by re-sending the
message to all peers that sent it to us originally.
This commit fixes a deadlock that could occur when
a peer disconnected during a call to sentToPeer. In
This particular case, a message would successfully
be queued, the peer would shutdown, and we would
block waiting for an error to be returned on the
message's error channel, which would deadlock.
This fixes that by also checking for peer shutdown.
This commit reorders logic in the peer termination
watcher such that we short circuit earlier if we
already have pending persistent connection requests.
Before, the debug statement may have indicated that
a reconnection was being attempted, even though it
may have exited before submitting the request to
the connection manager.
In this commit, we fix an existing bug that would cause funding
transaction to be broadcast without any fees attached at all. This is
only an issue if the fee rate reported is extremely so, as can happen
on testnet. In this case, when we went to scale down to sat/weight, we
would return a value of zero due to integer division. If we went via
the EstimateFeePerWeight call directly, then it would've been detected.
However, we accept the fee/byte from the user directly on the command
line this wasn't being done.
To fix this, we'll now manually set the fee to a sane value, if it
returns a value that can't properly be scaled to fee/weight.
