Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

net: OS X allows duplicate listen in single process? #2581

Closed
bradfitz opened this issue Dec 18, 2011 · 9 comments
Closed

net: OS X allows duplicate listen in single process? #2581

bradfitz opened this issue Dec 18, 2011 · 9 comments
Labels
FrozenDueToAge
Milestone
Go1

Comments

@bradfitz
Copy link
Contributor 

I have a program that listens on tcp port 8080, gets its *net.TCPListener's File()
*os.File, and passes that to a child process via exec.Command.ExtraFiles.  The idea is
for the child to then use that listener with net.FileListener.

As a test, I wanted to verify that the child would fail to re-listen on that port.

On Linux, as expected, the child gets an error trying to re-listen on port 8080.

On OS X, the listen succeeds (and lsof shows two entries with identical contents), but
the accept hangs forever on the second dup listener (which in itself isn't surprising). 
What's surprising is that the dup Listen even succeeded.

I'd like to know if OS X just sucks, or we have some portability problem here.

I can refine this to a test case, but filing this bug before I forget.
@adg
Copy link
Contributor

adg commented Jan 4, 2012

Comment 1:

Labels changed: added priority-go1.

@robpike
Copy link
Contributor

robpike commented Jan 13, 2012

Comment 2:

Owner changed to builder@golang.org.

@bradfitz
Copy link
Contributor Author

Comment 3:

Watching the build breakages between 669536c0ba8c and the fix in 5558056, it seems that
OS X just allows duplicate listens, even within the same process?  Should verify that
first, though, before closing this.

Owner changed to @bradfitz.

Status changed to Started.

@mikioh
Copy link
Contributor

mikioh commented Feb 11, 2012

Comment 5:

I checked below platforms w/ attached test program.
- linux-3.0.0
- darwin-11.3.0 (freebsd-based network stack)
- freebsd-8.2
- openbsd-5.1
Allow re-listen (actually bind) in single, multiple processes:
- darwin, freebsd and openbsd
- if multiple listeners exist:
   client data is delivered to last listener on both darwin, freebsd (last-come first-served)
   client data is delivered to first listener on openbsd (first-come first-served)
Not allow re-listen (actually bind) in single, multiple processes:
- linux
- because linux's bind is designed to achieve service port-uniqueness

Attachments:

  1. pfclient.go (791 bytes)
  2. pfserver.go (1450 bytes)

@rsc
Copy link
Contributor

rsc commented Feb 12, 2012

Comment 6:

Mikio, is any of this connected to SO_REUSEADDR or SO_REUSEPORT?
Are we still using it wrong?
I know that on Windows, multiple listens are allowed exactly when
the second listen sets SO_REUSEADDR.

@mikioh
Copy link
Contributor

mikioh commented Feb 13, 2012

Comment 7:

> Are we still using it wrong?
50%: I though I've removed SO_REUSEPORT from unicast listener's 
sockopts over all platforms but actually didn't (oops). I will send 
a fix CL soon.
And rest of the issue, it seems like IPV6_V6ONLY=0 related issue.
Hmm...

@rsc
Copy link
Contributor

rsc commented Feb 13, 2012

Comment 8:

I think this is fixed enough that you can write your test, Brad.
Just don't have one half of the test use "tcp4" and the other have say "tcp".

Status changed to Fixed.

@mikioh
Copy link
Contributor

mikioh commented Feb 26, 2012

Comment 9:

Please take a look at http://golang.org/cl/5677086/.
In conclusion, a) there are some bugs in package net that cause 
allowing wildcard address double listen on BSD variants, b) after 
fixing the bug even in the case of dual IP stack we can see a bit 
consistent listeners behavior now.

@mikioh
Copy link
Contributor

mikioh commented Mar 5, 2012

Comment 10:

This issue was closed by revision b5dc872.

@bradfitz bradfitz self-assigned this Mar 5, 2012
@rsc rsc added this to the Go1 milestone Apr 10, 2015
@rsc rsc removed the priority-go1 label Apr 10, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1
Development

No branches or pull requests
6 participants
@bradfitz @mikioh @rsc @robpike @adg @gopherbot