You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@kilrau Are both nodes being restarted at the same time? Consider the following situation:
Node A connects to Node B and advertises a listening connection.
Node B is shut down.
Node B comes back online but no longer accepts incoming connections.
4A. (Current behavior) Node B reconnects to Node A using the advertised address from step 1.
4B. (Proposed behavior) The nodes will not reconnect.
I'm wondering what is the downside of having potentially two connection attempts in a case like this. The second one should fail gracefully due to the nodes already being connected, if not that seems like the real issue.
See my comments on #1145 for more details about my concerns.
Thank you @sangaman for your input. What you said makes a lot of sense and I think we shouldn't restrict connection attempts to outbound connections only.
Even though originally we did not intend to re-connect to advertised URIs we never connected to before, now with TOR this behavior is actually desirable (since probability of advertised URIs being reachable is high) and this improves reconnections as per @sangaman description above. No need to change anything.
Background
xud
-level P2P reconnections are attempted from both sides of a former p2p connection.Your environment
xud
: latest masteruname -a
on *Nix): ubuntu 18btcd
,bitcoind
,ltcd
,litecoind
,geth
,parity
,raiden
,lnd
or other chain backend:Steps to reproduce
Connect two xud instances via manual connect on xud level. Restart both instances with e.g. network off and watch both instances trying to reconnect.
Expected behaviour
Only the connection initiator tries to reconnect
Actual behaviour
Both peers try to reconnect
The text was updated successfully, but these errors were encountered: