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

dgram: instantiate socket on creation #5496

Closed
Trott opened this issue Feb 29, 2016 · 6 comments
Closed

dgram: instantiate socket on creation #5496

Trott opened this issue Feb 29, 2016 · 6 comments
Labels
dgram Issues and PRs related to the dgram subsystem / UDP. libuv Issues and PRs related to the libuv dependency or the uv binding. semver-major PRs that contain breaking changes and should be released in the next major version.

Comments

@Trott
Copy link
Member

Trott commented Feb 29, 2016

In Node 5.7.0 and all currently-supported previous versions, it is possible to try to trigger an exception (EBADF) with code such as this:

var dgram = require('dgram');

var socket = dgram.createSocket('udp4');
socket.setTTL(1);

As @saghul explains in #5023, this is because dgram instantiates the socket lazily with uv_udp_init(). If uv_udp_init_ex() were used instead, then the socket could be created and ready for the various .set* functions upon creation.

Such a change would probably be semver-major because createSocket() might throw whereas currently that is not the case.

There are probably loads of other dangers and considerations. (I'm opening this issue so that the discussion can be had independently of the PR linked above, which is a relatively minor and safe change to a test file. This, on the other hand, would be a much bigger deal...)

@Trott Trott added dgram Issues and PRs related to the dgram subsystem / UDP. semver-major PRs that contain breaking changes and should be released in the next major version. libuv Issues and PRs related to the libuv dependency or the uv binding. labels Feb 29, 2016
@mscdex
Copy link
Contributor

mscdex commented Feb 29, 2016

What about lazily setting those options like what is currently done with net.Socket and socket.setKeepAlive(), and socket.setNoDelay()?

@saghul
Copy link
Member

saghul commented Feb 29, 2016

That would be unnecessary. An interesting bonus is that if the system runs
out of file descriptors it blows up on socket creation, not in some weird
place like bind.

On Tue, Mar 1, 2016 at 12:20 AM, Brian White [email protected]
wrote:

What about lazily setting those options like what is currently done with
net.Socket and socket.setKeepAlive(), and socket.setNoDelay()?


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

/Saúl
bettercallsaghul.com

@jasnell
Copy link
Member

jasnell commented May 30, 2017

@Trott... does this need to stay open?

@Trott
Copy link
Member Author

Trott commented May 30, 2017

@jasnell AFAIK, it should stay open, but the expert here is @saghul so let's ask them.

@cjihrig cjihrig mentioned this issue Jun 12, 2017
4 tasks
@cjihrig
Copy link
Contributor

cjihrig commented Jul 12, 2017

Making this change seems to be more involved than I originally thought. We would now need to pass the socket type to UDPWrap::UDPWrap(). It works fine in the normal case, but blows up when invoked via UDPWrap::Instantiate(). If it's not possible to pass a value through, then we could default to AF_UNSPEC, but that would just give us the existing behavior. Maybe @indutny could comment.

@Trott
Copy link
Member Author

Trott commented Dec 27, 2017

I'm going to close this as "sure, could be improved, but not really a bug, it's async, that's the way it is"... But feel free to re-open or comment if you think that's the wrong move.

@Trott Trott closed this as completed Dec 27, 2017
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. libuv Issues and PRs related to the libuv dependency or the uv binding. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

No branches or pull requests

5 participants