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

Artem Vysochyn artem.vysochyn at gmail.com
Fri Sep 20 18:20:09 CEST 2013


I' afraid I use ROUTER/DEALER correctly.

Let me make it more clear.

What is needed -- differentiate operations emitted by client side. Speaking
in terms of zmq -- I need different socket identity per "operation".
The operation in turn may be "one request / one reply",  or "N requests / M
replies".

I feel like I ca't re-use same DEALER for several operations. I.e. can't go
with DEALER per thread.  Simply  imagine the case:

You doing simple request-reply via DEALER and you timeouts:

send a message:    [thread-0][dealer-0][send]:   sent()
 message(correlation#0)
recv reply:                [thread-0][dealer-0][recv]:  recv()  ...
timedout on recv():  [thread-0][dealer-0][recv]:  timedout doing recv().

This is fine to not receive reply in specified timeout, still DEALER can be
used for further operations, and now we want to issue batch-of-requests and
get batch-of-replies:

send first message:        [thread-0][dealer-0][send]:   sent()
 message(correlation#1)
send second message:  [thread-0][dealer-0][send]:   sent()
 message(correlation#2)
send third message:       [thread-0][dealer-0][send]:   sent()
 message(correlation#3)
recv first time:                 [thread-0][dealer-0][recv]:  recv()  ...
got reply recv():               [thread-0][dealer-0][recv]:  recv()
message(correlation#0)

Here's real problem -- I have got reply message(correlation#0)   which has
been from previous "operation".
In second operation I sent correlation#1, correlation#2, correlation#3  so
I expect them back, and not the correlation#0.

Now it's more clear?

So having new DEALER per operation (instead per thread)  would perfectly be
a way to go, because new DEALER is essentially new identity. That would be
great.  Because ROUTER would be able to reply to "operation" identified by
identity.

But the thing is I can't create zmq socket per operation because this is
exhausting OS from file descriptors... 8((((((  That's why I'm here and
asking for help.


2013/9/20 Pieter Hintjens <ph at imatix.com>

> 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
> >
> _______________________________________________
> 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/51188df4/attachment.htm>


More information about the zeromq-dev mailing list