[Standards] Whitespace "ping"

Mickaël Rémond mremond at process-one.net
Tue Jun 11 13:09:43 UTC 2019

Hello Marcel,

> On 11 Jun 2019, at 14:59, Marcel Waldvogel <marcel.waldvogel at uni-konstanz.de> wrote:
> On Tue, 2019-06-11 at 14:23 +0200, Mickaël Rémond wrote:
>> Hello Guus,
>>> On 11 Jun 2019, at 14:00, Guus der Kinderen <guus.der.kinderen at gmail.com <mailto:guus.der.kinderen at gmail.com>> wrote:
>>>> 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.
>> Well, I think if the server does not have to approve the value, client could expect to set it to something extreme (like 1s) or useless (like 1 days). The server could thus reply with a different value. And still the server needs to know at which rate the client is expected to send the keep alive.
>> But, yes, it is always possible to do something like that in a non standard way. My point was trying to agree on something to make life of client developers easier :)
> The nice thing about TCP keepalives or IQ pings is that there is no need to negotiate: Once any of the sides thinks it is time to probe the other, it will send out the probe. This will cause the remote idle timer to be reset. So naturally, the minimum is chosen and it works even if only one side supports the feature.

The problem with XMPP ping is that it does not scale well. Having millions of connected clients doing XMPP ping is a nightmare.

> BTW: Per-socket TCP keepalive parameters are supported in Linux since 2.4, i.e., the beginning of this millenium. (Please note that most systems expect the keepalive interval in seconds, but Solaris considers them as milliseconds. We have been bitten very badly by this several years ago…)

Yes, but I still think being handle at a low level makes TCP keep-alive not adequate for the fast detection of connection loss. Without higher level protocol, we see too many admin complains that it takes hours before XMPP connections are seen as lost. From a server developer perspective, moving that at the application level means that we can help and not rely on mobile device or server configuration / version, etc.

Mickaël Rémond

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190611/eb6a126b/attachment.html>

More information about the Standards mailing list