[nanomsg] Re: Req/Rep setup...
- From: Soren Riise <sorenriise@xxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 20 Aug 2014 22:13:38 +0100
Thanks that makes sense.
XREP/XRES does not look like they are included by default -- Is that due to
that it is "work in progress"?
Soren
________________________________
From: Garrett D'Amore <garrett@xxxxxxxxxx>
To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
Sent: Wednesday, August 20, 2014 11:14 AM
Subject: [nanomsg] Re: Req/Rep setup...
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:
