Repository navigation
App gets stuck at "Connecting" when resuming from background #650
Description
Activity
i think i discovered the same issue on a freinds iphone here.
if app is online messaging and everything works. after i lock the iphone it still does. also gets messages pushed to lockscreen when i wait 5 min in lockscreen then my sent messages never arrive.
when i unlock the phone and open chatsecure i see the other contact (me) as offline - stil not receiving messages.if i then go to the settings in account manually disconnect an dreconnect messages arrive also "sent" messages get actually sent then (and arrive on the other phone) (conversations)
so actually at the moment chat with chatsecure with that friend is simply not working from a user point of view.
it's an iphone 4.
so i think it possibly correllates with low reccources.Sometimes conversations has issues with SRV lookups. I 'fix' this by enabling extended server settings and specifying the IP address of the SRV resulting A Record.
Did this fix not make it into the 4.0.4 release? Will it be in 4.1? The is one of the ones I'm looking for, along with OMEMO file transfer and MUC fixes.
Thanks for the 4.0.4 update!
@afriedmanGlacier I still haven't fully figured out why it's happening, but I have an untested theory. Right now there is a redundant enum property that tracks connection state, when we should just be asking the xmppStream itself.
@chrisballinger I don't fully understand the connection code so bear with me if this line of thinking is just due to my ignorance. I was looking at this awhile ago and noticed that the connection timeout value in XMPPStream, specifically in connectToHost and connectWithTimeout seems to be bypassed in favor of XMPPStreamTimeoutNone.
For us, we connect through a VPN which needs to reconnect first, and the connection hung when the VPN wasn't yet reconnected, so I modified those functions and used the timeout value. I also put something in GCDAsyncSocket.didNotConnect to retry the connection because it didn't seem to be trying to reconnect otherwise. These changes seemed to fix our problem until there is an official fix, though we haven't tested enough to be 100% confident.
I assume most people ChatSecure without VPN, but if the connection for some reason isn't made immediately, would a lack of timeout cause it to hang like ours was doing?
(I never submitted our code because I thought you guys would have a more elegant and more appropriate solution. Due to my limited understanding of this underlying connection code, I felt like mine was a temporary hack)
@afriedmanGlacier Yeah, under normal circumstances it should timeout and retry, but it isn't. This also affects Tor connections (while Tor is warming up it times out on the first try and doesnt retry). Thanks for your feedback.
Is the source to your fork available somewhere?
Its not right now and I'm about to leave for the day (and unavailable most of the weekend). I'll try to either make it available or send you the source changes I made for this either Sunday or Monday.
@afriedmanGlacier No worries
@chrisballinger I started to fork but since changes are in CocoaAsyncSocket Pod and XMPPFramework Development Pod in addition to ChatSecure core code, I will just zip and attach
the 3 changed files here. Also, again, I doubt this is the best solution or 100 percent effective, but as a temporary hack it seems to work for us. (By the way, I'm not sure this is related, but there was something funky going on when I didn't have an IPv6 address set, so I also changed the preferIPv6 value to NO).I assume you can just do a diff on the files, but if you want me to point out exactly where the changes are, I'd be glad to do that.
I completely changed the way we handle this. We started checking the connection status, got some weird values, and realized that because we weren’t specifically setting the Hostname under Advanced in the Login page, then in xmppStream.connectWithTimeout, hostname length is 0 and it was looking for a SRV record rather than connecting with the IP address which is what we expect. So, first, we set hostname to automatically fill in with the value after @ in the username.
As far as reconnection, I got rid of all changes we had in GCDAsyncSocket and XMPPStream, and instead use the XMPPReconnect class in XMPPFramework. I know this is meant specifically for “accidental disconnections,” but it seems to work well for when it comes from background and can’t connect too. Here are the changes:
XMPPReconnect.m - In the shouldReconnect method, we always return YES (I realize this could cause other problems, but shouldn't the way our system is used). And in maybeAttemptReconnectWithReachabilityFlags, we have “[xmppStream connectWithTimeout:(NSTimeInterval)10 error:nil];” instead of XMPPStreamTimeoutNone.
OTRXMPPManager.m - I also set “if (![self.xmppStream connectWithTimeout:(NSTimeInterval)5 error:&error])” instead of XMPPStreamTimeoutNone in the startConnection method of OTRXMPPManager.
Much less invasive than our last solution. Still needs more testing, but seems to work the way we expect. In case this is of any use.
Reacted by paskalitoReacted by paskalitoReacted by paskalito
It doesn't always happen. I noticed if you manually reconnect when it says "Connecting" the presences don't get repopulated and I'm not sure if the app fully "works" in that state. We need to do an audit of our connection timeout and reconnection management.