Remain online if app sleeps so MUCs remain active #780
Comments
|
We will be re-visiting group chat UX soon, so thank you for the report on this scenario. There is no way around the socket timeout on iOS, but you should be able to adjust this behavior on the server somewhat. Try setting your mod_smacks timeout |
|
My server currently does use the default. However, ChatSecure usually only stays online for about 2 minutes after the last activity (which often means just over 2 minutes total). This suggests to me that ChatSecure is disconnecting prematurely, though it's possible I'm misinterpreting the expected behavior. Do you know of any servers that are known to be definitely properly configured for use with ChatSecure? For example, are any of the servers on https://jmp.chat/suggested_servers.html known to work well? |
|
Unfortunately iOS sockets cannot remain connected in the background longer than 2 minutes. We cannot do anything about that part. You must enable |
|
I do have As mentioned, push does seem to do something - namely, if someone messages me while ChatSecure is offline, then ChatSecure will "wake up" and receive the message (suggesting push works). But it just won't stay online for some reason. |
|
Yes in that case you'll need to extend the mod_smacks timeout server side,
because the client is disconnected but you need to pretend that it's not.
If that doesn't work, then there must be an issue with smacks, but to my
knowledge the main client issues with smacks have been resolved.
…On Tue, May 30, 2017 at 7:11 PM, Denver Gingerich ***@***.***> wrote:
I do have mod_cloud_notify on the server, and ChatSecure shows a green
check next to the XEP-0357 support. That's why I'm a bit confused why it
isn't working better for me.
As mentioned, push does seem to do something - namely, if someone messages
me while ChatSecure is offline, then ChatSecure will "wake up" and receive
the message (suggesting push works). But it just won't stay online for some
reason.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#780 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAfqH9Ecrfq1Es6Rd9aZrxZ9Lm2Kb71Rks5r_MxUgaJpZM4Nq9ds>
.
|
|
Hmmm, that doesn't really make sense to me. When you say that "the client is disconnected but you need to pretend that it's not", shouldn't mod_smacks be pretending that it's not disconnected for at least 5 minutes, and only disconnect it after 5 minutes have passed? (This is given that my The problem here is that the ChatSecure user disconnects much sooner than 5 minutes. Reviewing its connection history just now (by reviewing how often it's been in a MUC), it seems that it remains online for 20-30 seconds at a time, which is definitely less than 5 minutes. Do you know why that might be happening? |
|
Are you using the latest version 4.0.9? There was a bug in an older version (forget which) that prevented xep-0198 from working properly. |
|
I had been using 4.0.8 prior to your comment, but I upgraded to 4.0.9 immediately after I saw it, and I've been seeing exactly the same behavior as before over the past couple days. |
|
Well, does iOS just close the socket after a few minutes without sending out anything further or does chatsecure send out a closing A closing stream is a clean shutdown and smacks is disabled server-side on clean shutdowns! |
|
It does not send a closing stream. It used to in very old versions, but
that was fixed. The only way to completely close the stream is to manually
log out from the account screen. It will close the socket a few seconds
before it's suspended by the OS because otherwise the server seems to have
trouble transitioning to "hibernating".
…On Sun, Jun 11, 2017 at 9:12 AM, tmolitor-stud-tu ***@***.***> wrote:
Well, does iOS just close the socket after a few minutes without sending
out anything further or does chatsecure send out a closing </stream>?
A closing stream is a clean shutdown and smacks is disabled server-side on
clean shutdowns!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#780 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAfqH-_TQryET2rfEjXcZ3QMjVPIQew9ks5sDBHugaJpZM4Nq9ds>
.
|
|
Well, then @ossguy should extend the smacks timeout to 900 seconds or more and provide a debug log of his prosody server. I'm currently maintaining prosody's smacks module and I'll have a look at the log to see what's happening :) |
|
@chrisballinger feel free to CC me for all reports related to smacks and/or push notifications when prosody is involved :) |
|
@tmolitor-stud-tu I set the smacks timeout to 1200 seconds, which still did not resolve the issue. Here is the Prosody log you asked for: https://ossguy.com/20170613-chatsecure_smacks_prosody/cs_smacks-prosody.log.txt (JIDs have been edited for privacy). The behavior in the logs contradicts what was said in #780 (comment) - it definitely seems ChatSecure is sending a </stream:stream> here. I'm not sure why. |
|
@ossguy Here's the code in question:
If |
|
No, I don't notice the app relaunch being required, since ChatSecure logs in all by itself every 15-20 minutes (modulo the problem I described in #782 (comment) ). |
|
I can't understand how that |
|
I will have to keep my debug log on for a bit longer to confirm for sure which of those cases is triggering the behavior. I'll reply here when I have that log, in the next day or two. |
|
@chrisballinger Here is the log: https://ossguy.com/20170613-chatsecure_smacks_prosody/all_cs-prosody.log.txt - the corresponding login/logout activity I see in a contact's chat window is this (in EDT, which is 4 hours behind log's UTC), with some annotations I've added to indicate when certain events occurred: -- phone was left alone (screen off) starting here (and for several hours prior) When I "opened the ChatSecure application" above, the app did not need a "relaunch" (per #780 (comment) ) - the app opened immediately with no empty table view. I'm going to guess that most of the above logouts are "after the 30 second background content-fetch" based on the timestamps, but you'll probably have a better idea than me given the information here. Note that I wasn't able to find any relevant <presence> in the debug log for the "[09:53:30 AM]" situation where the user went from Available to Away - I don't think that's important for debugging the issue, though. It does appear that ChatSecure is still sending </stream:stream> in all of the above logouts - hopefully the logs will help determine why that is. I tried to keep the log as complete as possible, erring on the side of leaving too much in than too little. Please let me know if you do need any further details. |
|
Thank you for the logs! I can't figure out why this is happening because there really shouldn't be a way for |
|
Both of those are already enabled. You can see mod_cloud_notify is on due to the "Push notifications enabled for ..." lines, and mod_offline is on by default in Prosody (we haven't turned it off). |
|
Ah sorry I missed it.. looks like I didn't glance hard enough. |
It appears that ChatSecure consistency logs out of the user's XMPP server a couple minutes after the last activity, showing the user as offline, even when mod_smacks is enabled on the user's (Prosody) server. While this is not terrible for private messages (contacts can send the user an offline message and the user will receive a push notification and ChatSecure will then login), it is quite bad for group chats, since there is no way for a member of a group chat to contact another "member" of the group chat who is offline (since then they aren't in the chat anymore) unless they happen to know the member's JID (not normally the case).
If there is some special configuration I need to do for mod_smacks to make ChatSecure work the way I expect, please let me know. I'm happy to test particular settings, or other known-working public servers (maybe some servers from https://jmp.chat/suggested_servers.html have been tested to do the right thing with ChatSecure?).
Similar issues have been reported in the past (see #770 and #591) but it's unclear if those cover precisely this case or not so I'm including them mainly for reference. Also, I previously reported an issue with push (see #773) that is somewhat related, as I was using presence in a MUC to determine whether a user was available by push. But it seems that push probably works, while the main issue is the lack of being able to stay online, so we may be able to close #773 as a result.
The text was updated successfully, but these errors were encountered: