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.

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

Add Kestrel port sharing support to some Linux benchmarks #2025

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

halter73
Copy link
Member

@halter73 halter73 commented Oct 16, 2024

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.

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 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.

@halter73 halter73 requested a review from sebastienros October 16, 2024 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant