> -Original Message-
> From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Georg
> Lukas
> Sent: Wednesday, May 07, 2014 2:46 PM
> To: standards@xmpp.org
> Subject: Re: [Standards] Security consideration for XEP-0198
>
> * Dave Cridland [2014-05-07 23:05]:
> > It's probably worth noting, yes. The solution is to request an
> > acknowledgement, and if one isn't forthcoming, to ditch the
> > connection, of course.
>
> It is not that easy, unfortunately. If the client is currently disconnected,
> the
> ultimate purpose of the stanza queue is to cache stanzas until the client
> reconnects. If you ditch the connection, you undermine the purpose of the XEP.
>
> It is wise to have a timeout mechanism for the client not responding to ack
> requests. However, the session should be kept for a defined time after that,
> to
> allow for a reconnection.
>
> IMHO, there should be a stanza limit per session/per JID, however once the
> limit is reached, new stanzas for that client should be rejected with an error
> without terminating the connection.
Although not mentioned, I would expect many server implementations would choose
to impose limits on how much unacknowledged traffic they will buffer. XEP-0198
leaves a lot of freedom to the implementer.
The primary goal of XEP-0198 is to optimize reconnection for clients with
unreliable connection (or hopping from wired/wireless). A resume may fail, but
if it succeeds quite often then it is a useful optimization.
If you assume you have no evidence that the client connection has failed (but
your buffer has hit its limit), you could simply discard the oldest unacked
packet and make space for the newer packet. In many cases the client will catch
up and no harm is done. If you are not so lucky, and you need a stanzas you
discarded for a resume request - oh well the resume will fail. This simple
implementation is sufficient for optimizing reconnection most of the time, but
occasionally it means someone has to take the slower session recreation path.
I don’t believe it was the goal of XEP-0198 to guarantee a stanza is either
delivered or bounced. I am not sure if you are trying to achieve this guarantee
by bouncing new stanzas once the buffer overflows.
I don’t think this will work well. This implementation is liable to fail to
deliver traffic the client, and the client would be totally oblivious. Events
from pub-sub nodes might have been missed, changes in occupants and roles
within a chat room, etc
I believe the only way to make this guarantee is to kill the session upon
overflow. All the unacked packets are available to bounce, the client will have
to reconnect and establish a new session (resume would fail), and the client
would rebuild their state. The price of this guarantee is that it could cause a
bad experience for users on slow connections, or cause problems when there are
heavy bursts of traffic.
Dave's suggestion could help detect dead/unresponsive connections sooner, but
you still have to deal with the problem of buffering stanzas while you are
waiting. You probably want to send stanzas anytime your buffer creeps up so
that you can solicit an stanza well before you hit your overflow point.
Note:
xep-0198 allows clients to send stanzas even if there was no from the
server. When you see an from the client that might not correlate to the
you sent. I suppose you could keep waiting for the that has 'h' equal to
the value you would expect for the you sent.
== Jock Williams ==
