Sorry if I sound like I'm just telling you to RTFM, but this is a
common symptom when starting to learn 0MQ, trying to solve problems in
a clumsy way when there's a simpler way that you see when you've
internalized the way things work. There seems to be no alternative
except to work through it.
___
Ok. Understood. Thanks for help Pieter.
2013/9/20 Pieter Hintjens
> Creating new sockets over and over isn't a perfect answer. It's a
> terrible answer. The right answer is to keep sockets connected and put
> the semantics of your operations into the message, where they belong.
> We have dozens
I' afraid I use ROUTER/DEALER correctly.
Let me make it more clear.
What is needed -- differentiate operations emitted by client side. Speaking
in terms of zmq -- I need different socket identity per "operation".
The operation in turn may be "one request / one reply", or "N requests / M
replies"
True, it is often quite subtle how the simple solutions emerge, and
sometimes they just don't.
What can help is to build higher level APIs - I've done this a lot in
CZMQ and FileMQ and similar projects to create abstractions that work
as I'd like, hiding the complexity.
On Fri, Sep 20, 2013 at
No problem et al. In general, I really love ZMQ, it teaches me always
think towards finding most simple-and-effective solutions. But it's always
"it depends" on what ppl mean under "clumsy way".
And when I originally wrote a code which has been sending correlation_id
along inside message, after
Creating new sockets over and over isn't a perfect answer. It's a
terrible answer. The right answer is to keep sockets connected and put
the semantics of your operations into the message, where they belong.
We have dozens of examples in the Guide that show how to do this.
My advice is to work thro
Have a next problem:
I'm working on generic RPC java library on the jzmq/zmq base. At the core
will be following arch:
clients own inproc DEALER/REQ and send to local inproc ROUTER-DEALER. The
latter DEALER side will be tcp, and it will propagate messages further to
the services which are tcp RO
The classic pattern is a router server that tracks client identities
and state per dealer client.
On Fri, Sep 20, 2013 at 5:21 PM, Artem Vysochyn
wrote:
> Have a next problem:
>
> I'm working on generic RPC java library on the jzmq/zmq base. At the core
> will be following arch:
> clients own in
I guess the point about router-dealer is the intelligence sits on the
router side, not the dealer side. One router, many dealers. Perhaps
you are using these the wrong way around?
On Fri, Sep 20, 2013 at 5:45 PM, Artem Vysochyn
wrote:
> Appreciate for prompt response, Pieter.
>
> Yes, I use this
Appreciate for prompt response, Pieter.
Yes, I use this classic pattern: DEALER on client / ROUTER on server,
exactly. The question still remains: how to make correlation between
requests and replies on client side if I use DEALER. What is on the
surface -- create new DEALER upon every operation
10 matches
Mail list logo
