Akka.Remote - tcp socket address reuse - default configuration

[maxcherednik]

Due to the default setting, I was able to bind several instances to the same socket port on windows machine.

Should it be this way by default? Follow up: @Aaronontheweb

Enables SO_REUSEADDR, which determines when an ActorSystem can open

  # the specified listen port (the meaning differs between *nix and Windows)
  # Valid values are "on", "off" and "off-for-windows"
  # due to the following Windows bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4476378
  # "off-for-windows" of course means that it's "on" for all other platforms
  tcp-reuse-addr = on

[Aaronontheweb]

Thanks for creating an issue out of this @maxcherednik.

I ran the test suite with this setting disabled (so, different from the current default) and everything passed, so I don't see any major issues there.

I think changing this default to off would be the "right" thing to do in the event that developers are accidentally setting themselves up for failure by having multiple Akka.NET processes all binding to the same ports by accident. This seems like a violation of the "fail fast" principle to me.

cc @akkadotnet/core any other thoughts on this?

[Aaronontheweb]

Great SO on thread on the implications of this setting: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

[Aaronontheweb]

Makes me think we should probably just disabled it altogether.

[nvivo]

On my tests, leaving tcp-reuse-addr = off may cause problems on Linux with .NET Core 2.

In most nodes I had a dynamic port selection for akka, so it selects the lowest free port in a range. That was used to have multiple services in the same server. I started noticing that after an app upgrade, the port in linux always changed even though it was the only process running with akka.

So, just for the sake of it I tried to let the port fixed, and after an app update, akka cannot bind to the same port for a few minutes, and the actorsystem keeps failing to start. That's probably related to the differences in the SO post, linux behaves differently from windows and really waits to cleanup the port before giving it to another app again.

There might be more to test, but just wanted to leave this experience here.

[Aaronontheweb]

Have a PR in-place which changes this to default to off-for-windows - which I think should be a happy medium.