[zeromq-dev] How fast inproc socket REQ/DEALER create/destroy lifecycle?

[Artem Vysochyn]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130920/a890b9f2/attachment.htm>