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 and send messages over it, block on getting replies, and after that -- dispose DEALER. This approach would allow me to send new socket identity (since I create new DEALER) upon every operation, so ROUTER side can use the newly created identity and reply.
2013/9/20 Pieter Hintjens <p...@imatix.com> > 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 > <artem.vysoc...@gmail.com> 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 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 ROUTER-s somewhere. Pretty classical: > > N-inproc-clients talking to M-tcp-ROUTER-s on the network. Here's > pastebin' > > diagram: http://pastebin.com/kR4y1Fhx > > > > The matter in that I want some synchronous nature on client side. Clients > > may emit one-request and should wait for one-reply, or clients may emit > > batch-of-requests and should wait for batch-of-replies. Formally like > this: > > req_i <--> rep_i and [req_i, ..., req_n] <--> [rep_i, ..., > > rep_m]. > > I found that DEALER is almost perfect for this. But here's a problem: > how > > to track correlation between what I sent and what received? In REQ socket > > this is done via some internal state machine, but in DEALER I'm free to > keep > > sending and keep receiving w/o knowing correlation between requests and > > replies. So how to do this correlation? Write some code on client side > which > > would keep a list of sent message' ids? > > > > Another question related to what I described above -- how to achieve this > > correlation w/o writing this custom code on client side? I really-really > > don't want to write it. And keeping in mind that, can be the following > > approach as a solution: create new inproc socket upon client operation, > and > > upon completion dispose socket? I.e. one inproc socket per operation > > (opposite to one per thread). And since this will be an inproc socket > (the > > guide says it's not real tcp and it's cheap), so can I follow this > approach: > > "inproc socket per operation"? > > > > > > Thank you in advance. > > > > _______________________________________________ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
