Pieter Hintjens ph at imatix.com
Fri Oct 19 07:58:19 CEST 2012

On Fri, Oct 19, 2012 at 1:39 PM, Ian Barber <ian.barber at gmail.com> wrote:

> Yeah, I have no problem going back to EHOSTUNREACH. Looking back at the PR,
> the idea of the change was pretty much precisely to allow a blocking send to
> a currently disconnected host (which is now what you're running up against
> from the other perspective) - that still does seem like good, developer
> friendly behaviour in many cases, but given this is a default-to-off option,
> I would be inclined to let the app handle it.

Right... perhaps there are two distinct strategies here. EHOSTUNREACH
is clear, simple, and solves the major issue we still have with ROUTER
sockets, that they unpleasantly just drop unroutable messages. It's a
major headache for debugging.

The second semantic is IMO dodgy. Blocking on a pending peer means
your thread is dead if any peer goes away. This would be fine if your
thread handled exactly one peer, but ROUTER is precisely for handling
many peers. If you need to block on sending to one peer, you can use

The pattern I'm designing now in Ch8 of the Guide for peer to peer
work uses ROUTER for incoming messages and DEALER for outgoing

So I'm going to create a new issue and revert the error code to EHOSTUNREACH.


More information about the zeromq-dev mailing list