XEP-0198 resume failure reconnect: resending of MUC messages

Smack Smack Dev
3

We are talking about the “resume failed” use case, so it’s longer than 5 minutes in typical deployments.

One could indeed argue that, however there is no hard line for that. How long a transmission delay does justify adding a <delay>? 10 seconds? A minute? 5 minutes?

The logic in yaxim works as follows:

  • if there is a connection, send the message right away
  • if we know we are not currently connected+authenticated (even during a short switch 3G/WiFi), store the message with a timestamp for later delivery
  • send all pending messages after resume/reconnect

So in fact, the above described issue only affects the messages that I send while yaxim is still “connected”, i.e. network traffic gets blackholed, and then SM resumption fails.

Regarding the API, I’ll be glad to implement one, but I’m not sure if you’ll like it. It would go like this:

  • mirror the (add|remove|removeAll)StanzaAcknowledgedListener() functions into (add|remove|removeAll)StanzaDroppedListener()
  • if at least one StanzaDroppedListener is registered, feed all of previouslyUnackedStanzas into it and drop the list (*)
  • send all of previouslyUnackedStanzas if no StanzaDroppedListener is available

(*) This would be compatible to the current behavior, but slightly surprising from an API design point. Maybe it would be better to have an explicit configuration option to resend queued stanzas after a failed resume?