On 5 Oct 2017, at 07:26, vaibhav singh <vaibhavsinghac...@gmail.com> wrote: > >> >> >> On Wed, Oct 4, 2017 at 4:38 PM, Florian Schmaus <f...@geekplace.eu> wrote: >> 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. > > I, for one, would love such an XEP. The thing which seemed to be lacking in > XEP0199 was > there could be different types of clients having different timeouts and there > was no clear way > for the server to keep tabs on whether the c-s connection was up without > pinging the clients itself > (which seemed like wasted effort to me). > > That said, XEP 0199 may not be a proper place to handle these things, a new > XEP would make much > more sense in that case. Either a predefined min timeout in some XEP for the > client to use, > or some sort of timeout negotiation happening between server and client, > after which the client/server > pings the other party to check the health of the connection, would be good.
I’m not sure that the sides need to agree on timeouts. As long as each side does sensible pinging (only when the stream is silent) and not blindly every X seconds, they can both satisfy whatever their own requirements are. That effectively leads to the same result as negotiation, as the shorter timeout wins, pretty much. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
