* 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. The Google Android cloud messaging client works around this mess by detecting NAT-imposed connection resets (unexpected RST packets) and maintaining separate per-WiFi-network idle timers. 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. 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. 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. Kind regards Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
