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.kinde...@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.nenak...@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.kinde...@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 <mrem...@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-unsubscr...@xmpp.org >>>> _______________________________________________ >>>> >>> _______________________________________________ >>> Standards mailing list >>> Info: https://mail.jabber.org/mailman/listinfo/standards >>> Unsubscribe: standards-unsubscr...@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-unsubscr...@xmpp.org >> _______________________________________________ >> > -- Sebastian Krzyszkowiak dos _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
