SO_REUSEADDR in Windows

[Paul Lalonde]

Change 10153 (Alex Brainman)  turned off SO_REUSEADDR on Windows.  I understand the reasoning, but this breaks my (previously working) apps, which listen and transmit on the same multicast group in the same application, but from different subsystems. 

The simple fix is to issue the SetSockOpt for the REUSEADDR before the JoinGroup call.

Does anyone have any particular guidance on how I could/should expose this?  There's certainly no clean way to expose the sysfd from a UDPConn, so making the syscall from user space looks like it's out.

Paul

 

[Russ Cox]

Turning on Windows SO_REUSEADDR for an ordinary point-to-point
connection is obviously a mistake: you end up stepping on other
programs that you did not intend to step on. Is that not the case
for multicast? I don't know enough to say. If the fact of multicast
makes SO_REUSEADDR safe in that situation, it would be fine
to turn on by default for that. But I am a little surprised that you
can't use multicast without using this terribly broken option.

Russ

[Paul Lalonde]

Yes, it's a mistake for point-to-point.

For multicast it's less clear - any subscriber is allowed to write into (and listen to) the multicast group without any access control, so I can't see a "stepping on" problem.  Winsock doesn't understand that multicast has different delivery semantics (to every listener) than point-to-point connections.  I've been unable to find any specific windows documentation pointing this out, however.

So yes, reservedly, I think the right answer is to turn on SO_REUSEADDR on multicast joins.  That's a three line addition to joinIPv4GroupUDP.  

I don't know what the situation is with regards to IPv6 multicast.

Mikio, Alex: do you have any other feedback?

Paul

[brainman]

I am not an expert here. I only use TCP. But from what I understand, I support your proposal. Especially, if you can back it up with some extra net tests ...  :-)

Alex

[Mikio Hara]

Hi,

On Thu, Dec 15, 2011 at 6:37 AM, Paul Lalonde <paul.a....@gmail.com> wrote:

>  There's certainly no clean way to expose the sysfd from a UDPConn,

Let me try it.
<http://codereview.appspot.com/5491044/>

[Paul Lalonde]

Yes, this certainly exposes it ;-)

I question the wisdom of this path, however, as it quickly leads to divergent (user code) paths to support for different OSes - it seems much more go-like to have the same user code behave identically on Linux as Windows.  For this reason I'd rather see SO_REUSEADDR added before the JoinGroup on Windows, so that so keep the cross-platform nature of the networking code.

Paul

[Mikio Hara]

On Thu, Dec 15, 2011 at 2:32 PM, Paul Lalonde <paul.a....@gmail.com> wrote:

> I question the wisdom of this path, however, as it quickly leads to
> divergent (user code) paths to support for different OSes - it seems much
> more go-like to have the same user code behave identically on Linux as
> Windows.  For this reason I'd rather see SO_REUSEADDR added before the
> JoinGroup on Windows, so that so keep the cross-platform nature of the
> networking code.

There's no one-size-fits-all solution, agree.