Reconnect from same IP fails if there's only one active client. about kcp-go HOT 13 CLOSED

I wonder if this fixes the bug I am hunting down, with being unable to reconnect after disconnect.

from kcp-go.

it's a bug if the client immediately reconnect from the same address:port tuple

from kcp-go.

Sure, it only happens when the client uses the same port. In my case, it does.

from kcp-go.

Not really, again p2p case, the client will always reconnect from the same tuple if it performs STUN.
I know KCP doesn't handle that, as to this day I am chasing a bug that prevents us from enabling it in syncthing.

from kcp-go.

@univac490 I assume you are doing something p2p. Do you have connection issues if you start A, start B, they connect, then restart B, in our case connections from B get refused as we still think we have an active one, yet once Bs connection timeout on A (using smux), any attempt from B to connect to A or A to B fails with smux io timeouts.

from kcp-go.

@AudriusButkevicius, I'm still experimenting with KCP. I have a server and a client running on the same machine. I also have a client on a different machine. Both clients behave the same. I don't have any issues reconnecting after the connection times out (I'm also using smux).

from kcp-go.

Do you do something clever like Dial via the listening connection etc (requited for NAT punch through)

from kcp-go.

I'm using this https://github.com/jbenet/go-reuseport

from kcp-go.

is this problem fixed in the recent commits?

from kcp-go.

Yes, should be.

from kcp-go.

So this now exposes a different problem.

If you have 1 client and 1 server, and the client restarts, the packets from the server make it look like connect attempts on the client. In the end you end up with 1 listen socket on each end (no dial sockets).

What's worse is if you have short lived dial connections (for example you connect, but the other end refuses you for some reason and disconnects), the same problem is exhibited with these dial connections which become server side connections on both sides.

Even if you hit timeouts and close connections, it seems that other end doesn't get the close message (smux) in time or something and these phantom conversations are resurrected forever.

from kcp-go.

@AudriusButkevicius it's too hard to understand, can you elaborate this problem by examples?
is it due to your recent commits?

from kcp-go.

It's not due to recent commits, it's a fundamental problem with KCP due to it not having control message

I think this is what happens:

A dials to B, they connect. B is the listener.
A restarts for some reason (crash whatever).
Packets from B related to the old connection reach A after restart
A assumes it's a new connection, creates the connection in listen mode.
Both A and B end up with listen mode connections.
A fails on smux accept (as we get random packets that are not handshake)
A probably sends something back on conn.Close,
B receives the packets, resets smux timeout/keepalive
B tries to match the packet but it's a rogue handshake it doesn't understand hence discards it.
B sends smux keepalive
Goto step 3.

I had to do this to work around it: https://github.com/AudriusButkevicius/kcp-go/commit/54928af49abc3a4e5b645f42466a56cebc4a941e

from kcp-go.