Random port: 0 doesn’t work on Node 0.12.0

[jeffreydwalter]

gruntjs/grunt-contrib-connect#126

See the above issue link in the gruntjs project for details. This was apparently an issue in node v0.11.0, but no one filed it in the node project because v0.11.x was the experimental branch. This issue is now appearing in node v0.12.0.

To be clear, this issue doesn't appear to be an issue with gruntjs because I am seeing it in a completely different context in a project using the node-spdy library, which doesn't use gruntjs at all.

[trevnorris]

Can you tell me your OS? I'm not seeing this issue on Linux:

> process.version
'v0.12.1-pre'
> net.createServer().listen(0).address().port
48225

[jeffreydwalter]

Sure, I'm running OSX 10.10.1. I haven't tested on Linux.

Did you happen to try the test that's in the link I pasted? I'd be curious to see if it passes on Linux.

[amir-s]

I dont have any problems in my Mac.

> process.version
'v0.12.0'
> net.createServer().listen(0).address().port
53114

[cjihrig]

Without a stack trace, it's more difficult to say, but I'm guessing that the portscanner module used by grunt-contrib-connect is doing something like this:

require('net').createConnection({port: 0});

[mzgoddard]

I don't think this is a bug in node. This is a bug in grunt-contrib-connect and its use of node-portscanner by passing the 0 value as the port to start searching at. Sorry for the noise.

For clarity here is the related stack trace.

RangeError: port should be > 0 and < 65536: 0
    at Socket.connect (net.js:901:13)
    at Socket.connect (net.js:847:37)
    at Object.portscanner.checkPortStatus (/Users/zen/Code/grunt-contrib-connect/node_modules/portscanner/lib/portscanner.js:107:10)
    at checkNextPort (/Users/zen/Code/grunt-contrib-connect/node_modules/portscanner/lib/portscanner.js:124:17)
    at Object.async.until (/Users/zen/Code/grunt-contrib-connect/node_modules/portscanner/node_modules/async/lib/async.js:576:13)
    at findAPortWithStatus (/Users/zen/Code/grunt-contrib-connect/node_modules/portscanner/lib/portscanner.js:139:9)
    at Object.portscanner.findAPortNotInUse (/Users/zen/Code/grunt-contrib-connect/node_modules/portscanner/lib/portscanner.js:42:3)
    at /Users/zen/Code/grunt-contrib-connect/tasks/connect.js:172:21
    at fn (/Users/zen/Code/grunt-contrib-connect/node_modules/async/lib/async.js:641:34)
    at Immediate._onImmediate (/Users/zen/Code/grunt-contrib-connect/node_modules/async/lib/async.js:557:34)

[mzgoddard]

I don't know if I'm wrong about this or not but pointed out to me in the above issue, this is a regression from node 0.10. In node 0.10 connecting to port 0 or 65536 emits an EADDRNOTAVAIL error. Connecting to any port in the range that doesn't have a server bound to it emits an ECONNREFUSED error. Those match the RangeError but the the error has become synchronous and is creating this issue for portscanner and grunt-contrib-connect as portscanner was written expecting asynchronous errors.

Just figured I'd add this to the conversation having poked around a bit further.

[jeffreydwalter]

I agree with @mzgoddard's astute observation. Right or wrong, this was not causing an issue in node 10.x. This appears to be a regression that is affecting multiple modules. I don't use the grunt modules but I am experiencing this issue with the node-spdy module.

[cjihrig]

Some background on this:

The error message you are seeing was added to 0.11.8 in d80d131 to prevent non-int ports. However, it was possible that a DNS lookup would occur before validating the port, resulting in an asynchronously thrown (not emitted) exception. So, I moved the check to Socket.prototype.connect() in 0.11.15 in b636ba8. Because this is a check for invalid input, this should be thrown synchronously, as it is now.

The real question is whether or not calling createConnection({port: 0}) is a valid use case. If not, then this is not a regression. If so, then the check can be updated to allow 0.

[jeffreydwalter]

I'm not sure if this is even related, but it seems like BSD-based operating systems treat port 0 as a "special" port, which may have something to do with the fact that this issue appears to only be affecting OSX and FreeBSD.

Found this on the web: "The designers of the original Berkeley UNIX "Sockets" interface, upon which much of the technology and practice we use today is based, set aside the specification of "port 0" to be used as a sort of "wild card" port. When programming the Sockets interface, the provision of a zero value is generally taken to mean "let the system choose one for me". Programmers who specify "port 0" know that it is an invalid port. They are asking the operating system to pick and assign whatever non-zero port is available and appropriate for their purpose."

Also, wikipedia (not that it's authoritative) lists 0 as a valid port: "The port numbers in the range from 0 to 1023 are the well-known ports or system ports."

[cjihrig]

@trevnorris @tjfontaine @misterdjules thoughts? I don't see real harm in supporting port 0, even though I don't find it particularly useful on the client.

[trevnorris]

@cjihrig We should support port 0.