On Wed, May 7, 2014 at 10:46 PM, Georg Lukas <ge...@op-co.de> wrote: > * Dave Cridland <d...@cridland.net> [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. > > If you do terminate the connection, you make the process susceptible to > DoS attacks against clients on slow connections (or currently in the > process of reconnecting).
No, if you start bouncing stanzas that you would have delivered to the client if it was connected, you need to kill the resume and bounce them all. Consider the case of a paused client in a MUC. The MUC sends a message, and gets a bounce because the buffer's full. The client resumes the session, but now its out of sync - it thinks its in the MUC and the MUC has removed it due to bounces. 198 resumption is an all-or-nothing job. /K
