Hello,
I agree with Doron here. Option is imo better and easier to implement.
+ Let the client generate a request idenfier (numbered, uuid, whatever
you prefer) and prepend it to request content.
+ The server simply copy that frame and prepend it to the response.
+ The client perform the match.
On Fri, Dec 18, 2015 at 11:09 AM, Doron Somech <[email protected]> wrote:
> 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
>
>
--
Kapp Arnaud - Xaqq
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev