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 <[email protected] >: > 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 <[email protected]> > 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: [email protected] >> _______________________________________________ >> > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > -- Andrew Nenakhov CEO, Redsolution, Inc. https://redsolution.com <http://www.redsolution.com>
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
