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.kinde...@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. 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…) -Marcel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
