Reconnect only for outgoing peers

[offerm]

Seen this on test2 server:

12/6/2018, 3:19:45 PM [P2P] error: peer error (03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7e5bb): Peer (03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7
e5bb) is stalling (56169410-f96a-11e8-ac3d-4f02ea5221a6)
12/6/2018, 3:19:45 PM [ORDERBOOK] debug: removed all orders for peer 03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7e5bb
12/6/2018, 3:19:45 PM [P2P] debug: closing socket with peer 03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7e5bb. reason: ResponseStalling
12/6/2018, 3:19:45 PM [P2P] debug: attempting to reconnect to a disconnected peer 03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7e5bb
12/6/2018, 3:19:45 PM [P2P] warn: could not open connection to peer (03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7e5bb): could not connect to peer at 127.0.0.1:9885: c
onnect ECONNREFUSED 127.0.0.1:9885
12/6/2018, 3:19:45 PM [P2P] info: Peer 03d2a862f7198143e96a08797e79c2ad86a09ee7a98494860cb1b9d73732c7e5bb socket closed
12/6/2018, 3:19:45 PM [P2P] debug: Connection attempt #1 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 5 sec...
12/6/2018, 3:19:50 PM [P2P] debug: Connection attempt #2 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 10 sec...
12/6/2018, 3:20:00 PM [P2P] debug: Connection attempt #3 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 20 sec...
12/6/2018, 3:20:20 PM [P2P] debug: Connection attempt #4 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 40 sec...
12/6/2018, 3:21:00 PM [P2P] debug: Connection attempt #5 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 80 sec...
12/6/2018, 3:22:20 PM [P2P] debug: Connection attempt #6 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 160 sec...
12/6/2018, 3:25:00 PM [P2P] debug: Connection attempt #7 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 320 sec...
12/6/2018, 3:30:20 PM [P2P] debug: Connection attempt #8 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 640 sec...
12/6/2018, 3:41:00 PM [P2P] debug: Connection attempt #9 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 1280 sec...
12/6/2018, 4:02:21 PM [P2P] debug: Connection attempt #10 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 2560 sec...
12/6/2018, 4:45:01 PM [P2P] debug: Connection attempt #11 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 3600 sec...
12/6/2018, 5:45:01 PM [P2P] debug: Connection attempt #12 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 3600 sec...
12/6/2018, 6:45:01 PM [P2P] debug: Connection attempt #13 to peer (127.0.0.1:9885) failed: connect ECONNREFUSED 127.0.0.1:9885. retrying in 3600 sec...

We should eliminate such reconnection.

[moshababo]

That's how it was implemented according to this proposal.
If you have a different idea on how to do it, let's discuss it here.

[offerm]

I'm not sure how this is related to the link.

The problem is that we try to connect to localhost:9885 but there is no XUD listening on it.
Somehow we got wrong information, we failed to validate it and we are using it.

Let's agree that it is wrong and find a way to fix it.

[moshababo]

I thought you’re referring to the multiple connection attempts.

From what the logs tell, we’re reconnecting after we disconnected due to ResponseStalling, and we’re applying connection retries on it. If the peer was outbound, it’s the address we were connected to. If it was inbound, it’s the first address from his advertised addresses list.

What from these do you find problematic?

[offerm]

XUD2 does not have and never had xud process running on port 9885.

Yet, the connection retry is done on (127.0.0.1:9885).

I'm not saying that there is a problem with the connection mechanism, but let's agree that there is a problem if the outcome is that xud2 is trying to connect to wrong host/port.

[moshababo]

Did XUD2 advertised 127.0.0.1:9885 address?

[offerm]

Never.

…

On Mon, 10 Dec 2018 at 14:33 Moshe Shababo ***@***.***> wrote: Did XUD2 advertised 127.0.0.1:9885 address? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#739 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJQ0ckEQi_4v_8AldphV2JHQz0G0HRhaks5u3lSagaJpZM4ZHMSL> .

[moshababo]

Then i'll need steps to reproduce.

[offerm]

A connects to B.
A advertise that it listens on 127.0.0.1:9885
connection between A and B dropped

Result:
B will try to connect to A using 127.0.0.1:9885

[offerm]

As I suggested before - since the advertise addresses are not reliable we better not try to reconnect an incoming connection. Incoming connection may also fail for other reasons (FW, NAT, etc).