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

Nate Leon n8leon at gmail.com
Tue Nov 15 01:14:23 UTC 2011


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

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"

Then it would be more clear that any other action would be initiating / 
propagating bad behavior, and the angry mob should be dispatched!

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.

appreciate your feedback,
n8

On 11/14/2011 4:24 PM, Dave Cridland wrote:
> On Tue Nov 15 00:05:50 2011, Nate Leon wrote:
>> Having worked on protocol servers for many years I have learned that 
>> clients will send you junk.
>> (I see ESMTP/IMAP in your sig, so I know you know what I'm talking 
>> about :-)
>
> That sig refers to my client... But I see both sides, I do servers 
> these days, and dabble in clientry.
>
>
>> Thus, I cannot assume that whatever I'm talking to is well-behaved.
>
> Actually you can, in the XMPP world, by and large. Exceptions get 
> fixed pretty quickly.
>
>
>> I try to follow the "be strict on what you send, liberal on what you 
>> receive" principle.
>
> The problem with Postel's principle of robustness, is that if taken 
> too literally, you run the risk of propogating bad behaviour, and 
> lowering interoperability long term.
>
>
>> I want the end-users to have a good experience when enabling XEP-0198,
>> and so, I'd like to mask as many errors as possible, including ones 
>> from buggy clients.
>> Given all that, I think disconnecting the client seems overly harsh 
>> when the r/a mechanism fails.
>> Even if I haven't received an ack to my request in (say) over four 
>> minutes, and the client
>> continues to send me other stanzas.
>>
>>
> So let's take this case as an example. If you did this - and if your 
> server was also a significant deployment (in terms of global users, or 
> significance) - then other servers may end up having to do the same 
> thing in order to cope.
>
> As you know, any IMAP server that fails to work with Outlook or 
> Thunderbird is automatically buggy, so for the same reasons, if Buggy 
> Client X works with your popular server just fine, but fails to work 
> with mine, say, people will blame me.
>
> And I'll be at your door with a pitchfork and a flaming torch.
>
> The problem you'll run into on a more technical level is that when you 
> do finally disconnect the client, you need to do something with any 
> unacked stanzas, and the point of 198's acks is to let you trim that 
> down - otherwise it's an unbounded list, and therefore a painful chunk 
> of memory that can disappear.
>
>
>> I do see your point about the server dropping the connection, and 
>> giving the client a chance
>> to warn the user / reconnect using SM, and possibly getting things 
>> back in sync.
>> On the flip side, a buggy client that doesn't respond to acks in some 
>> circumstance
>> will constantly be warning the user and re-connecting.  That user 
>> will likely disable SM forever.
>
> Or change their client.
>
> Case in point - RFC 3920 required that clients respond to all <iq/> 
> gets. When our server started doing reachability checks with XEP-0199 
> pings, clients which failed to do this got disconnected after 7 
> minutes. Affected users soon learned which client were compliant...
>
> Dave.




More information about the Standards mailing list