[nanomsg] Re: REQ/REP worker example
- From: Ramakrishna Mallireddy <ramakrishna.malli@xxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Fri, 13 Jun 2014 13:52:58 +0530
Hi Drew,
Thanks for a quick reply, I have not looked into nn_device(). I will look
into it and revert back.
Thanks
R K
On Fri, Jun 13, 2014 at 11:13 AM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
wrote:
> Hi RK,
>
> You’re correct that “full-blown” (e.g. AF_SP) sockets don’t process more
> than one message at a time. So a REQ socket has at most one request
> outstanding, and same for REP. There has been talk about removing this
> limitation, and I think an API was agreed to, in principle, but there
> hasn’t been any implementation.
>
> Raw sockets (e.g. AF_SP_RAW) are sort of the superclass of an AF_SP
> socket, and they do not have this limitation. However they don’t have full
> functionality either, and so the application programmer would have to do
> more work to make them compatible with a standard sockets, particularly
> when a raw server tries to respond to a full client by using nn_send().
>
> In the absence of a better implementation for “multiflight” req/rep,
> you’re going to want to create a REP worker pool, where each REP socket in
> the pool runs on its own thread. This should be pretty straightforward
> since each REP worker is basically a synchronous REP implementation,
> exactly like the sample code.
>
> Then the question becomes how to assign a request to a particular worker.
> The simplest way is just to publish a list of your REP workers and the
> client REQ socket connects to all of them. In the standard configuration,
> the REQ socket knows how to choose some available REP socket it is
> connected to, to handle its request, so that is the end.
>
> However, you may not want to publish a list of all workers down to your
> clients, because you change them dynamically, or want to hide the server
> implementation details, etc. In this case you would set up a broker
> thread/process, that would know the details of your workers. And this
> broker process would receive client requests on a REP socket, and emit them
> on a REQ socket, and receive worker responses on its REQ socket that it
> then posts back to the client(s) on the REP socket. That worker-side REQ
> socket being connected to the complete pool of workers and since reqrep
> automagically knows how to choose an available REP socket from the sockets
> a REQ is connected to, then things just work.
>
> One problem. If the broker’s logic looked like this:
>
> int broker() {
> int req = nn_socket(NN_REQ,AF_SP);
> int rep = nn_socket(NN_REP,AF_SP);
> while(1) {
> nn_recv(REP,…);
> nn_send(REQ,…);
> nn_recv(REQ,…);
> nn_send(REP,…);
> }
> }
>
> …then the broker will only process one message at a time. This is because
> our hypothetical broker has the same limitation that you describe, e.g. it
> uses full-blown sockets, where only one request can be inflight at a time
> on either side.
>
> To solve this, nanomsg ships with a built-in broker, called nn_device().
> nn_device uses raw sockets, and allows messages to flow freely between the
> sockets, without limitations as to “one request at a time". Since
> nn_device does not actually handle any requests (but simply passes them to
> a socket where they are eventually handled by a full-blown socket), this
> avoid a lot of the problems that would arise if you tried to respond to
> client requests within the raw socket yourself by calling
> nn_send(my_raw_rep_socket,…);
>
> Drew
>
>
>
> On Jun 13, 2014, at 12:04 AM, Ramakrishna Mallireddy <
> ramakrishna.malli@xxxxxxxxx> wrote:
>
> > I am new to nanomsg and I am looking to implement a client/server
> service using REQ/REP.
> >
> > Server is a stateless service, but depends on another google service for
> reply to incoming requests. REP Service should be either asynchronous, so
> that it can handle other REQ requests in the queue while data gets ready
> form google service, or it should start workers[ideally from pool] to
> process REQ request in the queue.
> >
> > But I have not found any examples that does anyone of the above or may
> be I am missed some docs.
> >
> > The example req/rep is targeted at synchronous REP implementations.
> >
> > I am looking for, how to start a worker / create a pool of workers at
> service start and assign worker to each incoming request.
> >
> > Or, with asynchronous REP how can I send the reply to the
> appropriate/correct client/REQ when data gets ready.
> >
> > I have seen a thread regarding SP RAW that can be used, but not sure how
> it helps in my case.
> >
> > I appreciate any help or guidance.
> >
> > Thanks
> > R K.
> >
> >
>
>
>
Other related posts:
