As noted in the code comments, this same socket option works on Windows, but it doesn't round robin new connections between processes like it does on Linux.
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.
This makes it a decent option for resiliency on Windows, but not for benchmarking, so I decided not to set SO_REUSEADDR on Windows. This way we don't lose out on address in use errors when you might not realize you were trying to bind multiple processes to the same port. We could make this opt-in on Linux as well if we want to keep getting address in use errors unless you're specifically testing multiple process bound to the same port on Linux.
It's probably also worth noting that the runtime networking PAL translates SO_REUSEADDR to SO_REUSEPORT on Linux since that gives behavior more similar to SO_REUSEADDR on Windows than SO_REUSEADDR on Linux does. We could use SetRawSocketOption instead, but this way we don't have to use magic numbers, and this is a use case for SetSocketOption that's supported and tested by the runtime on Linux.
I also didn't change the behavior on macOS or FreeBSD because I didn't test this on those platforms. Socket options are famously handled differently by different OS's and that's especially true for SO_REUSEADDR and SO_REUSEPORT. https://stackoverflow.com/a/14388707/719967 is an excellent writeup on these options and how they behave on various operating systems. I encourage anyone who's interested to give it a read and upvote it if they're interested.
As noted in the code comments, this same socket option works on Windows, but it doesn't round robin new connections between processes like it does on Linux.
https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse#using-so_reuseaddr
This makes it a decent option for resiliency on Windows, but not for benchmarking, so I decided not to set SO_REUSEADDR on Windows. This way we don't lose out on address in use errors when you might not realize you were trying to bind multiple processes to the same port. We could make this opt-in on Linux as well if we want to keep getting address in use errors unless you're specifically testing multiple process bound to the same port on Linux.
It's probably also worth noting that the runtime networking PAL translates SO_REUSEADDR to SO_REUSEPORT on Linux since that gives behavior more similar to SO_REUSEADDR on Windows than SO_REUSEADDR on Linux does. We could use
SetRawSocketOptioninstead, but this way we don't have to use magic numbers, and this is a use case forSetSocketOptionthat's supported and tested by the runtime on Linux.I also didn't change the behavior on macOS or FreeBSD because I didn't test this on those platforms. Socket options are famously handled differently by different OS's and that's especially true for SO_REUSEADDR and SO_REUSEPORT. https://stackoverflow.com/a/14388707/719967 is an excellent writeup on these options and how they behave on various operating systems. I encourage anyone who's interested to give it a read and upvote it if they're interested.