-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
basic support for TCP fast open #99490
Conversation
Note regarding the
|
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Unix.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you validated this with packet captures on all 3 platforms?
I don't know how it works on Mac, but note that this does not add support for server-side TFO on Linux therefore it's not a full implementation of #1476. We should either document this limitation or implement (& validate) server-side TFO.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Unix.cs
Outdated
Show resolved
Hide resolved
@@ -137,6 +137,7 @@ public enum SocketOptionName | |||
BsdUrgent = 2, | |||
Expedited = 2, | |||
TcpKeepAliveRetryCount = 16, | |||
FastOpen = 15, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should document the concerns (=fully controlled datapath needed) and the limitations around this flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I have no problem with good description. Even the man page for Linux talks about differences based on cookie availability.
what do you think is missing? |
I did macOS & Linux since Windows was reported working. |
With server side sockets (listener/accept) |
yes, This is what the part 1) does e.g. the new SocketOption case SocketOptionName_SO_TCP_FASTOPEN:
*optName = TCP_FASTOPEN;
return true; |
That logic is only triggered for mapping |
This part I don't understand. The rest works just like any other option. We map the .NET value to platform value and call |
Ok, it should be good (I missed part of the overall option setting logic). We still need the option roundtrip tests though. |
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Unix.cs
Outdated
Show resolved
Hide resolved
Expedited = 2, | ||
TcpKeepAliveRetryCount = 16, | ||
/// <summary> | ||
/// This enables TCP Fast Open as defined in RFC-7413. The actual observed behavior depend on OS configuration and state of kernel TCP cookie cache. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly believe that we need to document the risks of TFO in an easily discoverable way, including the fact that it's only recommended for fully controlled datapaths. I think this summary - or if it's valid for enum members - a remarks section would be a good place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What dog you suggest? Remarks probably should be edited directly in doc repo...?
I was thinking about it more and perps we can add something like
This enables TCP Fast Open as defined in RFC-7413. The actual observed behavior depend on OS configuration and state of kernel TCP cookie cache. Enabling TFO can impact interoperability and casue connectivity issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This enables TCP Fast Open as defined in RFC-7413. The actual observed behavior depend on OS configuration and state of kernel TCP cookie cache. Enabling TFO can impact interoperability and casue connectivity issues.
I would be ok with changing the summary
to the text above & opening an issue against https://github.com/dotnet/dotnet-api-docs/ to track adding more detailed information to an appropriate place, SocketOptionName
enum remarks maybe.
dotnet/dotnet-api-docs#9910 created to track adding remarks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM assuming the test failure will be addressed.
@@ -943,4 +1088,41 @@ public async Task SendTo_DifferentEP_Success(bool ipv4) | |||
Assert.Equal(sendBuffer.Length, result.ReceivedBytes); | |||
} | |||
} | |||
|
|||
internal static class ConnectExtensions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: it might be worth to move this into a separate file.
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
all the outer loop tests failures seems unrelated. |
@wfurt the failure I mentioned is not in outerloop. It's still there in the latest |
* initial drop * update * cleanup * err * 'test' * windows * sync * feedback & updates * macos * windows * feedback * await * docs * note * macos --------- Co-authored-by: Ubuntu <toweinfu@toweinfu-ubu22.c5goow0wwwee5hembzptmbtr0h.xx.internal.cloudapp.net>
* initial drop * update * cleanup * err * 'test' * windows * sync * feedback & updates * macos * windows * feedback * await * docs * note * macos --------- Co-authored-by: Ubuntu <toweinfu@toweinfu-ubu22.c5goow0wwwee5hembzptmbtr0h.xx.internal.cloudapp.net>
There are three somewhat separated parts here:
Tis currently works on Windows using
connectex
. With this PR it will light up on macOS usingconnectx
and on Linux using combination ofConnect
&Send
. Test added in #79669 is now portable across platforms.connectex
can already do that so asconnectx
on macOS. To make it work consistently across platforms I usedTCP_FASTOPEN_CONNECT
. That is available since Kernel 4.11 and that should cover all supported releases AFAIK. This is still best effort as the actual behavior will change based on /proc setting as well as TCP cookie availability. If either one is missing we will simply fallback to behavior described in 2)