[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] [ottlik fzi de: [Qemu-devel] [PATCH RFC] Do not set SO_REUSEADDR on Windows]

----- Forwarded message from Sebastian Ottlik <ottlik fzi de> -----
> This patchset disabels all use of SO_REUSEADDR on Windows. On Windows systems
> the default behavior is equivalent to SO_REUSEADDR on other operating
> systems. SO_REUSEADDR can still be set but results in undesired bahvior
> instead. It may even lead to situations were system behavior is
> unspecified. More information on this can be found at:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621.aspx
----- End forwarded message -----

Read that doc and cry. In summary

 - On UNIX, SO_REUSEADDR allows an application to re-bind to a socket
   while it is in the CLOSE_WAIT state.

 - On Windows, you can always bind to a socket in CLOSE_WAIT state and
   AFAIK you can't disable this behaviour. Setting SO_REUSEADDR lets
   you bind to a socket when in *any* state.

So if code originating on Linux is blindly setting SO_REUSEADDR it is
almost certainly broken on Windows. Windows' interpretation of SO_REUSEADDR
is somewhat closer to the new Linux v3.9 flag SO_REUSEPORT


but the behaviour of SO_REUSEADDR is undefined on Windows for non-multicast
sockets, while Linux explicitly says it'll round-robin accept() calls, so
they're still not a perfect match.

So without a way to 100% map the different semantics I don't think its
practical for gnulib to save us from this madness and so we'll just want
to #ifndef WIN32 the use of SO_REUSEADDR in Libvirt

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]