[nanomsg] Re: Req/Rep setup...
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 20 Aug 2014 14:55:02 -0700
No they are there. I may be misrecalling how to use them in the C library. In
my go implementation they are used with those names. In libnanomsg you should
probably look for raw mode.
Sent from my iPhone
> On Aug 20, 2014, at 2:13 PM, Soren Riise <sorenriise@xxxxxxxxxxx> wrote:
>
> 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:
