Issue with stream management reconnection (after closing app)

[thedjnK]

Describe the bug
Testing against openfire version 5.0.3 with default settings, seemingly with stream management enabled on openfire, the app can connect fine when creating the account, it seems to stay connected and resume instantly if you e.g. lock the screen and leave it for a while, however when you connect, then close the app from the task manager, then re-open it, it seems to have some issue. The openfire status of the session after closing is "detached" - which is expected, then when opening the app it remains in "detached" for about 10 seconds or so, then it changes to "Invalid session/connection", then after quite some time (about a minute) it changes to being connected with the IP address of the client.
If stream management is disabled on openfire, then seemingly the app connects instantly each time it is opened without issue, therefore indicating that the issue is within the stream management parts of this app (I do not believe that the issue would be in openfire's implementation)

To Reproduce
Steps to reproduce the behavior:

1. Enable stream management on server (openfire)
2. Open app
3. Add account
4. Connect
5. Close app from task switcher
6. Reopen app
7. Watch and wait

Expected behavior
For it to reconnect properly

Screenshots
Screenshot from openfire server when you reopen the app:

Details (please complete the following information):

• Siskin Version: 7.3.3
• iOS version: 13.4
• iPhone model: iPhone SE 2020

Additional context
Should note, all this is being tested on the same local network, so the delay is not caused by e.g. cellular latency

[hantu85]

That is interesting, however I do not agree with your findings. Closing Siskin from the task switcher is nothing else than just stopping the application and releasing all memory it uses (basically killing the process). Siskin stores information about enabled stream management only in memory - when it is stopped from the task switcher, then it loses those information and opens new and "clean" connection to the XMPP server.

However, when Siskin reconnects it uses the same resource (during XMPP session binding). If that resource is already in use (as in this case, as Openfire is not aware of broken connection and awaits reconnection), then server may decides what to do:

1. kill old connection and allow new one to take over
2. reject new connection awaiting for the old one to reconnect

From your description, it looks like 2 option is happening here. As you described:

then after quite some time (about a minute) it changes to being connected with the IP address of the client

That would be Openfire waiting for the "broken" XMPP session that had Stream Management enabled with support for resumption to resume within resumption timeout (that usually is 60-90 seconds) and rejecting new session for "already used" resource.

With Stream Management disabled in Openfire, this "broken" session is not hanging in Openfire, but is closed just after broken connection is detected and allows a new connection to be accepted.

I do not see any issue with Siskin IM behavior in this case, just not typical behavior of "blocking" reconnection when there is a session awaiting resumption for the same resource.

[thedjnK]

That would be Openfire waiting for the "broken" XMPP session that had Stream Management enabled with support for resumption to resume within resumption timeout (that usually is 60-90 seconds) and rejecting new session for "already used" resource.

Not from what I've seen, it seems the detach timeout was previously configurable but does not seem to be anymore, the old default was 10 minutes, I waited longer than that and openfire still had the session in a detached state, I then tried adding the server property manually to set it to 2.5 minutes and it still did not get cleaned up (leading to me believing that the property is in fact removed). So I do not believe this to be the case as the delay in connecting is constant no matter how long I wait before reopening it, if I open it after half a minute or 7 minutes then the connection time and status updates on openfire are the same

[thedjnK]

Also I would presume that the issue described here: #235 is likely actually the same issue

[hantu85]

Could you make one test for me?
Please try to wait until Siskin connects, then move it to the background and wait for about 30-60 seconds (but do not kill it from the task manager). After about 60-90 seconds, try to open it and let me know if the connection was fast.

[thedjnK]

Tested and yes, after 90 seconds of background idle with siskin, it resumes instantly.

Compared with snikket as seen in the other issue: snikket indicates stream management support also, it sets away upon backgrounding app, and instantly resumes states, upon closing app from task switcher and reopening it, it also connects instantly - the big difference here between siskin is that when you close the app the connection vanishes from openfire, whereas with siskin it shows as detached, unsure if something there was fixed or if they just added a workaround to not use stream management or force a disconnect upon app being closed.

[hantu85]

Thank you for this test. There is a bug in Siskin in which when in background it is not closing the connection to the XMPP server. The fix for it is ready, but fixed version was not released yet.

[hantu85]

I've pushed a new test flight build 7.4.0-b6 that should resolve this issue - at least I didn't encounter it in testing this version.