[nanomsg] Re: ZMQ_ROUTER like functionality

  • From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Thu, 18 Sep 2014 13:33:41 +0300

Hi Alex,

On Thu, Sep 18, 2014 at 8:40 AM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote:
> Looking at your mails for DIRECTORY, it almost seems like adding
> subscriptions/filters (with sender-side suppression for non-matching) to
> SURVEY would give pretty much exactly The Right Thing, and sounds like a
> useful primitive on its own.

Yes, except I'm not sure its similar to SURVEY pattern. I believe that
It's more like REQ/REP pattern, in the sense that matched requests are
load-balanced between respective workers, instead of being sent to
every matching worker (and David's use case seem to match mine).

However, sometimes I see subscriptions as a separate building block,
which can be applied to all pipeline, reqrep, and survey patterns, and
for all of them it makes sense. What do you think?

> As for how the subscriptions would actually go upstream, maybe they start
> with a default subscription of zero length (matches anything in a trie, and
> doesn't break back-compat), they can add more subscriptions, and when
> they're done they (explicitly) unsubscribe from ""?

I'm not sure why you need a subscription to start with. Let me
describe my use case better.

Imagine we have a three machines (or better a theee clusters, but I
skip that detail), that serve some articles. The machine S1 serves
articles, having title that starts A to J, machine S2 serves articles
K-Q and machine S3 serves articles R-Z.

Now let's imagine we have S2, and S3 down. When S2 comes online, if
it's first subscribed to empty string, it will get requests for K-Q
and for R-Z. For the latter group of articles it has no meaningful
answer, so I whould have to filter out that requests. Note that
comparing this with pub-sub, sending request to wrong recipient is
much more expensive, since it leaves request waiting for a timeout at
the client (and timeout is usually an order of magnitude larger than
expected response time).

Well, in fact if you see it's like a SURVEY, i.e. when request is sent
to many workers, then empty subscription at the start makes sense.

IIRC, our discussion with Martin have come to conclusion that it's
possible to make subscriptions good enough for the pattern without
additional semantics. I can recall details if somebody would try to
implement it.

-- 
Paul

Other related posts: