-
Notifications
You must be signed in to change notification settings - Fork 228
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
TCP_FASTOPEN option for Socket #336
base: master
Are you sure you want to change the base?
Conversation
zonyitoo
commented
Aug 24, 2022
- Supported platforms: Linux-like, FreeBSD, macOS, Windows
- ref Support TCP Fast Open #49
- Supported platforms: Linux-like, FreeBSD, macOS, Windows - ref rust-lang#49
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.
Can you add a smoke test for this?
If I call this with the value 5
, does this work on non-Linux? I.e. enable it, or would it error and would users have to do if linux { 5 } else { 1 }
? Depending on the answer can you also add a test for this?
We have the answer, |
Test failed on FreeBSD CI. It seems that TFO is not enabled on CI's OS. |
@Thomasdezeeuw Should I remove FreeBSD support? |
Can you change the method so that For FreeBSD can you try add a new step to enable_tcp_fastopen:
- sysctl net.inet.tcp.fastopen.client_enabled=1
- sysctl net.inet.tcp.fastopen.server_enabled=1 After |
Co-authored-by: Thomas de Zeeuw <[email protected]>
Co-authored-by: Thomas de Zeeuw <[email protected]>
Still not working on FreeBSD's CI test. |
@zonyitoo I'll work on FreeBSD |
@zonyitoo the - - sysctl net.inet.tcp.fastopen.client_enabled=1
- - sysctl net.inet.tcp.fastopen.server_enabled=1
+ - sudo sysctl net.inet.tcp.fastopen.client_enable=1
+ - sudo sysctl net.inet.tcp.fastopen.server_enable=1 However that doesn't seem to fix the problem (see my next comment). |
@asomers maybe you can help here. I got this to work on FreeBSD (the |
@Thomasdezeeuw this socket option is a flag, so you should only interpret it as either zero or non-zero. TCP_NODELAY is similar, and I see that socket2 interprets it correctly. I suggest you change the |
Thanks. That makes the API a little awkward as the value on Linux is the accept queue length, so we'll need to rethink the API. |