[nanomsg] Re: Req/Rep setup...
- From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Fri, 22 Aug 2014 08:47:01 -0700
You use AF_SP_RAW when you create the socket. This gives you an XREP
socket. The code for this is in src/protocols/xrep.c REP sockets (cooked
mode) are built on top of XREP sockets.
On Fri, Aug 22, 2014 at 8:42 AM, Soren Riise <sorenriise@xxxxxxxxxxx> wrote:
> 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:
