IPv6 support for sv_downloadurl (sv_downloadurl_ipv6)

[d47081]

Solution compatible with previous protocol / clients as implements new option sv_downloadurl_ipv6

Details described in #1559

Client-side already tested - I can provide IPv6 links in server.cfg and download resources from there, but stuck on server-side part, as don't know how to check remote connection type and return sv_downloadurl_ipv6 for IPv6 clients instead of sv_downloadurl

Here is the subject with example:
#1559 (comment)

[a1batross]

I'm not sure whether having two sv_downloadurl cvars is actually needed.

In my idea, by having both AAAA and A DNS records on the same domain, the client would be free to choose whether it wants to use IPv6 connection or IPv4 connection.

Also, the way svc_resourcelocation parser works, it actually allows multiple locations to be set, by listing all available URLs in sv_downloadurl separated by space.

[a1batross]

The same goes for having multiple locations in sv_downloadurl.

It's the client's choice whether they want to use IPv6 or IPv4.

[d47081]

DNS resolving does not work for me

Parser of sv_downloadurl also works with IPv4 only (in master branch)

and what about:

No, it's ipv4-only

sv_downloadurl however only allows to set only one address.

Maybe I'm newbie, but I don't understand how to connect IPv6 but with this patch, posted as maybe useful.
If no - please close it.

[d47081]

Well, just compiled and can confirm - everything works perfect:

connections from IPv4 gives IPv4 in sv_downloadurl (it also supports IPv6 now but I want to use it for clearnet users)
connections from IPv6 gives IPv6 Yggdrasil server - configured in sv_downloadurl_ipv6 (new option)

Example of server.cfg for documentation:

// fast download
sv_downloadurl "http://94.140.114.89/fastdl/half-life/"
sv_downloadurl_ipv6 "http://[201:5eb5:f061:678e:7565:6338:c02c:5251]/fastdl/half-life/"
sv_allowdownload 1

\o/

[a1batross]

#1862 now allows the usage of IPv6 for HTTP resources location, by passing AF_UNSPEC to resolver and then passing resolved address family to socket(). I haven't tested it yet, though.

But the idea is still the same: whatever resolver picks is going to be used here.