portfinder yields a port that is already in use

[lmorchard]

So, this issue might be related to #9. I'm seeing this on Mac OS X:

➜  ~/.local/android-sdk-macosx/platform-tools/adb forward --list
3739ced5 tcp:8000 localfilesystem:/data/local/debugger-socket
➜  curl http://127.0.0.1:8000
(expected output from the android device)
➜  node -e 'require("portfinder").getPort(console.log)'
null 8000

In other words, I have port 8000 forwarded to an Android device via adb and there's a service running that responds to curl. But, portfinder does not detect it, and it offers 8000 as a free port.

This doesn't seem limited to adb. Per #9, I tried running a PHP dev server and got similar results:

➜ php -S 127.0.0.1:8000
PHP 5.5.14 Development Server started at Thu Mar 19 15:41:33 2015
Listening on http://127.0.0.1:8000
Document root is /Users/lmorchard/devel/mozilla/node-firefox/node-firefox-forward-ports
Press Ctrl-C to quit.

(switch to another shell)

➜ curl -si http://127.0.0.1:8000 | head -1
HTTP/1.1 404 Not Found
➜ node -e 'require("portfinder").getPort(console.log)'
null 8000

In other words, there's an HTTP server running on port 8000 via php -S and it responds to curl. But, portfinder offers up its port as free.

But then, for the hell of it, I tried running a SimpleHTTPServer with Python.

This time, portfinder worked as expected:

➜ python -m'SimpleHTTPServer'
Serving HTTP on 0.0.0.0 port 8000 ...

(switch to another shell)

➜ curl -si http://127.0.0.1:8000 | head -1
HTTP/1.0 200 OK
➜ node -e 'require("portfinder").getPort(console.log)'
null 8001

So, I guess I'm wondering what are adb and php doing differently from the Python server that causes portfinder to not detect the occupied port?

[lmorchard]

Oh, ah hah! I figured out the difference:

➜ node -e 'require("portfinder").getPort({host: "127.0.0.1"}, console.log)'
null 8001
➜ node -e 'require("portfinder").getPort({host: "0.0.0.0"}, console.log)'
null 8000
➜ node -e 'require("portfinder").getPort(console.log)'
null 8000

Looks like adb and php occupy ports on 127.0.0.1:8000, while the Python SimpleHTTPServer occupies 0.0.0.0:8000 - and portfinder is only looking at the 0.0.0.0 host by default.

So, I guess for the purposes of this issue... Should portfinder maybe check 127.0.0.1 instead? Or in addition to 0.0.0.0? Or should this really just be a documented gotcha?

[hutson]

@lmorchard this same issue was actually brought up in #9

It's a feature that should really be documented in the README.

[gnestor]

Explicitly setting host fixed the issue for me 👍

[stefanpenner]

I've seen similar issues, in each case it boied down to the following:

1. IPv4 socket being taken
2. IPv6 socket being open
3. portfinder defaults to undefined host, which typically falls back to ipv6, thereby only checking IPv6.
4. portfinder then checks the IPv6 socket, and reports an open port.

This has a funny property, as depending on several outside conditions some requesters will prefer IPv4 and IPv6 over another. For example, curl against localhost will prefer IPv6, but curl against a host entry, tends to prefer IPv4. This actually masks many failure scenarios, and made debugging initially slightly more tricky.

Proposed solution is to (by default) check both IPv6 and IPv4, maybe allowing users to opt into something more specific. This would have the least surprising results.

[eriktrom]

I made a go at this

let me know thoughts - don't mind cleaning up for style, etc

this would unblock ember-cli/ember-cli#5352

feedback much appreciated

[stefanpenner]

@eriktrom link?