Update of bug #21583 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #21583 (project freeciv):
Status: Ready For Test = Fixed
Assigned to:None = cazfi
Open/Closed:Open = Closed
Update of bug #21583 (project freeciv):
Status: Fixed = In Progress
Open/Closed: Closed = Open
___
Follow-up Comment #13:
Apparently *some*
Update of bug #21583 (project freeciv):
Status: In Progress = Ready For Test
___
Follow-up Comment #14:
Attached patch restores SO_REUSEADDR for lan scan sockets.
(file #20860)
Update of bug #21583 (project freeciv):
Planned Release: 2.4.3, 2.5.0, 2.6.0 = 2.5.0-beta1, 2.6.0
___
Follow-up Comment #10:
Let's not risk this in a release branch, but let's test it in 2.5 beta series.
Follow-up Comment #9, bug #21583 (project freeciv):
- Remove SO_REUSEADDR from client side sockets too.
(file #20364)
___
Additional Item Attachment:
File name: SoReuseAddrRm-2.patch Size:1 KB
Update of bug #21583 (project freeciv):
Status: In Progress = Ready For Test
___
Follow-up Comment #8:
A conversation with a friend makes me wonder whether our use of
SO_REUSEADDR might be
URL:
http://gna.org/bugs/?21583
Summary: Client can connect to manually started server rather
than its own spawned one
Project: Freeciv
Submitted by: jtn
Submitted on: Sun Feb 2 14:56:08 2014
Category: None
Follow-up Comment #1, bug #21583 (project freeciv):
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.
Follow-up Comment #2, bug #21583 (project freeciv):
How fast one after another the programs were started?
The manually started server had been running for some time (maybe minutes?) so
I doubt it's a straightforward port claiming race.
___
Follow-up Comment #3, bug #21583 (project freeciv):
I think this _has_ to do with #21547.
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
Follow-up Comment #4, bug #21583 (project freeciv):
can't reproduce on Linux
No surprise -- I think this stuff tends to be horribly OS-dependent.
This is one reason why changing anything in this area scares me, especially
just before a release.
Another similar source of fun is whether
Follow-up Comment #5, bug #21583 (project freeciv):
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
Follow-up Comment #6, bug #21583 (project freeciv):
find_next_free_port() erronously returned 5557 in 2.4.1 despite
finding 5556 being available
Obvious low-risk workaround for 2.4.1: Start looking for the port for
client-spawn server from 5557, so in most cases it will get 5557 like it used
14 matches
Mail list logo
