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).
