Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Events emitted? #100

Open
kkartunov opened this issue Jul 10, 2015 · 5 comments
Open

Events emitted? #100

kkartunov opened this issue Jul 10, 2015 · 5 comments
Labels

Comments

@kkartunov
Copy link

Inspecting the code I spot those events that will be emitted:

  • survey-timeout
  • message
  • error
  • close
  1. Are there more?
  2. How can I be notified for connect event?
  3. What would be the road to go if I want to implement more events?
@reqshark
Copy link
Collaborator

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 
}

@kkartunov
Copy link
Author

@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?

@reqshark
Copy link
Collaborator

reqshark commented Aug 6, 2015

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

@gdamore
Copy link

gdamore commented Nov 23, 2016

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

@reqshark
Copy link
Collaborator

cool thanks for the heads up @gdamore!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants