Reusing server address

[xoft]

I'd like to question the wisdom of setting the address reuse option for the server (cServer.cpp, line 186 as of rev 234).

The purpose of this API is to allow multiple sockets listen on the same port, for the case when the program originally listening on that port crashes, then a new instance can listen on the same port again while the old tcp endpoint still is in the TIME_WAIT state. However, at least on Windows, this also allows multiple programs to actively listen on the same port at the very same time.

I strongly believe that MCServer should be the only application using the port, and it should end with an error message if that port is already used. Therefore I'd like to remove the Reuse option, at least from windows builds of MCS.

What do you say?

References:
SO_REUSEADDR on unix: http://www.unixguide.net/network/socketfaq/4.5.shtml
SO_REUSEADDR on Win: http://msdn.microsoft.com/en-us/library/...s.85).aspx

[FakeTruth]

I use it indeed for when the server crashes. It can take quite a while before the port is available again after a crash, it was annoying.

[xoft]

How about a cmdline option to activate this feature, then? Something like "I know the risks and I want to do it nevertheless". Perhaps even try first without the reuse and only if it fails, print a warning and then set the option.

EDIT: Was that failure of yours on windows or on *nix?

[FakeTruth]

It was on Windows :O

[tbar]

I use it indeed for when the server crashes. It can take quite a while before the port is available again after a crash, it was annoying.

You should consider reserving the ports in the OS so the ports isn't used by other apps during dynamic port requests. It is easily achieved with a minor registry setting. Use the following KB for reference: http://support.microsoft.com/kb/812873

(The KB only states win2000/2003/XP but it should also works on win2008/7).

EDIT: Thinking about it I come to the conclusion that I might totally have misunderstood the point... Sorry...

[FakeTruth]

If you look at the average person wanting to host a Minecraft server, you can be sure that person has no clue what you're talking about

[xoft]

The average person wanting to host MCS won't run into crashes too much, will they? And if they do and the port is still busy, they can start the server with the correct parameter (if the server instructs them to, citing the dangers). Still IMO better than silently running on the same port as something else and being randomly inaccessible.

[FakeTruth]

Well I think if the port is in use by another program you cannot start MCServer, but setting these options on the socket of MCServer allows other programs to override the port.

From my experience it's like this: (at the moment)

1. MCServer starts and uses port 1337
2. Some other program starts using port 1337
3. Shit hits the fan

1. Some other program uses port 1337
2. MCServer starts and cannot use port 1337 and shuts down.

This is how I experience it, but I could be wrong?

[xoft]

In case of "some other program" == "another instance of MCServer" you get the first kind of experience anyway.
I'm not so sure if the OS is "smart enough" to see if the port is used by the same program.

You seem horribly against the idea of having to use a switch for the current behavior and using a safer way as the default, why?

[FakeTruth]

I'm not against it, I'm just questioning if this is necessary. I've seen multiple people post already because they cannot start the server because the port is in use. What's the problem? The server is already unable to start when the port is in use apparently.