[zeromq-dev] [0MQ/3.0] discuss: rename XREP to ROUTER
sustrik at 250bpm.com
Sat Mar 19 09:07:21 CET 2011
> it is interesting to see such a multi-level discussion!
> (and it is rewarding to see how much of this is driven by how successful
> 0mq is!)
> let me offer some observations:
> 1) the rasion d'etre, or central meme, of 0mq is scalability to
> internet-sized problems.
> no one else offers this -- you must not lose it. this is why crap like
> and so forth is inherently a different layer -- there is too much
> and assumptions built into these things.
> 2) normally, i am utterly unimpressed by half-arsed solutions. being able to
> "route back" via XREP/XREQ has always struck me as lazy. to me, you
> either do it
> right (which can never involve XREQ/XREP alone, there has to be much more
> infrastructure to cope with different errors), or you don't (in which
> case your
> solution is not always correct so why do you care?).
> 3) having said 2), there nevertheless is a place for restricted domains.
> if someone were to offer, say, reliable routing within a domain
> where the networking has diameter of 2 hops (like a single cluster
> of machines), then that would be attractive to a large number of people.
> but that should be an explicit choice, just like choosing your
> messaging pattern is a choice. and by choosing the domain cleverly,
> you can probably offer this functionality simply.
> and with due respect to pieter, just because users do something,
> that doesn't make it right or even sensible. it simply points out a need.
> we all want to make users happy, but not at the cost of teh project's soul.
> (overstatement for sure, but you know what i mean.)
I think there's a middle ground here.
The idea is based on the fact that "send to address" pattern -- what
XREP is now often used for now -- is known to be scalable. If SMTP and
XMPP do it, there's no technical reason why 0MQ can't.
Thus, if we add a following line to zmq.h:
#define ZMQ_ROUTER ZMQ_XREP
we can achieve 3 goals in parallel:
1. Keep the functionality that's already widely used and not screw the
users by removing it.
2. Separate the request/reply pattern from send-to-address pattern and
thus prevent changes in one of them to break the another one.
3. Provide a sandbox for send-to-address pattern development.
There are some theoretical issues, like "isn't send-to-address just a
duplication of IP functionality further up in the stack?", "does it do
presence?" etc., however, clean separation of the pattern means that
it's up to those working on it to cope with these questions.
More information about the zeromq-dev