> A conversation with a friend makes me wonder whether our use of
> SO_REUSEADDR might be implicated.

From the article it sounds so. In fact, I can't understand why has SO_REUSEADDR ever been introduced there - doesn't sound something we would ever need. Attached patch simply removes it. At least in S2_4 I would be inclined to leave patch #4471 workaround to stand in addition to this, even if this seems to fix the actual problem. From the article it seems that the fix might not work on some version of Windows. Patch #4471 in turn does not fix reclaiming of a socket in cases other than one manually started server in default port + one client spawned server, so having both gives maximum stability we can reach.

> This is one reason why changing anything in this area scares
> me, especially just before a release.

Yes. The question is whether we consider this current problem a reggression from 2.4.1?
The bug itself certainly isn't, but the fact that find_next_free_port() erronously returned 5557 in 2.4.1 despite finding 5556 being available made this much less likely to happen.

This is one reason why changing anything in this area scares me, especially just before a release.

Another similar source of fun is whether listening on a given port on IPv6 also exclusively binds on IPv4. We had lots of fun with this around bug #15559. (In that case at least it was also configurable, with different Linux distros choosing different defaults at different times; and *BSDs were different again.)

A conversation with a friend makes me wonder whether our use of SO_REUSEADDR might be implicated. This article (which I've only skimmed so far) looks interesting. (But this could be a complete red herring.)

>> Quitting the client then killed the manually started server
>> (unsurprisingly).
> How that? The server should wait for (re)connects, and does
> so here.

I think client_kill_server() is called, which sends "/quit" to what it thinks is its spawned server. Since the client always ends up with "hack" access to a server on the same machine (indeed, this can't be disabled: bug #20556) this succeeds. (Or at least I'm guessing that's what happened, hence my lack of surprise.)

> I guess the problem is that Freeciv assumes it's not possible for two processes to listen on 0.0.0.0:5556 and 127.0.0.1:5556 simultaneously, or something.
> (Can I just note that I hate interface binding semantics.)

didn't know that and can't reproduce on Linux. 2 servers, at 127... and 192..., is possible, but 1 server on 0... blocks all.

> Quitting the client then killed the manually started server (unsurprisingly).

How fast one after another the programs were started? I just wonder if this could be race-situation that the manually started server had not yet reserved the port by the time client checks if it's available.

I had a freeciv-server.exe running (port 5556, started from start menu), started a freeciv-gtk2.exe, and accidentally chose "new game" rather than "connect to network game".

To my surprise, it connected to my manually-started server rather than one of its own.

Didn't seem 100% reproducible but I got it to happen twice in a few tries. Details from the second time:

There were two freeciv-server.exe processes, unsurprisingly.

netstat -a -b -o showed:

PID 3504 is presumably my standalone server and 3140 the spawned one.

I guess the problem is that Freeciv assumes it's not possible for two processes to listen on 0.0.0.0:5556 and 127.0.0.1:5556 simultaneously, or something.
(Can I just note that I hate interface binding semantics.)

Quitting the client then killed the manually started server (unsurprisingly).

After quitting the manual server, the spawned server hung around (unsurprisingly), but it didn't obviously cause trouble (a new client-spawned server used 5557).
(This might have been behind my lack of reproducibility, I didn't check again after I realised this was happening.)

(Windows 7 32-bit. Machine not connected to any "real" network, if it makes a difference.)

Dunno if this is 2.4.2 blocker -- case of manual server and local game simultaneously is quite niche, and messing around with this might break something else.

Copyright (C) 2004-2006, the Gna! people. Posted items are owned by whoever posted them.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.