[zeromq-dev] XREP vs. ROUTER

[Pieter Hintjens]

On Fri, Mar 18, 2011 at 1:51 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Now, XREP socket is implemented in such a way that it's "send the reply
> back to the original requester" functionality can be used to route
> messages to specific peer.

The problem with this semantic is that it's impossible to write a
device that does it any way except by explicitly manipulating the
address stack. Thus even the most basic REQ/REP device immediately
becomes a router, which is why this router pattern is so widely used.

> However, note that this is an implementation detail. If the
> implementation of request/reply pattern changes, the routing
> functionality can break.

... you would break every single REQ/REP device in existence, afaics.
This could be a valid extension of 0MQ but I see that as new
functionality, not refactoring existing functionality.

> 1. Routing is a low-level functionality used to build 0MQ patterns on
> top of it.

This is the current situation.

> 2. Routing to address is a separate messaging pattern and should be
> exposed as such.

This is already how it works, and is already exposed as such. I don't
see how this is different from option 1.

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

This is equivalent to discarding 40% of the 0MQ API afaics, you'd make
many people very unhappy.

The silent dropping of messages is fine, except that it's annoying
during development. To see this as the defining characteristic of a
ROUTER socket is not accurate. Rather, the exceptions need to be
accessible to developers. One does not want asserts on errors of
input, but one does not want utter silence either.

The way ahead here, IMO, is to recognize that the ROUTER semantics are
core to 0MQ and very, very important for building higher-level
patterns, and then to improve them carefully and gradually over time.
Making (even the suggestion of) large semantic changes here is both
dangerous and unnecessary afaics.

-Pieter