[Spread-users] SO_REUSEADDR Final Chapter?

Jonathan Stanton jonathan at cnds.jhu.edu
Sat Sep 22 23:43:30 EDT 2001

On Sat, Sep 22, 2001 at 01:09:44PM +0100, Joshua Goodall wrote:
> On Fri, 21 Sep 2001, Jonathan Stanton wrote:
> [snip]
> > Any suggestions as to how to best handle this in Spread?
> I must have missed something vital - under what circumstances does this
> arise?

Some more info is in the late july, early august discussion on the mailing


The problem is that if Spread crashes or is shut down and client
connections are live, Spread goes into TIME_WAIT and you cannot restart
the daemon for 2 minutes because it needs to bind to the same port as
before. So, to solve this we used to use REUSEADDR on the socket, however
since we also bind to INADDR_ANY on some unixes, RESUSEADDR is a security
hole because other processes can steal you connections by binding to a
specific interface and the kernel will allow that. 

Some unixes are safe because the kernel enforces some more checks (like
the new process must be run by the same user, or just doesn't allow it at
all) but some are not.

It sounds so far like the best option is to use reuseaddr if the user
configures specific IP addresses or if an autoconf like test shows it is
safe. Probably also have an option to force it on or off incase specific
platforms or sysadmins need a custom policy.

> Further, were these TCP or UDP binds? If UDP, then SO_REUSEPORT is also
> relevant (and is also variously mishandled for the differing
> broadcast/unicast/multicast cases in OS-specific ways).

These are TCP binds, the problem doesn't exist with UDP. Because UDP binds
don't get stuck in TIME_WAIT, they have never caused a problem with
restarting the daemon. What is the SO_REUSEPORT supposed to be used for?
Is it the BSD version of REUSEADDR for supporting multiple multicast binds
to the same port?


Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    

More information about the Spread-users mailing list