Reconnection attempt failing - what to do?

jonc · Post by **jonc** » 15 Sep 2011, 04:54

Hi, we're trying to handle disconnects more gracefully in our game using a Flash client. I've read about the HRC and how it should reconnect automatically. In our server config, I've set:

<userReconnectionSeconds>60</userReconnectionSeconds>
<overrideMaxUserIdleTime>90</overrideMaxUserIdleTime>

So, according to my understanding, this should reconnect automatically if possible within 60 seconds and then disconnect the user if no response is received from them in 90 seconds.

I'm testing this by disabling my network connection on the client. What happens is this:

- The client immediately detects a dropped connect.
- It receives a CONNECTION_RETRY event.
- It then immediately receives a CONNECTION_LOST event.

Although it listens for CONNECTION_RESUME, it never gets this event, even if the network connection is immediately restored.

On the server side, things seem to be handled correctly in that the USER_DISCONNECT event isn't fired until after about 90 seconds.

What do I need to do to make the reconnect happen? Should I try to reconnect manually in response to the CONNECTION_LOST event? Is there something else I should be configuring in the client to make it try to reconnect automatically?

We're using the Bits Connector object to make the initial connection. Does this perhaps affect what's going on?

Thanks for any help!

Post by **Lapo** » 19 Sep 2011, 05:55

How do you exactly disable/enable the connection? Can you explain?
What server and client API are being used? (Please be specific on the API too)

jonc · Post by **jonc** » 19 Sep 2011, 06:25

Hi Lapo,

Thanks for the reply.

I'm disconnecting by disabling the network adapter (Windows 7). I then immediately re-enable it after the client detects the dropped network.

We're using 2.0.0-RC1b and the Flash API from that build.

- Jon.

Post by **Lapo** » 19 Sep 2011, 06:47

Sorry I probably missed your initial steps.

- The client immediately detects a dropped connect.
- It receives a CONNECTION_RETRY event.
- It then immediately receives a CONNECTION_LOST event.

In this case it won't work, sure. Now I get it.
You turn off the network and then turn it on again but the API are much faster than you. They find no connectivity at all and fail, causing a full disconnection.

In the real world we would expect that your network is congested or your ISP has temporary hiccups. This is what happens:

1- Disconnection: API detect the problem and fire a new connection
2- The underlying OS TCP stack attempts the connection... due to the congestion you need to wait 15 seconds before the new connection is established
3- Connection is up again: CONNECTION_RESUME event is fired

The problem with your test is that you remove the whole network physically. This is not supported and there's no real use case for this.

Hope it helps

Post by **Lapo** » 19 Sep 2011, 06:49

Let me add 2 quick things:

1) If you want to test the disconnection/reconnection events use the API killConnection() method

2) We recommend to upgrade to version RC3. A few improvements have been added to HRC.

jonc · Post by **jonc** » 19 Sep 2011, 07:03

Thanks again Lapo.

I will test with killConnection(). Am I right in saying that if one experienced a network dropout due to a faulty internet connection or problems at the ISP one would expect an automatic reconnection if the glitch is resolved within the <userReconnectionSeconds> period?

We'll also upgrade to RC3.

Post by **Lapo** » 19 Sep 2011, 07:42

Yes, because when the new connection is attempted the OS will wait for the other end to respond, while if you remove the network card from the OS it will generate an error immediately... since no network resource is attached to the system.

jonc · Post by **jonc** » 20 Sep 2011, 00:07

Hi Lapo, this all seems to be working well now, at least when testing with killConnection(). It will be interesting to see how well it handles actually network disruptions.

thanks,

- Jon.