dgram: default send address to 127.0.0.1 or ::1

[mcollina]

Pull Request check-list

• Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
  this change (including linting)?
• Is the commit message formatted according to [CONTRIBUTING.md][0]?
• If this change fixes a bug (or a performance problem), is a regression
  test (or a benchmark) included?
• Is a documentation update included (if this change modifies
  existing APIs, or introduces new ones)?

Affected core subsystem(s)

dgram

Description of change

In net we default to 'localhost' as the default address for connect.
Not doing the same on dgram is confusing, because sending to 0.0.0.0
works on Linux/OS X but not on Windows. Defaulting that to 127.0.0.1 /
::1 addresses that.

Related: #5407
Related: #5398

Fixes: #5487

cc @mafintosh@rvagg@cjihrig@saghul@feross@silverwind

[silverwind]

This does include a bind change too, is that intentional? I'd suggest doing that in a separate PR.

[mcollina]

@silverwind yes. Both send and bind use the same defaults in the lookup functions: they need to be different. I thought to include the additional ifs in the bind call, given the fact that send is a hot path.

[silverwind]

Ah, alright, misread that change. I think you can do '::' instead of '::0' by the way.

[mafintosh]

before re-reading the docs last week i thought it already worked like this so big +1 from me.

[saghul]

Since this will be a semver-major, can we make the address in send mandatory?

[silverwind]

can we make the address in send mandatory?

I'm not opposed to this, but if we do that, we need to do it in net too where it's also optional.

[mcollina]

@mafintosh do you think that defining it as semver-major is too strict? Given that's how people use this, should it be semver-minor?

@saghul@silverwind I think those needs to be two separate fixes. To remove the default from net and dgram would cause a lot of modules/applications tests to start failing. I'm ok for removing the default in v7/v8, but not in v6 as it will be an LTS (and a lot of people will jump on that when it comes out, given that it will be "the" LTS version).

[saghul]

I'm not opposed to this, but if we do that, we need to do it in net too where it's also optional.

There is no send in net. Stream sockets are connected, so the target is already "fixed", aka, the other side. In datagram sockets, you can select the target for each datagram. They are different and they already behave different.

[mcollina]

I'm not opposed to this, but if we do that, we need to do it in net too where it's also optional.

There is no send in net. Stream sockets are connected, so the target is already "fixed", aka, the other side. In datagram sockets, you can select the target for each datagram. They are different and they already behave different.

There is net.connect(port [, address]), which defaults to localhost. IMHO, having a default for address in net.connect() is really similar to one for socket.send in dgram.

[saghul]

Ouch. Yeah, IMHO that should be mandatory too. The only place where it's ok
for it to be optional is bind, I'd say.

On Mon, Feb 29, 2016 at 10:59 PM, Matteo Collina notifications@github.com
wrote:

I'm not opposed to this, but if we do that, we need to do it in net too
where it's also optional.

There is no send in net. Stream sockets are connected, so the target is
already "fixed", aka, the other side. In datagram sockets, you can select
the target for each datagram. They are different and they already behave
different.

There is net.connect(port [, address]), which defaults to localhost.
IMHO, having a default for address in net.connect() is really similar to
one for socket.send in dgram.

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

/Saúl
bettercallsaghul.com

[Trott]

I would expect test/parallel/test-dgram-send-default-host.js to fail linting for removing the timer declaration but keeping a use of timer elsewhere in the test.

[mcollina]

@Trott no, lint passes. Good spot, I've updated the tests.

@saghul I agree with you that net.connect() and dgram.send() should not had a default to localhost in the first place. However, everybody uses those defaults, so it will cause a major disruption, and I am not sure it is worth it in the first place. I'm generally ok in such a change, but the impact on the community needs to be evaluated (not sure we have the means though).

Can I get a bunch of LGTM (or comments) so we land this?

Also, given that the intended behavior of send would have been to send the message to localhost anyway, can we consider this semver-minor?

[saghul]

Can you make this "::" ?

[saghul]

LGTM with a bit.

[mcollina]

CI: https://ci.nodejs.org/job/node-test-pull-request/1804/

[silverwind]

LGTM. Regarding semver: what does a send to 0.0.0.0 actually do when you have multiple interfaces? Does it send/receive a datagram on each?

[mcollina]

The behavior that I am seeing is: it just picks one of the interfaces on Linux and OS X, normally localhost. On Windows nothing is received.

[silverwind]

I'd say this is patch level commit if it's been going to localhost on most OSs.

[mcollina]

@saghul I've got a test failure on ARM with the '::' IPv6 address, I'll try again with '::0'. https://ci.nodejs.org/job/node-test-binary-arm/1244/RUN_SUBSET=3,nodes=pi1-raspbian-wheezy/tapTestReport/test.tap-29/

Restarted as https://ci.nodejs.org/job/node-test-pull-request/1831/.

[mcollina]

@rvagg any idea why these builds are failing? https://ci.nodejs.org/job/node-test-pull-request/1831/https://ci.nodejs.org/job/node-test-pull-request/1832

[silverwind]

@mcollina did you check that CERTIFY_SAFE box? See nodejs/build#342 (comment)

[mcollina]

Let's try again: https://ci.nodejs.org/job/node-test-pull-request/1845/ :)

[mcollina]

Skipping the dgram6 tests if ipv6 is not supported: https://ci.nodejs.org/job/node-test-pull-request/1846/.

[mcollina]

CI, again: https://ci.nodejs.org/job/node-test-pull-request/1848/

[mcollina]

Thanks @silverwind, that did the trick.

Any other opinion on the semver level? I think semver-minor or even patch are good: the behavior we are changing is broken in the affected OS. I'm changing this to patch, and I propose we don't land this in LTS anyway (just in case).

Any other opinion, lgtm or anything else before I land?

[mcollina]

I see two failed tests on OSX, but I can't open them https://ci.nodejs.org/job/node-test-commit-osx/2500/nodes=osx1010/

[silverwind]

Getting gateway timeouts too. The failures look unrelated, here they are from the plaintext output:

not ok 1049 test-stringbytes-external-exceed-max.js
# TIMEOUT
---
duration_ms: 61.404
not ok 1053 test-stringbytes-external-exceed-max-by-1-hex.js
# TIMEOUT
---
duration_ms: 60.940

[mcollina]

Landed in 8af4bb8.