On Fri, Oct 19, 2012 at 1:39 PM, Ian Barber <[email protected]> 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 DEALER. 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 messages. So I'm going to create a new issue and revert the error code to EHOSTUNREACH. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
