[nanomsg] Re: Req/Rep setup...
- From: Soren Riise <sorenriise@xxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Fri, 22 Aug 2014 16:42:00 +0100
That makes sense, however in nanomsg there is no interfaces for dealing with
raw sockets for req/rep.
There is an mailing list thread back from last year which proposes nn_req_send
and nn_req_recv as extra APIs which deals with exactly this situation, however
looking at the git-pull of v0.4 those functions just stubs out and calls
nn_assert(0) .. so no luck. Also there are no examples, unit test or other
code which I could find dealing with this, so I assume this is unsolved.
So my only solution for now is really to serialize the recv and the send on the
server side.
I was hoping to write part of my application in nodejs, but using that there is
NO WAY you can control serialization in nodejs as all IO work is done in
background threads -- so I have to abolish this, and for now just write it in
C/C++ as a single threaded server.
It would be great if anybody have more pointers.
Soren
________________________________
From: Max Mertens <max.mail@xxxxxxxxxx>
To: nanomsg@xxxxxxxxxxxxx
Sent: Thursday, August 21, 2014 9:20 AM
Subject: [nanomsg] Re: Req/Rep setup...
Hi there,
AFAIK in ZeroMQ (something like the C++ variant or predecessor of
nanomsg) these sockets are called XREQ and XREP.
In nanomsg you just call these sockets *raw* REQ and REP sockets.
You create them using AF_SP_RAW instead of AF_SP when invoking
nn_socket:
int sock = nn_socket (AF_SP, NN_REQ); /* regular REQ socket */
int raw_sock = nn_socket (AF_SP_RAW, NN_REQ); /* raw REQ (XREQ)
socket */
For more information about this see: http://nanomsg.org/v0.4/nn_socket.3.html
Max
On 20.08.2014 23:55, Garrett D'Amore wrote:
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:
