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