[IPython-dev] [ATTN: Kernel Authors] libzmq change breaks kernel heartbeat

[MinRK]

Patches have been accepted to various zeromq branches, so this problem
should not affect libzmq-4.0.7 or libzmq-4.1.2, once they are released. I
would still recommend kernel authors make the changes proposed above, even
though they will not be necessary after the next patch release of libzmq.

-MinRK

On Fri, Jun 5, 2015 at 4:25 PM, MinRK <benjaminrk at gmail.com> wrote:

> ATTN: Kernel authors,
>
> libzmq just released 4.0.6 and 4.1.1. Both of these include a change in
> zmq_proxy that breaks the kernel-side of our heartbeat machinery.
> Specifically, zmq_proxy cannot be called with a single REP socket for
> both ends.
>
> Currently, the message spec docs recommend the kernel-side of the
> heartbeat mechanism be implemented as zmq_device(FORWARDER, REP, REP).
> zmq_device has wrapped zmq_proxy since libzmq 3, in which case the first
> argument is actually ignored.
>
> This can be fixed by making the REP socket a ROUTER, which is what it
> should be anyway. There’s one caveat for this change, though: On very old
> systems with libzmq-2, ROUTERs don’t work in a FORWARDER device, only
> QUEUE. This is fine, and doesn’t really make a difference.
>
> To be fully compatible with libzmq-2.2 through 4.1, the heartbeat call
> should change from:
>
> zmq_device(FORWARDER, REP, REP)
>
> to:
>
> zmq_device(QUEUE, ROUTER, ROUTER)
>
> If you only need to support libzmq ≥ 3 (recommended), you can use:
>
> zmq_proxy(ROUTER, ROUTER)
>
> If you were using your own echo loop for the heartbeat socket instead of
> zmq_device, you shouldn’t be affected.
>
> This is really an implementation detail, not a protocol change, because it
> doesn’t affect how messages are sent or received by the kernel, only the
> internal event handling (REP is a restricted subclass of ROUTER,
> indistinguishable to peers).
>
> -MinRK
> ​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150608/92a8bce4/attachment.html>