Manage bad network disconnections

[Tatanan]

Hi.

In case cases, Smartfoxserver doesn´t manage bad disconnection or abrupt disconnection.
Some or this cases are unplug network wire, some error in proxies or a device that is sharing 3g with other devices and loses mobile signal.
I understand that in some extreme cases socket protocol can not send a connection close to the extension so Sfs doesn´t know that the connection is lost. (I have read http://forums.smartfoxserver.com/viewto ... 7716#17716).
To prevent that situations, in some special rooms that is very important to avoid this issues we have created a scheduleAtFixedRate Task that sends a message to all user rooms and
if in the next iteration of the Schedule Task some user haven´t response we manually this connect that user from the server.

The problem comes when trying to Kick users that have lost connection abruptly server can´t disconnect them.

We have tried this actions:

• extension.sfsApi.kickUser(player, null,"Connection Lost Abruptly", 1);

• extension.sfsApi.disconnectUser(player);

• extension.sfsApi.disconnect(player.getSession());

• Manually kick user in the Admin Tool

Any of this actions had any affect, the user where connected and inside the Room, and rest of users were not notified.

After some some test, finally we could handle this by adding: extension.sfsApi.logout(player) before extension.sfsApi.kickUser(player, null,"Connection Lost Abruptly", 1);

Is this a bug on Smartfoxserver or are we using sfsApi in the wrong way? why have I to logout a user before disconnecting him?

It is important to us manage not standard disconnections in some cases. We are aware that unplug ethernet wire doesn´t happen often but sharing 3g connection via Smartphone or
mobile router is becoming relative often.

Thanks.

[Lapo]

Hi.

In case cases, Smartfoxserver doesn´t manage bad disconnection or abrupt disconnection.
Some or this cases are unplug network wire, some error in proxies or a device that is sharing 3g with other devices and loses mobile signal.

Just to be clear... SmartFoxServer doesn't manage those if the underlying TCP stack doesn't. In other words it's the OS' own TCP stack that is responsible for notifying applications about the state of a connection.
In the case of the unplugged network cable that you have mentioned the OS still maintains the connection open as if nothing had happened and if you plug the cable back you will be able to transmit data without problems.

To prevent that situations, in some special rooms that is very important to avoid this issues we have created a scheduleAtFixedRate Task that sends a message to all user rooms and
if in the next iteration of the Schedule Task some user haven´t response we manually this connect that user from the server.

The problem comes when trying to Kick users that have lost connection abruptly server can´t disconnect them.

We have tried this actions:

• extension.sfsApi.kickUser(player, null,"Connection Lost Abruptly", 1);

• extension.sfsApi.disconnectUser(player);

• extension.sfsApi.disconnect(player.getSession());

• Manually kick user in the Admin Tool

Any of this actions had any affect, the user where connected and inside the Room, and rest of users were not notified.

After some some test, finally we could handle this by adding: extension.sfsApi.logout(player) before extension.sfsApi.kickUser(player, null,"Connection Lost Abruptly", 1);

Is this a bug on Smartfoxserver or are we using sfsApi in the wrong way? why have I to logout a user before disconnecting him?

No I don't think it is a bug. Kicking or disconnecting both attempt to close the socket. If the socket is in half-closed state it's likely that the action won't trigger the TCP disconnection which in turn triggers the server's own clean up process.

By logging out you're forcing the clean up process, at least at the server level while the socket will probably continue to stay in half-closed state until the TCP stack fires a timeout.

So what you're doing is working around the missing TCP events, and removing the lingering user.

It is important to us manage not standard disconnections in some cases. We are aware that unplug ethernet wire doesn´t happen often but sharing 3g connection via Smartphone or
mobile router is becoming relative often.

Managing network switches from 3G to Wifi etc... is quite tricky.
Normally we recommend to detect the change via the specific iOS/Android events, closing the current connection and starting a new one after the connection switch is done. This usually the most clean way to avoid problems, although it may need to save the state of the game to restore it on the next connection. If done correctly it can be transparent for the user.

hope it helps

[Tatanan]

Yes, I know Smartfoxserver doesn´t manage the TCP layer. I apologize if my explanation sounds that smartfoxserver is responsible of TPC issues. I know it depends on SO to detect network problems.

But the truth is that issues are happening in production because SO can not detect some network problems, Ios/Android TCP events some times are not enough, that´s why we want to protect business logic from that.

For this reason, we thought an extension solution with our own timeout. We don´t know if it is the best solution. But for the moment seems that it works.
About the differences about logout-disconnect-kick, we thought that disconnecting a user makes logout+close-connection, now I think it is clear.

So to confirm, disconnecting a user does not log him out, so if we want to "disconnect" a half-closed user (at server level, not network level) before ghost-hunter close its connection we could log the user out, right?

Thanks.

[Lapo]

Yes, I know Smartfoxserver doesn´t manage the TCP layer. I apologize if my explanation sounds that smartfoxserver is responsible of TPC issues. I know it depends on SO to detect network problems.

No problem, just wanted to clarify where the problem is.

Code: Select all

But the truth is that issues are happening in production because SO can not detect some network problems, Ios/Android TCP events some times are not enough, that´s why we want to protect business logic from that.

You may try by activating the LagMonitor in the API, by calling SmartFox.enableLagMonitor() after the Login event. This will send a ping-pong request every 4 seconds (very light in terms of network usage). If you have a client in half-connected state it may help triggering the TCP timeout.

Let me know if it helps.

So to confirm, disconnecting a user does not log him out, so if we want to "disconnect" a half-closed user (at server level, not network level) before ghost-hunter close its connection we could log the user out, right?

Yes this is correct.

cheers