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

net: check EADDRINUSE after binding localPort #15097

Closed
wants to merge 2 commits into from

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Aug 30, 2017

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

Fixes: #15084

See the comments of checkBindError for details.

Affected core subsystem(s)

net, test

@nodejs-github-bot nodejs-github-bot added the net Issues and PRs related to the net subsystem. label Aug 30, 2017
@joyeecheung
Copy link
Member Author

@jasnell
Copy link
Member

jasnell commented Aug 30, 2017

What should the semver-iness of this be?

const net = require('net');

const server1 = net.createServer(common.mustNotCall());
server1.listen(common.PORT, '127.0.0.1', common.mustCall(() => {
Copy link
Member

Choose a reason for hiding this comment

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

Can we avoid using common.PORT? If not I think it's better to move this test to sequential.

@@ -0,0 +1,26 @@
'use strict';

// This tests that net.connect() from a used local port throws EADDRINUSE.
Copy link
Contributor

Choose a reason for hiding this comment

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

👍
It makes me happy to see a new test with a description.

const net = require('net');

const server1 = net.createServer(common.mustNotCall());
server1.listen(common.PORT, '127.0.0.1', common.mustCall(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

You should use common.localhostIPv4

const server2 = net.createServer(common.mustNotCall());
server2.listen(common.PORT + 1, '127.0.0.1', common.mustCall(() => {
const client = net.connect({
host: server1.address().address,
Copy link
Contributor

Choose a reason for hiding this comment

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

common.localhostIPv4 here as well because of #14900

const server1 = net.createServer(common.mustNotCall());
server1.listen(common.PORT, '127.0.0.1', common.mustCall(() => {
const server2 = net.createServer(common.mustNotCall());
server2.listen(common.PORT + 1, '127.0.0.1', common.mustCall(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

If you're doing common.PORT + 1 this test should be in /test/sequential

@refack
Copy link
Contributor

refack commented Aug 30, 2017

What should the semver-iness of this be?

Tricky one... but IMHO patch. The previous behaviour was "working but not as expected" in that in the case of error it ignored the provided option.

@joyeecheung
Copy link
Member Author

@lpinca @refack Thanks for the review. Updated, PTAL.

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

@joyeecheung
Copy link
Member Author

@jasnell I would say it's a patch since it never worked anyway...to me depending on the "bind to that port if available, otherwise bind to a random port" behavior seems like a bug.

@refack
Copy link
Contributor

refack commented Aug 31, 2017

@joyeecheung I've added a commit that uses common.localhostIPv4 as the addressed for connecting as well, since server1.address().address can't be "trusted". If it returns '0.0.0.0' or '::' (even though it shouldn't) this will fail on Windows, and since this is not the subject of the test, why risk it?
Obviously feel free to push my suggestion out.

@joyeecheung
Copy link
Member Author

@refack Ah, makes sense to me, sorry that I overlooked #15097 (comment) .

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

BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Sep 3, 2017
PR-URL: nodejs#15097
Fixes: nodejs#15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@BridgeAR
Copy link
Member

BridgeAR commented Sep 3, 2017

Landed in c419adf

@BridgeAR BridgeAR closed this Sep 3, 2017
addaleax pushed a commit to addaleax/ayo that referenced this pull request Sep 5, 2017
PR-URL: nodejs/node#15097
Fixes: nodejs/node#15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@MylesBorins
Copy link
Contributor

This is not landing cleanly on v8.x. @joyeecheung would you be willing to backport to v8.x-staging

joyeecheung added a commit to joyeecheung/node that referenced this pull request Sep 10, 2017
PR-URL: nodejs#15097
Fixes: nodejs#15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@joyeecheung
Copy link
Member Author

@MylesBorins Backport opened at #15309

MylesBorins pushed a commit that referenced this pull request Sep 10, 2017
PR-URL: #15097
Fixes: #15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Sep 10, 2017
MylesBorins pushed a commit that referenced this pull request Sep 11, 2017
PR-URL: #15097
Fixes: #15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
MylesBorins pushed a commit that referenced this pull request Sep 11, 2017
PR-URL: #15097
Fixes: #15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
MylesBorins pushed a commit that referenced this pull request Sep 12, 2017
PR-URL: #15097
Fixes: #15084
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@MylesBorins
Copy link
Contributor

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

@joyeecheung
Copy link
Member Author

Depends on #11796 which is don't-land-on-v6.x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
net Issues and PRs related to the net subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

tcp socket localPort option does not work
9 participants