revolution-irc
revolution-irc copied to clipboard
MCMrARM
Does not reconnect on connection loss
Hello and thank you very much for making this app. So far this is shaping up to be the best IRC app I've used so far, and I can tell that a lot of thinking went into the UI and its functionality. Please keep it up, as this is great!
My internet connection tends to reset periodically. When this happens while the app is connected to a network, it does not notice. It acts as if it was still connected for many hours, missing everything that's being said.
If there's no other way, pinging the server periodically would be the last resort to figure out if you're connected.
my €0.02: I can actually confirm this and noticed this quite early on when using the app. But I have ignored this issue, i.e. didn't report it, since I was sure it's known one, due to the app's beta status.
I've even observed some issues with manual reconnection attempts (meaning, it was basically impossible to reconnect, even though it's not a problem at all with any other client on the same machine, same local network, same IRC server around the same time, etc. etc.).
If any reproduction steps would help here, then I'm glad to help out.
Today I noticed that when this happens, and you try to send a message, the app will reconnect on its own 15 minutes after the message is (supposedly) sent.
Actually more than reproduced, it's confirmed. I don't know the exact scenario in which this happens, but I definitely want this fixed for 0.4.0.
Testing 0.4.1 now. It appears to notice that it is not connected anymore on its own, but it can take anything from 25 minutes to several hours to do so.
Related to https://github.com/MCMrARM/revolution-irc/issues/139
I don't think I can fix it, but I'll add an option to set sub-15 min intervals for the next update. Either way that comes at a giant battery usage cost, so that's not really a solution in any way.
I noticed the sub-15 minute intervals proposed by @MCMrARM was dropped and there is still no solution to this. I honestly don't know if this would be a solution or not, but I can understand why you would feel uncomfortable about implementing it due to the power issue. To make you feel less uneasy about implementing this, how about a compromise to start so people can at least test it using it with WiFi only at first? If "Only send a heartbeat on WiFi" is checked, the lower limit is lifted and anything goes for the interval. As soon as it is unchecked, the lower limit of 15 minutes is automatically reinforced. WiFi is obviously a significantly less power drain than over mobile data, so I find this to be a fair proposition for now, as this issue is rather serious, and will at least get the needed feedback to either continue thinking about this as a possible solution or not in the future.
@haarp and @geisesteert, are you running "Data saver" on your phone? You can check by going to Settings -> Connections -> Data usage -> Data saver. If it's turned on, try adding Revolution IRC to the "Allow app while Data saver on" list and see if it solves your problem.
Related to #139
I don't think I can fix it, but I'll add an option to set sub-15 min intervals for the next update. Either way that comes at a giant battery usage cost, so that's not really a solution in any way.
@MCMrARM, the actual issue of this thread is this:
My internet connection tends to reset periodically. When this happens while the app is connected to a network, it does not notice. It acts as if it was still connected for many hours, missing everything that's being said.
Revolution IRC does not recognize when the server has disconnected due to timeout and says it's still connected when it isn't.
If there's no other way, pinging the server periodically would be the last resort to figure out if you're connected.
The issue https://github.com/MCMrARM/revolution-irc/issues/139 is not related to this as pinging is suggested as a form of "keepalive" to hold the connection open in that issue. That's not the case in this issue. @haarp is actually trying to suggest that ping be used to probe the status of the connection periodically to see if there is still a connection or not. If not, the client should attempt a reconnect. He is not suggesting ping be used to hold the connection open, as the cause of the disconnect is not in question here, unlike in https://github.com/MCMrARM/revolution-irc/issues/139 where the disconnect is trying to be prevented in the first place. This issue revolves solely around the client's inability to detect when the server has disconnected and remains a dead connection and does not attempt to reconnect because for some reason it's stuck and shows that it is connected when it's actually not.
The fact we don't detect disconnects is not due to a client bug, but due to how TCP works. There's no way to learn that we have actually disconnected other than a periodic ping. This is because we don't attempt to send any data over the socket, and the OS itself does not query the connection state nor track the timeout on it's own (this isn't bad per se -- it allows one to have a truly idle TCP connection with little to no overhead). However this also means that we rely on the other host to send us a disconnect notification packet which gets lost somewhere. As such, we are left with a stuck connection.
@haarp, can you do some further testing and see if this is happening specifically for ping timeout, read error, or both? On my end I have been trying to eliminate as many reasons for timeouts as possible to get a good control test, but no matter what I do there is always the occasional read error which causes the client to get stuck. Many people just assume ping timeout and read error are basically the same thing and just means your connection was cut somehow and the error the server encounters first is the one it throws, but this actually isn't true and you can get a read error for things completely unrelated to connection, such as problems internal to the client itself. If this is the case, the issue might not actually be triggered by something connection-related at all and there might be something else wrong in the client, like it's having a mini crash or freezing in such a way that the connection is still fine but the server just can't read from the client anymore.
I've seen this just now with 0.5.2 - no received messages in any channel for 2 hours, but the connection apparently still "up" from RevolutionIRC's PoV.
(I've simply been tolerating this for a long time, but it's more annoying recently as my ZNC is down.)
Some form of keepalive ping is the only reliable way to detect when the other end has gone away; failure to get an answer to a ping should be treated as a connection failure if no other traffic is received.
