[zeromq-dev] XREP vs. ROUTER

[Martin Sustrik]

Hi Ian,

> 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

Yup. This concept should be probably explained somewhere, but my 
experience is that people have to learn it the hard way to really get 
it. Reading an article about it doesn't usually induce the change of the 
mindset. Still, having an article wouldn't hurt.

As an interesting side note -- when 2.0 API was introduced, basically 
everyone tried to use ZMQ_PAIR sockets for everything, including 
simulating the patterns that were already present in the library. It 
looks like TCP mindset is so deeply imprinted in our brains that it's 
very hard, even painful, to get rid of it. The good news is that people 
finally got it and no one is using ZMQ_PAIR anymore. Hopefully, same 
will happen to the "sending messages to nodes" mindset and people will 
think more in the terms of "sending a message to weather forecast 
pub/sub tree" or "sending message to NASDAQ stock trading network".


Btw, anyone out there using ZMQ_PAIR anymore? What about dropping it in 
3.0? Hearing Zed Shaw saying something like "I don't know how to use it. 
I've never used a pair socket myself," makes me hope that that's the case.

  - 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.

Identity was introduced for completely different reason (limiting 
resource usage on the binding peer) back in version 0.3 and it was 
particularly bad design choice at the time. Mea culpa.

> 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.

Yes. I think you are right. The identity makes sense in "mail" pattern 
where you need to keep stable routing tables (similar to IP routing 
tables), in other words giving long-lived names (IP addresses) to the 
nodes. It doesn't make much sense for request/reply though.

> 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.

Yes. In other words it's about guarantees that each pattern provides. 
What's not provided by the pattern, should be built on top. So, say, 
there's reliability missing for request/reply. And the question arises 
whether is should be introduced into 0MQ itself, or whether it should be 
provided by a library on top of 0MQ.

> 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

That would not work in multi-hop scenarios. So say, if there's a device 
in-between you and the service, the fact that you are connected to the 
device doesn't necessarily mean the device is connected to the service 
and thus that the requests will be processed in a reasonable time frame.

> 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.

It's kind of redundant, but in theory it could be introduced.

Martin