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

Pieter Hintjens ph at imatix.com
Fri Sep 20 17:30:51 CEST 2013


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.vysochyn at 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 at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list