[Bug 8513] SO_REUSEADDR doesnt work?

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=8513





--- Comment #14 from Kai Blin <blin at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.