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

cibercitizen1 cibercitizen1 at gmail.com
Wed Dec 23 12:00:19 CET 2015



I'm still thinking that the second option is better: to use a separate 
(and dedicated) dealer socket for each RPC
call.

1. Some easy experiments showed that it is possible to create as many as 
10000 sockets (in case anyone needs such amount).
This is slow, but they are created at startup time and reused, or you 
can create new sockets by demand, in case they are all in use (and
keep them to be reused)

2. The ROUTER (server side) does not need to be aware and coded to help 
supporting a RPC number (to match responses with requests).
This means that you can do RPC only with a library for the client 
(DEALER) and this will work with ANY existing server (ROUTER).

El 18/12/15 a las 11:09, Doron Somech escribió:
> 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 <mailto: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 <mailto: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/20151223/e8273e85/attachment.htm>


More information about the zeromq-dev mailing list