HRC and Disconnection Difficulties

Post here your questions about the Unity / .Net / Mono / Windows 8 / Windows Phone 8 API for SFS2X

Moderators: Lapo, Bax

amateur
Posts: 29
Joined: 07 Jun 2017, 07:18

HRC and Disconnection Difficulties

Postby amateur » 10 Sep 2018, 23:41

Hi, studied this in detail and still coming a bit unstuck.

Using the Advaned Connector sample, Unity and server 2.13 with client 1.7.8.

I understand the folly of testing by disconnecting the Ethernet cable for testing...

However, what I'm getting (when, say, WiFi connection is briefly lost) is:

1. Client (eventaully) detects that it is not connected and retries the connection n times. WiFi is restored after a few seconds.

2. Server always logs a "Server Reconnection Failure" (due to timeout, even if only a few seconds. This does not happen if I use sfs.KillConnection)

3. Despite the server reconnection not working, the Client behaves as though it has reconnected successfully, even continuing to report lag monitor etc.


What I want to be able to do is to detect that the server has rejected the reconnection attempt (on the client) so that I can shut down the client connection and try again. I can set a timer checking sfs.IsConnected every 2 seconds or so but if I disconnect based on this then effectively HRC is disabled.

I hope I've explained this properly, thanks for your help.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: HRC and Disconnection Difficulties

Postby Lapo » 11 Sep 2018, 08:08

Hi,
is this an actually reproducible case?
The problem with a temporary lost Wifi is that it's not a deterministic event. In other words if you have 10 different instances of brief Wifi interruptions you could find 10 different network states (maybe less, but it can really get quite complicated over the internet).

This depends on many variables, such as the cause of the hiccup and which side of the communication is aware of it, which in turn can result in half-disconnected states, which are difficult to recover from because they don't trigger the disconnection on both sides.

HRC attempts to solve the disconnection issues where possible, i.e. where both sides of the communication acknowledge the disconnection.
(which is the definition of a disconnection). The other cases, can or cannot be recovered depending on the underlying OS timeout settings.

For instance if the client TCP stack takes 10 minutes to timeout a half-disconnected socket there will be no reconnection attempts because no disconnection event gets triggered until that timer is over.

Hope it helps
Lapo
--
gotoAndPlay()
...addicted to flash games
amateur
Posts: 29
Joined: 07 Jun 2017, 07:18

Re: HRC and Disconnection Difficulties

Postby amateur » 11 Sep 2018, 08:37

Hi

Yes, I can reproduce this lots of times, on 2 separate servers.

I have set the zone reconnection timeframe to 60, and the overrided max idle time to 120.

I'm not expecting the client to successfully connect: the server correctly detects a reconnection attempt and logs that the reconnection attempt has failed. The problem is that the client does not know that the reconnection attempt failed. OnConnectionRetry isn't being triggered, nor is OnConnectionLost.

I could turn on lag monitor, and shut down the client connection after not receiving pingpong messages after nn seconds.

Somehow, if the client is sending a reconnection request and it is rejected, the client should be able to tell that it has been rejected.

I hope this is clear, thanks for your help.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: HRC and Disconnection Difficulties

Postby Lapo » 11 Sep 2018, 08:47

amateur wrote:I'm not expecting the client to successfully connect: the server correctly detects a reconnection attempt and logs that the reconnection attempt has failed. The problem is that the client does not know that the reconnection attempt failed. OnConnectionRetry isn't being triggered, nor is OnConnectionLost.

You mean SFSEvent.CONNECTION_RETRY event on client side is not triggered and yet a reconnection request is fired anyways?
Are you sure you've added a listener for that event?

Thanks
Lapo

--

gotoAndPlay()

...addicted to flash games
amateur
Posts: 29
Joined: 07 Jun 2017, 07:18

Re: HRC and Disconnection Difficulties

Postby amateur » 11 Sep 2018, 09:13

Hi, thanks, the retry is being triggered when it first retries, but there is no acknowledgement that the retry has failed. In other words, if the reconnection is successful, it triggers CONNECTION_RESUME, but if it fails (and the server logs that it has failed), it does not trigger CONNECTION_LOST. Instead, it continues to go through all of the connection attempts until the client times out.


Logically, the server "knows" the client reconnection has been attempted and failed, but the client thinks it is still connected. If the server rejects the reconnection, I'd expect the client to be able to detect that rejection.


In practice, it means that you can have clients who think they're connected to the server but actually have lost connection. Since sfs returns True for "IsConnected" and the lag monitor reports start again, the client just thinks it's still connected, or that the resume was a success.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: HRC and Disconnection Difficulties

Postby Lapo » 11 Sep 2018, 14:45

amateur wrote:Hi, thanks, the retry is being triggered when it first retries, but there is no acknowledgement that the retry has failed. In other words, if the reconnection is successful, it triggers CONNECTION_RESUME, but if it fails (and the server logs that it has failed), it does not trigger CONNECTION_LOST. Instead, it continues to go through all of the connection attempts until the client times out.

You should get the CONNECTION_LOST either when the new connection fails or when the timeout goes off. I am confused as to why this doesn't happen.

Can you describe how this is reproducible?


Logically, the server "knows" the client reconnection has been attempted and failed, but the client thinks it is still connected. If the server rejects the reconnection, I'd expect the client to be able to detect that rejection.

Technically it's the client that must handle the disconnection event, simply because the new connection has been refused.
There is no message from the server side saying, "sorry you could not reconnect". It's not needed and it would simply play into an attacker's strategy of wasting server resources.

Thanks
Lapo

--

gotoAndPlay()

...addicted to flash games
amateur
Posts: 29
Joined: 07 Jun 2017, 07:18

Re: HRC and Disconnection Difficulties

Postby amateur » 11 Sep 2018, 15:16

How to reproduce:
1. Start the Advanced Connector (first updating the client DLL to 1.7.8)
2. Turn ON the Lag Monitor toggle
3. Click CONNECT. You get messages in the debug about connection being successful, then every few seconds it reports the lag e.g. "Measured lag is 60ms"
4. After a few minutes, turn off the WiFi on the client device. As expected, both client and server still think the connection is active. The lag reports stop on the client, but it keeps sending a PingPong message. As expected.
5. After several seconds, the client device will start reporting socket errors and will attempt to reconnect. At this point, turn the WiFi back on.
6. The server notices the reconnection attempt and rejects it (as expected), though it does not close the original session
7. The client does not detect that the reconnection has failed (but also doesn't report it as reconnected either), but leaves sfs.IsConnected true and starts reporting the lag reports again.

From the client perspective, it behaves as though the reconnection has been successful and never disconnects. The server eventually times out the session but the client never knows about this.

The effect is a user who thinks they have a connection to the server but they don't.

Many thanks
amateur
Posts: 29
Joined: 07 Jun 2017, 07:18

Re: HRC and Disconnection Difficulties

Postby amateur » 11 Sep 2018, 15:52

As a workaround, I could detect the reconnection attempt, then set a timeout for say 15 seconds, to check whether there has been a "resumed" event. If not, forcibly disconnect. Not elegant but might work. Can you think of any drawbacks?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: HRC and Disconnection Difficulties

Postby Lapo » 12 Sep 2018, 08:12

Is there a way in Unity to detect the device's WIFI state?
Under native SDKs you can do it, and if Unity does too it is probably the best idea. Listen for a WIFI on/off event. When it goes down, shut down the current connection and wait until it comes back on to create a new SmartFox object and connect again.

I am not too sure about your workaround, I think it need to be tested to see if it works. The WIFI detection is probably the safer way.

Cheers

p.s. = a similar case has been discussed here -> https://smartfoxserver.com/blog/handlin ... e-devices/
Lapo

--

gotoAndPlay()

...addicted to flash games
amateur
Posts: 29
Joined: 07 Jun 2017, 07:18

Re: HRC and Disconnection Difficulties

Postby amateur » 12 Sep 2018, 09:24

Thanks for your help.

According to SmartFox documentation referring to "SFSEvent.CONNECTION_RESUME", it's not behaving as it should. "When this event is dispatched the application interface should be reverted to the state it had before the disconnection. In case the reconnection attempt fails, the CONNECTION_LOST event is fired."

What I'm demonstrating is that this does not happen. Either CONNECTION_RESUME is triggered when it succeeds, or nothing at all happens. CONNECTION_LOST is never triggered.

I don't know if it helps but I notice that if the client remains off the network, it will fail after the timeout (i.e. retry # 10 or whatever). The "problem" I'm having is when the network connection is resumed during the attempts, it stops retrying and behaves as though it has reconnected to the server.

I agree that there are O/S triggers, but WiFi detection presents a few problems: 1) lots of different platforms and versions of platforms handle these things differently for different connection methods (so it's a lot of work), 2) depending on how sensitive these are, may interrupt the "normal" HRC behaviour.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: HRC and Disconnection Difficulties

Postby Lapo » 12 Sep 2018, 11:14

I hear what you're saying about the CONNECTION_RESUME mechanism. Back to your step-by-step description:

6. The server notices the reconnection attempt and rejects it (as expected), though it does not close the original session

This is correct. The server needs to detect the client's former connection to be closed in order to switch state and expect a reconnection.
A reconnection attempt without a prior disconnection is discarded, otherwise the client state will be lost.
When the connection is lost the player's Session is "frozen" and all updates are accumulated in a queue and re-sent later when the new connection is established (provided the player is able to reconnect).

7. The client does not detect that the reconnection has failed (but also doesn't report it as reconnected either), but leaves sfs.IsConnected true and starts reporting the lag reports again.

We should be able to improve this side of the event system, if we disconnect immediately the failed reconnection attempt and handle that on the client. We'll have to investigate this further by reproducing your use case.

I'll post an update when we have a clearer picture.
Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X C# API”

Who is online

Users browsing this forum: No registered users and 39 guests