According to the log the reason of alarm was “Too many connection tries” - this follows a red communication banner, and some 7 squares turning red after each connection try, all this replacing the normal, green arrows at the top. The session timeout was still at 171 seconds when this happened.
I can only reproduce this by manually turning off the wifi - I really don’t know why your phone is losing the communications, but the app is undoubtedly experiencing this.
Fortunately now that this is something you can reliably reproduce, we can try to know more and hopefully find a solution or workaround.
a) will try to get more information about the failures (anything that android reports about the comms)
b) will keep trying to reconnect for ever - meaning until the watchdog expires, that is, 300 secs
Please note I’ve not made it nice - once the 7 squares become red, they’ll keep red, only changes in the screen should be the timeout going down. But it will be trying to connect, once per second.
If the watchdog or the session timeout reach 0, the session will be closed.
I hope this helps, your collaboration in this is highly appreciated.
I ran a test of 100 frames. Comms failed on frames 36, 60, 71, 89, and 100. All recovered eventually. 71 recovered quickly. 89 and 100 were about 2 minutes recovery. 36 and 60 where longer than 71 but shorter than 89 and 100. There may have been other errors that I didn’t see.
I don’t know what is happening but this is way too may errors for what is a solid connection between the PC and phone.
in that I agree with you, but I’m afraid the problem really looks like external to the app.
By the way, the link for the logs gives me an error, I’d very much like to take a look, could you please check?
My best guess is either you have another wifi in a conflicting channel, causing the temporary dropouts, or a hardware issue. But I can’t tell.
I am however fairly confident the problem is not in the app, not only because I’m unable to reproduce it (and believe me I’ve tried), but because that would mean it is unusable - and there are many people running it with no issues.
The unfortunate fact of software development is when your app is not working it is your problem no matter what the cause. Here is a new link: Dropbox - File Deleted
Specially if you refer to the lack of (proper) support from the OS vendors, I totally agree. And customer perception, mostly, too.
Thanks for the logs.
What I’m seeing are mostly timeouts, but in some cases, if the conditions lasts more than 25 or so seconds, it goes to “No route to host” (phone side).
Really looks as if the tcp/ip stack is going down every few minutes.
I can make the re-connection system more persisting, but other than that don’t see what I can do… any ideas?
It sounds like you are thinking the problem is on the Android side. I’ve never tried to use TCP on an Android OS so I can’t offer any experience with that. Are you opening a TCP socket on the phone to the PC and keeping it open or opening and closing it? Are you using a common TCP connection to communicate both ways or opening a separate socket on each side?
It’s a normal TCP socket. The PC is always accepting the next connection so it can have any number of clients up to date.
The phone uses the standard socket calls, as in new(), connect(), { send() and receive() } close()
Everything going well, just one socket is used. It is disposed of in case of error, and a new one used to try and establish again.
I can always be wrong - so often in programming - but having no other complains about this since this new version was out (6 weeks), and having tried a few different phones with long sessions, no drops ever… I’m inclined to think there’s a spurious problem at your side. But I’m being honest when I say I may be wrong.
If your phone was iPhone, I am positive the code is ok as it’s been running no changes for almost a year, with no error reports at all.
BTW now that I’m at it I’m adding a screen saver to protect OLED screens.
Just one last thought before the weekend: with these log and beta versions the sensitivity to network errors is very acute - I removed all the retry logic, at first problem the session is dropped.
Depending on the exact nature of the problem this may be a significant difference or not.
Thank you, no. The beta and the log versions are for the moment the same, except for the log generation.
But the official version should be more resilient to connection problems. If you recall the problem was not so easy for you to reproduce with the first log enabled version, then I disable many retrying mechanisms to help diagnose.
At least we now know what is happening, more or less. Not sure if there’s any good solution if the conn drops for as long as it does.
have you tried forgetting the network and the connecting again afresh (from the phone)?
Alternatively, have you tried connecting via 3G, 4G or whatever? (if you can setup a port mapping in the router)?
Sorry - making some research (google) about wifi drops and android, it seems with some brands of mobile this is quite common. I managed to reproduce more or less what happens to you with my son’s phone (which is exactly the same model as mine, mine never loses connection, his does).
In the pages I found several solutions were proposed, in our case I found that telling the phone to forget the wifi network, so it is as if connection for the first time, asking password, etc… after doing this, the phone connects and keeps the communication up no problem at all. Not sure for how long, but it seems - again, in some android phones - the quality of the wifi deteriorates with time, for a given network.
In the tests I also set up a NAT port mapping - so I could connect to my GNS from outside my home network, using 4G. If, even with my son’s mobile while it would fail via wifi, I turn the wifi off and mobile data on, the connection will work no problem.
Just meaning it was a problem specific to that wifi network in the phone. Weird, but seems we’re not the only ones suffering this.
I will upload a new beta in a couple of days or so, with things back to normal but faster, and more solid, and including the screen saver for OLED devices.
@jaime What is the status on this work? I recently tried GNS again at a new location (i.e. different WIFI same phone) and the issue persists. I see that the new version of SGP has new GNS binaries and that is what I was using. GNS on the phone was the non-logging beta version.
last thing is I published (in google play) a beta version with the improvements, for everybody to try it out. I also became quite convinced this is a phone-specific issue - I can’t of course be 100% sure in your case. GNS is obviously sensitive to network issues, but with a long enough watchdog and reasonable timeouts the worst effect should be to get some statuses a bit late, or to lose a very short-lived one.
The binaries in SGP are good, no problem there; my best suggestion is to try via mobile data instead of wifi, I suspect that could fix your problem. You’d have to open a port in the router for that to work, and disable the phone’s wifi.
Also, if you tell me the brand and model of the phone maybe I can find some info about this.
Removing the wifi access point (“forgetting” it) and then connecting again, typing the password etc, and the problem solved. Just checked for a few days after that, can borrow it again to see if the solution lasted.
On the other hand, the recovery was quite sped up in the new version, so if / when the connection fails, it will be recovered faster if possible.
