Project

General

Profile

Presences sent after Stream Resumption

Mauro Carrio
Added about 5 years ago

Hi,

XEP-0198 says that both client and server must not send any presence state or roster changes happened during disconnection because any change will be sent after successful resumption process.

We were doing some test, and this is the behaviour: the first time I resume, all is fine, all contact status presences are sent to me, so I can update the screen with the online users. But the second time I resume on the same session, contact presences are not sent anymore. Only my presence status is sent.

In the third straight resumption, my presence status is sent twice and so on, one more is added if I continue resuming on the same session.

What would be the correct behaviour? All contact presence information should be sent after resumption?

Client log in third straight resumption:

2014-02-08 13:43:53.686 Company[4655:60b] XMPP: State Resuming - element = <resumed xmlns="urn:xmpp:sm:3" previd="f20e72c3-87f2-4c5a-aecd-e9c2f753ec8f" h="21"></resumed>
2014-02-08 13:43:53.991 Company[4655:60b] {1560f530} Did Receive Presence: 
<presence xmlns="jabber:client" to="5553641207@mydomain.com" from="5553641207@mydomain.com/iphone">
  <status>lalalag</status>
  <show>chat</show>
</presence>
2014-02-08 13:43:53.996 Company[4655:60b] {1560f530} Did Receive Presence: 
<presence xmlns="jabber:client" to="5553641207@mydomain.com" from="5553641207@mydomain.com/iphone">
  <status>lalalag</status>
  <show>chat</show>
</presence>
2014-02-08 13:43:54.809 Company[4655:60b] {1560f530} Did Receive Presence: 
<presence xmlns="jabber:client" to="5553641207@mydomain.com" from="5553641207@mydomain.com/iphone">
  <status>lalalag</status>
  <show>chat</show>
</presence>

Thanks,

Mauro


Replies (1)

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam about 5 years ago

Basicly XEP-0198 is about resumption of existing session which should lead only to delivery of packets which were sent to particular user connection during time in which client was disconnected and resumption did not timed out. So if during the time in which your client was disconnected, none of your buddies sent to you any presence or message packet then you should not receive any packets after stream resumption.

From what you describe I assume that during first attempt of resumption the resumption failed as you received all contact status presences. But resumption could also be successful but maybe your client during resumption send element with h attribute value which forced server to resend unacknowledged presences.

As for every next attempt it is hard to tell what exactly happend, but I suppose that your client sends initial presence packet after reconnection and if it will not acknowledge previous presence packet, then this behaviour may lead to presences being queued on resumption queue and this could be increased by one presence packet each time.

But this is what I assume, as I never have seen such a behavior which you described. To be sure we would need a log from a server side from a time during which this occured with debuging enabled.

    (1-1/1)