Events emitted? about node-nanomsg HOT 5 OPEN

both bind and connect are blocking functions without completion events, i think.

@comick would know more about that but generally one should allow for about 50-100 milliseconds for the TCP handshakes and roundtrips to settle down, depends on distance or network conditions.

these are good questions probably not explained enough by the documentation. @ColorfullyMe, would you consider a making a PR to help document what's missing?

@nickdesaulniers or I (whoever is available) I'm sure would be happy to review a PR so we can finally document these mechanisms facilitating re-use of the module. these are fundamental.

error and message are probably the most notable. survey-timeout is more of an internal thing written at a time when the underlying nanomsg C library offered less support for the survey/respondent pattern. So I wouldn't worry about that event too much. While survey/respondent works, the fact that our socket prototype pattern diverges with an additional specific function for handling this pattern elsewhere in the code is definitely not cool. Inconsistency of implementation in the module's socket prototype methods only complicate matters and misguides users on what the hell is going on. We should try to be more consistent and I would love to see that area of the code improved.

if we could document more events with an example it'd be great, i.e., message would be cool like:

socket.on('message', callback);

function callback (msg) {
  // handle the msg parameter here
  // or msg param could be given to an anonymous function
  // instead of using this named declaration style 
}

from node-nanomsg.

@reqshark I am new to node-nanomsg but will love to consider making a PR when I know more deeply what happens here :)
What I was after with this question was to gather knowledge how to have some basic socket statistics. I wan to know how many connected sockets there are, IPs etc things like that. Drop some of them say if they fail some sort of initial authorization.
It looks that node-nanomsg does not support this but this seems to be related that nanomsg itself is lacking build in support for statistics. What do you suggest?

from node-nanomsg.

it might be possible to initialize the library in one of its debug mode varieties. There's a memory allocation debugging utility built into libnanomsg, NN_ALLOC_MONITOR. There may be more socket reporting information available as well, but I'm not sure how much documentation is available from libnanomsg. I'm sure the mailing list can help there. We would need to figure out a way to expose that over the binding

also btw, we just introduced a major update in node-nanomsg v2. we're now using streams instead of EventEmitter, so the recv api is different... though socket.send(msg) hasn't changed

from node-nanomsg.

FYI: I'm planning to rip out the NN_ALLOC_MONITOR facility.

from node-nanomsg.

cool thanks for the heads up @gdamore!

looks like you're simplifying things upstream and got rid of ebase too

from node-nanomsg.