[Standards] Stream Management and Acks (XEP-0198)

Dave Cridland 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  
> possible".
> i.e. how long should we wait until we decide to give up on the ack?
Local policy.

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

> 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.
Argh! No!

> 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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list