[nanomsg] Re: Req/Rep setup...

  • From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Wed, 20 Aug 2014 11:14:46 -0700

Indeed, if you're using anything more than a simple direct reply (receive
request, process, and reply) on the server side, you're going to find that
normal "REP" isn't going to work.  In that case, you can be exposed to the
envelope by using XREP instead.  Then the message you get has the envelope,
which you will include in your reply.  Simple REP is for simple cases, not
for more sophisticated processing like devices, deferral, etc.  (Basically,
with a REP socket, the server "caches" the envelope for you, but each time
you recv, that cached envelope is overwritten.  So you can't have more than
a single message received and processing at a time unless you use XREP, in
which case the state comes with the message instead of being cached.)


On Wed, Aug 20, 2014 at 11:08 AM, Soren Riise <sorenriise@xxxxxxxxxxx>
wrote:

> I was wondering how the Rep/Req setup would work with a server and
> multiple clients making requests, as there is nothing in the API which
> signals which client the server is replying to when it get a request.
>  However it looks like the API is keeping some internal state which make it
> kind of work.
>
> When Im saying kind of work, I mean it works as long as Im not trying to
> do anything fancy on the server side.    However if the server implement an
> event loop (or is MT) and the reply becomes a deferred operation resolved
> later, then there is no way of directing the reply back to the original
> client.
>
> c1      c2      server
> req1 ------------>defer -+
>         req2-----> +     |
>         res2<----- +     V
>                   req1 ready
>  <- - - - ?-- res1 +
>
>
> What I see is that the res1 actually goes to c2 instead of c1 which is
> probably caused by an internal global state of the connection set to be the
> last active connection.
>
> Is there an API for getting and setting the state of the connection on the
> server side so that the server can programmaticly solve this -- or is
> there are better solution for this?
>
> This is particularly a really bad problem for non-blocking programming
> which is common these days such as in nodejs.
>
>
>
>
>

Other related posts: