-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Tracking Issue for TCP_QUICKACK support on Linux #96256
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
Comments
Add setter and getter for TCP_QUICKACK on TcpStream for Linux Reference issue rust-lang#96256 Setting TCP_QUICKACK on TcpStream for Linux
Add setter and getter for TCP_QUICKACK on TcpStream for Linux Reference issue rust-lang#96256 Setting TCP_QUICKACK on TcpStream for Linux
Add setter and getter for TCP_QUICKACK on TcpStream for Linux Reference issue rust-lang#96256 Setting TCP_QUICKACK on TcpStream for Linux
…dr, r=joshtriplett Move `unix_socket_abstract` feature API to `SocketAddrExt`. The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered. This PR makes four changes: 1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there. 2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change). 3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer. 4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly. Issues: 1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
…dr, r=joshtriplett Move `unix_socket_abstract` feature API to `SocketAddrExt`. The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered. This PR makes four changes: 1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there. 2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change). 3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer. 4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly. Issues: 1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
…dr, r=joshtriplett Move `unix_socket_abstract` feature API to `SocketAddrExt`. The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered. This PR makes four changes: 1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there. 2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change). 3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer. 4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly. Issues: 1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
…htriplett Move `unix_socket_abstract` feature API to `SocketAddrExt`. The pre-stabilized API for abstract socket addresses exposes methods on `SocketAddr` that are only enabled for `cfg(any(target_os = "android", target_os = "linux"))`. Per discussion in <rust-lang/rust#85410>, moving these methods to an OS-specific extension trait is required before stabilization can be considered. This PR makes four changes: 1. The internal module `std::os::net` contains logic for the unstable feature `tcp_quickack` (rust-lang/rust#96256). I moved that code into `linux_ext/tcp.rs` and tried to adjust the module tree so it could accommodate a second unstable feature there. 2. Moves the public API out of `impl SocketAddr`, into `impl SocketAddrExt for SocketAddr` (the headline change). 3. The existing function names and docs for `unix_socket_abstract` refer to addresses as being created from abstract namespaces, but a more accurate description is that they create sockets in *the* abstract namespace. I adjusted the function signatures correspondingly and tried to update the docs to be clearer. 4. I also tweaked `from_abstract_name` so it takes an `AsRef<[u8]>` instead of `&[u8]`, allowing `b""` literals to be passed directly. Issues: 1. The public module `std::os::linux::net` is marked as part of `tcp_quickack`. I couldn't figure out how to mark a module as being part of two unstable features, so I just left the existing attributes in place. My hope is that this will be fixed as a side-effect of stabilizing either feature.
The following PR proposes to stabilise the tcp_quickack feature, being present since 2yrs+ now.
|
Please consider adding a comment to Please also consider implementing support on Windows, which uses |
I think that would be a separate issue? It's not an exactly equivalent API and in any case obviously wouldn't be in |
Yes, absolutely. I mentioned it here because it's related, but it's certainly not a blocker. |
Feature gate:
#![feature(tcp_quickack)]
This is a tracking issue for linux specific socket option
TCP_QUICKACK
from linux man page TCP:
"Enable quickack mode if set or disable quickack mode if
cleared. In quickack mode, acks are sent immediately,
rather than delayed if needed in accordance to normal TCP
operation. This flag is not permanent, it only enables a
switch to or from quickack mode. Subsequent operation of
the TCP protocol will once again enter/leave quickack mode
depending on internal protocol processing and factors such
as delayed ack timeouts occurring and data transfer. This
option should not be used in code intended to be portable."
Public API
Steps / History
Unresolved Questions
Zulip Discussion
Windows .NET Discussion
Seems the windows API is significantly different from the Linux one to warrant a Linux specific trait.
The text was updated successfully, but these errors were encountered: