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

[Artem Vysochyn]

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