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

doc: clarify when 'listening' event is emitted #23959

Closed
wants to merge 1 commit into from

Conversation

dsinecos
Copy link
Contributor

Clarify that the 'listening' event for a UDP socket in NodeJS is emitted when the
underlying OS socket is created.

This occurs when either socket.send() or socket.bind()
are first invoked for the respective socket.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added dgram Issues and PRs related to the dgram subsystem / UDP. doc Issues and PRs related to the documentations. labels Oct 29, 2018
doc/api/dgram.md Outdated
The `'listening'` event is emitted on the first invocation of either `socket.send()`
or `socket.bind()` for the respective socket.

While the sockets are addressable immediately after creation using
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by "addressable"? #23952 (comment) shows the socket not having an address until the send or bind.

Copy link
Contributor Author

@dsinecos dsinecos Oct 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam-github I meant that we have a socket object (returned by dgram.createSocket) on which we can attach listeners so its addressable in that sense. However Node.js creates the underlying OS socket only after send or bind are invoked. I did not mean addressable in the sense of the socket having an address.

Now I can see how using addressable introduces ambiguity.

I was thinking to rephrase as follows

"While the different socket methods can be invoked immediately after creation using dgram.createSocket, Node.js doesn't create the underlying OS socket until ..."

But I'm a little confused because some socket methods can be used such as attaching listeners, setTTL etc, others such as socket.address() would throw an error until the underlying OS socket is created.

Let me know if you have any suggestions on the rephrasing and if my understanding is correct.

Thanks :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"addressable" means "has an address", and it doesn't yet have an address.

Its confusing in the docs for this API that there is an OS object called a "socket" and a Javascript class dgram.Socket that is also sometimes called a "socket". This problem pre-exists, but maybe you can avoid using the ambiguous "socket" terminology.

I would suggest something like:

The listening event is emitted once the dgram.Socket is addressable and can receive data. This happens either explicitly with socket.bind() or implicitly the first time data is sent using socket.send(). Until the dgram.Socket is listening the underlying system resources do not exist, and calls such as socket.address() and socket.SetTTL() will fail.

Also, it would be helpful for each method that cannot be called until the socket is listening to explicitly mention that in its documentation.

Copy link
Contributor Author

@dsinecos dsinecos Nov 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sam-github I was thinking to remove the second para entirely (if the ambiguity cannot be removed) and leave just the first sentence which clarifies when the 'listening' event is emitted

"The 'listening' event is emitted on the first invocation of either socket.send()
or socket.bind() for the respective socket"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what you mean by "ambiguity". Your single sentence lacks information useful to the API user, information which was in my suggestion. If you don't want to do this, that's OK, I'll PR a follow up sometime to expand the docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsinecos In the interest of progress, how about we do that (remove the second paragraph), land this PR with just the one sentence changed, and then if you wish, you can open a second PR with this second paragraph added back in and it can be discussed/improved in that second PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Trott That sounds good. Allow me a couple of days. I'll make the suggested changes and update the PR. Thanks :)

doc/api/dgram.md Outdated
or `socket.bind()` for the respective socket.

While the sockets are addressable immediately after creation using
`dgram.createSocket()` NodeJS doesn't create the underlying OS socket until the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit:

Suggested change
`dgram.createSocket()` NodeJS doesn't create the underlying OS socket until the
`dgram.createSocket()` Node.js doesn't create the underlying OS socket until the

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I'll update this :)

@Trott
Copy link
Member

Trott commented Nov 20, 2018

@dsinecos Still working on this?

@dsinecos
Copy link
Contributor Author

@Trott On the point that @sam-github raised, I have posted some alternatives I could think of.

I'd like some comments on that to move forward

@sam-github
Copy link
Contributor

It looks like the last comments were mine, and there are no changes or comments since then. I think this is waiting on @dsinecos to move forward.

@dsinecos
Copy link
Contributor Author

@sam-github I've commented with some alternatives based on the query you raised. Let me know your thoughts on that. I'll update the PR accordingly

Clarify that the `'listening'` event is emitted when the
underlying OS socket is created

This occurs when either `socket.send()` or `socket.bind()`
are first invoked for the respective socket.

Fixes: nodejs#23952
@dsinecos
Copy link
Contributor Author

The build says it's failing on the commit message guidelines. I'm not able to notice the error I've made in the commit message. Please suggest :)

@Trott
Copy link
Member

Trott commented Nov 30, 2018

The build says it's failing on the commit message guidelines. I'm not able to notice the error I've made in the commit message. Please suggest :)

Commit message is probably fine. GitHub API is throttling us. (I believe there is a PR somewhere to work around the GitHub API limitations.)

@Trott
Copy link
Member

Trott commented Nov 30, 2018

/ping @sam-github LGTY?

The `'listening'` event is emitted whenever a socket begins listening for
datagram messages. This occurs as soon as UDP sockets are created.
The `'listening'` event is emitted on the first invocation of either `socket.send()`
or `socket.bind()` for the respective socket.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be clearer?

The `'listening'` event is emitted whenever a socket begins listening for
datagram messages. This corresponds to the first invocation of either
`socket.send()` or `socket.bind()` for the respective socket.

@lundibundi
Copy link
Member

ping @sam-github @dsinecos

doc/api/dgram.md Outdated
The `'listening'` event is emitted on the first invocation of either `socket.send()`
or `socket.bind()` for the respective socket.

While the sockets are addressable immediately after creation using
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"addressable" means "has an address", and it doesn't yet have an address.

Its confusing in the docs for this API that there is an OS object called a "socket" and a Javascript class dgram.Socket that is also sometimes called a "socket". This problem pre-exists, but maybe you can avoid using the ambiguous "socket" terminology.

I would suggest something like:

The listening event is emitted once the dgram.Socket is addressable and can receive data. This happens either explicitly with socket.bind() or implicitly the first time data is sent using socket.send(). Until the dgram.Socket is listening the underlying system resources do not exist, and calls such as socket.address() and socket.SetTTL() will fail.

Also, it would be helpful for each method that cannot be called until the socket is listening to explicitly mention that in its documentation.

doc/api/dgram.md Outdated
The `'listening'` event is emitted on the first invocation of either `socket.send()`
or `socket.bind()` for the respective socket.

While the sockets are addressable immediately after creation using
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what you mean by "ambiguity". Your single sentence lacks information useful to the API user, information which was in my suggestion. If you don't want to do this, that's OK, I'll PR a follow up sometime to expand the docs.

@BridgeAR
Copy link
Member

@dsinecos I am very sorry that this PR seems to have been overlooked at some point. It is some times difficult to keep up with the amount of changes.

Would you still be interesting in following up on the comments?

@dsinecos
Copy link
Contributor Author

@Trott @sam-github @BridgeAR @lundibundi I'm sorry I missed the last few updates here. I'll not be able to work on this PR at the moment and cannot say for sure when I'll be able to pick it back up. Let me know if I should close it.

@HarshithaKP
Copy link
Member

@dsinecos, Will you be able to progress on this PR now ? If not I would like to pick this up.

@dsinecos
Copy link
Contributor Author

@HarshithaKP Please go ahead.

@HarshithaKP HarshithaKP mentioned this pull request Mar 31, 2020
4 tasks
@HarshithaKP
Copy link
Member

This can be closed as the intention is fulfilled in #32581.

@Trott Trott closed this Apr 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. doc Issues and PRs related to the documentations.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants