[zeromq-dev] Heartbeating using TCP keepalives

Alex Grönholm alex.gronholm at nextday.fi
Mon Dec 30 23:29:37 CET 2013


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131231/a22a82f3/attachment.htm>


More information about the zeromq-dev mailing list