[nanomsg] Re: Nanomsg - potential to boost

  • From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
  • To: omid shahraki <dreamstechgroup@xxxxxxxxx>
  • Date: Thu, 3 Nov 2016 12:59:09 -0700

It’s always better, IMO, to think in terms of problems you want to solve
first.  Thinking of possible patterns you might adapt nanomsg into is a fun
thought-experiment, but without a “business case” (or just use case) for
them, it seems of little merit.

Having concrete problems means that we can then discuss concrete solutions.

 - Garrett

On Thu, Nov 3, 2016 at 12:25 PM, omid shahraki <dreamstechgroup@xxxxxxxxx>
wrote:

Hi there,

I was thinking of facade pattern for nanomsg such as acceptor, connector,
reactor, proactor, leader/follower, timer-queue, etc.

I am not going to talk about details, architecture, strategy and policies
here as this is not the right moment to.

But, This is just the idea and we need to discuss and see if got value.
So, what do you think of?

Omid Shahraki
Omid.shahraki@xxxxxxx
On 1 Nov 2016 18:11, "SGSeven Algebraf" <a1rex2003@xxxxxxxxx> wrote:

Hi James!
I would like to thank you for your assistance and the code sample! It
helped me a lot. It clarified the concept of nn_poll and how it can be used
with the callback registration architecture.
I am sure it can help other developers.
Thank you,
Samuel

On Mon, Oct 31, 2016 at 1:34 PM, James Root <jamesroot@xxxxxxxxx> wrote:

As a follow up to this now that I have a few more minutes.. You could
build a callback architecture fairly simply with the following C-ish
pseudocode (sorry if formatting gets messed up):

    typedef void (*callback)(int socket);
    callback callbacks[N];
    callbacks[0] = first_callback;
    ...
    callbacks[N] = Nth_callback;

    struct nn_pollfd pfd[N];
    nn_pollfd[0].fd = socket;
    nn_pollfd[0].events = NN_POLLIN;
    ...

    while(1) {
        int rc = nn_poll(pfd, N, 2000 /* 2 seconds */);
        if (rc == 0) {
            // No sockets have pending data
            continue;
        }
        if (rc == -1) {
            // Error
            exit(1);
        }
        for (int i = 0; i < N; i++) {
            if (pfd[i].revents & NN_POLLIN) {
                callbacks[i](pfd[i].fd);
            }
        }
    }

You could expand this concept to create a callback registration
architecture pretty easily.

On Sun, Oct 30, 2016 at 9:24 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:

if you need to block in a single thread on multiple sockets then yes
nn_poll is probably the best way to do that.

having multiple protocols accessible on the same socket would be
nonsensical as they have very different semantics.  sorry.

Sent from my iPhone

On Oct 29, 2016, at 7:06 PM, SGSeven Algebraf <a1rex2003@xxxxxxxxx>
wrote:

Thank you James for your email!

What I am trying to achieve is the blocking wait on multiple messages
types in the same thread.

What would be the most convenient is what Garrett stated on Wed, 11 May
2016 :

"I hope to have a different, and superior, notification mechanism

involving callbacks that the application can register"

Indeed, that would be a huge, colossal breakthrough in terms of
the convenience and modern approach.

Thank you,

- Samuel




On Sat, Oct 29, 2016 at 9:17 PM, James Root <jamesroot@xxxxxxxxx> wrote:

Samuel,

I believe the best way to achieve what you are looking for is nn_poll (
http://nanomsg.org/v1.0.0/nn_poll.3.html). You store your sockets in a
way that you can look up what type they are when nn_poll tells you they are
ready.

I believe the reason a socket cannot have multiple types is because
many (all?) of the types are fundamentally different. For example, a reply
socket could never be paired with a sub socket (because you can never send
on the sub socket).

I hope this helps you!

- James Root

On Sat, Oct 29, 2016 at 8:44 PM, SGSeven Algebraf <a1rex2003@xxxxxxxxx>
wrote:

Being new to nanomsg I am not accustom yet how things work.

A few questions follows:

1)  The documentation says that I can call *nn_bind* and *nn_connect*
multiple times on the same socket .

s = nn_socket (AF_SP, NN_PAIR);

eid1 = nn_connect (s, "inproc://test");

eid2 = nn_connect (s, "tcp://127.0.0.1:5560");

Is there a way to know which endpoint sent a message (eid1 or eid2)
when I receive it by:

nn_recv (s, &buf, NN_MSG, 0);

?


2) I guess that I cannot mix different SP protocols on the same socket
and have to setup different threats for every socket type.


It would be potentially beneficial if  *nn_receive* could get a
message

a) from multiple nanomsg sockets (potentially configured with
different protocols) :

nn_recv_from_sockets (*socketArray,* &buf, NN_MSG, 0);

or

b) from different protocols

I guess what I need for case  b) is:

s = nn_socket (AF_SP, *NN_ALL*);

// or

s = nn_socket (AF_SP, *NN_SUB | NN_PAIR*);

or alternatively forcing *nn_receive* to receive from different SP
senders

nn_recv (s, &buf, NN_MSG, 0, *NN_ALL)*;

Another way to be able to receive from different SP could be a

nn_recv (s, &buf, NN_MSG, 0, *NN_SUB | NN_PAIR*);


(*nn_sen*d could indicate used protocol by having an extra parameter)


Is there any way or potential benefits to provide the mentioned above
functionalities or am I misguided?


Thank you,

- Samuel






Other related posts: