[Standards] Stream Management and Acks (XEP-0198)
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
Maybe I would be more comfortable with this if that section in the XEP
"... 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,
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
>> 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...
More information about the Standards