http://bugs.winehq.org/show_bug.cgi?id=8513
--- Comment #14 from Kai Blin blin@gmx.net 2007-11-06 13:23:04 --- (In reply to comment #13)
umm, the problem is not in "BSD socket platform"/linux tcpip stack, the problem is in Wine lacking this functionality. Wine is already a middleman between apps and the kernel sockets, so what is stopping it from lying a little?
I have no intentions to implement that. If you feel like testing and implementing it, have fun.
How does it work under windows? Does it hijack the port unbinding it from the previous owner (and returns error)? or does the previous owner just stop receiving data until the new SO_REUSEADDR socket is released? What if a third app also uses SO_REUSEADDR and again takes port rom the previous one that used SO_REUSEADDR? :)
According to MSDN, the behaviour in that case is indeterminate, apart from multicast sockets, where both apps will get the packet.
I know that implementing it would look like a hack, but i suspect that its already a hack under windows from early tcpip implementation, and there are many applications using this flag (with your fix some of them will just fail to bind port since windows has no problem with this flag).
Most Windows apps I've seen that use SO_REUSEADDR actually assume a BSD socket-like behaviour. The only one I know about that behaves differently is the one this bug report initially was about.