On Fri, Mar 18, 2011 at 12:51 PM, Martin Sustrik <[email protected]> wrote:
> 3. Routing to an address is not an valid and/or redundant pattern and > thus people are using XREP as an router at their own risk and should > expect strange behaviour (such as silent dropping of unroutable > messages) to happen. > Just to say, I found this whole explanation helpful. I do get into the habit of thinking about (IP style) sending messages to nodes, which is not really the 0mq way - as you say, if I wanted to send to a specific service, I have a queue for that service and shuffle a message onto it based on some intentional message semantic, not based on the identity. I think, in fact, that a fundamental issue *is* the identity - if it was always implicit I don't think people would have started using this as a to-node router, the fact that you can set your own choice of name makes this solution of using XREP to route more obvious. That said, identity as is a necessary and very worthwhile option, I just think it is to some degree behind that way of using this pattern. I also agree with Mato and Pieter that the library is being used a different way though - the LRU worker example is a classic demonstration of this. If you want LRU worker functionality you just have to use the socket identies, and therefore XREP as a router, because the only load balancing strategy in the library is round-robin. To do that pattern reasonably you either have to build reliability on top (which works, as in the ch4 example), or have some way of detecting dropped messages from XREP. Personally since you *can* layer the reliability in at the application level, I think the silent drop is inconvenient rather than a blocker, so it comes down to the line of how much functionality is in the library versus how much is layered on. I would say that this falls into the bucket of 'convenience' flags that I think are worth the maintenance up keep. Something as simple as a bool getSockOpt(CONNECTED_IDENTITY, "id", 2) would probably be sensible - I'd also like getSockOpt(SUBSCRIPTIONS) which would return a count of subscription filters on a socket for similar reasons. Being able to do sanity checks that things wont be silently dropped is convenient, but not essential. Ian
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
