net: dragonfly broken by Listen after close on same addr

[bradfitz]

I seem to have broken the dragonfly builder after:

syscall: allow nacl's fake network code to Listen twice on the same address
https://go-review.googlesource.com/16650 (rev 8ee90fa)

... which added a test to the net package, which dragonfly can't pass.

Failure is:

http://build.golang.org/log/732b7056b17948b06073dbe399de931765307152

--- FAIL: TestListenCloseListen (0.00s)
    net_test.go:283: failed on try 1/10: listen tcp 127.0.0.1:52085: bind: address already in use
    net_test.go:283: failed on try 2/10: listen tcp 127.0.0.1:52093: bind: address already in use
    net_test.go:283: failed on try 3/10: listen tcp 127.0.0.1:52101: bind: address already in use
    net_test.go:283: failed on try 4/10: listen tcp 127.0.0.1:52109: bind: address already in use
    net_test.go:283: failed on try 5/10: listen tcp 127.0.0.1:52117: bind: address already in use
FAIL
FAIL    net 4.894s

I see a recent failure: http://build.golang.org/log/c6e3c951e0398d21ff52b932bc261ab70003120b

--- FAIL: TestServerConnState (1.02s)
    serve_test.go:3041: Unexpected events.
        Got log: Conn 1: new active idle active closed 
        Conn 2: new active idle active 
        Conn 3: new active hijacked 
        Conn 4: new active hijacked 
        Conn 5: new closed 
        Conn 6: new active closed 
        Conn 7: new active idle closed 

           Want: Conn 1: new active idle active closed 
        Conn 2: new active idle active closed 
        Conn 3: new active hijacked 
        Conn 4: new active hijacked 
        Conn 5: new closed 
        Conn 6: new active closed 
        Conn 7: new active idle closed 

FAIL
FAIL    net/http    20.463s

... which suggests the net package, poller, or runtime are processing networking events in a different order than all the other platforms.

We also don't have a new-style builder for dragonfly, so people without dragonfly can't use gomote or trybots to debug.

I think a Dragonfly person needs to help.

[ianlancetaylor]

This suggests that there is something wrong with the way we are using SO_REUSEADDR on DragonFly. Unfortunately we use the same code on all the *BSD systems, so I have no idea why DragonFly would behave differently.

[mdempsky]

CC @fupjack @4a6f656c

[fupjack]

I am working on tracking someone down who can solve it, who I will immediately refer to as NotMe.

[jorisgio]

Hi, my understanding is that SO_REUSADDR is meant to relax the rules of address collision at bind. The man says :

SO_REUSEADDR indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.

This is not really clear, but what it appears to mean is that you can have collision in your binding : for instance you can bind to '0.0.0.0:80' and then bind to '192.168.1.1:80', something which is disallowed without this flag. But you cannot bind twice to the same exact (addr, port) tuple.

SO_REUSEPORT allows completely duplicate bindings by multiple processes

SO_REUSEPORT on the other hand allows for this behavior. You can bind twice to the syntaxically identical (addr, port) tuple.

I've tested your (bind/listen/close/bind/listen) example (in C) and indeed, it's working with SO_REUSEPORT but returns EADDRINUSE with SO_REUSEADDR.

EDIT: this is indeed working on freebsd with SO_REUSEADDR, maybe dfly should match the behavior.

[ianlancetaylor]

SO_REUSEADDR permits a server to quickly bind to the same local address, without having to wait for the TCP TIME_WAIT state to expire. This is a long-standing feature of the socket network API. If it doesn't work on Dragonfly (I don't know whether it does or not), that has to be considered a bug in Dragonfly.

SO_REUSEPORT is much newer. It permits multiple servers to bind to the same local address. That is not what we want here.

[jorisgio]

This is indeed a bug in dfly.

[fupjack]

Fixed here:

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/296c350d3c63a181744b80a4b7973dac5fc162a3

I've cleared the most recent breaks in the DragonFly builder and restarted them, and they are completing this test. (Albeit still failing with a different error that I suspect is related to the gold linker coming in to DragonFly.)

[mikioh]

Looks like dragonfly guys have finished working on handling of shared IP control blocks. So the latest DragonFly kernels, at least 4.4 and above, have no issues. Also we can re-enable TestDualStack{TCP,UDP}Listener in Go 1.7. Closing.

[gopherbot]

CL https://golang.org/cl/19406 mentions this issue.