Fix for disconnect causing instant loss

[ssk97]

For the past several months, users with somewhat spotty connections have sometimes experienced disconnects causing instant concessions with no chance to reconnect. Upon examination of server logs, it is seemingly entirely due to CLIENT DISCONNECTED.

I'm unsure as to why this is occurring, as the jboss documentation suggests that that the ClientDisconnectedException should only happen if the client does a normal client termination, but it has been consistent enough that I think it's worth putting this fix in.

[JayDi85]

It can broke normal disconnection without tables wait (player will be active and lock game for 5 minutes until lose by timeout).

[ssk97]

It can broke normal disconnection without tables wait (player will be active and lock game for 5 minutes until lose by timeout).

If the player quits normally then it should still go through the DisconnectedByUser path via removeListener, right?

[JayDi85]

Need tests (is it works or not). It’s important to test on real server (another machine) cause jboss uses diff logic for local client and server.

Just an idea: original problem in wrong lease timeouts — client wrongly catch broken connection status and try to close it (it’s use bisocket, e.g. both client and server keeps two depended connections and try to close another one on “fail”).

[JayDi85]

I’m stopped here.

Client side can auto-call disconnection on bad connection due failed pings:

Client side can auto-call disconnection on connection change due IP change:

P.S. There are also problems with hard coded pings and timeout settings (there are no tools to sync it between client and server).

[xenohedron]

I tested this today on the XDHS server (applying just this change on top of the tagged release from Feb 9, and building custom).

It works successfully to allow players to reconnect after network blips without getting kicked from their matches.

We also tested what happens on deliberate disconnect, and that does quit from active tables as intended.

It may be a good idea to add a comment in here explaining the workaround (to reduce confusion for future investigation), but this successfully addresses a critical bug without introducing other problems, so let's merge it.