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 <[email protected]>
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
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
