Hello again. Forgot to mention something that can be useful in this case. Since traffic (nr bytes) is important in this case, I would suggest you also look at compressing data. XEP 0322 (http://xmpp.org/extensions/xep-0322.html) provides a very efficient means to compress XML, better than conventional compression algorithms when used schemas are known. It is more efficient since it adapts itself to the structure of the XML being sent using knowledge from schemas used. It also has the ability to learn during the session making it even more efficient.
Best regards, Peter Waher From: Peter Waher [mailto:[email protected]] Sent: den 28 oktober 2013 12:48 To: XMPP Standards Cc: [email protected] Subject: Re: [Standards] Standard for Throttling/Queueing Stanzas Hello Spencer As Joachim mentioned, there is interest from the Internet of Things (IoT) community to create such a XEP. In fact, it is already planned because there's a need, but it is yet to be written. Anybody interested in co-authoring such a XEP is welcome to contact me. The envisioned XEP however is not IOS specific, but rather concerns battery-powered sensors, but can be applied to sensors in resource constrained networks (where bandwidth is constrained). The same solutions can be applied in the IOS case you mentioned, since it can be seen as a resource constrained device, when the application runs in the background. Peter Saint-André mentioned that the deferred XEP 0273 could solve part of this issue, by permitting the filtering of certain messages. Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the bandwidth can be controlled by the device, using the presence as an indication when the server can send information. (Here battery powered sensors often go into sleep mode and wake up regularly to perform a task. They can only receive messages when awake.) Other solutions can be envisioned, for instance using presence=away to signal clients restricting them to send important messages only, queuing not as important messages for later when online, etc. Ideas are welcome. Best regards, Peter Waher From: Spencer MacDonald [mailto:[email protected]] Sent: den 27 oktober 2013 13:17 To: XMPP Standards Subject: [Standards] Standard for Throttling/Queueing Stanzas I have observed from the XMPPFramework mailing list and Github issues, that one of the biggest problems that iOS Developers have with including XMPP (alongside VoIP) in their iOS apps, is that their apps get terminated for receiving to much data while in the background. There are proprietary solutions that allow an XMPP client to inform the XMPP Server that the app is going to be put in the background. The XMPP Server then queues the stanzas until the client in with the XMPP Server, which on iOS is less than or equal to 10 minutes. Some solutions also filter out presence packets so only the most recent one is queued for each jid. I appreciate that the problem is iOS specific, but the solution can be generic. Is this something that should be incorporated into an XEP? or is there already a solution for this issue? Regards Spencer
