Enable listening with IPv6 or IPv4 (previously only IPv4 was possible)

[finitemonkey]

I found that I couldn't specify an IPv6 address to listen on, so I made this tiny modification to enable it.

Any of the following are possible with it;

...

server.serve(Port(80), "localhost")
server.serve(Port(80), "127.0.0.1")
server.serve(Port(80), "::1")
server.serve(Port(80), "0.0.0.0")
server.serve(Port(80), "::")

The change is simply to call getAddrInfo with Domain.AF_UNSPEC then to use the result from getAddrInfo as arguments to createNativeSocket so we get a socket that matches the capabilities as probed by getAddrInfo.

[finitemonkey]

This PR also addresses the failure of the websockets test in the last one by changing "127.0.0.1" to "localhost" instead.

[guzba]

Thanks for the PR, will merge and work with this and then tag a release.

[guzba]

Sorry, in the end I had to revert this as Windows stopped working with this change.

[finitemonkey]

Sorry! It has taken/is taking a while to look into that. Everything is all Linux-y around here, so there is an overhead involved in testing on Windows, and I keep on finding other things to focus on than setting up a Windows VM!

That is the intent, though - I will test on Windows (and hopefully fix it!). I noticed that in the Linux error case too, the error message given by Github wasn't particularly useful, but when I ran the test locally the error message was good, making fixing easy. I suspect the same might be true with Windows.

I noticed another anomaly with the Windows checks. As I looked into this, I took a peek at closed pull-request checks (initially just to check whether the failure on this one was new) and I noticed that in all tests, Windows takes an extraordinarily long time to complete, somewhere between 3 - 6 times as much time to complete the checks compared to Linux. I wondered if that might be related in some way to this problem?

[guzba]

@finitemonkey Oh it is all good, I totally understand the Linux focus, it is the same here. My bar for Windows is something like "if someone is using Windows for testing / development, I'd like it to work for that". It does not need to be optimal or perfect, just works for dev purposes. This does mean if IPv6 is troublesome on Windows, it would be fine with me to only support it on non-WIndows systems.

When I ran it locally I found that pre-merge the tests passed (though a bit slower), post-merge they never completed. I did not look into the cause either yet.

[finitemonkey]

I found some time (and a Windows machine!) to do some testing with, but unfortunately I haven't found out what is going on here.

The tests and server compile fine and the server appears to run as it should (apart from being unreachable, obviously!). netstat -p TCPv6 -qn shows the server listening and also shows an established connection when using either a browser or the test scripts to connect to the server.

Proto   Local Address     Foreign Address    State
TCP     [::1]:8081        [::1]:0            LISTENING

Proto   Local Address     Foreign Address    State
TCP     [::1]:8081        [::1]:60630        ESTABLISHED
TCP     [::1]:60630       [::1]:8081         ESTABLISHED

However, connections just hang via IPv6.

Notably, the server does work fine with this PR when given an IPv4 address to work with (and of course, it works fine on Linux), which makes me think that this is either an IPv6 bug in one of the libraries that the server is relying on (on Windows only) or something to do with the Windows default networking set-up for IPv6. I suspect the Windows networking set-up due to the fact that a connection is established but unresponsive - it feels like a lost ICMP packets sort of issue. Sadly, my lack of familiarity with Windows (and indeed ICMPv6!) isn't helping here!

Looking around online, I found a couple of suggestions for similar problems and so I tried the suggestions provided, but neither disabling the Windows firewall nor setting the network profile to "private" fixed the issue for me.

So, although it would be better to fix it on Windows, perhaps the best option is to just hide it behind an OS-specific switch for now as you suggested and wait until somebody with more familiarity with that platform comes along and is motivated to fix it?