On Tue, Oct 3, 2017 at 8:04 PM, Jonas Wielicki <jo...@wielicki.name> wrote:
> On Dienstag, 3. Oktober 2017 19:13:47 CEST vaibhav singh wrote: > > Hi, > > Hi! > > > One of my colleagues is working our XMPP server, and saw an issue which > > seems foreign to me (I am also kind of new to XMPP). > > > > The issue is, in order to check whether the client is up or not, our XMPP > > server implemented XEP-0199 from the server side (S2C) which is enabled > by > > default, and the periodicity of pings can be controlled by server side > > configuration, but some XMPP clients send their own pings whose timeouts > > cannot be configured. This results in ping-pong packets coming and going > > around a lot, and awkward interactions (the client may think that the > > server is down but server may not, in case client timeout is less than > > server timeout). > > The client should not assume that the server party is "down". A temporary > network outage is more likely. A reconnect, especially with XEP-0198 > (Stream > Management) solves this quickly. Could you go into details on the actual > problem which arises here? > > > > 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). > > > > Is this a good idea? > > Not in the general context of XEP-0199, I think. Establishing a ping > timeout > between arbitrary parties would widen the scope of the protocol quite a > bit. > > Establishing a common ping timeout between client and server may be useful, > but in the end, modern clients and servers support XEP-0198, which makes > this > less and less needed (if a connection gets severed, the client will > eventually > notice and attempt to resume). > > Static ping timeouts also don’t work well with modern use-cases, like > mobile, > which can suffer from interesting conditions (like interruption of the link > for minutes, delays in the order of minutes, you name it). > > So, the issue is rather complex, and there’s no generally-good solution > (not > to mention that modern clients and servers will prefer XEP-0198 "pings" > over > XEP-0199 pings to lower bandwidth use). If you can go into details why the > situation you describe is a problem, maybe a specific solution can be > found. Thank you for pointing out about XEP0198, that seems to settle the issue inhouse at least. No specific issue, it was just we scratching our heads about how the server and the client would be able to manage streams without any prenegotiated timeout value between them, given the context of just XEP0199. However, it does seem like stream management is not really a concern of XEP0199, but of XEP 0198, that makes more sense to me now. Thanks, Vaibhav > > > kind regards, > Jonas > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > > -- Regards, Vaibhav Singh
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
