-
Notifications
You must be signed in to change notification settings - Fork 18.1k
net: dragonfly broken by Listen after close on same addr #13146
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.
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
Comments
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. |
I am working on tracking someone down who can solve it, who I will immediately refer to as NotMe. |
Hi, my understanding is that SO_REUSADDR is meant to relax the rules of address collision at bind. The man says :
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 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. |
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. |
This is indeed a bug in dfly. |
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.) |
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. |
CL https://golang.org/cl/19406 mentions this issue. |
It looks like the latest DragonFly BSD kernels, at least 4.4 and above, have finished working on handling of shared IP control blocks. Let's re-enbale test cases referring to IP control blocks and see what happens. Updates #13146. Change-Id: Icbe2250e788f6a445a648541272c99b598c3013d Reviewed-on: https://go-review.googlesource.com/19406 Reviewed-by: Ian Lance Taylor <[email protected]>
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
I see a recent failure: http://build.golang.org/log/c6e3c951e0398d21ff52b932bc261ab70003120b
... 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.
The text was updated successfully, but these errors were encountered: