On 04.10.2017 07:34, Georg Lukas wrote: > * vaibhav singh <vaibhavsinghac...@gmail.com> [2017-10-03 15:45]: >> After Service Discovery is done, the pinging and the pinged entity could >> negotiate a timeout between themselves (one of them could dictate what >> timeout to use, or both parties could suggest timeouts and we use the one >> which is lower). > > This is actually a highly complicated matter. The limiting factor for > most clients is the NAT session timeout imposed by their local router or > a carrier-grade NAT deployed by (mobile) ISPs. RFC 5382 states in REQ-5 > that a TCP "established connection idle-timeout" must be more than two > hours. I don't know how many ISPs follow that, but there are for sure > many broken WiFi routers that have significantly lower timeouts, even as > little as 5 minutes.
I've also experienced mobile carriers with an unreasonable low timeout (~2 minutes, it as a French one years ago IIRC). > From my experience as a client developer and server maintainer, a > ping interval of 14 minutes (after the last received packet) works well, > except on the notoriously broken WiFi routers. Not sure if I would call it "ping interval". It could lead people to implement an unconditional ping every X minutes. Not really battery friendly. > I would recommend against sending whitespace, because that relies on the > OS to kill the TCP session in a timely fashion, which doesn't happen if > the other endpoint of the connection becomes unavailable. IMO, the best > approach is to use an <r/> element on XEP-0198 enabled sessions and a > 0199 ping otherwise, with a response timeout value of 2 minutes. I agree with most of what you have written so far. > While either side can send a packet to refresh the NAT session, I would > recommend to implement the 14m-2m ping mechanism on both sides, because > knowing when you are offline has value both for the client and the > server. I think there is an important point missing here: Client and Server need to agree on a inactivity timeout after which they check the liveness of the connection (using a ping mechanism like xep198's <r/> or xep199). I have the idea of a "Don't Ping Me, I Ping You" XEP in my head for a long time, wondering if something like that would be sensible. It basically provides a way to signal the server that the client will never keep the connection inactive longer than X minutes. Which means the server doesn't need to ping the client unless there was an extended period of inactivity of X minutes. The XEP would allow clients to set the timeout to their preferred value, which may even could change over the lifetime of an XMPP session. Furthermore, I'm not sure if setting X is low as 14 minutes is realistic. For example on Android you can only check roughly every 15 minutes if the inactivity timeout has occurred using AlarmManager. And therefore(*) we can only guarantee a lower bound of the maximum inactivity period of 30 minutes (by sending pings after 15-30 minutes of inactivity). Because of that, and because of battery savings, why my recommend value for X would be 30. Of course, YMMV and that is why such a XEP sounds like a good idea to me. - Florian * I believe it is possibly related to the Nyguist-Shannon sampling theorem
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
