we are developing a Smack based XMPP communication stack in an IoT environment, where reliability of network communication is out of our control. Therefore we need a highly automated and flawless maintenance of XMPP communication by the Smack client. We must make sure that the device tries to reconnect to the network in all curcumstances. How often is not an issue, as long as there is a determinable time frame to retry.
Regarding these requirements, I found some issues with ReconnectionManager:
- Make ReconnectionManager a (Re)ConnectionManager
If the first connect of the XMPPConnection fails, ReconnectionManager is never triggered. If the device restarts after a power outage and there is no network available in the first place, the device would remain offline forever.
That means you need to implement the first retry loop yourself. The according logic is in ReconnectionManager already, so it would be great to actually be able to use it for that scenario and not to copy parts of it. Suggestion: Add another ConnectionListener callback that triggers at start of a connect (not at success) and/or call connectionClosedOnError at failure of connect (without being connected beforehand), so the ReconnectionManager can actually take over after the first connect failed.
- Add an option that makes ReconnectManager retry connecting under all circumstances
Currently, ReconnectManager will stop trying to reconnect on StreamError condition ‘conflict’. I can see the reason for doing so, but there is a (theoretic) scenario that would make a device fail to communicate:
What if there are two devices with same XMPP credentials due to a misconfiguration? One will connect/login, the other device will fail to login and never retry to connect. If someone solves the issue by fixing the first device, the second device will remain unconnected, since its ReconnectManager already has stopped retrying.
- Minor issue: The ReconnectManager notifies reconnectingIn(0) twice
We use reconnectingIn(0) to signal a “we are currently trying to connect” to our application, so I have to filter out the second notification. The while-loop checks for >0 first, then sleeps/decrements the seconds, then notifies. After the while loop it notifies reconnectingIn(0) again. Notifying first, then sleeping/decrementing would solve the issue.
I am looking forward to your comments.