JDK-4476378 : SO_REUSEADDR broken on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_95,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-06-29
  • Updated: 2001-08-02
  • Resolved: 2001-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
1.4.0 beta2Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Currently we only enable SO_REUSEADDR on Windows in very limited
circumstances. This stems from the fact that SO_REUSEADDR does not
implement BSD semantics on Windows. Specifically :-

1. SO_REUSEADDR on TCP sockets allows multiple processes to bind
to the same port/address. This is incorrect semantics as it should
only be possible to bind to the same port on a more specific
address - see 4446078 for details.

2. For TCP sockets the SO_REUSEADDR option allows multiple processes
to accept connections on the same port. Simililarly multiple processes
can receive non-multicast packets whereas the right semantics is
that SO_REUSEADDR on UDP sockets should only allow the second and
subsequent processes to receive multicast packets. For TCP sockets
there is SO_EXCLSUIVEADDRUSE socket option but its use is limited
and isn't appropriate for multicast sockets.

For merlin-beta we have a short term solution in place to avoid
the above 2 issues. The short term solution is to only allow 
SO_REUSEADDR to be enabled in limited circumstances. Specifically :-

1. {Socket,ServerSocket,DatagramSocket}.setReuseAddress(true) doesn't 
enable SO_REUSEADDR on Windows unless there is registry settings
indicating that it's secure. 

2. For MulticastSocket we will allow SO_REUSEADDR to be enabled
if the application is binding to the wildcard address. If 
binding to a specific address we disable SO_REUSEADDR. 

alan.bateman@ireland 2001-06-29

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2

EVALUATION Needs to be fixed by beta-refresh. alan.bateman@ireland 2001-06-29 Name: dfR10049 Date: 06/29/2001 Commit to fix in merlin-ea ====================================================================== Name: dfR10049 Date: 06/29/2001 Please ignore my previous evaluation. I used different bugID. ====================================================================== SO_REUSEADDR socket option has now been clean-up in terms of implementation and specification. Specifically :- 1. setReuseAddress(true) now enables the SO_REUSEADDR socket option on all platforms. 2. MulticastSocket constructors will enable SO_REUSEADDR by default. 3. ServerSocket specification no longer specifies that the socket option is enabled by default. In implementation terms it will be enabled on Solaris/Linux and on Windows it won't be enabled. This resolves backward compatibility issues and there isn't any issues related to restarting a server if a previous connection is in TIME_WAIT state. alan.bateman@ireland 2001-08-02