[jdev] Server implementation query: State after SM resumption

[Christian Schudt]

Hi,

I think Openfire doesn’t support Stream Resumption yet, but I’ve implemented Carbons in it and I think if it would support stream resumption, carbons state would not be restored.
I.e. Carbons state would be the same as before.

I guess any implementation would keep some stateful session object in memory and when clients resume a stream, the new connection is just associated with the old session (with the help of the SM-ID).

Therefore any negotiated session state (e.g. Carbons or CSI) would be unchanged after stream resumption, unless a developer explicitly resets any state (which is discouraged by XEP-0198, see below).

This is at least my opinion, because it feels like the most natural approach a developer would probably develop it.

Furthermore XEP-0198 clearly states:

• The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state, since this state will have been retained by the server.
• Both parties SHOULD NOT try to re-establish state information


Kind regards,
Christian


> Am 09.03.2017 um 21:17 schrieb Florian Schmaus <flo at geekplace.eu>:
> 
> Given the latest discussions at council@/standards@ ([1] 5.) I think it
> is time for a short inquiry of XMPP server behaviour in the wild. Please
> answer the following questions:
> 
> 1. What is the name of the server you develop?
> 
> 2. Is the carbons state restored after a stream resumption (XEP-0198)?
> (yes/no/not implemented)
> 
> 3. Is the CSI state restored after a stream resumption (XEP-0198)?
> (yes/no/not implemented)
> 
> Your answers will help the XMPP community to get more informed overview
> of the currently deployed state of interaction between Stream Management
> and CSI, Carbons and other XEPs.
> 
> Thanks for your time!
> 
> - Florian
> 
> 1: https://mail.jabber.org/pipermail/council/2017-March/004166.html
> 
> 
> 
> _______________________________________________
> JDev mailing list
> Info: https://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________