[Standards] Whitespace "ping"

Sebastian Krzyszkowiak dos at dosowisko.net
Tue Jun 11 12:51:13 UTC 2019


2 minutes is still way to low. Mobile modems conserve energy the best
while being in deep sleep - as soon as you wake the modem up, it
drains hundreds/thousands times more energy for some amount of time.
The timeout of 30 seconds wouldn't let some modems sleep at all, 2
minutes would most likely make them sleep only for minority of time.

It's always a trade-off, but an interval of 2 minutes is still
extremely low and is going to eat a lot of battery. Solutions like
push notification systems usually use some robust algorithms to detect
over time the highest but still somewhat reliable timeout value
possible for a given network.

Of course timeouts lower than ~30 seconds will raise the battery
consumption even more, as then you're basically constantly
transmitting and waking up the CPU a lot as well, but when considering
battery usage of your app you should compare it to idle, not to 100%
transmitter occupancy :P

On 6/11/19, Guus der Kinderen <guus.der.kinderen at gmail.com> wrote:
> Yeah, I remember our then-CEO telling us that his phone "would not get warm
> anymore", after we changed the interval from 30 seconds to 2 minutes. That
> was over a decade ago though. I think that you're right in that patterns
> change with evolving mobile phone components.
>
> Unless I'm mistaking, Push Notifications are one-way. As far as I know,
> they can't be used to tell if a client has dropped offline (and do all
> kinds of follow-up / cleanup actions, server sided).
>
> On Tue, 11 Jun 2019 at 14:11, Ненахов Андрей
> <andrew.nenakhov at redsolution.ru>
> wrote:
>
>> Btw, from a mobile client developer perspective, if a server pings an app
>> every 30 seconds, the battery drain is very high and is significantly
>> higher than if interval is set to 2 minutes. What's interesting is that
>> dependency is not linear: drain seems to rise sharply with intervals less
>> than 60 seconds. I don't recall the exact details though, it was 5+ years
>> ago since we tested it. Also, I think that in current state of affairs
>> the
>> way to go are push notifications, and thus the need for ping is somewhat
>> diminished.
>>
>> вт, 11 июн. 2019 г. в 17:01, Guus der Kinderen <
>> guus.der.kinderen at gmail.com>:
>>
>>> What we need basically is a way to negotiate the interval with server
>>>
>>>
>>> I'm not sure if this is _needed_? Without this being a requirement, much
>>> of the complexity of "making this more standard" falls away.
>>>
>>> A server could, before determining that a connection is lost, attempt to
>>> send any IQ stanza (PING is an obvious choice, but any query will do).
>>> As
>>> the client is obliged to respond, if anything with an error, the server
>>> knows if the connection is, in fact, lost.
>>>
>>>
>>> On Tue, 11 Jun 2019 at 11:50, Mickaël Rémond <mremond at process-one.net>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> The RFC 6120 mentions whitespace ping to keep the connection alive and
>>>> help the server detects that the client is gone.
>>>> I also see that there was some attempt to bring consistency in the way
>>>> server handles this in XEP-0304:
>>>> https://xmpp.org/extensions/xep-0304.html
>>>> It is rather old and today has also probably a bit of overlap with
>>>> XEP-0198 Stream Management, and possibly also with XEP-0199 XMPP ping.
>>>> I guess many client use the XEP-0198 acks, but still, XEP-0198
>>>> recommends the use of TCP level whitespace keepalive.
>>>> Having a way to check connection from client without generating load on
>>>> parsers and limiting bandwidth used is important, so whitespace
>>>> keepalive
>>>> are goods.
>>>>
>>>> What do you think of pushing forward a way to make whitespace ping
>>>> behaviour more standard?
>>>> What we need basically is a way to negotiate the interval with server,
>>>> so that client can be considered disconnected when that whitespace
>>>> trafic
>>>> is not receive in time.
>>>>
>>>> I am not really fond of making this a new stream feature, like XEP-0304
>>>> suggest, as maybe what would make more sense is to define that feature
>>>> in
>>>> Stream management XEP itself (and thus could be part of the stream
>>>> management negotiation)
>>>>
>>>> What do you think ?
>>>>
>>>> --
>>>> Mickaël Rémond
>>>>
>>>>
>>>> _______________________________________________
>>>> Standards mailing list
>>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>>> _______________________________________________
>>>>
>>> _______________________________________________
>>> Standards mailing list
>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>> _______________________________________________
>>>
>>
>>
>> --
>> Andrew Nenakhov
>> CEO, Redsolution, Inc.
>> https://redsolution.com <http://www.redsolution.com>
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
>


-- 
Sebastian Krzyszkowiak
dos


More information about the Standards mailing list