Jump to content
  • Advertisement
Sign in to follow this  

SO_REUSEADDR - when should this be used?

Recommended Posts

I thought I understood this socket option before, but now i'm unsure.


I read an article talking about how the functionality is different on windows and linux and some people suggesting this should never be used on windows.


I initially thought that this was to allow a server to start back up and bind instantly after a crash and not having to wait for the socket that was being listened on to exit TIME_WAIT.


I'm currently using windows 10 and have been unable to produce a situation where i'm unable to bind a socket after a server crash.


Can anyone give me a scenario on when I should be using SO_REUSEADDR and how to force a situation to occur where its use can be observed?



Share this post

Link to post
Share on other sites

SO_REUSEADDR is useful in the case you suggest, allowing re-use of the same local port.

It may be that Windows just allows you to bind anyway? I haven't checked this in a long time.

The drawback with SO_REUSEADDR is that two different processes can bind the same port at the same time while both are alive. This may be useful for some load sharing situations, but may also end up in a situation where an "old" and a "new" process fight for incoming connections (one of them will win, but it's kind of random which one will for each new connection.)

To make things even muddier: there is an alternative SO_REUSEPORT option that you may want to check out, too. This didn't exist many years ago when SO_REUSEADDR was the general solution, but it's been with us for many years now, and provides an alternative option for the "process re-start" problem.

Share this post

Link to post
Share on other sites
Posted (edited)

If I recall the warning in Window's is potential unintended consequences, including security issues, when another program can SO_REUSEADDR on a port that you are still currently using.

As far as I know on Windows for normal sockets, they get cleaned up, including listen sockets, along with the process. So if you close the process then restart it, you shouldn't need SO_REUSEADDR.


Windows also has a SO_EXCLUSIVEADDRUSE and my understanding is that new software should use that for security reasons.




Once the second socket has successfully bound, the behavior for all sockets bound to that port is indeterminate. 


Before the SO_EXCLUSIVEADDRUSE socket option was introduced, there was very little a network application developer could do to prevent a malicious program from binding to the port on which the network application had its own sockets bound. 


The SO_REUSEADDR option has very few uses in normal applications aside from multicast sockets where data is delivered to all of the sockets bound on the same port. Otherwise, any application that sets this socket option should be redesigned to remove the dependency since it is eminently vulnerable to "socket hijacking". As long as SO_REUSEADDR socket option can be used to potentially hijack a port in a server application, the application must be considered to be not secure.

All server applications must set SO_EXCLUSIVEADDRUSE for a strong level of socket security. Not only does it prevent malicious software from hijacking the port, but it also indicates whether or not another application is bound to the requested port. For example, a call to bind on the wildcard address by a process with the SO_EXCLUSIVEADDRUSE socket option set will fail if another process is currently bound to the same port on a specific interface.

Lastly, even though socket security has been improved in Windows Server 2003, an application should always set the SO_EXCLUSIVEADDRUSE socket option to ensure that it binds to all the specific interfaces the process has requested. The socket security in Windows Server 2003 adds an increased level of security for legacy applications, but application developers must still design their products with all aspects of security in mind.


Although worrying about that sort of denial of service is probably not an issue for games, and seems to assume there is already malicious software on the system. I believe it also refers to hijacking existing UDP "connections", not just a TCP listen socket, but I never really investigated this.

Edited by SyncViews

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!