Re: [Standards] XEP-0198 minor enhancement
Thanks Florian Dave, I made a major misunderstanding, and this now makes good sense. I was thinking the 'h' value in the failed stanza was the servers count of stanzas received by the session for delivery **to** the client. That is to say a resume using that value would require re-transmission of zero stanzas. I thought you were trying to make resume work with dropped packets - which could open up a can of worms. What you have in mind is that’s oldh is the servers count of packets received by the session **from** the client. As such it's just a way of allowing the client to know which stanzas made it to the server before the connection dropped. I can see that could be a useful enhancement. == John (Jock) Williams == -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Florian Schmaus Sent: Wednesday, June 03, 2015 12:35 AM To: XMPP Standards Subject: Re: [Standards] XEP-0198 minor enhancement On 03.06.2015 01:48, John Williams (johnwi3) wrote: Thanks for the clarification. Hum,.. not sure how useful this is, since a lot of stanzas are of little long term interest (eg: chatstates), but as you describe it seems pretty harmless. Consider the XMPP user walks into the subway without GSM reception scenario which leads to a failed/ once the user's device is back online. Without 'h' in failed/ the client is unable to tell which messages have been received by the server right before the signal was lost. With 'h', the client is able to display some more visual feedback about the state of outgoing messages. tl;dr: It's useful for mobile clients if you slightly missed the max resumption time. - Florian
Re: [Standards] XEP-0198 minor enhancement
Comments inline == John (Jock) Williams == From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Dave Cridland Sent: Friday, May 29, 2015 1:01 PM To: XMPP Standards Subject: [Standards] XEP-0198 minor enhancement What if, on a resumption failure, a server could include the 'h' attribute, to mean I can't actually resume your state, but I did get all the stanzas up until H. I think this allows servers to hold onto this small amount of state for considerably longer than it's desirable to keep a disconnected session live, and it also makes a halfway house between ack-only and full resumption possible for other servers. Thoughts? Jock Dave, could you provide some clarification on the use cases, and what the expectations should be if the server supports this new feature and a client choses to take advantage of it. Jock when a resume response comes back as failed, the client can bind and start a new session (with today’s xep-0198). With this addition are you giving the client the opportunity to retry the resume this time using the server supplied ‘h’? Doing so means the client is resuming knowing there are dropped stanzas. Jock Dropped stanzas imply missed messages, and missed state changes (eg: contacts presence, chatroom rosters, pubsub nodes updates). Jock Are you thinking of tolerating any consequences of these state errors in exchange for a faster re-connect (and less buffering overhead in the server)? Are expecting the client to make efforts to validate it’s state? Would you anticipate smarter servers that can orchestrate protocol soon after the resume, such that the clients state becomes current. Is this aimed at specialized xmpp applications? Also, do you think we could add this attribute without a version bump? Dave.
Re: [Standards] XEP-0198 minor enhancement
Thanks for the clarification. Hum,.. not sure how useful this is, since a lot of stanzas are of little long term interest (eg: chatstates), but as you describe it seems pretty harmless. == John (Jock) Williams == -Original Message- From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Matthew Wild Sent: Tuesday, June 02, 2015 3:24 PM To: XMPP Standards Subject: Re: [Standards] XEP-0198 minor enhancement On 2 June 2015 at 22:11, John Williams (johnwi3) john...@cisco.com wrote: Jock Dave, could you provide some clarification on the use cases, Jock and what the expectations should be if the server supports this new feature and a client choses to take advantage of it. The use-case is: allowing the client to know which stanzas the server received/didn't receive from a previous session (that has timed out). The only state the server needs to store is the 'h' value (and remember, this is an optional feature). Jock when a resume response comes back as failed, the client can Jock bind and start a new session (with today’s xep-0198). With this addition are you giving the client the opportunity to retry the resume this time using the server supplied ‘h’? Doing so means the client is resuming knowing there are dropped stanzas. No, resumption failed. The client has to start a new session. Jock Are you thinking of tolerating any consequences of these state Jock errors in exchange for a faster re-connect (and less buffering overhead in the server)? Are expecting the client to make efforts to validate it’s state? Would you anticipate smarter servers that can orchestrate protocol soon after the resume, such that the clients state becomes current. Is this aimed at specialized xmpp applications? None of this. The modification Dave is proposing has no bearing on the state of the stream. It is merely informative to the client, if present. It allows the client to display to the user, or possibly automatically re-send, messages that failed to be delivered. Currently this is only possible to do accurately if the client resumed before the server timed out the session. Regards, Matthew
Re: [Standards] Security consideration for XEP-0198
-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 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. 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 r stanzas anytime your buffer creeps up so that you can solicit an a stanza well before you hit your overflow point. Note: xep-0198 allows clients to send a stanzas even if there was no r from the server. When you see an a from the client that might not correlate to the r you sent. I suppose you could keep waiting for the a that has 'h' equal to the value you would expect for the r you sent. == Jock Williams ==
