[zeromq-dev] Heartbeating using TCP keepalives

[Pieter Hintjens]

It makes sense, and I'd try this; the timeout should be in msec, to be
consistent with other duration arguments. You can take any of the
existing socket options like ZMQ_SNDBUF as a template, and make a pull
request.

On Mon, Dec 30, 2013 at 11:29 PM, Alex Grönholm
<alex.gronholm at nextday.fi> wrote:
> This isn't directly related to ZeroMQ, but it is somewhat relevant now given
> A) the addition of the (yet unimplemented) heartbeating feature in ZMTP/3.0
> and B) the Windows TCP keepalive parameters fix I committed recently.
> The question is: has someone here used TCP keepalives as a substitute for
> application level heartbeating? Given the operating model of ZeroMQ, using
> TCP keepalives for this purpose would transparently shield the user from
> stale connections. Are there any downsides to this?
> TCP keepalives, when turned on, use a 2 hour interval by default (this is a
> de facto standard). This makes them impractical unless the values are
> adjusted.
> I've done some research on that. From what I've gathered, it seems that
> setting TCP keepalive parameters on a per-socket level is supported at least
> on the following operating systems:
>
> Linux
> FreeBSD
> Windows (since Windows 2000; set only, read not supported; number of
> keepalive probes is fixed on 10; must be set before connecting; values in
> milliseconds, not seconds)
> Mac OS X (since Mountain Lion)
> AIX
> Solaris (values in milliseconds, not seconds)
>
> It seems that both iOS and Android support sending TCP keepalives, but
> setting keepalive parameters is not supported.
> Note that the Windows TCP keepalive parameters patch takes the time
> intervals in seconds and multiplies by 1000 on Windows for cross platform
> compatibility. There is no similar fix for Solaris yet so Solaris users need
> to do it on the application level for now.
>
> Setting the keepalive idle and retransmission delay to values like 10 and 5
> seconds would make a lot of sense to me. If the peer fails to respond to the
> probes, zmq will just see a disconnection.
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>