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

Dave Cridland 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  
> harsh.
> 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  
> connection"
> 
> 
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  
> dispatched!
> 
> 
It's not a mob, it's probably just me. But I do wield a mean  
pitchfork.


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