[Standards] Stream Management and Acks (XEP-0198)
dave at cridland.net
Tue Nov 15 08:54:57 UTC 2011
On Tue Nov 15 01:14:23 2011, Nate Leon wrote:
> Your point is well taken about "enabling" buggy clients/peers.
> But at this early stage of SM adoption, I am hesitant to be overly
> As for switching to a new client, unfortunately, there are not a
> large number of SM-enabled clients out there at the moment. :)
No, but all three I've tried work fine, as far as my testing shows.
> There seems to be an implication that not closing the connection
> immediately is an incorrect behavior.
> But the spec doesn't say what the sender of the <r> should do in
> the case where the intended recipient does not respond in a
> (variable) time frame.
> Maybe I would be more comfortable with this if that section in the
> XEP read,
> "... the recipient MUST acknowledge ... the response SHOULD be
> sent ... otherwise, the sender of the <r/> SHOULD close the
The response MUST be sent, surely? I can't see any reason not to,
unless you simply can't because the connection's been dropped. (In
which case you're no longer bound by the spec).
But yes, if you want to write a patch to the XEP, I'd appreciate it.
> Then it would be more clear that any other action would be
> initiating / propagating bad behavior, and the angry mob should be
It's not a mob, it's probably just me. But I do wield a mean
> And I agree that we will not be able to trim our buffer if we don't
> receive those acks. :-( However, we will have an upper bound on
> the size of each session's buffer to avoid blowing out memory, and
> we will rely on that.
Right. So what you're saying is, in effect, that you want to send an
<r/> (on some heuristic), and if you don't receive an <a/> within a
certain timeframe (large) or within a heuristic period based on the
size of the buffer, then you're going to terminate the connection.
You could do this, yes. Come to think of it, clients failing to
acknowledge stanzas are going to get their users mighty annoyed
anyway - my recollection is that one client failed to acknowledge the
last few stanzas received prior to closing the stream, which resulted
in the server resending them to offline storage.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards