REQREP: How to really have multiple server instances?

[metadings]

The examples I found on the internet always have one instance to REPly on REQuests. When I tried an example (sorry not pure C, but C#) and I spawn more than 1 reply server, there is always the Address in use [100] (transports\tcp\btcp.c:378) (currently have a nanomsg build 0.3-beta). I also tried to use a mutex, released directly after ReceiveStream but this results in the same error.

How to have multiple reply services, which bind to the same port for requests, but "accept" and work to reply on another port (so that while working, the next worker can pickup following requests)?

[ramki1979]

May be this might be useful for you,
Use nn_device, I have done the same thing in C. Check post on the same
subject "REQ/REP worker example" and community answers and the final
working example on pastebin.

Note: IPC didn't worked, TCP worked.

On Sunday, June 29, 2014, metadings notifications@github.com wrote:

The examples I found on the internet always have one instance to REPly on
REQuests. When I tried an example (sorry not pure C, but C#) and I spawn
more than 1 reply server, there is always the "Address in use 100"
(currently have a nanomsg build 0.3). I also tried to use a mutex, released
directly after ReceiveStream but this results in the same error.

How to have multiple reply services, which bind to the same port for
requests, but "accept" and work to reply on another port (so that while
working, the next worker can pickup following requests)?

—
Reply to this email directly or view it on GitHub
#271.

[metadings]

Messing with Google I found three pastes, but they are full of "I tried here and I'm waiting forever there".

http://pastebin.com/rqpdaQmH "nanomsg REP/REQ example with threads"
http://pastebin.com/GQq6vPkX "nanomsg REP/REQ example with threads client code"
http://pastebin.com/j8naGfuD "nanomsg REP/REQ example with threads"
http://pastebin.com/3JL2Y7wh "nanomsg REP/REQ example with threads"

Which do you refer to?

[metadings]

It's weird trying to bind and connect around. It should be easier.
It should be that we spawn some REP workers, all binding on one port and when a REQ comes in, the first REP is dispatched and the next worker is going to wait on the next REQ. Just like in HTTP, port 80 is just a door in and answers go another door out.

Wait: I'm really impressed how easy it was to compile nanomsg-0.4-beta (sadly I'm just on Win x86)!

I'm now going to bind myself on a walk around the city, I hope someone starts a connect. ARGH

[ramki1979]

Out of the four one is client code [ http://pastebin.com/GQq6vPkX ] and
other are for server.

Use the latest one [http://pastebin.com/rqpdaQmH], and as I mentioned IPC
din't worked and TCP worked, so Just replace "ipc" end-point with "tcp"
end-point accordingly and
just ignore the comments.

On Sun, Jun 29, 2014 at 8:27 PM, metadings notifications@github.com wrote:

Messing with Google I found three pastes, but they are full of "I tried
here and I'm waiting forever there".

http://pastebin.com/rqpdaQmH "nanomsg REP/REQ example with threads"
http://pastebin.com/GQq6vPkX "nanomsg REP/REQ example with threads client
code"
http://pastebin.com/j8naGfuD "nanomsg REP/REQ example with threads"
http://pastebin.com/3JL2Y7wh "nanomsg REP/REQ example with threads"

Which do you refer to?

—
Reply to this email directly or view it on GitHub
#271 (comment).

[ramki1979]

I have to mention that using "nn_device" was easy but due to some issues on
my OS X[ I was still new to this OS], I was not able to fix IPC end-point.

Logically "nn_device" should be bind to the end-points. Client and Server
workers should connect to the "nn-device" respective end-points,
but as I was not able to get IPC worked, I just tried connect on
"nn_device"[even though I know It's wrong].

I hope this will help the comment in the sample code which confuses others.

On Sun, Jun 29, 2014 at 9:56 PM, Ramakrishna Mallireddy <
ramakrishna.malli@gmail.com> wrote:

Out of the four one is client code [ http://pastebin.com/GQq6vPkX ] and
other are for server.

Use the latest one [http://pastebin.com/rqpdaQmH], and as I mentioned IPC
din't worked and TCP worked, so Just replace "ipc" end-point with "tcp"
end-point accordingly and
just ignore the comments.

On Sun, Jun 29, 2014 at 8:27 PM, metadings notifications@github.com
wrote:

Messing with Google I found three pastes, but they are full of "I tried
here and I'm waiting forever there".

http://pastebin.com/rqpdaQmH "nanomsg REP/REQ example with threads"
http://pastebin.com/GQq6vPkX "nanomsg REP/REQ example with threads
client code"
http://pastebin.com/j8naGfuD "nanomsg REP/REQ example with threads"
http://pastebin.com/3JL2Y7wh "nanomsg REP/REQ example with threads"

Which do you refer to?

—
Reply to this email directly or view it on GitHub
#271 (comment).

[metadings]

No it just keeps confusing, weird and annoying.

Has anyone a working example of multiple worker threads REPlying on multiple REQuest threads?

[ramki1979]

please ignore the comments completely and just see the code and replace ipc
end-point with tcp endpoint.

I have an oauth2 service running with the same code, as I don't want to
post the complete code, there were some comments left there(I forgot to
remove) which doesn't have any relation to nanomsg use case. sorry for
that, but once you remove all the comments, then its plain nanomsg example.

If you still confuse i.e even after removing comments from the code, then I
strongly suggest to read the nanomsg documentation.

On Sun, Jun 29, 2014 at 11:20 PM, metadings notifications@github.com
wrote:

No it just keeps confusing, weird and annoying.

Has anyone a working example of multiple worker threads REPlying on
multiple REQuest threads?

—
Reply to this email directly or view it on GitHub
#271 (comment).

[ramki1979]

Ok, I have updated the example,

http://pastebin.com/XfBrqXPA

On Sun, Jun 29, 2014 at 11:49 PM, Ramakrishna Mallireddy <
ramakrishna.malli@gmail.com> wrote:

please ignore the comments completely and just see the code and replace
ipc end-point with tcp endpoint.

I have an oauth2 service running with the same code, as I don't want to
post the complete code, there were some comments left there(I forgot to
remove) which doesn't have any relation to nanomsg use case. sorry for
that, but once you remove all the comments, then its plain nanomsg example.

If you still confuse i.e even after removing comments from the code, then
I strongly suggest to read the nanomsg documentation.

On Sun, Jun 29, 2014 at 11:20 PM, metadings notifications@github.com
wrote:

No it just keeps confusing, weird and annoying.

Has anyone a working example of multiple worker threads REPlying on
multiple REQuest threads?

—
Reply to this email directly or view it on GitHub
#271 (comment).

[metadings]

Yeah, also had some issues because of MemoryStream Seek, WriteTo, Flush and Close resulting in nonsense exceptions.

Now it's doing a good job, so far I can see. Thanks for your help!

It is now as follows:

1. Create a RAW REP Socket, bind it to port 4444.
2. Create a RAW REQ Socket, bind it to port 4445.
3. Create and start a thread for the device to combine both sockets.
4. Create and start worker threads, with REP sockets, which connect to 4445.
5. Create client threads, with REQ sockets, which connect to 4444.

A bit of confusing is also the difference in (NNanomsg) SendStream/SendStreamImmediate and ReceiveStream/ReceiveStreamImmediate: The *Immediate methods are using NN_DONTWAIT, and I ended up using these methods inside of polling callbacks (receiving the REQuest, receiving the REPly), and the non-Immediate methods when I'm sending the REQuest, sending the REPly.

Now I'm just missing a nn_device which takes a timeout, so I can poll and break without having to kill it using NN.Term.

Also have a look for the example: mhowlett/NNanomsg#14 (comment)