In D1676#94736, @Stan wrote:

This may be a stupid question, but does this work in the following situations:

• player1 IPV4 + STUN → player2 IPV6
• player1 IPV4 + STUN ← player2 IPV6

In D1676#71458, @elexis wrote:

(I think symbols like 4, 6, S might not be understood by many players.

The idea is to provide users with enough information so that they can figure out not just why they can't join but also why their friend can't.
Perhaps not everyone would understand them but it would allow user to easily pick some host which not only he but also some his friend can connect.
Also it might help hosts to know which other users it makes sense to invite to their games and which they wouldn't be able to connect anyway.
We could also show some green circle or something on hosts which are compatible with everything (both direct IPv4 and IPv6). That would be more simple to understand. But a lot of information would be dropped.

If there was a failed connection attempt, the messagebox that already pops up could inform the user which types of connection issues it could be to begin with (as it knows whether the host has IPv4/6, whether it uses STUN, whether someone else was able to join.).
The difference between informing before connecting and after connecting is that in the latter case, we know for sure whether the client can connect, in the former case we don't. So we can conclude a little bit more about the possible connection issues after an attempt.

Users usually want to see whether they're gonna be able to connect before they really attempt to do so. And not to try every host and wait few seconds to get connection failure for each before they finally find some host which they can connect to.
But sure error message can be improved.

In D1676#70776, @elexis wrote:

the problem where 9/10 users can join but the 10th cannot.
That issue is, from the number of complaints on the lobby, much more frequent, and it's in particular more frustrating to that player;
(because the player who can't host at all will give up and find another host, while the 10th client now is unable to participate in the game where all his buddies are in).

In D1676#70774, @elexis wrote:

Server should connect via STUN just as any other joining player would if host has STUN enabled.

(As far as I know, the missing STUN connectivity for some clients is a clientside problem, not a serverside one (we can observe something like 90% of the people can join STUN games and something like 10% can't); what information does it yield to test with one client?
I suppose it could detect a serverside firewall issue, but the problem is to explain to the user why all the other players could join but he individually could not. Whether a host uses STUN or not, whether it's an IPv4 or IPv6, whether anyone else could join before should be known already at the point of displaying it in the lobby gamelist at least.)

In D1676#70771, @elexis wrote:

lobby

The gamelist bot would already provide IPv6 addresses if we hadn't configured it to IPv4 (see lobby README.md).
Just keep it in mind that users should be informed why they can't connect.

In D1676#70767, @wraitii wrote:

We probably need to setup a team moment to test this easily, as it won't work with the lobby obviously.

In D1676#70760, @elexis wrote:

The program should inform the lobby player or IP-joiner if he can't join because of an IPv4 vs IPv6 issue and advise him what he would have to do in order to solve this problem.

This patch does not support lobby at all. We need to support lobby first. Before we start with lobby support we should first apply this and let people test if there are no yet unrevealed issues such as bugs that only affects specific systems. AFAIK now I'm the only one who tested this.

It'd be good to attach a diff between the added version and a usual system version of enet.

You can run diff between zpl-c's and lsalzman's versions of enet on github. But I'm sure you will find that it makes no sense to do it.

It must be the VFS because 0ad should be distributable with the game data files being stored in a possibly compressed zipfile.

I don't think it's a good idea to put this file in zip. It would be better outside so user can easily update it. Apps usually don't even bundle the GeoLite2 DB and rather let users to download it themselves. Also it would be good to have path to the database configurable so user can download the new database once to some location and make all apps use it without need to taking special care of each app (well on unix like systems this could be also acomplished using symlinks). Though while there are already some apps using MaxMind DB version if you make 0ad require the CSV format I doubt any other app would use it too.

Anyhow, the lookup time is kind of irrelevant, there is also a cache for the few IPs looked up, the memory footprint is the dealbreaker.

Yes, I agree I was just replying to your previous statement.
Though if the game really should start for 2 seconds more it would seem dumb. Since some minor function would make the longest delay in game start process.

The std::map has logarithmic lookup time as well.

I didn't get why would this function affect memory consumption at all and now I noticed the intention is to use CSV version of GeoLite2 and as I understand it this whole database gets parsed and stored to memory. To me this seems to be definitely wrong decision. MaxMind format of this database contains binary search tree which allows to quickly search for any IP by descending only the necessary parts of search tree with no need to read the whole file. Compared to some parsing of CSV this is much more efficient and does not require any significant memory resources.

Looking up the hostname from the IP address is included in the patch.
But that doesn't show the country/cityname/ISP/VPN/Satellite data that GeoLite2 is about.
One can lookup these entries online, but these are usually attached to payment for some reason that isn't clear to me (downloads might yield much more traffic). https://www.maxmind.com/en/geoip2-precision-city-service?pkit_lang=en

Instead of adding some database wouldn't it be easier to just do RDNS lookup. And perhaps if it fails fall back to whois service?

In D1676#66499, @vladislavbelov wrote:

Do I understand it correctly, that IPv4 won't work when IPv6 is enabled?