Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
net: dragonfly broken by Listen after close on same addr #13146
I seem to have broken the dragonfly builder after:
... which added a test to the net package, which dragonfly can't pass.
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.
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.
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.)
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@example.com>