[Standards] Stream Management and Acks (XEP-0198)
dave at cridland.net
Mon Nov 14 22:51:54 UTC 2011
On Mon Nov 14 22:20:41 2011, Nate Leon wrote:
> In XEP-0198 / Section 4, we see this comment:
> "When an <r/> element ("request") is received, the recipient MUST
> acknowledge it by sending an <a/> element to the sender containing
> a value of 'h' that is equal to the number of stanzas handled by
> the recipient of the <r/> element. The response SHOULD be sent as
> soon as possible after receiving the <r/> element"
> One might ask, what happens if my side sends a request but never
> gets an ack in response?
You disconnect, and reconnect, resending the "missing" stanzas, or
resuming the session, as appropriate (and possible).
> Or maybe it's only been several minutes, but my sender continues to
> receive other stanzas on this session.
I can't parse this, sorry. "My sender continues to receive" has got
If you mean that although you're not getting acks, you're getting
*other* traffic in a regular stream, then your peer is horribly
screwed, and you're best off not using 198 with it at all, ever.
Disconnect, then run away screaming.
> So first, we have the problem of putting limits around "as soon as
> i.e. how long should we wait until we decide to give up on the ack?
> Assuming we do finally give up on receiving the ack, what should my
> side do about it?
If you don't receive an ack, assume the TCP layer is shot. Reconnect,
> It seems to be a clear violation of protocol given "the recipient
> MUST acknowledge..." clause,
> but shutting down this connection seems overly harsh in this case.
> (bad user-experience)
No, because the TCP connection really is likely to be dead.
The exception is a very very buggy peer, but in that case it's
probably a developer driving it, and they should be used to bad user
> Furthermore, how do I know the other side even received my request?
That's actually the point. You assume that the other end didn't, if
it hasn't acked quickly enough for you.
> Alternatively, my side could silently disable Stream Management for
> this session,
> since I don't have any way to communicate my unhappy state to the
> other side.
> I'd appreciate hearing thoughts from others (especially those
> implementing XEP-0198)
> as to how you interpreted / handled this scenario.
The situation we're trying to prevent here is sending stanzas off
into the ether when there is no other end. We're going to assume that
whatever you're talking to is well behaved, and not trying to trick
So when you send an <r/>, you have a reasonable expectation that
you'll get an <a/> back in roughly one RTT - however long that RTT is.
As a server, this can be treated as several minutes quite
comfortably, since mobile weirdness can make for very long RTTs, and
the recovery is always pretty clear. As a client, it's a bit
different, since the user may well decide there's a serious problem
much sooner, usually within seconds, if it seems that their messages
aren't getting through.
Equally, though, as a client, you're able to reconnect and resume the
session potentially without interruption, or at the very least warn
the user visibly and early, so realistically the user experience
improves through disconnects, rather paradoxically.
Nothing frustrates users more than having to type "Did you get
that?". 198 effectively prevents this on a link basis, meaning that
184 becomes truly reliable for end-to-end, even if you lose your
connection during the e2e round-trip.
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