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

Arnaud Kapp kapp.arno at gmail.com
Fri Dec 18 12:06:43 CET 2015


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 <somdoron at gmail.com> 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 <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
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 
Kapp Arnaud - Xaqq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20151218/7339bfc5/attachment.htm>


More information about the zeromq-dev mailing list