[Standards] Whitespace "ping"

Guus der Kinderen guus.der.kinderen at gmail.com
Tue Jun 11 12:19:54 UTC 2019


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
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190611/e38f127c/attachment-0001.html>


More information about the Standards mailing list