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

[Pieter Hintjens]

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
<artem.vysochyn at gmail.com> wrote:
> 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 <ph at 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.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
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>