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