[Standards] Using XMPP In A Mobile Environment

Florian Schmaus flo at geekplace.eu
Fri Feb 13 15:38:36 UTC 2015

On 13.02.2015 12:35, Sergey Dobrov wrote:
> On 02/11/2015 12:12 AM, Florian Schmaus wrote:
>> On 10.02.2015 09:11, Sergey Dobrov wrote:
>>> On 02/10/2015 01:57 AM, Florian Schmaus wrote:
>> I'm not sure about that, Even if you defer all messages for only 30
>> seconds, realtime (chat) communication would become a pain. And there is
>> also little gain in that. I guess that only if your defer interval is
>> something > 15 minutes you will see a measurable positive effect on the
>> battery consumption.
> I'm not sure here. This page
> http://chimera.labs.oreilly.com/books/1230000000545/ch07.html#_initiating_a_request
> says that it can take few dozen seconds for the radio to go to dormant
> state to conserve radio and each next wake up of it can consume up to
> 100ms and corresponding battery consumption.

Ahh that's an interesting reference you have here. I'm still unsure if
deferring all stanzas is something one should do. At least not as part
of the XEP I've in mind.

>>>> So the basic idea is clear, but I'm undecided how to specify such an
>>>> mechanism. For example:
>>>> - Should the stanzas which are bundled and deferred be matched by
>>>>   - Privacy Lists
>>>>   - SIFT. But SIFT has no way to filter on roster status (e.g. "If sender is
>>>>     not subscribed to my presence, defer and bundle the stanza he
>>>>     wants to send to me" :-( )
>>>> - Delay Time? I'm thinking about recommending 15-30 minutes, while
>>>>   warning that it should be not less then 15 minutes (a typical SMTP
>>>>   greylisting timeout).
>>> But it can be less than 15 minutes if device wakes up earlier, right?
>> Well we could say that if the client becomes active (by means of CSI),
>> all bundled and deferred stanzas are flushed (just like the presences
>> are). I would maybe mention this optimization in the spec but make it
>> optional, while noting that bundling and deferring should still happen
>> if the client is in active (CSI) state, because otherwise you circumvent
>> the protection.
> I don't see why the circumvention happens here? Inactive state does not
> mean you don't want anything to be received but rather means that it
> would be better to not receive because I don't wait for the data. But if
> smth urgent happens, we can deliver it all because it actually doesn't
> affect battery consumption again and from the other hand it keeps the
> xml stream sorted by time.

I meant to say, that deferring should still happen when the CSI state is
active. There is just *one* flush of the bundled and deferred stanzas
when the client enters the CSI active state (if any). If you don't
continue to bundle and defer stanzas when the CSI state is active, you
circumvent the protection it provides.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150213/974b0872/attachment.sig>

More information about the Standards mailing list