[Standards] UPDATED: XEP-0198 (Stream Management)

Philipp Hancke fippo at goodadvice.pages.de
Thu Apr 26 17:56:59 UTC 2012


old thread alert...

> Version 1.3 of XEP-0198 (Stream Management) has been released.

I implemented 0198 for s2s and am in general quite happy with it. Some 
notes I wrote down while implementing this. Thanks Dave for listening to 
my complaints and thanks Matthew for writing mod_smacks which was useful 
as the evil peer who did not send acknowledgments.

The only major issue is that the case of sm-after-dialback is not 
explicitly covered... Section 3 has the following text:
The client MUST NOT attempt to negotiate stream management until it is 
authenticated; i.e., it MUST NOT send an <enable/> element until after 
authentication (such as SASL, Non-SASL Authentication [8] or Server 
Dialback [9]) has been completed successfully.

This does allow the usage of dialback together with session managment.
However, there should be at least one example which shows how this is 
used, especially since the <enable/> element can only be sent after the 
<db:result type='valid'/> has been received.
	(this is  violating my sense for protocol aesthetics but works
	 reasonbly well)


Other issues:
It is not explicitly specified if a client is allowed to send stanzas 
after sending <enable/> but before receiving <enabled/>. Current server 
implementations allow that which is reasonable and reduces unnecessary 
delay. The client MUST NOT request acknowledgments before receiving 
<enabled/> obviously.

Additionally, the outbound stanza count must be set to 0 after sending 
<enable/>, not when receiving <enabled/>. Example 6 has annotations 
showing the right thing but this missing in the text of section 3.

I ignored s2s-session resumption for the time being. There might be some 
interesting opportunities wrt to DNA and multiplexing which still need 
to be figured out. I would not recommend servers to set resume=true on 
s2s for now.


Implementation note:
I implemented a one-r-at-a-time-and-only-after-a-stanza-has-been-sent 
strategy which sends an <r/> after a stanza unless the stream is waiting 
for an <a/> response from the peer. Now suppose there are 5 stanzas 
which are sent immediately after each other (which happened during 
stream setup).
The first stanza is sent, followed by <r/> and the other four stanzas. 
The peer sends the <a h='1'/> immediately when receiving the <r/>.
Now if there is no other traffic and the stream breaks, this means that 
there are four unacknowledged stanzas. The obvious solution (on the 
sender side) is to issue another <r/> when receiving <a/> and the value 
of h is different from the current outbound stanza count.



Last but not least I am not sure that doing this for s2s is really 
necessary.  But having implemented it means I can start gathering 
statistics (number of unacknowledged stanzas and the outbound count).



More information about the Standards mailing list