[zeromq-dev] RPC over DEALER-ROUTER conection (async client/server)

Doron Somech somdoron at gmail.com
Fri Dec 18 11:09:41 CET 2015


I disagree, I think the first option is the right one, and much faster (you
don't have to create sockets).

The server (router) doesn't really need to understand it, only use it when
reply.

So the first frame is the routing id (aka identity), make the next frame
the request id, now when the router reply it has to push the routing id and
the request id before the reply.

Another way to do it is to create inproc socket for each request (this is
also expensive) like so:

REQ connect to inproc

PROXY
               ROUTER bind on inproc
               DEALER connect to server

REP - bind to server address.

With this you have the request id automatically inside the message frames
by zeromq sockets (you have two routing ids pushed to the message frames,
first one of the REQ socket and second one of the DEALER socket).

Anyway just do the zeromq socket logic without using the complex chaining.




On Fri, Dec 18, 2015 at 11:55 AM, cibercitizen1 <cibercitizen1 at gmail.com>
wrote:

>
> Sorry if here is not the right place to ask this.
>
> I'm considering to implement simple RPC over
> a DEALER-ROUTER connection. Thus, I'm facing
> the obvious problem of matching the answers from the
> router side with the corresponding requests by the
> dealer side.
>
> Options considered:
>
> 1. number each request. Cons: the server (router side) must be
>    aware of this, and participate in the strategy.
>
> 2. use a separate (and dedicated) dealer socket for each RPC
> call. (Using a pool of reusable open connections so as to
> save time). Pros: this is transparent to the server.
>
> Is there any other option?
>
> Am I right that option 2 is the best?
>
> Thank you for any comment.
>
> _______________________________________________
> 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/20151218/4acde095/attachment.htm>


More information about the zeromq-dev mailing list