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@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
