net.ListenTCP succeeds twice on Windows

[gopherbot]

by yeswah:

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull", "hg update default", rebuild, and
retry
what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1.net.ListenTCP can been listen on one port more than once
2.
3.

What is the expected output?
can't exit

What do you see instead?
exit

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
windows7

Which revision are you using?  (hg identify)
r60

Please provide any additional information below.

Attachments:

1. main.go (489 bytes)

[rsc]

Comment 1:

Listen can only listen if nothing else is listening first.
Only one program gets to serve port 80, for example.
What are you trying to do?  Why are you starting
five listeners on the same port?
Russ

Status changed to WorkingAsIntended.

[gopherbot]

Comment 2 by yeswah:

if first Listen had listen on 81 port, second Listen can't listen on the same port, var
e should not equal nil, then program will been exit. but this program is not exit.

[rsc]

Comment 3:

It sounds like this is a Windows bug: a second Listen on the same port does not return
an error.  The program works fine on Linux.

Labels changed: added os-windows.

Status changed to Accepted.

[alexbrainman]

Comment 4:

All our windows sockets are marked as SO_REUSEADDR. This seems to allow to call listen
http://goo.gl/a8hJu multiple times. If we want opposite behavior, we should not set
SO_REUSEADDR on correspondent socket.
Should we stop setting SO_REUSEADDR on all sockets? Or should we do it selectively on
listening sockets only?
I am surprised it works on linux, listen with SO_REUSEADDR set ...
Alex

Labels changed: added packagebug.

Owner changed to @alexbrainman.

[ianlancetaylor]

Comment 5:

SO_REUSEADDR doesn't permit multiple sockets to listen on the same IP address and port
number.  By default, after you close a socket, it enters a TIME_WAIT state when no
socket can use the same pair of address & port for two minutes.  This is designed to
permit any trailing packets on the connection to get dropped.  SO_REUSEADDR disables
that wait, permitting the connection to be reestablished immediately.  It is normal to
use SO_REUSEADDR on a server.
So this has nothing to do with SO_REUSEADDR.  It does sound Windows-specific.  I can't
imagine what it would mean to open multiple sockets listening on the same IP address and
port.  Perhaps Windows defines that in some way.

[rsc]

Comment 6:

It appears that Microsoft decided to make SO_REUSEADDR
mean something different.  It looks like the fix is to not use
SO_REUSEADDR, but only on Windows.  On other systems
it works just fine and does what it is supposed to do.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx
"The SO_REUSEADDR socket option allows a socket to forcibly bind to a
port in use by another socket. The second socket calls setsockopt with
the optname parameter set to SO_REUSEADDR and the optval parameter set
to a boolean value of TRUE before calling bind on the same port as the
original socket. Once the second socket has successfully bound, the
behavior for all sockets bound to that port is indeterminate. For
example, if all of the sockets on the same port provide TCP service,
any incoming TCP connection requests over the port cannot be
guaranteed to be handled by the correct socket — the behavior is
non-deterministic. A malicious program can use SO_REUSEADDR to
forcibly bind sockets already in use for standard network protocol
services in order to deny access to those service. No special
privileges are required to use this option."
WTF.

[ianlancetaylor]

Comment 7:

Neat, that's always what I look for from my sockets code, indeterminate behaviour.

[alexbrainman]

Comment 8:

This issue was closed by revision c1d0f0e.

Status changed to Fixed.