smartfoxserver.com

The problem is you should put a filter on the captured packets otherwise you'll be looking for the proverbial needle in the haystack
In the text field at the top you should add:

or whatever port you're using for the server. Then Apply the filter. This is the easy part.

Then you have to go through the packets and look for the reconnection attempt. It's not so difficult because you will see in the TCP data the header of the client. If you're using Unity you will notice a string containing the Unity player ID.
e.g. "UnityPlayer::"

Right, after some extensive testing it seems this is an Android only issue. I've tested the game on PC, Mac, iPad and iPhone and the wifi disconnection issue doesn't affect the game, it happily carries on whether HRC is on or not. But on the four Android devices we have, the same thing happens on every device, (all different types and versions of Android): instant CONNECTION_LOST with HRC turned off, and when HRC is turned on it hangs as we've been talking about.

For what it's worth this is what Wireshark says on the PC laptop on wifi, just those four retransmission entries, although as I said, the game does not seem to have a problem on PC.

Thanks for reporting.
It makes a lot of sense that HRC doesn't matter here because the case scenario you have described should be handled at a much lower level of the protocol stack (TCP). Of course different OSes come with different implementations and, as you discovered, they all not behave in the same way.

Cheers

So in this scenario HRC can't reconnect it, but implementing it makes the user experience worse as no further events are called client-side as opposed to CONNECTION_LOST being called straight away without it. And I don't know whether HRC has any effect on Android or whether I'd potentially making everyone's disconnection experiences worse?

A little experimentation is required on every platform, as each one comes with its own quirks.
In general HRC will not work if the lower level TCP mechanisms fail, which seems to be the case for the Android test you have done.

Then is it possible to enable or disable HRC client-side so I can toggle it per platform?

Also, the docs says

CONNECTION_RESUME: this event is notified when the reconnection is successful. In case the reconnection fails a SFSEvent.CONNECTION_LOST event will be sent instead.

It's not doing either of these. As you say, something has gone wrong with the TCP mechanism and it's not in a proper reconnection phase but HRC is causing it to do something differently as I get different experiences with it on and off.

At the moment this is not "officially" supported, but I believe you might succeed with a bit of hacking.
You first need to establish a successful connection and then reset the reconnection timer by calling sfs.SetReconnectionSeconds(0) where sfs is whatever your SmartFox API instance is called.

It's not doing either of these. As you say, something has gone wrong with the TCP mechanism and it's not in a proper reconnection phase but HRC is causing it to do something differently as I get different experiences with it on and off.

Yes, I thought I was clear enough in my previous posts.
It is the same as saying that if the sensors of your house alarm (TCP) don't detect an intrusion the siren (HRC) won't go off and someone might be able to get inside undetected.
In other words HRC relies on accurate event dispatching from the TCP stack. Should this fail, it's expected that HRC might fail too.